Soren Hansen wrote:
> I'm sorry you took offence to what I said. It meant it in the most
> affectionate way imaginable. In fact, I usually consider myself to be in
> that very group. If someone refers to the style with which I attack a
> problem as old school, I blush like a school girl (on the inside, at
> least). I also proudly refer to myself myself as a nerd or geek.
:-)
> If we look solely at the packages I suggested, I don't think 5-6
> packages constitutes a greatly expanded list of items to be
> installed.
Agreed. But I work under the assumption that the list over time will grow
greatly and not over a very long time at that.
If I may expound further (and I think this will speak to several of your
questions below) I fear this list would become truly ridiculous if we pursue
this path with anything less than a very hard line approach. By way of example:
I find it truly amazing, yeah, incomprehensible that someone would suggest a
text mode browser should be installed by default on every server. My mind is
unable to grasp the concept. Meaning no offense to any who hold this opinion, I
just do not know how to even think about it.
That some folks have cases where such a thing is useful. Certainly. That it
should be easy to add to a base system. Absolutely. Install it on every box by
default. Can't imagine it.
I don't mean to pick on that example (or it's proponents), but if such an
innocuous and (to me) useless thing has a strong chance of being added to the
list, then I assume we'll shortly have a flood.
If someone wants to say that's an irrational fear, I won't argue the point. But
having too much history with "kitchen sink" distros like RH/Fedora I just can't
find it to be embarrassed about fearing to go back to anything similar.
>> The rational-defensible approach, IMHO, is to keep the base install as
>> lean as possible but also make it as easy as possible to layer on top
>> of that base.
>
> What is the goal you are trying to achieve by doing this?
Thank you for asking. I think I answer this in pieces below.
I is somewhat scary tho as I thought this was actually a design goal of sorts
of Ubuntu (somewhat) and ubuntu-server in particular. The necessity to keep all
images on one CD being an example. So you asking is surprising. Apologies if
I'm reading to much into this. I just thought this had been decided long ago.
>>> The current approach is something like:
>>>
>>> 1. Will more than 95% of our users need it? If yes, install it by
>>> default. If no, go to next question.
>>>
>>> 2. Will more than 80% of our users need it? If yes, include on CD. If
>>> no, go to next question.
>>>
>>> 3. Will more than 10% need it and be completely and utterly screwed
>>> without it? If yes, include it on the CD. If no, go to next question.
>>>
>>> 4. Forget it.
>> This is good stuff.
>
> ..yet you seem to think that point 1 should read "100%".
Perhaps. But I suspect the difficulty in gathering reliable data about it would
obscure the difference between 100% and 95%. So your process sounds fine given
that a certain amount of subjectivity and imprecision is a given.
>> The tools that a LAMP stack admin should be using are probably quite
>> different than what one of my very simple Samba boxes would require. I
>> don't think either's list should dictate the other.
>
> You seem to wilfully miss my point. I'm not trying to determine the
> /union/ of useful tools for /every possible/ user of Ubuntu Server. I'm
> trying to determine the /intersection/ of useful tools for /most/ users
> of Ubuntu Server.
I don't believe I'm doing that, certainly not willfully. I suppose it's just
that I'm comfortable that the intersection has already been reached. Not to say
there aren't things that should be added. But there may also be things that
could be removed. I truly cannot imagine that such an intersection would
contain more than a handful of items beyond what is already on the base server
install.
And, if I may... The seeming conclusion that w3m is a good candidate for being
added looks to me like the beginnings of a "union" process, not an
"intersection" process. But I'm probably guilty of making too much of one
example.
>>>> Here's my list:
>> Evidently my thick sarcasm obscured the fact that this list was
>> intended to show how quickly it becomes ridiculous to include what
>> everyone thinks is a necessity.
>
> As we're dealing with tricky bits of set logic, please be careful with
> words like "everyone". Surely, "what everyone thinks is a necessity"
> (i.e. something that *every* user finds necessary) should be installed?
What I meant by that "everyone thinks is necessity" was the idea of taking
everyone's list, adding them together ("union") and making that the list of
things we add to the default install. Obviously we won't be doing that. But the
w3m example looks awfully close to it. (See "irrational fears" paragraph above.)
>> Hence, no matter how bad I want it, it shouldn't be installed by
>> default.
>
> Why?
Answer predicated on my belief that it's primarily only useful to one class of
admins (those who remotely admin over less than reliable networks).
> I apologise. I meant no offense.
Thank you.
>>> Let me offer a take on this. Say there's a package called foo, which
>>> 60% of our users would want. If we install it by default, only 40% of
>>> our users will have to change the default, while 60% will be happy
>>> with it. Disregarding all other circumstances, surely that sounds
>>> sensible?
>> No. It doesn't sound sensible. Let me attempt to explain why...
>
>> Take the 60% group that needs the package. The only pain they feel is the
>> necessity, after install, to type a 30-character apt-get command. (I'm
>> assuming
>> it's on the CD or the net is available.) Their system is no worse for it.
>
> Since they take their time to install it later, they find the package to
> be useful. Hence, the lack of said package makes their system less
> useful than it could potentially be. "less useful" is "worse" here, IMO.
But the "damage" is minor ... trivial. Given that it can be rectified in a few
seconds by typing one short command. A data point certainly, but not a slam
dunk.
>> But the 40% group must a) allocate partition space for a package they
>> don't need,
>
> Some of the suggested packages are less than 100kB. I know very few
> people who allocate partition space with smaller granularity that a
> megabyte. (The ones who do, I would certainly call "old school", but
> that's a different point). If you're doing so, how do you cope with
> increasing size (added help messages, more code) of packages when you
> upgrade, for instance? I'd say you're asking for problems.
See "irrational fears" paragraph above. A meg here and a meg there and pretty
soon you're talking about some real disk space to mangle a quote from another
realm.
If the discussion really comes down to adding 5 or 6 packages of 100kB each,
then I'm wasting way too much of your time talking about it. I just doubt
that's really the long term effect of this.
I will also mention, in passing, the cases where I'm installing a very small
server on a flash card where the difference between, say, a 1GB root partition
and 2GB one could be very significant. This is, I think, somewhat of a special
case where the use of 'apt-get remove --MANY' would be in order. So it's not
the primary decision driver. But we also shouldn't lose sight of such things
either.
>> b) possibly answer configuration questions during install for a
>> package they don't need,
>
> It's funny that when I suggest installing a packages, I'm assuming that
> we'll choose them carefully so as to avoid there being asked additional
> questions on install, while you seem convinced that if we add but a
> single package more to be installed by default, it will surely be huge
> one which will ask tons of questions during its installation, will ony
> be useful at all to at most 51% of our users, and extremely offensive to
> rest.
>
> If you have this little faith in us, I think you're using the wrong
> distro.
No, definitely not. You guys have done way too much good work (both for
Ubuntu's users and the good name of Linux) for that conclusion to be likely.
But I don't take it for granted that it must always be that way. If we're not
careful what we could be doing with this idea is ordering up a supersize dose
of entropy.
Having observed, in a number of situations, how entropy creeps into human
endeavors I believe we should not go silently into that good night.
See "irrational fears" above. (I keep referring back to that because it
explains a lot of why this set me off so badly.)
>> c) remember to uninstall something that is likely
>> out-of-sight-out-of-mind,
>
> Why would you bother?
I probably wouldn't. But perhaps that makes my point. You offered this as a
solution (tongue in cheek, no doubt) so I am addressing why I believe this is
not a solution or at least not an acceptable one.
>> e) live with the knowledge and risk of knowing that uninstalling
>> packages is far more likely to break something than an install would
>> be (from my experience, anyways).
>
> The idea -- which seems to be lost somewhere -- is to add additional
> packages, which users will not want to remove (other than to be
> pointlessly difficult).
If that's really what we achieve, then certainly so. I just didn't see this
heading that way. See the (tiresome) w3m example above.
>> And please note that I place great weight on item 'e' above,
>> uninstalling is far worse than installing.
>
> Why do you bother? I'm genuinely curious.
Well, I sorta thought I'd covered this already.
- Keep disk/memory footprint small.
- Have no unnecessary security exposure.
- Minimize risk due to unnecessary software updates.
- Minimize work due to unnecessary software updates.
- Retain ability to run on low-end hardware.
If we're really talking about a few hundred kb of innocuous packages, then this
isn't worth chewing over. But the evidence was mounting that we weren't heading
that way. Perhaps I read that wrong.
I just really don't want to allow the idea that removing is just equal and
opposite to installing. I regard one as far more damaging and risky than the
other.
>> I think that's a *good* thing because I consider a server to be a
>> *platform* upon which I add the things (applications) that make it do
>> what I need.
>
> Does "do what you need" include keeping out crackers?
Yes. Does w3m help with that? :-)
Would a server with lots of internet-facing ports (LAMP, DNS, email, whatever)
need the same security tools as a samba-only server with no ports exposed to
the Internet and no user accounts? The "intersection" between those two might
very well be an empty set.
But I'm open to education in that sphere. There's been several mentions of
"best practices" which is always a good thing to have available. But often in
the Enterprise space, best practices is a code phrase for "most expensive"
practices (mostly as a way of covering the backside). I'm just rambling to
belabor the point that the spectrum here is incomprehensibly wide.
Finding an intersection, any intersection, may be difficult.
>> Yes you didn't say that at all. But the point I was trying to make is
>> that these "package deals" that are optionally installable are, IMHO,
>> a better solution than adding lots of clutter to the base install.
>
> Can you perhaps take a minute to explain why you insist on assuming that
> "lots of clutter" is what we'll add. All that is being suggested is to
> add "a few tools that are useful to most people".
If that's really the goal then I stand corrected. It just did not appear that
was what we were doing. And we need to decide if "most"==95% or "most"==51% or
whatever. I think 51% is insufficient given that a large base of users are
being "harmed". Perhaps 95% is too stringent.
If it's not obvious, I would be a proponent here of something approaching
"minority rule". This, given that the "harm" to the majority in accommodating
the minority is essentially nonexistent.
>> I do it all the time. Please think of the difference between something
>> like apt-get or wget versus something interactive like ssh or, perish
>> the thought, a gui.
>
> You're the one who brought GUI's to the discussion. I don't find the
> very interesting when dealing with servers, to be honest.
Agreed. But if I may, there are other things that have been brought up that (to
me) is no more interesting (or appropriate) than GUIs on a server.
>> The cli can only be made tolerable with tools like screen.
>
> ..yet you only want to share this useful tool with the few lucky users
> who already know about it.
I had it installed for years on servers and didn't know about it. (Someone on a
Linux list educated me to it. Changed my life.) Having it installed bears no
relationship to knowing about it. I've been installing Ubuntu servers now since
fall of 2004. In all those many times of bringing up a server from scratch, it
never occurred to me that typing 'apt-get install screen' was a hardship or
something I should have been spared from.
If it truly is a 95%+ tool and we have some reason to believe that other than a
few email responses, then I suppose there's no reason not to go for it. My
server footprint won't increase because of it.
Here's a thought exercise: what about when the day comes that the server image
is threatening to pass 700MB; which packages will be the first candidates to be
removed? And if they're a candidate then, then why include them now? Just
something to think about.
> You might have noticed that at least some of the tools I suggested to
> begin with were security tools. They're designed to solve security
> problems. Their failure to be installed by default are this very minute
> making scores of machines more vulnerable. (and it's all our fault,
> because we failed to simply install those packages by default).
I have to disagree. I don't think this is your fault. (Which is not to say I do
not take note of your willingness to take responsibility for providing the best
product you can.) But I submit that merely having those tools installed
automatically on my boxes will do little if anything to secure them. You've
done a good job with some of the tough-but-necessary decisions (e.g. no open
ports). But offhand, I can think of few things that if not deliberately
configured, monitored and used regularly by the admin will do much to to
enhance security. If you know of examples of things that can be configured by
the packagers and will make a meaningful contribution to security with no
active participation by the admin, I'd like to know of them. That sounds like
"zero effort security" which I think most would say is unachievable. But I'm
open to education. Repeating myself, just having it installed is not the same
as making use of it.
Thanks for the discussion, sorry I'm taking so much of your time and being such
a tiresome bother. I apologize for taking this so personally and taking it out
on you.
Best regards,
Michael
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
