Ansible Linux System Roles
- WHAT?
This article gives an introduction to various Ansible Linux system roles that help to automate the configuration and management on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
- WHY?
Learn how to automate IT infrastructure with Ansible Linux system roles.
- EFFORT
The average reading time of this article is approximately 40 minutes.
- REQUIREMENTS
Linux fundamentals: Understanding basic Linux commands,file permissions, directory structures and usage of the command line.
Networking: Ansible connects to remote machines via SSH so knowledge of IP addresses, SSH, host names and ports is required.
YAML: Ansible playbooks are written in YAML so knowing how to structure a YAML file is essential.
1 About Ansible Linux system roles #
Linux system roles are a set of Ansible roles designed to automate and configure common components and services of the Linux operating system.
Linux system roles are always used with Ansible playbooks. You define the desired state of your systems in an Ansible playbook, specifying which roles to apply and with what parameters. Ansible then connects to your Linux hosts and executes the tasks defined within the roles to bring your systems into the desired state.
The system roles are shipped in the ansible-linux-system-roles package on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
Once the ansible-linux-system-roles package is installed, you can access:
Roles:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/rolesDocumentation:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
Each role has a README in the docs directory that includes:
Description of the role
Supported variables and their usage
Example playbooks
The README.md files for each role:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs # ls
CHANGELOG_aide.md CHANGELOG_timesync.md README_suseconnect.md
CHANGELOG_certificate.md README_aide.md README_systemd.md
CHANGELOG_cockpit.md README_certificate.md README_timesync.md
CHANGELOG_crypto_policies.md README_cockpit.md aide
CHANGELOG_firewall.md README_crypto_policies.md certificate
CHANGELOG_ha_cluster.md README_firewall.md firewall
CHANGELOG_journald.md README_ha_cluster.md ha_cluster
CHANGELOG_keylime_server.md README_journald.md journald
CHANGELOG_mssql.md README_keylime_server.md keylime_server
CHANGELOG_podman.md README_mssql.md podman
CHANGELOG_postfix.md README_podman.md selinux
CHANGELOG_selinux.md README_postfix.md ssh
CHANGELOG_ssh.md README_selinux.md systemd
CHANGELOG_systemd.md README_ssh.md timesync2 Installing Ansible Linux system roles #
To install Ansible Linux system roles on a SUSE Linux Enterprise Server for SAP applications control node:
Install the roles on a control node:
>sudozypper install ansible-linux-system-roles
The control node is where Ansible and the Linux system roles are installed. It is not required to have Ansible or Linux system roles installed on managed nodes.
3 About the firewall Linux system role #
The firewall Linux system role in Ansible is a pre-packaged and reusable set of tasks and defaults designed to configure and manage the firewalld service
on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Install and enable the
firewalldservice.Manage zones such as
public,homeorinternal.Add or remove services such as
sshto specific zones.Open or close ports, for example,
8080orTCPfor particular zones.Configure port forwarding and masquerading (NAT).
Handle permanent and runtime configuration.
---
- name: Erase existing config and enable ssh service
hosts: managed_nodes
become: true
gather_facts: true
vars:
firewall:
- previous: replaced
- service: ssh
state: enabled
tasks:
- name: reset firewall and enable SSH service
ansible.builtin.include_role:
name: suse.linux_system_roles.firewallprevious: replaced: Resets thefirewalldconfiguration by removing all existing user-defined settings.previousis astringdatatype and accepts valuereplaced.service: ssh: Secure Shell (SSH) as the specific network traffic type to be managed.serviceis astringdatatype and accepts valuesssh,http,tftpetc.state: enabled: Permanently opens the firewall for incoming SSH traffic.stateis astringdatatype and accepts valuesenabledordisabled.
---
- name: Disable TFTP service on managed nodes
hosts: managed_nodes
become: true
gather_facts: true
vars:
firewall:
- service: tftp
state: disabled
tasks:
- name: Configure firewall to disable TFTP service
ansible.builtin.include_role:
name: suse.linux_system_roles.firewallservice: tftp: Defines the Trivial File Transfer Protocol (TFTP) as the specific network service to be managed.serviceis astringdatatype and accepts valuesssh,httptftpetc.state: disabled: Permanently block all incoming network traffic related totftp.stateis astringdatatype and accepts valuesenabledordisabled
For more details about all the variables in the firewall Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
4 About the AIDE Linux system role #
The AIDE Linux system role in Ansible installs, configures and manages the Advanced Intrusion Detection Environment (AIDE) utility on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Ensure the AIDE package is installed on the managed node.
Optionally generate and deploys a custom
/etc/aide.conffile.Create the baseline AIDE database on the managed node.
Run checks against the live system and reports any file additions, deletions, or modifications. This is used for daily intrusion detection.
Securely fetch the AIDE database files from the remote host back to the control node.
---
- name: Example aide role invocation
hosts: managed_hosts
become: true
gather_facts: true
tasks:
- name: Include role aide
vars:
aide_db_fetch_dir: files
aide_init: true
aide_check: false
aide_update: false
ansible.builtin.include_role:
name: suse.linux_system_roles.aideaide_db_fetch_dir: files: is astringdatatype that specifies the directory on control node, where the AIDE database files are fetched and stored from the remote managed nodes. The default isfiles, which means the role expects a directory namedfilesto exist in the same directory as the playbook being executed.aide_init: true: is aBooleandatatype that controls whether a AIDE database should be initialized on a managed node. The default isfalse. When set totrue, a AIDE database is created on the managed node, it is then fetched to the control node.aide_check: false: is aBooleandatatype that controls whether an integrity check should be immediately run on the managed nodes. The default isfalse. When set totrue, the AIDE check is run, data is compared with the current state of the file system with the trusted baseline database and a report is generated.aide_update: false: is aBooleandatatype that controls the creation of a new AIDE database to replace the current trusted baseline. The default isfalse. When set totrue, the AIDE update command is run on the managed system, which performs an integrity check, creates a new AIDE database reflecting the current system state and establishes this new file as the trusted baseline for future checks.
For more details about all the variables in the AIDE Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
5 About the Cockpit Linux system role #
The Cockpit Linux system role in Ansible automates the installation and configuration of the Cockpit Web Console, a web-based graphical interface for administering SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Ensure the necessary Cockpit packages are installed.
Ensure
cockpit.socketis enabled for socket-based activation.Allow the administrator to set specific options in the
/etc/cockpit/cockpit.conffile, such as the login title or session timeoutscockpit_config.
---
- name: install Cockpit on all hosts
hosts: managed_nodes
become : true
gather_facts: true
tasks:
- name: Dynamically execute the Cockpit role
ansible.builtin.include_role:
name: suse.linux_system_roles.cockpit ---
- name: Install Cockpit and automatically open firewall port
hosts: managed_hosts
become: true
gather_facts: true
vars:
cockpit_enabled: true
cockpit_started: true
cockpit_manage_firewall: true
tasks:
- name: Dynamically install Cockpit and open firewall
ansible.builtin.include_role:
name: suse.linux_system_roles.cockpitcockpit_enabled: true: controls thesystemdservice setting for the Cockpit Web Console.cockpit_enabledis aBooleandatatype and accepts valuestrueandfalse. Default istrue, which means the Cockpit service is configured to start automatically at system boot.cockpit_started: true: controls the immediate runtime status of the Cockpit Web Console service.cockpit_startedis aBooleandatatype and accepts valuestrueandfalse. Default istrue, which means the Cockpit service is running immediately on the managed host.cockpit_manage_firewall: true: delegates the task of configuring the firewall to the role itself, ensuring the Cockpit web interface is network-accessible.cockpit_manage_firewallis aBooleandatatype and accepts valuestrueandfalse. Default isfalse, which means the role installs and enables Cockpit but makes no changes to the firewall, leaving that task to be handled manually or by a separate dedicated firewall role.
For more details about all the variables in the Cockpit Linux system role,
refer to the specific REDADME.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
6 About the HA cluster Linux system role #
The HA cluster Linux system role in Ansible is designed to fully install, configure and manage a Pacemaker and Corosync High Availability (HA) cluster on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Automate the installation of core cluster components like Pacemaker and Corosync.
Create and initialize a robust, multi-node High Availability cluster.
Configure fencing devices to ensure true node isolation and data integrity upon failure.
Define and manage cluster resources, such as floating IP addresses, application services, and shared storage mounts.
Set resource constraints and dependencies to control which nodes run specific services.
Enable and manage cluster services across the defined cluster nodes.
Ensure consistent HA setup across multiple environments, adhering to best practices and minimizing manual errors.
---
- name: Configure firewall and selinux for managed nodes
hosts: managed_nodes
become: true
gather_facts: true
vars:
ha_cluster_manage_firewall: true
ha_cluster_manage_selinux: true
tasks:
- name: Manage firewall and selinux
ansible.builtin.include_role:
name: suse.linux_system_roles.ha_clusterha_cluster_manage_firewall: true: It controls whether the role should automatically configure the system's firewall to permit necessary cluster communication.ha_cluster_manage_firewallis aBooleandatatype and accepts valuestrue,false,yes,no,0and1. When set totrue, it automatically adds firewall rules to open the necessary ports for the cluster to function. Default isfalse.ha_cluster_manage_selinux: true: Controls whether the HA cluster role will automatically configure the SELinux policy to allow cluster processes to function.ha_cluster_manage_selinuxis aBooleandatatype and accepts valuestrue,false,yes,no,0and1. When set totrue, it manages SELinux and performs actions like setting the correct SELinux contexts on necessary files and directories, enabling or setting SELinux booleans required for cluster services etc. Default isfalse.
---
- name: Manage HA cluster with TLS certificates and key files
hosts: managed_nodes
become: true
gather_facts: true
vars:
ha_cluster_pcsd_certificates:
- name: FILENAME
common_name: "{{ ansible_hostname }}"
ca: self-sign
tasks:
- name: Manage firewall and selinux
ansible.builtin.include_role:
name: suse.linux_system_roles.ha_clusterThis example creates self-signed pcsd certificate and private key files in /var/lib/pcsd
with the file name FILENAME.crt and FILENAME.key.
ha_cluster_pcsd_certificates: is a list of dictionaries used to define TLS certificates for the pcsd service. The default is[]. It uses the structure of the underlyingcertificatesystem role. The certificate specific keys areca,common_nameandcert_basename. These keys are allstringdata types.
For more details about all the variables in the HA cluster Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
7 About the SUSEconnect Linux system role #
The SUSEconnect Linux system role in Ansible manages SUSE Linux system registrations with SUSE Customer Center or a SMT server. It automates the process of registering and deregistering systems, as well as managing additional products and modules on a SUSE system.
You can use this role to:
Register a SUSE system to the SCC or servers.
Activate or remove of specific add-on products or modules.
Deregister systems or products.
Support transactional update register SLE-MICRO.
Recheck tasks to ensure a smooth registration process.
Ensure compatibility with public cloud environments.
---
- name: Register with SCC and activate modules
hosts: managed_nodes
become: true
gather_facts: true
vars:
suseconnect_base_product:
key: '{{ sles_registration_key }}'
product: '{{ ansible_distribution }}'
suseconnect_subscriptions:
- {name: "sle-module-containers", state: enabled}
- {name: "PackageHub", state: disabled}
- {name: "sle-module-python3", state: enabled}
tasks:
- name: Register system and modules with SUSE Customer Center
ansible.builtin.include_role:
name: suse.linux_system_roles.suseconnectsuseconnect_base_product: defines the required parameters for registering the core operating system of a SUSE Linux machine.suseconnect_base_productis defined as a YAML Dictionary containing key-value pairs that map directly to the requirements of SCC or SMT servers. Accepted string values arekey,product,versionandarch.suseconnect_subscriptions: is a crucial component for enterprise SUSE deployments, as it controls which features, for example, High Availability, containers, or web application platforms enabled on the registered base operating system.suseconnect_subscriptionsis defined as a YAML Dictionary containing key-value pairs that map directly to the requirements of SCC or SMT servers. Accepted string values arename,state,versionandkey.
---
- name: Deregister products from SCC
hosts: managed_nodes
become: true
gather_facts: true
vars:
suseconnect_deregister: true
tasks:
- name: Deregister products from SUSE Customer Center
ansible.builtin.include_role:
name: suse.linux_system_roles.suseconnectsuseconnect_deregister: true: instructs the system to deactivate its base subscription and remove it from the the SCC or SMT servers.suseconnect_deregisteris aBooleandatatype and accepts valuesfalseandtrue. When set totrue, it executes the necessary SUSEConnect command to deregister the system's base product subscription. Default isfalse.
For more details about all the variables in the SUSEConnect Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
8 About the Journald Linux system role #
The Journald Linux system role in Ansible is designed to configure and manage the systemd-journald service on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
The role automates changes to /etc/systemd/journald.conffile. You can use this role to:
Determine where journal logs are stored. Logs can be stored temporarily in memory or persistently on the disk.
Set hard limits on how much disk space the journal can consume before old logs are deleted.
Configure how much disk space the journal should always leave free for other system uses.
Control whether journal data objects should be compressed to save space.
Configure whether log data is kept separate for individual users.
Manage the running state of the
systemd-journaldservice.
---
- name: Configure persistent storage, limit disk usage, enable user logging and set synchronization frequency
hosts: managed_nodes
become: true
gather_facts: true
vars:
journald_persistent: true
journald_max_disk_size: 1024
journald_per_user: true
journald_sync_interval: 1
tasks:
- name: Configure persistent storage, limit disk usage, enable user logging and set synchronization frequency
ansible.builtin.include_role:
name: suse.linux_system_roles.journaldjournald_persistent: true: instructs journald to create the/var/log/journaldirectory and store logs permanently.journald_persistentis aBooleandatatype and accepts values accepts valuestrueandfalse. Default isfalse.journald_max_disk_size: 1024: limits the total disk space the journal files may use up to 1 Gigabyte (1024 MB).journald_max_disk_sizeis anintegerdatatype and accepts an integer representing a size in megabytes (MB). No value is explicitly configured by this role; therefore, the default sizing logic fromman 5 journald.confapplies.journald_per_user: true: Enables per-user logging. Logs are kept separate for individual users, allowing unprivileged users to read logs related only to their own services.journald_per_useris aBooleandatatype and accepts valuestrue,false,yes,no,0and1. Default isfalse.journald_sync_interval: 1: limits the total disk space the journal files may use up to 1 Gigabyte (1024 MB).journald_max_disk_sizeis anintegerdatatype and accepts an integer representing a time span in minutes. By default role does not alter currently used value.
---
- name: Configure systemd-journald for persistent storage and disk limits
hosts: managed_nodes
become: true
gather_facts: true
vars:
journald_persistent: true
journald_max_disk_size: 1024
tasks:
- name: Configure journald for persistent storage and disk limits
ansible.builtin.include_role:
name: suse.linux_system_roles.journaldjournald_persistent: true: instructs journald to create the/var/log/journaldirectory and store logs permanently.serviceis aBooleandatatype and accepts values accepts valuestrue,false,yes,no,0and1. Default isfalse.journald_max_disk_size: 1024: limits the total disk space the journal files may use up to 1 Gigabyte (1024 MB).journald_max_disk_sizeis anintegerdatatype and accepts an integer representing a size in megabytes (MB). No value is explicitly configured by this role; therefore, the default sizing logic fromman 5 journald.confapplies.
For more details about all the variables in the journald Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
9 About the Podman Linux system role #
The Podman Linux system role in Ansible automates the deployment and lifecycle management of containers as system services at scale, ensuring consistent and often rootless container orchestration across an infrastructure.
You can use this role to:
Ensure the necessary Podman packages and related tools are installed and updated.
Automate the prerequisite setup for running containers as unprivileged users. Also includes managing the correct entries in
/etc/subuidand/etc/subgidfiles.Manage the creation, starting, stopping and removal of containers.
Leverage Podman's deep integration with
systemdby automatically generatingsystemdunit files (or Quadlet files on newer systems) to manage containers and pods as persistent services that start automatically at boot.Deploy complex multi-container workloads defined using standard Kubernetes YAML manifests.
---
- name: Manage podman root containers and services
hosts: managed_hosts
become: true
gather_facts: true
vars:
podman_firewall:
- port: 8080/tcp
state: enabled
podman_kube_specs:
- state: started
kube_file_content:
apiVersion: v1
kind: Pod
metadata:
name: test1-httpd
spec:
containers:
- name: test1-httpd
image: registry.access.suse.com/test1/httpd-24
ports:
- containerPort: 8080
hostPort: 8080
volumeMounts:
- mountPath: /var/www/html:Z
name: test1-html
volumes:
- name: test1-html
persistentVolumeClaim:
claimName: test1-html-volume
tasks:
- name: Dynamically install Cockpit and open firewall
ansible.builtin.include_role:
name: suse.linux_system_roles.podmanIn this example , a Kubernetes pod test1-httpd running an HTTP server container from the registry.access.suse.com/test1/httpd-24 image.
The container’s web content is mounted from a persistent volume named test1-html-volume.
By default, the role creates rootful containers.
podman_firewall: controls the necessary firewall configurations on the host to ensure container ports are accessible. It is a list of dictionaries, where each dictionary defines a single firewall rule for a container. The accepted values are specified as key-value pairs within these dictionaries. The most common and crucial keys accepted within each dictionary item areport,state,zoneandmasquerade. Default is an empty list[]ornull.podman_kube_specs: defines and manage Podman containers or pods based on Kubernetes YAML specifications. It is a list of dictionaries and each dictionary item defines one container or pod deployment and requires one of the following keys to specify the Kubernetes YAML source:kube_file_srcorkube_file_content. Default is an empty list[]ornull.
For more details about all the variables in the Podman Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
10 About the certificate Linux system role #
The certificate Linux system role in Ansible automates the entire lifecycle of TLS and SSL certificates on managed Linux hosts.
You can use this role to:
Generate the private key and the Certificate Signing Request (CSR) locally on the managed node, ensuring the private key never leaves the host.
Handle the submission of the CSR to a designated Certificate Authority (CA).
Save the newly issued certificate, key, and CA chain files to the correct, secure locations on the file system, managing file ownership and permissions.
Set up mechanisms such as
certmongerto automatically monitor the certificate's expiration date and attempt renewal before it expires.
---
-name: Issue a self signed certificate
hosts: managed_nodes
become: true
vars:
certificate_requests:
- name: mycert
dns: *.example.com
ca: self-sign
tasks:
- name: Issue a self signed certificate
ansible.builtin.include_role:
name: suse.linux_system_roles.certificatecertificate_requests: defines the specific details of the certificates the role needs to issue, manage, or renew. It is a list of dictionaries and each item in the list is a dictionary specifies the properties of one unique certificate to be managed. The default is an empty list[]. If this list is empty, the role performs no certificate management actions. Each dictionary within thecertificate_requestslist must define at least the certificate name and the issuing Certificate Authority. Other parameters specify the key size, subject, and domains. In this example,name,caarestringdata types and required.dnscan be either alistorstringand is optional.
You can find the directory at:
Certificates:
/etc/ssl/certsKeys:
/etc/ssl/certs/private
---
-name: Issue a certificate and specify location
hosts: managed_nodes
become: true
gather_facts: true
vars:
certificate_requests:
- name: test/path/mycert
dns: *.example.com
ca: self-sign
tasks:
- name: Issue a certificate and specify location
ansible.builtin.include_role:
name: suse.linux_system_roles.certificateThis example creates a certificate file in /test/path/mycert.crt and a key file in /test/path/mycert.key .
For more details about all the variables in the certificate Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
11 About the Crypto policies Linux system role #
The Crypto policies system role in Ansible is to establish the rules, guidelines, and standards for the proper and effective use of cryptography on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Specify when and how different types of data must be encrypted.
Ensure that organizations adheres to legal, regulatory and industry mandates that require specific, strong cryptographic controls for data protection.
Prohibit the use of weak, outdated, or known-vulnerable algorithms and protocols, thereby reducing the risk of a security breach.
System-wide cryptographic policy that provides a centralized way for administrators to configure core cryptographic like TLS, SSH, etc. so that most applications use a default, secure configuration.
Specify when and how different types of data must be encrypted.
Define the procedures for the entire lifecycle of cryptographic keys.
Mandate which cryptographic algorithms are approved for use, ensuring a consistent, secure level of protection across all systems and applications.
---
- name: Enforce the 'FUTURE' system-wide cryptographic policy
hosts: managed_nodes
become: true
gather_facts: true
vars:
crypto_policies_policy: "FUTURE"
crypto_policies_reload: true
crypto_policies_reboot_ok: false
tasks:
- name: Enforce the FUTURE policy
ansible.builtin.include_role:
name: suse.linux_system_roles.crypto_policiescrypto_policies_policy: "FUTURE": is used to system-wide cryptographic settings on compatible Linux distributions.crypto_policies_policyis astringdatatype and accepts valuesDEFAULT,FUTURE,LEGACYand custom policies that Administrators can define. Default isnull.crypto_policies_reload: true: ensures that the new cryptographic policy takes effect immediately by attempting to restart or reload services that rely on the system's cryptographic libraries.crypto_policies_reloadis aBooleandatatype and accepts valuestrueandfalsecan define. Default istrue.crypto_policies_reboot_ok: false: dictates whether the playbook is permitted to automatically reboot the managed server after changing the cryptographic policy.crypto_policies_reboot_okis aBooleandatatype and accepts valuestrueandfalsecan define. Default isfalse.
---
- name: Manage crypto policies
hosts: managed_nodes
become: true
gather_facts: true
vars:
crypto_policies_policy: "DEFAULT:NO-SHA1"
crypto_policies_reload: false
tasks:
- name: Configure default crypto policy level without SHA1
ansible.builtin.include_role:
name: suse.linux_system_roles.crypto_policiescrypto_policies_policy: "DEFAULT:NO-SHA1: is used to system-wide cryptographic settings on compatible Linux distributions.crypto_policies_policyis astringdatatype and accepts valuesDEFAULT,FUTURE,LEGACYand custom policies that Administrators can define. Default isnull. In this example, you are using theDEFAULTpolicy as a starting point and then modifying it with the built-inNO-SHA1sub-policy.crypto_policies_reload: false: ensures that the new cryptographic policy takes effect immediately by attempting to restart or reload services that rely on the system's cryptographic libraries.crypto_policies_reloadis aBooleandatatype and accepts valuestrueandfalsecan define. Default istrue.
For more details about all the variables in the Crypto policies Linux system role,
refer to the specific README.md file on the control node:
12 About the MSSQL Linux system role #
The MSSQL Linux system role in Ansible automates the installation, configuration and initial deployment of Microsoft SQL Server (MSSQL) on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Install the necessary SQL Server packages and tools.
Manages the acceptance of the End-User License Agreement (EULA), which is required for installation.
Set the required System Administrator
saandmssql_password. This is a mandatory variable for initial setup.Configures the TCP Port the server listens on.
Manages TLS/SSL certificates to ensure encrypted connections to the database.
Optimize the operating system for database performance and throughput, by applying the
mssqlTuned profile.
---
- name: Install and configure basic Microsoft SQL Server
hosts: managed_nodes
become: true
gather_facts: true
vars:
mssql_accept_microsoft_sql_server_standard_eula: true
mssql_password: "{{ sa_secret_password }}"
mssql_edition: "Developer"
tasks:
- name: Manage basic Microsoft SQL Server
ansible.builtin.include_role:
name: suse.linux_system_roles.mssqlmssql_accept_microsoft_sql_server_standard_eula: explicitly confirms the user agrees to the Microsoft SQL Server End-User License Agreement (EULA). It is a mandatoryBooleandatatype and accpets valuestrueorfalse. It must be set totruein your playbook or inventory for the role to proceed with the installation of SQL Server. If set tofalse, the installation tasks will fail or be skipped. The default is empty{}.mssql_password: sets the password for the Administratorsauser. It is a mandatorystringdatatype. The password must have a minimum length of 8 characters, include uppercase and lowercase letters, base 10 digits or non-alphanumeric symbols. Default isnull.mssql_edition: defines the specific version of Microsoft SQL Server to be installed on the host. It is a mandatorystringdatatype and accepts valuesEnterprise,Standard,Web,Developer,Express,Evaluationand a product key in form of#####-#####-#####-#####-#####where#is a number or letter. Default isnull.
For more details about all the variables in the MSSQL Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
13 About the SELinux Linux system role #
The SELinux Linux system role in Ansible automates the full management and enforcement of the SELinux policy on managed nodes in a standardized and idempotent way.
You can use this role to:
Set the global SELinux mode to
enforcing,permissiveordisabledusing theselinux_statevariable.Manage the state of SELinux booleans.
Define persistent rules for file system labeling (file contexts) for custom directories or applications.
Define security types for non-standard network ports, allowing services to listen on them without violating the policy.
Manage the mapping between Linux user accounts and specific SELinux user identities.
---
- name: Reset the selinux context
hosts: managed_nodes
become: true
gather_facts: true
vars:
selinux_restore_dirs:
- /var/www/
- /etc/
tasks:
- name: reset the selinux context
ansible.builtin.include_role:
name: suse.linux_system_roles.selinuxselinux_restore_dirs: specifies file system paths on the managed node where the SELinux contexts should be immediately reapplied or corrected (using the equivalent of therestoreconutility). It is a list of strings, where each string is a file system tree where you want to runrestorecon.
---
- name: set a selinux port label
hosts: managed_nodes
become: true
gather_facts: true
vars:
selinux_ports:
- ports: 8080
proto: tcp
setype: http_port_t
state: present
tasks:
- name: set a selinux port label
ansible.builtin.include_role:
name: suse.linux_system_roles.selinuxselinux_ports: manages the SELinux port labeling policy on a managed node. It is a list of dictionaries with each dictionary defining a specific port rule.portsare strings or a list and define port numbers to which you want to assign the SELinux label. Multiple values separated by a comma are accepted.protois astringdatatype and defines the network protocol.setypeis astringdatatype and defines the SELinux type (label) to assign to the port.
For more details about all the variables in the SELinux Linux system role,
refer to the specific REDADME.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
14 About the SSH Linux system role #
The SSH Linux system role in Ansible automates the configuration and management of the Secure Shell (SSH) service on SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Enforce security best practices on the SSH daemon.
Set default client options for all managed users.
Deploy public keys for specific users to enable passwordless access.
Define which users or groups are permitted to log in via SSH.
---
- name: Manage ssh clients
hosts: managed_nodes
become: true
gather_facts: true
vars:
ssh_user: root
ssh:
Compression: true
# wokeignore:rule=master
ControlMaster: auto
ControlPath: ~/.ssh/.cm%C
Match:
- Condition: "final all"
GSSAPIAuthentication: true
Host:
- Condition: example
Hostname: example.com
User: user1
ssh_ForwardX11: false
tasks:
- name: manage SSH clients
ansible.builtin.include_role:
name: suse.linux_system_roles.sshssh_user: is a role specific variable used to determine the scope of the SSH client configuration being deployed. The default value isnullor undefined, which means the role is configured to manage the global, system-wide SSH client configuration, which is located at/etc/ssh/ssh_configon the managed node.ssh_ForwardX11: controls whether X11 forwarding should be automatically enabled when establishing an SSH connection to a remote host. It determines if the graphical interface environment (X Window System) of the remote host should be tunneled securely back to the local client machine, allowing the user to run remote graphical applications. It is aBooleandatatype with valuesyesandno.
For more details about all the variables in the SSH Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
15 About the systemd Linux system role #
The systemd Linux system role in Ansible automates the full lifecycle management and deployment of systemd units and configurations SUSE Linux Enterprise Server for SAP applications 16.0 systems.
You can use this role to:
Place custom or templated
systemdunit files such as.service,.timeretc. into the correct directories/etc/systemd/system/.Control the execution status of services, allowing you to easily start, stop, restart, or reload specific units.
Control whether units are configured to start automatically at boot or are prevented from doing so.
Use the most aggressive method to prevent a service from ever running or being manually started by setting the unit as
masked.
---
- name: Deploy and start a systemd unit
hosts: managed_nodes
become: true
gather_facts: true
vars:
systemd_unit_file_templates:
- test.service.j2
systemd_started_units:
- item: test.service
user: root
- item: test1.service
user: user1
systemd_enabled_units:
- test.service
tasks:
- name: Manage a systemd unit
ansible.builtin.include_role:
name: suse.linux_system_roles.systemdsystemd_unit_file_templates: specifies a list of Jinja2 template file names residing on the control node that should be rendered and deployed as fullsystemdunit files on the managed nodes. It is a list of strings or dictionaries. Each item specifies a Jinja2 template file located in the role'stemplates/directory. Default is an empty list[]ornull.systemd_started_units: specifies whichsystemdunits should be set to the started state on the managed nodes. It is a list of strings or dictionaries. Default is an empty list[].systemd_enabled_units: specifies whichsystemdunit files should be enabled on the managed nodes, ensuring they start automatically at boot. It is a list of strings or dictionaries. Default is an empty list[]
For more details about all the variables in the systemd Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
16 About the time synchronization Linux system role #
The time synchronization Linux system role in Ansible automates the configuration and enforcement of system time synchronization on managed Linux hosts. NTP and PTP are essential standards used to synchronize computer clocks across a network. Accurate time synchronization is crucial because many critical network services rely on precise time to function correctly.
You can use this role to:
Install and configure the preferred time synchronization service such as Chrony or NTPD.
Set the list of reliable time servers like NTP peers and servers the system should synchronize with.
Ensure the system uses the desired synchronization method.
Helps ensure that systems are compliant with security requirements that mandate accurate logging and synchronized authentication, for example, Kerberos.
---
- name: Manage timesync
hosts: managed_nodes
become: true
gather_facts: true
vars:
timesync_ntp_servers:
- hostname: ntp.example.com
iburst: true
- hostname: time.example.com
iburst: true
- hostname: sync.example.com
iburst: true
tasks:
- name: Manage timesync
ansible.builtin.include_role:
name: suse.linux_system_roles.timesynctimesync_ntp_servers: is a primary mechanism for an administrator to specify which external network time sources (NTP servers) the managed Linux host should use for clock synchronization. It is a list of dictionaries.The default is an empty list[]. Each dictionary entry within thetimesync_ntp_serverslist defines a single time source and its desired configuration options. In this example,hostnameis a requiredstringdatatype andiburstis an optionalBooleandatatype.
---
- name: Manage timesync in PTP domain 0, interface eth0
hosts: managed_nodes
become: true
gather_facts: true
vars:
timesync_ptp_domains:
- number: 0
interfaces: [eth0]
tasks:
- name: Manage linuxptp
ansible.builtin.include_role:
name: suse.linux_system_roles.timesynctimesync_ptp_domains: configures Precision Time Protocol (PTP) synchronization It is a list of dictionaries. Default is an empty list[]. In this example,numberis a requiredstringdatatype andinterfacesare optionallist of stringsdata types.
For more details about all the variables in the time synchronization Linux system role,
refer to the specific README.md file on the control node:
/usr/share/ansible/collections/ansible_collections/suse/linux_system_roles/docs
17 Legal Notice #
Copyright© 2006–2025 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.