Hi,
from a user perspective (me) this is an excellent proposal.
Just to be able to access and verify config this way is gold.
Protected by ACI/ACL, of course.
In an enterprise environment it is more or less a prerequisite.
This may work in several fashions. A replica does auto configuration
based
on an ldap url like ldap://ds.some.domain entered into a conf-file or
as an
attribute in the DIT. When the attribute is saved, the the replica
starts
to do set-up.
The replica/consumer is doing its set-up by it self, maybe based on
type or
class of replica, consumer initiated replica (extract changes, pull
or polling),
supplier initiated replica (fed changes, push) or hub replica (fed
and feed changes).
This would then control the way config and replication is done. By
allowing
a replica to do it's set-up this way, managing a large distributed
landscape
is much less work, even in some cases made possible at all. We do not
have
skilled personnel everywhere.
One feature would be to have the possibility to set any part of the
configuration
as private, not accessible by auto configuration of a replica/consumer.
This would enable exceptions in the configuration and the replica
would then
use defaults. Making a private config public would make it propagate
in the landscape.
When the sever.xml is updated and loaded it overrides and update the
configuration
in the DIT. Well, it is handy to be able to update the server.xml
from the DIT information.
When managing a landscape of replicas it is vital to be able to
propagate changes to the
whole landscape and have the possibility to override a setting on all
replicas through
a central action. There are products that allow for replication of
schema updates which
is a huge timesaver and in some cases the only option from a
maintenance perspective.
I have been salvaged a number of times by the conf files in SunOne
when the config in the
master server was messed up but not saved to the conf files, like
core dumps.
Some config are both in the DIT and in a conf file.
At start-up the main conf file is read and it is saved at shutdown so
that changed config is made persistent outside the database as well.
Config is done through a management tool talking http and any changes
in the config
files done while the server is up and running are lost due to the
save at shutdown.
To be able to force a config file update without a server shutdown
would be good.
The servers may be up and running for years (hopefully) and you might
want to save
the config a bit more often.
A copy of the last successful startup config is also saved with the
startupOK sufix.
Very useful if there is a risk for corrupt config to be saved.
For what it is worth
/h
16 jul 2007 kl. 05:03 skrev Alex Karasulu:
Hi all,
Here's that thread on discussing the CiDIT agenda. Let's take a
look at the following
link before beginning:
http://directory.apache.org/apacheds/1.5/configuration-in-dit-
cidit.html
Thoughts? Comments?
Alex
---
Hans
mailto:[EMAIL PROTECTED]
