Re: it's safe to run a web hosting server with the unstable distributions ?
From: Phil Pennock <[EMAIL PROTECTED]> > Oh, and the boss says that we have a large proportion of 1,500 customers > of the relevant service whose scripts all date from perl4-only days and > if I want to phase out /bin/perl as perl4 then I can do it all by > myself. That's one way to end a discussion ;-)
Re: it's safe to run a web hosting server with the unstable distributions ?
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? SSH. Best regards, Daniel
Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, [EMAIL PROTECTED] 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. H. 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
Re: it's safe to run a web hosting server with the unstable distributions ?
On Mon, Apr 10, 2000 at 07:15:40PM +0200, Phil Pennock wrote: > Typing away merrily, John Haggerty produced the immortal words: > > Is there say a test that can be implimented that would test to determine > > wheather the program you are running will work under perl and > > then pick that version of perl? That would really rock and would possibly > > be quite easy considering perl is a great tool for text manipulation and > > analysis. > > At run-time of request? Erk! Actually, all of the scripts we maintain do "register" their existence and location in syslog each time called. 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.) 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. H. Anyway, management of legacy code is WAY OT from can you run "unstable" server. ;^) > > If you're using a web-server which pre-determines mime-types, such as > wn, you could conceivable use perl_version -c script, making sure that > you handle -T (taint-checking) on the command-line. > > But if the script is syntactically valid in a version where it would > actually fail, then your "test" becomes a competent human perl > programmer. Or non-human, if you employ such. > > The best way IME is to not have /bin/perl exist - always encode the > version number, and let the #! line be your switch for picking the perl > version. > > > Oh, and the boss says that we have a large proportion of 1,500 customers > of the relevant service whose scripts all date from perl4-only days and > if I want to phase out /bin/perl as perl4 then I can do it all by > myself. I think that fairly neatly ends that discussion - I'm already > trying to juggle too many things at work. Be careful next time you quote a job to make a minor modification; you might end up rewriting the entire package! -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Database publishing, e-commerce, office/internet integration, Debian linux.
Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, John Haggerty produced the immortal words: > If you need source that badly or ever need it in the future just get some > copies of everything and burn some CDs for permanent archival storage. You > can't go wrong there. We've now made sure that it's on a central CVS server in the UK. Much redundancy in the RAID, and backed up. Somehow, someone had neglected to ensure that we had perl4 source around. Not all _that_ surprising - at the time it was probably taken for granted that it was widely available. > I think in upgrading something like perl4 you could hire say one > programmer to do a temporary job and be on call for you. Then fix > everything. I may be incorrect but isn't most of the core language of perl > pretty much constant? Kind of like C/C++ or perl/delphi It tends to be backwards compatible - new features are added, so you can test for a minimum version number. The move from perl4 to perl5 was hot entirely backwards compatible, though. As an example of the most commonly encountered problem, in perl 4 arrays were not interpolated into double-quoted strings. So, given: @foo=(alpha, beta); $bar="x @foo x\n"; and the default output field separator of a single space, printing $bar will give you: perl4: x @foo x perl5: x alpha beta x which causes problems with, for example, email addresses (in the very common case where double-quotes have been used unnecessarily, or it's inside a here-document, or whatever). There are some other smaller gotchas as well, but I don't remember them off the top of my head as the vast majority of problems arise from the above scenario. -- 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
Re: it's safe to run a web hosting server with the unstable distributions ?
One of the most interesting things that actually got me charmed with debian was a copy of debian 0.99beta that I had on some old cds. I remember that day well. There were some problems and some functionality missing but overall it's useful. I could install almost everything in the distribution on my entire small partition and it worked great. If you need source that badly or ever need it in the future just get some copies of everything and burn some CDs for permanent archival storage. You can't go wrong there. I think in upgrading something like perl4 you could hire say one programmer to do a temporary job and be on call for you. Then fix everything. I may be incorrect but isn't most of the core language of perl pretty much constant? Kind of like C/C++ or perl/delphi On Mon, 10 Apr 2000, Phil Pennock wrote: > Typing away merrily, [EMAIL PROTECTED] produced the immortal words: > > So perl is perl4. That creates problems for users typing in perl and > > On one service, yes. But that service predates perl5. > > Upgrading the hardware for Y2k was fun - when was the last time that you > tried finding the source for perl4? > > > expecting it to work. At a certain point it is simply cheaper for you > > to bite the bullet and upgrade them for free, no? Because you are starting > > to twist everything else too. And then when you do that free upgrade > > all of a sudden you own everything else that goes wrong too, even if > > you made **less** go wrong. Been there - we start year 7 on May 1. :-) > > It would be nice to be allowed to just use find/ed to change all scripts > with /bin/perl to /bin/perl4 - but first you, eg, need customer > permission for that. And to sort out who's liable if something breaks. > Eg, the find/ed isn't as simple as it might appear at first sight - > remember the perl trick of using /bin/sh and the first three lines sort > out finding the interpreter for you? I think that service is the one > where the root directory for customers logged in with a shell is the > same as the one for the web-server, so /bin/sh is available, so that > trick may very well be in use. > > But yes, I don't want to be in the position of still having /bin/perl be > v4 in five years time. But, given the workload in working through 1,500 > customers' scripts, you'd be looking at: > * people to co-ordinate this with the customers > * people to fix the scripts > * people to test > which leaves you with one of: > * heavier workloads for various departments, perhaps an extra employee >in various places, just for upgrading perl > * a dedicated temporary team, hired to manage this upgrade > > Methinks it would be more appropriate, given out situation, to find a > way to get permission to automatically replace /bin/perl with > /bin/perl4, do so, run some scripts which try to look for monstrosities > like scripts which invoke perl interpreters, fix those, remove the > /bin/perl link and then just never ever let /bin/perl exist again. > > > > I think you are on right track with phase-out policy. It really is > > a business service issue and needs to be addressed that way. What > > do you provide, etc > > And this is much easier if you can manage easily which version of perl > is being used. So, when someone asks how to go about things, they can > get one of three responses from me: > * silence (I'm too busy) > * just install /bin/perl (I really don't like them) > * the advice I gave about numbered versions (I'm in a helpful mood and >trying to save them headaches later) > > Relying on timely response from customers from customers does not scale. > Searching for a magic bullet is naive. Trying to design things right > first time isn't perfect, but it makes life easier in the long run, at > the expense of more work at start-up time. > -- > 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, [EMAIL PROTECTED] produced the immortal words: > So perl is perl4. That creates problems for users typing in perl and On one service, yes. But that service predates perl5. Upgrading the hardware for Y2k was fun - when was the last time that you tried finding the source for perl4? > expecting it to work. At a certain point it is simply cheaper for you > to bite the bullet and upgrade them for free, no? Because you are starting > to twist everything else too. And then when you do that free upgrade > all of a sudden you own everything else that goes wrong too, even if > you made **less** go wrong. Been there - we start year 7 on May 1. :-) It would be nice to be allowed to just use find/ed to change all scripts with /bin/perl to /bin/perl4 - but first you, eg, need customer permission for that. And to sort out who's liable if something breaks. Eg, the find/ed isn't as simple as it might appear at first sight - remember the perl trick of using /bin/sh and the first three lines sort out finding the interpreter for you? I think that service is the one where the root directory for customers logged in with a shell is the same as the one for the web-server, so /bin/sh is available, so that trick may very well be in use. But yes, I don't want to be in the position of still having /bin/perl be v4 in five years time. But, given the workload in working through 1,500 customers' scripts, you'd be looking at: * people to co-ordinate this with the customers * people to fix the scripts * people to test which leaves you with one of: * heavier workloads for various departments, perhaps an extra employee in various places, just for upgrading perl * a dedicated temporary team, hired to manage this upgrade Methinks it would be more appropriate, given out situation, to find a way to get permission to automatically replace /bin/perl with /bin/perl4, do so, run some scripts which try to look for monstrosities like scripts which invoke perl interpreters, fix those, remove the /bin/perl link and then just never ever let /bin/perl exist again. > I think you are on right track with phase-out policy. It really is > a business service issue and needs to be addressed that way. What > do you provide, etc And this is much easier if you can manage easily which version of perl is being used. So, when someone asks how to go about things, they can get one of three responses from me: * silence (I'm too busy) * just install /bin/perl (I really don't like them) * the advice I gave about numbered versions (I'm in a helpful mood and trying to save them headaches later) Relying on timely response from customers from customers does not scale. Searching for a magic bullet is naive. Trying to design things right first time isn't perfect, but it makes life easier in the long run, at the expense of more work at start-up time. -- 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
Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, John Haggerty produced the immortal words: > Is there say a test that can be implimented that would test to determine > wheather the program you are running will work under perl and > then pick that version of perl? That would really rock and would possibly > be quite easy considering perl is a great tool for text manipulation and > analysis. At run-time of request? Erk! If you're using a web-server which pre-determines mime-types, such as wn, you could conceivable use perl_version -c script, making sure that you handle -T (taint-checking) on the command-line. But if the script is syntactically valid in a version where it would actually fail, then your "test" becomes a competent human perl programmer. Or non-human, if you employ such. The best way IME is to not have /bin/perl exist - always encode the version number, and let the #! line be your switch for picking the perl version. Oh, and the boss says that we have a large proportion of 1,500 customers of the relevant service whose scripts all date from perl4-only days and if I want to phase out /bin/perl as perl4 then I can do it all by myself. I think that fairly neatly ends that discussion - I'm already trying to juggle too many things at work. -- 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
Re: it's safe to run a web hosting server with the unstable distributions ?
On Mon, Apr 10, 2000 at 07:01:04PM +0200, Phil Pennock wrote: > Typing away merrily, [EMAIL PROTECTED] produced the immortal words: > > 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**. > > We found with experience that this doesn't scale all that well. Mind, > I work for a reasonably large ISP. > > When you have large corporate customers who make money from their sites, > they can be _very_ reluctant to make changes. Policy be damned if it's > not utterly and clearly specified in the contract and your customers > lose a few cents. :^( > > Result: despite trying to ensure /bin/perl5.003_03 etc, the fact that > we'd previously had /bin/perl as perl4 means that we had to give in and > put it back as just that. Unfortunately, this means that customers who > don't read the docs and just type /bin/perl get perl4. :^( Legacy > support is a problem, and a large one, which applies to more than just > web-sites. This is part of what support-departments are for, though - > pointing out to customers the stuff which is already documented clearly. > *coughs* > > I tried suggesting a phase-out policy for the contracts. I don't think > our contracts have that, unfortunately. Certainly not the oldest ones, > who are the ones most likely to be using perl4, etc. > > Hrm .. time to talk to the boss about having another go at phasing out > perl4 on the servers ... So perl is perl4. That creates problems for users typing in perl and expecting it to work. At a certain point it is simply cheaper for you to bite the bullet and upgrade them for free, no? Because you are starting to twist everything else too. And then when you do that free upgrade all of a sudden you own everything else that goes wrong too, even if you made **less** go wrong. Been there - we start year 7 on May 1. :-) I think you are on right track with phase-out policy. It really is a business service issue and needs to be addressed that way. What do you provide, etc -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Database publishing, e-commerce, office/internet integration, Debian linux.
Re: it's safe to run a web hosting server with the unstable distributions ?
On Mon, 10 Apr 2000, John Haggerty wrote: > Is there a good example of something in debian breaking a general > script/program server side? In the past, the upgrade of libmysqlclient.so.6 caused grief for most packages that version-depended on libmysqlclient.so.4. Having a non-production computer that gets upgraded first (personal discipline) lets you avoid some "bad timing" upgrades. I use my own box for that. With Debian, besides the stable and unstable distros, there is also "frozen" ... the soon-to-be-stable (AKA potato) that has been in "code freeze" since Jan 16. Usually (I've been through a couple), by the time it is frozen for a while the most significant problems have been eliminated. It seems to me that most of the time the dist is in frozen, the maintainers are concentrating on ensuring all the package inter-dependencies are resolved ... and slipping in bugfixes from upstream maintainers. If I was to do a new distribution install today, I would go with frozen. It has the 2.2.x kernel, the recent glibc and some configuration stuff which will ease future maintenance. --- Gerard MacNeil, P. Eng [EMAIL PROTECTED] System Administrator Supercity Internet Services http://www.supercity.ns.ca
Re: it's safe to run a web hosting server with the unstable distributions ?
Is there say a test that can be implimented that would test to determine wheather the program you are running will work under perl and then pick that version of perl? That would really rock and would possibly be quite easy considering perl is a great tool for text manipulation and analysis. On Mon, 10 Apr 2000, Phil Pennock wrote: > Typing away merrily, [EMAIL PROTECTED] produced the immortal words: > > 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**. > > We found with experience that this doesn't scale all that well. Mind, > I work for a reasonably large ISP. > > When you have large corporate customers who make money from their sites, > they can be _very_ reluctant to make changes. Policy be damned if it's > not utterly and clearly specified in the contract and your customers > lose a few cents. :^( > > Result: despite trying to ensure /bin/perl5.003_03 etc, the fact that > we'd previously had /bin/perl as perl4 means that we had to give in and > put it back as just that. Unfortunately, this means that customers who > don't read the docs and just type /bin/perl get perl4. :^( Legacy > support is a problem, and a large one, which applies to more than just > web-sites. This is part of what support-departments are for, though - > pointing out to customers the stuff which is already documented clearly. > *coughs* > > I tried suggesting a phase-out policy for the contracts. I don't think > our contracts have that, unfortunately. Certainly not the oldest ones, > who are the ones most likely to be using perl4, etc. > > Hrm .. time to talk to the boss about having another go at phasing out > perl4 on the servers ... > -- > 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, [EMAIL PROTECTED] produced the immortal words: > 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**. We found with experience that this doesn't scale all that well. Mind, I work for a reasonably large ISP. When you have large corporate customers who make money from their sites, they can be _very_ reluctant to make changes. Policy be damned if it's not utterly and clearly specified in the contract and your customers lose a few cents. :^( Result: despite trying to ensure /bin/perl5.003_03 etc, the fact that we'd previously had /bin/perl as perl4 means that we had to give in and put it back as just that. Unfortunately, this means that customers who don't read the docs and just type /bin/perl get perl4. :^( Legacy support is a problem, and a large one, which applies to more than just web-sites. This is part of what support-departments are for, though - pointing out to customers the stuff which is already documented clearly. *coughs* I tried suggesting a phase-out policy for the contracts. I don't think our contracts have that, unfortunately. Certainly not the oldest ones, who are the ones most likely to be using perl4, etc. Hrm .. time to talk to the boss about having another go at phasing out perl4 on the servers ... -- 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
Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, John Haggerty produced the immortal words: > Then you could have the solution of say changing the name of the package > to perhaps reflect that in fact you have perl4 or something and just > install incremental upgrades for the packages that aren't prone to > breakage. Eventually as people upgrade their stuff. You could slowly > retire the old stuff while supporting the new. Erm, as I understand what I wrote, that's part of what I said: > 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). >From the Date: header in your mail, I see that it's still morning there. Monday-morning. This explains a lot. :^) Another coffee? (Note that I also warned about libperl - we recently got caught by this, more than once. The best solution seems to be static compilation of perl. Forcing perl to be entirely static is apparently not as straight-forward as it should be; I don't know, though, as a couple of colleagues handled this) -- 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
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**. cfm 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 [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Database publishing, e-commerce, office/internet integration, Debian linux.
Re: it's safe to run a web hosting server with the unstable distributions ?
Then you could have the solution of say changing the name of the package to perhaps reflect that in fact you have perl4 or something and just install incremental upgrades for the packages that aren't prone to breakage. Eventually as people upgrade their stuff. You could slowly retire the old stuff while supporting the new. On Mon, 10 Apr 2000, Phil Pennock wrote: > Typing away merrily, John Haggerty produced the immortal words: > > Is there a good example of something in debian breaking a general > > script/program server side? > > Not that comes to mind. > > But what happens when, eg, perl is upgraded to 5.6? The perl4 -> perl5 > transition broke enough stuff. Will this new one break things? If so, > will Debian fork perl just to maintain backwards compatibility? > > The ISP where I work still has perl4 on its servers, for this very > reason. When a customer has something which works, they can be very > reluctant to make modifications just to use a newer version. > > Predicting the future is tricky. Being defensive in the way that you > set things up can help you bypass some of the uncertainty. > > Defensive SysAdmin-ing as opposed to Defensive Programming. :^) > -- > 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, John Haggerty produced the immortal words: > Is there a good example of something in debian breaking a general > script/program server side? Not that comes to mind. But what happens when, eg, perl is upgraded to 5.6? The perl4 -> perl5 transition broke enough stuff. Will this new one break things? If so, will Debian fork perl just to maintain backwards compatibility? The ISP where I work still has perl4 on its servers, for this very reason. When a customer has something which works, they can be very reluctant to make modifications just to use a newer version. Predicting the future is tricky. Being defensive in the way that you set things up can help you bypass some of the uncertainty. Defensive SysAdmin-ing as opposed to Defensive Programming. :^) -- 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
Re: it's safe to run a web hosting server with the unstable distributions ?
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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: it's safe to run a web hosting server with the unstable distributions ?
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
Re: it's safe to run a web hosting server with the unstable distributions ?
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. On Mon, 10 Apr 2000, Jaume Teixi wrote: > or better frozen or stable ? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
it's safe to run a web hosting server with the unstable distributions ?
or better frozen or stable ?
