Open frankhetterich opened 3 months ago
Thanks for the info. We'll look into it!
Hi. Sorry for the delay. This gave us a bit of a headache. Could you try if your problem is fixed with the latest commit? Should be fixed with https://github.com/NETWAYS/ansible-collection-elasticstack/pull/323
I have just created a PR to implement a possibility to disable the user and role creation for logstash. #328
Please try to fill out as much of the information below as you can. Thank you!
Which version contains the bug?
feature/update-216
Describe the bug
In addition to the elasticsearch upgrade, we also tested the logstash upgrade. Unfortunately the process is failing every time with this error:
TASK [netways.elasticstack.logstash : Put logstash_writer user into Elasticsearch if not present] *************************************************************************************************************** fatal: [eststelk16.int.cid-online.net -> eststelk01.int.cid-online.net]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'logstash_password_hash_salt' is undefined. 'logstash_password_hash_salt' is undefined. 'logstash_password_hash_salt' is undefined. 'logstash_password_hash_salt' is undefined\n\nThe error appears to be in '/home/INT.CID-ONLINE.NET/adminfhetterich/.ansible/collections/ansible_collections/netways/elasticstack/roles/logstash/tasks/logstash-security.yml': line 433, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Put logstash_writer user into Elasticsearch if not present\n ^ here\n"}
It seems to be related to the file lookup into the logstash_writer_user.j2 template file. We looked into the issue and tried to find a workaround with changing some variables but had no luck.
I have to mention that whe´re are not using the default username "logstash_writer" in our installation and it turned also out, that the logstash_writer username is hardcoded in the collection (logstash-security.yml, end of line 431).
Since we do not actually use the collection's user management, it would make sense from our point of view to make this configuration step deactivatable via a variable as well
How to recreate the bug?
No response