I recently found I wanted to move some data on my Apache webserver from one directory to another, and didn’t want to muck around with symbolic links (trying to keep the webspace clean and tidy), but also wanted to ensure that links to these items and searches would still find them.

The answer? .htaccess file and Redirect!

For example, say you moved the /photos directory on your webserver to /media/photos you could do the following to ensure that old links work:

In the .htaccess file in your webserver’s root directory, add the following line:
Redirect permanent /photos/ /media/photos

Shazam! http://yourserver/photos/whatever.jpeg will redirect to http://yourserver/media/photos/whatever.jpeg

1 person likes this post.

Unlike

There are numerous reasons that the mail queue can get over full, ranging from general network problems, to having a user repeatedly sending an email with a large attachment to an incorrectly type address.

The first thing you likely want to do is get some information on what’s in the queue:
To find out how many messages are in the queue:
mailq | tail -1
This will give you the total number of emails in the queue, ie:
Total requests: 6592
You might also want to know how old or new they are, so:
ls -lt | tail -10
and
ls -ltr | tail -10
will show you the oldest 10 and the newest 10 respectively.
To have sendmail retry the emails, simply run (as root):
sendmail -q -v
If you are in a situation where it has filled up the disk and need to fix it FAST, move the directory to another partition and then have sendmail process it from there (stopping sendmail with “/etc/init.d/sendmail stop” is recommended:
mkdir /root/tmpq
mv /var/spool/mqueue/* /root/tmpq
sendmail -q -v -oQ/root/tmpq
(if you get an error like “Argument list too long” instead run “mv /var/spool/mqueue /root/tmp” with sendmail stopped, then restart it)

1 person likes this post.

Unlike

Running an email server can result in some strange problems at times – a common one being the /var/spool/mqueue filling up (which I really need to write an article on….), and one which can be hard to pin down: A POP3 user with a mailbox that is too big.

I recently ran into a scenario where a user’s mailbox (which REALLY should have had a quota, but didn’t) had grown quite large (~1GB). When the user went to check their mail, the following would happen:

1. Mail client (Thunderbird, in this case), connects to the mail server and sends username and password
2. When the user is authenticated (right after the client sends the “PASS xxxxx” command), the pop3d process makes a copy of the user’s mailbox in the temporary directory (/tmp in my case)
3. There was insufficient space for the copy of the user’s mailbox in the temporary directory, and when if ills up the server aborts the operation sending an error like “-ERR cannot open mailbox /home/userdir/.mail/mbox: No space left on device”
4. The pop3d process clears out the temporary file (something like /tmp/pop3oj5oyy) freeing up the space
5. Email client (hopefully) shows the end user a meaningful error

The real problem with this process is the momentary filling up of the temporary directory which can cause a problem for virtually any other process (in my case it was frequently showing up as database errors on websites, amongst other odd problems)

In this case, I found I had a user’s mailbox file that was about 1.2GB:
ls -sh /home/userdir/.mail/mbox
1.2G mbox

To check how many messages there are in it run:
grep -c "^From\ " mbox
15881

15000+ messages!

Now to the fixing it part:

First move to another location so that nothing is added to it while working with it (preferably after shutting down your MTA, ie: /etc/init.d/sendmail stop – depending on your situation, this may not be practical) and switch to the directory where it is:
mv /home/userdir/.mail/mbox ~/mbox.tmp && cd ~
In my case, I figure if I break it into 10 chunks (about 1500 messages each) it should work fine:

cat mbox.tmp | formail -1500 -s > mbox.1

This gave me a file about 115MB.
If you shut down your MTA, just copy/move that file to the location where the original mailbox file was, fire up the MTA, and download the mail. If you did not shut down the MTA, you should append this new file to the mailbox that may be there now (if there was any new mail received). Note: This may be slightly dangerous, so making a backup copy of the mailbox file that is in place is highly recommended):

cat mbox.1 >> /home/userdir/.mail/mbox
Then, as above, download the mail.

Second chunk:
cat mbox.tmp | formail +1500 -1500 -s >mbox.2
Move the mbox.2 file as per above, and download.

Rinse and repeat, if necessary:
cat mbox.tmp | formail +3000 -1500 -s >mbox.2
Increasing the “+xxx value by the amount per download as required until it’s done.

Oh, and back to the title of this article: If we had a quota in place on this account, none of this would ever had happened!

Like

Unlike