#2086 Issue closed: Support also appropriate_dir/diskrestore.sh (similar as CONFIG_DIR/disklayout.conf)¶
Labels: enhancement, no-issue-activity
jsmeix opened issue at 2019-03-15 15:21:¶
Currently layout/prepare/default/010_prepare_files.sh
supports CONFIG_DIR/disklayout.conf
I suggest that also appropriate_dir/diskrestore.sh
should be supported in basically the same way.
Reason:
I would like to be able to provide a prepared
appropriate_dir/diskrestore.sh
script that can get used as is for "rear recover"
or such a script can be manually adapted as needed which means
when appropriate_dir/diskrestore.sh exists during "rear recover"
MIGRATION_MODE is set to 'true' so that the user gets the
matching dialog where he can adapt it (i.e. same behaviour
as currently when CONFIG_DIR/disklayout.conf exists).
Why I like to provide a prepared appropriate_dir/diskrestore.sh?
I like to be able to use ReaR to quickly set up an arbitrary disk
layout
via plain commands that I enter into my selfmade diskrestore.sh
script,
provide that as appropriate_dir/diskrestore.sh and get that disk layout
directly
via "rear recover" without any indirection via disklayout.conf.
Basically that means it must be possible to do "rear recover"
only with a diskrestore.sh and without any content in disklayout.conf.
I need to find out if that is possible with reasonable effort with current ReaR.
I fear there could be subtle dependencies on the contents in
disklayout.conf
in various scripts in ReaR that run during "rear recover" so that it is
not
possible in practice (with reasonable effort) to do "rear recover"
without
the content in disklayout.conf.
For example currently 'LAYOUT_FILE' is used in the finalize scripts
that install the bootloader:
finalize/Linux-ppc64/540_check_lilo_path.sh
finalize/Linux-ppc64/540_check_yaboot_path.sh
finalize/Linux-ppc64le/680_install_PPC_bootlist.sh
finalize/Linux-ppc64le/660_install_grub2.sh
finalize/GNU/Linux/240_reassign_luks_keyfiles.sh
finalize/Linux-i386/630_install_grub.sh
finalize/Linux-i386/640_install_lilo.sh
finalize/Linux-i386/650_install_elilo.sh
finalize/Linux-i386/660_install_grub2.sh
so some adaptions will be needed there
but at least what I see on first glance in
finalize/Linux-i386/660_install_grub2.sh
at laset GRUB2 installation should work without disklayout.conf
when GRUB2_INSTALL_DEVICES is specified...
gdha commented at 2019-03-15 15:38:¶
@jsmeix I would move the script to $CONFIG_DIR/scripts sub-directory to distinguish clearly between config files and scripts (albeit that everything is a script within rear)
jsmeix commented at 2019-03-18 08:11:¶
@gdha
it is perfectly fine with me to have "real scripts" in a sub-directory
to distinguish them from "config scripts".
But I would like to understand what your reason behind is
why you like to keep them separated.
I mean what would be actually wrong or bad in this case when
different kind of files are in one same directory?
gdha commented at 2019-03-19 16:00:¶
@jsmeix basically that is already possible via
http://www.it3.be/2016/06/08/rear-diskrestore/
Well to be honest I do not like to see any *.sh in the /etc/rear/
directory as it is forbidden by RPM building rules.
jsmeix commented at 2019-03-20 10:21:¶
@jsmeix
thank you for the explanation why we cannot have executables in /etc
so I will find and use another directory.
Perhaps I could simply use the var/lib/rear/layout/ directory
and if therein is already a diskrestore.sh during "rear recover"
then (to be on the safe side) go into MIGRATION_MODE and
show a user dialog where the user must decide to
either use the existing var/lib/rear/layout/diskrestore.sh as is
or let it be recreated anew by the layout/prepare stage.
In the past (when you had mentioned it somewhere) I had already a look
at
http://www.it3.be/2016/06/08/rear-diskrestore/
but as far as I understand the description that one is about
to create diskrestore.sh from disklayout.conf
i.e. basically "rear recover" but aborted just before
layout/recreate/default/200_run_layout_code.sh is run
or in other words only run the layout/prepare stage.
But this issue here is about to be able to manually make a
diskrestore.sh
and use that during "rear recover" (without any disklayout.conf).
jsmeix commented at 2019-03-29 08:25:¶
I like to have that in ReaR 2.6 because I do need it
for efficient testing ReaR with arbitrary disk layouts, cf.
https://github.com/rear/rear/issues/2023#issuecomment-456866405
It is just such a boring annoyance for me to install
a test system with a special disk layout setup
with indirectly working tools like YaST
when on the other hand I know that with ReaR
one could do that directly and much faster and 100% reproducible
if one could provide a ready-made diskrestore.sh to "rear recover"
that creates the disk layout directly without any indirection.
The basic idea behind is exactly the same as in the sections
"Generic usage of the plain SUSE installation system for backup and
recovery" and
"Generic system installation with the plain SUSE installation system"
and
"Using ReaR as generic installer in the ReaR recovery system" in
https://en.opensuse.org/SDB:Disaster_Recovery
that reads (excerpts)
An experienced admin makes a script that calls
his specifically appropriate low-level commands directly.
...
this is working in compliance with the KISS principle
"keep it simple and straightforward" ...
and it avoids what is best described in RFC1925 ... as
"It is always possible to add another level of indirection"
because the primary intent ... is simplicity and control
github-actions commented at 2020-06-30 01:33:¶
Stale issue message
[Export of Github issue for rear/rear.]