PreviousINDEXNext
Handling SpamAnother Debian Install

Installing Debian

A little while ago, the first home PC I purchased, in 1996, died. This machine, named chrome, had been providing word processing capabilities under Windows 95 for my wife since that time. The disk drive had failed, which held all my wife's files. I'd been performing reasonably regular backups, so it wasn't a complete disaster. However, luckily, I was able to rescue the latest files, by putting the disk drive in the fridge for a couple of hours, then re-installing in another machine and copying the contents to a drive with enough free space.

My wife transferred to a spare laptop, the only snag being that chrome had acted as the print server for the network. Now, the laptop had to be connected to the printer's parallel port to provide server capabilities, which kind of negated it's value as a portable device.

I therefore decided to resurrect chrome as a print and file server, but using samba. I could have put FreeBSD on chrome, but decided to try and install Debian Linux, and see how it compared against Redhat and FreeBSD in terms of installation and management.

I purchased a 40GB drive for chrome. I figured I could perform a network install, so I also downloaded and burnt a CD with the Debian installation files. Then, belatedly realising that chrome was so old that it couldn't boot off a CD, I copied down the rescue.bin and root.bin images and copied them to floppy disks.

My first attempt at installation wasn't wholly successful. My first problem was in understanding how Debian performed disk partitioning. The model I had in my head was from FreeBSD, in which the disk is partitioned and the mount points are defined at the same time. With Debian, the partitioning is performed first, and in a subsequent step, the partitions are mapped to mount points. Once my understanding was corrected, I selected the following partitioning scheme:

/dev/hda1           /           400MB
/dev/hda5           /home       8GB
/dev/hda6           /opt        8GB
/dev/hda7           /usr        3GB
/dev/hda8           /usr/local  3GB
/dev/hda9           /var        200MB
/dev/hda10          /tmp        200MB
/dev/hda11          swap        256MB

The next challenge I faced was the request for the installer for me to choose my desired installation medium: Hard Disk, CD or floppy. Hmm, no network install option. Ah, that's because I hadn't been asked to configure my network card yet. A quick glance at the installation manual revealed that I should have copied a bunch of drivers to floppy disks as well. Then I remembered the CD I had created - maybe that came with the drivers. I loaded into the CD drive, chose CD off the installation menu and, hurrah, we were off. Close call...

After configuring the network driver (generic Digital), I was offered a set of standard installs to download by a program called tasksel. I chose:

desktop environment
c and c++
python
conventional unix server
TeX/LaTex environment

This choice was mistaken, for reasons we will come to soon.

After tasksel, you are offered the chance to refine your gross selection with dselect. The user interface looked daunting (especially at the time of night I was doing this), so I left things as they were. The download started and I went to bed.

In the morning, everything looked OK. I was presented with screens allowing me to configure the timezone and sundry other aspects. However, during the completion of these dialogs, an error message informed me that /var was full. Uh oh, this wasn't good. It seemed entirely plausible that /var had filled up during the download. And so it transpired. The next stage, in which the packages are installed and configured into their rightful locations, seemed to go OK, but then the message "Loading /etc/console/boottime.kmap.gz" was printing slowly (but endlessly) on the console. Control-C did nothing. I hard reset the box to force a reboot, but after fscking the disks, the same message began to repeat.

A little bit of googling later, the problem appeared to be caused by a defect in the initial base-config. One workaround suggested was to use Control-Alt-Fn to go to another virtual console, login as root, copy /etc/inittab.real over /etc/inittab and then reboot. I tried this and it worked. I then discovered that I was correct in my assumption that a lot of packages had not been downloaded due to the full /var partition. Ah well, start again...

The second time I set /var to be 1GB, figuring that would be an ample size. This time the download proceeded OK, the package installation took a lot longer, and the looping message did not occur. At this stage I was feeling reasonably confident that everything was OK.

However, logging on, I found that while I had the bloatware that is KDE and Gnome, I did not have an X server. Looks like that "desktop environment" did not include X as I had surmised. OK, back to dselect. I found the xserver package, and along with samba, marked it for installation. Both these packages installed without glitches; the Debian package system seeming to be very similar to FreeBSD ports.

I'd read about apt-get, so for the next package I tried to use it:

apt-get install rxvt wmaker

This worked very well, so I used apt-get to remove KDE and Gnome:

apt-get remove kde gnome

That saved over 80MB of space.

I guess the lesson I should take from this experience of installing Debian is to read the manual first but, as we know, that is a refuge for scoundrels.

My impression is that Debian is a less heavy weight install than Redhat, and at run-time, has less processes running by default. The packages system is less painful than the RPM system used by Redhat (in which all the dependencies have to be resolved one at a time). Now that Redhat has moved firmly into the enterprise camp, I think I might shift my main Linux system to Debian.

Updating packages

I'd chosen to install the stable release, but noticed that a number of packages I generally used (e.g. emacs and python) were relatively old. Emacs was a 20.7 version and python was 2.1. While I am quite appreciative of conservatism for kernels, these were applications where a breakage was not fatal.

I needed to load emacs from the Debian testing distribution, which takes a couple of steps. The first is to add the location of the testing packages to the /etc/apt/source.list file. After adding the location of the testing packages, this looked like:

deb ftp://ftp.uk.debian.org/debian/ testing main contrib
deb ftp://ftp.uk.debian.org/debian/ stable main
deb-src ftp://ftp.uk.debian.org/debian/ stable main
deb http://non-us.debian.org/debian-non-US stable/non-US main
deb-src http://non-us.debian.org/debian-non-US stable/non-US main

deb http://security.debian.org/ stable/updates main

I also set up the /etc/apt/apt.conf file so that stable was my default distribution, to avoid unpleasant surprises later on, when I had forgotten what I'd done:

APT::Default-Release "stable";

Finally, you have to run apt-get update for it to download the new package listing from testing. At this point you can now install a package from testing by issuing a command of the form:

apt-get -t testing install emacs21

Printing via CUPS

I downloaded CUPS (apt-get install cupsys) to handle printing onto the locally connected HP LaserJet 5N. Using the web interface (http://localhost:631/admin), it was remarkably easy to setup the printer.

Initially, it would print a test page from the web interface, but would not print from the command line lpr. This is because the cupsys-client package must also be installed. That gives you the System V interface (lp, lpstat), but if you prefer the BSD interface, you must also install cupsys-bsd.

However, when I tried printing from a Windows client, a blank page was output at the end of job. I found out that this can be suppressed by modifying the /etc/printcap file to add the sf flag (suppress formfeed).

lp|Generic dot-matrix printer entry:\
        :lp=/dev/lp0:\
        :sd=/var/spool/lpd/lp:\
        :af=/var/log/lp-acct:\
        :lf=/var/log/lp-errs:\
        :pl#66:\
        :pw#80:\
        :pc#150:\
        :mx#0:\
        :sh:\
        :sf:

Access for users without UNIX logins

I wanted to grant access to the printer to all users, but without giving them UNIX logins. This turned out to need the security=share option in the [global] section of the /etc/smb.conf file, and ensuring that public=yes is set in the [printers] section.

Development Environment

For a C development environment, complete with useful man pages, make sure you have the following packages installed:

  gcc
  gcc-doc
  glibc-doc
  libc6-dev
  manpages-dev

Add g++ for C++.

PreviousINDEXNext
Handling SpamAnother Debian Install