Re: [Freeipa-users] ipa-client-install failure
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 ad...@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 ad...@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.cornacc...@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 timedate 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 ad...@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
Re: [Freeipa-users] ipa-client-install failure
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 ad...@hq.example.com mailto:ad...@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 ad...@hq.example.com mailto:ad...@hq.example.com'. 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 roberto.cornacc...@gmail.com mailto:roberto.cornacc...@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 timedate 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 ad...@hq.example.com mailto:ad...@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
Re: [Freeipa-users] ipa-client-install failure
On 24 March 2015 at 14:49, Dmitri Pal d...@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 ad...@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 ad...@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.cornacc...@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 timedate 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 ad...@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
Re: [Freeipa-users] ipa-client-install failure
On 23.3.2015 12:33, Roberto Cornacchia wrote: OK, thanks. That would be Dynamic updates, right? Then it is enabled. $ ipa dnszone-show --all Zone name: hq.example.com dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com. SOA serial: 1427108043 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE This is correct (but it should not affect SOA query anyway). Could you share named logs on debug level 10 with us? It would be even better is you could provide us tcpdump with transactions in question. On the client (before you start installation) please: 1) Execute command $ tcpdump -i any -w /tmp/dns.pcap 'port 53' 2) Run ipa-client-install 3) Kill the tcpdump: $ pkill tcpdump 4) Send us the file. Feel free to send the files to me (pspa...@redhat.com) and Martin^2 (mba...@redhat.com) privately if you do not want to make them public. Have a nice day! Petr^2 Spacek Allow query: any; Allow transfer: none; Allow PTR sync: FALSE nsrecord: ipa.hq.example.com. objectclass: idnszone, top, idnsrecord On 23 March 2015 at 12:27, Martin Basti mba...@redhat.com wrote: On 23/03/15 12:19, Roberto Cornacchia wrote: BTW, shouldn't named.conf contain an allow-update statement? Mine doesn't. Or is this managed differently? It is not needed. bind-dyndb-ldap plugin overrides this configuration, you just need to enable updates in IPA zone setting. Martin On 23 March 2015 at 12:16, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: On 23 March 2015 at 10:35, Petr Spacek pspa...@redhat.com wrote: On 23.3.2015 10:21, Roberto Cornacchia wrote: About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA server. Positive - Please check named.logs on the server side to see if there are any complains about unsuccessful key negotiation with client. I raised named's log level to debug 10 and restarted Ran ipa-client-install again. The log shows many queries from the client, for A/AAA/SOA record types, both about the server and the client. All approved, no problem. The log does not seem to contain a single failure / rejection. However: 1) The client reports that response to SOA query was unsuccessful. The server log does not say anything about this. 2) The server log does not contain any update request Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* Interesting, this should not be related to time synchronization in any way. DNS server simply did not return any answer. -- Petr^2 Spacek -- 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
Re: [Freeipa-users] ipa-client-install failure
Thank you, dump sent privately On 23 March 2015 at 13:33, Petr Spacek pspa...@redhat.com wrote: On 23.3.2015 12:33, Roberto Cornacchia wrote: OK, thanks. That would be Dynamic updates, right? Then it is enabled. $ ipa dnszone-show --all Zone name: hq.example.com dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com. SOA serial: 1427108043 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE This is correct (but it should not affect SOA query anyway). Could you share named logs on debug level 10 with us? It would be even better is you could provide us tcpdump with transactions in question. On the client (before you start installation) please: 1) Execute command $ tcpdump -i any -w /tmp/dns.pcap 'port 53' 2) Run ipa-client-install 3) Kill the tcpdump: $ pkill tcpdump 4) Send us the file. Feel free to send the files to me (pspa...@redhat.com) and Martin^2 (mba...@redhat.com) privately if you do not want to make them public. Have a nice day! Petr^2 Spacek Allow query: any; Allow transfer: none; Allow PTR sync: FALSE nsrecord: ipa.hq.example.com. objectclass: idnszone, top, idnsrecord On 23 March 2015 at 12:27, Martin Basti mba...@redhat.com wrote: On 23/03/15 12:19, Roberto Cornacchia wrote: BTW, shouldn't named.conf contain an allow-update statement? Mine doesn't. Or is this managed differently? It is not needed. bind-dyndb-ldap plugin overrides this configuration, you just need to enable updates in IPA zone setting. Martin On 23 March 2015 at 12:16, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: On 23 March 2015 at 10:35, Petr Spacek pspa...@redhat.com wrote: On 23.3.2015 10:21, Roberto Cornacchia wrote: About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA server. Positive - Please check named.logs on the server side to see if there are any complains about unsuccessful key negotiation with client. I raised named's log level to debug 10 and restarted Ran ipa-client-install again. The log shows many queries from the client, for A/AAA/SOA record types, both about the server and the client. All approved, no problem. The log does not seem to contain a single failure / rejection. However: 1) The client reports that response to SOA query was unsuccessful. The server log does not say anything about this. 2) The server log does not contain any update request Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* Interesting, this should not be related to time synchronization in any way. DNS server simply did not return any answer. -- Petr^2 Spacek -- 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
Re: [Freeipa-users] ipa-client-install failure
BTW, shouldn't named.conf contain an allow-update statement? Mine doesn't. Or is this managed differently? On 23 March 2015 at 12:16, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: On 23 March 2015 at 10:35, Petr Spacek pspa...@redhat.com wrote: On 23.3.2015 10:21, Roberto Cornacchia wrote: About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA server. Positive - Please check named.logs on the server side to see if there are any complains about unsuccessful key negotiation with client. I raised named's log level to debug 10 and restarted Ran ipa-client-install again. The log shows many queries from the client, for A/AAA/SOA record types, both about the server and the client. All approved, no problem. The log does not seem to contain a single failure / rejection. However: 1) The client reports that response to SOA query was unsuccessful. The server log does not say anything about this. 2) The server log does not contain any update request Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* Interesting, this should not be related to time synchronization in any way. DNS server simply did not return any answer. -- Petr^2 Spacek -- 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
Re: [Freeipa-users] ipa-client-install failure
On 23 March 2015 at 10:35, Petr Spacek pspa...@redhat.com wrote: On 23.3.2015 10:21, Roberto Cornacchia wrote: About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA server. Positive - Please check named.logs on the server side to see if there are any complains about unsuccessful key negotiation with client. I raised named's log level to debug 10 and restarted Ran ipa-client-install again. The log shows many queries from the client, for A/AAA/SOA record types, both about the server and the client. All approved, no problem. The log does not seem to contain a single failure / rejection. However: 1) The client reports that response to SOA query was unsuccessful. The server log does not say anything about this. 2) The server log does not contain any update request Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* Interesting, this should not be related to time synchronization in any way. DNS server simply did not return any answer. -- Petr^2 Spacek -- 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
Re: [Freeipa-users] ipa-client-install failure
OK, thanks. That would be Dynamic updates, right? Then it is enabled. $ ipa dnszone-show --all Zone name: hq.example.com dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com. SOA serial: 1427108043 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE Allow query: any; Allow transfer: none; Allow PTR sync: FALSE nsrecord: ipa.hq.example.com. objectclass: idnszone, top, idnsrecord On 23 March 2015 at 12:27, Martin Basti mba...@redhat.com wrote: On 23/03/15 12:19, Roberto Cornacchia wrote: BTW, shouldn't named.conf contain an allow-update statement? Mine doesn't. Or is this managed differently? It is not needed. bind-dyndb-ldap plugin overrides this configuration, you just need to enable updates in IPA zone setting. Martin On 23 March 2015 at 12:16, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: On 23 March 2015 at 10:35, Petr Spacek pspa...@redhat.com wrote: On 23.3.2015 10:21, Roberto Cornacchia wrote: About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA server. Positive - Please check named.logs on the server side to see if there are any complains about unsuccessful key negotiation with client. I raised named's log level to debug 10 and restarted Ran ipa-client-install again. The log shows many queries from the client, for A/AAA/SOA record types, both about the server and the client. All approved, no problem. The log does not seem to contain a single failure / rejection. However: 1) The client reports that response to SOA query was unsuccessful. The server log does not say anything about this. 2) The server log does not contain any update request Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* Interesting, this should not be related to time synchronization in any way. DNS server simply did not return any answer. -- Petr^2 Spacek -- 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 -- Martin Basti -- 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
Re: [Freeipa-users] ipa-client-install failure
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 timedate 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 ad...@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=117200(admin) gid=117200(admins) groups=117200(admins) On 22 March 2015 at 21:04, Jakub Hrozek jhro...@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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to
Re: [Freeipa-users] ipa-client-install failure
About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* On 23 March 2015 at 10:07, Roberto Cornacchia roberto.cornacc...@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 timedate 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 ad...@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=117200(admin) gid=117200(admins) groups=117200(admins) On 22 March 2015 at 21:04, Jakub Hrozek jhro...@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.
Re: [Freeipa-users] ipa-client-install failure
On 23.3.2015 10:21, Roberto Cornacchia wrote: About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA server. - Please check named.logs on the server side to see if there are any complains about unsuccessful key negotiation with client. Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* Interesting, this should not be related to time synchronization in any way. DNS server simply did not return any answer. -- Petr^2 Spacek -- 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
Re: [Freeipa-users] ipa-client-install failure
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. It seems SELinux can be ruled out as well. I switched to permissive mode and tried again, no difference. And so far I haven't been able to find anything useful in the logs. What strikes me is that these are really a plain and up to date FC21 machines, and my deployment was as from the book. The last of the settings you'd expect issues from. Can anyone (user or developer) confirm successful deployment of both server and client on up-to-date (updated this week) FC21 systems? I know it's maybe a bit far-fetched, but could any of the latest FC updates have created the issue? Roberto On 21 March 2015 at 17:26, Rob Crittenden rcrit...@redhat.com wrote: Roberto Cornacchia wrote: Hi Rob, Yes, sssd is running and this is sssd.conf: [domain/hq.example.com http://hq.example.com] debug_level=9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = hq.example.com http://hq.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = meson.hq.example.com chpass_provider = ipa ipa_server = _srv_, ipa.hq.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = hq.example.com [nss] homedir_substring = /home debug_level=9 [pam] [sudo] [autofs] [ssh] [pac] [ifp] Ok, that's good. Maybe authconfig didn't do the right thing. I'd add sss to these values in /etc/nsswitch.conf, grepp'd from mine: passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss automount: files sss sudoers:sss You've got quite a mix of odd things happening during install. It seems like DNS and firewall can be ruled out given that lots of other operations are working fine, and you've confirmed that NTP works pre-install. I guess working on a cleanish system, the things I'd look for on both client and server are the system logs to see if any errors are being thrown to syslog or service-specific logs. And I'd check for SELinux errors on the client if you're in enforcing mode. rob -- 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
Re: [Freeipa-users] ipa-client-install failure
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
Re: [Freeipa-users] ipa-client-install failure
On 03/22/2015 11:24 AM, 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. It seems SELinux can be ruled out as well. I switched to permissive mode and tried again, no difference. And so far I haven't been able to find anything useful in the logs. What strikes me is that these are really a plain and up to date FC21 machines, and my deployment was as from the book. The last of the settings you'd expect issues from. Can anyone (user or developer) confirm successful deployment of both server and client on up-to-date (updated this week) FC21 systems? I know it's maybe a bit far-fetched, but could any of the latest FC updates have created the issue? May be. To config nsswitch we call authconfig so may be there is something weird with it, can you check? Roberto On 21 March 2015 at 17:26, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Roberto Cornacchia wrote: Hi Rob, Yes, sssd is running and this is sssd.conf: [domain/hq.example.com http://hq.example.com http://hq.example.com] debug_level=9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = hq.example.com http://hq.example.com http://hq.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = meson.hq.example.com http://meson.hq.example.com chpass_provider = ipa ipa_server = _srv_, ipa.hq.example.com http://ipa.hq.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = hq.example.com http://hq.example.com [nss] homedir_substring = /home debug_level=9 [pam] [sudo] [autofs] [ssh] [pac] [ifp] Ok, that's good. Maybe authconfig didn't do the right thing. I'd add sss to these values in /etc/nsswitch.conf, grepp'd from mine: passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss automount: files sss sudoers:sss You've got quite a mix of odd things happening during install. It seems like DNS and firewall can be ruled out given that lots of other operations are working fine, and you've confirmed that NTP works pre-install. I guess working on a cleanish system, the things I'd look for on both client and server are the system logs to see if any errors are being thrown to syslog or service-specific logs. And I'd check for SELinux errors on the client if you're in enforcing mode. rob -- 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
Re: [Freeipa-users] ipa-client-install failure
Hi Rob, Yes, sssd is running and this is sssd.conf: [domain/hq.example.com] debug_level=9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = hq.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = meson.hq.example.com chpass_provider = ipa ipa_server = _srv_, ipa.hq.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = hq.example.com [nss] homedir_substring = /home debug_level=9 [pam] [sudo] [autofs] [ssh] [pac] [ifp] On 21 March 2015 at 17:05, Rob Crittenden rcrit...@redhat.com wrote: Roberto Cornacchia wrote: Indeed, id admin does not work and there is no sign of it in the log. From the client (with admin-tools installed): $ kinit admin Password for ad...@hq.example.com mailto:ad...@hq.example.com: $ ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 117200 GID: 117200 Account disabled: False Password: True Member of groups: trust admins, admins Kerberos keys available: True $ id admin id: admin: no such user $ getent passwd ad...@hq.spinque.com mailto:ad...@hq.spinque.com $ grep admin /var/log/sssd/* $ This is because sssd is not configured in nsswitch.conf to serve anything other than sudo. I see in the client install log you posted in the first message of the thread that there was no pre-existing sssd.conf so it created a new one, but that shouldn't be an issue. What does sssd.conf look like and is sssd running? rob On 21 March 2015 at 01:01, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/20/2015 07:40 PM, Roberto Cornacchia 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 Do the logs include an id call for admin? I do not see any instance of the word admin in the log. On 20 March 2015 at 23:03, Dmitri Pal d...@redhat.com mailto:d...@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 d...@redhat.com mailto:d...@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 ad...@hq.example.com mailto:ad...@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 641 0.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 640 0.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@hq.example.com mailto:ad...@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: ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:c...@hq.example.com, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com
Re: [Freeipa-users] ipa-client-install failure
Indeed, id admin does not work and there is no sign of it in the log. From the client (with admin-tools installed): $ kinit admin Password for ad...@hq.example.com: $ ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 117200 GID: 117200 Account disabled: False Password: True Member of groups: trust admins, admins Kerberos keys available: True $ id admin id: admin: no such user $ getent passwd ad...@hq.spinque.com $ grep admin /var/log/sssd/* $ On 21 March 2015 at 01:01, Dmitri Pal d...@redhat.com wrote: On 03/20/2015 07:40 PM, Roberto Cornacchia 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 Do the logs include an id call for admin? I do not see any instance of the word admin in the log. On 20 March 2015 at 23:03, Dmitri Pal d...@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 d...@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 $ ntpdate ipa.hq.example.com $ ldapsearch -x -h 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 ad...@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 6410.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 6400.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@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 krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com for krbtgt/hq.example@hq.example.com, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/ hq.example@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 d...@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 d...@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.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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
Re: [Freeipa-users] ipa-client-install failure
Roberto Cornacchia wrote: Indeed, id admin does not work and there is no sign of it in the log. From the client (with admin-tools installed): $ kinit admin Password for ad...@hq.example.com mailto:ad...@hq.example.com: $ ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 117200 GID: 117200 Account disabled: False Password: True Member of groups: trust admins, admins Kerberos keys available: True $ id admin id: admin: no such user $ getent passwd ad...@hq.spinque.com mailto:ad...@hq.spinque.com $ grep admin /var/log/sssd/* $ This is because sssd is not configured in nsswitch.conf to serve anything other than sudo. I see in the client install log you posted in the first message of the thread that there was no pre-existing sssd.conf so it created a new one, but that shouldn't be an issue. What does sssd.conf look like and is sssd running? rob On 21 March 2015 at 01:01, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/20/2015 07:40 PM, Roberto Cornacchia 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 Do the logs include an id call for admin? I do not see any instance of the word admin in the log. On 20 March 2015 at 23:03, Dmitri Pal d...@redhat.com mailto:d...@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 d...@redhat.com mailto:d...@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 ad...@hq.example.com mailto:ad...@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 641 0.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 640 0.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@hq.example.com mailto:ad...@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: ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:c...@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}, ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:hq.example@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
Re: [Freeipa-users] ipa-client-install failure
/etc/nsswitch.conf: passwd: files shadow: files group: files 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 netgroup: files publickey: nisplus automount: files aliases:files nisplus sudoers: files sss On 21 Mar 2015 01:06, Dmitri Pal d...@redhat.com wrote: 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.cornacc...@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.cornacc...@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 d...@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 d...@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 $ ntpdate ipa.hq.example.com $ ldapsearch -x -h 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 ad...@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 6410.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 6400.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@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 krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com for krbtgt/hq.example@hq.example.com, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/hq.example@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 d...@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 d...@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.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (hq.example.com), then I really get
Re: [Freeipa-users] ipa-client-install failure
It seems so: $ firewall-cmd --list-all FedoraServer (default, active) interfaces: em2 sources: services: cockpit dhcpv6-client ssh ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp 8011/tcp 53/udp 8082/tcp masquerade: no forward-ports: icmp-blocks: rich rules: On 20 March 2015 at 00:53, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: Yes. [root@meson ~]# cat /etc/resolv.conf search hq.example.com nameserver 192.168.0.72 Sorry from the short log I posted it's not visible, but that ip address is the address of the ipa server (ipa.hq.example.com) [root@meson ~]# dig ipa.hq.spinque.com ; DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 ipa.hq.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipa.hq.example.com. IN A ;; ANSWER SECTION: ipa.hq.example.com. 1200 IN A 192.168.0.72 ;; AUTHORITY SECTION: hq.example.com. 86400 IN NS ipa.hq.example.com. ;; Query time: 1 msec ;; SERVER: 192.168.0.72#53(192.168.0.72) ;; WHEN: do mrt 19 22:02:04 CET 2015 ;; MSG SIZE rcvd: 83 OK so you can in fact lookup the server. Have you opened all required ports for ldap and kerberos and other protocols in the firewall both UDP and TCP? On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain into hq.example.com), and in attachment, the full log with debug on. From the debug log, about the DNS update failure, I can see this: ; Communication with 192.168.0.72#53 failed: operation canceled could not reach any name server I'm not sure what communication problem this could be, as the server (which is both the IPA and the DNS servers), clearly can be reached. Any idea where to look at? Do you have the IPA DNS server in the resolv.conf of the client? Thanks, Roberto [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com 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... *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 ad...@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 *Unable to find 'admin' user with 'getent passwd ad...@hq.example.com ad...@hq.example.com'!* *Unable to reliably detect configuration. Check NSS setup manually.* NTP enabled Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Configuring
Re: [Freeipa-users] ipa-client-install failure
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.cornacc...@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 d...@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 d...@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 $ ntpdate ipa.hq.example.com $ ldapsearch -x -h 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 ad...@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 6410.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 6400.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@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 krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com for krbtgt/hq.example@hq.example.com, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/ hq.example@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 d...@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 d...@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.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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 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.cornacc...@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
Re: [Freeipa-users] ipa-client-install failure
On 03/20/2015 07:40 PM, Roberto Cornacchia 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 Do the logs include an id call for admin? I do not see any instance of the word admin in the log. On 20 March 2015 at 23:03, Dmitri Pal d...@redhat.com mailto:d...@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 d...@redhat.com mailto:d...@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 ad...@hq.example.com mailto:ad...@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 641 0.415 -0.006 0.000 LOCAL(0) .LOCL. 5 l- 6400.000 0.000 0.000 *But this does NOT work:* $ getent passwd ad...@hq.example.com mailto:ad...@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: ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:c...@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}, ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:hq.example@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 d...@redhat.com mailto:d...@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 d...@redhat.com mailto:d...@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.cornacc...@gmail.com
Re: [Freeipa-users] ipa-client-install failure
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.cornacc...@gmail.com mailto:roberto.cornacc...@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.cornacc...@gmail.com mailto:roberto.cornacc...@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 d...@redhat.com mailto:d...@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 d...@redhat.com mailto:d...@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 ad...@hq.example.com mailto:ad...@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 641 0.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 640 0.000 0.000 0.000 *But this does NOT work:* $ getent passwd ad...@hq.example.com mailto:ad...@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: ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:c...@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}, ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:hq.example@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 d...@redhat.com mailto:d...@redhat.com wrote: On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
Re: [Freeipa-users] ipa-client-install failure
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 On 21 March 2015 at 00:51, Roberto Cornacchia roberto.cornacc...@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.cornacc...@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 d...@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 d...@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 $ ntpdate ipa.hq.example.com $ ldapsearch -x -h 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 ad...@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 6410.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 6400.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@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 krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com for krbtgt/hq.example@hq.example.com, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/ hq.example@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 d...@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 d...@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.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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 And then it behaves precisely like the previous client. So something seems wrong in the server. On 20 March 2015 at 18:18,
Re: [Freeipa-users] ipa-client-install failure
The zone settings: $ ipa dnszone-show --all Zone name: hq.example.com. dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com. SOA serial: 1426857128 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE Allow query: any; Allow transfer: none; nsrecord: ipa.hq.example.com. objectclass: idnszone, top, idnsrecord The DNS log doesn't mention anything about updates. It does contain some errors about unreachable hosts, but that's because I had a temporary interruption towards the gateway from the ipa server. One thing I did after installing the IPA server is to turn off support for ipv6, using $ echo net.ipv6.conf.all.disable_ipv6 = 1 /etc/sysctl.conf $ sysctl -p Do you think it could have any influence? On 20 March 2015 at 12:31, Martin Basti mba...@redhat.com wrote: Hello, do you have enabled DNS dynamic updates for hq.example.zone? You can check it in zone settings. Are there any log entries in dns log related to nsupdate executed from a client? $ journalctl -b -u named-pkcs11 On 20/03/15 09:53, Roberto Cornacchia wrote: It seems so: $ firewall-cmd --list-all FedoraServer (default, active) interfaces: em2 sources: services: cockpit dhcpv6-client ssh ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp 8011/tcp 53/udp 8082/tcp masquerade: no forward-ports: icmp-blocks: rich rules: On 20 March 2015 at 00:53, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: Yes. [root@meson ~]# cat /etc/resolv.conf search hq.example.com nameserver 192.168.0.72 Sorry from the short log I posted it's not visible, but that ip address is the address of the ipa server (ipa.hq.example.com) [root@meson ~]# dig ipa.hq.example.com ; DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 ipa.hq.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipa.hq.example.com. IN A ;; ANSWER SECTION: ipa.hq.example.com. 1200 IN A 192.168.0.72 ;; AUTHORITY SECTION: hq.example.com. 86400 IN NS ipa.hq.example.com. ;; Query time: 1 msec ;; SERVER: 192.168.0.72#53(192.168.0.72) ;; WHEN: do mrt 19 22:02:04 CET 2015 ;; MSG SIZE rcvd: 83 OK so you can in fact lookup the server. Have you opened all required ports for ldap and kerberos and other protocols in the firewall both UDP and TCP? On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain into hq.example.com), and in attachment, the full log with debug on. From the debug log, about the DNS update failure, I can see this: ; Communication with 192.168.0.72#53 failed: operation canceled could not reach any name server I'm not sure what communication problem this could be, as the server (which is both the IPA and the DNS servers), clearly can be reached. Any idea where to look at? Do you have the IPA DNS server in the resolv.conf of the client? Thanks, Roberto [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com 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... *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 ad...@hq.example.com: Successfully retrieved CA
Re: [Freeipa-users] ipa-client-install failure
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.cornacc...@gmail.com mailto:roberto.cornacc...@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 d...@redhat.com mailto:d...@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.cornacc...@gmail.com mailto:roberto.cornacc...@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 ad...@hq.example.com mailto:ad...@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
Re: [Freeipa-users] ipa-client-install failure
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. On 20 March 2015 at 19:41, Dmitri Pal d...@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.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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 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.cornacc...@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 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... *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 ad...@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. 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 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 -- 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
Re: [Freeipa-users] ipa-client-install failure
But the ipa server itself is also enrolled as a client, just after the server installation, right?. And that worked fine. On 20 March 2015 at 18:55, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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 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.cornacc...@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 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... *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 ad...@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. 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 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 -- 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
Re: [Freeipa-users] ipa-client-install failure
On 03/20/2015 01:55 PM, Roberto Cornacchia 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. Does it really hit the right domain controller? Can it be that there is something else on the network that overshadows IPA server? Can you do everything correctly on the server itself? kinit, ipa commands? UI? On 20 Mar 2015 18:39, Dmitri Pal d...@redhat.com mailto:d...@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.cornacc...@gmail.com mailto:roberto.cornacc...@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 ad...@hq.example.com mailto:ad...@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
Re: [Freeipa-users] ipa-client-install failure
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 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.cornacc...@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 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... *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 ad...@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. 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 as NIS domain. Client configuration complete. -- 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
Re: [Freeipa-users] ipa-client-install failure
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.cornacc...@gmail.com mailto:roberto.cornacc...@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 ad...@hq.example.com mailto:ad...@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
Re: [Freeipa-users] ipa-client-install failure
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 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... *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 ad...@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. 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 as NIS domain. Client configuration complete. -- 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
Re: [Freeipa-users] ipa-client-install failure
No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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 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.cornacc...@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 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... *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 ad...@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. 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 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 -- 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
Re: [Freeipa-users] ipa-client-install failure
ipv6 re-enabled. No luck yet :( On 20 March 2015 at 17:06, Dmitri Pal d...@redhat.com wrote: On 03/20/2015 10:56 AM, Roberto Cornacchia wrote: The zone settings: $ ipa dnszone-show --all Zone name: hq.example.com. dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com. SOA serial: 1426857128 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE Allow query: any; Allow transfer: none; nsrecord: ipa.hq.example.com. objectclass: idnszone, top, idnsrecord The DNS log doesn't mention anything about updates. It does contain some errors about unreachable hosts, but that's because I had a temporary interruption towards the gateway from the ipa server. One thing I did after installing the IPA server is to turn off support for ipv6, using $ echo net.ipv6.conf.all.disable_ipv6 = 1 /etc/sysctl.conf $ sysctl -p Do you think it could have any influence? I think it can. I have a vague recollection of a bug related to that is some of the packages we depend on or something like. Can you try enabling it and see if it makes a difference? On 20 March 2015 at 12:31, Martin Basti mba...@redhat.com wrote: Hello, do you have enabled DNS dynamic updates for hq.example.zone? You can check it in zone settings. Are there any log entries in dns log related to nsupdate executed from a client? $ journalctl -b -u named-pkcs11 On 20/03/15 09:53, Roberto Cornacchia wrote: It seems so: $ firewall-cmd --list-all FedoraServer (default, active) interfaces: em2 sources: services: cockpit dhcpv6-client ssh ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp 8011/tcp 53/udp 8082/tcp masquerade: no forward-ports: icmp-blocks: rich rules: On 20 March 2015 at 00:53, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: Yes. [root@meson ~]# cat /etc/resolv.conf search hq.example.com nameserver 192.168.0.72 Sorry from the short log I posted it's not visible, but that ip address is the address of the ipa server (ipa.hq.example.com) [root@meson ~]# dig ipa.hq.example.com ; DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 ipa.hq.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipa.hq.example.com. IN A ;; ANSWER SECTION: ipa.hq.example.com. 1200 IN A 192.168.0.72 ;; AUTHORITY SECTION: hq.example.com. 86400 IN NS ipa.hq.example.com. ;; Query time: 1 msec ;; SERVER: 192.168.0.72#53(192.168.0.72) ;; WHEN: do mrt 19 22:02:04 CET 2015 ;; MSG SIZE rcvd: 83 OK so you can in fact lookup the server. Have you opened all required ports for ldap and kerberos and other protocols in the firewall both UDP and TCP? On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain into hq.example.com), and in attachment, the full log with debug on. From the debug log, about the DNS update failure, I can see this: ; Communication with 192.168.0.72#53 failed: operation canceled could not reach any name server I'm not sure what communication problem this could be, as the server (which is both the IPA and the DNS servers), clearly can be reached. Any idea where to look at? Do you have the IPA DNS server in the resolv.conf of the client? Thanks, Roberto [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com Discovery was successful! Hostname: meson.hq.example.com Realm: HQ.EXAMPLE.COM DNS Domain: hq.example.com IPA
Re: [Freeipa-users] ipa-client-install failure
On 03/20/2015 10:56 AM, Roberto Cornacchia wrote: The zone settings: $ ipa dnszone-show --all Zone name: hq.example.com http://hq.example.com. dn: idnsname=hq.example.com http://hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com http://hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com http://ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com http://hostmaster.hq.example.com. SOA serial: 1426857128 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM http://HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE Allow query: any; Allow transfer: none; nsrecord: ipa.hq.example.com http://ipa.hq.example.com. objectclass: idnszone, top, idnsrecord The DNS log doesn't mention anything about updates. It does contain some errors about unreachable hosts, but that's because I had a temporary interruption towards the gateway from the ipa server. One thing I did after installing the IPA server is to turn off support for ipv6, using $ echo net.ipv6.conf.all.disable_ipv6 = 1 /etc/sysctl.conf $ sysctl -p Do you think it could have any influence? I think it can. I have a vague recollection of a bug related to that is some of the packages we depend on or something like. Can you try enabling it and see if it makes a difference? On 20 March 2015 at 12:31, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: Hello, do you have enabled DNS dynamic updates for hq.example.zone? You can check it in zone settings. Are there any log entries in dns log related to nsupdate executed from a client? $ journalctl -b -u named-pkcs11 On 20/03/15 09:53, Roberto Cornacchia wrote: It seems so: $ firewall-cmd --list-all FedoraServer (default, active) interfaces: em2 sources: services: cockpit dhcpv6-client ssh ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp 8011/tcp 53/udp 8082/tcp masquerade: no forward-ports: icmp-blocks: rich rules: On 20 March 2015 at 00:53, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: Yes. [root@meson ~]# cat /etc/resolv.conf search hq.example.com http://hq.example.com nameserver 192.168.0.72 Sorry from the short log I posted it's not visible, but that ip address is the address of the ipa server (ipa.hq.example.com http://ipa.hq.example.com) [root@meson ~]# dig ipa.hq.example.com http://ipa.hq.example.com ; DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 ipa.hq.example.com http://ipa.hq.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipa.hq.example.com.INA ;; ANSWER SECTION: ipa.hq.example.com. 1200INA192.168.0.72 ;; AUTHORITY SECTION: hq.example.com.86400INNSipa.hq.example.com. ;; Query time: 1 msec ;; SERVER: 192.168.0.72#53(192.168.0.72) ;; WHEN: do mrt 19 22:02:04 CET 2015 ;; MSG SIZE rcvd: 83 OK so you can in fact lookup the server. Have you opened all required ports for ldap and kerberos and other protocols in the firewall both UDP and TCP? On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain
Re: [Freeipa-users] ipa-client-install failure
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 d...@redhat.com mailto:d...@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.cornacc...@gmail.com mailto:roberto.cornacc...@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 d...@redhat.com mailto:d...@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.cornacc...@gmail.com mailto:roberto.cornacc...@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 ad...@hq.example.com mailto:ad...@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'
Re: [Freeipa-users] ipa-client-install failure
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 $ ntpdate ipa.hq.example.com $ ldapsearch -x -h 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 ad...@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 6410.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 6400.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@hq.example.com *On the server, in /var/log/krb5kdc.log, I see many of these:* Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com for krbtgt/hq.example@hq.example.com, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/ hq.example@hq.example.com 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 d...@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 d...@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.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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 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.cornacc...@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 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... *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 ad...@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
Re: [Freeipa-users] ipa-client-install failure
SSSD logs are empty so far. Isn't sssd.conf written by ipa-client-install? If I raise the debug level after client installation, what activities do you suggest to attempt from the client? On 20 March 2015 at 22:37, Dmitri Pal d...@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 $ ntpdate ipa.hq.example.com $ ldapsearch -x -h 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 ad...@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 6410.415 -0.006 0.000 LOCAL(0).LOCL. 5 l- 6400.0000.000 0.000 *But this does NOT work:* $ getent passwd ad...@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 krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com for krbtgt/hq.example@hq.example.com, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/ hq.example@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 d...@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 d...@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.cornacc...@gmail.com wrote: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (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 d...@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 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.cornacc...@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 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... *Unable to sync time with IPA NTP server, assuming the time is in
Re: [Freeipa-users] ipa-client-install failure
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 d...@redhat.com mailto:d...@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 ad...@hq.example.com mailto:ad...@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 641 0.415 -0.006 0.000 LOCAL(0) .LOCL. 5 l- 6400.000 0.000 0.000 *But this does NOT work:* $ getent passwd ad...@hq.example.com mailto:ad...@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: ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:c...@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}, ad...@hq.example.com mailto:ad...@hq.example.com for krbtgt/hq.example@hq.example.com mailto:hq.example@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 d...@redhat.com mailto:d...@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 d...@redhat.com mailto:d...@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.cornacc...@gmail.com mailto:roberto.cornacc...@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 d...@redhat.com mailto:d...@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
Re: [Freeipa-users] ipa-client-install failure
On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: Yes. [root@meson ~]# cat /etc/resolv.conf search hq.example.com http://hq.example.com nameserver 192.168.0.72 Sorry from the short log I posted it's not visible, but that ip address is the address of the ipa server (ipa.hq.example.com http://ipa.hq.example.com) [root@meson ~]# dig ipa.hq.spinque.com http://ipa.hq.spinque.com ; DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 ipa.hq.example.com http://ipa.hq.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipa.hq.example.com.INA ;; ANSWER SECTION: ipa.hq.example.com. 1200INA192.168.0.72 ;; AUTHORITY SECTION: hq.example.com.86400INNSipa.hq.example.com. ;; Query time: 1 msec ;; SERVER: 192.168.0.72#53(192.168.0.72) ;; WHEN: do mrt 19 22:02:04 CET 2015 ;; MSG SIZE rcvd: 83 OK so you can in fact lookup the server. Have you opened all required ports for ldap and kerberos and other protocols in the firewall both UDP and TCP? On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain into hq.example.com http://hq.example.com), and in attachment, the full log with debug on. From the debug log, about the DNS update failure, I can see this: ; Communication with 192.168.0.72#53 failed: operation canceled could not reach any name server I'm not sure what communication problem this could be, as the server (which is both the IPA and the DNS servers), clearly can be reached. Any idea where to look at? Do you have the IPA DNS server in the resolv.conf of the client? Thanks, Roberto [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com http://meson.hq.example.com 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 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 ad...@hq.example.com mailto:ad...@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. 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/ipa/json' *Could not update DNS SSHFP records.* SSSD enabled Configured /etc/openldap/ldap.conf *Unable to find 'admin' user with 'getent passwd ad...@hq.example.com
Re: [Freeipa-users] ipa-client-install failure
On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain into hq.example.com http://hq.example.com), and in attachment, the full log with debug on. From the debug log, about the DNS update failure, I can see this: ; Communication with 192.168.0.72#53 failed: operation canceled could not reach any name server I'm not sure what communication problem this could be, as the server (which is both the IPA and the DNS servers), clearly can be reached. Any idea where to look at? Do you have the IPA DNS server in the resolv.conf of the client? Thanks, Roberto [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com http://meson.hq.example.com 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 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 ad...@hq.example.com mailto:ad...@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. 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/ipa/json' *Could not update DNS SSHFP records.* SSSD enabled Configured /etc/openldap/ldap.conf *Unable to find 'admin' user with 'getent passwd ad...@hq.example.com mailto:ad...@hq.example.com'!* *Unable to reliably detect configuration. Check NSS setup manually.* 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. -- 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
Re: [Freeipa-users] ipa-client-install failure
[root@meson ~]# dig ipa.hq.spinque.com humph, sorry about the confusion, I missed one in my anonymisation step.. that would be dig ipa.hq.example.com -- 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
Re: [Freeipa-users] ipa-client-install failure
Yes. [root@meson ~]# cat /etc/resolv.conf search hq.example.com nameserver 192.168.0.72 Sorry from the short log I posted it's not visible, but that ip address is the address of the ipa server (ipa.hq.example.com) [root@meson ~]# dig ipa.hq.spinque.com ; DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 ipa.hq.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipa.hq.example.com. IN A ;; ANSWER SECTION: ipa.hq.example.com. 1200 IN A 192.168.0.72 ;; AUTHORITY SECTION: hq.example.com. 86400 IN NS ipa.hq.example.com. ;; Query time: 1 msec ;; SERVER: 192.168.0.72#53(192.168.0.72) ;; WHEN: do mrt 19 22:02:04 CET 2015 ;; MSG SIZE rcvd: 83 On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain into hq.example.com), and in attachment, the full log with debug on. From the debug log, about the DNS update failure, I can see this: ; Communication with 192.168.0.72#53 failed: operation canceled could not reach any name server I'm not sure what communication problem this could be, as the server (which is both the IPA and the DNS servers), clearly can be reached. Any idea where to look at? Do you have the IPA DNS server in the resolv.conf of the client? Thanks, Roberto [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com 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... *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 ad...@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 *Unable to find 'admin' user with 'getent passwd ad...@hq.example.com ad...@hq.example.com'!* *Unable to reliably detect configuration. Check NSS setup manually.* NTP enabled Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Configuring hq.example.com as NIS domain. Client configuration complete. -- 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