[389-users] Re: a replication problem

2018-03-22 Thread Sergei Gerasenko 
The error I’m basically getting is:

[23/Mar/2018:03:23:29.461074995 +] - ERR - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt=“cn=HOST1-to-HOST2" (ipa203:389) - Replication bind 
with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()

Any ideas?

> On Mar 22, 2018, at 5:05 PM, Sergei Gerasenko  wrote:
> 
> Hi guys,
> 
> I ran into a rather significant problem. I needed to rebuild two nodes in my 
> topology and re-include them under the same hostnames. What I’m seeing now is 
> that the replication to these new nodes is broken. Replication from them 
> seems to work. I suspect that we have some stale metadata somewhere in the 
> topology whereby the old nodes are still present somewhere in the agreements 
> under other ids?
> 
> What’s the best way to troubleshoot this?
> 
> Thanks again,
>  Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] a replication problem

2018-03-22 Thread Sergei Gerasenko 
Hi guys,

I ran into a rather significant problem. I needed to rebuild two nodes in my 
topology and re-include them under the same hostnames. What I’m seeing now is 
that the replication to these new nodes is broken. Replication from them seems 
to work. I suspect that we have some stale metadata somewhere in the topology 
whereby the old nodes are still present somewhere in the agreements under other 
ids?

What’s the best way to troubleshoot this?

Thanks again,
  Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: replication question

2018-03-22 Thread Mark Reynolds 


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  > 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. 
>>>
>>> 
>>>
>>> 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: 5ab3dd8f04bc (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: 5ab1364d000407b3 (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: 5ab1364d000407b3 (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@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: replication question

2018-03-22 Thread JESSE LUNT 
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? 


Jesse

Sent from my iPhone

> On Mar 22, 2018, at 1:30 PM, Mark Reynolds  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. 
>> 
>> 
>> 
>> 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: 5ab3dd8f04bc (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: 5ab1364d000407b3 (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: 5ab1364d000407b3 (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@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: replication question

2018-03-22 Thread JESSE LUNT 
Hey Mark,

   Thanks Mark... I'll take a look. I wasn't sure if I could do that yet. 
That's a good idea.

Jesse



> On Mar 22, 2018, at 1:30 PM, Mark Reynolds  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. 
>> 
>> 
>> 
>> 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: 5ab3dd8f04bc (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: 5ab1364d000407b3 (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: 5ab1364d000407b3 (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@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org