rename GRUB_RESCUE to DEVEL_GRUB_RESCUE

[jsmeix]

rename GRUB_RESCUE to DEVEL_GRUB_RESCUE
to make it transparent that this is a development
and testing feature and not meant for production.

For background information see
#935

[jsmeix]

I am thinking about an even more explanatory name
to make it obvious that this is not about something
in the recovery system but a modification of GRUB
in the currently running system.

Unfortunately this week I must leave early into the weekend ;-)
but next week I will work on it...

[gdha]

@jsmeix @schlomo why not having a poll to drop or keep the GRUB_RESCUE thingy? I never used it myself (not since it is off by default)

[jsmeix]

Regarding "poll to drop or keep the GRUB_RESCUE":

Good idea to ask if GRUB_RESCUE is actually needed
by the users.

I do not menn if it is "nice to have", I mean if GRUB_RESCUE
is really needed by the users that justifies effort to maintain it.
After all GRUB_RESCUE is not an intrinsic functionality of rear
as far as I understand #913 (comment)

Regarding "renaming GRUB_RESCUE":

Initially I thought renaming GRUB_RESCUE could be
an exceptional case of #920 (comment)
but meanwhile I think renaming GRUB_RESCUE is
not a good thing (in particular because the name
GRUB_RESCUE is not plain wrong).

I think it is sufficient when I only make the documentation
about GRUB_RESCUE more clear what it is about.

In particular bevause nowadays GRUB_RESCUE is
disabled by default, the user would read the documentation
before he enables it and I assume when the documentation
is very clear what it is about everything should be o.k.

I will make a pull request with better documentation
about GRUB_RESCUE and then we can decide if
that is perhaps already sufficient or if more needs
to be done here...

[jsmeix]

With #941
I described GRUB_RESCUE meaning more clearly
in default.conf (thsi is the only place where
GRUB_RESCUE is documented in the rear source files).

[jsmeix]

For me GRUB_RESCUE does not work
on SLEs12-SP1 (which has GRUB 2):

# usr/sbin/rear -d -D mkbackup
...
ERROR: GRUB_RESCUE_PASSWORD needs to be set. Run grub2-mkpasswd-pbkdf2 to generate pbkdf2 hash

regardless that there is in usr/share/rear/conf/default.conf

GRUB_RESCUE_PASSWORD="REAR"

The rear log file shows:

+ source /root/rear/usr/share/rear/output/default/94_grub2_rescue.sh
...
++ [[ ! REAR == \g\r\u\b\.\p\b\k\d\f\2 ]]
++ Error 'GRUB_RESCUE_PASSWORD needs to be set. Run grub2-mkpasswd-pbkdf2 to generate pbkdf2 hash'

I think in output/default/94_grub2_rescue.sh the code

if [[ ! "${GRUB_RESCUE_PASSWORD:0:11}" == 'grub.pbkdf2' ]]; then
    Error "GRUB_RESCUE_PASSWORD needs to be set. Run grub2-mkpasswd-pbkdf2 to generate pbkdf2 hash"
fi

is plain wrong.

First I will fix the GRUB_RESCUE functionality so that it works
for me because I like to learn how to use it (I never used it)...

[gdha]

@jsmeix see issue #703 for more details about grub2-mkpasswd-pbkdf2 usage

[jsmeix]

Yes, I also found this out by reverse-engineering the code ;-)
while I implemented automated usage of grub-mkpasswd-pbkdf2
in output/default/94_grub2_rescue.sh as needed via

echo -e "$GRUB_RESCUE_PASSWORD\n$GRUB_RESCUE_PASSWORD" | $grub_mkpasswd_binary | grep -o 'grub.pbkdf2.*'

to generate a PBKDF2 hash from a plain text
GRUB_RESCUE_PASSWORD.

Is there a security reason why GRUB_RESCUE_PASSWORD
cannot be plain text (if the user wants it this way)
but must be always in the form of a PBKDF2 hash?

I mean what would be the real security when the user
already has the password as plain text in /etc/rear/local.conf
and only if GRUB_RESCUE="y" rear errors out?

I think nothing in the rear code can actually hinder the user
to store any plain text secrets wherever he wants.

[jsmeix]

With #942
it somewhat works for me on SLE12-SP1.

The drawback in its current form is
that now I get the GRUB 2 password dialog
also for the default SLES12 boot entry
but before I could boot default SLES12
without a GRUB 2 password dialog.

Note in particular that before #942
GRUB 2 failed to boot the rear recovery system
because its kernel and initrd that are in '/boot/'
but were falsely specified in GRUB 2 config to be in '/'
(i.e. GRUB 2 could not load them).

[jsmeix]

In #703
it seems whatever error in the user's GRUB_RESCUE
can easily result that he can no longer boot anything
cf. #703 (comment)

