Mark,
It worked!
Thanks!!! If you are ever in MA send me an email and I'll buy you a beer!
-Jesse
On Fri, Mar 23, 2018 at 12:02 PM, Mark Reynolds <mreynolds(a)redhat.com>
wrote:
Did you change both master and consumer's config?
Consumer:
dn: cn=replica,cn=dc\3Dnorthshore\2Cdc\3Dedu,cn=mapping tree,cn=config
...
nsDS5ReplicaBindDN: <Set to replica manager>
Master:
Update the agreements to use replica manager
On 03/23/2018 11:53 AM, JESSE LUNT wrote:
Mark
When I change the binding account I now get a permission denied error.
On Fri, Mar 23, 2018 at 9:52 AM, Mark Reynolds <mreynolds(a)redhat.com>
wrote:
>
>
> On 03/23/2018 09:05 AM, JESSE LUNT wrote:
>
> Here is the dse.ldif on 389ds2 (strange that it is in a slapd-389ds1
> directory, I thought it was supposed to create a directory named
> slapd-hostname. Could this server be a clone? )
>
> Perhaps, but you can name an instance anything you want.
>
> I see a problem here:
>
> dn: cn=replica,cn=dc\3Dnorthshore\2Cdc\3Dedu,cn=mapping tree,cn=config
> ...
> ...
> nsDS5ReplicaBindDN: cn=directory manager
>
>
> nsDS5ReplicaBindDN needs to be one of the replication managers (you have
> two) - it should not be the "Directory Manager":
>
> uid=rmanager,cn=config or uid=RManager2,cn=config
>
>
> Then on the replication agreement(s) on 389ds1, make sure the agreement
> bind dn (and credentials) is for one of these replication managers.
>
> Fix this first, and lets see what happens.
>
> Mark
>
>
>
>
> On Thu, Mar 22, 2018 at 4:08 PM, Mark Reynolds <mreynolds(a)redhat.com>
> wrote:
>
>>
>>
>> On 03/22/2018 04:04 PM, JESSE LUNT wrote:
>>
>> When I access the 389ds2 using an ldap browser, I still do not see the
>> user Root database. However, would I see it if it hasn't finished
>> initializing?
>>
>> You said you already created the userRoot database on 389ds2, so you are
>> saying you don't see it anymore?
>>
>> Any chance I could see the dse.ldif from 389ds2? Perhaps 389ds2 is not
>> properly configured?
>>
>> Anyway you need to look at the logs next to figure out why the
>> initialization is not occurring. The access log should show a connection
>> coming from 389ds1, and it binding as your replication manager. The errors
>> log might also have useful info (on either server).
>>
>> Mark
>>
>>
>>
>> Jesse
>>
>> Sent from my iPhone
>>
>> On Mar 22, 2018, at 1:30 PM, Mark Reynolds <mreynolds(a)redhat.com> wrote:
>>
>> How man entries are in the 389ds1?
>>
>> You need to look at the access/errors logs on 389ds2 to see if 389ds1 is
>> making contact and what is it doing.
>>
>> It's also possible it finished initializing. Are there any entries on
>> 389ds2? If you make an update on 389ds1 does it appear on 389ds2?
>>
>> On 03/22/2018 12:51 PM, JESSE LUNT wrote:
>>
>> Hello,
>>
>> I am trying to replicate my userRoot database to another 389LDAP
>> server (supplier: 389ds1, consumer: 389ds2). The database on the supplier
>> has not been replicated to any server for more than 2 years. (yikes!!!).
>>
>> I have been successful in backing up the database in question, and am
>> now trying to create a replica agreement. I created the root suffix on the
>> consumer side (389ds2) and then created a replication agreement from the
>> admin console. The admin console has been in the state of wait while
>> consumer is initialized.
>>
>> <image.png>
>>
>> Here is the output from the repl-monitor script
>>
>> Enter password for (:): Master: 389ds1.northshore.edu:389 ldap://
>> 389ds1.northshore.edu:389/
>> Replica ID: 1212
>> Replica Root: dc=northshore,dc=edu
>> Max CSN: 5ab3dd8f000004bc0000 (03/22/2018 12:45:03)
>> Use of uninitialized value in string at /usr/bin/repl-monitor.pl line
>> 814, <> line 1.
>> Use of uninitialized value in join or string at /usr/bin/repl-monitor.pl
>> line 1151, <> line 1.
>> Receiver: 389ds2.northshore.edu:389 ldap://389ds2.northshore.edu:389/
>> Type: consumer
>> Time Lag: - ?:??:??
>> Max CSN: none
>> Use of uninitialized value in concatenation (.) or string at /usr/bin/
>> repl-monitor.pl line 855, <> line 1.
>> Last Modify Time:
>> Supplier: 389ds1.northshore.edu:389
>> Sent/Skipped: 0 / 0
>> Update Status: 0 Replica acquired successfully: Incremental update
>> started
>> Update Started: 03/22/2018 12:45:01
>> Update Ended: 03/22/2018 12:45:01
>> Schedule: always in sync
>> SSL: n
>> Replica ID: 1971
>> Replica Root: o=netscaperoot
>> Max CSN: 5ab1364d000407b30000 (03/20/2018 12:26:53 4 0)
>> Receiver: 389ds2.northshore.edu:389 ldap://389ds2.northshore.edu:389/
>> Type: consumer
>> Time Lag: 0:00:00
>> Max CSN: 5ab1364d000407b30000 (03/20/2018 12:26:53 4 0)
>> Last Modify Time: 3/20/2018 12:26:52
>> Supplier: 389ds1.northshore.edu:389
>> Sent/Skipped: 0 / 0
>> Update Status: 0 Replica acquired successfully: Incremental update
>> succeeded
>> Update Started: 03/20/2018 13:58:15
>> Update Ended: 03/20/2018 13:58:15
>> Schedule: always in sync
>> SSL: n
>>
>>
>> My question is... is this hung or is the replication initialization
>> going to take days because of how long it has been since it has replicated
>> the database?
>> --
>>
>>
>> Thanks,
>>
>> Jesse
>>
>>
>>
>>
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>
>>
>>
>>
>
>
> --
>
>
> Jesse Lunt
> Director of Network and User Services
> Office of Information Services
> North Shore Community College
> (978)-762-4014 <%28978%29%20762-4014>
>
>
>
>
--
Jesse Lunt
Director of Network and User Services
Office of Information Services
North Shore Community College
(978)-762-4014 <(978)%20762-4014>
--
Jesse Lunt
Director of Network and User Services
Office of Information Services
North Shore Community College
(978)-762-4014