sudo service start weekend
— Nick (@linickx) June 29, 2012
For a long while now, one of my oldest posts (nagios ping tool) returned a 403 error and I couldn’t work out why… a recent post about curl also fell foul of the same issue so I’ve been forced to work out why
The main challenge that I faced was that I could not find any errors in my logs, apache’s error_logs were empty, varnish is not catching the error page and my mod_security debuglog didn’t show anything. Now there is clearly a 2do here, I need to look into my logging issues because the issue was mod_security!
modsecurity_crs_40_generic_attacks as a list of system rules which will deny access to commands, on my system ping & traceroute are indeed commands! Looking thru _crs_40 I can see that rule ID 950907 blocks curl, therefore I can create a simple location match to permit access to that page.
<LocationMatch "^/3659/my-lifestream-php-curl-ca-certificate-issues"> SecRuleRemoveById 950907 </LocationMatch>
Traceroute and Ping are IDs 958837 & 958893 respectively. Going forward I could simply remove those IDs globally, but to be honest I don’t want to, I feel comfort with the restriction they begin… I will just have to be more careful with the titles I use on pages.
Recently I’ve noticed that google searches show an avatar next to blog posts, I’ve just figured how it links to your google profile -> http://support.google.com/webmasters/bin/answer.py?hl=en&answer=1408986
A while back facebook disabled RSS importing of my linickx.com posts which has resulted in my facebook timeline being very empty.
It’s taken them a while, but facebook appear to have got with the program and released an official wordpress plugin… nice work guys!
This is a test post to see if I have it setup correctly… assuming it works my friends will starting seeing a bit more linickx’y things
I use my own lifestream plugin to feed my blog page with activity from other sites.
A (long) while ago HTTPS feeds stopped working, basically due to certificate trust issues.
Now the lifestream plugin uses WordPress built in functions to perform HTTP requests…. and this was not something I wanted to change. It’s taken a bit of exploring to work out why the default configuration did not work… and then find the best way to patch it.
Eventually I found out that you can set the PHP_CURL CA Path in php.ini using the curl.cainfo directive. On CentOS the “well known” CAs are stored in
/etc/pki/tls/certs/ therefore the fix was quite simple, add the following to
curl.cainfo = /etc/pki/tls/certs/
Job done! Now HTTPS only site (like github) lifestream nicely!