Arch Linux User Repository

Since nomachine 7.1.3-2 the default behavior of the package is StartNXDaemon Manual and FirewallConfiguration 0 on a new installation, if you want to change this, you need to modify PKGBUILD build options with your desire behavior:

BUILD OPTIONS

Set to y to enable nomachine service autostart

_autoservice=n

Set to y to enable firewall autorules

_autofirewall=n

END BUILD OPTIONS

@galvez_65 sorry I was looking at the server.cfg.sample file not the server-fedora.cfg.sample file in nxserver.tar.gz. The config file is being edited correctly and is installed on my system with both StartNXDaemon Manual and EnableFirewallConfirguration 0 set.

However, the nxserver.service is still running and enabled after installing the package. I'm suspecting it's a problem with the upstream script nxserver not repsecting it's own configuration rules. If someone else can confirm this is true, I'd just give up on offering PKGBUILD options and just have the package scream "REMOTE DESKTOP ACCESS IS ENABLED FOR YOUR MACHINE" as loud as possible.

@cheezsteak not sure I follow, I just checked the and the sample config file is present and contains the comments listed in the PKGBUILD that sed is looking for. I've not recently tested that changing the defaults works so I can't comment on that yet

Th upstream package stopped providing a full config file with commentted out defaults to just one option and copyright. The sed commands in the PKGBUILD were looking for the comments to replace them but not making any changes. The PKGBUILD should now use the commands below instead of the sed commands.

echo "EnableFirewallConfiguration 0" >> NX/etc/server-fedora.cfg.sample
echo "StartNXDaemon Manual" >> NX/etc/server-fedora.cfg.sample

The flags not working is definitely an issue that should be addressed. I wonder what changed in the config files ?

@galvez_65 a sticky would be better than nothing but I just don't understand the merit defaulting to enabling the service over not. Saying "users should be reviewing the PKGBUILD" doesn't justify being insecure by default. If the maintainer were to switch they could still say "users should be reviewing the PKGBUILD" if any users complain about the service not being automatically.

Also the flags don't seem to work. I changed them to n as instructed, stopped and disabled nxserver.service , uninstalled nomachine, and reinstalled with makepkg -si. The warning message didn't print but nxserver was started after the install finished.

Looking into server.cfg.sample, there's only ServerRoot = "/usr/NX" and no commented out configurations. So these commands from the PKGBUILD make no changes to the package.

sed -i 's/#EnableFirewallConfiguration 1/EnableFirewallConfiguration 0/' NX/etc/server-fedora.cfg.sample
sed -i 's/#StartNXDaemon Automatic/StartNXDaemon Manual/' NX/etc/server-fedora.cfg.sample

@cheezsteak While I won't argue that this package breaks with Arch norms, this is the AUR and users should be reviewing the PKGBUILD along with .install files to understand what they are doing. If this package were in the main repos, then yes what you describe would be the norm, but here I'm just thankful that someone put this together and is maintaining it. The same thing recently happened with tailscale, in the AUR it enabled the service automatically, once it was moved to the main redo that behavior was changed. Perhaps a sticky note should be added here to indicate that the default behavior is to enable by default and can be changed in the PKGBUILD file?

I would like to relitigate the default behavoir of enabling nxserver and opening the ports by default. While I appreciate the maintiner providing configuration variables and warning notices, those settings ought be secure by default.

It's particularly egregious because this package provides both the server and the client software. So users installing the package on their home machine to remote into work could inadvertently expose remote desktop access to their home machine.

I understand the upstream package is insecure by default but that doesn't justify this package continuing that irresponsibility. I'm also not entirely sure that changing the default behavior will break anyone's existing setups. New installers must enable the service and open the ports, but that's standard behavior for arch packages and can be addressed with a pinned comment and/or different warning message. Users with this package already installed, who want the service enabled, will already have it enabled.

This may be caused by not updating correctly. I edited nomachine.install removing the pre_upgrade stanza and changed the post_upgrade stanza to be:

post_upgrade() {
    echo "Running NX update script..."
    /usr/NX/nxserver --update fedora
}

which seems to fix the issue. I'm not sure why --uninstall and --install are used rather than --update so there may be other unintended consequences, but unless there is a reason I would suggest or at least explore changing the upgrade procedure.

With the last versions nomachine will start correctly only if removed completely first explicitly

@Groumpf I can confirm I had to do the same thing to attach to my wayland session on gnome as well