[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
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?