#496 Issue closed: SLES12: lsb_release missing in created iso image?

Labels: support / question

abbbi opened issue at 2014-10-29 10:04:

hi,

trying to recover a SLES12 instance gives me the following while executing rear recover:

RESCUE linux-60x9:~ # rear recover
Relax-and-Recover 1.16.1-git201410271553 / 2014-10-27
Using log file: /var/log/rear/rear-linux-60x9.log
ERROR: The LSB package is not installed.
Currently there is no support to detect the OS and VERSION without LSB support.
Please either install the LSB package (that supplies the 'lsb_release' command)
or improve Relax-and-Recover to handle this situation better.

it seems the lsb_release package is not included in the generated iso image, it however
exists on the system which created the backup. Grepping the logfile which was created
in debug mode does not give me any hints about lsb_release.

Should lsb_release not be part of the iso image?

abbbi commented at 2014-10-29 10:48:

hi,

on a closer look this issue is related to the situation that REAR in this case is not installed into its default path. The rear installation resides in /var/opt/sesam/var/lib/rear/, however, os.conf is created
beneath this directory while the recovery ISO image expects it in /etc/rear/.

schlomo commented at 2014-10-29 10:53:

Hi,

that is exactly the reason why I encourage vendors like SEP to not fork
ReaR but to participate in the ReaR development so that upstream ReaR does
what you need. I strongly believe that you will achieve more and better
results with much less effort. And you will save a lot of maintenance
effort if thinking long term.

Maybe you let us know what we the ReaR project should do to enable you to
use the ReaR project instead of forking it?

And you can pin the "supporting open source projects" medal to your chest
(or hang it on your office wall) :-)

Kind Regards,
Schlomo

On 29 October 2014 11:48, Michael Ablassmeier notifications@github.com
wrote:

hi,

on a closer look this issue is related to the situation that REAR in this
case is not installed into its default path. The rear installation resides
in /var/opt/sesam/var/lib/rear/, however, os.conf is created
beneath this directory while the recovery ISO image expects it in
/etc/rear/.


Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/496#issuecomment-60903492.

abbbi commented at 2014-10-29 11:31:

hi,

basically the only thing we do is:

  1. we ship REAR with local.conf that sets BACKUP=SESAM
  2. we ship REAR in an non-default installation path

there are no more changes other than that in the version that is included by our backup client.
It seems at least point 2) does have some troubles with the latest git version, we will investigate.

schlomo commented at 2014-10-29 11:39:

Why do you need to ship ReaR with a non-default installation path? Which
benefit do you get from this?

abbbi commented at 2014-10-29 11:54:

As sesam does install itself to /opt;/var/opt we also want to install the REAR version shipped with sesam into this path.

schlomo commented at 2014-10-29 12:04:

I see. What about not shipping ReaR but using ReaR from the OS repos? And
spending the same effort instead on helping the ReaR project to provide
updated ReaR versions through the OS repos?

On 29 October 2014 12:54, Michael Ablassmeier notifications@github.com
wrote:

As sesam does install itself to /opt;/var/opt we also want to install the
REAR version shipped with sesam into this path.


Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/496#issuecomment-60910668.

abbbi commented at 2014-10-29 12:09:

We do support client systems which make it more or less impossible to introduce new packages in the OS repos (debian stable for example). Also, i dont know how SLES or RHEL behave in this regard to their update repositories. It is simpler for our customers to get it working out of the box if the REAR client is installed within the sesam rpm package. I know that this is sub-optimal, but i dont see another good way at the moment. For a long term solution, of course it would be better to have the latest REAR package available in the OS repos.

gdha commented at 2015-05-28 12:52:

@abbbi Adding lsb_release to the rear ISO image would blow up the size of the ISO image and we do not want that. You already discovered the the os.conf was found under /var/opt/sesam/var/lib/rear/etc/rear?? and rear itself expects it under /etc/rear
Did you know that the /etc/rear/rescue.conf file defines the PATH where rear looks for its own internal paths, but it maybe a chicken and egg problem as the SESAM rear fork does not look beneath /etc/rear
What can we do about it? SEP Sesam is not very co-operative with us, so I would open a support call with them.


[Export of Github issue for rear/rear.]