#2501 Issue `closed`: Unsupported OUTPUT value like OUTPUT=iso is silently ignored or may error out with misleading error messages.¶

Labels: enhancement, fixed / solved / done, minor bug

pick34 opened issue at 2020-10-15 08:10:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.5 / Git
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:    20.04
Codename:   focal

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

# cat /etc/rear/local.conf
OUTPUT=iso
BACKUP=NETFS
BACKUP_URL=nfs://10.10.1.247/rearx/test1/

yes it is my first try :-)

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
ESXi guest
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86_64
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Bios
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
nfs or local
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):
Description of the issue (ideally so that others can reproduce it):

a) Typo in config file not reported.

b) Script 900_copy_result_files.sh failed silently not installing a README file which causes a latter script to fail. Should this script handle the error better?

But since Im new to ReaR - I could be wrong on this. But from a newbie experience ended up spending more time chasing up my nfs config, doubting someting there since it was just newly installed nas etc... And then it was just that I had a typo in a config file because I typed it in instead of cut and paste.... Who says laziness doesnt pay.

It's a user experience type of thing, more of an enhancement then any major issue,

E.g. local.conf contained "OUTPUT=iso"

Causes a shell script error with a cp failing copying a README file when running rear

rear -v mkrescue
.... deleted msgs ....
Copying resulting files to nfs location
Saving /var/log/rear/rear-rearx.log as rear-rearx.log to nfs location
Copying result files '/tmp/rear.6YQKxaBfN7OfgB8/tmp/VERSION /tmp/rear.6YQKxaBfN7OfgB8/tmp/README /tmp/rear.6YQKxaBfN7OfgB8/tmp/rear-rearx.log' to /tmp/rear.6YQKxaBfN7OfgB8/outputfs/rearx at nfs location
ERROR: Could not copy result file /tmp/rear.6YQKxaBfN7OfgB8/tmp/README to /tmp/rear.6YQKxaBfN7OfgB8/outputfs/rearx at nfs location
.... deleted msgs ....

The script which causes the error as it looks like it does not copy the README file to /tmp/rear.6YQKxaBfN7OfgB8/tmp/README

/usr/share/rear/output/RSYNC/default/900_copy_result_files.sh

And on this line could see what was going wrong -
cp $v $(get_template "RESULT_usage_$OUTPUT.txt") "${TMP_DIR}/rsync/${RSYNC_PREFIX}/README" >&2

Looking at the potential files to be copied made me check the config file for OUTPUT and indeeed it should be upper case (as is in the man page etc)

ls -1  /usr/share/rear/conf/templates/
EFI_readme.txt
...
RESULT_usage_ISO.txt
...

Tells me I had messed up the config file, and OUTPUT was incorrectly to iso.

Workaround, if any:

a)
In local.conf use -
OUTPUT=ISO

b)
Get more sleep :-)

Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

Thanks - been meaning to give ReaR a try every since I heard of it.
I am sure, no doubt, it will save me hours at some point !!!!

jsmeix commented at 2020-10-15 11:29:¶

Simply put:

Currently there is basically no syntax checking in ReaR
(except at very few exceptional places).

Currently user experience is not an actual development goal for ReaR.

Of course we (i.e. the ReaR upstream developers) do not actively work against our users
but in almost all cases we and our users are happy when "things work at all".

Cf. the section "RPM packages for disaster recovery" in
https://en.opensuse.org/SDB:Disaster_Recovery
that reads (excerpt):

The software ... is intended for experienced users and system admins.
There is no easy user-frontend (in particular there is no GUI)
and in general software for disaster recovery
does not behave really foolproof (it runs as 'root' and
you need to know what it does).

Further information:

Implementing reasonalby good user experience
needs much more development time compared to
implementing only the plain functionality.

We at ReaR upstream have many open issues about plain functionality,
even huge things that wait but need to be done, for an example see
https://github.com/rear/rear/issues/2254
and the other issues mentioned therein, in particular see
https://github.com/rear/rear/issues/791#issuecomment-406513969
with more other issues mentioned therein.

So in foreseeable future there will be no ReaR upstream development time
for issues that go beyond plain functionality.

