Bug 2087726

The Leapp Upgrade Tool detects a SAP HANA DB by the presence of /hana/shared/*/exe/linuxx86_64/hdb/sapcontrol as seen here:

   https://github.com/oamg/leapp-repository/blob/bd85b9bc2ee2d340f8cf875c8b7eeba9aae1f391/commands/command_utils.py#L46

However, the customer who is hitting this has mentioned that the sapcontrol file on a HANA Cockpit system is in /hana/shared/*/*/exe/linuxx86_64/hdb/sapcontrol and that, for some reason, in HANA Cockpit the SAP SID (System ID) is repeated twice in the path. In the system they are trying to upgrade, the path is /hana/shared/SID/SID/exe/linuxx86_64/hdb.

I think it would be good to double check (with a test system -I don't have any-) that the System ID is, indeed, repeated twice always in a SAP HANA Cockpit system versus in a SAP HANA non-Cockpit system. I couldn't find any specific reference to that path in the documentation I've provided in the description.

As already mentioned via e-mail just checking for the presence of the sapcontrol binary is IMHO not the best approach to detect if SAP HANA or SAP HANA Cockpit are installed on a system

---
On Wed, May 11, 2022 at 2:23 PM Michal Reznik <mreznik> wrote:

    Hello Bernd,


        @Petr: Is there a way for Leapp to enforce the SAP HANA code path


    To quickly unblock them, what if they just touch the file we are checking? 

    Michal

touching the file might work, but would be a quick and very crude workaround. And this might cause issues later, since the file you are checking for ("sapcontrol") is actually one of the main binaries used for managing a SAP instance. So if the customer forgets to remove the file later on it might lead to all sorts of other issues because other tools might then want to try to use this sapcontrol file as a binary since the might "think" that there is actually a SAP HANA instance installed on the system.

And IMHO just simply checking for the existence of this one binary is not a very good method for detecting if a HANA DB is installed on a system. As the start of the path where that binary is located ("/hana/shared") implies this is actually a directory that can be shared across multiple systems, and not all of them necessarily might have a full HANA DB instance installed, which could lead to Leapp unnecessarily assuming that it needs to use the HANA code-path instead of the regular one in some situations.

Therefore I think it might be better to consider other methods for trying to detect if HANA (or other SAP products like "HANA Cockpit" for example) are installed on a system. As an example for different methods for detecting instances of HANA or other SAP products you could look at the sapnw and saphana plugins used by the "sosreport" tool:
https://github.com/sosreport/sos/blob/main/sos/report/plugins/saphana.py
https://github.com/sosreport/sos/blob/main/sos/report/plugins/sapnw.py
---

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.