[Freeipa-users] ipa-client-install hangs on ipa-getkeytab - Fixed!!

[Martin Kosek]

On Wed, 2012-05-30 at 08:02 +0400, freeipa at noboost.org wrote:
> On Tue, May 29, 2012 at 09:00:43AM +0200, Martin Kosek wrote:
> > On Mon, 2012-05-28 at 10:21 +0400, freeipa at noboost.org wrote:
> > > Hi All,
> > > 
> > > This one has me stumped!
> > > For some reason my Centos 5.8 x64 Linux server hangs during
> > > "ipa-client-install"
> > > 
> > > Server:
> > > * ipa-admintools-2.1.3-9.el6.x86_64
> > > * ipa-client-2.1.3-9.el6.x86_64
> > > * ipa-pki-ca-theme-9.0.3-7.el6.noarch
> > > * ipa-pki-common-theme-9.0.3-7.el6.noarch
> > > * ipa-python-2.1.3-9.el6.x86_64
> > > * ipa-server-2.1.3-9.el6.x86_64
> > > * ipa-server-selinux-2.1.3-9.el6.x86_64
> > > 
> > > Client:
> > > CentOS release 5.8 (Final) (x86_64)
> > > * ipa-client-2.1.3-2.el5_8
> > > * sssd-client-1.5.1-49.el5_8.1
> > > 
> > > Questions:
> > > * Is there a better way to diagnose the ipa-getkeytab command? Perhaps I
> > >   can run a native kerberos command? 
> > > * Any tips welcome, I've tried straces and tcpdump to work this one out,
> > >   hmm..
> > > 
> > > 
> > > Error:
> > > "ipa-client-install" runs fine and then hangs (without reason):
> > > [below is the chopped version]
> > > 
> > > -------------------------------------------------------------------
> > > [libdefaults]
> > >   default_realm = EXAMPLE.COM
> > >   dns_lookup_realm = true
> > >   dns_lookup_kdc = true
> > >   rdns = false
> > >   ticket_lifetime = 24h
> > >   forwardable = yes
> > > 
> > > [realms]
> > >   EXAMPLE.COM = {
> > >     pkinit_anchors = FILE:/etc/ipa/ca.crt
> > >   }
> > > 
> > > [domain_realm]
> > >   .example.com = EXAMPLE.COM
> > >   example.com = EXAMPLE.COM
> > > 
> > > 
> > > Password for admin at EXAMPLE.COM: 
> > > root        : DEBUG    args=kinit admin at EXAMPLE.COM
> > > root        : DEBUG    stdout=Password for admin at EXAMPLE.COM: 
> > > 
> > > root        : DEBUG    stderr=
> > > -------------------------------------------------------------------
> > > 
> > > `ps -ef` on the client side, shows that the install is getting stuck on
> > > "ipa-getkeytab" for some reasons.
> > > 
> > > root     15842 15814  0 15:09 pts/1    00:00:00 /usr/bin/python -E
> > > /usr/sbin/ipa-client-install -d
> > > 
> > > root     15852 15842  0 15:09 pts/1    00:00:00 /usr/sbin/ipa-join -s
> > > ipa-server.example.com -b dc=example,dc=com -d
> > > 
> > > root     15853 15852  0 15:09 pts/1    00:00:00 /usr/sbin/ipa-getkeytab
> > > -s ipa-server.example.com -p
> > > host/client.example.com at EXAMPLE.COM -k /etc/krb5.keytab
> > > 
> > > 
> > > cya
> > > 
> > > Craig
> > > 
> > 
> > Hello Craig,
> > 
> > I think that in this case, strace may be a good choice to find out where
> > it hangs. I assume you already have the IPA server installed and you are
> > trying to install IPA client on different machine.
> yes that is correct
> > 
> > If you run ipa-getkeytab with strace separately from ipa-client-install
> > you can test where it hangs. You can use any principal existing in IPA
> > server, including host/client.example.com at EXAMPLE.COM if the host entry
> > exists.
> > 
> > To authenticate with ipa-getkeytab on a machine where ipa-client-isntall
> > was unsuccessful you can either manually configure /etc/krb5.conf to use
> > IPA server KDC and run kinit or you could use "-D BINDDN -w PASSWORD"
> > options to authenticate via LDAP bind.
> Heres what I did, I'm not sure which part fixed it. But everything works
> fine now!

Its great to hear that.

> 
> Steps followed:
> 
> 1) Found an old policy referring to this client in the kerberos
> database, Naturally I deleted this.
> 
> 2) Fixed up the /etc/krb5.conf on the client & ran the ipa-getkeytab
> command (using an existing host principal). To my surprise this worked.
> 
> # /usr/sbin/ipa-getkeytab -s sysvm-ipa.example.com -p \
> # host/craigpc.example.com at EXAMPLE.COM -k /etc/krb5.keytab
> # Keytab successfully retrieved and stored in: /etc/krb5.keytab
> 
> 3) re-run the ipa-client-install
> It worked first time and problem solved. 
> 
> Any thoughts on the actual issue? could it have been the old policy
> entry?

I am not a Kerberos guru, but I think it could have been possible. But
we would not know for sure until we have some reproducer for this issue
in our hands.

> 
> 4) local keytab file
> The local keytab file looks fine now, I assume that there is an easy way
> to delete the craigpc principal entry? 

You can use ipa-rmkeytab program to remove the unneeded principal
entries.

> 
> $ sudo klist -k /etc/krb5.keytab
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
>    2 host/craigpc.example.com at EXAMPLE.COM
>    2 host/craigpc.example.com at EXAMPLE.COM
>    2 host/craigpc.example.com at EXAMPLE.COM
>    2 host/craigpc.example.com at EXAMPLE.COM
>    2 host/craigpc.example.com at EXAMPLE.COM
>    1 host/client.example.com at EXAMPLE.COM
>    1 host/client.example.com at EXAMPLE.COM
>    1 host/client.example.com at EXAMPLE.COM
>    1 host/client.example.com at EXAMPLE.COM
>    1 host/client.example.com at EXAMPLE.COM
> 
> > 
> > Martin
> > 
> 
> cya
> 
> Craig

HTH,
Martin