Adjusting installer script for SAP NetWeaver Dev Edition for distros with kernel version 5.4 or higher

Intro

UPDATE September 2022: openSUSE Leap 15.4 is using kernel version 5.14.x, so the script in this blog will be needed as a workaround, if you intend to use Leap releases 15.4 or greater!

[At the original time of writing (June 2021), openSUSE Leap (15.3) had a Linux kernel version of 5.3.x. So back then, if you would be installing SAP NetWeaver Dev Edition using the “official” SAP guides, which are based on the openSUSE Leap 15 distros with kernel versions of 5.3.x or lower) then you wouldn’t be needing the script modifications in this blog’s Appendix.]

If you are using openSUSE Leap release 15.4 or higher, then the kernel version will be at least 5.14.x, which is greater than the 5.4.x threshold i.e. you will need the script presented in the Appendix below in order to install SAP NetWeaver Dev Edition 7.52 SP04.

Similarly, most Ubuntu releases (such as 21.04 used below as example) have been on an above-threshold kernel version since at least 2021, so this blog is also relevant for such Ubuntu distros – you implement the script and the install run should work.

Please also check the following advice: whichever distro you are using, it’s good to be aware, that you will need to get the newer Sybase “Part License” from the downloads site, extract (unrar) it, rename it to “SYBASE_ASE_TD.lic”, and put it in the subdirectory of the unrarred archives at ./server/TAR/x86_64/ … also you should delete any out of date .lic files, so as not to confuse Sybase.

The downloaded rar files, when extracted, contain brief generic instructions. The more detailed SAP guides for installing on openSUSE Leap are available here and here. The SAP community has a few blogs explaining how to install the Dev Edition on Ubuntu, for example one of mine is here. This blog assumes you are reasonably familiar with the install process for SAP NetWeaver Dev Edition.

Anyway, this blog is going to consider – and solve 😀… using simple bash script modifications – two problems that you can run into, when using Ubuntu 21.04 or greater, or openSUSE Leap 15.4 or greater, as the base distro for the SAP system installation. This blog mainly shows Ubuntu (at the time of blog creation Ubuntu was the only in-scope distro), but in September 2022 I tested successfully for openSUSE Leap 15.4, so a couple of screenshots from that test run also added at the end. Here’s a screenshot of the code (don’t worry, copy-pastable script listed later):

[I suppose it could be that in future, SAP corrects its installer script based on this blog, in that case the below will only be a minor footnote in the history of computing. However it can be that SAP has no intention of fixing its installer, as it seems to want people to use the Docker image and so there have been no fixes done since around 2018 when the rar archives were last updated on Downloads site].

The current bugs that we will solve for our in-scope distros (kernel version 5.4.x or greater) are as follows:

Main script exits when using saphostexec, even though “nothing is wrong” 🤔.

Starting Sybase ASE database when the Linux kernel version is >=5.4 …doesn’t work 😱.

Solving these will be easy for you, because in the blog I give the code changes needed, and you just implement those by copy-pasting, then run the enhanced installer script, and your SAP system installation succeeds – by the way, here is what script-modified success looks like:

So, let’s get these minor bugs solved, shall we? You can either read the blog through for a longer discussion, or if you know what you are doing and just want the code, then jump to the Appendix.

Get the main installer script to keep running after executing a saphostexec command…

So when running the main installer script “install.sh”, in the function server_install() after extracting a load of files, the script then moves into the directory /tmp/hostctrl and executes the command:

./saphostexec -install || do_exit $ERR_install_saphost

Though this isn’t a tutorial on bash scripting syntax, the “||” means “OR” in the following sense: if the first part ‘./saphostexec -install’ returns without an error, we’re done here, let’s move on… OR if ‘./saphostexec -install’ fails, then do the other option i.e. exit the whole install.sh run and output an error message defined earlier in the code:

[$ERR_install_saphost]="Could not install saphostexec"

When using openSUSE Leap 15.3, this goes as we expect (no error message, main script continues). On Ubuntu 21.04 Desktop (or openSUSE Leap 15.4), this does not go as we expect: instead, what happens is that the command ‘./saphostexec -install’ returns with no error, but exits the script anyway. [So you can test this yourself, by e.g. putting an ‘echo hello’ command just after the above command for saphostexec: the echo command is not executed, and neither does the defined error message “Could not install saphostexec” appear].

Now one of the nice things about VMs is you can have snapshots, so when something doesn’t work out, you can restore the previous snapshot (in our case: just before running “install.sh”) and have a new installation run. So remember kids to start the uuidd service each time before you run the installer script. So I restored from snapshot, started uuidd, and made a copy of install.sh to work with:

sudo systemctl start uuidd
cp install.sh zimshalabimstall.sh

Then in the new script put a command just before ‘.saphostexec -install’, so as to exit the main script:

exit 0

Then if the new script is not itself executable, make it so, and run that installer script:

chmod +x zimshalabimstall.sh
sudo ./zimshalabimstall.sh

Once it exits, then as the sudoer, manually run the command that would have come next, and afterwards check what exit code we got back from that saphostexec command:

