[Freeipa-devel] [PATCH] 0039 Try continue ipa-client-automount even if nsslapd-minssf > 0.

[Rob Crittenden]

David Kupka wrote:
> On 02/27/2015 02:26 PM, Martin Basti wrote:
>> On 27/02/15 14:21, Martin Basti wrote:
>>> On 26/02/15 15:54, David Kupka wrote:
>>>> On 02/26/2015 02:55 PM, Rob Crittenden wrote:
>>>>> Martin Basti wrote:
>>>>>> On 26/02/15 10:57, David Kupka wrote:
>>>>>>> https://fedorahosted.org/freeipa/ticket/4902
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Freeipa-devel mailing list
>>>>>>> Freeipa-devel at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>>>> Works for me, ACK.
>>>>>
>>>>> NACK.
>>>>>
>>>>> If you simply pass in /etc/ipa/ca.crt as the cacert path then it will
>>>>> use TLS.
>>>>>
>>>>> rob
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-devel mailing list
>>>>> Freeipa-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>>>
>>>>
>>>> Thanks for the catch Rob. Updated patch attached.
>>>>
>>> Hello, I tested it again, just nitpick:
>>>
>>> 1)
>>> Can you also update the commit message?
>> Never mind, I accidentally read old commit message. sorry.
>>>
>>> And question:
>>> I found, if you erase /etc/ipa/ca.crt from client and use --server
>>> option pointing to different IPA server (LDAP repectively) out of
>>> realm, ipa-client-atomount  returns success. Is this behavior good?
>>> This happens without this patch as well.
> 
> First of all this never happens if you rely on DNS discovery so most
> user will never encounter this behavior,
> 
> BUT it would be nice to add a check and warn the user that he is doing
> something unwise and will probably regret :-)
> Could you please file a ticket?

Hmm, interesting. Yeah, I suppose trying to get a host ticket would be
good defensive programming.

ACK on the new patch from me too.

rob