Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #56895 > unrolled thread

Bug#852395: unblock: gssproxy/0.5.1-2

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#852395: unblock: gssproxy/0.5.1-2 Niels Thykier <niels@thykier.net> - 2017-02-04 11:00 +0100
    Bug#852395: unblock: gssproxy/0.5.1-2 Daniel Pocock <daniel@pocock.pro> - 2017-02-04 11:00 +0100
      Bug#852395: unblock: gssproxy/0.5.1-2 Niels Thykier <niels@thykier.net> - 2017-02-04 11:10 +0100
        Bug#852395: unblock: gssproxy/0.5.1-2 Niels Thykier <niels@thykier.net> - 2017-03-05 19:50 +0100
          Bug#852395: unblock: gssproxy/0.5.1-2 Daniel Pocock <daniel@pocock.pro> - 2017-03-05 20:20 +0100
            Bug#852395: unblock: gssproxy/0.5.1-2 NeilBrown <neilb@suse.com> - 2017-03-20 06:30 +0100
              Bug#852395: unblock: gssproxy/0.5.1-2 Niels Thykier <niels@thykier.net> - 2017-04-05 12:50 +0200
                Bug#852395: unblock: gssproxy/0.5.1-2 Robbie Harwood <rharwood@club.cc.cmu.edu> - 2017-04-06 01:50 +0200
                  Bug#852395: unblock: gssproxy/0.5.1-2 Niels Thykier <niels@thykier.net> - 2017-04-09 21:50 +0200
                    Bug#852395: unblock: gssproxy/0.5.1-2 Robbie Harwood <rharwood@club.cc.cmu.edu> - 2017-04-11 07:40 +0200

#56895 — Bug#852395: unblock: gssproxy/0.5.1-2

Control: tags -1 moreinfo

CC'ing the maintainer of nfs-common and the reporter of #848306.

Robbie Harwood:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: unblock
> 
> Please unblock package gssproxy
> 
> gssproxy has been 10 days in unstable, and allowing it to migrate will fix
> bug#848306 (severity: important) in nfs-common.  gssproxy is a new package in
> unstable (so no debdiff is included), and would have made the freeze had I not
> made a mistake documenting copyright.
> 
> Thanks.
> 
> unblock gssproxy/0.5.1-2
> 
> [...]

Hi,

Thanks for bringing this up.

