From f91c6a92c086edf8e56e17967f020773b41ef5a6 Mon Sep 17 00:00:00 2001 From: binh <> Date: Mon, 17 Jan 2005 13:25:33 +0000 Subject: [PATCH] Removed X11.xml and PPP-SLIP.xml Binh. --- .../docbook/Linux-Networking/PPP-SLIP.xml | 953 ----------------- LDP/guide/docbook/Linux-Networking/X11.xml | 993 +----------------- 2 files changed, 2 insertions(+), 1944 deletions(-) delete mode 100644 LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml diff --git a/LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml b/LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml deleted file mode 100644 index 3cf3a707..00000000 --- a/LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml +++ /dev/null @@ -1,953 +0,0 @@ - - -PPP-SLIP - - -3.7. PPP, SLIP, PLIP - -The Linux kernel has built-in support for PPP (Point-to-Point- -Protocol), SLIP (Serial Line IP) and PLIP (Parallel Line IP). PPP is -the most popular way individual users access their ISPs (Internet -Service Providers). PLIP allows the cheap connection of two machines. -It uses a parallel port and a special cable, achieving speeds of -10kBps to 20kBps. - -· Linux PPP HOWTO - -· PPP/SLIP emulator - -· PLIP information can be found in The Network Administrator Guide - - -7.5.1. dip - - -dip (Dialup IP) is a smart program that is able to set the speed of -the serial device, command your modem to dial the remote end of the -link, automatically log you into the remote server, search for -messages sent to you by the server and extract information for them -such as your IP address and perform the ioctl necessary to switch your -serial port into SLIP mode. dip has a powerful scripting ability and -it is this that you can exploit to automate your logon procedure. - - - -You can find it at: metalab.unc.edu. - - - -To install it, try the following: - - - - - user% tar xvzf dip337o-uri.tgz - user% cd dip-3.3.7o - user% vi Makefile - root# make install - - - - -The Makefile assumes the existence of a group called uucp, but you -might like to change this to either dip or SLIP depending on your -configuration. - - -7.5.2. slattach - - -slattach as contrasted with dip is a very simple program, that is very -easy to use, but does not have the sophistication of dip. It does not -have the scripting ability, all it does is configure your serial -device as a SLIP device. It assumes you have all the information you -need and the serial line is established before you invoke it. slattach -is ideal to use where you have a permanent connection to your server, -such as a physical cable, or a leased line. - - -7.5.3. When do I use which ? - - -You would use dip when your link to the machine that is your SLIP -server is a dialup modem, or some other temporary link. You would use -slattach when you have a leased line, perhaps a cable, between your -machine and the server and there is no special action needed to get -the link working. See section `Permanent Slip connection' for more -information. - - - -Configuring SLIP is much like configuring an Ethernet interface (read -section `Configuring an ethernet device' above). However there are a -few key differences. - - - -First of all, SLIP links are unlike ethernet networks in that there is -only ever two hosts on the network, one at each end of the link. -Unlike an ethernet that is available for use as soon are you are -cabled, with SLIP, depending on the type of link you have, you may -have to initialize your network connection in some special way. - - - -If you are using dip then this would not normally be done at boot -time, but at some time later, when you were ready to use the link. It -is possible to automate this procedure. If you are using slattach then -you will probably want to add a section to your rc.inet1 file. This -will be described soon. - - - -There are two major types of SLIP servers: Dynamic IP address servers -and static IP address servers. Almost every SLIP server will prompt -you to login using a username and password when dialing in. dip can -handle logging you in automatically. - - -7.5.4. Static SLIP server with a dialup line and DIP. - - -A static SLIP server is one in which you have been supplied an IP -address that is exclusively yours. Each time you connect to the -server, you will configure your SLIP port with that address. The -static SLIP server will answer your modem call, possibly prompt you -for a username and password, and then route any datagrams destined for -your address to you via that connection. If you have a static server, -then you may want to put entries for your hostname and IP address -(since you know what it will be) into your /etc/hosts. You should also -configure some other files such as: rc.inet2, host.conf, resolv.conf, -/etc/HOSTNAME and rc.local. Remember that when configuring rc.inet1, -you don't need to add any special commands for your SLIP connection -since it is dip that does all of the hard work for you in configuring -your interface. You will need to give dip the appropriate information -and it will configure the interface for you after commanding the modem -to establish the call and logging you into your SLIP server. - - - -If this is how your SLIP server works then you can move to section -`Using Dip' to learn how to configure dip appropriately. - - -7.5.5. Dynamic SLIP server with a dialup line and DIP. - - -A dynamic SLIP server is one which allocates you an IP address -randomly, from a pool of addresses, each time you logon. This means -that there is no guarantee that you will have any particular address -each time, and that address may well be used by someone else after you -have logged off. The network administrator who configured the SLIP -server will have assigned a pool of address for the SLIP server to -use, when the server receives a new incoming call, it finds the first -unused address, guides the caller through the login process and then -prints a welcome message that contains the IP address it has allocated -and will proceed to use that IP address for the duration of that call. - - - -Configuring for this type of server is similar to configuring for a -static server, except that you must add a step where you obtain the IP -address that the server has allocated for you and configure your SLIP -device with that. - - - -Again, dip does the hard work and new versions are smart enough to not -only log you in, but to also be able to automatically read the IP -address printed in the welcome message and store it so that you can -have it configure your SLIP device with it. - - - -If this is how your SLIP server works then you can move to section -`Using Dip' to learn how to configure dip appropriately. - - -7.5.6. Using DIP. - - -As explained earlier, dip is a powerful program that can simplify and -automate the process of dialing into the SLIP server, logging you in, -starting the connection and configuring your SLIP devices with the -appropriate ifconfig and route commands. - - - -Essentially to use dip you'll write a `dip script', which is basically -a list of commands that dip understands that tell dip how to perform -each of the actions you want it to perform. See sample.dip that comes -supplied with dip to get an idea of how it works. dip is quite a -powerful program, with many options. Instead of going into all of -them here you should look at the man page, README and sample files -that will have come with your version of dip. - - - -You may notice that the sample.dip script assumes that you're using a -static SLIP server, so you know what your IP address is beforehand. -For dynamic SLIP servers, the newer versions of dip include a command -you can use to automatically read and configure your SLIP device with -the IP address that the dynamic server allocates for you. The -following sample is a modified version of the sample.dip that came -supplied with dip337j-uri.tgz and is probably a good starting point -for you. You might like to save it as /etc/dipscript and edit it to -suit your configuration: - - - - - # - # sample.dip Dialup IP connection support program. - # - # This file (should show) shows how to use the DIP - # This file should work for Annex type dynamic servers, if you - # use a static address server then use the sample.dip file that - # comes as part of the dip337-uri.tgz package. - # - # - # Version: @(#)sample.dip 1.40 07/20/93 - # - # Author: Fred N. van Kempen, - # - - main: - # Next, set up the other side's name and address. - # My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42) - get $remote xs4all.hacktic.nl - # Set netmask on sl0 to 255.255.255.0 - netmask 255.255.255.0 - # Set the desired serial port and speed. - port cua02 - speed 38400 - - # Reset the modem and terminal line. - # This seems to cause trouble for some people! - reset - - # Note! "Standard" pre-defined "errlevel" values: - # 0 - OK - # 1 - CONNECT - # 2 - ERROR - # - # You can change those grep'ping for "addchat()" in *.c... - - # Prepare for dialing. - send ATQ0V1E1X4\r - wait OK 2 - if $errlvl != 0 goto modem_trouble - dial 555-1234567 - if $errlvl != 1 goto modem_trouble - - # We are connected. Login to the system. - login: - sleep 2 - wait ogin: 20 - if $errlvl != 0 goto login_trouble - send MYLOGIN\n - wait ord: 20 - if $errlvl != 0 goto password_error - send MYPASSWD\n - loggedin: - - # We are now logged in. - wait SOMEPROMPT 30 - if $errlvl != 0 goto prompt_error - - # Command the server into SLIP mode - send SLIP\n - wait SLIP 30 - if $errlvl != 0 goto prompt_error - - # Get and Set your IP address from the server. - # Here we assume that after commanding the SLIP server into SLIP - # mode that it prints your IP address - get $locip remote 30 -if $errlvl != 0 goto prompt_error - -# Set up the SLIP operating parameters. -get $mtu 296 -# Ensure "route add -net default xs4all.hacktic.nl" will be done -default - -# Say hello and fire up! -done: -print CONNECTED $locip ---> $rmtip -mode CSLIP -goto exit - -prompt_error: -print TIME-OUT waiting for sliplogin to fire up... -goto error - -login_trouble: -print Trouble waiting for the Login: prompt... -goto error - -password:error: -print Trouble waiting for the Password: prompt... -goto error - -modem_trouble: -print Trouble occurred with the modem... -error: -print CONNECT FAILED to $remote -quit - -exit: -exit - - - - -The above example assumes you are calling a dynamic SLIP server, if -you are calling a static SLIP server, then the sample.dip file that -comes with dip337j-uri.tgz should work for you. - - - -When dip is given the get $local command it searches the incoming text -from the remote end for a string that looks like an IP address, ie -strings numbers separated by `.' characters. This modification was put -in place specifically for dynamic SLIP servers, so that the process of -reading the IP address granted by the server could be automated. - - - -The example above will automatically create a default route via your -SLIP link, if this is not what you want, you might have an ethernet -connection that should be your default route, then remove the default -command from the script. After this script has finished running, if -you do an ifconfig command, you will see that you have a device sl0. -This is your SLIP device. Should you need to, you can modify its -configuration manually, after the dip command has finished, using the -ifconfig and route commands. - - - -Please note that dip allows you to select a number of different -protocols to use with the mode command, the most common example is -cSLIP for SLIP with compression. Please note that both ends of the -link must agree, so you should ensure that whatever you select agrees -with what your server is set to. - - - -The above example is fairly robust and should cope with most errors. -Please refer to the dip man page for more information. Naturally you -could, for example, code the script to do such things as redial the -server if it doesn't get a connection within a prescribed period of -time, or even try a series of servers if you have access to more than -one. - - -7.5.7. Permanent SLIP connection using a leased line and slattach. - - -If you have a cable between two machines, or are fortunate enough to -have a leased line, or some other permanent serial connection between -your machine and another, then you don't need to go to all the trouble -of using dip to set up your serial link. slattach is a very simple to -use utility that will allow you just enough functionality to configure -your connection. - - - -Since your connection will be a permanent one, you will want to add -some commands to your rc.inet1 file. In essence all you need to do for -a permanent connection is ensure that you configure the serial device -to the correct speed and switch the serial device into SLIP mode. -slattach allows you to do this with one command. Add the following to -your rc.inet1 file: - - - - - # - # Attach a leased line static SLIP connection - # - # configure /dev/cua0 for 19.2kbps and cslip - /sbin/slattach -p cslip -s 19200 /dev/cua0 & - /sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up - # - # End static SLIP. - - - - -Where: - - - - IPA.IPA.IPA.IPA - represents your IP address. - - - - IPR.IPR.IPR.IPR - represents the IP address of the remote end. - - - -slattach allocates the first unallocated SLIP device to the serial -device specified. slattach starts with sl0. Therefore the first -slattach command attaches SLIP device sl0 to the serial device -specified and sl1 the next time, etc. - - - -slattach allows you to configure a number of different protocols with -the -p argument. In your case you will use either SLIP or cSLIP -depending on whether you want to use compression or not. Note: both -ends must agree on whether you want compression or not. - - -7.6. SLIP server. - - -If you have a machine that is perhaps network connected, that you'd -like other people be able to dial into and provide network services, -then you will need to configure your machine as a server. If you want -to use SLIP as the serial line protocol, then currently you have three -options as to how to configure your Linux machine as a SLIP server. My -preference would be to use the first presented, sliplogin, as it seems -the easiest to configure and understand, but I will present a summary -of each, so you can make your own decision. - - -7.6.1. Slip Server using sliplogin . - - -sliplogin is a program that you can use in place of the normal login -shell for SLIP users that converts the terminal line into a SLIP line. -It allows you to configure your Linux machine as either a static -address server, users get the same address everytime they call in, or -a dynamic address server, where users get an address allocated for -them which will not necessarily be the same as the last time they -called. - - - -The caller will login as per the standard login process, entering -their username and password, but instead of being presented with a -shell after their login, sliplogin is executed which searches its -configuration file (/etc/slip.hosts) for an entry with a login name -that matches that of the caller. If it locates one, it configures the -line as an 8bit clean line, and uses an ioctl call to convert the line -discipline to SLIP. When this process is complete, the last stage of -configuration takes place, where sliplogin invokes a shell script -which configures the SLIP interface with the relevant ip address, -netmask and sets appropriate routing in place. This script is usually -called /etc/slip.login, but in a similar manner to getty, if you have -certain callers that require special initialization, then you can -create configuration scripts called /etc/slip.login.loginname that -will be run instead of the default specifically for them. - - - -There are either three or four files that you need to configure to get -sliplogin working for you. I will detail how and where to get the -software and how each is configured in detail. The files are: - - -· /etc/passwd, for the dialin user accounts. -· /etc/slip.hosts, to contain the information unique to each dial-in - user. -· /etc/slip.login, which manages the configuration of the routing - that needs to be performed for the user. -· /etc/slip.tty, which is required only if you are configuring your - server for dynamic address allocation and contains a table of - addresses to allocate -· /etc/slip.logout, which contains commands to clean up after the - user has hung up or logged out. - -7.6.1.1. Where to get sliplogin - - -You may already have the sliplogin package installed as part of your -distribution, if not then sliplogin can be obtained from: -metalab.unc.edu. The tar file contains both source, precompiled -binaries and a man page. - - - -To ensure that only authorized users will be able to run sliplogin -program, you should add an entry to your /etc/group file similar to -the following: - - - - - .. - slip::13:radio,fred - .. - - - - -When you install the sliplogin package, the Makefile will change the -group ownership of the sliplogin program to slip, and this will mean -that only users who belong to that group will be able to execute it. -The example above will allow only users radio and fred to execute -sliplogin. - - - -To install the binaries into your /sbin directory and the man page -into section 8, do the following: - - - - - # cd /usr/src - # gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf - - # cd sliplogin-2.1.1 - # <..edit the Makefile if you don't use shadow passwords..> - # make install - - - - -If you want to recompile the binaries before installation, add a make -clean before the make install. If you want to install the binaries -somewhere else, you will need to edit the Makefile install rule. - - - -Please read the README files that come with the package for more -information. - - -7.6.1.2. Configuring /etc/passwd for Slip hosts. - - -Normally you would create some special logins for Slip callers in your -/etc/passwd file. A convention commonly followed is to use the -hostname of the calling host with a capital `S' prefixing it. So, for -example, if the calling host is called radio then you could create a -/etc/passwd entry that looked like: - - - - - Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin - - - - -It doesn't really matter what the account is called, so long as it is -meaningful to you. - - - -Note: the caller doesn't need any special home directory, as they will -not be presented with a shell from this machine, so /tmp is a good -choice. Also note that sliplogin is used in place of the normal login -shell. - - -7.6.1.3. Configuring /etc/slip.hosts - - -The /etc/slip.hosts file is the file that sliplogin searches for -entries matching the login name to obtain configuration details for -this caller. It is this file where you specify the ip address and -netmask that will be assigned to the caller and configured for their -use. Sample entries for two hosts, one a static configuration for host -radio and another, a dynamic configuration for user host albert might -look like: - - - - -# -Sradio 44.136.8.99 44.136.8.100 255.255.255.0 normal -1 -Salbert 44.136.8.99 DYNAMIC 255.255.255.0 compressed 60 -# - - - - -The /etc/slip.hosts file entries are: - - -1. the login name of the caller. -2. ip address of the server machine, ie this machine. -3. ip address that the caller will be assigned. If this field is coded - DYNAMIC then an ip address will be allocated based on the - information contained in your /etc/slip.tty file discussed later. - Note: you must be using at least version 1.3 of sliplogin for this - to work. -4. the netmask assigned to the calling machine in dotted decimal - notation eg 255.255.255.0 for a Class C network mask. -5. the slip mode setting which allows you to enable/disable - compression and slip other features. Allowable values here are - "normal" or "compressed". -6. a timeout parameter which specifies how long the line can remain - idle (no datagrams received) before the line is automatically - disconnected. A negative value disables this feature. -7. optional arguments. - - -Note: You can use either hostnames or IP addresses in dotted decimal -notation for fields 2 and 3. If you use hostnames then those hosts -must be resolvable, that is, your machine must be able to locate an ip -address for those hostnames, otherwise the script will fail when it is -called. You can test this by trying trying to telnet to the hostname, -if you get the `Trying nnn.nnn.nnn...' message then your machine has -been able to find an ip address for that name. If you get the message -`Unknown host', then it has not. If not, either use ip addresses in -dotted decimal notation, or fix up your name resolver configuration -(See section Name Resolution). - - - -The most common slip modes are: - - - - normal - to enable normal uncompressed SLIP. - - - - compressed - to enable van Jacobsen header compression (cSLIP) - - - -Naturally these are mutually exclusive, you can use one or the other. -For more information on the other options available, refer to the man -pages. - - -7.6.1.4. Configuring the /etc/slip.login file. - - -After sliplogin has searched the /etc/slip.hosts and found a matching -entry, it will attempt to execute the /etc/slip.login file to actually -configure the SLIP interface with its ip address and netmask. - - - -The sample /etc/slip.login file supplied with the sliplogin package -looks like this: - - - - - #!/bin/sh - - # - # @(#)slip.login 5.1 (Berkeley) 7/1/90 - # - # generic login file for a SLIP line. sliplogin invokes this with - # the parameters: - # $1 $2 $3 $4, $5, $6 ... - # SLIPunit ttyspeed pid the arguments from the slip.host entry - # - /sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up - /sbin/route add $6 - arp -s $6 pub - exit 0 - # - - - - -You will note that this script simply uses the ifconfig and route com­ -mands to configure the SLIP device with its ipaddress, remote ip -address and netmask and creates a route for the remote address via the -SLIP device. Just the same as you would if you were using the slattach -command. - - - -Note also the use of Proxy ARP to ensure that other hosts on the same -ethernet as the server machine will know how to reach the dial-in -host. The field should be the hardware address of the -ethernet card in the machine. If your server machine isn't on an -ethernet network then you can leave this line out completely. - - -7.6.1.5. Configuring the /etc/slip.logout file. - - -When the call drops out, you want to ensure that the serial device is -restored to its normal state so that future callers will be able to -login correctly. This is achieved with the use of the -/etc/slip.logout file. It is quite simple in format and is called with -the same argument as the /etc/slip.login file. - - - - - #!/bin/sh - - # - # slip.logout - # - /sbin/ifconfig $1 down - arp -d $6 - exit 0 - # - - - - -All it does is `down' the interface which will delete the manual route -previously created. It also uses the arp command to delete any proxy -arp put in place, again, you don't need the arp command in the script -if your server machine does not have an ethernet port. -7.6.1.6. Configuring the /etc/slip.tty file. - - - -If you are using dynamic ip address allocation (have any hosts -configured with the DYNAMIC keyword in the /etc/slip.hosts file, then -you must configure the /etc/slip.tty file to list what addresses are -assigned to what port. You only need this file if you wish your server -to dynamically allocate addresses to users. - - - -The file is a table that lists the tty devices that will support dial- -in SLIP connections and the ip address that should be assigned to -users who call in on that port. - - - -Its format is as follows: - - - - - # slip.tty tty -> IP address mappings for dynamic SLIP - # format: /dev/tty?? xxx.xxx.xxx.xxx - # - /dev/ttyS0 192.168.0.100 - /dev/ttyS1 192.168.0.101 - # - - - - -What this table says is that callers that dial in on port /dev/ttyS0 -who have their remote address field in the /etc/slip.hosts file set to -DYNAMIC will be assigned an address of 192.168.0.100. - - - -In this way you need only allocate one address per port for all users -who do not require an dedicated address for themselves. This helps you -keep the number of addresses you need down to a minimum to avoid -wastage. - - -7.6.2. Slip Server using dip . - - -Let me start by saying that some of the information below came from -the dip man pages, where how to run Linux as a SLIP server is briefly -documented. Please also beware that the following has been based on -the dip337o-uri.tgz package and probably will not apply to other -versions of dip. - - - -dip has an input mode of operation, where it automatically locates an -entry for the user who invoked it and configures the serial line as a -SLIP link according to information it finds in the /etc/diphosts file. -This input mode of operation is activated by invoking dip as diplogin. -This therefore is how you use dip as a SLIP server, by creating -special accounts where diplogin is used as the login shell. - - - -The first thing you will need to do is to make a symbolic link as -follows: - - - - - # ln -sf /usr/sbin/dip /usr/sbin/diplogin - - - - -You then need to add entries to both your /etc/passwd and your -/etc/diphosts files. The entries you need to make are formatted as -follows: - - - -To configure Linux as a SLIP server with dip, you need to create some -special SLIP accounts for users, where dip (in input mode) is used as -the login shell. A suggested convention is that of having all SLIP -accounts begin with a capital `S', eg `Sfredm'. - - - -A sample /etc/passwd entry for a SLIP user looks like: - - - - - Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin - ^^ ^^ ^^ ^^ ^^ ^^ ^^ - | | | | | | \__ diplogin as login shell - | | | | | \_______ Home directory - | | | | \____________ User Full Name - | | | \_________________ User Group ID - | | \_____________________ User ID - | \_______________________________ Encrypted User Password - \__________________________________________ Slip User Login Name - - - - -After the user logs in, the login program, if it finds and verifies -the user ok, will execute the diplogin command. dip, when invoked as -diplogin knows that it should automatically assume that it is being -used a login shell. When it is started as diplogin the first thing it -does is use the getuid() function call to get the userid of whoever -has invoked it. It then searches the /etc/diphosts file for the first -entry that matches either the userid or the name of the tty device -that the call has come in on and configures itself appropriately. By -judicious decision as to whether to give a user an entry in the -diphosts file, or whether to let the user be given the default -configuration you can build your server in such a way that you can -have a mix of static and dynamically assigned address users. - - - -dip will automatically add a `Proxy-ARP' entry if invoked in input -mode, so you do not need to worry about manually adding such entries. - - -7.6.2.1. Configuring /etc/diphosts - - -/etc/diphosts is used by dip to lookup preset configurations for -remote hosts. These remote hosts might be users dialing into your -linux machine, or they might be for machines that you dial into with -your linux machine. - - - -The general format for /etc/diphosts is as follows: - - - - - .. - Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006 - ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296 - .. - - - - -The fields are: - - -1. login name: as returned by getpwuid(getuid()) or tty name. -2. unused: compat. with passwd -3. Remote Address: IP address of the calling host, either numeric or - by name -4. Local Address: IP address of this machine, again numeric or by name -5. Netmask: in dotted decimal notation -6. Comment field: put whatever you want here. -7. protocol: Slip, CSlip etc. -8. MTU: decimal number - - -An example /etc/net/diphosts entry for a remote SLIP user might be: - - - - - Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296 - - - - -which specifies a SLIP link with remote address of 145.71.34.1 and MTU -of 296, or: - - - - - Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006 - - - - -which specifies a cSLIP-capable link with remote address 145.71.34.1 -and MTU of 1006. - - - -Therefore, all users who you wish to be allowed a statically allocated -dial-up IP access should have an entry in the /etc/diphosts. If you -want users who call a particular port to have their details -dynamically allocated then you must have an entry for the tty device -and do not configure a user based entry. You should remember to -configure at least one entry for each tty device that your dialup -users use to ensure that a suitable configuration is available for -them regardless of which modem they call in on. - - - -When a user logs in they will receive a normal login and password -prompt at which they should enter their SLIP-login userid and -password. If these verify ok then the user will see no special -messages and they should just change into SLIP mode at their end. The -user should then be able to connect ok and be configured with the -relevant parameters from the diphosts file. - - -7.6.3. SLIP server using the dSLIP package. - - -Matt Dillon has written a package that -does not only dial-in but also dial-out SLIP. Matt's package is a -combination of small programs and scripts that manage your connections -for you. You will need to have tcsh installed as at least one of the -scripts requires it. Matt supplies a binary copy of the expect utility -as it too is needed by one of the scripts. You will most likely need -some experience with expect to get this package working to your -liking, but don't let that put you off. - - - -Matt has written a good set of installation instructions in the README -file, so I won't bother repeating them. - - - -You can get the dSLIP package from its home site at: - - - -apollo.west.oic.com - - /pub/linux/dillon_src/dSLIP203.tgz - - - -or from: - - - -metalab.unc.edu - - /pub/Linux/system/Network/serial/dSLIP203.tgz - - - -Read the README file and create the /etc/passwd and /etc/group entries -before doing a make install. - - - diff --git a/LDP/guide/docbook/Linux-Networking/X11.xml b/LDP/guide/docbook/Linux-Networking/X11.xml index 0deb931b..f96513bc 100644 --- a/LDP/guide/docbook/Linux-Networking/X11.xml +++ b/LDP/guide/docbook/Linux-Networking/X11.xml @@ -34,999 +34,10 @@ at: Xfree . It is included in most Linux distributions. - - -This section provides an overview of the X Window System's architecture, -give a better understanding of its design, which components integrate with X -and fit together to provide a working graphical environment and what choices -are there regarding such components as window managers, toolkits and widget -libraries, and desktop environments. - - ------------------------------------------------------------------------------ -1. Preface - - -This document aims to provide an overview of the X Window System's -architecture, hoping to give people a better understanding of why it's -designed the way it's designed, which components integrate with X and fit -together to provide a working graphical environment and what choices are -there regarding those components. - - - -We explore several concepts that get mentioned a lot but might be a bit -unclear for those without a technical background, such as widgets and -toolkits, window managers and desktop environments. Some examples of how -these components interact during day-to-day use of applications are provided. - - - -This document is, deliberately, not too technically oriented. It's based on -the author's (empirical) knowledge of the subject, and while it's primarily -meant as a non-technical introduction, it can certainly benefit from any kind -of comments, further examples and explanations, and technical corrections. -The author welcomes all questions and comments regarding this document and -can be reached at roadmr@entropia.com.mx. - - ------------------------------------------------------------------------------ - -2. Introduction - - -Back when UNIX was a new thing, around 1970, graphical user interfaces were -only a weird thing being played with in a laboratory (Xerox's PARC to be -precise). Nowadays, however, any operating system in hopes of being -competitive needs to have a GUI subsystem. GUIs are supposed to be easier to -use. This is not much of a concern under UNIX, which has traditionally been, -to some extent, pretty user-hostile, preferring versatility over ease of use. -However, there are several reasons why a GUI is desirable even on a UNIX -system. For instance, given UNIX's multitasking nature, it's natural to have -a lot of programs running at any given time. A GUI gives more control over -how things are displayed on-screen, thus providing with better facilities for -having a lot of programs on-screen at the same time. Also, some kinds of -information are better displayed in graphical form (some, even, can only be -displayed in graphical form; like pr0n and other inherently graphical data). - - - -Historically, UNIX has had a lot of improvements done by academic types. A -good example is the BSD networking code added to it in the late 1970's, which -was, of course, the product of work at the University of California at -Berkeley. As it turns out, the X Window System (also called X, but never X -Windows), which is the foundation for most GUI subsystems found in modern -UNIX (unices?), Linux and the BSD's included, was also the result of an -academic project, namely the Athena project at the Massachusetts Institute of -Technology (MIT). - - - -Unix has been a multiuser, multitasking, timesharing operating system since -its beginnings. Also, since the incorporation of networking technologies, -it's had the ability to allow a user to connect remotely and perform work on -the system. Previously this was accomplished either via dumb serial -terminals, or network connections (the legendary telnet). - - - -When the time came to develop a GUI system that could run primarily under -Unix, these concepts were kept in mind and incorporated into the design. -Actually, X has a pretty complex design, which has often been mentioned as a -disadvantage. However, because of its design, it's also a really versatile -system, and this will become quite clear as we explain how all the parts -comprising a GUI under Unix fit together. - - - -Before taking a look at X's architecture, a really brief tour of its history, -and how it ended up on your Linux system, is in order. - - - -X was developed by the Athena project, and released in 1984. In 1988 an -entity called the "X Consortium" took over X, and to this day handles its -development and distribution. The X specification is freely available, this -was a smart move as it has made X almost ubiquitous. This is how XFree86 came -to be. XFree86 is the implementation of X we use on our Linux computers. -XFree86 also works on other operating systems, like the *BSD lineage, OS/2 -and maybe others. Also, despite its name, XFree86 is also available for other -CPU architectures. - - ------------------------------------------------------------------------------ - -3. The X Window System Architecture: overview - - -X was designed with a client-server architecture. The applications themselves -are the clients; they communicate with the server and issue requests, also -receiving information from the server. - - - -The X server maintains exclusive control of the display and services requests -from the clients. At this point, the advantages of using this model are -pretty clear. Applications (clients) only need to know how to communicate -with the server, and need not be concerned with the details of talking to the -actual graphics display device. At the most basic level, a client tells the -server stuff like "draw a line from here to here", or "render this string of -text, using this font, at this position on-screen". - - - -This would be no different from just using a graphics library to write our -application. However the X model goes a step further. It doesn't constrain -the client being in the same computer as the server. The protocol used to -communicate between clients and server can work over a network, or actually, -any "inter-process communication mechanism that provides a reliable octet -stream". Of course, the preferred way to do this is by using the TCP/IP -protocols. As we can see, the X model is really powerful; the classical -example of this is running a processor-intensive application on a Cray -computer, a database monitor on a Solaris server, an e-mail application on a -small BSD mail server, and a visualization program on an SGI server, and then -displaying all those on my Linux workstation's screen. - - - -So far we've seen that the X server is the one handling the actual graphics -display. Also, since it's the X server which runs on the physical, actual -computer the user is working on, it's the X server's responsibility to -perform all actual interactions with the user. This includes reading the -mouse and keyboard. All this information is relayed to the client, which of -course will have to react to it. - - - -X provides a library, aptly called Xlib, which handles all low-level -client-server communication tasks. It sounds obvious that, then, the client -has to invoke functions contained within Xlib to get work done. - - - -At this point everything seems to be working fine. We have a server in charge -of visual output and data input, client applications, and a way for them to -communicate between each other. In picturing a hypothetical interaction -between a client and a server, the client could ask the server to assign a -rectangular area on the screen. Being the client, I'm not concerned with -where i'm being displayed on the screen. I just tell the server "give me an -area X by Y pixels in size", and then call functions to perform actions like -"draw a line from here to there", "tell me whether the user is moving the -mouse in my screen area" and so on. - - ------------------------------------------------------------------------------ - -4. Window Managers - - -However, we never mentioned how the X server handles manipulation of the -clients' on-screen display areas (called windows). It's obvious, to anyone -who's ever used a GUI, that you need to have control over the "client -windows". Typically you can move and arrange them; change size, maximize or -minimize windows. How, then, does the X server handle these tasks? The answer -is: it doesn't. - - - -One of X's fundamental tenets is "we provide mechanism, but not policy". So, -while the X server provides a way (mechanism) for window manipulation, it -doesn't actually say how this manipulation behaves (policy). - - - -All that mechanism/policy weird stuff basically boils down to this: it's -another program's responsibility to manage the on-screen space. This program -decides where to place windows, gives mechanisms for users to control the -windows' appearance, position and size, and usually provides "decorations" -like window titles, frames and buttons, that give us control over the windows -themselves. This program, which manages windows, is called (guess!) a "window -manager". - - - -"The window manager in X is just another client -- it is not part of the X -window system, although it enjoys special privileges -- and so there is no -single window manager; instead, there are many, which support different ways -for the user to interact with windows and different styles of window layout, -decoration, and keyboard and colormap focus." - - - -The X architecture provides ways for a window manager to perform all those -actions on the windows; but it doesn't actually provide a window manager. - - - -There are, of course, a lot of window managers, because since the window -manager is an external component, it's (relatively) easy to write one -according to your preferences, how you want windows to look, how you want -them to behave, where do you want them to be, and so on. Some window managers -are simplistic and ugly (twm); some are flashy and include everything but the -kitchen sink (enlightenment); and everything in between; fvwm, amiwm, icewm, -windowmaker, afterstep, sawfish, kwm, and countless others. There's a window -manager for every taste. - - - -A window manager is a "meta-client", whose most basic mission is to manage -other clients. Most window managers provide a few additional facilities (and -some provide a lot of them). However one piece of functionality that seems to -be present in most window managers is a way to launch applications. Some of -them provide a command box where you can type standard commands (which can -then be used to launch client applications). Others have a nice application -launching menu of some sort. This is not standardized, however; again, as X -dictates no policy on how a client application should be launched, this -functionality is to be implemented in client programs. While, typically, a -window manager takes on this task (and each one does it differently), it's -conceivable to have client applications whose sole mission is to launch other -client applications; think a program launching pad. And of course, people -have written large amounts of "program launching" applications. - - ------------------------------------------------------------------------------ - -5. Client Applications - - -Let's focus on the client programs for a moment. Imagine you wanted to write -a client program from scratch, using only the facilities provided by X. You'd -quickly find that Xlib is pretty spartan, and that doing things like putting -buttons on screen, text, or nice controls (scrollbars, radio boxes) for the -users, is terribly complicated. - - - -Luckily, someone else went to the trouble of programming these controls and -giving them to us in a usable form; a library. These controls are usually -known as "widgets" and of course, the library is a "widget library". Then I -just have to call a function from this library with some parameters and have -a button on-screen. Examples of widgets include menus, buttons, radio -buttons, scrollbars, and canvases. - - - -A "canvas" is an interesting kind of widget, because it's basically a -sub-area within the client where i can draw stuff. Understandably, since I -shouldn't use Xlib directly, because that would interfere with the widget -library, the library itself gives a way to draw arbitrary graphics within the -canvas widget. - - - -Since the widget library is the one actually drawing the elements on-screen, -as well as interpreting user's actions into input, the library used is -largely responsible for each client's aspect and behavior. From a developer's -point of view, a widget library also has a certain API (set of functions), -and that might define which widget library i'll want to use. - - ------------------------------------------------------------------------------ - -6. Widget Libraries or toolkits - - -The original widget library, developed for the Athena Project, is of course -the Athena widget library, also known as Athena Widgets. It's very basic, -very ugly, and the usage is not intuitive by today's standards (for instance, -to move a scrollbar or slider control, you don't drag it; instead, you click -the right button to scroll up and the left button to scroll down). As such, -it's pretty much not used a lot these days. - - - -Just as it happens with window managers, there are a lot of toolkits, with -different design goals in mind. One of the earliest toolkits is the -well-known Motif, which was part of the Open Software Foundation's Motif -graphical environment, consisting of a window manager and a matching toolkit. -The OSF's history is beyond the scope of this document. the Motif toolkit, -being superior to the Athena widgets, became widely used in the 1980's and -early 1990's. - - - -These days, Motif is not a popular toolkit choice. It's not free (speech), -and OSF Motif costs money if you want a developer license (i.e. to compile -your own programs with it), altough it's OK to distribute a binary linked -against Motif. Perhaps the best-known Motif application, for Linux users at -least, is Netscape Navigator/Communicator (prior to Mozilla). - - - -For a while Motif was the only decent toolkit available, and there's a lot of -Motif software around. Of course people started developing alternatives, and -there are plenty of toolkits, such as XForms, FLTK and a few others. - - - -Motif is not heard of much these days, specially in the free software world. -The reason is that there are now better alternatives, in terms of licensing, -performance (Motif is widely regarded as quite a pig) and features. - - - -One such toolkit, the widely known and used Gtk, was specifically created to -replace Motif in the GIMP project (one possible meaning of Gtk is "GIMP -ToolKit, altough, with its widespread use, it could be interpreted as the GNU -ToolKit). Gtk is now very popular because it's relatively lightweight, -feature-rich, extensible and totally free (speech). The 0.6 release of the -GIMP included "Bloatif has been zorched" in the changelog. This sentence is a -testament to Motif's bloatedness. - - - -Another very popular toolkit these days is Qt. It was not too well-known -until the advent of the KDE project, which utilizes Qt for all its GUI -elements. We certainly won't get into Qt's licensing issues and the KDE/GNOME -disjunctive. Gtk gets a lengthy mention because its history as a Motif -replacement is interesting; Qt gets a brief mention because it's really -popular. - - - -Finally, another alternative worth mentioning is LessTif. The name is a pun -on Motif, and LessTif aims to be a free, API-compatible replacement for -Motif. It's not clear to what extent LessTif aims to be used in new -development, rather than just helping those with Motif code use a free -alternative while they (conceivably) port their apps to some other toolkit. - - ------------------------------------------------------------------------------ - -7. What we have so far - - -Up to this point we have an idea of how X has a client-server architecture, -where the clients are our application programs. Under this client-server -graphic system, we have several possible window managers, which manage our -screen real estate; we also have our client applications, which are where we -actually get our work done, and clients can be programmed using several -possible different toolkits. - - - -Here's where the mess begins. Each window manager has a different approach to -managing the clients; the behavior and decorations are different from one to -the next. Also, as defined by which toolkit each client uses, they can also -look and behave differently from each other. Since there's nothing that says -authors have to use the same toolkit for all their applications, it's -perfectly possible for a user to be running, say, six different applications, -each written using a different toolkit, and they all look and behave -differently. This creates a mess because behavior between the apps is not -consistent. If you've ever used a program written with the Athena widgets, -you'll notice it's not too similar to something written using Gtk. And you'll -also remember it's a mess using all these apps which look and feel so -different. This basically negates the advantage of using a GUI environment in -the first place. - - - -On a more technical standpoint, using lots of different toolkits increases -resource usage. Modern operating systems support the concept of dynamic -shared libraries. This means that if I have two or three applications using -Gtk, and I have a dynamic shared version of Gtk, then those two or three -applications share the same copy of Gtk, both on the disk and in memory. This -saves resources. On the other hand, if I have a Gtk application, a Qt -application, something Athena-based, a Motif-based program such as Netscape, -a program that uses FLTK and another using XForms, I'm now loading six -different libraries in memory, one for each of the different toolkits. Keep -in mind that all the toolkits provide basically the same functionality. - - - -There are other problems here. The way of launching programs varies from one -window manager to the next. Some have a nice menu for launching apps; others -don't, and they expect us to open a command-launching box, or use a certain -key combination, or even open an xterm and launch all your apps by invoking -the commands. Again, there's no standarization here so it becomes a mess. - - - -Finally, there are niceties we expect from a GUI environment which our scheme -hasn't covered. Things like a configuration utility, or "control panel"; or a -graphical file manager. Of course, these can be written as client apps. And, -in typical free software fashion, there are hundreds of file managers, and -hundreds of system configuration programs, which conceivably, further the -mess of having to deal with a lot of disparate software components. - - ------------------------------------------------------------------------------ - -8. Desktop environments to the rescue - - -Here's where the concept of a desktop environment kicks in. The idea is that -a desktop environment provides a set of facilities and guidelines aiming to -standardizing all the stuff we mentioned so that the problems we mentioned -earlier are minimized. - - - -The concept of a desktop environment is something new to people coming for -the first time to Linux because it's something that other operating systems -(like Windows and the Mac OS) intrinsically have. For example, MacOS, which -is one of the earliest graphical user interfaces, provides a very consistent -look-and-feel during the entire computing session. For instance, the -operating system provides a lot of the niceties we mentioned: it provides a -default file manager (the finder), a systemwide control panel, and single -toolkit that all applications have to use (so they all look the same). -Application windows are managed by the system (strictly speaking there's a -window manager working there). Finally, there are a set of guidelines that -tell developers how their applications should behave, recommend control looks -and placement, and suggest behaviors according to those of other applications -on the system. All this is done in the sake of consistency and ease of use. - - - -This begs the question, "why didn't the X developers do things that way in -the first place?". It makes sense; after all, it would have avoided all the -problems we mentioned earlier. The answer is that in designing X, its -creators chose to make it as flexible as possible. Going back to the policy/ -mechanism paradigm, the MacOS provides mostly policies. Mechanisms are there, -but they don't encourage people to play with those. As a result I lose -versatility; if I don't like the way MacOS manages my windows, or the toolkit -doesn't provide a function I need, I'm pretty much out of luck. This doesn't -happen under X, altough as seen before, the price of flexibility is greater -complexity. - - - -Under Linux/Unix and X, it all comes down to agreeing on stuff and sticking -to it. Let's take KDE for example. KDE includes a single window manager -(kwm), which manages and controls the behavior of our windows. It recommends -using a certain graphic toolkit (Qt), so that all KDE applications look the -same, as far as their on-screen controls go. KDE further extends Qt by -providing a set of environment-specific libraries (kdelibs) for performing -common tasks like creating menus, "about" boxes, program toolbars, -communicating between programs, printing, selecting files, and other things. -These make the programmer's work easier and standardize the way these special -features behave. KDE also provides a set of design and behavior guidelines to -programmers, with the idea that, if everybody follows them, programs running -under KDE will both look and behave very similarly. Finally, KDE provides, as -part of the environment, a launcher panel (kpanel), a standard file manager -(which is, at the time being, Konqueror), and a configuration utility -(control panel) from which we can control many aspects of our computing -environment, from settings like the desktop's background and the windows' -titlebar color to hardware configurations. - - - -The KDE panel is an equivalent to the MS Windows taskbar. It provides a -central point from which to launch applications, and it also provides for -small applications, called "applets", to be displayed within it. This gives -functionality like the small, live clock most users can't live without. - - ------------------------------------------------------------------------------ - -9. Specific Desktop Environments - - -We used KDE as an example, but it's by no means the earliest desktop -environment for Unix systems. Perhaps one of the earliest is CDE (Common -Desktop Environment), another sibling of the OSF. As per the CDE FAQ: "The -Common Desktop Environment is a standard desktop for UNIX, providing services -to end-users, systems administrators, and application developers consistently -across many platforms." The key here is consistency. However CDE wasn't as -feature-rich and easy as it needed to be. Along with Motif, CDE has -practically disappeared from the free software world, having been replaced by -better alternatives. - - - -Under Linux, the two most popular desktop environments are KDE and GNOME, but -they're not the only ones. A quick internet search will reveal about half a -dozen desktop environments: GNUStep, ROX, GTK+XFce, UDE, to name a few. They -all provide the basic facilities we mentioned earlier. GNOME and KDE have had -the most support, both from the community and the industry, so they're the -most advanced ones, providing a large amount of services to users and -applications. - - - -We mentioned KDE and the components that provide specific services under that -environment. As a good desktop environment, GNOME is somewhat similar in -that. The most obvious difference is that GNOME doesn't mandate a particular -window manager (the way KDE has kwm). The GNOME project has always tried to -be window manager-agnostic, acknowledging that most users get really attached -to their window managers, and forcing them to use something that manages -windows differently would detract from their audience. Originally GNOME -favored the Enlightenment window manager, and currently their preferred -window manager is Sawfish, but the GNOME control panel has always had a -window manager selector box. - - - -Other than this, GNOME uses the Gtk toolkit, and provides a set of -higher-level functions and facilities through the gnome-libs set of -libraries. GNOME has its own set of programming guidelines in order to -guarantee a consistent behavior between compliant applications; it provides a -panel (called just "panel"), a file manager (gmc, altough it's probably going -to be superseded by Nautilus), and a control panel (the gnome control -center). - - ------------------------------------------------------------------------------ - -10. How it all fits together - - -Each user is free to choose whichever desktop environment feels the best. The -end result is that, if you use an all-kde or all-gnome system, the look and -feel of the environment is very consistent; and your applications all -interact between them pretty nicely. This just wasn't possible when we had -apps written in a hodgepodge of different toolkits. The range of facilities -provided by modern desktop environments under Linux also enable some other -niceties, like component architectures (KDE has Kparts and GNOME uses the -Bonobo component framework), which allow you to do things like having a live -spreadsheet or chart inside a word processing document; global printing -facilities, similar to the printing contexts found in Windows; or scripting -languages, which let more advanced users write programs to glue applications -together and have them interact and cooperate in interesting ways. - - - -Under the Unix concept of "desktop environment", you can have programs from -one environment running in another. I could conceivably use Konqueror within -GNOME, or Gnumeric under KDE. They're just programs, after all. Of course the -whole idea of a desktop environment is consistency, so it makes sense to -stick to apps that were designed for your particular environment; but if -you're willing to cope with an app that looks "out of place" and doesn't -interact with the rest of your environment, you are completely free to do so. - - ------------------------------------------------------------------------------ - -11. A day in the life of an X system - - -This is an example of how a typical GNOME session goes, under a modern -desktop environment in a Linux system. It's very similar to how things work -under other environments, assuming they work on top of X. - - - -When a Linux system starts X, the X server comes up and initializes the -graphic device, waiting for requests from clients. First a program called -gnome-session starts, and sets up the working session. A session includes -things such as applications I always open, their on-screen positions, and -such. Next, the panel gets started. The panel appears at the bottom (usually) -and it's sort of a dashboard for the windowing environment. It will let us -launch programs, see which ones are running, and otherwise control the -working environment. Next, the window manager comes up. Since we're using -GNOME, it could be any of several different window managers, but in this case -we'll assume we're running Sawfish. Finally, the file manager comes up (gmc -or Nautilus). The file manager handles presentation of the desktop icons (the -ones that appear directly on the desktop). At this point my GNOME environment -is ready to work. - - - -So far all of the programs that have been started are clients, connecting to -the X server. In this case the X server happens to be in the same computer, -but as we saw before, it need not be. - - - -We'll now open an xterm to type some commands. When we click on the xterm -icon, the panel spawns, or launches, the xterm application. It's another X -client application, so it starts, connects to the X server and begins -displaying its stuff. When the X server assigns screen space for my xterm, it -lets the window manager (Sawfish) decorate the window with a nice titlebar, -and decide where it will be on screen. - - - -Let's do some browsing. We click on the Netscape icon on the panel, and up -comes a browser. Keep in mind that this browser doesn't use GNOME's -facilities, nor does it use the Gtk toolkit. It looks a bit out of place -here... also, it doesn't interact very nicely with the rest of the -environment. I'll open the "File" menu. Motif is providing the on-screen -controls, so it's the Motif library's job to make the appropriate calls to -the underlying Xlib, draw the necessary on-screen elements to display the -menu and let me select the "exit" option, closing the application. - - - -Now I open a Gnumeric spreadsheet and start doing some stuff. At some point I -need to do some work on the xterm I had open, so I click on it. Sawfish sees -that, and, being in charge of managing windows, brings the xterm to the top -and gives it focus so I can work there. - - - -After that, I go back to my spreadsheet, now that I'm finished I want to -print my document. Gnumeric is a GNOME application, so it can use the -facilities provided by the GNOME environment. When I print, Gnumeric calls -the gnome-print library, which actually communicates with the printer and -produces the hard copy I need. - - - - - -LBX (Low Bandwidth X) is an X server extension which performs compres­ -sion on the X protocol. It is meant to be used in conjunction with X -applications and an X server which are separated by a slow network -connection, to improve display and response time. - -______________________________________________________________________ - -1. Introduction - - -Low-Bandwidth X (LBX) attempts to recognize that in this day and age, -not everyone will be a fast LAN hop or two away from the system that -they are running their applications on. - - - -The X protocol can generate an extraordinary amount of traffic, -especially for simple-seeming things such as creating new windows. As -anyone who has tried to use X over a dial-in modem at 28.8 or even -higher can attest, creating new X windows can involve an excruciating -wait. - - - -LBX is fundamentally a compression and caching scheme designed to -minimize the amount of X traffic generated between two systems. - - -2. What's The Status Of LBX? - - -As of the X Consortium's release of X11R6.3 in December, 1996, LBX is -a full extension to the X protocol. For XFree86 folks, that's XFree86 -version 3.3. - - -3. Who Can Benefit From LBX? - - -If you use a modem to dial into a service provider, then run X -applications on remote machines with their DISPLAYs set to your local -machine (or vice versa), LBX will speed up that connection. Also if -you set DISPLAYs from systems across WANs (other countries, for -example) or other slow links, LBX can help. - - -4. Who Doesn't Need LBX? - - -LBX is useless, of course, if you're only running applications -locally, or if you're not running X at all. - - - -Also, if you're running on a fast LAN, LBX won't be much help. Some -people say "if LBX cuts down on network traffic, wouldn't it be good -to use even on fast LANs?" It might be, if your goal is to reduce -network traffic. But if your goal is to get better response time LBX -probably isn't what you want. Although it does introduce caching and -compression, that comes at a cost on both ends (extra memory for -caching, and extra CPU for decompression). If your link is fairly -speedy LBX will probably result in an overall slowdown. - - -5. How Does LBX Work? - - -LBX works by introducing a proxy server at the client side, which -performs caching and compression. The X server knows that the client -is using a proxy server, and decompresses accordingly. - - - -Here's a normal setup for remote X clients. In our discussion, LOCAL -is always the workstation sitting in front of you, whose monitor -you're looking at, and REMOTE is the remote workstation, where the -actual application is running. - - - - - ______________________________________________________________________ - REMOTE LOCAL - +-----+ +-----+ - | APP |-\ Network +----------+ | |\ - +-----+ \--------------------------->| X SERVER |=>| || - +-----+ / (X Protocol) +----------+ +-----+\ - | APP |-/ /_____// - +-----+ - ______________________________________________________________________ - - - - -When using LBX, a proxy server (lbxproxy) is introduced on the remote -side, and the applications talk to that process instead of directly to -the LOCAL server. That process then performs the caching and -compression of X requests and forwards them. It looks like this: - - - - -______________________________________________________________________ - REMOTE LOCAL - +-----+ - +-----+ +-------+ Network +----------+ | |\ - | APP |->| PROXY |----------------------------->| X SERVER |=>| || - +-----+ +-------+ (LBX/X Protocol) +----------+ +-----+\ - +-----+ / /_____// - | APP |--/ - +-----+ -______________________________________________________________________ - - - - -Details on exactly what caching and compression LBX does is beyond the -scope of this document. - - -6. What Do I Need To Use LBX? - - -You need an X server on your LOCAL system which has the LBX extension -compiled in. Unless you explicitly told it not to when building it, -X11R6.3 servers automatically enable LBX. Also, all XFree86 3.3 -servers have LBX enabled by default. - - - -You can use the xdpyinfo command to see if your server has the LBX -extension: run xdpyinfo and look at the list just under "number of -extensions"; you should see "LBX" listed there. - - - -Next, you need to get an lbxproxy program compiled for the REMOTE -system. This is the tricky part. If the remote system is not the -same type as your local system, the lbxproxy on your local system will -do you no good, of course. - - - -There is unfortunately no "broken out" distribution of lbxproxy, so -you will have to either (a) get and build most, if not all, of X11R6.3 -for the remote system, or (b) find someplace to get a pre-compiled -lbxproxy binary for your system. The latter is much simpler of -course. - - - -The lbxproxy is simply a single executable. There are no -configuration files, resource files, etc. associated with it. - - -7. What Don't I Need To Use LBX? - - -The REMOTE system does not need a new X server (as always, the REMOTE -system doesn't need any X server running). - - - -The application you want to run does not need to be linked with any -special version of X, or any special libraries; I regularly use -commercial X11R5 apps over LBX with no trouble. - - - -You do not need root or other privileged access on the REMOTE system; -the lbxproxy process runs under your normal access permissions. -Further, you can run it right from your home directory: it does not -have to be installed anywhere. - - -8. How Do I Start LBX? - - -OK, here it is... after all that it's actually quite simple. Replace -LOCAL and REMOTE below with the hostnames of your local workstation -and remote system, respectively (don't get them mixed up!) - - - -On LOCAL: - - -1. Start your X server. -2. Tell your X server that the remote system is allowed access. Using - the host-list method, type xhost +REMOTE. If you use xauth you may - need to do more than this; see the xauth(1) man page for more - information. - You should consult the Remote X Apps Mini-HOWTO - if you're not familiar - with remote X access permission setup. - - -On REMOTE: - - -1. Start lbxproxy and tell it to forward to the LOCAL X server, like - this: - - - $ lbxproxy -display LOCAL:0 :1 & - - - - -This tells lbxproxy to use display :1 on the REMOTE system; if that -system has >1 display already you can use :2 or whatever instead. - - -2. Set your DISPLAY environment variable to point to the display that - lbxproxy is providing, instead of the normal display: - - - - $ DISPLAY=:1 - $ export DISPLAY - - - - -Or, if you use csh or clones: - - - - - % setenv DISPLAY :1 - - - -3. If you're using xauth you will need to ensure that your cookie is - available locally. See the Remote X Apps Mini-HOWTO - for more information on - this. - -4. Start your X applications! - - -That's it; all X apps that are started up pointing to :1 will use LBX. -Of course, there's no reason you couldn't also start X apps pointing -to LOCAL:0 and have both running at the same time. - - -9. Problems - - -Here are some common problems: - - - Q) lbxproxy exits with an "access denied" error. - - A) This means the LOCAL system isn't accepting connections from the - REMOTE system due to permissions errors. See the Remote X Apps - Mini-HOWTO for details - on these issues. - - As a simple trouble-shooting measure, try running a simple X app - like xclock on REMOTE and have it display on the local system - without using lbxproxy: - - $ xclock -display LOCAL:0 - - If that doesn't work, it's xhost or some other basic X problem, not - LBX. - - -10. Documentation - -The only documentation available in a standard X distribution may be -the lbxproxy(1) man page. - -If you have access to the X source tree, then very interesting -information on LBX is available there: - - -· xc/doc/specs/Xext/lbx.mif (Framemaker MIF) -· xc/doc/hardcopy/Xext/lbx.PS.Z (Compressed Postscript) -· xc/doc/hardcopy/Xext/lbxTOC.html (HTML) - -More detailed discussion of specific LBX algorithms is available here: - -· xc/doc/specs/Xext/lbxalg.mif (Framemaker MIF) -· xc/doc/specs/Xext/lbxalg.PS.Z (Compressed Postscript) - -If you don't have access to the X11 source, you can obtain these files -from the X Consortium's FTP site . - -11. Alternatives - -If you don't like lbxproxy for some reason: you're not satisfied with -the performance, it doesn't work for you, you don't want to hassle -with creating an lbxproxy for the remote host, or you simply are -interested in trying other options, there is at least one other -package for X protocol compression (anyone have others?) - -11.1. dxpc - The Differential X Protocol Compressor - -· Original Author: Brian Pane -· Current Maintainer: Zachary Vonler - - -dxpc works in essentially -the same way as LBX. However, to avoid having to implement an X -extension and modify the X server code, dxpc uses two proxies: one -that runs on the REMOTE host, like lbxproxy, and one that runs on the -LOCAL host. - - - -The REMOTE host proxy communicates between the X clients and the LOCAL -host proxy, and the LOCAL host proxy communicates between the X server -and the REMOTE host proxy. - - - -So, to both the X clients and the X server, it looks like X protocol -as usual. - - -11.1.1. Advantages - -· Since it's a completely separate application that does not require - any X internals, it's much simpler to compile and install. -· It's maintained separately, so you don't have to wait for the OSF - to release new X versions for enhancements or fixes. -· It provides more and better compression information and statistics - than lbxproxy. - -11.1.2. Disadvantages - -· It is not a standard part of X; you must obtain and build it - separately. -· It is slightly more complex to set up, since it requires a LOCAL- - side proxy as well as the REMOTE proxy. - -11.1.3. Where Can I Get dxpc? - - -The source for dxpc is available at ftp.x.org -. - - - -There is a WWW homepage for dxpc that gives a lot of good information, -including pointers to the dxpc mailing list, access to the source -code, and a number of pre-built binaries for various platforms: - - - -11.2. SSH (Secure Shell) - - -Ken Chase notes that ssh - can be used for compression. Although its -main purpose is to provide security, it also compresses the data it -sends. - - - -Thus, if you run X over a ssh link you will automatically obtain some -amount of compression. - - -11.3. Which Is Better? - - -I don't know. Both LBX and dxpc are certainly better at raw -compression than ssh. Of course, ssh provides the added advantage of -security. And of course, there's no reason you can't use both ssh and -one of the other two, to get good compression and security. - - -It shouldn't be hard to run some benchmarking against these options -and get both subjective and statistical measurings of performance. -But I haven't done this, and I don't know of anyone who has. +For further information regarding X please see: - - + X11, LBX, DXPC, NXServer, SSH, MAS Related HOWTOs: