Subject: | |
From: | |
Reply To: | |
Date: | Tue, 26 Sep 2017 09:27:42 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
>>>
>>>
--
Pat Riehecky
Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org
|
|
|