Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPADNSSystemRecordsCheck displays warning message for 2 expected ipa-ca AAAA records. #270

Closed
menonsudhir opened this issue Jun 17, 2022 · 5 comments

Comments

@menonsudhir
Copy link

menonsudhir commented Jun 17, 2022

ipa-server and ipa-replica have been installed using ipv4 and ipv6 address, but when healthcheck test is run it displays WARNING message as below

#ipa-server-install --setup-dns --forwarder=ipv4-add -a password -p pasword -n testrealm.test -r TESTREALM.TEST --hostname server.testrealm.test --ip-address=ipv6-add --auto-reverse -U

#ipa-replica-install --setup-dns --forwarder=ipv4-add --realm TESTREALM.TEST -n testrealm.test -w password --setup-ca -P admin --ip-address=ipv4-add --server=server.testrealm.test -v --ip-address=ipv6-add -U --skip-conncheck

[root@server ~]# ipa dnsrecord-find
Zone name: testrealm.test
Record name: @
NS record: server.testrealm.test., replica.testrealm.test.

Record name: _kerberos
TXT record: "TESTREALM.TEST"
URI record: 0 100 "krb5srv:m:tcp:server.testrealm.test.", 0 100 "krb5srv:m:udp:server.testrealm.test.", 0 100 "krb5srv:m:tcp:replica.testrealm.test.", 0 100 "krb5srv:m:udp:replica.testrealm.test."

Record name: _kpasswd
URI record: 0 100 "krb5srv:m:tcp:server.testrealm.test.", 0 100 "krb5srv:m:udp:server.testrealm.test.", 0 100 "krb5srv:m:tcp:replica.testrealm.test.", 0 100 "krb5srv:m:udp:replica.testrealm.test."

Record name: _kerberos._tcp
SRV record: 0 100 88 server.testrealm.test., 0 100 88 replica.testrealm.test.

Record name: _kerberos-master._tcp
SRV record: 0 100 88 server.testrealm.test., 0 100 88 replica.testrealm.test.

Record name: _kpasswd._tcp
SRV record: 0 100 464 server.testrealm.test., 0 100 464 replica.testrealm.test.

Record name: _ldap._tcp
SRV record: 0 100 389 server.testrealm.test., 0 100 389 replica.testrealm.test.

Record name: _kerberos._udp
SRV record: 0 100 88 server.testrealm.test., 0 100 88 replica.testrealm.test.

Record name: _kerberos-master._udp
SRV record: 0 100 88 server.testrealm.test., 0 100 88 replica.testrealm.test.

Record name: _kpasswd._udp
SRV record: 0 100 464 server.testrealm.test., 0 100 464 replica.testrealm.test.

Record name: ipa-ca
A record: replica-add
AAAA record: replica-ipv6-add, server-ipv6-add

Record name: replica
A record: replica-ipv4-add
AAAA record: replica-ipv6-add
SSHFP record:

Record name: server
AAAA record: server-ipv6-add
SSHFP record:
Number of entries returned 13


#ipa-healthcheck --failures-only
{
"source": "ipahealthcheck.ipa.idns",
"check": "IPADNSSystemRecordsCheck",
"result": "WARNING",
"uuid": "5fe925f2-6bd5-411c-9a0d-352d850b792c",
"when": "20220617143708Z",
"duration": "0.038578",
"kw": {
"msg": "Got {count} ipa-ca A records, expected {expected}",
"count": 1,
"expected": 2
}

@flo-renaud
Copy link
Contributor

The issue happens when IPv4 or IPv6 is configured on one server but not on all the servers.
Relevant code:

ca_count = 0
for server in system_records.servers_data:
master = system_records.servers_data.get(server)
if 'CA server' in master.get('roles'):
ca_count += 1
if len(answers) != ca_count:

and
ca_count = 0
for server in system_records.servers_data:
master = system_records.servers_data.get(server)
if 'CA server' in master.get('roles'):
ca_count += 1
if len(answers) != ca_count:

ca_count is incremented for each server with the CA role, not considering that the server could have either IPv4 or IPv6 disabled. The code assumes all-or-nothing: if one server has an IPv4 address, all the other ones are expected to also have an IPv4 address and ipa-ca should contain an A record for each server with the CA role. Same for IPv6.

@rcritten
Copy link
Collaborator

This is working as designed. There is no way to know at execution time whether this is on purpose or not. A missing ipa-ca record can impact ACME in particular. Hence it is marked as a WARNING.
If this does not apply to an installation the result can be excluded via configuration.

@flo-renaud
Copy link
Contributor

IMO it's also possible to avoid the warning, if the logic is replaced with the following:

  • if there is at least one a_rec:
    • loop on the system_records.servers_data
      • if the server has 'CA server role':
      • increment ca_count with the number of A records for the server
    • compare ca_count with len(ipa-ca A records)

For instance, let's imagine serverA has 1 A record, server B none, serverC one, and the 3 servers have the CA role. We should expect 1+0+1 ipa-ca A records.
Other example, serverA has 1 record, serverB none, serverC one but serverC doesn't have the CA role, we should expect 1+0+0 ipa-ca A record.

Same logic can be applied to ipa-ca AAAA records.

rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Jul 6, 2022
The previous method counted the number of servers with CA's and
expected an identical count of servers in ipa-ca, for each of the
A and AAAA types.

If one server had only A or AAAA records then this count could be
off and issue a spurious warning.

Instead get the list of A and AAAA records for servers with a CA
and compare the IP addresses to those of the A and AAAA records
of ipa-ca. Return a warning if any are missing or not expected
(e.g. a server was removed but remains in ipa-ca).

freeipa#270

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
@rcritten
Copy link
Collaborator

rcritten commented Jul 6, 2022

Rather than doing a count I compare the expected and actual records and report those taht don't match expectations. It is a rather radical change.

@rcritten
Copy link
Collaborator

rcritten commented Jul 6, 2022

It looks like dns-update-system-records doesn't handle removing the last IP type. I opened IPA issue https://pagure.io/freeipa/issue/9195

rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Jul 6, 2022
The previous method counted the number of servers with CA's and
expected an identical count of servers in ipa-ca, for each of the
A and AAAA types.

If one server had only A or AAAA records then this count could be
off and issue a spurious warning.

Instead get the list of A and AAAA records for servers with a CA
and compare the IP addresses to those of the A and AAAA records
of ipa-ca. Return a warning if any are missing or not expected
(e.g. a server was removed but remains in ipa-ca).

freeipa#270

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Jul 6, 2022
The previous method counted the number of servers with CA's and
expected an identical count of servers in ipa-ca, for each of the
A and AAAA types.

If one server had only A or AAAA records then this count could be
off and issue a spurious warning.

Instead get the list of A and AAAA records for servers with a CA
and compare the IP addresses to those of the A and AAAA records
of ipa-ca. Return a warning if any are missing or not expected
(e.g. a server was removed but remains in ipa-ca).

freeipa#270

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
menonsudhir added a commit to menonsudhir/freeipa that referenced this issue Aug 4, 2022
Certain healthcheck realted checks are failing since
the testenviornment contains IPV6 addressess as a result
the tests have been skipped till the issue is fixed.

Related:
freeipa/freeipa-healthcheck#270

Signed-off-by: Sudhir Menon <sumenon@redhat.com>
menonsudhir added a commit to menonsudhir/freeipa that referenced this issue Aug 5, 2022
Certain healthcheck realted checks are failing since
the testenviornment contains IPV6 addressess as a result
the tests have been skipped till the issue is fixed.

Related:
freeipa/freeipa-healthcheck#270

Signed-off-by: Sudhir Menon <sumenon@redhat.com>
rcritten added a commit that referenced this issue Oct 17, 2022
The previous method counted the number of servers with CA's and
expected an identical count of servers in ipa-ca, for each of the
A and AAAA types.

If one server had only A or AAAA records then this count could be
off and issue a spurious warning.

Instead get the list of A and AAAA records for servers with a CA
and compare the IP addresses to those of the A and AAAA records
of ipa-ca. Return a warning if any are missing or not expected
(e.g. a server was removed but remains in ipa-ca).

#270

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants