Re: won't stay connected to isp
Well assuming your ISP actually supports 2400 baud connections to it's dialup then you might have a little problem. Usually if you can't even connect properly you do not possess a fast enough connection (I have a 2400 as well and I tried to connect to a service that supposedly was up to 33.3 and it wouldn't accept my connection. On Thu, 13 Apr 2000, Sheri wrote: > I'm running Linux on a 486 laptop with a 2400 > baud modem, and I haven't been able to stay > connected to any isp. > > When I used minicom to connect, I get a prompt > for user name and password, then I get a message > saying ppp is starting and then garbage on the > screen for about a minute, then it disconnects. > > When I use pon, the log says something like sending > LCD packet, receiving LCD packet, a few times, then > I'm disconnected. > > I know this isp uses PAP, and I've used pppconfig over and > over to try and get this to work, but no luck. Any suggestions > for changes to my scripts? > > Thanks, > Sheri > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: FTP upload by email
Not off the top of my head. I know of programs that have been floating around to facilitate the transfer of files from anonymous (and possible authenticated) ftp sites to the email address of the user. The options were a little vague and I decided against it for various reasons. One of the biggest problems with this is security. How will you secure the transfer of the files to the user's account when they are e-mailed? How will you be able to cope with say someone trying to stuff massive quantities of data (say the uuencoded version of the emacs and the linux kernel cat'ed together). The only plausible method would be to somehow get a program that allowed only inbound ftp-email traffic from certain "trusted" hosts and only by issuing say temporary passwords. If anyone is going to be monitoring your e-mail traffic they might get more than auth thelma's recipe for bundt cake if you get my drift. On Thu, 13 Apr 2000 [EMAIL PROTECTED] wrote: > Hi, > > I need a programm with which I can upload files by email. I want to pipe > the mails to its stdin and it should put it to a special directory or what > ever. > > any open source software like that ? > > Kind regards, > achim hendriks > mediagenic services > > > > -- > 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 ?
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 ?
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 ?
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 ?
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 ?
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] >
