syncrepl does not work as expected

List overview All Threads
Download

newer

older

Re: [EXT] Re: syncrepl does not...

Privileges for slapd service

rahul2002mit＠gmail.com

9 Jun 2020 9 Jun '20

8:12 a.m.

I am using LDAP protocol as front end and Berkeley DB as back end. I am observing a strange syncrepl issue

type=refreshAndPersist is being used $OpenLDAP: slapd 2.4.44 OS: RHEL7U6

I have 2 server setup say S1 and S2. S1 is in provider and S2 is in consumer mode. Added data D1 in database and that was synced with S2 database. Now I killed slapd process on server S1.

At this point server S2 assumes provider role. Now I removed data D1 from database using server S2. Once deletion is complete validated that data was removed from server S2 database.

Now i brought S1 slapd service back up and started the application which starts syncrepl.

Here is what i see

both server S1 and S2 has data D1 which was actually deleted.

Expected behavior: Both server should sync properly and data D1 which was deleted using Server S2 should not be present in the database after sync.

Request you guys to help.

Thanks Rahul

Show replies by thread

Quanah Gibson-Mount

9 Jun 9 Jun

8:26 a.m.

--On Tuesday, June 9, 2020 4:12 PM +0000 rahul2002mit@gmail.com wrote:

...

$OpenLDAP: slapd 2.4.44

That release is over 4 years old. Please use a current release. There are a variety of options available, such as Symas OpenLDAP for Linux for RHEL7, which is a drop in replacement using the current release (https://repo.symas.com/sofl/rhel7/) or the LTB project which installs into an alternate location (https://ltb-project.org/documentation/openldap-rpm#yum_repository).

Please use delta-syncrepl rather than standard syncrepl.

Regards, Quanah

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

rahul2002mit＠gmail.com

8:32 a.m.

Hi Quanah

Thank you for quick response. is Symas OpenLDAP or LTB project open source?

I am new to LDAP. Can you help me with configuration guidelines of delta-syncrepl?

Thank you in advance.

Thanks Rahul

Quanah Gibson-Mount

8:40 a.m.

--On Tuesday, June 9, 2020 4:32 PM +0000 rahul2002mit@gmail.com wrote:

...

Hi Quanah

Thank you for quick response. is Symas OpenLDAP or LTB project open source?

OpenLDAP is an open source project. The Symas OpenLDAP for Linux and LTB project are providing compiled binaries of that open source.

...

I am new to LDAP. Can you help me with configuration guidelines of delta-syncrepl?

https://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl%20replication

https://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl

https://mishikal.wordpress.com/2019/04/23/configuring-mmr-using-delta-syncrepl-in-openldap-updating-an-existing-standalone-configuration/

Regards, Quanah

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

rahul2002mit＠gmail.com

8:55 a.m.

Thank you Quanah for help. Let me try new binary and will update.

Thanks Rahul

rahul2002mit＠gmail.com

2:36 p.m.

Hi Quanah

I download the openldap version 2.4.50 from here https://www.openldap.org/software/download/ and installed. I made no other configuration changes but i still see the issue. The issue is seen only with delete operation. For add operation sync works fine

I have 2 server setup say S1 and S2. S1 is in provider and S2 is in consumer mode. Now I killed slapd process on server S1.

At this point server S2 assumes provider role. Now I added data D1 into database using server S2. Once addition is complete validated that data was added into server S2 database.

Now i brought S1 slapd service back up and started the application which starts syncrepl.

Both Servers S1 and S2 were synced.

So i am not able to understand why in case of delete sync does not work properly and both database ends us having stale data.

Thank you for all the help!

Thanks Rahul

Quanah Gibson-Mount

2:56 p.m.

--On Tuesday, June 9, 2020 10:36 PM +0000 rahul2002mit@gmail.com wrote:

...

Hi Quanah

I download the openldap version 2.4.50 from here https://www.openldap.org/software/download/ and installed. I made no other configuration changes but i still see the issue. The issue is seen only with delete operation. For add operation sync works fine

You haven't provided your configuration, so whether or not your syncrepl configuration is valid is unknown. Also, you do not note if you updated your configuration to use delta-syncrepl.

At a guess you may be hitting something like ITS#8125, which is a known problem with standard syncrepl and why I explicitly said to use delta-syncrepl.

Regards, Quanah

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

rahul2002mit＠gmail.com

3:08 p.m.

Thank you for response. Can you provide me the link to issue ITS#8125. In the mean time I am going though your blog to understand delta-syncrepl configuration.

Unfortunately i cannot share the exact configuration details. But here is the scenario when delete works as well

2 server setup say S1 and S2. S1 is in provider and S2 is in consumer mode. 1) killed slapd process on server S2. 2) Added data D1 using server S1. 3) Brought back server S2, sync worked fine. 4) Killed slapd process on server S1. 5) Added data D2 using server S2. 6) Brought back server S1, sync worked fine. 7) killed slapd process on server S2. 8) Removed data D1 using server S1. 9) Brought back server S2, sync worked fine.

Thank you for help!

Thanks Rahul

Quanah Gibson-Mount

3:36 p.m.

--On Tuesday, June 9, 2020 11:08 PM +0000 rahul2002mit@gmail.com wrote:

...

Thank you for response. Can you provide me the link to issue ITS#8125. In the mean time I am going though your blog to understand delta-syncrepl configuration.

Unfortunately i cannot share the exact configuration details. But here is the scenario when delete works as well

2 server setup say S1 and S2. S1 is in provider and S2 is in consumer mode. 1) killed slapd process on server S2. 2) Added data D1 using server S1. 3) Brought back server S2, sync worked fine. 4) Killed slapd process on server S1. 5) Added data D2 using server S2. 6) Brought back server S1, sync worked fine. 7) killed slapd process on server S2. 8) Removed data D1 using server S1. 9) Brought back server S2, sync worked fine.

Your description doesn't make logical sense, as by definition a pure consumer cannot accept direct write operations. If it does, it would indicate you have not configured replication correctly.

Regards, Quanah

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

Quanah Gibson-Mount

3:44 p.m.

--On Tuesday, June 9, 2020 11:08 PM +0000 rahul2002mit@gmail.com wrote:

...

Thank you for response. Can you provide me the link to issue ITS#8125.

https://bugs.openldap.org/show_bug.cgi?id=8125

Regards, Quanah

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

rahul2002mit＠gmail.com

3:52 p.m.

Both the servers are configured as Provider and consumer in my configuration. But the write always happens to the active server(Our application decides which server is active). As soon as the Active server goes down the other server becomes active hence all the writes start going to that server. By definition i thought a master can be consumer as well. Let me if this assumption is correct.

Thanks Rahul

Quanah Gibson-Mount

4:32 p.m.

--On Tuesday, June 9, 2020 11:52 PM +0000 rahul2002mit@gmail.com wrote:

...

Both the servers are configured as Provider and consumer in my configuration. But the write always happens to the active server(Our application decides which server is active). As soon as the Active server goes down the other server becomes active hence all the writes start going to that server. By definition i thought a master can be consumer as well. Let me if this assumption is correct.

If you're running multimaster, yes, a node can be both a provider and a consumer.

You'll really need to provide your configuration if you want further help (passwords redacted), as I've no idea if it's remotely valid.

Regards, Quanah

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

rahul2002mit＠gmail.com

4:54 p.m.

Here is the configuration information. Let me know if you need more info.

Provider ++++++++++++++++++++ dn: olcOverlay=syncprov, olcDatabase={1}mdb,cn=config objectclass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10

Consumer +++++++++++++++++++++++++++++++++++++++ dn: cn=config changetype: modify add: olcServerId olcServerId: <Server ID> Unique value assigned For S1 = 1, S2 = 2

dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcAccess olcAccess: to * by dn.base="cn=info,dc=data" read by * break - add: olcDbIndex olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq

Initial config +++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: <>

dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema

include: file:///usr/local/etc/openldap/schema/core.ldif include: file:///usr/local/etc/openldap/schema/cosine.ldif include: file:///usr/local/etc/openldap/schema/nis.ldif include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif

Init config DIT ++++++++++++++++++++++++++++ dn: dc=server-config objectClass: dcObject objectClass: organization dc: server-config o: ServerGlobalConfigs

Xuhua Lin

7:20 p.m.

Have you tried mirror-mode for multi-master?

Xuhua

Quanah Gibson-Mount

8:31 p.m.

--On Wednesday, June 10, 2020 3:20 AM +0000 Xuhua Lin xuhua.lin@gmail.com wrote:

...

Have you tried mirror-mode for multi-master?

That's what he described as doing...

--Quanah

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

Xuhua Lin

8:55 p.m.

I mean there should be an option "mirrormode on" in the config?

Xuhua

Quanah Gibson-Mount

10 Jun 10 Jun

8:21 a.m.

--On Wednesday, June 10, 2020 12:54 AM +0000 rahul2002mit@gmail.com wrote:

...

Here is the configuration information. Let me know if you need more info.

These random snippets do not a configuration make. Please provide the full configuration information for both of the providers.

slapcat -n 0 -a "(!(entryDN:dnSubtreeMatch:=cn=schema,cn=config))" -l /tmp/config.ldif

redact any passwords.

Regards, Quanah

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

rahul2002mit＠gmail.com

8:28 p.m.

Hi Quanah

Please find the output of the command as requested

Server S1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: 921d4e8a-3fcb-103a-9160-bb4344d6cab0 creatorsName: cn=config createTimestamp: 20200611010648Z olcServerID: 1 entryCSN: 20200611010648.811142Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010648Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 921d5f38-3fcb-103a-9162-bb4344d6cab0 creatorsName: cn=config createTimestamp: 20200611010648Z entryCSN: 20200611010648.652744Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010648Z

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: <password> structuralObjectClass: olcDatabaseConfig entryUUID: 921d5c90-3fcb-103a-9161-bb4344d6cab0 creatorsName: cn=config createTimestamp: 20200611010648Z entryCSN: 20200611010648.652672Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010648Z

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/data_db olcSuffix: dc=data olcRootDN: cn=info,dc=data olcRootPW:: <password> olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 92275682-3fcb-103a-9dbc-c3eb7e1096c9 creatorsName: cn=config createTimestamp: 20200611010648Z olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break olcSyncrepl:: ezB9cmlkPTAwMQogICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8vMzMuMz MuMzMuNjA6Mzg5CiAgICAgICAgICAgICAgIHR5cGU9cmVmcmVzaEFuZFBlcnNpc3QKICAgICAgI CAgICAgICAgcmV0cnk9IjIgMTAgNjAgKyIKICAgICAgICAgICAgICAgc2VhcmNoYmFzZT0iZGM9 c21hcnRzYW4iCiAgICAgICAgICAgICAgIHNjb3BlPXN1YgogICAgICAgICAgICAgICBhdHRycz0 iKiwrIgogICAgICAgICAgICAgICBiaW5kbWV0aG9kPXNpbXBsZQogICAgICAgICAgICAgICBiaW 5kZG49ImNuPWFkbWluLGRjPXNtYXJ0c2FuIgogICAgICAgICAgICAgICBjcmVkZW50aWFscz1zZ WNyZXQyCiAgICAgICAgICAgICAgIHRpbWVvdXQ9MQ== olcMirrorMode: TRUE entryCSN: 20200611010717.666697Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20200611010717Z

dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 9232ff3c-3fcb-103a-9dc0-c3eb7e1096c9 creatorsName: cn=config createTimestamp: 20200611010648Z entryCSN: 20200611010648.794462Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010648Z

dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/openldap-data/data_config_db olcSuffix: dc=server-config olcRootDN: cn=admin,dc=server-config olcRootPW:: <password> olcDbIndex: objectClass eq structuralObjectClass: olcMdbConfig entryUUID: 922a5bac-3fcb-103a-9dbd-c3eb7e1096c9 creatorsName: cn=config createTimestamp: 20200611010648Z entryCSN: 20200611010648.737846Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010648Z

=============================================================

Server S2 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: 9ced39a6-3fcb-103a-9772-1daafa61332c creatorsName: cn=config createTimestamp: 20200611010706Z olcServerID: 2 entryCSN: 20200611010706.956958Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010706Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 9ced5a26-3fcb-103a-9774-1daafa61332c creatorsName: cn=config createTimestamp: 20200611010706Z entryCSN: 20200611010706.792979Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010706Z

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: c2VjcmV0 structuralObjectClass: olcDatabaseConfig entryUUID: 9ced56fc-3fcb-103a-9773-1daafa61332c creatorsName: cn=config createTimestamp: 20200611010706Z entryCSN: 20200611010706.792893Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010706Z

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/data_db olcSuffix: dc=data olcRootDN: cn=info,dc=data olcRootPW:: <password> olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 9cf76dd6-3fcb-103a-94f5-197008472876 creatorsName: cn=config createTimestamp: 20200611010706Z olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break olcSyncrepl:: ezB9cmlkPTAwMQogICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8vMzMuMz MuMzMuNTA6Mzg5CiAgICAgICAgICAgICAgIHR5cGU9cmVmcmVzaEFuZFBlcnNpc3QKICAgICAgI CAgICAgICAgcmV0cnk9IjIgMTAgNjAgKyIKICAgICAgICAgICAgICAgc2VhcmNoYmFzZT0iZGM9 c21hcnRzYW4iCiAgICAgICAgICAgICAgIHNjb3BlPXN1YgogICAgICAgICAgICAgICBhdHRycz0 iKiwrIgogICAgICAgICAgICAgICBiaW5kbWV0aG9kPXNpbXBsZQogICAgICAgICAgICAgICBiaW 5kZG49ImNuPWFkbWluLGRjPXNtYXJ0c2FuIgogICAgICAgICAgICAgICBjcmVkZW50aWFscz1zZ WNyZXQyCiAgICAgICAgICAgICAgIHRpbWVvdXQ9MQ== olcMirrorMode: TRUE entryCSN: 20200611010718.020345Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20200611010718Z

dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 9d04652c-3fcb-103a-94f9-197008472876 creatorsName: cn=config createTimestamp: 20200611010706Z entryCSN: 20200611010706.943989Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010706Z

dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/openldap-data/data_config_db olcSuffix: dc=server-config olcRootDN: cn=admin,dc=server-config olcRootPW:: <password> olcDbIndex: objectClass eq structuralObjectClass: olcMdbConfig entryUUID: 9cfafe9c-3fcb-103a-94f6-197008472876 creatorsName: cn=config createTimestamp: 20200611010706Z entryCSN: 20200611010706.882383Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200611010706Z

Kumar Rahul

15 Jun 15 Jun

8:21 a.m.

Hi Quanah

I have provided the command output you requested. Let me know if you need more information.

Thanks Rahul

Quanah Gibson-Mount

10:03 a.m.

--On Thursday, June 11, 2020 4:28 AM +0000 rahul2002mit@gmail.com wrote:

...

Hi Quanah

Please find the output of the command as requested

Your configuration shows that you have not configured a session log as a part of the syncprov overlay. This is not an optional parameter. It should be no smaller than the total number of entries in your db (I usually suggest entries + 10% or so).

Regards, Quanah

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

Kumar Rahul

12:05 p.m.

Hi Quanah

I added session log as part of syncprov but the sync still does not work as expected. I still see the same issue.

Here is configuration from server S1 after adding session log to syncprov

Server S1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: 2ef0a49a-4383-103a-9074-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z olcServerID: 1 entryCSN: 20200615183843.452534Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 2ef0b962-4383-103a-9076-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.152282Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: <Password> structuralObjectClass: olcDatabaseConfig entryUUID: 2ef0b638-4383-103a-9075-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.152195Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/data_db olcSuffix: dc=smartsan olcRootDN: cn=info,dc=data olcRootPW:: <Password> olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 2f11ecae-4383-103a-87c8-85fd54de9add creatorsName: cn=config createTimestamp: 20200615183843Z olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break olcSyncrepl:: ezB9cmlkPTAwMQogICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8vMzMuMz MuMzMuNjA6Mzg5CiAgICAgICAgICAgICAgIHR5cGU9cmVmcmVzaEFuZFBlcnNpc3QKICAgICAgI CAgICAgICAgcmV0cnk9IjIgMTAgNjAgKyIKICAgICAgICAgICAgICAgc2VhcmNoYmFzZT0iZGM9 c21hcnRzYW4iCiAgICAgICAgICAgICAgIHNjb3BlPXN1YgogICAgICAgICAgICAgICBhdHRycz0 iKiwrIgogICAgICAgICAgICAgICBiaW5kbWV0aG9kPXNpbXBsZQogICAgICAgICAgICAgICBiaW 5kZG49ImNuPWFkbWluLGRjPXNtYXJ0c2FuIgogICAgICAgICAgICAgICBjcmVkZW50aWFscz1zZ WNyZXQyCiAgICAgICAgICAgICAgIHRpbWVvdXQ9MQ== olcMirrorMode: TRUE entryCSN: 20200615183925.011817Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20200615183925Z

dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 structuralObjectClass: olcSyncProvConfig entryUUID: 2f1c8e16-4383-103a-87cc-85fd54de9add creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.439528Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/openldap-data/data_config_db olcSuffix: dc=server-config olcRootDN: cn=admin,dc=server-config olcRootPW:: <Password> olcDbIndex: objectClass eq structuralObjectClass: olcMdbConfig entryUUID: 2f14d720-4383-103a-87c9-85fd54de9add creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.388967Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

Thanks Rahul

Quanah Gibson-Mount

12:29 p.m.

--On Monday, June 15, 2020 8:05 PM +0000 Kumar Rahul rahul2002mit@gmail.com wrote:

...

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/data_db olcSuffix: dc=smartsan olcRootDN: cn=info,dc=data olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break

Assuming the above is your actual configuration, then..

Your sync replication configuration uses:

binddn="cn=admin,dc=smartsan"

But this identity is given no access to your database, as it's not the rootDN, and there are no ACLs providing access to it.

As an aside, your ACL {0} makes no sense since you have cn=info,cn=data as your rootdn, and rootdn's are not subject to access control. The only other thing it does is break to the default ACL of to * by * none.

Regards, Quanah

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

Kumar Rahul

12:42 p.m.

Sorry I gave you output from different server. Here is configuration info from the right server. Let me know if configuration looks right.

++++++++++++++++++++++++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: 2ef0a49a-4383-103a-9074-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z olcServerID: 1 entryCSN: 20200615183843.452534Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 2ef0b962-4383-103a-9076-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.152282Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/data_db olcSuffix: dc=data olcRootDN: cn=info,dc=data olcRootPW:: <Password> olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 2f11ecae-4383-103a-87c8-85fd54de9add creatorsName: cn=config createTimestamp: 20200615183843Z olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break olcSyncrepl:: ezB9cmlkPTAwMQogICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8vMzMuMz MuMzMuNjA6Mzg5CiAgICAgICAgICAgICAgIHR5cGU9cmVmcmVzaEFuZFBlcnNpc3QKICAgICAgI CAgICAgICAgcmV0cnk9IjIgMTAgNjAgKyIKICAgICAgICAgICAgICAgc2VhcmNoYmFzZT0iZGM9 c21hcnRzYW4iCiAgICAgICAgICAgICAgIHNjb3BlPXN1YgogICAgICAgICAgICAgICBhdHRycz0 iKiwrIgogICAgICAgICAgICAgICBiaW5kbWV0aG9kPXNpbXBsZQogICAgICAgICAgICAgICBiaW 5kZG49ImNuPWFkbWluLGRjPXNtYXJ0c2FuIgogICAgICAgICAgICAgICBjcmVkZW50aWFscz1zZ WNyZXQyCiAgICAgICAgICAgICAgIHRpbWVvdXQ9MQ== olcMirrorMode: TRUE entryCSN: 20200615183925.011817Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20200615183925Z

dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/openldap-data/data_config_db olcSuffix: dc=server-config olcRootDN: cn=admin,dc=server-config olcRootPW:: <Password> olcDbIndex: objectClass eq structuralObjectClass: olcMdbConfig entryUUID: 2f14d720-4383-103a-87c9-85fd54de9add creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.388967Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

Quanah Gibson-Mount

1:09 p.m.

--On Monday, June 15, 2020 8:42 PM +0000 Kumar Rahul rahul2002mit@gmail.com wrote:

...

Sorry I gave you output from different server. Here is configuration info from the right server. Let me know if configuration looks right.

This config has the same issues as the prior config. It uses a DN for replication that has no access.

Regards, Quanah

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

Kumar Rahul

1:21 p.m.

Hi Quanah

Based on the configuration i have provided , can you suggest the change I need to make to grant access?

Thanks Rahul

Quanah Gibson-Mount

1:28 p.m.

--On Monday, June 15, 2020 9:21 PM +0000 Kumar Rahul rahul2002mit@gmail.com wrote:

...

Hi Quanah

Based on the configuration i have provided , can you suggest the change I need to make to grant access?

Since the DN used for replication is:

"cn=admin,dc=smartsan"

You need to ensure that DN has full read access on both systems.

Regards, Quanah

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

Kumar Rahul

1:32 p.m.

How do I check on both systems that the DN has full read access?

Kumar Rahul

1:36 p.m.

Here is olcaccess config on both servers. Server does seem to have read access with DN

olcAccess: to * by dn.base="cn=admin,dc=smartsan" read by * break

Quanah Gibson-Mount

1:46 p.m.

--On Monday, June 15, 2020 9:36 PM +0000 Kumar Rahul rahul2002mit@gmail.com wrote:

...

olcAccess: to * by dn.base="cn=admin,dc=smartsan" read by * break

The config you provided has:

olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break

It's impossible to assist you if you cannot accurately provide what you're doing.

Regards, Quanah

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

Kumar Rahul

1:50 p.m.

Hi Quanah

Sorry for the confusion. Here is the server configuration information.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: 2ef0a49a-4383-103a-9074-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z olcServerID: 1 entryCSN: 20200615183843.452534Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 2ef0b962-4383-103a-9076-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.152282Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: <> structuralObjectClass: olcDatabaseConfig entryUUID: 2ef0b638-4383-103a-9075-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.152195Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/sns_db olcSuffix: dc=smartsan olcRootDN: cn=admin,dc=smartsan olcRootPW:: <> olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 2f11ecae-4383-103a-87c8-85fd54de9add creatorsName: cn=config createTimestamp: 20200615183843Z olcAccess: {0}to * by dn.base="cn=admin,dc=smartsan" read by * break olcSyncrepl:: ezB9cmlkPTAwMQogICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8vMzMuMz MuMzMuNjA6Mzg5CiAgICAgICAgICAgICAgIHR5cGU9cmVmcmVzaEFuZFBlcnNpc3QKICAgICAgI CAgICAgICAgcmV0cnk9IjIgMTAgNjAgKyIKICAgICAgICAgICAgICAgc2VhcmNoYmFzZT0iZGM9 c21hcnRzYW4iCiAgICAgICAgICAgICAgIHNjb3BlPXN1YgogICAgICAgICAgICAgICBhdHRycz0 iKiwrIgogICAgICAgICAgICAgICBiaW5kbWV0aG9kPXNpbXBsZQogICAgICAgICAgICAgICBiaW 5kZG49ImNuPWFkbWluLGRjPXNtYXJ0c2FuIgogICAgICAgICAgICAgICBjcmVkZW50aWFscz1zZ WNyZXQyCiAgICAgICAgICAgICAgIHRpbWVvdXQ9MQ== olcMirrorMode: TRUE entryCSN: 20200615183925.011817Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20200615183925Z

dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/openldap-data/sns_config_db olcSuffix: dc=server-config olcRootDN: cn=admin,dc=server-config olcRootPW:: <> olcDbIndex: objectClass eq structuralObjectClass: olcMdbConfig entryUUID: 2f14d720-4383-103a-87c9-85fd54de9add creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.388967Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

Kumar Rahul

2:16 p.m.

and here are the provider and consumer ldif files. Let me know if the configuration looks alright

Provider ++++++++++++++++++++++++++++++++++++++++ dn: olcOverlay=syncprov, olcDatabase={1}mdb,cn=config objectclass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 110

+++++++++++++++++++++++++++++++++++++++++++++++++

Consumer

======================================================= dn: cn=config changetype: modify add: olcServerId olcServerId: 1

dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcSyncrepl - add: olcAccess olcAccess: to * by dn.base="cn=admin,dc=smartsan" read by * break - add: olcDbIndex olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq - replace: olcMirrorMode olcMirrorMode: TRUE ===============================================

Kumar Rahul

16 Jun 16 Jun

7:31 a.m.

Hi Quanah

Please let me know if you need more information.

Thanks Rahul

Scott Classen

8:24 a.m.

Hello Kumar,

What does the entire olcSyncrepl entry look like on your consumer?

There are many options as you can see from the documentation:

5.2.5.8. olcSyncrepl <> olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port] [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] searchbase=<base DN> [filter=<filter str>] [scope=sub|one|base] [attrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [bindmethod=simple|sasl] [binddn=<DN>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [starttls=yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] [logbase=<base DN>] [logfilter=<filter str>] [syncdata=default|accesslog|changelog]

And unless I missed it in one of your previous responses, I really don’t know the full set of olcSyncrepl parameters you have specified.

Scott

...

On Jun 16, 2020, at 7:31 AM, Kumar Rahul rahul2002mit@gmail.com wrote:

Hi Quanah

Please let me know if you need more information.

Thanks Rahul

Kumar Rahul

8:28 a.m.

Hi Scott

Here are olcSyncrepl options we are using

0}rid=001 provider=ldap://<IP>:389 type=refreshAndPersist retry="2 10 60 +" searchbase="dc=smartsan" scope=sub attrs="*,+" bindmethod=simple binddn="cn=admin,dc=smartsan" credentials=<Password> timeout=1

Quanah Gibson-Mount

8:31 a.m.

--On Monday, June 15, 2020 10:16 PM +0000 Kumar Rahul rahul2002mit@gmail.com wrote:

Two things:

a) As I said before when you sent bits like this, this is NOT a configuration, it's a series of MODifications.

b) Your serverID here is clearly wrong. You just gave it the SAME EXACT serverID as the provider. The serverIDs, as documented, must be unique between providers. Since both nodes are using the same serverID, changes will be discarded instead of replicating between nodes.

...

Consumer

======================================================= dn: cn=config changetype: modify add: olcServerId olcServerId: 1

Regards, Quanah

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

Scott Classen

8:36 a.m.

Here is an example of setting up mirror mode Syncrepl from the Admin guide:

18.3.4.1. Mirror Node Configuration <> The first step is to configure the syncrepl provider the same as in the Set up the provider slapd <https://www.openldap.org/devel/admin/replication.html#Set up the provider slapd> section.

Here's a specific cut down example using LDAP Sync Replication <https://www.openldap.org/devel/admin/replication.html#LDAP Sync Replication> in refreshAndPersist mode:

MirrorMode node 1:

# Global section serverID 1 # database section

# syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +"

mirrormode on MirrorMode node 2:

# Global section serverID 2 # database section

# syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +"

mirrormode on

...

On Jun 16, 2020, at 8:28 AM, Kumar Rahul rahul2002mit@gmail.com wrote:

Hi Scott

Here are olcSyncrepl options we are using

0}rid=001 provider=ldap://<IP>:389 type=refreshAndPersist retry="2 10 60 +" searchbase="dc=smartsan" scope=sub attrs="*,+" bindmethod=simple binddn="cn=admin,dc=smartsan" credentials=<Password> timeout=1

