Chris Tyler - Fedora Linux

%_repackage_all_erasures 1

To configure yum , edit /etc/yum.conf and add the tsflags ( transaction set flags ) line shown in bold here:

[main]

cachedir=/var/cache/yum

debuglevel=2

logfile=/var/log/yum.log

pkgpolicy=newest

distroverpkg=redhat-release

tolerant=1

exactarch=1

retries=20

obsoletes=1

gpgcheck=1

exclude=*xorg* *xfree* *XFree* *kernel*

tsflags=repackage

# PUT YOUR REPOS HERE OR IN separate files named file.repo

# in /etc/yum.repos.d

The tsflags line may appear anywhere after the [main] tag.

Once you have set this up, any package removal or upgrade (which is actually an installation and a removal performed together) will create a backup of the old data.

You can then roll back to a particular point in time by performing an upgrade with rpm and specifying the --rollback option with the time you wish to revert to:

# rpm -Uhv --rollback '10 minutes ago'

Rollback packages (+1/-0) to Sat Oct 29 15:23:40 2005 (0x4363cc3c):

Preparing... ########################################### [100%]

1:abe ########################################### [ 50%]

Cleaning up repackaged packages:

Removing /var/spool/repackage/abe-1.0-5.i386.rpm:

Notice that the rollback installed one package and removed no packages (+1/-0) , and that the rollback data was deleted after the rollback.

The format for --rollback values is quite flexible; most reasonable dates and times are interpreted correctly. Here are some examples:

# rpm -Uhv --rollback 'last Monday'

# rpm -Uhv --rollback '2 hours ago'

# rpm -Uhv --rollback '10 Jan 2007 16:30'

# rpm -Uhv --rollback 'march 17'

# rpm -Uhv --rollback '9:00 am'

# rpm -Uhv --rollback '4:30 pm last Monday'

# rpm -Uhv --rollback 'yesterday'

When repackaging is enabled and RPM package updates or removals are performed, the metadata for the package to be removed is combined with the current state of the package's files to create a new RPM package. This is different from the original package used to install the software because it reflects any changes that were made to the package's files. Configuration changes, deleted files, high scores, changes in sample data, and script modifications are all included in the repackaged file. This permits the package to be restored in exactly the same form as it was when it was removed.

However, files that were not in the archive portion of the original RPM package are neither repackaged nor erasedso if you install a package such as MySQL and create files with it (databases, in the case of MySQL), those files will not be removed when MySQL is removed, and they won't be restored if the package removal is rolled back.

Repackaged files are in standard RPM format, with two exceptions: the transaction ID (date and time of the transaction in seconds since the start of 1970) is recorded in the RPM, and the signatures and hashes are usually invalid because the repackaged files are different from the original files (at least the modification time of the files has changed, and in many cases the contents of one or more files, as well).

Installing a package does not create a repackaged RPM because there are no files already on the system that need to be repackaged. However, the package installation is recorded in the RPM database, and that is enough information for rpm to roll back the transaction: it just erases the package.

Sorry, there are just too many variables to roll back a rollback! To prevent confusion rpm deletes repackaged files once they have been used for rollback.

rpm 's --test option is very useful for this:

# rpm -Uhv --test --rollback "1 minute ago"

Rollback packages (+1/-0) to Sat Oct 29 22:47:27 2005 (0x4364343f):

Preparing... ########################################### [100%]

Cleaning up repackaged packages:

Removing /var/spool/repackage/abe-1.0-5.i386.rpm:

From the output, you can see that this rollback will result in one package being reinstalled and no packages being removed ( +1/-0 ). The package being reinstalled can be identified from the clean-up line: it's abe .

To proceed with the rollback, execute the command again without the --test option:

# rpm -Uhv --rollback "1 minute ago"

Repackaged files are stored in /var/spool/repackage . The total amount of disk space used is displayed by this command:

# du -sh /var/spool/repackage

15M /var/spool/repackage

If you are certain that you won't need to perform a rollback, you can delete these files to free up some disk space:

# rm -rf /var/spool/repackage

The repackage repository can grow to be fairly large. If you want to store it on another mounted disk, you can configure its directory by adding this line to /etc/rpm/macros :

_repackage_dir /bigdisk/repackage

This will use /bigdisk/repackage for future repackaging.

However, I prefer to use a symbolic link (see Lab 4.3, "Managing Files "), so that when I look in the default location I'll know where the files have been moved:

# mv /var/spool/repackage /bigdisk/repackage

# ln -s /bigdisk/repackage /var/spool/repackage

# ls -la /var/spool/repackage

lrwxrwxrwx 1 root root 18 Oct 31 14:47 /var/spool/repackage -> /bigdisk/repackage

 The manpage for rpm (which covers the --repackage option but not --rollback )

 The Linux Journal article "Transactions and Rollback with RPM": http://www.linuxjournal.com/article/7034

 The manpage for cvs ; see the date format for -D for information on the date/time formats accepted by rpm 's --rollback option

One of the main reasons that packages are updated is to correct newly discovered security vulnerabilities. It's important to keep a system up-to-date so that these security vulnerabilities are eliminated as soon as fixes are made available.

Automating system updates makes this easy. Fedora is configured to perform updates automatically; all you need to do is turn this feature on.