doccaz / scc-tools

A set of simple tools to interact with SUSE Customer Center (SCC)
MIT License
12 stars 1 forks source link

SLES for SAP identification issues #23

Closed doccaz closed 2 years ago

doccaz commented 2 years ago

There is a TID (https://www.suse.com/support/kb/doc/?id=000019341) that describes os-release inconsistencies that were found on SLES for SAP. Basically, different CPE string schemes were used on each release.

Coincidentally, my table of product IDs in the code matches all the flavors up until SLES for SAP 12 SP4, but according to the TID, it can still be misleading and we should not rely on just the os-release information, but also check the installed base products:

Even when the base product is SLES for SAP, the contents of the os-release file should never have been used to identify this fact.

SLES for SAP 12 (no service pack): when registered and patched during the build process, had the correct settings in os-release (all indicating SLES, not 'SLES for SAP'). Also incorrectly has two additional product files in /etc/products.d/ SLES for SAP 12 (no service pack): when not registered and patched during build, had the wrong settings in os-release for NAME, VERSION_ID, PRETTY_NAME, ID and CPR_NAME SLES for SAP 12.1: the NAME, PRETTY_NAME, ID and CPE_NAME fields were all changed (incorrectly) from a 'SLES' identifier to a 'SLES for SAP' identifier. The contents of the products.d directory correctly reflect the only two entries that should be present. SLES for SAP 12.2: os-release contents followed the same pattern as SLES for SAP 12.1 SLES for SAP 12.3: os-release contents changed the NAME, PRETTY_NAME and ID fields 'back' to SLES only identifiers. CPE_NAME was left stating 'SLES for SAP' (this was an over-sight). SLES for SAP 12.4: os-release contents followed the same pattern as SLES for SAP 12.3 SLES for SAP 15: os-release contents match the original correct syntax from SLES 12 (no service pack) with CPE_NAME also correctly reflecting SLES. The contents of the products.d directory has changed with this release to reflect the new packaging/module schema.

And indeed, my CPE strings for SLES for SAP 15 and up are incorrect. I'll need to implement an extra check for the base products (present in updates.txt).

doccaz commented 2 years ago

Got a report on a supportconfig being misidentified:

$ ./vercheck.py -d ../scc_xxxxxxxx_211207_1725 Analyzing supportconfig directory: ../scc_xxxxxxxx_211207_1725 product name = SUSE Linux Enterprise Server 15 SP1 x86_64 (id 1763, x86_64) <---- no SAP? $ ./vercheck.py -l|grep " 15 SP1" | grep _64 1766 SUSE Linux Enterprise Server for SAP Applications 15 SP1 x86_64 <--- expected 1763 SUSE Linux Enterprise Server 15 SP1 x86_64 <---- found 1764 SUSE Linux Enterprise Desktop 15 SP1 x86_64

Downloading the supportconfig to inspect.

doccaz commented 2 years ago

While the TID focuses on /etc/os-release and advises on looking into the products.d directory to find out if it is indeed a SAP system, I found out that a common characteristic is the SLES_SAP-release RPM package:

erico@suselab-erico:~/Projetos/scc-tools/tests> egrep -h '^SLES_SAP-release-([0-9]+\.[0-9]+)' */rpm.txt -r
SLES_SAP-release-12.1-1.288.x86_64            Tue Aug 30 15:42:55 2016
SLES_SAP-release-15.1-66.1.x86_64             Wed Jun  3 06:47:47 2020
SLES_SAP-release-12.4-1.131.ppc64le           Mon May  4 18:48:36 2020
SLES_SAP-release-15.2-44.1.x86_64             Fri Jul  9 13:22:11 2021

and indeed, manually searching for this package name on all releases from 12 GA to 15 SP3, I can see it is present. I'll still need to fix the CPE product table though, as according to the TID sometimes the CPE matches as well. I'll give preference to checking for the SLES_SAP-release RPM package first, then fall back to the CPE string.

doccaz commented 2 years ago

Organized my test case supportconfig files according to the type of system. I have variants for SLE11SP4, SLE15SP1, SLE15SP2, various SAP systems (12SP4, 12SP5, 15, 15SP2), various SUMA systems.

I had to create two regexes to match and extract version numbers from both the RPM package and CPE string:

regex_sap=r"SLES_SAP-release-([0-9]+)-|SLES_SAP-release-([0-9]+)\.([0-9]+)"
regex_sap_cpe=r".*sles_sap\:([0-9]+)$|.*sles_sap\:([0-9]+)\:[a-z]+?([0-9]+)"

The first one deals with the RPM package, and returns the major and minor versions (including GA versions). The second one deals with the CPE strings in my product table. Even if they're "useless" according to the TID, I set them as "sles_sap" for all SAP products, so I have something to search and match against.

doccaz commented 2 years ago

Implemented the RPM checks and validated against my testcases. All SAP systems appear to be detected fine.