On 05/03/17 19:42, Niels Thykier wrote:
> On Sat, 04 Feb 2017 09:58:00 +0000 Niels Thykier <[email protected]> wrote:
>> Daniel Pocock:
>>> [...]
>>>
>>> Upstream is not really supporting rpc.svcgssd any more, they actually
>>> disabled it in the build so people can still have it as a transitional
>>> measure in stretch.
>>>
>>> People shouldn't be using it in any new installations. Offering them
>>> gssproxy is a very sensible thing to do.
>>>
>>> Regards,
>>>
>>> Daniel
>>>
>> Debian kernel team <[email protected]>
>> Ok, follow up questions:
>>
>> * Do you have an upstream reference to the state of rpc.svcgssd?
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=24b5d60d7f0a514310df810e3eb27b72f665febf
"svcgssd: Disable support for the rpcsec_gss server by default
At this point the gssproxy is better option than the
svcgssd so the support is off by default.
Use --enable-svcgss to re-enable the support"
but it looks like it may not be completely abandoned, there have been
other commits that mention gssd recently.
>>
>> * Can we provide both rpc.svcgssd and gssproxy in Debian (with the
>> admin choosing) or is it an "xor"?
>>
I think there are two questions:
a) can they both exist in different packages that conflict with each
other? I'm guessing that will probably be yes.
b) can they both be installed simultaneously? Possibly not (can anybody
on the linux-nfs list answer?)
>> * If this package is unblocked, are there any changes needed in
>> nfs-common needed to support gssproxy? (source upload, binNMU or
>> "just works with no further changes")
>>
I don't have time to investigate that right now, if anybody else has
time to look more closely that would be great.
Regards,
Daniel
On Sun, Mar 05 2017, Daniel Pocock wrote:
> On 05/03/17 19:42, Niels Thykier wrote:
>> On Sat, 04 Feb 2017 09:58:00 +0000 Niels Thykier <[email protected]> wrote:
>>> Daniel Pocock:
>>>> [...]
>>>>
>>>> Upstream is not really supporting rpc.svcgssd any more, they actually
>>>> disabled it in the build so people can still have it as a transitional
>>>> measure in stretch.
>>>>
>>>> People shouldn't be using it in any new installations. Offering them
>>>> gssproxy is a very sensible thing to do.
>>>>
>>>> Regards,
>>>>
>>>> Daniel
>>>>
>>> Debian kernel team <[email protected]>
>>> Ok, follow up questions:
>>>
>>> * Do you have an upstream reference to the state of rpc.svcgssd?
>
>
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=24b5d60d7f0a514310df810e3eb27b72f665febf
>
> "svcgssd: Disable support for the rpcsec_gss server by default
>
> At this point the gssproxy is better option than the
> svcgssd so the support is off by default.
>
> Use --enable-svcgss to re-enable the support"
>
> but it looks like it may not be completely abandoned, there have been
> other commits that mention gssd recently.
>
>
>>>
>>> * Can we provide both rpc.svcgssd and gssproxy in Debian (with the
>>> admin choosing) or is it an "xor"?
>>>
>
> I think there are two questions:
>
> a) can they both exist in different packages that conflict with each
> other? I'm guessing that will probably be yes.
>
> b) can they both be installed simultaneously? Possibly not (can anybody
> on the linux-nfs list answer?)
Yes, they can.
The systemd unit files are designed so that svcgssd will only be started
if gssproxy didn't start - and gssproxy is tried first.
If you use something other than systemd, similar logic would be needed.
NeilBrown
>
>
>>> * If this package is unblocked, are there any changes needed in
>>> nfs-common needed to support gssproxy? (source upload, binNMU or
>>> "just works with no further changes")
>>>
>
> I don't have time to investigate that right now, if anybody else has
> time to look more closely that would be great.
>
> Regards,
>
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
NeilBrown:
> On Sun, Mar 05 2017, Daniel Pocock wrote:
>
>> [...]
>
> Yes, they can.
> The systemd unit files are designed so that svcgssd will only be started
> if gssproxy didn't start - and gssproxy is tried first.
>
> If you use something other than systemd, similar logic would be needed.
>
> NeilBrown
>
>
> [...]
Hi,
@Neil: Thanks for the clarification. :) I am taking you and linux-nfs
off again (BCC'ed) as I assumed the rest follows from here are less like
to be relevant for you.
@Robbie: Can you clarify what happens for people who have chosen to use
sysvinit as init system? Will they end up with gssproxy or svcgssd or a
broken NFS?
Thanks,
~Niels