I am happy to announce the release of a new upgrade script. Before I get
into the nitty gritty, I'd like to thank Jake, Nick, Erik, and Devendra
for their work on the previous upgrade script. Without it, I couldn't
have written the new one. Additional thanks to Jake for help with
testing, and Nick for helping with implementation.
The scripts are available (for the time being) at
http://qmt.shubes.homeip.net. I expect that Nick will make them
available on the toaster website sometime soon.
There are two scripts, and you'll need both of them. The main script is
qmt-newmodel.sh, and qmt-build-rpms.sh is a sub-script (so to speak).
Simply download them to any directory you like (they need to be in the
same location though). To run:
# sh qmt-newmodel.sh
-or-
# ./qmt-newmodel.sh
from the directory where you put them.
Notice, the scripts have undergone substantial testing, but should still
be considered beta. Please report back to the list any problems and/or
successes.
There are two variables set at the beginning of qmt-newmodel.sh that you
may care to change:
.) UPGRADE_DIR=/usr/src/qmt is a general working directory.
Subdirectories are SRPMS, RPMS, backup, old-rpms and log (pretty much
self explainatory).
.) SANDROOT=/opt/qmt-sandbox is a directory where the sandbox is built.
More on the sandbox in a moment.
All directories are created automatically by the script.
Here's an overview of what the scripts do (in sequence):
.) Determine the DISTRO and ARCH variables
The script interrogates /etc/*-release to see which distro your machine
is, and sets variables accordingly. If your distro isn't supported, the
script will not continue.
.) Downloads current package list from www.qmailtoaster.com
.) If bind is installed on the machine, djbdns is removed from the list
.) Checks to see which packages aren't installed, and lets you select
which ones to process. Normally, you'll want to select all that are
available.
.) Downloads source packages
This essentially does what the former current-download-script did.
.) Builds the sandbox
.) chroot to the sandbox and invoke qmt-build-rpms.sh, which:
.) builds and installs each package in the sandbox
.) copies the binary rpms out from the sandbox
.) backs up control and configuration files
.) stops qmail
.) removes any packages that need to be removed
.) upgrades the packages with a single rpm -Uvh command
.) restores control and configuration files
.) handles mrtg file changes
.) starts qmail
.) restarts spamassassin
.) cleans up sandbox, source rpms, and binary rpms
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.
.) 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 I wouldn't use it until you're comfortable with the process. You
might do something like:
# ./qmt-newmodel.sh -b >newmodel.log 2>&1 &
to run it in background, probably overnight.
.) 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 previous work is saved. That means
you can run it any time to download and build the rpms (the most time
consuming), then run it again when you're ready to actually do the
update. During 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 script can be used to do a new installation too. It replaces
steps 6 and 7 in the install guide.
Now for a few words about the 'sandbox'.
The sandbox is essentially what is more commonly known as a chroot jail.
I like the term sandbox better than jail, because I'm not fond of jail
(who is?), 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 my puny
P-II/266) to build, but only a fraction of the time it takes to compile.
A good trade IMO, given the savings in down time.
When 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. A linked sandbox will attempt to use hard links instead of
copies for the 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 is 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.
As a final note, I would not use the linked option on a production
server until it has been more thoroughly tested. However, a copied
sandbox should be safe.
That's about it for now. I welcome all suggestions, and should be
readily available in the near future to assist with any problems you may
encounter.
Updated documentation on the wiki site is forthcoming.
NJoy!
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
