Open Source Activism

Marking a user as a spammer in Wordpress MU is rather straightfoward. The steps to do this are below.
(more…)

Deleting a user in Wordpress MU is rather straightfoward. The steps to do this are below. Remember, you cannot undelete a user in the admin screen. You can only do that by restoring a database backup which you should not do under most normal circumstance.
(more…)

We got hit with a barrage of spam signups yesterday. I was able to shut them down yesterday, but I have just completed cleaning up and adding keywords exclusion lists to prevent much of this in the future. I know I have still have many offensive words to add to my lists, so if you have any suggestions please email them to me at Email Me. (I use Email Address Obfuscator to encode my email address. More on that in another post.)
(more…)

Have you ever seen this error in your Wordpress feed?

XML Parsing Error: xml declaration not at start of external entity

I have now, multiple times. It is something that is so easy to cause without even knowing how it happened or that it happened at all for hours or days.

We use Wordpress MU here at Blogivists running on a Linux server. On the main page we have a feed that displays the latest posts from all of the blogivists blogs. Yesterday, we discovered our feed was broken and displaying the error shown above. I had seen this error before when securing the website.

I recognized it immediately as being blank lines in the code outside the php tags of . The problem becomes finding the errant code. If you don’t have shell access you will have to go through each file you have changed to find the error. With shell access the task becomes a little easier. I intend to make it even easier for you.

I started by doing the following in the webroot of the website:

find . -mtime -1 -name \*.php

This gave me a list of all files that had been changed in the past 24 hours. I then stepped through each file looking for the problem. This was a tedious and slow process. I started with files in wp-content/plugins and wp-includes. I had no luck.

Next I wrote a quick script that printed the first 2 and last 2 lines of each php file. I then worked my way through the list and again found nothing.

I assumed at this point that something was getting printed incorrectly. I added print statements throughout the feed building code (FeedWordPress) until it was obvious that my first thought was correct, a file had whitespace before or after the php tags.

I reran the find command from earlier. At this point I started checking the themes themselves. I had skipped those earlier since I did not think theme templates would have an effect on the feed building. I discovered themes do have an effect, particularly since the theme that caused the problem was the main page theme. I finally discovered the functions.php file had been edited and 2 blank lines had been placed at the top of the file before the <?php. I removed those and the feed was working properly again.

Now, to make this easier for everyone and myself when this happens again. I wrote a script that will run through every php file and check the to make sure there is no whitespace before the starting tag. As a side note here, you can remove the ending tag ?> to eliminate that issue, however it won’t prevent the leading whitespace issue. I don’t do that because I think it is bad coding style to not close all tags.

You can download a gzip file that contains the test files and script source by right clicking and choosing Save Link As on the following link (Check Whitespace Download). These are written for Linux, but could be modified for Windows is you wish. Included in the file are my test files. I’ll outline the process below so you can see how it works.

The first script is a bash script that prints a file tree into a text file and starts the perl script that does the actual searching.

find . -name \*.php > checkfiles.lst
perl checkfiles.pl

The perl script loops through the file list and checks the beginning and end of the file. Here is the code segment to check for any whitespace before the <?php tag:

for ( $line=0; $line < $rows; $line++ ) {
#print “line $line: ” . $myfile[$line];
if ( $myfile[$line] =~ /^[ 0 ) { print "$fname - check leading whitespace\n"; }
break;
}
}

For both of those segments the current file has already been read into an array. This makes the searching must easier to accomplish. Basically all I am doing is checking each line to see if it contains <?php. If it is not the first line I print out a message to check the beginning of the file.

Checking the trailing whitespace is just the opposite. I start with the last line and walk backwards looking for ?>. Here is the code segment that checks the end of the file:

for ( $line = ($rows-1); $line >= 0 ; $line-- ) {
#print "line $line: " . $myfile[$line];
if ( $myfile[$line] =~ /[?][>]/ ) {
if ( $line < ($rows-1) ) { print “$fname - check trailing whitespace\n”; }
break;
}
}

Hopefully you will never need to run any of these checks, but if you do this should make your life much easier.

Website backups go hand in had with security. They are security for a disaster or if you website gets hacked. You should make regular backups of your website. This applies not only to websites, but blogs, Joomla and Mediawiki sites.

Most hosting companies do not do backups for you. They backup the server installation, but leave you on your own for your blog. The better hosting companies will do periodic backups of your websites. If anyone know hosting companies that do or don’t provide backups please add them in the comments. I am talking about the basic hosting services that many bloggers and simple websites use. Siteground does weekly backups, while Hostmonster, Dreamhost, and Cyberwurx do not.

To do a backup, you usually have 2 options with most hosting company control panels. These 2 methods are as follows:

1. Full backup of your entire site
   • Includes your website, database and home directory files
   • Options:
     1. Save this to your local computer
     2. Backup locally on the hosting server and then download when complete
2. Separate backups for your database and your website
   • Run this after you add plugins, themes, images, podcasts, videos or other files on your website
   • Backup your database on a more regular basis

My recommendations for backups would be to do a full backup after you have your website completely setup and then again once a quarter. I would then recommend doing a website only backup monthly unless you make many changes to your website on a regular basis. This does not count frequent posting updates. I would then do the website backup at least weekly or whenever a large number of changes are made. Lastly, I would recommend backup up the database at least weekly. If you post multiple times a day you may want to make backups daily or find a service that does it for you.

To make these backups faster, more reliable, and quickly accessible, allow the backups to run locally on the hosting server. When it is complete, download them to you local computer.

