bascule wrote:
>
> perhaps you are confusing advice (often seen in this list) to have a
> /boot partition which need only be very small -20mb i think but an
> expert will have a better idea of ideal size,
> a seperate /usr partion will keep / down, but unless on a seperate drive
> total space used remains the same,
> newbie mailing list archive is here (as pointed out to me in a different
> post!):
> http://www.mail-archive.com/newbie@linux-mandrake.com
>
> Yuri K wrote:
> >
> > Could someone point me to The Ultimate Guide on HDD partitioning, please?
> >
> > My point: I come across notions to make root partition as small as possible,
> > 80-120 Mb being as more than generous amount, etc.
> > yet when I try to install I get messages that my root partition is too small
> > for the packages i chose.
> >
> > I understand, that this topic is an eternal one, but I need to crarify it.
Bascule -- you're correct about the small /boot partition. A nice
10-20M partition can hold quite a few kernels for playing around with.
Yuri -- the one thing that it sounds like the FAQs left out concerning
the small root partition is the need to create partitions for all of the
large portions that hang off root (/usr, /var, /tmp, /opt, etc, etc).
The idea of a small root partition is that in the case of a crash, you
have a very small chance of trashing vital system binaries (those things
in /bin, /lib, and /sbin). The advantage is that since these files
don't change very often, you can mount that partition as read-only and
completely bypass the need to fsck them when the system is brought back
up. Indeed, by mounting / read-only, you can also reduce the
possibilities of unnoticed hacker activity -- they'll need to remount
the drive read-write in order to compromise system binaries. That's
something that will be noticable to you in the logs. The last thing
that it provides is extra protection against "fast fingers". I don't
know if it's happened to you, but on more than one occasion I've typed
'rm *' instead of 'rm *~' and trashed a large directory (in my case,
/etc. Bad choice, let me tell you!)
So, if you're going to use the small root idea, you'll need to do a bit
more partitioning on the drive to accomodate it. Here's what I'd try:
/boot 10M
/ 100M
/usr 2G
/var 500M
/tmp 500M
/home 2G
/opt 2G
/root 500M
Adjust the sizes appropriately for the things that you'll be doing with
the system.
With a partitioning scheme like this, you could mount /boot, /, /usr,
and /opt as read-only and protect the items that are installed there.
Leave /var, /home, and /tmp as read-write because that's where
applications write their temporary data.
Now, doing something like this has its tradeoffs:
Pro:
Increased protection against script-kiddies and "fast fingers"
Reduced likelihood of system corruption in the event of a crash
Reduced fsck times after a crash
Con:
Makes quick administration more difficult because you'll have to
remount a read-only partition as read-write in order to make
changes
Makes system installation and upgrade a bit more taxing because
of the need to remember all those partitions and their use.
For my home system, I don't go to any of these lengths. I have nothing
valuable enough that I can't afford to lose it to a reinstall. I have
nothing secret enough that I have to worry about script-kiddies
destroying it. I have a firewall secure enough that I don't worry about
script-kiddies. :)
For my work system, all of those ideas are put to use along with adding
immutable flags to system binaries and configuration files (one more
thing for a script-kiddie to have to figure out), mounting web content
from a read-only media, and tripwire checking nightly.
Hope this information helps,
--
Steve Philp, MCSE/MCP+I
Network Administrator
Advance Packaging Corporation
[EMAIL PROTECTED]
