#8375 Client Ubuntu 20.04 do not send IP adress when enrolled
Opened 3 years ago by slamy. Modified 3 years ago

Request for enhancement

As admin, I want to enroll an Ubuntu 20.04 client so that it will be an IPA client.

Issue

IP address of the Ubuntu 20.04 client is not set in the IPA DNS zone

Steps to Reproduce

  1. Setup an IPA server (Centos 8)
  2. Launch ipa-client-install on ubuntu 20.04
  3. Check DNS records for the Ubuntu 20.04 client in the IPA DNS zone if IP address is added

Actual behavior

IP address is not set when enrolled

Expected behavior

IP address should be set when enrolled

Version/Release/Distribution

Server Centos 8:
ipa-server-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64
ipa-client-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64
389-ds-base-1.4.2.4-8.module_el8.2.0+366+71e3276f.x86_64
pki-ca-10.8.3-2.module_el8.2.0+371+f5726439.noarch
krb5-server-1.17-18.el8.x86_64

Client Ubuntu 20.04:
ii freeipa-client 4.8.6-1ubuntu2 amd64 FreeIPA centralized identity framework -- client
ii freeipa-common 4.8.6-1ubuntu2 all FreeIPA centralized identity framework -- common files
ii libipa-hbac0 2.2.3-3 amd64 FreeIPA HBAC Evaluator library
ii python3-ipaclient 4.8.6-1ubuntu2 all FreeIPA centralized identity framework -- Python3 modules for ipaclient
ii python3-ipalib 4.8.6-1ubuntu2 all FreeIPA centralized identity framework -- shared Python3 modules
ii python3-libipa-hbac 2.2.3-3 amd64 Python3 bindings for the FreeIPA HBAC Evaluator library
ii sssd-ipa 2.2.3-3 amd64 System Security Services Daemon -- IPA back end

Additional info:

My setup is working with Debian 10 client

My ipa-client-install command:
ipa-client-install \
--unattended \
--domain={{ ipa.domain }} \
--principal={{ ipa.join_principal }} \
--password="{{ ipa.join_password }}" \
--hostname={{ ipahostname }}.{{ ipa.domain }} \
--force-join \
--mkhomedir


Please attach your install log and information about your server. What the version and OS of your FreeIPA server and are you running with IPA DNS server or external DNS server?

Okay I've attached the 2 logs, server and ubuntu client:

ipaserver-install.log

ipaclient-install.log

Software version is already in my initial post:

Version/Release/Distribution

Server Centos 8:
ipa-server-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64
ipa-client-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64
389-ds-base-1.4.2.4-8.module_el8.2.0+366+71e3276f.x86_64
pki-ca-10.8.3-2.module_el8.2.0+371+f5726439.noarch
krb5-server-1.17-18.el8.x86_64

Client Ubuntu 20.04:
ii freeipa-client 4.8.6-1ubuntu2 amd64 FreeIPA centralized identity framework -- client
ii freeipa-common 4.8.6-1ubuntu2 all FreeIPA centralized identity framework -- common files
ii libipa-hbac0 2.2.3-3 amd64 FreeIPA HBAC Evaluator library
ii python3-ipaclient 4.8.6-1ubuntu2 all FreeIPA centralized identity framework -- Python3 modules for ipaclient
ii python3-ipalib 4.8.6-1ubuntu2 all FreeIPA centralized identity framework -- shared Python3 modules
ii python3-libipa-hbac 2.2.3-3 amd64 Python3 bindings for the FreeIPA HBAC Evaluator library
ii sssd-ipa 2.2.3-3 amd64 System Security Services Daemon -- IPA back end

Yes I use IPA DNS server like this:

ipa-server-install \
  --unattended \
  --domain={{ ipa.domain }} \
  --realm={{ ipa.domain|upper }} \
  --ip-address={{ ansible_default_ipv4.address }} \
  --ds-password={{ ipa.ds_password }} \
  --admin-password={{ ipa.admin_password }} \
  --setup-dns \
  --no-reverse \
  --forwarder={{ dns }} \
  --mkhomedir

