heywood

[heywood]

Perfect—thanks for clarifying!

 

Cheers,

-H

[heywood]

In that case, I’m confused: what is the difference (in function/purpose) between the two instances of node.cfg? (And the same question applies to server.cfg.)

 

In any case, I’ll keep an eye on logfile buildup in both places and post here if it starts accumulating in either one.

 

Thanks,

-H

[heywood]

Hello Gega,

 

Thank you very much for the detailed tips. I’d already been working on cleaning out ~/.nx/ (without removing cache/, config/, and temp/) and …/var/log/node/ (which I wasn’t sure if I could simply delete — thanks for clarifying!).

I’ll set SessionLogClean 1 as you suggest and keep an eye on …/node/ to see if I start getting the cruft buildup again. If that happens, I’ll gather full logs and submit them described at the link you kindly provided.

One related question: during my cleanup, I found copies of server.cfg and node.cfg in two locations: the aforementioned /Applications/NoMachine.app/Contents/Frameworks/etc/ (with user:group = nx:nx) and, separately, /etc/NX/server/localhost/ (with user:group = root:wheel). Timestamps in both locations are recent (past few days). Is it possible that this machine has an old/incorrect NX installation that is competing with the “proper” one? If so, what’s the best way to check (and fix) this?

 

Thanks again for your help,

-H

[heywood]

EDIT: The NoMachine hidden directory inside the (sole) user’s home directory, ~/.nx/ , exhibits a similar problem. Even trying to count the number of files/directories inside that directory, for example by running “ls | wc -l” from the command line, runs for five minutes (that’s not a typo) with the hard drive audibly thrashing before producing any output. Eventually it returns a count of >260000 (one-quarter million lines), the vast majority of which are logfile directories of the form T-C-*, F-C-*, and so on.

I’m currently running a full backup (using Carbon Copy Cloner), manually excluding the directories mentioned above. Once that completes, I intend to do an erase-and-restore using a file-level copy; hopefully that will address the severe free-space fragmentation issues that have resulted from the runaway logfiles. Unfortunately, I neglected to exclude /Library/Application Support/NoMachine/var/log/node/ on my first backup attempt (I did remember ~/.nx/)—resulting in CCC taking ~16 hours just to build its list of files to compare and back up. (Even though this is an old machine—2GHz Core2Duo, 6GB RAM—my sense is that it should be much faster than that.)

I’ll continue with my cleanup plan for now, but I would be grateful for any pointers on how to avoid this “runaway logfile” situation in the future.

In particular, I’m aware of at least https://www.nomachine.com/TR12O08309, https://www.nomachine.com/AR12K00765″> and https://forums.nomachine.com/topic/nomachine-linux-workstation-6-1-6-generates-logfiles – but all of those refer to node.cfg and server.cfg at locations that do not seem to exist on a standard NoMachine installation on MacOS. Moreover, the only instances of those two files I see on this machine, at /etc/NX/server/localhost/ , do not have anything resembling the keys (SessionLogClean, SessionLogLevel, etc.) described in those articles.

 

Thanks in advance for any tips,

-H

[heywood]

Hi Tor,

My point was that if I define two different connections within NX client, both to the same host IP (differing only by TCP port number), then go into Advanced > UDP settings and define the preferred UDP port on one connection, that change _also_ changes the preferred UDP port for the other connection. This is consistent with the second comment on this thread, but it seems counterintuitive to me (unless there’s a good technical reason for doing things this way).

This obviously isn’t catastrophic — NX client falls back to trying all UDP ports in the defined range if the preferred port is busy upon initial connection — but it’s pretty counterintuitive that changing the setting for one defined connection should also change it for the others.

In any case, I’ve now defined the same preferred UDP port, and the same fallback range, for both connections to avoid this issue, and forwarded the entire range through the router.

Thanks,

-H

[heywood]

I’ll chime in with a “vote” for this FR. As it is, whether a public-facing server uses NX or SSH, it’s still (somewhat) susceptible to brute-force password guessing unless there’s a way to enforce key-only authentication. This would be a very welcome addition to NX.

-H

[heywood]

Hi Reza,

Thanks for the link. A reboot seems to have solved the problem for now, but if the “Error 5” stuff reappears reliably, I’ll send a copy of the logs to issues@ as you suggest.

-H

[heywood]

Hi Bilbotine,

Thanks for that! I had indeed copied the client’s public key to the wrong place on the server (~/.ssh/authorized_keys instead of ~/.nx/config/authorized.crt).

Unfortunately, fixing that now causes a different login failure: when I configure the client (on the Ubuntu side) and try to connect, I momentarily see the first of the informational panels (audio streaming stuff), as if the login has completed successfully… followed about 1 second later by “The connection with the server was lost. Error is 5: Input/output error.” The relevant(?) part of the logfile now looks like this:

> 21127 21127 19:10:43 540.213 ClientDaemonConnector: Starting a new connection to host ‘192.168.1.3’ on port ‘4000’.
> 21127 21127 19:10:43 540.496 Connection: Started connection at 0x97c13d8.
> 21127 21127 19:10:43 550.571 ClientSession: Started session at 0x95bfc68.
> Info: Connection to 172.31.1.153 port 4000 started at 19:10:43 622.470.
> 21127 21187 19:10:44 584.931 ClientSession: A valid certificate for this server was found.
> 21127 21127 19:10:50 623.190 ClientSession: Going to query for available services.
> 21127 21127 19:10:50 757.749 UiRemoteSessionList: Going to automatically select the first session.
> 21127 21127 19:10:50 758.085 ClientSession: Selecting the destination node.
> 21127 21127 19:10:50 778.602 ClientSession: Going to query for available services.
> 21127 21127 19:10:50 829.791 ClientSession: Going to attach session at index ‘0’.
> 21127 21127 19:10:50 830.680 Keyboard: Current model ‘evdev’ session model ‘evdev’ layout ‘us’ variant ‘(empty)’ options ‘(empty)’.
> 21127 21127 19:10:52 192.575 ClientSession: Stopping the connector before creating the proxy.
> 21127 21127 19:10:52 194.965 ClientDaemonConnector: Stopping the current connection.
> Info: Slave server running with pid 21193.
> Info: Display running with pid 21194.
> Info: Listening to slave connections on port 13002.
> Session: Starting session at Mon Oct 20 19:10:52 2014.
> 21127 21127 19:10:52 335.987 Connection: Stop reading after switching the connection.
> 21127 21196 19:10:52 788.132 ProxySession/ProxySession: ERROR! Session failure in stage ‘StageWaitingProxyVersion’.
> Error: Session negotiation failure.
> 21127 21196 19:10:52 788.505 ProxySession/ProxySession: ERROR! We possibly provided a wrong version
> 21127 21196 19:10:52 788.518 ProxySession/ProxySession: ERROR! or an invalid session authentication cookie.
> Error: Connection closed by the remote peer.
> Session: Session terminated at Mon Oct 20 19:10:52 2014.
> 21127 21194 19:10:52 789.709 Encryptor/Encryptor: WARNING! Destroying pending buffer with 89 bytes.
> 21127 21127 19:10:52 816.239 ClientSession: Exiting from the client transport loop.
> 21127 21127 19:10:52 816.481 ClientSession: The transport closed with reset ‘1’ error ‘5’.
> 21127 21127 19:10:52 816.729 ClientSession: Session at 0x95bfc68 failed.
> 21127 21127 19:10:52 816.921 ClientSession: Failing reason is ‘The connection with the server was lost. Error is 5: Input/output error.’.

Could this be a permissions issue? On both the client (Ubuntu) and server (OSX), I have the following permissions:
~/.nx 700
~/.nx/config 700
~/.nx/config/{authorized.crt, client.crt, player.cfg} 600

For the client-side key I’m using to log in to the server:
~/.ssh 700
~/.ssh/id_rsa 600
~/.ssh/id_rsa.pub 644 [the contents of this file are what I copied to ~/.nx/config/authorized.crt on the host]

I’m not sure where else to look… can you spot anything obviously wrong here?

Thanks very much in advance for your help!

Regards,

-H

[heywood]

Just tried with 4.1.29 on OSX (10.6.8) and the problem seems to be completely resolved.

 

Cheers,

 

-H.

[heywood]

I have the latest V4 (4.1.29) installed on a MacBook Pro running 10.6.8, and I have not had any such problems. That warning sounds like the kind you see when you try to run an application compiled for Intel (x86) on an old PowerPC machine. What hardware are you running?

[heywood]

Ack, never mind — I was looking at your screenshots, but missed the hardware details at the end of your post. I have almost the exact same hardware, but I do not see any error like that.

[heywood]

@titan: Thanks for the update. I see 4.1 is not yet out as of today (2013-12-31), but I understand the reason for the delay and it isn’t a big deal for me. I’ll keep an eye on the downloads page for a release announcement.

 

@snejok: Cool — good to know it’s on the “radar,” and that this feature will get added eventually.

 

Happy new year to all!

 

-H

[Author]

Posts