Skip to Content

Those who administrate systems running SAP applications on SLES may be already familiar with the configuration and tuning tool “sapconf”.
For those who don’t, now is an excellent time to do so!

A new improved version of sapconf has been released for SLES 12 SP1 onwards.
Some key improvements are:

  • one central configuration file (besides the tuned config)
  • Simplified and adjusted configuration based on current SAP notes
  • Unified sap-hana and sap-netweaver profiles to simplify deployment
  • Improved documentation

So it is worth to update or install it.

Here the minimal versions for the reworked sapconf:

4.1.12-40.47.1     (SLES 12 SP3)
4.1.12-33.15.1     (SLES 12 SP2)
4.1.12-18.24.1     (SLES 12 SP1)

In this post I will cover the installation and during the next few weeks I’ll publish further blog post about how to update and configure the new sapconf, as well as giving a few tips what you should look out for and how to achieve certain things,

To do so, I have set up a SLES 12 SP3 with the latest updates and sapconf 4.1.12-40.47.1.

NOTE: For further documentation check SAP note 1275776 and the man pages shipped with sapconf.

Let’s start!

Installation

sles12-sp3:~ # zypper install sapconf
Refreshing service 'SUSE_Linux_Enterprise_Server_12_SP3_x86_64'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 4 NEW packages are going to be installed:
  sapconf sysstat tuned uuidd

4 new packages to install.
Overall download size: 534.7 KiB. Already cached: 0 B. After the operation, additional 1.4 MiB will be used.
Continue? [y/n/...? shows all options] (y):
Retrieving package
...
(removed for brevity)
...
Additional rpm output:
Created symlink from /etc/systemd/system/sockets.target.wants/uuidd.socket to /usr/lib/systemd/system/uuidd.socket.
...
Additional rpm output:
Updating /etc/sysconfig/sapnote-1680803...
Updating /etc/sysconfig/sapconf...
Created symlink from /etc/systemd/system/multi-user.target.wants/sapconf.service to /usr/lib/systemd/system/sapconf.service.
Set the maximum number of OS tasks each user may run concurrently (UserTasksMax) to 'infinity'
With this setting your system is vulnerable to fork bomb attacks.
Please reboot the system for the UserTasksMax change to become effective

This is quite a lot of information to digest. Let me work thru it step by step and tell you the meaning.

The following 4 NEW packages are going to be installed:
 sapconf sysstat tuned uuidd

Obviously sapconf is not the only package we have got. The packages sysstat to collect sar data, tuned for system tuning (we’ll come to it later) and uuidd which is indispensable for SAP software have been installed too.

Everyone of these packages contains units for systemd (just believe me here), so let’s see what systemd has to say about the status:

 sles12-sp3:~ # systemctl status sapconf sysstat tuned uuidd
 ● sapconf.service - sapconf
 Loaded: loaded (/usr/lib/systemd/system/sapconf.service; enabled; vendor preset: enabled)
 Active: active (exited) since Fri 2018-05-11 12:02:18 CEST; 21min ago
 ...

After the installation sapconf.service has been enabled and started.

This is important!

Sapconf is meant as a minimalistic tool to prepare your system for SAP workload. Installation implies the intend to use it, so a default configuration has been applied.

These default values are sane and should be valid for most use cases. Nevertheless you should verify that all settings are suited for your scenario.
If you feel uneasy that sapconf is changing your system directly after installation, I will show in a later article, how you can prevent this.

There is one exception when sapconf is not enabled and started by default. Because sapconf relies on tuned, a set non-sapconf profile prevents this (I will cover this in more detail in the article about sapconf configuration).
This is based under the assumption that an administrator has already configured tuned on purpose and sapconf will not interfere with this.

IMPORTANT: After installation sapconf is started and enabled unless a non-sapconf tuned profile is set already!

● sysstat.service - Write information about system start to sysstat log
 Loaded: loaded (/usr/lib/systemd/system/sysstat.service; disabled; vendor preset: disabled)
 Active: active (exited) since Fri 2018-05-11 12:02:18 CEST; 21min ago
 ...

