2023-06-13 03:49:16

by Aram Akhavan

[permalink] [raw]
Subject: [PATCH 0/2] Mitigate startup race between DNS resolution and idmapd

idmapd needs DNS resolution on startup if a domain isn't specified by
config file. This isn't trivial since even with systemd's
network-online.target, DNS resolution isn't guaranteed. On Debian,
for example (in part due to some lingering bugs), adding the
target, and even enabling the not-well-documented
ifupdown-wait-online.service is not enough. These two patches aim to
improve the startup behavior in common setup scenarios.

Aram Akhavan (2):
nfs-idmapd.service: add network-online.target to Wants= and After=
libnfsidmap: try to get the domain directly from hostname if the DNS
lookup fails and always show the log message if the domain can't be
determined

support/nfsidmap/libnfsidmap.c | 15 ++++++++++-----
systemd/nfs-idmapd.service | 3 ++-
2 files changed, 12 insertions(+), 6 deletions(-)

--
2.39.2



2023-06-13 03:49:17

by Aram Akhavan

[permalink] [raw]
Subject: [PATCH 2/2] libnfsidmap: try to get the domain directly from hostname if the DNS lookup fails and always show the log message if the domain can't be determined

In nfs4_init_name_mapping(), if no domain is specified in the config file, the hostname will be looked up in DNS, and the domain extracted from that.
If DNS resolution isn't up at this time (i.e. on idmapd startup), the hardcoded domain in IDMAPD_DEFAULT_DOMAIN is used. This will break id mapping
for anyone who doesn't happen to use "localdomain". Previously, the log message indicating this has happened requires -v to be passed, so the
"failure" was silent by default.

Signed-off-by: Aram Akhavan <[email protected]>
---
support/nfsidmap/libnfsidmap.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/support/nfsidmap/libnfsidmap.c b/support/nfsidmap/libnfsidmap.c
index 0a912e52..f8c36480 100644
--- a/support/nfsidmap/libnfsidmap.c
+++ b/support/nfsidmap/libnfsidmap.c
@@ -219,10 +219,15 @@ static int domain_from_dns(char **domain)

if (gethostname(hname, sizeof(hname)) == -1)
return -1;
- if ((he = gethostbyname(hname)) == NULL)
- return -1;
- if ((c = strchr(he->h_name, '.')) == NULL || *++c == '\0')
- return -1;
+ if ((he = gethostbyname(hname)) == NULL) {
+ IDMAP_LOG(1, ("libnfsidmap: DNS lookup of hostname failed. Attempting to use domain from hostname as is."));
+ if ((c = strchr(hname, '.')) == NULL || *++c == '\0')
+ return -1;
+ }
+ else {
+ if ((c = strchr(he->h_name, '.')) == NULL || *++c == '\0')
+ return -1;
+ }
/*
* Query DNS to see if the _nfsv4idmapdomain TXT record exists
* If so use it...
@@ -387,7 +392,7 @@ int nfs4_init_name_mapping(char *conffile)
dflt = 1;
ret = domain_from_dns(&default_domain);
if (ret) {
- IDMAP_LOG(1, ("libnfsidmap: Unable to determine "
+ IDMAP_LOG(0, ("libnfsidmap: Unable to determine "
"the NFSv4 domain; Using '%s' as the NFSv4 domain "
"which means UIDs will be mapped to the 'Nobody-User' "
"user defined in %s",
--
2.39.2


2023-07-17 21:51:32

by Steve Dickson

[permalink] [raw]
Subject: Re: [PATCH 0/2] Mitigate startup race between DNS resolution and idmapd



On 6/12/23 11:46 PM, Aram Akhavan wrote:
> idmapd needs DNS resolution on startup if a domain isn't specified by
> config file. This isn't trivial since even with systemd's
> network-online.target, DNS resolution isn't guaranteed. On Debian,
> for example (in part due to some lingering bugs), adding the
> target, and even enabling the not-well-documented
> ifupdown-wait-online.service is not enough. These two patches aim to
> improve the startup behavior in common setup scenarios.
>
> Aram Akhavan (2):
> nfs-idmapd.service: add network-online.target to Wants= and After=
> libnfsidmap: try to get the domain directly from hostname if the DNS
> lookup fails and always show the log message if the domain can't be
> determined
>
> support/nfsidmap/libnfsidmap.c | 15 ++++++++++-----
> systemd/nfs-idmapd.service | 3 ++-
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
Both committed... (Tag nfs-utils-2-6-4-rc3)

steved