Description of problem: While debugging bug 1813136, I noticed that realmd seems to lock up when running "detect" against a Windows 2012 AD server (to which Stephen Gallagher granted me access). Version-Release number of selected component (if applicable): realmd-0.16.3-21.fc31.x86_64 How reproducible: Always Steps to Reproduce: 1. Set hostname/domain to match the remote AD domain hostnamectl set-hostname testhost.domain.name 2. Point /etc/resolv.conf to the DNS server of the Windows domain, so that auto-discovery works 3. Run `realm -v discover` This seems to work (output redacted for privacy reasons): # realm -v discover * Resolving: _ldap._tcp.[domain] * Performing LDAP DSE lookup on: [IPv6] * Performing LDAP DSE lookup on: [Ipv4] * Successfully discovered: [domain] type: kerberos realm-name: [DOMAIN] domain-name: [domain] configured: no server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common-tools Aside from that information, the journal just contains some extra messages: realmd[7329]: claimed name on bus: org.freedesktop.realmd realmd[7329]: client using service: :1.48 realmd[7329]: holding daemon: :1.48 realmd[7329]: Using 'r216.7326' operation for method 'Discover' invocation on 'org.freedesktop.realmd.Provider' interface realmd[7329]: Registered cancellable for operation 'r216.7326' realmd[7329]: * Resolving: [...] realmd[7329]: * Resolving: [...] realmd[7329]: * Performing LDAP DSE lookup on: [...] realmd[7329]: * Performing LDAP DSE lookup on: [...] realmd[7329]: * Performing LDAP DSE lookup on: [...] realmd[7329]: * Performing LDAP DSE lookup on: [...] realmd[7329]: Searching for (objectClass=*) realmd[7329]: Got defaultNamingContext: DC=[...] realmd[7329]: Sending TCP Netlogon request realmd[7329]: Received TCP Netlogon response realmd[7329]: * Successfully discovered: [domain] realmd[7329]: * Successfully discovered: [domain] realmd[7329]: client gone away: :1.48 realmd[7329]: released daemon: :1.48 4. Run the discover command again Actual results: discover commands hangs and eventually times out # realm -v discover realm: Couldn't load the realm service: Timeout was reached `systemctl stop realmd` also hangs: ● realmd.service - Realm and Domain Configuration Loaded: loaded (/usr/lib/systemd/system/realmd.service; static; vendor preset: disabled) Active: deactivating (stop-sigterm) since Fri 2020-03-27 03:18:03 EDT; 10s ago [...] systemd[1]: Stopping Realm and Domain Configuration... I have to kill -9 the realmd pid. Afterwards discovery works again. The lockup doesn't seem specific to the "discover" operation. This hangs as well: busctl introspect org.freedesktop.realmd /org/freedesktop/realmd Expected results: Daemon does not lock up after discover.
Confirmed on Fedora 32 with realmd-0.16.3-22.fc32.x86_64 I tested this against FreeIPA, and the bug does not happen with that.
Hi, thanks for the detailed report. About your test with FreeIPA, were there multiple different lines * Performing LDAP DSE lookup on: [IPv6] * Performing LDAP DSE lookup on: [Ipv4] e.g. with IPv6 and IPv4 addresses as well or was there only a single line? Is the AD DC reachable via IPv6 in your environment or only with IPv4? bye, Sumit
(In reply to Sumit Bose from comment #3) > About your test with FreeIPA, were there multiple different lines > > * Performing LDAP DSE lookup on: [IPv6] > * Performing LDAP DSE lookup on: [Ipv4] > > e.g. with IPv6 and IPv4 addresses as well or was there only a single line? My test VM only has IPv4 configured, so there is only a single line: # realm -v discover * Resolving: _ldap._tcp.cockpit.lan * Performing LDAP DSE lookup on: 10.111.112.100 * Successfully discovered: cockpit.lan cockpit.lan type: kerberos realm-name: COCKPIT.LAN domain-name: cockpit.lan configured: no server-software: ipa client-software: sssd required-package: freeipa-client required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd However, this is quite different network-wise: The FreeIPA server lives in a VM right next to my test VM (a single hop through the libvirt bridge), while Stephen's AD server goes through the Red Hat VPN to his machine. That could very well be related. > Is the AD DC reachable via IPv6 in your environment or only with IPv4? Only IPv4 is configured, IPv6 just has the fe80:: link-local addresses. Indeed the discovery shows me an IPv6 address as well ("Performing LDAP DSE lookup on: 26XX.."), and ping6'ing that address hangs. Could that be the reason for discover sometimes hanging even at the first attempt, when it's waiting for a reply from IPv6, even when it already got one on IPv4? I had a default route: default via fe80::2 dev eth0 proto ra metric 1024 expires 1413sec hoplimit 64 pref medium which NM apparently sets up. When I drop this with "ip -6 route del default", then the hang is gone \o/, and I can run "discover" multiple times. It now says * Performing LDAP DSE lookup on: 26xx:[..addresss] ! Can't contact LDAP server So maybe this is a NetworkManager bug after all (setting a default route for an IPv6LL address), but I suppose it shouldn't cause realmd to completely lock up? Thanks, great hint about IPv6!
(In reply to Martin Pitt from comment #4) ... > > So maybe this is a NetworkManager bug after all (setting a default route for > an IPv6LL address), but I suppose it shouldn't cause realmd to completely > lock up? > Hi, yes, I think I now have all details to reproduce it and I'll try to fix realmd. Thanks. bye, Sumit
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Hi, to reproduce this issue IPv6 is not needed, it is sufficient to drop all packet to one of the addresses returned by DNS even an IPv4 address. bye, Sumit
Fix: https://gitlab.freedesktop.org/realmd/realmd/-/commit/370bf84857d5674a092f46fa5932a0c92ad5bbf5
FEDORA-2021-c32332b9a4 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c32332b9a4
FEDORA-2021-c32332b9a4 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.