Bug 626515

So, do you think that YaST NIS client should offer to save Domain value of /etc/idmapd.conf as the configured NIS domain? Probably only when automounter option is checked?

Thorsten, does the above solution make sense?

(In reply to comment #1)
> So, do you think that YaST NIS client should offer to save Domain value of
> /etc/idmapd.conf as the configured NIS domain? Probably only when automounter
> option is checked?

Definitely only when the automounter option is checked.

The value is also set on the YaST / NFS Client Configuration / NFS Settings tab.
I do not know if it is possible to connect these or chain them together.

If you can open this same NFS tab from the NIS Client screen after the Automounter option is checked, that would proably make a good re-use of existing code.

Otherwise, duplicating the Enable NFS4 & NFS4 Domain options below the Automounter checkbox is also acceptable, and gives it needed visibility.

Please also reference the Enhancement request in Bug 626516

(In reply to comment #3)

> If you can open this same NFS tab from the NIS Client screen after the
> Automounter option is checked, that would proably make a good re-use of
> existing code.

Probably not exactly this. But I could add a button "Run NFS client" there.
 
> Otherwise, duplicating the Enable NFS4 & NFS4 Domain options below the
> Automounter checkbox is also acceptable, and gives it needed visibility.

Yes, that's what I meant.


Thorsten, what do you think?

I don't understand the problem.

According to the idmapd configuration, "Domain" should be by default the FQDN of the host for NFSv4, while the NIS domain should never be the FQDN.

If ipmapd "domain" is identical to NIS domainname, why does idmapd not use the getdomainname() syscall but needs the config option?
Or is the problem, that we have a wrong default entry in idmapd.conf? Then this should be fixed.

(In reply to comment #6)
> I don't understand the problem.
> 
> According to the idmapd configuration, "Domain" should be by default the FQDN
> of the host for NFSv4, while the NIS domain should never be the FQDN.
> 
> If ipmapd "domain" is identical to NIS domainname, why does idmapd not use the
> getdomainname() syscall but needs the config option?
> Or is the problem, that we have a wrong default entry in idmapd.conf? Then this
> should be fixed.

The problem is that the default 'Domain' set in idmapd.conf is not appropriate for the environment.  It was "localdomain", instead of the domain part of the FQDN.  

And (if that actually gets set to something during installation) I'll take a WAG here and say the installation method may have contributed to this problem.  I installed this machine via NFS, booting from the Net-Install CD.

Also, there is a 'host' entry on the local DHCP server for this machine's MAC address, so it can pick up the following info automagically during the install:
FQDN hostname
ip address
domain-name-servers
subnet-mask
broadcast-address
routers
nis-domain
nis-servers
(and other trivial stuff, but not the NFS4 domain)

I'm still not sure if I should add anything to NIS client. It would help your particular problem, but may confuse (most of) other users, that do not need it.

Shouldn't you actually have NFS configured?

Neil, what do you think? Isn't there a problem with idmapd.conf defaults (comment 6)?

There isn't really any 'right' value for the idmap.conf domain name.
All that is required is that the client and server need to have the same
name if (and only if) the same user-name on each maps to the same external entity.

The value from 'getdomainname' would certainly be a reasonable choice on installations using NIS for password file lookup.
The current default of using the DNS domain name is also reasonable in a
lot of cases.

'localdomain' is never really reasonable, and idmapd should only use that when nothing else is available - setting it in idmapd.conf certainly seems wrong.

I would suggest that by default Yast should not set a domain name in idmapd.conf.  However when configuring NIS for username lookup it would be appropriate to have an option "Use NIS domain for NFSv4 username mapping" which should probably default to 'on'.

Does that help?

(In reply to comment #9)

> I would suggest that by default Yast should not set a domain name in
> idmapd.conf.  However when configuring NIS for username lookup it would be
> appropriate to have an option "Use NIS domain for NFSv4 username mapping" which
> should probably default to 'on'.

It probably makes sense from the point of NFS configuration (to offer NIS domain, if available), but I'm not sure if I should add the "Use Domain for NFSv4 username mapping" checkbox into the NIS configurator... (wouldn't it scare other users?)

Or did you mean rightly this?

Since it is about NFS configuration, it should go into the yast2 nfs module. People don't expect and will not search for that option in the NIS module.

(In reply to comment #11)
> Since it is about NFS configuration, it should go into the yast2 nfs module.
> People don't expect and will not search for that option in the NIS module.

NFS4 Domain configuration is already in the NFS Module.

Enabling NIS+automounter is not aware of it, because it happens in the NIS module.

(In reply to comment #9)
> I would suggest that by default Yast should not set a domain name in
> idmapd.conf.  However when configuring NIS for username lookup it would be
> appropriate to have an option "Use NIS domain for NFSv4 username mapping" which
> should probably default to 'on'.

I'd have to disagree with using the NIS domain as the default.  Other *nix implementation use the DNS domain in preference to the NIS domain.

--
I did a bit poking around and came up with the following info:

There are/were two proposals for using DNS records for finding the NFS4 Domain, one used the RR: NFS4ID.  The other used the TXT record _nfsv4idmapdomain.

HP-UX uses a (Sun based) nfsmapid which uses _nfsv4idmapdomain DNS text record as "first choice".
Solaris should be implementing it too, but in what release, I don't know.

Solaris uses the DNS domain by default, then the NIS domain. (I'm not sure if this is dynamic, or set during installation)

Both HP-UX and Solaris fall back to a manual setting in a config file.

AIX seems to use just a config file, and custom command (chnfsdom) for updating it.

The CentOS/RHEL 5 (BSD) man page says "By default, domain is set to be the FQDN of the host, minus the hostname." (assuming it's not set in idmapd.conf)

(In reply to comment #14)

> 
> I'd have to disagree with using the NIS domain as the default.  Other *nix
> implementation use the DNS domain in preference to the NIS domain.
> 
> --
> I did a bit poking around and came up with the following info:
> 
> There are/were two proposals for using DNS records for finding the NFS4 Domain,
> ...

But who should actually do that? NFS client configurator (YaST)? Or some daemon?

The question presented here is, if NIS client configurator (YaST) should offer an option to adapt /etc/imapd.conf's domain value to the current value of NIS domain. So this would not be a default behavior, just a possibility.

However, the problem is, if it does not mean adding extra complexity to NIS client module and if it weren't better to advice users to use NFS client module directly.

(In reply to comment #15)
> (In reply to comment #14)
> 
> > 
> > I'd have to disagree with using the NIS domain as the default.  Other *nix
> > implementation use the DNS domain in preference to the NIS domain.
> > 
> 
> But who should actually do that? NFS client configurator (YaST)? Or some
> daemon?

assuming "some daemon" == rpc.idmapd

Then the answer is 'both', and is the way things are currently implemented.  idmapd has to have some value for the domain, and that is defined in the RFCs mentioned, and already implemented.  Alternately, the domain is specified in a configuration, which overrides the idmapd defaults.  The YaST's NFS client module can handle the manual configuration.

> 
> The question presented here is, if NIS client configurator (YaST) should offer
> an option to adapt /etc/imapd.conf's domain value to the current value of NIS
> domain. So this would not be a default behavior, just a possibility.

No, that's not quite the question presented here.  It should not be the NIS domain name.

The correct question here is, can/should YaST's NIS client module offer an option to configure the NFSv4 domain value (stored in /etc/imapd.conf)?

A second question may be, what (if any) default value should be supplied?
Hint: leave it unset, and idmapd will fall back to the FQDN of the host, minus the hostname.

A third question (and possibly a separate bug) is how/where did /etc/imapd.conf get the invalid setting of "localdomain" from?

> 
> However, the problem is, if it does not mean adding extra complexity to NIS
> client module and if it weren't better to advice users to use NFS client module
> directly.

Of course, any new added code to YaST's NIS client module will add some complexity (coding, maintenance, QA, testing, etc), and that is just a fact of life.

The simple alternative is just adding a text message to advise the users to go to the NFS client module and configure the NFSv4 domain name there.  That would be an acceptable option IF the resources are not there to do anything better.  But, isn't the whole point of YaST to make administration of the system simpler and more "user friendly"?

(In reply to comment #16)

> > The question presented here is, if NIS client configurator (YaST) should offer
> > an option to adapt /etc/imapd.conf's domain value to the current value of NIS
> > domain. So this would not be a default behavior, just a possibility.
> 
> No, that's not quite the question presented here.  It should not be the NIS
> domain name.
> 
> The correct question here is, can/should YaST's NIS client module offer an
> option to configure the NFSv4 domain value (stored in /etc/imapd.conf)?

If the value is not related to NIS domain name, than YaST NIS client should not offer its configuration.

It can offer a button to start NFS client config, which is a bit more than mentioning it in the help text.

(In reply to comment #17)
> > The correct question here is, can/should YaST's NIS client module offer an
> > option to configure the NFSv4 domain value (stored in /etc/imapd.conf)?
> 
> If the value is not related to NIS domain name, than YaST NIS client should not
> offer its configuration.

By the same logic, should the NIS Client module offer the Automounter checkbox?  That checkbox is a convenience, which may or may not be related to NIS (depends on where your maps are stored).  And the NFSv4 Domain name may be related to Automounter....


> It can offer a button to start NFS client config, which is a bit more than
> mentioning it in the help text.

That's also a good solution, and probably the most practical one.  I'd suggest making it available if the Automounter checkbox is checked.

(In reply to comment #18)

> > It can offer a button to start NFS client config, which is a bit more than
> > mentioning it in the help text.
> 
> That's also a good solution, and probably the most practical one.  I'd suggest
> making it available if the Automounter checkbox is checked.

OK, I'll take care of this one.

Regarding other problems, not related to YaST NIS, please open separate reports.

Created attachment 390236 [details]
screenshot of the proposal

Sorry, I had other work to do.

What would you think about this?

(In reply to comment #20)
> What would you think about this?

The button placement is ok.

The text in Help reads like there is a "automounter configuration" option in the NFS Client.

I'd recommend instead saying "NFS Settings which affects how the automouter operates can be set in NFS Client, ...."

Can the button automagically directly open the "NFS Settings" tab of the NFS Client?  That would be better than taking the user to the "NFS Shares" tab.

(In reply to comment #21)
> (In reply to comment #20)
> > What would you think about this?
> 
> The button placement is ok.
> 
> The text in Help reads like there is a "automounter configuration" option in
> the NFS Client.
> 
> I'd recommend instead saying "NFS Settings which affects how the automouter
> operates can be set in NFS Client, ...."

I changed it according to your proposal and submitted new package (yast2-nis-client-2.20.0) into Factory.

> Can the button automagically directly open the "NFS Settings" tab of the NFS
> Client?  That would be better than taking the user to the "NFS Shares" tab.

Well, theoretically yes, but unfortunately NFS stuff maintainer is too busy with other stuff to care of such minor issue.

Sorry, I know it took quite long time, and the change is minimal, but that's caused by our current workload and changed goals.... :-(

This is an autogenerated message for OBS integration:
This bug (626515) was mentioned in
https://build.opensuse.org/request/show/65008 Factory / yast2-nis-client