Category Archives: Administration

Setting up the backend

Permalinks on Mac OS

Mac OS X has Apache and PHP built in. I installed MySQL and set up a localhost WordPress install on it. Everything looked good, until I tried to enable pretty permalinks. The pretty links just didn’t work.

The Codex page indicates that FollowSymLinks must be enabled and AllowOverride should be All (or FileInfo). I tried putting that into the httpd.conf file but that didn’t work.

It took a while to realise that I was putting those directives into the section for the web root directory and not the user specific folder where I had actually put the site. Following the trail of includes in the well commented config files, I found my user Apache config in /etc/apache2/users/.conf

Added those options into the config file and permalinks are working 🙂

EDIT: Upgraded to OSX Mountain Lion and it uses a different set of configuration files. It looks like user config files aren’t created by default so I just changed the default directive.

Advertisements

SVN Tip

I run a few localhost installs of WordPress for testing and experimentation. They are installed using the svn method, as outlined in the Codex.

At first, I would go in manually to each folder to svn up occasionally. This got tiresome after a while so I wrote a simple bash script to cd to each folder and run svn up

Recently, I discovered that there’s a shortcut. All I have to do is to go to the parent directory and type svn up *

This will run the command on all the subfolders and thus bring all my sites up to date.

Amazon Web Services

Amazon Web Services (AWS) provides computing resources in the cloud. You can get access to as many ‘machines’ as you’re willing to pay for, as well as storage, database services and many others. All these can be combined to create a rapidly scalable application.

AWS does provide a free usage tier, allowing anyone to sign up and try out the service for free for a year, as long as the application remains below limits. Full details of these limits can be found on their website.

The free usage tier includes 750 hours of an EC2 micro instance, enough to run a little web server. The rest of this post will give a brief overview of how to get WordPress running on EC2.

Start by creating a new instance in the region of your choice. The Amazon Machine Images (AMIs) which are free to use are marked with a yellow star. AWS has recently started offering Ubuntu as a free image. This has made it much easier for me to get stuff working.

AWS provides instructions on how to create a SSH key and use it to login to the instance. If you want to allow others or other machines to login, generate SSH keys for them and place the public portion in the /home/ubuntu/.ssh/authorized_keys file.

Install Apache, PHP and MySQL using apt-get. This is basic LAMP setup stuff.

Install SVN. This is optional, but I like using SVN to install WordPress because it’s so easy to update.

To change the location of the webroot folder, change the DocumentRoot setting of /etc/apache2/sites-enabled/000-default

For permalinks to work, mod_rewrite must be enabled. Also, the AllowOverride setting in the 000-default apache configuration file must be set to ‘all’.

From the AWS Management Console, click on the instance to see its public DNS information. This address is the publicly accessible IP address. The full domain name ending in ec2-xxx-xxx-xx-xx..compute.amazonaws.com can be used for the WordPress site and home URLs. You can also create a shorter address with DynDNS and point it to the IP address given.

Before your web server can be reached from the internet, there’s one more thing to do. Go to Security Groups in the AWS Management Console, it’s under the Network & Security section. Select the security group used by your instance. Add a new inbound rule for port 80 (HTTP). This is necessary for the web server to be publicly accessible.

Now that everything is ready, use any method you like to install WordPress. Remember to create a database and user first.

SSL Certificates

Strictly speaking, this isn’t a WordPress post. However, it is related to the server setup I use for WordPress development and testing.

I’ve been using Apache’s built in snakeoil SSL certificate because the server was only accessible on port 443. However, this gave that ugly and very scary looking untrusted SSL certificate error whenever I accessed my own development server. One day, I got sick of that extra click to confirm that I wanted to continue, so I decided to do something about it.

Generating a new Certificate

Information about generating self-signed SSL certificates is available in the documentation located at /usr/share/doc/apache2.2-common/README.Debian.gz

Run the command

make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /path/to/cert-file.crt

This will prompt for the hostname, where I put the domain name of the dyndns address. This command generates both the public and private key and puts them in the same file. The documentation suggests putting it in /etc/ssl/private

Configuring Apache

Modify the apache2 configuration in /etc/apache2/sites-enabled/default-ssl
Change the value of “SSLCertificateFile” to the path of the newly generated certificate. Comment out “SSLCertificateKeyFile” as both parts are in the certificate file.

Generating the Public Key for the Cert

Generate the public key portion of the certificate by running

openssl x509 -in /path/to/cert-file.crt -out /path/to/output -pubkey

Importing the Certificate

Copy the public certificate file to the host machine. You can also do this on other machines used regularly to access the web server.

