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)
--
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
