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
>>>>
>>>>
>