Unsupported OUTPUT value like OUTPUT=iso is silently ignored or may error out with misleading error messages.

[pick34]

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]

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
#2254
and the other issues mentioned therein, in particular see
#791 (comment)
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]

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]

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]

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]

@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]

With #2503 merged
this issue should be fixed
as far as possible with reasonable implementation effort, cf.
#2503 (comment)
and with reasonable maintenance effort for the future, cf.
#2503 (comment)

[jsmeix]

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

[pick34]

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 ***@***.***> wrote: Closed #2501 <#2501>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2501 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5RC6BWI3S3H2RBSSBL26TSLRBL7ANCNFSM4SRUPINQ> .

[jsmeix]

@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.