I recently started using sslmate to manage SSL certificates. SSL is one of those complicated things you deal with rarely so it has historically been a pain in the neck.
But sslmate makes it all easy … you install the sslmate command and can generate, sign, and install certificates from the command-line. You then have to check your email when getting a signed cert to verify … and you’re good.
The certificates auto-renew annually, assuming you click the email. I did this for an important cert yesterday. Another thing you do (sslmate walks you through all these details) is set up a cron.
This morning at 6:25am the cron got run on our servers … with minimal intervention (I had to click a confirmation link on an email yesterday) our web servers are now running on renewed certs …. one less pain in the neck.
So … next time you have to deal with SSL I would say “go to sslmate.com and follow the instructions and you’ll be in a happy place.”
I was poking around my CloudFlare Control Panel, and pulled up stats for the past month, from Oct 11 to Nov 11. It says it had blocked a bunch of attacks on my site, and consequently saved me over 5GB in bandwidth.
I said to myself, "I pay for bandwidth! Maybe this free service is saving me money?!"
“Really,” I said, “I pay for bandwidth, so if CloudFlare is saving me bandwidth, it is saving me money!”
But 5GB seemed kind of high. So, I checked my invoices from RackSpace. Here is the outbound bandwidth I have been charged for this year:
RackSpace charges me on the 11th of the month, and, conveniently enough, I started using CloudFlare around October 11th. The highlighted line above is my first month on CloudFlare. It is my lowest number of the year, and it is conceivable that I could have totaled 9.5 GB in October since I pushed more than that in February. I’m skeptical that they are saving me as much as they claim to be, but for a free service to speed up my web site and save me even a little money . . . that is a good deal in my book!
If you have a self-hosted WordPress blog, you really ought to keep it up to date. Popular software is a popular security target, and as new exploits are discovered, new patches are deployed. Fortunately, WordPress makes this super-easy. Just go to Dashboard > Updates and you can update with one click. I basically get a free update any time I get it in my head to write something.
Except this morning, when I was told that an update was available, but:
On my CentOS VM, this was addressed by:
sudo yum update
sudo service httpd restart
Actually, it was a little difficult, because we’re replacing php with php53:
0-13:11 djh@www0 ~$ cat /etc/redhat-release
CentOS release 5.6 (Final)
0-13:11 djh@www0 ~$ rpm -q php
php-5.1.6-27.el5_5.3
0-13:11 djh@www0 ~$ yum list installed | grep ^php
php.x86_64 5.1.6-27.el5_5.3 installed
php-cli.x86_64 5.1.6-27.el5_5.3 installed
php-common.x86_64 5.1.6-27.el5_5.3 installed
php-gd.x86_64 5.1.6-27.el5_5.3 installed
php-mysql.x86_64 5.1.6-27.el5_5.3 installed
php-pdo.x86_64 5.1.6-27.el5_5.3 installed
1-13:11 djh@www0 ~$ sudo service httpd stop
Stopping httpd: [ OK ]
0-13:11 djh@www0 ~$ yum list installed | grep ^php | awk '{print $1}'
php.x86_64
php-cli.x86_64
php-common.x86_64
php-gd.x86_64
php-mysql.x86_64
php-pdo.x86_64
0-13:12 djh@www0 ~$ sudo yum remove `!!`sudo yum remove `yum list installed | grep ^php | awk '{print $1}'`
Loaded plugins: fastestmirror
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package php.x86_64 0:5.1.6-27.el5_5.3 set to be erased
---> Package php-cli.x86_64 0:5.1.6-27.el5_5.3 set to be erased
---> Package php-common.x86_64 0:5.1.6-27.el5_5.3 set to be erased
---> Package php-gd.x86_64 0:5.1.6-27.el5_5.3 set to be erased
---> Package php-mysql.x86_64 0:5.1.6-27.el5_5.3 set to be erased
---> Package php-pdo.x86_64 0:5.1.6-27.el5_5.3 set to be erased
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
php x86_64 5.1.6-27.el5_5.3 installed 6.2 M
php-cli x86_64 5.1.6-27.el5_5.3 installed 5.3 M
php-common x86_64 5.1.6-27.el5_5.3 installed 397 k
php-gd x86_64 5.1.6-27.el5_5.3 installed 333 k
php-mysql x86_64 5.1.6-27.el5_5.3 installed 196 k
php-pdo x86_64 5.1.6-27.el5_5.3 installed 114 k
Transaction Summary
================================================================================
Remove 6 Package(s)
Reinstall 0 Package(s)
Downgrade 0 Package(s)
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Erasing : php-gd 1/6
Erasing : php 2/6
Erasing : php-mysql 3/6
Erasing : php-cli 4/6
Erasing : php-common 5/6
warning: /etc/php.ini saved as /etc/php.ini.rpmsave
Erasing : php-pdo 6/6
Removed:
php.x86_64 0:5.1.6-27.el5_5.3 php-cli.x86_64 0:5.1.6-27.el5_5.3
php-common.x86_64 0:5.1.6-27.el5_5.3 php-gd.x86_64 0:5.1.6-27.el5_5.3
php-mysql.x86_64 0:5.1.6-27.el5_5.3 php-pdo.x86_64 0:5.1.6-27.el5_5.3
Complete!
0-13:13 djh@www0 ~$ sudo yum install php53 php53-mysql php53-gd
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: yum.singlehop.com
* epel: mirror.steadfast.net
* extras: mirror.fdcservers.net
* updates: mirror.sanctuaryhost.com
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php53.x86_64 0:5.3.3-1.el5_6.1 set to be updated
--> Processing Dependency: php53-cli = 5.3.3-1.el5_6.1 for package: php53
--> Processing Dependency: php53-common = 5.3.3-1.el5_6.1 for package: php53
---> Package php53-gd.x86_64 0:5.3.3-1.el5_6.1 set to be updated
--> Processing Dependency: libXpm.so.4()(64bit) for package: php53-gd
---> Package php53-mysql.x86_64 0:5.3.3-1.el5_6.1 set to be updated
--> Processing Dependency: php53-pdo for package: php53-mysql
--> Running transaction check
---> Package libXpm.x86_64 0:3.5.5-3 set to be updated
---> Package php53-cli.x86_64 0:5.3.3-1.el5_6.1 set to be updated
---> Package php53-common.x86_64 0:5.3.3-1.el5_6.1 set to be updated
---> Package php53-pdo.x86_64 0:5.3.3-1.el5_6.1 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
php53 x86_64 5.3.3-1.el5_6.1 updates 1.3 M
php53-gd x86_64 5.3.3-1.el5_6.1 updates 109 k
php53-mysql x86_64 5.3.3-1.el5_6.1 updates 92 k
Installing for dependencies:
libXpm x86_64 3.5.5-3 base 44 k
php53-cli x86_64 5.3.3-1.el5_6.1 updates 2.4 M
php53-common x86_64 5.3.3-1.el5_6.1 updates 605 k
php53-pdo x86_64 5.3.3-1.el5_6.1 updates 67 k
Transaction Summary
================================================================================
Install 7 Package(s)
Upgrade 0 Package(s)
Total download size: 4.6 M
Is this ok [y/N]: y
Downloading Packages:
(1/7): libXpm-3.5.5-3.x86_64.rpm | 44 kB 00:00
(2/7): php53-pdo-5.3.3-1.el5_6.1.x86_64.rpm | 67 kB 00:00
(3/7): php53-mysql-5.3.3-1.el5_6.1.x86_64.rpm | 92 kB 00:00
(4/7): php53-gd-5.3.3-1.el5_6.1.x86_64.rpm | 109 kB 00:00
(5/7): php53-common-5.3.3-1.el5_6.1.x86_64.rpm | 605 kB 00:00
(6/7): php53-5.3.3-1.el5_6.1.x86_64.rpm | 1.3 MB 00:00
(7/7): php53-cli-5.3.3-1.el5_6.1.x86_64.rpm | 2.4 MB 00:00
--------------------------------------------------------------------------------
Total 12 MB/s | 4.6 MB 00:00
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : php53-common 1/7
Installing : php53-pdo 2/7
Installing : php53-cli 3/7
Installing : libXpm 4/7
Installing : php53 5/7
Installing : php53-mysql 6/7
Installing : php53-gd 7/7
Installed:
php53.x86_64 0:5.3.3-1.el5_6.1 php53-gd.x86_64 0:5.3.3-1.el5_6.1
php53-mysql.x86_64 0:5.3.3-1.el5_6.1
Dependency Installed:
libXpm.x86_64 0:3.5.5-3 php53-cli.x86_64 0:5.3.3-1.el5_6.1
php53-common.x86_64 0:5.3.3-1.el5_6.1 php53-pdo.x86_64 0:5.3.3-1.el5_6.1
Complete!
0-13:14 djh@www0 ~$ sudo service httpd start
Starting httpd: [ OK ]
And now I have successfully upgraded via the web UI.
Most days, I am not a CentOS admin, so if there is a better way to have done this, I am keen to hear.
That “Sea of Glass” building from a different perspective.
While clicking around in a WordPress install last night I discovered that under Appearance > Media I can change the size of images posted through WordPress.
I have run in to this a zillion times. You SSH to a Unix server, type your password, and then wait a minute or two before you get the initial shell prompt, after which everything is reasonably zippy.
The short answer is “probably, something is wrong with DNS . . . your server is trying to look up your client but it can not, so it sits there for a couple of minutes until it times out, and then it lets you in.”
Yesterday I was working with an artist who had a hosting account, and when he got in, I said:
sudo vim /etc/resolv.conf
He admitted that he had just copied the DNS configuration from his previous server. How to fix this? Well, he could check what nameservers are provided by his current hosting company . . . . or, I changed his file to read:
I recently migrated this web site to a virtual server at the Rackspace Cloud. I started with the cheapest, 256M slice, but after hitting some performance issues really quickly, I figured that the extra $10/month to grow the slice to 512M was worthwhile. Even so, I don’t think MySQL and Apache are tuned, out-of-the-box, for such “small” systems.
I am running WordPress, a PHP application, on Apache and MySQL, running on CentOS. I am using Munin to track the system health. Since MySQL performance tuning can be extremely complicated I have focussed my initial efforts on Apache.
So, the memory graph would ideally top out at 512MB, but in practice, the system and programs allocate excess memory they rarely touch, and that gets paged out to swap. It is when the swap activity gets high that system performance goes to heck. A spike in system load is a good symptom of possible performance issues.
When things went bad on Wednesday, I tuned Apache down somewhat from the defaults and then enabled the Apache status page, and told Munin to go ahead and graph that. I am new to Munin, but Slicehost has some excellent articles on installing and configuring it in my environment.
This morning Munin sent me e-mail that it was having trouble collecting data, so I took a look, and reset performance values for Apache based on the above graph:
Hopefully, this will hold. I would love to audit the system memory use in greater detail to allow Apache some greater flexibility, but in the interests of achieving a stable system quickly, this will hopefully prove to be a good strategy.
I just enabled a caching plugin. This ought to make browsing the site a wee bit faster. More importantly, it should reduce stress on the web server, which is an older beast managed by friends. If anyone notices new or unexpected behavior, please give me a shout!
0-11:17 djh@ratchet ~> cd public_html/toldme
0-11:17 djh@ratchet ~/public_html/toldme> svn sw http://svn.automattic.com/wordpress/tags/2.5.1/
[ . . . ]
Updated to revision 7839.
When I logged in to post this little note, it blocked me and ran the upgrade procedure, then I had to log in again, and here I am!
There’s a further note about the secret key setting:
Since 2.5 your wp-config.php file allows a new constant called SECRET_KEY which basically is meant to introduce a little permanent randomness into the cryptographic functions used for cookies in WordPress. You can visit this link we set up to get a unique secret key for your config file. (It’s unique and random on every page load.) Having this line in your config file helps secure your blog.
It leaves me to wonder: if the secret key can be randomly generated by a machine, why not go ahead and do that and then stash it in the database? There may be a good reason for that . . .
In unrelated news, I upgraded to the newer Ubuntu release at home yesterday. The only trick I have noticed so far is that it runs with Firefox 3.0, which is beta, and I lost use of my foxmarks plugin, for now. So, I’m waiting until that is supported before I upgrade my workstation.
On the weekend of July 22 and 23, I and about 400 other folks attended WordCamp 2007 in San Francisco. This is a conference about WordPress blogging software, and blogging itself. I am usually a bit wary of killing my weekend by spending the bulk of it with a bunch of nerds. Especially bloggers. But then, I am a nerd, and this is, I admit, a blog . . . that and registration was merely $25 and covered my food for the weekend. That’s a pretty compelling deal for the unemployed! Added value was found at the open bar on Saturday night at one of my favorite bars: Lucky 13.
Here are notes I compiled during the Saturday presentations. (more…)
BUG: Uhm, actually, if you have pretty permalinks this plugin will break unless your post slug is photos . . . I just tried to fix this but failed. Sorry about that.
I just spent a fair amount of time wrestling with Apache on my Macintosh. The problem is that it simply refused to read the .htaccess file in my user directory.
My First Approach
I took the “Unix Guy” approach and edited /etc/httpd/httpd.conf to ensure that Apache was configured to consult my user’s .htaccess file. I changed this bit:
I had planned to “ship” this version last Friday, but it was a little more adventure than I had anticipated.
Photos Flickr is an early version of a plugin that I am developing for WordPress blog software to display a user’s Flickr album within their blog. The result? Someone with a WordPress blog can now have a basic interface to let readers view their Flickr images, using their own web site and design.
Changed: Fixed the tag-listing function to drop the last comma.
Changed: A bunch of internal work for functions to understand the current “context” appropriately when navigating through a photostream, versus a set …
New: Added photos_photoset_title() and photos_photoset_description()
Changed: is_photo() returns current photo ID.
New: Added photos_photo_date_taken()–support date format manipulation.
New: photos_photo_tag_list() and photos_photo_photoset_list() return lists of tags and photosets for a photo.
Changed: Functions photos_photo_(next|prev)_(href|url|title) wrap around new private photos_private_getContext().
New: New functions photos_photoset_(next|prev)_(href|url|title) wrap around new private photos_private_getContext().
Changed: Disabled ALT and TITLE attributes on image links due to not-escaping-quotes issues.
Changed: Renamed photos_index() to photos_photo_index() and photos_pageindex() to photos_photo_pageindex() with stub functions for
backwards-compatibility.
Added: New is_index() returns photo, tag, or photoset to tell us what index has been requested.
New: Added photos_photoset_index() function to display a “pretty” index of photosets.
New: Added photos_photo_index_href() and photos_photoset_index_href() functions to refer to photo index and photoset index pages.
I have had my sleeves rolled up . . . and I am having a blast! It is with some joy that I announce the release of the latest development version of my WordPress Flickr plugin, Photos Flickr 0.5:
Photos Flickr is an early version of a plugin that I am developing for WordPress blog software to display a user’s Flickr album within their blog. The result? Someone with a WordPress blog can now have a basic interface to let readers view their Flickr images, using their own web site and design.
