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 <
[email protected]> wrote:

> >>> kevin sullivan <[email protected]> schrieb am 06.11.2014 um
> 15:14 in
> Nachricht
> <CAELdiYHrFvZVXCRD96PvP00Hxi2TFJC_GwQM2N=elaiqbtr...@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 <
> [email protected]>
> > 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 <[email protected]
> >
> >> wrote:
> >>
> >>> --On Friday, October 31, 2014 4:13 PM -0400 kevin sullivan <
> >>> [email protected]> 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) $
> >>>>
> >>>> [email protected]:/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:
> >>>
> >>> <http://pastebin.com/nv1WNX2y>
> >>>
> >>>
> >>> --Quanah
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Quanah Gibson-Mount
> >>> Server Architect
> >>> Zimbra, Inc.
> >>> --------------------
> >>> Zimbra ::  the leader in open source messaging and collaboration
> >>>
> >>
> >>
>
>
>
>

Reply via email to