Unix way of doing GUI's1 has always been different than Windows way of doing things. There are client and server programs that communicate with each other via network. Most commonly used X-server is XFree86 [xf]. (You can read more about basic operation from [xf].) We can use so called ssh-program 2 to make our connections more secure and robust. Firstly we need to get ssh and install it. We can get it from [ssh], either in rpm packet or in ``tarred'' source packet. RPM packet usually is easier way, they just install with
rpm -Uvh openss*.rpmAfter that you should be able to invoke ssh with simply typing ``ssh'':
[henkka@ping henkka]$ ssh Usage: ssh [options] host [command] Options: -l user Log in using this user name. -n Redirect input from /dev/null. -A Enable authentication agent forwarding. -a Disable authentication agent forwarding. -X Enable X11 connection forwarding. -x Disable X11 connection forwarding. -i file Identity for RSA authentication (default: /.ssh/identity). -t Tty; allocate a tty even if command is given. -T Do not allocate a tty. -v Verbose; display verbose debugging messages. Multiple -v increases verbosity. -V Display version number only. -P Don't allocate a privileged port. -q Quiet; don't display any warning messages. -f Fork into background after authentication. -e char Set escape character; ``none'' = disable (default: ). -c cipher Select encryption algorithm: ``3des'', ``blowfish'' -p port Connect to this port. Server must be on the same port. -L listen-port:host:port Forward local port to remote address -R listen-port:host:port Forward remote port to local address These cause ssh to listen for connections on a port, and forward them to the other side by connecting to host:port. -C Enable compression. -N Do not execute a shell or command. -g Allow remote hosts to connect to forwarded ports. -4 Use IPv4 only. -6 Use IPv6 only. -2 Force protocol version 2. -o 'option' Process the option as if it was read from a configuration file. [henkka@ping henkka]$As you can see, we could now easily connect to another machine just by typing
ssh remotemachineThat connects us to ``remotemachine'' with username ``remoteuser''. And after we give our password, the remote shell is opened for us:
[henkka@ping henkka]$ ssh kilpikonna henkka@kilpikonna's password: Last login: Thu Feb 15 21:15:16 2001 from ping.koti [henkka@kilpikonna henkka]$Notice how first the machine name is ``ping'' and after successfull connection it changes to ``kilpikonna''. Everything we now type at the ``kilpikonna'' terminal would be secured by ciphering it with DES/Blowfish cryptocraphy.
We could now invoke program that needs X-connection (such as TkEMC-frontend). The connection is automatically forwarded from remote machines (``kilpikonna'') display to our local display (``ping''). No matter if there is 1m or 1000km between those computers, it just forwards the connection same way. It does this by taking just the needed ``display'' or ``windows'' and transferring only these. And of course mouse and keyboard inputs are transferred too. In my personal network I'm using this regulary with TkEMC because I want ``normal'' PC to control the CNC-machine and I want to have as much workspace as possible at my workingtable. So I'm using laptop to connect to PC running EMC/TkEMC and that PC doesn't even have keyboard/display connected. Ssh can be set up so that you don't have to provide passwords every time you connect to machine. This is so called RSA-key authentication. Here is the sample setup of such an arrangement. Machine ``ping'' is where I'm connecting FROM and ``kilpikonna'' is where I'm connectin TO. So here's the setup:
[henkka@ping henkka]$ ssh-keygen... it creates the necessary key-pairs ...
[henkka@ping henkka]$ scp /.ssh/identity.pub kilpikonna:.ssh/authorized_keys henkka@kilpikonna's password:(it copies the public key to machine we want connect to. Notice the dot ( . ) before ``ssh'', it's critical.)
(now we are in kilpikonna's terminal)[henkka@ping henkka]$ ssh kilpikonna henkka@kilpikonna's password: Last login: Thu Feb 15 21:15:16 2001 from ping.koti
[henkka@kilpikonna henkka]$ ls -l /.ssh/authorized_keys -rw-r--r-- 1 henkka henkka 995 Sep 6 10:01 /home/henkka/.ssh/authorized_keys(so there is the file we just copied. There are too much right's for it just now, and ssh won't work with them, so we need to tighten them a bit)
[henkka@kilpikonna henkka]$ chmod go-rwx /.ssh/authorized_keys [henkka@kilpikonna henkka]$ ls -l /.ssh/authorized_keys -rw------- 1 henkka henkka 995 Sep 6 10:01 /home/henkka/.ssh/authorized_keys(so now there is just read and write permissions for owner only, nobody else can't read or write to that file). Now just type
[henkka@kilpikonna .ssh]$ exitto exit from kilpikonna and try to connect again:
[henkka@ping henkka]$ ssh kilpikonna Last login: Thu Feb 15 21:15:16 2001 from ping.koti [henkka@kilpikonna henkka]$So now we didn't need the password anymore. This is handy when we are copying files between computers frequently etc. The file-copying command is ``scp'', and it works (almost) just like ``cp'' does:
[henkka@ping henkka]$ scp usage: scp [-pqrvC46] [-P port] [-c cipher] [-i identity] f1 f2; or: scp [options] f1 ... fn directorySo basically it's like this if we would like to copy one file to remote computer:
scp setup.txt remotemachine:That would copy file ``setup.txt'' to ``remotemachine'' named computer to our home directory. Notice that ``:`` at the end tells that this is not a regular file but an computer.
scp setup.txt remotemachine:/tmpwould copy same file to remote directory ``/tmp''.
scp setup* remotemachine:/tmpwould copy all files begining ``setup'' to remote ``/tmp''. scp works another way around also, we just need to know the exact location of file in remote machine what we are going to copy:
scp remotemachine:/tmp/setup.txt .would copy remote ``/tmp/setup.txt'' to our computer to current directory (you can always see what is current directory with ``pwd'' command)
scp remotemachine:/tmp/*setup* .would copy all remote files at ``/tmp'' directory matching pattern ``*setup*'' to our computer to current directory. Notice the backslash ( ) before asterixs ( * ), that is needed because we want that remote end ``expands'' the ``*'' mark, not our local end. The backslash transmits the ``*'' mark as it is, without our local end expanding it.
Another opportunity is to use special VNC[vnc]3 software to maintain same state of desktop no matter where you are connecting from. VNC is a software that creates it's own X-session and waits for special vnc-client to connect to that server. VNC client can be a) Windows machine, b) Unix/Linux-machine, c) Machintosh or d) almost anything that have Java-capable browser. That way we can run every EMC GUI from any platform / network we choose.
First we setup an VNC-server so that client can connect to that. After that we connect that server with client (optionally securing our connection with ssh) and then we just start TkEMC normally. When we want to exit our current session, just quit the VNC client (leave TkEMC and CNC-PC on) and that's it. Next time just connect again with CNC-client (maybe from another PC or even from work, if you would like to show how flexible EMC+Linux is ;-) ) and 'voila, you have the exactly same desktop where you last dropped it. It can sometimes be handy to monitor what EMC-PC is doing by just simply taking VNC connection, looking for EMC's backplot, closing connection and doing something else while CNC machine does it's job.
http://www.xfree.org
http://www.openssh.org, http://www.rpmfind.net/linux/rpm2html/search.php?query=openssh
https://en.wikipedia.org/wiki/Virtual_Network_Computing
[GUI]Graphical User Interface. Term refers to windows, graphics, buttons etc. where user can interact with program
[SSH]Secure SHell
[VNC]Virtual Network Computing