[Freeipa-users] errors when one ipa server down

[Jakub Hrozek]

On Wed, Sep 19, 2012 at 12:00:08PM -0400, Michael Mercier wrote:
> 
> 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 -.
> 

I agree. I think that the SSSD fails over just fine.

> 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.

The unlock (if perfomed through GDM at least) would trigger an auth and
by extension going online/offline.

What I suspect was happening is that the kinit just contacted a KDC that was
present in the kdcinfo files, but down without the Kerberos libraries
knowing it was down -- and without a mechanism to tell the SSSD to go
and try another server. We're tracking this as a future enhancement..

Thank you for testing, Mike!