--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