[rear-devel] RFC: what should I do with my ideas for "rear 2.0"?

Johannes Meixner jsmeix at suse.de
Thu Oct 29 17:38:45 CET 2015


Hello,

On Oct 29 16:22 Schlomo Schapiro wrote (excerpt):
> I tried skimming over the SDB article... Quite impressive!

I really suggest to actually do
"Generic system installation with the plain SUSE installation system"
at least once to get that experience yourself.

Privately I use already several such selfmade installer scripts
e.g. one for SLE12 on UEFI, one for SLE12-SP1 default, one for
SLE12-SP1 with plain GPT and Grub2 in MBR on a >2TB virtual disk
(instead of our SUSE-specific 'gpt_sync_mbr' hack) - basically
"everything is possible" and does "just work" (at least for me ;-)

If you need such an installer script e.g. for openSUSE 13.2
(or for the upcoming openSUSE Leap) I can make one for you
so that you could have that breathtaking experience yourself.

Perhaps you can set up a virtual machine on Debian/Ubuntu
only for a test or demonstration with openSUSE
to actually see yourself what I mean?

Note that this is not in principle resticted to SUSE.

It is only that I did not investigate if and to what extent
selfmade installer scripts also work with the original
intallation media of other Linux distributions.


> Do you mean something like this (I use Debian/Ubuntu instead of SUSE)?
>
> * Boot computer from ReaR rescue media

No.
I mean boot from the original Debian/Ubuntu medium
but "do the right things for Debian/Ubuntu" so that
it does not run the Debian/Ubuntu installer but
instead a selfmade installer script.

If there was a generic rear installation system
(you may call that a generic "ReaR rescue media"),
then you could also boot that and run a generic installer.


> * configure hard disks / partitions / filesystems
> * run "debootstrap wily /mnt/local ..."

I do not know what "debootstrap wily /mnt/local ..." means.

> * install boot loader
> * reboot & done
>
> (Yes, I am suffering from the super slow Ubuntu installation
> process and the general lack of good documentation for preseed).

Then you should try to find out how to circumvent the Debian/Ubuntu
installer - i.e. how to boot the original Debian/Ubuntu installation
medium but run your own installer script.

The first step is to find out how to boot the original Debian/Ubuntu
installation medium and let it start only a plain bash.

Perhaps alternatively Debian/Ubuntu provides a rescue system
that can be booted where ony a plain bash runs.

If this is possible you should try to find out if
the Debian/Ubuntu rescue system is sufficiently equipped
with the basic tools to install a system which are usually
- parted
- mkfs*
- the Debian/Ubuntu tool to install Debian/Ubuntu software packages
- bootloader

Then you you should try to do an installation of a small basic
system completely manually oly with bash command line calls.

If you can install this way a Debian/Ubuntu system
those bash command line calls are your own installer script.

The final step is to find out how to launch your script
automatically when booting from an original Debian/Ubuntu
medium.


> I think that such an approach would work only for people who have 100%
> automation for their system setup & configuration. For others the
> traditional approach probably works better.

Not necessarily.

But I agree that I have in particular business environments
with many servers in mind where full automated deployment
is ofter a must. In such an environment I think it could
be of interest to use one same installer (the rear installer)
both for deployment and for disaster recovery.

For full automated installation the admin would create
a complete installation config file that is read
by the generic rear installer so that it can do
a full automated installation.

When needed items in that config file are missing,
the generic rear installer would stop and ask the
admin for input - preferably with a proposal for a
reasonabble default (e.g. if no swap specified,
propose to use the size of the main memory but
at most 10G as swap) and with a reasonabble timeout
when it automatically proceeds with the default.

When that config file is empty, the generic rear
installer would ask for all needed items (also preferably
with a reasonabble default/falback behaviour).


> In general, I am not sure how to solve the chicken-egg problem
> if you want to do all installation by restoring a full backup.

I do not want to do the "payload dump" during an initial
installation by restoring a backup - because there cannot
be a backup in case of an initial installation.

When rear can also be used as generic installer
an additional "payload dump" method must be implemented
that supports to install the usual software packages
(e.g. from the original Debian/Ubuntu medium) by calling
the native tool of the particular Linux distribution
to install their software packages.

Regarding what I mean with "payload dump" see
"Disaster recovery is installation" at
https://en.opensuse.org/SDB:Disaster_Recovery

> How would you setup a new system? How would you imagine
> to replace the traditional process of
> "source -> binary package -> installation media -> boot computer ->
> install"?

See how I have done it already for SUSE at
"Generic system installation with the plain SUSE installation system"
in https://en.opensuse.org/SDB:Disaster_Recovery


> BTW, if you need to add stuff to ReaR to make your vision happen: Please go
> ahead! We always value your contributions and I think that ReaR on SUSE
> would not be as good as it is without your work.

Many thanks for your kind plaudit.

But this case "transform rear into a generic installer"
is not about only adding stuff.

I think such a transformation could result
major backward incompatible changes.

As far as I can imagine right now,
"rear mkbackup" and "rear recover" could keep their semantics
but when rear is transformed into a generic installer
the actual code would have to be changed very much
and those changes will cause regressions at least
in this or that special case.

This is the reason why I am talking about "rear 2.0".

On the other hand with a major version number change
a lot of other wanted stuff can be implemented
(e.g. using "set -e -o pipefail" everywhere)
i.e. everything where we fear regressions.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)



More information about the rear-devel mailing list