Re: [PATCH 1/2] nfs-service: Added the starting of gssproxy

Steve Dickson
2014-09-23T15:52:21Z

On 09/23/2014 11:16 AM, J. Bruce Fields wrote:
> On Tue, Sep 23, 2014 at 11:06:45AM -0400, Steve Dickson wrote:
>> >
>> >
>> > On 09/22/2014 09:55 PM, J. Bruce Fields wrote:
>>> > > On Mon, Sep 22, 2014 at 08:26:55PM -0400, Simo Sorce wrote:
>>>> > >> No, starting before those service in itself achieves nothing.\
>>>> > >> I think what may cause the module to load maybe the fact
>>>> > >> gssproxy.service includes:
>>>> > >> Requires=proc-fs-nfsd.mount
>>> > >
>>> > > I'd expect that to only load the nfsd module.
>>> > >
>>> > > Hm, I think nfsd actually has a dependency on auth_rpcgss. I wonder if
>>> > > that's correct. Maybe that's what's doing it.
>> > It is... In another thread I clearly showed that....
> The dependency of nfsd on auth_rpcgss looks to me like an implementation
> detail. The client module doesn't have the same dependency.
It does... auth_rpcgss and friends are loaded during the mount

> We definitely shouldn't depend on it, as the dependency could get removed
> some day.
Well if that dependency gets removed (which I can't see why it ever would)
we'll deal with the then...

Remember the scope of this patch set is to enable the server to use
the gssproxy, seamlessly... As thing stand today, I think we can
easily do that by modifying the server service file to "call"
gssproxy when its installed... Plus since both gssproxy
and the server have the 'Requires=proc-fs-nfsd.mount' in their
service files and Today we know that loads the needed modules
I thinking we are good go to...

If things change down the road, lets deal with it then...

>
>> > So I really don't think another unit file is necessary...
> I haven't seen an alternative yet.
I'm thinking adding yet another unit file to do something that
is already being done is just adding more complexity to an
already confusing situation...

So I guess my alternative is to do nothing. ;-)

steved.