#1022 PR `closed`: Notification feature rhbz #1377547¶

Labels: support / question, fixed / solved / done

phracek opened issue at 2016-10-04 08:40:¶

Signed-off-by: Petr Hracek phracek@redhat.com

reference rhbz https://bugzilla.redhat.com/show_bug.cgi?id=1377547

jsmeix commented at 2016-10-04 08:59:¶

https://bugzilla.redhat.com/show_bug.cgi?id=1377547
tells me:

You are not authorized to access bug #1377547.
To see this bug, you must first log in to an account
with the appropriate permissions.

jsmeix commented at 2016-10-04 09:06:¶

Relax-and-Recover is free software.
We need freely accessibly information.

phracek commented at 2016-10-18 14:15:¶

Here is the text:

Description of problem:
Once backup is completed (rear mkbackup), customer would like to log message that "backup complete" with a timestamp and location of the backup so the result can be inserted into a database.

Version-Release number of selected component (if applicable):
rear-1.17.2-1.el7.noarch

How reproducible:
Always

Steps to Reproduce:
Currently there is no provision to log message after successful backup completion.

Actual results:
Currently there is no provision to log message after successful backup completion.

Expected results:
Have some kind of provision to log message after successful backup completion only.

Additional info:
As a temporary hack, I modified /usr/sbin/rear bash script itself to log such message.

# Check for and run the requested workflow
if has_binary WORKFLOW_$WORKFLOW; then
        Log "Running $WORKFLOW workflow"
        WORKFLOW_$WORKFLOW "${ARGS[@]}"
        Log "Finished running $WORKFLOW workflow $BACKUP_URL"
        LogPrint "Finished running $WORKFLOW workflow $BACKUP_URL `date` " <<<<<< Added this line to print any messages and access variables 
else
        VERBOSE=1
        LogPrint "ERROR: The specified command '$WORKFLOW' does not exist !"
        EXIT_CODE=1
fi

I have not completely tested above but looks possible to get notification from here.

gozora commented at 2016-10-18 14:45:¶

Hello, not sure if I've understood all aspects of your problem, but wouldn't be enough to modify command like:
rear mkbackup && echo "$(date) $(hostname): Backup finished." || echo "$(date) $(hostname): Backup failed."
?

gdha commented at 2016-10-18 16:00:¶

@phracek And, rear does write a message in:

[root@client vagrant]# grep rear /var/log/messages 
Oct 18 06:01:25 localhost yum[10520]: Installed: rear-1.18-177.git201609201246.el7.x86_64
Oct 18 10:38:45 localhost rear[8005]: DONE: rc=0

after each run (as you see). Your proposal only writes a message in the rear log itself.

jsmeix commented at 2016-10-19 08:23:¶

In its current form I cannot accept it, see
https://github.com/rear/rear/issues/1023#issuecomment-251369333

If the customer request is actually valid in general
it needs to be implemented in a generally working way,
in particular the kind of final reporting message must be
configurable via a variable that is described in default.conf
and by default it must be empty to behave backward compatible.

If the customer request is actually valid in general
I am thinking about an array variable that lists those
variables that will be printed as final reporting message
e.g. in /etc/rear/local.conf something like

FINAL_REPORT_VARIABLES=( WORKFLOW BACKUP_URL )

and in /usr/sbin/rear at the end something like

if test $FINAL_REPORT_VARIABLES ; then
    LogPrint "Final report:"
    for v in ${FINAL_REPORT_VARIABLES[@]} ; do
        LogPrint "$v : ${!v}"
    done
fi

But currently I am wondering if the customer request is actually valid
because when /usr/sbin/rear only prints some variable values
it means basically nothing at all whether or not the reported stuff
was actually successful.
It only means that /usr/sbin/rear somehow reached the end
and prints some variable values.
Is this really what the customer wants?
Or does the customer want to know if it was actually successful?

FYI why it means basically nothing
when /usr/sbin/rear reached its end,
cf. "Try to care about possible errors"
https://github.com/rear/rear/wiki/Coding-Style

gigawatts commented at 2016-10-20 16:47:¶

Please reference https://github.com/rear/rear/issues/991 for my initial issue, that will help explain a lot of what I am trying to do here.

What I am proposing, instead of hijacking the umount command like I have in the past (which worked great up to and including rear v1.15) is to add a new variable we can define in local.conf or site.conf that gets executed at the very end of the backup, so that I can use internal rear variables such as:

"$NETFS_URL/${NETFS_PREFIX}/${BACKUP_PROG_ARCHIVE}${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX}"

In my case, I am interested in a string with the timestamp and the above final location of the backup tar so that I can insert them into a database. Let me know if any of that needs more explaining.

Thank you.

jsmeix commented at 2016-10-21 08:24:¶

@gigawatts
are you the above mentioned Red Hat customer?
If yes, I appreciate it very much to have now a direct
communication with the original requester.

A side note:
Indirect communication via intermediate people
who cannot fully understand the original request
is just another instance of RFC 1925 (6a):

It is always possible to add another level of indirection.

which - from my personal experience - is one of the main
root causes in more than 90% of issues. Another main
root cause in more than 90% of issues is RFC 1925 (5):

It is always possible to aglutenate multiple separate
problems into a single complex interdependent solution.

which I call "Keep Separated Items Separated" ('KSIS').
Accordingly 81% of the issues have both as root causes.

Back to the actual topic:

In general regarding a "variable we can define in local.conf
or site.conf that gets executed at the very end of the backup"
see in current rear master code or in rear 1.19 release
conf/default.conf

POST_BACKUP_SCRIPT=

I tested on my SLES12-SP2 system
with that in local.conf (excerpts):

OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://10.160.4.244/nfs
...
POST_BACKUP_SCRIPT=( 'echo "NETFS_URL: $NETFS_URL" ; echo "NETFS_PREFIX: $NETFS_PREFIX" ; echo "BACKUP_PROG_ARCHIVE: $BACKUP_PROG_ARCHIVE" ; echo "BACKUP_PROG_SUFFIX: $BACKUP_PROG_SUFFIX" ; echo "BACKUP_PROG_COMPRESS_SUFFIX: $BACKUP_PROG_COMPRESS_SUFFIX"' )

I got:

# /usr/sbin/rear -d -D mkbackup
Relax-and-Recover 1.19 / Git
Using log file: /root/rear/var/log/rear/rear-g136.log
...
Archived 1221 MiB in 136 seconds [avg 9198 KiB/sec]
NETFS_URL: 
NETFS_PREFIX: g136
BACKUP_PROG_ARCHIVE: backup
BACKUP_PROG_SUFFIX: .tar
BACKUP_PROG_COMPRESS_SUFFIX: .gz

In my case NETFS_URL is not shown because
it is nowhere used during "rear mkbackup"
except in my POST_BACKUP_SCRIPT.

Note that NETFS_URL is outdated according to
doc/rear-release-notes.txt:

Replaced NETFS_URL and ISO_URL by BACKUP_URL
and OUTPUT_URL. However, old references will still be
recognized and used.

cf. prep/default/02_translate_url.sh
and verify/default/02_translate_url.sh

if [[ "$NETFS_URL" ]] ; then
    Log "Using NETFS_URL is deprecated. Use BACKUP_URL instead."
    BACKUP_URL=$NETFS_URL
fi

When I use BACKUP_URL in my POST_BACKUP_SCRIPT
I get its value.

Bottom line:
POST_BACKUP_SCRIPT should do what you need.

I regard this issue as a "support" question
that is "fixed" hereby.

gigawatts commented at 2016-10-21 17:04:¶

Yes, I am said customer. Originally I was trying to solve an issue with NETFS_UMOUNTCMD not working as expected (still an open issue), but realized that a better solution to my problem was a post script. It sounds like that new POST_BACKUP_SCRIPT var is exactly what I was looking for!

I'll have a look at v1.19 and see if that works for my needs. Thank you.

schlomo commented at 2016-10-22 17:44:¶

@gigawatts what prevents your from adding your custom code in a script in /usr/share/rear/backup/default/99_custom_code.sh or something similar? Use rear -s mkbackup to see all the scripts in all the stages that are run.

FYI, adding scripts to the ReaR structure is the recommended way of extending ReaR with new or custom functionality.

jsmeix commented at 2016-10-24 08:18:¶

@schlomo
by the way regarding adding user scripts
like .../99_my_script.sh or .../01_my_other_script.sh:

I noticed several .../01_... and .../99_... scripts
in the current ReaR master code.

I wonder if we should re-number them so that the
numbers 01 and 99 are never used by ReaR so that
those numbers are always reserved for user scripts?

The current ReaR 01_ and 99_ scripts:

backup/default/01_pre_backup_script.sh
backup/default/99_post_backup_script.sh
build/default/99_update_os_conf.sh
finalize/NBU/default/99_copy_bplogrestorelog.sh
finalize/default/01_prepare_checks.sh
init/default/01_set_drlm_env.sh
layout/prepare/default/01_prepare_files.sh
output/default/01_set_umask.sh
rescue/GNU/Linux/99_sysreqs.sh
rescue/default/01_merge_skeletons.sh
restore/default/99_move_away_restored_files.sh
setup/default/01_pre_recovery_script.sh
wrapup/default/99_copy_logfile.sh

schlomo commented at 2016-10-25 21:54:¶

That might be a good idea. Thanks for seeing that.

On 24 October 2016 at 10:18, Johannes Meixner notifications@github.com
wrote:

@schlomo https://github.com/schlomo
by the way regarding adding user scripts
like .../99_my_script.sh or .../01_my_other_script.sh:

I noticed several .../01_... and .../99_... scripts
in the current ReaR master code.

I wonder if we should re-number them so that the
numbers 01 and 99 are never used by ReaR so that
those numbers are always reserved for user scripts?

The current ReaR 01_ and 99_ scripts:

backup/default/01_pre_backup_script.sh
backup/default/99_post_backup_script.sh
build/default/99_update_os_conf.sh
finalize/NBU/default/99_copy_bplogrestorelog.sh
finalize/default/01_prepare_checks.sh
init/default/01_set_drlm_env.sh
layout/prepare/default/01_prepare_files.sh
output/default/01_set_umask.sh
rescue/GNU/Linux/99_sysreqs.sh
rescue/default/01_merge_skeletons.sh
restore/default/99_move_away_restored_files.sh
setup/default/01_pre_recovery_script.sh
wrapup/default/99_copy_logfile.sh

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/pull/1022#issuecomment-255676605, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGMCJmaq2AVqAK2mk033xih9ZHytOSXks5q3Gm4gaJpZM4KNbNb
.

jsmeix commented at 2016-10-26 13:06:¶

I cannot do a re-numbering with reasonable effort, see
https://github.com/rear/rear/pull/1051#issuecomment-256338122

jsmeix commented at 2016-10-27 17:41:¶

FYI:

The re-numbering is done now via
https://github.com/rear/rear/pull/1053

Since I merged https://github.com/rear/rear/pull/1053
basically ALL scripts got a changed name
from NM_name.sh to NM0_name.sh
(except 00_name.sh that is now 005_name.sh)

This means you must update your working copy
to the current master state otherwise I assume
you will get big conflicts with further pull requests.

[Export of Github issue for rear/rear.]

#1022 PR closed: Notification feature rhbz #1377547¶