Forum Replies Created
-
Posts
-
First off: if you install the Workstation on the server you will get the same 3.5 behavior.
It’s not that the 4 works differently, it’s that you are comparing a virtual desktop created by the Workstation, that is one that only exists in the computer’s memory can be resized to any possible resolution, and a physical desktop, that is one that is displayed on a physical monitor and hence is subject to a number of constraints regarding the resolution and the way the OS (or X, in this case) allows applications to modify this setting. Basically you can’t have the same flexibility. But indeed there is some flexibility that can be achieved.
There are 2 possible uses of NoMachine: if you are using it to access a remote system, you probably want to modify on the fly the resolution on the server to match the resolution on the client. This, in general, is not a problem, as long the resolution on the client is listed among the resolutions supported by the server. There are corner cases to be handled and the multi-monitor configurations on the client, requiring that the physical desktop is resized to, say, 3840×1080, that surely most graphic cards do not support. Then there is the case when NoMachine is used as a collaboration tool, where a remote user connects to the machine which has a user in front of the physical monitor. In this case the user sitting in front of the monitor doesn’t want his/her display changed when the remote user connects. This is not a big problem in virtual desktops, since the use-case is often different. The draconian solution of never resizing the physical server desktop implicitly (you can still do that in the control panel) sometimes is not what the user wants. We are working on distinguishing the two cases and adding more of flexibility.
On the Mac run:
# find /Library/Logs/CrashReporter/ -name \*.crash
And:
find ~/Library/Logs/CrashReporter/ -name \*.crash
You should find the backtraces there. Please send to the support.
If it crashed on the Linux server, you should find the core file in your home.
NIS is not supported by the free NoMachine server version 4 at the present moment. The Workstation is probably the product you are looking for. Install the Workstation and login by SSH. It will work the same as the version 3.
Please follow the instructions you get in “What to include” (see below), namely:
– NoMachine product and version on local and remote machine (free version, Workstation, etc).
– Whether the problem arises connecting to a physical or a virtual display.
– Remote and local Windows/Mac/Linux version (Windows XP/7/8, OS X 10.x, Ubuntu xyz, Mint x.y, etc.).
– If on Linux, desktop version (GNOME. KDE, whatever) on client and on server.That error is reported when the client is disconnected before getting past the session negotiation. It is likely a display problem. It would be useful if you could provide a tar of the server logs to the support.
Please provide all the information that can be useful to dig into this. Xorg version, desktop environment version, graphics card model, GPU driver and specific version.
BTW, did you try updating to the latest version of Xorg?
It seems we need a paid subscription to send data to NoMachine tech support so we haven’t followed up.
That’s obviously the norm. Except in the case data can be useful to solve a bug of general interest, like in this case.
isabel,
this is very likely a firewall problem. Try disabling the firewall or the antivirus program on the server computer. If it is that, we will later see how to selectively enable the ports that are used by NoMachine.
Please also tell me the exact Windows version you are running, the antivirus program or any detail that can be useful. We’ll investigate what we need to do to set up the ports automatically in this particular configuration.
As I said already, this is a X bug. It may be interesting to investigate, but I don’t think it has specifically to do with NoMachine. NoMachine performance with physical desktop sessions are at least as good as with virtual desktop sessions. They are often better, given that the physical desktop sessions are normally HW accelerated, while HW acceleration in VD is more limited, given the lack of “virtualization” capabilities in current GPU drivers.
I do not know if the security issue is caused by Apple Fast User Switching mechanism or by NX server authentication.
I can confirm that this has nothing to do with the NX server authentication.
The problem is that a user could see the session of another user without the credential of that session.
At the present moment, the remote user logging in with valid credentials is treated like a user sitting in front of the monitor. Even from the point of view of Fast User Switching, this remote user is subject to the same restrictions of a user sitting at the computer. That is, to switch from one session to the other, the remote user needs to re-enter the password. But if the user running the session did not lock the screen, the computer becomes available to the remote user as it would be available to whoever was transiting in front of the computer. This is traditionally the way “remote screen” tools work. I agree that this way of handling the remote user is not flexible and can present a security problem (mitigated by the fact we are talking about a small group of people normally sharing the same Mac). Other users have pointed out the same but NoMachine for Mac is a remote access system not a terminal server.
Until not long ago it was possible to select between client or server at setup time. We decided to skip this because we want NoMachine to attract a much wider audience than the traditional Linux remote desktop user. Most people are not used to the fact you can separate a program in “client” and “server”. When people install Skype, they expect to be able to both place and receive calls with a single program. Not always things are obvious. Recently I’ve seen a review at Download.com where a user gave NoMachine 1 star (screwing our score forever 😉 ) because we didn’t explain better that he had to install NoMachine on TWO computers to let these computers communicate each other. Of course the user was right.
There are number of things we plan to work on:
– Make easier to shutdown the server forever in one click.
We made the mock-ups already, albeit I don’t know the status of development. This would make most users interested only in the client happy.
– Make possible to install only the client.
Maybe there is a command line options already (there are to make “silent” and “very silent” automated installations). If there is not, expect this option to become available soon.
– Make possible to install the client without admin privileges.
This is easy too. The only thing for which the client needs admin rights is to install some device redirection drivers. No drivers, no redirection, but no loss of functionality beyond that.
– Make possible to install the server without admin privileges.
This is a bit more complicated because the server was born as an “enterprise” solution, so it is a bit overloaded compared to the needs of a single-user program. The idea is to build a single-user server in the player. In the 4 we made huge steps to streamline everything and now this goal is not too far away.
– Create an install-less client (and server).
The idea is to make easy creating a USB image including players for all the supported platforms, so that people can run the client from there. I don’t know where we are, but AFAIR I have seen some prototypes working. Making a “portable client” is one of the most requested features.
I certainly understand that your company has no specific interest in making this port run (resp. build) on every platform (resp. in every development environment).
Believe me, we really WANT it to run on every Windows and build in every environment. I just wanted to say that, given the thousands of things boiling in the pot, people should not expect too much from us on this front :-/. This was clearly NOT aimed at you. From what you say the instructions are inexplicably poor. Probably at the time we last built the port stand-alone, the software built OK and who was responsible of creating the instructions thought a quick how-to was enough. Then things bit-rotted. We’ll fix our fault ;-).
We take security very seriously, of course, and the described problem is no exception. But to better understand what the problem is we need to know one thing:
– You say that three users were able to login to the machine. Were these users able to do so without a valid user name and without a valid system password?
– Or all of them had to provide valid credentials for the system (that has these three system users created)?
I have the impression that the problem is just regarding what desktop was presented to them (what Apple calls Fast User Switching). Please, be quick to respond because if this problem is really exposing NoMachine users to a risk, it’s important we react quickly.
Just a quick recap because I’m sure this will be helpful to make things more clear:
– We did this port since we use OpenSSH on Windows. We also ship a SSHD in the Enterprise servers.
– While the code is exactly the same, we build using a custom-developed build system where autotools and pkgconfig are part of a bigger whole, with higher level scripts taking care of the differences between configurations and platforms. This custom build system required a considerable amount of work and is one of the most valuable assets of our company, therefore we decided to keep it for us.
– We put somebody at creating the instructions to build OpenSSH in the average Windows environment of the average user, but we DID NOT test it in every environment and in every configuration and have no intention to do so because we just care to build it in OUR environment (where it obviously builds perfectly).
– We released this code upstream to OpenSSH and we’ll of course continue to provide any development or bug fix that would arise as part of using OpenSSH in the NoMachine product family. At the same time we don’t want to maintain a “Windows port” ourselves. In fact this is the exact reason why generally people make ports and then release them upstream.
– AFAIK, in 3 years or more, we never heard from OpenSSH, neither to confirm they have seen the code or to report build problems. That’s not a problem. We needed the code and made it, but, as you can imagine, we have lost some interest.
– We obviously have no interest in dealing with all possible build environments, Windows versions, GCC versions, Cygwin versions, MinGW versions, library dependencies, accessory packages needed, etc. etc. We tell what we used and what was the exact configuration, so that everybody can audit the code in the same conditions and make builds that are repeatable across different machines.
That said, let me add that I’m very sorry about the problems you are having. We’ll get the developer who made the configuration and build script to check what may have gone wrong, but if he didn’t even list the version of the compiler used or the various library versions, I agree with you that he didn’t do a good job. If you have other hints on how the documentation can be improved, we’ll be glad to follow your suggestions.
Just found this:
http://www.linuxforums.org/forum/ubuntu-linux/199110-ubuntu-amazon-ec2-remote-desktop.html
Wow, another Temviewer shill.
I presume you are the same RobMunfy. I’m really interested in knowing how Teamviewer performs without a display :-).