It was already resolvable:

2020-06-18T13:51:36Z DEBUG found 1 A records for ubuntu2004.lin.test.lan.: 10.0.0.118

It looks like you have neither created the host with a IP address configuration nor passed --enable-dns-updates, --all-ip-addresses, or --ip-address to ipa-client-install. Could you please try again with --enable-dns-updates --all-ip-addresses?

OK I try to understand why Debian10 is working and not Ubuntu20.04 with automatic IP discovery. Of course it works when I force the ip-address in ipa-client-install.

Please read below, I do not set ip adress nor dns-update. More details on my setup:

My IPA domain is: lin.test.lan

I have a top DNS, DHCP with dnsmasq (IP 10.0.0.1) with this relevant configuration:

server=/lin.test.lan/10.0.0.179
dhcp-option=option:dns-server,10.0.0.1
dhcp-option=option:router,10.0.0.1
dhcp-host=ubuntu2004,52:54:00:84:77:8f,10.0.0.118
dhcp-host=freeipareplica,52:54:00:6b:5f:b1,10.0.0.151
dhcp-host=debian10,52:54:00:43:da:67,10.0.0.154
dhcp-host=freeipaserver,52:54:00:88:58:99,10.0.0.179

This dnsmasq is my forwarder for IPA

I delete these 2 hosts in IPA (debian10 and ubuntu2004). DNS information in IPA zone for theses 2 hosts are now absent.

Before enrollment I get this from dnsmasq:

Host ubuntu2004.lin.test.lan not found: 3(NXDOMAIN)
Host debian10.lin.test.lan not found: 3(NXDOMAIN)

Which is right because nor more hosts in IPA zone. Zone redirection is working fine.

At boot my 2 hosts get right network configuration from dnsmasq and the dnsmasq resolver in /etc/resolv.conf

# top DNS dnsmasq
nameserver 10.0.0.1

Then I launch ipa-client-install on clients (Debian and Ubuntu)

  ipa-client-install \
  --unattended \
  --domain={{ ipa.domain }} \
  --principal={{ ipa.join_principal }} \
  --password="{{ ipa.join_password }}" \
  --hostname={{ ipahostname }}.{{ ipa.domain }} \
  --force-join \
  --mkhomedir

That's the trick, when enrollment finished successfully I get my Debian10 IP address in the IPA dns zone but not for Ubuntu2004

So my question, why IPA discover and set the IP address of the Debian and not the Ubuntu?

debian10-ipaclient-install.log

ubuntu2004-ipaclient-install.log

On Ubuntu the installer detects that you have valid DNS entries for the host and therefore does not send nsupdate commands to the DNS server:

2020-06-19T10:01:46Z DEBUG found 1 A records for ubuntu2004.lin.test.lan.: 10.0.0.118
2020-06-19T10:01:46Z DEBUG found 1 AAAA records for ubuntu2004.lin.test.lan.: fe80::5054:ff:fe84:778f

OK but where does it come from? How to clean it to verify?

Host ubuntu2004.lin.test.lan not found: 3(NXDOMAIN)

Before ipa client install...

It's unclear to me what command prints the message and on which host you are executing the command. You need to provide more context so we are able to understand the issue.

ipa-client-install performs a DNS lookup for FQDN and A/AAAA records. It uses the local resolver configuration. Does Ubuntu run local DNS resolver or DNS cache like dnsmasq, mdns, systemd-resolver, or similar DNS services?

Yes, sorry. The command with NXDOMAIN result come from the host where dnsmasq is running, not the Ubuntu client.

You make me realize that Ubuntu uses ''systemd-resolved'' which acts like a local DNS cache.

Indeed, the Ubuntu host return:

ubuntu2004.lin.test.lan has address 10.0.0.118

Which causes ipa-client-install to avoid updating the IP address in IPA.

