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: