#774 Issue `closed`: issues if rear is installed in non-default path¶

Labels: support / question

abbbi opened issue at 2016-02-15 10:27:¶

hi there,

im struggeling to get rear correctly working on a non-standard installation path.
Im using the DESTDIR= parameter to install rear into another path than usually, that results in some
issues which should at least be discussed.

For example, installing rear into /opt/rear/ with the following command:

make install DESTDIR=/opt/rear/

will result in the following error:

linux-fhta:~/rear # /opt/rear/usr/sbin/rear mkrescue -v
/opt/rear/usr/sbin/rear: line 282: /usr/share/rear/conf/default.conf: No such file or directory
/opt/rear/usr/sbin/rear: line 290: IsInArray: command not found
/opt/rear/usr/sbin/rear: line 296: has_binary: command not found
ERROR: Required program 'pidof' missing, please check your PATH

Issue is that the Makefile does not use the DESTDIR parameter in all places to replace the paths within the rear exectuable. I think i have created a patch for this sometime in the past and it was reverted as it lead to break rear in other modules or situations, the diff is one like this:

diff --git a/Makefile b/Makefile
index 16df320..b098d4b 100644
--- a/Makefile
+++ b/Makefile
@@ -136,9 +136,9 @@ install-config:
 install-bin:
        @echo -e "\033[1m== Installing binary ==\033[0;0m"
        install -Dp -m0755 $(rearbin) $(DESTDIR)$(sbindir)/rear
-       sed -i -e 's,^CONFIG_DIR=.*,CONFIG_DIR="$(sysconfdir)/rear",' \
-               -e 's,^SHARE_DIR=.*,SHARE_DIR="$(datadir)/rear",' \
-               -e 's,^VAR_DIR=.*,VAR_DIR="$(localstatedir)/lib/rear",' \
+       sed -i -e 's,^CONFIG_DIR=.*,CONFIG_DIR="$(DESTDIR)$(sysconfdir)/rear",' \
+               -e 's,^SHARE_DIR=.*,SHARE_DIR="$(DESTDIR)$(datadir)/rear",' \
+               -e 's,^VAR_DIR=.*,VAR_DIR="$(DESTDIR)$(localstatedir)/lib/rear",' \
                $(DESTDIR)$(sbindir)/rear

 install-data:

Is there another way to install REAR into a non-default path than using DESTDIR=?

Another problem is that with a recent change, the "os.conf" file is allways forcibly installed into the /etc/rear directory of the resulting image. This causes rear to not find the os.conf configuration file and exit upon execution during recovery. One has to copy the os.conf configuration file within the recovery image from /etc/rear/os.conf to $DESTDIR/etc/rear/os.conf:

commit 5507548d9796706dfbab13f5617c854121694728
    write os.conf to /etc/rear/

    os.conf MUST be at /etc/rear/os.conf in the rescue image. $CONF_DIR may have been different depending on the rear installation directory.


diff --git a/usr/share/rear/build/default/99_update_os_conf.sh b/usr/share/rear/build/default/99_update_os_conf.sh
index f9ffcb6..9b51782 100644
--- a/usr/share/rear/build/default/99_update_os_conf.sh
+++ b/usr/share/rear/build/default/99_update_os_conf.sh
@@ -1,6 +1,6 @@
 # add os/version info to os.conf in the rescue system so that we don't need to pull lsb into the rescue system

-echo -e "#\n# WARNING ! This information was added automatically by the $WORKFLOW workflow !!!" >> $ROOTFS_DIR/$CONFIG_DIR/os.conf
+echo -e "#\n# WARNING ! This information was added automatically by the $WORKFLOW workflow !!!" >> $ROOTFS_DIR/etc/rear/os.conf
 for var in ARCH OS OS_VERSION OS_VENDOR OS_VENDOR_VERSION OS_VENDOR_ARCH ; do
        echo "$var='${!var}'"