From Start -> Run, type in ‘mmc’. Go to File->Add/Remove Snap-in, and add the certificate snap-in.
Expand Trusted Root Certification Authorities ->Certificates, then go to Action->All Tasks->Import in the menu.

Import the public key file. The default location is Trusted Root Certification Authority.

After this, Chrome and IE will no longer give scary looking warnings about untrusted certificates.

Error Establishing a Database Connection

I hadn’t started up my virtual test server since changing the network configuration to get port forwarding to work properly. Today when I tried it out, I got the dreaded “Error Establishing a Database Connection” message on all my local WordPress sites.

Even the mysql client couldn’t connect to the database, and of course neither could phpmyadmin. The database server was running and I had even restarted it multiple times to make sure. Removing it and installing it again didn’t help either.

I finally found the problem in the mysql config file in /etc/mysql/my.cnf. The bind-address setting was set to the old fixed IP address I had been using. I’m not sure why it hadn’t broken before when I first changed from a fixed IP to the Virtualbox NAT. I changed it back to ‘localhost’, restarted mysql server, and all my sites started working again.

EDIT: I realised from WordPress.com’s statistics page that there are quite some visitors landing here by searching for the title. The information above is probably not what you’re looking for.

If you’re getting this error on your WordPress.org self hosted install, check the settings in the wp-config.php file. If you’re unsure what the values should be, ask your hosts. Every host configures their servers in their own way. Some have the database on the same machine, so the DB_SERVER setting is ‘localhost’. Others might put it on a dedicated database server with its own hostname. Also make sure that your hosting plan lets you use a database. Some of the cheapest ones may not.

If you’re still stuck, post a question in the Installation or How-to and Troubleshooting sections of the WordPress.org forum.

Networking Woes

After changing ISP, I got a new modem with a built in wireless router. I managed to configure port forwarding and get it to work with my test server running on VirtualBox. Just for the record, the port forwarding interface on the device required me to select from a list of devices. I had to port forward to the host machine’s IP.

After some weeks of using the built in wireless router, I got tired of the weak signal strength. To be fair, it might be because it is placed in a less centralized location due to wiring constraints. I decided to connect my Linksys router to it and use the Linksys device for wireless service.

I had previously tried connecting a LAN cable from the local Ethernet port of the ISP provided modem to the WAN port of the Linksys device. That didn’t work at all. However, it does work when it’s connected to a LAN port on the Linksys device. I’m not sure why that’s the case as I thought putting it to WAN would just send all the packets through another layer of address translation.

Next step was to disable the wireless network on the built in modem and make sure that the Linksys router was configured with the desired settings. This was accomplished with the provided web administration interfaces.

When I tested the network, some devices could get Internet access, while some couldn’t. I had to disable and re-enable the wireless network adapter to get it to work.

Unfortunately, all these steps broke port forwarding to my guest OS. I had VirtualBox set up to use a bridged network, but it looked like the modem didn’t even recognize the guest as its IP did not show up in the list of connected devices.

I looked through the other network options in VirtualBox and looked up the documentation.

It turns out that with the NAT option, I could run a server on the guest OS if I configured port forwarding with VBoxManage. There’s even an example on the page.

Shut down the guest OS, change the networking option to NAT, and run the following command.

VBoxManage modifyvm "guest-name" --natpf1 "guest-https,tcp,,443,,443"

Restart the guest. As no IP address was specified with modifyvm, it is necessary to use DHCP on the guest. Change the networking settings, restart the eth interface, and try to access the web server.

A request to the web server now goes to the modem, where it is forwarded to the host machine, which then forwards it onwards to the guest! A little convoluted, but once again my test server is publicly accessible so I can ask friends for feedback.

WordPress 3.3

WordPress 3.3 is out!! Upgrade your sites now. Here’s what I did to upgrade.

  1. Backup the database. Using phpmyadmin provided by my host, I exported the database to a .sql file, just in case.
  2. Upgrade. Using SSH, I logged in to my webhost and ran the following command in the root directory of my site.
    svn co http://core.svn.wordpress.org/tags/3.3 .
    This works because I used SVN to install WordPress. Personally, I like this method as it is very easy to switch versions if I ever have to. I can even switch to trunk if I’m feeling adventurous. I have yet to do this though.
  3. Update the database. Visit domain.com/wp-admin/upgrade.php and a page will come up prompting for a database update. Just click the button.
  4. Update plugins. Slidedeck was the only plugin that needed updating. Remembering what happened the previous time, I backed up my custom skin first. Sure enough, the update overwrote the folder and I had to copy the skin back.
  5. Enjoy WordPress 3.3 🙂