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

Invalid errors are reported in a CA-less IPA installation #201

Closed
rcritten opened this issue May 11, 2021 · 1 comment
Closed

Invalid errors are reported in a CA-less IPA installation #201

rcritten opened this issue May 11, 2021 · 1 comment
Assignees

Comments

@rcritten
Copy link
Collaborator

Some invalid errors are reported by ipa-healthcheck in a CA-less installation.

This one by healthcheck itself:

  {
    "source": "ipahealthcheck.ipa.roles",
    "check": "IPACRLManagerCheck",
    "result": "CRITICAL",
    "uuid": "17c830ea-7384-4d60-ba52-86bb4991c412",
    "when": "20210511153916Z",
    "duration": "0.000073",
    "kw": {
      "exception": "Unable to read /var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
    }
  },

And a bunch of these by the pki plugin. We may need to filter out this plugin if the CA is not configured.

  {
    "source": "pki.server.healthcheck.certs.expiration",
    "check": "CASystemCertExpiryCheck",
    "result": "CRITICAL",
    "uuid": "8135159e-c551-44ba-89da-5cff80e54c16",
    "when": "20210511153916Z",
    "duration": "0.000104",
    "kw": {
      "msg": "Invalid PKI instance: pki-tomcat"
    }
  },
@rcritten rcritten self-assigned this May 11, 2021
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue May 11, 2021
This was raising a false positive in the IPA CA-less case.

freeipa#201

Signed-off-by: Rob Crittenden <[email protected]>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue May 11, 2021
The pki checks spew the error "Invalid PKI instance: pki-tomcat" so
we need to suppress them in the IPA CA-less installation case.

So if the IPA CA is not configured then don't register the
pki sources.

A side-effect is that to user the sources will not be listed at
all in this case.

This should not affect pki-healthcheck and it will continue to
return errors in the unconfigured case.

freeipa#201

Signed-off-by: Rob Crittenden <[email protected]>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue May 19, 2021
The pki checks spew the error "Invalid PKI instance: pki-tomcat" so
we need to suppress them in the IPA CA-less installation case.

So if the IPA CA is not configured then don't register the
pki sources.

A side-effect is that to user the sources will not be listed at
all in this case.

This should not affect pki-healthcheck and it will continue to
return errors in the unconfigured case.

freeipa#201

Signed-off-by: Rob Crittenden <[email protected]>
rcritten added a commit that referenced this issue Jun 2, 2021
This was raising a false positive in the IPA CA-less case.

#201

Signed-off-by: Rob Crittenden <[email protected]>
rcritten added a commit that referenced this issue Jun 2, 2021
The pki checks spew the error "Invalid PKI instance: pki-tomcat" so
we need to suppress them in the IPA CA-less installation case.

So if the IPA CA is not configured then don't register the
pki sources.

A side-effect is that to user the sources will not be listed at
all in this case.

This should not affect pki-healthcheck and it will continue to
return errors in the unconfigured case.

#201

