Drupal-powered websites can be put into an "offline mode." This is much better than most alternatives (such as taking the web server offline), especially for search engines, as the message and HTTP status codes given to users and robots alike will tell them to patiently come back later.

I've found that putting the site into offline mode makes database backups go much faster on heavily trafficked sites (which is obvious). However, for a particular site I was working with, this needed to be done in an automated manner, and on a dedicated database server that did not have access to the Drupal installation.

Most people take their Drupal sites offline through Drupal's web-based administration interface. They can also be put offline through the Drupal Shell. Neither were suitable for me: the former cannot be automated easily, and the latter requires access to the Drupal installation. Fortunately, Drupal sites can easily be taken offline by setting things in the database, which can easily be done via bash scripts and the command-line MySQL client.

Given your database user is my_db_user, password my_password, and database my_drupal_db, the backup script would look something similar to:

Update: The original version of this article had some problems on some setups with the variables table being cached. I added another SQL statement to make sure this cache is flushed so the site actually reflects its configuration.

Update: This method really doesn't work that well, and the more I think about it, there isn't a way to get around writing something that interacts with Drupal. I'm working on a script that will be more fool-proof.

A page in the Beyond Linux from Scratch manual describes environment variables that should be set when installing software in a non-traditional location (e.g. your home directory).

I've written a sh/bash include that can be included from .bashrc to set these variables, as well as PYTHON_PATH for separately installed Python libraries:

Many versions of SSH, including the extremely common OpenSSH, provide support a feature known as "X11 forwarding."

Say on you are on one computer running an X server. You want to be able to run a GUI program on another computer (to, say, access files on it), but display the program on the computer you're sitting at. SSH's X11 forwarding lets you do this easily in one command, without having to worry about firewalls and permissions.

But it's a bit slow. There are several options to SSH that you can use to make things faster.

The "-c" option allows selection of cipher for a connection. The default AES cipher is extremely slow: you can get much better performance out of the arcfour and blowfish ciphers. I've noticed arcfour to perform the best, but there have been legitimate complaints in the cryptography community about whether or not it is "secure." If your paramount concern is security, go with blowfish, as it can be just as fast.

The "-C" option enables compression for an SSH connection. On anything but LAN links, compression can make a big difference. SSH performs packet-based compression. That is, it can only compress the data immediately available to it, whatever may be contained in the packet it is currently processing. This immediately limits how much compression can be done, and results in bad compression ratios. But it is usually better than nothing.

All this can be incorporated into a simple bash alias:

To run a program "xterm" on machine "baz.example.com" but display its GUI on the local machine, simply run:

A new addition to my .bashrc, a bash function that will swap Macintosh newlines for UNIX ones: function mac2unix() { sed 's/\r/\n/gi' } To use it, pipe it as so:

This will convert Macintosh newlines from files that Mac friends forgot to upload in ASCII mode. If this is not done, programs will ignore the Macintosh newlines and files will have no newlines, which goes without saying is very annoying.