[Freeipa-users] errors when one ipa server down
Michael Mercier
mmercier at gmail.com
Wed Sep 19 16:00:08 UTC 2012
On 2012-09-18, at 4:03 PM, Jakub Hrozek wrote:
> On Tue, Sep 18, 2012 at 02:38:13PM -0400, Michael Mercier wrote:
>>
>> On 2012-09-18, at 4:03 AM, Jakub Hrozek wrote:
>>
>>> On Mon, Sep 17, 2012 at 11:17:47AM -0400, Dmitri Pal wrote:
>>>>> [root at ipaserver2 ~]ifdown eth0 # NOTE: ipaserver2 is 172.16.112.8
>>>>>
>>>>> [root at ipaclient ~]# SSSD_KRB5_LOCATOR_DEBUG=1 kinit mike
>>>>> [sssd_krb5_locator] sssd_krb5_locator_init called
>>>>> [sssd_krb5_locator] Found [172.16.112.8] in [/var/lib/sss/pubconf/kdcinfo.MPLS.LOCAL].
>>>>> [sssd_krb5_locator] sssd_realm[MPLS.LOCAL] requested realm[MPLS.LOCAL] family[0] socktype[2] locate_service[1]
>>>>> [sssd_krb5_locator] addr[172.16.112.8:88] family[2] socktype[2]
>>>>> [sssd_krb5_locator] [172.16.112.8] used
>>>>> [sssd_krb5_locator] sssd_krb5_locator_close called
>>>>> [sssd_krb5_locator] sssd_krb5_locator_init called
>>>>> [sssd_krb5_locator] Found [172.16.112.8] in [/var/lib/sss/pubconf/kdcinfo.MPLS.LOCAL].
>>>>> [sssd_krb5_locator] sssd_realm[MPLS.LOCAL] requested realm[MPLS.LOCAL] family[0] socktype[1] locate_service[1]
>>>>> [sssd_krb5_locator] addr[172.16.112.8:88] family[2] socktype[1]
>>>>> [sssd_krb5_locator] [172.16.112.8] used
>>>>> [sssd_krb5_locator] sssd_krb5_locator_close called
>>>>> kinit: Cannot contact any KDC for realm 'MPLS.LOCAL' while getting initial credentials
>>>>
>>>> Jakub, does this make sense to you?
>>>>
>>>
>>> As stated elsewhere in this thread, bare kinit does not contact the SSSD
>>> at all. You want to go through the PAM stack (with "su - mike" or "ssh
>>> mike at ipaclient") in order to contact the SSSD so that the SSSD refreshes
>>> the file.
>>>
>>> Does using "su - mike" refresh the file?
>>
>> When performing an 'su - mike' I will occasionally see a short delay (~2 seconds) when bringing the interfaces up and down on the servers.
>>
>> e.g.
>>
>> [root at ipaclient sssd]# su - mike
>
> ^^ Sorry, but can you re-run the test again and either su from another
> non-root user or ssh into the client for instance? The reason is that
> performing su as root would not contact the SSSD at all either. The
> default PAM configuration for su includes "pam_rootok.so" which just
> returns PAM_SUCCESS if the user who performs su has UID=0.
Hello,
[mike at ipaclient ~]$ su - eric
Password: # NOTE: no delay
[eric at ipaclient ~]$ exit
logout
[root at ipaserver ~]ifdown eth0
[mike at ipaclient ~]$ su - eric
Password: # NOTE: there is a delay here, ~5 seconds
[eric at ipaclient ~]$ exit
logout
[root at ipaserver ~]ifup eth0
[root at ipaserver2 ~]ifdown eth0
[mike at ipaclient ~]$ su - eric
Password: # NOTE: no delay
[eric at ipaclient ~]$exit
logout
[root at ipaserver ~]ifdown eth0
[root at ipaserver2 ~]ifup eth0
[mike at ipaclient ~]$ su - eric
Password: # NOTE: no delay
[eric at ipaclient ~]$ exit
logout
There does not appear to be any problems when doing an su -.
An addition note is that the ipaclient system had been sitting idle all night. Right before starting this test, I had to unlock the workstation.
Thanks,
Mike
>
> I kinda expect the result to be the same (at least for user who is not
> recently cached) because the case of IPA we need to establish a GSSAPI
> encrypted connection anyway so we'd talk to the KDC only to perform
> initgroups.
More information about the Freeipa-users
mailing list