Re: [Freeipa-users] ipa-client-install failure

2015-03-24 Thread Roberto Cornacchia
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

2015-03-24 Thread Dmitri Pal

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

2015-03-24 Thread Roberto Cornacchia
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

2015-03-23 Thread Petr Spacek
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

2015-03-23 Thread Roberto Cornacchia
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

2015-03-23 Thread Roberto Cornacchia
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

2015-03-23 Thread Roberto Cornacchia
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

2015-03-23 Thread Roberto Cornacchia
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

2015-03-23 Thread Roberto Cornacchia
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

2015-03-23 Thread Roberto Cornacchia
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

2015-03-23 Thread Petr Spacek
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

2015-03-22 Thread Roberto Cornacchia
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

2015-03-22 Thread Jakub Hrozek
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

2015-03-22 Thread Dmitri Pal

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

2015-03-21 Thread Roberto Cornacchia
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

2015-03-21 Thread Roberto Cornacchia
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

2015-03-21 Thread Rob Crittenden
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

2015-03-21 Thread Roberto Cornacchia
/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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Dmitri Pal

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

2015-03-20 Thread Dmitri Pal

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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Dmitri Pal

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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Dmitri Pal

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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Dmitri Pal

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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Dmitri Pal

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

2015-03-20 Thread Dmitri Pal

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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Roberto Cornacchia
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

2015-03-20 Thread Dmitri Pal

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

2015-03-19 Thread Dmitri Pal

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

2015-03-19 Thread Dmitri Pal

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

2015-03-19 Thread Roberto Cornacchia

 [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

2015-03-19 Thread Roberto Cornacchia
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