From builds at travis-ci.org Tue Oct 2 22:02:49 2018 From: builds at travis-ci.org (Travis CI) Date: Tue, 02 Oct 2018 22:02:49 +0000 Subject: [sos-devel] Passed: BryanQuigley/sos#96 (md5 - 00ca878) In-Reply-To: Message-ID: <5bb3eb094a48_43ff005912708124834@a516937f-f0fa-4fcb-a89f-6566f344ca18.mail> Build Update for BryanQuigley/sos ------------------------------------- Build: #96 Status: Passed Duration: 1 min and 39 secs Commit: 00ca878 (md5) Author: Bryan Quigley Message: Default to sha256 over md5 Previously sha256 only used if in a FIPS environement we now default to it over md5. >From looking at dates and availablity I believe python3 installations should all have sha256 so used that as a cutoff point. If you are running sosreport with python2 you will stay on md5. Signed-off-by: Bryan Quigley View the changeset: https://github.com/BryanQuigley/sos/compare/7b475f1da0f8^...00ca878cec9a View the full build log and details: https://travis-ci.org/BryanQuigley/sos/builds/436375105?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the BryanQuigley/sos repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=12244263&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Tue Oct 2 22:04:47 2018 From: builds at travis-ci.org (Travis CI) Date: Tue, 02 Oct 2018 22:04:47 +0000 Subject: [sos-devel] Errored: BryanQuigley/sos#97 (md5 - fdb91f5) In-Reply-To: Message-ID: <5bb3eb7f2d6d9_43fde760a6538722f5@b054cc0f-0058-4084-92ae-0584492d6e69.mail> Build Update for BryanQuigley/sos ------------------------------------- Build: #97 Status: Errored Duration: 2 mins and 10 secs Commit: fdb91f5 (md5) Author: Bryan Quigley Message: Default to sha256 over md5 Previously sha256 only used if in a FIPS environment we now default to it over md5. >From looking at dates and availability I believe python3 installations should all have sha256 so used that as a cutoff point. If you are running sosreport with python2 you will stay on md5. Signed-off-by: Bryan Quigley View the changeset: https://github.com/BryanQuigley/sos/compare/00ca878cec9a...fdb91f5febbe View the full build log and details: https://travis-ci.org/BryanQuigley/sos/builds/436375474?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the BryanQuigley/sos repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=12244263&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.equoy at canonical.com Fri Oct 19 07:19:50 2018 From: pierre.equoy at canonical.com (Pierre Equoy) Date: Fri, 19 Oct 2018 15:19:50 +0800 Subject: [sos-devel] sosreport and snap (sandboxing) issue Message-ID: Hello! I've been trying to package sosreport as a snap [1] along a small tool I've developed to submit issues in a bugtracker. I've been facing an issue with several plugins (e.g. the pci or usb ones) which generate empty log files. After some investigation [2], I discovered that the culprit might be sosreport itself given that it hardcodes paths in the $PATH environment variable [3]. For instance, I found that replacing PATH = "/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" \ + ":/usr/local/sbin:/usr/local/bin" with PATH = "$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$SNAP/usr/games:$SNAP/usr/local/games" \ + ":$SNAP/usr/local/sbin:$SNAP/usr/local/bin" in policies/debian.py [3] helps producing a better-looking report (I mean lspci and lsusb logs are available and contain relevant information). Given how snaps are sandboxed, there is currently no way of using sosreport in a snap as it is. Apart from manually patching the policies/debian.py file before packaging sosreport in my snap, is there a better way to deal with this issue? Thanks in advance for your help! [1] https://snapcraft.io/ [2] https://forum.snapcraft.io/t/report-generated-from-sosreport-within-my-snap-is-incomplete/6453 [3] https://github.com/sosreport/sos/blob/master/sos/policies/debian.py#L16 -- Pierre Equoy QA Engineer | Canonical Ltd. www.canonical.com | www.ubuntu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmr at redhat.com Fri Oct 19 14:26:31 2018 From: bmr at redhat.com (Bryn M. Reeves) Date: Fri, 19 Oct 2018 15:26:31 +0100 Subject: [sos-devel] sosreport and snap (sandboxing) issue In-Reply-To: References: Message-ID: <20181019142631.GA21678@localhost.localdomain> On Fri, Oct 19, 2018 at 03:19:50PM +0800, Pierre Equoy wrote: > Hello! > > I've been trying to package sosreport as a snap [1] along a small tool I've > developed to submit issues in a bugtracker. > > I've been facing an issue with several plugins (e.g. the pci or usb ones) > which generate empty log files. After some investigation [2], I discovered > that the culprit might be sosreport itself given that it hardcodes paths in > the $PATH environment variable [3]. > > For instance, I found that replacing > > PATH = "/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" \ > + ":/usr/local/sbin:/usr/local/bin" The value of PATH is policy controlled (as you found). This is so that distributions that have moved things around can set the appropriate path set based on version or other information (e.g. Red Hat made the "UsrMove" switch a few years ago). It (and the --sysroot support) are also used in some cases where sos runs in a container (Atomic Host). That said, I would have thought that you typically want to run the commands that are present in the host's regular bin/ paths, rather than from snap. I'm not that familiar with snap's runtime model and whether or not it uses any kind of container or other literal sandboxing. If that is the case then you may want to look at how the Atomic policy works and the use of "super-privileged" containers (that map in parts of the host file system to the container namespace where sos runs). Otherwise, if it's just a matter of using different paths then you just need to create a new e.g. UbuntuSnapPolicy that subclasses the UbuntuPolicy and set up the correct paths there. For now you will need to modify sos locally to support this, but if a new policy and other changes are submitted upstream they should be included in the next sos release. Regards, Bryn. From builds at travis-ci.org Wed Oct 31 19:43:34 2018 From: builds at travis-ci.org (Travis CI) Date: Wed, 31 Oct 2018 19:43:34 +0000 Subject: [sos-devel] Passed: BryanQuigley/sos#100 (newbranch - 77eec0b) In-Reply-To: Message-ID: <5bda05e645e4c_43fc7d26188a0265f3@a2a3affd-eb5b-49d5-acc2-39bb1a2ea9a0.mail> Build Update for BryanQuigley/sos ------------------------------------- Build: #100 Status: Passed Duration: 2 mins and 32 secs Commit: 77eec0b (newbranch) Author: Bryan Quigley Message: [kernel] Stop collecting char devices, instead move common to plugin Instead of creating char devices which is usually just /dev/null symlinked from systemd- we can just check that a couple key ones exist. Creating these character devices makes it harder to manage (delete) extracted sosreports without more permissions. I can't envision the exact attack/problem but I think it's better practice if sosreport doesn't create these special devices on collecting systems. Signed-off-by: Bryan Quigley View the changeset: https://github.com/BryanQuigley/sos/commit/77eec0b3d4d8 View the full build log and details: https://travis-ci.org/BryanQuigley/sos/builds/449028528?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the BryanQuigley/sos repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=12244263&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: