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:
>> 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
>> - I do not get errors about LDAP users.
>> - I do not get errors about DNS update
>> - 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 '
>> 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 '
>> *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:
> Go to http://freeipa.org for more info on the project
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project