sap_hana_install: Update Pseudo-Idempotency

[marcelmamula]

Changes

This pull request is created in alignment with #1213, where strict detection is added. Existing SAP HANA detection was only fairly strict, allowing to see HANA as detected just from files, which is not conclusive.

• Reworked detection
• Added internal variables that were missing (we had unsanitized HANA shared path)

Detection Approach

New approach uses detection matrix shared with SWPM:

### List of scenarios for determining next steps.
# This ensures that installation can be skipped when needed to prevent any potential issues affecting existing installations.
# Optional override is available in defaults/main.yml to execute regardless of warning.
# NOTE: SAP Host Agent can be skipped during installation using 'install_hostagent=n'.

## 'saphostctrl' is present:
# 1. SKIP - 'root' saphostctrl check finds the desired SID and instance number.
# 2. INSTALL - 'root' saphostctrl check does not find the desired SID and instance number, and no other indicators are found.
# 3. FAIL - 'root' saphostctrl check does not find the desired SID and instance number, and any other indicators are found.

# 'saphostctrl' is not present:
# 4. SKIP - 'sidadm' sapcontrol check finds the desired SID and instance number.
# 5. INSTALL - 'sidadm' sapcontrol check does not find the desired SID and instance number, and no other indicators are found.
# 6. FAIL - 'sidadm' sapcontrol check does not find the desired SID and instance number, and any other indicators are found.

# Breakdown of potential scenarios and actions:
# | saphostctrl | sapcontrol | Instance Found | Files Found | Action
# |-------------|------------|----------------|-------------|--------
# | Yes         | N/A        | Yes            | N/A         | SKIP
# | Yes         | N/A        | No             | No          | INSTALL
# | Yes         | N/A        | No             | Any         | FAIL
# | No          | Yes        | Yes            | N/A         | SKIP
# | No          | Yes        | No             | Any         | FAIL
# | No          | No         | No             | No          | INSTALL

# List of non-saphostctrl indicators for potential existing SAP HANA installation:
# A. Files found in /hana/shared/<SID> directory.
# B. Files found in /usr/sap/<SID> directory.

Tests

Tested on SLES_SAP 16.0 on SAP HANA 2.0 SPS08 installation.

[berndfinger]

@marcelmamula I found some time for testing and noticed that with fapolicyd running, some Ansible functionality is blocked. So I analyzed the problem and found that it is possible to add Ansible rules to fapolicyd, allowing the role to succeed even with fapolicyd running.

The following code changes on top of your branch achieved the goal in my tests (README.md is not yet updated as there might be follow-up discussions and changes): https://github.com/marcelmamula/community.sap_install/compare/hana-fix...berndfinger:fapolicyd-fix?expand=1 .

The proposed change can deal with an already existing fapolicyd rule file (e.g. with entries for other users) and also with such a rule file not yet present. In both cases, the changes are reverted at the end of the role (but only if the role does not fail in between - there appears to be no mechanism to run tasks in all cases except if we add all tasks to a try: block.

Or we could put all fapolicyd prepare and cleanup tasks into separate roles or as separate tasks in the playbook which executes sap_hana_install. But separate roles just for that is probably too unusual and too difficult to explain, and the latter puts too much burden on the user. Stopping fapolicyd before running the role is not a good alternative either because it opens an otherwise protected system too much.

So maybe an additional warning message related to opening fapolicyd for Ansible is an alternative.

[berndfinger]

@marcelmamula I am no longer able to reproduce the issue I reported in #1215 (comment).

But I found another issue which I would like you to fix as part of this PR, because if users assume that the role has some level of idempotency, they may not be careful enough before running the role against an existing SAP HANA system.

In such cases, on RHEL with sap_hana_install_configure_fapolicyd set to true, all the files under sap_hana_install_directories will be added to the fapolicyd trust files.

This must be avoided by default, as it may lead to compromised files to be trusted and later be executed.

Can you please modify your code so that the tasks of file post_tasks/fapolicyd.yml will only be executed for new HANA installations or for new hosts during addhosts?

[marcelmamula]

@marcelmamula I am no longer able to reproduce the issue I reported in #1215 (comment).

But I found another issue which I would like you to fix as part of this PR, because if users assume that the role has some level of idempotency, they may not be careful enough before running the role against an existing SAP HANA system.

In such cases, on RHEL with sap_hana_install_configure_fapolicyd set to true, all the files under sap_hana_install_directories will be added to the fapolicyd trust files.

This must be avoided by default, as it may lead to compromised files to be trusted and later be executed.

Can you please modify your code so that the tasks of file post_tasks/fapolicyd.yml will only be executed for new HANA installations or for new hosts during addhosts?

@berndfinger I have pushed commit with restricted fapolicyd execution as you requested.

I do believe your original issue from #1215 (comment) still exists, but maybe your host is no longer empty enough to trigger issue.

• Dedicated PR for fapolicyd issue you described (your proposal but with improvements I proposed) would still be beneficial when you get time to setup some test environment to have consistent results.

[berndfinger]

LGTM!