Only a blind guess:
I assume a single "typo" (i.e. a copy and paste error)
when the GRUB_RESCUE_PASSWORD value is a PBKDF2 hash
results that one can no longer boot anything because
he current GRUB 2 modification via GRUB_RESCUE
results that all boot entries are protected by the same
GRUB_RESCUE_PASSWORD.

Therefore I is perhaps an useful fail-safe feature when one
can specify the GRUB_RESCUE_PASSWORD as plain text
and its PBKDF2 hash is autogenerated by rear to ensure that
the GRUB 2 password config matches the plain text password.

[gozora]

Now I'm starting to get better picture. It looks like GRUB_RESCUE (which should be rather called GRUB2_RESCUE) and GRUB_RESCUE_PASSWORD are tightly bind together. So you can't have unprotected ReaR entry. This is IMHO not correct.
If you decide to keep this option widely available you should consider making password optional.

@jsmeix

Only a blind guess:
I assume a single "typo" (i.e. a copy and paste error)
when the GRUB_RESCUE_PASSWORD value is a PBKDF2 hash
results that one can no longer boot anything because
he current GRUB 2 modification via GRUB_RESCUE
results that all boot entries are protected by the same
GRUB_RESCUE_PASSWORD.

As stated in comment to issue #703, when I did test on Centos only password protected entry was that one ReaR created, but the behavior might differ on SuSE. This however does not change the fact, that my Centos was not able to boot "out of the box" (I had to use some manual reconfiguration in grub shell to make it work).
I'll test it deeper tomorrow.

@jsmeix @gdha But first I'd like to know whether it gives any sense to work further on this code as its future is unclear. The poll might be a good idea here.
For me I'd say it that this feature not that useful, especially when I consider that it updates OS related files, which I'd not expect from backup software.

[jsmeix]

With my better description of GRUB_RESCUE
in current GitHub master cf. #941
I think it is sufficiently clear what that thingy does.

Because GRUB_RESCUE is disabled by default,
there are no unexpected changes of files in the
current running system when "rear mkbackup" is done.

What I like most about the GRUB_RESCUE feature is
to be quickly able to recover a system from soft errors
(like deleting all of /lib/) without digging out the rear recovery
boot media.

Because of this I think the GRUB_RESCUE feature
could be in particular of interest for normal end-users
who do not have compatible replacement hardware available.

With the GRUB_RESCUE feature normal end-users
could use rear on their computer to be quickly able
to recover the system from soft errors.

For normal end-users who do not have compatible
replacement hardware available a broken hardware
usually means they go to the shop and buy newest
replacement hardware which is usually not sufficiently
compatible so that "rear recover" would work on it.
I think when hardware breaks for normal end-users
it usually means a new installation from scratch with
an original installation system of a Linux distributor.

On the other hand the GRUB_RESCUE feature
requires the backup to be available which means
one must at least "dig out the backup media"
(e.g. the USB stick where the backup is stored).

But then the GRUB_RESCUE feature does no longer
make much sense in practice because it is more
straightforward to make a bootable USB stick
that contains both the rear recovery system
and the backup.

Therefore in the end the GRUB_RESCUE feature
might be in practice only be useful for server admins
to be quickly able to recover a system from soft errors
without digging out the rear recovery boot media
when the backup is stored on another server in the network
(e.g. on a NFS server) so that the backup is always available
and thre is no need to "dig out a backup media".

Because in business environments recovery speed matters
the GRUB_RESCUE feature could be useful there
to get a messed up system faster back working.

To even more increase recovery speed the server admin
could set up rear so that it runs "rear recover" fully automated
when the rear recovery system is booted
(i.e. without manual login as root and typing "rear recover")
cf. #915

Bottom line:
From my current point of view the GRUB_RESCUE feature
looks useful and at least for rear 1.19 I would not drop it.

[jsmeix]

@gozora
regarding "you can't have unprotected ReaR entry":

With my current code in #942
you can have an unprotected 'Relax-and-Recover' entry
via plain "GRUB_RESCUE=y" without
any GRUB_RESCUE_PASSWORD and GRUB_SUPERUSER
(the latter default now to empty values in default.conf).

But if you already have a /etc/grub.d/01_users file
where a previous rear run had set up a GRUB 2 superuser
you must manually remove tha file before you get an
unprotected 'Relax-and-Recover' entry, cf.
#942 (comment)

[gozora]

@jsmeix yes, I've tested this yesterday and can confirm thatit works fine.

[jsmeix]

My current #942
should now work sufficiently well for GRUB 2
on SUSE and Red Hat based Linux distributions
because I think I fixed
#703 (comment)
at least for Red Hat based Linux distributions.

When there are no objections
I will merge #942
in a few hours to have it in GitHub master code
so that also other rear users can test it more easily.

[jsmeix]

With the now merged #942
I consider this issue here as sufficiently solved.

[jsmeix]

See the follow-up issue #946