On 24 March 2015 at 14:49, Dmitri Pal <[email protected]> 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 [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]'". > > > 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 < > [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 >> 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 [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/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 <[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 >
-- 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
