Bug 7718 - tl-setup fails to detect nfs support on modern distributions
Summary: tl-setup fails to detect nfs support on modern distributions
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server Installer (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: Pierre Ossman
URL:
Keywords: relnotes, samuel_tester
Depends on:
Blocks:
 
Reported: 2021-06-01 09:43 CEST by Pierre Ossman
Modified: 2021-06-03 16:53 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2021-06-01 09:43:06 CEST
The way tl-setup detects if the system supports NFS is very fragile as it checks for specific error messages from the mount command. This fragile system is now broken as mount now prints:

> $ sudo mount -t nfs / / 
> mount: /: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.

This is not among our expected error messages so we incorrectly assume the system supports NFS.

This problem exists on at least RHEL 8, Fedora 34 and Ubuntu 20.04.
Comment 1 Pierre Ossman cendio 2021-06-01 12:48:11 CEST
This change was introduced in v2.30, back in 2017. This is the specific commit:

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=e1706a6783c8b63fb66c4a065ad8ee3807bb5f2d

Out of the current distributions only RHEL 7 has anything older. Even SLES 12 has v2.33.
Comment 2 Pierre Ossman cendio 2021-06-01 13:26:19 CEST
Instead of the current fragile method we should be able to check for /sbin/mount.nfs. POSIX doesn't require this to exist, but util-linux has always required it and this is what the current documentation says:

> For most types all the mount program has to do is issue a simple mount(2)
> system call, and no detailed knowledge of the filesystem type is required. For
> a few types however (like nfs, nfs4, cifs, smbfs, ncpfs) ad hoc code is 
> necessary. The nfs, nfs4, cifs, smbfs, and ncpfs filesystems have a separate 
> mount program. In order to make it possible to treat all types in a uniform
> way, mount will execute the program /sbin/mount.TYPE (if that exists) when 
> called with type TYPE.

As such it seems unlikely this will change in the future.
Comment 4 Pierre Ossman cendio 2021-06-01 13:53:32 CEST
Detection now works correctly. Tested both with NFS support missing and available on RHEL 8 and Ubuntu 20.04 (for a total of four test runs).
Comment 5 Samuel Mannehed cendio 2021-06-03 16:53:59 CEST
Tested tl-setup on Ubuntu 18.04:

 ✓ The NFS module showed properly with missing packages in text mode
 ✓ The NFS module showed properly with missing packages in GUI mode
 ✓ The following packages were successfully installed:

    nfs-common
    libtirpc1
    keyutils
    rpcbind
    libnfsidmap2

 ✓ Local drives work
 ✓ The NFS module did not show once the packages were available

And Ubuntu 21.04:

 ✓ The NFS module showed properly with missing packages in text mode
 ✓ The NFS module showed properly with missing packages in GUI mode
 ✓ The following packages were successfully installed:

     nfs-common
     keyutils
     rpcbind
     libnfsidmap2

 ✓ Local drives work
 ✓ The NFS module did not show once the packages were available

And RHEL7:

 ✓ The NFS module showed properly with missing packages in text mode
 ✓ The NFS module showed properly with missing packages in GUI mode
 ✓ The following packages were successfully installed:

     nfs-utils
     gssproxy
     keyutils
     libbasicobjects
     libcollection
     libevent
     libini_config
     libnfsidmap
     libpath_utils
     libref_array
     libverto-libevent
     quota
     quota-nls
     rpcbind
     tcp_wrappers

 ✓ Local drives work
 ✓ The NFS module did not show once the packages were available

Note You need to log in before you can comment on or make changes to this bug.