Forum Replies Created
-
Posts
-
After a long search i found creating an additional account, it works without problems – just connection to this account and then using the screen of my standard user … so i decided not go deeper in the problem with my account…
Well, let me know if we can help with this first account. Did you try creating a new .nxs file to login with the first user? Can it be a wrong key stored in the .nxs file?
Yes, NX does (normally) ask. However, to work from remote i have configured the NX-Server that it dont ask for permission. Because if it asks, and i sit remote, a cannot click on the button “ok” 😉
OK, but it will ask only if you connect to the machine as a different user. If you connect to the machine as the same user running the session you should get in without problems.
Is there any reason you are connecting as a different user (I’m sure there is, just asking to be sure I understand correctly).
I’m not sure I understand correctly.
Suppose you are User1, logged on X :0. User2 connects to the machine (this User2 is a different system user). Doesn’t NoMachine display a dialog asking User1 (on :0) whether User2 should be able to connect?
Is there an option for NX4 to open a new session in any case as it was in NX3.5?
NoMachine Workstation and all Terminal Server products do this. They offer the option to create a new session. Anyway this doesn’t solve the problem of what to do when User2 wants to connect to the desktop of User1. This is a perfectly common case of desktop collaboration.
At the moment the solution is to let User1 connect without asking permissions (since we assume User1 is the same User1 and asking permissions would block User1 from connecting in the case he moved to a different machine), and force User1 (or any other user currently viewing :0) to authorize User2.
To show the version run:
> /usr/NX/bin/nxserver –version
Be sure you have installed the right package. The Terminal Server packages are here:
https://www.nomachine.com/Select-package-virtual-desktop-linux&id=21
I don’t think the server log is going to tell anything useful. If it’s a nxupnp crash, only a core file with symbols will help. If you get in contact with the support, we’ll provide such binary tomorrow.
In the meanwhile you can just replace the binary with a script doing nothing:
> sudo sh
> /usr/NX/bin/nxserver –shutdown
> cd /usr/NX/bin/
> mv nxupnp nxpupnp.ori
> cat > nxupnp
#!/bin/sh
sleep 1
exit 0
^D <— press CTRL+D here
> chmod a+x nxupnpTest it:
> ./nxupnp
>Restart the server:
/usr/NX/bin/nxserver –startup
I tried it and I was still able to connect. UPnP is only used to query and forward ports on the router. You won’t have ports forwarded but, except for that, it should work fine.
Hi monksy,
can you provide more details on what you are trying to do? Do you simply have a headless machine with X installed but no monitor? Is this the answer you are looking for?
Jason,
open a console and run:
> ps auxwww| grep nxd
You should see nxd running with pid 17603. Can you see it?
AFAIR you said that you can connect to nxd when running the client on the same machine. It seems to me a trivial firewall problem, that is the connection on port 4000 is blocked before reaching nxd. It can be a security feature on your machine blocking connections to “unknown” services. The installation script adds all the required rules for SELinux and AppArmor. You disabled SELinux and this didn’t work either… I don’t think changing port will help, but…
Install netcat (nc) and run:
> nc -l 4012
Or some other port. Then on another machine:
> telnet server_machine 4012
Can you connect to this other port?
There is not much more that I can say. What I can suggest is:
– Tunnel the connection to that machine by ssh. See this post on how to do it:
https://www.nomachine.com/forums/forums/topic/unable-to-connect
– Install the Workstation evaluation. In the meanwhile we’ll investigate if there are similar reports from other users
In the free 4 we removed the distinction between client and server, especially because NoMachine is now available as server on all platforms. Like a Skype install can be used to both connect and accept connections from Skype clients, so can NoMachine. You can obviously disable the server and use only the client. In the past, we received lot of critiques because installing NoMachine on a host required installing multiple packages, so this change should be for the better.
Client-only packages are still available in the Enterprise downloads:
https://www.nomachine.com/download-enterprise
Note that these client products are still free, as they were in NX 3.
What makes you think it is a NoMachine bug?
It looks like Xorg process is pegged at 93+% CPU.
Not only that. I see nxnode.bin at 0.7% and nothing else running. I suggest you send an email to the CentOS people or Red Hat. I’d tend to exclude it’s NoMachine.
For the record: it seems that you are running a “remote desktop” session, not even a “virtual desktop”. So your KDE desktop runs in Xorg, not in nxnode. In other words X clients are connected to Xorg. What NoMachine does for “remote desktops” is just querying the content of the top-level windows on a interval (in your case, probably 25 times a second). I have never seen a Xorg instance taking more than 5% of the CPU to return 25 XShmGetImage() per second, even on HW of 10 years ago (that we keep here for testing). Even if you had disabled the X-SHM extension in Xorg.conf (that would have been deliberate), load should have distributed 50%-50% between Xorg and nxnode. Yes, it looks like a Xorg or KDE bug. I’ve also seen Pulseaudio causing this kind of behavior. I hope for you it can be solved with an upgrade.
Good try. With a couple of hundred thousand 4 installs already around and more of 70% of customers who already upgraded from the old 3 we didn’t receive a single complain about performance. You are the first. So there must be something wrong with your install, or on that specific machine, or on your network. But, to be honest, I have some difficulties to believe.
If you know how to do, run the session for a couple of minutes, then locate the nxnode.bin process running the session. It shouldn’t be difficult. Considering the poor performance you are experiencing I suppose it must be very high on top. Do a kill -USR1 of the pid, then make a zip on the .nx directory in %HOME% on the client and a tar.gz of /usr/NX/var and of the .nx directory of the desktop user on the server. Send to our support. You can also display the statistics in the player. Open the panel -> Connection -> Take the statistics. I’m curious to see what is it.
Ops!
I forgot to mention. You can tell the client to store the password in the .nxs file. Well, you have probably noted that (I know it’s not the same thing).
We have key-based authentication implemented in the NX protocol and we use it for server-to-server communication, for example in the cluster. Unfortunately still missing is key selection and GUI integration in the client. Once implemented, key-based authentication for the NX protocol will mirror the SSH implementation, so you will be able to insert the key as you do now for SSH.
There are multiple reasons for using our own protocol rather than SSH. The first is performance. Tunneling over SSH means that our packets have to traverse at least 1 additional process before coming to the destination (at least the SSHD process, if we don’t run a separate SSH client). This is an additional process for each machine traversed, so in a multi-node server there are at least two. Then with SSH we have processes communicating through pipes (like multiple separate commands piped in a shell), so we are adding a further encryption stage at each hop. With NX we can simply hand over the SSL context from one process to the next (as Apache does) and relay connections by only running encryption end-to-end. I can’t provide the details, but we were in a situation where a display packet, to come to the client, had to traverse 12 processes and be encrypted 3 times. Not so with the NX protocol. Additionally, when using the NX protocol, audio and video can use UDP. Not that we couldn’t use a UDP side-channel with SSH, but it would have been hard to explain to managers in a company that, yes, we use SSH for the connection but then most data is not going through SSH. There are additional tiny details, like the efficiency of the crypto key used, that adds to the speed, or the fact that SSHD is a single-threaded process while with NX everything is multi-threaded and can run on platforms, like iOS, where multi-process is not an option.
A second reason is that, using SSH, we can’t simply support a number of features we need in NX, like keeping a NX users separate from the system users, supporting guest connections and redirecting users to different machines without having to create system accounts. Unless recurring to workarounds. That is what we did with the use of the “NoMachine login”. These workarounds are perfectly in the spirit of SSH but were judged “questionable” by some, simply because they by-passed the PAM God and let NoMachine create users and check passwords by its own. With the NX protocol these “questionable” uses of SSHD are gone.
A third reason is supportability. It’s hard to support something you have no control on the way it is used or configured. SSH is an extremely powerful and configurable tool. When users install NoMachine and NoMachine doesn’t work because the SSH client or server are configured to do something special that we could not foresee, users tend to blame NoMachine. They have all rights to do so, but you will agree that hardly this way NoMachine could aspire to become mainstream. Now enterprise users can still use SSH, if they like, but at least we can know if a problem is due to SSH or NoMachine.
A fourth reason is Windows. We ported the OpenSSH client and server to native Windows and released it on the same licensing terms of OpenSSH. This was done to offer the same set of features on all platforms, but clearly we don’t want to keep developing SSH just to be able to run NoMachine on Windows.