[Freeipa-users] Missing data encountered + Incremental update failed and requires administrator action

[Martin Kosek]

On 09/17/2015 04:48 PM, Benjamin Reed wrote:
> Sorry it's taken a while to get back to you, I was gone for a few
> weeks.  This seemed to get us back up and running and things looked like
> they were working, but looking at the logs, it appears we're hitting the
> next issue that is going to eventually bite us.  :)
>
> Here's what I'm seeing in the logs:
>
>> [15/Sep/2015:08:57:29 -0400] ipalockout_postop - [file ipa_lockout.c,
>> line 503]: Failed to retrieve entry "david": 32
>> [15/Sep/2015:09:56:20 -0400] ipalockout_preop - [file ipa_lockout.c,
>> line 749]: Failed to retrieve entry "emily": 32
>> [15/Sep/2015:09:56:20 -0400] ipalockout_postop - [file ipa_lockout.c,
>> line 503]: Failed to retrieve entry "emily": 32
>> [15/Sep/2015:11:50:34 -0400] ldbm_back_delete - conn=0 op=0 [retry: 1]
>> No original_tombstone for changenumber=102502,cn=changelog!!
>> [15/Sep/2015:12:02:19 -0400] ipalockout_preop - [file ipa_lockout.c,
>> line 749]: Failed to retrieve entry "tina": 32
>> [15/Sep/2015:12:02:19 -0400] ipalockout_postop - [file ipa_lockout.c,
>> line 503]: Failed to retrieve entry "tina": 32
>
> I've found some references to this stuff in google searches, but I'm not
> real clear on what the implications are, nor how to go about
> understanding it well enough to know the right fix.

This is https://fedorahosted.org/freeipa/ticket/4889. So it should be benign, 
it just seems that some software of yours is using user name instead of DN to 
log user in. More info in the ticket.

>
> There are two hosts (ipa and ipa2).  These logs are from the "ipa"
> server, the one I had to rebuild.  I do eventually get this:
>
>> [15/Sep/2015:12:58:46 -0400] NSMMReplicationPlugin -
>> agmt="cn=meToipa2.XXX" (ipa2:389): Replication bind with GSSAPI auth
>> resumed
>
> ...but the original_tombstone thing makes me thing something is still
> not in sync.

This message is actually OK, it means replication plugin was connected. Not 
sure about the tombstone though, if you are still hitting issues, I would 
suggest including bigger chunk of your server logs.

> Any clues as to what else I might need to do to make sure this server is
> back in 100% working order?
>
> Thanks,
> Ben
>
> On 8/24/15 2:42 AM, Martin Kosek wrote:
>>>> I fear this means that something is still not properly in sync and will
>>>> eventually come back to bite me.  Any ideas what's going on here, and
>>>> how to fix it?
>> Yup, this looks as something that can eventually bite you. It looks like your
>> replica's CA database got somehow corrupted and stopped replicating with other
>> master. This could lead to outdated data on the replica, like certificates,
>> CRL, etc.
>>
>> You can re-initialize the Dogtag database from other healthy master with CA,
>> using "ipa-csreplica-manage" command. Some advise should be for example here:
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-topology.html#initialize
>>
>> (Note that we need "ipa-csreplica-manage" in this case, as the reported faulty
>> agreement is Dogtag/CA agreement)
>