Linux
“file too large” error message in /var/log/maillog
0I run Postfix as the mail transfer agent (MTA) on my server and saw a bunch of “error writing message: File too large” errors in /var/log/maillog as well as senders getting this bounce message:
I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <example@example.com>: cannot update mailbox /var/mail/example for user example. error writing message: File too large
Ends up that Postfix has a mailbox_size_limit setting & since I didn’t have that set, it was set to the default 50MB. The user’s mailbox was near that limit so I up’d the default to 150MB in /etc/postfix/main.cf:
mailbox_size_limit = 157286400
then reloaded postfix:
service postfix reload
and all was good again.
upgrading from apache 2.0.x to 2.2.x
0Upgraded apache from 2.0.59 to 2.2.8 yesterday and my htaccess rules broke. I searched around & discovered that one of the things that changed with 2.2.x was a renaming of the various apache auth modules. Had to put in the following to my httpd.conf to get things to work again
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_user_module modules/mod_authz_user.so
Other than that, everything else was easy breezy.
Stemming spam
1I use a combination of DNS blacklists (DNSBLs) and spamassassin on my server to try and limit the amount of spam I get. I use the Postfix mail server and here is the relevant part of my Postfix main.cf config file:
smtpd_sender_restrictions = reject_unknown_address
smtpd_client_restrictions =
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl-1.uceprotect.net,
permit
message_size_limit = 15728639
disable_vrfy_command = yes
smtpd_helo_required = yes
Note that I’m using 3 DNSBLs (spamhaus, spamcop, and uceprotect — the values for reject_rbl_client) and they are placed towards the end of smtpd_client_restrictions. I only want the external DNSBL DNS lookups to occur if the mail passes the simpler checks first.
Seems to be doing a decent job. I still get a few pieces of spam that fall through the cracks, but don’t want it so aggressive that letgitimate email doesn’t get to me. Here’s the summary data from logwatch from yesterday:
1 Reject relay denied 0.02%
207 Reject HELO/EHLO 4.40%
442 Reject unknown user 9.40%
4053 Reject RBL 86.18%
-------- ------------------------------------------------
4703 Total Rejects 100.00%
The DNSBLs combined rejected over 4000 pieces of mail, most of which would have likely been caught by spamassassin anyways if I didn’t have the DNSBL checks, but it’s nice that they didn’t get past my mail server and into my mailbox!
installed mod_deflate
0Never one to leave good enough alone, I configured mod_deflate this evening to squeeze out a little more performance out of the server that hosts this site and a few others. Not like it really needed it bandwidth savings-wise since nothing bandwidth-intensive is hosted on this box (yet), but I’ve always been a bite of an optimization nut and a tweaker. Thankfully tweaking this server is free other than my time.
2gb log files are bad
0Especially if they cause the primary DNS for a domain to hang. Not the server that runs this site, but one that I am involved in developing applications on. I’m far from a linux expert, but I know enough to be dangerous! rndc kept returning a “connection refused” message when called. So I checked rndc.conf, named.conf, rndc.key and everything looked peachy. It wasn’t until I did a `ls -lh`in the logs directory that I noticed that bind-queries.log was 2GB in size. On a hunch, i renamed that file and then tried rndc again. Presto! Too bad I went through nearly 5 hours of troubleshooting to get to that point, but glad to have found the root of the problem.
