On Sun, 27 Nov 2011 01:42:40 +0700 Pandu Poluan <pa...@poluan.info> wrote:
> On Nov 26, 2011 2:57 PM, "Alan McKinnon" <alan.mckin...@gmail.com> > wrote: > > > > On Fri, 25 Nov 2011 20:53:17 +0700 > > Pandu Poluan <pa...@poluan.info> wrote: > > > > > I want to build a Gentoo server box whose structure is > > > highly-partitioned, like this: > > > > partition setups are like lovers - highly variable. And the one that > > suits you will suit almost no-one else. > > > > Careful, you've just raised some unholy memories there ;-) > > > Many of the recommendations you find on-line come from an earlier > > time and the reason they got going is no longer valid for the most > > part. So do take care to evaluate the real reason why you are doing > > something. > > > > Valid reasons included: > > > > You want to unmount a dir structure (/boot). > > The fs type for a partition is different from that fs it mounts to > > (often /var/log but these days most often used with tmpfs). > > You need to mount an fs with different mount options to the fs it > > mounts onto (/home noexec on multi-user setups for example) > > > > The way to do this is not to search Google for recommendations, as > > there is no such valid thing, but to figure out for yourself why you > > want a mountpoint, calculate how much space *you* need, then do it. > > Indeed, that's what I originally asked: the numbers. > > > Read other's experiences who use similar software as you by all > > means, but that will be mere hints. > > > > My own thoughts: > > > > - I can't find a good reason anymore to have a local /usr separate. > > It's always mounted on my systems, even in maintenance mode (there's > > always at least one decent tool that the distro decided to put > > in /usr/sbin) > > > > Mounting it ro not a good idea? Personally, I find an ro /usr a gigantic PITA. I'm the kind of guy that will forget to remount it before emerge too many times, then write a wrapper script around emerge. Thus effectively undoing the entire benefot of having it ro at all :-) I also remember the the brain-dead rpm maintainer from RedHat. rpm would happily update it's database then bail out halfway through the install() phase if /usr was mounted ro, leaving the database irreversibly corrupt. For three years this person refused to consider this a bug even though rpm could easily detect the condition in advance every single time (i.e. a classic case of verify you *can* write something before writing it). Such stories make me fearful of a local /usr mounted ro. Your needs may differ. A remote /usr mounted over NFS remotely as a terminal server - that's a different story altogether. > > > - /tmp is only useful on it's own if it's a tmpfs. Mine hasn't ever > > filled up anywhere (despite best efforts of users). tmpfs is > > general is an awesome idea. > > > > Noted. > > > - Keeping data and code separate is always a good idea. But only a > > few things in /var are critical like /var/log and /var/<database>. > > Everything else is usually tiny and can safely live on / > > > > Except /var/tmp, which can grow to epic proportions :-) As a sysadmin of a real server I would expect no less from you than a Nagios instance that mails you before the point of epicness :-) > > - /boot is traditionally separate partly because long long long ago > > BIOSs couldn't read past 1024 cylinders which borked lilo. This is > > no longer true. > > > > I'm a bit scared that a buggy program or script borked the kernels I > put there... > > Thus also the reason to mount /usr ro. Following on from above, consider this: The only thing you will allow to write to /usr is emerge, right? And like most folks you don't check every bit of what it does? So the buggy scripts you are in fear of will be ebuilds. And yet, you will always allow then to be installed without prior checks. So why do you plan to have safeguards when you know in advance you will always suspend them? > And if I can make /bin /sbin /etc all ro, I want to make them ro, > too... > > Am I being too paranoid? Yes. You are causing yourself an insane amount of work for no good reason and it will drive you beserk in a week. Or you will implement workarounds. Normally only root can write to those areas. Only root can remount them. If a user gets into a position where they can overwrite things, you have already lost every last measure of protection and the game is already over. What you need is a proper backup strategy with restores that actually work. -- Alan McKinnnon alan.mckin...@gmail.com
