directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans <hml...@gmail.com>
Subject Re: [ApacheDS] [CiDIT] Discussion
Date Fri, 20 Jul 2007 12:30:13 GMT
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:hmlhdr@gmail.com




Mime
View raw message