[Freeipa-users] Checking 389 for ACI contamination

[Martin Kosek]

On 04/14/2015 03:51 AM, Brian Topping wrote:
> 
>> On Apr 13, 2015, at 1:33 PM, Martin Kosek <mkosek at redhat.com> wrote:
>> 
>> On 04/12/2015 05:27 AM, Brian Topping wrote:
>>> Hi all, trying to figure out if I may have contaminated my ACIs in the 
>>> process of upgrading my replicated deployment. I didn't upgrade the 
>>> instances at the same time, is there any possibility that the 3.x ACIs 
>>> contaminated the 4.x DIT?
>> 
>> What do you mean, by... contaminated? Can you please described what
>> exactly happened?
>> 
>> As Dmitri said, there were major ACI related changes in 4.0, but I am not
>> sure what is the problem in your case.
> 
> The only thing that is broken at the moment is my OCD. I did make a couple
> of changes in my 3.x deployment that appear to have been insufficient when I
> upgraded, but I didn't name them well and I'm having issues trying to find
> which ones they were. Now that I've RTFM on ACIs, I want to make sure
> everything that is there is there for a reason. I'd rather put effort in now
> than be surprised by some cruft I left behind in a future upgrade.

Ok :-)

> 
>>> If so, how would I check it? Is there an LDIF in the disto that I can 
>>> manually compare the entries?
>> 
>> I am not sure which entries are you referring to. But from 4.0, most of
>> the ACIs are now generated dynamically, from Python code.
> 
> If the schema/ACIs are managed by Python, it might be interesting for the
> script to generate warnings when it runs. Stuff like missing/extra schema &
> ACIs. Just a thought.

I think the ACI upgrade plugin indeed generates warnings whet it has problems
when processing the ACIs.

Not all ACIs are processed during upgrade to FreeIPA 4.0+. Only the FreeIPA
default system ACIs are processed, after upgrade you will see them as "System:
..." permissions that you will only have limited edit capabilities.