Alrighty
So I’m behind the curve and am updating all of my collections and testing out playbooks here and there, and I noticed along the way that from between community.windows 1.1.0 to 1.6.0 that there has been a major change to how this module is handling computer_name:
Namely, right before I updated it, I tested the playbook and it ran without incident.
immediately after, I ran it, and failures abound.
Using module file /root/.ansible/collections/ansible_collections/community/windows/plugins/modules/win_dns_record.ps1
Pipelining is enabled.
< Windows_ansible_host.DOMAIN.net > ESTABLISH WINRM CONNECTION FOR USER:
SA_REDACTED_Domain@DOMAIN.NET
on PORT 5986 TO
l1pnchwmgt12.columbuschildrens.net
EXEC (via pipeline wrapper)
ok: [Windows_ansible_host.DOMAIN.net] => {
“changed”: false,
“invocation”: {
“module_args”: {
“computer_name”: “
DNSserverredacted.DOMAIN.net
”,
“name”: “deleteme”,
“port”: null,
“priority”: null,
“state”: “present”,
“ttl”: 3600,
“type”: “A”,
“value”: [
“10.60.24.121”
“weight”: null,
“zone”: “
DOMAIN.net
”
The above are the results for what worked in 1.1.0.
Immediately after update, it appears that the Computer_name: field is being entirely ignored and this module is trying to process the request locally, seeing as my ansible node isn’t a DNS server, domain controller, or anything special, its failing every time with a complete inability to find the DNS Zone, duh.
The full traceback is:
Failed to get the zone information for
DOMAIN.net
on server Windows_ansible_host.
At line:73 char:12
$records = Get-DnsServerResourceRecord -ZoneName $zone -Name $name -R …
CategoryInfo : NotSpecified: (
columbuschildrens.net
:root/Microsoft/…rResourceRecord) [Get-DnsServerResourceRecord], CimException
FullyQualifiedErrorId : WIN32 1722,Get-DnsServerResourceRecord
ScriptStackTrace:
at Get-DnsServerResourceRecord, : line 3130
at , : line 73
Microsoft.Management.Infrastructure.CimException: Failed to get the zone information for
DOMAIN.net
on server Windows_ansible_host.DOMAIN.
Am I mishandling something here?
I’ve attempted FQDN, NetBios name and IP addr for computer_name, and nothing is successful.
it is a VERY simplistic playbook for simply testing the module that it will work.
I can post it if necessary.
Thanks
That issue appears to have been fixed in the collection, but the change has not been included in a release yet:
https://github.com/ansible-collections/community.windows/pull/277
Howdy,
I am also seeing this issue.
chris:~/git/ansible$ ansible -m community.windows.win_dns_record -a “type=CNAME computer_name=‘dc1.example.local’ name=myapp zone=‘
internal.example.co.uk
’ ttl=60 value=‘docker1.example.local’” -i inventory/test.yml admgmthost -vvv
ansible [core 2.11.5]
config file = /home/chris/git/ansible/ansible.cfg
configured module search path = [‘/home/chris/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’]
ansible python module location = /home/chris/git/.venv/lib/python3.8/site-packages/ansible
ansible collection location = /home/chris/git/ansible/installed_collections
executable location = /home/chris/git/.venv/bin/ansible
python version = 3.8.10 (default, Jun 2 2021, 10:49:15) [GCC 9.4.0]
jinja version = 3.0.1
libyaml = True
Using /home/chris/git/ansible/ansible.cfg as config file
host_list declined parsing /home/chris/git/ansible/inventory/test.yml as it did not pass its verify_file() method
script declined parsing /home/chris/git/ansible/inventory/test.yml as it did not pass its verify_file() method
Parsed /home/chris/git/ansible/inventory/test.yml inventory source with yaml plugin
Skipping callback ‘default’, as we already have a stdout callback.
Skipping callback ‘minimal’, as we already have a stdout callback.
Skipping callback ‘oneline’, as we already have a stdout callback.
META: ran handlers
Using module file /home/chris/git/.venv/lib/python3.8/site-packages/ansible_collections/community/windows/plugins/modules/win_dns_record.ps1
Pipelining is enabled.
<admgmthost.example.local> ESTABLISH WINRM CONNECTION FOR USER: example\service.ansible on PORT 5985 TO admgmthost.example.local
EXEC (via pipeline wrapper)
The full traceback is:
Failed to get the zone information for
internal.example.co.uk
on server admgmthost.
At line:73 char:12
$records = Get-DnsServerResourceRecord -ZoneName $zone -Name $name -R …
CategoryInfo : NotSpecified: (
internal.example.co.uk
:root/Microsoft/…rResourceRecord) [Get-DnsServerResourceRecord], CimException
FullyQualifiedErrorId : WIN32 1722,Get-DnsServerResourceRecord
ScriptStackTrace:
at Get-DnsServerResourceRecord, : line 4075
at , : line 73
Microsoft.Management.Infrastructure.CimException: Failed to get the zone information for
internal.example.co.uk
on server admgmthost.
at Microsoft.Management.Infrastructure.Internal.Operations.CimAsyncObserverProxyBase`1.ProcessNativeCallback(OperationCallbackProcessingContext callbackProcessingContext, T currentItem, Boolean moreResults, MiResult operationResult, String errorMessage, InstanceHandle errorDetailsHandle)
admgmthost | FAILED! => {
“changed”: false,
“msg”: “Unhandled exception while executing module: Failed to get the zone information for
internal.example.co.uk
on server admgmthost.”
I have verified that the ps1 file looks correct located at: /home/chris/git/.venv/lib/python3.8/site-packages/ansible_collections/community/windows/plugins/modules/win_dns_record.ps1
(It appears to have the changes in the above-mentioned PR:
https://github.com/ansible-collections/community.windows/pull/277
)
Installed 1.7.0 of the ansible.windows collection.
Re-created the Get-DNSServerResourceRecord command used here and ran on a windows machine via winrm to the same admgmthost server with no issue. Also ran find on the host machine logged in as the service.ansible user. Interestingly, if I omit the -ComputerName switch in the powershell replicas I get the same response. However, it appears as though the variables are being set correctly in the win_dns_record.ps1 file… unless I missed something
Any thoughts?
Cheers
Chris
I should add that we’ve been using this in various playbooks for a while now. It mysteriously stopped working some time between the 9th of August and the 21st of September. Although, that is quite dependant on when our ansible build process ran and picked up new dependency versions.
Cheers
Chris
Ok, after finding the last version of my ansible container that worked and digging around in the galaxy collection versions. I managed to fix it by installing the collection community.windows at version 1.5.0,
This should keep me going for now
Although I’m interested to know if I can help troubleshoot the issue (or indeed if a newer version will also work)
Cheers
Chris