#1

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?

Thanks in advance! :slight_smile:

#2

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.

1 Like
#3

Ahh I hadn’t tried it that way! I’ll give that a try tomorrow, thanks! :blush:

#4

I can’t really see anything wrong with this, why doesn’t that work on
Silverblue?

#5

Because the NoMachine service tries to write its log and configuration files to /usr/NX

Which is read-only.

1 Like
#6

Why in the world would /usr be read-only? That breaks the FHS.

#7

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.

https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#THEUSRHIERARCHY

/usr on Silverblue is immutable and managed by OSTree, therefore its read-only for the most part.

2 Likes
#8

I’m going to have to see when that was last edited, because that would make
every real distro in violation of the FHS.

#9

Whilst I question your definition of a “real distro”, here’s the latest version from 2015.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html

#10

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.

2 Likes
#11

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]
(https://www.freedesktop.org/software/systemd/man/file-hierarchy.html):

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.

Not at all, NoMachine is a vendor-supplied RPM.

#12

A real disto would be something like Fedora proper, Debian and similar GNU/
Linux distros.

#13

/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.

3 Likes
#14

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).

2 Likes
#15

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.

#16

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.

1 Like