“Where shall I begin, please your Majesty?” he asked.
“Begin at the beginning,” the King said gravely, “and go on till you come to the end: then stop.”
― Lewis Carroll, Alice’s Adventures in Wonderland / Through the Looking-Glass
This was the question I had in mind when starting to write this blog post. I love to code, I really do. Even after almost 15 years as ABAP developer, I love learning new things when I have time on the weekends! For these reasons at home I have a couple of MiniSAP installations on my Linux desktop:
- NPL: AS ABAP 7.52 SP04, Developer Edition
- A4H: SAP ABAP Platform 1909, Developer Edition (Currently Not Available)
The desktop has enough resources to comfortably run both installations, plus the Java SAP GUI and Eclipse. If I need to use the SAP GUI for Windows, I can either use the company laptop or my own, neither of which is powerful enough to host the MiniSAP installations directly, however.
So where’s the problem? Well, last summer the whole building where I live underwent a renovation and I switched from fully remote working (because of the pandemic) to trying to be at home as little as possible; this meant that I had to get creative, in order to connect to my server from another quieter location.
Now that I have a problem statement, here’s a quick overview of the necessary steps:
- remote start / stop of server and MiniSAP installations
- tips for DNS configuration
- tips for VPN configuration
I assume you’re able to install the MiniSAPs on your own, so kindly refer to the installation guides for the version that you wish to use.
Remote start / stop
Host
Unless you’re planning to run the server full time, with all SAP instances active, you’ll need a way to turn on and off the server and the SAP instances when needed. For power control, I’m using the WOL (wake on lan) functionality on my home router, running OpenWRT:
Alternatively, you could also use a smart socket and switch it on via an app but in any case please remember to check that the system always boots without manual intervention after power on. Also, note that the MiniSAP installations have a minimum degree of automation in my scenario but by design they do not come online automatically after starting the desktop host since I don’t always have the time to play around with them.
NPL
For isolation, this particular MiniSAP runs in a VirtualBox VM with openSUSE in it; I’ve elected to login to the host via ssh and use the following commands to start and stop the VM:
- VBoxManage startvm “AS ABAP 7.52 SP04” –type headless
- VBoxManage controlvm “AS ABAP 7.52 SP04” acpipowerbutton
If you followed the official SAP guide, you’ll need to also start and stop the MiniSAP within this VM; you could well login into this machine and issue the relevant commands but I chose to create a systemd unit as follows:
- login to the VM and stay there for all the following steps; files under the “username” homedir should be created with the normal user, files under /etc/ as well as the control commands should be done as root
- create /etc/systemd/system/npl.service with the following content:
[Unit] Description=NPL - SAP AS ABAP 7.52 SP04 After=network.target [Service] Type=simple RemainAfterExit=true ExecStart=/home/username/bin/start_npl.sh ExecStop=/home/username/bin/stop_npl.sh TimeoutStartSec=300 TimeoutStopSec=300 [Install] WantedBy=multi-user.target
- create /home/username/bin/start_npl.sh as follows:
#!/bin/bash echo '-----------------------------' echo `date` echo 'Starting NPL...' sudo su - npladm << EOF startsap EOF echo '...After Starting NPL'
- created /home/username/bin/stop_npl.sh as follows:
#!/bin/bash echo '-----------------------------' echo `date` echo 'Stopping NPL...' sudo su - npladm << EOF stopsap EOF echo '...After Stopping NPL'
- make the scripts executable with the appropriate command:
- chmod ugo+x /home/username/bin/start_npl.sh
- chmod ugo+x /home/username/bin/stop_npl.sh
- enable the unit
- systemctl enable npl
- enable persistent logging in systemd so that you have a chance to debug failed startups and shutdowns:
- edit /etc/systemd/journald.conf
- add: “Storage=persistent”
- save and quit (changes will be active at the next reboot)
- optionally, to ensure that the unit has enough time to stop the MiniSAP:
- clone /etc/pam.d/common-session into custom-su-session
- add: session [success=1 new_authtok_reqd=ok default=ignore] pam_listfile.so item=user sense=allow file=/etc/SAPUsers
- create /etc/SAPUsers with the following content:
- npladm
- sapadm
- replace calls to “common-session” with “custom-su-session” in the following files:
- /etc/pam.d/su
- /etc/pam.d/su-l
- /etc/pam.d/sudo
- /etc/pam.d/sudo-i
- reboot the VM and verify that NPL comes online: you may now use the manage commands at the beginning of the chapter to control the VM and the NPL installation in one go!
One final note regarding the unit and the scripts: they use “startsap” and “stopsap” because that’s what the demo documentation suggests but I’d like to point out that they’re listed as deprecated by the SAP documentation. You’ve been warned 🙂
A4H
This particular MiniSAP comes in the form of a docker image so you could of course use “docker start A4H” and “docker stop A4H” and it will work; alternatively, you could install Portainer which is a very nice GUI to control docker (and a whole lot more than that): for this you’ll need the community edition, portainer-ce.
One word of caution if you’re running A4H on a Linux host: be aware that the kernel version of the host matters a great deal, too new and A4H won’t start. In my case, 5.15 is highest working version.
There’s not much more to say about this until SAP releases an updated version of the docker image, sadly. And don’t pester Julie, in the meanwhile.
DNS
The scenario imagined by SAP for the MiniSAP installation is that of a single host installation, whereas the VM / docker image would live on the same machine as the (tipically Windows) GUI. Consequently, the easiest way to configure the connection is to configure the GUi as follows:
You would then edit the HOSTS file and add the following line:
127.0.0.1 vhcalnplci vhcalnplci.dummy.nodomain
The changes for A4H are similar but I wanted to avoid having to maintain local files on each client and simply have my local DNS answer queries for this bogus domain, pointing to the correct host regardless of the client and its location in the network. Also, my home network is fully dual stack but I won’t go into the IPV6 setup in this post.
Therefore, I installed unbound on the router and this is the relevant part of /etc/unbound/unbound_srv.conf, with comments below:
# Extra ACL for vpn network access-control: 10.42.0.1/24 allow # Special zone for SAP local-zone: "dummy.nodomain." static # AS ABAP 7.52SP04 (bridge) local-data: "vhcalnplci.dummy.nodomain. IN A 192.168.2.29" local-data-ptr: "192.168.2.29 vhcalnplci.dummy.nodomain" # HANA1909 local-data: "vhcalA4Hci.dummy.nodomain. IN A 192.168.2.6" local-data-ptr: "192.168.2.6 vhcalA4Hci.dummy.nodomain"
Important notes:
- the ACL must match the subnet you allocate to the VPN, else unbound with the default configuration won’t answer the queries coming from the vpn at all
- be sure to match the DNS entries above with the static lease (as I did for NPL, since the VM is bridged to the local network in my setup) or with the fixed IP address (A4H in my case)
VPN
For a remote connection to work in a secure way, you’ll need:
- a static IP address or dynamic DNS solution for your WAN connection: I can heartily recommend DuckDNS, which is totally free and well maintained; refer to their setup guide for more information on your specific client
- a VPN server that is compatible with your router, in my case when I began this setup the obvious choice was OpenVPN but that’s no longer the only option
- firewall rules allowing VPN clients to access the local network where the server lives, it’s up to you to decide how strict you want to be in this case
an open port on your router: in the case of OpenVPN, usually 1194
This is the relevant /etc/config/openvpn for my installation, I’ll point out the important bits later:
config openvpn 'casa_andrea' option port '1194' option proto 'udp' option dev 'tun' option server '10.42.0.0 255.255.255.0' option keepalive '10 120' option persist_key '1' option persist_tun '1' option user 'nobody' option status '/tmp/openvpn-status.log' option verb '3' option log '/tmp/openvpn.log' option ifconfig_pool_persist '/tmp/openvpn-ipp.txt' option fast_io 'on' option comp_lzo 'adaptive' option cipher 'AES-256-CBC' option ca '/etc/openvpn/ca.crt' option cert '/etc/openvpn/router-casa-andrea.crt' option key '/etc/openvpn/router-casa-andrea.key' option dh '/etc/openvpn/dh2048.pem' option enabled '1' option tls_auth '/etc/openvpn/ta.key' option tls_exit '1' list 'push' 'redirect-gateway def1' list 'push' 'dhcp-option DNS 10.42.0.1'
Important notes:
- the port here must match the config in the router firewall
- use the appropriate dhcp option to push the DNS server information to the connected clients: this ensures that the requests for the bogus domain are served by your own router
Wrapping it up
To summarize, I hope I have given you an overview of what is possible with the MiniSAP demos in terms of remote working and enough tips to whet your appetite for exploration. I might follow up with another blog, where I show the changes required to introduce IPV6 support in this context, if there is enough interest. Please let me know in the comments if you require more information on specific issues, if you find mistakes and so on.
