directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ApacheDS] [CiDIT] Discussion
Date Fri, 20 Jul 2007 17:39:20 GMT
Thanks for the feedback Hans.  I appreciate the use cases you've outlined
here for CiDIT since
they show real world situations which would benefit from this feature.  I'm
going to reread your
email a few times to add some of your suggestions to what we were thinking.


On 7/20/07, Hans <> wrote:
> 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:
> >
> >
> > cidit.html
> >
> > Thoughts? Comments?
> >
> > Alex
> >
> ---
> Hans

View raw message