[conspire] Parititioning revisited briefly

[jim]

I love it, thanks lots! More, more.... 


On Fri, 2010-10-15 at 18:33 -0700, Rick Moen wrote:
> If you're bored from hearing about partitioning, you're out of luck,
> because I had in mind to post tidbits about it until I run out of
> inspiration.  Here's that server partition scheme, again:
> 
> 
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> 
> ## sda is (obviously) the boot drive.  73 GB SCSI.
> /dev/sda1       /boot           ext2    defaults        0       2
> /dev/sda5       none            swap    sw              0       0
> /dev/sda6       /var            ext2    noatime,nodev,nosuid 0       2
> /dev/sda7       /               ext3    defaults,errors=remount-ro 0       1
> /dev/sda8       /recovery       ext3    defaults        0       2
> /dev/sda9       /usr            ext2    nodev,ro        0       2
> 
> ## sdb and sdc are RAID1 mirrored, except for swap.  Each is 18 GB SCSI.
> /dev/md0        /var/www        ext3    nodev,nosuid    0       2   #sdb5,sdc5
> /dev/md1        /var/lib        ext3    nodev           0       2   #sdb6,sdc6
> /dev/md2        /var/spool      ext3    defaults        0       2   #sdb7,sdc7
> /dev/sdb8       none            swap    sw              0       0
> /dev/sdc8       none            swap    sw              0       0
> /dev/md3        /home           ext3    defaults        0       2   #sdb9,sbc9
> /dev/md4        /usr/local      ext3    defaults        0       2   #sdb10,sdc10
> 
> 
> This time, a few words about choice of filesystem type, mount flags and
> such.  Let's start with /var.
> 
> First thing to note about /var is that I've carefully moved _off_ of the 
> /var partition per se all the subtrees that contain indispensible
> things:
> 
> /var/www   System HTML and ftp trees
> /var/lib   all data files for Mailman, MySQL, some others
> /var/spool System SMTP spools, NNTP spools, SpamAssassin files
> 
> Everything that remains is system-built dynamic files that come and go,
> that you could blow away and would have minimal trouble from doing so.
> _Therefore_, the first thing is that we want flat-out maximal
> performance even at the expense of data protection, and there's nothing
> better for that than good old ext2 (with no journal).  
> 
> You'll notice that /boot is likewise ext2.  I got into this habit during
> the long period of reliance on the lilo bootloader.  One distinctive
> thing about lilo is that the installed bootloader, at startup time, finds 
> the system map, boot kernel, initial RAMdisk, and root filesystem first
> sector by memorising their physical location (cylinder, head, sector,
> etc.), _not_ by memorising their pathspecs within filesystems.
> Therefore, lilo doesn't need to mount anything to do booting, and in
> fact doesn't need to understand filesystems at all (to do booting).
> 
> Thus, when using lilo as one's bootloader, you actually almost never
> need to mount /boot at all.  The only time you need to mount that
> subtree is when _updating_ lilo data, e.g., because you just installed a
> new kernel.
> 
> Leaving /boot normally unmounted is yet another small protection against
> mishap.  Critical files in a subtree you haven't mounted are critical
> files you cannot accidentally screw up.
> 
> And since you only ever mounted /boot a few times a year for fifteen
> minutes at a time to implement new boot kernels, why waste space on a
> filesystem journal?  Thus, ext2.
> 
> As mentioned, given the reduced rationale for having a separate /boot 
> in the first place, I will be losing that filesystem in the future.
> 
> 
> There are some restrictive flags on several filesystems, as a limited
> sort of security measure:
> 
> /var      noatime,nodev,nosuid
> /usr      nodev
> /var/www  nodev,nosuid
> /var/lib  nodev
> 
> The 'noatime' flag gives a filesystem a very non-trivial performance
> gain, where you can get away with it, by eschewing the overhead of
> continually updating the atime timestamp every time the file is 
> accessed _including just for reads_.  ('File', here, includes 
> directories.)  Some software relies on the atime timestamp, and 
> disabling it (as above ) is consider a non-standards-compliant mode
> of operation.  However, if no software requires atime for a subtree,
> the gains are compelling.
> 
> (Note:  As of kernel version 2.6.30, Linux's default behaviour is 
> something called 'relatime' = relative atime, invented by Valerie
> Aurora, that greatly reduces atime overhead without software problems.
> See:  http://valhenson.livejournal.com/36519.html )
> 
> 
> /var's nodev and nosuid are very modest security measures of a sort.
> That is, given that there's no conceivable legitimate purpose for
> special device files (such as /dev/sda) within /var, why permit them to
> be valid there?  Thus, nodev.  Given that there's no conceivable
> legitimate purpose for SUID files within /var, why permit them to
> be valid there?  Thus, nosuid.
> 
> A not-especially-sophisticated attack tool, say, a network worm, that
> you or one of your users accidentally executed on your system, might be
> foiled by an unexpected inability to have a special device file or a
> SUID executable, functional within /var.  An astute human attacker with
> root authority, or a sophisticated attack tool with root authority,
> would easily defeat that safeguard by remounting /var without the flag,
> so it's a modest measure.
> 
> The other three filesystems' similar flags are of the same sort.
> Note that one must be careful not to shoot legitimate software in the
> foot, in planning these flags.  Notice, for example, that /var/lib lacks
> the 'nosuid' mount flag.  Doubtless, this is because I tried that and
> noticed something that broke.  (Oops.)  But it's difficult to know until
> you try.
> 
> 
> 
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>