Tony Stevenson wrote:
Emmanuel,
Hi Tony,
It's good to see some of these things on the list. However one or two
of these will be required should we decide to use ADS for the ASF. I
know we will be able to get a good basic LDAP service in place without
some of these, *but* some are core requirements to the implementation
of ADS within the ASF.
I'm perfectly aware of that :) A LDAP server without replication is
pretty useless, from a production POV.
For example, the replication system will be one such core fundamental
requirement. In fact we cannot really proceed a lot further with the
current demo/testing environment without it. What state is it
currently in?
It's running. The concern we have about it is that we didn't used it
_yet_ in a production environment (here the 'we' is Alex and me). We
have to review it. However, two of our committers have worked on it, and
one of them (Martin Alderson) has use the replication for its own
project, after a few fixes, one year ago.
We also have integration tests, still running after thousands of
commits, so I guess the replication system is still robust, as we didn't
modified the tests.
The fact that replication has been mentioned into the 'Toward 2.0' list
is because we want to be 100% sure that it works well, is solid, and
covers all the corner cases. We also want to move the current
implementation to something more versatile, based on the since added
Change Log system. This is what we want to work on in the next 4 months.
But the next 2 weeks will be dedicated to check that Mitoses (the
current replication code name) is working well.
Also before LDAP goes live we will need some good basic documentation,
which I can certainly help produce. These will mainly focus on system
runbooks, and who/what/where/how to make changes, stop/start services
etc.
We can work on that, for sure. As ADS is running as a daemon, it should
be pretty easy to write the basic documentation.
The DRS system is of interest to me.
You bet a lot of people are interested in it !
What happens at the moment if the system crashes?
...
Can we copy the flat files, daily, hourly?
...
Would they be re-usable. i.e. Could I copy the data files, and could
they be used again if copied over the other files? I am thinking
about a backup strategy for the LDAP data.
We do too. The think is that currently, we are relying on JDBM, and if
the server crash severely well, you may lost some data. This is
certainly not something we can accept. Now, this is the bad. About the
good : a LDAP server is known to be read most of the time, and written a
few. If we backup the JDBM files, hourly, we will be able to restart the
server and only lost a few modification. The ChangeLog system will be
extended in the next few days to write a journal (a LDIF file) in order
to be able to restore the server state. As we have a unique revision
number associated with each modification, a bit like subversion, we
should be able to apply this journal starting at some specific point in
the past we know to be good.
Those two features are for us the _most_ important things we want to
work on, and we want to start working on it right now, in order to get a
production ready server.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
