Downstream bug: https://bugs.gentoo.org/928526
In Gentoo we allow disabling NFSv3 support, which entails nothing more
than not installing `nfs-server.service`. This has uncovered an issue
that many .service files reference `nfs-server.service` explicitly,
making them unusable with `nfsv4-server.service`.
> server ~ # grep nfs-server.service $(qlist nfs-utils | grep service)
> /usr/lib/systemd/system/rpc-statd-notify.service:After=nfs-server.service
> /usr/lib/systemd/system/nfs-mountd.service:BindsTo=nfs-server.service
> /usr/lib/systemd/system/rpc-svcgssd.service:PartOf=nfs-server.service
> /usr/lib/systemd/system/fsidd.service:Before=nfs-mountd.service nfs-server.service
> /usr/lib/systemd/system/fsidd.service:RequiredBy=nfs-mountd.service nfs-server.service
> /usr/lib/systemd/system/nfs-idmapd.service:BindsTo=nfs-server.service
The only service file that depends on nfsv4-server is nfsv4-exportd:
> server ~ # grep nfsv4-server.service $(qlist nfs-utils | grep service)
> /usr/lib/systemd/system/nfsv4-exportd.service:BindsTo=nfsv4-server.service
How should `nfsv4-server.service` be used?
Thanks,
Matt
Hello,
On 4/5/24 10:29 AM, Matt Turner wrote:
> Downstream bug: https://bugs.gentoo.org/928526
>
> In Gentoo we allow disabling NFSv3 support, which entails nothing more
> than not installing `nfs-server.service`. This has uncovered an issue
> that many .service files reference `nfs-server.service` explicitly,
> making them unusable with `nfsv4-server.service`.
Very interesting... not supporting v3... Just curious as to why?
>
>> server ~ # grep nfs-server.service $(qlist nfs-utils | grep service)
>> /usr/lib/systemd/system/rpc-statd-notify.service:After=nfs-server.service
>> /usr/lib/systemd/system/nfs-mountd.service:BindsTo=nfs-server.service
>> /usr/lib/systemd/system/rpc-svcgssd.service:PartOf=nfs-server.service
>> /usr/lib/systemd/system/fsidd.service:Before=nfs-mountd.service nfs-server.service
>> /usr/lib/systemd/system/fsidd.service:RequiredBy=nfs-mountd.service nfs-server.service
>> /usr/lib/systemd/system/nfs-idmapd.service:BindsTo=nfs-server.service
>
> The only service file that depends on nfsv4-server is nfsv4-exportd:
>
>> server ~ # grep nfsv4-server.service $(qlist nfs-utils | grep service)
>> /usr/lib/systemd/system/nfsv4-exportd.service:BindsTo=nfsv4-server.service
>
> How should `nfsv4-server.service` be used?
The idea was to make nfs-utils have a smaller footprint for containers.
No rpcbind, lockd, statd etc.. exportd is to replace mountd
and only accept v4 mounts.
Unfortunately the idea of having a nfsv4 only server
did not go over well with upstream.
But, I will be more than willing to work with you to make it work.
steved.
>
> Thanks,
> Matt
>
On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]> wrote:
>
> Hello,
>
> On 4/5/24 10:29 AM, Matt Turner wrote:
> > Downstream bug: https://bugs.gentoo.org/928526
> >
> > In Gentoo we allow disabling NFSv3 support, which entails nothing more
> > than not installing `nfs-server.service`. This has uncovered an issue
> > that many .service files reference `nfs-server.service` explicitly,
> > making them unusable with `nfsv4-server.service`.
> Very interesting... not supporting v3... Just curious as to why?
I don't think there's a particularly compelling reason. I guess it
lets you avoid a dependency on rpcbind.
> >> server ~ # grep nfs-server.service $(qlist nfs-utils | grep service)
> >> /usr/lib/systemd/system/rpc-statd-notify.service:After=nfs-server.service
> >> /usr/lib/systemd/system/nfs-mountd.service:BindsTo=nfs-server.service
> >> /usr/lib/systemd/system/rpc-svcgssd.service:PartOf=nfs-server.service
> >> /usr/lib/systemd/system/fsidd.service:Before=nfs-mountd.service nfs-server.service
> >> /usr/lib/systemd/system/fsidd.service:RequiredBy=nfs-mountd.service nfs-server.service
> >> /usr/lib/systemd/system/nfs-idmapd.service:BindsTo=nfs-server.service
> >
> > The only service file that depends on nfsv4-server is nfsv4-exportd:
> >
> >> server ~ # grep nfsv4-server.service $(qlist nfs-utils | grep service)
> >> /usr/lib/systemd/system/nfsv4-exportd.service:BindsTo=nfsv4-server.service
> >
> > How should `nfsv4-server.service` be used?
> The idea was to make nfs-utils have a smaller footprint for containers.
> No rpcbind, lockd, statd etc.. exportd is to replace mountd
> and only accept v4 mounts.
Seems like we would just need to modify the build system to not
install `nfs-server.service` and other NFSv3-only service files and
modify the remaining service files to reference nfsv4-server.service
instead?
> Unfortunately the idea of having a nfsv4 only server
> did not go over well with upstream.
Which upstream do you mean? nfs-utils, Linux kernel?
> But, I will be more than willing to work with you to make it work.
Thanks!
On 4/6/24 6:26 PM, Matt Turner wrote:
> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]> wrote:
>>
>> Hello,
>>
>> On 4/5/24 10:29 AM, Matt Turner wrote:
>>> Downstream bug: https://bugs.gentoo.org/928526
>>>
>>> In Gentoo we allow disabling NFSv3 support, which entails nothing more
>>> than not installing `nfs-server.service`. This has uncovered an issue
>>> that many .service files reference `nfs-server.service` explicitly,
>>> making them unusable with `nfsv4-server.service`.
>> Very interesting... not supporting v3... Just curious as to why?
>
> I don't think there's a particularly compelling reason. I guess it
> lets you avoid a dependency on rpcbind.
And the other baggage that comes with v3... but
I think it will be difficult to deprecate it.
But it might be fun trying :-)
>
>>>> server ~ # grep nfs-server.service $(qlist nfs-utils | grep service)
>>>> /usr/lib/systemd/system/rpc-statd-notify.service:After=nfs-server.service
>>>> /usr/lib/systemd/system/nfs-mountd.service:BindsTo=nfs-server.service
>>>> /usr/lib/systemd/system/rpc-svcgssd.service:PartOf=nfs-server.service
>>>> /usr/lib/systemd/system/fsidd.service:Before=nfs-mountd.service nfs-server.service
>>>> /usr/lib/systemd/system/fsidd.service:RequiredBy=nfs-mountd.service nfs-server.service
>>>> /usr/lib/systemd/system/nfs-idmapd.service:BindsTo=nfs-server.service
>>>
>>> The only service file that depends on nfsv4-server is nfsv4-exportd:
>>>
>>>> server ~ # grep nfsv4-server.service $(qlist nfs-utils | grep service)
>>>> /usr/lib/systemd/system/nfsv4-exportd.service:BindsTo=nfsv4-server.service
>>>
>>> How should `nfsv4-server.service` be used?
>> The idea was to make nfs-utils have a smaller footprint for containers.
>> No rpcbind, lockd, statd etc.. exportd is to replace mountd
>> and only accept v4 mounts.
>
> Seems like we would just need to modify the build system to not
> install `nfs-server.service` and other NFSv3-only service files and
> modify the remaining service files to reference nfsv4-server.service
> instead?
Or we break up nfs-utils into 5 packages... nfs-common, which would
be used by nfsv3-client, nfsv3-sever, nfsv4-client and nfsv4-server.
Not clear other distros would be happy with that.
>
>> Unfortunately the idea of having a nfsv4 only server
>> did not go over well with upstream.
>
> Which upstream do you mean? nfs-utils, Linux kernel?
The NFS server maintainers... they didn't push back hard
but the didn't it was necessary.
>
>> But, I will be more than willing to work with you to make it work.
>
> Thanks!
>
We have a virtual Bakeathon [1] coming at the end of the month
Maybe this would be a topic for Talks at 2pm [2].
steved.
[1] http://www.nfsv4bat.org/Events/2023/Oct/BAT/index.html
[2]
https://docs.google.com/spreadsheets/d/1-wmA_t4fp7X5WvshYPnB-0vHeMpoQMohim2Kb7Gx9z0/edit#gid=1920779269
> On Apr 7, 2024, at 10:45 AM, Steve Dickson <[email protected]> wrote:
>
> On 4/6/24 6:26 PM, Matt Turner wrote:
>> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]> wrote:
>
>>> Unfortunately the idea of having a nfsv4 only server
>>> did not go over well with upstream.
>> Which upstream do you mean? nfs-utils, Linux kernel?
> The NFS server maintainers... they didn't push back hard
> but the didn't it was necessary.
I'm sympathetic to some folks wanting a narrower footprint,
but I think we'd like to have support for all versions
packaged and available for an NFS server administrator,
right out of the shrink-wrap. Currently, most installations
want to deploy v3 and v4, so we should cater to the common
case.
As I recall, the NFSv4-only mechanism proposed at the time
was pretty clunky. If you have alternative ideas, I'm happy
to consider them. But let's recognize that an NFSv4-only
deployment is the special case here, and not make life more
difficult for everyone else, especially folks who might
start with an NFSv4-only deployment and need to add NFSv3
later, for whatever crazy reason.
The nfs-server unit should be made to do the right thing
no matter what is installed on the system and no matter what
is in /etc/nfs.conf. I don't see why screwing with the
distro packaging is needed?
--
Chuck Lever
On 4/7/24 12:29 PM, Chuck Lever III wrote:
>
>> On Apr 7, 2024, at 10:45 AM, Steve Dickson <[email protected]> wrote:
>>
>> On 4/6/24 6:26 PM, Matt Turner wrote:
>>> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]> wrote:
>>
>>>> Unfortunately the idea of having a nfsv4 only server
>>>> did not go over well with upstream.
>>> Which upstream do you mean? nfs-utils, Linux kernel?
>> The NFS server maintainers... they didn't push back hard
>> but the didn't it was necessary.
>
> I'm sympathetic to some folks wanting a narrower footprint,
> but I think we'd like to have support for all versions
> packaged and available for an NFS server administrator,
> right out of the shrink-wrap. Currently, most installations
> want to deploy v3 and v4, so we should cater to the common
> case.
Which we have now... nfs-utils.
>
> As I recall, the NFSv4-only mechanism proposed at the time
> was pretty clunky. If you have alternative ideas, I'm happy
> to consider them. But let's recognize that an NFSv4-only
> deployment is the special case here, and not make life more
> difficult for everyone else, especially folks who might
> start with an NFSv4-only deployment and need to add NFSv3
> later, for whatever crazy reason.
I'm not sure what you mean by "clunky"... The only addition
was exportd which mirrors the v4 code/support in mountd.
>
> The nfs-server unit should be made to do the right thing
> no matter what is installed on the system and no matter what
> is in /etc/nfs.conf. I don't see why screwing with the
> distro packaging is needed?
nfs-server.service and nfsv4-server.service were never
meant to be compatible... One or the other... Maybe
that was the mistake.
steved.
On 8/4/24 00:29, Chuck Lever III wrote:
>> On Apr 7, 2024, at 10:45 AM, Steve Dickson <[email protected]> wrote:
>>
>> On 4/6/24 6:26 PM, Matt Turner wrote:
>>> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]> wrote:
>>>> Unfortunately the idea of having a nfsv4 only server
>>>> did not go over well with upstream.
>>> Which upstream do you mean? nfs-utils, Linux kernel?
>> The NFS server maintainers... they didn't push back hard
>> but the didn't it was necessary.
> I'm sympathetic to some folks wanting a narrower footprint,
> but I think we'd like to have support for all versions
> packaged and available for an NFS server administrator,
> right out of the shrink-wrap. Currently, most installations
> want to deploy v3 and v4, so we should cater to the common
> case.
I have to say I agree with Chuck.
Over the years I have had to deal with the consequences of dropping support
for NFS versions. So far that has been at the distribution level but if it
had been at the upstream level I would have had a much harder time of it.
am-utils for example, yes it's maybe not a good case because it lacks
upstream
support nowadays, but I still work on it. It uses an NFS client
implementation
to provide automount support and NFS v2 was ideal for the localhost
server but
v2 support was removed from distro kernel builds and I had to implement
an NFS
v3 server for this which was very much overkill.
Now there's talk of dropping v3 support which will spell the end of
am-utils,
unnecessarily IMHO.
I can understand the urge to drop v2 but there are still many v3 users
so I wonder
about the wisdom of even thinking about dropping v3 support and multiple
packages,
IMHO, will introduce an unnecessary downstream overhead. It's hard
enough to keep
up with the workload as it is.
I also gat that mostly what I'm saying has happened at distro level but
please don't
go down this path upstream too.
Ian
>
> As I recall, the NFSv4-only mechanism proposed at the time
> was pretty clunky. If you have alternative ideas, I'm happy
> to consider them. But let's recognize that an NFSv4-only
> deployment is the special case here, and not make life more
> difficult for everyone else, especially folks who might
> start with an NFSv4-only deployment and need to add NFSv3
> later, for whatever crazy reason.
>
> The nfs-server unit should be made to do the right thing
> no matter what is installed on the system and no matter what
> is in /etc/nfs.conf. I don't see why screwing with the
> distro packaging is needed?
>
> --
> Chuck Lever
>
>
Hey Ian!
Good to hear from you!!
On 4/7/24 7:57 PM, Ian Kent wrote:
> On 8/4/24 00:29, Chuck Lever III wrote:
>>> On Apr 7, 2024, at 10:45 AM, Steve Dickson <[email protected]> wrote:
>>>
>>> On 4/6/24 6:26 PM, Matt Turner wrote:
>>>> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]> wrote:
>>>>> Unfortunately the idea of having a nfsv4 only server
>>>>> did not go over well with upstream.
>>>> Which upstream do you mean? nfs-utils, Linux kernel?
>>> The NFS server maintainers... they didn't push back hard
>>> but the didn't it was necessary.
>> I'm sympathetic to some folks wanting a narrower footprint,
>> but I think we'd like to have support for all versions
>> packaged and available for an NFS server administrator,
>> right out of the shrink-wrap. Currently, most installations
>> want to deploy v3 and v4, so we should cater to the common
>> case.
>
> I have to say I agree with Chuck.
Yes... I definitely see Chuck's point.
>
>
> Over the years I have had to deal with the consequences of dropping support
>
> for NFS versions. So far that has been at the distribution level but if it
>
> had been at the upstream level I would have had a much harder time of it.
>
>
> am-utils for example, yes it's maybe not a good case because it lacks
> upstream
>
> support nowadays, but I still work on it. It uses an NFS client
> implementation
>
> to provide automount support and NFS v2 was ideal for the localhost
> server but
>
> v2 support was removed from distro kernel builds and I had to implement
> an NFS
>
> v3 server for this which was very much overkill.
My apologies... That was me. Removing v2 cut down
the testing matrix two-fold. v3 was there to replace
v2... I just did the obvious.
>
>
> Now there's talk of dropping v3 support which will spell the end of
> am-utils,
>
> unnecessarily IMHO.
Yes... I was poking the bear when I said "deprecate" v3. Knowing
full well it would go over like a lead balloon :-)
But coming up with a way of separating the protocols
so only one can be used (client or server) in VMs or
containers is a bad idea?
>
>
> I can understand the urge to drop v2 but there are still many v3 users
> so I wonder
>
> about the wisdom of even thinking about dropping v3 support and multiple
> packages,
>
> IMHO, will introduce an unnecessary downstream overhead. It's hard
> enough to keep
>
> up with the workload as it is.
>
>
> I also gat that mostly what I'm saying has happened at distro level but
> please don't
>
> go down this path upstream too.
You are right... this is distro level conversation but
upstream should be involved... IMHO.
steved.
>
>
> Ian
>
>>
>> As I recall, the NFSv4-only mechanism proposed at the time
>> was pretty clunky. If you have alternative ideas, I'm happy
>> to consider them. But let's recognize that an NFSv4-only
>> deployment is the special case here, and not make life more
>> difficult for everyone else, especially folks who might
>> start with an NFSv4-only deployment and need to add NFSv3
>> later, for whatever crazy reason.
>>
>> The nfs-server unit should be made to do the right thing
>> no matter what is installed on the system and no matter what
>> is in /etc/nfs.conf. I don't see why screwing with the
>> distro packaging is needed?
>>
>> --
>> Chuck Lever
>>
>>
>
On 8/4/24 19:01, Steve Dickson wrote:
> Hey Ian!
>
> Good to hear from you!!
>
> On 4/7/24 7:57 PM, Ian Kent wrote:
>> On 8/4/24 00:29, Chuck Lever III wrote:
>>>> On Apr 7, 2024, at 10:45 AM, Steve Dickson <[email protected]> wrote:
>>>>
>>>> On 4/6/24 6:26 PM, Matt Turner wrote:
>>>>> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]>
>>>>> wrote:
>>>>>> Unfortunately the idea of having a nfsv4 only server
>>>>>> did not go over well with upstream.
>>>>> Which upstream do you mean? nfs-utils, Linux kernel?
>>>> The NFS server maintainers... they didn't push back hard
>>>> but the didn't it was necessary.
>>> I'm sympathetic to some folks wanting a narrower footprint,
>>> but I think we'd like to have support for all versions
>>> packaged and available for an NFS server administrator,
>>> right out of the shrink-wrap. Currently, most installations
>>> want to deploy v3 and v4, so we should cater to the common
>>> case.
>>
>> I have to say I agree with Chuck.
> Yes... I definitely see Chuck's point.
>
>>
>>
>> Over the years I have had to deal with the consequences of dropping
>> support
>>
>> for NFS versions. So far that has been at the distribution level but
>> if it
>>
>> had been at the upstream level I would have had a much harder time of
>> it.
>>
>>
>> am-utils for example, yes it's maybe not a good case because it lacks
>> upstream
>>
>> support nowadays, but I still work on it. It uses an NFS client
>> implementation
>>
>> to provide automount support and NFS v2 was ideal for the localhost
>> server but
>>
>> v2 support was removed from distro kernel builds and I had to
>> implement an NFS
>>
>> v3 server for this which was very much overkill.
> My apologies... That was me. Removing v2 cut down
> the testing matrix two-fold. v3 was there to replace
> v2... I just did the obvious.
Hehe, Yeah, I know.
But this seemed like a good opportunity to let you know these changes
can be rather
inconvienient for some so that you have all the information when making
changes at
a later time.
Even removing UDP support from the Fedora kernel config caused a problem
for me.
Again, am-utils, it had a bug with it's background processing that was
causing slow mounts
that, ASAICS, could only be fixed by using UDP (which is sensible for a
service running or
localhost) or re-writting the entire application to use threads, a good
idea but way too much
work.
OTOH we always knew the amd application would die in time to come so it
isn't such a big
deal I suppose.
>
>>
>>
>> Now there's talk of dropping v3 support which will spell the end of
>> am-utils,
>>
>> unnecessarily IMHO.
> Yes... I was poking the bear when I said "deprecate" v3. Knowing
> full well it would go over like a lead balloon :-)
>
> But coming up with a way of separating the protocols
> so only one can be used (client or server) in VMs or
> containers is a bad idea?
Yes, that's a bit harder and I think will require a division of the
packages ...
>
>>
>>
>> I can understand the urge to drop v2 but there are still many v3
>> users so I wonder
>>
>> about the wisdom of even thinking about dropping v3 support and
>> multiple packages,
>>
>> IMHO, will introduce an unnecessary downstream overhead. It's hard
>> enough to keep
>>
>> up with the workload as it is.
>>
>>
>> I also gat that mostly what I'm saying has happened at distro level
>> but please don't
>>
>> go down this path upstream too.
> You are right... this is distro level conversation but
> upstream should be involved... IMHO.
Indeed, yes.
Ian
>
> steved.
>
>>
>>
>> Ian
>>
>>>
>>> As I recall, the NFSv4-only mechanism proposed at the time
>>> was pretty clunky. If you have alternative ideas, I'm happy
>>> to consider them. But let's recognize that an NFSv4-only
>>> deployment is the special case here, and not make life more
>>> difficult for everyone else, especially folks who might
>>> start with an NFSv4-only deployment and need to add NFSv3
>>> later, for whatever crazy reason.
>>>
>>> The nfs-server unit should be made to do the right thing
>>> no matter what is installed on the system and no matter what
>>> is in /etc/nfs.conf. I don't see why screwing with the
>>> distro packaging is needed?
>>>
>>> --
>>> Chuck Lever
>>>
>>>
>>
>
On 4/9/24 1:24 PM, Chuck Lever wrote:
> On Sun, Apr 07, 2024 at 02:36:44PM -0400, Steve Dickson wrote:
>> On 4/7/24 12:29 PM, Chuck Lever III wrote:
>>> The nfs-server unit should be made to do the right thing
>>> no matter what is installed on the system and no matter what
>>> is in /etc/nfs.conf. I don't see why screwing with the
>>> distro packaging is needed?
>> nfs-server.service and nfsv4-server.service were never
>> meant to be compatible... One or the other... Maybe
>> that was the mistake.
>
> I remember being uncomfortable with the addition of a second
> "NFS server" unit. If the logic to disable the NFSv3
> components when not in use can fit into nfs-server.service,
> that would be a better solution, IMO.
>
Fair enough... thanks!
steved.
On 4/9/24 1:53 AM, Ian Kent wrote:
> On 8/4/24 19:01, Steve Dickson wrote:
>> Hey Ian!
>>
>> Good to hear from you!!
>>
>> On 4/7/24 7:57 PM, Ian Kent wrote:
>>> On 8/4/24 00:29, Chuck Lever III wrote:
>>>>> On Apr 7, 2024, at 10:45 AM, Steve Dickson <[email protected]> wrote:
>>>>>
>>>>> On 4/6/24 6:26 PM, Matt Turner wrote:
>>>>>> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <[email protected]>
>>>>>> wrote:
>>>>>>> Unfortunately the idea of having a nfsv4 only server
>>>>>>> did not go over well with upstream.
>>>>>> Which upstream do you mean? nfs-utils, Linux kernel?
>>>>> The NFS server maintainers... they didn't push back hard
>>>>> but the didn't it was necessary.
>>>> I'm sympathetic to some folks wanting a narrower footprint,
>>>> but I think we'd like to have support for all versions
>>>> packaged and available for an NFS server administrator,
>>>> right out of the shrink-wrap. Currently, most installations
>>>> want to deploy v3 and v4, so we should cater to the common
>>>> case.
>>>
>>> I have to say I agree with Chuck.
>> Yes... I definitely see Chuck's point.
>>
>>>
>>>
>>> Over the years I have had to deal with the consequences of dropping
>>> support
>>>
>>> for NFS versions. So far that has been at the distribution level but
>>> if it
>>>
>>> had been at the upstream level I would have had a much harder time of
>>> it.
>>>
>>>
>>> am-utils for example, yes it's maybe not a good case because it lacks
>>> upstream
>>>
>>> support nowadays, but I still work on it. It uses an NFS client
>>> implementation
>>>
>>> to provide automount support and NFS v2 was ideal for the localhost
>>> server but
>>>
>>> v2 support was removed from distro kernel builds and I had to
>>> implement an NFS
>>>
>>> v3 server for this which was very much overkill.
>> My apologies... That was me. Removing v2 cut down
>> the testing matrix two-fold. v3 was there to replace
>> v2... I just did the obvious.
>
> Hehe, Yeah, I know.
>
>
> But this seemed like a good opportunity to let you know these changes
> can be rather
>
> inconvienient for some so that you have all the information when making
> changes at
>
> a later time.
Point taken....
>
>
> Even removing UDP support from the Fedora kernel config caused a problem
> for me.
>
>
> Again, am-utils, it had a bug with it's background processing that was
> causing slow mounts
>
> that, ASAICS, could only be fixed by using UDP (which is sensible for a
> service running or
>
> localhost) or re-writting the entire application to use threads, a good
> idea but way too much
>
> work.
>
>
> OTOH we always knew the amd application would die in time to come so it
> isn't such a big
>
> deal I suppose.
Again it was a testing matrix thing... Plus TCP handled network
congestion much better than NFS ever could
>
>
>>
>>>
>>>
>>> Now there's talk of dropping v3 support which will spell the end of
>>> am-utils,
>>>
>>> unnecessarily IMHO.
>> Yes... I was poking the bear when I said "deprecate" v3. Knowing
>> full well it would go over like a lead balloon :-)
>>
>> But coming up with a way of separating the protocols
>> so only one can be used (client or server) in VMs or
>> containers is a bad idea?
>
> Yes, that's a bit harder and I think will require a division of the
> packages ...
Right...
steved.
>
>
>>
>>>
>>>
>>> I can understand the urge to drop v2 but there are still many v3
>>> users so I wonder
>>>
>>> about the wisdom of even thinking about dropping v3 support and
>>> multiple packages,
>>>
>>> IMHO, will introduce an unnecessary downstream overhead. It's hard
>>> enough to keep
>>>
>>> up with the workload as it is.
>>>
>>>
>>> I also gat that mostly what I'm saying has happened at distro level
>>> but please don't
>>>
>>> go down this path upstream too.
>> You are right... this is distro level conversation but
>> upstream should be involved... IMHO.
>
> Indeed, yes.
>
>
> Ian
>
>>
>> steved.
>>
>>>
>>>
>>> Ian
>>>
>>>>
>>>> As I recall, the NFSv4-only mechanism proposed at the time
>>>> was pretty clunky. If you have alternative ideas, I'm happy
>>>> to consider them. But let's recognize that an NFSv4-only
>>>> deployment is the special case here, and not make life more
>>>> difficult for everyone else, especially folks who might
>>>> start with an NFSv4-only deployment and need to add NFSv3
>>>> later, for whatever crazy reason.
>>>>
>>>> The nfs-server unit should be made to do the right thing
>>>> no matter what is installed on the system and no matter what
>>>> is in /etc/nfs.conf. I don't see why screwing with the
>>>> distro packaging is needed?
>>>>
>>>> --
>>>> Chuck Lever
>>>>
>>>>
>>>
>>
>
On Sun, Apr 07, 2024 at 02:36:44PM -0400, Steve Dickson wrote:
> On 4/7/24 12:29 PM, Chuck Lever III wrote:
> > The nfs-server unit should be made to do the right thing
> > no matter what is installed on the system and no matter what
> > is in /etc/nfs.conf. I don't see why screwing with the
> > distro packaging is needed?
> nfs-server.service and nfsv4-server.service were never
> meant to be compatible... One or the other... Maybe
> that was the mistake.
I remember being uncomfortable with the addition of a second
"NFS server" unit. If the logic to disable the NFSv3
components when not in use can fit into nfs-server.service,
that would be a better solution, IMO.
--
Chuck Lever