[sf-lug] the latest on the servepath colo story

[Rick Moen]

Jim Stockford asked the classic partitioning question:

>     QUESTION 1--what are good ideas for partitioning?
>   * Not /root, /, and swap, right?
>   * How about /root, /, /var/log, /var/www, swap, /usr/local,
> /opt, /stash  (note swap in the middle) ???
>    * Other???

(Swap in the middle is quite astute.  Less seek time, on average.)

People new to the Unixes typically want to punt and keep everything
simple:  That's actually an excellent place to start!  Like (assuming
IDE):

/dev/hda1   swap   size = 2x RAM, or whatever
/dev/hda2   /      the rest

That'll serve you well until you're more seasoned, and start to have
opinions -- along with being able to easily move around data if you've
screwed up and made a partition too small.[1]  It serves less well on
multiuser boxes.


>     i got a job recently on a box where the hard drive
> went down--/boot, /, swap.
>     It was a production box, and the owner was dying
> to get his scripts and data back. it would have been
> a lot easier if he'd had more partitions--then whichever
> went bad, the others would be okay (except in the
> case of total failure, which is pretty rare, yes?).

It depends on the failure mode.  If it was HD hardware failure, then
probably you have to revert to backup.  If it was misbehaved software
causing filesystem damage, then some more-detailed partitioning might
have either saved him, or at least made recovery easier, depending.

As Asheesh points out, defensive partitioning should not be confused
with redundancy (e.g., a RAID1 pair) or backup.[2]

>    and thus i plead the case for more, smaller partitions
> rather than fewer bigger parts.

The rest of this message is strictly for the curious.

Let's consider some of the problems people solve using separare
filesystems.  Key concepts:  shareable vs. non-shareable contents, 
static vs. variable contents, mount options, FHS = Filesystem Hierarchy
Standard.


Problem:  Root filesystem once hit 100%, which then was a real bear to
recover from.

Solution:  Separate non-root filesystems for portions of the tree whose
contents are variable as opposed to static:  /var, /home, /usr/local, 
/tmp, /opt (which might be a symlink to /usr/local/opt).


Problem:  Risk of filesystem corruption, and need to recover from same.

Solution:  Same as above, but also put /usr (which tends to be static)
on its own filesystem.   Recovery tools will be on root filesystem in
/bin, /usr/bin or /sbin with libs in /lib.


Problem:  Need to keep portions of the tree with network-shareable files
(those usefully stored on one host and used on others) separate from
those that are are non-shareable.  This applies mostly to NFS-based
or similar networks.

Solution:  /usr, /opt, /var/mail, and /var/spool/news (if present)
should be away from the root filesystem, which is not shareable.


Problem:  Fumblefingered sysadmin can accidentally blow away big file
collections with root account usage.

Solution:  Good backups -- but also keeping some portions of the tree
with static content normally mounted read-only, to make mishaps less
likely.  Mostly, this means /usr, but could also be used on /boot if
it's separate.


Problem:   One-size-fits-all journaled filesystem (e.g., ext3) yields
suboptimal performance in directories with throwaway contents, and 
adds unjustifiable complexity to static filesystems that will be
normally mounted read-only anyway.

Solution:  Make /tmp and /usr be of type ext2 (faster, less complex),
rather than ext3.  Also, you don't need the "atime" time stamp in /var, 
and so can save overhead by not writing it.


Problem:  In the event of partial security compromise, it couldn't hurt
to make it more difficult for automated attack scripts to do their work.

Solution:  Remove from mount options the support for types of files that 
have no legitimately existence in various places:  device files in
everywhere but /dev; SUID files in /boot, /var (except maybe /var/lib),
/tmp, and /home; executable files in /boot, and so on.  (Be cautious
and pay attention:  Once, I removed the exec flag from /tmp, and it took
a while to realise that packages' preinst and postinst scripts need to
be able to run, there.)



More of this is covered in:
http://www.pathname.com/fhs/
http://twiki.iwethey.org/Main/NixPartitioning

Both are well worth reading.

[1] "Copying Directory Trees" on http://linuxmafia.com/kb/Admin/
[2] "Backup Fallacies / Pitfalls" on http://linuxmafia.com/kb/Admin/