Make sysconfig / defaults file configurable

[widhalmt]

We need to change a line in /etc/sysconfig/elasticsearch or /etc/default/elasticsearch for NETWAYS/ansible-role-elasticsearch#74 . The current impelementation is not very friendly for more upcoming changes.

So either find a way to merge ES_JAVA_OPTS and use several lineinfile or change the current implementation and go for a template. (Might be better but way more work due to possibly version dependent contents of the file)

[Donien]

I've been playing around with some regex.
Turns out we could preserve present options while only injecting our own option.

TLDR

If we only ever change that one option, not touching any other option via this role, we might have a solution that keeps existing options (e.g. set by the user manually) and adds this one in case it's needed.

Simple solution, not as robust

My test looks like this:

- hosts: ansible-ubuntu22
  become: yes 
  vars:
    java_opt: "-Djna.tmpdir=/var/lib/elasticsearch/tmp"
  tasks:
    - name: Replace
      replace:
        path: "/etc/default/elasticsearch"
        regexp: '^#* *(ES_JAVA_OPTS=)"(((?!{{ java_opt }}).)*)"'
        replace: '\1"{{ java_opt }} \2"'

Pre:

ES_JAVA_OPTS="something that I already put in here before"

Post:

ES_JAVA_OPTS="-Djna.tmpdir=/var/lib/elasticsearch/tmp something that I already put in here before"

Problem: This way we can not change the path (/var/lib/elasticsearch/tmp) because it would would result in something like this

ES_JAVA_OPTS="-Djna.tmpdir=/var/lib/elasticsearch/tmp2 -Djna.tmpdir=/var/lib/elasticsearch/tmp something that I already put in here before"

More complex solution, more robust

The other approach we can take is to

1. Get the contents of the whole file
2. Get the specific line of interest
3. Parse the options present
4. Remove the -Djna.tmpdir option if present
5. Readd the (by now potentially changed) option and use it with lineinfile

Example:

- hosts: ansible-ubuntu22
  become: yes 
  vars:
    java_opt: "-Djna.tmpdir=/var/lib/elasticsearch/tmp"
  tasks:
    - name: Fetch contents of /etc/default/elasticsearch
      slurp:
        src: "/etc/default/elasticsearch"
      register: "elasticsearch_defaults_file"

    - name: Debug
      vars:
        full_line: "{{ elasticsearch_defaults_file.content | b64decode | split('\n') | select('match', '^ES_JAVA_OPTS=.*') | join }}"
        old_options: "{{ full_line | regex_search('ES_JAVA_OPTS=\"(.*)\"', '\\1') | first }}"
        new_options: "{{ java_opt + ' ' + ( old_options | regex_replace('-Djna\\.tmpdir=[^\\s]+ ?', '')) }}"
      lineinfile:
        path: "/etc/default/elasticsearch"
        regexp: 'ES_JAVA_OPTS='
        line: 'ES_JAVA_OPTS="{{ new_options }}"'

Set vars explained quickly:
full_line: The whole line of interest as a string
old_options: First entry in list of found regex groups matching anything between "..." -> string of all options
new_options: Old options minus -Djna.tmpdir=... + potentially changed -Djna.tmpdir option added back at the front of the string

This example can deal with

• the option (-Djna.tmpdir) not even present to begin with
• no option being present (ES_JAVA_OPTS="")
• the option being present and having some value (+ other options present)

---

But before I get too ahead of myself: what exactly do you mean by "configurable", @widhalmt?
What behaviour do you want to see here?
Do you want to be able to configure multiple options via the role, or do want to give users the ability to manually add (actual vim FILE) to the options?
Or is this issue about more than just ES_JAVA_OPTS?

If we only ever need to change this one option and otherwise would (manually) edit the file, there should be no problem with the approach I layed out. We'd keep whatever is in the options and (re)add our single option.