Re: Provider-Consumer replication 2.4 OLC (second attempt)

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

--On Friday, October 28, 2016 9:50 AM -0400 Ted Hyde <laserted@gmail.com> 
wrote:

> Quanah - thanks for the response. Sorry to insult if I did - but thank
> you, I DID read the admin guide. Which as you have also pointed out uses
> slapd.conf examples. Since I am not knee-deep in commercial OpenLdap
> configuration every day (I am just a lowly IT admin, not a
> paid-to-openldap-person) I would disagree in that your comment that
> "conversion to cn=config" process isn't trivial, personally I get quite
> swamped by it, but push through as best I can. But if you're offering to
> convert my sample configs for me, I'd be happy to share them with you.

You can convert your sample configs via the slaptest command, as documented.

> Or
> perhaps you could help the community by providing some OLC config
> examples for the admin guide, that way us peons would be able to use that
> as our only official source instead of having to google to find "Random"
> help.

My point was more that converting examples in the admin guide from 
slapd.conf to cn=config is fairly trivial.

For example, if we look at section 18.3.1.2 in the admin guide:

       database mdb
       maxsize 1073741824
       suffix dc=Example,dc=com
       rootdn dc=Example,dc=com
       directory /var/ldap/db
       index objectclass,entryCSN,entryUUID eq

       overlay syncprov
       syncprov-checkpoint 100 10
       syncprov-sessionlog 100

this is rather trivially converted to:

dn: olcDatabase={1}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcSuffix: dc=example,dc=com
olcRootDN: dc=example,dc=com
olcDbDirectory: /var/ldap/db
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq

dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcSpCheckpoint: 100 10
olcSpSessionlog: 100


etc.  Converting to cn=config from slapd.conf is not particularly difficult.


> I *can* move to refreshAndPersist; but the service provides two
> documented options (information I got from reading the admin guide), the
> description for refreshOnly best fits my scenario and needs. I didn't
> read any reason as to *not* use - perhaps you're aware of a bug report
> that refreshOnly is broken?

I'm aware that operating in refreshOnly is problematic, and it is advise 
not to use it.  If you want to persist in using it, I certainly can't stop 
you. ;)  If/when I find time to rewrite the admin guide, removing it from 
the examples will be one of the first steps I take.

> Perhaps my research (which I'm sure isn't as broad as yours) just seemed
> to point to the fact that openldap will/may be depreciating the
> slapd.conf procedures, and that everyone should get on board with OLC as
> soon as possible. While I can perform the setup with slapd.conf (as noted
> in the admin guide), I was hoping to practice some useful technique I
> could use in the future.

Again, as noted in the documentation, you can set up one time with 
slapd.conf, and then move forward with converting it to cn=config via 
slaptest, and then just use cn=config from that point forward, using ldap* 
commands to make updates as necessary.

If you want some further examples of cn=config, you may like the following:

<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/conf/ldap/config/>

Which has a basic cn=config layout for a standalone server with a suffix of 
"" and a few overlays loaded as a starting point.

You may also be interested in the tools I wrote for manipulating cn=config 
to use as examples:
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapenable-mmr>
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapenablereplica>
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapreplicatool>
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapmmrtool>

etc.  While bits of it are specific to Zimbra, the ideas behind 
updating/modifying cn=config are universal.

On the documentation, I would note that it is a community effort, and 
anyone can contribute updates, etc, via the ITS system.  The sad fact is, 
many people complain about the documentation, but very few ever step up and 
contribute back, which means that it often languishes.

I hope the above helps.

Regards,
Quanah


--

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