Re: rpm rollback features...

[Jeff Johnson <jbj redhat com>]

On Fri, Jul 12, 2002 at 01:05:22PM -0500, James Olin Oden wrote:
> Hi All,
> 
> I have been looking at RPM's transactional rollback features
> and I what I believe is a basic understanding, but I am 
> fuzzy on some points and would like some guidance.  Also,
> I may be assuming I understand whereas I do not truly, so
> I would like to re-iterate what I think I understand...understand? (-;
> 
> 	- Transactional rollback capabilities are in the 
> 	  RPM 4 series and only really became workable 4.04.

Yup.

> 	- As RPM's are installed or upgraded the image of 
> 	  the header of each rpm is stored away somewhere.


Stored in a directory, configured with the macros (from /usr/lib/rpm/macros)

...
#       The directory in which erased packages will be saved when using
#       the --repackage option.
%_repackage_dir         /var/spool/up2date

#       A path (i.e. URL) prefix that is pre-pended to %{_repackage_dir}.
%_repackage_root        %{nil}
...

FWIW, a ftp:// URL probably works there as well through rpmio.
Disclaimers: Dunno if I can support the functionality, haven't tested,
tried, you're only the 2nd person I've even told :-)

> 	- Also, when RPM's are installed as a group (even a
> 	  a group of one), a TID (transactional ID) is assigned
> 	  to this group of rpm's and the TID is time stamped 
> 	  (I assume in some relational way but the implementation
> 	  is not important).

Yup. By "relational", you probably mean the property of ordering, nod.
Currently the transaction id is just a unix time stamp.

> 	- When doing an upgrade or an erase of an rpm 
> 	  one can use the --repackage switch and all the compents
> 	  of the package as they are currently installed onto the
> 	  system and the saved package header will be stuffed 
> 	  back into a package which will be created in the
> 	  directory defined by %_repackage_dir.

Yup. It's important to realize that modified files will be repackaged
with original MD5 sums, and that missing files will just be skipped.

