Package Details: nomachine 8.16.1-1

Git Clone URL: https://aur.archlinux.org/nomachine.git (read-only, click to copy)
Package Base: nomachine
Description: Remote desktop application
Upstream URL: http://www.nomachine.com
Licenses: custom:"NoMachine EULA"
Groups: network
Conflicts: nxclient, nxmanager, nxnode, nxserver, nxwebplayer
Submitter: FreeK
Maintainer: runnytu
Last Packager: runnytu
Votes: 95
Popularity: 0.52
First Submitted: 2014-07-24 15:45 (UTC)
Last Updated: 2025-02-01 20:34 (UTC)

Pinned Comments

runnytu commented on 2021-02-20 13:44 (UTC)

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

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 25 Next › Last »

gchamon commented on 2021-05-19 17:13 (UTC) (edited on 2021-05-19 18:39 (UTC) by gchamon)

updating nomachine to 7.5.2:

diff --git a/PKGBUILD b/PKGBUILD
index f17ff7d..9071874 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -11,8 +11,8 @@ _autofirewall=n
 ### END BUILD OPTIONS

 pkgname=nomachine
-pkgver=7.4.1
-_pkgvermain=7.4
+pkgver=7.5.2
+_pkgvermain=7.5
 _pkgrel_i686=1
 _pkgrel_x86_64=1
 _pkgrel_armv6h=1
@@ -30,13 +30,13 @@ options=('!strip')
 conflicts=('nxmanager' 'nxwebplayer' 'nxserver' 'nxnode' 'nxclient')
 depends=('bash' 'openssh' 'nawk')
 optdepends=('xorg-xauth: allows logging into a headless machine')
-sha512sums_x86_64=('3e72109be04f594998ce750defd926d34d38dd1309e6953f36348d6a97479e27173f1aa1e75d7dcf95b157e16a0349e436c53006f2a240b3134ee83c89e487ed')
-sha512sums_i686=('497d0c1a4cfe822db07bbc008e64688be792e1543250db0384b55ba5cb783c14495014fc8150401d822d7d3c54981341751761b2c413d441bdc1f8047dd81026')
-sha512sums_armv6h=('b4d8aba4fa15d9e34dfaf79d72873e307e5acf8bef774b3a2c01f5d1fd380de17e0d811ff24427fb808104366ba7b92f5c798f8d6eaecb9a8e27c221d4dc6e42')
-sha512sums_armv7h=('c17858e079ff8b403c1f66704c4f234db7d7519522f0dc728a5a06a34e89ad34d9fe11c8d87a83bd7a8a294a5606da78366b222ce785fb1892f7207db0d0309c')
-sha512sums_armv8h=('ed8626ee4f9b7da650ee9d08847ff6abb23130717318556e1c7930fbc80aac80d163fa56c8f04732740f1137c9439d5d853827621b67c99d0f66f44527a67f00')
-sha512sums_aarch64=('ed8626ee4f9b7da650ee9d08847ff6abb23130717318556e1c7930fbc80aac80d163fa56c8f04732740f1137c9439d5d853827621b67c99d0f66f44527a67f00')
-sha512sums_pentium4=('497d0c1a4cfe822db07bbc008e64688be792e1543250db0384b55ba5cb783c14495014fc8150401d822d7d3c54981341751761b2c413d441bdc1f8047dd81026')
+md5sums_x86_64=('a194542d0a41628f85df0786e07f9543')
+md5sums_i686=('5cbd2ad4c493a227db3e0b65937216de')
+md5sums_armv6h=('de7abbf7817d7987e28f29e6e04e8a67')
+md5sums_armv7h=('c77416f9d11625717ec1f62e43ab2a19')
+md5sums_armv8h=('d2335fb175b664812f33c26b54e1abc3')
+md5sums_aarch64=('d2335fb175b664812f33c26b54e1abc3')
+md5sums_pentium4=('5cbd2ad4c493a227db3e0b65937216de')
 source_x86_64=("http://download.nomachine.com/download/${_pkgvermain}/Linux/${pkgname}_${pkgver}_${_pkgrel_x86_64}_x86_64.tar.gz")
 source_i686=("http://download.nomachine.com/download/${_pkgvermain}/Linux/${pkgname}_${pkgver}_${_pkgrel_i686}_i686.tar.gz")
 source_armv6h=("http://download.nomachine.com/download/${_pkgvermain}/Raspberry/${pkgname}_${pkgver}_${_pkgrel_armv6h}_armv6hl.tar.gz")

sha512 to md5 checksum is a downgrade, but that is what is provided in the download page

runnytu commented on 2021-02-20 13:44 (UTC)

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

runnytu commented on 2021-02-20 13:28 (UTC)

@cheezsteak, It's working ok, nxserver.service is always starting, and you see the icon on your desktop, but if you look in server status/ports you'll see the service in port 4000 are stopped and "Start the automatic service at startup" checkbox is disabled, even if you search devices in your LAN can see the PC but if you attempt to connect it will be rejected because is no NX service running.

I updated the package with update script when it's updated, and with disable autostart by default, I'll pin a warning and info for changing this behavior.

cheezsteak commented on 2021-02-17 18:54 (UTC) (edited on 2021-02-17 18:58 (UTC) by cheezsteak)

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

galvez_65 commented on 2021-02-17 17:24 (UTC)

@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

cheezsteak commented on 2021-02-17 15:55 (UTC)

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

galvez_65 commented on 2021-02-17 15:42 (UTC)

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

cheezsteak commented on 2021-02-17 15:32 (UTC)

@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

galvez_65 commented on 2021-02-17 14:16 (UTC)

@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?

cheezsteak commented on 2021-02-16 21:18 (UTC)

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.