subject:"Re\: \[Freeipa\-users\] Two masters and one of them is desynchronized"

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-25 Thread Ludwig Krispenz



On 08/25/2016 04:41 PM, bahan w wrote:


Hello everyone.

Could you explain to me about this field Sent/Skipped please ?
if replication is enabled all changes on a server are logged into the 
changelog -changes coming from clients and internal changes (eg mmeberof 
update, passwordpolocy updates, lstlogin time ...).
In the replication agreement you can configure attributes for which 
changes are not replicated (keep them local) - and IPA uses this feature 
eg for krblastlogintime.


Looking at the replication traffic your monitoring shows, I think most 
of the "real" updates are going to one server and most of the clients 
triggering internal updates are going to the other. This makes 
replciation in one direction "normal" and in the other fractional. The 
problem with fractional is that the determined staring point for a 
replciation session can b every far behind and it again and again 
iterates over the same changes until finally an update which is not 
skipped is found.


There are some options to improve this:
- upgarde to a newer version, teh DS will automatically generate updates 
to a "keep alive" entry, so that the sequences of skipped changes get 
much smaller
- do it yourself by regularily applying a dummy update on the 
problematic server which will be replicated
- check configuration if writing the internal mods can be avoided, I 
think there is an option not to log krblastlogin




I checked the doc and found this :
###

Sent/Skipped :



The number of changes that were sent from the supplier and the number 
skipped in the replication update. The numbers are kept in suppliers’ 
memory only and are cleared if the supplier is restarted.


###

If I check the first part :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Last Modify Time: 8/24/2016 18:36:32
Supplier: :389
Sent/Skipped: 182110 / 1054
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:36:32
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

This is the replication from the MASTER OK (the supplier) to the 
MASTER UNSYNC (the receiver), right ?

So, the MASTER OK sent 182110 changes.
And in addition to these 182110 changes, 1054 changes were sent to the 
MASTER UNSYNC but skipped by the MASTER UNSYNC, right ?

Why are they skipped ?

In the other side, if I take the second part :
###
Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9048655
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:36:33
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

The supplier is the MASTER UNSYNC and the receiver is the MASTER OK.
In this case I have only 3 changes sent.
And in addition to these 3 changes, 9 048 655 changes were sent but 
skipped on the MASTER OK, right ?


I ask these questions just to be sure I understand right the return of 
the pl script.



Best regards.

Bahan


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-25 Thread bahan w

Hello everyone.

Could you explain to me about this field Sent/Skipped please ?

I checked the doc and found this :
###

Sent/Skipped :

The number of changes that were sent from the supplier and the number
skipped in the replication update. The numbers are kept in suppliers’
memory only and are cleared if the supplier is restarted.
###

If I check the first part :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
Last Modify Time: 8/24/2016 18:36:32
Supplier: :389
Sent/Skipped: 182110 / 1054
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:36:32
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

This is the replication from the MASTER OK (the supplier) to the MASTER
UNSYNC (the receiver), right ?
So, the MASTER OK sent 182110 changes.
And in addition to these 182110 changes, 1054 changes were sent to the
MASTER UNSYNC but skipped by the MASTER UNSYNC, right ?
Why are they skipped ?

In the other side, if I take the second part :
###
Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9048655
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:36:33
Update Ended: 08/24/2016 18:36:34
Schedule: always in sync
SSL: SASL/GSSAPI
###

The supplier is the MASTER UNSYNC and the receiver is the MASTER OK.
In this case I have only 3 changes sent.
And in addition to these 3 changes, 9 048 655 changes were sent but skipped
on the MASTER OK, right ?

I ask these questions just to be sure I understand right the return of the
pl script.


Best regards.

Bahan
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-25 Thread Ludwig Krispenz


I just noticed that you have many skipped entries, Sent/Skipped: 3 / 9045345

that could be an effect of fractional replication which  reiterates the 
same sequence of changes. This is fixed in recent releases, but looks 
like your on RHEL 6.6


Ludwig

On 08/24/2016 06:33 PM, bahan w wrote:

Hey guys.

I performed it :
###
# /usr/bin/repl-monitor.pl  -f /tmp/checkconf -s
Directory Server Replication Status (Version 1.1)

