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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday, February 04, 2014 08:24:26 AM Jeff Layton wrote:
> On Tue, 04 Feb 2014 06:42:12 -0600
> 
> Anthony Messina <amessina@xxxxxxxxxxxx> wrote:
> > 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
> >
> > 
> 
> Please do open a bug at bugzilla.redhat.com for that and cc me on it.
> We really do want to ensure that these sorts of corner-cases get
> addressed.

https://bugzilla.redhat.com/show_bug.cgi?id=1061180

-- 
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.


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux