neoave / mrack

Multicloud use-case based multihost async provisioner for CIs and testing during development
Apache License 2.0
11 stars 14 forks source link

feat: Add read-only flag for windows domain controllers #179

Closed danlavu closed 2 years ago

danlavu commented 2 years ago

Add read-only flag from metadata to inventory which can be used later for windows domain controllers

pvoborni commented 2 years ago

What it should be used for? Does it has any special semantic meaning that is has to be hardcoded here?

Tiboris commented 2 years ago

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

pvoborni commented 2 years ago

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.

Tiboris commented 2 years ago

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
Tiboris commented 2 years ago

This could be possibly replaced by generic : https://github.com/neoave/mrack/pull/180

Tiboris commented 2 years ago

Thanks @sidecontrol we will use the generic one, from user perspective in this particular use case nothing is changing.

danlavu commented 2 years ago

Thanks, that works!