So, now the script just pauses to remind you to deactivate your plugins.  I tried to find a way to automate that, but have struck out so far.  If you know how, let me know!  I’ll give you credit.

Script follows:

#!/bin/bash

# Updated by: Jerry Bell
# License remains intact
# Changes:
# - Added a backup directory that is outside the document root. The previous script left copies of the database accessible
# - Added code to automatically determine the database name, database username, and database password from the wp-config.php file.

# - Removed "read" prompts - they're not really needed any more

# - Set tar to send the archive to the backup directory instead of document root.
#
# This program upgrades your existing WordPress installations that you are running on your server.
#
# You need to make the necessary adjustments to this script as needed for your situation.
#
# Make this script executable: 'chmod 777 wp_upgrade.sh'
# Run the script: './wp_upgrade.sh'
#
# Author: Aaron Toponce
# License: GPL v2
# Version: 0.1.2

# =================== Start of Script =================== #

# Provide the necessary directories to what WordPress installations need to be backed up space delimited
# Change as necessary and uncomment
# For example, if you had 3 sites in /var/www/site1, /var/www/site2 and /var/www/site3
# then it would look like below (do not add the trailing slash):
# directories=(/var/www/site1 /var/www/site2 /var/www/site3)
backupdir=/var/tmp
number=${#directories[@]}
# Testing that all directories specified above are valid before beginning
for (( i = 0 ; i < number ; i++ )); do
        if [[ ! -d ${directories[$i]} ]]; then
                echo "Directory ${$directories[$i]} does not exist."
                return 1
        fi
done

# First, we need to get the necessary file
cd ~

if [[ -f wordpress.tar.gz ]]; then
        echo "wordpress.tar.gz exists.  Please take notice to this upgrade before continuing."
        return 1
fi

wget -O latest.tar.gz http://wordpress.org/latest.tar.gz

echo "First disable all plugins on all installations before continuing."
echo "Press ENTER to continue..."
read blah

for (( i = 0 ; i < number ; i++ )); do
        clear
        cd ${directories[$i]}
        back_ts=$(date +%s)
        mkdir ${backupdir}/backup_${back_ts}
        echo "We are backing up the full directory, in case anything goes wrong. Press ENTER..."
        read blah
        tar -cvvf ${backupdir}/backup_${back_ts}/backup.tar ${directories[$i]}
        gzip  ${backupdir}/backup_${back_ts}/backup.tar

        # Timestamp in unix epoch format to create unique backup directories

        echo "backing up database for ${directories[$i]}:"
        # Backing up the necessary WordPress database
        wp_db=`grep DB_NAME ${directories[$i]}/wp-config.php | cut -f 4 -d "'"`
        wp_user=`grep DB_USER ${directories[$i]}/wp-config.php | cut -f 4 -d "'"`
        wp_pass=`grep DB_PASSWORD ${directories[$i]}/wp-config.php | cut -f 4 -d "'"`
        mysqldump --add-drop-table -u ${wp_user} -p${wp_pass} ${wp_db} > ${backupdir}/backup_${back_ts}/${wp_db}.sql
        # Make the necessary changes for what to backup.  This is the default as provided by WordPress.
        echo "Backing up the important files. Press ENTER..."
        read blah
        cp .htaccess wp-config.php ${backupdir}/backup_${back_ts}
        cp -r wp-content wp-images wp-includes/languages ${backupdir}/backup_${back_ts}

        # Time to copy the latest wordpress that we downloaded and overwrite all files
        echo "Getting the latest cp of wordpress. Press ENTER..."
        read blah
        cp ~/latest.tar.gz ./wordpress.tar.gz
        tar -zxvf wordpress.tar.gz

        # Overwrite all files
        echo "Overwriting all old WordPress files with the new."
        cd wordpress
        cp -rf * ../

        # Copy the files that we backed up back
        echo "Coping the important backed up files back in."

        cp -rf  ${backupdir}/backup_${back_ts}/.htaccess ${directories[$i]}
        cp -rf  ${backupdir}/backup_${back_ts}/wp-config.php ${directories[$i]}
        cp -rf  ${backupdir}/backup_${back_ts}/wp-content ${directories[$i]}/wp-content
        cp -rf  ${backupdir}/backup_${back_ts}/wp-images ${directories[$i]}/wp-images
        cp -rf  ${backupdir}/backup_${back_ts}/wp-includes/languages ${directories[$i]}/wp-includes/languages

        echo "Point your browser to the necessary site and run the upgrade script."
        echo "EG: http://example.com/wp-admin/upgrade.php"
        echo "Update your permalinks and .htaccess."
        echo "Install updated plugins and themes"
        echo "Reactivate plugins"
        echo "Press ENTER to continue..."
        read blah
done

clear
echo "Congratulations! You have successfully upgraded your WordPress."
echo "Please review that your browser resolves your site."
echo "Enjoy!"

Background

The “cost of entry” to run a website is very low now, and we have seen an explosion of small sites on the Internet. Supporting this trend has been the availability of free and open source applications that allow site owners to do nearly anything they want, from blogs to wikis to forums. 

Unfortunately, nearly all of the software has inherent bugs that can be exploited by bad people. The exploitation of such bugs has matured in a similar fashion to the applications themselves.  Compromised web sites are a foundation to many threats currently on the Internet. Site owners are unknowingly supporting illegal activities such as:

• Hosting warez
• Hosting copyrighted files
• Hosting tools to compromise other sites
• Sending massive amounts of spam
• Host phishing sites to steal money
• Become part of command and control for botnets

Running a web site properly is truly becoming a social responsibility. If you are not part of the solution, you are likely part of the problem. 

This guide outlines some general and basic security measures that you MUST take if you want to make sure your site is not defaced or otherwise compromised.

Key elements needed in a web hosting platform

Try as you might, if another site on the server you share does not follow prudent security measures, then your site it still vulnerable. Suphp executes php scripts as the user-id and group-id of the account – not the userid/group id of the web server.

This will allow more restrictive permissions on your directories and will prevent an attacked from being able to read your php files.

Some hosts will not want to use suphp, as it can cause performance problems.

Build a relationship with provider on dealing with security issues

Firewall outbound connections

 This is not always practical or possible, but firewalling traffic originating from the server – other than what is expected – can prevent backdoor tools from phoning home.

Run suhosin patch for php

Suhosin can stop the exploitation of many different types of coding weaknesses and some vulnerabilities in php itself.

Keeping up with the web software you use

• Subscribe to mailing list for any application software used as part of your site.  Nearly all such applications have an “announcement” list that is low traffic.
• Attempt to participate regularly in the forums or discussion lists for the software you use. You will often get advanced warning of security issues and interim fixes.  You will also know if the software is at risk of being abandoned and not updated.
• Upgrade after a security fix release within 3 days.  Vulnerabilities are often exploited soon after they are discovered.
• If an application you use becomes abandon, plan to migrate your site to a new tool as fast as possible.
• Try not to customize software.  This will slow down your ability to patch or upgrade, because you’ll have to rewrite code, test, etc, and that can be difficult to do when it’s not on your timeline.
• Attempt to remove ‘powered by’ and version number references.  Nearly all open source web applications proudly, but this has turned out to be an extrodinarily efficient way to systematically identify sites running vulnerable software. 
  
• Create a file with a random name in your html directory. Do not reference the file in your site. Grep your web logs daily for the file being accessed. Any hits may indicate that your site has been compromised.
  
• Scan for file differences and notify of differences
  

Your responsibilities as a site owner

• Perform frequent off-site backups.  Even if you have a local backup strategy, such as to another server, it is imperative to maintain an offsite backup.  While it doesn’t happen often, datacenters are broken into and servers are phyically stolen.
• Do not store sensitive data like credit card numbers.  Just don’t do it.
• Change account passwords regularly