Time: Wed Aug 24 2016 18:16:50

Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Last Modify Time: 8/24/2016 18:16:50
Supplier: :389
Sent/Skipped: 179031 / 1037
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9045345
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI
###

Do you see something strange in there ?
I have another environment where I have two replicated master and they 
are OK.

And when I check the same command, the result is a little bit different :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Last Modify Time: 8/24/2016 18:16:00
Supplier: :389
Sent/Skipped: 343515 / 0
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:15:59
Update Ended: 08/24/2016 18:16:08
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 390:51:38
Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
Last Modify Time: 8/8/2016 11:24:28
Supplier: :389
Sent/Skipped: 5 / 2596073
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:16:00
Update Ended: 08/24/2016 18:16:12
Schedule: always in sync
SSL: SASL/GSSAPI
###

Best regards.

Bahan


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-25 Thread Ludwig Krispenz

The replication agreements to the "unsync" master says that update has 
started, so it looks like replication connection is active.
You need to check the access and error logs of bot sides and check if 
tehre is replication traffic


On 08/24/2016 06:33 PM, bahan w wrote:

Hey guys.

I performed it :
###
# /usr/bin/repl-monitor.pl  -f /tmp/checkconf -s
Directory Server Replication Status (Version 1.1)

Time: Wed Aug 24 2016 18:16:50

Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Last Modify Time: 8/24/2016 18:16:50
Supplier: :389
Sent/Skipped: 179031 / 1037
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9045345
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI
###

Do you see something strange in there ?
I have another environment where I have two replicated master and they 
are OK.

And when I check the same command, the result is a little bit different :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Last Modify Time: 8/24/2016 18:16:00
Supplier: :389
Sent/Skipped: 343515 / 0
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:15:59
Update Ended: 08/24/2016 18:16:08
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 390:51:38
Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
Last Modify Time: 8/8/2016 11:24:28
Supplier: :389
Sent/Skipped: 5 / 2596073
Update Status: 0 Replica acquired successfully: Incremental update 
succeeded

Update Started: 08/24/2016 18:16:00
Update Ended: 08/24/2016 18:16:12
Schedule: always in sync
SSL: SASL/GSSAPI
###

Best regards.

Bahan


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-24 Thread bahan w

Le 24 août 2016 18:42, "bahan w"  a écrit :

> Hey guys.
>
> I rechecked and in fact I also have the same message on the multi master
> setup with one master unsynchronized :
> ###
> Master: :389 ldap://:389/
> Replica ID: 4
> Replica Root: dc=
> Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
> Receiver: :389 ldap://:389/
> Type: master
> Time Lag: 0:00:00
> Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
> Last Modify Time: 8/24/2016 18:36:32
> Supplier: :389
> Sent/Skipped: 182110 / 1054
> Update Status: 0 Replica acquired successfully: Incremental update
> succeeded
> Update Started: 08/24/2016 18:36:32
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
>
> Master: :389 ldap://:389/
> Replica ID: 3
> Replica Root: dc=
> Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
> Receiver: :389 ldap://:389/
> Type: master
> Time Lag: - 0:22:29
> Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
> Last Modify Time: 8/24/2016 17:07:34
> Supplier: :389
> Sent/Skipped: 3 / 9048655
> Update Status: 0 Replica acquired successfully: Incremental update
> succeeded
> Update Started: 08/24/2016 18:36:33
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
> ###
>
> So even the synchronization looks good no ?
>
> And even with that, this master really is unsynchronized and don't have
> all the users the other master has.
>
> Best regards.
>
> Bahan
>
> On Wed, Aug 24, 2016 at 6:33 PM, bahan w  wrote:
>
>> Hey guys.
>>
>> I performed it :
>> ###
>> # /usr/bin/repl-monitor.pl -f /tmp/checkconf -s
>> Directory Server Replication Status (Version 1.1)
>>
>> Time: Wed Aug 24 2016 18:16:50
>>
>> Master: :389 ldap://:389/
>> Replica ID: 4
>> Replica Root: dc=
>> Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: 0:00:00
>> Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
>> Last Modify Time: 8/24/2016 18:16:50
>> Supplier: :389
>> Sent/Skipped: 179031 / 1037
>> Update Status: 0 Replica acquired successfully: Incremental update started
>> Update Started: 08/24/2016 18:16:50
>> Update Ended: n/a
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>>
>> Master: :389 ldap://:389/
>> Replica ID: 3
>> Replica Root: dc=
>> Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: - 0:22:29
>> Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
>> Last Modify Time: 8/24/2016 17:07:34
>> Supplier: :389
>> Sent/Skipped: 3 / 9045345
>> Update Status: 0 Replica acquired successfully: Incremental update started
>> Update Started: 08/24/2016 18:16:50
>> Update Ended: n/a
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>> ###
>>
>> Do you see something strange in there ?
>> I have another environment where I have two replicated master and they
>> are OK.
>> And when I check the same command, the result is a little bit different :
>> ###
>> Master: :389 ldap://:389/
>> Replica ID: 4
>> Replica Root: dc=
>> Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: 0:00:00
>> Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
>> Last Modify Time: 8/24/2016 18:16:00
>> Supplier: :389
>> Sent/Skipped: 343515 / 0
>> Update Status: 0 Replica acquired successfully: Incremental update
>> succeeded
>> Update Started: 08/24/2016 18:15:59
>> Update Ended: 08/24/2016 18:16:08
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>>
>> Master: :389 ldap://:389/
>> Replica ID: 3
>> Replica Root: dc=
>> Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: - 390:51:38
>> Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
>> Last Modify Time: 8/8/2016 11:24:28
>> Supplier: :389
>> Sent/Skipped: 5 / 2596073
>> Update Status: 0 Replica acquired successfully: Incremental update
>> succeeded
>> Update Started: 08/24/2016 18:16:00
>> Update Ended: 08/24/2016 18:16:12
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>> ###
>>
>> Best regards.
>>
>> Bahan
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-24 Thread bahan w