Signed-off-by: Rob Crittenden <[email protected]>
@rcritten rcritten closed this as completed Jun 2, 2021
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Jan 17, 2022
Skipping the pki plugins was dependent upon the order the registry
was being processed. The assumption was that the ipa plugin would
be done first so ca_configured would be defined. If this isn't the
case the the pki plugins are incorrectly skipped. So run through
the list twice (it's short).

Signed-off-by: Rob Crittenden <[email protected]>

freeipa#201
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Jan 17, 2022
python3-libsss_nss_idmap isn't required but if it is not present
then the asumption is that trust is not available. This code
was executing prior to collecting the ca_configured status so
if the package was not installed then ca_configured could never
be True.

Signed-off-by: Rob Crittenden <[email protected]>

freeipa#201
rcritten added a commit that referenced this issue Feb 1, 2022
Skipping the pki plugins was dependent upon the order the registry
was being processed. The assumption was that the ipa plugin would
be done first so ca_configured would be defined. If this isn't the
case the the pki plugins are incorrectly skipped. So run through
the list twice (it's short).

Signed-off-by: Rob Crittenden <[email protected]>

#201
rcritten added a commit that referenced this issue Feb 1, 2022
python3-libsss_nss_idmap isn't required but if it is not present
then the asumption is that trust is not available. This code
was executing prior to collecting the ca_configured status so
if the package was not installed then ca_configured could never
be True.

Signed-off-by: Rob Crittenden <[email protected]>

#201
@rcritten rcritten reopened this Feb 16, 2022
@rcritten
Copy link
Collaborator Author

I implemented ca_configured right originally, then ended up breaking it again.

Other things can consume the core ipahealthcheck engine so I need to be careful not to impose too many IPA-isms into it.

One of those consumers is dogtag which has its own pki-healthcheck.

So this means we need to be able to run in these conditions:

  1. IPA is configured with a CA: the pki checks are run
  2. IPA is configured without a CA: the pki checks are not run
  3. IPA is not configured: the pki checks are run

Which basically equates to three states: True, False, None

This was done originally with the ca_configured variable set to None. Using some inside knowledge the registries are loaded which will set ca_configured to True or False in the IPA registry. Using that we can determine if the pki checks should be available. Unfortunately I changed the initialization to False so it always assumes that IPA is installed. ca_configured will be False for the case of IPA not installed instead of None so we can't handle that last state.

So I just need to flip it back to None and add a bunch of comments since this is not at all obvious.

rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Feb 16, 2022
The pki healthchecks are noisy if a CA is not configured. We
want to suppresse these in IPA so don't make the checks visible
if a CA is not configured.

So this means we need to be able to run in these conditions:

1. IPA is configured with a CA: the pki checks are run
2. IPA is configured without a CA: the pki checks are not run
3. IPA is not configured: the pki checks are run

Which basically equates to three states: True, False, None

This was done originally with the ca_configured variable set to
None. Using some inside knowledge the registries are loaded which
will set ca_configured to True or False in the IPA registry.
Using that we can determine if the pki checks should be available.
Unfortunately I changed the initialization to False so it always
assumes that IPA is installed. ca_configured will be False for the
case of IPA not installed instead of None so we can't handle that
last state.

So initialize ca_configured to False so we can satisfy all three
states.

freeipa#201

Signed-off-by: Rob Crittenden <[email protected]>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Feb 16, 2022
The pki healthchecks are noisy if a CA is not configured. We
want to suppresse these in IPA so don't make the checks visible
if a CA is not configured.

So this means we need to be able to run in these conditions:

1. IPA is configured with a CA: the pki checks are run
2. IPA is configured without a CA: the pki checks are not run
3. IPA is not configured: the pki checks are run

Which basically equates to three states: True, False, None

This was done originally with the ca_configured variable set to
None. Using some inside knowledge the registries are loaded which
will set ca_configured to True or False in the IPA registry.
Using that we can determine if the pki checks should be available.
Unfortunately I changed the initialization to False so it always
assumes that IPA is installed. ca_configured will be False for the
case of IPA not installed instead of None so we can't handle that
last state.

So initialize ca_configured to None so we can satisfy all three
states.

freeipa#201

Signed-off-by: Rob Crittenden <[email protected]>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Feb 16, 2022
The pki healthchecks are noisy if a CA is not configured. We
want to suppresse these in IPA so don't make the checks visible
if a CA is not configured.

So this means we need to be able to run in these conditions:

1. IPA is configured with a CA: the pki checks are run
2. IPA is configured without a CA: the pki checks are not run
3. IPA is not configured: the pki checks are run

Which basically equates to three states: True, False, None

This was done originally with the ca_configured variable set to
None. Using some inside knowledge the registries are loaded which
will set ca_configured to True or False in the IPA registry.
Using that we can determine if the pki checks should be available.
Unfortunately I changed the initialization to False so it always
assumes that IPA is installed. ca_configured will be False for the
case of IPA not installed instead of None so we can't handle that
last state.

So initialize ca_configured to None so we can satisfy all three
states.

freeipa#201

Signed-off-by: Rob Crittenden <[email protected]>
rcritten added a commit that referenced this issue Feb 17, 2022
The pki healthchecks are noisy if a CA is not configured. We
want to suppresse these in IPA so don't make the checks visible
if a CA is not configured.

So this means we need to be able to run in these conditions:

1. IPA is configured with a CA: the pki checks are run
2. IPA is configured without a CA: the pki checks are not run
3. IPA is not configured: the pki checks are run

Which basically equates to three states: True, False, None

This was done originally with the ca_configured variable set to
None. Using some inside knowledge the registries are loaded which
will set ca_configured to True or False in the IPA registry.
Using that we can determine if the pki checks should be available.
Unfortunately I changed the initialization to False so it always
assumes that IPA is installed. ca_configured will be False for the
case of IPA not installed instead of None so we can't handle that
last state.

So initialize ca_configured to None so we can satisfy all three
states.

#201

Signed-off-by: Rob Crittenden <[email protected]>
miskopo added a commit to miskopo/freeipa that referenced this issue Jun 1, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
miskopo added a commit to miskopo/freeipa that referenced this issue Jun 1, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
miskopo added a commit to miskopo/freeipa that referenced this issue Jun 5, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
miskopo added a commit to miskopo/freeipa that referenced this issue Jun 8, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
miskopo added a commit to miskopo/freeipa that referenced this issue Jun 13, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
abbra pushed a commit to freeipa/freeipa that referenced this issue Jun 16, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
Reviewed-By: Rob Crittenden <[email protected]>
miskopo added a commit to miskopo/freeipa that referenced this issue Jun 16, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
abbra pushed a commit to freeipa/freeipa that referenced this issue Jun 17, 2022
Test if ipa-healthcheck complains about pki.server.healthcheck errors
when CA is not configured on the replica.

Related: freeipa/freeipa-healthcheck#201

Signed-off-by: Michal Polovka <[email protected]>
Reviewed-By: Rob Crittenden <[email protected]>
joeldavidparker added a commit to joeldavidparker/freeipa-healthcheck that referenced this issue Jun 24, 2022
This was raising a false positive in the IPA CA-less case.

freeipa/freeipa-healthcheck#201

Signed-off-by: Rob Crittenden <[email protected]>
joeldavidparker added a commit to joeldavidparker/freeipa-healthcheck that referenced this issue Jun 24, 2022
The pki checks spew the error "Invalid PKI instance: pki-tomcat" so
we need to suppress them in the IPA CA-less installation case.

So if the IPA CA is not configured then don't register the
pki sources.

A side-effect is that to user the sources will not be listed at
all in this case.

This should not affect pki-healthcheck and it will continue to
return errors in the unconfigured case.

freeipa/freeipa-healthcheck#201

Signed-off-by: Rob Crittenden <[email protected]>
joeldavidparker added a commit to joeldavidparker/freeipa-healthcheck that referenced this issue Jun 24, 2022
Skipping the pki plugins was dependent upon the order the registry
was being processed. The assumption was that the ipa plugin would
be done first so ca_configured would be defined. If this isn't the
case the the pki plugins are incorrectly skipped. So run through
the list twice (it's short).

Signed-off-by: Rob Crittenden <[email protected]>

freeipa/freeipa-healthcheck#201
joeldavidparker added a commit to joeldavidparker/freeipa-healthcheck that referenced this issue Jun 24, 2022
python3-libsss_nss_idmap isn't required but if it is not present
then the asumption is that trust is not available. This code
was executing prior to collecting the ca_configured status so
if the package was not installed then ca_configured could never
be True.

Signed-off-by: Rob Crittenden <[email protected]>

freeipa/freeipa-healthcheck#201
joeldavidparker added a commit to joeldavidparker/freeipa-healthcheck that referenced this issue Jun 24, 2022
The pki healthchecks are noisy if a CA is not configured. We
want to suppresse these in IPA so don't make the checks visible
if a CA is not configured.

So this means we need to be able to run in these conditions:

1. IPA is configured with a CA: the pki checks are run
2. IPA is configured without a CA: the pki checks are not run
3. IPA is not configured: the pki checks are run

Which basically equates to three states: True, False, None

This was done originally with the ca_configured variable set to
None. Using some inside knowledge the registries are loaded which
will set ca_configured to True or False in the IPA registry.
Using that we can determine if the pki checks should be available.
Unfortunately I changed the initialization to False so it always
assumes that IPA is installed. ca_configured will be False for the
case of IPA not installed instead of None so we can't handle that
last state.

So initialize ca_configured to None so we can satisfy all three
states.

freeipa/freeipa-healthcheck#201

Signed-off-by: Rob Crittenden <[email protected]>
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

1 participant