SosreportUpdates
3325
Comment:
|
4029
|
Deletions are marked like this. | Additions are marked like this. |
Line 22: | Line 22: |
* For each test above | === sos report === |
Line 40: | Line 41: |
=== sos clean === $ sos clean <path_to_sosreport> * Make sure it generates a default_mapping file inside /etc/sos/cleaner/ (at first run) * Make sure it produces the following files: sosreport-host0-2020-08-26-eywxccq-obfuscated.tar.xz ## Tarball with sensitive information obfuscated (e.g. Ready to share with 3rd party vendor) sosreport-host0-2020-08-26-eywxccq-obfuscated.tar.xz.md5 ## Tarball accompanied md5 checksum sosreport-host0-2020-08-26-eywxccq-private_map ## Private do not share sosreport-sosfocal-2020-08-26-eywxccq-obfuscation.log ## Private do not share === sos collect === |
|
Line 42: | Line 57: |
* v4.0 [[https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1892275|(LP: #1892275)]] |
This document describes the policy for updating sosreport package in a stable supported distro, including LTS. It is also the aim of this document to provide an example for any upstream project that wants to push updates to an Ubuntu stable release.
Sosreport is an extensible, portable, support data collection tool primarily aimed at Linux distributions and other UNIX-like operating systems. This tool is mission critical for Canonical to support UA (Ubuntu Advantage) customer, partners and community. Sosreport is also widely used by other third party vendors.
- Upstream reference:
Therefore, in addition to bug fixes, new features are allowed in an update as long as the conditions outlined below are met.
Process
This is the mandatory process that the proposed packages have to pass. The following requirements must be met:
- Sosreport needs to be tested
- By a reasonable amount of Canonical Support team members with positive and detailed feedbacks (documented in an LP bug)
- On physical hardware, container and virtual machine.
- Under various UA customer similar environment and context (for LTS version only, no UA customer has such setup using non-LTS):
Cloud, Ceph, Landscape, MAAS, JuJu managed environment, ....
- On as much architecture as available to the testers.
- For commonly used parameters : -a, --all-logs, --upload, --batch, ...
sos report
Make sure sosreport generates an archive under /tmp in the form of sosreport-<HOSTNAME>-2020-06-19-ogwtrgb.tar.xz with its accompanied md5 checksum sosreport-<HOSTNAME>-2020-06-19-ogwtrgb.tar.xz.md5 (Note that the naming pattern may vary depending on the options and versions used.)
- Extract the archive
- Validate its content and make sure it is sane and accurate.
- Validate that sosreport obfuscates sensible information for plugins instructed to do so such as:
- landscape plugin, should obfuscate password(s) and secret-token from config file.
or any plugins (sos/plugins/) exercising the do_file_sub() method.
- Inspect for 0 size file(s) within the archive and use common sense if legit or not (e.g. "command is not found" can be avoided for instance)
- find /path_to_sosreport_archive/ -type f -size 0
- Look under "sos_reports" for full report.
- Look under "sos_logs" for WARN and/or ERROR
- grep -v "INFO:" sos_logs/sos.log
- Look under "sos_logs" for error files (e.g. sos_logs/systemd-plugin-errors.txt).
- Run "simple.sh": An upstream port of the Travis tests to bash. Generating various type of sosreport collections (which is part of the autopkgtest (d/test/simple.sh)) now.
sos clean
$ sos clean <path_to_sosreport>
* Make sure it generates a default_mapping file inside /etc/sos/cleaner/ (at first run)
* Make sure it produces the following files: sosreport-host0-2020-08-26-eywxccq-obfuscated.tar.xz ## Tarball with sensitive information obfuscated (e.g. Ready to share with 3rd party vendor) sosreport-host0-2020-08-26-eywxccq-obfuscated.tar.xz.md5 ## Tarball accompanied md5 checksum sosreport-host0-2020-08-26-eywxccq-private_map ## Private do not share sosreport-sosfocal-2020-08-26-eywxccq-obfuscation.log ## Private do not share
sos collect
Previous sosreport updates bugs
v4.0 (LP: #1892275)
v3.9.1 (LP: #1884293)
v3.9 (LP: #1862830)
v3.6 (LP: #1775195)
Requesting the SRU
The SRU should be requested as usual (StableReleaseUpdates) with the additional note about having the above steps being completed.
SosreportUpdates (last edited 2024-07-24 08:17:27 by arif-ali)