[Freeipa-users] ipa-client-install failure

Roberto Cornacchia roberto.cornacchia at gmail.com
Tue Mar 24 14:01:00 UTC 2015 

On 24 March 2015 at 14:49, Dmitri Pal <dpal at redhat.com> wrote:

>  On 03/24/2015 09:43 AM, Roberto Cornacchia wrote:
>
> Hi there,
>
>  All the issues I reported in this long thread are SOLVED.
>
>
> Thanks for closing the loop.
>
>  For completeness, I'm posting here the conclusions.
>
>  ipa-client-install did enroll the client but failed in several points:
>
>  $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
> [...]
> 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.
> [...]
> Failed to update DNS records.
> [...]
> Could not update DNS SSHFP records.
>  [...]
> Unable to find 'admin' user with 'getent passwd admin at hq.example.com'!
>  Unable to reliably detect configuration. Check NSS setup manually.
> [...]
> Client configuration complete.
>
>  There were two distinct problems:
>
>  1) NTP sync failed because despite using --force-ntp, chronyd wasn't
> stopped beforehand. Stopping it manually solved the issue. I believe
> ipa-client-install stopping chronyd was the intended behaviour, in which
> case this is perhaps a bug. If it needs to be stopped manually, then it
> should be documented clearly.
> The failed NTP sync caused Kerberos to fail, which explains "Unable to
> find 'admin' user with 'getent passwd admin at hq.example.com'".
>
>
> We should probably file a ticket about this. I am just not sure what
> exactly it should be.
>
>
>
IMHO, the "assuming the time is in sync" bit is dangerous. The client and
the server were already quite in sync (both automatically synced with a
remote time server) , but apparently not enough. Being time sync so central
in the infrastructure, I would probably want to abort the installation if
no sync can be performed successfully.



>
>  2) DNS update failed because for some obscure reason I forgot to open
> port 53/tcp on the server's firewall. Only 53/udp was open. This fooled me,
> because with 53/udp open, the DNS was almost completely functional.
> However, updates also require 53/tcp.
>
>
>  All in all, it was a full 2day digging and debugging. Bright side is, I
> learned a lot.
>
>  A sincere thank you for the many useful answers I received!
> Best,
> Roberto
>
>
> On 23 March 2015 at 10:07, Roberto Cornacchia <
> roberto.cornacchia at gmail.com> wrote:
>
>>  Dmitri, Rob, Jakub,
>>
>>  I found at least one of the major problems: chronyd.
>>
>>  This is what I get when I use ipa-client-install on a plain FC21
>> machine, *without* using --force-ntpd
>>
>>  WARNING: ntpd time&date synchronization service will not be configured
>> as
>> conflicting service (chronyd) is enabled
>> Use --force-ntpd option to disable it and force configuration of ntpd
>>
>>
>>  Good, then I abort and run it again with  --force-ntpd:
>>
>>   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.
>>
>>
>>  Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it
>> would take care of stopping and disabling chronyd. But it doesn't. That's
>> why I get the error above.
>>
>>  If I first stop chronyd manually and run the installation again, then
>> it does synchronise with NTP.
>> This was apparently the cause of "id admin" not working (kerberos failing
>> without proper NTP sync?)
>> Now the basic functionalities are all OK.
>> Also, chronyd is disabled and ntpd is enabled after installation - good.
>>
>>  My nsswitch.conf now looks like this:
>>
>>  passwd:     files sss
>> shadow:     files sss
>> group:      files sss
>>  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 sss
>> netgroup:   files sss
>>  publickey:  nisplus
>>  automount:  files sss
>>  aliases:    files nisplus
>> sudoers: files sss
>>
>>
>>
>>  I am left with 2 issues:
>>
>>  1) Is the above expected? Do I have to stop chronyd manually? Or is it
>> a bug?
>> 2) DNS update still does not work
>>
>>
>>  The latest installation log:
>>
>>
>>  $ systemctl stop chronyd
>>  $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
>>  Discovery was successful!
>>  Hostname: meson.hq.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...
>>  User authorized to enroll computers: 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.
>>  Hostname (meson.hq.example.com) not found in DNS
>> *Failed to update DNS records.*
>>  Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
>>  Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
>>  Adding SSH public key from /etc/ssh/ssh_host_rsa_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.
>>
>>  $ id admin
>>  uid=1172000000(admin) gid=1172000000(admins) groups=1172000000(admins)
>>
>>
>>
>>
>> On 22 March 2015 at 21:04, Jakub Hrozek <jhrozek at redhat.com> wrote:
>>
>>> On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia wrote:
>>> > Thanks Rob.
>>> >
>>> > Knowing that /etc/nsswitch.conf is created wrongly is a step forward,
>>> > although we don't know why that happens yet.
>>> > I'm not very keen on fixing it post-installation (except if this is
>>> just to
>>> > learn more about the issue), even if this seems to solve problems. I'm
>>> not
>>> > going to deploy freeIPA for real before I can at least run
>>> successfully a
>>> > plain installation.
>>>
>>> Hi,
>>>
>>> I find it a bit unexpected that the client system didn't have
>>> nsswitch.conf configured..I've never seen the client installation fail
>>> in this particular way.
>>>
>>> For debugging SSSD issues, we've created a new troubleshooting page
>>> upstream that should walk you through the config:
>>>     https://fedorahosted.org/sssd/wiki/Troubleshooting
>>> maybe this article would also help:
>>>
>>> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/
>>>
>>> But most improtantly, I wouldn't expect to see any issues as long as
>>> you use ipa-client-install. I guess re-enrolling the client would be the
>>> fastest way forward?
>>>
>>> --
>>> 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/20150324/62cbe23a/attachment.htm>

More information about the Freeipa-users mailing list