Classifying authentication errors within modules as an error instead of unreachable

43 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Jimmy Fort

ungelesen,
04.11.2021, 16:01:5404.11.21
an Ansible Development
For some background, this was initially an RFE that was opened from a Red Hat support ticket.  https://github.com/ansible/ansible/issues/76227.

Here's where I'm struggling with this.  I have a playbook that creates a VM in vCenter, sets it up for WinRM, and then applies some OS configs (updates and move to OU).  When the system gets moved to an OU within our domain, it has a GPO applied.  This GPO will rename the default Administrator account to a different name, which breaks the credentials I have set for this newly created system.  I can easily use the set_fact module to cover the account rename, but I've found there isn't any place to put it without creating an error.

Here's what I've found though:

When using the win modules (Specifically I'm using the win_ping, win_reboot, and win_update modules), I've found that if the wrong credentials are used from the start, the module fails as unreachable because of authentication issues.  However, if authentication issues happen during a module execution (win_reboot, and win_update with reboots) the module reports a failure because the stored credentials are no longer working.

I can cover if the credentials change during module execution with a block/rescue setup, and everything completes with green.  I can also cover the initial unreachable error if I use the ignore_unreachable keyword and use a conditional to change the credentials.  The problem is that the ignore_unreachable does not show that the playbook completed without errors, and at the summary report, it shows the host as red (like it failed).

There was an initial suggestion to submit an RFE that would allow the ignore_unreachable keyword to not show the host as failed, but that would mean that if there is a host that is actually down or the WinRM or SSH port is down that we wouldn't be able to tell from this.

Essentially, I'm looking for the option to do one of two things:

1. Have authentication errors not classified as unreachable.  This would allow them to be handled in a rescue block and it would allow the overall summary to show error free.

2. Allow unreachable errors to be handled in a rescue block.  This would cover authentication issues, and allow for the ability to try different usernames/passwords (we have many systems in our environment where the password could have variations currently).  I think this would be an easier implementation, as a conditional could be applied to handle things depending on why it's unreachable.

This is a long explanation, and I can provide more info if needed (scrubbed playbooks, output, etc...).  I come from a python background, so I'm familiar with error handling and how I can cover some complex behavior with it.

Brian Coca

ungelesen,
04.11.2021, 16:26:2804.11.21
an Jimmy Fort, Ansible Development
You can do this now w/o waiting for a new feature.

- block:
- win_ping:
ignore_unreachable: true
register: ping

- name: this forces a recoverable fail
assert:
that:
- not ping['unreachable']|default(False)
- # depending on connection plugin, you can inspect ping['msg']
for the specific auth errors you can rescule

rescue:
- action: do stuff here



--
----------
Brian Coca

Jimmy Fort

ungelesen,
10.11.2021, 12:49:4110.11.21
an Ansible Development
Thank you for the reply.  That gets me to the same workaround I had before though.  The problem is that it still shows that the playbook failed overall as the host is shown in red at the end because the unreachable error does not trigger the rescue block, and it still gets shown at the end as the playbook failing overall even though the logic is in there to recover from the errors and be successful.  I think that due to the way Ansible handles unreachable errors with blocks, there won't be a way to properly handle it to avoid the playbook showing as failed at the end.  While it's not an issue right now for testing and dev stuff, people are going to be concerned if this behavior occurs in production.  Unfortunately, all the ignore_unreachable keyword does is prevent the playbook from stopping on the unreachable error.

This is the scrubbed playbook for reference:

tasks:
- name: Test WinRM connectivity
block:
- name: Test WinRM connectivity

win_ping:
ignore_unreachable: true
register: ping

- name: this forces a recoverable fail
assert:
that:
- not ping['unreachable']|default(False)
# depending on connection plugin, you can inspect ping['msg'] for the specific auth errors you can rescue

rescue:
- name: Change admin account name
set_fact:
ansible_user: '[new user]'

- name: Test WinRM connectivity again
win_ping:

ansible_unreachable_fail.PNG

Allen antworten
Antwort an Autor
Weiterleiten
0 neue Nachrichten