Of course things change when a user needs something implemented
that he cannot implement on his own (e.g. "no knowledge" or "no time")
but he can and wants to pay someone to implement if for him, see
http://relax-and-recover.org/support/
and
http://relax-and-recover.org/development/

jsmeix commented at 2020-10-15 11:54:¶

I tried OUTPUT=iso and I see now that this issue is much more serious
than it looks on a first glance because with OUTPUT=iso none of the
scripts in directories like prep/ISO and output/ISO/ are run.
In my particular case rear -D mkrescue did not even error out with OUTPUT=iso
so it behaves against "Try hard to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style

pick34 commented at 2020-10-15 21:26:¶

That makes complete sense, and appreciate the very complete response. It's an imense project, and extremely important one. Keep up the good work and park this issue as you feel appropriate.

Cheers - Allan

jsmeix commented at 2020-10-16 08:40:¶

Technically it is only a minor bug in ReaR when it misbehaves in case of wrong or invalid user settings
regardless that such misbehaviour could be a mayor annoyance for the user - in particular when
there are no helpful (error) messages.

Meanwhile (as always sleeping over an issue helps a lot ;-) I remember the exceptional place
where we have syntax checking in ReaR that matches this issue here:
usr/share/rear/prep/default/035_valid_backup_methods.sh
https://github.com/rear/rear/blob/master/usr/share/rear/prep/default/035_valid_backup_methods.sh

I will add a matching prep/default/036_valid_output_methods.sh

jsmeix commented at 2020-10-16 11:18:¶

@pick34
if you like you could add a
usr/share/rear/prep/default/036_valid_output_methods.sh
script with content as in
https://github.com/rear/rear/pull/2503/files
to your installed ReaR scripts
and play around how then ReaR behaves in case of invalid OUTPUT values.

jsmeix commented at 2020-10-19 14:03:¶

With https://github.com/rear/rear/pull/2503 merged
this issue should be fixed
as far as possible with reasonable implementation effort, cf.
https://github.com/rear/rear/pull/2503#issuecomment-709976054
and with reasonable maintenance effort for the future, cf.
https://github.com/rear/rear/pull/2503#issuecomment-710017235

jsmeix commented at 2020-10-19 14:04:¶

@pick34
thank you for your issue report that revealed a generic misbehaviour in ReaR.

pick34 commented at 2020-10-20 11:36:¶

much appreciated. And again - much appreciated. Been meaning to install
ReaR for all our physical iron for some time now. Having problems with a
restore and rpcbin but that's for another bug.

Regards - Allan

On Mon, 19 Oct 2020 at 16:03, Johannes Meixner notifications@github.com
wrote:

Closed #2501 https://github.com/rear/rear/issues/2501.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/2501#event-3893619885, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AC5RC6BWI3S3H2RBSSBL26TSLRBL7ANCNFSM4SRUPINQ
.

jsmeix commented at 2020-10-20 12:30:¶

@pick34
you reported that you use ReaR 2.5.

ReaR 2.6 is our current ReaR upstream release, cf.
http://relax-and-recover.org/download/
that lists a link that points to
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/xUbuntu_20.04/
wherefrom you can go to
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/xUbuntu_20.04/amd64/

You may also have a look at the sections
"Testing current ReaR upstream GitHub master code" and
"Help and Support" in
https://en.opensuse.org/SDB:Disaster_Recovery

In general we at ReaR upstream support (on a voluntary basis)
only the newest ReaR upstream version or
preferably the ReaR upstream GitHub master code.

This does not mean we reject all issues with older ReaR versions
but we only spend time with older ReaR versions when it is obvious
that the issue also exists in current ReaR upstream GitHub master code
because we fix only the ReaR upstream GitHub master code.

Therefore "Testing current ReaR upstream GitHub master code"
would help us at ReaR upstream most and at the same time
it should help you most because when you are used to use
our current upstream master code you get all our fixes directly.
See also the section
"Version upgrades with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
I.e. you can test the current ReaR upstream GitHub master code
until things work for you as you need it in your particular case
and then don't change what works for you unless there is real need.

[Export of Github issue for rear/rear.]

#2501 Issue closed: Unsupported OUTPUT value like OUTPUT=iso is silently ignored or may error out with misleading error messages.¶