On 11/03/2015 04:24 PM, Andrew Krause wrote:
there are requests to hide these conflict entries so that the do not
interfere with other operations and there is ongoing discussion in DS
to implement another mechanism which doesn't have these side effects.
But on the other hand these entries are not generated out of the blue,
they indicate a scenario on the application/client side where the same
entry is added simultaneously on two or more servers. maybe as Martin
said by upgrading in parallel or by impatient clients which move to
another servers if no immediat success or by misconfigured proxies or
load balancers which send ops to multiple masters. So these conflict
entries could also seen as a hint that somthing is or was wrong.
You can proactively check for these entries before and harm is done and
delete them. Do
I upgraded 4 at the same time actually. It makes sense why the objects were
created and I do understand how replication conflicts are handled. I just
wanted to be absolutely certain that it was ok to delete these objects since it
seems pointless to ever keep them around. Has there been any talk of a
mechanism to just handle this on a regular basis (not that this situation
should happen regularly)?
ldapsearch -b "<SUFFIX>" "nsds5ReplConflict=*" nsds5ReplConflict
On Nov 3, 2015, at 1:42 AM, Martin Kosek <mko...@redhat.com> wrote:
On 11/03/2015 12:05 AM, Andrew Krause wrote:
After upgrading to 4.1 I have duplicated permission objects in my directory
with names including nsuniqueid. Is it safe to delete all of these objects?
Somehow this is only causing an issue for a specific user hitting a specific
(Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_eval_user_element]
(0x0080): Parse error on [cn=Read PassSync Managers
(Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules]
(0x0020): Could not construct eval request
(Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [ipa_hbac_evaluate_rules]
(0x0020): Could not construct HBAC rules
This is causing authentication to fail for the user in question, and I would
like to get rid of these useless objects if they are no longer necessary.
It looks like you had some replication problem in your network, or maybe
upgraded 2 FreeIPA instances at the same time, so they both generated
In any case, it should be case to delete the permissions with nsuniqueid,
FreeIPA should generate the managed permissions from scratch anyway, if they
are missing and upgrade is run again.
More info on replication conflicts here:
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project