On Jul 10, 2010, at 6:58 PM, Ludovic Courtès wrote:
>
>> The killer design issue is scripting with --rollback. Its extremely
>> hard to permit general scripting side-effects whose effects can ALWAYS
>> be reversed by --rollback.
>
> You’ve already partly answered. :-)
>
> Are you saying that RPM-based distros already allow ‘--rollback’? Or
> that the RPM package manager has a ‘--rollback’ option that happens to
> work *if* packages are side-effect-free, etc.? Are upgrades atomic?
>
What RPM-based distros do has no single answer.
RPM has had *THREE* implementations of --rollback now, each based
on experience with the previous version.
Its --rollback v2 that is sending SMS in Brazil. The major change there was
to add doubly linked upgrade chains. Each upgraded package includes
backward links to the package(s) that it erased, each erased package
(re-rolled into a *.rpm with the content that was present at time of erasure)
includes forward links to the package(s) that caused erasure.
With a doubly linked upgrade chain, and sets of packages marked with a
transaction ID,
all the necessary elements to move forwards <-> backwards through time are
present.
Yes scripts have general; side effects that can do anything, including
rm -rf /
that cannot be predicted or rolled back or anything else. But the mechanism
is known to work with some quite modest and reasonable restrictions on
scriptlets (like no typoes, duh!).
The latest version (presented briefly @FOSDEM 2010, you really
can't say much in 45 minutes about --rollback) is
Transactionally Protected Package Management
aka TPPM or "RPM ACID". In a nut-shell, the side effects of
package management are broken into 2 categories
1) databased ACID (yes the traditional technical term, fully
implemented, level 2 isolation)
2) syscall ACID (i.e the set of operations to install package payloads
on file systems like write(2) and mkdir(2) etc. Prototyped using the
abstract log mechanism within Berkeley DB extended in simple ways so
that, say, rmdir(2) reverses mkdir(2). Content goes into the log
before it goes onto the file system which is a bit bloaty but
eaxctly what is entailed with --rollback insturmentation).
3) scriptlet ACID this is the piece that Mancoosi WP3 is focussed
on, modeling and simulating common debhelper-like scriptlet operations
for transactional logging. Also presented @FOSDEM 2010 and actively
being
worked on).
But sure --rollback is entirely a fiction if, say, you attack the physical media
on which the transactional store resides. Kinda hard to run a --rollback
mechanism
from a dead hard drive imho, but whatever ...
... and the answer to attacks on physical media where the transactional log
resides will be to tie the mess into a Cassandra distributed store. Which lurks
1 or 2 slots down on my RPM todo++ list, I've gotten side tracked into crypto
land since May (keys.rpm5.org SKS keyserver and more) and am just starting
to get back to TPPM development.
But the killer design flaw for --rollback is _STILL_ general scriptlet
side-effects,
which are highly non-trivial to reliably invert generally. But the class of
debhelper-like scripts (~55 scripts, avg length ~3 lines, see Joey Hess's
measurements, this is just what I recall) can be modeled/simulated and made
reliable
using a DSL as in Mancoosi WP3.
hth
73 de Jeff
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
