win_dns_client should support DNS suffix
SUMMARY
I'm trying to add a dns suffix on a windows server machine which is NOT in a domain. win_dns_client does not support that unfortunately
ISSUE TYPE
- Feature Idea
COMPONENT NAME
ansible.windows.win_dns_client
ADDITIONAL INFORMATION
Doable with Get-DnsClientGlobalSetting and Set-DnsClientGlobalSetting
https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientglobalsetting https://learn.microsoft.com/en-us/powershell/module/dnsclient/set-dnsclientglobalsetting
@mohag it looks like the call to ListBuckets is superfluous when name is provided.
I tried to fix it with #2184, could you please give it a try ?
That does work yes, thanks!
TASK [mongodb : If we have a bucket and no endpoint / region, fetch the endpoint from AWS] ******************************************************************************************************************************************
task path: /home/gertvdb/src/<removed>/ansible/roles/mongodb/tasks/pbm.yml:290
ok: [mongo.qa1.<removed>] => {
"bucket_name": "<removed>-backup-us-east-1-59c5daac",
"buckets": [
{
"bucket_location": {
"LocationConstraint": "us-east-1"
},
"name": "<removed>-backup-us-east-1-59c5daac"
}
],
"changed": false
}
MSG:
Retrieved s3 info.
I installed the collection from git+https://github.com/abikouo/amazon.aws.git,s3_buckect_issue_2183
I also have a workaround that requires no bucket permissions / boto3 installation... (S3 redirects to the correct region for a bucket even without permissions, It also returns the correct region in a header, we use that here)
- name: Check the correct region from the "wrong endpoint" error message
ansible.builtin.uri:
url: "https://s3.dualstack.us-east-1.amazonaws.com/{{ backup_s3_bucket }}"
follow_redirects: none
status_code:
- 301 # Wrong region
- 403 # Correct region
register: region_check_request
when:
- backup_s3_endpoint is not defined
- backup_s3_region is not defined
- backup_s3_bucket is defined
- backup_s3_bucket != ''
- name: Get correct region from header on response
ansible.builtin.set_fact:
backup_s3_region: "{{ region_check_request.x_amz_bucket_region }}"
when:
- backup_s3_endpoint is not defined
- backup_s3_region is not defined
- backup_s3_bucket is defined
- backup_s3_bucket != ''
```
I also have a workaround that requires no bucket permissions / boto3 installation... (S3 redirects to the correct region for a bucket even without permissions, this uses that)
In theory it would be possible to implement all of our modules without technically requiring boto3 (they're just calling an HTTP based API after all...). However, doing so would result in a massive amount of duplicate code. While I can see your use case, and I understand where you're coming from, there comes a point of diminishing returns.
Similarly, when it comes to working around missing permissions on a bucket, I can see the value in making the list_buckets call optional (technically it's not superfluous, it's returning creation_date too), but hacking around missing GetBucketLocation is something to poke Amazon about, not something we should be adding here. There's also no guarantee that at some point Amazon won't close that loophole.
I also have a workaround that requires no bucket permissions / boto3 installation... (S3 redirects to the correct region for a bucket even without permissions, this uses that)
In theory it would be possible to implement all of our modules without technically requiring boto3 (they're just calling an HTTP based API after all...). However, doing so would result in a massive amount of duplicate code. While I can see your use case, and I understand where you're coming from, there comes a point of diminishing returns.
Similarly, when it comes to working around missing permissions on a bucket, I can see the value in making the list_buckets call optional (technically it's not superfluous, it's returning creation_date too), but hacking around missing
GetBucketLocationis something to poke Amazon about, not something we should be adding here. There's also no guarantee that at some point Amazon won't close that loophole.
I agree that that workaround does not make sense in the module, but it might be useful for someone else (and I have somewhere that I can find it was well in the future) (It was mainly my solution before the change to get rid of ListBuckets) (I currently install boto3 / botocore on the managed nodes just for this one step, so I'm thinking of keeping it)
Edit: The updated version no longer need xmltodict (It uses a header instead of parsing the response)