cd /tmp/hostctrl/
sudo ./saphostexec -install
echo $?

So that ran just fine, here is some of the output:

badmin@vhcalnplci:/tmp/hostctrl$ sudo ./saphostexec -install
[…]
[Thr 140600393182144] Executing : useradd -c “SAP Local Administrator” -r -g sapsys -s /bin/false sapadm
Check Installation Path …
ok
Copy Executable …
ok
Generate Profile …
ok
Install SYS-V service …
./installsapinit.sh: 206: chkconfig: not found
[WARNING] installsapinit.sh exit with status 5
-> Start /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile <-
start hostcontrol using profile /usr/sap/hostctrl/exe/host_profile
ok
[OK] SAPHostExec / SAPHostControl succesfully installed
[…]
SAPCAR: rc 0
badmin@vhcalnplci:/tmp/hostctrl$ echo $?
0
badmin@vhcalnplci:/tmp/hostctrl$

So an exit code of 0, in Linux that usually means “Everything is fine”. Now I don’t know why it should be, that in Ubuntu 21.04 or openSUSE Leap 15.4, executing this ‘saphostexec -install’ command in a bash script, causes the bash script to end its processing (if any readers know the root cause, feel free to enlighten us all). In older versions of these distros – which either coincidentally or not, had kernel versions of 5.3.x or lower, this too-early-ending issue did not occur.

However, I have an idea how we can solve this issue: by executing the ‘saphostexec -install’ command with the ‘&’ character added, so that in effect we execute the command asynchronously, as the ‘&’ character says “do the action stated, but let that happen in a new subshell/process ‘in the background’, while we continue on with our own script’s process”.

One side-effect of this tactic, is that we have no easy way of knowing how long the command takes to execute or even if it was successful, but we are in hackathon mood today, so the only “safety net” code we are going to provide is (a) a wait command in the main script processing, to give the subshell command a chance to complete, and (b) we will comment out the main script’s command that would actually delete the subdirectory /tmp/hostctrl including the saphostexec file in there – so as this is just a load of temporary files, after next reboot they will be gone anyway; while on the other hand if we deleted files that were being used by another process, that could get messy.

So either we restore the VM again (and start uuidd, and copy install.sh to a new installer file), or we manually remove the ‘exit 0’ line from current zimshalabimstall.sh; then we replace the original code:

    ./saphostexec -install || do_exit $ERR_install_saphost

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
    rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

with this code:

#Replace this line with one which tries to continue (this) main script using ‘&’:
    #./saphostexec -install || do_exit $ERR_install_saphost
    ./saphostexec -install &

#Wait for a while so that hopefully the asynchronous call ends:
    log_echo "Waiting 30 seconds for asynchronous call to /tmp/hostctrl/saphostexec -install to complete..."
    sleep 30
    log_echo "30 seconds are up, continuing the main script."

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
#Let's not remove the temporary directory, in case saphostexec command
#is still executing. So commenting out:
    # rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

You will be better off reading the next section and adding some more code before running the new installer script, but anyway, now if the script is run it can proceed without exiting on saphostexec call:

So, that is our solution for enabling the main script to continue processing while also ensuring the ‘saphostexec -install’ command is called. A bit hacky, but using a decision-workflow of one person asking himself, it got approved because hey, it works. Now let’s move on right away to the second thing, which is about Linux distros with kernel version >=5.4…

Adjust an ASE database config file in mid-flight to avoid installation hanging on ASE startup

When trying to install the SAP system with ASE database on Ubuntu 21.04 (or e.g. on Leap 15.4), then although our above trick for saphostexec gets us onto the “main install” stage, still the installation run hangs eventually and just waits:

INFO 2021-06-03 16:29:44.619 (root/sapinst) (startInstallation) [iaxxbfile.cpp:594] id=syslib.filesystem.aclSetSucceeded CIaOsFile::chmod_impl(3,0755)
Authorizations set for /sybase/NPL/startase_reset_sa.

You can wait for hours (tested 🤣), nothing more will happen, so eventually you need to Ctrl+C out of the installation run. “Now what?”… well, I rootled around a bit in that network of networks the cool kids are calling “the Internet”, and found what look like the relevant answers, from Former Member and Daniel Thrall respectively:

https://answers.sap.com/questions/13185432/docker-installation-of-as-abap-752-sp04-hangs.html

https://answers.sap.com/questions/13386863/i-updated-my-system-and-now-server-is-crahing.html?childToView=13385953

So to summarise their answers: If the Linux kernel version is greater than or equal to 5.4, ASE startup doesn’t work without a config change: and the config change to make it work again, is to include in the appropriate file the trace-flag 11889. It turns out that this config change does indeed solve the problem, so thanks to Robert and Daniel for their informative answers. For people with access to read SAP Notes, there is the related Note 3018138 about the topic, with the Resolution section as follows:

“Resolution
Upgrade ASE to a version where CR 824104 is fixed when fix becomes available

Work-around:
Enable traceflag 11889 in the RUN_<server> file. This traceflag prevents initialization of the “Simplified Native Access Plan (SNAP)” feature buring boot.”

