Score:1

How to use the output of a command inside ansible ini_file value

ve flag

I wanted to set a value inside a ini_file, but this value is an MD5 hash of the current time. (I am not afraid of accidentally replacing the value, or magically running it twice and having the same value in two different servers.)

This is what I tried, but got only the command as the value in the file (not sure why I thought it would work...):

- name: Replace HardwareID with new MD5
      ini_file:
        path: /etc/app/config.ini
        section: DEFAULT
        option: hardware_token
        value: $(date | md5sum | cut -d" " -f1)

Is there a simple way to make it work?

Michael Hampton avatar
cz flag
That's just the md5sum of some random string. Is it important what format the string is in?
Score:1
cz flag

Ansible can generate its own date and time strings and do its own MD5 sums without calling out to external programs. Consider:

---
- hosts: localhost
  connection: local
  tasks:
    - debug:
        msg: "{{ ansible_date_time.iso8601 | hash('md5') }}"

Note that ansible_date_time contains the last time you gathered facts from the remote server, not necessarily the current time. If you always gather facts on every playbook run, then this should not be a problem.

Guilherme Richter avatar
ve flag
I did not know Ansible had those native "functions". Glad that I asked this question.
Score:0
br flag

Q: "How to use the output of command inside Ansible ini_file value?"

A: Register the result of the command and use it as the value, e.g.

- hosts: test_24
  gather_facts: false
  tasks:
    - shell: 'date | md5sum | cut -d" " -f1'
      register: result
      check_mode: false
    - debug:
        var: result
    - name: Replace HardwareID with new MD5
      ini_file:
        path: etc/app/config.ini
        section: DEFAULT
        option: hardware_token
        value: "{{ result.stdout }}"

gives (running with --check --diff)

TASK [Replace HardwareID with new MD5] ***********************************
--- before: etc/app/config.ini (content)
+++ after: etc/app/config.ini (content)
@@ -0,0 +1,3 @@
+
+[DEFAULT]
+hardware_token = ba3f11c4f1ecfe9d1e805dc8c8c8b149

changed: [test_24]

It's easier to use Ansible facts if you want to use data and time as the input. For example, the dictionary ansible_date_time keeps the date and time if you gather the facts. In the playbook, we set gather_facts: false. ​Therefore the dictionary is not defined

    - debug:
        var: ansible_date_time.iso8601

gives

ok: [test_24] => 
  ansible_date_time.iso8601: VARIABLE IS NOT DEFINED!

You'll have to either gather the facts gather_facts: true when you start the play or run setup, e.g.

    - setup:
        gather_subset: min
    - debug:
        var: ansible_date_time.iso8601

gives

ok: [test_24] => 
  ansible_date_time.iso8601: '2021-07-29T21:32:26Z'

This is not very practical because to get the current time you have to run setup. Instead, the filter strftime gives you always the current time, e.g.

    - debug:
        msg: "{{ '%Y-%m-%d %H:%M:%S' | strftime }}"

    - name: Replace HardwareID with new MD5
      ini_file:
        path: etc/app/config.ini
        section: DEFAULT
        option: hardware_token
        value: "{{'%Y-%m-%d' | strftime | hash('md5') }}"

gives

TASK [debug] ***************************************************************
ok: [test_24] => 
  msg: '2021-07-29'

TASK [Replace HardwareID with new MD5] *************************************
--- before: etc/app/config.ini (content)
+++ after: etc/app/config.ini (content)
@@ -0,0 +1,3 @@
+
+[DEFAULT]
+hardware_token = 5847924805aa614957022ed73d517e7e

As a side note: Using this hash might be very quick searching if the date-time (in granularity of seconds) is the index.

Guilherme Richter avatar
ve flag
Wow, I had no idea I could do some of those things in ansible. Also, your proposed solution is way better than "just grab the shell output and use the value".
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.