Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1474976 - RFE - sosreport should collect more about rear, specifically /etc/rear/* & /var/log/rear/*
RFE - sosreport should collect more about rear, specifically /etc/rear/* & /v...
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sos (Show other bugs)
7.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Pavel Moravec
Miroslav Hradílek
: FutureFeature
Depends On:
Blocks: 1599701
  Show dependency treegraph
 
Reported: 2017-07-25 14:08 EDT by Blair Aitken
Modified: 2018-08-28 05:58 EDT (History)
9 users (show)

See Also:
Fixed In Version: sos-3.6-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1599701 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github sosreport/sos/pull/1121 None None None 2017-10-10 12:34 EDT
Github sosreport/sos/pull/1370 None None None 2018-07-02 06:55 EDT

  None (edit)
Description Blair Aitken 2017-07-25 14:08:10 EDT
* sosreport does not collect all information on rear configurations
* we'd like to request this enhancement be considered for future releases of sos

In the below example, you can see items that are apart of the rear configuration and logs but are not picked up by sosreport.

[root@r73 ~]# find /etc/ | grep rear
/etc/cron.d/rear
/etc/rear
/etc/rear/local.conf
/etc/rear/os.conf

[root@r73 ~]# find /var/log  | grep rear
/var/log/rear
/var/log/rear/rear-r73.log
/var/log/rear/rear-r73.log.lockless.old
/var/log/rear/rear-r73.log.lockless

[root@r73 ~]# sosreport

sosreport (version 3.3)
[....]

[root@r73 sos]# tar xvf sosreport
[root@r73 sos]# cd sosreport

[root@r73 sosreport]# find etc/ | grep rear
etc/cron.d/rear

[root@r73 sosreport]# find /var/log | grep rear
/var/log/rear
/var/log/rear/rear-r73.log
/var/log/rear/rear-r73.log.lockless.old
/var/log/rear/rear-r73.log.lockless


So /etc/rear/* needs to be collected also, please. What sort of custom files are put under this path are relevant to troubleshooting rear problems.
Comment 2 Blair Aitken 2017-07-25 15:51:09 EDT
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/*
Comment 3 Blair Aitken 2017-07-25 15:54:08 EDT
I opened this same BZ for RHEL 6 - https://bugzilla.redhat.com/show_bug.cgi?id=1474997
Comment 5 Pavel Moravec 2017-08-12 10:40:26 EDT
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?
Comment 6 Pavel Moravec 2017-08-30 07:21:16 EDT
(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.
Comment 7 Blair Aitken 2017-10-09 17:07:32 EDT
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.
Comment 8 Blair Aitken 2017-10-09 17:22:09 EDT
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.
Comment 9 Pavel Moravec 2017-10-10 09:21:40 EDT
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)
Comment 10 Pavel Moravec 2017-11-15 11:57:56 EST
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)
Comment 11 Pavel Moravec 2017-11-15 11:59:39 EST
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)
Comment 13 Pavel Moravec 2018-03-03 11:57:28 EST
will appear in 7.6 automatically as we will rebase to upstream sos version containing the upstream PR
Comment 16 Pavel Moravec 2018-07-02 06:55:43 EDT
Errr.. regexp substitutions are completely broken. See https://github.com/sosreport/sos/issues/1370

Note You need to log in before you can comment on or make changes to this bug.