[Freeipa-users] errors when one ipa server down

[Jakub Hrozek]

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.

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.