[BugFix] Debian make fix for openscap 1.0.x

[iankko]

This changeset is performing the following:

• patch 8678159 is fixing failing 'make' target when Debian/8 content when build with openscap-1.0.x (e.g with 1.0.10 on RHEL-6 or 1.0.9 on Debian's Jessie). It fixes the issues as reported / observed here:

    [1] https://jenkins.open-scap.org/job/scap-security-guide-pull-requests/332/console
    [2] #952 (comment)

It is fixing the issue on defining the oval:ssg-service_sshd_disabled:def:1 also for the case just OVAL-5.10 version is used in the final OVAL document (e.g. systemdunitdependency construct is not available yet). It is doing the check based on the following two observations:

• (observation_#1) the <runlevel> OVAL object / test elements are not implemented in OpenSCAP yet when compiled on Debian system:

    [3] https://github.com/OpenSCAP/openscap/blob/maint-1.2/src/OVAL/probes/unix/runlevel.c#L210

Therefore instead of attempting to use the <runlevel> elements we directly check content of /etc/rc*.d/ folders (/etc/rc0.d .. /etc/rcS.d) to see if there are some entries like S\d{2]ssh present. If present, we consider the service ssh not to be disabled on such a system. If not present, we consider the ssh service to be disabled on the system. This observation holds because:

root@jessie:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.2 (jessie)
Release:    8.2
Codename:   jessie

root@jessie:~# chkconfig --list ssh
ssh                       0:off  1:off  2:off  3:off  4:off  5:off  6:off

root@jessie:~# find /etc/rc*.d -name S*ssh

while in the case the ssh service is enabled, the situation looks like the following:

root@jessie:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.2 (jessie)
Release:    8.2
Codename:   jessie

root@jessie:~# chkconfig --level 0123456 ssh on

root@jessie:~# chkconfig --list ssh
ssh                       0:on   1:on   2:on   3:on   4:on   5:on   6:off

root@jessie:~# find /etc/rc*.d -name S*ssh
/etc/rc0.d/S03ssh
/etc/rc1.d/S03ssh
/etc/rc2.d/S03ssh
/etc/rc3.d/S03ssh
/etc/rc4.d/S03ssh
/etc/rc5.d/S03ssh
/etc/rc6.d/S03ssh

• (observation_#2) The proper service name on Jessie system for chkconfig case is 'ssh', rather than 'sshd' (when e.g. systemd tool is used):

root@jessie:~# chkconfig --list ssh
ssh                       0:on   1:on   2:on   3:on   4:on   5:on   6:off

vs

root@jessie:~# chkconfig --list sshd
sshd: unknown service

Therefore this first patch also enhances the shared/oval/templates/create_services_disabled.py helper script to count with the possibility the daemon name might differ from service name,

Then:

• patch 0465a4f is dropping the unused services_enabled and services_disabled CSV files for Webmin product (it can't happen Webmin would need to check status of some service),
• patch b1ed546 is fixing the form of services_disabled CSV file for the RHEVM3 product (in the first patch we enhanced create_services_disabled.py helper script to count with voluntarily provided daemon_name [for the case daemon name would differ from service name]. Therefore we need to update the RHEVM3's services_disabled.csv CSV file to properly deal with this new feature,
• patch 690060d is fixing services_disabled.csv`` form for theRHEL/7``` product,
• patch 4799d45 is dropping the unused services_enabled and services_disabled CSV files for Firefox product (it can't happen Firefox content would ever need to check some service is enabled),
• patch 0dd3052 is fixing the services_disabled.csv file for OpenStack/RHEL-OSP/7 product,
• patch 2b9f0e5 is fixing services_disabled.csv form for RHEL/5 and RHEL/6 products,
• and finally patch 2850a4c is fixing the services_disabled.csv file for Debian/8 product for the case we are using openscap capable of OVAL-5.11 to build the content.

Testing report:

The change has been manually tested on the following two systems:

• RHEL-6 (Debian/8/make now works && also make jenkins now works),
• RHEL-7 (make services are still working for all of the products touched within this changeset).

Please review.

Thank you, Jan.

[isimluk]

This is wonderful.

I'll smile a little bit longer today. Thanks!

[iankko]

Thanks for the review, Simon! Much appreciated.