On Nov 21, 2007, at 4:37 AM, Gavin Henry wrote:
Scott Classen wrote: I added the syncprov overlay to the cn=config directive on the PROVIDER as such: cn=config olcDatabase={0}config olcOverlay={0}syncprov Now on a brand new CONSUMER machine I created the following LDIF file (sync-seed.ldif): dn: cn=config objectClass: olcGlobal cn: config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=ldapadmin,cn=config olcRootPW: {SSHA}mysoopersecretpasswd olcsyncrepl: rid=001 provider=ldap://my.provider.machine binddn="cn=ldapadmin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshOnly interval=00:00:00:10 I then put the file in my openldap dir and cd there: cd /usr/local/etc/openldap mkdir slapd.d slapadd -b "cn=config" -F slapd.d -l sync-seed.ldif all is OK I then start slapd: /usr/sbin/slapd -d 256 ... slapd starting syncrepl_message_to_entry: rid=001 mods check (olcDbConfig: value #6 provided more than once) do_syncrepl: rid=001 quitting Hmmm what have I done wrong? Thanks, Scott
Can you slapcat your config back out and show us everything?
slapdcat -n 0 > config.ldif
/usr/sbin/slapd not /usr/local/libexec/slapd ?
I have a symlink so ... yes, I'm using the right slapd (2.4.6)
here is the output from
slapdcat -n 0 > config.ldif on the CONSUMER machine
dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 2a37e848-2cba-102c-9007-85f7c9c1cd1d creatorsName: cn=config modifiersName: cn=config createTimestamp: 20071121201453Z modifyTimestamp: 20071121201453Z entryCSN: 20071121201453.411262Z#000000#000#000000
dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema
snip snip snip lots of schema definitions snip snip snip
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 2a37fc84-2cba-102c-9009-85f7c9c1cd1d creatorsName: cn=config createTimestamp: 20071121201453Z entryCSN: 20071121201453.412021Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20071121201453Z
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcSyncrepl: {0}rid=001 provider=ldap://myprovidermachine:389 binddn="cn=ldap admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshOnly interval=00:00:00:10 structuralObjectClass: olcDatabaseConfig entryUUID: 2a37f888-2cba-102c-9008-85f7c9c1cd1d creatorsName: cn=config modifiersName: cn=config createTimestamp: 20071121201453Z modifyTimestamp: 20071121201453Z entryCSN: 20071121201453.411896Z#000000#000#000000
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 20 600 olcSpSessionlog: 100 structuralObjectClass: olcSyncProvConfig entryUUID: fd14c728-2bdd-102c-8b89-17e8c59360fa creatorsName: cn=ldapadmin,cn=config createTimestamp: 20071120175848Z entryCSN: 20071120175848.403267Z#000000#000#000000 modifiersName: cn=ldapadmin,cn=config modifyTimestamp: 20071120175848Z
I've been thinking about this some and I am still confused about what is probably a fairly simple syncrepl concept.
What I have been trying to do is synchronize the cn=config base from the PROVIDER to the CONSUMER. My hope was that by replicating cn=config then all the other databases (well, really only the primary BDB for now) would then be automagically synched too. Does this make sense? My concern is that I am using TLS and currently the names of the crt and key files are different for the PROVIDER and CONSUMER so simply replicating the cn=config may not actually work unless I remain consistent in my naming of the SSL files. I guess I can do this, but I thought to clarify the idea with the openldap experts first.
I'm still hopeful. I really like the idea of building a new machine, compiling openldap, slapadding a seed LDIF file and instantly having a backup slave LDAP server.
Thanks, Scott