Newsgroups: ru.comp.qa.windows.x Subject: Re: Help: Using X from remote with server on Linux Distribution: ru References: bjkramer@remus.rutgers.edu (Brian Kramer) writes: >How do I use X windows from remote? I have an X server on Linux. >What commands do I need to execute to get my X server to recognize the >machines at RU. How do I connect? I have a term program cakked >seyon, and Linux is a fully functional unix system for PC's. It has >all the same commands that the unix at RU does as well as full >Xwindows support. >Do I need a slip connection? Linux does support slip. Can I get a >SLIP connection from RU? How do I do this? You can use X via either SLIP or term. I don't know much about term, so I won't comment on it. However the speed of a dialup line is a bit marginal for X. I generally recommend trying to run your software on your Linux system where possible, and using X only for things that absolutely have to be run at Rutgers. I normally connect to Rutgers using SLIP. This gives me a TCP/IP connection. You can run any network utility, just as if you were on the campus network directly -- except much slower. This includes running X applications. However you'll get better response if you open an xterm window on your Linux machine and telnet to a Rutgers system, rather than running xterm remotely on the Rutgers system. The reason is that telnet connections send a lot fewer bytes of data than X connections. So here's how I normally do things: xterm - as just mentioned, I open xterm windows locally, and telnet to the machine I want to log into. I give you a script to do this below. mosaic - I run it on my Linux machine. I've run it successfully at Rutgers, and gotten it to display using X over SLIP, but it took forever to start up. It's much better just to run it at home. wxmap - I don't have a copy for Linux, and I don't think there would be much advantage to running it at home anyway. I run this at Rutgers and display using X over SLIP. emacs - obviously if I'm editing a file on a Rutgers machine, I have to run Emacs there (well, technically there are other approaches, but this is the most sensible one). However I prefer to disable X support in emacs (by unsetting the DISPLAY environment variable). Otherwise starting emacs takes a long time. Emacs version 18 was just barely tolerable, but Emacs version 19 takes too long to start up using X over SLIP. (If you really wanted to use X support, there's a way around this -- Emacs can run in a client-server mode. When you use emacsclient, you only have to start up a copy of emacs once in a session.) The rest of this message contains three sections: 0. software versions I. starting up SLIP -- what you do each time you want to use SLIP II. configuring SLIP -- one-time setup III. using X via SLIP 0. software versions These instructions assume that you're using at least version 0.99pl15 of the kernel, and new versions of dip and route. Versions of other network utilities are less critical. You should have no trouble getting a current kernel. It's on tsx-11, sunsite, and other places you're likely to find kernels. However it's sometimes a bit hard to find the current version of some of the other software. I've put current version of the following programs on athos.rutgers.edu in /pub/linux: dip, route, trf.tar.Z trf.tar.Z is a compressed tar file containing telnet, rlogin, and ftp. It's critical for you to have the latest dip and route. Otherwise these instructions may not work. Telnet, rlogin, and ftp are not as critical. These instructions assume that you are using a copy of dip that supports bootp. As that code hasn't made it into the official version yet, for the moment these instructions work only with the version of dip on athos.rutgers.edu. I. starting up SLIP -- what you do each time you want to use SLIP To start up SLIP. I'm going to give you commands in detail. Presumably you won't really type all of this each time, but will put the commands into scripts. I'm going to give instructions for kermit, because I don't know seyon. 0) You should set a hostname on your machine. Normally this is done in /etc/rc, but you can do it manually. It doesn't much matter what name you use. I use my own name, i.e. hedrick.rutgers.edu. However make sure you pick a name that isn't actually in use at Rutgers. For the purposes of this document I'm going to use foo.rutgers.edu (though there is actually a host by that name). The command to make that your hostname is hostname foo.rutgers.edu There's some wierdness about this, because the name doesn't actually correspond to anything. (When you connect to our terminal servers, they give you a different IP address and name each time.) But some software gets confused if you don't have a hostname set. These instructions assume that no other network setup is being done in /etc/rc or any other startup scripts. When you install the network software, the installation instructions may tell you to put various things into your startup scripts. If you do anything other than what I tell you, I take no responsibility for the results. 1) dial a Rutgers terminal server using kermit. Configure your modem for the fastest possible speed. You might want to try different setting of compression. With some modems you may get better response if you disable MNP or V.42 error control and compression, because these introduce some delay. Note that TCP/IP has error control, so you don't absolutely need the modem's error control (though it is likely to help performance significantly). I'd try it both ways. You may also be able to get better performance by changing things like MNP or v.42 block size and dispatch timeout if your modem allows that. 2) Once you get the terminal server prompt, login. The things you type are underlined terminalserver> login ----- Username: user@host --------- Password: password (will not echo) -------- terminalserver> slip ---- Entering SLIP mode. Your IP address is 128.6.4.123. MTU is 1500 bytes. Header compression will match your system. As shown here, the login command will ask you for a user name and password. For this, you must have an account on one of our Unix machines (in your case remus). Furthermore, it must be one of the machines whose name is listed in the banner message that you get when the terminal server first answers. When the terminal server asks for Username, you should respond with the user name and hostname of the machine on which you have the account. When it asks for Password, you must give the password for your account on that machine. Note that the terminal server doesn't actually log you in on the Unix machine. It simply queries the Unix machine to verify that you have an account there, and that the password is right. In addition to Username and Password, the terminal server may ask for an address. If it does, say "default". 3) Now exit from kermit. With kermit there's no problem, but if you use some other communications program, make sure it doesn't hang up the telephone when you exit! 4) On your Linux machine, as root, type the following commands. dip -t port tty65 ;use your actual tty name, probably ttys0 or ttys1 speed 19200 ;or whatever speed you're really using get $mtu 192 bootp mode CSLIP If dip does not recognize the "bootp" command, make sure you are using the copy of dip from athos.rutgers.edu:/pub/linux. dip should detach itself from the terminal. I.e. at this point you should get another prompt. If you don't, try typing ^Z and then "bg" /etc/route add default dev sl0 /usr/etc/inetd ;if you want to allow incoming services (There are also multiple versions of route. Older ones may not understand the "dev" specification. Again, for more complete instructions, see slip.instructions.) Once this works, you'll want to put the commands port, speed, get, bootp, and mode into a file and run dip on that file. E.g. you might create a file /usr/local/lib/slip.dip containing port tty65 speed 19200 get $mtu 192 bootp mode CSLIP Then all you need to do is dip /usr/local/lib/slip.dip I actually use a shell script that contains this dip command and the routing commands: dip /usr/local/lib/slip.dip route add default dev sl0 inetd Note that using inetd is optional. (You may need to specify the path for route and inetd if they aren't in your default path.) If you run inetd, you'll need to set up /etc/inetd.conf to list the servers that you want run. I recommend keeping the number of servers to a minimum. That is, I suggest that you remove or comment out most of the lines in inetd.conf as it comes with the software distribution. There are security concerns with running servers. Do you really need people to be able to log into your PC from Rutgers? It's probably best not to run inetd at all. 5) It should now be possible to telnet, ftp, etc. 6) To shutdown, kill dip and (if you run it) inetd. Here's the script I use: #!/bin/tcsh -f set pid = `ps agx | grep inetd | grep -v grep` kill $pid[1] set pid = `ps agx | grep dip | grep -v grep` kill $pid[1] ------------------------ II. configuring SLIP -- one-time setup Those instructions tell you have to start up SLIP once you've got it set up. Here's what you have to do to get it set up. First, you need the current network utilities. This is things like telnet and ftp. I'm using a very old set. I really don't know much about where they are now. The copy I used originally came from tsx-11.mit.edu, with a few others from other places. See net-2-utils.README via anonymous FTP on athos.rutgers.edu in /pub/linux. Some patched versions of software are in that directory. However by the time you read this, Linux 1.0 should be out, with new versions of all the utilities. During the time before the release of 1.0, you'll find source to the new versions at ftp.funet.fi, in /pub/OS/Linux/PEOPLE/Linus/net-sources. Unfortunately they are available only in source form. Second, you need a kernel that contains support for SLIP. I recommend using 0.99pl15 or later. When you build the kernel, "make config" will ask you a series of questions. You must answer "y" to "Network device support", "SLIP support" and "CSLIP compressed headers". That will give you a kernel that has SLIP in it. Third, you need a couple of configuration files: /etc/host.conf: one line specifying the order in which to use the hosts file and the resolver. I suggest order hosts bind /etc/resolv.conf: your domain and nameserver. For Rutgers this would be domain rutgers.edu nameserver 128.6.4.4 There are a lot more configuration files needed for a full network setup. But for simple stuff like telnet and ftp, this is all you need. I recommend not having the file /etc/hosts. --------------------------------------------------- III. using X via SLIP To run an X application at Rutgers and have it display on your Linux machine, you need to deal with two things: 1) Make sure DISPLAY is set in the shell you're using at Rutgers. By default telnet should set DISPLAY for you. If you have to set it manually, type the command setenv DISPLAY 128.6.4.123:0.0 at Rutgers. (Remember that 128.6.4.123 is just an example. You must use the actual IP address that the terminal server assigned you.) 2) Make sure that the X server on your Linux system is set to allow connections from the machine you're using at Rutgers. To do this, type the command xhost +foo.rutgers.edu on your Linux machine, where foo.rutgers.edu is the name of the system you're using at Rutgers. There's a security problem with this. It lets anyone on foo use your X server. There are some bad things people can do by connecting to your X server. So I recommend that you do this right before starting the X application, and once it's started, do xhost -foo.rutgers.edu Once the application has made its connection, xhost no longer needs to be in effect. The application will continue to run. There are better approaches than this, but they involve modifying the X startup script on your Linux machine, and finding a way to update .Xauthority on your Rutgers machine. I haven't found a practical way to do that yet. Note: if the environment variable DISPLAY is set, Emacs will attempt to open an X window. Because that takes a while, you may want to remove the DISPLAY variable for normal operation, and only set it when you're actually going to use an X application. To unset DISPLAY, use the command unset DISPLAY Here are some scripts I use: On my Linux machine I use this script to open an X window on a Rutgers machine. Note that this actually starts an xterm on my Linux machine and telnets to Rutgers. That's my preferred approach: #!/bin/tcsh -f xterm -T $1 -e tcsh -c "unsetenv DISPLAY; telnet -r $1" & I call this script /usr/local/bin/x. Note that it unsets DISPLAY. If it doesn't bother you that emacs comes up using X, you can omit this. On my Rutgers machine, I put this in .login: set myhost = `who am i` if ($#myhost >= 6) then set myhost = $myhost[6] set myhost = `echo $myhost | sed -e ' s/\..*//' -e 's/^(//' -e 's/)$//'` if ($myhost != "") then setenv MYHOST $myhost endif endif unset myhost This sets up an environment variable MYHOST to have the IP address of my Linux machine. That's needed to set DISPLAY. In .cshrc on my Rutgers account I put: alias X "(setenv DISPLAY ${MYHOST}:0.0; \!*)" That allows me to execute an X application. It sets up DISPLAY just for that one call. This is only necessary because I don't normally leave DISPLAY set (in order to avoid getting the X version of emacs). If you leave DISPLAY set, you don't need this. E.g. to run wxmap I would do X wxmap PS: If you want to use X for interactive work, there's one more thing you can do. There's a program called sxpc, which provides compression for X connections. This significantly improves performance. You'll find it at both tsx-11.mit.edu and sunsite.unc.edu. There are instructions with it. I don't recommend trying sxpc until you have everything working correctly without it.