[aklug] Re: What should I consider before doing an install?

On Wed, June 29, 2011 10:11 am, Arthur Corliss wrote:
> If you're going to do initrd and take advantage of root in LVM, etc., you'll
> want a separate /boot partition. If you're going host any exposed network
> services you'll want a separate /tmp partition mounted noexec, nodev.
> Daemons shouldn't be able to run your system out of disk space, so /var
> should be a separate partition. At the same time, misbehaving daemons
> shouldn't be able to run your syslogger out of space, either, so you should
> consider having a separate /var/log as well. Filesystem corruption, while
> rare, can still happen, so you should have a separate /usr and/or /opt to
> keep your precious config data in /etc isolated from the parts of the system
> more likely to change.
>
> Finally, given that remote shell access is often granted to users you should
> consider mounting /home as nosuid, nodev, along with any other LV/partition
> that doesn't need it.
>
> Sounds like a lot, right? And it would be an unmanageable nightmare unless
> you use LVM. With LVM, however, it's a cinch, and it provides a great deal
> more protection from a wider array of attack vectors.

Why is that? I understand that the benefit of LVM is being able to
move and resize filesystems. But is there something that makes the
initial setup easier with LVM than without it? And what is the greater
protection you allude to?

Also, while I understand the purpose of an initrd, it's always seemed
like more trouble than it was worth. It's an awful lot to go through
just to get the darn thing booted (and more steps to forget during an
update). If you just make sure your kernel has what it needs to run
the system, most of the reason for the initrd goes away, right?
(Except for LVM, at least.)

I prefer to avoid an initrd, though I may end up using it -- for the
technical benefits and/or just learning how it works.

--
Bryan Medsker
bryanm@acsalaska.net
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.