Skip to content

Implement rear recovery system update support (my next SUSE hackweek project) #841

@jsmeix

Description

@jsmeix

I like to implement a "rear update" workflow
that is initially intended for the following use-case:

In the rear recovery system one can run "rear update"
which can download and install a tar.gz archive
that gets installed into the running rear recovery system.

This way a rear recovery system can be updated
if needed during run-time without the need to
create a new recovery system ISO image
on the original system via "rear mkrescue".

The basic idea behind is to implement the same
kind of functionality as the so called "dud" provides
for SUSE installation systems, cf. "DUD" and "dud" at
https://en.opensuse.org/SDB:Linuxrc

In particular my use-case will be to update the
rear configuration files in a running rear recovery system.

This way I can use one same fixed rear recovery system
for various sufficiently similar systems (i.e. systems
where the same rear recovery system works but
the only differences are in the rear configuration files).

This should in particular mitigate the problem that
UEFI bootable ISO images are much bigger than
traditional BIOS bootable ISO images, cf.
#810 (comment)

An UEFI bootable ISO image is much bigger (almost 450MiB)
than a traditional BIOS bootable ISO image which is less than
120 MiB for me.

Assume one has 100 servers with identical hardware of type A
and 200 servers with identical hardware of type B, then
(I hope) it is possible to have only one bootable ISO image
for all type A servers and one for all type B servers.

For recovery of a type A server one boots the type A
ISO image on type A replacement hardware and
runs in the rear recovery system first and foremost
something like

rear update server_ID

which downloads a tar.gz archive that matches server_ID
(e.g. from a fixed predefined HTTP or NFS server
that is stored in the currently used local.conf file)
or explicitly something like

rear update http://my_internal_server/server_ID.tar.gz

that contains the rear configuration files that belong
to server_ID.

Afterwards one runs as usual

rear recover

to recover exactly that server_ID machine.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions