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 [email protected]
<mailto:[email protected]>'!
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 [email protected]
<mailto:[email protected]>'".
We should probably file a ticket about this. I am just not sure what
exactly it should be.
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
<[email protected] <mailto:[email protected]>>
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 <http://meson.hq.example.com>
Realm: HQ.EXAMPLE.COM <http://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 [email protected] <mailto:[email protected]>:
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
<http://ipa.hq.example.com>/ipa/json'
Forwarding 'ca_is_enabled' to json server
'https://ipa.hq.example.com <http://ipa.hq.example.com>/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (meson.hq.example.com <http://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
<http://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.
$ id admin
uid=1172000000(admin) gid=1172000000(admins) groups=1172000000(admins)
On 22 March 2015 at 21:04, Jakub Hrozek <[email protected]
<mailto:[email protected]>> 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
