nfs-utils update status

Thu Feb 10 13:54:18 UTC 2022

Hi,

I just wrote a lengthy email to a debian bug
(https://bugs.debian.org/1005236) and thought I should share it here
too. CCing ubuntu-devel@ since this is not an Ubuntu Server package.

This is the current situation with nfs-utils regarding LP bug
#1878601[1]. I guess the most important part is how to handle the
migration of /etc/default/nfs-* to /etc/nfs.conf, and changes in
general, considering the next ubuntu release is an LTS. Details in the
text below.

"""
I've been looking at the exp package lately, since I'm trying to
update[1] the ubuntu nfs-utils package as well, which we neglected for
many releases.

There are upstream changes, and packaging changes, and a question on
how to handle upgrades.

src:libnfsidmap and src:libnfsidmap-regex were pulled[2][3] into
upstream's nfs-utils (in 2017 and 2020, respectively), which deprecate
those source packages in debian and ubuntu. libnfsidmap actually
forked, and got some new features like LDAP_tls_reqcert config
support[4] and SASL binds[5] in its new home in nfs-utils, for
example, besides plenty of fixes.

Upstream's most visible change is probably the configuration. Instead
of a complicated mechanism to source different configuration files
(/etc/sysconfig in RH, /etc/default/nfs-* in debian/ubuntu), and then
adjust command-line options to all the different daemons, upstream now
changed the daemons themselves to read a new /etc/nfs.conf ini-style
config file[6]. Fedora has a python conversion script[7] that they use
as a one-shot systemd service unit[8]. I played[9] with it a little
and we can easily make it work with debian/ubuntu, and that opens up
some paths for us to handle the migration.

Maybe the only reason to keep the /etc/default/nfs-* files is for sysv
initscripts, to be able to run or not a particular service
(NEED_<foo>=yes|no), if that's still an objective. For systemd, it
will be the usual systemctl enable/disable/mark/unmask.

The old nfs-config.service unit is gone, since there is no need to
generate an aggregated config file for the different systemd units to
source and adjust command line options.

The old libnfsidmap2 package unfortunately has an incorrect major
number, it should have been libnfsidmap0 (the library it carries is
.so.0.3.0 and has a soname of 0). Maybe there is some history behind
this. That creates the odd situation now with the new one, which is
libnfsidmap1. Reminds me of the pcre2/pcre3 situation, where pcre2 is
newer.

There is a new service, nfsdcld, a client tracking daemon, used in
NFSv4. It's just an upgrade from what was called "legacy tracking" in
old kernels, then got replaced by "nfsdcltrack", but that one isn't
container-friendly, and now we have nfsdcld.

NFS, as usual, has many intertwined services, and I'm just happy that
all the systemd units seem to have correct declarations and that it
"just works", so far at least in my testing. But corner cases are for
sure there somewhere. I tested one, where nfs was exporting an iscsi
mounted filesystem, and in older versions that would hang the boot of
the server, but that worked, phew. That sounded exactly like a "corner
case".

Finally, the reverse dependencies need to be rebuilt and checked that
they still work. In Ubuntu, that's nfs-ganesha and sssd, and they at
least build, I haven't checked Debian.

So, my summary:
- it's my opinion that debian and ubuntu need the new version sooner
rather than later. I'm actively working on bringing it into ubuntu,
based on the exp package from debian. My branch is currently at [10],
with a PPA at [11]. The delta we had was basically zeroed, due to a
combination of upstream changes and debian changes.
- we need a plan for an upgrade path. Some choices:
  - do nothing but release notes
  - detect if /etc/default/nfs-* have changes, and warn in that case,
asking the user to move the changes over to /etc/nfs.conf
  - to help with above, also ship fedora's script and let the user
know it exists and could be used. Maybe even run it and place the
output somewhere temporary for analysis
  - actually run fedora's conversion script in postinst, and let the
user know it was done and ask them to double check
- old source packages (src:libnfsidmap and src:libnfsidmap-regex) need
to be removed/obsoleted. I think it's safe to say upstream libnfsidmap
is gone, but libnfsidmap-regex still seems active. We *could* just not
build nfs-utils's regex plugin, and use src:libnfsidmap-regex, but the
libnfsidmap history has shown that at least in that case, nfs-utils'
implementation has diverged over time.

Cheers!

1. https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1878601
2. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=1ea6d9231f839b968adb44eaf98b363f436cb1d5
3. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
4. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=d77ee0f18c0e0658f892932600c38c346c4d5337
5. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=1699fc34fe74ceda67e45453890a654c59f2b9e3
6. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=2662e1ba98707014b6167e1e5bd3162d6d8f52af
7. https://src.fedoraproject.org/rpms/nfs-utils/blob/rawhide/f/nfsconvert.py
8. https://src.fedoraproject.org/rpms/nfs-utils/blob/rawhide/f/nfs-convert.service
9. https://code.launchpad.net/~ahasenack/+git/nfsconvert
10. https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils
11. https://launchpad.net/~ahasenack/+archive/ubuntu/nfs-utils-merge/
"""