# SAP NetWeaver on Amazon Automation Amazon Systems Manager is a collection of capabilities that help you manage your applications and infrastructure running in Amazon Cloud. Systems Manager simplifies application and resource management, shortens the time to detect and resolve operational problems, and helps you manage your Amazon resources securely at scale. This chapter contains information about how to use Systems Manager to automate management of your SAP applications. ## Automation prerequisites Because SAP automation in Amazon Cloud relies on Systems Manager, you must satisfy the Systems Manager prerequisites. In addition, there are prerequisites specified in this chapter for specific tasks, such as SAP installation and operating system patching. Those prerequisites are listed in their respective sections. Before you begin, verify the following prerequisites, which apply to all of the automation tasks described in this chapter: + You must have the latest SSM agent installed on your Amazon EC2 instances. For more information, see [Manually installing SSM Agent on EC2 instances for Linux](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-manual-agent-install.html) in the * Amazon Systems Manager User Guide*. + You must satisfy the prerequisites for Systems Manager. For more information, see [Systems Manager prerequisites](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-prereqs.html) in the * Amazon Systems Manager User Guide*. **Topics** # Automated SAP installation Deploying an SAP system requires significant effort in building an infrastructure that conforms to SAP specifications. Installation, operating system configuration, and configuration of parameters based on the type of SAP workload must be repeated for the development, quality, and production landscape. You can automate this installation and configuration using Amazon Systems Manager. Automating the installation and configuration of your SAP landscape helps your team stay compliant with auditable policies related to configuration as code. In addition, it turns the SAP installation into an easily repeatable process, which makes the quality of the outcome easier to improve because you can simulate it and run it multiple times using the same source of information. The solution described here uses Systems Manager documents to install a distributed SAP landscape that contains the following: + ABAP SAP Central Services (ASCS) + Database instance + Primary Application Server (PAS) + Additional Application Servers (AAS) # Automated SAP installation architecture The example architecture shown in the diagram below uses a centralized Amazon account that stores the Amazon Systems Manager document (SSM document). The document is shared with Amazon accounts that host Amazon EC2 instances running SAP HANA workloads. ![\[The Systems Manager automation document connects to three child accounts.\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/automation-installation-architecture.png) You can use multiple Amazon accounts and Amazon organizations to arrange the accounts into a hierarchy and group them into organizational units. These organizational units can be used for things such as consolidated billing, workload isolation, and administrative isolation. You can create separate Amazon accounts for development, testing, staging, and production on a per-application basis as part of an organization. For more information, see the https://docs.aws.amazon.com/organizations/latest/userguide/orgs\$1introduction.html* Amazon Organizations">User Guide*. Systems Manager automation provides multi-account and multi-Amazon Region support that allows you to execute your own automation documents across multiple accounts from a central Amazon account. You can centralize the SSM documents into a Shared Services account or use an automation account. The automation account can be the Amazon account that runs SAP workloads or a dedicated account that only runs SSM documents. Using a centralized Amazon for automation reduces administration overhead by maintaining the SSM document and its dependencies in a single account. For more information about Shared Services, see [Infrastructure OU - Shared Services account](https://docs.amazonaws.cn/prescriptive-guidance/latest/security-reference-architecture/shared-services.html) in the * Amazon Security Reference Architecture*. In order for Systems Manager to trigger automation documents from a centralized Amazon account to the connected accounts, IAM permissions are required in the automation and child accounts. For more information, see [Running automations in multiple Amazon Regions and accounts](https://docs.amazonaws.cn/systems-manager/latest/userguide/running-automations-multiple-accounts-regions.html) in the * Amazon Systems Manager User Guide*. You can share SSM documents privately or publicly with accounts in the same Region. To privately share a document, modify the document permissions and allow specific individuals to access it based on their Amazon account ID. For more information, see [Sharing SSM documents](https://docs.amazonaws.cn/systems-manager/latest/userguide/ssm-sharing.html) in the * Amazon Systems Manager User Guide*. ## Components The installation automation workflow includes automation runbooks and SSM command documents. **Automation runbook** An automation runbook defines the actions that Systems Manager performs on your managed instances and other Amazon resources. A runbook contains one or more steps that run in sequential order. For more information, see the following documentation: + [What is an automation?](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-automation.html#what-is-an-automation) in the * Amazon Systems Manager User Guide* + [Systems Manager Automation runbook reference](https://docs.amazonaws.cn/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html) **SSM command document** If a task must be repeated multiple times on multiple hosts, you can create it as an SSM command document. These documents are usable across multiple runbooks. For more information, see [Systems Manager Command document plugin reference](https://docs.amazonaws.cn/systems-manager/latest/userguide/ssm-plugins.html) in the * Amazon Systems Manager User Guide*. You can make the SSM command document as granular as you need, based on factors such as: + Segregation of duties + Types of SAP systems that are being deployed + Complexity of SAP systems that are being deployed + Security **Workflow** As an example, each runbook can be made up of several SSM documents that perform a specific configuration. The following runbooks can be used, which are illustrated in the diagram below. + Bootstrap Amazon EC2 instances for SAP HANA database + Bootstrap Amazon EC2 instances for SAP application servers + Install SAP HANA database + Install ABAP SAP Central Services (ASCS) + Install a database instance + Install a primary application server + Install an additional application server ![\[Detailed flow chart of the SSM document.\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/automation-flow.png) # Automated SAP NetWeaver on Amazon installation prerequisites In addition to the prerequisites described in the [Automation prerequisites](sap-nw-automation.md#automation-prerequisites) section of this guide, verify the following prerequisites that are specific to automated SAP installation: + You must have an existing infrastructure deployed. The example described in this guide uses a SAP HANA database, an SAP Central Services (ASCS) instance, and a database instance. The * Amazon for SAP* blog has a [Terraform your SAP Infrastructure on Amazon](https://www.amazonaws.cn/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/) example. + SAP media files must be available. You must provide the SAP installation media files, which are obtained from SAP, in an Amazon S3 bucket. For more information, see [Make SAP application software available for Amazon Launch Wizard for SAP to deploy SAP](https://docs.amazonaws.cn/launchwizard/latest/userguide/launch-wizard-sap-software-install-details.html) in the * Amazon Launch Wizard User Guide*. If you use the sample code provided in this guide, the media files are copied to local Amazon Elastic Block Store volumes. **SAP Notes** Read the following SAP Note: + SAP Note: [2230669 - System Provisioning Using a Parameter Input File](https://me.sap.com/notes/2230669) **Additional references** Before you begin, you can also familiarize yourself with how SAP works on Amazon by reading the following documentation: + [SAP on Amazon Planning](https://docs.amazonaws.cn/sap/latest/general/overview-sap-planning.html) in the *General SAP Guides* + [Amazon EC2 instance types for SAP on Amazon](https://docs.amazonaws.cn/sap/latest/general/ec2-instance-types-sap.html) in the *General SAP Guides* + [SAP NetWeaver Environment Setup for Linux on Amazon](https://docs.amazonaws.cn/sap/latest/sap-netweaver/std-sap-netweaver-environment-setup.html) in the *SAP NetWeaver Guides* # Configuring automated SAP installation The sections below contain detailed instructions on how to configure automated SAP NetWeaver on Amazon installation. ## Customize the Systems Manager document This section shows you how to customize the Amazon Systems Manager document (SSM document) for the automated SAP installation. For more information about SSM documents, see [Amazon Systems Manager Documents](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-ssm-docs.html) in the * Amazon Systems Manager User Guide*. This section details the content that goes into the SSM document. For information about how to create the document, see [Create an SSM document (console)](https://docs.amazonaws.cn/systems-manager/latest/userguide/create-ssm-console.html) in the * Amazon Systems Manager User Guide*. As you create your SSM document, we recommend you do the following: + Use schema version 2.2. For more information, see [SSM document schema features and examples](https://docs.amazonaws.cn/systems-manager/latest/userguide/document-schemas-features.html) in the * Amazon Systems Manager User Guide*. + Use Parameter Store to easily reference parameters that you use often. For more information, see [Amazon Systems Manager Parameter Store](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-parameter-store.html) in the * Amazon Systems Manager User Guide*. **Tip** You can find sample SSM documents and parameter files in the [aws-samples/terraform-aws-sap-netweaver-on-hana](https://github.com/aws-samples/terraform-aws-sap-netweaver-on-hana/tree/master/modules/sap-deploymentscripts/scripts/module-automations) GitHub repository. ### Bootstrap Amazon EC2 instances Bootstrapping in Amazon EC2 consists of adding commands or scripts to the user data section of the instance. These commands and scripts can be executed when the instance starts. This simplifies configuration tasks. For more information, see [Run commands on your Linux instance at launch](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/user-data.html) in the *Amazon Elastic Compute Cloud User Guide for Linux Instances*. For SAP installation, bootstrapping includes several tasks, such as setting the hostname, installing operating system packages, setting operating system parameters, installing Amazon Data Provider for SAP, installing agents for monitoring, logging, and alerting, and mounting disks for the SAP HANA database instance and SAP application servers. The image below shows the steps required for the bootstrap instance SSM document. ![\[Detailed flow chart of the bootstrap instances SSM document.\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/automation-bootstrap.png) The SSM document accepts required and optional parameters. The code below is an example parameter section for bootstrapping an SAP HANA database instance or any SAP NetWeaver application server instance: ``` parameters: AutomationAssumeRole: type: String description: "(Optional) The ARN of the role that allows Automation to perform the actions on your behalf. " default: '' InstanceId: type: String description: "(Required) The instance ids to bootstrap before SAP HANA installation" default: '' HostnameTagKey: type: String description: "(Required) The tag key where the hostname is stored" default: 'Hostname' DnsPrivateZoneName: type: String description: "(Optional) DNS Zone name to specify FQDN in hosts" default: 'sapteam.net' EfsFileSystemId: type: String description: (Required) The EFS file system id for /sapmnt folder default: ‘fs-7df7edae’ MasterPassword: type: String description: '(Required) SAP NetWeaver Master Password' default: '' IniFile: type: String description: '(Required) Path to INI file' default: '/sapmnt/software/sapinstall.params' CloudWatchLogGroupName: type: String description: "(Required) Cloud Watch log group for the log output" default: '/customer/SAP/dev-setup-logs' ``` The next section of the SSM document is the `mainSteps` section. A composite SSM document is a custom document that performs a series of actions by running one or more secondary SSM documents. Composite documents promote infrastructure as code by allowing you to create a standard set of SSM documents for common tasks, such as bootstrapping software or domain-joining instances. For example, you can create a composite document with secondary SSM documents for each bootstrap item, as listed below: + Setting the hostname + Installing operating system packages for SAP HANA + Setting the operating system parameters for SAP HANA + Mounting disks for SAP HANA + Installing the Amazon Data Provider agent for SAP Composite and secondary documents can be stored in Systems Manager, private and public GitHub repositories, or Amazon S3. They can be created in JSON or YAML. For more information, see [Creating composite documents](https://docs.amazonaws.cn/systems-manager/latest/userguide/composite-docs.html) in the * Amazon Systems Manager User Guide*. The code below shows the `mainSteps` section of the SSM document with the composite and secondary documents: ``` mainSteps: - name: Prepare_logs action: aws:runCommand inputs: DocumentName: d4h-prepare-sap-installation-logs InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Set_hostname action: aws:runCommand inputs: DocumentName: d4h-set-hostname InstanceIds: - '{{ InstanceId }}' Parameters: PrivateZone: '{{ DnsPrivateZoneName }}' Hostname: '{{ Get_hostname.Hostname }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Install_Packages action: aws:runCommand inputs: DocumentName: d4h-install-sap-packages InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Set_OS_Parameters action: aws:runCommand inputs: DocumentName: d4h-set-sap-hana-parameters InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Mount_Disks action: aws:runCommand inputs: DocumentName: d4h-mount-hana-disks InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Install_Aws_Sap_Data_Provider action: aws:runCommand isCritical: false inputs: DocumentName: d4h-install-sap-aws-data-provider InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True ``` ### Install the SAP HANA database After you bootstrap the Amazon EC2 instances, you must install the SAP HANA database. For this installation, you can store the SAP HANA master password in the SSM document Parameter Store or use it as an input to the SSM document and reference it in the `passfile.xml` file. The code below is an example SSM document for an SAP HANA installation: ``` mainSteps: - action: "aws:runShellScript" name: "Run_installer" inputs: runCommand: - #!/bin/bash - HANA_MEDIA=`find /software/hana -name "DATA_UNITS"` - if [ -z "$HANA_MEDIA" ] - then - echo "Could not find the DATA_UNITS folder in /software/hana. Check if everything was downloaded successfully. Exiting..." | tee -a $SSM_LOG_FILE - exit 1 - fi - PASSFILE=$HANA_MEDIA/../passfile.xml - chmod +x $HANA_MEDIA/HDB_LCM_LINUX_X86_64/hdblcm - HOSTNAME=`(hostname)` - INSTANCE=`(instancenumber)` - SID=`echo "{{sid}}" | tr a-z A-Z` - echo "Executing installation from $HANA_MEDIA/HDB_LCM_LINUX_X86_64/hdblcm for SID $SID, instance $INSTANCE, hostname $HOSTNAME..." - cat $PASSFILE | $HANA_MEDIA/HDB_LCM_LINUX_X86_64/hdblcm --action=install --components=client,server --batch --autostart=1 -sid=$SID --hostname=$HOSTNAME --number=$INSTANCE --read_password_from_stdin=xml | tee -a $SSM_LOG_FILE - echo "`date` Installation finished. Please check logs..." | tee -a $SSM_LOG_FILE - rm $INIFILE ``` ### Install SAP Installing SAP includes ABAP SAP Central Services (ASCS), the database instance, and the primary and additional application server installation. First, you create a parameter file with the required parameters. Refer to the SAP installation guide for the parameters that are specific to your installation. The code below is an example parameter file: ``` mainSteps: - action: "aws:runShellScript" name: "Prepare_sapinstall_ini" inputs: runCommand: - #!/bin/bash - SAPINSTALL_INI_FILE={{ IniFile }} - SID=`echo "{{Sid}}" | tr a-z A-Z` - SAPSYSUID=`sapsysuid` - SIDADMUID=`sidadmuid` - SWTARGET=/sapmnt/software/ - DOMAINNAME={{ DnsPrivateZoneName }} - HOSTNAME=`hostname` - FQDN=${LHOSTNAME}.${DOMAINNAME} - sed -i "s|default_scsVirtualHostname|${HOSTNAME}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_scsInstanceNumber|00|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_ssmpass|{{ MasterPassword }}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_sid|${SID}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_fqdn|${DOMAINNAME}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_sapsysGID|${SAPSYSUID}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_AdmUID|${SIDADMUID}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_downloadBasket|${SWTARGET}|g" ${SAPINSTALL_INI_FILE} - echo '`date` Prepared the Ini File:...' | tee -a $SSM_LOG_FILE ``` The next step is to start the installation using the SAP silent, or unattended, installation mode, referring to the parameter file as in the example code below: ``` mainSteps: - action: "aws:runShellScript" name: "Execute_installation" inputs: runCommand: - #!/bin/bash - echo '`date` Starting the Installation process...' | tee -a $ - SYSTEMNUMBER=`systemnumber` - SAPAliasName=`hostname` - SWPMFILE=`find /sapmnt/software/SWPM-SUM/ -name SWPM*SAR` - chmod 775 /sapmnt/software/utils/sapcar - /sapmnt/software/utils/sapcar -xvf $SWPMFILE -R /sapmnt/software/SWPM - chmod 755 /sapmnt/software/SWPM/sapinst - cd /sapmnt/software/SWPM - ./sapinst SAPINST_INPUT_PARAMETERS_URL=/sapmnt/software/sapinstall.params SAPINST_EXECUTE_PRODUCT_ID={{ProductId}} SAPINST_USE_HOSTNAME=${SAPAliasName} SAPINST_SKIP_DIALOGS="true" SAPINST_START_GUISERVER=false | tee -a $SSM_LOG_FILE ``` You can add additional sections in the SSM document to validate the SAP installation by checking the SAP process running on the host and sending the results to the SSM document log file. The following code is an example of how to do this: ``` - action: "aws:runShellScript" name: "Validate_Installation" inputs: runCommand: - #!/bin/bash - sid=`echo {{ Sid }} | tr '[:upper:]' '[:lower:]'}` - SID=`echo {{ Sid }} | tr '[:lower:]' '[:upper:]'}` - HOSTNAME=`hostname` - SIDADM=${sid}adm - su - $SIDADM -c "stopsap $HOSTNAME" | tee -a $SSM_LOG_FILE - su - $SIDADM -c "startsap $HOSTNAME" | tee -a $SSM_LOG_FILE - sleep 15 - _SAP_UP=$(netstat -an | grep 3200 | grep tcp | grep LISTEN | wc -l ) - echo "This is the value of SAP_UP - $_SAP_UP" | tee -a $SSM_LOG_FILE - if [ "$_SAP_UP" -eq 1 ] - then - echo "$(date) __ done installing ASCS." | tee -a $SSM_LOG_FILE - exit 0 - else - echo "$(date) __ ASCS could not be installed successfully. Fix the issue and rerun the automation" | tee -a $SSM_LOG_FILE - exit 1 - fi - action: "aws:runShellScript" name: "Save_services_file" inputs: runCommand: - #!/bin/bash - grep -i sap /etc/services > /sapmnt/services - if [ -s /sapmnt/services ] - then - echo "Services file copied to sapmnt" | tee -a $SSM_LOG_FILE - exit 0 - else - echo "Services file could not be copied" | tee -a $SSM_LOG_FILE - exit 1 - fi ``` ## Tag the Systems Manager document A tag is a label that you assign to an Amazon resource. Each tag consists of a key and a value, both of which you define. For an overview of tagging Systems Manager resources, see [Tagging Systems Manager resources](https://docs.amazonaws.cn/systems-manager/latest/userguide/tagging-resources.html) in the * Amazon Systems Manager User Guide*. For detailed instructions on how to tag SSM documents, see [Tagging Systems Manager documents](https://docs.amazonaws.cn/systems-manager/latest/userguide/tagging-documents.html) in the * Amazon Systems Manager User Guide*. **Example - tags and access management** You can use tagging for a variety of purposes. For example, if you’re using Amazon Identity and Access Management (IAM), you can control which users in your account can create, edit, or delete tags, and you can implement attribute-based access control (ABAC). For more information, see [Grant permission to tag resources during creation](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/supported-iam-actions-tagging.html) and [Control access to Amazon EC2 resources using resource tags](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/control-access-with-tags.html) in the *Amazon Elastic Compute Cloud User Guide for Linux Instances*. **Example - tags and billing** You can use tags to organize your Amazon bill in a way that reflects your cost structure. To do this, sign up to get your Amazon account bill with tag key values included. For more information about setting up a cost allocation report with tags, see [Monthly cost allocation report](https://docs.amazonaws.cn/awsaccountbilling/latest/aboutv2/configurecostallocreport.html) in the * Amazon Billing User Guide*. To see the cost of your combined resources, you can organize your billing information based on resources that have the same tag key values. For example, you can tag several resources with a specific application name, and then organize your billing information to see the total cost of that application across several services. For more information, see [Using cost allocation tags](https://docs.amazonaws.cn/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) in the * Amazon Billing User Guide*. # Automated operating system patching Patch management is an ongoing activity that is a key part of the SAP software lifecycle. It is a critical step in improving security, minimizing risk, remaining compliant, and reducing unplanned downtime. You can use Amazon Systems Manager to automate system patching activities. Systems Manager can reduce the manual effort that is required to manage the SAP landscape, which saves time and IT resources. An operating system patching strategy should adhere to SAP software lifecycle best practices. Patches should be applied downstream across the landscape, from development, to test, to production. This allows the patches to be tested in less-critical systems before deploying them into production. Because patching is a repeatable process, it can be automated with Systems Manager and can be documented as a standard operating procedures (SOP). This will ensure consistent patch management across the SAP landscape. The SOP should be updated continuously for future maintenance activities. The sections below describe how to use Systems Manager to apply regular patches that are released by operating system vendors. # Automated operating system patching architecture The diagram below highlights the Amazon services that you can use to set up automated operating system patching and optional notifications on the patch status using Amazon Simple Notification Service (Amazon SNS). ![\[The patch architecture uses Systems Manager\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/automation-patch-arch.png) The topics below contain descriptions of key components of the automated operating system patching setup. Familiarize yourself with them before continuing to the prerequisites. **Topics** + [ ## Patch Manager ](#automation-os-patch-patchmanager) + [ ## Lifecycle hooks ](#auto-os-patch-lifecycle-hooks) ## Patch Manager Patch Manager is a capability of Amazon Systems Manager that automates the process of patching managed nodes with security-related and general operating system updates. You can use Patch Manager to apply patches for operating systems and applications, such as installing service packs on Microsoft Windows nodes and performing minor version upgrades on Linux nodes. Patch Manager helps to patch fleets of Amazon EC2 instances according to operating system type. This includes versions of Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), Oracle Linux, and Microsoft Windows Server that are supported by SAP on Amazon. You can patch your instances on a schedule or on-demand by creating a patching configuration. You can also scan instances to see a report of missing patches or to automatically install missing patches. Patch Manager integrates with Amazon Identity and Access Management (IAM), Amazon CloudWatch Events, and Amazon Security Hub to provide a secure patching experience that includes event notifications and the ability to audit usage. ## Lifecycle hooks Patch Manager allows you to add lifecycle hooks that enable a multi-step, custom patching process. These hooks let you perform a custom action on instances when the corresponding lifecycle event occurs. When you patch the operating system of an SAP application, lifecycle hooks can help you perform SAP-specific operations and automate the operating system patching lifecycle. You can automate the following tasks using lifecycle hooks: + Stop the SAP application and necessary database services + Initiate database or storage snapshot backup + Patch the operating system and reboot if necessary + Start the SAP application and the database after successful operating system patch update For more information about lifecycle hooks, see the following documentation: + [About the Amazon-RunPatchBaselineWithHooks SSM document](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-about-aws-runpatchbaseline.html) in the * Amazon Systems Manager User Guide* + [Orchestrating multi-step](https://www.amazonaws.cn/blogs/mt/orchestrating-custom-patch-processes-aws-systems-manager-patch-manager/) in the * Amazon Cloud Operations & Migrations Blog* # Automated operating system patching prerequisites In addition to the prerequisites described in the [Automation prerequisites](sap-nw-automation.md#automation-prerequisites) section of this guide, verify the following prerequisites that are specific to automated operating system patching: + Verify the Patch Manager prerequisites. Because the solution described here uses Amazon Systems Manager Patch Manager, you must verify that you have satisfied all of the Patch Manager prerequisites. For more information, see [Patch Manager prerequisites](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-prerequisites.html) in the * Amazon Systems Manager User Guide*. + Ensure you have a backup of your SAP system. Before you make changes to the SAP system, verify that a backup is available to support rollback in case you encounter problems. You should have the following backups: + Operating system backup – You should have an Amazon Machine Image (AMI) backup of the Amazon EC2 instance that consists of the base operating file system (`root` for Linux and `C:\` for Microsoft Windows) and the SAP application and database file systems. + Database backup – If patching will occur on the database server, ensure you have the most recent database backup. For data recovery recommendations, see [Plan for data recovery](https://docs.amazonaws.cn/wellarchitected/latest/sap-lens/design-principle-12.html) in the *SAP Lens Amazon Well-Architected Framework*. ## Supported operating systems The following operating systems are supported by SAP and Patch Manager. Check the Patch Manager prerequisites for currently supported versions of the operating systems. For more information, see [Patch Manager prerequisites](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-prerequisites.html) in the * Amazon Systems Manager User Guide*. + Oracle Linux **Note** Oracle Linux is required if you are running an Oracle database. + Red Hat Enterprise Linux (RHEL) + SUSE Linux Enterprise Server (SLES) + Microsoft Windows Server **Note** SUSE Linux and Red Hat Linux have SAP versions of the Linux operating system. SAP recommends that you use RHEL for SAP Solutions/Applications or SLES for SAP Applications to run the SAP application. Oracle Linux operating system is required for Oracle Database Server and SAP NetWeaver Application Servers with Oracle client installed. For more information, see [SAP Note 2358420 - Oracle Database Support for Amazon Web Services EC2](https://me.sap.com/notes/2358420/E) (SAP portal access required). For each of these operating systems, you can bring your own subscription to Amazon or use the Amazon Machine Images (AMIs) from the [Amazon Marketplace](https://www.amazonaws.cn/marketplace). ## SAP Notes Review the following SAP Notes. You require SAP portal access to check these references from SAP. + SAP Note: [1656099 - SAP Applications on Amazon: Supported DB/OS and Amazon EC2 products](https://me.sap.com/notes/1656099) + SAP Note: [2871484 - SAP supported variants of Red Hat Enterprise Linux](https://me.sap.com/notes/2871484) + SAP Note: [2358420 - Oracle Database Support for Amazon Web Services EC2](https://me.sap.com/notes/2358420) + SAP Note: [62988 - Service Packs for MS SQL Server](https://me.sap.com/notes/62988) + SAP Note: [2235581 - SAP HANA: Supported Operating systems](https://me.sap.com/notes/2235581) # Configuring automated operating system patching The sections below contain detailed instructions on how to configure automated operating system patching. # Configure patch baselines Patch Manager uses patch baselines, which include rules for auto-approving patches within days of their release, as well as a list of approved and rejected patches. For information about patch baselines, see [About patch baselines](https://docs.amazonaws.cn/systems-manager/latest/userguide/about-patch-baselines.html) in the * Amazon Systems Manager User Guide*. You can use predefined patch baselines or create custom patch baselines. The sections below contain instructions on how to use both. For information about patch baselines that is specific to Linux, see [How patch baseline rules work on Linux-based systems](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-how-it-works-linux-rules.html) in the * Amazon Systems Manager User Guide*. For information about the differences between Linux and Windows patching, see [Key differences between Linux and Windows patching](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-patch-differences.html) in the * Amazon Systems Manager User Guide*. If your system landscape has a combination of Windows Server and Linux operating systems, such as Windows Server for SAP application servers and Linux for database servers, you can define a baseline for each operating system type. # Predefined patch baselines Patch manager provides predefined patch baselines for each of the supported operating systems. If your patching requirement patches the predefined baseline configuration, you might be able to use a predefined patch baseline for operating system patching. Alternatively, you can create your own custom patch baselines. This gives you greater control over which patches are approved or rejected for your environment. For information about predefined patch baselines, see [Viewing Amazon predefined patch baselines (console)](https://docs.amazonaws.cn/systems-manager/latest/userguide/view-predefined-patch-baselines.html) in the * Amazon Systems Manager User Guide*. **Note** SUSE Linux Enterprise Server for SAP Applications and Red Hat Enterprise Linux for SAP Applications require custom patch baselines. The following table is a subset of the predefined patch baselines in the Patch Manager documentation. To view the full list of predefined patch baselines, see [About predefined baselines](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-patch-baselines.html#patch-manager-baselines-pre-defined) in the * Amazon Systems Manager User Guide*. The predefined patch baselines listed here are applicable to SAP. | Name | Supported operating system | Details | | --- | --- | --- | | ` Amazon-OracleLinuxDefaultPatchBaseline` | Oracle Linux | Approves all operating system patches that are classified as "Security" and that have a severity level of "Important" or "Moderate". Also approves all patches that are classified as "Bugfix" 7 days after release. Patches are auto-approved 7 days after they are released or updated.¹ | | ` Amazon-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Approves all operating system patches that are classified as "Security" and that have a severity level of "Critical" or "Important". Also approves all patches that are classified as "Bugfix". Patches are auto-approved 7 days after they are released or updated.¹ | | ` Amazon-SuseDefaultPatchBaseline` | SUSE Linux Enterprise Server (SLES) | Approves all operating system patches that are classified as "Security" and with a severity of "Critical" or "Important". Patches are auto-approved 7 days after they are released or updated.¹ | | ` Amazon-DefaultPatchBaseline` | Windows Server | Approves all Windows Server operating system patches that are classified as "CriticalUpdates" or "SecurityUpdates" and that have an MSRC severity of "Critical" or "Important". Patches are auto-approved 7 days after they are released or updated.¹ | ¹ For Amazon Linux and Amazon Linux 2, the 7-day wait before patches are auto-approved is calculated from an `Updated Date` value in `updateinfo.xml`, not a `Release Date` value. Various factors can affect the `Updated Date` value. Other operating systems handle release and update dates differently. For information to help you avoid unexpected results with auto-approval delays, see [How package release dates and update dates are calculated](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-how-it-works-release-dates.html) in the * Amazon Systems Manager User Guide*. # Custom patch baselines Unlike predefined patch baselines, custom patch baselines do not have default patch approvals and compliance levels. This gives you greater control over which patches are approved or rejected for your environment and allows you to define your custom repositories. For example, you can assign specific approval rules and compliance values. It is also possible to create a custom patch baseline by copying a predefined patch baseline and specifying the compliance values that you want to assign to patches. You can use Patch Manager to create a custom patch baseline for Linux-based managed nodes, such as Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), Oracle Linux. You can also specify patch source repositories for each of these operating systems. See the sections below for additional information about patch sources for each. For instructions on how to create a custom patch baseline for Linux and Windows, see the following documentation: + [Creating a custom patch baseline (Linux)](https://docs.amazonaws.cn/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * Amazon Systems Manager User Guide* + [Creating a custom patch baseline (Windows)](https://docs.amazonaws.cn/systems-manager/latest/userguide/create-baseline-console-windows.html) in the * Amazon Systems Manager User Guide* ## Patch sources When you use the default repositories that are configured on a managed node for patching operations, Patch Manager scans for security-related patches or installs them. This is the default behavior for Patch Manager. On Linux systems, you can also use Patch Manager to install patches that aren’t related to security or that are in a different source repository than the default repository that is configured on the managed node. In the procedure to create a custom patch baseline, there is an option to specify alternative patch source repositories if you are not using the default repository configuration. In each custom patch baseline, you can specify patch source configurations for up to 20 versions of a supported Linux operating system. For more information about alternative patch sources, see [How to specify an alternative patch source repository (Linux)](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-how-it-works-alt-source-repository.html) in the * Amazon Systems Manager User Guide*. **Note** If you specify alternative repositories, you must also specify the default repositories as part of the alternative patch source configuration if you want those updates to be applied. The sections below contain information about how to obtain patch source details for SLES for SAP Applications, RHEL for SAP Applications, and Oracle Linux. You can use this information to specify a patch source when you create a custom patch baseline. ## Patch sources for SLES for SAP Applications You can use one of the following patch repositories for SUSE Linux Enterprise Server (SLES) for SAP Applications: + SUSE public cloud update infrastructure + Private repository For information about how to use a private patch repository, see [Private and local repositories](auto-os-patch-private-repo.md) in this guide. The public cloud update infrastructure is a global network of update servers maintained by SUSE on Amazon Cloud that provides low-latency access to patches from on-demand instances. Customers that use SUSE on-demand instances in Amazon automatically connect to the public cloud update infrastructure on boot. You can view the SUSE patch source server details in the `/etc/hosts` directory. You can connect to the public cloud update infrastructure through an internet gateway in a public subnet, NAT gateway in a private subnet, or through a local data center. To see the repository list, run the command `zypper ls`. By default, all repositories are considered for patching. If you want to only patch certain repositories or if you are using multiple patch sources for repositories, you must explicitly add patch sources based on repository configuration. Complete the following steps to identify the patch source for the repository that you would like to use for patching: 1. Navigate to the following directory to view the repository files: ``` /etc/zypp/repos.d ``` 1. Save the name and configuration for each repository file. For example, you might save the following: + Name – `SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64:SLE-Product-SLES_SAPXX-SPX-Updates` + Configuration – ``` name=SLE-Product-SLES_SAPXX-SPX-Updates enabled=1 autorefresh=1 baseurl=plugin:/susecloud?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64&path=/repo/SUSE/Updates/SLE-Product-SLES_SAP/XX-SPX/x86_64/update/ service=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64 ``` 1. Enter this information when you create the custom patch baseline in the **Patch sources** section of **Patch Manager**. For the full list of steps, see [Creating a custom patch baseline (Linux)](https://docs.amazonaws.cn/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * Amazon Systems Manager User Guide*. 1. If you add a patch source for any repository, you must add patch sources for all the repositories that you would like to patch, including the default repositories. **Important** Before you deploy the patch, you must accept the license agreement in the `zypper.conf` configuration file. You can find the file in the following directory: ``` /etc/zypp/zypper.conf ``` To accept the license agreement, uncomment the license agreement property and save it as: ``` autoAgreeWithLicenses = yes ``` ## Patch sources for RHEL for SAP Applications You can use one of the following patch repositories for Red Hat Enterprise Linux (RHEL) for SAP Applications: + Red Hat update infrastructure + Local repository For information about how to use a private patch repository, see [Private and local repositories](auto-os-patch-private-repo.md) in this guide. Red Hat update infrastructure is a global network of update servers maintained by Red Hat on Amazon Cloud that provides low-latency access to patches from on-demand instances. Customers that use Red Hat on-demand instances in Amazon automatically connect to the Red Hat update infrastructure on boot. The RHEL repositories are stored in the following location: ``` /etc/yum.repos.d/ ``` Complete the following steps to identify the patch source for the repository that you would like to use for patching: 1. Run the following command to view the default, enabled repositories: ``` cat /etc/yum.repos.d/* | grep -B 4 -A 6 "enabled=1" ``` This command returns four lines before and six lines after each repository that is enabled. For example, the command might return something like this: ``` [rhui-client-config-server-8-sap-bundle] name=Red Hat Update Infrastructure 3 Client Configuration for SAP Bundle mirrorlist=https://rhui3.REGION.ce.redhat.com/pulp/mirror/protected/rhui-client- config/rhel/server/8/$basearch/sap-bundle enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify=1 sslcacert=/etc/pki/rhui/cdn.redhat.com-chain.crt sslclientcertexample=/etc/pki/rhui/product/rhui-client-config-server-8-sap-bundle.crt sslclientkeyexample=/etc/pki/rhui/rhui-client-config-server-8-sap-bundle.key ``` 1. Save the name and configuration for each repository file. In this example, you would save the following: + Name – `rhui-client-config-server-8-sap-bundle` + Configuration ``` name=Red Hat Update Infrastructure 3 Client Configuration for SAP Bundle mirrorlist=https://rhui3.REGION.ce.redhat.com/pulp/mirror/protected/rhui-client- config/rhel/server/8/$basearch/sap-bundle enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify=1 sslcacertexample=/etc/pki/rhui/cdn.redhat.com-chain.crt sslclientcertexample=/etc/pki/rhui/product/rhui-client-config-server-8-sap-bundle.crt ``` 1. For each entry that was returned by the command in the previous step, create a new patch source when you create a custom patch baseline in the **Patch sources** section of **Patch Manager**. For the full list of steps, see [Creating a custom patch baseline (Linux)](https://docs.amazonaws.cn/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * Amazon Systems Manager User Guide*. 1. If you add a patch source for any repository, you must add patch sources for all the repositories that you would like to patch, including the default repositories. ## Patch sources for Oracle Linux On Oracle Linux, the patch baseline uses preconfigured repositories on the managed node. All Oracle Linux Amazon Machine Images (AMIs) can access the public YUM repository. Only licensed Oracle Linux systems can access the Oracle ULN repository. The Oracle Linux repositories are stored in the following location: ``` /etc/yum.repos.d/ ``` Complete the following steps to identify the patch source for the repository that you would like to use for patching: 1. Run the following command to view the default, enabled repositories: ``` cat /etc/yum.repos.d/* | grep -B 4 -A 6 "enabled=1" ``` This command returns four lines before and six lines after each repository that is enabled. For example, the command might return something like this: ``` [o18-appsteream] name=Oracle Linux 8 Application Stream ($basearch) baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/OL8/appstream/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 ``` 1. Save the name and configuration for each repository file. In this example, you would save the following: + Name – `o18-appsteream` + Configuration ``` name=Oracle Linux 8 Application Stream ($basearch) baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/OL8/appstream/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 ``` 1. For each entry that was returned by the command in the previous step, create a new patch source when you create a custom patch baseline in the **Patch sources** section of **Patch Manager**. For the full list of steps, see [Creating a custom patch baseline (Linux)](https://docs.amazonaws.cn/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * Amazon Systems Manager User Guide*. 1. If you add a patch source for any repository, you must add patch sources for all the repositories that you would like to patch, including the default repositories. Oracle Linux 7 managed nodes use YUM as the package manager, while Oracle Linux 8 managed nodes use DNF as the package manager. Both package managers have an update notice, which is a file named `updateinfo.xml`. The update notice is a collection of packages that fix specific issues. Individual packages aren’t assigned classifications or severity levels, so Patch Manager assigns the attributes of an update notice to the related packages and installs the packages based on the classification filters specified in the patch baseline. Only patches specified in `updateinfo.xml` are applied if you are using the default patch baseline provided by Amazon or if you do not select the option to include non-security update patches when you create a custom baseline. If you create a custom baseline and you do select the option to include non-security update patches, the patches in `updateinfo.xml` and the patches that are not in `updateinfo.xml` are applied. For more information, see [How patch baseline rules work on Oracle Linux](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-how-it-works-linux-rules.html#patch-manager-how-it-works-linux-rules-oracle) in the * Amazon Systems Manager User Guide*. Oracle Linux instances require internet access to the public YUM repository or Oracle ULN in order to download packages. If the Amazon EC2 instance is on a private subnet of an Amazon VPC, you can use a proxy server or a local YUM repository to download packages. For more information, see [Oracle Linux Software Management documentation](https://docs.oracle.com/en/operating-systems/oracle-linux/software-management/) in the Oracle documentation. Alternatively, Oracle Linux systems can work with Oracle Linux Manager for YUM package management. An Oracle Linux Manager system can be in a public subnet while Oracle Linux systems can be in a private subnet. For more information, see [Oracle Linux Manager](https://docs.oracle.com/en/operating-systems/oracle-linux-manager/) in the Oracle documentation. ## Windows Server considerations For additional information about security patches for Windows, see [How security patches are selected](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-how-it-works-selection.html) and [How patches are installed](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-how-it-works-installation.html) in the * Amazon Systems Manager User Guide*. # Create patch groups You can use patch groups to organize instances for patching. This can help you ensure that you only deploy patches to the correct set of instances and that the patches have been adequately tested before they are deployed. After you create the patch group, you can tag your Amazon EC2 instances to add them to the patch group and then add the patch group to a patch baseline. You might want to organize patch groups by: + Operating system – such as Linux and Windows + Environment – such as development, test, and production + Server function – such as SAP database servers and SAP application servers **Note** An Amazon EC2 instance can only be in one patch group at a time. For more information about patch groups, see [About patch groups](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-patch-patchgroups.html) in the * Amazon Systems Manager User Guide*. **Tag Amazon EC2 instances to add to the patch group** After you create the patch group, use tags to add Amazon EC2 instances to the patch group. For detailed steps on how to do this, see [Working with patch groups](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-patch-group-tagging.html) in the * Amazon Systems Manager User Guide*. **Add the patch group to a patch baseline** To ensure that the correct patches are installed during the patching execution, you must register the patch group with a patch baseline. When the system applies a patch baseline to an instance, the service checks to see if a patch group is defined for the instance. For detailed steps on how to add a patch group to a patch baseline, see [Add a patch group to a patch baseline](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-patch-group-tagging.html#sysman-patch-group-patchbaseline) in the * Amazon Systems Manager User Guide*. **Note** Patch groups are not used in patching operations that are based on patch policies. For more information, see the following: [Using Quick Setup patch policies](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-policies.html) [Configure the home Amazon Region](https://docs.amazonaws.cn/systems-manager/latest/userguide/quick-setup-getting-started.html#quick-setup-getting-started-home) [Creating a patch policy](https://docs.amazonaws.cn/systems-manager/latest/userguide/quick-setup-patch-manager.html#create-patch-policy) # Applying patches After you have created the patch baseline and tagged your Amazon EC2 instances to the patch group, you can apply patches. You can schedule patches or run them on-demand. ## Scheduled patching SAP maintenance activities are usually scheduled in advance. The non-critical SAP systems can be patched in an ad-hoc manner, such as a sandbox system. The patching process should be documented in runbooks. After the system is successfully patched, the patching activities for the downstream SAP systems can be scheduled, either using maintenance windows or directly from Patch Manager. For more information about patching schedules, see the following documentation: + [About patching schedules using maintenance windows](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-patch-scheduletasks.html) in the * Amazon Systems Manager User Guide* + [Walkthrough: Creating a maintenance window for patching (console)](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-patch-mw-console.html) in the * Amazon Systems Manager User Guide* ## On-demand patching The **Patch now** option in Patch Manager allows you to run on-demand patching operations directly from the Systems Manager console. With this option, you do not need to create a schedule to update the compliance status of your managed nodes or to install patches on non-compliant nodes. Scanning the Amazon EC2 instances allows you to identify systems that are potentially non-compliant, vulnerable, or un-patched. We recommend that you schedule system scans frequently, such as weekly. For detailed instructions on how to run on-demand patching, see [Patching managed nodes on demand](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-on-demand.html) in the * Amazon Systems Manager User Guide*. ## Patch summary After the patch baseline has run, you can view the patch status in Patch Manager. For details about the patch summary and how to access it in Patch Manager, see [Viewing patch Dashboard summaries (console)](https://docs.amazonaws.cn/systems-manager/latest/userguide/view-patch-dashboard-summaries.html) in the * Amazon Systems Manager User Guide*. ## Patch compliance reports Patch compliance reports allow you to view the status of managed nodes. For more information about compliance reports, including detailed instructions on how to view them, see the following documentation: + [Working with patch compliance reports](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-compliance-reports.html) in the * Amazon Systems Manager User Guide* + [Viewing patch compliance results (console)](https://docs.amazonaws.cn/systems-manager/latest/userguide/viewing-patch-compliance-results.html) in the * Amazon Systems Manager User Guide* # Monitoring You can view Patch Manager output after each patch is run. By default, Patch Manager stores the first 48,000 characters of the command output. In some cases, you might want to view the complete log, such as for troubleshooting. In this case, the log output can be stored in Amazon S3. For details about how to store log output in Amazon S3, see [Configuring Amazon CloudWatch Logs Logs for Run Command](https://docs.amazonaws.cn/systems-manager/latest/userguide/sysman-rc-setting-up-cwlogs.html) in the * Amazon Systems Manager User Guide*. Another option is to output the logs to Amazon CloudWatch Logs for unified logging. For more information, see [Sending SSM Agent logs to CloudWatch Logs](https://docs.amazonaws.cn/systems-manager/latest/userguide/monitoring-ssm-agent.html) in the * Amazon Systems Manager User Guide*. For information about how to set up detailed monitoring and notifications, see [Monitoring Amazon Systems Manager](https://docs.amazonaws.cn/systems-manager/latest/userguide/monitoring.html) in the * Amazon Systems Manager User Guide*. # Private and local repositories If you would like to manage your operating system repository locally, either within your VPC on Amazon or an on-premises data center, without using an outbound internet connection for your instance, you can use a private or local repository. Some reasons to use a private repository are: + They provide access to repositories for Amazon EC2 instances that do not have access to the internet for security reasons. + You have additional add-on products from vendors that are not provided through the public cloud update infrastructure. + You want to deploy an organized and consistent set of patches across mission-critical workloads. Using an online repository might introduce new updates which could lead to inconsistency across the landscape. + You want to improve software download times and reduce bandwidth overhead while patching a large fleet of infrastructure. If you are on SUSE Linux Enterprise Server (SLES) and you want to use private repositories, make sure that the operating system repositories are pointing to the local repository instead of the respective vendor repositories before you use Patch Manager. If you are on Red Hat Enterprise Linux (RHEL) or Oracle Linux, you must use a custom baseline to point to local repositories. # Alternative tools for patching In addition to Amazon Systems Manager, there are other automated patching tools that you might use, which are listed below. This list is not exhaustive, but is meant to give you a starting point for doing your own research if you decide to consider alternate tools. ## SUSE Manager SUSE Manager is an infrastructure management tool for Linux systems. With SUSE manager, you can automate software management of SLES< RHEL and OEL operating systems. For more information, and a list of Amazon EC2 instances, see [SUSE Manager Documentation](https://documentation.suse.com/suma/). ## Repository Mirroring Tool (For SUSE Linux) Repository Monitoring Tool (RMT) is a service from SUSE Linux that helps manage private repositories by downloading updates and distributing them across the landscape. This reduces network bandwidth usage and allows you to set more restrictive firewall policies. For more information, see the SUSE Linux [Repository Mirroring Tool Guide](https://documentation.suse.com/sles/15-SP1/single-html/SLES-rmt/index.html). ## Red Hat Satellite (For Red Hat Linux) Red Hat Satellite is a system management solution that enables you to deploy, configure, and maintain your systems across physical, virtual, and cloud environments. Satellite Server synchronizes the content from the Red Hat Customer Portal and other sources, and provides functionality such as fine-grained lifecycle management, user and group role-based access control, integrated subscription management, as well as advanced GUI, CLI, or API access. For more information, see the [Red Hat Customer Portal](https://access.redhat.com/). ## KernelCare (For Red Hat Linux) KernelCare is a live patching system that patches Linux kernel vulnerabilities automatically, with no reboots. It works with all major Linux distributions, such as RHEL, CentOS, Amazon Linux, and Ubuntu. It also interoperates with common vulnerability scanners such as Nessus, Tenable, Rapid7, and Qualys. For more information, see [KernelCare](https://www.amazonaws.cn/marketplace/pp/prodview-aksvbtgd4utj2) on Amazon Marketplace. ## Zypper Package Manager (For SUSE Linux) Zypper is a command-line package manager for installing updating, and removing packages. It can also be used to manage repositories. Zypper offers advantages over graphical package managers such as scripting actions. For more information, see the [Zypper package manager](https://documentation.suse.com/smart/linux/html/concept-zypper/index.html) documentation. # Considerations for multiple accounts When you run SAP workloads in Amazon, you must consider an Amazon account strategy that meets the security controls of your organization. For example, you might separate SAP from non-SAP workloads and separate production from non-production environments. Amazon Systems Manager does not support multi-account patching. In every Amazon account with SAP workloads, patch baselines should be created and patch execution should be performed to ensure that patching is applied to all SAP systems. In a multi-account environment, this should also follow the SAP best practice of patching in the development account, then test, and finally in the production Amazon account. # Automation troubleshooting If you encounter errors related to SAP automation, refer to the [Troubleshooting Systems Manager Automation](https://docs.amazonaws.cn/systems-manager/latest/userguide/automation-troubleshooting.html) documentation in the * Amazon Systems Manager User Guide*. There, you will find an action-specific failures reference as well as information about common errors such as access denied errors and errors related to timed out or failed statuses after the execution started. ## Logging installation steps You can log individual automated installation steps with the code below. In this example, logs are added to `$SSM_LOG_FILE` for each `run` command. ``` action: "aws:runShellScript" name: "Validate_Installation" inputs: runCommand: - #!/bin/bash - sid=echo {{ Sid }} | tr '[:upper:]' '[:lower:]'}`` - SID=echo {{ Sid }} | tr '[:lower:]' '[:upper:]'}`` - HOSTNAME=hostname`` - SIDADM=${sid}adm - su - $SIDADM -c "stopsap $HOSTNAME" | tee -a $SSM_LOG_FILE - su - $SIDADM -c "startsap $HOSTNAME" | tee -a $SSM_LOG_FILE - sleep 15 - _SAP_UP=$(netstat -an | grep 3200 | grep tcp | grep LISTEN | wc -l ) - echo "This is the value of SAP_UP - $_SAP_UP" | tee -a $SSM_LOG_FILE - if [ "$_SAP_UP" -eq 1 ] - then - echo "$(date) __ done installing ASCS." | tee -a $SSM_LOG_FILE - exit 0 - else - echo "$(date) __ ASCS could not be installed successfully. Fix the issue and rerun the automation" | tee -a $SSM_LOG_FILE - exit 1 - fi ```