Apologies, I messed up in the first one. My output above suggests that sos already collects /var/log/rear/* when it does not.

# find etc/ var/log/ | grep rear
etc/cron.d/rear

I have adjusted the title appropriately to account for the correction.

UPDATE: we need sos to collect the following for rear:

/etc/rear/*

-AND-

/var/log/rear/*

I opened this same BZ for RHEL 6 - https://bugzilla.redhat.com/show_bug.cgi?id=1474997

This would need to be added as a new sos plug-in. Where any plug-in:

- is enabled by presence of at least one package from specified package list

- can collect files and command outputs

- can scrub / obfuscate confidential data like passwords in configs or so


That brings me the following questions:
1) what package(s) shall trigger/enable this plug-in?

2) can't be the logs (or config files) too big? Can't be there e.g. a symlink to a block device we shall not copy?

3) Cant be there (in logs or configs) some secret information (password, SSL key,..) we shall obfuscate?

4) potentially is there some command whose output can be valuable to collect as well?

(In reply to Pavel Moravec from comment #5)
> This would need to be added as a new sos plug-in. Where any plug-in:
> 
> - is enabled by presence of at least one package from specified package list
> 
> - can collect files and command outputs
> 
> - can scrub / obfuscate confidential data like passwords in configs or so
> 
> 
> That brings me the following questions:
> 1) what package(s) shall trigger/enable this plug-in?
> 
> 2) can't be the logs (or config files) too big? Can't be there e.g. a
> symlink to a block device we shall not copy?
> 
> 3) Cant be there (in logs or configs) some secret information (password, SSL
> key,..) we shall obfuscate?
> 
> 4) potentially is there some command whose output can be valuable to collect
> as well?

Hello Blair,
could you please provide the requested information to let us implement the plug-in?

Thanks.

Hi Pavel,

Thanks for responding to this. Sorry for the delay.

1) what package(s) shall trigger/enable this plug-in?

Either rear.noarch or rear.x86_64 should trigger/enable the plugin

2) can't be the logs (or config files) too big? Can't be there e.g. a symlink to a block device we shall not copy?

I don't think these can be a symlink to a block device. But we may need to ask the maintainer of rear to weigh in. I'm pretty sure the configs will be very small. The logs, I can't imagine, even with debug enabled, being larger than something like /var/log/messages or /var/log/secure. If we need to put a size limit on these, I am not entirely sure how that works but I've seen when a customer doesn't have a log rotate, we tail the log to limit it's size. I don't imagine that being necessary here, but if it is required, whatever tailed size is implemented on */messages or */secure would be reasonable for applciation to any files in /var/log/rear/*.log. 

Rear can be configured to output the boot.iso and backup.tar.gz it creates to any location, and we would want to omit this from any sos collection. These should be collected separately, as they are fairly large, and the backup is not needed in any case I've seen. The default location for these is to go is under /var/lib/rear/ but of course, the customer could re-direct this elsewhere. So I see why we can't just blindly collect /var/log/rear/* because the configuration could be to put the entire back up in that space and then the sosreport ends up 4-8 GB in size.

As far as I can see, the only thing needed:

/etc/rear*                <-- all config files
/var/log/rear/*log*       <-- all log files

Please let me know if more explanation is needed.

3) Cant be there (in logs or configs) some secret information (password, SSL key,..) we shall obfuscate?

The only item I know that may need addressing is this:

/usr/share/rear/conf/default.conf
[..]
# SSH_ROOT_PASSWORD defines a root password to allow SSH connection whithout a public/private key pair
# Be aware, the password is saved in hashed MD5 format (do not forget the password after months:)
# Generate a hashed password with the following command:
#   echo "my_rescue_root_password" | openssl passwd -1 -stdin
# and copy paste the output of openssl to variable SSH_ROOT_PASSWORD='...' (mind the single quotes!)
# into config file /etc/rear/local.conf
SSH_ROOT_PASSWORD=
[..]

If they have this specified in a config file, we should change any value right of the '=' from 'password' to 'xxxxxxxx' maybe? I'm not sure what the procedure is for that. This is the only item I could find where this was a possibility. Perhaps checking with the maintainer of rear would confirm any other possibilities that I overlooked. 

4) potentially is there some command whose output can be valuable to collect as well?

Not that I am aware of with rear. All of rear's commands are actional items and none of them display content that we need on a regular basis for cases. But this may be a scenario where there may be useful output that I am unaware of. For this, I'd also recommend we check with the maintainer before fufilling this request.

Thank you again for your assistance.

EDIT: 4) potentially is there some command whose output can be valuable to collect as well?

# rear dump

This would be one of the only commands that would be useful to collect the output of. And perhaps store it at:

/sos_commands/rear/dump

Or something of that sort.

Thanks for detailed answer. Just one question pending:

> The only item I know that may need addressing is this:
>
> /usr/share/rear/conf/default.conf
> ..

This file is not supposed to be collected - just /etc/rear* and /var/log/rear/*log* are.

Shall sosreport collect also /usr/share/rear/conf (whole dir)? Or just that file?

Or is there a symlink from /etc/rear to this file (in that case, since sosreport follows symlinks when collecting data, the file will be collected)?

Thanks in advance for the answer.


> # rear dump

No problem to collect it, also under that name (I think rear_dump is better name to distinguish also the command, though that is evident from the plug-in)

Steve,
could you pls. pm_ack+ this request of a new plugin to sosreport? (for for Relax and Recover, or rear, which is a backup and recovery tool)

Blair,
could you pls. test the plugin once available in sosreport re-spin?

(it falled down the table due to the needinfo so processing now when needinfo clarified; but our QE might not grant qa_ack due to capacity, henze asking for OtherQE)

will appear in 7.6 automatically as we will rebase to upstream sos version containing the upstream PR

Errr.. regexp substitutions are completely broken. See https://github.com/sosreport/sos/issues/1370

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3144