Bug 746497

Summary: Configuration file ignored
Product: [Fedora] Fedora Reporter: Göran Uddeborg <goeran>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 16CC: amessina, bfields, jlayton, mbooth, stephenrtate, steved
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: nfs-utils-1.2.5-3.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-19 01:03:58 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Göran Uddeborg 2011-10-16 11:38:21 EDT
After upgrading to nfs-utils-1.2.5-1.fc16.x86_64 rpc.idmapd stopped to recognize the Translation/Mapping configuration I had in my idmap.conf file.

I've reported this upstreams with more details and an explanation of what I believe is the problem.  See https://bugzilla.linux-nfs.org/show_bug.cgi?id=205 for further information.  With this report I wish to ask for the fix when it is available to be included in F16.
Comment 1 Matthew Booth 2011-11-02 19:54:44 EDT
I believe I have hit the same problem with different symptoms. 'Domain' is ignored from idmapd.conf. It seems that idmapd in F16 is entirely ignoring its config file.

I've bisected nfs-utils, and the regression was introduced by this seemingly innocuous change to the build system: d7c64ddf66b04a225fab249af8a8fdd684551c5c. As far as I can tell, before this change, we were not linking against libnfsidmap, but after it we are.

Specifically, the bug seems to be caused by nfs4_init_name_mapping in libnfsidmap re-calling conf_init() *after* idmapd has already called it in main(). This wipes all previously parsed config. Although the config is then re-parsed, somehow config_bindings doesn't end up being populated the second time it runs. I haven't fully followed this through yet, so I haven't managed to work out why.
Comment 2 Matthew Booth 2011-11-03 05:50:55 EDT
There's a very simple reproducer for this. Change Domain to something random in /etc/idmapd.conf, and run rpc.idmapd -vvf. The domain used is output almost immediately. If it outputs the random value from /etc/idmapd.conf it has succeeded. If it outputs a default value taken from the domain name of the host, it has failed.
Comment 3 Steve Tate 2011-11-14 16:29:02 EST
I can confirm this, and that it causes real problems.  For those having this problem, if the only problem is the Domain, here's my very ugly and hopefully very temporary work-around:  I stop the idmapd service, change the hostname so that the default Domain comes out right, start idmapd, and then change the hostname back to what it should be.  In other words, this works:

systemctl stop nfs-idmap.service
hostname dummy.DESIRED-DOMAIN
systemctl start nfs-idmap.service
hostname real-host-name

A single restart (instead of stop/start) would probably work as well, but what's above is the way I have done it, and idmapd is working OK now (but the Domain was the only non-default setting I have).  Of course, you'll have to do that after any reboot as well (could script it...).

Looking forward to a real fix!
Comment 4 Göran Uddeborg 2011-11-14 16:34:13 EST
If your only problem is the domain, maybe a slightly less ugly work-around would be to set


in /etc/sysconfig/nfs.
Comment 5 Fedora Update System 2011-11-14 18:13:31 EST
nfs-utils-1.2.5-3.fc16 has been submitted as an update for Fedora 16.
Comment 6 Steve Tate 2011-11-14 22:31:14 EST
Goran:  Unfortunately, that doesn't work.  The latest versions of idmapd (with the borked config file reading) also disable the "-d" command line option.  So there is, in fact, no way to have it use a different domain without fooling it with a fake hostname.

The comments with the nfs-utils update say this fixes the problem though, which is great.  I'm waiting for it to pass through the release system....
Comment 7 Göran Uddeborg 2011-11-15 17:07:51 EST
> Unfortunately, that doesn't work.

Hm, I thought I used it for a while.  But maybe that was earlier, trying to understand other issues I had.

Anyway, I completely agree it's good a version that fixes it is on the way. :-)
Comment 8 Fedora Update System 2011-11-15 19:26:06 EST
Package nfs-utils-1.2.5-3.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.5-3.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2011-11-19 01:03:58 EST
nfs-utils-1.2.5-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.