When trying to install thinlinc-server_4.16.0-3491_amd64.deb, either manually or through ./install-server, the installation will fail with: > 2024-04-19 07:44:45,607: Version to install: 4.16.0-3491_amd64 > 2024-04-19 07:44:45,607: Current version(s): > 2024-04-19 07:44:45,607: Packages to install: thinlinc-server_4.16.0-> 3491_amd64.deb > 2024-04-19 07:44:46,321: Installing package(s): thinlinc-server_4.16.0-3491_amd64.deb > 2024-04-19 07:44:46,423: Warning during installation of '/home/cendio/tl-4.16.0-server/packages/thinlinc-server_4.16.0-3491_amd64.deb': " unable to create '/lib32/libnss_passwdaliases.so.2.dpkg-new' (while processing './lib32/libnss_passwdaliases.so.2'): No such file or directory" > 2024-04-19 07:44:46,452: Installation of packages failed: > 2024-04-19 07:42:48,399: Selecting previously unselected package thinlinc-server. > 2024-04-19 07:42:48,399: (Reading database ... 83184 files and directories currently installed.) > 2024-04-19 07:42:48,399: Preparing to unpack .../thinlinc-server_4.16.0-3491_amd64.deb ... > 2024-04-19 07:42:48,399: Unpacking thinlinc-server (4.16.0-3491) ... > 2024-04-19 07:42:48,399: dpkg: error processing archive /home/cendio/tl-4.16.0-server/packages/thinlinc-server_4.16.0-3491_amd64.deb (--install): > 2024-04-19 07:42:48,399: unable to create '/lib32/libnss_passwdaliases.so.2.dpkg-new' (while processing './lib32/libnss_passwdaliases.so.2'): No such file or directory > 2024-04-19 07:42:48,399: dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > 2024-04-19 07:42:48,399: Errors were encountered while processing: > 2024-04-19 07:42:48,399: /home/cendio/tl-4.16.0-server/packages/thinlinc-> server_4.16.0-3491_amd64.deb Manually creating /lib32 will work around this issue. The package installation and the following tl-setup worked fine.
Creating a symlink from /usr/lib to /lib32 before the installation will fix this on my installations. (Hint: Creating a freshly /lib32 directory will fail with the usrmerge error: ****************************************************************************** * * The base-files package cannot be installed because this system has a * split /usr. * Please install the usrmerge package to convert this system to merged-/usr. * For more information please read https://wiki.debian.org/UsrMerge. * ******************************************************************************) Symlinking the /lib32 is compatible with the recognition system of the base-files package.
Agree. Creating the symlink seems like a better approach to work around this.
Another Idea: Even better will be maybe to remove /lib32/libnss_passwdaliases.so.2 in the next release and on Ubuntu 24.04. Cause the 32bit release has been stopped (sind 18.04) and everything has been consolidated now in ubuntu 24.04 to merged a merge lib in /usr/lib (64 bit).
Just found same! I just created as root, "mkdir /lib32" and the installer completed
(In reply to John Radley from comment #13) > Just found same! > I just created as root, "mkdir /lib32" > and the installer completed Creating the /lib32 is *not* a good idea and breaks the merged /usr system from Debian / Ubuntu See also https://wiki.debian.org/UsrMerge and https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge * dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs. * dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
If none of the distributions in support still use the old /lib*, /bin and /sbin, it should be possible to move the location of those files to /usr/*. Below is the state of a few dists: Ubuntu 20.04 uses /usr/* Ubuntu 18.04 uses /lib* etc (has reached EOL) Debian 10 uses /usr/* RHEL 8 uses /usr/* SLES 15 appears to use /lib* etc, but there are also files under /usr/lib*. If we're lucky, we can use /usr/* without any complications.
We need to look at whether we still need to translate the RHEL-native lib-paths to Debian-native counterparts. That is, translating RHEL:(/lib, /lib64) to Debian:(/lib32, /lib). This path translation has been done by us for a very long time, likely due to a historical difference in file system hierarchy between RHEL and Debian. It is obvious that this is no longer correct under Ubuntu 24.04, where /lib32 (and /usr/lib32) no longer exist. Ubuntu 24.04 now has the same file system hierarchy as RHEL with respect to library paths: > /lib -> /usr/lib > /lib64 -> /usr/lib64 > /usr/lib > /usr/lib64 If we are lucky, it may be possible to skip the path translation entirely, if the distributions we support, all have /lib and lib64 present, either as dirs or symbolic lincs to /usr/lib*.
Tested installing file libnss_passwdaliases.so.2 under /usr/lib/ and /usr/lib64 on SLES 15, and passwdaliases works correctly! The steps I followed are described below (basically the steps under "Using Smart Card Public Key Authentication" -> "Automatic Connection" in the TAG [1]): 1. In /etc/nsswitch.conf, add 'passwdaliases' to the following in line: > passwd: compat passwdaliases 2. In /etc/passwdaliases, add <username alias>:<uid> on a new row: > cendio2:1000 For testing 64-bit, its enough that command 'getent' points to the correct user: > $ getent passwd cendio2 > cendio:x:1000:100:Cendio:/home/cendio:/bin/bash For testing 32-bit, I used the following C-program and compiled it as 32-bit. > #include <stdio.h> > #include <pwd.h> > int main() { > char* user = "cendio2"; > struct passwd* pw; > pw = getpwnam(user); > printf( "%s uname: %s\n", user, pw->pw_name ); > return 0; > } > > $ gcc -m32 test.c > $ ./a.out > cendio2 uname: cendio [1]: https://www.cendio.com/resources/docs/tag-devel/html/authentication_scpublickey.html
Checked the client, it does not add files in any of the outdated directories, so no changes needed there. Removing the acceptance criteria regarding the client since it is not relevant for this bug: > SHOULD: > * The client should place relevant files under /usr/lib*, /usr/bin and /usr/sbin, > and no longer use /lib*, /bin or /sbin
(In reply to Alexander Zeijlon from comment #16) Turns out that we still need to assume that /usr/lib32 is the correct location to put 32-bit libraries on Debian and Ubuntu. I semi-verified this by installing the 32-bit library, lib32stdc++6, packaged in the default repositories on Ubuntu 24.04. This resulted in some files being installed in /usr/lib32 (which did not previously exist). There was also a symlink created, "/lib32 -> /usr/lib32", during install.
It is a bit strange that the installer fails if /lib32 does not exist to begin with. Normally, apt/dpkg will create directories when installing, if they do not already exist. If we just make sure that our libnss_passwdaliases.so.2 is installed to /usr/lib32 instead of /lib32, the installation procedure succeeds, even if /usr/lib32 does not exist before running the installer.
There are only a few files that will be affected by this move. * libnss_passwdaliases.so.2 This file exists under /lib and /lib64 on rpm-system, and under /lib32 and /lib on deb-systems. * systemd files On rpm systems, these are placed in /usr/lib. On deb-systems, these files are instead placed in /lib/systemd. On modern Ubuntu:s (v. 20.04 and newer), /lib and friends are symlinks to /usr/lib etc, so to see the issue I used Ubuntu 18.04.
Tested that file libnss_passwdaliases.so.2 works as expected after the move on SLES 15 (see comment 17 for more details). Tested that systemd and libnss_passwdaliases.so.2 is installed in /usr/ on Fedora 39 and Ubuntu 18.04. Also tested uninstalling on those dists, and could see that the files were removed correctly. Did not test upgrading the server. Last thing to fix before this bug is fully done is to add an autotest to prevent files from being placed in outdated directories.
Added auto tests for both .rmp-files and .deb-files that verifies that we are not trying to install files in the legacy paths /bin, /sbin and /lib*.
On older distributions not supporting the move to /usr/, it should be possible to get the old behaviour by creating a symlink in /lib*. However, I tested installing the server on Ubuntu 18.04 RHEL 7 and SLES 12 and followed the steps for 'getent' in comment 17. Ubuntu and RHEL worked out of box, and I didn't get SLES working for the latest build or for the 4.16.0 server, so that issue is not affected by this bug. I didn't go further back than that, but in theory, this is how the symlink could be created if needed Find the offending files: > find /usr/ -name *passwdalias* > find /usr/ -name *vsm*service > find /usr/ -name *tlweb*service Create symlinks. The symlinks should basically have the same path but without prefix "/usr", like the example below: > sudo ln -s /usr/lib/libnss_passwdaliases.so.2 /lib/libnss_passwdaliases.so.2
Tested this bug using server build #3646 on dists Ubuntu20.04 Ubuntu22.04 Ubuntu24.04 Debian12 SLES15 RHEL9 No files appears to be installed in legacy root directories, from the server installation. Made use of the test case suggestions in comment #17, and also tested via Python's pwd module. Sanity checked by renaming the libfile libnss_passwdaliases.so.2 which resulted in negative results so it is evidently working as intended. This so-file is consistently installed in the correct /usr/-dirs across all dists. Furthermore, the systemd services are placed in correct directories and are working as intended. MUST: > The server should place relevant files under /usr/lib*, /usr/bin and /usr/sbin, and no longer use /lib*, /bin or /sbin. ✅ Check. > When uninstalling ThinLinc, files should be removed: > - if they exist under /lib*, /bin or /sbin > - if they exist under /usr/lib*, /usr/bin and /usr/sbin ✅ Check. > Upgrading ThinLinc should not leave leftover files in /lib*, /bin or /sbin. ✅ Check. SHOULD: > There should be an autotest for preventing files to be placed in /lib*, /bin or /sbin ✅ Check. This bug appears to be resolved as the server can be installed without issues on Ubuntu24.04 with no regressions regarding other dists. Closing.
