From a8d1c1809b2d8e6ce95f65bf341be37b854ecdd0 Mon Sep 17 00:00:00 2001 From: binh <> Date: Fri, 19 Nov 2004 13:31:14 +0000 Subject: [PATCH] Editing of new "Linux-Networking" guide. This copy is not to be distributed. Its just a draft to give people an idea as to the format of the new document and a backup just in case my laptop dies. Binh. --- .../docbook/Linux-Networking/Foreward.xml | 2 +- .../docbook/Linux-Networking/Glossary.xml | 1 + .../docbook/Linux-Networking/Leased-Line.xml | 935 +++++---- LDP/guide/docbook/Linux-Networking/PLIP.xml | 320 +-- .../docbook/Linux-Networking/PPP-SLIP.xml | 1736 +++++++++-------- .../docbook/Linux-Networking/Sources.xml | 33 + LDP/guide/docbook/Linux-Networking/VNC.xml | 358 ---- LDP/guide/docbook/Linux-Networking/X11.xml | 1543 ++++++++++----- 8 files changed, 2649 insertions(+), 2279 deletions(-) diff --git a/LDP/guide/docbook/Linux-Networking/Foreward.xml b/LDP/guide/docbook/Linux-Networking/Foreward.xml index 1086f59c..5faddc00 100644 --- a/LDP/guide/docbook/Linux-Networking/Foreward.xml +++ b/LDP/guide/docbook/Linux-Networking/Foreward.xml @@ -375,6 +375,6 @@ connection issue. The administrator can proceed in one of either two ways. He can move upwards through the hierarchy or downwards, either way he is eliminating possible issues at each point which therefore reduces the possible number of problems at each point. The purpose of each layer will -be explained below. +be explained in the sections on the TCP/IP and OSI networking models. diff --git a/LDP/guide/docbook/Linux-Networking/Glossary.xml b/LDP/guide/docbook/Linux-Networking/Glossary.xml index 00544af5..93fd126a 100644 --- a/LDP/guide/docbook/Linux-Networking/Glossary.xml +++ b/LDP/guide/docbook/Linux-Networking/Glossary.xml @@ -1,4 +1,5 @@ + Glossary ARPA diff --git a/LDP/guide/docbook/Linux-Networking/Leased-Line.xml b/LDP/guide/docbook/Linux-Networking/Leased-Line.xml index 76ef6314..10eae53f 100644 --- a/LDP/guide/docbook/Linux-Networking/Leased-Line.xml +++ b/LDP/guide/docbook/Linux-Networking/Leased-Line.xml @@ -2,491 +2,486 @@ Leased-Line +_______________________________________________________________________________ + + +Configuring your modem and pppd to use a 2 wire twisted pair leased +line. + + +1.2. What is a leased line + + +Any fixed, that is permanent, point to point data communications link, +which is leased from a telco or similar organisation. The leased line +involves cables, such as twisted pair, coax or fiber optic, and may +involve all sorts of other hardware such as (pupin) coils, +transformers, amplifiers and regenerators. + + + + This document deals with: + Configuring your modem and pppd to use a 2 wire twisted pair + leased line. + + + + This document does NOT deal with: + SLIP, getting or installing pppd, synchronous data + communication, baseband modems, xDSL. + + +1.3. Assumptions + + +You should already have a working pppd on your system. You also need +Minicom or a similar program to configure your modems. + + +2. Modem + + +A leased line is not connected to a telephone exchange and does not +provide DC power, dial tone, busy tone or ring signal. This means that +your modems are on their own and have to be able to deal with this +situation. + + + +You should have 2 identical (including firmware version) external +modems supporting both leased line and dumb mode. Make sure your +modems can actually do this! Also make sure your modem is properly +documented. You also need: + + +· 2 fully wired shielded RS232 cables. The shield should be connected + to the connector shell (not pin 1) at both ends (not at one end). +· A RS232 test plug may be handy for test purposes. +· 2 RJ11 cords, one for each end of the leased line. +· A basic understanding of `AT' commands. + +2.1. Modem Configuration + + +A note on modem configuration and init strings in general: Configure +your modem software such as minicom or (m)getty to use the highest +possible speed; 57600 bps for 14k4 and 115200 bps for 28k8 or faster +modems. Lots of people use very long and complicated init strings, +often starting with AT&F and containing lots of modem brand and -type +specific commands. This however is needlessly complicated. Most +programs feel happy with the same modem settings, so why not write +these settings in the non volatile memory of all your modems, and only +use `ATZ' as an init string in all your programs. This way you can +swap or upgrade your modems without ever having to reconfigure any of +your software. + + + +Most programs require you to use the following settings; + + +· Fixed baud rate (no auto baud) +· Hardware bidirectional RTS-CTS flow control (no x-on/x-off) +· 8 Bits, no parity, 1 stopbit +· The modem should produce the TRUE DCD status (&C1) +· The modem should NOT ignore the DTR status (&D2 or &D3) + + +Check this with AT&V or AT&Ix (consult your modem documentation) + + + +These settings are not necessarily the same as the default factory +profile (&F), so starting an init string with AT&F is probably not a +good idea in the first place. The smart thing to do is probably to use +AT&F only when you have reason to believe that the modem setup stored +in the non volatile memory is really screwed up. If you think you +have found the right setup for your modems, write it to non volatile +memory with AT&W and test it thoroughly with Z-modem file transfers of +both ASCII text and binary files. Only if all of this works perfectly +should you configure your modems for leased line. + + + +Find out how to put your modem into dumb mode and, more importantly, +how to get it out of dumb mode; The modem can only be reconfigured +when it is not in dumb mode. Make sure you actually configure your +modems at the highest possible speed. Once in dumb mode it will +ignore all `AT' commands and consequently will not adjust its speed to +that of the COM port, but will use the speed at which it was +configured instead (this speed is stored in a S-register by the AT&W +command). + + + +Now configure your modem as follows; + + +· Reset on DTR toggle (&D3, this is sometimes a S register). This + setting is required by some ISP's! +· Leased line mode (&L1 or &L2, consult your modem documentation) +· The remote modem auto answer (S0=1), the local originate (S0=0) +· Disable result codes (Q1, sometimes the dumb mode does this for + you) +· Dumb mode (\D1 or %D1, this is sometimes a jumper) In dumb mode the + modem will ignore all AT commands (sometimes you need to disable + the ESC char as well). + + +Write the configuration to non-volatile memory (&W). + + +2.2. Test + + +Now connect the modems to 2 computers using the RS232 cables and +connect the modems to each other using a RJ11 lead. Use a modem +program such as Minicom (Linux), procom or telix (DOS) on both +computers to test the modems. You should be able to type text from +one computer to the other and vice versa. If the screen produces +garbage check your COM port speed and other settings. Now disconnect +and reconnect the RJ11 cord. Wait for the connection to reestablish +itself. Disconnect and reconnect the RS232 cables, switch the modems +on and off, stop and restart Minicom. The modems should always +reconnect at the highest possible speed (some modems have speed +indicator leds). Check whether the modems actually ignores the ESC +(+++) character. If necessary disable the ESC character. + + + +If all of this works you may want to reconfigure your modems; Switch +off the sound at the remote modem (M0) and put the local modem at low +volume (L1). + + +2.3. Examples + +2.3.1. Hi-Tech + + +This is a rather vague `no name clone modem'. Its config string is +however typical and should work on most modems. + + + + Originate (local): + ATL1&C1&D3&L2%D1&W&W1 + + + + Answer (remote): + ATM0L1&C1&D3&L2%D1S0=1&W&W1 + + +2.3.2. Tornado FM 228 E + + +This is what should work; + + + + Originate (local): + ATB15L1Q1&C1&D3&L2&W&W1 + + + + Answer (remote): + ATM0B15M0Q1&C1&D3&L2S0=1&W&W1 + + + +Move the dumb jumper from position 2-3 to 1-2. + + + +Due to a firmware bug, the modems will only connect after being hard +reset (power off and on) while DTR is high. I designed a circuit which +hard resets the modem on the low to high transition of DTR. The +FreeBSD pppd however, isn't very happy about this. By combining the +setting &D0 with a circuit which resets on the high to low transition +instead, this problem can be avoided. + + +2.3.3. Tron DF + + +The ESC char should be disabled by setting S2 > 127; + + + + Originate: + ATL1&L1Q1&C1&D3S2=171\D1&W + + + + Answer: + ATM0&L2Q1&C1&D3S0=1S2=171\D1&W + + +2.3.4. US Robotics Courier V-Everything + + +The USR Sportster and USR Courier-I do not support leased line. You +need the Courier V-everything version for this job. There is a +webpage on the USR site `explaining' how to set-up your Courier for +leased line. However, if you follow these instructions you will end up +with a completely brain dead modem, which can not be controlled or +monitored by your pppd. + + + +The USR Courier can be configured with dip switches, however you need +to feed it the config string first. First make sure it uses the right +factory profile. Unlike most other modems it has three; &F0, &F1 and +&F2. The default, which is also the one you should use, is &F1. If you +send it an AT&F, however it will load the factory profile &F0! For +the reset on DTR toggle you set bit 0 of S register 13. This means you +have to set S13 to 1. Furthermore you need set it to leased line mode +with &L1; ATS13=1&L1&W The dip switches are all default except for the +following: - Leased line Mini HOWTO - - Configuring your modem and pppd to use a 2 wire twisted pair leased - line. - ______________________________________________________________________ - - Table of Contents - - - 1. Introduction - - 1.1 Copyright and License - 1.2 What is a leased line - 1.3 Assumptions - - 2. Modem - - 2.1 Modem Configuration - 2.2 Test - 2.3 Examples - 2.3.1 Hi-Tech - 2.3.2 Tornado FM 228 E - 2.3.3 Tron DF - 2.3.4 US Robotics Courier V-Everything - - 3. PPPD - - 3.1 Configuration - 3.2 Scripts - 3.2.1 Starting the pppd and keeping it alive - 3.2.2 Setting the routes - 3.3 Test - - - ______________________________________________________________________ - - The most recent (beta) version of this HOWTO can be found at: - http://www.sput.nl/software/leased-line/ - - - 1. Introduction - - 1.1. Copyright and License - - This document is distributed under the terms of the GNU Free - Documentation License. You should have received a copy along with it. - If not, it is available from http://www.fsf.org/licenses/fdl.html. - - 1.2. What is a leased line - - Any fixed, that is permanent, point to point data communications link, - which is leased from a telco or similar organisation. The leased line - involves cables, such as twisted pair, coax or fiber optic, and may - involve all sorts of other hardware such as (pupin) coils, - transformers, amplifiers and regenerators. - - - - This document deals with: - Configuring your modem and pppd to use a 2 wire twisted pair - leased line. - - - - This document does NOT deal with: - SLIP, getting or installing pppd, synchronous data - communication, baseband modems, xDSL. - - - 1.3. Assumptions - - You should already have a working pppd on your system. You also need - Minicom or a similar program to configure your modems. - - 2. Modem - - A leased line is not connected to a telephone exchange and does not - provide DC power, dial tone, busy tone or ring signal. This means that - your modems are on their own and have to be able to deal with this - situation. - - - You should have 2 identical (including firmware version) external - modems supporting both leased line and dumb mode. Make sure your - modems can actually do this! Also make sure your modem is properly - documented. You also need: - - - · 2 fully wired shielded RS232 cables. The shield should be connected - to the connector shell (not pin 1) at both ends (not at one end). - - · A RS232 test plug may be handy for test purposes. - - · 2 RJ11 cords, one for each end of the leased line. - - · A basic understanding of `AT' commands. - - - 2.1. Modem Configuration - - A note on modem configuration and init strings in general: Configure - your modem software such as minicom or (m)getty to use the highest - possible speed; 57600 bps for 14k4 and 115200 bps for 28k8 or faster - modems. Lots of people use very long and complicated init strings, - often starting with AT&F and containing lots of modem brand and -type - specific commands. This however is needlessly complicated. Most - programs feel happy with the same modem settings, so why not write - these settings in the non volatile memory of all your modems, and only - use `ATZ' as an init string in all your programs. This way you can - swap or upgrade your modems without ever having to reconfigure any of - your software. - - - Most programs require you to use the following settings; - - - · Fixed baud rate (no auto baud) - - · Hardware bidirectional RTS-CTS flow control (no x-on/x-off) - - · 8 Bits, no parity, 1 stopbit - - · The modem should produce the TRUE DCD status (&C1) - - · The modem should NOT ignore the DTR status (&D2 or &D3) - - - Check this with AT&V or AT&Ix (consult your modem documentation) - - - These settings are not necessarily the same as the default factory - profile (&F), so starting an init string with AT&F is probably not a - good idea in the first place. The smart thing to do is probably to use - AT&F only when you have reason to believe that the modem setup stored - in the non volatile memory is really screwed up. If you think you - have found the right setup for your modems, write it to non volatile - memory with AT&W and test it thoroughly with Z-modem file transfers of - both ASCII text and binary files. Only if all of this works perfectly - should you configure your modems for leased line. - - - Find out how to put your modem into dumb mode and, more importantly, - how to get it out of dumb mode; The modem can only be reconfigured - when it is not in dumb mode. Make sure you actually configure your - modems at the highest possible speed. Once in dumb mode it will - ignore all `AT' commands and consequently will not adjust its speed to - that of the COM port, but will use the speed at which it was - configured instead (this speed is stored in a S-register by the AT&W - command). - - - Now configure your modem as follows; - - - · Reset on DTR toggle (&D3, this is sometimes a S register). This - setting is required by some ISP's! - - · Leased line mode (&L1 or &L2, consult your modem documentation) - - · The remote modem auto answer (S0=1), the local originate (S0=0) - - · Disable result codes (Q1, sometimes the dumb mode does this for - you) - - · Dumb mode (\D1 or %D1, this is sometimes a jumper) In dumb mode the - modem will ignore all AT commands (sometimes you need to disable - the ESC char as well). - - - Write the configuration to non-volatile memory (&W). - - 2.2. Test - - Now connect the modems to 2 computers using the RS232 cables and - connect the modems to each other using a RJ11 lead. Use a modem - program such as Minicom (Linux), procom or telix (DOS) on both - computers to test the modems. You should be able to type text from - one computer to the other and vice versa. If the screen produces - garbage check your COM port speed and other settings. Now disconnect - and reconnect the RJ11 cord. Wait for the connection to reestablish - itself. Disconnect and reconnect the RS232 cables, switch the modems - on and off, stop and restart Minicom. The modems should always - reconnect at the highest possible speed (some modems have speed - indicator leds). Check whether the modems actually ignores the ESC - (+++) character. If necessary disable the ESC character. - - - If all of this works you may want to reconfigure your modems; Switch - off the sound at the remote modem (M0) and put the local modem at low - volume (L1). - - 2.3. Examples - - - - 2.3.1. Hi-Tech - - This is a rather vague `no name clone modem'. Its config string is - however typical and should work on most modems. - - - - Originate (local): - ATL1&C1&D3&L2%D1&W&W1 - - - Answer (remote): - ATM0L1&C1&D3&L2%D1S0=1&W&W1 - - - 2.3.2. Tornado FM 228 E - - This is what should work; - - - - Originate (local): - ATB15L1Q1&C1&D3&L2&W&W1 - - - Answer (remote): - ATM0B15M0Q1&C1&D3&L2S0=1&W&W1 - - - Move the dumb jumper from position 2-3 to 1-2. - - - Due to a firmware bug, the modems will only connect after being hard - reset (power off and on) while DTR is high. I designed a circuit which - hard resets the modem on the low to high transition of DTR. The - FreeBSD pppd however, isn't very happy about this. By combining the - setting &D0 with a circuit which resets on the high to low transition - instead, this problem can be avoided. - - 2.3.3. Tron DF - - The ESC char should be disabled by setting S2 > 127; - - - - Originate: - ATL1&L1Q1&C1&D3S2=171\D1&W - - - Answer: - ATM0&L2Q1&C1&D3S0=1S2=171\D1&W - - - 2.3.4. US Robotics Courier V-Everything - - The USR Sportster and USR Courier-I do not support leased line. You - need the Courier V-everything version for this job. There is a - webpage on the USR site `explaining' how to set-up your Courier for - leased line. However, if you follow these instructions you will end up - with a completely brain dead modem, which can not be controlled or - monitored by your pppd. - - - The USR Courier can be configured with dip switches, however you need - to feed it the config string first. First make sure it uses the right - factory profile. Unlike most other modems it has three; &F0, &F1 and - &F2. The default, which is also the one you should use, is &F1. If you - send it an AT&F, however it will load the factory profile &F0! For - the reset on DTR toggle you set bit 0 of S register 13. This means you - have to set S13 to 1. Furthermore you need set it to leased line mode - with &L1; ATS13=1&L1&W The dip switches are all default except for the - following: - - - - 3 OFF Disable result codes - - - 4 ON Disable offline commands - - - 5 ON For originate, OFF For answer - - - 8 OFF Dumb mode - - - 3. PPPD - - You need a pppd (Point to Point Protocol Daemon) and a reasonable - knowledge of how it works. Consult the relevant RFC's or the Linux PPP - HOWTO if necessary. Since you are not going to use a login procedure, - you don't use (m)getty and you do not need a (fake) user associated - with the pppd controlling your link. You are not going to dial so you - don't need any chat scripts either. In fact, the modem circuit and - configuration you have just build, are rather like a fully wired null - modem cable. This means you have to configure your pppd the same way - as you would with a null modem cable. - - - For a reliable link, your setup should meet the following criteria; - - - · Shortly after booting your system, pppd should raise the DTR signal - in your RS232 port, wait for DCD to go up, and negotiate the link. - - · If the remote system is down, pppd should wait until it is up - again. - - · If the link is up and then goes down, pppd should reset the modem - (it does this by dropping and then raising DTR), and then try to - reconnect. - - · If the quality of the link deteriorates too much, pppd should reset - the modem and then reestablish the link. - - · If the process controlling the link, that is the pppd, dies, a - watchdog should restart the pppd. - - - 3.1. Configuration - - Suppose the modem is connected to COM2, the local IP address is - `Loc_Ip' and the remote IP address is `Rem_Ip'. We want to use 576 as - our MTU. The /etc/ppp/options.ttyS1 would now be: - - - - crtscts - mru 576 - mtu 576 - passive - Loc_Ip:Rem_Ip - -chap - modem - #noauth - -pap - persist - - - - Stuff like `asyncmap 0', `lock', `modem' and `-detach' are probably - already in /etc/ppp/options. If not, add them to your - /etc/ppp/options.ttyS1. So, if the local system is 192.168.1.1 and - the remote system is 10.1.1.1, then /etc/ppp/options.ttyS1 on the - local system would be: - - - - crtscts - mru 576 - mtu 576 - passive - 192.168.1.1:10.1.1.1 - -chap - modem - #noauth - -pap - persist - - - - The options.ttyS1 on the remote system would be: - - - - crtscts - mru 576 - mtu 576 - passive - 10.1.1.1:192.168.1.1 - -chap - modem - #noauth - -pap - persist - - - - The passive option limits the number of (re)connection attempts. The - persist option will keep pppd alive in case of a disconnect or when it - can't connect in the first place. If you telnet a lot while doing - filetransfers (FTP or webbrowsing) at the same time, you might want to - use a smaller MTU and MRU such as 296. This will make the remote sys­ - tem more responsive. If you don't care much about telnetting during - FTP, you could set the MTU and MRU to 1500. Keep in mind though, that - UDP cannot be fragmented. Speakfreely for instance uses 512 byte UDP - packets. So the minimum MTU for speakfreely is 552 bytes. The noauth - option may be necessary with some newer distributions. - - 3.2. Scripts - - 3.2.1. Starting the pppd and keeping it alive - - You could start the pppd form a boot (rc) script. However, if you do - this, and the pppd dies, you are without a link. A more stable - solution, is to start the pppd from /etc/inittab; - - - - s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200 - - - - This way, the pppd will be restarted if it dies. Make sure you have a - `-detach' option (nodetach on newer systems) though, otherwise inittab - will start numerous instances of pppd, will complaining about - `respawning too fast'. - - Note: Some older systems will not accept the speed `115200'. In this - case you will have to set the speed to 38400 en set the `spd_vhi' flag - with setserial. Some systems expect you to use a `cua' instead of - `ttyS' device. - - 3.2.2. Setting the routes - - The default route can be set with the defaultroute option or with the - /etc/ppp/ip-up script; - - - - #!/bin/bash - case $2 in - /dev/ttyS1) - /sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0 - ;; - esac - - - - Ip-up can also be used to sync your clock using netdate. - - - Of course the route set in ip-up is not necessarily the default route. - Your ip-up sets the route to the remote network while the ip-up script - on the remote system sets the route to your network. If your network - is 192.168.1.0 and your ppp interface 192.168.1.1, the ip-up script on - the remote machine looks like this; - - - - #!/bin/bash - case $2 in + + 3 OFF Disable result codes + 4 ON Disable offline commands + 5 ON For originate, OFF For answer + 8 OFF Dumb mode + + +3. PPPD + + +You need a pppd (Point to Point Protocol Daemon) and a reasonable +knowledge of how it works. Consult the relevant RFC's or the Linux PPP +HOWTO if necessary. Since you are not going to use a login procedure, +you don't use (m)getty and you do not need a (fake) user associated +with the pppd controlling your link. You are not going to dial so you +don't need any chat scripts either. In fact, the modem circuit and +configuration you have just build, are rather like a fully wired null +modem cable. This means you have to configure your pppd the same way +as you would with a null modem cable. + + + +For a reliable link, your setup should meet the following criteria; + + +· Shortly after booting your system, pppd should raise the DTR signal + in your RS232 port, wait for DCD to go up, and negotiate the link. +· If the remote system is down, pppd should wait until it is up + again. +· If the link is up and then goes down, pppd should reset the modem + (it does this by dropping and then raising DTR), and then try to + reconnect. +· If the quality of the link deteriorates too much, pppd should reset + the modem and then reestablish the link. +· If the process controlling the link, that is the pppd, dies, a + watchdog should restart the pppd. + +3.1. Configuration + + +Suppose the modem is connected to COM2, the local IP address is +`Loc_Ip' and the remote IP address is `Rem_Ip'. We want to use 576 as +our MTU. The /etc/ppp/options.ttyS1 would now be: + + + + +crtscts +mru 576 +mtu 576 +passive +Loc_Ip:Rem_Ip +-chap +modem +#noauth +-pap +persist + + + + +Stuff like `asyncmap 0', `lock', `modem' and `-detach' are probably +already in /etc/ppp/options. If not, add them to your +/etc/ppp/options.ttyS1. So, if the local system is 192.168.1.1 and +the remote system is 10.1.1.1, then /etc/ppp/options.ttyS1 on the +local system would be: + + + + + crtscts + mru 576 + mtu 576 + passive + 192.168.1.1:10.1.1.1 + -chap + modem + #noauth + -pap + persist + + + + +The options.ttyS1 on the remote system would be: + + + + + crtscts + mru 576 + mtu 576 + passive + 10.1.1.1:192.168.1.1 + -chap + modem + #noauth + -pap + persist + + + + +The passive option limits the number of (re)connection attempts. The +persist option will keep pppd alive in case of a disconnect or when it +can't connect in the first place. If you telnet a lot while doing +filetransfers (FTP or webbrowsing) at the same time, you might want to +use a smaller MTU and MRU such as 296. This will make the remote sys­ +tem more responsive. If you don't care much about telnetting during +FTP, you could set the MTU and MRU to 1500. Keep in mind though, that +UDP cannot be fragmented. Speakfreely for instance uses 512 byte UDP +packets. So the minimum MTU for speakfreely is 552 bytes. The noauth +option may be necessary with some newer distributions. + + +3.2. Scripts + +3.2.1. Starting the pppd and keeping it alive + + +You could start the pppd form a boot (rc) script. However, if you do +this, and the pppd dies, you are without a link. A more stable +solution, is to start the pppd from /etc/inittab; + + + + + s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200 + + + + +This way, the pppd will be restarted if it dies. Make sure you have a +`-detach' option (nodetach on newer systems) though, otherwise inittab +will start numerous instances of pppd, will complaining about +`respawning too fast'. + + + +Note: Some older systems will not accept the speed `115200'. In this +case you will have to set the speed to 38400 en set the `spd_vhi' flag +with setserial. Some systems expect you to use a `cua' instead of +`ttyS' device. + + +3.2.2. Setting the routes + + +The default route can be set with the defaultroute option or with the +/etc/ppp/ip-up script; + + + + + #!/bin/bash + case $2 in /dev/ttyS1) - /sbin/route add -net 192.168.1.0 gw 192.168.1.1 netmask 255.255.255.0 - ;; - esac + /sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0 + ;; + esac + + + +Ip-up can also be used to sync your clock using netdate. + + +Of course the route set in ip-up is not necessarily the default route. +Your ip-up sets the route to the remote network while the ip-up script +on the remote system sets the route to your network. If your network +is 192.168.1.0 and your ppp interface 192.168.1.1, the ip-up script on +the remote machine looks like this; + - The `case $2' and `/dev/ttyS1)' bits are there in case you use more - than one ppp link. Ip-up will run each time a link comes up, but only - the part between `/dev/ttySx)' and `;;' will be executed, setting the - right route for the right ttyS. You can find more about routing in - the Linux Networking HOWTO section on routing. + + + #!/bin/bash + case $2 in + /dev/ttyS1) + /sbin/route add -net 192.168.1.0 gw 192.168.1.1 netmask 255.255.255.0 + ;; + esac + + - 3.3. Test + +The `case $2' and `/dev/ttyS1)' bits are there in case you use more +than one ppp link. Ip-up will run each time a link comes up, but only +the part between `/dev/ttySx)' and `;;' will be executed, setting the +right route for the right ttyS. You can find more about routing in +the Linux Networking HOWTO section on routing. + - Test the whole thing just like the modem test. If it works, get on - your bike and bring the remote modem to the remote side of your link. - If it doesn't work, one of the things you should check is the COM port - speed; Apparently, a common mistake is to configure the modems with - Minicom using one speed and then configure the pppd to use an other. - This will NOT work! You have to use the same speed all of the time! +3.3. Test + + +Test the whole thing just like the modem test. If it works, get on +your bike and bring the remote modem to the remote side of your link. +If it doesn't work, one of the things you should check is the COM port +speed; Apparently, a common mistake is to configure the modems with +Minicom using one speed and then configure the pppd to use an other. +This will NOT work! You have to use the same speed all of the time! + + + + T1-T4 + +A T1 line is a high-speed, dedicated, point-to-point leased line that +includes 24 seperate 64 Kbps channles for voice and data. Other lines +of this type, called T-carrier lines, support larger numbers of channels. +T1 and T3 lines are the most commonly used. + -A T1 line is a high-speed, dedicated, point-to-point leased line that includes 24 seperate -64 Kbps channles for voice and data. Other lines of this type, called T-carrier lines, support -larger numbers of channels. T1 and T3 lines are the most commonly used. - -Carrier Channels Total Bandwidth + + +Carrier Channels Total Bandwidth T1 24 1.544 Mbps T2 96 6.312 Mbps T3 672 44.736 Mbps T4 4032 274.176 Mbps + + -While the specification for T-carrier lines does not mandate a particular media type, T1 and -T2 are typically carried on copper, and T3 and T4 typically use fiber optic media. DS1, DS2, -DS3, and DS4 are an alternate type of line equivalent to T1-T4, and typically use fiber optic -media. - + +While the specification for T-carrier lines does not mandate a particular +media type, T1 and T2 are typically carried on copper, and T3 and T4 +typically use fiber optic media. DS1, DS2, DS3, and DS4 are an alternate +type of line equivalent to T1-T4, and typically use fiber optic media. + + SONET (Synchronous Optical Network) + +A leased-line system using fiber optic media to support data speeds up to +2.4 Gbps. SONET services are sold based on optical carier (OC) levels. OC +levels are calculated as multiples of the OC-1 speed, 51.840 Mbps. For +example, OC-3 level would correspond with a data speed of 155 Mbps and +OC-12 level would equate to a data transfer rate of 622 Mbps. OC-1 and +OC-3 are the most commonly used SONET lines. + -A leased-line system using fiber optic media to support data speeds up to 2.4 Gbps. SONET -services are sold based on optical carier (OC) levels. OC levels are calculated as multiples -of the OC-1 speed, 51.840 Mbps. For example, OC-3 level would correspond with a data speed of -155 Mbps and OC-12 level would equate to a data transfer rate of 622 Mbps. OC-1 and OC-3 -are the most commonly used SONET lines. - - + diff --git a/LDP/guide/docbook/Linux-Networking/PLIP.xml b/LDP/guide/docbook/Linux-Networking/PLIP.xml index 1cdf4114..ac7fa464 100644 --- a/LDP/guide/docbook/Linux-Networking/PLIP.xml +++ b/LDP/guide/docbook/Linux-Networking/PLIP.xml @@ -3,147 +3,183 @@ PLIP - 7.2. PLIP for Linux-2.0 - - PLIP device names are `plip0', `plip1 and plip2. - - Kernel Compile Options: - - - Network device support ---> - <*> PLIP (parallel port) support - - - - plip (Parallel Line IP), is like SLIP, in that it is used for - providing a point to point network connection between two machines, - except that it is designed to use the parallel printer ports on your - machine instead of the serial ports (a cabling diagram in included in - the cabling diagram section later in this document). Because it is - possible to transfer more than one bit at a time with a parallel port, - it is possible to attain higher speeds with the plip interface than - with a standard serial device. In addition, even the simplest of - parallel ports, printer ports, can be used in lieu of you having to - purchase comparatively expensive 16550AFN UART's for your serial - ports. PLIP uses a lot of CPU compared to a serial link and is most - certainly not a good option if you can obtain some cheap ethernet - cards, but it will work when nothing else is available and will work - quite well. You should expect a data transfer rate of about 20 - kilobytes per second when a link is running well. - - The PLIP device drivers competes with the parallel device driver for - the parallel port hardware. If you wish to use both drivers then you - should compile them both as modules to ensure that you are able to - select which port you want to use for PLIP and which ports you want - for the printer driver. Refer to the ``Mudules mini-HOWTO'' for more - information on kernel module configuration. - - Please note that some laptops use chipsets that will not work with - PLIP because they do not allow some combinations of signals that PLIP - relies on, that printers don't use. - - The Linux plip interface is compatible with the Crynwyr Packet Driver - PLIP and this will mean that you can connect your Linux machine to a - DOS machine running any other sort of tcp/ip software via plip. - - In the 2.0.* series kernel the plip devices are mapped to i/o port and - IRQ as follows: - - - - device i/o IRQ - ------ ----- --- - plip0 0x3bc 5 - plip1 0x378 7 - plip2 0x278 2 - - - - If your parallel ports don't match any of the above combinations then - you can change the IRQ of a port using the ifconfig command using the - `irq' parameter (be sure to enable IRQ's on your printer ports in your - ROM BIOS if it supports this option). As an alternative, you can - specify ``io='' annd ``irq='' options on the insmod command line, if - you use modules. For example: - - - - root# insmod plip.o io=0x288 irq=5 - - - - PLIP operation is controlled by two timeouts, whose default values are - probably ok in most cases. You will probably need to increase them if - you have an especially slow computer, in which case the timers to - increase are actually on the other computer. A program called - plipconfig exists that allows you to change these timer settings - without recompiling your kernel. It is supplied with many Linux - distributions. - - To configure a plip interface, you will need to invoke the following - commands (or add them to your initialization scripts): - - - - root# /sbin/ifconfig plip1 localplip pointopoint remoteplip - root# /sbin/route add remoteplip plip1 - - - - Here, the port being used is the one at I/O address 0x378; localplip - amd remoteplip are the names or IP addresses used over the PLIP cable. - I personally keep them in my /etc/hosts database: - - - - # plip entries - 192.168.3.1 localplip - 192.168.3.2 remoteplip - - - - The pointopoint parameter has the same meaning as for SLIP, in that it - specifies the address of the machine at the other end of the link. - - In almost all respects you can treat a plip interface as though it - were a SLIP interface, except that neither dip nor slattach need be, - nor can be, used. - - Further information on PLIP may be obtained from the ``PLIP mini- - HOWTO''. - - 7.3. PLIP for Linux-2.2 - - During development of the 2.1 kernel versions, support for the - parallel port was changed to a better setup. - - Kernel Compile Options: - - - General setup ---> - [*] Parallel port support - Network device support ---> - <*> PLIP (parallel port) support - - - - The new code for PLIP behaves like the old one (use the same ifconfig - and route commands as in the previous section, but initialization of - the device is different due to the advanced parallel port support. - - The ``first'' PLIP device is always called ``plip0'', where first is - the first device detected by the system, similarly to what happens for - Ethernet devices. The actual parallel port being used is one of the - available ports, as shown in /proc/parport. For example, if you have - only one parallel port, you'll only have a directory called - /proc/parport/0. - - If your kernel didn't detect the IRQ number used by your port, - ``insmod plip'' will fail; in this case just write the right number to - /proc/parport/0/irq and reinvoke insmod. - - Complete information about parallel port management is available in - the file Documentation/parport.txt, part of your kernel sources. +plip (Parallel Line IP), is like SLIP, in that it is used for +providing a point to point network connection between two machines, +except that it is designed to use the parallel printer ports on your +machine instead of the serial ports (a cabling diagram in included in +the cabling diagram section later in this document). Because it is +possible to transfer more than one bit at a time with a parallel port, +it is possible to attain higher speeds with the plip interface than +with a standard serial device. In addition, even the simplest of +parallel ports, printer ports, can be used in lieu of you having to +purchase comparatively expensive 16550AFN UART's for your serial +ports. PLIP uses a lot of CPU compared to a serial link and is most +certainly not a good option if you can obtain some cheap ethernet +cards, but it will work when nothing else is available and will work +quite well. You should expect a data transfer rate of about 20 +kilobytes per second when a link is running well. - +7.2. PLIP for Linux-2.0 + + +PLIP device names are `plip0', `plip1 and plip2. + + + + + Kernel Compile Options: + + Network device support ---> + <*> PLIP (parallel port) support + + + + +The PLIP device drivers competes with the parallel device driver for +the parallel port hardware. If you wish to use both drivers then you +should compile them both as modules to ensure that you are able to +select which port you want to use for PLIP and which ports you want +for the printer driver. Refer to the ``Modules mini-HOWTO'' for more +information on kernel module configuration. + + + +Please note that some laptops use chipsets that will not work with +PLIP because they do not allow some combinations of signals that PLIP +relies on, that printers don't use. + + + +The Linux plip interface is compatible with the Crynwyr Packet Driver +PLIP and this will mean that you can connect your Linux machine to a +DOS machine running any other sort of tcp/ip software via plip. + + + +In the 2.0.* series kernel the plip devices are mapped to i/o port and +IRQ as follows: + + + + + device i/o IRQ + ------ ----- --- + plip0 0x3bc 5 + plip1 0x378 7 + plip2 0x278 2 + + + + +If your parallel ports don't match any of the above combinations then +you can change the IRQ of a port using the ifconfig command using the +`irq' parameter (be sure to enable IRQ's on your printer ports in your +ROM BIOS if it supports this option). As an alternative, you can +specify ``io='' annd ``irq='' options on the insmod command line, if +you use modules. For example: + + + + + root# insmod plip.o io=0x288 irq=5 + + + + +PLIP operation is controlled by two timeouts, whose default values are +probably ok in most cases. You will probably need to increase them if +you have an especially slow computer, in which case the timers to +increase are actually on the other computer. A program called +plipconfig exists that allows you to change these timer settings +without recompiling your kernel. It is supplied with many Linux +distributions. + + + +To configure a plip interface, you will need to invoke the following +commands (or add them to your initialization scripts): + + + + + root# /sbin/ifconfig plip1 localplip pointopoint remoteplip + root# /sbin/route add remoteplip plip1 + + + + +Here, the port being used is the one at I/O address 0x378; localplip +amd remoteplip are the names or IP addresses used over the PLIP cable. +I personally keep them in my /etc/hosts database: + + + + + # plip entries + 192.168.3.1 localplip + 192.168.3.2 remoteplip + + + + +The pointopoint parameter has the same meaning as for SLIP, in that it +specifies the address of the machine at the other end of the link. + + + +In almost all respects you can treat a plip interface as though it +were a SLIP interface, except that neither dip nor slattach need be, +nor can be, used. + + + +Further information on PLIP may be obtained from the ``PLIP mini- +HOWTO''. + + +7.3. PLIP for Linux-2.2 + + +During development of the 2.1 kernel versions, support for the +parallel port was changed to a better setup. + + + + + Kernel Compile Options: + + General setup ---> + [*] Parallel port support + Network device support ---> + <*> PLIP (parallel port) support + + + + +The new code for PLIP behaves like the old one (use the same ifconfig +and route commands as in the previous section, but initialization of +the device is different due to the advanced parallel port support. + + + +The ``first'' PLIP device is always called ``plip0'', where first is +the first device detected by the system, similarly to what happens for +Ethernet devices. The actual parallel port being used is one of the +available ports, as shown in /proc/parport. For example, if you have +only one parallel port, you'll only have a directory called +/proc/parport/0. + + + +If your kernel didn't detect the IRQ number used by your port, +``insmod plip'' will fail; in this case just write the right number to +/proc/parport/0/irq and reinvoke insmod. + + + +Complete information about parallel port management is available in +the file Documentation/parport.txt, part of your kernel sources. + + + diff --git a/LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml b/LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml index cdfd2cd5..3cf3a707 100644 --- a/LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml +++ b/LDP/guide/docbook/Linux-Networking/PPP-SLIP.xml @@ -3,813 +3,951 @@ PPP-SLIP - 3.7. PPP, SLIP, PLIP +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. +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 - · Linux PPP HOWTO +· PPP/SLIP emulator - · PPP/SLIP emulator - - · PLIP information can be found in The Network Administrator Guide - +· 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 - +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. + +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/Sources.xml b/LDP/guide/docbook/Linux-Networking/Sources.xml index 64853b01..4f450954 100644 --- a/LDP/guide/docbook/Linux-Networking/Sources.xml +++ b/LDP/guide/docbook/Linux-Networking/Sources.xml @@ -1151,5 +1151,38 @@ who we should thank for writing the first versions of this document. they wrote with questions but ended up giving me as much information as I gave them. Unfortunately I haven't compiled a list of names (maybe next time). You know who you are :-). + +X Window System Architecture Overview HOWTO +Daniel Manrique +roadmr@entropia.com.mx  +Revision History +Revision 1.0.1 2001-05-22 Revised by: dm +Some grammatical corrections, pointed out by Bill Staehle +Revision 1.0 2001-05-20 Revised by: dm +Initial LDP release. +12. Copyright and License +Copyright (c) 2001 by Daniel Manrique +Permission is granted to copy, distribute and/or modify this document under +the terms of the GNU Free Documentation License, Version 1.1 or any later +version published by the Free Software Foundation with no Invariant Sections, +no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be +found [http://www.gnu.org/copyleft/fdl.html] here. + + The LBX Mini-HOWTO + Paul D. Smith, psmith@baynetworks.com + v1.04, 11 December 1997 + + Leased line Mini HOWTO + The most recent (beta) version of this HOWTO can be found at: + http://www.sput.nl/software/leased-line/ + 1. Introduction + 1.1. Copyright and License + This document is distributed under the terms of the GNU Free + Documentation License. You should have received a copy along with it. + If not, it is available from http://www.fsf.org/licenses/fdl.html. + + + + diff --git a/LDP/guide/docbook/Linux-Networking/VNC.xml b/LDP/guide/docbook/Linux-Networking/VNC.xml index 1cc5ef2f..6f7c7df1 100644 --- a/LDP/guide/docbook/Linux-Networking/VNC.xml +++ b/LDP/guide/docbook/Linux-Networking/VNC.xml @@ -258,364 +258,6 @@ my fault. Remember, what you do here could make very large holes in the security model of your network. You've been warned. ----------------------------------------------------------------------------- -1.4.3. GNU Free Documentation License - -Version 1.1, March 2000 - - - Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite - 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and - distribute verbatim copies of this license document, but changing it is - not allowed. - ------------------------------------------------------------------------------ -1.4.4. PREAMBLE - -The purpose of this License is to make a manual, textbook, or other written -document "free" in the sense of freedom: to assure everyone the effective -freedom to copy and redistribute it, with or without modifying it, either -commercially or noncommercially. Secondarily, this License preserves for the -author and publisher a way to get credit for their work, while not being -considered responsible for modifications made by others. - -This License is a kind of "copyleft", which means that derivative works of -the document must themselves be free in the same sense. It complements the -GNU General Public License, which is a copyleft license designed for free -software. - -We have designed this License in order to use it for manuals for free -software, because free software needs free documentation: a free program -should come with manuals providing the same freedoms that the software does. -But this License is not limited to software manuals; it can be used for any -textual work, regardless of subject matter or whether it is published as a -printed book. We recommend this License principally for works whose purpose -is instruction or reference. ------------------------------------------------------------------------------ - -1.4.5. APPLICABILITY AND DEFINITIONS - -This License applies to any manual or other work that contains a notice -placed by the copyright holder saying it can be distributed under the terms -of this License. The "Document", below, refers to any such manual or work. -Any member of the public is a licensee, and is addressed as "you". - -A "Modified Version" of the Document means any work containing the Document -or a portion of it, either copied verbatim, or with modifications and/or -translated into another language. - -A "Secondary Section" is a named appendix or a front-matter section of the -Document that deals exclusively with the relationship of the publishers or -authors of the Document to the Document's overall subject (or to related -matters) and contains nothing that could fall directly within that overall -subject. (For example, if the Document is in part a textbook of mathematics, -a Secondary Section may not explain any mathematics.) The relationship could -be a matter of historical connection with the subject or with related -matters, or of legal, commercial, philosophical, ethical or political -position regarding them. - -The "Invariant Sections" are certain Secondary Sections whose titles are -designated, as being those of Invariant Sections, in the notice that says -that the Document is released under this License. - -The "Cover Texts" are certain short passages of text that are listed, as -Front-Cover Texts or Back-Cover Texts, in the notice that says that the -Document is released under this License. - -A "Transparent" copy of the Document means a machine-readable copy, -represented in a format whose specification is available to the general -public, whose contents can be viewed and edited directly and -straightforwardly with generic text editors or (for images composed of -pixels) generic paint programs or (for drawings) some widely available -drawing editor, and that is suitable for input to text formatters or for -automatic translation to a variety of formats suitable for input to text -formatters. A copy made in an otherwise Transparent file format whose markup -has been designed to thwart or discourage subsequent modification by readers -is not Transparent. A copy that is not "Transparent" is called "Opaque". - -Examples of suitable formats for Transparent copies include plain ASCII -without markup, Texinfo input format, LaTeX input format, SGML or XML using a -publicly available DTD, and standard-conforming simple HTML designed for -human modification. Opaque formats include PostScript, PDF, proprietary -formats that can be read and edited only by proprietary word processors, SGML -or XML for which the DTD and/or processing tools are not generally available, -and the machine-generated HTML produced by some word processors for output -purposes only. - -The "Title Page" means, for a printed book, the title page itself, plus such -following pages as are needed to hold, legibly, the material this License -requires to appear in the title page. For works in formats which do not have -any title page as such, "Title Page" means the text near the most prominent -appearance of the work's title, preceding the beginning of the body of the -text. ------------------------------------------------------------------------------ - -1.4.6. VERBATIM COPYING - -You may copy and distribute the Document in any medium, either commercially -or noncommercially, provided that this License, the copyright notices, and -the license notice saying this License applies to the Document are reproduced -in all copies, and that you add no other conditions whatsoever to those of -this License. You may not use technical measures to obstruct or control the -reading or further copying of the copies you make or distribute. However, you -may accept compensation in exchange for copies. If you distribute a large -enough number of copies you must also follow the conditions in section 3. - -You may also lend copies, under the same conditions stated above, and you may -publicly display copies. ------------------------------------------------------------------------------ - -1.4.7. COPYING IN QUANTITY - -If you publish printed copies of the Document numbering more than 100, and -the Document's license notice requires Cover Texts, you must enclose the -copies in covers that carry, clearly and legibly, all these Cover Texts: -Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. -Both covers must also clearly and legibly identify you as the publisher of -these copies. The front cover must present the full title with all words of -the title equally prominent and visible. You may add other material on the -covers in addition. Copying with changes limited to the covers, as long as -they preserve the title of the Document and satisfy these conditions, can be -treated as verbatim copying in other respects. - -If the required texts for either cover are too voluminous to fit legibly, you -should put the first ones listed (as many as fit reasonably) on the actual -cover, and continue the rest onto adjacent pages. - -If you publish or distribute Opaque copies of the Document numbering more -than 100, you must either include a machine-readable Transparent copy along -with each Opaque copy, or state in or with each Opaque copy a -publicly-accessible computer-network location containing a complete -Transparent copy of the Document, free of added material, which the general -network-using public has access to download anonymously at no charge using -public-standard network protocols. If you use the latter option, you must -take reasonably prudent steps, when you begin distribution of Opaque copies -in quantity, to ensure that this Transparent copy will remain thus accessible -at the stated location until at least one year after the last time you -distribute an Opaque copy (directly or through your agents or retailers) of -that edition to the public. - -It is requested, but not required, that you contact the authors of the -Document well before redistributing any large number of copies, to give them -a chance to provide you with an updated version of the Document. ------------------------------------------------------------------------------ - -1.4.8. MODIFICATIONS - -You may copy and distribute a Modified Version of the Document under the -conditions of sections 2 and 3 above, provided that you release the Modified -Version under precisely this License, with the Modified Version filling the -role of the Document, thus licensing distribution and modification of the -Modified Version to whoever possesses a copy of it. In addition, you must do -these things in the Modified Version: - - A. Use in the Title Page (and on the covers, if any) a title distinct from - that of the Document, and from those of previous versions (which should, - if there were any, be listed in the History section of the Document). You - may use the same title as a previous version if the original publisher of - that version gives permission. - - B. List on the Title Page, as authors, one or more persons or entities - responsible for authorship of the modifications in the Modified Version, - together with at least five of the principal authors of the Document (all - of its principal authors, if it has less than five). - - C. State on the Title page the name of the publisher of the Modified - Version, as the publisher. - - D. Preserve all the copyright notices of the Document. - - E. Add an appropriate copyright notice for your modifications adjacent to - the other copyright notices. - - F. Include, immediately after the copyright notices, a license notice giving - the public permission to use the Modified Version under the terms of this - License, in the form shown in the Addendum below. - - G. Preserve in that license notice the full lists of Invariant Sections and - required Cover Texts given in the Document's license notice. - - H. Include an unaltered copy of this License. - - I. Preserve the section entitled "History", and its title, and add to it an - item stating at least the title, year, new authors, and publisher of the - Modified Version as given on the Title Page. If there is no section - entitled "History" in the Document, create one stating the title, year, - authors, and publisher of the Document as given on its Title Page, then - add an item describing the Modified Version as stated in the previous - sentence. - - J. Preserve the network location, if any, given in the Document for public - access to a Transparent copy of the Document, and likewise the network - locations given in the Document for previous versions it was based on. - These may be placed in the "History" section. You may omit a network - location for a work that was published at least four years before the - Document itself, or if the original publisher of the version it refers to - gives permission. - - K. In any section entitled "Acknowledgements" or "Dedications", preserve the - section's title, and preserve in the section all the substance and tone - of each of the contributor acknowledgements and/or dedications given - therein. - - L. Preserve all the Invariant Sections of the Document, unaltered in their - text and in their titles. Section numbers or the equivalent are not - considered part of the section titles. - - M. Delete any section entitled "Endorsements". Such a section may not be - included in the Modified Version. - - N. Do not retitle any existing section as "Endorsements" or to conflict in - title with any Invariant Section. - - -If the Modified Version includes new front-matter sections or appendices that -qualify as Secondary Sections and contain no material copied from the -Document, you may at your option designate some or all of these sections as -invariant. To do this, add their titles to the list of Invariant Sections in -the Modified Version's license notice. These titles must be distinct from any -other section titles. - -You may add a section entitled "Endorsements", provided it contains nothing -but endorsements of your Modified Version by various parties--for example, -statements of peer review or that the text has been approved by an -organization as the authoritative definition of a standard. - -You may add a passage of up to five words as a Front-Cover Text, and a -passage of up to 25 words as a Back-Cover Text, to the end of the list of -Cover Texts in the Modified Version. Only one passage of Front-Cover Text and -one of Back-Cover Text may be added by (or through arrangements made by) any -one entity. If the Document already includes a cover text for the same cover, -previously added by you or by arrangement made by the same entity you are -acting on behalf of, you may not add another; but you may replace the old -one, on explicit permission from the previous publisher that added the old -one. - -The author(s) and publisher(s) of the Document do not by this License give -permission to use their names for publicity for or to assert or imply -endorsement of any Modified Version. ------------------------------------------------------------------------------ - -1.4.9. COMBINING DOCUMENTS - -You may combine the Document with other documents released under this -License, under the terms defined in section 4 above for modified versions, -provided that you include in the combination all of the Invariant Sections of -all of the original documents, unmodified, and list them all as Invariant -Sections of your combined work in its license notice. - -The combined work need only contain one copy of this License, and multiple -identical Invariant Sections may be replaced with a single copy. If there are -multiple Invariant Sections with the same name but different contents, make -the title of each such section unique by adding at the end of it, in -parentheses, the name of the original author or publisher of that section if -known, or else a unique number. Make the same adjustment to the section -titles in the list of Invariant Sections in the license notice of the -combined work. - -In the combination, you must combine any sections entitled "History" in the -various original documents, forming one section entitled "History"; likewise -combine any sections entitled "Acknowledgements", and any sections entitled -"Dedications". You must delete all sections entitled "Endorsements." ------------------------------------------------------------------------------ - -1.4.10. COLLECTIONS OF DOCUMENTS - -You may make a collection consisting of the Document and other documents -released under this License, and replace the individual copies of this -License in the various documents with a single copy that is included in the -collection, provided that you follow the rules of this License for verbatim -copying of each of the documents in all other respects. - -You may extract a single document from such a collection, and distribute it -individually under this License, provided you insert a copy of this License -into the extracted document, and follow this License in all other respects -regarding verbatim copying of that document. ------------------------------------------------------------------------------ - -1.4.11. AGGREGATION WITH INDEPENDENT WORKS - -A compilation of the Document or its derivatives with other separate and -independent documents or works, in or on a volume of a storage or -distribution medium, does not as a whole count as a Modified Version of the -Document, provided no compilation copyright is claimed for the compilation. -Such a compilation is called an "aggregate", and this License does not apply -to the other self-contained works thus compiled with the Document, on account -of their being thus compiled, if they are not themselves derivative works of -the Document. - -If the Cover Text requirement of section 3 is applicable to these copies of -the Document, then if the Document is less than one quarter of the entire -aggregate, the Document's Cover Texts may be placed on covers that surround -only the Document within the aggregate. Otherwise they must appear on covers -around the whole aggregate. ------------------------------------------------------------------------------ - -1.4.12. TRANSLATION - -Translation is considered a kind of modification, so you may distribute -translations of the Document under the terms of section 4. Replacing -Invariant Sections with translations requires special permission from their -copyright holders, but you may include translations of some or all Invariant -Sections in addition to the original versions of these Invariant Sections. -You may include a translation of this License provided that you also include -the original English version of this License. In case of a disagreement -between the translation and the original English version of this License, the -original English version will prevail. ------------------------------------------------------------------------------ - -1.4.13. TERMINATION - -You may not copy, modify, sublicense, or distribute the Document except as -expressly provided for under this License. Any other attempt to copy, modify, -sublicense or distribute the Document is void, and will automatically -terminate your rights under this License. However, parties who have received -copies, or rights, from you under this License will not have their licenses -terminated so long as such parties remain in full compliance. ------------------------------------------------------------------------------ - -1.4.14. FUTURE REVISIONS OF THIS LICENSE - -The Free Software Foundation may publish new, revised versions of the GNU -Free Documentation License from time to time. Such new versions will be -similar in spirit to the present version, but may differ in detail to address -new problems or concerns. See [http://www.gnu.org/copyleft/] http:// -www.gnu.org/copyleft/. - -Each version of the License is given a distinguishing version number. If the -Document specifies that a particular numbered version of this License "or any -later version" applies to it, you have the option of following the terms and -conditions either of that specified version or of any later version that has -been published (not as a draft) by the Free Software Foundation. If the -Document does not specify a version number of this License, you may choose -any version ever published (not as a draft) by the Free Software Foundation. ------------------------------------------------------------------------------ - -1.4.15. How to use this License for your documents - -To use this License in a document you have written, include a copy of the -License in the document and put the following copyright and license notices -just after the title page: - - - Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute - and/or modify this document under the terms of the GNU Free Documentation - License, Version 1.1 or any later version published by the Free Software - Foundation; with the Invariant Sections being LIST THEIR TITLES, with the - Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A - copy of the license is included in the section entitled "GNU Free - Documentation License". - -If you have no Invariant Sections, write "with no Invariant Sections" instead -of saying which ones are invariant. If you have no Front-Cover Texts, write -"no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise -for Back-Cover Texts. - -If your document contains nontrivial examples of program code, we recommend -releasing these examples in parallel under your choice of free software -license, such as the GNU General Public License, to permit their use in free -software. ------------------------------------------------------------------------------ - 1.5. Document History The original "VPN mini-HOWTO" was written by Arpad Magosanyi, < diff --git a/LDP/guide/docbook/Linux-Networking/X11.xml b/LDP/guide/docbook/Linux-Networking/X11.xml index f159d5ad..0deb931b 100644 --- a/LDP/guide/docbook/Linux-Networking/X11.xml +++ b/LDP/guide/docbook/Linux-Networking/X11.xml @@ -2,524 +2,1049 @@ X11 - 7.3. The X Window System - - The X Window System was developed at MIT in the late 1980s, rapidly - becoming the industry standard windowing system for Unix graphics - workstations. The software is freely available, very versatile, and is - suitable for a wide range of hardware platforms. Any X environment - consists of two distinct parts, the X server and one or more X - clients. It is important to realise the distinction between the server - and the client. The server controls the display directly and is - responsible for all input/output via the keyboard, mouse or display. - The clients, on the other hand, do not access the screen directly - - they communicate with the server, which handles all input and output. - It is the clients which do the "real" computing work - running - applications or whatever. The clients communicate with the server, - causing the server to open one or more windows to handle input and - output for that client. - - In short, the X Window System allows a user to log in into a remote - machine, execute a process (for example, open a web browser) and have - the output displayed on his own machine. Because the process is - actually being executed on the remote system, very little CPU power is - needed in the local one. Indeed, computers exist whose primary purpose - is to act as pure X servers. Such systems are called X terminals. - - A free port of the X Window System exists for Linux and can be found - at: Xfree . It is included in most Linux - distributions. - - Related HOWTO: - - · Remote X Apps HOWTO - -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. - -X11, LBX, DXPC, NXServer, SSH - -> Linux XDMCP HOWTO -> XDM and X Terminal mini-HOWTO -> The Linux XFree86 HOWTO -> ATI R200 + XFree86 4.x mini-HOWTO -> Second Mouse in X mini-HOWTO -> Linux Touch Screen HOWTO -> XFree86 Video Timings HOWTO -> Linux XFree-to-Xinside mini-HOWTO -> XFree Local Multi-User HOWTO -> Using Xinerama to MultiHead XFree86 V. 4.0+ -> Connecting X Terminals to Linux Mini-HOWTO -> How to change the title of an xterm -> X Window System Architecture Overview HOWTO -> The X Window User HOWTO +The X Window System was developed at MIT in the late 1980s, rapidly +becoming the industry standard windowing system for Unix graphics +workstations. The software is freely available, very versatile, and is +suitable for a wide range of hardware platforms. Any X environment +consists of two distinct parts, the X server and one or more X +clients. It is important to realise the distinction between the server +and the client. The server controls the display directly and is +responsible for all input/output via the keyboard, mouse or display. +The clients, on the other hand, do not access the screen directly - +they communicate with the server, which handles all input and output. +It is the clients which do the "real" computing work - running +applications or whatever. The clients communicate with the server, +causing the server to open one or more windows to handle input and +output for that client. - The LBX Mini-HOWTO - Paul D. Smith, psmith@baynetworks.com - v1.04, 11 December 1997 + +In short, the X Window System allows a user to log in into a remote +machine, execute a process (for example, open a web browser) and have +the output displayed on his own machine. Because the process is +actually being executed on the remote system, very little CPU power is +needed in the local one. Indeed, computers exist whose primary purpose +is to act as pure X servers. Such systems are called X terminals. + + + +A free port of the X Window System exists for Linux and can be found +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. - 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. - ______________________________________________________________________ + 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. - Table of Contents +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 - 1. Introduction +· 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. - 2. What's The Status Of LBX? +11.1.3. Where Can I Get dxpc? - 3. Who Can Benefit From LBX? + +The source for dxpc is available at ftp.x.org +. + - 4. Who Doesn't Need LBX? - - 5. How Does LBX Work? - - 6. What Do I Need To Use LBX? - - 7. What Don't I Need To Use LBX? - - 8. How Do I Start LBX? - - 9. Problems - - 10. Documentation - - 11. Alternatives - - 11.1 dxpc - The Differential X Protocol Compressor - 11.1.1 Advantages - 11.1.2 Disadvantages - 11.1.3 Where Can I Get dxpc? - 11.2 Ssh (Secure Shell) - 11.3 Which Is Better? - - - ______________________________________________________________________ - - 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. + +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. + + + +X11, LBX, DXPC, NXServer, SSH, MAS + +Related HOWTOs: + +· Remote X Apps HOWTO +· Linux XDMCP HOWTO +· XDM and X Terminal mini-HOWTO +· The Linux XFree86 HOWTO +· ATI R200 + XFree86 4.x mini-HOWTO +· Second Mouse in X mini-HOWTO +· Linux Touch Screen HOWTO +· XFree86 Video Timings HOWTO +· Linux XFree-to-Xinside mini-HOWTO +· XFree Local Multi-User HOWTO +· Using Xinerama to MultiHead XFree86 V. 4.0+ +· Connecting X Terminals to Linux Mini-HOWTO +· How to change the title of an xterm +· X Window System Architecture Overview HOWTO +· The X Window User HOWTO +