[vchkpw] qmail queue directory...
I know this is not the right list but do you know how can I change the qmail's queue directory nicely? :) Is a little symlink to another location would do? or would sacrifice too much of performance? Evren
Re: [vchkpw] qmail queue directory...
Hi Evren, On Fri, 22 Aug 2003 11:18:29 +0300 (WET) Evren Yurtesen wrote: I know this is not the right list but do you know how can I change the qmail's queue directory nicely? :) Is a little symlink to another location would do? or would sacrifice too much of performance? It should work and not impact on performance /too/ much, but why do you want to change the location? But be aware the queue is empty before you switch over, files names used in queue directory are 'Inode-bound', simply moving the queue files will break them. -- Ciao, Pit
Re: [vchkpw] qmail queue directory...
Hi Evren, Please don't send any reply to me privately unless explicitely requested. I do read the list (else I wouldn't have been able to answer your question) and I don't need two or more copies of one mail. Thank you. On Fri, 22 Aug 2003 12:17:36 +0300 (WET) Evren Yurtesen wrote: [quoting fixed] I know this is not the right list but do you know how can I change the qmail's queue directory nicely? :) Is a little symlink to another location would do? or would sacrifice too much of performance? It should work and not impact on performance /too/ much, but why do you want to change the location? But be aware the queue is empty before you switch over, files names used in queue directory are 'Inode-bound', simply moving the queue files will break them. I want to change it because current queue directory is in /var/qmail/queue and I figured out that the 256mbyte in /var filesystem might be insufficient if there comes too much emails with attachments from my customers at the same time. Plus the undeliverable ones etc. What about an extra partition for '/var/qmail/queue' that's simply mounted there? No need for symlinking, lots of space, not affected by a possible overflow in '/var/log', etc , etc ... I thought I might use this qmail queue fix tool from qmail web page. I simply dont know how to empty the queue ? Stop the SMTPD for no new mails coming in. Make your best attempt to stop processes that might inject mails locally. Send 'qmail-send' process an 'ALRM' signal. Wait. You'll /NOT/ loose any external mail that can't be delivered due to the fact the SMTP is down, /IF/ the foreing MTAs are configured correctly. They should keep the message in queue for several days until your MTA is up again (if you don't even have a backup MX for your domain). Previously I had bad experience with lock/trigger file in queue directory. Maybe because 'qmail-send' still ran when you did something on this file? It's 'fifo', a 'name pipe' and qmail-send keeps a handle opened on this file. Stop qmail-send before moving anything and if you've any trouble moving 'lock/trigger' as is use 'mkfifo' to recreate it at it's new location. I also wonder how to regenerate it with correct options in the new filesystem. :) There was supposed to be a make command for that but :) 'make setup' in qmail source tree will generate the queue structure. But you can easliy pushd /var/qmail/queue find . -type d | \ (cd /path/to/new/queue/dir; while read $DIRECTORY; do mkdir $DIRECTORY \ chown --reference=/var/qmail/queue/$DIRECTORY \ chmod --reference=/var/qmail/queue/$DIRETORY ; done) It's then two files to copy: './lock/{sendmutex,tcpto}' and the fifo './lock/trigger' that has to be created and you're done with creating a new, clean qmail-queue-structure. -- Ciao, Pit
Re: [vchkpw] 5.3.23 vadduser segfaults
I am still working with our web designer for the inter7 development page. There is more than just pointing at source forge. So for the time being I will keep it up to date manually. Ken On Thursday 21 August 2003 4:12 pm, Tom Collins wrote: On Thursday, August 21, 2003, at 01:48 PM, Paul L. Allen wrote: Any ideas (better still, fixes) would be appreciated. Please use 5.3.24 from SourceForge http://sourceforge.net/projects/vpopmail/. Ken, please update http://inter7.com/develop.html to point to SourceForge for qmailadmin and vpopmail downloads. -- Tom Collins [EMAIL PROTECTED] http://sniffter.com/ - info on the Sniffter hand-held Network Tester
Re: [vchkpw] qmail queue directory...
I think I will try to use the symlik and then run qmail queue-fix program. I had nice results a little bit ago moving a whole system to another drive. I tarred everything and opened to the filesystems in new disk. The only thing which didnt work was again qmail trigger file (I assumed but might be something else) I ran the qmail-queue-fix program and everything is working. Now I think that trigger file was not the problem but the inode numbers which are changed when I tar the directory and open back was. Also now I know that I can just move the queue directory symlink it then run qmail queue-fix program and everything will work. Thanks Evren On Fri, 22 Aug 2003, Peter Palmreuther wrote: Hi Evren, Please don't send any reply to me privately unless explicitely requested. I do read the list (else I wouldn't have been able to answer your question) and I don't need two or more copies of one mail. Thank you. On Fri, 22 Aug 2003 12:17:36 +0300 (WET) Evren Yurtesen wrote: [quoting fixed] I know this is not the right list but do you know how can I change the qmail's queue directory nicely? :) Is a little symlink to another location would do? or would sacrifice too much of performance? It should work and not impact on performance /too/ much, but why do you want to change the location? But be aware the queue is empty before you switch over, files names used in queue directory are 'Inode-bound', simply moving the queue files will break them. I want to change it because current queue directory is in /var/qmail/queue and I figured out that the 256mbyte in /var filesystem might be insufficient if there comes too much emails with attachments from my customers at the same time. Plus the undeliverable ones etc. What about an extra partition for '/var/qmail/queue' that's simply mounted there? No need for symlinking, lots of space, not affected by a possible overflow in '/var/log', etc , etc ... I thought I might use this qmail queue fix tool from qmail web page. I simply dont know how to empty the queue ? Stop the SMTPD for no new mails coming in. Make your best attempt to stop processes that might inject mails locally. Send 'qmail-send' process an 'ALRM' signal. Wait. You'll /NOT/ loose any external mail that can't be delivered due to the fact the SMTP is down, /IF/ the foreing MTAs are configured correctly. They should keep the message in queue for several days until your MTA is up again (if you don't even have a backup MX for your domain). Previously I had bad experience with lock/trigger file in queue directory. Maybe because 'qmail-send' still ran when you did something on this file? It's 'fifo', a 'name pipe' and qmail-send keeps a handle opened on this file. Stop qmail-send before moving anything and if you've any trouble moving 'lock/trigger' as is use 'mkfifo' to recreate it at it's new location. I also wonder how to regenerate it with correct options in the new filesystem. :) There was supposed to be a make command for that but :) 'make setup' in qmail source tree will generate the queue structure. But you can easliy pushd /var/qmail/queue find . -type d | \ (cd /path/to/new/queue/dir; while read $DIRECTORY; do mkdir $DIRECTORY \ chown --reference=/var/qmail/queue/$DIRECTORY \ chmod --reference=/var/qmail/queue/$DIRETORY ; done) It's then two files to copy: './lock/{sendmutex,tcpto}' and the fifo './lock/trigger' that has to be created and you're done with creating a new, clean qmail-queue-structure. -- Ciao, Pit
[vchkpw] Outside Virus and Spam Filtering
Ok... we are going to use an outside MX forwarding service to scan all incoming mail coming to the servers from other hosts for spam and viruses. Now how can I lock things down so ONLY the users popping in for SMTP and the filtering servers can have access? I already have the pop-before-smtp configured I just don't want to lock everybody out. If I recall it is done in tcp.smtp correct? Wil