The Arrival of NX, Part 5: Using NX
It took only 50 seconds for me to receive an e-mail with my login data. After 50 more seconds, I successfully was logged in to the testdrive server and was running a KDE session. testdrive.nomachine.com is not in any way a highly tuned big machine ready to be LinuxJournal.com-dotted, though; it is a dual 2.4GHz Xeon PC with 1,024MB of RAM.
I noticed during my tests for this article that the testdrive server was a bit slow due to heavy loads: 24 other NX sessions were running, 19 KDE and 5 GNOME. The site is not set up to provide a leaner or more optimized-for-remote-access desktop than what installs out of the box--SuSE 9.1 Professional--nor is it tuned to minimize the resources used. If you wait long enough, even a random screensaver may kick in, using some quite unnecessary resources. Also during my test, one malicious NX testdrive user deliberately was trying to bring the server to its knees by opening more than 300 Bash sessions, one after the other, producing a very high load for the box. My NX session still worked, albeit a bit slowly.
To connect to the NoMachine NX testserver, in the Knoppix main menu (KDE session) select Internet --> NX Client for Linux --> NX Client for Linux from the main program menu (see Figure 5). When you start the NX client for the first time, it runs in wizard mode (see Figure 6).
Any future start-up of the NX Client brings it up in normal mode (see Figure 10). If you prefer to see the wizard, you always can re-run it from the command line by typing /usr/NX/bin/nxclient --wizard.
The second screen is the most important screen of the NX Connection Wizard. You use it to:
assign a name to the session; all other session parameters are stored under this name, with a .conf (in 1.4.0) or .nxc (in 1.5.0) suffix. If you connect to different NX servers or to the same one with various settings, this is a handy feature.
fill in the fully qualified hostname or the IP address of the NX server to which you want to connect.
use the correct port number to connect. Because NX utilizes the target system's SSH daemon for connections, this usually is port 22, but this need not be so. An SSH daemon may be configured to listen on multiple ports or on a more unusual one. If you plan to set up an "outside" NX server that you need to access from an internal network through a firewall, port 443 (usually assigned to the HTTPS protocol) often is convenient to use, because most firewalls and their admins already allow access to that port. If in doubt, check with your network administrator.
use the slider to change the level of NX compression from highest (Modem) to none at all (LAN). It doesn't hurt and often is beneficial to use the Modem compression level, even if you are on a DSL line. Notice that the LAN setting does not use any compression at all, so be sure to play with variations for that setting if the session performs too slowly for you.
On the third Wizard screen, you can select the session type. The NoMachine NX testdrive server does not offer Windows or VNC connections, however. For Figure 8, the numbered fields correspond accordingly to the following tasks:
this dropdown menu offers Unix, Windows and VNC connections
this dropdown menu offers KDE, Gnome, CDE or Custom sessions for Unix connections; it is grayed out and disabled for Windows or VNC connections.
the Settings button is enabled for Unix/Custom or Windows and VNC connections. A Unix/Custom connection and Windows or VNC ones are explained in other screenshots.
this field determines the window size of your remote NX session. 1.5.0 NX servers allow to change the size on the fly; 1.4.0 server sessions use the same fixed size throughout their lifetime. You can select between various pre-defined sizes, a custom size or Fullscreen. Fullscreen is particularly interesting in that it creates a window without any borders that overlays the original client machine screen. This way you can pretend to run a Linux KDE session even from a Windows NX client without much risk that the occasional observer will discover the "fake". If you choose a custom window size, you set the width and height in 4a and 4b. There is no restriction here; you even may choose a portrait type window for your remote desktop.
enabling "SSL encryption of all traffic" permanently is highly recommended. However, be aware that the ongoing encryption and its companion decryption of all traffic puts more load onto both CPUs, NX client as well as NX server. You may want to disable it for older client hardware with weaker CPUs, in case you are running your NX network inside an isolated corporate network with trusted users only.
On the final screen of the Connection Wizard, you can use Field 1 to create a shortcut on the desktop that is handy to re-run the remote session. The Advanced Configuration dialog is introduced in other screenshots below.
The standard NX Client login dialog provides spaces for you to enter:
your login name or user ID to use, as communicated to you by e-mail.
your password, not displayed in clear text but hidden behind the asterisks.
a self-invented name for your upcoming NX session. This name is used to store your selected settings in a sessionname.conf config file. You can have variants of settings for the same or various remote NX servers stored under different names for easier re-use at a later time. The Session field is editable. If you change it, NX asks you if you want to create a new configuration under the changed name or if you want to rename the old configuration.
the Configure... button brings up the advanced configuration dialog, which is discussed in other screenshots below.
click Login to start up a remote session.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- RSS Feeds
- It is quiet helping
1 hour 1 min ago
1 hour 18 min ago
- Reachli - Amplifying your
2 hours 35 min ago
3 hours 24 min ago
- good point!
3 hours 27 min ago
- Varnish works!
3 hours 36 min ago
- Reply to comment | Linux Journal
4 hours 5 min ago
- Reply to comment | Linux Journal
6 hours 31 min ago
- Reply to comment | Linux Journal
10 hours 31 min ago
- Yeah, user namespaces are
11 hours 47 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?