Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Partitioning strategy...?
Date: Sat, 26 Nov 2011 21:00:05
Message-Id: 20111126225853.15955a40@rohan.example.com
In Reply to: Re: [gentoo-user] Partitioning strategy...? by Pandu Poluan
1 On Sun, 27 Nov 2011 01:42:40 +0700
2 Pandu Poluan <pandu@××××××.info> wrote:
3
4 > On Nov 26, 2011 2:57 PM, "Alan McKinnon" <alan.mckinnon@×××××.com>
5 > wrote:
6 > >
7 > > On Fri, 25 Nov 2011 20:53:17 +0700
8 > > Pandu Poluan <pandu@××××××.info> wrote:
9 > >
10 > > > I want to build a Gentoo server box whose structure is
11 > > > highly-partitioned, like this:
12 > >
13 > > partition setups are like lovers - highly variable. And the one that
14 > > suits you will suit almost no-one else.
15 > >
16 >
17 > Careful, you've just raised some unholy memories there ;-)
18 >
19 > > Many of the recommendations you find on-line come from an earlier
20 > > time and the reason they got going is no longer valid for the most
21 > > part. So do take care to evaluate the real reason why you are doing
22 > > something.
23 > >
24 > > Valid reasons included:
25 > >
26 > > You want to unmount a dir structure (/boot).
27 > > The fs type for a partition is different from that fs it mounts to
28 > > (often /var/log but these days most often used with tmpfs).
29 > > You need to mount an fs with different mount options to the fs it
30 > > mounts onto (/home noexec on multi-user setups for example)
31 > >
32 > > The way to do this is not to search Google for recommendations, as
33 > > there is no such valid thing, but to figure out for yourself why you
34 > > want a mountpoint, calculate how much space *you* need, then do it.
35 >
36 > Indeed, that's what I originally asked: the numbers.
37 >
38 > > Read other's experiences who use similar software as you by all
39 > > means, but that will be mere hints.
40 > >
41 > > My own thoughts:
42 > >
43 > > - I can't find a good reason anymore to have a local /usr separate.
44 > > It's always mounted on my systems, even in maintenance mode (there's
45 > > always at least one decent tool that the distro decided to put
46 > > in /usr/sbin)
47 > >
48 >
49 > Mounting it ro not a good idea?
50
51 Personally, I find an ro /usr a gigantic PITA. I'm the kind of guy that
52 will forget to remount it before emerge too many times, then write a
53 wrapper script around emerge. Thus effectively undoing the entire
54 benefot of having it ro at all :-)
55
56 I also remember the the brain-dead rpm maintainer from RedHat. rpm
57 would happily update it's database then bail out halfway through the
58 install() phase if /usr was mounted ro, leaving the database
59 irreversibly corrupt. For three years this person refused to consider
60 this a bug even though rpm could easily detect the condition in advance
61 every single time (i.e. a classic case of verify you *can* write
62 something before writing it).
63
64 Such stories make me fearful of a local /usr mounted ro. Your needs may
65 differ.
66
67 A remote /usr mounted over NFS remotely as a terminal server - that's a
68 different story altogether.
69
70
71 >
72 > > - /tmp is only useful on it's own if it's a tmpfs. Mine hasn't ever
73 > > filled up anywhere (despite best efforts of users). tmpfs is
74 > > general is an awesome idea.
75 > >
76 >
77 > Noted.
78 >
79 > > - Keeping data and code separate is always a good idea. But only a
80 > > few things in /var are critical like /var/log and /var/<database>.
81 > > Everything else is usually tiny and can safely live on /
82 > >
83 >
84 > Except /var/tmp, which can grow to epic proportions :-)
85
86 As a sysadmin of a real server I would expect no less from you than a
87 Nagios instance that mails you before the point of epicness :-)
88
89 > > - /boot is traditionally separate partly because long long long ago
90 > > BIOSs couldn't read past 1024 cylinders which borked lilo. This is
91 > > no longer true.
92 > >
93 >
94 > I'm a bit scared that a buggy program or script borked the kernels I
95 > put there...
96 >
97 > Thus also the reason to mount /usr ro.
98
99 Following on from above, consider this:
100
101 The only thing you will allow to write to /usr is emerge, right? And
102 like most folks you don't check every bit of what it does?
103
104 So the buggy scripts you are in fear of will be ebuilds. And yet, you
105 will always allow then to be installed without prior checks.
106
107 So why do you plan to have safeguards when you know in advance you
108 will always suspend them?
109
110 > And if I can make /bin /sbin /etc all ro, I want to make them ro,
111 > too...
112 >
113 > Am I being too paranoid?
114
115 Yes.
116
117 You are causing yourself an insane amount of work for no good reason
118 and it will drive you beserk in a week. Or you will implement
119 workarounds.
120
121 Normally only root can write to those areas. Only root can remount
122 them. If a user gets into a position where they can overwrite things,
123 you have already lost every last measure of protection and the game is
124 already over.
125
126 What you need is a proper backup strategy with restores that actually
127 work.
128
129
130
131 --
132 Alan McKinnnon
133 alan.mckinnon@×××××.com