Re: Woody+Testing Apache Segmentation Fault
Jacob S. wrote: Has anybody seen this before? I have not experienced this problem before, but I have seen several threads here on Debian-user that resolved it by uninstalling the php4-imap package. Alternatively, you should be able to simply disable php4-imap in your php.ini file to see if it is the problem. HTH, Jacob I've seen this problem as well; I don't remember what module it was, but try commenting out all modules from the php.ini and enabling them one by one if it's not the php-imap module. Maarten
Re: Intel Hyperthreading problem on server?
On Wed, 16 Jun 2004 09:18:07 +0800, Jason Lim [EMAIL PROTECTED] wrote: Dear Gilles , I'll try as well... hope we can find a solution. I have a few Redhat Linux 9 servers with Hyperthreading CPUs, and no problem whatsoever. I think they run Apache 2, so maybe that is the solution... but surely there must be people running Apache 1.x without any problem and hyperthreading?! Jas We're running Debian with a custom 2.4.26 kernel on a couple of dual Xeon's, with apache 1.3.x without any problem. I'll admit that these are ligtly loaded servers for now, but we've done some stress testing before they went into production and never saw this problem. Maarten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Hyperthreading problem on server?
On Wed, 16 Jun 2004 09:18:07 +0800, Jason Lim [EMAIL PROTECTED] wrote: Dear Gilles , I'll try as well... hope we can find a solution. I have a few Redhat Linux 9 servers with Hyperthreading CPUs, and no problem whatsoever. I think they run Apache 2, so maybe that is the solution... but surely there must be people running Apache 1.x without any problem and hyperthreading?! Jas We're running Debian with a custom 2.4.26 kernel on a couple of dual Xeon's, with apache 1.3.x without any problem. I'll admit that these are ligtly loaded servers for now, but we've done some stress testing before they went into production and never saw this problem. Maarten
Re: Exim AUTH with PAM - pls. HELP
Johannes Formann wrote: Franz Georg Köhler [EMAIL PROTECTED] wrote: I bett exim can't read /etc/shadow, make it readable to exim, oder compile and install pam_exim. IIRC, you need to run Exim as root to enable PAM functionality. Regards, Maarten
Re: Why doesn't Exim ever clean out /var/spool/exim/input?
Joe Emenaker wrote: Yeah... well... I've already moved every other machine I deal with over to Courier. I like it because it's one-stop-shopping for all of my mail needs (ie, smtp, pop, and imap modules as well as an ssl version of each), because it supports authenticated smtp (which I understand Exim4 does now but too late for me), and also because it has a variety of authentication methods. FWIW, Exim 3 supports authentication as well... We're using: Exim version 3.35 #1 built 05-Sep-2003 13:52:12 Copyright (c) University of Cambridge 2001 If anyone needs help setting this up please let me know. Maarten Vink -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why doesn't Exim ever clean out /var/spool/exim/input?
Joe Emenaker wrote: Yeah... well... I've already moved every other machine I deal with over to Courier. I like it because it's one-stop-shopping for all of my mail needs (ie, smtp, pop, and imap modules as well as an ssl version of each), because it supports authenticated smtp (which I understand Exim4 does now but too late for me), and also because it has a variety of authentication methods. FWIW, Exim 3 supports authentication as well... We're using: Exim version 3.35 #1 built 05-Sep-2003 13:52:12 Copyright (c) University of Cambridge 2001 If anyone needs help setting this up please let me know. Maarten Vink
Re: Moving Sites
Tarragon Allen wrote: On Tuesday 21 October 2003 13:43, Rod Rodolico wrote: Guess is boils down to this. When I update the address of mail.dailydata.net, it can take up to 72 hours for that change to perculate throughout the net, so I'm assuming some places will still try to send to the old IP and, if I leave that box on, be delivered to it. If I turn the other box off, I'm assuming they will bounce. No they won't bounce; most mailservers will leave messages in their queues for up to 5 days when your machine is down. If you lower the TTL for mail.dailydata.net it shouldn't take 72 hours either. Put the IP address of the old site on the new mail server when you bring down the old one, and then change your DNS entry, wait three days, then drop the old IP address. Alternatively, set up a redirector on the old mail server to forward traffic to the new mail server (using 'redir' or something similar). Or even easier: assuming the machines are in the same subnet, why not add the IP address of the old server to the new one, on eth0:1 or any other alias for your primary NIC? Both traffic to the old and the new IP will end up on the right server, and you can easily back out if there is a problem by removing the alias. Maarten Vink -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving Sites
Tarragon Allen wrote: On Tuesday 21 October 2003 13:43, Rod Rodolico wrote: Guess is boils down to this. When I update the address of mail.dailydata.net, it can take up to 72 hours for that change to perculate throughout the net, so I'm assuming some places will still try to send to the old IP and, if I leave that box on, be delivered to it. If I turn the other box off, I'm assuming they will bounce. No they won't bounce; most mailservers will leave messages in their queues for up to 5 days when your machine is down. If you lower the TTL for mail.dailydata.net it shouldn't take 72 hours either. Put the IP address of the old site on the new mail server when you bring down the old one, and then change your DNS entry, wait three days, then drop the old IP address. Alternatively, set up a redirector on the old mail server to forward traffic to the new mail server (using 'redir' or something similar). Or even easier: assuming the machines are in the same subnet, why not add the IP address of the old server to the new one, on eth0:1 or any other alias for your primary NIC? Both traffic to the old and the new IP will end up on the right server, and you can easily back out if there is a problem by removing the alias. Maarten Vink