[Freeipa-users] ipa-client-install failure
Dmitri Pal
dpal at redhat.com
Sat Mar 21 00:03:38 UTC 2015
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 <mailto: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
> <mailto: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
> <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/17274ba4/attachment.htm>
More information about the Freeipa-users
mailing list