![[Photo of the Author]](../../common/images/Who.gif)
original in en Serge Winitzki
![[Ilustration]](../../common/images/illustration16.gif)
This is my second time installing a GNU/Linux operating system on a laptop. The first experience was with a LapNote P150 and is documented here. I used information from the Slackware CDROM, such as the various HOWTOs, the Linux Installation Guide version 3.2, and of course the Linux on Laptops web page. All information below regards specifically the Slackware 3.5 installation on a Fujitsu 635T. Internet links to specific programs are not provided, assuming that the reader will be able to locate them through the referenced web sites.
I bought a second-hand laptop, a Fujitsu 635T, by email order. As I expected, the computer came loaded with the so called operating system with "windows", version "95 OSR 2". The installation of "windows" had probably been a "clean re-installation" done by its previous owner before selling it to me. The sound card was not recognized, and the whole PCMCIA system seemed absent as well. I don't remember now whether the true-color mode was supported. I also didn't try the "suspend to disk" option since there was no suspend-to-disk partition on the hard disk, and I thought it wouldn't work and might damage the existing partition without a special suspend-to-disk partition. (My fears were unfounded: the BIOS recognized that no suspend-to-disk partition existed and printed a warning when I tried to enable that option.
I knew that it is not wise to succumb to the temptation to delete "windows" right away; I needed to extract a couple of things from it. First, I installed the "Generic Text" printer driver and then used the Control Panel to print out all system settings to a file, for possible future reference. This file is perhaps the only useful thing one can get from this so called operating system, since the main computer unit came with no manuals (no thanks to the fishy computer dealer, you know who you are). In principle, all this information should be contained in the hardware manuals; but today's marketing practice is to consider an installation of "windows" equivalent to giving you full information about the hardware. Essentially you get a presumably correctly installed copy of "windows" from which you can try to extract information.
Next thing after writing the hardware summary file to a floppy, I rebooted and entered the BIOS setup mode. The BIOS has a pleasant interface and lets one control
|
|
So the first step was to figure out how to create Linux bootdisks. I had already downloaded the Slackware Linux 3.5 distribution and browsed through files called README, INSTALL and so on. According to the suggested procedure, I used a DOS program "rawrite.exe" provided with Slackware to write the bootable floppy images onto the floppy disks. The command was something like rawrite.exe bare.i a: executed in the bootdsks.144 directory of the Slackware CDROM, to make a bootable floppy with the simplest ("bare") kernel, and rawrite.exe color.gz a: in the rootdisk directory to make the "rootdisk" floppy which is also necessary to start the Slackware installation. Later I figured out that I should have used the "bareapm.i" startup disk because the laptop has "advanced power management" (APM) functions and this way I could use them right away during the initial installation, e.g. I could suspend the laptop in the middle of installation and resume it later. But at first I didn't want to use anything except the most basic kernel. As a result of using a kernel which did not support APM, I got some strange crashes when I left the laptop for an hour and it went into auto-suspend. The typical reaction was that random programs would refuse to run and give a "zero divide" CPU level error message with a register dump. Glitches of that kind disappeared once I started using an APM-enabled kernel.
Having made the two floppies, I rebooted the computer and got a Linux system to which I could log in as "root" with no password. The login prompt told me that now I needed to create some hard drive partitions for Linux and execute the "setup" program once finished with that. The same message said that I could use either fdisk or cfdisk for partitioning. Since I already knew that fdisk wasn't very convenient to use, I decided to try cfdisk and was pleasantly surprised by its simple and intuitive text-mode interface. I deleted the single 1.35 GB FAT partition (goodbye, "windows"!) and created one 64MB swap partition and two (300 MB and 1 GB) native Linux type "ext2" partitions. I thought I would use the smaller partition for system files and the larger partition for user files and applications, so that if I later decide to reinstall Linux I won't have to delete everything.
After I was done with cfdisk, I started the setup program. First steps with the setup were clear enough: remap our keyboard (I didn't want to), set the swap space, choose the installation target directories and source directories. I chose the smaller partition to be the root partition (/) and the larger partition to be mounted as /usr. The first catch was with the source directory: I didn't have the original Slackware CDROM but rather I had downloaded all files and put them on a CDROM using "windows". I tried several times but the setup didn't recognize the directories I gave it as directories
|
|
The next step was to select the software packages I wanted to install. I selected all packages except the games, the X server development kit and the documentation which was on the CDROM anyway. Then the setup offered to make the hard disk bootable with the lilo boot manager. I chose the "automatic lilo installation" using the bareapm.i kernel. I skipped the network configuration, did not select any custom fonts, said that my modem was on COM2, my mouse was a PS/2 mouse, and that my timezone was in Amsterdam. (Why didn't they make PageDown work to scroll quickly through that huge list of timezones?) Finally I rebooted and got the system up successfully. I logged in as root with no password again and was ready to rock, with computational power of about 53 "BogoMips". This was roughtly correct for a 133 MHz Pentium (as listed in the "BogoMips mini-HowTo").
The only blemish so far was that the ZIP drive on the parallel port could not be recognized. The driver (ppa, parallel port adapter) essentially said that there was no
|
|
I also tried to edit the lilo configuration file by hand, but found that using the liloconfig program instead is more foolproof, especially since I usually forget to run lilo after changing its configuration file.
Final comments: sometimes there are error messages after performing some of the setup functions, but these error messages are immediately lost when the next screen is shown. I wish the error messages were still available so that I could see whether the setup procesures were successful. This would require perhaps more work for the shell scripts, but not that much: at least, the output of the commands can be redirected and shown on demand. Hallo, Mr. Volkerding, maybe you hear me.
I anticipated the first major problem to be setting up the X window system, to work with my graphics adapter and the 800x600 LCD screen. But the actual process was far from painful; it basically worked right away, and only the truecolor mode required some tweaking.
The Slackware Linux distribution comes with XFree86, a high-quality free X server which promises to fully support my graphics chip. I contemplated trying Accelerated X but then decided against it because XFree86 is more configurable and I've had better experience with it on my previous, less fully supported laptop. There were two alternatives for setting up XFree86: the X based configuration program and the text-based one. The only mouse I had was the somewhat worn down and unwieldy touchpad, so I opted for the text-mode configuration (the interface was a bit clunky but straightforward). Later I found that the graphical configuration wouldn't have worked anyway at that point because it was incompatible with gpm, the text-mode mouse driver which I have selected to be installed and activated. Killing it by gpm -k helped but the graphical configuration isn't really that helpful and it requires mouse.
The graphics adapter, C&T 65550 with 2MB of memory, was present in the list and I selected the 800x600 modes in all color depths. The only glitch was when halfway through the setup I was offered to run X -probeonly to detect the viable video modes, but it failed because at that point the installation hasn't yet written enough information into the initialization files. So I skipped that step and went ahead with further questions. I also ignored the questions about the monitor characteristics (such as admissible ranges of horizontal and vertical refresh frequencies); from my previous experience, this information is neither necessary
|
|
After everything was done with the config, I looked at the main video hardware configuration file /etc/X11/XF86Config. This file is usually full of garbage automatically inserted there by the configuration program. The most important part of it as far as hardware is concerned is the so called "Modelines" section. Each "Modeline" describes a particular video mode, corresponding to certain screen resolution, refresh frequencies and so on. Each mode has a name, and the configuration file refers to the modes by name later on, when the server is actually told which modes to use in which particular color depth (in the Screen section of the file). If several modes are given the same name, the server will only use one of them, the one with "best" refresh frequency and therefore image quality. From my previous experience configuring the XFree86 server, I knew the main catch with the automatic configuration: namely, it inserts way too many modelines with the same resolution and names them identically, like 640x480 or 800x600, leaving it up to the server to select the "best" mode for the given monitor. But only a few of the modes named say 800x600 may actually be workable. What happens in practice is this: the server selects the best mode but if it doesn't work for some reason, the user is stuck. A better way is to rename these modes differently, such as 800x600a, 800x600b and so on, and let the server use all of them. The user can then press Ctrl Alt + and Ctrl Alt - to switch between all available modes and select the best looking one.
So I deleted all modes except the 800x600 ones, renamed them, included them all into the Screen section and typed startx to start up the X window system. My best modeline was:
# 800x600 @ 60 Hz, 37.8 kHz hsync Modeline "800x600a" 40 800 840 968 1056 600 601 605 628 +hsync +vsync
Another one was similar at 56 Hz with almost the same image quality. I got a nice picture in full resolution right away. However, there was no window manager visible. Also, the truecolor mode didn't work at all. (The truecolor mode is started by startx -- -bpp 24 since on my chip the correct truecolor mode is not 32 bit but 24 bit per pixel, i.e. 24 bpp; X configurator correctly omits the 32 bit setting in the Screen section and it also uses the default color depth of 8bpp.) I ran X with redirected output (startx >& /tmp/startx-output) and then looked at the resulting file. This technique is very useful for diagnosing X setup problems, since otherwise the messages scroll up too quickly.
|
|
The problem with the window manager not showing up was due to the DISPLAY variable not being set up, for some reason. This environment variable is necessary for all programs to know where to show their windows. I fixed it by editing the startx script (see below).
The problem with truecolor was that X complained of the "pixel clock being too high" in the truecolor modes. Apparently it is a genuine hardware limitation on the pixel clock. For some time I thought that the truecolor mode was impossible to get, but then I looked up some other people's modelines for C&T adapters (from a wealth of information found on the Linux on Laptops web page) and discovered the following modeline with lower clock frequency:
#800x600 @ 49.5 Hz vsync, 30 kHz hsync, yucky and flickery even on LCD ModeLine "800x600b" 28.3 800 816 856 920 600 603 605 618
This mode has a very low refresh rate and poor image quality; when I switched it on, the monitor audibly buzzed while my eyes watered. LCD screens give better image quality than CRT ones and often the image is acceptable at say 56 Hz vertical refresh rate (which would be a terrible pain for the eyes on a typical 14 inch tube) but this was definitely not good enough. I didn't know what I was doing but I just increased the clock frequency to 35.1 instead of 28.3 while not changing the other numbers. The mode then worked much better. I then tried replacing the clock frequency by the lower bound 35.4 in the old modeline and it worked, too! I'm using it right now (in truecolor) to write this. I also added the line DefaultColorDepth 24 to the Screen section of the XF86Config file, to make truecolor mode the default one. I remembered that there was a way to make it use a certain color depth by default, but I had to look through the X manuals to find out the exact word "DefaultColorDepth", because the X configuration script didn't put in any sample default color depth line in there.
To make the trial 28.3 mode acceptable for the X server, I had to fix the allowed monitor frequency ranges. The configurator put in these ranges:
HorizSync 31.5 - 37.9 VertRefresh 50 - 90but then the new 28.3 mode wouldn't start because of frequencies being too low: I examined the /tmp/startx-output file and found that X complained about disallowed frequency ranges. So I lowered HorizSync to 30 instead of 31.5 and VertRefresh to 48 instead of 50. However, these two settings, especially the lower bounds, are not essential since the actual clock frequencies are completely determined by the modeline. In principle, these settings are here to prevent the monitor from burning out when given too high a frequency: the X server will compute the frequencies resulting from all modelines and reject those with frequencies outside the given ranges. But in practice I found that I could never get precise data about the monitor capabilities, and that I usually needed to change these ranges a little just to make the X server accept the good modes.
There were two final touches: I added the line TextClockFreq 40 to the XF86Config file to restore the correct text frequency when switching from an X session back to a text console; and I modified the startx script (/usr/X11R6/bin/startx) to keep the virtual console accessible and to set the DISPLAY environment variable (that variable was supposedly managed by the window manager, fvwm2, but it didn't seem to w). The final part of the script now looks like this:
export DISPLAY=":0.0" exec xinit $clientargs -- $serverargs >& /tmp/xinit.out &
The second line above redirects all output of the X console to a file in temporary directory and puts the whole X window process in the background, to be examined if necessary.
The system was up but I had an impression that I was missing out on the fun: I had two of these latest semi-commercial distributions, RedHat 5.1 and SuSE 5.2, both promising unrivaled ease of installation and configuration, and instead I am using the barebones hacker's distribution, Slackware. So I decided to get a taste of the alternatives.
|
|
SuSE 5.2, for all its proclaimed virtues, was never to boot on my laptop. I prepared the bootdisks using my working Slackware installation, with the command dd if=/cdrom/disks/eide01 of=/dev/fd0. None of its IDE bootdisks (eide01 to eide03) went any further than the printing the message "Loading Linux..." (with three periods), perhaps due to a memory conflict or something like that. I've heard people saying that sometimes bootdisks crash and then one needs to play with the memory cache or select different kernels, but 1) none of the kernels
|
|
Turning to RedHat 5.1, I was curious since my previous Linux experience was with RedHat 4.2 and I heard that much has been improved. The installation script shined, I had to make only one bootdisk which worked flawlessly and got me through the installation in a breeze. The parallel port zip drive was detected successfully as "/dev/sda", but since I didn't have to use it for installation, it was more of a nuisance; for example, fdisk couldn't be started, complaining of being "unable to access the default device /dev/sda". During setup I had one free parallel console which was already running bash, and two error log consoles (Ctrl-Alt-F3 and F4) to monitor the script progress. As I went ahead with the script and got to the point of selecting the individual packages, I could see how much space would be necessary for installation of various components, unlike Slackware's script. But it was not crucial since the total required space was under 400MB anyway and I had over twice as much free space on the /usr partition.
I got up to the configuration of X, which went more or less painlessly. The /etc/X11/XF86Config file which resulted from the configuration was somewhat less suitable for my hardware Because it omitted the relevant 24bpp truecolor mode; instead it should have thrown away the 32bpp one. But I already knew which modes worked and it wasn't that bad after all. My graphics adapter (C&T) was correctly identified. I started up X with no problems (except that the X terminal used white text on black background which I don't like) and, just to warm up, tried to use the glorious rpm ("RedHat package manager", the tool they use to manage software installation and de-installation) to install the new Ghostscript 5.10 from the redhat/contrib directory. This should be a piece of cake, I thought, one just needs to type a simple and intuitive command rpm -i packagename.rpm instead of the tedious and cryptic tar zxf packagename.tgz, right? Oopsie... I got a message from rpm saying that another package was needed to install Ghostscript, something like "ghostscript-fonts-standard", and that package was nowhere to be found. Other ghostscript font packages were around but not that one. I've seen something like this before: I remember rpm telling me once (under RedHat 4.2) that I "didn't have the package /bin/sh on my system"; /bin/sh is the shell, how would I be typing those commands without it. I'd like to hear it tell me that the motherboard is missing. Typical "rpm madness", I thought and gave up on that. Overall the system seemed to work slower than with the Slackware installation of essentially the same components.
|
|
Then I tried the system configuration tool linuxconf, touted as the best friend of the system admin. Unfortunately I wasn't able to understand what its many disconnected widgets were going to change in the system; some places were obvious while others were totally cryptic. The main priority for me is to understand the system configuration and be able to fix problems based on that understanding; I suspect that RedHat and perhaps other followers of the "make-it-easy" doctrine are trying to make system management "easy" not by hiding trivial details but by making the administrator run certain supplied software and never configure anything by hand.
Another gripe: although the ZIP drive was detected, access was terribly slow because the driver they used was a very old beta version that only supported the slowest access mode, so I needed to recompile the driver (and possibly the kernel) anyway. I encountered some other problem while trying to install kernel sources, I don't remember now what it was. Because of these considerations and fear of the "rpm madness", I decided to abandon RedHat and come back to the old rusty-and-trusty Slackware. I rebooted with the Slackware floppies I still had, repeated the installation with the caveats I already knew about and soon the system was up and running again.
At the center of a Linux system is the kernel, and I knew that it must include support for all the various peripheral devices connected to the system, from the mouse to the sound card to my parallel port ZIP drive to my external SCSI CDROM drive. I also knew that the kernel can support these devices in a modular form, that is loading the drivers on demand and unloading them afterwards. This makes the kernel smaller and more flexible, since in principle I could then load and unload drivers for incompatible devices when necessary. For example, the printer driver may not be compatible with the parallel port ZIP drive, in which case I would load the driver for only one of these at a time.
|
|
The kernel that comes with a standard Linux distribution includes support for some basic devices, including those I don't intend to ever have; the drivers for those devices merely sit in memory and do nothing. It's better to compile a custom kernel which will support precisely the computer it's run on.
With this in mind, I started to configure and compile the custom kernel for my computer. Since I had chosen to install the full kernel sources (version 2.0.34) when I installed Slackware, recompiling the kernel was very easy. I changed to the directory /usr/src/linux and said make menuconfig to start the text-based kernel configuration script. After a short time, I was presented with a pleasant-looking dialog box with various kernel options. Each kernel option is well commented and I was able to look through them in almost no time. I entered everything I could, up to the sound card (an "ESS AudioDrive") which was not listed but as I gathered from the READMEs, was a SoundBlaster clone (although it is not listed explicitly as a SoundBlaster, it should be). I choose every peripheral device I had to be compiled as a module; the devices included the power management ("APM"), SoundBlaster compatible sound card, a PS/2 mouse, serial ports, floppy disk, cdrom, and SCSI disk support (for my ZIP disk, and is good to have anyway). I made modules for various networking-related things such as SLIP and PPP, and for a.out, ELF, and java executable formats (in case I need to run them). I compiled separately the modules for Macintosh filesystem (hfs) which I need to work with SGI-compatible ZIP disks, and the updated support for the parallel ZIP drive (these things don't come with the standard kernel but I need them). I also downloaded the latest PCMCIA package (pcmcia-cs-3.0.4) and compiled the SCSI card and the network card support modules.
Then I said make dep; make zlilo; make modules; make modules_install and waited for about 15 minutes. After everything was done, the new kernel and modules were compiled and put into their correct locations. I checked that the kernel file /vmlinuz was newer and smaller than the old one saved as /vmlinuz.old, and rebooted... only to find that it doesn't boot any more, stopping before even any filesystems are mounted. The usual sequence of boot messages stopped after partition checking at VFS: mounted root (ext2 filesystem) readonly. No filesystems were mounted as read-write and no system initialization scripts (started by INIT) were executed. Oops.
After rebooting with the Slackware boot floppy which had the old kernel, I got my system back, went through the kernel configuration again and started thinking about what was wrong in my new kernel. Soon I found the fatal flaw: I was so fond of the idea of making everything modular that I made a stupid mistake and compiled the support for all executable formats (i.e. a.out, ELF and java) as modules. The kernel and all programs are compiled in ELF. So when the kernel started, it was unable to run any programs unless it loaded the module for ELF support, but to load that module it needs to run the insmod program, which is ELF. The way out is of course to compile the ELF executable support into the kernel, not as a module. This is also a natural thing to do since most programs these days are compiled as ELF executables. After I recompiled the kernel with this single change, I was able to reboot without problems.
Then I went to the /lib/modules directory and deleted all modules older than the currently compiled ones. This got rid of the error messages about incompatible modules at bootup. Also I edited the system initialization script /etc/rc.d/rc.S to enable kerneld, the "daemon" which inserts and removes modules automatically. With kerneld it is not necessary to insert and remove the kernel modules by hand using insmod and rmmod (although it is still possible to do so). The command lsmod lists all modules currently loaded in the kernel.
|
|
kerneld worked flawlessly, inserting modules when needed and removing them after they haven't been used for a while. I needed to add the line alias scsi_hostadapter ppa to /etc/conf.modules and the parallel port module ppa was automatically loaded when I attempted to mount the ZIP disk (/dev/sda). I guess I'd have to change that if I use a SCSI card instead of the parallel port adapter.
Several fine points of configuration came up after the new kernel was recompiled. They were: configuring access to external data storage devices (currently the floppy, CDROM, and ZIP drives); supporting two mice at once; supporting the Russian language; and setting up the fvwm2 window manager.
The Slackware installation script had created the /mnt directory under which it put the subdirectories /mnt/floppy and /mnt/cdrom for mounting the external filesystems on floppies and CDROMs. At first I decided that having them in a separate directory was not as convenient, and created /floppy and /cdrom in the root directory instead. But later on I realized that I need more directories for mounting devices with different options, and rather than keep them all in the root directory, I recreated the /mnt hierarchy.
I also changed the file mounting options in /etc/fstab. After the installation, that file contained reasonable defaults but it was not enough for my needs. First of all, I made the lines for the floppy, CDROM and ZIP drive devices, I needed to disable their automatic mounting and to allow all users to mount them (the user option):
/dev/fd0 /mnt/floppy vfat user,noauto,noexec,nonumtail 0 0 /dev/sda4 /mnt/zip vfat user,noauto,noexec,nonumtail 0 0 /dev/hdc /mnt/cdrom iso9660 user,noauto,noexec 0 0
Note the noexec option for the DOS-compatible filesystems: it makes files on those filesystems not executable, which is probably a sensible thing to do. The nonumtail option prevents creating ugly filenames: the file longname.file will be named longname.fil instead of longna~1.fil if there are no name conflicts. The vfat filesystem type supports long filenames in a DOS-compatible way, unlike the older msdos type, so why not use it.
The mtools package gave me some trouble: it needs either read/write permissions on /dev/fd0 or only the superuser can actually read or write to the floppy. Setting the setuid bit on the mtools files did not seem to help. I decided that I would rather mount these devices by hand.
The story with mice was relatively simple because I already had to figure it out when configuring my previous laptop. The laptop has a built-in touchpad (which is technically a PS/2 mouse), and I also like to use a real external mouse connected via the serial port. Both mice can be most easily supported simultaneously by using the program gpm ("general purpose mouse"). The program serves two purposes: firstly, in text consoles it enables use of mouse as a pointer (in
|
|
gpm -t ps2 -m /dev/psaux -2 -M -t mman -m /dev/cua0 -3 -R
This can be deciphered as: first mouse has type PS/2 on auxiliary port, has two buttons; the second mouse (-M) is of type [Logitech] MouseMan, connected on serial port 1 (/dev/cua0), has three buttons, and -R means that both mice should be available to X window sessions as one mouse. (Note that the option -R is not necessary here if using gpm version 1.14 or later.) After entering this line, I killed and restarted gpm (gpm -k; /etc/rc.d/rc.local) and then both of my mice worked immediately and without any problems. I was even able to plug in the serial mouse while already working in an X window session and voila, it worked right away. Such things were impossible under the so-called operating system with "windows": the latter tells the user to reboot the computer to make any "new hardware" work.
The next thing which occupied me was to set up support for Cyrillic characters. I need to be able to read and occasionally type Russian text. I installed support for Cyrillics only in X windows. This consisted of two parts: getting Cyrillic fonts and getting Cyrillic keyboard layout. There is a number pages on the net which explain all details of "Cyrillization of Unix". A set of KOI-8 fonts is provided with Slackware. The "Cyrillic How-To" points to the collection VakuFonts created by Serge Vakulenko (vak@kiae.su). It can be found in the collection of cyrillic stuff for the X Window System. I downloaded two font packages which supplied identical fonts in the KOI-8 and CP-1251 (or "Windows") encodings, unpacked the font files (*.pcf.gz) into subdirectories koi8-r and x-cp1251 of the main X window fonts directory /usr/X11R6/lib/X11R6/fonts/ (which on my Slackware system is easier accessed via the link /etc/X11/fonts).Then I installed the fonts by adding these two subdirectories to the "FontPath" in the file /etc/X11/XF86Config. After this, I restarted X window and all fonts were available, so I could configure Netscape (I used version 4.05) to automatically use these fonts for the corresponding "encodings" koi8-r and x-cp1251.
Then I needed a Russian keyboard driver. I used the simple and inobtrusive program xrus which I got from Moshkow's Library, the page on Cyrillization and after patching its resource file /etc/X11/app-defaults/Xrus and its keyboard layouts according to my understanding of the Russian typewriter :) I was comfortable typing in Russian.
The final thing was to install some program for converting files between Russian encodings. I use a very basic homemade script which I called 323.pl. It is capable of converting between CP866 ("DOS" or "alternative"), KOI-8, CP1251 ("Windows"), and Macintosh encodings. I created hard links to 323 named koi2win, alt2mac and so on (ln 323 koi2win etc.) and the script automatically determines what to do based on its name. Using this script and the installed fonts, one can read most any text in Russian.
|
|
All was set up properly for the X window system, except the window manager fvwm2. All its settings are controlled by a single resource file ~/.fvwm2rc or (if that file doesn't exist) by the systemwide file /etc/X11/fvwm2/system.fvwm2rc. I found that the resource file provided with Slackware had many things commented out which were actually not useful at all or didn't work, and I cut down considerably on those "features". The basic things I wanted from the window manager were: to show some buttons for quickly calling up a small number of most useful programs; to respond to keyboard and mouse for window operations such as moving or raising windows; to put some common operations in the titlebar buttons of all windows; and to show a menu of all installed X window applications. Ideally all this should be accessible from the keyboard without touching the mouse.
I started with the provided resource file and edited it many times, reading the long and somewhat dense manual page (man fvwm2) to find out how its various functions were invoked and adding changes incrementally. In particular, I was interested in making the "Windows 95" keys useful for various window operations. The result is .fvwm2rc, (which can be downloaded here), with hopefully enough comments to see what's going on.
The dial-up access to my local PPP network provider was up and running in so little time that I was actually amazed. After reading some complicated and also outdated-looking manuals on PPP setup, including the "Installation Guide", I was under impression that setting up PPP is quite a painful process. However, by random probing the command names starting with ppp I discovered that Slackware included a script called pppsetup which asked me just the right questions about my modem and my PPP provider. I didn't know one thing about it though: whether the "authentication protocol" was "PAP", "CHAP", or "CHAP-Microsoft". I (randomly) selected "CHAP" and went on with the setup. Soon everything was done and I was told to use two rather self-explanatory commands, ppp-go and ppp-off to control the PPP connection, and there was also a detailed text /etc/ppp/pppsetup.txt describing what has been done to the system during pppsetup. In that file, I was told to run ifconfig to see whether the PPP connection has been successfully established, and I was also pointed to the system log files /var/log/messages and /var/log/debug in case of any problems (since the debug option in the PPP options file /etc/ppp/options was enabled by default; later on I turned it off since the debug file was mostly being filled with the now useless pppd messages).
Everything seemed rosy, but when I connected the modem to the phone line, the ppp-go command didn't seem to create a connection. The /var/log/debug file contained many messages; I looked near the end of the file and found an unsuccessful exchange between the pppd and the remote host. One of the messages received from the remote host said <auth pap>. Aha, I said. So I should have actually selected the "PAP" instead of the "CHAP" authorization. I re-did the pppsetup and the PPP connection was up and running in no time. As a second thought, the pppscript contained some functions which grep'ed the system log file and printed messages such as "It seems that they want PAP..." and so on, but for some reason these functions were commented out. Is there a better version of pppsetup, maybe its development was not finished yet?
|
|
Although PPP is now running fine and I am able to use fetchmail, ncftp, Pine, netscape and other fine pieces of software with no problems, I am not completely satisfied with the setup. I wish the dial-up process were more controllable and its error messages, if any, visible to the user. In case the PPP connection is broken for any reason, I wish there was a way to find it out without logging on as root and browsing the system logs. Perhaps those more commercial Linuxes come with utilities which make a user-friendly PPP connection visible (maybe gppp?), but I was afraid that those utilities require lots of other opaque stuff to be installed or they may not work at all without their "native" environment. Some day I'll install a more friendly utility or learn Perl/Tk and write my own dial-up networking widgets. Or maybe I'll go with RedHat "all the way", when its GNOME object-oriented desktop manager grows to maturity.
Another issue with PPP was that the ppp-go script has to be started by the root user. At first I thought I'd set up on-demand dialing, but the kernel for some reason did not contain a version of the PPP driver (2.3) which supported that feature. Then I dug up the network archives and found a very short C program, "ppp for mortals," which essentially called the setuid(0) function to become the root user and then executed the ppp-go script. I compiled it and installed on the path with the setuid bit set to 1 (chmod 4755 ppp_for_mortals). After this, I could run this program as a user to start or stop the PPP connection.