[Freeipa-users] ipa-client-install failure

Tue Mar 24 13:43:23 UTC 2015

Hi there,

All the issues I reported in this long thread are SOLVED.
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'".

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150324/7469de4b/attachment.htm>