Re: Olc deployment vs slapd.conf based deployment

[Quanah Gibson-Mount <quanah@symas.com>]

--On Thursday, September 14, 2017 10:59 PM -0500 Andy Dorman 
<adorman@ironicdesign.com> wrote:

Hi Andy,

> FWIW, we also need the git trail of changes over time.  I have not
> figured out a good way to do that with OLC.

Well, there are a few options I suppose:

a) You could set up an accesslog database that stores the changes made to 
cn=config over time.  If you had to have it in git, it shouldn't be 
particularly difficult to write a tool to parse those changes out into some 
format you desire

b) Since cn=config is simply a tree, you could have your cn=config in git, 
commit your changes there, and use a tool like ldapdiff to create 
changesets to apply programatically.  Then you keep a full git history of 
your configuration, and have the ability to create changesets out of it. 
It might actually be kind of useful to develop something like ldapdiff (or 
update it accordingly) that works specificaly with git commits.  You could 
build an entire automation setup for pushing out changes from that. ;)

> === To add the same attribute to our dev server running OLC:
>
> - print the current OLC config to copy exactly how the current object
> class is stored for use in my changes.ldif file. I do this because the
> first time I did an OLC change I had a typo and the server was down for
> almost an hour while I tried to find the typo and recover.
>
> - prepare a change.ldif file using the old OLC config for the object
> class along with the new attribute definition.  Adding the same new
> attribute as above looks like this:
>
> dn: cn={5}antespam,cn=schema,cn=config
> changetype: modify
> add: olcAttributeTypes
> olcAttributeTypes: ( idInteger:29 NAME 'asEstReportCardSpan' DESC 'How
> many days of data to include in EST Report Cards' SUP idInteger )
> -

Looks correct.

> delete: olcObjectClasses
> olcObjectClasses: ( idDomain:1 NAME 'asDomain' DESC 'A domain using
> AnteSpam' SUP top AUXILIARY MUST ( asSidelineServer $ asPlan ) MAY (
> asAcceptUnknown $ asActive $ asAdvanced $ asBlockList $ asCountAccepted $
> asCountDiscarded $ asCountRejected $ asCountSent $ asCountSidelined $
> asCountVirus $  asDestination $ asDisposeThreshold $ asPassList $
> asSidelineThreshold $ asSpam $ asVirus $ asCountValid $
> asCountUnconfirmed $ asCountInvalid $ asCountIndependent $
> asAddressListReminder $ asRejectInvalidSender $ asPingAddress $
> asBlockArchive $ asBlockDoc $ asBlockDocOn $ asBlockExecutable $
> asBlockGeoIP $ asBlockNonLatin $ asBlockPassDoc $ asExternalAuth $
> asAlias $ asPayInterval $ asPlanStart $ asPlanCredit $ asBackup $
> asBackupUsageStats $ asEmergencyEmail $ asEmergencyEmailOn $
> asEmergencyEmailOff $ asEmergencyEmailUsed $ fmExternal $ asOutbound $
> asOutboundAccount $ asOutboundNotify $ asBPReportEmail $
> fmMaxRecipientsPer24Hr $ asUstEnabled $ asUstUsage ) )
> -

You can delete by index number.  It'd be simpler to do something like
delete: olcObjectClasses
olcObjectClasses: {3}

(Or whatever index number it is).  This avoids having to write out the 
entire object for the delete operation.  I've used that as well with ACLs, 
which is handy.  Although if you have a useful ldapdiff tool, then it'll 
generate this correctly for you as well.


> add: olcObjectClasses
> olcObjectClasses: ( idDomain:1 NAME 'asDomain' DESC 'A domain using
> AnteSpam' SUP top AUXILIARY MUST ( asSidelineServer $ asPlan ) MAY (
> asAcceptUnknown $ asActive $ asAdvanced $ asBlockList $ asCountAccepted $
> asCountDiscarded $ asCountRejected $ asCountSent $ asCountSidelined $
> asCountVirus $  asDestination $ asDisposeThreshold $ asPassList $
> asSidelineThreshold $ asSpam $ asVirus $ asCountValid $
> asCountUnconfirmed $ asCountInvalid $ asCountIndependent $
> asAddressListReminder $ asRejectInvalidSender $ asPingAddress $
> asBlockArchive $ asBlockDoc $ asBlockDocOn $ asBlockExecutable $
> asBlockGeoIP $ asBlockNonLatin $ asBlockPassDoc $ asEstReportCardSpan $
> asExternalAuth $ asAlias $ asPayInterval $ asPlanStart $ asPlanCredit $
> asBackup $ asBackupUsageStats $ asEmergencyEmail $ asEmergencyEmailOn $
> asEmergencyEmailOff $ asEmergencyEmailUsed $ fmExternal $ asOutbound $
> asOutboundAccount $ asOutboundNotify $ asBPReportEmail $
> fmMaxRecipientsPer24Hr $ asUstEnabled $ asUstUsage ) )
>
> - After the changes.ldif is done, I just pass it to ldapmodify and, as
> long as there are no typos, everything works beautifully.
>
> And lastly, I will admit I haven't researched it recently, but when OLC
> first came out I did not find any docs on how to set OLC up in a
> master-slave arrangement so the OLC changes on the master are replicated
> to the slaves? At least I assume that is how changes should be handled?

This is already covered in test059 in the OpenLDAP test suite. ;)  For this 
scenario what you have is:

provider server with:
cn=config db (master configuration)
back-ldif db (replica configuration)

replica server(s) that use syncrepl with the suffixmassage parameter to 
replica from the back-ldif DB on the master.  This allows you to isolate 
out the replica configuration, since it by definition has to differ from 
the provider configuration.  To update the replica configs, you simply do a 
write to the ldap provider's back-ldif DB, and the replicas all pull it 
down immediately.  One write op -> Updates all replicas.

> So anyway, we need a git trail of changes (or some sort of change log)
> and I need to figure out how to set up delta-syncrepl for cn=config and
> then seamlessly and safely transition 15 slaves and a master.  If I can
> do this I will jump on the cn=config wagon.

This is possible as noted above. ;)  I've put it on my to-do list however 
to create a test script that covers delta-sync replication for cn=config 
(There's none currently covering that).  Then it can be used as an example. 
;)

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>