Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy "rear recover" log file and related data into recovered system #706

Closed
jsmeix opened this issue Nov 20, 2015 · 8 comments
Closed

Copy "rear recover" log file and related data into recovered system #706

jsmeix opened this issue Nov 20, 2015 · 8 comments
Assignees
Labels
enhancement Adaptions and new features fixed / solved / done

Comments

@jsmeix
Copy link
Member

jsmeix commented Nov 20, 2015

At the end of "rear recover"
the log file /var/log/rear/
and other recovery related data
like /var/lib/rear/layout/disklayout.conf
and its matching /var/lib/rear/layout/diskrestore.sh
exist only in the rear recovery system.

When the rear recovery system is shut down
the "rear recover" related data is lost.

I like to implement that "rear recover" by default copies
the recovery related log and data into the recovered system
so that this data is later available for example for a detailled
analsysis of the recovery.

To keep the recovery related log and data strictly separated from
the other rear logs and data I like to use a separated directory
var/log/rear/recover for this.

In short:
I like to implemet that at the end of "rear recover"
basically the following is done:

mkdir -p /mnt/local/var/log/rear/recover
cp -p /var/log/rear/rear*.log /mnt/local/var/log/rear/recover
mkdir /mnt/local/var/log/rear/recover/layout
cp -pr /var/lib/rear/layout/*  /mnt/local/var/log/rear/recover/layout

I did a "rear --debugscripts xv recover" and the above
commands manually and /mnt/local/var/log/rear/recover
needs 1.1 MB disk space and with plain "rear recover"
/mnt/local/var/log/rear/recover needs needs 80 kB for me.

I do not think this "wastes disk space" and therefore
I think it can (and should) be done by default.

If there is so little free disk space that about 2 MB
for 'rear recover' with 'set -xv' and about 100 kB
for plain 'rear recover' makes a noticeable difference,
then that only points out the real problem
("too little free disk space").

@jsmeix jsmeix added enhancement Adaptions and new features waiting for info labels Nov 20, 2015
@jsmeix jsmeix self-assigned this Nov 20, 2015
@gdha
Copy link
Member

gdha commented Nov 20, 2015

@jsmeix I have no objection against it.
Perhaps we could in the meantime also tackle issue #21 ?

@jsmeix
Copy link
Member Author

jsmeix commented Nov 20, 2015

I will implement this one together with #21

jsmeix added a commit to jsmeix/rear that referenced this issue Nov 20, 2015
and provide a compatibility link with where the log file was before
see rear#706
@schlomo
Copy link
Member

schlomo commented Nov 21, 2015

Why not copy it to /root in the recovered system - similar to how Red Hat's Kickstart leaves there the kickstart file and log?

@schlomo
Copy link
Member

schlomo commented Nov 21, 2015

In any case, I would make sure that only root can read those files.

@jsmeix
Copy link
Member Author

jsmeix commented Nov 23, 2015

I already implemented that only root can access files
in /var/log/rear/recover

But I wonder why everybody can read the other files
in /var/log/rear and /var/lib/rear ?

In other words:
I wonder why it seems what "rear mkbackup" results is o.k. to be read by any user while what "rear recover" results is not?

@gdha
Copy link
Member

gdha commented Nov 23, 2015

@jsmeix @schlomo Personally, I don't think a log file is a security threat if it is readable. We only have to make sure there are no passwords or any other sensitive data visible. And, I believe we already have done that in the past (#560)

@jsmeix
Copy link
Member Author

jsmeix commented Nov 23, 2015

I implemented this particular issue with #709 but this does not yet implement #21

@jsmeix
Copy link
Member Author

jsmeix commented Nov 25, 2015

This particular issue is fixed with #709

@jsmeix jsmeix closed this as completed Nov 25, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adaptions and new features fixed / solved / done
Projects
None yet
Development

No branches or pull requests

3 participants