Hey guys.

I performed it :
###
# /usr/bin/repl-monitor.pl -f /tmp/checkconf -s
Directory Server Replication Status (Version 1.1)

Time: Wed Aug 24 2016 18:16:50

Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Last Modify Time: 8/24/2016 18:16:50
Supplier: :389
Sent/Skipped: 179031 / 1037
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9045345
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI
###

Do you see something strange in there ?
I have another environment where I have two replicated master and they are
OK.
And when I check the same command, the result is a little bit different :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Last Modify Time: 8/24/2016 18:16:00
Supplier: :389
Sent/Skipped: 343515 / 0
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:15:59
Update Ended: 08/24/2016 18:16:08
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 390:51:38
Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
Last Modify Time: 8/8/2016 11:24:28
Supplier: :389
Sent/Skipped: 5 / 2596073
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:16:00
Update Ended: 08/24/2016 18:16:12
Schedule: always in sync
SSL: SASL/GSSAPI
###

Best regards.

Bahan
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-24 Thread Petr Spacek

Hi,

again, please always keep freeipa-users@redhat.com in Cc of your e-mails. This
is not a private support channel.

Ludwig, do you know if dataversion is expected to be consistent among all
replicas or not? I would not expect consistent values.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/rootdse-attributes.html#dataversion

did not answer this question. If we find out the right answer we should extend
the description in documentation.

Petr^2 Spacek

On 24.8.2016 12:12, bahan w wrote:
> Re.
> 
> I checked the conflicts but I didn't find any between the two servers.
> ###
> 
> ldapsearch -x -D "cn=directory manager" -W -b "dc="
> "nsds5ReplConflict=*" \* nsds5ReplConflict
> ###
> 
> The only thing I see is that one my master is in IPA 3.0.0.42 and another
> is IPA 3.0.0.47.
> The server with a problem of synchronization is 3.0.0.47.
> 
> Here is a partial result from the command on each server:
> ###
> ldapsearch -Y GSSAPI -h `hostname` -b "" -s base
> ###
> 
> On the server OK
> ###
> 
> vendorVersion: 389-Directory/1.2.11.15 B2015.247.1737
> dataversion: 020160823201940
> 
> ###
> 
> 
> On the server with the problem of sync :
> 
> ###
> 
> vendorVersion: 389-Directory/1.2.11.15 B2015.022.1831
> dataversion: 020160823195011
> ###
> 
> Is the field dataversion the timestamp of the last version of the ldap
> database ?
> 
> I'm going to increase loglevel to DEBUG this afternoon before anything.
> 
> I found this in the red hat doc :
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html
> 
> ###
> 28.5.4. Reinitializing IdM Servers
> When a replica is first created, the database of the master server is
> copied, completely, over to the replica database. This process is called
> *initialization*. If a server/replica is offline for a long period of time
> or there is some kind of corruption in its database, then the server can be
> re-initialized, with a fresh and updated set of data.
> This is done using the re-initialize command. The target server being
> initialized is the local host. The server or replica from which to pull the
> data to initialize the local database is specified in the --from option:
> 
> [root@server ~]# ipa-replica-manage re-initialize --from srv1.example.com
> 
> ###
> 
> Do you know if it is available in IPA 3.0.0.47 ?
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Aug 24, 2016 at 11:50 AM, bahan w  wrote:
> 
>> Hello Petr, Orion.
>>
>> I checked the errors log from the dirsrv on both masters and I found
>> nothing related to an error with the replication plugin.
>>
>> I also performed all the tests described in the link Petr provided. Thank
>> you for this. Every one of this command is OK on both masters.
>>
>> I'm checking the access logs from dirsrv now.
>>
>> Any other tracks to follow ? Increase the log level on the replica failing
>> to sync ?
>>
>> Best regards.
>>
>> Bahan
>>
>> On Wed, Aug 24, 2016 at 8:41 AM, Petr Spacek  wrote:
>>
>>> On 23.8.2016 22:44, bahan w wrote:
 Hello !

 I am using IPA 3.0.0 on RedHat 6.6 servers.

 I have two masters and this evening, I realized that one of them was
 desynchronized, some users and groups were missing.

 I was wondering if there was an ipa command to resynchronize replica
>>> which
 are not sync with the other ?
>>>
>>> First of all, it is necessary to find out replication does not work.
>>>
>>> Please see
>>> http://www.freeipa.org/page/Troubleshooting#Replication_issues
>>>
>>> --
>>> Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-24 Thread Petr Spacek

Hi,

please keep freeipa-users@redhat.com in Cc.

If there are no problems indicated in log, is it really a problem with
replication or something else?

I would try

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Monitoring_Replication_Status.html#replication-monitoring-script

and see if replication is working or not.

Petr^2 Spacek

On 24.8.2016 11:50, bahan w wrote:
> Hello Petr, Orion.
> 
> I checked the errors log from the dirsrv on both masters and I found
> nothing related to an error with the replication plugin.
> 
> I also performed all the tests described in the link Petr provided. Thank
> you for this. Every one of this command is OK on both masters.
> 
> I'm checking the access logs from dirsrv now.
> 
> Any other tracks to follow ? Increase the log level on the replica failing
> to sync ?
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Aug 24, 2016 at 8:41 AM, Petr Spacek  wrote:
> 
>> On 23.8.2016 22:44, bahan w wrote:
>>> Hello !
>>>
>>> I am using IPA 3.0.0 on RedHat 6.6 servers.
>>>
>>> I have two masters and this evening, I realized that one of them was
>>> desynchronized, some users and groups were missing.
>>>
>>> I was wondering if there was an ipa command to resynchronize replica
>> which
>>> are not sync with the other ?
>>
>> First of all, it is necessary to find out replication does not work.
>>
>> Please see
>> http://www.freeipa.org/page/Troubleshooting#Replication_issues
>>
>> --
>> Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

2016-08-23 Thread Petr Spacek

On 23.8.2016 22:44, bahan w wrote:
> Hello !
> 
> I am using IPA 3.0.0 on RedHat 6.6 servers.
> 
> I have two masters and this evening, I realized that one of them was
> desynchronized, some users and groups were missing.
> 
> I was wondering if there was an ipa command to resynchronize replica which
> are not sync with the other ?

First of all, it is necessary to find out replication does not work.

Please see
http://www.freeipa.org/page/Troubleshooting#Replication_issues

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

Re: [Freeipa-users] Two masters and one of them is desynchronized

9 matches

Site Navigation

Mail list logo

Footer information