[rhelv6-list] RHEL 6.3 Released

[Feldt, Andrew N.]

Folks,

I have tracked down the source of this problem.  This
is due to the fact that the following order of init
scripts occurs:

S18rpcidmapd
...
S25netfs
...
S27ypbind

I happen have a mount in my /etc/fstab which does
an NFS mount of a filesystem owned by my uid/gid.  This
occurs in the netfs script before ypbind is run so
that my uid and gid get cached as 'nobody'.  I am still
considering how I will best work around this, but it
will be a problem for anyone who uses NIS and happens
to mount (as NFSv4) a directory which should later
get its true mapping via NIS.

Andy

On Jun 25, 2012, at 10:30 AM, Matthias Saou wrote:

> *very* interesting to know, thanks for sharing what you've found!
> 
> Matthias
> 
> On Mon, 25 Jun 2012 15:04:58 +0000
> "Feldt, Andrew N." <afeldt at ou.edu> wrote:
> 
>> Ian,
>> 
>> I went to verify the response I originally began for this
>> message and used other accounts than my own for testing
>> ls -l /home/username (before, I just used mine because
>> I first tested with that and found this problem).
>> 
>> To my surprise, I found that the id mapping works fine
>> for all of our user accounts *except* mine!  This
>> account has uid and gid of 900.  I have other accounts
>> with numbers below this, so it is not some minimum
>> cutoff.  I also have other accounts in my group
>> (all with gid 900) which map the username properly
>> but the gid for 900 is still shown as 'nobody' for
>> them (as expected since that is how it is shown for
>> my account.
>> 
>> I discovered a change in nfs-utils which provides the
>> new command nfsidmap (see its man page for details).
>> I find that, if I run 'nfsidmap -c' after booting
>> the problem is resolved.  It appears that there has
>> been a change in the way ids are mapped so that they
>> are cached. And, something in our boot process must
>> access my uid/gid (e.g. my account) before ypbind is
>> run and so these get cached as 'nobody'.  However,
>> this begs the question of the startup ordering of
>> rpcidmapd, ypbind and autofs since I have no
>> special script of any sort that is run in between
>> rpcidmapd and autofs.  I will try to dig into this
>> further, but we should not have to work around this
>> caching issue.
>> 
>> Andy
>> 
>> On Jun 24, 2012, at 6:57 PM, Ian Mortimer wrote:
>> 
>>> On Fri, 2012-06-22 at 17:22 +0000, Feldt, Andrew N. wrote:
>>> 
>>>> Thanks for the info.  Unfortunately, this does not help the
>>>> idmapper problem.  And, we had no problem actually automounting
>>>> the file systems.  The only problem is in the id mapping.
>>> 
>>> So is the problem with autofs or with rpcidmapd?  Every time I've
>>> seen this, the fix has been: 
>>> 
>>> umount file_system
>>> service rpcidmapd restart
>>> mount file_system
>>> 
>>> 
>>> --
>>> Ian
>>> 
>>> _______________________________________________
>>> rhelv6-list mailing list
>>> rhelv6-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>> 
>> 
>> _______________________________________________
>> rhelv6-list mailing list
>> rhelv6-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rhelv6-list
> 
> 
> 
> -- 
>            Matthias Saou                  ██          ██
>                                             ██      ██
> Web: http://matthias.saou.eu/              ██████████████
> Mail/XMPP:  matthias at saou.eu             ████  ██████  ████
>                                       ██████████████████████
> GPG: 4096R/E755CC63                    ██  ██████████████  ██
>     8D91 7E2E F048 9C9C 46AF          ██  ██          ██  ██
>     21A9 7A51 7B82 E755 CC63                ████  ████
> 
> _______________________________________________
> rhelv6-list mailing list
> rhelv6-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rhelv6-list

Andy Feldt
Senior System Support Programmer
Affiliate Assistant Professor
Homer L. Dodge Department of Physics & Astronomy
The University of Oklahoma