[ale] NFSv4, Kerberos, and OpenLDAP

Fri Mar 21 00:48:21 EDT 2008

I keep getting the feeling that there should be something simple and
obvious that I am missing, and yet I don't get it.

I have several machines on my home network.  At any given point, any one
of them is likely to be temporarily unavailable for one reason or
another.  I'd like for such issues to not have a huge impact on me; that
is, I'd like for my home directory (and everyone else's home
directories) to be stored on the server, and I would also like the user
accounts and the information that is associated with them to be stored
on the server.  The machines involved are all Ubuntu boxes, so this
should be a bit easier than if the network were hybrid... though in the
future I would like to add the ability to hook Windows clients into the
network, too, should the need arise.

To that effect, I have installed support on the server for Kerberos,
OpenLDAP, and NFSv4.  However, I can't quite get the whole thing to work
together.

Now, Kerberos works just fine, albeit in a very limited way at the
moment.  I have it talking to OpenLDAP, too, though the OpenLDAP
database does not (yet) have anything useful in it, because I'd like to
get NFS working before I switch the authentication method on my system
to use everything on the server:

mbt at sage:~$ kinit
Password for mbt at SPICERACK: 
mbt at sage:~$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: mbt at SPICERACK
SASL SSF: 56
SASL data security layer installed.
dn:uid=mbt,ou=people,dc=spicerack

So, OpenLDAP and Kerberos talk fine.  However, NFSv4, which is
*supposed* to be using Kerberos, doesn't seem to work at all:

mbt at sage:/mounts/mbt$ ls -l *.cs
-rw-r--r-- 1 nobody nogroup 1090 2008-03-06 04:11 fsw.cs
-rw-r--r-- 1 nobody nogroup  970 2008-03-07 12:41 threading.cs
mbt at sage:/mounts/mbt$ 

For some reason, it is showing the files and directories mounted from
the NFS server as being owned by nobody:nogroup, which is getting to be
rather frustrating.  In the system log, I see:

Mar 20 23:50:02 sage rpc.idmapd[4965]: nss_getpwnam: name '1000' domain
'spicerack': resulting localname '(null)' 
Mar 20 23:50:02 sage rpc.idmapd[4965]: nss_getpwnam: name '1000' does
not map into domain 'spicerack' 
Mar 20 23:50:02 sage rpc.idmapd[4965]: Client 0: (user) name "1000" ->
id "65534"
Mar 20 23:50:02 sage rpc.idmapd[4965]: Client 0: (group) name "1000" ->
id "65534"

Well, that's just fine and dandy, but my /etc/idmapd.conf is set to the
correct domain on both the client and the server, the system domain name
is the same on both the client and the server (e.g., they are both in
the domain "spicerack"), and the Kerberos realm is network is SPICERACK,
which should totally not matter (since the NFSv4 domain is supposed to
be separate from either the system domain name or the Kerberos realm).

I _must_ be missing something "obvious", but I can't figure out what it
is.  I have gone over several documents and readmes and manuals on
setting these things up, and the only thing that I know for _sure_ to be
true is the that the Kerberos system is working.  Though, at the moment,
it's not all that useful.

My exports on the server (exportfs -v) look like this:

/srv/exports/pxe
10.0.0.0/8(ro,async,wdelay,insecure,no_root_squash,no_subtree_check)

/srv/exports/music
gss/krb5(rw,wdelay,nohide,insecure,no_root_squash,no_subtree_check)

/srv/exports/home
gss/krb5(rw,wdelay,nohide,insecure,no_root_squash,no_subtree_check)

/srv/exports/etc
gss/krb5(rw,wdelay,nohide,insecure,no_root_squash,no_subtree_check)

/srv/exports
gss/krb5(ro,wdelay,insecure,no_root_squash,no_subtree_check,fsid=0)

(the /etc directory export isn't actually going to replace the
workstation's /etc, by the way... it's just going to supplement it, and
that's where I will put a few things that need to be done centrally.)

Has anyone here setup a system similar to this?  Does anything stand out
as obviously incorrect of the relatively minor amount of detail
exhibited?  Would there be anything helpful/useful to check that I
haven't shown?

	--- Mike

-- 
Michael B. Trausch                                   mike at trausch.us
home: 404-592-5746, 1                                 www.trausch.us
cell: 678-522-7934                       im: mike at trausch.us, jabber
Ubuntu Unofficial Backports Project:    http://backports.trausch.us/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080321/ad41f2b2/attachment.bin 