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:
signature.asc
Description: This is a digitally signed message part.
