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 |