[Freeipa-users] ipa-client-install failure

Dmitri Pal dpal at redhat.com
Sat Mar 21 00:01:25 UTC 2015


On 03/20/2015 07:40 PM, Roberto Cornacchia wrote:
> Two log files in attachment (the other files in /var/log/sssd are all 
> empty).
>
> I'll also go through the troubleshooting page again, thanks
>

Do the logs include an id call for admin?
I do not see any instance of the word "admin" in the log.

>
> On 20 March 2015 at 23:03, Dmitri Pal <dpal at redhat.com 
> <mailto:dpal at redhat.com>> wrote:
>
>     On 03/20/2015 05:59 PM, Roberto Cornacchia wrote:
>>     SSSD logs are empty so far.
>
>     This is wrong.
>
>>     Isn't sssd.conf written by ipa-client-install?
>
>     Yes
>
>>     If I raise the debug level after client installation,
>
>     (and restart)
>
>>     what activities do you suggest to attempt from the client?
>     the ones that fail. getent call that returns nothing.
>     Also try 'id'.
>
>     http://www.freeipa.org/page/Troubleshooting#Client_Installation
>     https://fedorahosted.org/sssd/wiki/Troubleshooting
>
>>
>>
>>     On 20 March 2015 at 22:37, Dmitri Pal <dpal at redhat.com
>>     <mailto:dpal at redhat.com>> wrote:
>>
>>         On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
>>>         It certainly gets there, because the client gets in fact
>>>         enrolled as a domain host. I can see it from the UI in
>>>         Identity / Hosts. But not in the DNS zone.
>>>
>>>         *Before ipa-client-install, all these do work: *
>>>
>>>         $ ssh ipa.hq.example.com <http://ipa.hq.example.com>
>>>         $ ntpdate ipa.hq.example.com <http://ipa.hq.example.com>
>>>         $ ldapsearch -x -h ipa.hq.example.com
>>>         <http://ipa.hq.example.com> -b dc=hq,dc=example,dc=com uid=admin
>>>
>>>
>>>         *After running ipa-client-install, all these do work:*
>>>
>>>         $ kinit admin
>>>         Password for admin at HQ.EXAMPLE.COM <mailto:admin at HQ.EXAMPLE.COM>:
>>>         $ ipa dnszone-show --all
>>>         [...]
>>>         $ ntpq -p
>>>              remote       refid      st t when poll reach   delay
>>>         offset  jitter
>>>         ==============================================================================
>>>         *ipa.hq.example. 131.155.140.130  3 u   19   64    1  
>>>          0.415 -0.006   0.000
>>>          LOCAL(0)  .LOCL.           5 l    -   64    0    0.000
>>>          0.000   0.000
>>>
>>>         *But this does NOT work:*
>>>         $ getent passwd admin at hq.example.com
>>>         <mailto:admin at hq.example.com>
>>
>>         What do SSSD logs show on the client?
>>         Please rise the SSSD debug_level and provide SSSD logs.
>>
>>>
>>>         *On the server, in /var/log/krb5kdc.log, I see many of these:*
>>>
>>>         Mar 20 21:53:17 ipa.hq.example.com
>>>         <http://ipa.hq.example.com> krb5kdc[9229](info): AS_REQ (6
>>>         etypes {18 17 16 23 25 26}) 192.168.0.207
>>>         <http://192.168.0.207>: NEEDED_PREAUTH: admin at HQ.EXAMPLE.COM
>>>         <mailto:admin at HQ.EXAMPLE.COM> for
>>>         krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM
>>>         <mailto:COM at HQ.EXAMPLE.COM>, Additional pre-authentication
>>>         required
>>>         Mar 20 21:53:17 ipa.hq.example.com
>>>         <http://ipa.hq.example.com> krb5kdc[9229](info): AS_REQ (6
>>>         etypes {18 17 16 23 25 26}) 192.168.0.207
>>>         <http://192.168.0.207>: ISSUE: authtime 1426884797, etypes
>>>         {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM
>>>         <mailto:admin at HQ.EXAMPLE.COM> for
>>>         krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM
>>>         <mailto:HQ.EXAMPLE.COM at HQ.EXAMPLE.COM>
>>
>>         This is not an error. It is a normal user authentication.
>>         OK so it is DNS that is not working. Is DNS server running on
>>         the server?
>>         What do Bind logs show?
>>
>>
>>>
>>>         192.168.0.207 is the IP of the client I'm trying to install.
>>>         However, higher up in the log, I also see such errors for
>>>         the ipa server itself.
>>>
>>>         On 20 March 2015 at 20:24, Dmitri Pal <dpal at redhat.com
>>>         <mailto:dpal at redhat.com>> wrote:
>>>
>>>             On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
>>>>             No, all real machines.
>>>>
>>>>             I'm really sorry it's taking so much of your time.
>>>>             I had tried almost everything on a VM setting first,
>>>>             and everything was fine.
>>>>             Everything always works fine, until you actually need it.
>>>
>>>
>>>             We try to help as much as we can.
>>>             Can you do LDAP lookups as a directory manager from
>>>             client host to server?
>>>             Can you ssh from client to server?
>>>
>>>             When you try to install client is there anything in the
>>>             logs on the server? Does it even get there?
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>             On 20 March 2015 at 19:41, Dmitri Pal <dpal at redhat.com
>>>>             <mailto:dpal at redhat.com>> wrote:
>>>>
>>>>                 On 03/20/2015 01:57 PM, Roberto Cornacchia wrote:
>>>>>                 But the ipa server itself is also enrolled as a
>>>>>                 client, just after the server installation,
>>>>>                 right?. And that worked fine.
>>>>
>>>>                 Are these VMs?
>>>>                 There have been a similar case when the network was
>>>>                 not set properly for the virtual test environment.
>>>>
>>>>
>>>>>
>>>>>                 On 20 March 2015 at 18:55, Roberto Cornacchia
>>>>>                 <roberto.cornacchia at gmail.com
>>>>>                 <mailto:roberto.cornacchia at gmail.com>> wrote:
>>>>>
>>>>>                     No, sorry about the confusion, i shouldn't
>>>>>                     have posted so quickly.
>>>>>
>>>>>                     When I use the correct domain (hq.example.com
>>>>>                     <http://hq.example.com>), then I really get
>>>>>                     all the same errors as before, also in the new
>>>>>                     client.
>>>>>
>>>>>
>>>>>
>>>>>                     On 20 Mar 2015 18:39, "Dmitri Pal"
>>>>>                     <dpal at redhat.com <mailto:dpal at redhat.com>> wrote:
>>>>>
>>>>>                         On 03/20/2015 01:25 PM, Roberto Cornacchia
>>>>>                         wrote:
>>>>>>                         Oops. Not true, forget last email.
>>>>>>
>>>>>>                         This secon client installation went
>>>>>>                         different just because it took the wrong
>>>>>>                         domain.
>>>>>>                         It used *example.com
>>>>>>                         <http://example.com>* (what was
>>>>>>                         previously set) instead of
>>>>>>                         *hq.example.com <http://hq.example.com>*
>>>>>>
>>>>>>                         Uninstalled, tried again with
>>>>>>                         --hostname=photon.hq.example.com
>>>>>>                         <http://photon.hq.example.com>
>>>>>>                         And then it behaves precisely like the
>>>>>>                         previous client.
>>>>>>
>>>>>>                         So something seems wrong in the server.
>>>>>>
>>>>>>                         On 20 March 2015 at 18:18, Roberto
>>>>>>                         Cornacchia <roberto.cornacchia at gmail.com
>>>>>>                         <mailto:roberto.cornacchia at gmail.com>> wrote:
>>>>>>
>>>>>>                             Update:
>>>>>>                             I tried from another client. Also
>>>>>>                             FC21, same network, same settings
>>>>>>                             from the same DHCP.
>>>>>>                             But obviously it must have something
>>>>>>                             different because it partially succeeded.
>>>>>>
>>>>>>                             - I do not get errors about LDAP users.
>>>>>>                             - I do not get errors about DNS update
>>>>>>
>>>>>>                             However:
>>>>>>                             - I still get the initial error about NTP
>>>>>>                             - The host is enrolled, but not added
>>>>>>                             to the DNS zone
>>>>>>
>>>>>>                             Now, I don't care much about the
>>>>>>                             previous client. It was pretty much
>>>>>>                             empty and can re-install Fedora from
>>>>>>                             scratch.
>>>>>>
>>>>>>                             But I'd like to understand if this is
>>>>>>                             still a problem.
>>>>>>                             It should be added to the zone,
>>>>>>                             shouldn't it?
>>>>>>
>>>>>>                             $ ipa-client-install --mkhomedir
>>>>>>                             --ssh-trust-dns --force-ntpd
>>>>>>                             Discovery was successful!
>>>>>>                             Hostname: photon.example.com
>>>>>>                             <http://photon.example.com>
>>>>>>                             Realm: HQ.EXAMPLE.COM
>>>>>>                             <http://HQ.EXAMPLE.COM>
>>>>>>                             DNS Domain: hq.example.com
>>>>>>                             <http://hq.example.com>
>>>>>>                             IPA Server: ipa.hq.example.com
>>>>>>                             <http://ipa.hq.example.com>
>>>>>>                             BaseDN: dc=hq,dc=example,dc=com
>>>>>>
>>>>>>                             Continue to configure the system with
>>>>>>                             these values? [no]: yes
>>>>>>                             Synchronizing time with KDC...
>>>>>>                             *Unable to sync time with IPA NTP
>>>>>>                             server, assuming the time is in sync.
>>>>>>                             Please check that 123 UDP port is
>>>>>>                             opened.*
>>>>>>                             User authorized to enroll computers:
>>>>>>                             admin
>>>>>>                             Password for admin at HQ.EXAMPLE.COM
>>>>>>                             <mailto:admin at HQ.EXAMPLE.COM>:
>>>>>>                             Successfully retrieved CA cert
>>>>>>                             Subject: CN=Certificate
>>>>>>                             Authority,O=HQ.EXAMPLE.COM
>>>>>>                             <http://HQ.EXAMPLE.COM>
>>>>>>                             Issuer:  CN=Certificate
>>>>>>                             Authority,O=HQ.EXAMPLE.COM
>>>>>>                             <http://HQ.EXAMPLE.COM>
>>>>>>                             Valid From:  Mon Mar 16 18:44:35 2015 UTC
>>>>>>                             Valid Until: Fri Mar 16 18:44:35 2035 UTC
>>>>>>
>>>>>>                             Enrolled in IPA realm HQ.EXAMPLE.COM
>>>>>>                             <http://HQ.EXAMPLE.COM>
>>>>>>                             Created /etc/ipa/default.conf
>>>>>>                             New SSSD config will be created
>>>>>>                             Configured sudoers in /etc/nsswitch.conf
>>>>>>                             Configured /etc/sssd/sssd.conf
>>>>>>                             Configured /etc/krb5.conf for IPA
>>>>>>                             realm HQ.EXAMPLE.COM
>>>>>>                             <http://HQ.EXAMPLE.COM>
>>>>>>                             trying
>>>>>>                             https://ipa.hq.example.com/ipa/json
>>>>>>                             Forwarding 'ping' to json server
>>>>>>                             'https://ipa.hq.example.com/ipa/json'
>>>>>>                             Forwarding 'ca_is_enabled' to json
>>>>>>                             server
>>>>>>                             'https://ipa.hq.example.com/ipa/json'
>>>>>>                             Systemwide CA database updated.
>>>>>>                             Added CA certificates to the default
>>>>>>                             NSS database.
>>>>>>                             Adding SSH public key from
>>>>>>                             /etc/ssh/ssh_host_rsa_key.pub
>>>>>>                             Adding SSH public key from
>>>>>>                             /etc/ssh/ssh_host_ed25519_key.pub
>>>>>>                             Adding SSH public key from
>>>>>>                             /etc/ssh/ssh_host_dsa_key.pub
>>>>>>                             Adding SSH public key from
>>>>>>                             /etc/ssh/ssh_host_ecdsa_key.pub
>>>>>>                             Forwarding 'host_mod' to json server
>>>>>>                             'https://ipa.hq.example.com/ipa/json'
>>>>>>                             *Could not update DNS SSHFP records.*
>>>>>>                             SSSD enabled
>>>>>>                             Configured /etc/openldap/ldap.conf
>>>>>>                             NTP enabled
>>>>>>                             Configured /etc/ssh/ssh_config
>>>>>>                             Configured /etc/ssh/sshd_config
>>>>>>                             Configuring hq.example.com
>>>>>>                             <http://hq.example.com> as NIS domain.
>>>>>>                             Client configuration complete.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>                         It is different. It does not have the same
>>>>>                         failure about admin as you had in the
>>>>>                         first email.
>>>>>                         So may be it is the permissions issue and
>>>>>                         a separate NTP issue?
>>>>>                         Did you play with any permissions on the
>>>>>                         server side?
>>>>>
>>>>>
>>>>>                         -- 
>>>>>                         Thank you,
>>>>>                         Dmitri Pal
>>>>>
>>>>>                         Sr. Engineering Manager IdM portfolio
>>>>>                         Red Hat, Inc.
>>>>>
>>>>>
>>>>>                         --
>>>>>                         Manage your subscription for the
>>>>>                         Freeipa-users mailing list:
>>>>>                         https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>                         Go to http://freeipa.org for more info on
>>>>>                         the project
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>                 -- 
>>>>                 Thank you,
>>>>                 Dmitri Pal
>>>>
>>>>                 Sr. Engineering Manager IdM portfolio
>>>>                 Red Hat, Inc.
>>>>
>>>>
>>>>                 --
>>>>                 Manage your subscription for the Freeipa-users
>>>>                 mailing list:
>>>>                 https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>                 Go to http://freeipa.org for more info on the project
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>             -- 
>>>             Thank you,
>>>             Dmitri Pal
>>>
>>>             Sr. Engineering Manager IdM portfolio
>>>             Red Hat, Inc.
>>>
>>>
>>>             --
>>>             Manage your subscription for the Freeipa-users mailing list:
>>>             https://www.redhat.com/mailman/listinfo/freeipa-users
>>>             Go to http://freeipa.org for more info on the project
>>>
>>>
>>>
>>>
>>
>>
>>         -- 
>>         Thank you,
>>         Dmitri Pal
>>
>>         Sr. Engineering Manager IdM portfolio
>>         Red Hat, Inc.
>>
>>
>>         --
>>         Manage your subscription for the Freeipa-users mailing list:
>>         https://www.redhat.com/mailman/listinfo/freeipa-users
>>         Go to http://freeipa.org for more info on the project
>>
>>
>>
>>
>
>
>     -- 
>     Thank you,
>     Dmitri Pal
>
>     Sr. Engineering Manager IdM portfolio
>     Red Hat, Inc.
>
>
>     --
>     Manage your subscription for the Freeipa-users mailing list:
>     https://www.redhat.com/mailman/listinfo/freeipa-users
>     Go to http://freeipa.org for more info on the project
>
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150320/6d2a5793/attachment.htm>


More information about the Freeipa-users mailing list