Linux
Updating WordPress via SSH instead of FTP
Dec 1st
I’ve shut off FTP access to my server a while back, since FTP passwords are passed in plaintext over the net which is A Bad Thing™. For the occasions that I would need to update WordPress via its web interface, I would start up the FTP daemon so that I could use WordPress’ auto-update feature, and then shut it back down after I was done. Not that big of a hassle, but it required me to login into my server before doing anything from the web interface which was one step too many.
I discovered that WordPress has built-in support for updating via SSH2 if PHP has the PECL SSH2 library installed. Following is a quick summary of how to get it running.
The PECL ssh2 library requires libssh2 which I downloaded and then compiled painlessly with a
$ ./configure $ make $ make install
Once libssh2 was compiled and installed, I installed the PECL ssh2 library via
$ pecl install -f ssh2
The -f flag is to force the install since ssh2 is still in beta & you’d otherwise get a warning like
Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.0, stability "beta", use "channel://pecl.php.net/ssh2-0.11.0" to install
After installing ssh2 via pecl, i edited the php.ini file (located at /etc/php.ini for me) to tell PHP to load this extension
extension=ssh2.so
and then restart apache afterwards (via apachctl, service httpd restart, or whatever is appropriate for your system) so that the library would be available to PHP.
After apache comes back up, you should see a new option (SSH) in the wordpress upgrade page (which applies to plugins as well).
BTW, if you’re on a Red Hat Fedora system and/or use yum, you might be able to just pull the libssh2 rpm from yum instead of compiling it:
$ yum install libssh2 $ yum install libssh2-devel $ yum install libssh2-docs
“file too large” error message in /var/log/maillog
Mar 19th
I 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.
Stemming spam
Sep 29th
I 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
Aug 28th
Never 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
Aug 24th
Especially 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.
