[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Olc deployment vs slapd.conf based deployment
- To: openldap-technical@openldap.org
- Subject: Re: Olc deployment vs slapd.conf based deployment
- From: Andy Dorman <adorman@ironicdesign.com>
- Date: Thu, 14 Sep 2017 21:59:35 -0500
- Content-language: en-US
- In-reply-to: <77336596566E63C254BF34B5@[192.168.1.30]>
- References: <CALm_VjikYjnYEcrfKXYjm8AFt0VQ7EV1crGX=tXst3-RUbr7fQ@mail.gmail.com> <WM!5ccf6f006a0b3aa9abfbc3f9c9be3eb021708e582b17a98c6ed49d59b8e29485947e7650 daf5ed804e3554164491fa2d!@mailstronghold-1.zmailcloud.com> <78567B9241600A3CA0EAC7A6@[192.168.1.30]> <b9e230a5-1dc0-b01f-ae4d-d23e0cd21d3e@stroeder.com> <b7d93005-3de5-5b9a-630e-d93510bd9b44@ironicdesign.com> <WM!c441031e673082de9904bb70fc818ffda9b9f7dd5392e09c37cc5ccb7332246257b6daf5a456f233f94aa06df0aea0f3!@mailstronghold-1.zmailcloud.com> <77336596566E63C254BF34B5@[192.168.1.30]>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
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.
--
Andy Dorman
Ironic Design, Inc.
AnteSpam.com