Closed danlavu closed 2 years ago
What it should be used for? Does it has any special semantic meaning that is has to be hardcoded here?
The idea is to have a way to specify the extra information in metadata, in this case read-only, that can be later read from inventory for the plays. The name itself - read-only - suppose to mark the system to be used later as read-only DC for windows domains. I know the flag itself is not needed for provisioning at all but from the output perspective if we can leverage this and have the inventory with some specifics which ease the later use of the inventory and data in it.
I was thinking about having another group which will be something like ad_root_read_only or similar which we could distinguish in later automation and use another ansible block to handle this group. (this change in this case would not be needed)
however these 2 lines ease the automation for the DC install:
- hosts: ad_rootbackup
tasks:
- name: Promote server to a domain controller in the root domain
win_domain_controller:
dns_domain_name: "{{ meta_domain }}"
domain_admin_user: "{{ ansible_user }}@{{ meta_domain }}"
domain_admin_password: "{{ ansible_password }}"
safe_mode_password: "{{ ansible_password }}"
read_only: "{{ meta_read_only | default('no') }}"
state: domain_controller
register: join_domain_result
alternatively we could do this, but with more additions to the provisioning config - defining the group etc:
- hosts: ad_rootbackup:ad_root_read_only
tasks:
- name: Set fact when DC needs to be read olny
set_fact:
read_only_dc: "yes"
when: groups["ad_root_read_only"] is defined and meta_hostname is in groups["ad_root_read_only"]
- name: debug read_only_dc
debug: msg={{ read_only_dc | default(false) }}
- name: Promote server to a domain controller in the root domain
win_domain_controller:
dns_domain_name: "{{ meta_domain }}"
domain_admin_user: "{{ ansible_user }}@{{ meta_domain }}"
domain_admin_password: "{{ ansible_password }}"
safe_mode_password: "{{ ansible_password }}"
read_only: "{{ read_only_dc | default(false) }}"
state: domain_controller
register: join_domain_result
according to https://docs.ansible.com/ansible/latest/collections/ansible/windows/win_domain_controller_module.html this should work as well
In the playbook, it is also possible to get the information from metadata file directly. But yes, it is not that convenient (one would need to iterate over domains to find the current host) and it would probably needs some supporting functionality to have it convenient (to have direct access).
Thus I understand why this is wanted but that said I'm not a big fan of this as it is for single purpose and in time ppl will forget why it was added (as e.g. there is not doc, no supporting information in the commit message). Thus later it will be misused and some workloads will get broken as a result.
What about some more general which could be use also for other stuff (thus having bigger value).
When ppl define in host part of job metadata file an attribute prefixed with, e.g. meta_
, then all of those attributes will get copied into ansible inventory file.
So one could have
domains:
- name: example.test
type: ipa
hosts:
- name: server.example.test
role: ad
group: ad
os: win-2022
meta_readonly_dc: yes
meta_something_else: for_fun
Then this value would get propagated for the host to the inventory and it would be directly usable.
Btw, for the group use-case. I'm not sure if needs any provisioning-config changes. We can defined multiple groups per host via groups
var.
This very good idea to have some fields in metadata that will be reflected in ansible inventory... So idea what about we add ansible_inventory
key to the host section and we loop through all the keys of this dict and just copy values to the ansible_inventory?
domains:
- name: example.test
type: ipa
hosts:
- name: server.example.test
role: ad
group: ad
os: win-2022
ansible_inventory:
readonly_dc: yes
something_else: for_fun
which could result to records in ansible_inventory.yaml
:
meta_readonly_dc: yes
meta_something_else: for_fun
This could be possibly replaced by generic : https://github.com/neoave/mrack/pull/180
Thanks @sidecontrol we will use the generic one, from user perspective in this particular use case nothing is changing.
Thanks, that works!
Add read-only flag from metadata to inventory which can be used later for windows domain controllers