25.2. Specifying the base, server and client variables for installing the IdM replica

Procedure

1. Open the inventory file for editing. Specify the fully-qualified domain names (FQDN) of the hosts to become IdM replicas. The FQDNs must be valid DNS names:

   • Only numbers, alphabetic characters, and hyphens (-) are allowed. For example, underscores are not allowed and can cause DNS failures.

   • The host name must be all lower-case.

     Example of a simple inventory hosts file with only the replicas' FQDN defined

     [ipareplicas]
     replica1.idm.example.com
     replica2.idm.example.com
     replica3.idm.example.com
     [...]

     If the IdM server is already deployed and the SRV records are set properly in the IdM DNS zone, the script automatically discovers all the other required values.

2. Optional: Provide additional information in the inventory file based on how you have designed your topology:

   Scenario 1

   If you want to avoid autodiscovery and have all replicas listed in the [ipareplicas] section use a specific IdM server, set the server in the [ipaservers] section of the inventory file.

   Example inventory hosts file with the FQDN of the IdM server and replicas defined

   [ipaservers]
   server.idm.example.com
   
   [ipareplicas]
   replica1.idm.example.com
   replica2.idm.example.com
   replica3.idm.example.com
   [...]

   Scenario 2

   Alternatively, if you want to avoid autodiscovery but want to deploy specific replicas with specific servers, set the servers for specific replicas individually in the ipareplicas section in the inventory file.

   Example inventory file with a specific IdM server defined for a specific replica

   [ipaservers]
   server.idm.example.com
   replica1.idm.example.com
   
   [ipareplicas]
   replica2.idm.example.com
   replica3.idm.example.com ipareplica_servers=replica1.idm.example.com

   In the example above, replica3.idm.example.com uses the already deployed replica1.idm.example.com as its replication source.

   Scenario 3

   If you are deploying several replicas in one batch and time is a concern to you, multitier replica deployment can be useful for you. Define specific groups of replicas in the inventory file, for example [ipareplicas_tier1] and [ipareplicas_tier2], and design separate plays for each group in the install-replica.yml playbook.

   Example inventory file with replica tiers defined

   [ipaservers]
   server.idm.example.com
   
   [ipareplicas_tier1]
   replica1.idm.example.com
   
   [ipareplicas_tier2]
   replica2.idm.example.com \ ipareplica_servers=replica1.idm.example.com,server.idm.example.com

   The first entry in ipareplica_servers will be used. The second entry will be used as a fallback option. When using multiple tiers for deploying IdM replicas, you must have separate tasks in the playbook to first deploy replicas from tier1 and then replicas from tier2:

   Example of a playbook file with different plays for different replica groups

   ---
   - name: Playbook to configure IPA replicas (tier1)
     hosts: ipareplicas_tier1
     become: true
   
     roles:
     - role: freeipa.ansible_freeipa.ipareplica
       state: present
   
   - name: Playbook to configure IPA replicas (tier2)
     hosts: ipareplicas_tier2
     become: true
   
     roles:
     - role: freeipa.ansible_freeipa.ipareplica
       state: present

3. Optional: Provide additional information regarding firewalld and DNS:

   Scenario 1

   If you want the replica to use a specified firewalld zone, for example an internal one, you can specify it in the inventory file. If you do not set a custom zone, IdM will add its services to the default firewalld zone. The predefined default zone is public.

   重要

   The specified firewalld zone must exist and be permanent.

   Example of a simple inventory hosts file with a custom firewalld zone

   [ipaservers]
   server.idm.example.com
   
   [ipareplicas]
   replica1.idm.example.com
   replica2.idm.example.com
   replica3.idm.example.com
   [...]
   
   [ipareplicas:vars]
   ipareplica_firewalld_zone=<custom zone>

   Scenario 2

   If you want the replica to host the IdM DNS service, add the ipareplica_setup_dns=true line to the [ipareplicas:vars] section. Additionally, specify if you want to use per-server DNS forwarders:

   • To configure per-server forwarders, add the ipareplica_forwarders variable and a list of strings to the [ipareplicas:vars] section, for example: ipareplica_forwarders=192.0.2.1,192.0.2.2
   • To configure no per-server forwarders, add the following line to the [ipareplicas:vars] section: ipareplica_no_forwarders=true.

   • To configure per-server forwarders based on the forwarders listed in the /etc/resolv.conf file of the replica, add the ipareplica_auto_forwarders variable to the [ipareplicas:vars] section.

     Example inventory file with instructions to set up DNS and per-server forwarders on the replicas

     [ipaservers]
     server.idm.example.com
     
     [ipareplicas]
     replica1.idm.example.com
     replica2.idm.example.com
     replica3.idm.example.com
     [...]
     
     [ipareplicas:vars]
     ipareplica_setup_dns=true
     ipareplica_forwarders=192.0.2.1,192.0.2.2

   Scenario 3

   Specify the DNS resolver using the ipaclient_configure_dns_resolve and ipaclient_dns_servers options (if available) to simplify cluster deployments. This is especially useful if your IdM deployment is using integrated DNS:

   An inventory file snippet specifying a DNS resolver:

   [...]
   [ipaclient:vars]
   ipaclient_configure_dns_resolver=true
   ipaclient_dns_servers=192.168.100.1

   注記

   The ipaclient_dns_servers list must contain only IP addresses. Host names are not allowed.

   For details about all variables used in the playbook, see the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README.md file on the control node.