Debian (woody) Cheat Sheet
<stddisclaimer.h>
This represents a selection of issues I came across while installing Debian 3.0r1 (aka. "Woody") on a rather atypical setup; specifically, a DMZ server which runs a limited set of custom apps written in Java. I found various answers to these issues, and wrote them down here for my own benefit as much as anything else. (I expect to have to repeat the exercise in future, and I'd like it to go a little more quickly next time.) I'm publishing it in the hope that somebody else will find it useful.
Most of what's in here is covered in more depth in the Debian Reference , q.v.; however, there is so much information in that reference that it can take a while to track down the nugget you need. Hence the need (my need, anyway) for this; it's a limited, partial cross-reference.
None of this is official. Much of it is my personal opinion and therefore biased or even wrong. YMMV. Caveat utor - use at your own risk. Etc.
Why Debian?
Initially, we used SuSE7, which suited us well. I decided to try Debian following a long war of attrition with SuSE8.0's new installer / maintenance tool, which I eventually won but decided I wasn't prepared to go through again. (I look after two DMZ servers, so I wanted to be sure that, even if it was a bit of a challenge the first time around, would be substantially easier thereafter.) I also considered a selection of other distros, but nothing answered. (Slackware, too hard; Red Hat, too pigopolist wanabee; various others, either aimed at the desktop, too experimental, or supported by too few people and therefore too risky.)
Basic installation
The Debian Install Guide covers this in considerable, not to say scary, detail. Frankly, if you've ever installed linux before, there's nothing you need to worry about. Debian may be a little less friendly on the surface, but it more than compensates for this by telling you stuff; all you need to do is read the screen and stay awake. (Other distros sing you a lullaby and leave you with a setup which you don't have the first clue about).
Use the bf24 kernel (boot from disk 5, not disk 1). The default kernel is late 2.2.x, and it's time that retired.
Debian reversibility principle: that which you cock up first time round, you can always come back and fix later. (Finding the right incantation can require a little educated guesswork.) This includes major foulups, such as inadvertently choosing not to install most of the standard packages! Debian is very robust.
Corrolary to DRP: all the things you see during the install process, are available to you subsequently - Debian's installer is just a script which plays through all the tools in approximately the right order.
When you get to the hardcore-looking bit which asks you abstruse questions about
kernel modules, you can probably just ignore the whole thing, at least for now.
They're all about exotic hardware of various kinds. (BTW, this beast is called
modconf and it can be useful. It's much friendlier with a custom
kernel; the default one has modules available for everything under the sun,
hence the huge list of options. With a custom kernel it only gives you the options
for the more limited list of modules you decided to compile.)
Murphy's law of ISA: ISA is nasty, and PnP won't. Ever. Seriously, for generic stuff like network cards, you will spend more in time attempting to bring the wretched thing up than it would cost you in money to bin it and get a PCI version instead. If you're stuck with ISA for some reason, make sure the card is non-PnP. Most ISA cards can be persuaded into non-PnP mode via some kind of setup program, usually DOS-based. Good luck.
Make friends with dselect; this takes a little doing but is essential.
The other killer spell is dpkg-reconfigure <packagename>,
which allows you to reconfigure and administer just about anything. (The trick is to
get the right package name.)
Even on a production system it can be helpful to have tasksel install
the C and python development systems, since they're needed to make various useful
tools work. (This is a security risk, use with caution.)
As well as the base installation, have dselect install the following as well:
unzip vim eject oldlibs/libstdc++* bzip2 libncurses5-dev. If you have a
USB mouse, get hotplug as well.
A certain amout of NFS stuff gets installed by default, which if you're like me
you don't want. Uninstall the following packages:
statd openssh nfs portmap. Leave bind9-host alone;
it looks suspicious but is harmless.
You tend to get given exim and inetd whether you want
them or not. If you don't want them, delete the startup symlinks in
/etc/rc2.d
On the subject of init scripts: in Debian the done thing is just to delete the
/etc/rcX.d symlinks to services you don't want, in the
old-fashioned way. (Some other distros have links to everything+dog, but use
flags in the config files to selectively enable or disable the corresponding
scripts.). update-rc.d is a script which does all the levels
at once, but nothing else; feel free to do the job by hand if you prefer.
The default runlevel in Debian is 2.
X marks the blot
If you ask tasksel for X windowing, and you're running Woody, then it pulls a nasty on you. Specifically, it hands you the version of XFree 4 which comes with Woody, which by its own admission is a mess. Large swathes of inoffensive hardware are broken by it - XFree 4 is a more-or-less a ground-up rebuild, and many drivers simply hadn't been ported when that version was released.
You've got two choices: one, upgrade to "testing" (see below); two, downgrade to XFree 3.3.6, which comes with. I eventually went for option one; with hindsight, it might've been better to go with option two. Oh well.
See section 9.4 of debian ref. Key survival commands:
dpkg-reconfigure xserver-common then
dpkg-reconfigure xserver-xfree86.
NB. even now, some basic cards don't do 24-bit colour. Specifically, my generic S3-Trio64 doesn't, as I found out the hard way. If you're running a basic card, stick to 16-bit.
NB. for UK users: your keyboard is almost certainly 102 or 105 key (depending on whether it has the extra Logo / menu keys, which most gamers take a screwdriver to shortly after purchase :-). It's not a 101-key, like the US one. It's suprisingly difficult to count the number of keys on a keyboard without making off-by-one errors. If you want to verify this, split the keys up by area, count the keys in each and then sum: I suggest F-Key row, each of the 4 rows of the main alpha area (careful about keys which span multiple rows), the cursor block, and finally the numeric keypad. Country code is GB, not UK!
USB mice are now easy, provided you're using kernel 2.4. See section 3.3.2 of
Debian reference. Protocol is IMPS/2 (assuming you've got a mouse with a scrollwheel).
Port is /dev/input/mice. I hadn't met that one before either.
Basic scrollwheel mice are also now easy; the config tool does it for you. About time too! If you have a more sophisticated mouse, you might find the separate guide to The Logitech MX-500 mouse in Linux useful.
All the critical X stuff claims a dependency on XDM. This is the thing which gives
you a graphical login. It's also the thing which makes your machine unusable if your
X configuration is hosed, which is why I consider it harmful. It's too much effort
not to install it, so let it install and then remove its symlinks from /etc/rc2.d.
To be fair, the Debian version seems to be better than many others I've encountered
at detecting a hosed X configuration and failing back to text mode.
System Administration
Adding users: adduser. Presumably there's an addgroup
as well, although I haven't tried. Interestingly, each new user now gets an
eponymous group of their own, as well.
Other system admin tasks are mostly handled by a combination of modconf
for adding new hardware, and dpkg-reconfigure for the software side.
Debian doesn't really have a centralised system-admin ubertool.
Upgrading to Testing
Debian's "stable" distribution is tested thoroughly, and over a period, before it gets given the title. However, one person's "mature" is another's "obsolescent", so you may well wish to upgrade. (I decided to upgrade in order to obtain a functional XFree4.)
Successive Debian releases have fixed codenames (e.g. 3.0 is "Woody") but the important status information is conferred by one of three possible aliases, which migrate from release to release over a period. "Stable" is the current mature release, which is currently Woody. "Testing" is the release in progress; strictly its a beta but they're careful to ensure that nothing in there is too buggy. Finally, "Unstable" is bleeding-edge and is not recommended unless you like living in Interesting Times.
Debian's packaging system is sophisticated, and I don't pretend to understand it
entirely; in particular, they have a "pinning" system which allows you to selectively
track packages, and which I haven't quite got the hang of yet. However, adding the
following line to /etc/apt/sources.list seemed to do the trick:
deb ftp://ftp.uk.debian.org/debian testing main
The clearest explanation of the format of the above seems to be
man sources.list .
Java
Our stuff is all written in Java, and requires J2RE 1.4.1, so we usually have to
install this manually. The gotcha is thatt the Java font manager requires a specific
version of libstdc++, and only later versions are installed by default.
This is where the use of oldlibs comes in - see
Basic Installation.
Appendix: Which Filesystem?
There are now a wide variety of filesystem types out there, which have various properties. Here's my take on a few of them.
Ext2: The old workhorse. It has some structural issues which most people won't come across - they only kick in when you do something unkind, like putting 50,000 1-byte files in the same directory - and one serious weakness. That weakness is that, if it's not unmounted properly, it can end up on an inconsistent internal state which the recovery tool can't fix, and at that point you either need an expensive data-recovery expert or a new installation. (This is what killed my previous installation, and started a week-long chain of events which ended up with this document.) The other problem is that, with the very large filesystems you get with modern, high-capacity hard disks, periodic filesystem checking (required even if you don't get any events which force you to reset the machine without unmounting) becomes prohibitively long-winded.
Ext3: retrofits "journalling" to ext2. Journalling is a technique whereby, provided the journal's active, metadata in transit (metadata is the information the filesystem uses to find your stuff) is first copied into a special "journal" area. and only then propagated onto the disk. The practical upshot of this is that, no matter where in the process the system is when it takes a hit (e.g. transient blackouts, a local speciality) it can recover its metadata and so ensure that your filesystem stays alive. (NB. This does not guarantee that the data itself won't be garbage, only that it will be readable garbage.) It also doesn't need the lengthy consistency checking that ext2 requires.
Ext3 also provides data journalling: this extends the protection afforded to the metadata to your data, offering extra security. (However, even this is not a guarantee that your data will not be corrupted by an event; very large writes are not atomic even under journalling and so may end-up half-written. It helps, but not nearly as much as a UPS does.) Finally, ext3 is fully backwards-compatible with ext2, can be retrofitted to an existing ext2 filesystem without affecting it, and can be read by by ext2-only code (e.g. rescue kernels).
ReiserFS: non-compatible new kid on the block. Only provides metadata journalling (so far) but has significant advantages. Firstly, it doesn't mind filesystem setups which tend to hurt ext2 (e.g. very large numbers of very small files). Secondly it allows extensibility (although to date no such extensions have shown up). Finally, ReiserFS with metadata journalling is mildly faster than ext2 without, and a lot faster than ext3 with metadata journalling. Ext3 with data journalling is even slower.
Recommendation: if you've got large ext2 filesystems which you don't want to rebuild, upgrade them to ext3. If you've got a free choice, go with ReiserFS. Ext2's OK for a small boot partition if you've got that setup, but I wouldn't recommend it any longer for other uses.
Buy a UPS. The smaller ones are cheap, and can save you a great deal of pain.
Final wrinkle: the author of shred(1) (secure deletion) says that
journalling filesystems make this tool ineffective. I'm not an expert, but I'd
suspect that ext3 might not suffer from this caveat, since the actual filesystem is
still ext2.
One technique I'd suspect would still work even on a journalling filesystem: at the end of a session, create a large empty "bloat file", which occupies all the empty space on the filesystem, and then shred it. This floods huge amounts of wipage through the journal (thus cleaning it severely) and also ensures that any unwiped data which remained due to the filesystem electing to move a secret file while wiping it, will have been overwritten by the bloat file and thus wiped.
