I have a customer that requested the domain used
to do the ID mapping be available via DNS SVR
record. I didn't think was that bad of an idea.
IPA and FedFS use SRV records which seem to work out
pretty well. This patch is heavily based on the
FedFS code. ;-)
My only question is do we want libnfsidmap to be
dependent on the resolver library. There has been
some talk about moving libnfsidmap into nfs-utils
which means nfs-utils would be dependent the
resolver library.
Note, this is not complete. If we are going to do
this I have to document it somehow, either in
the man page or idmap.conf or both.
Just looking for thoughts... good/bad idea??
Steve Dickson (1):
libnfsidmap: Query DNS for the NFSv4 ID domain
configure.ac | 1 +
libnfsidmap.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 89 insertions(+), 1 deletion(-)
--
2.5.0
When a DNS domain is found in nfs4_init_name_mapping()
query the DNS for the _nfsv4-iddomainname.tcp SRV record.
When the record exists, use that as the v4 id domain.
Signed-off-by: Steve Dickson <[email protected]>
---
configure.ac | 1 +
libnfsidmap.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 89 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 5944166..52e12c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,6 +13,7 @@ LT_INIT
AC_PROG_CC
# Checks for libraries.
+AC_CHECK_LIB([resolv], [res_querydomain])
AC_ARG_ENABLE([ldap],
[AS_HELP_STRING([--disable-ldap],[Disable support for LDAP @<:@default=detect@:>@])])
diff --git a/libnfsidmap.c b/libnfsidmap.c
index a8a9229..84b5ea8 100644
--- a/libnfsidmap.c
+++ b/libnfsidmap.c
@@ -53,6 +53,10 @@
#include <stdarg.h>
#include <dlfcn.h>
#include <ctype.h>
+#include <resolv.h>
+#include <arpa/nameser.h>
+#include <arpa/nameser_compat.h>
+
#include "nfsidmap.h"
#include "nfsidmap_internal.h"
#include "cfg.h"
@@ -79,6 +83,10 @@ gid_t nobody_gid = (gid_t)-1;
#define IDMAPD_DEFAULT_DOMAIN "localdomain"
#endif
+#ifndef IDMAPD_DEFAULT_SRVNAME
+#define IDMAPD_DEFAULT_SRVNAME "_nfsv4-iddomainname.tcp"
+#endif
+
/* Default logging fuction */
static void default_logger(const char *fmt, ...)
{
@@ -129,6 +137,76 @@ static int domain_from_dns(char **domain)
return 0;
}
+static char *
+iddomain_from_dns(char *domain)
+{
+ int len, l;
+ unsigned char *msg, *eom, *comp_dn;
+ char *exp_dn, *iddomain = NULL;
+ const char *srvname = IDMAPD_DEFAULT_SRVNAME;
+ unsigned short count;
+ HEADER *hdr;
+
+ if ((msg = calloc(1, NS_MAXMSG)) == NULL) {
+ IDMAP_LOG(1, ("iddomain_from_dns: calloc(msg) failed: %m\n"));
+ return NULL;
+ }
+ if ((exp_dn = calloc(1, NS_MAXDNAME)) == NULL) {
+ IDMAP_LOG(1, ("iddomain_from_dns: calloc(exp_dn) failed: %m\n"));
+ free(msg);
+ return NULL;
+ }
+ len = res_querydomain(srvname, domain, C_IN, T_SRV, msg, NS_MAXMSG);
+ if (len < 0) {
+ IDMAP_LOG(1, ("SRV query failed for %s.%s: %s\n",
+ srvname, domain, hstrerror(h_errno)));
+ goto free_mem;
+ }
+
+ hdr = (HEADER *)msg;
+ /* answer count */
+ count = ntohs(hdr->ancount);
+
+ /* Note: if more than one answer is returned, only
+ * the first answer will be processed
+ */
+ if (count < 1) {
+ IDMAP_LOG(1, ("No SRV record returned for %s\n", srvname));
+ goto free_mem;
+ }
+
+ /* find the EOM */
+ eom = msg + len;
+ /* skip header */
+ comp_dn = &msg[HFIXEDSZ];
+ /* skip question header */
+ comp_dn += dn_skipname(comp_dn, eom) + QFIXEDSZ;
+
+ /* read in the question */
+ l = dn_expand(msg, eom, comp_dn, exp_dn, NS_MAXDNAME);
+ if (l < 0) {
+ IDMAP_LOG(1, ("dn_expand(que) failed for %s.%s: %s\n",
+ srvname, default_domain, hstrerror(h_errno)));
+ goto free_mem;
+ }
+
+ /* skip to the answer and read it in */
+ comp_dn += 18;
+ l = dn_expand(msg, eom, comp_dn, exp_dn, NS_MAXDNAME);
+ if (l < 0) {
+ IDMAP_LOG(1, ("dn_expand(ans) failed for %s.%s: %s\n",
+ srvname, default_domain, hstrerror(h_errno)));
+ goto free_mem;
+ }
+ iddomain = strdup(exp_dn);
+
+free_mem:
+ free(msg);
+ free(exp_dn);
+
+ return (iddomain);
+}
+
static int load_translation_plugin(char *method, struct mapping_plugin *plgn)
{
void *dl = NULL;
@@ -233,7 +311,7 @@ int nfs4_init_name_mapping(char *conffile)
int ret = -ENOENT;
int dflt = 0;
struct conf_list *nfs4_methods, *gss_methods;
- char *nobody_user, *nobody_group;
+ char *nobody_user, *nobody_group, *iddomain;
/* XXX: need to be able to reload configurations... */
if (nfs4_plugins) /* already succesfully initialized */
@@ -254,6 +332,15 @@ int nfs4_init_name_mapping(char *conffile)
"user defined in %s\n",
IDMAPD_DEFAULT_DOMAIN, PATH_IDMAPDCONF));
default_domain = IDMAPD_DEFAULT_DOMAIN;
+ } else {
+ /* Since a DNS domain does exist, see if the
+ * idmap domain exists in DNS
+ */
+ iddomain = iddomain_from_dns(default_domain);
+ if (iddomain != NULL) {
+ free(default_domain);
+ default_domain = iddomain;
+ }
}
}
IDMAP_LOG(1, ("libnfsidmap: using%s domain: %s",
--
2.5.0
> On May 23, 2016, at 12:18 PM, Steve Dickson <[email protected]> wrote:
>
> I have a customer that requested the domain used
> to do the ID mapping be available via DNS SVR
> record. I didn't think was that bad of an idea.
Solaris NFS peers look for a TXT record. This
facility has been around for a decade or more.
;; NFSv4 domain (for idmapping). See Sun doc 819-1634 and
;; http://tools.ietf.org/html/draft-mesta-nfsv4-domain-01.html
_nfsv4idmapdomain IN TXT "oracle.com"
But there's no standard in this area. mesta-nfsv4-domain
was a personal I-D that never advanced. I brought it
up again in Orlando, and the WG decided to table it.
At the time it was decided that the right course of
action was for the NFSv4 idmapping domain to be set
based on security realm or other criteria. There was
no interest in involving DNS at all.
> IPA and FedFS use SRV records which seem to work out
> pretty well. This patch is heavily based on the
> FedFS code. ;-)
>
> My only question is do we want libnfsidmap to be
> dependent on the resolver library. There has been
> some talk about moving libnfsidmap into nfs-utils
> which means nfs-utils would be dependent the
> resolver library.
>
> Note, this is not complete. If we are going to do
> this I have to document it somehow, either in
> the man page or idmap.conf or both.
>
> Just looking for thoughts... good/bad idea??
If you really do want to go down this path, I
think Linux should follow the existing de facto
standard (TXT), not invent its own. Maybe also
check how SMB does this.
Involving a published DNS record format should
require standards action. But I was discouraged
from pursuing this further.
I think it's important to ask in what cases
will the ID mapping domain be different than
the system's DNS domain name, and is there a
preferable mechanism for determining the ID
mapping domain in those cases? Knowing more
about how your customer plans to use this
feature would help us discuss this more fully.
I've also proposed the ability to set the ID
mapping domain via a command line tool like
nfsidmap. But I never got past the difficulties
of parsing and updating the /etc/idmapd.conf
file. It makes sense to add an API to libnfsidmap
for setting the system's ID mapping domain name.
How would "nfsidmap -d" work if the ID mapping
domain was set via DNS?
Would the DNS-derived ID domain name be cached
somewhere?
> Steve Dickson (1):
> libnfsidmap: Query DNS for the NFSv4 ID domain
>
> configure.ac | 1 +
> libnfsidmap.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 89 insertions(+), 1 deletion(-)
>
> --
> 2.5.0
--
Chuck Lever
Hello,
On 05/23/2016 01:22 PM, Chuck Lever wrote:
>
>> On May 23, 2016, at 12:18 PM, Steve Dickson <[email protected]> wrote:
>>
>> I have a customer that requested the domain used
>> to do the ID mapping be available via DNS SVR
>> record. I didn't think was that bad of an idea.
>
> Solaris NFS peers look for a TXT record. This
> facility has been around for a decade or more.
>
> ;; NFSv4 domain (for idmapping). See Sun doc 819-1634 and
> ;; http://tools.ietf.org/html/draft-mesta-nfsv4-domain-01.html
> _nfsv4idmapdomain IN TXT "oracle.com"
I see... Looks reasonable
>
> But there's no standard in this area. mesta-nfsv4-domain
> was a personal I-D that never advanced. I brought it
> up again in Orlando, and the WG decided to table it.
>
> At the time it was decided that the right course of
> action was for the NFSv4 idmapping domain to be set
> based on security realm or other criteria. There was
> no interest in involving DNS at all.
Hmm... it seems pretty convenient to me... although
its just another place for rpc.idmap to get hung. ;-)
>
>
>> IPA and FedFS use SRV records which seem to work out
>> pretty well. This patch is heavily based on the
>> FedFS code. ;-)
>>
>> My only question is do we want libnfsidmap to be
>> dependent on the resolver library. There has been
>> some talk about moving libnfsidmap into nfs-utils
>> which means nfs-utils would be dependent the
>> resolver library.
>>
>> Note, this is not complete. If we are going to do
>> this I have to document it somehow, either in
>> the man page or idmap.conf or both.
>>
>> Just looking for thoughts... good/bad idea??
>
> If you really do want to go down this path, I
> think Linux should follow the existing de facto
> standard (TXT), not invent its own. Maybe also
> check how SMB does this.
I think I will and I agree using a TXT RR is
the way to go... Why reinvent the wheel?? 8-)
>
> Involving a published DNS record format should
> require standards action. But I was discouraged
> from pursuing this further.
I think if everybody is doing the same thing
would be good enough...
>
> I think it's important to ask in what cases
> will the ID mapping domain be different than
> the system's DNS domain name, and is there a
> preferable mechanism for determining the ID
> mapping domain in those cases? Knowing more
> about how your customer plans to use this
> feature would help us discuss this more fully.
This would help me here at Red Hat. I live
on at (eat your own dog food) test network
that has its own DNS
So [email protected] maps into a valid id/gid but
[email protected] does not so I need to add a
Domain=redhat.com in /etc/idmapd.conf to get
v4 working. Having the domain in our test DNS
would work out well.
Also, the person that is asking for this is
probably moving from a Solaris env to Linx
env... That's just a guess.
>
> I've also proposed the ability to set the ID
> mapping domain via a command line tool like
> nfsidmap. But I never got past the difficulties
> of parsing and updating the /etc/idmapd.conf
> file. It makes sense to add an API to libnfsidmap
> for setting the system's ID mapping domain name.
Does having the domain in DNS help with this? I'm
thinking not...
>
> How would "nfsidmap -d" work if the ID mapping
> domain was set via DNS?
I guess we would have to teach nfs4_get_default_domain()
to check DNS like nfs4_init_name_mapping() would.
>
> Would the DNS-derived ID domain name be cached
> somewhere?
Currently its stored in the global default_domain
variable in libnfsidmap... I think its a good
place for it to live.
steved.
> On May 24, 2016, at 12:02 PM, Steve Dickson <[email protected]> wrote:
>
> Hello,
>
> On 05/23/2016 01:22 PM, Chuck Lever wrote:
>>
>>> On May 23, 2016, at 12:18 PM, Steve Dickson <[email protected]> wrote:
>>>
>>> I have a customer that requested the domain used
>>> to do the ID mapping be available via DNS SVR
>>> record. I didn't think was that bad of an idea.
>>
>> Solaris NFS peers look for a TXT record. This
>> facility has been around for a decade or more.
>>
>> ;; NFSv4 domain (for idmapping). See Sun doc 819-1634 and
>> ;; http://tools.ietf.org/html/draft-mesta-nfsv4-domain-01.html
>> _nfsv4idmapdomain IN TXT "oracle.com"
> I see... Looks reasonable
>
>>
>> But there's no standard in this area. mesta-nfsv4-domain
>> was a personal I-D that never advanced. I brought it
>> up again in Orlando, and the WG decided to table it.
>>
>> At the time it was decided that the right course of
>> action was for the NFSv4 idmapping domain to be set
>> based on security realm or other criteria. There was
>> no interest in involving DNS at all.
> Hmm... it seems pretty convenient to me... although
> its just another place for rpc.idmap to get hung. ;-)
Right, see below for a way to prevent that.
>>> IPA and FedFS use SRV records which seem to work out
>>> pretty well. This patch is heavily based on the
>>> FedFS code. ;-)
>>>
>>> My only question is do we want libnfsidmap to be
>>> dependent on the resolver library. There has been
>>> some talk about moving libnfsidmap into nfs-utils
>>> which means nfs-utils would be dependent the
>>> resolver library.
>>>
>>> Note, this is not complete. If we are going to do
>>> this I have to document it somehow, either in
>>> the man page or idmap.conf or both.
>>>
>>> Just looking for thoughts... good/bad idea??
>>
>> If you really do want to go down this path, I
>> think Linux should follow the existing de facto
>> standard (TXT), not invent its own. Maybe also
>> check how SMB does this.
> I think I will and I agree using a TXT RR is
> the way to go... Why reinvent the wheel?? 8-)
>
>>
>> Involving a published DNS record format should
>> require standards action. But I was discouraged
>> from pursuing this further.
> I think if everybody is doing the same thing
> would be good enough...
>
>>
>> I think it's important to ask in what cases
>> will the ID mapping domain be different than
>> the system's DNS domain name, and is there a
>> preferable mechanism for determining the ID
>> mapping domain in those cases? Knowing more
>> about how your customer plans to use this
>> feature would help us discuss this more fully.
> This would help me here at Red Hat. I live
> on at (eat your own dog food) test network
> that has its own DNS
>
> So [email protected] maps into a valid id/gid but
> [email protected] does not so I need to add a
> Domain=redhat.com in /etc/idmapd.conf to get
> v4 working. Having the domain in our test DNS
> would work out well.
So your security realm is redhat.com. Any way
to discover that fact, either at system install
time, or after every boot, or ... ?
I think the ID mapping domain name only matters
when you are using Kerberos? sec=sys should use
only stringified UIDs.
> Also, the person that is asking for this is
> probably moving from a Solaris env to Linx
> env... That's just a guess.
>
>>
>> I've also proposed the ability to set the ID
>> mapping domain via a command line tool like
>> nfsidmap. But I never got past the difficulties
>> of parsing and updating the /etc/idmapd.conf
>> file. It makes sense to add an API to libnfsidmap
>> for setting the system's ID mapping domain name.
> Does having the domain in DNS help with this? I'm
> thinking not...
>
>>
>> How would "nfsidmap -d" work if the ID mapping
>> domain was set via DNS?
> I guess we would have to teach nfs4_get_default_domain()
> to check DNS like nfs4_init_name_mapping() would.
Or both functions could use common infrastructure
or a cached value.
>> Would the DNS-derived ID domain name be cached
>> somewhere?
> Currently its stored in the global default_domain
> variable in libnfsidmap... I think its a good
> place for it to live.
That means every time an application loads
libnfsidmap, it has to retrieve the ID mapping
domain from DNS again?
What if you built a small tool that just set
the Domain value in /etc/idmapd.conf during
system startup?
$ nfsidmap --txt
could retrieve it and display it,
# nfsidmap --txt -s
could retrieve it and update idmapd.conf if
there was a TXT record retrieved, for example.
Then the rest of the infrastructure would not
have to change. Just a thought!
--
Chuck Lever
On 05/24/2016 12:20 PM, Chuck Lever wrote:
>
>
> So your security realm is redhat.com. Any way
> to discover that fact, either at system install
> time, or after every boot, or ... ?
Yea... put it DNS ;-) But I think the answer
is no... at least I don't know of a way.
>
> I think the ID mapping domain name only matters
> when you are using Kerberos? sec=sys should use
> only stringified UIDs.
Netapp filers still use name@domain strings and
probably Solaris servers... I think only Linux
use the stringified UIDs.
>>>
>>> How would "nfsidmap -d" work if the ID mapping
>>> domain was set via DNS?
>> I guess we would have to teach nfs4_get_default_domain()
>> to check DNS like nfs4_init_name_mapping() would.
>
> Or both functions could use common infrastructure
> or a cached value.
Yeah.. we could make domain_from_dns() a bit smarter...
>
>
>>> Would the DNS-derived ID domain name be cached
>>> somewhere?
>> Currently its stored in the global default_domain
>> variable in libnfsidmap... I think its a good
>> place for it to live.
>
> That means every time an application loads
> libnfsidmap, it has to retrieve the ID mapping
> domain from DNS again?
Yeah... which I didn't think it was a big deal with
rpc.idmap since its only started once... but
maybe that's not the best solution for every
nfsidmap upcall, although the uid/gids are cached
maybe its not so bad.
>
> What if you built a small tool that just set
> the Domain value in /etc/idmapd.conf during
> system startup?
I would hate to change something an admin has set.
I'm thinking if Domain is set in /etc/idmapd.conf
that override everything, including DNS.
>
> $ nfsidmap --txt
>
> could retrieve it and display it,
>
> # nfsidmap --txt -s
>
> could retrieve it and update idmapd.conf if
> there was a TXT record retrieved, for example.
I see what you are trying to do here... instead
of rewriting idmapd.conf... we should probably
uses... the system that shall go nameless... systemd! ;-)
systemd could run the nfsidmap --txt command that would
create a file under /run, which is managed by the
systemd-tmpfiles package. rpcbind does something similar
to manage its warmstart up files.
Then we could point rpc.idmap and nfsidmap to that
runtime file via the libnfsidmap interfaces.
The problem with this is how do we expire this cache?
We would have to store the TTL to know when its time
to ping DNS again... Is the TTL returned in the DNS
query?
>
> Then the rest of the infrastructure would not
> have to change. Just a thought!
yeah we probably should cache but it does add
a lot of complexity... Doesn't DNS cache things
internally? If so, would using that cache work?
steved.
> On May 24, 2016, at 1:43 PM, Steve Dickson <[email protected]> wrote:
>
>
>
> On 05/24/2016 12:20 PM, Chuck Lever wrote:
>>
>>
>> So your security realm is redhat.com. Any way
>> to discover that fact, either at system install
>> time, or after every boot, or ... ?
> Yea... put it DNS ;-) But I think the answer
> is no... at least I don't know of a way.
>
>>
>> I think the ID mapping domain name only matters
>> when you are using Kerberos? sec=sys should use
>> only stringified UIDs.
> Netapp filers still use name@domain strings and
> probably Solaris servers... I think only Linux
> use the stringified UIDs.
I'm pretty sure recent Solaris servers will behave
like Linux. But there's plenty of S10 out there.
>>>> How would "nfsidmap -d" work if the ID mapping
>>>> domain was set via DNS?
>>> I guess we would have to teach nfs4_get_default_domain()
>>> to check DNS like nfs4_init_name_mapping() would.
>>
>> Or both functions could use common infrastructure
>> or a cached value.
> Yeah.. we could make domain_from_dns() a bit smarter...
>
>>
>>
>>>> Would the DNS-derived ID domain name be cached
>>>> somewhere?
>>> Currently its stored in the global default_domain
>>> variable in libnfsidmap... I think its a good
>>> place for it to live.
>>
>> That means every time an application loads
>> libnfsidmap, it has to retrieve the ID mapping
>> domain from DNS again?
> Yeah... which I didn't think it was a big deal with
> rpc.idmap since its only started once... but
> maybe that's not the best solution for every
> nfsidmap upcall, although the uid/gids are cached
> maybe its not so bad.
>
>>
>> What if you built a small tool that just set
>> the Domain value in /etc/idmapd.conf during
>> system startup?
> I would hate to change something an admin has set.
> I'm thinking if Domain is set in /etc/idmapd.conf
> that override everything, including DNS.
Fair enough, there should be a way to override
the TXT value.
>> $ nfsidmap --txt
>>
>> could retrieve it and display it,
>>
>> # nfsidmap --txt -s
>>
>> could retrieve it and update idmapd.conf if
>> there was a TXT record retrieved, for example.
> I see what you are trying to do here... instead
> of rewriting idmapd.conf... we should probably
> uses... the system that shall go nameless... systemd! ;-)
>
> systemd could run the nfsidmap --txt command that would
> create a file under /run, which is managed by the
> systemd-tmpfiles package. rpcbind does something similar
> to manage its warmstart up files.
>
> Then we could point rpc.idmap and nfsidmap to that
> runtime file via the libnfsidmap interfaces.
Or provide a setting in /etc/idmapd.conf which is
the pathname of the /run file.
It's a little nicer if these settings were all in
one place instead of split between /etc/sysconfig,
systemd configuration, and idmapd.conf.
No Domain= setting means:
1. use the contents of the /run file
2. if no /run file exists, or it's empty, use the
current mechanism to determine the ID mapping
domain name
How does hostnamectl work? does it use /run files?
> The problem with this is how do we expire this cache?
> We would have to store the TTL to know when its time
> to ping DNS again... Is the TTL returned in the DNS
> query?
I'm not aware of any required caching semantics
(again, no real standard here).
I wouldn't expect this setting to change very
often. Perhaps once per boot, or once per system
wake-up, or whenever there is a network configuration
change, is good enough. My guess is you don't want
this changing arbitrarily with running users on
the system. So maybe once per boot is the right
answer.
"nfsidmap --txt -s" could force a refresh by hand.
(Also we need to figure out how to break a tie
on multi-homed systems where more than one TXT
record is found; maybe the only thing to do in
that case is use Domain= , but you'd kind of
prefer good behavior without needing a manual
setting).
>> Then the rest of the infrastructure would not
>> have to change. Just a thought!
> yeah we probably should cache but it does add
> a lot of complexity... Doesn't DNS cache things
> internally? If so, would using that cache work?
I think it's the same arrangement. The resolver's
cache is process-local.
--
Chuck Lever
> On May 24, 2016, at 11:20 AM, Chuck Lever <[email protected]> wrote:
>
>>
>> On May 24, 2016, at 1:43 PM, Steve Dickson <[email protected]> wrote:
>>
>>
>>
>> On 05/24/2016 12:20 PM, Chuck Lever wrote:
>>>
>>>
>>> So your security realm is redhat.com. Any way
>>> to discover that fact, either at system install
>>> time, or after every boot, or ... ?
>> Yea... put it DNS ;-) But I think the answer
>> is no... at least I don't know of a way.
>>
>>>
>>> I think the ID mapping domain name only matters
>>> when you are using Kerberos? sec=sys should use
>>> only stringified UIDs.
>> Netapp filers still use name@domain strings and
>> probably Solaris servers... I think only Linux
>> use the stringified UIDs.
>
C-mode uses stringified UIDs. Not so sure about 7-mode.
Primary Data uses stringified UIDs.
> I'm pretty sure recent Solaris servers will behave
> like Linux. But there's plenty of S10 out there.
>
----- Original Message -----
> From: "Thomas Haynes" <[email protected]>
> To: "Chuck Lever" <[email protected]>
> Cc: "Steve Dickson" <[email protected]>, "Linux NFS Mailing List" <[email protected]>
> Sent: Tuesday, May 24, 2016 9:34:28 PM
> Subject: Re: [RFC PATCH 0/1] Create a DNS SRV record of the ID mapping domain
>> On May 24, 2016, at 11:20 AM, Chuck Lever <[email protected]> wrote:
>>
>>>
>>> On May 24, 2016, at 1:43 PM, Steve Dickson <[email protected]> wrote:
>>>
>>>
>>>
>>> On 05/24/2016 12:20 PM, Chuck Lever wrote:
>>>>
>>>>
>>>> So your security realm is redhat.com. Any way
>>>> to discover that fact, either at system install
>>>> time, or after every boot, or ... ?
>>> Yea... put it DNS ;-) But I think the answer
>>> is no... at least I don't know of a way.
>>>
>>>>
>>>> I think the ID mapping domain name only matters
>>>> when you are using Kerberos? sec=sys should use
>>>> only stringified UIDs.
>>> Netapp filers still use name@domain strings and
>>> probably Solaris servers... I think only Linux
>>> use the stringified UIDs.
>>
>
> C-mode uses stringified UIDs. Not so sure about 7-mode.
>
> Primary Data uses stringified UIDs.
dCache server accepts stringified UIDs and returns
name@domain when possible.
A SRV record will help with auto configuration as
our nfsv4 domain and dns domain are different (long
story).
Tigran.
>
>
>> I'm pretty sure recent Solaris servers will behave
>> like Linux. But there's plenty of S10 out there.
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/24/2016 02:20 PM, Chuck Lever wrote:
>>> $ nfsidmap --txt
>>> >>
>>> >> could retrieve it and display it,
>>> >>
>>> >> # nfsidmap --txt -s
>>> >>
>>> >> could retrieve it and update idmapd.conf if
>>> >> there was a TXT record retrieved, for example.
>> > I see what you are trying to do here... instead
>> > of rewriting idmapd.conf... we should probably
>> > uses... the system that shall go nameless... systemd! ;-)
>> >
>> > systemd could run the nfsidmap --txt command that would
>> > create a file under /run, which is managed by the
>> > systemd-tmpfiles package. rpcbind does something similar
>> > to manage its warmstart up files.
>> >
>> > Then we could point rpc.idmap and nfsidmap to that
>> > runtime file via the libnfsidmap interfaces.
> Or provide a setting in /etc/idmapd.conf which is
> the pathname of the /run file.
>
> It's a little nicer if these settings were all in
> one place instead of split between /etc/sysconfig,
> systemd configuration, and idmapd.conf.hostnamectl
I agree... but... we are dealing with systemd which
limits your options when it comes to reading in
configuration files.
>
> No Domain= setting means:
> 1. use the contents of the /run file
> 2. if no /run file exists, or it's empty, use the
> current mechanism to determine the ID mapping
> domain name
Right... but changing the name of the /run file
really does not have to changeable, IMHO...
>
> How does hostnamectl work? does it use /run files?
Taking a quick look it appears not to... I see a lot
of dbus code... It does not look too interesting to me.
>
>
>> > The problem with this is how do we expire this cache?
>> > We would have to store the TTL to know when its time
>> > to ping DNS again... Is the TTL returned in the DNS
>> > query?
> I'm not aware of any required caching semantics
> (again, no real standard here).
>
> I wouldn't expect this setting to change very
> often. Perhaps once per boot, or once per system
> wake-up, or whenever there is a network configuration
> change, is good enough. My guess is you don't want
> this changing arbitrarily with running users on
> the system. So maybe once per boot is the right
> answer.
Fine... we can deal with expiring the cache if
it becomes an issue...
>
> "nfsidmap --txt -s" could force a refresh by hand.
True.
>
> (Also we need to figure out how to break a tie
> on multi-homed systems where more than one TXT
> record is found; maybe the only thing to do in
> that case is use Domain= , but you'd kind of
> prefer good behavior without needing a manual
> setting).
Does that even work? How can you have multiple domains
on the same host?
I would say we document the fact the first TXT record
processed is the one we go with. All others are ignored.
steved.
> On May 25, 2016, at 8:14 AM, Steve Dickson <[email protected]> wrote:
>
>
>
> On 05/24/2016 02:20 PM, Chuck Lever wrote:
>>>> $ nfsidmap --txt
>>>>>>
>>>>>> could retrieve it and display it,
>>>>>>
>>>>>> # nfsidmap --txt -s
>>>>>>
>>>>>> could retrieve it and update idmapd.conf if
>>>>>> there was a TXT record retrieved, for example.
>>>> I see what you are trying to do here... instead
>>>> of rewriting idmapd.conf... we should probably
>>>> uses... the system that shall go nameless... systemd! ;-)
>>>>
>>>> systemd could run the nfsidmap --txt command that would
>>>> create a file under /run, which is managed by the
>>>> systemd-tmpfiles package. rpcbind does something similar
>>>> to manage its warmstart up files.
>>>>
>>>> Then we could point rpc.idmap and nfsidmap to that
>>>> runtime file via the libnfsidmap interfaces.
>> Or provide a setting in /etc/idmapd.conf which is
>> the pathname of the /run file.
>>
>> It's a little nicer if these settings were all in
>> one place instead of split between /etc/sysconfig,
>> systemd configuration, and idmapd.conf.hostnamectl
> I agree... but... we are dealing with systemd which
> limits your options when it comes to reading in
> configuration files.
>
>>
>> No Domain= setting means:
>> 1. use the contents of the /run file
>> 2. if no /run file exists, or it's empty, use the
>> current mechanism to determine the ID mapping
>> domain name
> Right... but changing the name of the /run file
> really does not have to changeable, IMHO...
Are /run files in the same place for every distribution?
If so, then I agree.
>> (Also we need to figure out how to break a tie
>> on multi-homed systems where more than one TXT
>> record is found; maybe the only thing to do in
>> that case is use Domain= , but you'd kind of
>> prefer good behavior without needing a manual
>> setting).
> Does that even work? How can you have multiple domains
> on the same host?
Which interface is used for the TXT record query?
If a system is on multiple networks with their
own DNS services, it is possible for them to see
a different TXT lookup result depending on which
interfaces happen to be up when the query is done,
and what DNS service has been set up by DHCP.
> I would say we document the fact the first TXT record
> processed is the one we go with. All others are ignored.
Can that value be guaranteed to be the same after
every boot, even in the face of things like changing
order of interface bring-up and DHCP?
The problem with "first TXT record processed" is that
the order these records are processed can change, and
thus the ID mapping domain name is potentially
different after every boot.
I think none of the automated mechanisms are 100%
reliable in this scenario, so the best that can be
done is to use the Domain setting in idmapd.conf.
But admins generally ignore this and hilarity ensues.
It may not be possible to solve it, but at least we
should provide tools for tracking down the issue if
it should occur. Maybe start by reporting the system's
ID mapping domain setting in the system log at boot
time, and how it was derived.
--
Chuck Lever
On 05/25/2016 11:25 AM, Chuck Lever wrote:
>
>> On May 25, 2016, at 8:14 AM, Steve Dickson <[email protected]> wrote:
>> Does that even work? How can you have multiple domains
>> on the same host?
>
> Which interface is used for the TXT record query?
I'm assuming the interfaces in /etc/resolv.conf
> If a system is on multiple networks with their
> own DNS services, it is possible for them to see
> a different TXT lookup result depending on which
> interfaces happen to be up when the query is done,
> and what DNS service has been set up by DHCP.
> On May 25, 2016, at 12:07 PM, Steve Dickson <[email protected]> wrote:
>
>
>
> On 05/25/2016 11:25 AM, Chuck Lever wrote:
>>
>>> On May 25, 2016, at 8:14 AM, Steve Dickson <[email protected]> wrote:
>>> Does that even work? How can you have multiple domains
>>> on the same host?
>>
>> Which interface is used for the TXT record query?
> I'm assuming the interfaces in /etc/resolv.conf
The DHCP client can change /etc/resolv.conf.
>> If a system is on multiple networks with their
>> own DNS services, it is possible for them to see
>> a different TXT lookup result depending on which
>> interfaces happen to be up when the query is done,
>> and what DNS service has been set up by DHCP.
> From my understand of the BIND api, which is
> very limited, domain names and field names
> are use to do lookups. Not interfaces.
>
>>
>>
>>> I would say we document the fact the first TXT record
>>> processed is the one we go with. All others are ignored.
>>
>> Can that value be guaranteed to be the same after
>> every boot, even in the face of things like changing
>> order of interface bring-up and DHCP?
> none... we are asking for a TXT record called
> _nfsv4idmapdomain for from a particular domain.
> why would we care what interface it comes from?
The order in which interfaces initialize may control
the contents of /etc/resolv.conf.
>> The problem with "first TXT record processed" is that
>> the order these records are processed can change, and
>> thus the ID mapping domain name is potentially
>> different after every boot.
>>
>> I think none of the automated mechanisms are 100%
>> reliable in this scenario, so the best that can be
>> done is to use the Domain setting in idmapd.conf.
>> But admins generally ignore this and hilarity ensues.
>>
>> It may not be possible to solve it, but at least we
>> should provide tools for tracking down the issue if
>> it should occur. Maybe start by reporting the system's
>> ID mapping domain setting in the system log at boot
>> time, and how it was derived.
> I think this is a phase two thing... Lets the the
> core up and working and then go from there.
Fair enough, but adding a log entry seems like
it is simple enough to do as part of phase one.
--
Chuck Lever