Is this migration from rpc.svcgssd to gssproxy so important (release
critical) that it ought to be granted an exception? And if so, why is it
that important (despite #848306 not being release critical)?

Thanks,
~Niels

[toc] | [next] | [standalone]

#56896

On 04/02/17 10:50, Niels Thykier wrote:
> Control: tags -1 moreinfo
>
> CC'ing the maintainer of nfs-common and the reporter of #848306.
>
> Robbie Harwood:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package gssproxy
>>
>> gssproxy has been 10 days in unstable, and allowing it to migrate will fix
>> bug#848306 (severity: important) in nfs-common.  gssproxy is a new package in
>> unstable (so no debdiff is included), and would have made the freeze had I not
>> made a mistake documenting copyright.
>>
>> Thanks.
>>
>> unblock gssproxy/0.5.1-2
>>
>> [...]
> Hi,
>
> Thanks for bringing this up.
>
> Is this migration from rpc.svcgssd to gssproxy so important (release
> critical) that it ought to be granted an exception? And if so, why is it
> that important (despite #848306 not being release critical)?

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

[toc] | [prev] | [next] | [standalone]

#56897

Daniel Pocock:
> On 04/02/17 10:50, Niels Thykier wrote:
>> [...]
>> Hi,
>>
>> Thanks for bringing this up.
>>
>> Is this migration from rpc.svcgssd to gssproxy so important (release
>> critical) that it ought to be granted an exception? And if so, why is it
>> that important (despite #848306 not being release critical)?
> 
> 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
> 

Ok, follow up questions:

 * Do you have an upstream reference to the state of rpc.svcgssd?

 * Can we provide both rpc.svcgssd and gssproxy in Debian (with the
   admin choosing) or is it an "xor"?

 * 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")

Thanks,
~Niels

[toc] | [prev] | [next] | [standalone]

#57169

On Sat, 04 Feb 2017 09:58:00 +0000 Niels Thykier <niels@thykier.net> 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 <debian-kernel@lists.debian.org>
> Ok, follow up questions:
> 
>  * Do you have an upstream reference to the state of rpc.svcgssd?
> 
>  * Can we provide both rpc.svcgssd and gssproxy in Debian (with the
>    admin choosing) or is it an "xor"?
> 
>  * 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")
> 
> Thanks,
> ~Niels
> 
> 
> 
> 


Hi,

We are waiting for feedback on the above in order to move forward on
this unblock request.

Thanks,
~Niels

[toc] | [prev] | [next] | [standalone]

#57170

On 05/03/17 19:42, Niels Thykier wrote:
> On Sat, 04 Feb 2017 09:58:00 +0000 Niels Thykier <niels@thykier.net> 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 <debian-kernel@lists.debian.org>
>> 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

[toc] | [prev] | [next] | [standalone]

#57286

[Multipart message — attachments visible in raw view] — view raw

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 <niels@thykier.net> 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 <debian-kernel@lists.debian.org>
>>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#57455

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

[toc] | [prev] | [next] | [standalone]

#57463

[Multipart message — attachments visible in raw view] — view raw

Niels Thykier <niels@thykier.net> writes:

> NeilBrown:
>> On Sun, Mar 05 2017, Daniel Pocock wrote:
>> 
>> 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.
>
> @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?

I don't totally understand these unit files, so this is probably a
better question for the NFS folk.  But:

The gssproxy package contains a sysvinit script, which works just fine
on my sysvinit system.  (And I assume on systemd systems due to lack of
bug reports :) )

Since nfs-common doesn't provide sysvinit scripts as far as I can tell,
I think you already can't run any of this on them, unless I'm missing
something.

So you'd get gssproxy, and no NFS, but that was already the case.

[toc] | [prev] | [next] | [standalone]

#57492

Robbie Harwood:
> Niels Thykier <niels@thykier.net> writes:
> 
>> NeilBrown:
>>> On Sun, Mar 05 2017, Daniel Pocock wrote:
>>>
>>> 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.
>>
>> @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?
> 
> I don't totally understand these unit files, so this is probably a
> better question for the NFS folk.  But:
> 
> The gssproxy package contains a sysvinit script, which works just fine
> on my sysvinit system.  (And I assume on systemd systems due to lack of
> bug reports :) )
> 
> Since nfs-common doesn't provide sysvinit scripts as far as I can tell,
> I think you already can't run any of this on them, unless I'm missing
> something.
> 
> So you'd get gssproxy, and no NFS, but that was already the case.
> 

Ok - as I understand it, what we are dealing with here is:

 * systemd: You can get gssproxy + NFS and it "just works(tm)" if
   you install gssproxy.  Otherwise you get svcgssd + NFS.
   (This is how I understood Neil Brown)
 * sysvinit: Business as usual either way.


So granting gssproxy will:

 * Provide systemd users with NFS + gssproxy if they opt-in to it
   (by installing it)
 * Provide sysvinit users gssproxy and if they want to use it with
   NFS, they may have to tweak things themselves
 * Not cause any issues for neither systemd users nor sysvinit users
   just by installing it.
 * enable users to get gssproxy which is not deprecated (unlike the
   existing svcgssd)

Is the above correct? And you are happy with gssproxy/0.5.1-2 as it is?

If we are going to grant an exception, we will do so under the
assumption that it "just works" and it won't case issues.  If that
assumption turns out to be false, I will sooner undo this exception and
remove gssproxy than I will be spending time reviewing additional
unblock requests for it.

Thanks,
~Niels

[toc] | [prev] | [next] | [standalone]

#57512

[Multipart message — attachments visible in raw view] — view raw

Niels Thykier <niels@thykier.net> writes:

> Ok - as I understand it, what we are dealing with here is:
>
>  * systemd: You can get gssproxy + NFS and it "just works(tm)" if
>    you install gssproxy.  Otherwise you get svcgssd + NFS.
>    (This is how I understood Neil Brown)
>  * sysvinit: Business as usual either way.
>
>
> So granting gssproxy will:
>
>  * Provide systemd users with NFS + gssproxy if they opt-in to it
>    (by installing it)
>  * Provide sysvinit users gssproxy and if they want to use it with
>    NFS, they may have to tweak things themselves
>  * Not cause any issues for neither systemd users nor sysvinit users
>    just by installing it.
>  * enable users to get gssproxy which is not deprecated (unlike the
>    existing svcgssd)
>
> Is the above correct? And you are happy with gssproxy/0.5.1-2 as it is?

That sounds right.  And yes.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web