Hello list,
I found a lot of information on the subject NFS server, ipv6 + krb5, but
not anything conclusive. So I tried it out; I got IPv6 +
NFS4 to work, but only with sec=sys.
When using sec=krb5, there seemed to be errors in gssd communication.
(Ubuntu 10.04 with rpcbind instead of portmap; with nfs-utils-1.2.3 from
nfs.sf.net, and with a 2.6.35-020635rc1-generic kernel package).
Is this correct, i.e. svcgssd still needs to be adapted to IPv6? Or
should NFS-server/IPv6/Kerberos on Linux just work, i.e. should I
re-check my configuration?
Best regards,
Valentijn Sessink
(I hope you don't mind the repost; I did not get any answers on my
previous posting. If you do mind, please say so off-list).
Valentijn Sessink wrote:
Hello list,
I found a lot of information on the subject NFS server, ipv6 + krb5, but
not anything conclusive. So I tried it out; I got IPv6 +
NFS4 to work, but only with sec=sys.
When using sec=krb5, there seemed to be errors in gssd communication.
(Ubuntu 10.04 with rpcbind instead of portmap; with nfs-utils-1.2.3 from
nfs.sf.net, and with a 2.6.35-020635rc1-generic kernel package).
Is this correct, i.e. svcgssd still needs to be adapted to IPv6? Or
should NFS-server/IPv6/Kerberos on Linux just work, i.e. should I
re-check my configuration?
I don't know the specific answer to your question, but ipv6 support is still
a work in progress, and I'm actually a bit surprised it works out of the box
even with sec=sys.
You may want to try the very latest ipv6 version of nfs-utils, which may
have some patches that have not yet been merged upstream. You can get it
from git://git.linux-nfs.org/projects/cel/nfs-utils.git . The usual
warnings apply, this is experimental code, you could lose data, it may not
work with your 2.6.35 kernel, and if you find bugs you can't necessarily get
anyone to help you.
On Wed, 13 Oct 2010 12:57:10 +0200
Valentijn Sessink <[email protected]> wrote:
> Hello list,
>
> I found a lot of information on the subject NFS server, ipv6 + krb5, but
> not anything conclusive. So I tried it out; I got IPv6 +
> NFS4 to work, but only with sec=sys.
>
> When using sec=krb5, there seemed to be errors in gssd communication.
> (Ubuntu 10.04 with rpcbind instead of portmap; with nfs-utils-1.2.3 from
> nfs.sf.net, and with a 2.6.35-020635rc1-generic kernel package).
>
> Is this correct, i.e. svcgssd still needs to be adapted to IPv6? Or
> should NFS-server/IPv6/Kerberos on Linux just work, i.e. should I
> re-check my configuration?
>
> Best regards,
>
> Valentijn Sessink
>
When I last tested it and reviewed it (which was quite some time ago),
it worked without any issues. rpc.svcgssd doesn't really do much with
addresses, so it didn't need anything to convert it to IPv6.
What sort of problems were you having?
--
Jeff Layton <[email protected]>
Jeff Layton schreef:
> As of nfs-utils-1.2.3, IPv6 server-side support should be
> "complete" (modulo bugs, of course).
Which is "correct" (I copied the quotation marks, because I tested very
inextensively). What I'm wondering about is the combination with
Kerberos. I'm currently setting up a better testing environment.
V.
On Wed, 13 Oct 2010 08:56:56 -0400
Jim Rees <[email protected]> wrote:
> Valentijn Sessink wrote:
>
> Hello list,
>
> I found a lot of information on the subject NFS server, ipv6 + krb5, but
> not anything conclusive. So I tried it out; I got IPv6 +
> NFS4 to work, but only with sec=sys.
>
> When using sec=krb5, there seemed to be errors in gssd communication.
> (Ubuntu 10.04 with rpcbind instead of portmap; with nfs-utils-1.2.3 from
> nfs.sf.net, and with a 2.6.35-020635rc1-generic kernel package).
>
> Is this correct, i.e. svcgssd still needs to be adapted to IPv6? Or
> should NFS-server/IPv6/Kerberos on Linux just work, i.e. should I
> re-check my configuration?
>
> I don't know the specific answer to your question, but ipv6 support is still
> a work in progress, and I'm actually a bit surprised it works out of the box
> even with sec=sys.
>
> You may want to try the very latest ipv6 version of nfs-utils, which may
> have some patches that have not yet been merged upstream. You can get it
> from git://git.linux-nfs.org/projects/cel/nfs-utils.git . The usual
> warnings apply, this is experimental code, you could lose data, it may not
> work with your 2.6.35 kernel, and if you find bugs you can't necessarily get
> anyone to help you.
As of nfs-utils-1.2.3, IPv6 server-side support should be
"complete" (modulo bugs, of course).
--
Jeff Layton <[email protected]>
Valentijn Sessink wrote:
Well, I did, in fact. At least, that is what I'm currently seeing with
another system, where "networkmanager" messes with the hosts-file, and
as a result, effectively wipes out the FQDN.
You mean resolv.conf? This is one of my gripes with network manager. I
usually un-install it, or "chattr +i resolv.conf".
The usual fix for idmapd is to set the domain in /etc/idmapd.conf.
On Wed, 13 Oct 2010 10:49:37 -0400
Jeff Layton <[email protected]> wrote:
> On Wed, 13 Oct 2010 15:56:31 +0200
> Valentijn Sessink <[email protected]> wrote:
>
> > Jeff Layton schreef:
> > > As of nfs-utils-1.2.3, IPv6 server-side support should be
> > > "complete" (modulo bugs, of course).
> >
> > Which is "correct" (I copied the quotation marks, because I tested very
> > inextensively). What I'm wondering about is the combination with
> > Kerberos. I'm currently setting up a better testing environment.
> >
> > V.
> >
>
> FWIW, I was planning on doing some testing of this soon anyway. It
> works for me:
>
> From /proc/mounts:
>
> rhel6srv.example.com:/export/ /mnt/test nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=feed::3,minorversion=0,addr=feed::4 0 0
>
> $ klist
> Ticket cache: FILE:/tmp/krb5cc_50000
> Default principal: [email protected]
>
> Valid starting Expires Service principal
> 10/13/10 10:43:48 10/14/10 10:43:46 krbtgt/[email protected]
> renew until 10/13/10 10:43:48
> 10/13/10 10:43:58 10/14/10 10:43:46 nfs/[email protected]
> renew until 10/13/10 10:43:48
>
> $ id -a
> uid=50000(testuser) gid=50000(testuser) groups=50000(testuser) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>
> $ cd /mnt/test; echo foo > testuser ; stat testuser
> File: `testuser'
> Size: 4 Blocks: 0 IO Block: 131072 regular file
> Device: 15h/21d Inode: 29 Links: 1
> Access: (0664/-rw-rw-r--) Uid: (50000/testuser) Gid: (50000/testuser)
> Access: 2010-10-13 10:47:07.771053989 -0400
> Modify: 2010-10-13 10:47:07.802186619 -0400
> Change: 2010-10-13 10:47:07.802186619 -0400
>
> It sounds more like you have a problem with idmapping rather than
> anything krb5 specific, but I'm not sure why that would be the case
> with sec=krb5 and not with sec=sys.
>
One thing that you may need to do is set the Local-Realms option
in idmapd.conf, depending on your network and krb5 configuration.
--
Jeff Layton <[email protected]>
Jeff, list,
Jeff Layton schreef:
> It sounds more like you have a problem with idmapping rather than
> anything krb5 specific, but I'm not sure why that would be the case
> with sec=krb5 and not with sec=sys.
Well, I did, in fact. At least, that is what I'm currently seeing with
another system, where "networkmanager" messes with the hosts-file, and
as a result, effectively wipes out the FQDN. Thus, idmapd thinks that
"localdomain" (added by networkmanager - why?? - no that's not a
question, just venting my frustration ;) was a good guess to test the
logged in user against:
rpc.idmapd: nss_getpwnam: name '[email protected]' domain
'localdomain': resulting localname '(null)'
(We run idmapd relying on DNS instead of a "Domain = " clause, because
we thought that made us flexible - I'll rethink that decision.)
V.
Jeff Layton schreef:
> Valentijn Sessink <[email protected]> wrote:
>> Is this correct, i.e. svcgssd still needs to be adapted to IPv6? Or
>> should NFS-server/IPv6/Kerberos on Linux just work, i.e. should I
>> re-check my configuration?
> When I last tested it and reviewed it (which was quite some time ago),
> it worked without any issues. rpc.svcgssd doesn't really do much with
> addresses, so it didn't need anything to convert it to IPv6.
>
> What sort of problems were you having?
>From the user's viewpoint, there was no uid-mapping: everything you
wrote would end up as nobody:nogroup on the server. This happens when
your Kerberos-tickets cannot be validated - hence my pointing at svcgssd
and gssd.
I did test starting rpc.svcgssd and rpc.gssd with -vvvf, and there were
a few suspiciously looking messages. Then I ran out of time :)
Anyway, from your answers I conclude that there is not a reason "per se"
that it cannot work (nor is there a reason it should work ;), so I'll
test again and this time I will gather more extensive logging
information to feed the list with ;)
Best regards,
Valentijn
Hi Jim, Jeff, list,
Jim Rees schreef:
> another system, where "networkmanager" messes with the hosts-file, and
> You mean resolv.conf?
No, /etc/hosts
Today, I found a long standing Ubuntu bug about this:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/8980
> This is one of my gripes with network manager. I
> usually un-install it, or "chattr +i resolv.conf".
Yep, we usually uninstall it as well.
But now, we're thinking about changing nsswitch.conf to "hosts: dns
files" - might be a better way in this case.
> The usual fix for idmapd is to set the domain in /etc/idmapd.conf.
Yes, I know. In fact, during the install phase we commented the "Domain"
clause out, to have the system configure it's own FQDN (based on DHCP,
mostly). I'm not a big fan of spraying domain name and hostname on every
file in /etc if the system can find things out by itself.
But I guess I'm being corrected by reality.
V.
Valentijn Sessink wrote:
Jim Rees schreef:
> another system, where "networkmanager" messes with the hosts-file, and
> You mean resolv.conf?
No, /etc/hosts
That's evil. The 127 net addresses have always been listed in /etc/hosts as
just "localhost" with no fqdn, and everything worked fine. I will add this
to my already long list of reasons to hate network manager.
But I guess I'm being corrected by reality.
Ha!
On Wed, 13 Oct 2010 15:56:31 +0200
Valentijn Sessink <[email protected]> wrote:
> Jeff Layton schreef:
> > As of nfs-utils-1.2.3, IPv6 server-side support should be
> > "complete" (modulo bugs, of course).
>
> Which is "correct" (I copied the quotation marks, because I tested very
> inextensively). What I'm wondering about is the combination with
> Kerberos. I'm currently setting up a better testing environment.
>
> V.
>
FWIW, I was planning on doing some testing of this soon anyway. It
works for me:
>From /proc/mounts:
rhel6srv.example.com:/export/ /mnt/test nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=feed::3,minorversion=0,addr=feed::4 0 0
$ klist
Ticket cache: FILE:/tmp/krb5cc_50000
Default principal: [email protected]
Valid starting Expires Service principal
10/13/10 10:43:48 10/14/10 10:43:46 krbtgt/[email protected]
renew until 10/13/10 10:43:48
10/13/10 10:43:58 10/14/10 10:43:46 nfs/[email protected]
renew until 10/13/10 10:43:48
$ id -a
uid=50000(testuser) gid=50000(testuser) groups=50000(testuser) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$ cd /mnt/test; echo foo > testuser ; stat testuser
File: `testuser'
Size: 4 Blocks: 0 IO Block: 131072 regular file
Device: 15h/21d Inode: 29 Links: 1
Access: (0664/-rw-rw-r--) Uid: (50000/testuser) Gid: (50000/testuser)
Access: 2010-10-13 10:47:07.771053989 -0400
Modify: 2010-10-13 10:47:07.802186619 -0400
Change: 2010-10-13 10:47:07.802186619 -0400
It sounds more like you have a problem with idmapping rather than
anything krb5 specific, but I'm not sure why that would be the case
with sec=krb5 and not with sec=sys.
--
Jeff Layton <[email protected]>