Re: it's safe to run a web hosting server with the unstable distributions ?
We run unstable and make a point of upgrading frequently.
It is our job as ISP to maintain the environment and make
improvements. We tell our clients that old scripts will break
as that environment changes. Either they pay us to maintain
the scripts or they take it on themselves.
The most recent breakage that comes to mind was change of path
for imagemagick from /usr/X11R6/bin to /usr/bin. There was something
with a2ps too that broke our catalogs momentarily. Those would have
wreaked havoc whether stable or unstable. AFAIK that only affected
systems scripts that we maintain, so it was our responsibility
to fix it. That's our job. Personally I'd rather fix a few
now and then than find everything reduced to rubble at once!
Most breakages are our own changes in infrastructure, eg drop
msql for mySQL, etc.... We've always been able to warn clients
and give them a grace period to convert or they will have us do it
for them. There have been a few clients unwilling to pay for that
and we have given them a grace period to go away. Others won't
do anything and leave broken perl4 and libc4 binaries kicking errors.
You **need** clients to complain loudly when something breaks; otherwise
how will you know? As for the lawyers, you'll hear from them
if you upgrade or if you fail to upgrade. ;^) We've just found
it easier to maintain consistent upgrades as a matter of **policy**.
On Mon, Apr 10, 2000 at 10:28:27AM -0400, John Haggerty wrote:
> Is there a good example of something in debian breaking a general
> script/program server side?
> On Mon, 10 Apr 2000, Phil Pennock wrote:
> > Typing away merrily, John Haggerty produced the immortal words:
> > > I think that would work quite well. Just make sure to upgrade the system
> > > regularly. That will keep you abreast of all the problems and allow for a
> > > nice system.
> > Customers can complain quite loudly when something which used to work
> > has suddenly stopped working because of an upgrade.
> > How likely are your customers to have lawyers?
> > Another approach is to go for something stable, specify perl versions
> > with an embedded version number (watch out for the libperl linking) and
> > put something in the customer contract about being allowed to make
> > changes which break their scripts if there are security reasons for
> > doing so - this allows you to patch your system or temporarily disable
> > certain functionality.
> > If you have, eg, /bin/perl5.005_03 etc within the customer-facing root
> > and maintain those properly, you can introduce new versions and allow
> > the customers to manage the migration themselves; if you want to be able
> > to retire older versions which are broken, make sure that the customer
> > is aware of this fact and that they agree to a time-limit for phasing
> > out older versions (contracts time again).
> > Of course, if you're dealing with smaller customers on a more informal
> > basis, where they're more likely to rely on you for direct technical
> > assistance with scripting and stuff, then you're much less likely to
> > need to bother with this in contracts (IANAL, please don't not use a
> > contract on the basis of this paragraph).
> > Larger ISPs sometimes have customers who _seem_ hostile to the ISP and
> > like to carp a lot, even with no real justification. Although when
> > something which did work stops working and the customer starts losing
> > revenue because of this, they do have a point. Try to make the customer
> > environment as stable as possible if there's money involved in the
> > websites.
> > You could always have two types of web-service. One with a server which
> > is stable in the way I describe, one which is a current OS, regularly
> > upgraded and which has latest-and-greatest, but the customer assumes
> > some responsibility for changing their scripts appropriately.
> > All this IMnsHO. HAND.
> > --
> > 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
> > --
> > To UNSUBSCRIBE, email to firstname.lastname@example.org
> > with a subject of "unsubscribe". Trouble? Contact email@example.com
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
Christopher F. Miller, Publisher firstname.lastname@example.org
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
Database publishing, e-commerce, office/internet integration, Debian linux.