Date: Tue, 1 Dec 2015 16:56:24 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: hackers@freebsd.org Subject: Re: NFSv4 details and documentations Message-ID: <1491578361.114386779.1449006984539.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151201135315.GH31314@zxy.spb.ru> References: <9BC3EFA2-945F-4C86-89F6-778873B58469@cs.huji.ac.il> <20151116155710.GB31314@zxy.spb.ru> <1312967974.89238067.1447714816355.JavaMail.zimbra@uoguelph.ca> <20151130165940.GB31314@zxy.spb.ru> <183609075.112643195.1448924896262.JavaMail.zimbra@uoguelph.ca> <20151201074425.GD31314@zxy.spb.ru> <1745794347.113212991.1448977306722.JavaMail.zimbra@uoguelph.ca> <20151201135315.GH31314@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Slawa Olhivchenkov wrote:
> 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`
>
When I was a sysadmin, I just made sure my NFS server stayed up and the network
fabric was stable. I never recall having a problem using "hard" mounts.
But I agree it is a tradeoff. If you don't need file locking visible across
multiple clients, use nfsv3,nolockd and intr if it works for you.
If you need file locking to work and be visible across multiple clients, then
the tradeoff is a hung system if your NFS server fails or your network fabric
is flakey. (Do you want file locking to work, but only when things are running
smoothly?)
You can use "umount -f" but I will admit you can get stuck. If you do a "umount"
without "-f" the mount point gets locked and "umount -f" doesn't work.
I, for one, do not believe that NFSv4 is a replacement for NFSv3. It is a very
different protocol (some say "NFS in name only") and fills a different somewhat
overlapping solution space.
> > 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.
That's going to be a problem. I'm not sure how that will work unless
the access as root can be done by "nobody". Normally it is assumed
that a user accesses files on the NFS mount as that user.
(ie. This just might not be doable unless you get rid of the
access as root during the login.)
> 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 don't think this works as you'd expect. The server doesn't see "root"
as the principal for the host-based credential in the keytab file.
To be seen as "root" on the server:
- I think you need a root@YOUR.REALM user principal in your KDC.
- The client must "kinit" this to get a TGT in /tmp/krb5cc_0.
- You can create a keytab entry for root@YOUR.REALM and "kinit -k" it, I think?
--> Most would consider putting a keytab entry in /etc/krb5.keytab for "root"
too large a security risk, but maybe it's ok for your environment.
(Someone could move the keytab entry to another machine and it would still
work.)
(You mentioned doing something like this in your crontab.)
Btw, you can use Kerberos with NFSv3. It works about the same and doen't
require a host-based credential in /etc/krb5.keytab. It does require that
the login do "kinit" before attempting to access the home dir.
> > > 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.
>
Yes, for Kerberos root access, I think you will need "root@YOUR.REALM" in
your KDC and need to kinit for that.
rick
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1491578361.114386779.1449006984539.JavaMail.zimbra>