On 01/23/2017 05:09 PM, Harald Dunkel wrote:
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?
Yes I think so. It is difficult to predict how many entries need to be
fixed but we may consider it should be close to 43.
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.
Do you want to run ipabak against ipa1 or ipa2 server ?
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
enabled.
Do you think this could work?
It should work if you run ipabak against ipa1 or ipa2. But then how to
prevent that ipa1/ipa2 get more conflicts with the iterations of tests ?
Regards
Harri
--
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
