Open michel-thomas opened 3 years ago
Do you have an idea why?
nope. I did not resolve this, I run manually postmap
command :(
Are you able to run the playbook with the -vv verbosity level and inform if ansible reports a change on the configure sender canonical maps
task? It should look like changed: [hostname] => {"changed": true, ...}
. The handler won't run if a change isn't detected.
Sorry for the delay.
I made some changes in my config to rewrite every sender:
admin_mail: "original@email.com"
postfix_sender_canonical_maps:
- sender: "/.+/"
rewrite: "{{ admin_mail }}"
postfix_sender_canonical_maps_database_type: "regexp"
So, I ran twice:
No changes
TASK [oefenweb.postfix : configure sender canonical maps] *********************
task path: /home/user/Dev/gitlab.com/ansible/.roles_requirements/oefenweb.postfix/tasks/main.yml:127
Friday 17 September 2021 09:48:33 +0200 (0:00:00.029) 0:01:55.283 ******
ok: [edsdev] => (item={'sender': '/.+/', 'rewrite': 'original@email.com'}) => {"ansible_loop_var": "item", "backup": "", "changed": false, "item": {"rewrite": "original@email.com", "sender": "/.+/"}, "msg": ""}
With a change
TASK [oefenweb.postfix : configure sender canonical maps] *********************
task path: /home/user/Dev/gitlab.com/ansible/.roles_requirements/oefenweb.postfix/tasks/main.yml:127
Friday 17 September 2021 09:52:54 +0200 (0:00:00.026) 0:01:52.695 ******
changed: [edsdev] => (item={'sender': '/.+/', 'rewrite': 'changed@email.com'}) => {"ansible_loop_var": "item", "backup": "", "changed": true, "item": {"rewrite": "changed@email.com", "sender": "/.+/"}, "msg": "line replaced"}
NOTIFIED HANDLER oefenweb.postfix : postmap sender_canonical_maps for edsdev
I'm still having a problem with this happening for the sasl_password file not being handled when there it a change. I will take a look at it and see if I can create a fix. In my case, what happened was the playbook errored after the sasl_password file was created so the handler was never reached. I'm not entirely sure that the postmap commands should occur in a handler because a change is never raised in the edge case where the playbook has an error after the role, the error is fixed and the playbook is run again.
Did you take a look @ljurgs?
In most cases handlers are called when there're errors, right?
Did you take a look @ljurgs?
In most cases handlers are called when there're errors, right?
As far as I know, handlers do not get raised if an error causes the playbook execution to abort.
Did you take a look @ljurgs?
In most cases handlers are called when there're errors, right?
From the latest Ansible docs:
Ansible runs handlers at the end of each play. If a task notifies a handler but another task fails later in the play, by default the handler does not run on that host, which may leave the host in an unexpected state. For example, a task could update a configuration file and notify a handler to restart some service. If a task later in the same play fails, the configuration file might be changed but the service will not be restarted. You can change this behavior with the
--force-handlers
command-line option, by includingforce_handlers: True
in a play, or by addingforce_handlers = True
to ansible.cfg. When handlers are forced, Ansible will run all notified handlers on all hosts, even hosts with failed tasks. (Note that certain errors could still prevent the handler from running, such as a host becoming unreachable.)
Maybe it can be mentioned the use of --force-handlers
in the README.md
?
If run the playbook with this:
and then run it again with a change in
postfix_sender_canonical_maps
:the
postmap
command is not launch again and and/etc/postfix/postfix_sender_canonical_maps.db
not updated with new or modified entries. In Postfix logs we can also see