Hi Thierry,

On 01/23/17 11:59, thierry bordaz wrote:
> We need to get a clear status before trying to swap them.
> For example in your attachment the valid entry is member of 'DNS Admin' while 
> the conflict one is not. So possibly the valid entry is the one to keep.
> Conflicts entry
> dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=de
> belong to all these groups
> memberOf: cn=System: Read DNS 
> Configuration,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Write DNS 
> Configuration,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Manage DNSSEC 
> keys,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Manage DNSSEC 
> metadata,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Remove DNS 
> Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Update DNS 
> Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Read DNS Servers 
> Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de
> My initial thought was to check how it was member (which attribute it is 
> using and if it is nested/direct membership).
> So then we may try to repair the "valid" entry, making it similarly member of 
> those groups.
> But this is looking to be complex job and no guaranty it will repair 
> everything broken.
> Do you have a way to restore from a state where there was no conflict ?

I do have old backups. ipa1 and ipa2 were setup in dec 2015. They
are included in at least one monthly archive in jan 2016. I am not
sure if this old version is OK, though.

ldapsearch -o ldif-wrap=no -D "cn=directory manager" -w secret -b 
"dc=example,dc=de" | grep nsuniqueid | wc -l

tells me that there are 43 problems open, including the DNs that
are not referenced anywhere. Maybe its easier and less risky to
fix the broken entries?

I created a full replica (including CA) in an LXC container today
("ipabak"). The idea is to take a snapshot of the whole container,
run ipabak without network connection, and then create and verify
a shell script to fix the disconnected replica. On problems I can
roll ipabak back to the snapshot. Maybe it needs some iterations to
create a working script.

When the script appears to be fine I can revert the ipabak container
to the most recent snapshot again, connect it to the network to sync
it with ipa1 and then run the script with multisite replication

Do you think this could work?


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to