Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Sat, Dec 17, 2011 at 04:13:50AM +0800, Thomas Goirand wrote:
> Seems you're as much passionate about this topic as I am! :)
> At this point, I don't remotely hope to convince you, but perhaps you
> will find some of my points valid.
Likewise. :)
> On 12/17/2011 02:46 AM, Josh Triplett wrote:
> > Hence why I said "most people" (because I didn't want to imply
> > unanimity), but there's a difference between "consensus" and "complete
> > lack of dissent". In any case, note that I specifically mentioned
> > separate /usr as a special-purpose configuration, not other separate
> > partitions. I don't want to argue here that no possible reason exists
> > for separate /usr (that seems like another argument entirely, and a
> > mostly orthogonal one); I simply suggested that it represents an
> > uncommon configuration. Do you really disagree with the statement
> > that separate /usr represents an uncommon configuration?
> >
> >> On 12/16/2011 04:46 AM, Josh Triplett wrote:
> >>> Meanwhile, we don't want to steer any new users towards a setup with a
> >>> pile of different partitions, which makes their system more complex with
> >>> more potential failure modes.
> >>
> >> I hope that we are still the universal operating system,
> >> and that we don't want to force anyone to do anything.
> >> If I want to use many partitions, this is *my* call, and
> >> not everyone's business. Please don't try to force your
> >> view on partitioning to anyone.
> >
> > Nobody stops you from using as many partitions as you like. I've
> > suggested a change to the guided partitioner, which exists to make the
> > most common partition configurations easy, and to steer new Debian users
> > in the direction of configurations which will work well for them and not
> > give them too much trouble.
>
> But I do not agree with your steering, just for the sake of making it
> more easy. We shouldn't only target "most common partition
> configurations easy", there's isn't a "one solution fits all", but
> really some choice depending on your needs. Showing to our users that
> separate /usr, /var, /tmp and /home can be a good choice is also
> important to me.
That sounds like you want the Debian installer to actively advocate for
your preferred partitioning scheme, even though it doesn't represent a
common configuration.
The guided partitioner exists in large part to say "If you don't have
custom needs, we recommend this configuration". And while we might
debate the usefulness of a separate /usr back and forth, I think I can
safely say that it won't become a *recommended* configuration anytime
soon. :)
That represents the primary reason I filed this bug: to ensure that
people only end up with a separate /usr if they actively want one, not
because they saw the option in the installer and didn't know any better.
> Pushing users to do encryption would also be great. The Debian installer
> shouldn't only aim to be easy: it should do the job and do it well.
I don't think we can push encryption any more strongly than we do, short
of making it the default (and while I wish we could do that, I can see
a number of good reasons why we can't, not least of which systems that
need to boot unattended).
For the installer, "easy" represents a significant component of "do the
job and do it well". I still remember doing installs via boot-floppies.
It certainly offered quite a lot more choices. :)
> I'd be happy if we had a partionner which could do as much as we can
> with right now with partman (which is: a lot!), just more efficiently.
> In other words: I'd like to do more complicated things faster.
Sure; see below for a more detailed suggestion along these lines.
However, I also don't think that should stop us from optimizing for the
common case.
> > A configuration with everything in one partition needs no extra
> > configuration; anyone who wants such a configuration will like what the
> > guided partitioner comes up with.
>
> Of course, anyone who wants X will like X... What if I like Y?
This point went with the next one. If you want X, you'll like the
option that gives you X. If you prefer Y, it doesn't necessarily help
you to have an option for Z, any more than it helps you to have an
option for X.
> > A configuration with five separate
> > partitions seems almost impossible to provide sensible proportions for
> > that work for everyone without editing. And getting the proportions
> > wrong means people have to deal with strange and annoying cases like
> > /var filling up when /home has tons of room, or / filling up when /usr
> > has tons of room.
>
> Sometimes, you just don't care about partition sizes, you just want them
> to be there automatically (as long as there's a separate /var and /tmp...).
Only in the case where you have such a big disk that you can afford to
waste a pile of space with mostly empty partitions. Personally, when I
have a 1TB disk, I'd still like to have the ability to use 99% of that
for the contents of /home, and at the same time as long as I haven't
done so yet I'd like to have that space available for use in / or /usr
or /var or /tmp or /srv.
> But well anyway, that's a valid reason for giving *more* template
> choices and control in partman not less! :) Indeed, I'd be cool to
> select such layout, then just quickly just enter sizes on the LVM,
> without having to define types and mount points manually (which takes
> soooooo muuuuuuch time).
Personally, when I want something other than "everything in one
partition", I find that it takes more time to clean up after the guided
partitioner than to just create what I want from scratch.
I would actually advocate having a pile of convenient templates, but not
offered as part of the guided partitioner, just as an option from within
the manual partitioner. In other words, I'd love to see a menu
structure that looks like this (structure, not necessarily exact
wording):
Partition layout: [all in one] [all in one with encryption]
[custom/manual] For the first two options, just confirm the result and
proceed. For "custom/manual", open the manual partitioner, and have a
prominent option to apply a template. The template, rather than
offering a linear list of some subset of 2^N options, could actually ask
"what do you want as a separate partition: [ ] /home [ ] /tmp [ ] /var
...", and make it easy to configure the individual sizes.
That makes the most straightforward options simpler (one less question),
and makes the complex options simpler as well. However, it also
represents a significantly larger change, and I don't want to see small
improvements put on hold waiting for a massive overhaul like that.
> I have tried multiple times to convince Otavio at the last Debconf11
> that I believed partman should also be providing templates with RAID1 /
> RAID10 setups, since a lot of people are using it in the server room. I
> had a hard time, and I think he stand in your side for less choices,
> since his answer was that I should make a custom ISO for myself (which
> doesn't satisfy me, really).
I agree that RAID1 and RAID10 seem common, but the question remains: can
we come up with a template that will actually work for many people
without requiring manual editing afterward?
I suspect the right solution for that would involve a friendly RAID
configuration option which let you first pick the RAID you want, and
then mark areas of free space that you want included, rather than having
to create partitions, mark them as RAID components, and then create a
RAID device containing them. In any case, that seems less like a
template and more like a custom partitioner option.
> >>> Please consider removing the option in the guided partitioner for
> >>> separate /usr, /var, and /tmp partitions; that would leave only the "All
> >>> files in one partition" and "Separate /home partition" setups, both of
> >>> which potentially make sense for users of the guided partitioner.
> >>
> >> Please don't remove the above option, I like it, and I
> >> don't see why it needs to be removed just because
> >> you Josh (and maybe others) don't like/use it.
> >
> > That line of reasoning would never let Debian remove *anything*, ever.
>
> We have debconf priority and the expert install mode for a reason. If
> you said you want to remove some templates from the non-expert
> installer, then I'd say it's a good idea. But not for the expert mode.
"expert" should not represent a dumping ground for all possible
questions. But yes, if I can't successfully argue that this particular
template in the guided partitioner should go away, I plan to suggest
that it should not appear when not in expert mode. That would certainly
satisfy my original goal: ensuring that people don't accidentally end up
with a "pile of partitions" configuration without actively wanting one.
> >> You feel like a separate partition for /home is useful.
> >
> > Actually, I don't, but I didn't advocate that today. :)
> >
> >> Good for you, and your desktop. But when it comes
> >> to servers, the /home separate partition is useless,
> >> and having a separate /var makes things faster.
> >
> > Exactly my point, then. The guided partitioning option I mentioned
> > makes /home, /usr, /var, and /tmp all separate partitions. You just
> > said you don't want a separate /home, and you do want a separate /var.
> > Thus, you have custom requirements that don't fit the guided option, and
> > you'd need to use the manual partitioner instead. I argue that the same
> > holds true for almost anyone who might want something similar to that
> > guided option: they don't actually want what the guided option provides.
>
> If your point is to say that partman can do everything BUT it's GUI
> isn't convenient, then would agree.
No, not my point. I simply said that the particular guided partitioner
recipe I've advocated the removal of doesn't actually do what you want
anyway.
> I'd really love to have more
> predefined templates, and only change sizes only, and there really,
> partman missed the point of templates. On an average server install, I
> spend like half of my time in it.
I certainly agree that I'd like to see a more useful concept of
templates in partman, with more pluggable parameters such as partition
sizes. In the meantime, I think the existing "pile of partitions"
template does more harm than good, not least of which because it doesn't
have a giant "don't use if you don't know what you're doing" warning
attached to it. How do you expect a novice Debian user to deal with
obscure problems like "d-i created a tiny / partition and it filled up"?
> Ideally, it'd be really a cool feature
> to be able to scp/ftp an HDD template directly from the installer (both
> ways: load and save).
Saving a partman-auto recipe directly from the installer sounds like a
great idea; if nothing else, perhaps the installer could save a sample
recipe next to the install log on the installed system. As for loading
one, I'd suggest loading a d-i preseed file. You can boot the installer
with url=http://example.org/d-i to load an arbitrary preseed file and
pre-answer a pile of questions to save yourself time. That preseed file
can include an arbitrarily complex partman-auto recipe. And you don't
have to make a custom CD, though you may want to if you install enough
systems that typing the boot parameter gets annoying.
Tell you what: if you can describe the partitioning setup you actually
want with sufficient precision, I'll help you write a partman recipe and
explain how to put it somewhere that d-i preseeding can find. :)
> >> Also, having a separate /tmp avoids that the rootfs
> >> gets full, and I consider it quite important especially
> >> on servers. I would recommend using it for absolutely
> >> *every* setup (desktop or servers) as a security measure,
> >> especially considering any application can fill up the
> >> temp space.
> >
> > Note that newly installed Debian systems have /tmp on tmpfs by default.
>
> I'm not so sure I will like the "improvement" of eating my RAM when a
> program is explicitly asking to write on a storage medium, but we'll see
> if I like it. :)
Likewise. I actually prefer to have /tmp not wiped at boot time,
personally. I have a (probably bad) habit of storing things there. One
of these days I'll break that habit, at which point I'll probably like
having /tmp as a tmpfs, but for now I always edit /etc/default/rcS on
every new system and set TMPTIME=infinite. I also recognize that as the
uncommon case. :)
> > Also, it really doesn't matter for single-user systems, only for
> > multi-user systems with untrusted users.
>
> With untrusted users, I think I'd implement quotas for writing in /tmp
> (it was like that under OSF1 10/15 years ago...). But when you have
> separate /usr and /var, your rootfs can be very small, so you don't want
> any random program, for a valid or an invalid reason, fills your rootfs
> with anything until it's full. I've seen MySQL doing that for example,
> and was very happy that my dedicated /tmp showed it to me (and that's
> only *one* example of what can happen in a normal usage of a computer
> running Debian).
That sounds like a very good argument for not having a tiny /, actually.
:)
Modern systems seem to cope just fine with near-full disks, and provide
appropriate warnings to users to help them clean things up. And
applications which spew unbounded amounts of data to /tmp need fixing.
> > Distributions *exist* to make choices for you, most of which you don't
> > care about.
>
> One of the reason I like Debian is that it gives me the choice to have
> the choice (eg: debconf priority is configurable).
Sure. In general, I like the principle of "make the easy things easy,
and the hard things possible". In this case, I'd like to make the easy
things easier, while continuing to leave the hard things possible.
- Josh Triplett
Reply to: