Ubuntu has issued an advisory on December 17: http://www.ubuntu.com/usn/usn-2845-1/ CVE-2014-3925 was fixed in 3.2, so it doesn't affect us. I don't believe CVE-2015-7529 is a security issue for us, due to the protected_symlinks feature in the kernel, but it is still a bug that should be fixed in Cauldron. You can include the patch in Mageia 5 SVN too. Reproducible: Steps to Reproduce:
URL: (none) => http://lwn.net/Vulnerabilities/668547/
Fedora has issued an advisory for this on December 28: https://lists.fedoraproject.org/pipermail/package-announce/2015-December/174434.html They included a ton of additional patches: http://pkgs.fedoraproject.org/cgit/sos.git/commit/?id=89b86368f897cbcfe159cda0c2dc76ad5f2f6a3b http://pkgs.fedoraproject.org/cgit/sos.git/commit/?id=bdf0a9d235b10c3653fa7b7e970799c73c373091
RedHat has issued an advisory for this today (February 16): https://rhn.redhat.com/errata/RHSA-2016-0188.html
CC: (none) => marja11Component: RPM Packages => SecurityQA Contact: (none) => security
This is just a regular bug for us, not a security issue.
Component: Security => RPM PackagesQA Contact: security => (none)
Uploaded sos 3.3 in update_testing for Mageia 5 which should fix it for good.
Status: NEW => RESOLVEDResolution: (none) => FIXED
Status: RESOLVED => REOPENEDResolution: FIXED => (none)Assignee: bruno => qa-bugs
An advisory in SVN as well (thanks to Bruno, with small enhancement from me). Reference for 3.3 update: https://github.com/sosreport/sos/releases/tag/3.3
CC: (none) => brunoVersion: Cauldron => 5
MGA5-32 on Acer D620 Xfce No installation issues Ran sosreport as root and got a 3.6 Mb tar file with logs, reports, current config files and som more as result. Seems thus OK
CC: (none) => herman.viaeneWhiteboard: (none) => MGA5-32-OK
Trying M5_64 BEFORE the update: sos-3.2-2.mga5 # sosreport sosreport (version 3.2) This command will collect diagnostic and configuration information from this Mageia system and installed applications. An archive containing the collected information will be generated in /var/tmp and may be provided to a Mageia support representative. ... No changes will be made to system configuration. Press ENTER to continue, or CTRL-C to quit. Please enter your first initial and last name [localhost.localdomain]: lsmith Please enter the case id that you are generating this report for: preupdate Setting up archive ... Setting up plugins ... Running plugins. Please wait ... Running 30/71: logs... [plugin:logs] command 'journalctl --all --this-boot --no-pager' timed out after 300s [plugin:logs] command 'journalctl --all --this-boot --no-pager -o verbose' timed out after 300s [plugin:logs] command 'journalctl --all --since="-3days"' timed out after 300s Running 71/71: xinetd... Creating compressed archive... Your sosreport has been generated and saved in: /var/tmp/sosreport-lsmith.preupdate-20170106213919.tar.xz ... although the two jornalctl timeouts seemed longer than 5m. AFTER update: sos-3.3-1.mga5 # sosreport sosreport (version 3.3) ... An archive containing the collected information will be generated in /var/tmp/sos.HN0Zb5 and may be provided to a Red Hat support representative. Any information provided to Red Hat will be treated in accordance with the published support policies at: https://access.redhat.com/support/ ... No changes will be made to system configuration. Press ENTER to continue, or CTRL-C to quit. Please enter your first initial and last name [localhost.localdomain]: lsmith Please enter the case id that you are generating this report for []: postupdate Setting up archive ... Setting up plugins ... caught exception in plugin method "monit.setup()" writing traceback to sos_logs/monit-plugin-errors.txt Running plugins. Please wait ... Running 34/80: logs... ------------------------ And there it stopped; stuck indefinitely, disc access evident. That is problem no.3. Problem no.1: Early output refers to RedHat, not Mageia as previously. Problem no.2: caught exception in plugin method "monit.setup()" Need opinion of ? Bruno please.
CC: (none) => lewyssmith
On my test with MGA5-32. I gave an <Enter> on the question "Please enter the case id......", and then a lot of patience to let it finish. In fact I let the laptop running and went to do something else, so the run might easily have exceeded 30 min.
Re-testing M5_64 real h/w AFTER update # sosreport sosreport (version 3.3) ... this Red Hat Enterprise Linux system and installed applications. ... /var/tmp/sos.L8Hx3w and may be provided to a Red Hat support ... https://access.redhat.com/support/ ... Setting up archive ... Setting up plugins ... caught exception in plugin method "monit.setup()" [does this matter?] writing traceback to sos_logs/monit-plugin-errors.txt Running plugins. Please wait ... Running 80/80: xinetd... Creating compressed archive... Your sosreport has been generated and saved in: /var/tmp/sosreport-lsmith.postupdate-20170107201457.tar.xz So this time it worked; perhaps a re-boot after the update was necessary. But I suspect we would want to change 'RedHat' to 'Mageia' (like Comment 2 before update) before pushing the update. Asking for feedback about this.
Whiteboard: MGA5-32-OK => MGA5-32-OK feedback
Whiteboard: MGA5-32-OK feedback => MGA5-32-OK feedback advisory
Lewis and Herman, the slow times are likely due to having a large partition and using the journald defaults. I use ... # grep Max /etc/systemd/journald.conf|grep -v ^# SystemMaxUse=64M RuntimeMaxUse=64M MaxRetentionSec=2month On my vb guests, both i586 and x86_64, sosreport is working both before and after the update. Lewis, my best guess is the exception was likely caused by the very large output from journalctl -a. Here it's finishing in about 10 seconds (under vb). Before oking and validating, David do you want to change the references to Red Hat back to Mageia, or go with this update as is?
CC: (none) => davidwhodgins
Seeing as this isn't a critical update anyway, if there's a regression such as the RedHat reference, it should probably be fixed first. Hopefully Bruno can address that.
Can we have a move on the 'Red Hat' question (ex Comments 7 & 9): "this Red Hat Enterprise Linux system and installed applications." "An archive containing the collected information will be generated in /var/tmp/sos.HN0Zb5 and may be provided to a Red Hat support representative. Any information provided to Red Hat will be treated in accordance with the published support policies at: https://access.redhat.com/support/" Personally I feel that we should change the wording to Mageia. Otherwise the update was good.
Installed and tested without issues. sosreport run for less than a minute and generated a 3.9MiB tar ball with the report files. Regarding, the 'Red Hat' text, I also agree that it should be changed, otherwise it will cause confusion in (some) users. System: x86_64, Plasma, nVidia (proprietary driver) $ uname -a Linux marte 4.4.78-desktop-1.mga5 #1 SMP Mon Jul 24 20:49:58 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q sos sos-3.3-1.mga5
Whiteboard: MGA5-32-OK feedback advisory => MGA5-32-OK MGA5-64-OK feedback advisoryCC: (none) => mageia
Assigning back to Bruno, the RedHat mention should be replaced by Mageia as 3.2 used to have.
Assignee: qa-bugs => brunoWhiteboard: MGA5-32-OK MGA5-64-OK feedback advisory => feedback
Keywords: (none) => feedbackWhiteboard: feedback => (none)
Out of time to update this for Mageia 5.
Status: REOPENED => RESOLVEDResolution: (none) => OLD