[Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins

Alexander Bokovoy abokovoy at redhat.com
Fri Feb 19 14:23:23 UTC 2016


On Fri, 19 Feb 2016, Martin Kosek wrote:
>On 02/19/2016 03:14 PM, Alexander Bokovoy wrote:
>> On Fri, 19 Feb 2016, Martin Kosek wrote:
>>>>> Why trust-add?
>>>>>
>>>>> I'm not a big fan of cluttering existing commands(find, show, mod) with logic
>>>>> to fix one upgrade bug. But I understand a need to communicate it somehow.
>>>>>
>>>>> Would it make sense to move such logic to a separate command, e.g.
>>>>> trust-check/trust-verify?  The command can do additional check in a future.
>>>> No. What is the value of trust-add if it says you 'Trust established and
>>>> verified' while in reality it didn't? This specific issue is very easy
>>>> to catch.
>>>
>>> I think the point was that we are proposing and doing a non-trivial engineering
>>> effort to do warning for one-off bug that will be fixed in next bugfix release.
>>> I would agree if the check is more systematic, but doing a special LDAP search
>>> (for example) from now on because of this one-off bug does not seem to me as
>>> ideal path.
>> I don't want to have a separate LDAP search. We do LDAP search *already*
>> in trust_add because the object is actually created by Samba code as
>> result of our interactions with local smbd, so we anyway are reading it.
>
>Ok.
>
>> The problem here is in the fact that somebody may restore a backup done
>> before the package upgrade which means whole data in LDAP will be back
>> to the old state even though we ran the upgrade before.
>
>I think that is a highly unlikely situation to warrant any non-trivial
>development effort. After such restore, when the admin notice that trust is not
>working, they would start redoing trust-add anyway.
May be. I still think adding check for ipaNTSecurityIdentifier missing
for normal operation of trust-add is beneficial because it actually
allows us to detect problem immediately.
-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list