-----Original Message----- From: Quanah Gibson-Mount quanah@symas.com Sent: mercredi 20 mai 2020 23:25 To: Jean-Luc Chandezon jlch@lan-explore.fr; openldap- technical@openldap.org Subject: Re: Remove/change replication partner

--On Wednesday, May 20, 2020 3:33 PM +0000 Jean-Luc Chandezon jlch@lan-explore.fr wrote:

...

ldapmodify -Y EXTERNAL -H ldapi:/// -f removeConfigPartner.ldif

SASL/EXTERNAL authentication started

SASL username:

gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

...

SASL SSF: 0

modifying entry "olcDatabase={0}config,cn=config"

Sounds like the "mirrormode" parameter is incorrectly set to FALSE instead of TRUE. In any case, there's clearly multiple things wrong with your config DB (like the multiple syncprov overlays).

Once again, you're right.

I would suggest you use slapcat to export it to LDIF, fix it to be correct, and then import the corrected LDIF with slapadd.

I followed your advice by removing wrong lines, but I can not import with simple line : slapadd -n 0 -l /tmp/config.ldif

I removed these lines in "dn: olcDatabase={0}config,cn=config" and " dn: olcDatabase={1}mdb,cn=config" :

olcSyncrepl: {0}rid=01 provider=ldap://bea-olp-001. lanexplore.com binddn ="cn=replication,dc=lanexplore,dc=com" bindmethod=simple credentials= i4Df0rXigrdz8HtYZemJ searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=02 provider=ldap://cdb-olp-001. lanexplore.com binddn ="cn=replication,dc= lanexplore,dc=com" bindmethod=simple credentials= i4Df0rXigrdz8HtYZemJ searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: FALSE

olcSyncrepl: {0}rid=01 provider=ldap://bea-olp-001. lanexplore.com binddn ="cn=replication,dc= lanexplore,dc=com" bindmethod=simple credentials= i4Df0rXigrdz8HtYZemJ searchbase="dc= lanexplore,dc=com" type=refreshAn dPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=02 provider=ldap://cdb-olp-001.opticiens-atol.com binddn ="cn=replication,dc= lanexplore,dc=com" bindmethod=simple credentials= i4Df0rXigrdz8HtYZemJ searchbase="dc= lanexplore,dc=com" type=refreshAn dPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE

Result: slapadd: could not add entry dn="cn=config" (line=1)

Here are overlays config:

dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 5a27c6c6-675a-1039-8db6-a516a2c70684 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20190909143210Z entryCSN: 20190909143210.478109Z#000000#001#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20190909143210Z

dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: f6e4c5ce-7d4c-1039-8dc3-a516a2c70684 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20191007125146Z entryCSN: 20191007125146.068170Z#000000#001#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20191007125146Z

Can I safely remove these parts? May I change the next overlay index? (unique overlay for example)?

Thanks,

Jean-Luc

--Quanah

--

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

--On Wednesday, June 3, 2020 4:26 PM +0000 Jean-Luc Chandezon jlch@lan-explore.fr wrote:

...

I followed your advice by removing wrong lines, but I can not import with simple line : slapadd -n 0 -l /tmp/config.ldif

Result: slapadd: could not add entry dn="cn=config" (line=1)

Did you remove your existing configuration database files from /etc/ldap or wherever it is they exist prior to running the slapadd? slapadd will not overwrite existing files.

Yes I did. /etc/ldap/slapd.d is empty

Generally you may want to do something like:

cd /etc/ldap mv slapd.d slapd.d.orig mkdir slapd.d chown ldap:ldap slapd.d

I did believe that chown should be played after slapadd.

Note that the above is making guesses about (a) the location of your cn=config database and (b) the user/group used by slapd. Adjust accordingly.

Sure. For me it's the same location. I just need to replace ldap by openldap for chown.

Can I find/enable logging with error details?

Thank you, Jean-Luc

Regards, Quanah

--

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

-----Original Message----- From: Quanah Gibson-Mount quanah@symas.com Sent: mercredi 3 juin 2020 18:00 To: Jean-Luc Chandezon jlch@lan-explore.fr; openldap-

...

Can I find/enable logging with error details?

Add "-d -1" to the slapadd command to see why it's unhappy.

Great, thank you!

Note that that is a "minus one" after the -d option.

I can see the following logs:

5ed7ca87 : config_add_internal: DN="cn=config" already exists slapadd: could not add entry dn="cn=config" (line=1):

I checked one again that /etc/ldap/slapd.d is empty. What I missed?

Thanks again

Jean-Luc

...

...

Note that that is a "minus one" after the -d option.

I can see the following logs:

5ed7ca87 : config_add_internal: DN="cn=config" already exists slapadd: could not add entry dn="cn=config" (line=1):

I checked one again that /etc/ldap/slapd.d is empty. What I missed?

Is it using /etc/openldap/slapd.d rather than /etc/ldap/slapd.d perhaps? The output should include the location it is attempting to write to, IIRC.

In order to prepare multi-master replication, I imported config & data, with ldif export from another server. I imported with slapadd -F. It's not a best practice I believe.

Now I exported config with "slapcat -n 0", but my export keeps traces, isn't it? Can I correct this?

Thanks,

Jean-Luc

...

...

...

I can see the following logs:

5ed7ca87 : config_add_internal: DN="cn=config" already exists slapadd: could not add entry dn="cn=config" (line=1):

In order to prepare multi-master replication, I imported config & data, with ldif export from another server. I imported with slapadd -F. It's not a best practice I believe.

Now I exported config with "slapcat -n 0", but my export keeps traces, isn't it? Can I correct this?

I don't know what this statement means (my export keeps traces).

Sorry for my english. If I play "slapadd -d -1 -n 0 -l /tmp/config.ldif", there is the error above. If I specify "-F /etc/ldap/slap.d" in the slapadd command, it works fine. Do you know why?

Thanks,

Jean-Luc