Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

["Michael StrÃder" <michael@stroeder.com>]

Aaron Richton <richton@nbcs.rutgers.edu> wrote
> On Thu, 6 Feb 2014, Paul B. Henson wrote:
> 
> >> Our servers do a nightly backup of cn=config via slapcat -n 0, and 
> >> those are kept for a month.  Since this is for clients, there's no 
> >> revision control involved, but it would be trivial for someone to check 
> >> in the resulting LDIF file into their favorite RCS system.
> >
> > Hmm, so the revision control system would transition from being the 
> > authoritative source of what the configuration is (ie, in our current 
> > system, if somehow the running configuration deviated from the version 
> > in revision control, it would automatically be corrected back) to simply 
> > becoming a record of whatever changes happen to have been made on the 
> > running configuration?
> 
> Off the top of my head, I'm not really seeing this. With slapd.conf:
> 
> (human on workstation)
> $RCS checkout repo/production.slapd.conf
> $EDITOR !$
> $RCS checkin repo/production.slapd.conf
> 
> (magical config overlord/human on server)
> $RCS checkout repo/production.slapd.conf
> cp repo/production.slapd.conf /server/production.slapd.conf
> pkill slapd
> slapd
> 
> 
> or slapd.d:
> 
> (human on workstation)
> $RCS checkout repo/production.slapd.ldif
> $EDITOR !$
> $RCS checkin repo/production.slapd.ldif
> 
> (magical config overlord/human on server)
> $RCS checkout repo/production.slapd.ldif
> ldifdiff /server/production.slapd.ldif repo/production.slapd.ldif >
> /tmp/diff.ldif ldapmodify [...] -f /tmp/diff.ldif
> slapcat -n0 -l /server/production.slapd.ldif
> 
> These both end up with the same state, and it's the same number of 
> commands! You can checkout and revert to the latest head/trunk/etc. or any 
> arbitrary rev with either config format. Monitoring in-core vs. on-disk 
> vs. expected-in-production committed config is possible in both cases and 
> actually easier/more comprehensive with cn=config. If "magical config 
> overlord" is a cron job then "automatically be corrected" happens with 
> both of these workflows. How are your hands tied in this case?

I'm checking in the VCS and from there the automated configuration (puppet,
ansible etc.) does the rest of it. Automatically diffing config DBs and apply
the changes is far more complicated than diffing text files. Especially the
latter gives you far better text logs of which changes were done.

Ciao, Michael.