NFSv4 details and documentations

[Slawa Olhovchenkov]

On Tue, Dec 01, 2015 at 08:41:46AM -0500, Rick Macklem wrote:

> > > (Note that "host" here implies that the principal for the host-based
> > > credential is
> > >  "host@<client-host>.<domain>". --> What is after the "=" above is what is
> > >  before the
> > >  "@" in the host based principal name.)
> > > Then system operations are done as nobody, but users are done as that user
> > > (they need
> > 
> > This is strange. I am mount (by automount) as:
> > 
> > /NFS    -nfsv4,intr,soft,sec=krb5i,gssname=host storage01:/
> > 
> I'd recommend that you never use "intr" or "soft" on NFSv4 mounts.
> (It's somewhere in a man page and basically if you use these and an
>  RPC that does locking times out, you break the locking horribly.)

W/o "intr" and "soft" I can got staled mount and process (till
reboot). This is prodaction servers and this is unacceptable. Correct
locking for me least important, as last resort I am do `umount -f`

> Also, I never use automount. I'd suggest you try the mount command
> typed manually and then once you have it working, then try the automount
> and see if it works.

I am debuging this manualy, yes.

> > in rc.conf:
> > gssd_enable="YES"
> > gssd_flags="-h"
> > 
> On the client, this looks correct.
> 
> > In this case, I am can't login to user with $HOME on this NFS --
> > root (sshd run as root and PAM accounting run as root -- check
> > .k5login and etc) totaly don't have access (10016).
> > 
> This means that the client fell back to AUTH_SYS and the server
> doesn't accept that.
> 
> Getting a home directory to work is harder than it should be and I
> don't even know how to make it work, because I haven't done it.
> The login must do a "kinit" so the user has access to the volume
> and I don't know how to set FreeBSD up to do the kinit as a part of
> the login. It also must be done early enough in the login, so that
> it happens before any access to the home dir is attempted.
> (To be honest, unless there is a way to do this in FreeBSD, you
> can forget about Kerberized NFS mounts for home dirs.)

First access to home directory do as root, not as user.
After root access ticket created in /tmp/krb5cc_UID and home
succesuful accesed.

> I would start by testing a mount that isn't a home directory, so you
> can log into the machine (home dir not Kerberized NFS mounted) and
> then the user can "kinit" and them "cd /kerberized/mount" and see
> if it works.
> --> Once that works, I don't know how to do the rest.
> (I'm an NFS guy, not a Kerberos one.;-)
> 
> Also, I don't know what effect having sshd etc running as root will
> be, since they will then be seen as running by "nobody" on the server.

As last resort I can export with -maproot=root.

> > I am avoid this by "kinit -k host/`hostname`" in crontab and startup
> > script, but may be gssd is best for this functionality?
> > 
> Shouldn't matter. "gssd -h" does exactly the same stuff as "kinit -k".
> (I wrote the code essentially cloning what "kinit -k" did.)

For mount only, not for root access from sshd, as I see.