[opensuse-factory] ANNOUNCE: transactional updates for Tumbleweed From : Thorsten Kukuk <kukuk@xxxxxxx>

: Thorsten Kukuk <kukuk@xxxxxxx> Date : Sat, 21 Jan 2017 14:46:19 +0100

: Sat, 21 Jan 2017 14:46:19 +0100 Message-id : <20170121134619.GA9756@suse.de>



Hello,



I would like to announce a new package in Tumbleweed: "transactional-update".



What is this, and why is this from interest for you?



Tumbleweed is a rolling release distribution. Which means, even

intrusive changes will be applied to a running system, which is

in use by the user.

For a lot of updates this is no problem, but sometimes there are

updates, which make trouble. Only remember the email from

Martin Wilk from Jan 16th, 2017: "CAREFUL: New Tumbleweed snapshot 20170112

released!". Or think about the pam-config update last year.



For another project I wrote a script updating a distribution in a

transactional way. I was asked by many people if I couldn't provide

that for Tumbleweed, too. So, here it is.



What are transactional updates?



A transactioan update:



- is atomic

- The update does not influence your running system.

- It's either successful applied or nothing is changed. So no broken

RPMs are flying around in the system.

- can be rolled back

- if the upgrade fails or if the update is not compatible, you can

quickly restore the situation as it was before the upgrade.





What do you need to be able to use it?

- A recent installation of Tumbleweed (updating from older versions,

especially installations made with openSUSE 13.x, will not work)

with btrfs and snapshots enabled. If your installation is not

recent enough, the script will tell and warn you and refuse to work.



How does it work?



In short, we create a snapshot of the system, update this snapshot,

do a "rollback" (or better "somersault") to this new snapshot and with

the next reboot, the updates are there. And if they don't work, boot

the old snapshot and continue to work, until the problem is fixed with

another update.



So, everything is fine?

No, it is not. The original project did work with a read-only root

filesystem. Which means, after taking the snapshot, the original data

couldn't be modified and no data could go lost. With Tumbleweed, all

changes you are doing to the root filesystem subvolume after starting

the script will be lost with the next reboot into the new snapshot.

Which means, after running the script, you should immeaditly reboot

to activate the changes and avoid data lossage.

Modifications in other subvolumes are fine.



Another problem is: we are using snapshots and rollback, so face the

same issues as with snapshots and rollback.

I have run this script now for three month on a default Tumbleweed

installation by cron without any problems. But there are RPMs, which

will create problems, and which needs to be adjusted.

1. strictly seperate code from user data. /srv is a real nightmare.

Either user data will go lost, or the application will not be

updated or rolled back.

2. Don't modify data in post install sections, but during boot or

first start instead. If the data is in a subvolume, this one will

not be accessible during the upgrade. Or the update wouldn't be

atomic anymore.

3. Don't create something outside the snapshot subvolume, this

will not survive the next reboot.

4. RPM, which installs directories or data into directories, which

are subvolumes, needs to be adjusted. This will not work.

Example: /var/cache is an own subvolume. Quite some RPMs

create directories and data there, and some of them will stop

working if you remove this directories.

That's bad even without transactional updates, a system

administrator should always be allowed to delete the cache.

A better way is to create the directories during boot with

tmpfiles.d(5).

Same problem for all other subvolumes like /var/log, /var/spool,

etc.



So, now you can test the script and I hope it is from use for many

of you. I'm pretty sure there are still situations which the script

cannot handle, and a lot of you have ideas about how to improve it.

I'm happy about every patch or idea. And of course adjusted RPMs,

which have no problem with this update method.



Thorsten



--

Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP

SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany

GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

--

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx

To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx



