Archy's Blog

When updating Rundeck from version 4.0 to 4.1(+), the database has to be migrated from v1 to v2 because the service won't start otherwise. So here's  a quick how-to: First, stop the rundeck service and create a backup: [root@rundeck ~]# systemctl stop rundeckd.service [root@rundeck ~]# mkdir -p /var/backup/rundeck [root@rundeck ~]# tar -cvpf /var/backup/rundeck/rundeck-db-v1-$(date +%F).tar /var/lib/rundeck/data There's a script that can be utilized to migrate the db from v1 to v2 so let's clone that: [root@rundeck ~]# git clone https://github.com/rundeck-plugins/h2-v2-migration.git Now run the migration script against the current database. Ensure that you have a backup so you can rollback if things go haywire: [root@rundeck ~]# cd h2-v2-migration [root@rundeck ~]# /usr/bin/sh migration.sh -f /var/lib/rundeck/data/rundeckdb -u 'sa' -p Once that migration is done, the script will create an './output' directory where the db files are stor

This error most likely occurs during startups and is usually caused by errors or missing parameters in the service unit configuration. In my case, the service provided by a vendor, let's call it 'fancy.service', was misconfigured out of the box which led to these errors in the system's journal: [root@server ~]# journalctl ... Jun 21 20:02:54 server.example.com systemd[992]: fancy.service: Failed to determine user credentials: No such process Jun 21 20:02:54 server.example.com systemd[992]: fancy.service: Failed at step USER spawning /usr/bin/sh: No such process ... The root cause was the order in which the services were started. This 'fancy.service' didn't have any 'Wants=' or 'After=' declared although it required having network (network.target) access and being able to authenticate users (sssd.service), so let's fix that. First, create the overrides-directory for the service and add the required settings to a '.conf&#

Depending on what you're configuring, you might have to configure YAML Variables inside of text strings that should not be templated at runtime. There's a solution for templates and for tasks. Let's start with templates, there's '{% raw %}' and '{% endraw %}'. Here's an example: {% raw %} a string that won't be templated and contains a {{ var }} {% endraw %} This will result in the following file content: a string that won't be templated and contains a {{ var }} Now for playbooks, you can use '!unsafe' in front of the line of text. This will make ansible ignore the jinja variable definition and treat it as text.  Now to the problem that spawned this post: creating a mail notification with custom messages in AWX. Here's an example playbook: --- - hosts: localhost become: false delegate_to: localhost collections: - awx.awx tasks: - name: create mail notification awx.a