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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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 <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 [email protected]
<mailto:[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]
<mailto:[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
<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:
[email protected] <mailto:[email protected]>
for krbtgt/[email protected]
<mailto:[email protected]>, 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}, [email protected]
<mailto:[email protected]> for
krbtgt/[email protected]
<mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[email protected]>> 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"
<[email protected]
<mailto:[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
<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
<[email protected]
<mailto:[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
<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
[email protected]
<mailto:[email protected]>:
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 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
