Make your HANA Express impersonate Cloud Foundry
From Webster: Impersonate = to assume the character or appearance of
When I help partners set up their HANA Express servers for development use, I want to configure them to impersonate the behavior of Cloud Foundry so that they get used to how the XSA generated URLs work. This approach also tends to promote a more deployment target agnostic behavior and leads to projects that deploy into both HANA XSA on-prem and Cloud Foundry environments without any code differences.
Note: In this post, I’m using the fully qualified domain name for my server’s name as hxe.local.com. You will want to replace this name throughout the example commands in this post with your choice for a server name.
The primary problem is that the HANA Express(HXE) installer assumes ports routing mode. In ports routing mode, applications provided by the XSA system get urls like this.
https://hxe.local.com:53075
URLs in Cloud Foundry(CF) look like this.
https://webide.cfapps.us10.hana.ondemand.com
While I can’t (currently) cause apps deployed into CF to use my own domain name, I can configure HXE to create URLs in a similar way by installing it with hostnames routing mode which will result in a URL like this.
https://webide.hxe.local.com
Note that while I’m making an HXE install behave more like CF, I’m not duplicating other aspects of CF like stubbing up all the same services that CF makes available. I’ll save that exercise for another blog post.
Another aspect that I can configure in HXE to make it behave more like CF is to define a trust relationship with an external Identity Provider(IdP) and use it as the source of the application’s users. By default, HXE will use the local HANA DB as a store of applications users and in fact this is how the XSA_ADMIN, XSA_DEV, and other utility users are defined. However, I try to promote the use of an external IdP and HANA SPS03 now allows you to configure your app’s xsuaa service instance to skip the normal (DB defined user) login page and redirect the user directly to external IdP’s login page seamlessly. Again, this is fodder for another blog post so I won’t cover it here.
So the main point of this post is to force the HXE installer to hostname routing mode and as a bonus show you how to use real (or at least your own) certificates so that your browser doesn’t complain constantly about your HXE server.
These instructions assume that you’ll be installing on a Linux X86 based VM and compatible OS distribution. You can use AWS, or Azure, or GCP, or your own laptop to provide this, so I won’t go into detail. I will advise you to use a 32GB image or hardware that has 32GB of RAM or larger. You may be able to get by with 16GB, but if you try to do it in 16GB, I’d advise to make sure you’ve also got 16GB of swap available and that you install things a little at a time (by breaking up the installer script) and turning things off as you go.
Also, I’m going to be assuming OpenSuSe with the Leap 42.3 repos. YMMV.
With this in mind go get the binary installer files by signing up for HXE and using the latest downloader.
Note: This post is specific to the HXE installer distributed in April, 2018 with version 2.00.030…
http://sap.com/sap-hana-express
Once you’ve got the tgz files, use SCP to move them to your VM or server.
SSH into your VM as root (or become root) and do some updating before we start installing anything.
zypper repos
zypper refresh
zypper update
zypper update
Loading repository data... Reading installed packages... Nothing to do.
shutdown -r now
cat /etc/hosts | grep hxe.local.com
127.0.0.1 localhost hxe.local.com
hxe IN A 123.45.67.123 .hxe IN CNAME hxe.local.com
zypper in dnsmasq
vi /etc/dnsmasq.conf
...
address=/.hxe.local.com/127.0.0.1
...
service dnsmasq restart
dig hxe.local.com @127.0.0.1
...
;; ANSWER SECTION:
hxe.local.com. 0 IN A 127.0.0.1
...
Verify other wildcard variations.
dig abc.hxe.local.com @127.0.0.1
vi /etc/sysconfig/network/config
...
NETCONFIG_DNS_STATIC_SERVERS="127.0.0.1"
...
Trigger a rebuild of the /etc/resolv.conf file.
netconfig update -f
cat /etc/resolv.conf
... search us-west-1.compute.internal nameserver 127.0.0.1 nameserver xxx.xx.xx.xxx
dig hxe.local.com
...;; ANSWER SECTION: hxe.local.com. 0 IN A 127.0.0.1 ...
dig abc.hxe.local.com
dig xyz.hxe.local.com
ping hxe.local.com
PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.016 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.021 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.019 ms ^C
ping abc.hxe.local.com
chkconfig dnsmasq on
Created symlink from /etc/systemd/system/multi-user.target.wants/dnsmasq.service to /usr/lib/systemd/system/dnsmasq.service.
systemctl enable dnsmasq.service
systemctl start dnsmasq.service
systemctl list-unit-files | grep dnsmasq
dnsmasq.service enabled
shutdown -r now
ping anything.hxe.local.com
cd /install
tar xzvf /var/tmp/hxe.tgz
tar xzvf /var/tmp/hxexsa.tgz
git clone https://github.com/alundesap/hxe_installer_scripts.git
mv hxe_installer_scripts/* .
rm -rf hxe_installer_scripts/
./prep4hostnames.sh
Enter fully qualified host name: hxe.local.com Enter organization name: MyHXE Enter development space name: DEV
screen
./setup_hxe.sh
instance number = 00
local host name = hxe.local.com password = <secret>
Rerun the install script. Answer the prompts with the same values you did the first time.
./setup_hxe.sh
When you get to this prompt answer yes.
Detected server instance HXE without Extended Services + apps (XSA) Do you want to install XSA? (Y/N): Y
while sleep 5; do clear; date; lsof -n -i -P | grep LISTEN | grep -v 127.0.0.1 | sort --key=9.3,9.7; done
sapwebdis 1467 hxeadm 12u IPv4 294103 0t0 TCP *:30033(LISTEN)
[37] XS Controller API available at 'https://api.hxe.local.com:30033'. Creating a connection to this URL using the XS Commandline Client should get you started.
su - hxeadm
xs api https://api.hxe.local.com:30033/ --skip-ssl-validation
xs login -u XSA_ADMIN -p <secret> -o MyHXE -s SAP
xs apps
hdbsql -u SYSTEM -p <secret> -i 00 -d SYSTEMDB "SELECT * FROM M_INIFILE_CONTENTS WHERE FILE_NAME='xscontroller.ini'"
FILE_NAME,LAYER_NAME,TENANT_NAME,HOST,SECTION,KEY,VALUE ... "xscontroller.ini","SYSTEM","","","communication","api_url","https://api.hxe.local.com:30033" "xscontroller.ini","SYSTEM","","","communication","default_domain","hxe.local.com" "xscontroller.ini","SYSTEM","","","communication","internal_https","true" "xscontroller.ini","SYSTEM","","","communication","router_https","true" "xscontroller.ini","SYSTEM","","","communication","routing_mode","hostnames" ... Press "q" to exit
hdbsql -u SYSTEM -p <secret> -i 00 -d SYSTEMDB "alter system alter configuration('xscontroller.ini','SYSTEM') SET ('communication','router_port') = '443' with reconfigure"
hdbsql -u SYSTEM -p <secret> -i 00 -d SYSTEMDB "alter system alter configuration('xscontroller.ini','SYSTEM') SET ('communication','listen_port') = '443' with reconfigure"
hdbsql -u SYSTEM -p <secret> -i 00 -d SYSTEMDB "alter system alter configuration('xscontroller.ini','SYSTEM') SET ('communication','api_url') = 'https://api.hxe.local.com:443' with reconfigure"
hdbsql -u SYSTEM -p <secret> -i 00 -d SYSTEMDB "SELECT * FROM M_INIFILE_CONTENTS WHERE FILE_NAME='xscontroller.ini'"
FILE_NAME,LAYER_NAME,TENANT_NAME,HOST,SECTION,KEY,VALUE ... "xscontroller.ini","SYSTEM","","","communication","api_url","https://api.hxe.local.com:443" "xscontroller.ini","SYSTEM","","","communication","default_domain","hxe.local.com" "xscontroller.ini","SYSTEM","","","communication","internal_https","true" "xscontroller.ini","SYSTEM","","","communication","listen_port","443" "xscontroller.ini","SYSTEM","","","communication","router_https","true" "xscontroller.ini","SYSTEM","","","communication","router_port","443" "xscontroller.ini","SYSTEM","","","communication","routing_mode","hostnames" "xscontroller.ini","SYSTEM","","","communication","single_port","true" "xscontroller.ini","SYSTEM","","","general","embedded_execution_agent","false" "xscontroller.ini","SYSTEM","","","persistence","hana_blobstore","true" Press "q" to exit
./HDB stop
exit
cd /hana/shared/HXE/xs/router/webdispatcher
cp icmbnd.new icmbnd
chown root:sapsys icmbnd
chmod 4750 icmbnd
ls -al icmbnd
-rwsr-x--- 1 root sapsys 2066240 May 4 04:03 icmbnd
shutdown -r now
while sleep 5; do clear; date; lsof -n -i -P | grep LISTEN | grep -v 127.0.0.1 | sort --key=9.3,9.7; done
sapwebdis 4764 hxeadm 14u IPv4 56676 0t0 TCP *:443 (LISTEN)
su - hxeadm
xs api https://api.hxe.local.com:443/ --cacert=/hana/shared/HXE/xs/controller_data/controller/ssl-pub/router/default.root.crt.pem
xs login -u XSA_ADMIN -p <secret> -o MyHXE -s SAP
webide STARTED 1/1 512 MB <unlimited> https://webide.us.sap-a-team.com
https://webide.hxe.local.com/


cd /root
git clone https://alunde@bitbucket.org/alunde/ca.git
cd ca
./1_gen-root-key-cert
./2_gen-intermediate-key-cert
cd intermediate
./gen-xsa-ca-ssl-cert
Enter fully qualified host name: hxe.local.com
When prompted for Common Name []: use this *.hxe.local.com
---- Country Name (2 letter code) [US]: State or Province Name [State]: Locality Name []: Organization Name [My Corp, Inc.]: Organizational Unit Name []: Common Name []:*.hxe.local.com Email Address [info@local.com]:
cd /root/ca/intermediate/
/hana/shared/HXE/xs/bin/xs api https://api.hxe.local.com:443 --skip-ssl-validation
/hana/shared/HXE/xs/bin/xs login -u XSA_ADMIN -p <secret> -s SAP
/hana/shared/HXE/xs/bin/xs set-certificate hxe.local.com -k private/hxe.local.com.key -c certs/hxe.local.com.pem
cd /hana/shared/HXE/HDB00/demo.isdev.net/sec
cp SAPSSLS.pse SAPSSLS_pse.bak
cp /root/ca/intermediate/certs/ca-chain.cert.pem .
cp /root/ca/intermediate/certs/hxe.local.com.cert.pem .
cp /root/ca/intermediate/private/hxe.local.com.key .
su - hxeadm
cd /hana/shared/HXE/HDB00/hxe.local.com/sec
sapgenpse import_p8 -p hana2sp03.pse -r ca-chain.cert.pem -c hxe.local.com.cert.pem hxe.local.com.key
cp hana2sp03.pse SAPSSLS.pse
cd /usr/sap/HXE/HDB00
./HDB stop ; ./HDB start
while sleep 5; do clear; date; lsof -n -i -P | grep LISTEN | grep -v 127.0.0.1 | sort --key=9.3,9.7; done
su - hxeadm
https://api.hxe.local.com:443/ --cacert /hana/shared/HXE/xs/controller_data/controller/ssl-pub/router/default.root.crt.pem
xs login -u XSA_ADMIN -p <secret> -s SAP
Now check the running apps.
xs apps
The second column will be either STARTED or STOPPED for each app. This is deceiving until you notice the column header is “requested state” not “actual state”. The apps that actually have started completely are those where the number of instances started is equal to the number of instances requested. So initially in the third column you’ll see a lot of 0/1’s. Keep running the xs a command until you see those with STARTED as 1/1. Again, this will take some time but keep checking back.
webide STARTED 1/1 512 MB <unlimited> https://webide.hxe.local.com
While we are waiting, we can check the info screen of the api endpoint in our browser. Browse to this URL.
https://api.hxe.local.com/v2/info
But wait a second you say! My browser is still showing that it’s not secure!
If you’re using Chrome browser and you fire up the developer tool window and select the security tab where you can inspect the details of the certificate.
These (blurred) values should match what you entered when creating the certificate authority certificate above.
But it’s still not trusted…
That’s because we haven’t yet told your system to trust certificates that we create with our own CA. To do this we must first copy the ca certificate and the intermediate certificate to our local system.
Copy the ca.cert.pem and intermediate.cert.pem files from your server to the local system. I’ll use scp, but if you don’t have a better way, you can always dump the contents of the pem files with the cat command and then just cut/paste them into text files on your local system.
scp hxe.local.com:/root/ca/certs/ca.cert.perm .
scp hxe.local.com:/root/ca/intermediate/certs/intermediate.cert.pem .
Now that you have local copies, import them into your local system’s trust store. This varies by system type but on Mac you’ll use the Keychain Access application and set the CA cert to “Always Trust” and on Windows you’ll use the Internet Options system tool’s Content tab Certificates button to import them into Trusted Root Certification Authorities and Intermediate Certification Authorities respectively. You’ll need local admin rights to do this and if your system is locked down by IT, you’ll have to get them to do it for you or you’re just plain out of luck.
Once this is done, it’s time to test. Load the api URL as before and see that the location bar has a happy green lock icon now. If it doesn’t, you may have to quit your browser and restart it as some browsers hang onto certificates for a while even when a new one is available.
You should now be able to get to the WebIDE without any issues of the browser complaining (assuming it’s had enough time to get started by now).
Note: Remember to login with the XSA_DEV user not the XSA_ADMIN user when accessing the WebIDE as the XSA_DEV user has the proper role collections assigned to it.
https://webide.hxe.local.com
Let’s also confirm that the XS-Classic web dispatcher has it’s certificate correctly set. Browse to this URL to test that it also has a happy green lock icon in the browser’s location bar.
https://hxe.local.com:4300/
You should see this screen.
Wow, this post has gotten quite long.
I hope that people find this helpful. I’ve tried to make all the step as explicit as possible so that you can cut/paste the commands with little modification. I find that I often paste the commands into a text document and do a search/replace to make life easier and less error prone.
Please let me know if you find any errors/omissions and good luck setting up your server.
-Andrew
Hi Andrew,
thank you for this detailed instructions on how to get the hostname based routing to work. For the wildcard certificates in a demo installation it might be worth looking into the Wildcard Certificate Support by Let's Encrypt that was announced in Mach this year.
Best regards
Gregor
Thanks for the tip Gregor,
I'd looked at Let's Encrypt in the past and hadn't realized that they are now issuing wildcard certs. One downside to Let's Encrypt is that the system must be online at the time the cert needs to be updated. There may be cases where this isn't possible, but is likely rare.
-Andrew
Hi Andrew!
Thank you a lot for such an unique and easy to follow installation procedure. I've tested it twice with a Mac Fusion VM and ESXi on NUC and it works as you designed. At the end my HANA 2.0 Express (2.00.031 as of now) is fully FQDN compliant with eyes candy xs app's links and easy routing with only one exception.
I'm not able to build anything on it because DI builder is not available after install. That is common issue for HANA 2.0 and wouldn't be an issue if Space enablement worked in FQDN mode. But unfortunately it is not. I'm constantly getting blank page in place of Space Enablement interface in hostnames HANA mode. First time was when I switched from ports to hostnames routing on existing VM and second after fresh binary install in FQDN mode.
In other words links like https://di-space-enablement-ui.<FQDN>/index.html are always blank while worked fine with port 51024.
Did I miss something important in the procedure or anything is required above it to start builds in Web IDE?
P.S. I have reference the same question on the community space to share with others: https://answers.sap.com/questions/572020/blank-space-enablement-page-with-fqdn.html
Thank you again for your efforts,
Valery Semichev
Valery,
Thanks for your comments, I appreciate the positive feedback.
In terms of the di-space-enablement-ui, I find that by default it isn't started. First make sure it's running. You may need to restart or restage it after switching to FQDN mode. Also, make sure you are logging in as XSA_ADMIN and not XSA_DEV (even from the same browser sometimes the session context gets mixed up). When in doubt, close the browser entirely and open it again making sure to login with XSA_ADMIN. I personally keep several different browsers around for this (Safari, Opera, etc).
In my experience it's been working once started. If you have continued issues, please reach out to me and I'll see if we can get your instance fixed.
-Andrew
Hi Andrew!
I can confirm now that <blank> di-space-enablement-ui in FQDN mode is a pure bad SSL certificate issue. Starting or even scaling the service didn't help either. When I did generate an OpenSSL CA as per your guide and installed it on my local machine, the di-space-enablement-ui site content loaded successfully and I was able to configure di-builder and run my builds from Web IDE.
Thank you again for your exhaustive tutorials and will be waiting for your next external IdP configuration for UAA services and other Cloud Foundry guides.
Valery