You could always wait for SAP to fix the issue and package the new ASE in the free NetWeaver Dev Edition, but that might be a long wait; so instead of waiting, we will right away just implement the trace-flag workaround in our zimshalabimstall.sh script (where we already have the code above that keeps the script running after calling saphostexec).

By the way, to find out which Linux kernel your current distro you are working with has, here is the command:

uname -r

Result of this command for Ubuntu 21.04 Desktop:

badmin@vhcalnplci:~$ uname -r
5.11.0-18-generic
badmin@vhcalnplci:~$

So with a kernel version of 5.11.x, which is several minor versions forward from 5.4.x, we can expect that the above advice for setting the trace-flag 11889, applies to our case.

Maybe you restore the VM to the state of just before installation, starting uuidd service again. Then add in again to new script zimshalabimstall.sh the above code snippet for working around saphostexec call (which ends with commenting out deletion of /tmp/hostctrl subdirectory); anyway, immediately after that code snippet, we can also add the following new code snippet:

# Now we modify the RUN_NPL executable (executable permissions are for sybnpl user):
FILENPL=/sybase/NPL/ASE-16_0/install/RUN_NPL
if test -f "$FILENPL"; then
    echo "$FILENPL exists. Adding the -T11889 option to config in that file:"
    sed -i 's/NPL.cfg \\/NPL.cfg -T11889 \\/g' /sybase/NPL/ASE-16_0/install/RUN_NPL
    cat $FILENPL
    echo "-T11889 config option added"
    sleep 15
else
    echo "$FILENPL does not exist. Not modifying what doesn’t exist, ontologically seems ok."
fi

Then just run the new installer (if not an executable, make it so using ‘chmod’):

chmod +x zimshalabimstall.sh
sudo ./zimshalabimstall.sh

So the idea here, in the new code snippet, is to use the ‘sed’ utility to modify the file at the appropriate place, adding the trace-flag ‘-T11889’. If you look at the file /sybase/NPL/ASE-16_0/install/RUN_NPL after the ’sed’ command has run, you will find in there the modified line:

-c/sybase/NPL/ASE-16_0/NPL.cfg -T11889 \

I put the ‘sleep 15’ line into the bash script just so I could view the output of the ‘cat’ command for the modified file while the main installer script was running, to check that the code did what it was supposed to ok. In fact I even had time to take a screenshot:

At least for me, these code changes worked fine: the SAP system was installed successfully on Ubuntu 21.04 (later also worked for openSUSE Leap 15.4), running the enhanced installer script as sudo. I’m not saying my workaround code is the most elegant way to solve the two problems noted in the intro, however I can say that the workaround code got the installation procedure working again, which was nice 🏆.

Appendix – bash script code.

For reference, here are the code snippets combined into one. So in our zimshalabimstall.sh (which is a copy of install.sh) we are replacing the old code:

    ./saphostexec -install || do_exit $ERR_install_saphost

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
    rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

with the following code:

#Replace this line with one which tries to continue (this) main script using ‘&’:
    #./saphostexec -install || do_exit $ERR_install_saphost
    ./saphostexec -install &

#Wait for a while so that hopefully the asynchronous call ends:
    log_echo "Waiting 30 seconds for asynchronous call to /tmp/hostctrl/saphostexec -install to complete..."
    sleep 30
    log_echo "30 seconds are up, continuing the main script."

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
#Let's not remove the temporary directory, in case saphostexec command
#is still executing. So commenting out:
    # rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

# Now we modify the RUN_NPL executable (executable permissions are for sybnpl user):
FILENPL=/sybase/NPL/ASE-16_0/install/RUN_NPL
if test -f "$FILENPL"; then
    echo "$FILENPL exists. Adding the -T11889 option to config in that file:"
    sed -i 's/NPL.cfg \\/NPL.cfg -T11889 \\/g' /sybase/NPL/ASE-16_0/install/RUN_NPL
    cat $FILENPL
    echo "-T11889 config option added"
    sleep 15
else
    echo "$FILENPL does not exist. Not modifying what doesn’t exist, ontologically seems ok."
fi

Our smoketesting has shown that when we run (as sudo) this enhanced installer script:

chmod +x zimshalabimstall.sh
sudo ./zimshalabimstall.sh

…on Ubuntu (21.04 Desktop) with kernel >=5.4, the installation then completes successfully, due to the code changes.

[Note that there is a risk in re-using this script – if your installation run fails for another reason, then zimshalabimstall.sh script does not (when re-run) check whether the T11889 flag has already been added. So it’s an exercise for the reader to either implement such a check, or, if like me you prefer to just delete all extracted files:

sudo rm -rf /sapmnt /sybase /usr/sap

…and start again, then no need to implement any such check, since the re-run will then be acting on a “clean” (i.e. extracted and not yet modified) version of the RUN_NPL file].

UPDATE September 2022: the exact same script (both parts of which were needed i.e. the part that prevents script-exit on using saphostexec, and the part that adds the T11889 flag) was tested on openSUSE Leap 15.4… test successful:

…