Re: COMMERCIAL: Anyone leasing a debian server?
Hi, Zentek International does provide such a service using Debian servers. If you would like more information, just mail me directly at [EMAIL PROTECTED] As for the availability of other companies using Debian, i can tell you that you'd be hard pressed to find even a handful. I think they use Redhat because that is now the trusted distribution in most people's eyes, and it would be foolish for an ISP to go with a rogue distro. Oh well... - Original Message - From: Sanjeev Gupta [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Sunday, April 09, 2000 5:53 PM Subject: COMMERCIAL: Anyone leasing a debian server? Folks, Apologies for the UCE. I need to lease a Linux server. All the sites I have seen seem to be offerring RedHat only. As you guys are on the _Debian_ list, perhaps you can contact me? I need a basic Intel box, running 2.1, 64MB, 4-6GB, 8IP. I will do all admin myself. Private mail, please. In case there are issues of a non-personal nature, I will summarize and post to the list. Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Strange message in logs
Hi! I get the following error messages in my log: Apr 9 06:47:39 ns tcp-env[17281]: warning: /etc/hosts.allow, line 11: can't verify hostname: gethostbyname(114.trusted.net) failed Apr 9 06:47:40 ns tcp-env[17281]: refused connect from 209.140.0.114 Apr 9 06:56:54 ns tcp-env[17346]: connect from murphy.debian.org Apr 9 06:58:38 ns tcp-env[17364]: warning: /etc/hosts.allow, line 11: can't verify hostname: gethostbyname(114.trusted.net) failed Apr 9 06:58:38 ns tcp-env[17364]: refused connect from 209.140.0.114 Is this because my hosts.deny file is set to ALL: PARANOID (this is the only line apart from comments and is line 9) My hosts.allow has the following in line 11: ALL: .mydomain.com.au Is there a way to fix this, as I am assuming that the machine that is denied access cannot access my server to browse a web page or send e-mail. This message seems to crop up when someone tries to send email mainly. I am running Debian 1.3 (but some parts are Hamm (eg: libraries are lib.so.6), apache and qmail. Rob...
Re: COMMERCIAL: Anyone leasing a debian server?
I checked the communitech.net website... such as at their dedicated server webpage (http://www.communitech.net/hosting/dedicated/unix/packages.cgi ) and they all stated they run Redhat 6.1. Maybe you could direct us to the correct webpage for debian hosting? Actually... are they one and the same company? Check out http://www.communitech.net/hosting/virtual/ and http://www.nextvision.net/webhosting/resellers/ , on the different websites. Notice the SAME chequered graphic (the one with red x crosses). The graphic is IDENTICAL on both websites. Pretty strange. Sorry if i'm not looking at the right pages, but i look all around and couldn't find it. - Original Message - From: Andy Gardner [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Monday, April 10, 2000 12:18 PM Subject: Re: COMMERCIAL: Anyone leasing a debian server? Hi, Zentek International does provide such a service using Debian servers. If you would like more information, just mail me directly at [EMAIL PROTECTED] As for the availability of other companies using Debian, i can tell you that you'd be hard pressed to find even a handful. I use nextvision.net and communitech.net -- Andrew P. Gardner Never underestimate the power of stupid people in large groups. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tracing a PERL cgi script
From: Chad A. Adlawan [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Monday, April 10, 2000 1:30 PM Subject: tracing a PERL cgi script hello, were trying oto debug this _big_ PERL web application (lots of forms, etc, whatever) and it seems like were really lost w/ its code. is there any way that you can do a line by line trace when a PERL code is executed on the web that way, we'll have some idea w/c goes where ? if you use the CGI module: perl -d -w script.pl name=value name=value... Damyan Ivanov [EMAIL PROTECTED]
Re: Strange message in logs
Typing away merrily, Robert Ruzbacky produced the immortal words: Apr 9 06:47:39 ns tcp-env[17281]: warning: /etc/hosts.allow, line 11: can't verify hostname: gethostbyname(114.trusted.net) failed Apr 9 06:47:40 ns tcp-env[17281]: refused connect from 209.140.0.114 Apr 9 06:56:54 ns tcp-env[17346]: connect from murphy.debian.org Apr 9 06:58:38 ns tcp-env[17364]: warning: /etc/hosts.allow, line 11: can't verify hostname: gethostbyname(114.trusted.net) failed Apr 9 06:58:38 ns tcp-env[17364]: refused connect from 209.140.0.114 Is this because my hosts.deny file is set to ALL: PARANOID No. Your DNS setup is broken. % host -t ptr 209.140.0.114 Name: 114.trusted.net Address: 209.140.0.114 % host 114.trusted.net 114.trusted.net does not exist (Authoritative answer) You need forward DNS which matches the reverse. Otherwise, an attacker could do something like the following ... goodppl.example.net has 192.168.1/24 badppl.example.net have 192.168.6/24 Set reverse DNS for 192.168.6.66 to point to ours.goodppl.example.net. Hey presto, badppl can bypass all your filters easily, and nothing you can do about it. Matching forward and reverse DNS is a Good Thing(tm). -- 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: COMMERCIAL: Anyone leasing a debian server?
I checked the communitech.net website... such as at their dedicated server webpage (http://www.communitech.net/hosting/dedicated/unix/packages.cgi ) and they all stated they run Redhat 6.1. Maybe you could direct us to the correct webpage for debian hosting? http://www.communitech.net/hosting/dedicated/quote/index.php3 Custom built server. I went for hardware RAID1 (IDE card) and loads of memory. They tried, but failed to get the SCSI RAID card going on Debian. Actually... are they one and the same company? Check out http://www.communitech.net/hosting/virtual/ and http://www.nextvision.net/webhosting/resellers/ , on the different websites. Notice the SAME chequered graphic (the one with red x crosses). The graphic is IDENTICAL on both websites. Heh. Clipart? Communitech.net hosts out of Missouri, Nextvision.net from Arizona. Nextvision claim (or used to claim) to have 24/7 tech support, but when my machine curled up its toes 10pm Friday night recently, despite panic emails, faxes and phone calls, it didn't get re-booted until Monday morning, and no apology email was received. Due to this, I'd suggest communitech as a first choice. -- Andrew P. Gardner Never underestimate the power of stupid people in large groups.
it's safe to run a web hosting server with the unstable distributions ?
or better frozen or stable ?
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]
Re: tracing a PERL cgi script
Typing away merrily, Chad A. Adlawan produced the immortal words: were trying oto debug this _big_ PERL web application (lots of forms, etc, whatever) and it seems like were really lost w/ its code. is there any way that you can do a line by line trace when a PERL code is executed on the web that way, we'll have some idea w/c goes where ? Do you control the programs installed on the server? If so, install a second copy of perl, one with debugging support enabled. Then go and read perlrun(1) for information on -D switches. Eg, #!/bin/perl_debug -Dtls -- 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: 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 ?
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: 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 ?
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 ?
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 ?
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 ?
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 ?
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 perlwhatever 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 ?
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, 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 ?
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 toothnail. 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 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
