https://bugzilla.redhat.com/show_bug.cgi?id=815145 (Red Hat Enterprise Linux 6)
Request to add an enable/disable IPA server command to the "ipa" CLI. It's causing long waits with clients such as pam_krb5 and other client tools when there is an issue with an IPA server, such as a hardware fault, requiring the IPA server to be unavailable for an extended period of time. For such a case it's not wanted to remove the entire replica. In this case it would be very useful to easily be able to remove this servers ldap and kerberos SRV entries in DNS. I would suggest a command such as: ipa dns-disable-ipa IPA-SERVER-FQDN --dns-zone=STR ipa dns-enable-ipa IPA-SERVER-FQDN --dns-sone=STR --priority=INT --weight=INT Where the "dns-zone" is optional. specifying what DNS zone to add/remove entries from, if not the default dns zone. The "priority" and "weight" options are optional and directly related to their function in the SRV DNS records for when the SRV records are added back in. The dns-enable-ipa command should also be accepted with new values for "priority" and "weight" if the DNS SRV records for the specified IPA server already exists.
This feature would require a schema change. We do not have an attribute in the entry to denote whether it is enabled or disabled. It would also require changes to ldap driver, CLI and UI. Overall a major effort this I think it should be in the 3.3 Backlog. Pushing to needs triage for now.
Dmitri I think you took the feature request a little too literally.
The request is to disable IPA servers in DNS in the sense that they are not made available anymore in DNS records, this is relatively simple to do all is needed is to delete the relative records, and just re-add them once the server is back to working. The ipa command is needed because ipa servers have more than just an A record, they also have SRV records, so a simple command that properly removes/populates all necessary records would help a lot.
Removing SRV records is simple and has no real consequences, however removing the A record will cause replicas to fail to replicate until it is re-instated. I am not sure this is a problem, after all this feature is requested for when the replica has issues, but needs to be taken into consideration if we want to remove also the A record.
If we discount removing the A record we could also use a different name for the commands hinting that what we are doing is making the server undiscoverable, this is something that people may want to do also for real functioning replica that admins amy want to keep as 'shadows' and use mostly as a way to work as a sort of hub for replication and other similar purposes, like deidcating a replica to a specific subset of machines and not advertising in with SRV records so to avoid other random clients to try to connect to it.
HTH.
Replying to [comment:4 simo]: ...
Why do we consider removing replica A records? I thought that the Bug was only about removing broken server FQDN/relative name from IPA domain SRV records... But you are right that it should not be a too big change in our DNS plugin.
I do not like the idea of removing records because it is hard to restore them later. I was thinking about a different approach. If we have an enabled/disable attribute in the entry we can then make the ldap driver ignore the disabled entries.
It is IMO more elegant solution than deleting and restoring things.
Another idea that came to mind is to move the records out of the tree. Create a container parallel to the one that is currently used by DNS records. cn=disabledservers. Then on the provided "disable" command move all the DNS records related to the server from the normal container to that container. On the enable operation do the reverse. This might be a less intrusive change.
What's the benefit of keeping them around ?
I see DNS being pretty sensitive and fragile. If something is misconfigure the hell breaks loose. So if you have a working server with all the right entries that you need to temporarily take offline I would prefer hiding and unhiding (disabling/enabling or moving around) the entries rather than deleting and recreating. Just less probably that something would go wrong when the system comes back.
The problem is that most of the values you want to really disable are not in their own record but are in 'common' records like the SRV record _ldap._tcp.ipa.example.com In order to be able to disable only one of the servers referenced by the SRV record you'd have to disable a single attribute in the SRV record object. That's not something we can easily do. The only records you could actually disable are the A records, but they are the least important to disable. They are only really relevant if you have hosts that directly reference the server name, in most cases where discovery is used you can leave the A records and only remove the SRV records.
I thought that every SRV record is a separate record. Is this not the case? Can/should they be separate?
Each SRV record is a separate object, but each SRV record references multiple servers. I have a test zone with a number of server: red, blue, green, yellow, purple, orange
This is an example for the SRV record _ldap._tcp.test.ipa:
$ dig -t SRV _ldap._tcp.test.ipa @192.168.1.2 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.3 <<>> -t SRV _ldap._tcp.test.ipa @192.168.1.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42744 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 1, ADDITIONAL: 6 ;; QUESTION SECTION: ;_ldap._tcp.test.ipa. IN SRV ;; ANSWER SECTION: _ldap._tcp.test.ipa. 86400 IN SRV 0 100 389 orange.test.ipa. _ldap._tcp.test.ipa. 86400 IN SRV 0 100 389 red.test.ipa. _ldap._tcp.test.ipa. 86400 IN SRV 0 100 389 blue.test.ipa. _ldap._tcp.test.ipa. 86400 IN SRV 0 100 389 green.test.ipa. _ldap._tcp.test.ipa. 86400 IN SRV 0 100 389 yellow.test.ipa. _ldap._tcp.test.ipa. 86400 IN SRV 0 100 389 purple.test.ipa. ;; AUTHORITY SECTION: test.ipa. 86400 IN NS red.test.ipa. ;; ADDITIONAL SECTION: red.test.ipa. 86400 IN A 0.0.0.1 blue.test.ipa. 86400 IN A 0.0.0.2 green.test.ipa. 86400 IN A 0.0.0.3 yellow.test.ipa. 86400 IN A 0.0.0.4 purple.test.ipa. 86400 IN A 0.0.0.5 orange.test.ipa. 86400 IN A 0.0.0.6
And this is how it looks like in ldap:
objectClass: top objectClass: idnsrecord sRVRecord: 0 100 389 red sRVRecord: 0 100 389 blue sRVRecord: 0 100 389 green sRVRecord: 0 100 389 yellow sRVRecord: 0 100 389 purple sRVRecord: 0 100 389 orange idnsName: _ldap._tcp
A single object with one attribute per server.
My request was for removing and adding the IPA server in question from/to the ldap/krb srv records only, leaving the rest of the records for the server untouched.
I hope this feature will be implemented in this way as I am not yet using the bind-dyndb plugin on the busiest DNS servers due to the instability I've had with it. I am using a perl script I wrote to dump all the entries from LDAP into flat zone files where I use bind to serve the flat files.
Moving my tickets back to free-to-take pool.
Metadata Update from @mkosek: - Issue assigned to someone - Issue set to the milestone: Ticket Backlog
Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.