Sysstat was started, but is disabled.
The sapconf.service will start sysstat.service automatically.

Here is the magic behind:

sles12-sp3:~ # cat /usr/lib/systemd/system/sapconf.service
 [Unit]
 Description=sapconf
 ...
 Wants=sysstat.service
 ...

As long as you use sapconf, sysstat will be started and stopped with it. When you remove the sapconf package the sysstat package will remain on the system, but the service will be inactive. You have to enable the sysstat service, if you want to use it further.
It does not do any harm to do it now if you like.
If you have objections against sysstat, I will show in a later article a way to disable it.

With tuned we see the same behavior like with sysstat. It is disabled, but started by sapconf.service.

But when we check /usr/lib/systemd/system/sapconf.service, we do not see any dependency for tuned.
To find out how it works, you have to dig deeper and check the script, that is started by the sapconf.service:

sles12-sp3:~ # cat /usr/lib/systemd/system/sapconf.service
 ...
 ExecStart=/usr/sbin/sapconf start
 ...
 sles12-sp3:~ # cat /usr/sbin/sapconf
 ...
 case "$1" in
 start|restart|try-restart)
...
 if ! systemctl status tuned &> /dev/null; then
 systemctl start tuned
 fi
 ...

Mystery solved.

Now, only uuidd is left:

● uuidd.service - Daemon for generating UUIDs
 Loaded: loaded (/usr/lib/systemd/system/uuidd.service; indirect; vendor preset: disabled)
 Active: inactive (dead)

Strange. Disabled and dead! But let us go back and take a closer lock to a tiny part of the rpm output above:

...
 Additional rpm output:
 Created symlink from /etc/systemd/system/sockets.target.wants/uuidd.socket to /usr/lib/systemd/system/uuidd.socket.
...

The uuidd will be started by socket activation, so we have to check the status of the uuidd.socket and not the service:

sles12-sp3:~ # systemctl status uuidd.socket
 ● uuidd.socket - UUID daemon activation socket
 Loaded: loaded (/usr/lib/systemd/system/uuidd.socket; enabled; vendor preset: enabled)
 Active: active (listening) since Fri 2018-05-11 13:22:34 CEST; 13min ago

Ah! Enabled and active. How it should be.

Another glance at the service file of sapconf connects the dots:

sles12-sp3:~ # cat /usr/lib/systemd/system/sapconf.service
...
Requires=uuidd.socket
...

There are a few lines left:

...
Updating /etc/sysconfig/sapnote-1680803...
Updating /etc/sysconfig/sapconf...
...

Some configuration files have been updated.
I skip these for now, because I tell more about the configuration of sapconf in the next article.

...
Created symlink from /etc/systemd/system/multi-user.target.wants/sapconf.service to /usr/lib/systemd/system/sapconf.service.
...

Well, here we see that the sapconf service is enabled for the multi-user target. We have found out that already.

...
Set the maximum number of OS tasks each user may run concurrently (UserTasksMax) to 'infinity'
With this setting your system is vulnerable to fork bomb attacks.
Please reboot the system for the UserTasksMax change to become effective
...

A reboot is required!

Here a systemd limit (UserTasksMax) is set to infinity, because the system default is to low for most SAP workloads.

Those who have more knowledge about systemd might argue, that a reboot is not required. Users should log off and log on again, programs have to be restarted, and so on and so on. This might be true, but in real life the chance that something is overseen even by a skilled administrator is high. A reboot is much easier and makes sure that the changes are in effect.
Even if sapconf tries to avoid reboots, sometimes it is unavoidable.

IMPORTANT: Please always check the output of the rpm to see, if additional steps are required after installation.

Sapconf is installed and working with its defaults. I have tried to summarize the dependencies in this picture:

 

That’s it for today. The next article will cover the configuration.

 


next article: sapconf – A way to prepare a SLES system for SAP workload – Part 2


 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply