[389-users] Re: Replication question

[Marc Sauton]

I think you are correct for a "no", from the admin guide:
"
What Directory Units Are Replicated
The smallest unit of of the directory which can be replicated is a database.
This means that one can replicate an entire database but not a subtree
within a database.
Therefore, when creating the directory tree, consider any replication plans
as part of determining how to distribute information.
Replication also requires that one database correspond to one suffix.
This means that a suffix (or namespace) that is distributed over two or
more databases using custom distribution logic cannot be replicated.
"


On Thu, Aug 24, 2023 at 4:04 PM  wrote:

> I've got two 389 multi-supplier replicated instances that I want to
> replicate to two new ones just temporarily for migration purposes. Since
> this is production, it would be ideal if it could be replicating right up
> to the second I make the new ones live. However, I simplified the
> configuration on the new one and now I'm wondering if this scheme will
> still work.
>
> On the old one, I have two replicated DBs, one mapped to
> ou=b,dc=a,dc=arizona,dc=edu and the other mapped to dc=a,dc=arizona,dc=edu.
> On the new one, I decided to have just one replicated DB, mapped to
> dc=arizona, dc=edu. Is it possible to replicate the old ones to the new
> instance? I'm thinking no, but I had to ask.
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: replication question

[Mark Reynolds]

dn: cn=replica,cn=dc\3Dnorthshore\2Cdc\3Dedu,cn=mapping tree,cn=config
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaRoot: dc=northshore,dc=edu
nsDS5ReplicaType: 2
nsDS5Flags: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN:*cn=replication manager,cn=config*
cn: replica
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20180320162523Z
modifyTimestamp: 20180323150229Z
nsDS5ReplicaId: 65535


But "*cn=replication manager,cn=config*" does not exist in your config. 
The two existing replication manager entries you have are:

dn: uid=rmanager,cn=config
uid: rmanager
givenName: replication manager
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: manager
cn: directory manager
userPassword: {SSHA}Q6BkStQecBSJFsro4jrOP5Suf6fIVemBV4SLGQ==
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20180319140621Z
modifyTimestamp: 20180323145435Z
pwdpolicysubentry:
cn=cn\3DnsPwPolicyEntry\2Cuid\3Drmanager\2Ccn\3Dconfig,cn=n
 sPwPolicyContainer,cn=config
passwordGraceUserTime: 0

dn: uid=RManager2,cn=config
uid: RManager2
givenName: Replication
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Manager
cn: Replication Manager
userPassword: {SSHA}p8hq6oMxQY7TlO8QB3lzUMpbuQsGHri8mmiHEQ==
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20171106192255Z
modifyTimestamp: 20171106192255Z


Pick one of these(if you know the password), or create the
"cn=replication,cn=config" entry.

Regards,
Mark





___
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

[Sergei Gerasenko]

Looks like I have a replication conflict but I’m not sure if it’s really the 
cause of the problem.

ldapsearch -xLLL -o ldif-wrap=no -D cn='directory manager' -w PWD -h 
ipa102.cnvr.net -b 'dc=CNVR,dc=NET' nsDS5ReplConflict=* dn

cn=System: Read Certmap 
Configuration+nsuniqueid=0cefb68c-0b9111e8-9447e803-d19ee9c0,cn=permissions,cn=pbac,dc=cnvr,dc=net
cn=ipa201-to-ipa202+nsuniqueid=73b7ef20-2e2211e8-bd0bfbd1-7f1a6887,cn=domain,cn=topology,cn=ipa,cn=etc,dc=XXX,dc=net

Those two hosts don’t exist anymore. I rekicked them and changed their names to 
ipa204 and ipa203 respectively.

Do I delete that on each host where the conflict is shown or just one?

> On Mar 23, 2018, at 8:52 AM, Mark Reynolds  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 > > 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 >> > 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

[389-users] Re: replication question

[Mark Reynolds]

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  > 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 > > 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 succee

[389-users] Re: replication question

[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

[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

[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