Has anyone managed to make NoMachine server (or something similar) play nice with Silverblue? I tried to install it as an rpm overlay a while ago, and never quite got it working, and I’m considering revisiting it, but I figured I’d jump out there and ask if anyone has a decent local-network remote desktop solution for Silveblue working?
Yes. You can attempt to manually install the tar to /usr/local/NX or /opt, and then copy/fix the service and .desktop files
The reason it doesn’t work when using the overlay is because NoMachine tries to write it’s log files to /usr/NX. I raised a bug report with them but they didn’t see anything wrong with it.
Actually, /usr being read only is fully compliant with the FHS. NoMachine writing to /usr is a violation of the FHS.
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Well although the FHS is somewhat out-of-date (as it doesn’t e.g. account for the /usr merge), the systemd filesystem hierarchy specification does say:
Vendor-supplied operating system resources. Usually read-only, but this is not required. Possibly shared between multiple hosts. This directory should not be modified by the administrator, except when installing or removing vendor-supplied packages.
This is why package managers generally have a fit if you do anything inside /usr itself that they haven’t tracked. (Also why you should never use sudo pip, because it does try to write here and has a tendency to overwrite system Python libraries with incorrect versions.)
/usr/local, on the other hand, generally should be RW (and it is on Silverblue), since that’s where system-global installations that are not managed by the package manager should go.
Based on both the FHS and the systemd specification, NoMachine should write logs to /var and configuration data to /etc or /var/lib.
Well although the FHS is somewhat out-of-date (as it doesn’t e.g. account
for the /usr merge), the systemd filesystem hierarchy specification [does say]
(file-hierarchy):
Vendor-supplied operating system resources. Usually read-only, but
this is not required. Possibly shared between multiple hosts. This
directory should not be modified by the administrator, except when
installing or removing vendor-supplied packages.
This is why package managers generally have a fit if you do anything inside
/usr itself that they haven’t tracked. (Also why you should never use sudo pip, because it does try to write here and has a tendency to overwrite
system Python libraries with incorrect versions.)
/usr/local, on the other hand, generally should be RW (and it is on
Silverblue), since that’s where system-global installations that are not
managed by the package manager should go.
Based on both the FHS and the systemd specification, NoMachine should write
logs to /var and configuration data to /etc or /var/lib.
/usr is not a valid place for placing log files, that in itself is a violation of the FHS. You can’t complain that Silverblue breaks the FHS, by having it read-only, which it doesn’t, then say it’s okay for apps to blatantly break it by placing their log files in what is effectively the Linux equivalent of system32, that has no guarantee to be rw.
The statement “when installing or removing vendor-supplied packages” is referring to the actions of the vendor’s package manager (in this case, rpm-ostree or dnf), not the actions of the installed packages themselves, especially after the install is already completed, to store log data of all things (which again shouldn’t be in /usr anyway).
If this were the “Linux equivalent of system32” (it is not, the kernel doesn’t
care about what’s in the filesystem), or if it were the “[GNU/Linux]
equivalent of system32” then it would still be writable. system32 has files
which are only written by the running system.
Anyway, you can just do a bind mount to get this working, that will probably
work on Silverblue too, unless it does some voodoo I’m not aware of, for
example a kernel module or SELinux policy.
As to “decent local-network remote desktop solution”, Fedora packages x2go, which is an open version of nomachine afaik. It works very well for me, even for desktops 3000 miles away. And for a “local-network” solution, there is always ssh -X, which also works quite well on my gigabit LAN.