May 9, 2014 at 14:21 #3501esarmienParticipant
When upgrading the NoMachine Cloud Server RPM using ‘rpm -Uvh’, this RPM replaces all configuration files, keys, and starts all services. I have a few questions:
1. Is this the desired action?
2. Can you build an RPM which only updates the binaries and libraries in /usr/NX rather than replace all configurations, keys, and starting all services?
3. If not, do you have an SRPM available which I could customize to remove these actions?
EvanMay 13, 2014 at 14:58 #3567zaqParticipant
After the update all services should be working. The update procedure updates the configuration files (*.cfg)
only for adding new configuration keys. Your settings in the *.cfg files shouldn’t be changed, likewise license
files (*.lic) aren’t overwritten and files in NX/etc/keys/ remain the same.
No special package. As explained above, the update procedure is intended to preserve current configurations and settings.
If this is not the case, ie. you have found your configuration or keys changed, please tell us what these are.
Logs would also be useful which you can attach here or send to issues[at]nomachine[dot]com
We will need the /usr/NX/var/log/nxinstall.log and the /usr/NX/var/log/nxupdate.log files from the server side installation.May 15, 2014 at 10:48 #3596drichardParticipant
For sure, rpm -U does wipe and change information from the .cfg files. I have to hand check them on each upgrade to ensure it’s all right. We have a high number of things “locked down” and it seems like the testing is done with more permissive settings so it’s not seen. Off the top of my head, I know that:
Gets wiped with each upgrade and goes back to
I also have found the upgrade scripts are adding duplicate entries which are commented out, and the file is getting bigger and bigger.May 16, 2014 at 10:39 #3627zaqParticipant
Value of AvailableSessionTypes entry is reseting during update. This is list of keys which are re-set during every update:
Most of those keys keeps the paths to system tools. The paths are refreshed during every update/upgrade.
EnableCUPSSupport 1 (checks if CUPS is available if YES, set to “1”)
AudioInterface (checks which audio tool is available)
Your old *.cfg file has changed name:
server.cfg -> server.cfg.backup
node.cfg -> node.cfg.backup
You can easly restore your old *cfg file.
If any entry during update is duplicated it’s a bug. Could you send more information about the case. A *cfg file with double entries will
be helpful and also /usr/NX/var/log/nxinstall.log and the /usr/NX/var/log/nxupdate.log files from the server side installation.
These files you can attach here or send to issues[at]nomachine[dot]com.May 16, 2014 at 18:08 #3646drichardParticipant
Sent you a node.cfg file which has been upgrade many times with patches. You can see the file has gotten bigger and has dupes. What might work is the approach of reading in all the keys and then generating a fresh/clean file which does not try and merge into an existing file. As long as there is always a backup, that approach seems like it would keep the file clean.
The above list is a good amount of work for me on each upgrade. We don’t want clients to have printer or SMB support and we only allow them to use GNOME. These types of things would be the reason I would never enable automatic updates. It seems great to reload the keys with paths and features, but the actual concept of enabling them seems like not the right approach on an upgrade. I do understand that you are trying to find the balance between plug-and-play and power users that have made customizations.July 9, 2014 at 10:34 #4099
This topic was marked as solved, you can't post.