#732 Issue `closed`: SUSE Hack Week 13: Use rear as generic installer in the plain SUSE installation system¶

Labels: enhancement, won't fix / can't fix / obsolete

jsmeix opened issue at 2015-12-04 15:16:¶

During SUSE Hack Week 13 I will imlement to use rear
as generic installer in the plain SUSE installation system.

See
https://hackweek.suse.com/13/projects/1190

I think I can add functionality to rear so that it can be used as generic installer without any incompatible changes.

My current plan:

I add a separated new workflow "install" where install-workflow.sh
is derived from recover-workflow.sh as follows:

The stages of the install workflow are the same as the stages of the recover workflow

SourceStage "restore" is replaced with a new SourceStage "install" that installs software packages (RPMs)
after SourceStage "install" there is the additional new SourceStage "configure" that does the very basic configuration that is needed so that the system can boot (i.e. bootloader configuration and bootloader installation) and that 'root' can log in (i.e. set 'root' password and very basic networking setup like starting dhcpd and sshd).
there is no longer the SourceStage "finalize" that installed the boot loader because that already happened in SourceStage "configure"

Basically usr/share/rear/lib/install-workflow.sh is something like

function WORKFLOW_install () {
    SourceStage "setup"
    SourceStage "verify"
    # Set up persistent storage (disk partitioning with filesystems and mount points):
    SourceStage "layout/prepare"
    SourceStage "layout/recreate"
    # Dump the payload into the persistent storage (install files).
    # Usually "dump the payload" means to install software packages:
    SourceStage "install"
    # Basic system configuration so that it can boot
    # (i.e. boot loader configuration and creating etc/fstab)
    # and that 'root' can log in (i.e. initial temporary root password,
    # keyboard layout, basic networking like dhcpd plus sshd running):
    SourceStage "configure"
    # Prepare for reboot:
    SourceStage "wrapup"
}

With the rear framework (in particular with appropriate usr/share/rear/install/default/50_install_software_packages.sh and usr/share/rear/configure/default/50_basic_configuration.sh scripts that implement the stages "install" and "configure") and an appropriate /etc/rear/disklayout.conf in the installation system, running "rear install" in the installation system should install the system from scratch.

I think I do not need to change any existing script in an incompatible way - I even hope I do not need to change any existing script at all - so that I can add the "install" functionality without any possible regression elsewhere.

jsmeix commented at 2015-12-04 15:25:¶

For my very first tentative experiments see
https://github.com/jsmeix/rear/tree/add_install_workflow

(Currently the 50_install_software_packages.sh and 50_basic_configuration.sh scripts are ugly SUSE-specific hacks.)

jsmeix commented at 2015-12-04 15:31:¶

For the fun:
With some (but not too much) additional manual stuff in the installation system I have right now installed my first SLES12 system via "rear install" from within the plain SUSE installation system :-)

Have a nice weekend!

gdha commented at 2015-12-04 16:01:¶

@jsmeix do you have some specific goal in mind like cloud installations and bare metal restore from cloud images? Or, do you see it broader?

jsmeix commented at 2015-12-09 11:37:¶

@gdha

(late reply because I was not in the office until now)

I do not have a specific goal in mind.
I see it as a natural/native/intrinsic/inherent/genuine functionality.

Why I see "install" as natural functionality:

See https://en.opensuse.org/SDB:Disaster_Recovery

Disaster recovery is installation
(reinstalling from scratch)
The core of disaster recovery is an installer
that reinstalls the system from scratch.

I.e. the core functionality of rear is already "installation".

The only real diffeerence between "recovery installation"
and "initial installation" is how the files get onto the system.

For "recovery installation" the files get copied
from a backup onto the system.
For "initial installation" the files get copied
from software packages onto the system.

See https://en.opensuse.org/SDB:Disaster_Recovery

The fundamental steps of system installation are:
1. prepare persistent storage (disk partitioning with filesystems and mount points)
2. dump the payload into the persistent storage (install files)
3. install a boot loader
4. reboot
In case of an initial system installation "dump the payload"
means usually to install RPM software packages.
In case of disaster recovery "dump the payload" means
to restore the files from a backup.
The only real difference between an usual system installation
and disaster recovery is how the payload is dumped.

When rear works as generic installer in the plain SUSE installation system, my next goal is to use rear as generic installer in any reasonably powerful installation system - in particular to use rear as generic installer in the installation systems of other major Linux distributions.

