Thank you very much for the advice and the example config! I generally convert my slapd.conf to cn=config, I just find it easier to use the slapd.conf when debugging. But this gives me hope that my problem could be an issue with the conversion of slapd.conf to cn=config or something that I can find in your configuration.
Thank you again, and I will let you know what I find!
On Fri, Oct 31, 2014 at 3:40 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Friday, October 31, 2014 4:13 PM -0400 kevin sullivan < kevin4sullivan@gmail.com> wrote:
Quanah,
Thank you for the suggestion to move to delta-syncrepl MMR. Unfortunately, I am having problems setting this up properly. After reading through some documentation, I thought it would be simple but when I bring up slapd on my two servers, they both start using around 100% CPU and in the debug output the two servers are constantly looping through all of the objects in my DIT and saying that the objects have not changed:
5453d6b5 @(#) $OpenLDAP: slapd 2.4.39 (Jun 18 2014 05:19:18) $
mockbuild@x86-028.build.eng.bos.redhat.com:/builddir/build/BUILD/openldap -2.4.39/openldap-2.4.39/build-servers/servers/slapd 5453d6b5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5453d6b5 slapd starting ... 5453d6b5 syncrepl_message_to_entry: rid=001 DN: dc=example,dc=com, UUID: 1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN dc=example,dc=com 20141031161001.910968Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (dc=example,dc=com) 5453d6b5 syncrepl_message_to_entry: rid=001 DN: ou=users,dc=example,dc=com, UUID: 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN ou=users,dc=example,dc=com 20141031161001.922234Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 ou=users,dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (ou=users,dc=example,dc=com) ..... 5453d6b5 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT 5453d6b5 do_syncrep2: rid=001 cookie= ... Repeated forever ...
Am I configuring something incorrectly?
To refresh your memory, I am running 2.4.39-8. I have two servers (server1 and server2) that I want to setup in delta-syncrepl MMR MirrorMode.
Hi Kevin,
I stopped using the deprecated slapd.conf format years ago, as it's prone to misuse and incorrect setup. Your supplied config is an example of why it's a bad idea to use slapd.conf (For example, you have serverID under the database section, when it's a global option, etc). I'd strongly advise you to switch to using cn=config so that you can have an actual validated configuration. It also makes troubleshooting a lot easier to do.
Aside from that, your log simply shows the server comparing each entry between the two servers... Sounds like they didn't start out believing they were in sync and are trying to get there.
Here's an example of my config, using cn=config (slapcat export) minus the schema:
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
Quanah,
Thank you for the example config earlier. I was finally able to run delta sync replication in an MMR configuration! I was unable to get it to work earlier because I was prepopulating my database via 'slapadd'. Does 'slapadd' not work well with the accesslog overlay? When I started with a blank database and then populated my database via 'ldapadd', the accesslog overlay was properly updated and I was properly able to replicate to my other server.
I am guessing that delta syncrepl was failing for me because my accesslog had no record of the objects in my DIT. Is there a way to prepopulate your DIT and accesslog with 'slapadd' instead of having to us 'ldapadd'? I tried to slapcat my accesslog database and then slapadd it to a blank accesslog database, and that didn't seem to work.
After all of this, I still need to see if delta sync replication will solve my original problem of a deleted user being restored!
Thanks,
Kevin
On Fri, Oct 31, 2014 at 4:13 PM, kevin sullivan kevin4sullivan@gmail.com wrote:
Thank you very much for the advice and the example config! I generally convert my slapd.conf to cn=config, I just find it easier to use the slapd.conf when debugging. But this gives me hope that my problem could be an issue with the conversion of slapd.conf to cn=config or something that I can find in your configuration.
Thank you again, and I will let you know what I find!
On Fri, Oct 31, 2014 at 3:40 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Friday, October 31, 2014 4:13 PM -0400 kevin sullivan < kevin4sullivan@gmail.com> wrote:
Quanah,
Thank you for the suggestion to move to delta-syncrepl MMR. Unfortunately, I am having problems setting this up properly. After reading through some documentation, I thought it would be simple but when I bring up slapd on my two servers, they both start using around 100% CPU and in the debug output the two servers are constantly looping through all of the objects in my DIT and saying that the objects have not changed:
5453d6b5 @(#) $OpenLDAP: slapd 2.4.39 (Jun 18 2014 05:19:18) $
mockbuild@x86-028.build.eng.bos.redhat.com:/builddir/ build/BUILD/openldap -2.4.39/openldap-2.4.39/build-servers/servers/slapd 5453d6b5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5453d6b5 slapd starting ... 5453d6b5 syncrepl_message_to_entry: rid=001 DN: dc=example,dc=com, UUID: 1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN dc=example,dc=com 20141031161001.910968Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (dc=example,dc=com) 5453d6b5 syncrepl_message_to_entry: rid=001 DN: ou=users,dc=example,dc=com, UUID: 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN ou=users,dc=example,dc=com 20141031161001.922234Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 ou=users,dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (ou=users,dc=example,dc=com) ..... 5453d6b5 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT 5453d6b5 do_syncrep2: rid=001 cookie= ... Repeated forever ...
Am I configuring something incorrectly?
To refresh your memory, I am running 2.4.39-8. I have two servers (server1 and server2) that I want to setup in delta-syncrepl MMR MirrorMode.
Hi Kevin,
I stopped using the deprecated slapd.conf format years ago, as it's prone to misuse and incorrect setup. Your supplied config is an example of why it's a bad idea to use slapd.conf (For example, you have serverID under the database section, when it's a global option, etc). I'd strongly advise you to switch to using cn=config so that you can have an actual validated configuration. It also makes troubleshooting a lot easier to do.
Aside from that, your log simply shows the server comparing each entry between the two servers... Sounds like they didn't start out believing they were in sync and are trying to get there.
Here's an example of my config, using cn=config (slapcat export) minus the schema:
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
--On November 6, 2014 at 9:14:31 AM -0500 kevin sullivan kevin4sullivan@gmail.com wrote:
Quanah,
Thank you for the example config earlier. I was finally able to run delta sync replication in an MMR configuration! I was unable to get it to work earlier because I was prepopulating my database via 'slapadd'. Does 'slapadd' not work well with the accesslog overlay? When I started with a blank database and then populated my database via 'ldapadd', the accesslog overlay was properly updated and I was properly able to replicate to my other server.
I am guessing that delta syncrepl was failing for me because my accesslog had no record of the objects in my DIT. Is there a way to prepopulate your DIT and accesslog with 'slapadd' instead of having to us 'ldapadd'? I tried to slapcat my accesslog database and then slapadd it to a blank accesslog database, and that didn't seem to work.
After all of this, I still need to see if delta sync replication will solve my original problem of a deleted user being restored!
Hi Kevin,
The accesslog DB is unique to a given server. You should never slapcat it from one server and slapadd it to another server. It should always start out "blank" on any given new server. The only DB you load between servers is the primary db.
--Quanah
Quanah,
Thank you for you response again! That seems to make sense, the accesslog DB should not be slapcat-ed and then slapadd-ed to a different server.
Any idea why using slapcat to populate my primary db seemed to cause delta syncrepl MMR to not work? I was starting with a blank accesslog DB and a prepopulated primary DB. When starting slapd on each server (with -d sync), I would see that each server was endlessly looping over every object in their primary DBs and saying that every object was unchanged.
Thanks,
Kevin
On Thu, Nov 6, 2014 at 11:33 AM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On November 6, 2014 at 9:14:31 AM -0500 kevin sullivan < kevin4sullivan@gmail.com> wrote:
Quanah,
Thank you for the example config earlier. I was finally able to run delta sync replication in an MMR configuration! I was unable to get it to work earlier because I was prepopulating my database via 'slapadd'. Does 'slapadd' not work well with the accesslog overlay? When I started with a blank database and then populated my database via 'ldapadd', the accesslog overlay was properly updated and I was properly able to replicate to my other server.
I am guessing that delta syncrepl was failing for me because my accesslog had no record of the objects in my DIT. Is there a way to prepopulate your DIT and accesslog with 'slapadd' instead of having to us 'ldapadd'? I tried to slapcat my accesslog database and then slapadd it to a blank accesslog database, and that didn't seem to work.
After all of this, I still need to see if delta sync replication will solve my original problem of a deleted user being restored!
Hi Kevin,
The accesslog DB is unique to a given server. You should never slapcat it from one server and slapadd it to another server. It should always start out "blank" on any given new server. The only DB you load between servers is the primary db.
--Quanah
-- Quanah Gibson-Mount Platform Architect Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On November 6, 2014 at 1:50:27 PM -0500 kevin sullivan kevin4sullivan@gmail.com wrote:
Quanah,
Thank you for you response again! That seems to make sense, the accesslog DB should not be slapcat-ed and then slapadd-ed to a different server.
Any idea why using slapcat to populate my primary db seemed to cause delta syncrepl MMR to not work? I was starting with a blank accesslog DB and a prepopulated primary DB. When starting slapd on each server (with -d sync), I would see that each server was endlessly looping over every object in their primary DBs and saying that every object was unchanged.
What options did you use with slapadd?
--Quanah
I ran the following command:
[root@localhost ~]# slapadd -F /etc/openldap/slapd.d -n 2 -l setup.ldif _#################### 100.00% eta none elapsed none fast!
Closing DB...
On Thu, Nov 6, 2014 at 2:11 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On November 6, 2014 at 1:50:27 PM -0500 kevin sullivan < kevin4sullivan@gmail.com> wrote:
Quanah,
Thank you for you response again! That seems to make sense, the accesslog DB should not be slapcat-ed and then slapadd-ed to a different server.
Any idea why using slapcat to populate my primary db seemed to cause delta syncrepl MMR to not work? I was starting with a blank accesslog DB and a prepopulated primary DB. When starting slapd on each server (with -d sync), I would see that each server was endlessly looping over every object in their primary DBs and saying that every object was unchanged.
What options did you use with slapadd?
--Quanah
-- Quanah Gibson-Mount Platform Architect Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On November 6, 2014 at 3:04:57 PM -0500 kevin sullivan kevin4sullivan@gmail.com wrote:
I ran the following command:
[root@localhost ~]# slapadd -F /etc/openldap/slapd.d -n 2 -l setup.ldif
_#################### 100.00% eta none elapsed none fast! Closing DB...
You may want to take a closer look at the options for slapadd (i.e., read up on the -w option). Also, if you've done an export directly of the DB from an existing directory, there should be no problem adding in -q to further speed things up. ;)
--Quanah
kevin sullivan kevin4sullivan@gmail.com schrieb am 06.11.2014 um 15:14 in
Nachricht CAELdiYHrFvZVXCRD96PvP00Hxi2TFJC_GwQM2N=eLAiqBTRuAA@mail.gmail.com:
Quanah,
Thank you for the example config earlier. I was finally able to run delta sync replication in an MMR configuration! I was unable to get it to work earlier because I was prepopulating my database via 'slapadd'. Does 'slapadd' not work well with the accesslog overlay? When I started with a blank database and then populated my database via 'ldapadd', the accesslog overlay was properly updated and I was properly able to replicate to my other server.
I think if your LDIF contains entry UUIDs and CSNs, you can pre-populate the databases; if those are missing, slapadd will create new ones. And if sync works on UUIDs, you'll loose. Am I right?
Regards, Ulrich
I am guessing that delta syncrepl was failing for me because my accesslog had no record of the objects in my DIT. Is there a way to prepopulate your DIT and accesslog with 'slapadd' instead of having to us 'ldapadd'? I tried to slapcat my accesslog database and then slapadd it to a blank accesslog database, and that didn't seem to work.
After all of this, I still need to see if delta sync replication will solve my original problem of a deleted user being restored!
Thanks,
Kevin
On Fri, Oct 31, 2014 at 4:13 PM, kevin sullivan kevin4sullivan@gmail.com wrote:
Thank you very much for the advice and the example config! I generally convert my slapd.conf to cn=config, I just find it easier to use the slapd.conf when debugging. But this gives me hope that my problem could be an issue with the conversion of slapd.conf to cn=config or something that I can find in your configuration.
Thank you again, and I will let you know what I find!
On Fri, Oct 31, 2014 at 3:40 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Friday, October 31, 2014 4:13 PM -0400 kevin sullivan < kevin4sullivan@gmail.com> wrote:
Quanah,
Thank you for the suggestion to move to delta-syncrepl MMR. Unfortunately, I am having problems setting this up properly. After reading through some documentation, I thought it would be simple but when I bring up slapd on my two servers, they both start using around 100% CPU and in the debug output the two servers are constantly looping through all of the objects in my DIT and saying that the objects have not changed:
5453d6b5 @(#) $OpenLDAP: slapd 2.4.39 (Jun 18 2014 05:19:18) $
mockbuild@x86-028.build.eng.bos.redhat.com:/builddir/ build/BUILD/openldap -2.4.39/openldap-2.4.39/build-servers/servers/slapd 5453d6b5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5453d6b5 slapd starting ... 5453d6b5 syncrepl_message_to_entry: rid=001 DN: dc=example,dc=com, UUID: 1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN dc=example,dc=com 20141031161001.910968Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (dc=example,dc=com) 5453d6b5 syncrepl_message_to_entry: rid=001 DN: ou=users,dc=example,dc=com, UUID: 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN ou=users,dc=example,dc=com 20141031161001.922234Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 ou=users,dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (ou=users,dc=example,dc=com) ..... 5453d6b5 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT 5453d6b5 do_syncrep2: rid=001 cookie= ... Repeated forever ...
Am I configuring something incorrectly?
To refresh your memory, I am running 2.4.39-8. I have two servers (server1 and server2) that I want to setup in delta-syncrepl MMR MirrorMode.
Hi Kevin,
I stopped using the deprecated slapd.conf format years ago, as it's prone to misuse and incorrect setup. Your supplied config is an example of why it's a bad idea to use slapd.conf (For example, you have serverID under the database section, when it's a global option, etc). I'd strongly advise you to switch to using cn=config so that you can have an actual validated configuration. It also makes troubleshooting a lot easier to do.
Aside from that, your log simply shows the server comparing each entry between the two servers... Sounds like they didn't start out believing they were in sync and are trying to get there.
Here's an example of my config, using cn=config (slapcat export) minus the schema:
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
Thank you Ulrich and Quanah for you help!
It looks like the '-w' option for slapadd was what I was looking for. When I run 'slapadd -F /etc/openldap/slapd.d -n 2 -w -l setup.ldif', delta syncrepl works as expected.
Since I have finally been able to setup and run in a delta syncrepl MMR configuration, I have found that I no longer have my initial problem where a deleted user is restored!
Thanks,
Kevin
On Fri, Nov 7, 2014 at 2:00 AM, Ulrich Windl < Ulrich.Windl@rz.uni-regensburg.de> wrote:
kevin sullivan kevin4sullivan@gmail.com schrieb am 06.11.2014 um
15:14 in Nachricht CAELdiYHrFvZVXCRD96PvP00Hxi2TFJC_GwQM2N=eLAiqBTRuAA@mail.gmail.com:
Quanah,
Thank you for the example config earlier. I was finally able to run delta sync replication in an MMR configuration! I was unable to get it to work earlier because I was prepopulating my database via 'slapadd'. Does 'slapadd' not work well with the accesslog overlay? When I started with a blank database and then populated my database via 'ldapadd', the
accesslog
overlay was properly updated and I was properly able to replicate to my other server.
I think if your LDIF contains entry UUIDs and CSNs, you can pre-populate the databases; if those are missing, slapadd will create new ones. And if sync works on UUIDs, you'll loose. Am I right?
Regards, Ulrich
I am guessing that delta syncrepl was failing for me because my accesslog had no record of the objects in my DIT. Is there a way to prepopulate
your
DIT and accesslog with 'slapadd' instead of having to us 'ldapadd'? I
tried
to slapcat my accesslog database and then slapadd it to a blank accesslog database, and that didn't seem to work.
After all of this, I still need to see if delta sync replication will
solve
my original problem of a deleted user being restored!
Thanks,
Kevin
On Fri, Oct 31, 2014 at 4:13 PM, kevin sullivan <
kevin4sullivan@gmail.com>
wrote:
Thank you very much for the advice and the example config! I generally convert my slapd.conf to cn=config, I just find it easier to use the slapd.conf when debugging. But this gives me hope that my problem could
be
an issue with the conversion of slapd.conf to cn=config or something
that I
can find in your configuration.
Thank you again, and I will let you know what I find!
On Fri, Oct 31, 2014 at 3:40 PM, Quanah Gibson-Mount <quanah@zimbra.com
wrote:
--On Friday, October 31, 2014 4:13 PM -0400 kevin sullivan < kevin4sullivan@gmail.com> wrote:
Quanah,
Thank you for the suggestion to move to delta-syncrepl MMR. Unfortunately, I am having problems setting this up properly. After reading through some documentation, I thought it would be simple but
when
I bring up slapd on my two servers, they both start using around 100%
CPU
and in the debug output the two servers are constantly looping through all of the objects in my DIT and saying that the objects have not changed:
5453d6b5 @(#) $OpenLDAP: slapd 2.4.39 (Jun 18 2014 05:19:18) $
mockbuild@x86-028.build.eng.bos.redhat.com:/builddir/ build/BUILD/openldap -2.4.39/openldap-2.4.39/build-servers/servers/slapd 5453d6b5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5453d6b5 slapd starting ... 5453d6b5 syncrepl_message_to_entry: rid=001 DN: dc=example,dc=com,
UUID:
1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfcd560-f564-1033-9f47-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN dc=example,dc=com 20141031161001.910968Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (dc=example,dc=com) 5453d6b5 syncrepl_message_to_entry: rid=001 DN: ou=users,dc=example,dc=com, UUID: 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5453d6b5 syncrepl_entry: rid=001 inserted UUID 1cfe8cf2-f564-1033-9f48-b521eabdb6ad 5453d6b5 dn_callback : entries have identical CSN ou=users,dc=example,dc=com 20141031161001.922234Z#000000#000#000000 5453d6b5 syncrepl_entry: rid=001 be_search (0) 5453d6b5 syncrepl_entry: rid=001 ou=users,dc=example,dc=com 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored (ou=users,dc=example,dc=com) ..... 5453d6b5 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT 5453d6b5 do_syncrep2: rid=001 cookie= ... Repeated forever ...
Am I configuring something incorrectly?
To refresh your memory, I am running 2.4.39-8. I have two servers (server1 and server2) that I want to setup in delta-syncrepl MMR MirrorMode.
Hi Kevin,
I stopped using the deprecated slapd.conf format years ago, as it's
prone
to misuse and incorrect setup. Your supplied config is an example of
why
it's a bad idea to use slapd.conf (For example, you have serverID
under the
database section, when it's a global option, etc). I'd strongly
advise you
to switch to using cn=config so that you can have an actual validated configuration. It also makes troubleshooting a lot easier to do.
Aside from that, your log simply shows the server comparing each entry between the two servers... Sounds like they didn't start out believing
they
were in sync and are trying to get there.
Here's an example of my config, using cn=config (slapcat export) minus the schema:
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
--On November 7, 2014 at 8:00:29 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
I think if your LDIF contains entry UUIDs and CSNs, you can pre-populate the databases; if those are missing, slapadd will create new ones. And if sync works on UUIDs, you'll loose. Am I right?
If he had been using ldapsearch, without requesting the operational attributes, to export the DB, you would have been right. However, he had already noted he was using slapcat, which always exports the operational attributes, so you are wrong. The problem was he didn't use the -w flag, which is why I directed him to read up on it.
--Quanah
Quanah Gibson-Mount quanah@zimbra.com schrieb am 07.11.2014 um 23:59 in
Nachricht F1D5400AA26DE151A609FC8E@quanah-mac.local:
--On November 7, 2014 at 8:00:29 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
I think if your LDIF contains entry UUIDs and CSNs, you can pre-populate the databases; if those are missing, slapadd will create new ones. And if sync works on UUIDs, you'll loose. Am I right?
If he had been using ldapsearch, without requesting the operational attributes, to export the DB, you would have been right. However, he had already noted he was using slapcat, which always exports the operational attributes, so you are wrong. The problem was he didn't use the -w flag, which is why I directed him to read up on it.
I wonder: If you exported a complete database, shouldn't the contextCSN be exported and imported correctly; why is it necessary to recompute it?
Regards, Ulrich
--Quanah
-- Quanah Gibson-Mount Platform Architect Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
kevin sullivan -
Quanah Gibson-Mount -
Ulrich Windl