/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" <[email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]: >>>>> $ 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 64 1 0.415 -0.006 >>>>> 0.000 >>>>> LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 >>>>> 0.000 >>>>> >>>>> *But this does NOT work:* >>>>> $ getent passwd [email protected] >>>>> >>>>> >>>>> 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: >>>>> [email protected] for krbtgt/[email protected], >>>>> 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}, [email protected] for >>>>> krbtgt/[email protected] >>>>> >>>>> >>>>> 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 <[email protected]> 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 <[email protected]> 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 < >>>>>>> [email protected]> 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" <[email protected]> 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 < >>>>>>>>> [email protected]> 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 [email protected]: >>>>>>>>>> Successfully retrieved CA cert >>>>>>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>>>>>> >>>>>>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>>>>>> Created /etc/ipa/default.conf >>>>>>>>>> New SSSD config will be created >>>>>>>>>> Configured sudoers in /etc/nsswitch.conf >>>>>>>>>> Configured /etc/sssd/sssd.conf >>>>>>>>>> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM >>>>>>>>>> trying https://ipa.hq.example.com/ipa/json >>>>>>>>>> Forwarding 'ping' to json server ' >>>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>>> Forwarding 'ca_is_enabled' to json server ' >>>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>>> Systemwide CA database updated. >>>>>>>>>> Added CA certificates to the default NSS database. >>>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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
