7:33 a.m.
Hello,
I'm trying to remove replication partner (olcSyncrepl overlay).
Here are results for partner parameter(config):
# ldapsearch -LLLY external -H ldapi:/// -b "olcDatabase={0}config,cn=config"
olcSyncRepl
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=01 provider=ldap://bea-olp-001.lan-explore.fr binddn="
cn=replication,dc= lan-explore,dc=fr" bindmethod=simple credentials=i2Df
0rXiQokb8HtYZemJ searchbase="cn=config" type=refreshAndPersist retry="5 5
300
5" timeout=1
olcSyncrepl: {1}rid=02 provider=ldap://cdb-olp-001. lan-explore.fr binddn="
cn=replication,dc= lan-explore,dc=fr" bindmethod=simple credentials=i2Df
0rXiQokb8HtYZemJ searchbase="cn=config" type=refreshAndPersist retry="5 5
300
5" timeout=1
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
dn: olcOverlay={2}syncprov,olcDatabase={0}config,cn=config
I tested this query:
dn: olcDatabase={0}config,cn=config
changetype: modify
delete: olcSyncrepl
The result is:
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"
ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral
Please what I missed?
Thanks,
Jean-Luc
2:25 p.m.
--On Wednesday, May 20, 2020 3:33 PM +0000 Jean-Luc Chandezon
<jlch(a)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).
I would suggest you use slapcat to export it to LDIF, fix it to be correct,
and then import the corrected LDIF with slapadd.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:26 a.m.
-----Original Message-----
From: Quanah Gibson-Mount <quanah(a)symas.com>
Sent: mercredi 20 mai 2020 23:25
To: Jean-Luc Chandezon <jlch(a)lan-explore.fr>; openldap-
technical(a)openldap.org
Subject: Re: Remove/change replication partner
--On Wednesday, May 20, 2020 3:33 PM +0000 Jean-Luc Chandezon
<jlch(a)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>
8:46 a.m.
--On Wednesday, June 3, 2020 4:26 PM +0000 Jean-Luc Chandezon
<jlch(a)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.
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
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.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:52 a.m.
--On Wednesday, June 3, 2020 4:26 PM +0000 Jean-Luc Chandezon
<jlch(a)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>
9 a.m.
--On Wednesday, June 3, 2020 4:52 PM +0000 Jean-Luc Chandezon
<jlch(a)lan-explore.fr> wrote:
Can I find/enable logging with error details?
Add "-d -1" to the slapadd command to see why it's unhappy.
Note that that is a "minus one" after the -d option.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
9:15 a.m.
-----Original Message-----
From: Quanah Gibson-Mount <quanah(a)symas.com>
Sent: mercredi 3 juin 2020 18:00
To: Jean-Luc Chandezon <jlch(a)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
9:33 a.m.
--On Wednesday, June 3, 2020 5:15 PM +0000 Jean-Luc Chandezon
<jlch(a)lan-explore.fr> wrote:
> 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.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:54 a.m.
>> 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
10:27 a.m.
--On Thursday, June 4, 2020 10:54 AM +0000 Jean-Luc Chandezon
<jlch(a)lan-explore.fr> wrote:
> >> 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?
I don't know what this statement means (my export keeps traces).
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:10 a.m.
>> >
>> > 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
6:02 a.m.
On Mon, Jun 08, 2020 at 09:10:47AM +0000, Jean-Luc Chandezon wrote:
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?
I have a guess, based on symptoms in my own environment. In my
case:
I have two versions of OpenLDAP installed (with corresponding slapadd
binaries).
The one in my path the default one that came with the OS. I later
installed a newer version of OpenLDAP, to introduce some key feature.
The default slapadd has some default sense of where config files
are, but my DB is being driven by a different set of config files
(associated with the newer installation).
When I try to use the CLI tools, I have to expressly tell the tool
where the correct config files are, to perform the operation I need.
Thanks,
Jean-Luc
--
Brian Reichert <reichert(a)numachi.com>
BSD admin/developer at large
1023
days inactive
1042
days old
openldap-technical@openldap.org
11 comments
3 participants
participants (3)
-
Brian Reichert -
Jean-Luc Chandezon -
Quanah Gibson-Mount