Default User wrote:
On Fri, 2007-04-20 at 19:42 -0400, Douglas Allan Tutty wrote:On Fri, Apr 20, 2007 at 10:37:35AM -0500, Default User wrote:Hi! After installing fresh Etch with encrypted lvm (all except /boot), per non-expert install, I am reconsidering whether lvm is a good idea. Itworks fine - now - but what if it stops working?
8< snip
I really do like the ability to resize my partitions as needed (the layout that seemed fine upon install can really look stupid 6 monthslater). But not at the price of my data.And does encryption of lvm partitions unnecessarily complicate matters, especially recovery? Would just an encrypted swap partition only bebetter?
8< snip
a fresh install is a rare opportunity to do things right, so I try notto squander it.
Interestingly I've been thinking about this recently as I migrate my home servers, firewalls, etc.. to Etch. It occurred to me that since one of the main reasons we partition harddrives on a server is so that a problem causing one partition to fill, won't necessarily cause the whole system crash, given this, what would be really cool would be to partition the system at install time using a slightly mean, but granular, best guess layout [0] so things should fit in their partitions without too much wasted space, then configure each partition as one mount point on one logical volume consisting of one physical volume [1] and then partition up the rest of the drive in 1GB chunks that sit in a pool of unused logical volumes so they can be assigned to any mount point when needed, preferably automatically. You could have the system email you whenever a gig is added to a mount point, so when you get attacked, mail bombed or have a program crash in a noisy log filling way, the system doesn't go down, it keeps tacking chunks on to the back of the relevant logical volume and emailing/SMSing you each time, you could then ssh in, figure out what's wrong, fix it, and then, assuming you used a file system that can be contracted while online, [3] clear the relevant logs, mail, whatever, shrink the file system and return the now unused chunks to the pool.
I don't know if this has been done already, but it could all be done today with shell scripts, [4] which would make it easy to have rules about how much any one partition can grow, and extend it so if you've got an email address that collects spam it could purge that, or automatically purge the syslog of dhclient messages, [5] run logrotate or whatever.
One hassle is it would be a PITA to do all that partitioning by hand, it would be much better handled by a script at install time.
[0] meaning have a lot of partitions of appropriate sizes, /var, /var/tmp, /var/mail, /var/log, /var/cache... [1] at least most of them, not /boot or any others you're very confident won't grow beyond the initial partition size [3] it would be nice to have one that doesn't require 30% free space to reduce fragmentation but... [4] although we could use some loopy script running df to monitor mount point utilization, there must already be some much more efficient daemon for monitoring and emailing which could be made to run a shell script
[5] my damn ADSL router renews my IP every 30 seconds -- Garrr, do your bit for global warming, become a pirate, you can "borrow" my copy of Windows 95 if you want.