* Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages
@ 2012-06-01 15:53 Orion Poplawski
2012-06-01 15:58 ` Myklebust, Trond
0 siblings, 1 reply; 6+ messages in thread
From: Orion Poplawski @ 2012-06-01 15:53 UTC (permalink / raw)
To: linux-nfs
I'm seeing a fair number of these messages on our file server:
Jun 1 09:37:58 alexandria rpc.idmapd[28890]: nss_getpwnam: name 'nobody' does
not map into domain 'cora.nwra.com'
I think they are coming from accessing files on another file server that are
owned by an unknown uid (user left and was removed from the user database).
These files end up owned by "nobody" (as expected) on the remote system:
drwxr-xr-x. 7 nobody nwra 4096 Mar 15 2010 analysis_data
Now, this seems like a perfectly normal operation and so shouldn't generate a
system log message. First two possible fixes I can think of:
- Should the remote system send the username as "nobody@cora.nwra.com" instead
of just "nobody"?
recc_attr: FATTR4_OWNER (36)
fattr4_owner: nobody
length: 6
contents: nobody
fill bytes: opaque data
recc_attr: FATTR4_OWNER_GROUP (37)
fattr4_owner_group: nwra@cora.nwra.com
length: 18
contents: nwra@cora.nwra.com
fill bytes: opaque data
- Don't log if the username is "nobody"? Although since this is independently
configurable on the different machines this seems like a bad idea. Maybe don't
log if there is no domain part at all?
This is on EL6 with nfs-utils-1.2.3-15.el6_2.1
Orion Poplawski
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages 2012-06-01 15:53 Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages Orion Poplawski @ 2012-06-01 15:58 ` Myklebust, Trond 2012-06-01 16:26 ` Orion Poplawski 0 siblings, 1 reply; 6+ messages in thread From: Myklebust, Trond @ 2012-06-01 15:58 UTC (permalink / raw) To: Orion Poplawski; +Cc: linux-nfs@vger.kernel.org T24gRnJpLCAyMDEyLTA2LTAxIGF0IDE1OjUzICswMDAwLCBPcmlvbiBQb3BsYXdza2kgd3JvdGU6 DQo+IEknbSBzZWVpbmcgYSBmYWlyIG51bWJlciBvZiB0aGVzZSBtZXNzYWdlcyBvbiBvdXIgZmls ZSBzZXJ2ZXI6DQo+IA0KPiBKdW4gIDEgMDk6Mzc6NTggYWxleGFuZHJpYSBycGMuaWRtYXBkWzI4 ODkwXTogbnNzX2dldHB3bmFtOiBuYW1lICdub2JvZHknIGRvZXMNCj4gbm90IG1hcCBpbnRvIGRv bWFpbiAnY29yYS5ud3JhLmNvbScNCj4gDQo+IEkgdGhpbmsgdGhleSBhcmUgY29taW5nIGZyb20g YWNjZXNzaW5nIGZpbGVzIG9uIGFub3RoZXIgZmlsZSBzZXJ2ZXIgdGhhdCBhcmUNCj4gb3duZWQg YnkgYW4gdW5rbm93biB1aWQgKHVzZXIgbGVmdCBhbmQgd2FzIHJlbW92ZWQgZnJvbSB0aGUgdXNl ciBkYXRhYmFzZSkuIA0KPiBUaGVzZSBmaWxlcyBlbmQgdXAgb3duZWQgYnkgIm5vYm9keSIgKGFz IGV4cGVjdGVkKSBvbiB0aGUgcmVtb3RlIHN5c3RlbToNCj4gDQo+IGRyd3hyLXhyLXguICA3IG5v Ym9keSBud3JhIDQwOTYgTWFyIDE1ICAyMDEwIGFuYWx5c2lzX2RhdGENCj4gDQo+IE5vdywgdGhp cyBzZWVtcyBsaWtlIGEgcGVyZmVjdGx5IG5vcm1hbCBvcGVyYXRpb24gYW5kIHNvIHNob3VsZG4n dCBnZW5lcmF0ZSBhDQo+IHN5c3RlbSBsb2cgbWVzc2FnZS4gIEZpcnN0IHR3byBwb3NzaWJsZSBm aXhlcyBJIGNhbiB0aGluayBvZjoNCj4gDQo+IC0gU2hvdWxkIHRoZSByZW1vdGUgc3lzdGVtIHNl bmQgdGhlIHVzZXJuYW1lIGFzICJub2JvZHlAY29yYS5ud3JhLmNvbSIgaW5zdGVhZA0KPiBvZiBq dXN0ICJub2JvZHkiPw0KDQpOby4gQWNjb3JkaW5nIHRvIHNlY3Rpb24gNS44IG9mIFJGQzM1MzAs IGl0IHNob3VsZCB1c2UgdGhlIG5hbWUgIm5vYm9keSINCndpdGhvdXQgYSBkb21haW4sIGFuZCB0 aGUgaWRtYXBwZXIgc2hvdWxkIGJlIG1hcHBpbmcgdGhhdCBzdHJpbmcgdG8gdGhlDQphbm9ueW1v dXMgdXNlciAoaS5lLiB1aWQgLTIpLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZT IGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20N Cnd3dy5uZXRhcHAuY29tDQoNCg== ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages 2012-06-01 15:58 ` Myklebust, Trond @ 2012-06-01 16:26 ` Orion Poplawski 2012-06-01 16:41 ` Myklebust, Trond 0 siblings, 1 reply; 6+ messages in thread From: Orion Poplawski @ 2012-06-01 16:26 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs@vger.kernel.org On 06/01/2012 09:58 AM, Myklebust, Trond wrote: > On Fri, 2012-06-01 at 15:53 +0000, Orion Poplawski wrote: >> I'm seeing a fair number of these messages on our file server: >> >> Jun 1 09:37:58 alexandria rpc.idmapd[28890]: nss_getpwnam: name 'nobody' does >> not map into domain 'cora.nwra.com' >> >> I think they are coming from accessing files on another file server that are >> owned by an unknown uid (user left and was removed from the user database). >> These files end up owned by "nobody" (as expected) on the remote system: >> >> drwxr-xr-x. 7 nobody nwra 4096 Mar 15 2010 analysis_data >> >> Now, this seems like a perfectly normal operation and so shouldn't generate a >> system log message. First two possible fixes I can think of: >> >> - Should the remote system send the username as "nobody@cora.nwra.com" instead >> of just "nobody"? > > No. According to section 5.8 of RFC3530, it should use the name "nobody" > without a domain, and the idmapper should be mapping that string to the > anonymous user (i.e. uid -2). > Well, it's mapping it to "nobody" id 99: drwxr-xr-x. 7 99 1001 4096 Mar 15 2010 analysis_data Okay, so no domain. Also according to 5.8: In the case where there is no translation available to the client or server, the attribute value must be constructed without the "@". Therefore, the absence of the @ from the owner or owner_group attribute signifies that no translation was available at the sender and that the receiver of the attribute should not use that string as a basis for translation into its own internal format. Even though the attribute value can not be translated, it may still be useful. In the case of a client, the attribute string may be used for local display of ownership. So absence of @ indicates no need to translate locally, so don't complain about it. So how about this: --- ./libnfsidmap-0.25/nss.c.nobody 2011-12-05 13:28:10.000000000 -0700 +++ ./libnfsidmap-0.25/nss.c 2012-06-01 10:23:53.408603517 -0600 @@ -177,9 +177,10 @@ IDMAP_LOG(4, ("nss_getpwnam: name '%s' domain '%s': " "resulting localname '%s'\n", name, domain, localname)); if (localname == NULL) { - IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map " - "into domain '%s'\n", name, - domain ? domain : "<not-provided>")); + if (strchr(name, '@' != NULL) + IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map " + "into domain '%s'\n", name, + domain ? domain : "<not-provided>")); goto err_free_buf; } -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages 2012-06-01 16:26 ` Orion Poplawski @ 2012-06-01 16:41 ` Myklebust, Trond 2012-06-01 16:53 ` Orion Poplawski 2012-06-01 17:10 ` Jim Rees 0 siblings, 2 replies; 6+ messages in thread From: Myklebust, Trond @ 2012-06-01 16:41 UTC (permalink / raw) To: Orion Poplawski; +Cc: linux-nfs@vger.kernel.org T24gRnJpLCAyMDEyLTA2LTAxIGF0IDEwOjI2IC0wNjAwLCBPcmlvbiBQb3BsYXdza2kgd3JvdGU6 DQo+IE9uIDA2LzAxLzIwMTIgMDk6NTggQU0sIE15a2xlYnVzdCwgVHJvbmQgd3JvdGU6DQo+ID4g T24gRnJpLCAyMDEyLTA2LTAxIGF0IDE1OjUzICswMDAwLCBPcmlvbiBQb3BsYXdza2kgd3JvdGU6 DQo+ID4+IEknbSBzZWVpbmcgYSBmYWlyIG51bWJlciBvZiB0aGVzZSBtZXNzYWdlcyBvbiBvdXIg ZmlsZSBzZXJ2ZXI6DQo+ID4+DQo+ID4+IEp1biAgMSAwOTozNzo1OCBhbGV4YW5kcmlhIHJwYy5p ZG1hcGRbMjg4OTBdOiBuc3NfZ2V0cHduYW06IG5hbWUgJ25vYm9keScgZG9lcw0KPiA+PiBub3Qg bWFwIGludG8gZG9tYWluICdjb3JhLm53cmEuY29tJw0KPiA+Pg0KPiA+PiBJIHRoaW5rIHRoZXkg YXJlIGNvbWluZyBmcm9tIGFjY2Vzc2luZyBmaWxlcyBvbiBhbm90aGVyIGZpbGUgc2VydmVyIHRo YXQgYXJlDQo+ID4+IG93bmVkIGJ5IGFuIHVua25vd24gdWlkICh1c2VyIGxlZnQgYW5kIHdhcyBy ZW1vdmVkIGZyb20gdGhlIHVzZXIgZGF0YWJhc2UpLg0KPiA+PiBUaGVzZSBmaWxlcyBlbmQgdXAg b3duZWQgYnkgIm5vYm9keSIgKGFzIGV4cGVjdGVkKSBvbiB0aGUgcmVtb3RlIHN5c3RlbToNCj4g Pj4NCj4gPj4gZHJ3eHIteHIteC4gIDcgbm9ib2R5IG53cmEgNDA5NiBNYXIgMTUgIDIwMTAgYW5h bHlzaXNfZGF0YQ0KPiA+Pg0KPiA+PiBOb3csIHRoaXMgc2VlbXMgbGlrZSBhIHBlcmZlY3RseSBu b3JtYWwgb3BlcmF0aW9uIGFuZCBzbyBzaG91bGRuJ3QgZ2VuZXJhdGUgYQ0KPiA+PiBzeXN0ZW0g bG9nIG1lc3NhZ2UuICBGaXJzdCB0d28gcG9zc2libGUgZml4ZXMgSSBjYW4gdGhpbmsgb2Y6DQo+ ID4+DQo+ID4+IC0gU2hvdWxkIHRoZSByZW1vdGUgc3lzdGVtIHNlbmQgdGhlIHVzZXJuYW1lIGFz ICJub2JvZHlAY29yYS5ud3JhLmNvbSIgaW5zdGVhZA0KPiA+PiBvZiBqdXN0ICJub2JvZHkiPw0K PiA+DQo+ID4gTm8uIEFjY29yZGluZyB0byBzZWN0aW9uIDUuOCBvZiBSRkMzNTMwLCBpdCBzaG91 bGQgdXNlIHRoZSBuYW1lICJub2JvZHkiDQo+ID4gd2l0aG91dCBhIGRvbWFpbiwgYW5kIHRoZSBp ZG1hcHBlciBzaG91bGQgYmUgbWFwcGluZyB0aGF0IHN0cmluZyB0byB0aGUNCj4gPiBhbm9ueW1v dXMgdXNlciAoaS5lLiB1aWQgLTIpLg0KPiA+DQo+IA0KPiBXZWxsLCBpdCdzIG1hcHBpbmcgaXQg dG8gIm5vYm9keSIgaWQgOTk6DQoNClllcywgdGhhdCdzIHRoZSBjb3JyZWN0IHRoaW5nIHRvIGRv IGlmIGEgdXNlciAibm9ib2R5IiBleGlzdHMuDQoNCj4gZHJ3eHIteHIteC4gIDcgOTkgMTAwMSA0 MDk2IE1hciAxNSAgMjAxMCBhbmFseXNpc19kYXRhDQo+IA0KPiBPa2F5LCBzbyBubyBkb21haW4u ICBBbHNvIGFjY29yZGluZyB0byA1Ljg6DQo+IA0KPiAgICAgSW4gdGhlIGNhc2Ugd2hlcmUgdGhl cmUgaXMgbm8gdHJhbnNsYXRpb24gYXZhaWxhYmxlIHRvIHRoZSBjbGllbnQgb3INCj4gICAgIHNl cnZlciwgdGhlIGF0dHJpYnV0ZSB2YWx1ZSBtdXN0IGJlIGNvbnN0cnVjdGVkIHdpdGhvdXQgdGhl ICJAIi4NCj4gICAgIFRoZXJlZm9yZSwgdGhlIGFic2VuY2Ugb2YgdGhlIEAgZnJvbSB0aGUgb3du ZXIgb3Igb3duZXJfZ3JvdXANCj4gICAgIGF0dHJpYnV0ZSBzaWduaWZpZXMgdGhhdCBubyB0cmFu c2xhdGlvbiB3YXMgYXZhaWxhYmxlIGF0IHRoZSBzZW5kZXINCj4gICAgIGFuZCB0aGF0IHRoZSBy ZWNlaXZlciBvZiB0aGUgYXR0cmlidXRlIHNob3VsZCBub3QgdXNlIHRoYXQgc3RyaW5nIGFzDQo+ ICAgICBhIGJhc2lzIGZvciB0cmFuc2xhdGlvbiBpbnRvIGl0cyBvd24gaW50ZXJuYWwgZm9ybWF0 LiAgRXZlbiB0aG91Z2gNCj4gICAgIHRoZSBhdHRyaWJ1dGUgdmFsdWUgY2FuIG5vdCBiZSB0cmFu c2xhdGVkLCBpdCBtYXkgc3RpbGwgYmUgdXNlZnVsLg0KPiAgICAgSW4gdGhlIGNhc2Ugb2YgYSBj bGllbnQsIHRoZSBhdHRyaWJ1dGUgc3RyaW5nIG1heSBiZSB1c2VkIGZvciBsb2NhbA0KPiAgICAg ZGlzcGxheSBvZiBvd25lcnNoaXAuDQo+IA0KPiBTbyBhYnNlbmNlIG9mIEAgaW5kaWNhdGVzIG5v IG5lZWQgdG8gdHJhbnNsYXRlIGxvY2FsbHksIHNvIGRvbid0IGNvbXBsYWluIA0KPiBhYm91dCBp dC4gIFNvIGhvdyBhYm91dCB0aGlzOg0KPiANCj4gLS0tIC4vbGlibmZzaWRtYXAtMC4yNS9uc3Mu Yy5ub2JvZHkgICAgIDIwMTEtMTItMDUgMTM6Mjg6MTAuMDAwMDAwMDAwIC0wNzAwDQo+ICsrKyAu L2xpYm5mc2lkbWFwLTAuMjUvbnNzLmMgICAgMjAxMi0wNi0wMSAxMDoyMzo1My40MDg2MDM1MTcg LTA2MDANCj4gQEAgLTE3Nyw5ICsxNzcsMTAgQEANCj4gICAgICAgICAgSURNQVBfTE9HKDQsICgi bnNzX2dldHB3bmFtOiBuYW1lICclcycgZG9tYWluICclcyc6ICINCj4gICAgICAgICAgICAgICAg ICAgICJyZXN1bHRpbmcgbG9jYWxuYW1lICclcydcbiIsIG5hbWUsIGRvbWFpbiwgbG9jYWxuYW1l KSk7DQo+ICAgICAgICAgIGlmIChsb2NhbG5hbWUgPT0gTlVMTCkgew0KPiAtICAgICAgICAgICAg ICAgSURNQVBfTE9HKDAsICgibnNzX2dldHB3bmFtOiBuYW1lICclcycgZG9lcyBub3QgbWFwICIN Cj4gLSAgICAgICAgICAgICAgICAgICAgICAgImludG8gZG9tYWluICclcydcbiIsIG5hbWUsDQo+ IC0gICAgICAgICAgICAgICAgICAgICAgIGRvbWFpbiA/IGRvbWFpbiA6ICI8bm90LXByb3ZpZGVk PiIpKTsNCj4gKyAgICAgICAgICAgICAgIGlmIChzdHJjaHIobmFtZSwgJ0AnICE9IE5VTEwpDQo+ ICsgICAgICAgICAgICAgICAgICAgICAgIElETUFQX0xPRygwLCAoIm5zc19nZXRwd25hbTogbmFt ZSAnJXMnIGRvZXMgbm90IG1hcCAiDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ImludG8gZG9tYWluICclcydcbiIsIG5hbWUsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgZG9tYWluID8gZG9tYWluIDogIjxub3QtcHJvdmlkZWQ+IikpOw0KPiAgICAgICAgICAg ICAgICAgIGdvdG8gZXJyX2ZyZWVfYnVmOw0KPiAgICAgICAgICB9DQoNCkFDSy4gVGhhdCBsb29r cyBhYm91dCByaWdodC4uLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVu dCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5u ZXRhcHAuY29tDQoNCg== ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages 2012-06-01 16:41 ` Myklebust, Trond @ 2012-06-01 16:53 ` Orion Poplawski 2012-06-01 17:10 ` Jim Rees 1 sibling, 0 replies; 6+ messages in thread From: Orion Poplawski @ 2012-06-01 16:53 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs@vger.kernel.org On 06/01/2012 10:41 AM, Myklebust, Trond wrote: > On Fri, 2012-06-01 at 10:26 -0600, Orion Poplawski wrote: >> So absence of @ indicates no need to translate locally, so don't complain >> about it. So how about this: >> >> --- ./libnfsidmap-0.25/nss.c.nobody 2011-12-05 13:28:10.000000000 -0700 >> +++ ./libnfsidmap-0.25/nss.c 2012-06-01 10:23:53.408603517 -0600 >> @@ -177,9 +177,10 @@ >> IDMAP_LOG(4, ("nss_getpwnam: name '%s' domain '%s': " >> "resulting localname '%s'\n", name, domain, localname)); >> if (localname == NULL) { >> - IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map " >> - "into domain '%s'\n", name, >> - domain ? domain : "<not-provided>")); >> + if (strchr(name, '@' != NULL) >> + IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map " >> + "into domain '%s'\n", name, >> + domain ? domain : "<not-provided>")); >> goto err_free_buf; >> } > > ACK. That looks about right... > Another possibility is that we shouldn't even be calling nss_getpwnam() in the first place in this case, but I don't know the code well enough to pursue that or if it's worth it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages 2012-06-01 16:41 ` Myklebust, Trond 2012-06-01 16:53 ` Orion Poplawski @ 2012-06-01 17:10 ` Jim Rees 1 sibling, 0 replies; 6+ messages in thread From: Jim Rees @ 2012-06-01 17:10 UTC (permalink / raw) To: Myklebust, Trond; +Cc: Orion Poplawski, linux-nfs@vger.kernel.org Myklebust, Trond wrote: > Well, it's mapping it to "nobody" id 99: Yes, that's the correct thing to do if a user "nobody" exists. Is it? RFC3530 says "nobody" (on the wire) is the anonymous user. If the server has a real user whose local name is "nobody," should the nfs anonymous user be mapped to the real local user named "nobody", or should it be mapped to uid -2? I'm inclined to say that if you have a real user named "nobody" on linux then you get what you deserve. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-06-01 17:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-06-01 15:53 Spurious rpc.idmapd nss_getpwnam: name 'nobody' does not map into domain messages Orion Poplawski 2012-06-01 15:58 ` Myklebust, Trond 2012-06-01 16:26 ` Orion Poplawski 2012-06-01 16:41 ` Myklebust, Trond 2012-06-01 16:53 ` Orion Poplawski 2012-06-01 17:10 ` Jim Rees
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).