Overview

In this blog post I will describe how to use custom validations in SAP Landscape Management to check if a certain SAP profile parameter is set to a given value over all SAP systems in your landscape. The whole process is documented in the SAP Landscape Management manual in chapter Configuring Custom Operations, but I want to give you a real-life example how you can leverage this feature in your SAP Landscape.

Example use-case

Let’s say you need to make sure that the profile parameter login/no_automatic_user_sapstar is enabled (= 1) for each SAP instance and you have hundreds of them in your SAP landscape. With a short script and a few configuration steps in SAP LaMa you can create a custom validation which checks this parameter on all of your systems on a regular base, so that you can take the necessary actions to disable it, if it should be enabled.

The steps to implement the validation are:

1. Create the validation script which checks the profile parameter
2. Introduce the script to the SAP host agent for each system you want to validate
3. Introduce the script to SAP LaMa by creating a “Provider Implementation Definition”
4. Create a LaMa “Custom Operation” and mark it as “Validation Operation”

Implementation

Create validation script

Let’s start at the beginning with creating the validation script which will be executed by LaMa. We create a small bash script which takes the path to the SAP instance profile as parameter. This parameter will be passed in by LaMa during the execution. The script basically calls the sappfpar command to check the current setting for the parameter login/no_automatic_user_sapstar:

#!/bin/bash

echo "=== Custom validation $0 called with parameters:"
echo "$*"

while getopts "p:" opt; do
 case $opt in
 p)
  PROFILE=$OPTARG
  ;;
 esac
done

if [[ ! -f $PROFILE ]]; then
 echo "[WARNING]:WARNING: Instance profile $PROFILE not found!"
 exit 0
fi

no_automatic_user_sapstar=$(sappfpar pf=$PROFILE login/no_automatic_user_sapstar)

if [[ $no_automatic_user_sapstar == 1 ]]; then
 echo "OK: login/no_automatic_user_sapstar is enabled."
else
 echo "[WARNING]:Possible security issue: Profile parameter login/no_automatic_user_sapstar is disabled!"
fi

In my environment I store such scripts in the /usr/local/bin/ directory. This directory is replicated to all SAP hosts in my landscape, so that I have it available on every SAP system. The script can now be executed manually by calling it as <sid>adm user:

/usr/local/bin/LamaValAutoSapstar.bash -p <PATH TO INSTANCE PROFILE>

But we don’t want to execute it manually on all systems. LaMa is supposed to do it for all of our systems. So the next step is to make it known to the SAP host agent.

Introduce validation script to SAP host agent

The configuration files for the scripts to be executed are stored in the operations.d subdirectory of the SAP host agent. On my systems I stored the config file as /usr/sap/hostctrl/exe/operations.d/LamaValAutoSapstar.conf. The configuration for our new validation script needs to look like that:

