Skip to Content
Technical Articles
Author's profile photo John Appleby

Building an App on SAP HANA Express – Part 1, Installing Linux

A while back, my friends at Intel were kind enough to give me a NUC. Thanks, Intel! Anyhow it was time to give it a whirl, so I got it out the cupboard and decided to put SAP HANA Express on it.

In this series of blogs, I’m going to take you through getting HANA Express running on a NUC and building an application based on a publicly available dataset. The same principals will work if you want to install HANA Express on any system.


Before you get started with SAP HANA Express, you’re going to need something which it can run on. SAP HANA Express requires 16GB RAM and 2 cores, but recommends 32GB RAM and 4 cores.

My NUC is a NUC6i7KYK which is an Intel Core i7-6770HQ. It’s 4-core, 2.6GHz, with 32GB RAM and 1TB SSD, so we are good to go from a hardware perspective!

I know we are all moving to the cloud, but an Amazon EC2 system with 32GB RAM costs $0.50 an hour to run, over $4000 a year. Yikes. Of course, you’ll turn it off when you’re not using it.

Amusingly I don’t have a USB keyboard or a HDMI screen any more, so I hooked up an Apple Magic keyboard via USB à Lightning, and plugged it into a 55” 4k TV.

I also decided to hardwire the network for the NUC. It will sit in a cupboard once I have it up and running, and having a hardwired network means the SLES will update during the installation.

Operating System

The first thing we need is an OS which SAP HANA Express supports. That’s SLES 12, or RHEL 7. I’m sure my IBM friends will kick me for this, but I’m a SLES guy, ever since RH 4.8 wiped my system in 1997. Just kidding, they’re both great products.

It does surprise me that SAP only supports commercial Linux distributions for HANA Express. It would be cool if they supported at least one non-commercial distribution.

The good news is that SLES provide a 60-day trial of SLES 12 SP3 for SAP Applications. You will need of course to register. Your SLES system may continue to work after 60 days, though you won’t be eligible for updates.

Update BIOS

It’s always a good idea to update the BIOS before you get started, and Intel made this super easy. You just need to find the download page for your product, download the EFI update onto a USB drive, boot the NUC and hit F7 to load the file. I updated from revision 41 to 58 and it took about 5 minutes to complete.

Creating a bootable USB Drive

My NUC has the ability to boot from USB, so I don’t need to be trying to burn a DVD. Using PXE to network boot looks like too much hard work for a one-off activity, so I’m going to go with the USB option.

First up, make sure you format your USB stick to MBR and MS-DOS:

I’m going to use Etcher to burn my ISO to USB.

It took about a minute to flash the 3.8GB ISO onto the USB stick. Success!

Installing SLES 12 SP3

This isn’t complicated – insert the USB stick and then boot the NUC. My NUC has F10 reserved for selecting a boot device, so I hit F10 and select the SanDisk.

From there I decided to install SLES with all the default options. I’ll probably need to change some things later that could have been configured in the installer, but since I don’t know exactly what I want right now, there doesn’t seem to be any point in second guessing the installation settings.

It takes about 10 minutes to install the OS. It’s funny, I remember watching early versions of Linux install for hours. It’s great that it installs so fast, but some of the anticipation is lost.

Basic Security

Once you’ve setup the system, the next step is to configure a ssh server and configure ssh keys. For reasons unknown to me, SUSE don’t do this by default during installation.

Run yast, and go to Security and Users –> Firewall. Add Secure Shell Server to the Allowed Services.

First, add on the server the ability to authenticate via public key in /etc/ssh/sshd_config

Then restart sshd

Create a new user for login purposes:

N.B. I did have some additional hardening here, but found that HXE would not install after this. So I’ll come back to additional Linux hardening after the HXE installation.

Now you need to go ahead and generate the ssh key on your Mac:

And then copy your ID to the server:

Now I can login without entering a password:

Go ahead and remove password authentication and root login from your system in /etc/ssh/sshd_config:

And restart sshd:

OK – now we have disabled username and password login, as well as root login via ssh, it’s only possible to login from my Mac, and only my user can su to root. This is simple security best practice/hardening.

I really wish that Linux providers would step up and provide basic hardening out the box.

Update SLES 12 SP3 to latest versions

This should have happened during the installation, which is really neat. Still, it’s worth checking that your system is completely up to date. This will avoid security or other issues down the line.

As a separate check, we can check that we are running a recent Linux kernel, so we know the updates are working.

As you can see, we are running on Linux 4.4.156, which is a recent release of the Linux 4.4 Stable branch. 4.4 is an older release of Linux, but SUSE stay within one Linux kernel release within a SP, and SLES 12 SP3 was released on Linux 4.4 in August 2017.

I also like to disable X Windows, because I will be using this as a headless system, so I prefer not to run X Windows on the NUC. Note that this does NOT prevent you from running a remote X Windows Server like XQuartz

Configuring Hosts File

This is just a local system, so I don’t have DNS setup. I therefore have to put a manual hosts file entry on my Mac:

N.B. I found that HXE requires a FQDN, i.e. It did not work with hana.local

Installing XQuartz for X Windows tunneling

I like to have a local XQuartz X Windows Server on my Mac, so I can do any GUI work needed on the Linux system.

Once you run XQuartz, it just hangs out in the background and appears to do nothing. X Servers are like that, don’t hold it against them. The only way you know it’s running is to check it’s in the task bar:

Now I can use ssh in -X mode (X Windows tunneling), and use the hostname hana. It checks to make sure, because I haven’t connected to this system before with this hostname.

Then I can test xclock, and launch it into the background. xclock successfully appears on my Mac. Yay!

Final Words

Installing SLES 12 SP3 for SAP Applications on a NUC is fairly painless if you know the steps to take. It took me some trial and error to find the right tools like Etcher, and knowing how to update the BIOS etc.

Hopefully it helps someone in their journey to get started with HANA Express.

In the next blog, I’m going to take you through downloading and installing HANA Express onto your NUC. Stay tuned.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo DJ Adams
      DJ Adams

      Nice post John, great to see you around. I like the attention to the detail of using ssh with keys, and tunneling X over ssh. After mainframes, Unix is my second love and I think the fact that tech as old as this is still relevant and still working as well as ever. Looking forward to the next posts in this series, esp on XSA.

      Author's profile photo John Astill
      John Astill

      Nice post John. I don't have the same friends at Intel, I wanted to replace my HXE VM on Windows with a 'nix based system.

      I bought a NUC. I'd previously used the NUC8I7HVK1 that comes with VR support for a demo build, which is a decent price for an 8th gen and decent video card at $799 ( ).

      For this project I wanted to go a little cheaper and also have my 15yo assemble his first PC.

      I went with the following which came in at under $900, I wanted the 32GB memory and could have gone cheaper on the storage:

      406496 INTEL INTEL NUC 7I7BNH

      748954 SAMSUNG E 1TB 970EVO NVME M.2 SSD

      077792 CRUCIAL 16GB DDR4 2400 BL SODIMM * 2

      I'd used SLES previously for HXE and my SUSE page is full of expired registrations. As this build was for home I was looking for another option. I was hoping to avoid Windows and a VM so I could use as much of the RAM as possible, and fortunately came across this post from Lucia .

      I went old school and burned a DVD and used the portable DVD drive that has sat unused for a long time.

      The initial install I used a 4K TV I used as a monitor, but my ultimate goal was headless. after the OpenSUSE install I dropped the monitor and ssh was my preferred access to the machine and the install.

      HXE installation was seemless apart from an hostname glitch I had, I needed hxehost in the /etc/hosts file.

      I also wanted to make this portable, take it anywhere with me. I added a TP Link N300 portable router and gave the NUC a fixed IP through ethernet. The N300 allows me to work with the NUC in a private network, or connect to another network if I need.

      My son has a Chromebook, ssh and a browser are all he needs to interact with the system (and no X server).

      Next up, we hope to use the HANA geospatial capabilities in a Human Geography project showing migration paths.




      Author's profile photo Lars Breddemann
      Lars Breddemann

      Good job! It was about time that someone with proper Linux admin know-how goes about writing up a step-by-step guide for this.

      More than two years after Hana in a pocket I don’t see many people using this setup, even though it allows for very flexible, fast and cloud-independent work.

      What I do see are requests for demo, training and test-systems to gain hands-on experience with the  system landscape that is HANA today. The NUC setup, attached to the local network only, is a secure and easy way to do just that. By now, this piece of hardware allows me to run multiple HANA DBs in parallel, operate several HANA based products via virtual machines and even have a bare-metal HANA2 + Cockpit + Dynamic Tiering as well as XSC ALM transports between HANA 1 and 2.

      Looking forward to seeing the next instalments of this blog series. Would be perfect if you include how you take your “local” mtar application and deploy it to “the cloud”.