How to connect Apache2 to Tomcat4?
Is anyone else using Apache2 with Tomcat4? I've been trying to find an appropriate connector to use between them. I've found references on Google to things like libapache2-mod-jk2, libapache2-mod-webapp, or libapache2-mod-jk, but I haven't been able to find any of them in stable or unstable... and I can't even find anything at www.apt-get.org. It seems that my only two options are to: 1 - Tell Apache to do a Redirect for anything involving .jsp to Tomcat's HTTP port (which, if it didn't cause other problems, would cause my Apache logs to be missing most of the webapp traffic... since the logs would have the initial redirect, but not the traffic after that). 2 - Go compile libapache-mod-jk2 or libapache-mod-webapp by hand, which is likely to be a bigger pain in the butt than I want to bother with. I'm eagerly waiting for a third option. - Joe
How to connect Apache2 to Tomcat4?
Is anyone else using Apache2 with Tomcat4? I've been trying to find an appropriate connector to use between them. I've found references on Google to things like libapache2-mod-jk2, libapache2-mod-webapp, or libapache2-mod-jk, but I haven't been able to find any of them in stable or unstable... and I can't even find anything at www.apt-get.org. It seems that my only two options are to: 1 - Tell Apache to do a Redirect for anything involving .jsp to Tomcat's HTTP port (which, if it didn't cause other problems, would cause my Apache logs to be missing most of the webapp traffic... since the logs would have the initial redirect, but not the traffic after that). 2 - Go compile libapache-mod-jk2 or libapache-mod-webapp by hand, which is likely to be a bigger pain in the butt than I want to bother with. I'm eagerly waiting for a third option. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Starting isp and going to use Debian
Nicolas Rueff wrote: Anyway, my question is what software do most of you use? Obviously, we have decided to use Debian for our base os. However, what do most of you use for: 1. Webmail Imp. Works well. Really. I've had a lot of headaches with Imp. Imp relies on Horde being correctly setup. It seems that, every time I do an update of my packages to the latest .deb's, Imp and Horde break. I have to completely purge it, and re-install it... and that fixes it about half the time. The other half, I have to wait a few weeks for something to get fixed in Imp or Horde. Sometimes, it's a clear error, where I get an error page about how it can't find some .php file in its path. Other times (most of the time, lately), it just says that my username/password combination we wrong and it dumps me back to the login screen. When it works, however, it *is* cool... all the features you can set (you can restrict what IMAP servers the user can connect to, for example..). The newer Imp3 and Horde2 are even cooler, because Horde2 now has more cool PIM plugins, like the calendaring tool. However, like I said... it's broken most of the time on our servers. Instead, I direct our users to Squirrelmail. It's more basic... but that's its strength, I guess. Less chance to break. 2. Imap/pop access Courier, definitely. Virtual-user based conf. I use Courier, too. I like it because it's one-stop shopping. Courier has SMTP, secure-SMTP, SMTP authentication, POP, secure-POP, IMAP, and secure-IMAP. A world of difference from having to use, say, Exim for SMTP and UW-IMAP and UW-IMAP-SSL. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Solving "Address already in use"
Michael Wood wrote: On Fri, Feb 06, 2004 at 03:34:04PM -0800, Joe Emenaker wrote: Is there a better way, these days? Can I forcibly "un-use" the port? If not, can I, at the least, find out what process ID's the kernel thinks have it open? It will time out after a while. How long is "a while"? We waited three days before giving up and rebooting the server. - Joe
Re: Solving "Address already in use"
Michael Wood wrote: On Fri, Feb 06, 2004 at 03:34:04PM -0800, Joe Emenaker wrote: Is there a better way, these days? Can I forcibly "un-use" the port? If not, can I, at the least, find out what process ID's the kernel thinks have it open? It will time out after a while. How long is "a while"? We waited three days before giving up and rebooting the server. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Solving "Address already in use"
Here's a wierd one. Our SpamAssassin daemon crashed and, when I tried to restart it, I got: Could not create INET socket: Address already in use IO::Socket::INET: Address already in use ... and I can't find any running spamd, so it looks like it's a stuck socket. I haven't seen one of these for a long time but, in the past, we'd have to reboot the machine in order to fix it. Is there a better way, these days? Can I forcibly "un-use" the port? If not, can I, at the least, find out what process ID's the kernel thinks have it open? - Joe
Solving "Address already in use"
Here's a wierd one. Our SpamAssassin daemon crashed and, when I tried to restart it, I got: Could not create INET socket: Address already in use IO::Socket::INET: Address already in use ... and I can't find any running spamd, so it looks like it's a stuck socket. I haven't seen one of these for a long time but, in the past, we'd have to reboot the machine in order to fix it. Is there a better way, these days? Can I forcibly "un-use" the port? If not, can I, at the least, find out what process ID's the kernel thinks have it open? - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [courier-users] FW: amavis
Kóczán Péter wrote: I have a problem regarding to amavis. I've configured it for courier and the config file is ok, however amavis does not run, when i execute amavis, it gives the following error: AMAVIS: Couldn't init AMAVIS::MTA::Courier: Invalid argument at /usr/share/perl/AMAVIS.pm line 235, line 520. I use Debian Amavis, but courier is not the .deb version but the source version. I get the same problem trying to use Amavis configured for Courier or Exim or a variety of others. The first working solution I came upon was to configure Amavis to work with "Maildrop". Then, I told Courier to use Maildrop to deliver local mail. As the last step, I made a /etc/courier/maildroprc file that looks like this: import SENDER xfilter "/usr/bin/spamc -s 20480" xfilter "/usr/bin/amavis" - Joe
Re: [courier-users] FW: amavis
Kóczán Péter wrote: I have a problem regarding to amavis. I've configured it for courier and the config file is ok, however amavis does not run, when i execute amavis, it gives the following error: AMAVIS: Couldn't init AMAVIS::MTA::Courier: Invalid argument at /usr/share/perl/AMAVIS.pm line 235, line 520. I use Debian Amavis, but courier is not the .deb version but the source version. I get the same problem trying to use Amavis configured for Courier or Exim or a variety of others. The first working solution I came upon was to configure Amavis to work with "Maildrop". Then, I told Courier to use Maildrop to deliver local mail. As the last step, I made a /etc/courier/maildroprc file that looks like this: import SENDER xfilter "/usr/bin/spamc -s 20480" xfilter "/usr/bin/amavis" - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Stopping Exim from sending "Message frozen" messages...
Okay since I had a 3-year-old Exim configuration file, I decided to take a brand-new one and then use "diff" to find what I needed to move over. Hopefully now, it is rejecting bad recipients at SMTP time. However, it's also sending me "Message frozen" messages every time it freezes something. Does anybody know, off hand, how to turn this off? - Joe
Stopping Exim from sending "Message frozen" messages...
Okay since I had a 3-year-old Exim configuration file, I decided to take a brand-new one and then use "diff" to find what I needed to move over. Hopefully now, it is rejecting bad recipients at SMTP time. However, it's also sending me "Message frozen" messages every time it freezes something. Does anybody know, off hand, how to turn this off? - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting up hosting server
Tommy Moore wrote: but what will I use for hosting the e-mail accounts? Also what are my options for a web based interface to these e-mail accounts as well as a control pannel for my users to create e-mail addresses for their domains? Well, Courier lets you have "true" virtual accounts. By that, I mean that the *users* log in with their full e-mail address to retrieve their mail. This allows you to let people log in as "[EMAIL PROTECTED]". Some people regard this as the optimum solution, but I don't. The problem, coming from someone who's a bit of an "accountability nazi", is that the username and password for a "[EMAIL PROTECTED]" account is much more likely to be shared amongst a few people at the company. So if, in the future, there arises a case of abuse of the account, it's tough to figure out who the culprit is. You also run into similar problems if one of the people with the password is terminated; the password needs to be changed and you have to notify everyone who's supposed to have access to the account. So, I regard that as kind of a bad way of doing things. Personally, the way I do it at my isp is that *every* account that can *retrieve* mail maps back to a *single* user (ie, "bsmith", "dwatson", etc.). Because we set this up years ago, before domain-specific logins were in vogue, these were system-wide accounts (ie, they're in /etc/passwd). The problem this presents is that, if one hosted company had a "Brad Smith" and another company has a "Brian Smith", then the first comer is going to get "bsmith" and the next is probably going to get "brsmith" or something. Yes, this is "old school" but that's how I am. So then, the *incoming* domain-specific stuff is handled in alias files. It's actually kinda clever, I think. I use Exim and Exim looks to a file to determine which domains are local. I call this file "/etc/exim.domains". The format of the file looks like: *.somecompany.com somecompany.com.aliases *.company2.com company2.com.aliases *.company3.com company3.com.aliases then, each aliases file has the aliases for that domain, like a normal aliases file, so "company2.com.aliases" might have: help: bsmith custsvc: rjones *: rjones The nice thing is the catch-all wildcard at the bottom for all other mail to that domain. Another nice thing is that, if you do it right, you can have the global /etc/aliases pre-empt the domain-specific ones, so that mail to "postmaster" at any of the domains would come to the sysadmin. Again, this is prety old-school. It's all text files (no database structure to have wrong) and it's easy to edit and you don't have to HUP any daemons of regenerate any db files (like sendmail's or Courier's "newaliases"). That's just how I do it right now - Joe
Re: Setting up hosting server
Tommy Moore wrote: but what will I use for hosting the e-mail accounts? Also what are my options for a web based interface to these e-mail accounts as well as a control pannel for my users to create e-mail addresses for their domains? Well, Courier lets you have "true" virtual accounts. By that, I mean that the *users* log in with their full e-mail address to retrieve their mail. This allows you to let people log in as "[EMAIL PROTECTED]". Some people regard this as the optimum solution, but I don't. The problem, coming from someone who's a bit of an "accountability nazi", is that the username and password for a "[EMAIL PROTECTED]" account is much more likely to be shared amongst a few people at the company. So if, in the future, there arises a case of abuse of the account, it's tough to figure out who the culprit is. You also run into similar problems if one of the people with the password is terminated; the password needs to be changed and you have to notify everyone who's supposed to have access to the account. So, I regard that as kind of a bad way of doing things. Personally, the way I do it at my isp is that *every* account that can *retrieve* mail maps back to a *single* user (ie, "bsmith", "dwatson", etc.). Because we set this up years ago, before domain-specific logins were in vogue, these were system-wide accounts (ie, they're in /etc/passwd). The problem this presents is that, if one hosted company had a "Brad Smith" and another company has a "Brian Smith", then the first comer is going to get "bsmith" and the next is probably going to get "brsmith" or something. Yes, this is "old school" but that's how I am. So then, the *incoming* domain-specific stuff is handled in alias files. It's actually kinda clever, I think. I use Exim and Exim looks to a file to determine which domains are local. I call this file "/etc/exim.domains". The format of the file looks like: *.somecompany.com somecompany.com.aliases *.company2.com company2.com.aliases *.company3.com company3.com.aliases then, each aliases file has the aliases for that domain, like a normal aliases file, so "company2.com.aliases" might have: help: bsmith custsvc: rjones *: rjones The nice thing is the catch-all wildcard at the bottom for all other mail to that domain. Another nice thing is that, if you do it right, you can have the global /etc/aliases pre-empt the domain-specific ones, so that mail to "postmaster" at any of the domains would come to the sysadmin. Again, this is prety old-school. It's all text files (no database structure to have wrong) and it's easy to edit and you don't have to HUP any daemons of regenerate any db files (like sendmail's or Courier's "newaliases"). That's just how I do it right now - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Exim: Different mail retry times depending upon response from remote host...
Craig Sanders wrote: On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote: Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. why should there be? All 5xx codes are permanent failures. the MTA should bounce back to sender immediately. All 4xx codes are temporary failures. the MTA should (optionally) retry later, but eventually bounce back to sender if not delivered in X hours/days. Because, like you mentioned later in your message, not all mailers give proper responses. For example, I've see a lot of 5xx codes where the verbal explanation is that the user is over quota. But the *real* problem, I guess, is that I'm seeing so many 5xx's in /var/spool/exim/msglog at *all*. If the sender address is bogus, the bounce notification just hangs around forever, it seems. I'd like to be able to give bounce notifications avout 4 hours to be delivered and then, buh'bye. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. these sound like 5xx errors, rather than 4xx. exim should be bouncing these, if the remote systems are issuing the correct error codes.if they aren't, there's little you can do about it. Except write a script, I guess. :) one possibility is that there is some error in your configuration which is making permanent errors be treated as temporary (4xx) errors, Well, I haven't tweaked our config too much... BUT it's the config file from when we switched to Exim about 4 years ago, and I haven't allowed Debian to overwrite it with a new one (lest we lose our mods to the config file). So, it might be time to get a new config file and move our changes over by hand. But... if we're going through that much trouble geez... I'd just switch to Courier. - Joe
Re: Exim: Different mail retry times depending upon response from remote host...
Craig Sanders wrote: On Wed, Jan 28, 2004 at 07:23:50PM -0800, Joe Emenaker wrote: Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. why should there be? All 5xx codes are permanent failures. the MTA should bounce back to sender immediately. All 4xx codes are temporary failures. the MTA should (optionally) retry later, but eventually bounce back to sender if not delivered in X hours/days. Because, like you mentioned later in your message, not all mailers give proper responses. For example, I've see a lot of 5xx codes where the verbal explanation is that the user is over quota. But the *real* problem, I guess, is that I'm seeing so many 5xx's in /var/spool/exim/msglog at *all*. If the sender address is bogus, the bounce notification just hangs around forever, it seems. I'd like to be able to give bounce notifications avout 4 hours to be delivered and then, buh'bye. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. these sound like 5xx errors, rather than 4xx. exim should be bouncing these, if the remote systems are issuing the correct error codes.if they aren't, there's little you can do about it. Except write a script, I guess. :) one possibility is that there is some error in your configuration which is making permanent errors be treated as temporary (4xx) errors, Well, I haven't tweaked our config too much... BUT it's the config file from when we switched to Exim about 4 years ago, and I haven't allowed Debian to overwrite it with a new one (lest we lose our mods to the config file). So, it might be time to get a new config file and move our changes over by hand. But... if we're going through that much trouble geez... I'd just switch to Courier. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Exim: Different mail retry times depending upon response from remote host...
You don't have to be a rocket scientist to realize that the following remote mailer messages give varying degrees of optimism regarding future delivery: 550 Requested action not taken: mailbox unavailable 452 Mailbox full 452 Insufficient disk space; try again later 421 Too many concurrent SMTP connections; please try again later. With the first, you're pretty sure that the problem is *not* going to be corrected in the next few days. Meanwhile, the others give you some hope in waiting. Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. But I figured I'd ask... does anybody already have a script for doing this (or maybe a better way altogether, since this script has to be explicitly run periodically)? - Joe
Exim: Different mail retry times depending upon response from remote host...
You don't have to be a rocket scientist to realize that the following remote mailer messages give varying degrees of optimism regarding future delivery: 550 Requested action not taken: mailbox unavailable 452 Mailbox full 452 Insufficient disk space; try again later 421 Too many concurrent SMTP connections; please try again later. With the first, you're pretty sure that the problem is *not* going to be corrected in the next few days. Meanwhile, the others give you some hope in waiting. Unfortunately, I haven't seen anything in Exim that lets you customize it's retry behavior based upon this. It does offer an "error" field in the retry section, but it's only for some silly hard-coded failure types. So, I wrote a little script that goes through all of the msglog files and finds good candidates to toss (ie, "No such user", "Account Terminated", etc.). With just a day's worth of tweaking the script, I've managed to get the pending queue down to about 1/3 of what it was. But I figured I'd ask... does anybody already have a script for doing this (or maybe a better way altogether, since this script has to be explicitly run periodically)? - Joe -- 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?
Craig Sanders wrote: i can't answer your question, but here's some relevant advice for you: exim doesn't scale. if you want performance, switch to postfix. 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. We just haven't had the time to figure out how to port all of our virtual domains over to Courier yet, so we're still using Exim for the time being. - Joe
Re: Why doesn't Exim ever clean out /var/spool/exim/input?
Craig Sanders wrote: i can't answer your question, but here's some relevant advice for you: exim doesn't scale. if you want performance, switch to postfix. 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. We just haven't had the time to figure out how to port all of our virtual domains over to Courier yet, so we're still using Exim for the time being. - Joe -- 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?
Maarten Vink wrote: Does the output of the "mailq" command provide any useful information about these messages? My first guess would be that you're dealing with "frozen" messages Yup. A lot of them are frozen. If that is the case, have a look at the "timeout_frozen_after" setting; this will automatically remove messages after being frozen for a certain period. I'm already using: timeout_frozen_after=48h but that doesn't seem to be doing anything. - Joe
Re: Why doesn't Exim ever clean out /var/spool/exim/input?
Maarten Vink wrote: Does the output of the "mailq" command provide any useful information about these messages? My first guess would be that you're dealing with "frozen" messages Yup. A lot of them are frozen. If that is the case, have a look at the "timeout_frozen_after" setting; this will automatically remove messages after being frozen for a certain period. I'm already using: timeout_frozen_after=48h but that doesn't seem to be doing anything. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Why doesn't Exim ever clean out /var/spool/exim/input?
Here's a question that has always been bugging me. Ever since we moved from smail to exim many years ago at my isp, exim never seems to discard messages in the input queue. Even though the single retry rule is the stock one (which retrys for something like 4 days), we end up with stuff that is weeks... months old. Periodically, it would get pretty full and we'd notice that there were about 10 queue runners going and so I'd go in and do a "find" and remove anything older than 14 days or so. I *had* to do a find, because doing an "ls" would just sit there an churn for about a half-hour. Anyhow, as our customer base has grown and as their e-mail usage has grown, the problem has reached an all-time high. With this SCO DDoS virus going around, I had occasion to go clean out the input queue again. The directory was using 17 megs I'm not talking about the FILES in the directory... I'm talking about the directory ENTRIES (filename, inode number, etc.). I was forced to just say "screw it!" and I mv'd the input and msglog folders to other names and then created new, empty ones so that our mail server wouldn't buckle under the load. But anyway, like the subject line says, my real question is: why doesn't Exim ever clean this stuff out itself? - Joe
Why doesn't Exim ever clean out /var/spool/exim/input?
Here's a question that has always been bugging me. Ever since we moved from smail to exim many years ago at my isp, exim never seems to discard messages in the input queue. Even though the single retry rule is the stock one (which retrys for something like 4 days), we end up with stuff that is weeks... months old. Periodically, it would get pretty full and we'd notice that there were about 10 queue runners going and so I'd go in and do a "find" and remove anything older than 14 days or so. I *had* to do a find, because doing an "ls" would just sit there an churn for about a half-hour. Anyhow, as our customer base has grown and as their e-mail usage has grown, the problem has reached an all-time high. With this SCO DDoS virus going around, I had occasion to go clean out the input queue again. The directory was using 17 megs I'm not talking about the FILES in the directory... I'm talking about the directory ENTRIES (filename, inode number, etc.). I was forced to just say "screw it!" and I mv'd the input and msglog folders to other names and then created new, empty ones so that our mail server wouldn't buckle under the load. But anyway, like the subject line says, my real question is: why doesn't Exim ever clean this stuff out itself? - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