Name: LamaValAutoSapstar
Command: /usr/local/bin/LamaValAutoSapstar.bash -p $[SAPSTARTPROFILE:#required]
Description: LAMA validation for login/no_automatic_user_sapstar
Username: $[SAPSYSTEMNAME:#tolower]adm
ResultConverter: hook
Platform: UNIX

Name:

With the Name: keyword we just specify a name for our LaMa operation

Command:

Here we specify how the script needs to be called. We just put the complete path to our script in here and provide all necessary parameters. As -p parameter we need the path to the instance profile. This parameter is passed in by LaMa as $[SAPSTARTPROFILE]. #required marks this parameter as required for execution of the operation.

Description:

As the name says, this is just some descriptive sentence for this operation.

Username:

Here we specify the username under which the script is executed. As the script calls sappfpar, it needs to be run as <sid>adm user. With the given setting, LaMa passes in the SAP system SID as parameter $[SAPSYSTEMNAME]. With the modifier #tolower, the SID is translated to lowercase and afterwards the string “adm” is appended. That should give us the <sid>adm username.

ResultConverter:

ResultConverter hook means, that the output of our script is analyzed by LaMa. If LaMa sees an output line which is starting with “[WARNING]:”, the validation will raise a validation warning.

Platform:

With the platform we specify, that this operation is only valid for UNIX systems.

Note: Make sure that you distribute the .conf file to each SAP host were you want to use this operation.

For a complete documentation on what is possible here, please look into the LaMa manual chapter Configuring SAP Host Agent Registered Scripts.

Introduce validation script to LaMa (Provider Implementation Definition)

Now as the script is available and known to the SAP host agent on all of our systems, the rest is just some configuration in LaMa. To be able to use the script as custom validation, we need to create a Provider Implementation Definition first. This can be done via Automation Studio -> Design -> Provider Implementation Definitions:

As Name we can specify how LaMa should call the operation. I prefer to use the same name as defined in the .conf file of the SAP host agent. As type we use Script registered with host agent. As Registered Script we need to specify exactly the name we used in the .conf file. In my case this is the same as Name.

Make sure that you mark the required Provider Implementation Usage on the right side. As we want to validate a profile parameter setting for SAP instances, I marked Operation: Instance. With this setting we can use our script as an Instance Operation only. After saving it, we only need to finally set up the custom operation as validation.

Create custom operation for validation

To create the last bit of LaMa configuration, go to Automation Studio -> Design -> Custom Operations:

Here we add a new custom operation. As Name we can use the name from the SAP host agent .conf file again. As Definition Name we need to reference to the Provider Implementation Definition we created in the previous step. As Button Group we just keep the “default” button group, as this is not important if the operation is run as validation. To define it as validation operation, we need to place the checkmark on the right side of the screen (Validation Operation).

The button Add Default Constraints gives us some constraints which make sure that the validation is only run if the install is not in the initial state and the host is reachable. I manually added another constraint for the Instance Type. With this constraint the validation will only be run for SAP instances of type AS Instance. And that’s finally it! After saving, LaMa will run our validation script during each validation run of an application server instance. Normally this is every 24 hours or when you manually click the Validate All button on the validation tab of an instance.

Hint: For troubleshooting it might be helpful to remove the checkmark Validation Operation temporarily. When the checkmark is not set, the script can be called as normal custom operation. With this configuration it is shown under the selected button group in the Advanced Operations -> Instance Details view of your instance:

From this view you can trigger the script with the Execute button. Afterwards you will find the execution log of the script in the Log tab. This comes in very handy if your script should not work as expected. From the logs you can also see the parameter names which are used to pass information between LaMa and your custom scripts.

Viewing the results

Now that our new validation is active, we can view the validation results over our whole SAP Landscape. To get a good overview of the results, I prefer to go to the Advanced Operations view in LaMa:

With the Grouping & Filtering button, we can group by Validation – Name. Now this view can be filtered for our new validation. In the screenshot I filtered for Lama* for convenience. From this view I can read the following:

1. I have one system were the validation ran and it raised a warning, which means that I still have to disable the login/no_automatic_user_sapstar parameter.
2. I have several other systems, were the validation was not yet run. I need to schedule a validation run for them or just wait until the next automatic validation run.
3. There is one system, for wich the validation was skipped because the constraints did not match.

Result

We now have defined a custom validation which is run by the daily LaMa validation schedule. By viewing the validation warnings we can find out which SAP instances are configured incorrectly regarding the login/no_automatic_user_sapstar parameter. 

With custom validations you can validate pretty much anything in your SAP Landscape. Basically you can do everything you are able to code in a shell script. You can also define custom notifications based on the result of your custom validations and let LaMa send you an E-Mail if a Warning is raised. Of course you can also let your script send out the E-Mail directly. 😉

I think this is a very strong tool to monitor your system configurations and keep things in the standard configuration. In this example you will quickly know when somebody tinkers with the login/no_automatic_user_sapstar SAP profile parameter! The possibilities are endless!

Feedback

Feel free to use this blog post to configure your own custom validations in LaMa. If you do, I would be curious to know what you validated with a LaMa custom validation. It would be great if you would leave a comment to share your ideas on useful custom validations.