RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2166326 - Removing the last DNS type for ipa-ca does not work.
Summary: Removing the last DNS type for ipa-ca does not work.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: ipa
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Florence Blanc-Renaud
QA Contact: Sudhir Menon
URL:
Whiteboard:
Depends On: 2158775
Blocks: 2099484
TreeView+ depends on / blocked
 
Reported: 2023-02-01 13:42 UTC by Rob Crittenden
Modified: 2023-05-09 08:26 UTC (History)
6 users (show)

Fixed In Version: ipa-4.10.1-5.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2158775
Environment:
Last Closed: 2023-05-09 07:33:20 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-9396 0 None None None 2023-02-01 13:44:12 UTC
Red Hat Issue Tracker RHELPLAN-147304 0 None None None 2023-02-01 13:44:21 UTC
Red Hat Product Errata RHBA-2023:2205 0 None None None 2023-05-09 07:33:35 UTC

Description Rob Crittenden 2023-02-01 13:42:32 UTC
+++ This bug was initially created as a clone of Bug #2158775 +++

Description of problem: Removing the last DNS type for ipa-ca does not work.


Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:1. Install a server
2. In my manual test the server IPv6 address WAS added to ipa-ca so I used ipa dnsrecord-del to remove it
3. Install a client
4. Install a replica with --setup-ca
5. ipa server-del replica
6. dig -t AAAA ipa-ca.DOMAIN

Actual results:
The replica AAAA record is listed.

Expected results:


Additional info:

--- Additional comment from Florence Blanc-Renaud on 2023-01-06 15:15:26 UTC ---

Sudhir, can you add a bit more info?

> 1. Install a server
which options are provided? Is --ip-address provided (with IPv4, with IPv6)?

> 2. In my manual test the server IPv6 address WAS added to ipa-ca so I used ipa dnsrecord-del to remove it
Was the server IPv6 address also added to the server DNS records?

> 3. Install a client
> 4. Install a replica with --setup-ca
Is --ip-address provided (with IPv4, IPv6)?

> 5. ipa server-del replica
> 6. dig -t AAAA ipa-ca.DOMAIN
>
> Actual results:
> The replica AAAA record is listed.

--- Additional comment from Rob Crittenden on 2023-01-06 15:41:54 UTC ---

Flo, for clarity the failing test we reproduced this with is ipatests/test_integration/test_ipahealthcheck::TestIpaHealthCheck::test_ipahealthcheck_ca_not_configured

Sudir ran the tests and we watched the logs live as the servers were installed.

The initial server created only a DNS A record for ipa-ca.

The replica was installed via promotion, so client install first, then ipa-replica-install --setup-ca.

This added both an A and an AAAA record for ipa-ca.

Based on the servers install logs:

ipa-server-install: no address was passed in
ipa-replica-install: the IPv4 address was passed in

One major difference is the order in which ipa-client-install is executed. The replica runs it first so there are already A and AAAA records for itself when the server install completes and I suspect that is why the AAAA record is added to ipa-ca (not that this is wrong).

But there is still an issue in ipa-ca cleanup. My working assumption is that the last record of a given type gets orphaned.

I suppose there is also a bug in that the initial install doesn't get an IPv6 address in ipa-ca.

DNS looked like this after the replica install was completed:

# dig -t A ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      A       0.0.0.83
ipa-ca.example.test.  1       IN      A       0.0.0.175

# dig -t AAAA ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      AAAA    aaaa:52:0:a9:f816:3eff:fe3a:951b

The test uninstalls the replica and then re-installs it without a CA. The same queries post install look like:

# dig -t A ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      A       0.0.0.83

# dig -t AAAA ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      AAAA    aaaa:52:0:a9:f816:3eff:fe3a:951b

So the IPv6 address got left behind somehow.

--- Additional comment from Florence Blanc-Renaud on 2023-01-06 16:01:08 UTC ---

Rob, thanks for the clarifications.
Could this be somehow related to https://pagure.io/freeipa/issue/9195, for which there is a PR in progress https://github.com/freeipa/freeipa/pull/6358 Wipe the ipa-ca DNS record when updating system records ?

--- Additional comment from Rob Crittenden on 2023-01-06 16:50:53 UTC ---

Yes, it could be the same issue. I've started working on the the PR again.

Comment 4 Rob Crittenden 2023-02-09 19:25:57 UTC
Fixed upstream
master:
https://pagure.io/freeipa/c/c38546d0853c97e2a6ad9868d0c7020bc0f9f586

Comment 12 errata-xmlrpc 2023-05-09 07:33:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (ipa bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2205


Note You need to log in before you can comment on or make changes to this bug.