Kumar Rahul

8:57 a.m.

Hi Quanah

Please find my answers a) As I said before when you sent bits like this, this is NOT a configuration, it's a series of MODifications. [Rahul] Let me know that list the information you need. I will send you fresh set of information.

Thanks Rahul

Kumar Rahul

9:03 a.m.

Hi Scott

Here is the ldap configuration from 1st server with consumer and Provider settings. Let me know if I am missing something

+++++++++++++++++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: 2ef0a49a-4383-103a-9074-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z olcServerID: 1 entryCSN: 20200615183843.452534Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 2ef0b962-4383-103a-9076-6962462c185e creatorsName: cn=config createTimestamp: 20200615183843Z entryCSN: 20200615183843.152282Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200615183843Z

Xuhua Lin

9:56 a.m.

Hi Kumar, can you check if the time on both servers are synched? Also you can enable syncrepl log to get more information.

Xuhua

Kumar Rahul

22 Jun 22 Jun

7:06 a.m.

Hi Scott

I do have sync setup as per guide lines

Here is the behavior i see

++++++++++++++++++++++++++++++++++++++++++ I am using LDAP protocol as front end and Berkeley DB as back end. I am observing a strange syncrepl issue

type=refreshAndPersist is being used $OpenLDAP: slapd 2.4.50 OS: RHEL7U6

I have 2 server setup say S1 and S2. S1 is in provider and S2 is in consumer mode. Added data D1 in database and that was synced with S2 database. Now I killed slapd process on server S1.

At this point server S2 assumes provider role. Now I removed data D1 from database using server S2. Once deletion is complete validated that data was removed from server S2 database.

Now i brought S1 slapd service back up and started the application which starts syncrepl.

Here is what i see

both server S1 and S2 has data D1 which was actually deleted.

Expected behavior: Both server should sync properly and data D1 which was deleted using Server S2 should not be present in the database after sync.

++++++++++++++++++++++++++++++++++++++++++

Let me know if you need more information.

Thanks Rahul

Kumar Rahul

7:08 a.m.

Hi Quanah

Thank you for all the help so far. I am still seeing the original issue reported. Let me know if you need fresh set of configuration information.

Thanks Rahul

Kumar Rahul

7:09 a.m.

Hi Xuhua

Yes time on both servers are synched. Can you help me with steps on how to enable and capture logs?

Thanks Rahul

Quanah Gibson-Mount

9:09 a.m.

--On Monday, June 22, 2020 3:08 PM +0000 Kumar Rahul rahul2002mit@gmail.com wrote:

...

Hi Quanah
Thank you for all the help so far. I am still seeing the original
issue reported. Let me know if you need fresh set of configuration information.

I've told you repeatedly what is necessary, you haven't provided it.

To re-iterate:

Full configuration of both servers, not config snippets or LDAP modify change code.

Regards, Quanah

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

Kumar Rahul

9:35 a.m.

Hi Quanah

Just to be clear, you want output of following command from both servers?

slapcat -n 0 -a "(!(entryDN:dnSubtreeMatch:=cn=schema,cn=config))" -l /tmp/config.ldif

Thanks Rahul

Xuhua Lin

10:57 a.m.

You can set olcLogLevel to sync and you should see some syncrepl calls in the log files.

Xuhua

Kumar Rahul

1:22 p.m.

Hi Quanah

Please find the command output from both servers. Let me know if you need more info.

Server S1 +++++++++++++++++++++++++++++++++++++++++ dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: a826a9dc-490e-103a-98ae-f3409debd9d9 creatorsName: cn=config createTimestamp: 20200622195942Z olcServerID: 1 entryCSN: 20200622195942.531227Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195942Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: a826c58e-490e-103a-98b0-f3409debd9d9 creatorsName: cn=config createTimestamp: 20200622195942Z entryCSN: 20200622195942.370104Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195942Z

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: <> structuralObjectClass: olcDatabaseConfig entryUUID: a826c2f0-490e-103a-98af-f3409debd9d9 creatorsName: cn=config createTimestamp: 20200622195942Z entryCSN: 20200622195942.370032Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195942Z

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/sns_db olcSuffix: dc=smartsan olcRootDN: cn=admin,dc=smartsan olcRootPW:: <> olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: a8306d0a-490e-103a-9ba0-e3e7d4b90654 creatorsName: cn=config createTimestamp: 20200622195942Z olcAccess: {0}to * by dn.base="cn=admin,dc=smartsan" read by * break olcSyncrepl:: ezB9cmlkPTAwMQogICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8vMzMuMz MuMzMuNjA6Mzg5CiAgICAgICAgICAgICAgIHR5cGU9cmVmcmVzaEFuZFBlcnNpc3QKICAgICAgI CAgICAgICAgcmV0cnk9IjIgMTAgNjAgKyIKICAgICAgICAgICAgICAgc2VhcmNoYmFzZT0iZGM9 c21hcnRzYW4iCiAgICAgICAgICAgICAgIHNjb3BlPXN1YgogICAgICAgICAgICAgICBhdHRycz0 iKiwrIgogICAgICAgICAgICAgICBiaW5kbWV0aG9kPXNpbXBsZQogICAgICAgICAgICAgICBiaW 5kZG49ImNuPWFkbWluLGRjPXNtYXJ0c2FuIgogICAgICAgICAgICAgICBjcmVkZW50aWFscz1zZ WNyZXQyCiAgICAgICAgICAgICAgIHRpbWVvdXQ9MQ== olcMirrorMode: TRUE entryCSN: 20200622200005.603921Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20200622200005Z

dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: a83c3ea0-490e-103a-9ba4-e3e7d4b90654 creatorsName: cn=config createTimestamp: 20200622195942Z entryCSN: 20200622195942.510824Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195942Z

dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/openldap-data/sns_config_db olcSuffix: dc=server-config olcRootDN: cn=admin,dc=server-config olcRootPW:: <> olcDbIndex: objectClass eq structuralObjectClass: olcMdbConfig entryUUID: a8332e6e-490e-103a-9ba1-e3e7d4b90654 creatorsName: cn=config createTimestamp: 20200622195942Z entryCSN: 20200622195942.451427Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195942Z ++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Server S2

================================================================= dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid structuralObjectClass: olcGlobal entryUUID: b0f7505c-490e-103a-8a23-033ed85ade7e creatorsName: cn=config createTimestamp: 20200622195957Z olcServerID: 2 entryCSN: 20200622195957.324389Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195957Z

dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: b0f76204-490e-103a-8a25-033ed85ade7e creatorsName: cn=config createTimestamp: 20200622195957Z entryCSN: 20200622195957.159031Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195957Z

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: <> structuralObjectClass: olcDatabaseConfig entryUUID: b0f75f70-490e-103a-8a24-033ed85ade7e creatorsName: cn=config createTimestamp: 20200622195957Z entryCSN: 20200622195957.158960Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195957Z

dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/openldap-data/sns_db olcSuffix: dc=smartsan olcRootDN: cn=admin,dc=smartsan olcRootPW:: <> olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: b1016d62-490e-103a-9023-630ea41688ff creatorsName: cn=config createTimestamp: 20200622195957Z olcAccess: {0}to * by dn.base="cn=admin,dc=smartsan" read by * break olcSyncrepl:: ezB9cmlkPTAwMQogICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8vMzMuMz MuMzMuNTA6Mzg5CiAgICAgICAgICAgICAgIHR5cGU9cmVmcmVzaEFuZFBlcnNpc3QKICAgICAgI CAgICAgICAgcmV0cnk9IjIgMTAgNjAgKyIKICAgICAgICAgICAgICAgc2VhcmNoYmFzZT0iZGM9 c21hcnRzYW4iCiAgICAgICAgICAgICAgIHNjb3BlPXN1YgogICAgICAgICAgICAgICBhdHRycz0 iKiwrIgogICAgICAgICAgICAgICBiaW5kbWV0aG9kPXNpbXBsZQogICAgICAgICAgICAgICBiaW 5kZG49ImNuPWFkbWluLGRjPXNtYXJ0c2FuIgogICAgICAgICAgICAgICBjcmVkZW50aWFscz1zZ WNyZXQyCiAgICAgICAgICAgICAgIHRpbWVvdXQ9MQ== olcMirrorMode: TRUE entryCSN: 20200622200006.071455Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20200622200006Z

dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: b10da0aa-490e-103a-9027-630ea41688ff creatorsName: cn=config createTimestamp: 20200622195957Z entryCSN: 20200622195957.304809Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195957Z

dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/openldap-data/sns_config_db olcSuffix: dc=server-config olcRootDN: cn=admin,dc=server-config olcRootPW:: <> olcDbIndex: objectClass eq structuralObjectClass: olcMdbConfig entryUUID: b1050350-490e-103a-9024-630ea41688ff creatorsName: cn=config createTimestamp: 20200622195957Z entryCSN: 20200622195957.248353Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20200622195957Z

=================================================================

1397

Age (days ago)

1410

Last active (days ago)

openldap-technical@openldap.org

45 comments

5 participants

tags (0)

participants (5)

Kumar Rahul
Quanah Gibson-Mount
rahul2002mit＠gmail.com
Scott Classen
Xuhua Lin