#566 PR merged: write os.conf to /etc/rear/

Labels: bug

Bullja opened issue at 2015-03-18 15:35:

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.

schlomo commented at 2015-03-18 16:34:

I don't understand why. According to https://github.com/rear/rear/blob/master/usr/sbin/rear we read $CONFIG_DIR/os.conf so that the original code should be correct.

Could you please tell us which problem you are trying to solve? Do you use a non-default $CONFIG_DIR?

Bullja commented at 2015-03-18 16:54:

In case rear is installed at a non-default location, for example /opt/rear/, CONFIG_DIR would be /opt/rear/etc/rear which would result in the os.conf tried to be written to /tmp/rear.sJ21Z1FtDdfQQOF/rootfs//opt/rear/etc/rear/os.conf which fails of course as this path doesn't exist.

When I run mkrescue, the os.conf file should be written to "/tmp/rear.sJ21Z1FtDdfQQOF/rootfs/etc/rear", but actually rear tries to write the os.conf file to "/tmp/rear.sJ21Z1FtDdfQQOF/rootfs//opt/rear/etc/rear/os.conf" failing with /opt/rear/usr/share/rear/build/default/99_update_os_conf.sh: line 3: /tmp/rear.sJ21Z1FtDdfQQOF/rootfs//opt/rear/etc/rear/os.conf: No such file or directory

Also, other config from the original installation directory are beeing copied from $CONFIG_DIR to rootfs/etc/rear/ as you can see here: 10_copy_as_is.sh#L27

Bullja commented at 2015-03-18 17:36:

My setup:

  • lsb_release -i -s: Debian
  • lsb_release -r -s: 7.8
  • installed rear to /opt/rear/: cd /opt; wget https://codeload.github.com/rear/rear/zip/rear-1.16.1; unzip rear-1.16.1; rm rear-1.16.1; mv rear-rear-1.16.1 rear
  • the only file I touch is /opt/rear/etc/rear/local.conf adding BACKUP_URL and OUTPUT_URL, no other files like os.conf or so is beeing created/edited.

During "/opt/rear/usr/sbin/rear mkrescue" I find this in rear.log:
2015-03-18 18:15:57 Including build/default/99_update_os_conf.sh
/opt/rear/usr/share/rear/build/default/99_update_os_conf.sh: line 3: /tmp/rear.Y18ytE8SbBOlDty/rootfs//opt/rear/etc/rear/os.conf: No such file or directory
/opt/rear/usr/share/rear/build/default/99_update_os_conf.sh: line 6: /tmp/rear.Y18ytE8SbBOlDty/rootfs//opt/rear/etc/rear/os.conf: No such file or directory

When booting the rescue image and running "rear recover", this stack trace can be found:
=== Stack trace ===
Trace 0: /bin/rear: 200 main
Trace 1: /usr/share/rear/lib/config-functions.sh:32 SetOSVendorAndVersion
Message: The LSB package is not installed. Currently there is no support to ....

But, if I apply the patch from above, the os.conf will be properly written to /etc/rear/os.conf of the rescue image and the "LSB package is not installed" does not appear.

schlomo commented at 2015-03-19 10:41:

I see what you mean. I think that you found a bug that $CONFIG_DIR is not honored in the rescue image. Would it not solve your problem if $CONFIG_DIR works also in the rescue system?

Another question: Why do you "install" ReaR like this? What you do is basically running it from source without proper installation. Why not install it with make install or by building a Debian package or simply using our ready made Debian package?

schlomo commented at 2015-03-19 11:01:

I digged some more and found
usr/share/rear/prep/default/10_init_workflow_conf.sh where CONFIG_DIR is set explicitly to /etc/rear for the Rescue system.

The truth is that I cannot say for sure which strategy we should implement here:

  1. CONFIG_DIR is the same in source system and in rescue system
  2. CONFIG_DIR is always /etc/rear in rescue system.

Running grep -r etc/rear suggest that ATM we follow the 2nd strategy. In that case you are right with your patch.

@gdha what do you think?

@Bullja:
I would still be happy to understand why you install ReaR like that. Maybe you have a use case we are not aware of.

BTW, did you try to do make install DESTDIR=/opt/rear?

gdha commented at 2015-03-19 12:05:

@schlomo @Bullja Personally I think it is better to define /etc/rear/ in rescue image then having your own path (especially after months it might be problematic to remember the original $CONFIG_DIR path). I remember issue #336 which is similar as this one.
For me it is fine to accept the pull request.

Bullja commented at 2015-03-19 15:36:

Installing via the deb packages I received some dependency problems I couldn't solve before so I tried just running rear from source which was working just great except the one issue os.conf was not beeing written properly which looked like a bug imho.

On some production systems I still do not want to meet the dependencies and trying to install as few packages as possible. (portmap, nfs-client, ...)

I am using rear only since few days and found the following installation methods:

  1. Installation via dpkg: If dependencies are not met, for example (portmap for NETFS support?, nfs-client for NETFS support) I can still force to install of course, but every time somebody will run apt-get on the system, the rear dependency error appears -> not good unless there is an option to to tell apt-get to ignore dependencies for rear.
  2. Installation via make install: Didn't know about that method before. Installation looks good but when running, it failes with some errors I do not want to continue looking into. See log below.
  3. "Installation" via copy to /opt/rear: Works well and easy, doesn't affect/touch the system at all.

Tending to go the
$ "copy to /opt/rear"
$ sed -i 's/$CONFIG_DIR/etc/rear/g' /opt/rear/usr/share/rear/build/default/99_update_os_conf.sh
path as compared to the other methods it is the least intrusive way to use rear.
I don't want to say "make install" or "dpkg -i" are bad, I just like to have the option to just copy and run it :)

#################
after "make install DESTDIR=/opt/rear" while running from source works well.
#################
root@zz-str:/opt/rear# usr/sbin/rear --help
usr/sbin/rear: line 131: /usr/share/rear/conf/default.conf: No such file or directory
usr/sbin/rear: line 138: has_binary: command not found
ERROR: Required program 'pidof' missing, please check your PATH
root@zz-str:/opt/rear# which pidof
/bin/pidof

schlomo commented at 2015-03-20 09:42:

Thanks for providing some background information.

It seems like so far the make install DESTDIR=... only works for our build scripts. Feel free to submit more pull requests to improve that behaviour.

The pidof error you see is a follow up error caused by ReaR not finding its files. In your case I would advice to use make install to manually install ReaR into its default paths. That way you will get a regular install without the dependency trouble.

The package dependencies are a constant source of conflict. Some people only want the bare minimum and others complain if common features don't work "out of the box".

So far we have only a single ReaR package wich obviously cannot suit everybody. Maybe we should have a rear base package with just the really required minimum dependencies and then addon packages for different use cases that pull in the neccessary dependencies. Again, patches are welcome.

[Export of Github issue for rear/rear.]