Re: Linux ease of use

Kwan Lowe wrote:

>>That's only a good thing when you're installing something
>>system-wide that could affect the whole system. But regular
>>users *should* be able to install things on their *own*
>>account that only *affect* their own account. And they
>>*would* be able to do that *too* if it weren't for the
>>fact that so many installers are just too inflexible.
>>
>
>I can understand some of your points, having been in a position where I
>had to request technical support to get certain applications installed on
>my desktop. However, as a system administrator for over 10 years and a
>computer user for close to twenty, I can't agree with most of your
>reasoning.
>
Okaye. I see your point. And this, I extend my appologies
to Daniel. And as I see your point, I can therefore agree
that *sometimes* you and Daniel are right: but not always.

Whenever I shop around for a hosting service of any kind,
I always ask several questions: such as: Is there a C
compiler? Is there a CGI Wrapper? And so-forth: all questions
that make it crystal-clear that I intend to compile and
install stuff on my account.

I am (usually) only willing to go with a service that can
say "yes" to my questions. And for that, I am willing to
pay a premium. On the other hand, there are other people
(and in very *rare* cases that *may* include myself) who
don't really care about these features, if foregoing them
can save a buck or two.

Now, if a service-provider does *not* portray themselves
as being supportive of such features as this, then it is
perfectly OK to protect their machines by means that
disable these features, especially if that makes their
job easier. In such cases, you and Daniel are correct.

However, if a service-provider portrays themselves as
*yes* being supportive of such features, thereby potentially
increasing the market-value of their service: then they
obligate themselves to the task of protecting their
server *without* disabling such features, even if
that task is more difficult. That does not mean that
you have to prevent individual users from screwing up
their *own* accounts. It only means that you have to
make sure that whatever damage one user does is *limited*
to *that* user's account, and does not bring down the
system as a whole. Protecting the server in such a way
might be a slightly more difficult task than simply
*disabling* the features in question: but if the
service was advertised to me as supporting these features,
and if that was a factor in my choosing that service
provider over another, then I have the right to *expect*
the sys-admin to go this extra mile.
--

>
>
>>I mean, sometimes you just need to get something installed
>>quickly in order to meet a deadline: and going through the
>>hastle and red-tape of convincing the sys-admin to install
>>it for you could result in kissing that deadline goodbye.
>>
>
>There's a reason that I am hesitant to install packages quickly. For one,
>there's almost no predicting what effect a new package will have on
>existing applications, on system load, disk space, bandwidth usage, and a
>host of other issues. Even a relatively benign program such as a new shell
>or system libraries can have multiple unintended consequences. In the
>worst case a package may contain SUID executables that, though were not
>intended as a backdoor, can easily allow compromise. Many, many times I've
>had to tell users that just because an application works fine on their
>personal Windows or Solaris or Linux desktop does not mean it will work
>the same on the server. In any case, it's my job that's on the line should
>these programs cause havoc, not the end users.
>
--
First of all, by "quickly", I don't mean hours instead of days.
Rather, I mean days instead of weeks or months. Also, when I
need something installed in order to do my job, I don't want
to have to pay some sys-admin three-or-four times what I make
per-hour just to review and inspect my software. Of course, if
an admin chooses out of his curiousity to do that *without* my
paying him/her to do so, that's fine with me since everything
I write as well as everything I'd install on the server is
Open Source. And the few sys-admins who ever took me up on
that offer were all *amazed* at how robust and non-intrusive
my software is.
--

>
>
>>It is *not* a good thing if you miss a deadline because
>>you're waiting for the SysAdmin to install a given program
>>in "/usr/bin" when if only the installer had been more
>>flexible you'd be able to set a preference variable to
>>install it in "/home/myself/bin" (assuming that
>>"/home/myself" is your homedir).
>>
>
>The worst users I've encountered are those are constantly need something
>*right away*. It's as if their projects were far more important than the
>System Administrator's responsibility to keep the servers running for
>dozens or hundreds of other users.
>
If I'm paying for just an el-cheapo account on a service
that doesn't portray itself as supporting these features
I'm talking about, then you're right.

But if I chose your service over another because you
claimed that you *do* have the features needed for me
to install my own software, then yes, you do have the
responsibility to keep the server running smoothly. But
disabling the features that you touted yourself as
having is *not* an acceptable way of doing this. Rather,
the way in *these* cases to keep the server running
smoothly is to make sure that any damage I do is
localized to my own account.

Furthermore, I stronly suspect that the argument you're
bringing is (whether you realize it or not) a smokescreen
argument. This is because the most reliable hosting
service I ever worked with not *only* supports these
features, but is *very* supportive of these features.
But even if you *are* right and disabling these features
*is* easier than protecting the server *without* disabling
these features, that does not change the fact that if
you tell a shopper that you *do* support these features,
and then backpedal once the shopper's tied to you, you
are doing something that is (at very least) unethical.
--

> If a user cannot prioritize his time
>properly, which means giving the SysAdmin advanced notice to either
>install the application on a test server or at least get the approval of a
>senior manager who is willing to take the risks, then I do not install the
>software. Now I understand deadlines, having worked on both print
>publications and on software projects, but this does not mean that the
>SysAdmin is suddenly at fault because I didn't plan my time properly.
>
I'm not talking about getting software installed system-wide. I'm
talking about getting stuff installed just on my-own account.

Nontheless, you're quotes of "prioritize his time" and "plan my
time propperly" are not lines that I want to (or should have to)
hear from a SysAdmin if I chose his service becaus they claimed
to support these features. True, the SysAdmin may not be at
fault for failing to blow-my-noze for me. But the SysAdmin *is*
at fault for preventing me from blowing my *own* noze.

And as for the issue of "risk", I don't think it is that hard
to set the system up so that the "risk" is limited to my-own
account. Especially if I chose your service because you claimed
to offer these features.
--

>
>
>>There are some programs (such as CGI Wrappers) that by
>>their very nature can and should be installed by only
>>one user, the SysAdmin. But what is the *point* of having
>>a CGI Wrapper? It's very *point* is to allow regular
>>users to have their *own* CGI scripts without the risk
>>of jeopardizing each-other's security.
>>
>
>CGI programs are notorious for buffer overflows and bad programming
>practices. Why? Many of the authors are concerned mainly about getting a
>web page working than keeping a system secure.  The problem with allowing
>arbitrary CGI programs (read, those installed by users) is that the CGI
>will run as the httpd process. This, in most modern cases, is either the
>apache or nobody user. In some older systems it is root. An overflow or
>cross site script vulnerability, even in the modern case, can easily lead
>to compromise or data exposure.
>
That may be said about *some* CGI scripts, but never
about any CGI scripts that *I* wrote.
--

>
>
>>Any sys-admin who does that looses my business. I have
>>no patience for admins who's idea of "protecting" the
>>service involves crippling it.
>>
>
>Give me an example. As you know, there's always a compromise between
>security and convenience. To be frank, I wouldn't work for a company that
>had your attitude towards security and system administration.
>

But many times, one can have *both* security *and* convenience
if one is only willing to forego *laziness*.

True, if I'm paying for an el-cheapo service, then one might
be truly un-able to deal with both allowing these features
and having security: and I mean *without* being lazy. Since
I can't prove that to be fales, I'll grant that it's true.
But if I'm paying a *premium* for your service, then this
excuse I don't want to hear.
--