This page is obsolete. Please see QmailToaster-Plus for the current version.
The original upgrade.sh script was written by Jake Vickers.
Backup and restore of configuration files was added by Devendra Meena.
Thanks go to Jake, Nick, Erik, and Devendra who contributed to the previous upgrade.sh script. I could not have written the new script without their previous work as a starting point. -ES
On July 13, 2006 Eric 'shubes' announced to the email list the release of new upgrade scripts. The new scripts are a substantial change to the former process, and thus go by new names, qtp-newmodel and various qtp-* sub-scripts. They create a new model of QmailToaster with minimal effort and downtime.
The scripts have undergone substantial testing and use, and are now considered to be Production status. Please report to the list any problems and/or suggestions.
Here's an overview of what the scripts do (in sequence):
- Determine the DISTRO and ARCH variables - the qtp-whatami script interrogates /etc/*-release to see which distro your machine is, and sets variables accordingly. If your distro isn't supported, the newmodel script will not continue.
- invokes qtp-config to set common environment variables
- Downloads current package list from the official QmailToaster, and optionally the Development web sites
- If bind is installed on the machine, djbdns is removed from the list(s)
- Checks to see which packages are not installed, and lets you select which ones to process. Normally, you'll want to select all that are available. You may also select packages from the Development site for the latest features.
- Downloads source packages from the official QmailToaster or QmailToaster Development web site.
- Builds the sandbox by invoking the qtp-build-sandbox script
- chroot to the sandbox and invokes qtp-build-rpms, which:
- invokes qtp-remove-pkgs to remove certain packages from the sandbox
- builds and installs each package in the sandbox
- copies the binary rpms out of the sandbox
- backs up control and configuration files
- stops qmail
- invokes qtp-remove-pkgs to remove certain packages that need to be removed
- upgrades the packages with a single rpm -Uvh command
- restores control and configuration files
- invokes qtp-convert to do conversion processing:
- mrtg file changes
- mysql password location change
- starts qmail
- runs spamassassin debug configuration
- cleans up source rpms, binary rpms and the sandbox
That's it in a nutshell.
Some aspects of the script:
- all questions asked (except the first one) have a default value. If you're not sure what to do, take the default.
- all directories are created automatically by the script.
- the script has one command line option: -b which will run the script without prompting. This is convenient if you don't want to babysit it, but should not be used until you're comfortable with the process. To run it in background, probably overnight, you might do something like:
# qtp-newmodel -b >qtp-newmodel.log 2>&1 &
- the compile output (and some other stuff) is sent to a log file instead of the screen. This can be useful for problem determination.
- the script can be interrupted (preferrably by using quit when asked) and rerun at a later time, and all previously completed work is saved. This means you can run it at any time to download and build the rpms (the most time consuming), then run it again later when you're ready to actually do the upgrade. During development testing, the upgrade portion for all packages took less than 10 minutes (most of which was generating domain keys) on a P-II/266.
The sandbox is essentially what is more commonly known as a chroot jail. The term sandbox is used instead of jail because few people are fond of jail, and the purpose of this sandbox is to provide a safe place to play (which a sandbox is for the most part).
The sandbox is basically a copy of a (very) large portion of your system. Hence, it occupies a good deal of disk space, probably 2.4G or better. It also takes quite some time (20 cpu minutes or so on a P-II/266) to build, but this is only a fraction of the time it takes to compile. A good trade, given the savings in down time.
Just before the sandbox is built, you will be asked if you'd like a copied or linked sandbox. A copied sandbox is a normal copy of files on your system.
For a linked sandbox, the script will attempt to use hard links instead of copies for a majority of the files, drastically reducing disk space required (down to as little as 100M). However, this savings can only be achieved when the sandbox and other major system directories are contained on the same partition as the root (/) filesystem, as hard links cannot cross partition boundaries. The script will automatically copy files which are on separate partitions when trying to build a linked sandbox. Any partition scheme should work, although a linked sandbox provides the greatest savings when the system is largely on a single partition.
The sandbox can be placed on any mounted partition. If the sandbox is on a partition other than root (/), the linked option will not be available.
Note regarding reuse: If any substantial packages (i.e. qmailtoaster-plus, OS libs) have been upgraded since the sandbox was built, you should create a new sandbox (the script gives you this option). Otherwise, the sandbox can safely be reused.
To run the script(s), at the command prompt simply enter:
You may also invoke it from qtp-menu, which is part of QmailToaster-Plus too.
Simply answer the questions at the prompts, and that's all there is to it!
There are three variables set by the qtp-config script that you may care to change, although it is strongly recommended that you change them only if you have a good reason to do so and you know what you are doing:
- UPGRADE_DIR=/usr/src/qtp is a general working directory. Subdirectories are SRPMS, RPMS, backup, old-rpms and log (pretty much self explanatory).
- SANDBOX=/opt/qtp-sandbox is a directory where the sandbox is built. See The Sandbox above for considerations. This should point to a directory that does not yet exist, and is used exclusively for the sandbox.
- RPMBUILD_OPTIONS is a variable the contents of which are included in the rpmbuild command for all packages. This can be set to any valid rpmbuild parameter, such as RPMBUILD_OPTIONS="-v" to turn on verbose mode, or RPMBUILD_OPTIONS="--quiet" for quiet mode.
If you need to tailor the rpmbuild command for a specific package, you can do so by creating a file in the /opt/qmailtoaster-plus/etc/rpmbuild directory containing the command line option(s) to be used for building the package. For example, if you want to use the "--define 'spambox 1'" option for the qmailadmin-toaster package, you simply create a file named qmailadmin-toaster in the rpmbuild directory that contains "--define 'spambox 1'" (without the double quotes). There is a qmailadmin-toaster.sample file included in the QmailToaster-Plus package for reference.