Re: Putting variables into files section?

[Adam Ophir Shapira <red_angel techno-info com>]

John,

 I appreciate your concerns, but <boxenv> addresses every one of them.

John Aldrich wrote:

> Adam:
> I'll say this, I'm the admin on ONE box... my personal box where I *am* the 
> user.. :-) 
>
> On the other hand, I really do understand where you're coming from. I have a 
> shell account at one ISP and would dearly LOVE to install some stuff like MTR 
> and other network utils for when I'm trying to figure out a problem, however, 
> I can't do that because I'm not an admin.

There are some things that by their very *nature* can only be
installed by the admin, and <boxenv> does not change that. The
first example that comes to my mind is a CGI-wrapper.

There was one time that my boss asked me to install Nathan
Neulinger's <cgiwrap> program on a system, and it took me a
while to explain to my boss that only the Systems Administrator
could do such a thing.

It took about a month or so of nagging for them to finally
install it: it would have been much faster if I could install
it myself. But the fact that I had to nag the sys-admin was
acceptable, because by it's very *nature* a CGI wrapper can
not be installed by a regular user.

However, with another program <cgiemail>, I could not tell
my boss to wait for me to nag the sys-admin. So, instead,
I modified <cgiemail> to work with <boxenv>: so that now
I can install it.

<boxenv> can not change the fact that certain programs, by
their nature, have to be installed by the sys-admin: and
it *shoudn't* change that. That fact should remain as it is,
and <boxenv> does not violate this.

The problem I had is that with non-<boxenv> packaging,
certain programs could only be installed by the sys-admin
even if there was *nothing* in the nature of that program
to render this limitation necessary.


> That being said, I *do* understand why the average user isn't allowed to 
> install stuff at will. Think about it this way -- if you run a shell server 
> for a couple hundred people and they all want their own appz installed, is 
> that REALLY a good thing? Do you want to be responsible for all the junk that 
> would be installed?

If you mean, do you want to be responsible for providing tech-support
etcetera for things that individual users install: then that's nothing
that a simple disclaimer can't solve. There's nothing wrong with telling
someone to go to whoever gave them the program they're trying to install.

If you're asking if you want to be responsible for any complications
such a program will have on the system: there my answer is simple
again. A program that a user installs on one account should have no
effect on anyone else's account: and <boxenv> does not change that.


> Also, what if the user installs something and overwrites 
> a config file somewhere?

The only one who can overwite systemwide config files is the
sys-admin. The only config files that regular users can modify
are their own config files. And <boxenv> does not change that
either.

You are absolutely right, no user (other than the sys-admin)
should have access to systemwide config files. But there
also need to be config files that reside *within* the
account that the individual user *does* have access to.


> That's the reason (in my mind, at least) that only the admin should be 
> installing stuff. I really do appreciate your point about allowing the users 
> to be self-reliant, but after 2.5 years as tech support for a local ISP, 
> there are only a handful of people I know who are "clueful" enough to install 
> software on a linux box. Of those, I'm not sure how many of them I'd want to 
> take responsibility for... there are several really nice guys who I would NOT 
> want to stand up and say "yes, I let them install this software package."

Then the company I work for would have no use for your services.

We very often (*far* more often than not) have to be able to install
programs in order to do what clients pay us to do.

The purpose of <boxenv> is *not* to allow regular users to screw
with system-wide resources. That's not allowed, that still doesn't
need to be allowed, and in my opnion (as well as yours) that
*shouldn't* be allowed.

The purpose of <boxenv> is *not* to allow regular users to screw
with system-wide resources: but rather to allow regular users to
install things on their own accounts *without* screwing with
system-wide resources.

> If you think I've been on a pedestal too long, maybe I have... but maybe 
> you've been looking UP at the sys-admin too long and need to step up and BE 
> the SysAdmin for awhile... kinda balances things out. :-)
> 	John

You may be right. Maybe if I had been vested with such a
responsibility, I would have insights that I don't have, which
can only be gained by experience.

But though I haven't ever been a sys-admin (and I assume we both
agree that me administrating my own PC does not count) I have spoken
to people who have (often while they were acting in their capacities
as sys-admins).

There was one time in the early days of <boxenv>, when I needed to
write a script that would automatically install on both of two
systems: and I had a problem. The PERL interpreter was in one place
on one system, and in another place on another system. On one system,
it was installed at /usr/bin/perl, and on the other it was installed
at /usr/local/bin/perl.

The sys-admin of the system that had the interpreter at /usr/bin/perl
argued that the place he had it in was the standard place where the
interpreter is *supposed* to be with PERL 5. I to this day don't know
whether his statement was right or wrong, but I do know that that is
what he said and stood by: and he refused to put even an alias anywhere
else.

The sys-admin of the system that had the interpreter at /usr/local/bin/perl
argued that this was where he had to install it because of how the Network
Fie System was set up, and he refused to put even an alias anywhere
else.

He even told me (IMHO quite rightly) that I needed my programs to be
flexible enough to accomodate such variety at run-time.

Now, obviously, this kind of variety couldn't be accomodated at
run-time, because the very first line of a PERL script has to
be either
 #! /usr/bin/perl
or
 #! /usr/local/bin/perl
and so I couldn't accomodate this difference at run-time. But
with <boxenv>, I *could* accomodate it at install-time.

The details of how I accomodated it are not relevant to this
post, so I will omit them. But the moral of the story (which *is*
relevant) is that sometimes even the sys-admin can benefit from
flexibility regarding where he/she installs a program.

But the bottom line is that when the client and the provider
have seemingly conflicting needs, the mature solution is *not*
to tell one side or the other to shove-it. That approach tends
to be bad for business. Rather, the mature approach is to if
at all possible, find a way to accomodate both needs.

The sys-admin has a need to prevent regular users from screwing
with systemwide resources. Though I've never been a sys-admin,
I don't *have* to have been one to know that. Likewise, some
users (such as myself) have the need to install some software
on our own accounts. If that need is not met, I can't do my
job, therefore it is a valid need.

Therefore, the only way to keep everyone happy is to find a
way to allow individuals to install software on their own
systems *without* having to screw with system-wide resources.
I believe that <boxenv> offers exactly such a solution.


Now, I was *hoping* that I could find a way to make RPM
packages that use <boxenv>, since RPM has things to offer
too. But since it looks like that's not going to work,
how about plan B: Is there a way that I could get <boxenv>
to *communicate* with RPM?