Chapter 28. Managing systemd units by using RHEL system roles

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content. Use only the variables depending on what actions you want to perform.

   ---
   - name: Managing systemd services
     hosts: managed-node-01.example.com
     tasks:
       - name: Perform action on systemd units
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.systemd
         vars:
           systemd_started_units:
             - <systemd_unit_1>.service
           systemd_stopped_units:
             - <systemd_unit_2>.service
           systemd_restarted_units:
             - <systemd_unit_3>.service
           systemd_reloaded_units:
             - <systemd_unit_4>.service
           systemd_enabled_units:
             - <systemd_unit_5>.service
           systemd_disabled_units:
             - <systemd_unit_6>.service
           systemd_masked_units:
             - <systemd_unit_7>.service
           systemd_unmasked_units:
             - <systemd_unit_8>.service

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a Jinja2 template with the systemd drop-in file contents. For example, create the ~/sshd.service.conf.j2 file with the following content:

   {{ ansible_managed | comment }}
   [Unit]
   After=
   After=network.target sshd-keygen.target network-online.target

   This drop-in file specifies the same units in the After setting as the original /usr/lib/systemd/system/sshd.service file and, additionally, network-online.target. With this extra target, sshd starts after the network interfaces are activated and have IP addresses assigned. This ensures that sshd can bind to all IP addresses.

   Use the <name>.<unit_type>.conf.j2 convention for the file name. For example, to add a drop-in for the sshd.service unit, you must name the file sshd.service.conf.j2. Place the file in the same directory as the playbook.

2. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Managing systemd services
     hosts: managed-node-01.example.com
     tasks:
       - name: Deploy an sshd.service systemd drop-in file
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.systemd
         vars:
            systemd_dropins:
              - sshd.service.conf.j2

   The settings specified in the example playbook include the following:

   systemd_dropins: <list_of_files>

   Specifies the names of the drop-in files to deploy in YAML list format.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a Jinja2 template with the custom systemd unit file contents. For example, create the ~/example.service.j2 file with the contents for your service:

   {{ ansible_managed | comment }}
   [Unit]
   Description=Example systemd service unit file
   
   [Service]
   ExecStart=/bin/true

   Use the <name>.<unit_type>.j2 convention for the file name. For example, to create the example.service unit, you must name the file example.service.j2. Place the file in the same directory as the playbook.

2. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Managing systemd services
     hosts: managed-node-01.example.com
     tasks:
       - name: Deploy, enable, and start a custom systemd service
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.systemd
         vars:
            systemd_unit_file_templates:
              - example.service.j2
            systemd_enabled_units:
              - example.service
            systemd_started_units:
              - example.service

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a Jinja2 template with the custom systemd unit file contents. For example, create the ~/example.service.j2 file with the contents for your service:

   {{ ansible_managed | comment }}
   [Unit]
   Description=Example systemd service unit file
   
   [Service]
   ExecStart=/bin/true
   RemainAfterExit=yes
   
   [Install]
   WantedBy=multi-user.target

   Use the <name>.<unit_type>.j2 convention for the file name. For example, to create the example.service unit, you must name the file example.service.j2. Place the file in the same directory as the playbook.

2. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Managing systemd services
     hosts: managed-node-01.example.com
     tasks:
       - name: Deploy, enable, and start a custom systemd service for a user
         ansible.builtin.include_role:
           name: rhel-system-roles.systemd
         vars:
           systemd_unit_file_templates:
             - item: example.service.j2
               user: <username>
           systemd_enabled_units:
             - item: example.service
               user: <username>
           systemd_started_units:
             - item: example.service
               user: <username>

   Important

   The systemd RHEL system role does not create new users, and it returns an error if you specify a non-existent user in the playbook.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook ~/playbook.yml