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