-done >> $ROOTFS_DIR/$CONFIG_DIR/os.conf
+done >> $ROOTFS_DIR/etc/rear/os.conf
lines 1-13/13 (END)

gdha commented at 2016-02-15 13:24:¶

See also #329 - SEP Sesam also tried it and it broke rear (pull request #324).
You can use rear from the directory where you ran the 'git cloneor untarred that archive as./usr/sbin/rear`

abbbi commented at 2016-02-16 21:30:¶

hi again,

yes, i know that just executing rear from a cloned repository or extracted archive will work.
This is solving our first "Problem".

This however still creates files in /etc/rear/, even if the user does not want it to. Is there a
special usecase or why has the os.conf been hardcodet to /etc/?

I know the old commit from SEP Sesam broke some Fedora related things :-)
We from SEP ship REAR with our client installation and we dont want to modify the system
in pathes which are not related to SEP Sesam. Of course we can change REAR to place os.conf in the right directory, but we dont want our shipped REAR components to differ from your release versions!

abbbi commented at 2016-02-17 08:37:¶

After some more testing: simply running rear from extracted tar or git checkout solves both problems. I think we can close this here :-)

jsmeix commented at 2016-02-17 08:45:¶

@abbbi
it seems what you need is a general prefix for all of rear's files
so that in particular rear creates files in /etc/rear/.

In usr/sbin/rear there is

# Find out if we're running from checkout
REAR_DIR_PREFIX=""
readonly SCRIPT_FILE="$( readlink -f $( type -p "$0" || echo "$0" ) )"
if test "$SCRIPT_FILE" != "$( readlink -f /usr/sbin/$PROGRAM )" ; then
    REAR_DIR_PREFIX=${SCRIPT_FILE%/usr/sbin/$PROGRAM}
fi
readonly REAR_DIR_PREFIX
# Program directories - they must be set here. Everything else is then dynamic.
# Not yet readonly here because they are set via the /etc/rear/rescue.conf file
# in the recovery system that is sourced by the rear command in recover mode
# and CONFIG_DIR can also be changed via '-c' command line option:
SHARE_DIR="$REAR_DIR_PREFIX/usr/share/rear"
CONFIG_DIR="$REAR_DIR_PREFIX/etc/rear"
VAR_DIR="$REAR_DIR_PREFIX/var/lib/rear"
LOG_DIR="$REAR_DIR_PREFIX/var/log/rear"

Accordingly if for example $CONFIG_DIR is used in the scripts and no hardcoded "/etc/rear", rear should create files accordingly.

It seems currently it is hardcoded in usr/sbin/rear when a non-empty REAR_DIR_PREFIX will be used.

I assume you may need to adapt and enhance that for your needs and then verify if a non-empty REAR_DIR_PREFIX will really be used in all the various rear scripts as needed.

As far as I see there is a difference if rear runs in its recovery system (basically when "rear recover" is run) in contrast to when rear is run in the original system (e.g. when "rear mkbackup" is run).

As far as I see if rear runs in its recovery system then rear should use hardcoded paths like "/etc/rear/" to match the actual direcories in the recovery system.

In contrast when rear is run in the original system it should consistently use REAR_DIR_PREFIX where appropriate.

jsmeix commented at 2016-02-17 08:51:¶

@abbbi
I did not see your https://github.com/rear/rear/issues/774#issuecomment-185095007 while I wrote my last comment.

As far as I see your https://github.com/rear/rear/issues/774#issuecomment-185095007 proves that rear works correctly when a non-empty REAR_DIR_PREFIX is used.

Accordingly I think all what you still may need to make rear working perfectly for your use-case is to to adapt and enhance the current hardcoded magic in usr/sbin/rear when a non-empty REAR_DIR_PREFIX will be used.

gdha commented at 2016-02-17 08:59:¶

In recovery mode the /etc/rear/rescue.conf defines the rear paths

[Export of Github issue for rear/rear.]

#774 Issue closed: issues if rear is installed in non-default path¶