[Freeipa-users] ipa-client-install failure
Roberto Cornacchia
roberto.cornacchia at gmail.com
Sat Mar 21 11:33:12 UTC 2015
/etc/nsswitch.conf:
passwd: files
shadow: files
group: files
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files
netgroup: files
publickey: nisplus
automount: files
aliases: files nisplus
sudoers: files sss
On 21 Mar 2015 01:06, "Dmitri Pal" <dpal at redhat.com> wrote:
> On 03/20/2015 07:56 PM, Roberto Cornacchia wrote:
>
> From https://fedorahosted.org/sssd/wiki/Troubleshooting, I see that
> invoking getent should correspond to seeing command 17 invoked in the nss
> log:
>
> Something like:
> [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input
> [admin].
>
> I don't see any command invocation in my sss_dnss log
>
>
> Forgot to reply to the list...
>
> Right.
> So how does your nsswitch.conf looks like?
>
>
> On 21 March 2015 at 00:51, Roberto Cornacchia <
> roberto.cornacchia at gmail.com> wrote:
>
>> Ah, I see, I had forgotten to enable debut in the nss section. Here its
>> log.
>>
>> On 21 March 2015 at 00:40, Roberto Cornacchia <
>> roberto.cornacchia at gmail.com> 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
>>>
>>>
>>> On 20 March 2015 at 23:03, Dmitri Pal <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> 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
>>>>> $ ntpdate ipa.hq.example.com
>>>>> $ ldapsearch -x -h 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:
>>>>> $ 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
>>>>>
>>>>>
>>>>> 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 krb5kdc[9229](info): AS_REQ (6
>>>>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH:
>>>>> admin at HQ.EXAMPLE.COM for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM,
>>>>> Additional pre-authentication required
>>>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>>>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime
>>>>> 1426884797, etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for
>>>>> krbtgt/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> 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> 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> wrote:
>>>>>>>
>>>>>>>> No, sorry about the confusion, i shouldn't have posted so quickly.
>>>>>>>>
>>>>>>>> When I use the correct domain (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> 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
>>>>>>>>> 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> 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
>>>>>>>>>> Realm: HQ.EXAMPLE.COM
>>>>>>>>>> DNS Domain: hq.example.com
>>>>>>>>>> IPA Server: 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:
>>>>>>>>>> Successfully retrieved CA cert
>>>>>>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
>>>>>>>>>> Issuer: CN=Certificate Authority,O=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
>>>>>>>>>> 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
>>>>>>>>>> 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 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.
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150321/03ed4c99/attachment.htm>
More information about the Freeipa-users
mailing list