``There's more than one way to do it.'' Since the various ways have their own advantages and disadvantages, several are mentioned here. The console (text-only) login or the VNC (graphical) login are most likely to be of interest.
All users on the systems are authenticated by the department's fileserver. Users have the same usernames as on the webserver and the ms-windows domain. The passwords are the same as for the webserver and other linux hosts.
If you have never used SCP or SSH to the webserver or simulation servers, you probably need to ask an administrator to set an initial password for you.
(Some day, it is supposed to be that all computers here start using the university-wide system [kerberos and ldap], with accounts and passwords thereby becoming automatic... This still hasn't happened in several years, so I'm giving no further thought to it until told that old accounts need to be changed -- I prefer my short local username!)
File-space for users is described more on another page. Users will probably want to copy files between their own computers and the simulation servers. The home-directory is the same on all the servers and on the division's web-server, as well as on linux or other unix desktop computers. It is available from ms-windows computers as \\penguin\USERNAME and in some cases will be automatically mounted on H:. This is probably the simplest and easiest way to transfer files, using this common storage space.
As an alternative, for example, for use from home or to access other directories local to the server, e.g. /local and /tmp, ssh-based file-transfer methods can be used:
SCP is `secure copy', and uses an ftp transaction tunnelled through ssh. From Unixes, `scp user@host:~/file ./' would transfer file `file' from the home-directory on remote computer `host', logging in as `user'. Reverse the arguments to copy the other way. Add the option `-r' to copy a directory recursively. A GUI client for SCP for ms-windows is WinSCP.
rsync is discussed more on another page; it is highly suitable for transferring just the required differences to make a local and remote directory become the same. Its remote use is done (as usual) by tunnelling through ssh. `rsync -avz user@host:/local/work/ ./host_work/ ' would update a local directory `host_work' to be the same as the directory `/local/work' on the remote host `host'.
Login is available by SSH (secure shell). On pretty much any modern Unixish system the ssh command should be available, and is used as `ssh hostname' or `ssh user@hostname', where the hostname is, for example diagsim.ets.kth.se (the ets.kth.se part isn't needed internally, but probably will be if connecting from outside). For ms-windows systems an ssh client such as PuTTY will be needed; download putty.exe, run it, and give the above hostname, connecting by ssh (port 22). You should then end up, after giving your password, with a shell prompt ready for commands. Only text-based programs can then be used.
Advantage: simple, quick, available from anywhere on the internet.
Disdvantage: no graphical programs, everything dies if connection fails (unless
using the `screen' program
that allows multiple virtual consoles on a single login).
The graphical windowing system, `X', used in Unix systems, is `network transparent': any running X-server program can display a graphical window from a client program as long as the two have been told to use/accept each other.
[The old way to do this, which will work within the division's subnet and could even be made to work to a home computer (not really advised) is: run an X-server on one's own local (client) computer (this will already be the case with any graphical Unix system, but an extra program is needed for ms-windows); configure this X-server to accept connections from the simulation server, e.g. `xhost +diagsim' to allow a host called diagsim; log in to the simulation server by ssh (to be properly old-fashioned, you'd use telnet), then type `export DISPLAY=own.host.name:0.0' before running any graphical program. This way, all graphics are sent unencrypted to display :0.0 on the computer `own.host.name'.]
The much, much easier, and secure modern way is just to connect by ssh, using the options -XY (forward X11, all). So: `ssh -XY user@host'. Then, as long as you have an X-server on your computer, available to the ssh program, everything will work automatically, with all the X connections tunnelled through ssh. ms-windows ssh clients such as putty will have an option to click somewhere to enable X-forwarding (but remember: you need an X-server too).
Advantage (modern way): simple, quick, available from anywhere on the internet,
includes graphics.
Disadvantage: X is intended for quite fast networks and will be unpleasant to
use without several Mbps connection, everything dies if connection fails.
VNC is a way of remotely viewing a graphical desktop. In our case, the vncserver program starts an X-server on the simulation server, called Xvnc: this allows client programs to connect to the Xvnc display, and the Xvnc program basically makes a video of the desktop available to VNC clients on the network (without actually doing any physical display of the desktop on the server computer).
This has the advantage over normal X that the viewer program is freely and easily available even on ms-windows systems (it needs to be downloaded), and that the VNC connection for transferring the image of the desktop can be adjusted for slow connections. Perhaps most importantly, the VNC server and all the running programs keep running even if the client computer or network has a problem: a re-connection can be made later.
What is rather tedious is that instead of using `system authentication' and starting vnc servers automatically for users who try to access them, the VNC default is that a user first starts the vnc server on the server computer, sets up a password for connections, remembers which `display number' the server got, then connects to it from the client with the vncviewer program! Until the server is rebooted (once a year or so in our case) this VNC session should remain, but it's still a little less easy than just an ssh login!
How to do it: having installed the VNC programs if necessary (ms-windows), log in by ssh (see above) to the desired simulation server. Run the command `vncserver'. On the first time, it will ask you to set a password; give something of at least 6 characters. Remember which display number you get (e.g. diagsim:4). Then, from the client computer, run the command `vncviewer diagsim:4' to connect to it, or (ms-windows) run the GUI vncserver program and tell it to connect to `diagsim:4' or whatever host and display number is valid for your case.
The above method is fine within the division, since there's no network filtering or particular security risk with unencrypted traffic. For better security, ssh tunnelling can be used. The unix vncviewer program takes a -via option as a host to use for tunnelling: `vncviewer -via diagsim diagsim:4' would first require an ssh login to diagsim, then would connect the vnc viewer through this tunnel to vnc display `diagsim:4' (requiring the vnc password). If this is the only way you intend to connect, then start the vnc server with the -localhost option so that it won't even listen on the network. Then the vncserver command would be `vncserver -localhost' and the client would be `vncviewer -via diagsim localhost:4' (or other display number).
The vnc password is stored in you home-directory, under the .vnc/ directory. There is also a file .vnc/xstartup which by default starts the very quick and simple IceWM window manager (desktop), with a menu of programs hoped to be useful to ETK users. You can change your vnc desktop by altering the `icewm' line to something else like for example `startkde' for a much more thorough desktop. The vnc server can have its size set on startup, with the option `-geometry widthxheight', e.g. `vncserver -geometry 1280x960'.
Notes: You don't need to start a new vncserver for every time you connect! The session stays open, waiting for the next client connection. (It can be destroyed with `vncserver -kill hostname:displaynumber'.) There have been cases of tens of running vncservers when I didn't make it clear that the server only needs to be started once! Movement on screen wastes CPU time! If there is, for example, lots of text streaming down a window that is shown on vnc, then this wastes lots of server CPU time just encoding all that information to send to the client. Simply minimising such windows or hiding them behind others prevents this waste.
Advantages: graphical, better than X on slow network, doesn't die if
network or client fails, client is easily and freely available even on
ms-windows.
Disadvantages: for local connections it's generally not as responsive as
X, since everything seen is a picture (not at all bad, though); it also
takes a little more user effort than the other methods, particularly
for secure access from ms-windows clients outside the division; some
programs requiring 3D acceleration will fail (e.g. Comsol with 3D model).
From within the division's network, the display managers of the simulation servers are available to manage a login window to any X-server that asks. So, starting an X-server with the option `-query diagsim' would get a GUI login screen to diagsim, giving options of which graphical environment to use. This X-server could be: an ms-windows based one; or, the `X-server-in-a-window' called Xnest (invoked as for example `Xnest :9 -geometry 1024x768 -query diagsim' if display :9 isn't already in use). The login screen on our Linux hosts has an option "Remote Login" that will display other available systems and allow connecting to them instead of to the local display manager.
Advantages: fully graphical, simple.
Disadvantages: only available within the division, client or network problem
makes whole session die.
(The NX server on our systems is limited to 2 concurrent sessions in order not to incur licensing costs.)
`Nomachine' makes a clever enhanced X implementation that uses caching and round-trip reduction to give good response even when running on a distant, slow connection. It is primarily intended for the (our) situation of a Unix (Linux or Solaris) server running applications for mixed clients. A proprietary server and freely downloadable multiplatorm client are available, and so is a freely downloadable server limited to two users. There is support for encryption and for leaving a session running in the background after logout, for a later reconnection (`resuming').
The libraries used for the protocol have been released as GPL licensed
free software, and some projects provide variations on a server, e.g.
FreeNX.
This seems to be a rather suitable system for us, but so far the expensive
proprietary server seems the only suitable one for our needs.
Page started: 2007-11-xx
Last change: 2008-12-01