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

Thu May 31 05:28:53 UTC 2012

On Wed, May 30, 2012 at 12:01:21PM -0400, Rob Crittenden wrote:
> 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!
> >
> >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?
> 
> Can you provide any more information on what this policy was and
> where it was stored?
It was just a simple HBAC policy which allowed a couple of users to that
host, on all services and from any client. At this stage I don't have an ldap 
dump to send you. But if I get time, I'll restore it from backup and send it over.

cya

Craig

> 
> rob
> 
> >
> >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?
> >
> >$ 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
> >
> >_______________________________________________
> >Freeipa-users mailing list
> >Freeipa-users at redhat.com
> >https://www.redhat.com/mailman/listinfo/freeipa-users
>