While on the topic of Wordpress, I thought I’d share 2 simple and quick tips to help secure your Wordpress blog installation.

Security Task 1
The first tip is one you should have done when you installed Wordpress, but is easy to skip over and not do. This task is to remove the install program. If not, you run the risk of someone trying to reinstall your blog or what is more likely using it to get information about your account and server to hack your database. To remove the install program do the following steps:

1. Log into your hosting account control panel
2. Open the file manager and traverse to your blog/wp-admin directory
3. Find the install.php file and delete it. If you wish you can download it to your computer first if you are paranoid about having a copy.

Security Task 2
The second task involves your blogs database security. Wordpress, along with many other web programs, place their database settings in the configuration file that resides within the web directory. For Wordpress, that file is wp-config.php and it resides in the root blog directory.

In most instances nothing will ever come of this although it is a major security risk. What can happen is that for some reason your blog does not work and displays the actual php code, you just exposed your database settings to a potential hacker. They can use this to delete or edit your content very simply. To fix this, do the following:

1. Log into your hosting account control panel
2. Open the file manager and traverse to your blog root directory
3. Edit your wp-config.php file
4. Find the lines of code that contain your MySQL settings. They’ll look similar to the following example code. Leave this window open for later use.
   

   // ** MySQL settings ** //
   define(’DB_NAME’, ‘putyourdbnamehere’); // The name of the database
   define(’DB_USER’, ‘usernamehere’); // Your MySQL username
   define(’DB_PASSWORD’, ‘yourpasswordhere’); // …and password
   define(’DB_HOST’, ‘localhost’); // 99% chance you won’t need to change this value

5. Copy these MySQL setting lines so you can put then into a new file outside of your web root directory. For example, your account directory when you log into your file manager is /home/youraccount. The web root would most likely be /home/youraccount/www or /home/youraccount/public_html.
6. Create a new file in /home/youraccount directory. You can name the file whatever you wish, just make sure it ends in .php as shown in the example. For this example the name to use is blog.database.php
7. Open blog.database.php and insert the lines copied in step 4 above as follows:
   

   <?php
   // ** MySQL settings ** //
   define(’DB_NAME’, ‘putyourdbnamehere’); // The name of the database
   define(’DB_USER’, ‘usernamehere’); // Your MySQL username
   define(’DB_PASSWORD’, ‘yourpasswordhere’); // …and password
   define(’DB_HOST’, ‘localhost’); // 99% chance you won’t need to change this value
   ?>

   Notice the 2 additional lines, 1 at the beginning and 1 at the end. This tells the web server to run this file as PHP code. If you don’t put these lines in the file, you will again have your database information shown in plain text in the browser. An additional tip here, DO NOT leave a blank line after the final ?>. If you do, you will have unexplained issues in your Wordpress Control Panel, particularly in the Presentation and Plug-In screens (and yes, I found that out the hard way).

8. Go back to your wp-config.php window and remove the MySQL setting lines now and replace them with the following:
   

   require_once( ‘/home/youraccount/blog.database.php’ );

9. Test your blog to make sure everything still works. If it does not, retrace the steps here to make sure you don’t have any misspellings and everything is correct before trying again. Linux is case sensitive, so also ensure the capitalization is correct. I would suggest going all lowercase anyway for simplicity.

These steps are simple, but effective in protecting your blog. Of course these won’t protect against every attack, but they go along way in protecting you. In addition, in case of a disaster you still have the backup that you can restore. Hopefully , you’ll never need any of these tips. However, it is better to be prepared just in case.

Since I setup the webserver myself, I have total control. Because of this, there are occasional permission issues that I run into. Yesterday this happened with Wordpress Permalinks.

To change Permalinks, you do so under Control Panel -> Options -> Permalinks. The best choice is Date and Name based, This is better for SEO (Search Engine Optimization). Unless you are familiar with wordpress paramaters, I would stay away from the custom choice.

Once you choose the option you want click “Update Permalink Structure”. You should see a message at the top saying “Permalink structure updated.” My first issue was that the .htaccess file was not writable. You can read more about these at httpd.apache.org/docs/1.3/howto/htaccess.html. I won’t get into the discussion of whether these files are good or bad at this time. Simply put they are required for wordpress blogs if you do not control your own server.

.htaccess files (or “distributed configuration files”) provide a way to make configuration changes on a per-directory basis. A file, containing one or more configuration directives, is placed in a particular document directory, and the directives apply to that directory, and all subdirectories thereof.

I created the .htaccess file in my root web directory and make it writable by the web server, i.e. on linux it is 664. This time when I clicked update the file was saved and the Rewrite Rules were written into the .htaccess file. Here is a sample of what it wrote:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

I still had a problem though. The permalinks still did not work. Since I was controlling the apache configuration I tend to keep it more locked down. So I went to my configuration include file for this domain and made the following additions:

Options Indexes FollowSymLinks
AllowOverride FileInfo Options

These were added inside the tags. I then restarted the apache service. Everything now worked.

I am planning on taking you through the entire process of setting up Wordpress and even a web server as I have time.

I’ve finally decided to start a technology blog. I have had friends encourage me to do this for a while. My intent will be to blog about what I do to setup open source technology in my work to help with political activism. I will blog mostly about the following open source packages and topics:

• Wordpress - blogging software utilized by Blogivists
• Joomla - CMS system that contains blogs, forums, polls and other features
• Mediawiki - Software used by Wikipedia
• Web server setup/management
• Internet Identity