You're setting up a new machine. The smallest hard drive you could find is 40GB. Your home partition and all the other shared files are already on the file server in your closet. What are you going to do with all that space?
One thing you can do with all of the extra disk space on a client machine is try out lots of different Linux distributions. It's fun, it's easy, it proves there's a world beyond Red Hat. Here are some hints.
Partitioning is pretty simple: just chop the disk up into pieces of about 5GB or so, as many as will fit (and you think you're going to need). Make a couple of swap partitions, too. The old `double your RAM' rule of thumb is still pretty good, but make sure there's at least 1GB if you're planning to play with a source-based distro like Gentoo.
/v.
A boot partition isn't usually necessary these days (unless you have an old motherboard with a BIOS that can't read past cylinder 1024), and it could complicate things, but it doesn't hurt either. Put it at the beginning of the disk, and make it something like 100-200MB. (More like 500Mb-1Gb if you want to put a mini/rescue distro on it. I have some additional thoughts on the boot partition below.)
If there's likely to be a Windows partition as well, bear in mind that Windows likes to boot from partition 1. What I do in this case is the following:
| 1 | dos |
starts after partion 2! This is legal -- don't worry about
it. Windows is happy, lilo is happy, you're happy.
|
|---|---|---|
| 2 | /boot |
starts in the first available cylinder, at the beginning of the disk. |
| 3 | extended | this is where you put all your Linux stuff. |
| 4 | unused | some BIOSs may want it for a hybernation partition or other purposes. Or you could just leave it alone. |
Note that you'll probably have to use fdisk(8) for this; any
partitioning program with a GUI front-end probably won't offer you the
choice of starting partition 1 after partition 2 on the disk.
Linux allows filesystems to have labels. I usually make them the same as, or closely related to, the corresponding mount points, which makes it easy to see where stuff belongs.
I usually give partitions single-letter names and mount them under the
root (not under /mnt), e.g., at /u,
/v, /w, /x, /y,
/z. The DOS partition, if any, is called /c.
If I only have one big extra partition (common in servers, for example),
I'll call it /v because it's likely to be mounted on
/var or symlinked from /var.
Note that for any given installation, one of these mount points will be
missing because it's mounted on /. That helps you identify
your root partition: just look for the missing letter.
Note, too, that it's rare for a Linux installer to let you define your
filesystem labels -- what you have to do is re-label the partitions after
the first install, change /etc/fstab, and reboot.
The big advantage of using labels is that you can move the disk to another system, or add another, and everything still works.
Finally, label each partition in a human-readable way by using
touch(1) to make an empty file in the root whose name is the
distribution's name and version. For example, /RH7.3 or
/DEBIAN-WOODY. Now, you can find out what's on your disk
with the following one-liner:
[steve 1013] ls /[A-Z]* /?/[A-Z]* /RH7.3 /w/DEBIAN /y/RH8.0
(From this we can conclude that there are three distributions on this
drive and that the one we're currently running, RedHat 7.3, is mounted on
a partition with the label /x.)
If your disk is already partitioned as one huge partition plus swap, and
contains a distro you want to keep, use GNU parted
(partition editor) to bust up the big partition. It will do this without
losing any data (though I'd recommend a backup anyway), and unlike most
earlier tools like fdisk doesn't require that DOS partitions
be defragmented.
There are only a few problems with parted:
grub does it.
parted, lilo, and a Debian
installer.
ext3 partitions.
Every distribution you install is going to want to install its own boot loader. Let it -- in most if not all cases you'll be given the option to put it in the boot sector of its root partition. Then you can just chain to it.
Of course, the first install you do should mount the boot
partition, if you have one, on /boot. Install
GNU GRUB.
You only have to install it once; after that you can just edit its menu
(usually /boot/grub/menu.lst or
/boot/grub/grub.conf) to add new partitions or kernels.
Many seasoned system administrators prefer lilo as a
bootloader for servers, because you can set it up from the command line to
boot just once from an alternative kernel or partition, and to reboot on a
kernel panic. This makes it ideal for use on systems you're not
physically sitting in front of. GRUB is bettter for workstations, and
it's ideal for this kind of multiple-distro experimentation
because if you get its configuration file wrong, you can actually edit it
by hand during the boot process.
Here's how you chain-load another partition: just add something like the
following incantation to /boot/grub/grub.conf for each
partition you want to boot from:
title chain /dev/hda5 DeMuDi
rootnoverify (hd0,4)
chainloader +1
Note that GRUB numbers disks and partitions from zero, not a
(disks) or 1 (partitions) the way Linux does, so
hda5 becomes (hd0,4) in GRUB. Also,
all hard disks, including SCSI disks, are called
"hd". The file /boot/grub/device.map contains
the mapping between GRUB devices and Linux devices, and can be handy for
figuring out where your partitions are.
My next project is to identify a suitable mini-distribution to go on my boot partitions. In order to do this I'll have to clean out the original install, typically RedHat on my systems, by copying the original boot partition to an ordinary directory, and doing another install of GRUB into the boot track of the main partition. Next time I'll probably just start out that way.
After each distribution is comfortably installed, there are a couple of things you have to do before it's completely happy:
/etc/passwd, /etc/group, and the shadow files
if you have them. Skip this step if you're using NIS.
/etc/fstab
(or symlink them from your first install, if you don't have a fileserver
and they're on the same machine).
/etc/ssh from the first install.
This ensures that your host has the same host keys no matter which
distro it's running. Very important: ssh will complain
that "somebody could be doing something nasty" if a host's key
changes.
/etc/resolv.conf.
sendmail.cf, httpd.conf (wherever it
happens to be), XF86Config, the printer configuration
files, and so on.
The nice thing about playing this game is that the things that really
matter, like /home and /usr/local, stay in one
place, usually on your fileserver. How you back them up, therefore,
doesn't change no matter what distro you're running on your workstation.
The only thing you really have to back up on a workstation is
/etc. If you're using tar or rsync
(as most of us do) it's best to back up each distro's /etc
separately.
You may also have shared parts of /var to back up, in
particular /var/spool/mail and wherever your distro keeps web
documents (usually /var/www these days, but older distros put
it in /home/httpd). The simple approach is to put everything
on the fileserver -- e.g. under /usr/local --and symlink or
mount directories wherever each distro expects them. For websites you can
use the DocumentRoot directive to point the server directly
at the appropriate directory.
Another good thing to do is to collect all of the config files that you
customize heavily into one or two directories, and back those up.
This also makes it a bit easier to keep them under CVS version control.
Make sure that only root and perhaps users in your system
administration group can modify them.