[Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, <NULL>) [Internal Error (System error)]

thierry bordaz tbordaz at redhat.com
Mon Jan 23 16:45:20 UTC 2017



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
>




More information about the Freeipa-users mailing list