Bug 1299794 - sosreport doesn't collect from /host
sosreport doesn't collect from /host
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhel-tools-docker (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Eliska Slobodova
atomic-bugs@redhat.com
Vikram Goyal
: Extras
Depends On: 1299578
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-19 04:43 EST by Marius Vollmer
Modified: 2016-11-04 05:10 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-04 05:10:41 EDT
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)

  None (edit)
Description Marius Vollmer 2016-01-19 04:43:23 EST
Description of problem:

Contrary to the documentation (https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/getting-started-with-containers/#using_the_atomic_tools_container_image), running sosreport inside the rhel-tools container seems to collect information from the container, and not from the host.

For example, the /etc/os-release file in the report archive is a copy of /etc/os-relase from inside the container, and not of /host/etc/os-release.

Version-Release number of selected component (if applicable):
Image has tag "latest" *cough* and id is fd2acbeb2b97, if that helps.
sos-3.2-35.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. atomic run rhel7/rhel-tools
2. # sosreport
3. # tar -xOaf sosreport-localhost.localdomain.localdomain-20160119092307.tar.xz sosreport-localhost.localdomain.localdomain-20160119092307/etc/os-release

Actual results:
Contents of /etc/os-release is shown

Expected results:
Contents of /host/etc/os-release is shown


Additional info:
This can be fixed by using --sysroot /host, but the docs seem to say that this isn't necessary.
Comment 3 Bryn M. Reeves 2016-01-19 11:34:06 EST
> This can be fixed by using --sysroot /host, but the docs seem to say that this 
> isn't necessary.

Right; we have a whole separate policy for Atomic (i.e. it is treated as a separate distro just like Fedora/Ubuntu/whatever). One of the things the policy should do is to detect we are running with HOST and retrieve the path from the environment.

Out of curiousity, what do you get in the boilerplate text? This should also be customized for Atomic:

"""\
This command will collect diagnostic and configuration \
information from this Red Hat Atomic Host system.

An archive containing the collected information will be \
generated in /host/var/tmp and may be provided to a Red Hat \
support representative.

Any information provided to %(vendor)s will be treated in \
accordance with the published support policies at:

    https://access.redhat.com/

The generated archive may contain data considered sensitive \
and its content should be reviewed by the originating \
organization before being passed to any third party.
%(vendor_text)s
"""

The policy retrieves HOST from the environment and then inspects $HOST/etc/redhat-release to detect if we are running in an Atomic environment.
Comment 4 Bryn M. Reeves 2016-01-19 11:37:01 EST
fwiw I think this is almost certainly the same as bug 1299578. We do some extra cosmetic tweaks on Atomic vs. the sos-in-container case for RHEL but only really to print the custom boilerplate text.

Current sos releases should support running in a privileged container on any capable distribution.

Since you mention that it works correctly with --sysroot we can rule out that the sos version in the image has been updated to some pre-7.2 version that was missing the sysroot support.

We'll need access to an environment for testing or detailed logs to make progress with this.
Comment 6 Marius Vollmer 2016-01-20 11:49:17 EST
(In reply to Bryn M. Reeves from comment #3)
> Right; we have a whole separate policy for Atomic (i.e. it is treated as a
> separate distro just like Fedora/Ubuntu/whatever). One of the things the
> policy should do is to detect we are running with HOST and retrieve the path
> from the environment.

Here is a longer transcript:

# atomic run rhel7/rhel-tools
docker run -it --name rhel-tools --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=rhel-tools -e IMAGE=rhel7/rhel-tools -v /run:/run -v /var/log:/var/log -v /etc/localtime:/etc/localtime -v /:/host rhel7/rhel-tools
docker run -it --name rhel-tools --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=rhel-tools -e IMAGE=rhel7/rhel-tools -v /run:/run -v /var/log:/var/log -v /etc/localtime:/etc/localtime -v /:/host rhel7/rhel-tools
[   24.249712] XFS (dm-4): Mounting V4 Filesystem
[   24.295819] XFS (dm-4): Ending clean mount
[   24.316424] XFS (dm-4): Unmounting Filesystem
[   24.389363] XFS (dm-4): Mounting V4 Filesystem
[   24.407531] XFS (dm-4): Ending clean mount
[   24.408810] XFS (dm-4): Unmounting Filesystem
[   24.462918] XFS (dm-4): Mounting V4 Filesystem
[   24.475934] XFS (dm-4): Ending clean mount
[root@localhost /]# env
HOSTNAME=localhost.localdomain.localdomain
HOST=/host
TERM=xterm
NAME=rhel-tools
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin
PWD=/
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
IMAGE=rhel7/rhel-tools
LESSOPEN=||/usr/bin/lesspipe.sh %s
container=docker
_=/usr/bin/env
[root@localhost /]# sosreport --batch

sosreport (version 3.2)

This command will collect diagnostic and configuration information from
this Red Hat Atomic Host system.

An archive containing the collected information will be generated in
/var/tmp 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/

The generated archive may contain data considered sensitive and its
content should be reviewed by the originating organization before being
passed to any third party.


 Setting up archive ...
 Setting up plugins ...
[plugin:pcp] /var/log/pcp/pmlogger/localhost.localdomain.localdomain not found
[plugin:sar] sar: could not list /var/log/sa
 Running plugins. Please wait ...

  Running 1/70: abrt...        
  Running 2/70: acpid...        
  Running 3/70: anaconda...        
  Running 4/70: anacron...        
  Running 5/70: block...        
  Running 6/70: boot...        
  Running 7/70: cgroups...        
  Running 8/70: cron...        
  Running 9/70: dbus...        
  Running 10/70: devicemapper...        
  Running 11/70: devices...        
  Running 12/70: dmraid...        
  Running 13/70: docker...        
  Running 14/70: etcd...        
  Running 15/70: filesys...        
  Running 16/70: gdm...        
  Running 17/70: general...        
  Running 18/70: hardware...        
  Running 19/70: hardwaretestsuite...        
  Running 20/70: i18n...        
  Running 21/70: java...        
  Running 22/70: kernel...        
[   61.059591] nr_pdflush_threads exported in /proc is scheduled for removal
  Running 23/70: krb5...        
  Running 24/70: kubernetes...        
  Running 25/70: last...        
  Running 26/70: ldap...        
  Running 27/70: libraries...        
  Running 28/70: libvirt...        
  Running 29/70: logrotate...        
  Running 30/70: logs...        
  Running 31/70: lsbrelease...        
  Running 32/70: lvm2...        
  Running 33/70: md...        
  Running 34/70: megacli...        
  Running 35/70: memory...        
  Running 36/70: mrggrid...        
  Running 37/70: mrgmessg...        
  Running 38/70: multipath...        
  Running 39/70: networking...        
  Running 40/70: nis...        
  Running 41/70: numa...        
  Running 42/70: openhpi...        
  Running 43/70: openshift...        
  Running 44/70: openssl...        
  Running 45/70: pam...        
  Running 46/70: pci...        
  Running 47/70: pcp...        
  Running 48/70: postfix...        
  Running 49/70: process...        
  Running 50/70: processor...        
  Running 51/70: puppet...        
  Running 52/70: python...        
  Running 53/70: rpm...        
  Running 54/70: sar...        
  Running 55/70: scsi...        
  Running 56/70: selinux...        
  Running 57/70: services...        
  Running 58/70: soundcard...        
  Running 59/70: ssh...        
  Running 60/70: system...        
  Running 61/70: systemd...        
  Running 62/70: systemtap...        
  Running 63/70: sysvipc...        
  Running 64/70: udev...        
  Running 65/70: usb...        
  Running 66/70: vhostmd...        
  Running 67/70: x11...        
  Running 68/70: xen...        
  Running 69/70: xfs...        
  Running 70/70: yum...        

Creating compressed archive...

Your sosreport has been generated and saved in:
  /var/tmp/sosreport-localhost.localdomain.localdomain-20160120164426.tar.xz

The checksum is: c3bc8c33064f729cf611b8b667609baf

Please send this file to your support representative.

[root@localhost /]#

-------------------------------------

Thus, $HOST is set, the banner talks about Atomic Host, but it still writes into /var/tmp.
Comment 7 Chris Evich 2016-01-20 14:14:30 EST
(In reply to Marius Vollmer from comment #6)
> Thus, $HOST is set, the banner talks about Atomic Host, but it still writes
> into /var/tmp.

Fix for bug 1299578 will address the last part as well (IIUC).
Comment 8 Bryn M. Reeves 2016-01-21 06:14:12 EST
> Fix for bug 1299578 will address the last part as well (IIUC).

Correct: the paths in the banner message, final message, and the actual path used are all manifestations of the same bug - that due to the missing "container_uuid" that these versions check for sos thinks it is running in a non-container environment and does not evaluate the HOST environment variable.

Let me know if it would be helpful to have a build with this patch included for testing.
Comment 9 Bryn M. Reeves 2016-01-21 06:15:27 EST
btw you could also work around this for testing purposed by adding '-e container_uuid=anything' to the 'docker run' command (sos does not inspect the content of the variable).
Comment 10 Marius Vollmer 2016-01-21 07:14:36 EST
(In reply to Bryn M. Reeves from comment #8)
>
> Let me know if it would be helpful to have a build with this patch included
> for testing.

Not for us, but I am happy to help with verifying the fix.
Comment 14 Chris Evich 2016-10-31 17:24:27 EDT
# atomic host status
State: idle
Deployments:
● rhel-atomic-host:rhel-atomic-host/7/x86_64/standard
       Version: 7.3 (2016-10-26 14:24:09)
        Commit: 90c9735becfff1c55c8586ae0f2c904bc0928f042cd4d016e9e0e2edd16e5e97
        OSName: rhel-atomic-host

# rpm -q sos
	 sos-3.3-4.el7.noarch

# sosreport --verbose &> /tmp/sosreport.output
# less /tmp/sosreport.output

(verified data collected from /host/...whatever... for appropriate plugins)
Comment 15 errata-xmlrpc 2016-11-04 05:10:41 EDT
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/RHBA-2016:2643

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