> 	- Their is a mysterious --rollback switch in the source
> 	  that has something to do with all this (-;

The --rollback switch works like a cvs -D using the ageless getdate.y.
That means that you can do
	rpm --rollback "1 week ago"
and various other syntaxes supported by getdate.y.

FYI none of the transaction rollback facility in rpm is documented because
I don't believe that transactional rollbacks are a desireable or even
useful feature on the rpm command line. The CLI interface is unforgiving,
and transaction rollbacks require absolutely perfect system administration.

OTOH with discipline, and a methodology like Red Hat Network, I suspect
that rollbacks might be useful.

> 
> What I am not sure about (other than the last statement (-;), is 
> what is the prefered method of:
> 
> 	- rolling back one package to a saved previous package.  That
> 	  is you did the upgrade with --repackage, you realized you
> 	  really did not want that upgrade, and now you want to install
> 	  the old package.  What is the "correct" way of doing that?

What's implemented is much like
	cvs update -D "3 months ago"
so the rpm analogue would be
	rpm --rollback "3 months ago"

> 	- You have a group of package that you wish to roll back to
> 	  what is the prefered method of doing this? 

There is no general or clean way to unroll a "group" ATM, because that
may break dependencies. Rolling back all transactions to a point before
the group of packages is the recommended way, but that may be in conflict
with other upgrades.

> 
> Lastly just some questions:
> 
> 	- what are the things to consider when building packages that
> 	  will not hinder a rollback/backout (I have some ideas,
> 	  but I would like to hear others)?

Clarifying ownership of directories is probably the most important
packaging issues. rpm, just like tar/cpio, will create all necessary
leading directories, but, when erasing, will not remove directories
that are not "owned" by a package.

Always installing the entire contents of the payload, and trying to
maintain machines with package(s) rather than editing config files
is likely to be very important as well.

> 	- How does rpm handle the scriptlets in a backout situation?

Each package always contains before/after scriptlets for both install
and erase, so this isn't a problem. The usual scriptlets are run in the
usual places.

> 	- Are there any docs (other than source, but I am trying to 
> 	  parse through them) for these features (also, I know of the
> 	  tiny mention in the man page)?

I'll attach my initial internal request for testing, that's about the
best/only doco I have ATM.

HTH

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC

All --

A little help testing "transaction rollbacks" in rpm-4.0.4-0.29, please,
while y'all are waiting for the anaconda to be cooked.

In a nut shell, transaction rollbacks are gonna be used by RHN
to provide an UNDO button somewhen soon. During an upgrade, --repackge puts
the old bits back into a package in the /var/spool/up2date directory
with a remove transaction id. Newly installed packages are marked with
an identical install transaction id. Finally, --rollback <timestamp>
replays transactions backwards, removing newly installed packages,
and re-installing the old packages, until the timestamp goal is reached.

Kinda simple and cute, huh? Esrever ni adnocana is anaconda in reverse.

Well, considering that
	rpm -Fvh --rollback "20 years ago"
is a *great* way to scrub your disk, we need some help testing,
as there's a zillion packages out there, and transaction rollbacks
are gonna be a bear to test and stabilize. This is a whole new
dimension to package management, and no one -- especially me -- has
a clue.

BTW, the clean disk problem has been addressed by terminating rollbacks
as soon as there are no more removed packages to be re-installed. There
are most certainly other problems, *lots* of them, *expect* --rollback
to break.

I've put a toy test script into /usr/lib/rpm/trpm in rpm-4.0.4-0.29.
I use this script daily for testing rpm install/upgrade into a chroot.
Yes, the script is grotty, WORKSFORME, but feel free to be creative.

Since it's a chroot, you can find a lot of problems w/o a great deal of
effort. I suggest using trpm to test 8.0 in a chroot as well. For example,
once you're set up properly, the following commands will get you an 8.0
chroot with enough packages to attempt a compilation:
	rm -rf 8.0
	./t 8.0 build --initdb -Uvh
	./t 8.0 chroot
In fact a great deal of package testing can be done within a chroot.

In order to use the trpm script, you need to do (hank is our QA
repository of distros past, mount CDROM's if you don't have access to
hank)
	mkdir -p /mnt/dist
	mount hank.test.redhat.com:/mnt/dist /mnt/dist
	for i in 5.2 6.0 6.1 6.2 7.0 7.1 7.2
	do
	    mkdir /$i
	    ln -sf ../mnt/dist/$i/i386/RedHat/RPMS/ /$i/i386
	done
to follow my convention(s). Or hack on trpm to roll your own convention,
'tain't hard.

Basically, /{7.2,7.1,...}/i386 should point to a pile of rpm's from the
corresponding distro RedHat/RPMS directory.

Then, to use trpm for testing --rollback (renamed to t below to accomodate my
fumble fingers), do

	mkdir -p /somewhere		# Make a playpen, you'll need disk space
	cd /somewhere			#

	cp /usr/lib/rpm/trpm t		# local copy for hacking

	./t 7.1 clean			# scrub
	./t 7.1 config manifest		# generate manifests (only needed once)
	./t 7.2 clean			# scrub
	./t 7.2 config manifest		# generate manifests (only needed once)

	ls -al .			# Hmmm, wassup?

	sudo rm -rf ./7.[012]		# wipe out the chroot's

	./t 7.1 $type --initdb -Uvh	# install 7.1 "min0" set

	mv ./7.1 ./7.2			# Prepare for 7.2 upgrade
	sudo rm -f ./7.2/var/lib/rpm/__db*	# XXX just in case

	sudo rm -f /var/spool/up2date/*.rpm	# XXX just in case
	./t 7.2 $type -Fvh --nodeps --repackage # 7.1 -> 7.2 upgrade

	sudo /bin/rpm -Fvv --nomd5 --root `pwd`/7.2 --rollback "1 hour ago"

Candidate install sets in increasing size currently in trpm are
	min0
	min1
	min2
	base
	devel
	build
	all
I use min0, min1, and build mostly. Feel free to augment the install
set globs if you wish. The sets above are known to work hen applied
5.2, 6.0, 6.1, 6.2, 7.0, 7.1, and 7.2 packages (more or less). I haven't
looked at 8.0 yet.

Dink a bit, and you'll figger it out.

Bugs in bugzilla, please, and attach at least the sequence of trpm
commands you ran so that I have a prayer of reproducing the problem.

Thanks for any/all help.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC