Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

[Anthony Messina <amessina@messinet.com>]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On Monday, February 03, 2014 04:01:21 PM Steve Dickson wrote:
> This changes the current API... Today to enable/start this service 
> today one does:
> 
>   systemctl enable nfs-server
>   systemctl start nfs-server
> 
> which would change to:
> 
>   systemctl enable nfs-server.target
>   systemctl start nfs-server
> 
> with the same daemons being started.
> This changed will cause existing scripts to fail... 
> I guess I don't see the point of having a .target file. 
> 
> How is rpc.svcgssd enabled? Since the .service file does
> not have a [Install] section the systemctl enable rpc.svcgssd
> fails.
> 
> Also how does gss-proxy come to play in all this? Maybe we 
> just use  gss-proxy by default and retire rpc.svcgssd.

Usually just a quite listener (end-user & small-time sysadmin) on this ML...

+1 for gss-proxy by default (for Fedora anyway).  I've been using it 
throughout F19 extensively in the KRB5/NFSv4.1 environment with great success.  
I have nfs-secure-server.service "masked" via systemd to prevent it from being 
started.

There seems to be only one strange issue I've come across with gss-proxy vs. 
rpc.svcgssd: https://fedorahosted.org/gss-proxy/ticket/98.  This is with 
regard to how access for the "nfsnobody" user is handled.  The ticket attempts 
to show that with rpc.svcgssd, a host with host credentials and a user without 
credentials can still access NFS shares with 0755 directories and 0644 files 
(via the host credentials and mapped to the nfsnobody user).  With gss-proxy, 
I had to create user credentials for kojibuilder@REALM because the access 
wasn't allowed via the nfsnobody path.  I'm not sure if this is resolved, or 
by design, etc.  But it is the only issue I've seen with gss-proxy vs. 
rpc.svcgssd.

Thanks.  -A

-- 
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]