Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

postfix_sender_canonical_maps.db not updated #111

Open
michel-thomas opened this issue Apr 20, 2021 · 8 comments
Open

postfix_sender_canonical_maps.db not updated #111

michel-thomas opened this issue Apr 20, 2021 · 8 comments

Comments

@michel-thomas
Copy link

If run the playbook with this:

postfix_sender_canonical_maps:
  - sender:                 "root"
    rewrite:                "root@email.com"

and then run it again with a change in postfix_sender_canonical_maps:

postfix_sender_canonical_maps:
  - sender:                 "postmaster"
    rewrite:                "postmaster@email.com"

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

warning: database /etc/postfix/sender_canonical_maps.db is older than source file /etc/postfix/sender_canonical_maps
@tersmitten
Copy link
Member

Do you have an idea why?

@michel-thomas
Copy link
Author

nope. I did not resolve this, I run manually postmap command :(

@ljurgs
Copy link

ljurgs commented Aug 11, 2021

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.

@michel-thomas
Copy link
Author

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:

  1. 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": ""}
  1. 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

@ljurgs
Copy link

ljurgs commented Oct 1, 2021

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.

@tersmitten
Copy link
Member

Did you take a look @ljurgs?

In most cases handlers are called when there're errors, right?

@ljurgs
Copy link

ljurgs commented Nov 30, 2021

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.

@Adito5393
Copy link

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 including force_handlers: True in a play, or by adding force_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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants