Nomachine client

[uli42]

I wanted to check if the current nx-libs are still working with one of the last nxclient versions I have. So I setup freenx-server and tried.

Unfortunately I failed for several reasons:

1. with nxclient_3.5.0-7_amd64.deb

/usr/NX/bin/nxclient: /usr/NX/lib/libz.so.1: no version information available (required by /usr/lib/x86_64-linux-gnu/libpng16.so.16)
/usr/NX/bin/nxclient: /usr/NX/lib/libz.so.1: no version information available (required by /usr/lib/x86_64-linux-gnu/libpng16.so.16)
/usr/NX/bin/nxclient: relocation error: /usr/lib/x86_64-linux-gnu/libpng16.so.16: symbol inflateReset2 version ZLIB_1.2.3.4 not defined in file libz.so.1 with link time reference

2. nxssh from ./nxclient-3.0.0-89.i386/NX/bin/nxssh does not work - it always wants a passphrase for the key although it is not password protected:

NX> 203 NXSSH running with pid: 11900
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: ::1 on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
NX> 210 Enter passphrase for key '/home/uli/.nx/temp/11881/keylog':

3. testing nxssh of nxclient_3.5.0-7_amd64.deb with some LD_LIBRARY_PATH magic reveals it checks .ssh/ssh_config for unknown config parameters and then aborts with an error if it finds any. This is a PITA because you cannot use newer features like ControlPersist or PubkeyAcceptedKeyTypes +ssh-dss (the latter one being important for compatibility as freenx's nxsetup is telling me).

So any suggestions ho to successfully test an nomachine nxclient on a current distro (Beian Buster in my case)?

[uli42]

Making nxclient-3.0.0-89 use the nxssh that comes with opennx I come one step further but fail like this:

NX> 203 NXSSH running with pid: 32547
command-line line 0: Unsupported option "rsaauthentication"
command-line line 0: Unsupported option "rhostsrsaauthentication"
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: ::1 on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
HELLO NXSERVER - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.20)
NX> 105 NX> 280 Exiting on signal: 15

Any ideas?

[dimbor-ru]

Please use nxssh from Etersoft with nxclient. Like opennx, which downloads and uses it in its package.
On my test machine i simple replaced /usr/lib/nxclient/bin/nxssh. It works.

[dimbor-ru]

Note: My installation is simple adopted for me from Etersoft nxclient_3.5.0.7-deb64 packet. Unfortunately I could not find its source.

[uli42]

that package is not installable on debian buster (missing deps nx and libpng12). With some tinkering I could get it to run but even with this version I get "exiting with signall 15"

(note: The reason for using the original client is some code in nxagent I would like to change. This code is using XSetSelectionOwner() to communicate with the nxclient. I suppose openx is not watching them but nomachine's client is. So I'd like to study the effects of changing that code.)

[dimbor-ru]

Yes, nxclient for linux contain it's own "built-in" copy of old nxagent binary. However, the conditions in which it is used are unknown to me. At least in the list of tasks on the client I have never seen him. Usually nxclient starts a session and ends. Further used nxssh+nxcomp only. I myself wouldn’t refuse to listen to such an existential variant as nxagent on nxclient side.

[uli42]

No, there is no built-in nxagent in nxclient (and there's no sense in doing so). But nxagent on the server will own some selections on the real X server (where nxclient runs) and nxclient is supposed to wait for those to know a) when nxagent is ready and b) when the splash screen has ben removed and c) learn the window ids

[dimbor-ru]

Ok, I understood. (So my information about nxagent in nxclientis very forcefully outdated.)

"exiting with signall 15" can be caused by the incompatibility of the new and the old libc. In this case, we will not do anything, because code of nxclient is closed. Maybe the required window ids (with timestamps ) will be found in the nxclient's connection log? I am ready to send it to you, just tell me what to run and in what modes. I can also make a test virtual machine with working nxclient. There will also be freenx installed. And you can connect by opennx there to connect somewhere by nxclient. But preparing a second solution will take some time.

[Djelff]

Just install nxclient_3.5.0-7 and delete /usr/NX/lib/libz*
Its worked on Ubuntu 16.04 and 18.04
Versions that work this way are found here: https://cs.mtsu.edu/software/nxarchive/

[uli42]

Ok, thanks! Will try that.

…

On Tue, Jan 21, 2020 at 10:32 AM Djelff ***@***.***> wrote: Just install nxclient_3.5.0-7 and delete /usr/NX/lib/libz* Its worked on Ubuntu 16.04 and 18.04 Versions that work this way are found here: https://cs.mtsu.edu/software/nxarchive/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[uli42]

Nope, still not working. It looks like shown above. nxclient does not seem to send any commands to nxserver. Hmm...

[Djelff]

This is strange, I really did nothing other than erasing libz * to run nxclient on the above systems.
Have you run nxclient as root? Perhaps some files have become blocked.
Erase /home/user/.nx and /home/user/.Xautority
Do any logs appear in /home/user/.nx?

[Djelff]

Indeed, on Debian 10.02, NXClient not work.
The log shows the expectation of a fingerprint from nhssh, at this moment the client should have displayed a consent window, but the window does not appear :(

upd:
I set LD_LIBRARY_PATCH and connect to server witch command
/usr/NX/bin/nxssh -nx -i nx.key nx@server
and accept fingerprint, after this nxclient connected to server, but not work

I assume nxclient have capture problem from stdin and stdout

[dimbor-ru]

What about replacing nxssh?

[uli42]

@Djelff: that's exactly what I had done, too. I will try to setup the original nxserver and check, if the connection work better with it.

@Dimbor: Of course I am using the nxssh from opennx. Do the patches to nxssh change the output of nxssh?

[dimbor-ru]

As far as I know, don't change.

[dimbor-ru]

I called into the thread specially trained kind spirits from Etersoft. Suddenly they will respond ...

[Djelff]

t is most likely that in nxclient it stopped seeing threads properly due to the correction of the POSIX standard error in glibc 2.28.
https://sourceware.org/bugzilla/show_bug.cgi?id=1190
Not sure, but it is possible to return the old nxclient behavior if you write a wrapper for the changed functions and apply lD_PRELOAD.
Is it worth it if remmina works?

But, I still checked.
Returned #if 0 to fileops.c, compiled glibc 2.30 (Ubuntu 19.10), and added first to LD_LIBRARY_PATCH
Result - nxclient works.
A simpler solution would be nice, but it lacks experience;)

[uli42]

Oh, how on earth did you find this?

I have recompiled glib 2.28-10 from debian buster with this patch and it worked. Just using LD_PRELOAD with the resulting libc.so.6 is sufficient.

--- glibc-2.28.orig/libio/fileops.c
+++ glibc-2.28/libio/fileops.c
@@ -469,10 +469,12 @@ _IO_new_file_underflow (FILE *fp)
 {
   ssize_t count;
 
+#if 0
   /* C99 requires EOF to be "sticky".  */
   if (fp->_flags & _IO_EOF_SEEN)
     return EOF;
-
+#endif
+  
   if (fp->_flags & _IO_NO_READS)
     {
       fp->_flags |= _IO_ERR_SEEN;
--- glibc-2.28.orig/libio/oldfileops.c
+++ glibc-2.28/libio/oldfileops.c
@@ -295,10 +295,11 @@ _IO_old_file_underflow (FILE *fp)
 {
   ssize_t count;
 
+#if 0
   /* C99 requires EOF to be "sticky".  */
   if (fp->_flags & _IO_EOF_SEEN)
     return EOF;
-
+#endif
   if (fp->_flags & _IO_NO_READS)
     {
       fp->_flags |= _IO_ERR_SEEN;

Maybe we could convince the glibc developers to add an env var that switches to old behaviour?

Regarding "is it worth": I don't know if there are people using the old nxclient... For me this is a sufficient way to test what I wanted to test. Currently we are trying to keep nx-libs compatible to the original nomachine nxclient. If there's no proper way to run it on current glibc version we eventually can drop this compatibility completely.

[Djelff]

There is also a _IO_EOF_SEEN flag, you need to intercept _IO_new_file_underflow, clear this flag, and do LD_PRELOAD.
Then it will work on all versions above 2.28.
So far I have not been able to do this.

[dimbor-ru]

I still use nxclient where previous versions of opennx worked poorly. And where too lazy to change it. ;)

[uli42]

I have tried to intercept *file_underflow and failed. _IO_(new|old)_file_underflow are mapped to _IO_file_underflow which again is mapped to __underflow. I had no success in intercepting any of those (but I had success with (f)read and f(write)). Any suggestions how to achieve the goal?

[Djelff]

This flag does not help, I set it by intercepting _IO_getc (FILE * fp), after which the client generally stops receiving messages and freezes. Without a flag with interception, the behavior is the same.

[uli42]

So what's your theory why recompilation without the flag works?

[Djelff]

There is not quite a recompilation without a flag, there is its point-blank disregard. The flag itself is used in many places, in particular here:

glibc-2.30\libio\bits\types\struct_FILE.h

#define _IO_EOF_SEEN 0x0010
#define __feof_unlocked_body(_fp) (((_fp)->_flags & _IO_EOF_SEEN) != 0)

Therefore, simply resetting the flag does not fix it ;(
So far, there are no other thoughts on how to fix it, except how to replace all glibs.

[uli42]

Well, we then need to replace the file_underflow functions as a whole ;-( Maybe we can limit it to just recompiling fileops.c and get a fileops.so.

[uli42]

I have updated the glibc bugzilla an asked for a way to reestablish the old behaviour.

[Djelff]

Fixed!

This library allows you to run nxclient 3.5.0-7 on versions of Glibc> = 2.28
https://sourceware.org/bugzilla/show_bug.cgi?id=1190
Use the following:
gcc -shared -ldl -fPIC ./nxfixglibc1190.c -o /usr/NX/lib/nxfixglibc1190.so
LD_PRELOAD=/usr/NX/lib/nxfixglibc1190.so /usr/NX/bin/nxclient

Source and libs x32 and x64 builded on Ubuntu 16.04 and tested on 18.04x386 and 19.10x64.
nxfixglibc1190.tar.gz

[uli42]

Cool! Will test this soon.

I noticed this code checks for sshlog - isn't there a way to switch sshlog off in nxclient? This would make the library obsolete...

Next, this fix is specific for nxclient. There might be other programs with similar problem. Have you tried to write a generic fix for bug 1190?

[Djelff]

Judging by the fact that I managed to find not so many about 1190 such programs, for example, there were problems with the cups and were quickly fixed. I don’t think that there is any proprietary program that uses the access method in such a disgusting way.

I already have a prototype of the client for the golang, it does not intercept the file, but the stdout and stder, and its connection speed is about two times faster. While it is console, because the problem is in gui, I have not yet decided what to use.

In this case, I specifically intercept nhssh specifically for reading, because there is no need to intercept the rest of the streams and this will make this library potentially more surviving on the next versions of glibs.

In any case, an approach to fixing the 1190 problem has been found, and the correction, probably for almost any program, will only be in search of where to stick clearerr.

To make a universal library is a long time, until I achieved at least that I got a lot of crash dumps.

The fix was the "what if it finally works" method ;)

There is still a problem with the delivery of the client, the license, as far as I remember, prohibits its repackaging.

And I'm a very weak Linux programmer, there was just a lot of free time ;)

[uli42]

I have tested your lib, works fine. Thanks a lot!