On 09/14/2017 07:36 PM, Quanah Gibson-Mount wrote:

--On Thursday, September 14, 2017 6:30 PM -0500 Andy Dorman adorman@ironicdesign.com wrote:

...

I have our dev server using OLC and it takes me twice as long to modify it's config than the 15 other servers we have running openLDAP.

It takes all of ldapadd/modify to modify cn=config.  If you're having that much difficulty, it sounds like you don't understand how to use cn=config.

--Quanah

Quanah, what you say about my lack of understanding is very likely and the last thing I want to do take your valuable time to explain things to me...but I would like to explain my situation. Then I will revisit the docs to see if any questions I mention below have been answered in the past couple of years since I last researched moving to OLC.

FWIW, I have always suspected I may be making OLC unnecessarily complex and would love to find a better way to do it....

So, my issue is, using OLC is not a question of the number of steps involved, but the complexity of the steps.

=== Currently...to add a new attribute to all our servers using the static conf file:

- edit the conf file in our git repository to add the attribute definition and modify the object class the new attribute will be used in. Altogether about 3 new, easily read and proofed lines of text for the attribute and adding it to the appropriate object class like this:

attributetype ( idInteger:29 NAME 'asEstReportCardSpan' DESC 'How many days of data to include in EST Report Cards' SUP idInteger )

objectclass ( 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 $ asSendingServers $ asSidelineThreshold $ asSpam $ asVirus $ asCountValid $ asCountUnconfirmed $ asCountInvalid $ asCountIndependent $ asAddressListReminder $ asRejectInvalidSender $ asPingAddress $ asBlockArchive $ asBlockDoc $ asBlockDocOn $ asBlockExecutable $ asBlockGeoIP $ asBlockNonLatin $ asBlockPassDoc $ asDomainManaged $ asDomainProhibitAlias $ asEstReportCardSpan $ asExternalAuth $ asAlias $ asPayInterval $ asPlanStart $ asPlanCredit $ asBackup $ asBackupUsageStats $ asEmergencyEmail $ asEmergencyEmailOn $ asEmergencyEmailOff $ asEmergencyEmailUsed $ fmExternal $ asOutbound $ asOutboundAccount $ asOutboundNotify $ asBPReportEmail $ fmMaxRecipientsPer24Hr $ asUstEnabled $ asUstUsage ) )

- Then I run our automated test suite to ensure the new attribute works as planned and there are no surprises.

- Once I am sure the modify conf file is going to work, I check the new conf file into the repo and push it to our configuration management system. From there the configuration management system automatically takes care of pushing the changes to all servers and restarting LDAP. And our service has enough redundancy that a restart of one LDAP server, even the master, is not a big deal.

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

=== 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 ) - 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 ) ) - 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?

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.

Thanks.

Quanah Gibson-Mount wrote:

It takes all of ldapadd/modify to modify cn=config. If you're having that much difficulty, it sounds like you don't understand how to use cn=config.

I'm also having this difficulties with cn=config.

And the upgrade issue with 'pwdMaxRecordedFailure' (see other mail thread) serves as good example how easy it is to run into a operational dead-end with cn=config. There's no easy way to fix this afterwards without violating what's considered best practice for maintaining cn=config. I could give several other examples for this kind of operational dead-ends.

So do you think my LDAP skills are not strong enough?

Ciao, Michael.