With "reasonably powerful installation system" I mean anything
that provides the usual tools to set up partitioning/filesystems/mountpoints and to get files copied into the system i.e. package install tools and backup restore tools. When the user uses a special backup tool he cannot use a generic installation system. When the user uses a special backup tool he must use a specifically made installation system like the current rear recovery system or the user must specifically enhance a generic installation system (e.g. the SUSE installation system can be enhanced with any additional software via "dud", see https://en.opensuse.org/SDB:Linuxrc).

Another future goal is to create a generic "static/fixed" rear installation system and run the generic rear installer therein.

Currently the rear recovery system is specific for the system that should be recovered.

This means for thousands of servers in business/enterprise environments the user/admin has to deal with thousands of rear recovery systems where each one is specific for one particular server.

With a generic "static/fixed" rear installation system the user has only one rear installation system for all his servers and runs one "static/fixed" generic rear installer therein.

The user has only system-specific config files that define how to install and recover a system. With "config files" I mean in this context only what is needed to specify how to install or reinstall a system (i.e. disklayout.conf et alii). I do not mean the zillions of config files /etc/* in an installed system.

To recover a system the user has mainly
the disklayout.conf (how to do partitioning,filesystems,mountpoints)
plus /etc/rear/local.conf (how to restore the backup).

For special cases the user may need additional config files like
kernel_modules.conf and network_setup.conf to get his
particular installation/recovery system set up as he needs
(e.g. by default network set up may happen via DHCP).

To install a system the user needs some more config files:
First and foremost disklayout.conf and /etc/rear/local.conf
but additionally also some kind of
files_install.conf (how to get files onto the system) and
bootloader.conf (how to set up the bootloader) and
basic_setup.conf (e.g. root password, networking, ...).

In the very end my final goal is to get separated parts separated
so that each part can be used on its own:

A generic installation/recovery system.
A generic installer that uses config files
(this is what this issue is about).
A generic system analyzer that writes config files
(i.e. partially what "rear mkrescue" does
and partially what "rear savelayout" does).
A tool to create a specific installation/recovery system
maily needed to add special backup/restore tools
(i.e. partially what "rear mkrescue" does).
A user dialog tool (text-based) to create config files
(optional new tool - config files should be human editable).

To install a system from scratch the user
boots the generic installation/recovery system and
runs the generic user dialog that creates the initial config files
or provides manually created config files.
Then (within the generic installation/recovery system) the user
runs the generic installer that installs the system.
Finally the user reboots.

To prepare recovery the user runs in the running system
the generic system analyzer that writes config files.
Additionally the user creates a backup of his files
(i.e. what "rear mkbackuponly" does).
The user does this any time when he needs updated
config files or an updated backup.
When the user uses special backup software he must also
run the tool that creates a specific installation/recovery system
that has his special backup/restore software included
(i.e. what "rear mkrescue" does).

To recover the system on new hardware the user
boots the generic installation/recovery system
or his specific installation/recovery system and
runs the generic installer with his latest config files
that recreates his system on the new hardware.
Finally the user reboots.

jsmeix commented at 2015-12-09 16:13:¶

FYI:
I have a first usable implementation of the "install" workflow.
It is still a SUSE-specific proof-of-concept hack.
It is not at all generic.
But it works (for me)!
See
https://github.com/jsmeix/rear/tree/add_install_workflow

gdha commented at 2015-12-09 16:25:¶

I think your install script is not located in the right directory default
-> SUSE_LINUX/i386/ as it uses zypper (and it seems rather hard-coded).
But, I understand it is a proof-of-concept so I forgive you ;-)
Gratien

On Wed, Dec 9, 2015 at 5:13 PM, Johannes Meixner notifications@github.com
wrote:

FYI:
I have a first usable implementation of the "install" workflow.
It is still a SUSE-specific proof-of-concept hack.
It is not at all generic.
But it works (for me)!
See
https://github.com/jsmeix/rear/tree/add_install_workflow

—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/732#issuecomment-163309845.

jsmeix commented at 2015-12-10 07:59:¶

I know that both my scripts are currently plain wrong in "default"
and in particular the basic_configuration script needs to be split
into its separated parts and much more things like that.

As long as I did not make a pull request I consider all my stuff as
totally tentative and experimental.

My next steps will be to implement the current SUSE-specific install
workflow properly so that I think it could be accepted by upstream
as a SUSE-specific first step enhancement towards a generic
install workflow and then I will make a pull request.

Note that my current install workflow does not change any existing
file in rear which means it cannot cause regressions.

jsmeix commented at 2015-12-10 16:41:¶

Now https://github.com/jsmeix/rear/tree/add_install_workflow
works reasonably well for me and
I have splitted SUSE-specific stuff into
install/payload/SUSE_LINUX/

But it is still not ready for a pull request because there is
too much hardcoded stuff in the SUSE-specific scripts.

Note that meanwhile I had to change an existing script:
wrapup/default/99_copy_logfile.sh
because before it only worked for the "recover" workflow
but now I also use it for the "install" workflow (but my change
is fully backward compatible).

Furthermore I enhanced the Source function a bit.
Not it tries using $SHARE_DIR/$source_file as fallback
if $source_file does not exist so that no longer the full path
is required to include a file in $SHARE_DIR. I think I will
make a totally separated pull request for this enhancement.

Tomorrow I would like to document my current state.
In particular I would like to describe how to setup using
rear as installer in the SUSE installation system because
that requires a few "magic tricks" (nothing complicated
but one must know how to do it so that it works o.k.l).

jsmeix commented at 2015-12-11 16:05:¶

I postpone to document it until it is basically usable
by someone else (except me).

Today I cleaned it up so that no longer hardcoded stuff is used
except install/configure/SUSE_LINUX/20_fstab.sh that I need
to make as generic fstab creator that creates fstab based on
what is mounted under /mnt/local.

All other hardcoded hacks are removed now and the data
needs now to be provided in variables in /etc/rear/local.conf
as described in https://github.com/rear/rear/commit/b8f5e5eaa67604dd6ccdbcabe8e685617377a013

I have now created a new branch
https://github.com/jsmeix/rear/tree/first_working_install_workflow
to get rid of the various confusing trial-and-error commits in
my old https://github.com/jsmeix/rear/tree/add_install_workflow
but I keep that old branch for now as a reference.

I.e. the current up-to-date branch for the install workflow is
https://github.com/jsmeix/rear/tree/first_working_install_workflow

But ist is still not ready for a pull request - mainly
because a generic fstab creator is mandatory
before someone (except me) should try it out.

Unfortunately next week I have to do other work
and then there is Christmas vacation so that
probably I can continue not until next year.

@gdha
I would appreciate it if you could have a look
what you think about my current code in general in
https://github.com/jsmeix/rear/tree/first_working_install_workflow

I mean if the general way how I implemented it is o.k.
or if there is perhaps something "broken by design".

jsmeix commented at 2016-02-05 10:25:¶

To document the current state (i.e. what I presented on FOSDEM)
I added the new section

Using rear as generic installer in any installation system

to https://en.opensuse.org/SDB:Disaster_Recovery

didacog commented at 2016-02-05 10:58:¶

Hi! this is what we talked at FOSDEM true? We will take a look!

jsmeix commented at 2016-02-05 11:13:¶

@didacog
I assume you need help to get it working in its current experimental proof-of-concept and work-in-progress state.

Just ask me if you need help.

To get prepared I suggest that you experiment with "generic system installation with the plain SUSE installation system" and "generic working with the plain SUSE installation system".

You must know how to enhance the SUSE installation system to add zypper and rear and rear config files into the SUSE installation system to be able to run "rear install" from inside the SUSE installation system.
How to do that for "rear install" is not yet descibed at https://en.opensuse.org/SDB:Disaster_Recovery but without a description it is probably hard.

What I use for my experiments are KVM/Qemu virtual machines with a single 20 GB virtual harddisk that appears as /dev/sda and BIOS (do not use UEFI). To make the harddisk appear as /dev/sda you must use full hardware virtualization (except the CPU) which I always do to get virtual machines that "look same" as real hardware (if you use some kind of paravirtualization the harddisk appears as /dev/vd0 or similar). I use "virt-manager" to set up virtual machines and to get full hardware virtualization I select in virt-manager for the operating system type to be "generic".

jsmeix commented at 2016-02-05 12:26:¶

Right now I added "A sketchy description how to use rear as generic installer in the plain SUSE installation system for people who are experienced in generic system installation with the plain SUSE installation system" at https://en.opensuse.org/SDB:Disaster_Recovery

didacog commented at 2016-02-05 12:35:¶

@jsmeix

Yes, first we'll do some testing with your current approach in order to determine how to provide required services, configs,... from DRLM.

I will ask you for help if any doubts!

I have few to-do's for current DRLM roadmap, but when finished or in my free time i will take a look for sure.

Thx!

didacog commented at 2016-07-05 09:25:¶

@jsmeix as I've finished my heavy work on DRLM 2.0. I will start working with your rear installer proposal.

If you can refresh me some concepts, I will start thinking about how to implement it on DRLM.

jsmeix commented at 2016-07-07 13:25:¶

@didacog
I documented my experimental proof-of-concept
and work-in-progress state in the section
"Using rear as generic installer in any installation system"
in
https://en.opensuse.org/SDB:Disaster_Recovery

I did not work on it since that time.

Tomorrow I am not in the office so that further
questions need to wait until next week...

didacog commented at 2016-07-07 13:28:¶

@jsmeix cool! I can wait until next week without problem ;)

jsmeix commented at 2016-07-07 13:33:¶

@didacog
uncool ;-)
I had expected that you play around with it until next week
so that you can ask me some cool questions :-)

FYI:

A related enhancement issue is https://github.com/rear/rear/issues/841

With rear recovery system update support it should be much
easier (hopefully) to download the rear config files into
the rear recovery/installation system during "rear install".

didacog commented at 2016-07-08 11:01:¶

@jsmeix I told you next week because this weekend is my weeding... I will not be able to take a look until next week. ;-)

gdha commented at 2016-07-08 11:23:¶

@didacog Congrats!

jsmeix commented at 2016-07-11 07:34:¶

@didacog
if "weeding" is a typo and you meant "wedding":
Congratulations on your wedding!

didacog commented at 2016-07-11 07:38:¶

@gdha @jsmeix thanks!! ;)

didacog commented at 2016-07-20 09:11:¶

@jsmeix

I've been reading your approach for rear install, and the hardest part for implement it on DRLM should be the provided "rescue/install" images.

On one hand the stuff like disklayout and config files should be quite easy to implement with DRLM to get them through our RESTful API.

On the other hand will be some work on, at least, providing rear install procedures for the major linux distros, now is just for SuSE (i know is just an initial approach).

Did you think about how to provide the install-rescue images with rear included? In your documentation is required to make a rescue from a fresh install image, but this may not work on some "special" installations like BOOT from SAN,... that need some modules included in the initrd image.
IMHO I think that should be as easy as installing with actual procedures with no requirements on previous steps to provide the installation images. I need to work on your approach a little bit more but seems promising! ;)

jsmeix commented at 2016-07-20 14:57:¶

@didacog
I do not fully understand what exactly you mean with installation image.

Do you mean an installation image based on the rear recovery system
or do you mean an installation image based on a Linux distributors
installation system?

In case of an installation image based on the rear recovery system
most of what is needed is already there in rear.

Basically all what is missing is to add an RPM package installation tool
to the rear recovery system.
I did this for SUSE by adding the "zypper" RPM package installation
and dependency solver tool to the rear recovery system, see in
particular the step 4. in the section "Using rear as generic installer
in the plain SUSE installation system" at
https://en.opensuse.org/SDB:Disaster_Recovery
the REQUIRED_PROGS and COPY_AS_IS values.

For Red Hat and one Debian and Ubuntu would have to add their
preferred RPM or deb package installation and dependency solver
tool to the rear recovery system in the same way.

If additional kernel modules are needed one would have to
specify them via "MODULES_LOAD".

didacog commented at 2016-07-21 07:41:¶

@jsmeix

I was talking about installation image, yes I've seen that on your approach is required to create a base image from rear recovery system and I just try to figure out if could be possible to skip this initial installation and rear recovery image creation. Maybe not, I just was thinking aloud :-P

Let me investigate a little bit more, so far I've just been reading your docs and thought on them, I want to talk with my mates at DRLM and come back with real objectives.

jsmeix commented at 2016-07-21 08:19:¶

I think to get a rear installation image for "Foo Linux 1.2.3"
you must have a running "Foo Linux 1.2.3" system
wherefrom something like "rear mkrescue"
(or perhaps a future "rear mkinstsys") can copy
what it needs to make an installation image that contains
the right tools in the right versions (plus right patches)
to install a "Foo Linux 1.2.3" system in the right way.

With https://github.com/rear/rear/issues/841(rear
it should in the end be possible to have one single static
full-featured rear installation image for "Foo Linux 1.2.3"
to be able to install any "Foo Linux 1.2.3" system.

This way admins who maintain hundreds of
"Foo Linux 1.2.3" systems have one single static
rear installation image for "Foo Linux 1.2.3" plus
hundreds of rear configurations (one for each system).

Note that because Linux distributors seem to love
to modify basic installation tools (like parted and so on)
as they need it for their particular version of their distribution,
one cannot have one single static full-featured rear installation
image for several Linux distributions.

E.g. parted behaves different for different SLE versions,
even for different service packs.
In particular SLE12-SP1 parted and SLE12-SP2 parted behave
different. The latter does no longer support the SUSE-specific
'gpt_snc_mbr' hack (hooray that this hack is finally gone!).

But what could be possible is one single generic
rear installation image for several Linux distributions
that can do only traditional generic installations
without any newest/fancy Linux distribution specific stuff.

Perhaps admins who maintain hundreds of systems
of different Linux distributions may be interested in
simplifying that mess when they can reduce the diversity
to simple traditional generic installations that work with
one single generic rear installation image plus
hundreds of rear configurations (one for each system).

Alternatively you can use the original "Foo Linux 1.2.3"
installation medium and add the rear installer to it
to achieve an installation system that contains
the right tools in the right versions (plus right patches)
to install a "Foo Linux 1.2.3" system.
Now one does no longer use the original "Foo Linux 1.2.3"
installer but the generic rear installer.
This is what I did with the SUSE "inst-sys" by using the
SUSE-specific method "dud" to add the rear installer to
the SUSE "inst-sys".
For Red Hat one would use a Red Hat specific method to
add the rear installer to the Red Hat installation system.

All that is not yet poperly implemented.
What I currently implemented are quick and dirty hacks
where the only purpose is to find out if it seems doable.

didacog commented at 2016-07-21 08:44:¶

@jsmeix
I'm agree with you, as I said, I just was thinking aloud. The problem is the same on each Linux Distro with differents tools and software versions.

Let me talk with my mates @proura and @krbu. We need to think well how to provide this stuff, from DRLM, in the easiest possible way.

This week we are on the final testings prior to publish DRLM 2.0 and I don't want to mix issues.

Hope you can give me little bit more time ;-)

jsmeix commented at 2016-07-21 08:50:¶

Of course no need to hurry!

Also for me it has low priority (basically only for HackWeeks).

jsmeix commented at 2016-11-25 09:48:¶

I think I have meanwhile a better plan, see
https://github.com/rear/rear/issues/1085
which emerged as successor of this issue here
and is intended to replace it which is the reason
why I close this issue here (at least for now)
because I think with a BACKUP=ZYPPER method
I can provide the same functionality i.e.
"install a system from scratch" but BACKUP=ZYPPER
integrates much nicer into the existing ReaR framework
i.e. I can get the intended functionality with less effort.

[Export of Github issue for rear/rear.]

#732 Issue closed: SUSE Hack Week 13: Use rear as generic installer in the plain SUSE installation system¶

jsmeix opened issue at 2015-12-04 15:16:¶

jsmeix commented at 2015-12-04 15:25:¶

jsmeix commented at 2015-12-04 15:31:¶

gdha commented at 2015-12-04 16:01:¶

jsmeix commented at 2015-12-09 11:37:¶

jsmeix commented at 2015-12-09 16:13:¶

gdha commented at 2015-12-09 16:25:¶

jsmeix commented at 2015-12-10 07:59:¶

jsmeix commented at 2015-12-10 16:41:¶

jsmeix commented at 2015-12-11 16:05:¶

jsmeix commented at 2016-02-05 10:25:¶

didacog commented at 2016-02-05 10:58:¶

jsmeix commented at 2016-02-05 11:13:¶

jsmeix commented at 2016-02-05 12:26:¶

didacog commented at 2016-02-05 12:35:¶

didacog commented at 2016-07-05 09:25:¶

jsmeix commented at 2016-07-07 13:25:¶

didacog commented at 2016-07-07 13:28:¶

jsmeix commented at 2016-07-07 13:33:¶

didacog commented at 2016-07-08 11:01:¶

gdha commented at 2016-07-08 11:23:¶

jsmeix commented at 2016-07-11 07:34:¶

didacog commented at 2016-07-11 07:38:¶

didacog commented at 2016-07-20 09:11:¶

jsmeix commented at 2016-07-20 14:57:¶

didacog commented at 2016-07-21 07:41:¶

jsmeix commented at 2016-07-21 08:19:¶

didacog commented at 2016-07-21 08:44:¶

jsmeix commented at 2016-07-21 08:50:¶

jsmeix commented at 2016-11-25 09:48:¶

#732 Issue `closed`: SUSE Hack Week 13: Use rear as generic installer in the plain SUSE installation system¶