> I'm not familiar of changes in nfs-utils. Given the major version update and > the > fact that both Debian 11/Sid haven't included v2, I guess it's either not > well- > tested on Debian, or has breaking changes that most people don't want?
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/