But, I am wondering if this is perfect? Because no other host in the IPA world will be able to communicate with this Ubuntu host.

Do you advise me to always force the "IP address" or "dns-updates" when enrolling a client?

No current option to bypass the local DNS caching when the client install?
I would certainly disable the systemd-resolved, if present, before enrolling with IPA...

Thank you, you've already helped me to understand this important step :)

I wonder if you can force a cache flush before running ipa-client-install, maybe that will help:

systemd-resolve --flush-caches

@rcritten nope! I tried but still resolved...

Ah, Ubuntu 20.04 already moved to systemd-resolved. Distributions with systemd-resolved are not yet supported by FreeIPA, see #8275 for a related issue. Your bug report is a useful to understand how installations with systemd-resolved behave differently.

Wild guess: Maybe systemd-resolved returns a positive answer for the host's own FQDN?

yes, systemd-resolved returns a positive hit for local FQDN. I guess that's breaking client installer logic:

# systemctl start systemd-resolved
# ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:2b:66:74 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    inet 10.0.138.132/22 brd 10.0.139.255 scope global dynamic noprefixroute eth0
       valid_lft 85517sec preferred_lft 85517sec
   ...
# hostnamectl set-hostname ipaserver.ipa.example
# dig @127.0.0.53 ipaserver.ipa.example

; <<>> DiG 9.11.20-RedHat-9.11.20-1.fc33 <<>> @127.0.0.53 ipaserver.ipa.example
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27719
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ipaserver.ipa.example.         IN      A

;; ANSWER SECTION:
ipaserver.ipa.example.  0       IN      A       10.0.138.132

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Jun 19 11:01:49 EDT 2020
;; MSG SIZE  rcvd: 66

Should we file a bug against systemd-resolve? I'm not sure if thats working as expected or not.

It looks like this is expected, from the man page:

SYNTHETIC RECORDS         

       systemd-resolved synthesizes DNS resource records (RRs) for the
       following cases:

       ·   The local, configured hostname is resolved to all locally
           configured IP addresses ordered by their scope, or — if none are
           configured — the IPv4 address 127.0.0.2 (which is on the local
           loopback) and the IPv6 address ::1 (which is the local host).

       ·   The hostnames "localhost" and "localhost.localdomain" (as well as
           any hostname ending in ".localhost" or ".localhost.localdomain")
           are resolved to the IP addresses 127.0.0.1 and ::1.

       ·   The hostname "_gateway" is resolved to all current default
           routing gateway addresses, ordered by their metric. This assigns
           a stable hostname to the current gateway, useful for referencing
           it independently of the current network configuration state.

       ·   The mappings defined in /etc/hosts are resolved to their
           configured addresses and back, but they will not affect lookups
           for non-address types (like MX). Support for /etc/hosts may be
           disabled with ReadEtcHosts=no, see resolved.conf(5).

Can you try adding ReadEtcHosts=no and try the installation again?

We may need to disable this during installation and then re-enable it afterward.

I assume a service restart will be needed when touching the config file.

Hi,

I am here, don't really understand what happens...

On the client I run:

moi@ubuntu2004:~$ dig +short ubuntu2004.lin.test.lan
moi@ubuntu2004:~$ dig @10.0.0.1 +short ubuntu2004.lin.test.lan
moi@ubuntu2004:~$ dig @10.0.0.179 +short ubuntu2004.lin.test.lan

First command default DNS server is systemd-resolved, no response
Second command DNS server is my top dnsmasq, no response
Last command DNS server is IPA server, no response

But after running ipa-client-install I get in the LOG:

2020-07-03T12:42:33Z DEBUG found session_cookie in persistent storage for principal 'host/ubuntu2004.lin.test.lan@LIN.TEST.LAN', cookie: 'ipa_session=MagBearerToken=5mZCV%2bIfhkCHxGHd9Pf4jtv%2fCjYDEAvqSqRFt2EGbaiWq6QTQ3gIFt9QEZyA26Ak8zqIX4k8IVHw8qz%2fPqvPKNgMZvUcYh%2fv5QPw1OIbtJf2LfHSiQMybaJi5jOMw1E7ggqda%2fyHGtvpws2C93hmHXQYZRcuZ6LNr0EYIMAGZ2rdup8uq91Vf%2fSzjCNkT%2bGGYYmIYnYg9txXEqOjuNadEsmog2Gr%2fjYlL2qFBlNTg%2f4WVp0m2TfBOjw3MGwbw%2bD1GGQzRcnrZOiCtv%2fEtDub8QsgW8p%2fWkoHgsg56gwdvcQ%3d'
2020-07-03T12:42:34Z DEBUG found 1 A records for ubuntu2004.lin.test.lan.: 10.0.0.118
2020-07-03T12:42:34Z DEBUG found 1 AAAA records for ubuntu2004.lin.test.lan.: fe80::5054:ff:fe84:778f

Is the session cookie responsible for the DNS response? I don't know but I doubt.

@rcritten I tried what you said with exact same result... the ReadEtcHosts=no change nothing on it...

The way to go for now is to add --enable-dns-updates, if you can

Thanks guys for the good work on IPA, we love it!

To replicate what the installer is doing:

import dns.resolver
import socket

fqdn = socket.getfqdn()

try:
    for rdtype in ['A', 'AAAA']:
        answer = dns.resolver.query(fqdn, rdtype)
        print('found %d %s records for %s: %s' % (
         len(answer),
         rdtype,
         fqdn,
         ' '.join(str(rr) for rr in answer)))
except dns.resolver.NoAnswer as ex:
    print('%s' % ex)

I'm not sure how enlightening this will be but it is closer to what is going on in the client during install. If you're up for it if you add a pdb before the dns.resolver.query() and step through dns.resolver.query() you'll be able to see better where it's getting that data. For example, it could be cached. I think you'll also be able to see the nameserver being used which could be handy to know.

The session cookie comes from the IPA web server and is unrelated to DNS.

It looks like this is expected, from the man page:

Sort of!

The local, configured hostname is resolved to all locally configured IP addresses

In practice, this refers only to the first label of a multi-label hostname.

My system (being joined to an IPA domain) has myhost.ipa.domain.example set in /proc/sys/kernel/hostname, but I still observe DNS queries going over the wire when I run resolvectl query myhost.ipa.domain.example.

If I run resolvectl query myhost then I see nothing going over the wire, even though myhost is nothing special--it's not "the locally configured hostname"!

IMO this behaviour doesn't match what is documented, at least the documentation needs to be clearer.

The mappings defined in /etc/hosts are resolved to their configured addresses and back, but they will not affect lookups for non-address types (like MX). Support for /etc/hosts may be disabled with ReadEtcHosts=no, see resolved.conf(5).

If I create an entry for myhost.ipa.domain.example in /etc/hosts then resolvectl query myhost.ipa.domain.example does not result in resolved querying its configured DNS servers.

So disabling ReadEtcHosts= during installation will likely work as long as resolved's continues to only synthesize records for the first label of a multi-label hostname.

OTOH, I think you have a good use case for a systemd-resolved RFE: an API to query only the upstream configured DNS servers, bypassing any caching, synthesized records or other protocols (not that LLMNR or mDNS are strictly relevant here, but anyway...)

I suppose this RFE already sort-of exists: you can perform DNS queries against the servers listed in /run/systemd/resolve/resolv.conf to bypass systemd-resolved entirely.

@yrro and how does one do the query by bypassing systemd-resolved using standard tools?

The installer could do it in Python:

r = dns.resolver.Resolver('/run/systemd/resolve/resolv.conf')
answer = r.query(hostname)

with 'standard' tools you have to pull the nameserver lines out of that file yourself and pass one to dig/host/nslookup etc.

Login to comment on this ticket.

Metadata
Attachments 4