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...
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:
$
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
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
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:
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
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:
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
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
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:*
;;
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
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
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
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
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 =
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:
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
/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
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
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,
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
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
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
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
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.
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
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
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
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
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*
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
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
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
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:
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
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
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
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
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
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
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.
[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
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
43 matches
Mail list logo
