Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, cfm@maine.com produced the immortal words:
> Actually, all of the scripts we maintain do "register" their existence
> and location in syslog each time called.
Interesting. Why not just parse the server logs?
> This is not just a perl issue. What about header files, /usr/src/linux
> and so forth? What if client linked to libc4 krb4 libs? (No
> that is not made up.)
We don't support the use of binary CGIs. We reserve the right to make
changes which may cause them to fail. We support the use of Perl for
CGIs.
The CGI environment of just about all services doesn't include, eg,
/bin/sh, /bin/rm, etc.
> At a certain point, a customer that does NOT want to upgrade is
> increasing your costs and complexity. That complexity (and associated
> costs) apply to all users. Worst case, imagine the extra expense
> caused to 1500 perl users because just one doesn't want to upgrade
> from legacy /usr/bin/perl -> perl4 to current. I'd guess that
> ASPs might have contracts that addressed this fairly well. Hmmmm.
If we can justify to senior management the man hours of getting our
customers away from */bin/perl -> perl4 then we could do it. It's not
"expense to 1500 users" though - we're never again going to have a
web-environment where the interpreter filename doesn't map to a very
specific version. Well, never in so far as "all current sysadmin (which
includes my boss) will fight tooth&nail".
The blurb sent to new accounts states the interpreter naming thing. The
web-site help docs state it. Support know about it. Very occasionally
a new/clueless support bob might have to escalate a problem because they
can't see what's going on. But yes, removing the unversioned perl
interpreters is a goal.
Actually, a major way of doing this is by having the newer web offerings
get it right from the start and pricing them lower. Quite a few
customers are making the migration.
> Anyway, management of legacy code is WAY OT from can you
> run "unstable" server. ;^)
Is it? "Can you run an unstable server" is not boolean unless you first
provide much more detail. How much time do you later want to spend
sorting out problems, either technical or legal?
> Be careful next time you quote a job to make a minor modification; you
> might end up rewriting the entire package!
NOCOL sucks[1]. I'm investigating NetSaint and MON. Does anyone have
any operational experience of these packages please? Any feedback that
you'd care to give?
[1] Technical term. Well, okay, mostly it's the module interface which
sucks[2], and the inability to make a chain of system dependencies,
so you can't say "if BigRouter goes down, just report that, and not
the 300 LittleServices behind it".
[2] Mostly nocollib.pl which is unclean and leaks memory and I don't
want to have to maintain a new custom Nocol.pm so I've had to look
at solutions which have more long-term viability.
--
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
We believe in world peace through extortionate license fees." -Bluemeat
Reply to: