Ini_file destroys all other content

Get Help
1

I’m trying to use the ini_file module to add AmbientCapabilties option with three values to a file. It’s worse than just not idempotent, it’s destructive. The first time it works fine but the second time it removes everything else in the file except the section, option and values.

  - name: Ensure "AmbientCapibilities is in section "[Service]" in the SplunkForwarder service config
    community.general.ini_file:
      path: /etc/systemd/system/SplunkForwarder.service
      section: Service
      option: AmbientCapabilities
      value: "{{ splunk_forwarder_ambient_capabilities | list | flatten | unique | join(' ') }}"
       mode: '0644'
       backup: true
       exclusive: true
       no_extra_spaces: true
    become: true
    when: splunk_forwarder_ambient_capabilities is defined and splunk_forwarder_ambient_capabilities | length

I’ve tried doing it with values: {{ splunk_forwarder_ambient_capabilities }}
and section_has_values but it seems this results in three individual option/value lines in the target file, like this:

AmbientCapabilities=foo
AmbientCapabilities=bar
AmbientCapabilities=baz

I can’t use a template because the service file is created by a command task that runs earlier in the role and can’t be easily replaced. I may be able to use lineinfile or some other module but I’d rather use ini_file because it matches the type of file (technically a systemd service file) but the structure is the same as an ini file.

I’m aware of systemd drop-ins but in this case the vendor has chosen to do things in a non-standard way so I have to work with what I have.

2

The task you have posted doesn’t look valid due to the indenting, also the unbalanced quotes in the name breaks syntax highlighting, do these things make a difference? I can’t see what you are doing wrong apart from this.

I have also added a sort below so that a change in the order won’t result in changes.

  - name: "Ensure AmbientCapibilities is in section [Service] in the SplunkForwarder service config"
    community.general.ini_file:
      path: /etc/systemd/system/SplunkForwarder.service
      section: Service
      option: AmbientCapabilities
      value: "{{ splunk_forwarder_ambient_capabilities | list | flatten | unique | sort | join(' ') }}"
      mode: '0644'
      backup: true
      exclusive: true
      no_extra_spaces: true
    become: true
    when: splunk_forwarder_ambient_capabilities is defined and splunk_forwarder_ambient_capabilities | length

It is to be expected that using a values list will result in multiple options, there is an example of this in the documentation:

- name: Ensure multiple values "beverage=coke" and "beverage=pepsi" are in section "[drinks]" in specified file
  community.general.ini_file:
    path: /etc/conf
    section: drinks
    option: beverage
    values:
      - coke
      - pepsi
    mode: '0600'
    state: present
3

That’s not true. You might not want to do it with a template, but it is something you can do. (Source: it’s what I do.)

It’s also unclear to me what you mean by this. You should still be able to use drop-in files as it’s systemd functionality, not something that Splunk needs to do something special to support.

4

No, in this case, I can’t. The file is modified by a script provided by the vendor. For some dumb reason, instead of providing a systemd service file with the RPM, like every other service package in existence. They decided to leave it out and give you a binary that will generate it, and I can’t be sure that what it generates won’t change. Even doing it the way I’m doing it isn’t bulletproof but it is better than maintaining a template that might not match the one generated by the vendor’s script after a couple of versions.

Also, the generated file is in /etc/systemd/system, which is where a drop-in would go as well. Not sure how systemd could differentiate the two files. It is worth looking into though. Maybe I can figure out how to override a systemd service file in /etc/systemd/system.

5

“Better” in your opinion, not objectively. In either case you have to keep track of whether what it generates changes, so you can just update your template when it does instead of using a fragile and more expensive chain of tasks. (Again, it’s what I do, and it works fine.)

Drop-ins go in /etc/systemd/system/<unit>.d, the files are differentiated by being different files in different locations.

If you’re really set on modifying the file in-place, you should make sure it’s not a symlink to somewhere else. The only way I was able to replicate your result was by making the destination a symlink instead of the real file (with the default follow=false.)

1 Like