I have Cacti installed so that I have pretty graphs (CPU/load/memory/disk/network) for all my servers (VPS) in one place. I just enabled full IPv6 on one of them and Cacti stopped working. The problem wasn’t Cacti though, it was the server it was now trying to contact through IPv6.
As I only need SNMP for Cacti, the snmpd.conf file on all my servers is very simple, just:
However for IPv6 that isn’t enough. On Ubuntu 14.04 (what the server is running) snmpd will only work on IPv4 this way. I quickly found out you can use an agentAddress directive in the snmpd.conf file to enable the daemon to listen on IPv6, but more changes are required if you want to actually return data through IPv6. As it turns out the “rocommunity” directive is apparently also IPv4 only.
The final solution was this:
agentAddress udp:161,udp6:161 rocommunity public rocommunity6 public
Warning: above configuration will cause snmpd to listen on all network interfaces. Be sure to lock down access to UDP port 161 in your firewall to only authorized hosts. And make sure your firewall supports IPv6.
Let’s Encrypt is now in public beta phase. It allows you to create free unlimited trusted SSL certificates that work in all browsers (all relevant browsers anyway). There are now no excuses for adding SSL encryption to your website(s).
That isn’t to say that Let’s Encrypt isn’t without flaws: the certificates you can get are only valid for a maximum of 90 days. While you can of course renew them, if you don’t have some kind of automated way of renewing your certificates it can quickly become a pain to keep them up-to-date.
The other issue (at the moment) is that Let’s Encrypt own monolithic tool for requesting certificates requires to be run as root on your server, which no doubt some people will have issues with. Fortunately the protocol (ACME) used is public and alternative clients are available. I personally used letsencrypt-nosudo to issue my first certificate (this tool allows you to register an account with an email address with Let’s Encrypt, which might be useful) and intent to issue further certificates (and renewals) with the very simple acme-tiny.
If you haven’t set up SSL on your server before, these resources might also be useful:
I intend to use Let’s Encrypt for all my less important domains (which includes this site) until its reliability is proven and CheapSSLSecurity (Comodo PositiveSSL 3 years for $4.99/year) for the rest in the mean time. No need to pay any more.
Update February 2016: Mandrill has announced changes that if I understand them correctly would mean for my sending volume I’d go from paying $65 in the past two years to $30/month in the future. Needless to say, I’ll be moving away from them a.s.a.p. and do not recommend them anymore to anyone! Of course I am not the only one who is not happy about that. While I have yet to properly evaluate alternatives, Mailgun looks promising. I’ll update my plugins when I’ve moved to another service.
If you have a server that needs to send mail, I highly recommend using a specialized service such as SendGrid or
my personal favorite Mandrill (up to 12k sends per month are free). While integrating Mandrill in certain web software is easy (like their wpMandrill plugin for WordPress), vBulletin is a bit more tricky.
While it is easy to configure vBulletin to send mail through Mandrill (just create an API key and configure mail in the vBulletin settings) a problem is that the vBulletin Contact Us form uses the user’s email address in the “From:” field and that pollutes your Mandrill account very quickly.
As solution I’ve written a little plugin that rewrites the “From:” field into a “Reply-To:” field and then adds your webmaster email address as “From:” field, which solves this issue.
Now on to one of the neat things you can do with Mandrill: automated handling of bounced mail. Mandrill supports webhooks where you can have certain events be reported to automatically, such as “hard-bounce” or “reject” email events. Such a webhook can then take action on this information.
I’ve written a Mandrill webhook for vBulletin that will automatically move a user to the “Users Awaiting Email Confirmation” usergroup if such an event occurs, so that no more mail is sent to them (until they update and reconfirm their email address), which will improve your email delivery score.
The plugin and webhook plus further info can be found here: https://bitbucket.org/ghdpro/vbulletin-mandrill
Tip: for greater security, limit your Mandrill API key access (in Mandrill settings) to your server’s IP address and for vBulletin (or any service that only uses SMTP access) you only need to allow the “send-raw” API call, nothing else.
Edit: I stumbled on this nice site recently: willmyphonework.net, which allows you to check compatibility of a lot of phones in various countries. It confirmed my iPhone 6S also works in Japan.
And now for something slightly different (still tech related), I went to Japan this summer (btw, I wouldn’t recommend that: go in spring or autumn) and wanted to use a sim card in my unlocked iPhone 5S (model A1457) and wondered if it would work.
Different sub-models of iPhones have different antennas (GSM/UMTS/CDMA/LTE etc), which means an iPhone bought in one country may not necessarily work in another country due to different standards. So I tried to find information on this topic but couldn’t find confirmation on whether the A1457 model would work in Japan.
Well having been there and used it with the U-Mobile (NTT Docomo network) sim card I got for it: Yes, the A1457 does work in Japan with both LTE & 3G. I had no problems using it in Japan even in somewhat remote areas.
Now fortunately newer iPhones (6/6S) are a better kind of “world phone” than the iPhone 5S was, so I should have no trouble in the future either.
A few years ago I wrote about keeping WordPress & phpMyAdmin up-to-date with a single command. While those methods still work it is time to make a few changes (and revive this blog while I’m at it, it has been too long).
First off, using Subversion to track stable versions might keep WordPress itself up-to-date (unless something breaks due to subtle changes in the repository as I found out with WordPress 4.1), it won’t do anything for your themes or plugins.
If you like to keep everything in WordPress up-to-date through the command line (instead of FTP, which I don’t even have installed) there now fortunately is a tool called wp-cli. Updating all plugins for example is as simple as:
wp plugin --all update
There is loads more it can do, see the wp-cli site for documentation of all commands and features.
Second, while the method of using git to update phpMyAdmin in my previous article wasn’t inaccurate, it was highly inefficient. The commands would first download the whole phpMyAdmin repository (including all branches and commit history) and then switch to tracking the stable branch. This was slow and wasted a lot of space.
So here are the updated commands:
git clone --depth=1 -b STABLE https://github.com/phpmyadmin/phpmyadmin.git git pull -q origin STABLE composer update --no-dev
With this we tell git that we want only the latest commit (depth flag) in the stable branch (b flag). This executes must faster and occupies only about 70 MB of space instead of nearly 500 MB. I recommend calling the git pull command from a cron job every day, so that your phpMyAdmin is always up-to-date.