It is possible to install a replica with DNS support even if there is no DNS support in (any of) the server(s).
From the discussion with Alexander:
<twoerner__> which differences are allowed with DL1? <twoerner__> for the replica <twoerner__> everything? <ab> I think so <ab> I mean, you can deploy without CA even if original one was CA <ab> you can deploy without ad trust <ab> dns, etc <twoerner__> yes, but why the other way around also? <ab> with DL0 you've got a replica file from the master <ab> so that defined which services are there <ab> with DL1 you start with a client or even non-enrolled <ab> thus you decide which ones to go with <ab> there is no inherent limit <twoerner__> but for example the server without DNS and the replica with DNS was a major issue in the tests I have done as the clients have been useless after uninstalling the replica as the server was not able to serve as a DNS server also <ab> that's different <ab> so you have master without integrated DNS, this means something else already provides you a DNS <ab> if you add replica with DNS this doesn't really change the situation <twoerner__> hmmm <ab> if you uninstalled replica, you supposedly have external DNS anyway <ab> if you didn't have external DNS before installing replica, that's deployment design fault <twoerner__> yes, but maybe without reverse mapping <ab> because while a single server is self-sufficient, any additional client would require working DNS setup <twoerner__> ok - I expected this to be a bit more error-save <twoerner__> error-safe :-) <ab> you literally don't know how DNS deployment is organized when you are a client <ab> you just have DNS entries in /etc/resolv.conf, that's all <twoerner__> yes <ab> nothing we could do technically <ab> perhaps, for replica uninstall we could verify that if we were DNS server role owner and none would be left after unenrollment, we can warn about that <twoerner__> shouldn't there be at least a warning that the DNS server in the replica will not be propagated to the server? <twoerner__> ab there is a warning about the replica for uninstall.. <ab> I'm not sure we can do the same for other roles except CA <twoerner__> but this does not help if the replica simply died <ab> this definitely needs to go into deployment documentation (considerations) <twoerner__> this at least might help <twoerner__> personally I do not see a reason why there should be a DNS server in a replica only - maybe I am missing some inforamtion here <twoerner__> or I do not know about the use case for this scenario <ab> well, I think also if you started with external DNS, you continue with that <ab> they are practically exclusive configurations <ab> because of the concept of zone ownership <twoerner__> in my opinion the replica installation should complain before setting up the DNS if the server is not also providing the DNS sever <ab> while all IPA masters report that they own the DNS zone, you cannot have external DNS owning what is owned by IPA and vice versa <ab> no, you can have replicas without DNS, that's fine <ab> as long as one of masters is DNS <ab> or none of them is <ab> the latter is external DNS case <twoerner__> yes, without DNS is fine.. <ab> however, if 'ipa server-role-find --role="DNS server"' returns an entry, we have integrated DNS <ab> there might be more than one, of course <twoerner__> sure <ab> I mean, this gives us a bit of criteria <ab> installing replica: if that command returns 0 entries against the master, if we were asked to deploy DNS, refuse <ab> because this is a mixture of external/integrated <ab> of course, this could be possible too, but then we would need to check if external DNS zone is authoritative or not <ab> e.g. if that one is not authoritative, we can deploy DNS <ab> because this simply means someone is moving to integrated DNS and external zone would be a secondary source <ab> but that's too much logic <ab> may be needed, may be not <ab> it is worth to file a ticket and discuss
Do you see a use case where it might make sense to have the DNS server in a replica only without having a server/replica up in the topology with DNS support?
Additional question here is if this can be seen as an issue for other things that can be enabled in the replica only without being activated in the server.
The best practices advise to configure all the needed roles on at least 2 servers in order to avoid single point of failure (DNS, CA, KRA, AD trust controller/agent). When only one master/replica is providing a given role and this master/replica is uninstalled, a warning is displayed about leaving the topology without xx role.
In domain-level 1, if the first master is configured without a given role, it is however possible to install a replica and add the DNS/CA/KRA/AD trust role to the replica, even if the master does not provide this role. The role is properly working but this creates a topology with a single point of failure. In order to avoid the SPOF, the role can be configured on the first master or on another replica. IPA does not care if a role is installed on the first master or on a replica.
So to answer your specific questions:
Yes, because the DNS functionality will be provided by the replica. But we advise to configure a 2nd machine with the DNS in order to avoid SPOF.
No issue because once a replica is installed, he can be enabled for any server role even if this role is not present on the master (for instance become a CA or AD trust controller).
Does this address your concerns?
O.k. this is very flexible, but also could result in loosing the overview quickly. Are there tools that are giving an overview over the topology with all the things that are enabled in the nodes? Especially something that would show where the SPOFs are in the topology?
You can query the server role plugin to get a list of servers for each role.
I think we need more details on exactly how you uninstalled the replica.
It should already fail if the last role is removed at least for CA and DNS.
All masters are equals, there is none above the others. The only exceptions are the optional services installed and which one is designated as the CRL and replication manager.
I'm going to close this as invalid.
Metadata Update from @rcritten: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.