Recently in Servers Category

In Movable Type 4.0 users had the option of offloading the task of publishing to a separate program or application called Publish Queue. This had the advantage of dramatically increasing Movable Type's performance and reliability.

Most users run Pubish Queue via a scheduled task that wakes up at a fixed internal, executes and then quits. However, some users use Publish Queue's "daemon mode" to make it so that it is always running. But its own daemon mode does not have the capability to monitor and restart itself should it unexpectedly quit, exit or die.

Should Publish Queue crash the consequence would be that publishing would simply stop without you ever really knowing about it. Plus you couldn't start it up again without you manually going into the server and starting the publish queue up again. This rarely happens in actuality, but in a business critical application, you never want this to happen. Period.

Of course this problem is not unique to Movable Type. Many programs in Linux should be running at all times to ensure that the operating system functions properly. That is why there exists a suite of utilities in Linux called "damon tools." Together these tools can be configured to monitor any script and ensure that it is always running. If the script/application dies, then daemon tools will restart it. Handy.

This article discussed the process for those unfamiliar with daemon tools with how to get started and how to configure it so that you can relax knowing that Movable Type's background publishing engine will never stop running.

A few weeks ago I got a telephone call from my web host letting me know that "one of your Movable Type CGI scripts is using up half the resources of the server and would you please disable the script before we find it necessary to close your account?" Don't you just love news like that? Fortunately, it all got sorted out within a couple of hours; here's the scoop.

If you've had your MT blog for a while, since before version 3.2, you may have upgraded your MT installation, but didn't bother to make changes to the code in your templates. In the templates for one of the earlier versions of MT, if you use Typekey authentication, the Individual Entry Archive Template calls the comments.cgi script to invoke a javascript file that reads back to the commenter their name. Turns out that every time a page displays that includes a Typekey-authenticated comment, the CGI script will run. One of my sites is fairly high traffic, and starting some time last year I was getting over 25,000 requests to the comments.cgi script each day.

This is the line of code that can bring your server to its knees:

The solution is easy. Really easy.

Updated. Originally published Jan 2, 2004

Error messages are the messages that are displayed when a visitor to your site encounters a server error. The most common error messages are 404: File Not Found and 403: Access Forbidden. The 404 error message is displayed when a visitor to your site tries to access a page that does not exist on your server. The 403 message is displayed when a visitor tries to enter an area on your site that is off limits to the public.

You can customize your error messages so that instead of seeing an ugly server message, your visitor sees instead a personalized note from you. The methods are different depending on if you are doing static (the default) or dynamic publishing in Movable Type.

Updated October 16, 2004

The first step in installing Movable Type is making sure that your web host meets MT requirements. In addition to the basic requirements there are many other factors to consider, in particular the quality of support, the reliability of the service, and the degree to which the host's staff is familiar with Movable Type. Which web host you choose can make a big difference in terms of the ease with which you install and maintain your MT weblog.

What to Look for in a Host Provider

Absolutely Necessary:
1. Ability to run custom CGI scripts
2. Perl installed on server, version 5.004_04 or greater.

Practically Essential:
3. MySQL (although MT works with Berkeley DB, MySQL is much more powerful and stable)
4. PHP (necessary for many customizations)
5. CGIWrap or suEXEC (for added security in shared server environments)

Co-authored by Elise Bauer and Arvind Satyanarayan.
Tutorial cross posted on Movalog and Learning Movable Type

The installation instructions in the Movable Type Install Guide contain a section in the Configuration area called Enable Security Features. These instructions tell you to uncomment the Umask lines in your mt.cfg if your server is running cgiwrap or suexec. If you don't know what CGIwrap or suEXEC are, you may be tempted to skip this step. Don't. This step gives your MT installation extra security, which we will explain. (Note that this tutorial is only appropriate for MT installations on Linux/Apache web servers.)

What is CGIWrap or suEXEC?

CGIWrap and suEXEC are features installed by your web host that give extra security to your files in a shared server, or "virtual host", environment. Most Movable Type weblogs are hosted at commercial web hosts who are able to give their customers affordable server space by hosting the files of several customers on a shared server. In a shared server environment, CGIWrap and suEXEC allow your cgi files to be executed with you as the account "owner". The cgi scripts can then create files with more restrictive permissions (644) that keep others from editing your files, yet still allow you to edit them. Without CGIWrap or suEXEC, cgi scripts create html files that need to have more relaxed permissions (666) so that the account owner can manage those files.

Co-authored by Elise Bauer and Arvind Satyanarayan.
Tutorial cross posted on Movalog and Learning Movable Type

Future posting is a convenient new feature in MT3.1x, allowing you to create an entry and have it automatically post at a future time. But before you can use this feature you need to set up a Cron Job on your server.

What is a Cron Job?

Cron is a task scheduler for unix servers. A cron job is a specific task that runs a certain number of times per minute, day, week, or month on your server. For example, you can use a cron job to automate a daily MySQL database backup. The main problem with cron jobs is that if they aren't properly configured they can cause high server loads which may result in suspension of your site with your web host. If you are able, configure your cron job so that the results of running the scheduled script are emailed to you.

There are two main ways by which you create a cron job on your server: cPanel, and using shell access to your server. Cpanel is the easiest way; shell access requires knowledge of UNIX editing commands and should only be attempted by those familiar with such commands.

One way to set up a private, password-protected weblog is by adding a .htaccess file to the directory in which the weblog resides. htaccess files can give you extra control over your server, allowing you to password protect directories, enable server side includes, generate custom error messages, and block users by IP address among other things. I've already described the fundamentals of .htaccess in another tutorial, see What is .htaccess? If you are setting up .htaccess for the first time, be sure to read this tutorial thoroughly.

1. Create .htpasswd

The first thing you need to do, before creating your .htaccess file, is to create a file called .htpasswd, which will hold the user names and passwords of those you to whom you are giving access to your private weblog. You will need to encrypt the passwords. It has been recommended by a commenter here that you not use a web-based password generator site for security reasons. The same commenter notes that if you have root access to your server, SSH to it, change to the directory you wish to create the .htpasswd in and type "htpasswd -bc .htpasswd username password" (without the quotes; replacing username with your username and password with your desired password). The "c" mean "create a new file" and the "b" means "use the password given in the command line (rather than prompting for it)". If you do not have access to your server, it is suggested that you have your server admin do this for you.

For example, the name "bartlett" and password "westwing" would look like this, encrypted and ready to be placed on your .htpasswd file: bartlett:09ArhAKMeRSE6

Create the strings of user names and passwords for those to whom you will give access to your private blog.

Copy and paste these into a text editor, one line for each name:password. Save the file to your desktop; note that you probably will not be able to save it with the (.) in front of htaccess. That's okay, make the change when you upload the file to your server with FTP.

Co-authored by Arvind Satyanarayan and Elise Bauer
Tutorial cross posted on Movalog and Learning Movable Type

With the release of Movable Type 3.1 comes a new and powerful feature - Dynamic Publishing. To take advantage of Dynamic Publishing, you need to edit or create a file on your Apache server called .htaccess as explained in the Movable Type Manual. htaccess files can give you extra control over your server, allowing you to password protect directories, enable server side includes, generate custom error messages, and block users by IP address among other things. (See this Guide to .htaccess for more information.)

Note: You should really know what you are doing before attempting to work on an htaccess file. It is a powerful and potentially dangerous file. In some extreme cases you could lock yourself out of your domain completely, including the use of back-end tools such as cPanel and FTP. (Elise once took her site offline for several hours unintentionally after changing the code on a .htaccess file. Fortunately her web host tech support came up with the proper code that got the file and the site working again.) If you are unsure, check your .htaccess code with your web host before uploading. You might want to experiment with a .htaccess file in a subdirectory first, to avoid causing site-wide problems. We take no responsibility for what may result on your server by following these instructions.

This tutorial needs to be updated for MT4, which has a back-up utility built-in. ~Elise

Occassionally databases get corrupted, servers fail or web hosts go out of business. So it's a good idea to back up your Movable Type blogs. There are many methods for doing so, a few of which I will cover here. The back-up process is much easier if you are using MySQL as your database.

Backing up your MT blogs with MySQL

If you have chosen MySQL as your database for your MT install you can easily back-up the entire blog - entries, comments, authors, templates, etc. - with a simple MySQL "dump" command. The dump command will create a large "dump" file that will have all of the data from your database in it that can be used to easily restore all of your weblogs. To do this you need either command line access to your database or phpMyAdmin installed on your server. The instructions for the dump command and phpMyAdmin can be found in the MT 3.2 User Manual. You can also find instructions for the dump command at MySQL's website. All that said, phpMyAdmin is not installed on my server and I could not get the dump instructions to work. So I ended up needing some handholding from tech support from my web host. Tech support also set up a "cron job" for the server to automatically create a dump file, backing up all of my blogs every night. Every few days I FTP into my server and download the dump file to my desktop, so I have a local copy of the database.