Hi, I made pull request https://github.com/sosreport/sos/pull/1115. Bests, Alex On 09/26/2017 04:27 PM, Pat Riehecky wrote: > These patches look neat! > > Are you interested in posting the more generic versions (/etc/os-release > and /etc/redhat-release parsing) versions to the upstream repo[1]? > > Pat > > [1] > https://github.com/sosreport/sos/pulls > > On 09/26/2017 07:10 AM, Oleg Sadov wrote: >> On Tue, Sep 26, 2017 at 2:33 PM, aleksander.baranowski >> <[log in to unmask]> wrote: >>> Hi! >>> >>> Thanks Oleg for not so obvious (for me) observation about spins. >>> >>> There is simple solution for SL7 - It's possible to use /etc/os-release. >>> Some useful information could be provided from there. /etc/os-release is >>> part of sl-release rpm. Assuming that spins have their own release rpms, >>> it should work. >>> >>> Patch could check if os-release exists and if so take >>> NAME="Scientific Linux" and && >>> HOME_URL="http://www.scientificlinux.org//" >>> There is still problem with vendor string. The simplest solution is to >>> make NAME as vendor. >> Just adding of VENODR variable may be a reasonable solution. >> >> Actually, to get the "Distributor ID" in the lsb_release shell script, >> commands like this were used: >> >> head -n 1 /etc/redhat-release | sed -e >> 's/[[:blank:]][Ll][Ii][Nn][Uu][Xx][[:blank:]]/ /g' -e >> 's/\(.*\)[[:blank:]]release.*/\1/' -e 's/[[:blank:]]//g' >> >> >>> But there is still problem with SL6. >>> >>> I will try dig more into this problem, especially how policy is chosen, >>> and if there is possibility to find some useful URL in minimal >>> installations of SL6. >>> >>> Bests, >>> Alex >>> >>> >>> >>> On 09/25/2017 06:21 PM, Oleg Sadov wrote: >>>> Actually, the main difference between RHEL and SL distributions is the >>>> ability to create a custom "site" or "spin" of SL for your own >>>> environments. It seems reasonable not to use the hardcoded name of the >>>> distribution, but set distro-related settings dynamically by using data >>>> from for ex. lsb_release utility. A more flexible solution -- >>>> possibility of creating specialized sos policies for respins >>>> (unfortunately in LSB info we don't have data about vendor_url). >>>> >>>> 2017-09-25 16:20 GMT+03:00 aleksander.baranowski >>>> <[log in to unmask] >>>> <mailto:[log in to unmask]>>: >>>> >>>> Howdy, >>>> >>>> I noticed some time ago that sosreport command gives following >>>> output. >>>> >>>> "$ sudo sosreport >>>> >>>> sosreport (version 3.4) >>>> >>>> This command will collect diagnostic and configuration >>>> information from >>>> this Red Hat Enterprise Linux system and installed applications. >>>> >>>> An archive containing the collected information will be >>>> generated in >>>> /var/tmp/sos.Nh_uEc 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/ >>>> <https://access.redhat.com/support/> >>>> " >>>> >>>> With patch that I provided it looks like: >>>> >>>> " >>>> [vagrant@builder7 ~]$ sudo sosreport >>>> >>>> sosreport (version 3.4) >>>> >>>> This command will collect diagnostic and configuration >>>> information from >>>> this Scientific Linux system and installed applications. >>>> >>>> An archive containing the collected information will be >>>> generated in >>>> /var/tmp/sos.fxOclX and may be provided to a Scientific Linux >>>> support >>>> representative. >>>> >>>> Any information provided to Scientific Linux will be treated in >>>> accordance with the published support policies at: >>>> >>>> http://scientificlinux.org/ >>>> " >>>> >>>> I'm not sure if it's such important branding issue :). >>>> >>>> Bests, >>>> Alex >>>> >>>> >