Posts tagged wordpress
If like me, you use the very useful CloudFlare service to speed up & protect your site(s), you may have noticed that since using CloudFlare, your access logs may seem to have a ton of visits from a very narrow range of IP addresses. This is because CloudFlare acts as a reverse proxy and the IPs you are seeing are from CloudFlare’s network.
This is a bit sucky for analytics since those IPs are not of the actual visitors to your site(s). The original IP is still in the HTTP request headers when CloudFlare is enabled, though, and looks something like this sample request header:
GET /blog/feed/ HTTP/1.0 Host: www.normyee.net Accept-Encoding: gzip CF-Connecting-IP: 220.127.116.11 CF-IPCountry: US X-Forwarded-For: 18.104.22.168 Connection: close Set-Keepalive: 0 Accept: */* From: googlebot(at)googlebot.com User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
CloudFlare inserts a
CF-Connecting-IP header containing the original requester’s IP. In this case, the IP 22.214.171.124 is google’s web crawler paying me a visit, although the request was logged as coming from 126.96.36.199 — one of CloudFlare’s IPs. We of course want the original IP logged, and not CloudFlare’s. Fortunately there are quick solutions for both Apache and WordPress.
For Apache, CloudFlare has an Apache module, mod_cloudflare, which you’ll need to compile from source for your system. You can get more info and instructions here & view the source on github here (it’s linked to from the previous link as well). It’s pretty straightforward, assuming you have shell access and the ability to run apxs (the APache eXtenSion tool).
For WordPress, you can just simply download the CloudFlare WordPress plugin at wordpress.org to get the correct IPs back in WordPress. CloudFlare has a wiki page for the plugin as well, but the WordPress.org plugin page has all the info you need.
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.
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
and then restart apache afterwards (via
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