Coder Social home page Coder Social logo

freeipa-healthcheck's Introduction

What is healthcheck?

It is an attempt to answer the question "Is my IPA server installation working properly."

Major pain points in an IPA server installation were identified and tests written to verify that the system is configured or running with expected settings.

The major areas currently covered are:

  • Certificate configuration and expiration dates
  • Replication errors
  • Replication topology
  • AD Trust configuration
  • Service status
  • File permissions of important configuration files
  • File system space

How to use it?

The simplest way to use Healthcheck is to run it from the command-line as root as ipa-healthcheck. Running from the command-line will display the output to the console unless --output-file=FILENAME is used. There is output for all tests so we can be sure that an error condition isn't providing a false positive. The command-line option --failures-only will skip printing the SUCCESS conditions. If running in a tty and not using --output-file then --failures-only defaults to True. The --all option will display all output if you want/need it.

Healthcheck is designed only to be run on IPA servers. It only checks for issues on the server it is executed on.

To automate running Healthcheck every day a systemd timer can be used. The default destination directory for healthcheck logs is /var/log/ipa/healthcheck and this can be the input into a monitoring system to track changes over time or to alert if a test goes from working to error or warning.

A systemd timer is provided but is not enabled by default. To enable it:

# systemctl enable ipa-healthcheck.timer
# systemctl start ipa-healthcheck.timer

logrotate will handle log rotation and keep up to 30 days of history. This can be configured via the /etc/logrotate.d/ipahealthcheck file.

If using upstream or if your distribution's package does not include the timer, it can be installed manually as follows.

First create the destination log directory:

# mkdir /var/log/ipa/healthcheck

Then copy the systemd configuration into place:

# cp systemd/ipa-healthcheck.timer /usr/lib/systemd/system
# cp systemd/ipa-healthcheck.service /usr/lib/systemd/system

Put a shell script in place to do the invocation:

# cp systemd/ipa-healthcheck.sh /usr/libexec/ipa

Tell systemd about it and enable it:

# systemctl daemon-reload
# systemctl enable ipa-healthcheck.timer
# systemctl start ipa-healthcheck.timer

Finally add a proper logrotate configuration:

# cp logrotate/ipahealthcheck /etc/logrotate.d/

Note that logrotate requires crond to be started+enabled.

To test:

# systemctl start ipa-healthcheck

What if I get an error or warning?

In general the output should contain enough information to provide a basic idea of why it is considered an error. If a specific value is expected then that will be provided along with the observed value. For example a number of files are checked for owner, group and permissions. If a value differs from the expected value then the expected and got values will be reported.

Running from the command-line will aid in ensuring that the condition is correct to what is expected. The basic idea is that it would be iterative:

  1. ipa-healthcheck
  2. manually address any errors

Repeat until until no errors are reported.

What about false positives?

It is possible that some tests will need to be tweaked to accommodate real world situations. If you observe false positives then please open an issue at https://github.com/freeipa/freeipa-healthcheck/issues

There is no way to suppress an error without making a change either in the test or in the system to accommodate the test requirements.

Organization

In order to gauge the health of a system one needs to check any number of things.

These things, or checks, can be logically grouped together. This is a source. A source consists of 1..n checks.

A check should be as atomic as possible to limit the scope and complexity, ideally returning a yes/no whether the check passes or fails. This is not always possible and that's ok.

At a higher level than source is product. The hierarchy looks like:

ipahealthcheck
  product
    source
      check
      check
      ...
    source
      check
      ...

A source provides a registry so its checks are discoverable.

Writing a check module

The base class for a check is ipahealthcheck.core.plugin::Plugin

The only method that needs to be implemented is check(). This implements the test against the system and should yield a Result object. Because check() is a generator multiple results can be yielded from a single check.

Typically each source defines its own plugin.py which contains the registry. This looks like:

    from ipahealthcheck.core.plugin import Registry

    registry = Registry()

A basic check module consists of:

    from ipahealthcheck.core.plugin import Plugin, Result
    from ipahealthcheck.core import constants
    from ipahealthcheck.mymodule.plugin import registry


    @registry
    class MyPlugin(Plugin):
        def check(self):
            yield Result(self, constants.SUCCESS)

Return value

A check yields a Result. This contains the outcome of the check including:

  • result as defined in ipahealthcheck/core/constants.py
  • kw, a python dictionary of name value pairs that provide details on the error

The kw dict is meant to provide context for the check. Err on the side of too much information.

Some predefined keys of the kw dictionary are:

  • key: some checks can have multiple tests. This provides for uniqueness.
  • msg: A message that can take other keywords as input
  • exception: used when a check raises an exception

kw is optional if result is SUCCESS.

If a check consist of only a single test then it is not required to yield a Result, one marking the check as successful will be added automatically.

If a check is complex enough that it checks multiple values then it should yield a SUCCESS Result() for each one.

A Result is required for every test done so that one can know that the check was executed.

The run time duration of each check will be calculated. The mechanism differs depending on complexity.

A check should normally use the @duration decorator to track the duration it took to execute the check.

    @registry
    class MyPlugin(Plugin):
        @duration
        def check(self):
            yield Result(self, constants.SUCCESS)

Registering a source

The list of sources is stored in setup.py in the top-level of the tree.

Assuming it is contained in-tree it takes the form of:

'ipahealthcheck.

': [ 'name = ipahealthcheck..' ]

For example, to add replication to the src/ipahealthcheck/ipa directory

'ipahealthcheck.ipa': [
    'ipacerts = ipahealthcheck.ipa.certs',
    'ipafiles = ipahealthcheck.ipa.files',
    'ipakerberos = ipahealthcheck.ipa.kerberos',
    'replication = ipahealthcheck.ipa.replication',
],

If a new branch of sources is added a new registry is needed. This is added into the ipahealthcheck.registry section in setup.py. If we decided that replication didn't belong under ipahealthcheck.ipa but instead in ipahealthcheck.ds it would look like:

'ipahealthcheck.registry': [
    'ipahealthcheck.ipa = ipahealthcheck.ipa.plugin:registry',
    'ipahealthcheck.dogtag = ipahealthcheck.dogtag.plugin:registry',
    'ipahealthcheck.meta = ipahealthcheck.meta.plugin:registry',
    'ipahealthcheck.ds = ipahealthcheck.ds.plugin:registry',
],

and

'ipahealthcheck.ds': [
    'replication = ipahealthcheck.ds.replication',
],

Execution

It is possible to execute a single check or all checks in a single source by passing --source and/or --check on the command-line. This is intended to help user's quickly ensure that something is fixed by re-running a check after making a change.

--source, when used on its own i.e. without --check, can also accept a module namespace and all sources within that namespace shall be executed.

Output

Output is controlled via Output plugins. These take the global Results object and iterate over it to produce output in the desired format. The result is returned as a string.

A custom Output class must implement the generate method which generates the output.

A bare-bones output class is:

    @output_registry
    class Basic(Output):
        def generate(self, data):
            output = [x for x in data.output()]

            return output

An output object can declare its own options by adding a tuple named options to the class in the form of (arg_name, dict(argparse options).

An example to provide an option to indent the text to make it more readable.

    options = (
        (--indent', dict(dest='indent', help='How deeply to indent')),
    )

Meta

The meta source is intended to collect basic information about the run such as the host it is run on and the time it was run.

Useful to diagnose a failed installation?

No. healthcheck compares a known state to the state of the installation. If the installation failed then you are guaranteed to get a ton of false positives and all it will tell you is that your installation failed.

Testing and development

The package can be tested and developed in a python virtual environment.

It requires a full freeIPA deployment so full set of system packages need to be installed and an IPA master running.

To create the virtual environment run:

% python3 -m venv --system-site-packages venv
% venv/bin/pip install -e .

To use the environment

% source venv/bin/activate

To run the healthchecks (must be done as root for proper results):

# source venv/bin/activate
# ipa-healthcheck

To run the tests execute the virtual environment:

% pip install pytest
% pytest

The configuration file and directory are not yet created so you'll need to do that manually:

# mkdir /etc/ipahealthcheck
# echo "[default]" > /etc/ipahealthcheck/ipahealthcheck.conf

Understanding the results

Here is some basic guidance on what a non-SUCCESS message from a check means. How to fix any particular result is heavily dependent on the error(s) discovered and their context. A single failure may be detected by multiple checks.

ipahealthcheck.dogtag.ca

DogtagCertsConfigCheck

Compares the value of the CA (and KRA if installed) certificates with the value found in CS.cfg. If they don't match then the CA will likely fail to start.

{
  "source": "ipahealthcheck.dogtag.ca",
  "check": "DogtagCertsConfigCheck",
  "result": "ERROR",
  "kw": {
    "key": "ocspSigningCert cert-pki-ca",
    "directive": "ca.ocsp_signing.cert",
    "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
    "msg": "Certificate 'ocspSigningCert cert-pki-ca' does not match the value of ca.ocsp_signing.cert in /var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
    }
}

DogtagCertsConnectivityCheck

Runs the equivalent of ipa cert-show 1 to verify basic connectivity.

{
  "source": "ipahealthcheck.dogtag.ca",
  "check": "DogtagCertsConnectivityCheck",
  "result": "ERROR",
  "kw": {
    "msg": "Request for certificate failed, Certificate operation cannot be completed: Unable to communicate with CMS (503)"
  }
}

ipahealthcheck.ds.replication

ReplicationConflictCheck

Searches for entries in LDAP matching (&(!(objectclass=nstombstone))(nsds5ReplConflict=*))

{
  "source": "ipahealthcheck.ds.replication",
  "check": "ReplicationConflictCheck",
  "result": "ERROR",
  "kw": {
    "key": "nsuniqueid=66446001-1dd211b2+uid=bjenkins,cn=users,cn=accounts,dc=example,dc=test",
    "conflict": "namingConflict",
    "msg": "Replication conflict"
  }
}

ipahealthcheck.ipa.certs

IPACertmongerExpirationCheck

Loops through all expected certmonger requests and checks expiration based on what certmonger knows about the certificate. A warning is issued if the certificate expires in cert_expiration_days (the default is 28).

Expired certificate:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertmongerExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "expiration_date", "20160101001704Z",
    "msg": "Request id 1234 expired on 20160101001704Z"
  }
}

Expiring certificate:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertmongerExpirationCheck",
  "result": "WARNING",
  "kw": {
    "key": 1234,
    "expiration_date", "20160101001704Z",
    "days": 9,
    "msg": "Request id 1234 expires in 9 days"
  }
}

IPACertfileExpirationCheck

Similar to IPACertmongerExpirationCheck except the certificate is pulled from the PEM file or NSS database and re-verified. This is in case the certmonger tracking becomes out-of-sync with the certificate on disk.

The certificate file cannot be opened:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "certfile": "/path/to/cert.pem",
    "error": [error],
    "msg": "Unable to open cert file '/path/to/cert.pem': [error]"
  }
}

The NSS database cannot be opened:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "dbdir": "/path/to/nssdb",
    "error": [error],
    "msg": "Unable to open NSS database '/path/to/nssdb': [error]"
  }
}

The tracked nickname cannot be found in the NSS database:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "dbdir": "/path/to/nssdb",
    "nickname": [nickname],
    "error": [error],
    "msg": "Unable to retrieve cert '[nickname]' from '/path/to/nssdb': [error]"
  }
}

Expired certificate:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "expiration_date", "20160101001704Z",
    "msg": "Request id 1234 expired on 20160101001704Z"
  }
}

Expiring certificate:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "WARNING",
  "kw": {
    "key": 1234,
    "expiration_date", "20160101001704Z",
    "days": 9,
    "msg": "Request id 1234 expires in 9 days"
  }
}

IPACAChainExpirationCheck

Load the CA chain from /etc/ipa/ca.crt and test each one for expiration. This test is designed to ensure that the entire CA chain for all certificates is validated. For example, if the web or LDAP certificates have been replaced then the CA chain for those certs will reside in /etc/ipa/ca.crt. This includes an IPA CA signed by an external authority.

Expiring certificate:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACAChainExpirationCheck",
  "result": "WARNING",
  "kw": {
    "path": "/etc/ipa/ca.crt",
    "key": "CN=Certificate Authority,O=EXAMPLE.TEST",
    "days": 2,
    "msg": "CA '{key}' is expiring in {days} days."
  }
}

Expired certificate:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACAChainExpirationCheck",
  "result": "CRITICAL",
  "kw": {
    "path": "/etc/ipa/ca.crt",
    "key": "CN=Certificate Authority,O=EXAMPLE.TEST",
    "msg": "CA '{key}' is expired."
  }
}

IPACertTracking

Compares the certmonger tracking on the system to the expected values. A query of the expected name/value pairs in certmonger is done to certmonger. On failure the contents of the query are missing. This result would be seen either if the certificate is tracked but there is some slight change in the expected value or if the tracking is missing entirely.

Missing certificate tracking:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertTracking",
  "result": "ERROR",
  "kw": {
    "key": "cert-file=/var/lib/ipa/ra-agent.pem, key-file=/var/lib/ipa/ra-agent.key, ca-name=dogtag-ipa-ca-renew-agent, cert-storage=FILE, cert-presave-command=/usr/libexec/ipa/certmonger/renew_ra_cert_pre,  cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ra_cert"
    "msg": "Missing tracking for cert-file=/var/lib/ipa/ra-agent.pem, key-file=/var/lib/ipa/ra-agent.key, ca-name=dogtag-ipa-ca-renew-agent, cert-storage=FILE, cert-presave-command=/usr/libexec/ipa/certmonger/renew_ra_cert_pre,  cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ra_cert"
  }
}

An unknown certificate is being tracked by certmonger. This may be perfectly legitimate, it is provided for information only:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertTracking",
  "result": "WARNING",
  "kw": {
    "key": 1234,
    "msg": "Unknown certmonger id 1234'
  }
}

IPACertNSSTrust

The trust for certificates stored in NSS databases is compared against a known good state.

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertNSSTrust",
  "result": "ERROR",
  "kw": {
    "key": "auditSigningCert cert-pki-ca",
    "expected": "u,u,Pu",
    "got": "u,u,u",
    "nickname": "auditSigningCert cert-pki-ca",
    "dbdir": "/etc/pki/pki-tomcat/alias",
    "msg": "Incorrect NSS trust for auditSigningCert cert-pki-ca. Got u,u,u expected u,u,Pu"
  }
}

IPACertMatchCheck

Ensure CA certificate entries in LDAP and NSS databases match.

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertMatchCheck",
  "result": "ERROR",
  "kw": {
    "msg": "CA Certificate from /etc/ipa/nssdb does not match /etc/ipa/ca.crt"
  }
}

IPADogtagCertsMatchCheck

Check if Dogtag certificates present in both NSS DB and LDAP match.

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPADogtagCertsMatchCheck",
  "result": "ERROR",
  "kw": {
    "msg": "'subsystemCert cert-pki-ca' certificate in NSS DB does not match entry in LDAP"
  }
}

IPANSSChainValidation

Validate the certificate chain of the NSS certificates. This executes: certutil -V -u V -e -d [dbdir] -n [nickname].

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPANSSChainValidation",
  "result": "ERROR",
  "kw": {
    "key": "/etc/dirsrv/slapd-EXAMPLE-TEST:Server-Cert",
    "nickname": "Server-Cert",
    "dbdir": [path to NSS database],
    "reason": "certutil: certificate is invalid: Peer's Certificate issuer is not recognized.\n: ",
    "msg": ""Validation of Server-Cert in /etc/dirsrv/slapd-EXAMPLE-TEST/ failed: certutil: certificate is invalid: Peer's Certificate issuer is not recognized.\n "
  }
}

IPAOpenSSLChainValidation

Validate the certificate chain of the OpenSSL certificates. This executes: openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt /path/to/cert.pem

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPAOpenSSLChainValidation",
  "result": "ERROR",
  "kw": {
    "key": "/var/lib/ipa/ra-agent.pem",
    "reason": "O = EXAMPLE.TEST, CN = IPA RA\nerror 20 at 0 depth lookup: unable to get local issuer certificate\n",
    "msg": "Certificate validation for /var/lib/ipa/ra-agent.pem failed: O = EXAMPLE.TEST, CN = IPA RA\nerror 20 at 0 depth lookup: unable to get local issuer certificate\n"
  }
}

IPARAAgent

Verify the description and userCertificate values in uid=ipara,ou=People,o=ipaca.

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPARAAgent",
  "result": "ERROR",
  "kw": {
    "expected": "2;125;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST",
    "got": "2;7;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST",
    "msg": "RA agent description does not match. Found 2;7;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST in LDAP and expected 2;125;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST"
  }
}

IPAKRAAgent

Verify the description and userCertificate values in uid=ipakra,ou=people,o=kra,o=ipaca.

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPAKRAAgent",
  "result": "ERROR",
  "kw": {
    "expected": "2;125;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST",
    "got": "2;7;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST",
    "msg": "KRA agent description does not match. Found 2;7;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST in LDAP and expected 2;125;CN=Certificate Authority,O=EXAMPLE.TEST;CN=IPA RA,O=EXAMPLE.TEST"
  }
}

IPACertRevocation

Confirm that the IPA certificates are not revoked. This uses the certmonger tracking to determine the list of certificates to validate.

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertRevocation",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "revocation_reason": "superseded",
    "msg": "Certificate is revoked, superseded"
  }
}

IPACertmongerCA

Check that the certmonger CA configuration is correct. Evaluates dogtag-ipa-ca-renew-agent and dogtag-ipa-ca-renew-agent-reuse.

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertmongerCA",
  "result": "ERROR",
  "kw": {
    "key": "dogtag-ipa-ca-renew-agent",
    "msg": "Certmonger CA 'dogtag-ipa-ca-renew-agent' missing"
  }
}

ipahealthcheck.ipa.dna

IPADNARangeCheck

This reports the configured DNA range, if any. It is expected that this is combined elsewhere for further analysis.

{
  "source": "ipahealthcheck.ipa.dna",
  "check": "IPADNARangeCheck",
  "result": "SUCCESS",
  "kw": {
    "range_start": 1000,
    "range_max": 199999,
    "next_start": 0,
    "next_max": 0,
  }
}

ipahealthcheck.ipa.files

These checks verify the owner and mode of files installed or configured by IPA. There are many permutations of file permissions and ownership that may be valid and continue to work. This reports on the expected values in a fresh IPA installation. Deviations are reported at the WARNING level.

This covers the following checks:

IPAFileNSSDBCheck

IPAFileCheck

TomcatFileCheck

Examples include:

{
  "source": "ipahealthcheck.ipa.files",
  "check": "IPAFileCheck",
  "result": "WARNING",
  "kw": {
    "key": "_etc_ipa_ca.crt_mode",
    "path": "/etc/ipa/ca.crt",
    "type": "mode",
    "expected": "0644",
    "got": "0444",
    "msg": "Permissions of /etc/ipa/ca.crt are 0444 and should be 0644"
  }
}

{
  "source": "ipahealthcheck.ipa.files",
  "check": "IPAFileNSSDBCheck",
  "result": "WARNING",
  "kw": {
    "key": "_etc_dirsrv_slapd-EXAMPLE-TEST_pkcs11.txt_mode",
    "path": "/etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt",
    "type": "mode",
    "expected": "0640",
    "got": "0666",
    "msg": "Permissions of /etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt are 0666 and should be 0640"
  }
},

ipahealthcheck.ipa.host

IPAHostKeytab

Executes: kinit -kt /etc/krb5.keytab to verify that the host keytab is valid.

ipahealthcheck.ipa.roles

A set of information checks to report on whether the current master is the CRL generator and/or the renewal master.

IPACRLManagerCheck

{
  "source": "ipahealthcheck.ipa.roles",
  "check": "IPACRLManagerCheck",
  "result": "SUCCESS",
  "kw": {
    "key": "crl_manager",
    "crlgen_enabled": true
  }
},

IPARenewalMasterCheck

{
  "source": "ipahealthcheck.ipa.roles",
  "check": "IPARenewalMasterCheck",
  "result": "SUCCESS",
  "kw": {
    "key": "renewal_master",
    "master": true
  }
}

ipahealthcheck.ipa.topology

Topology checks to check both for compliance with recommendations and errors.

IPATopologyDomainCheck

Provide the equivalent of: ipa topologysuffix-verify

On failure this will return any errors discovered like connection errors or too many replication agreements.

On success it will return the configured domains.

{
  "source": "ipahealthcheck.ipa.topology",
  "check": "IPATopologyDomainCheck",
  "result": "SUCCESS",
  "kw": {
    "suffix": "domain"
  }
},
{
  "source": "ipahealthcheck.ipa.topology",
  "check": "IPATopologyDomainCheck",
  "result": "SUCCESS",
  "kw": {
    "suffix": "ca"
  }
}

ipahealthcheck.ipa.trust

Verify common AD Trust configuration issues. Checks will return SUCCESS if not configured as a trust agent or controller.

IPATrustAgentCheck

Check the sssd configuration when the machine is configured as a trust agent.

provider should be ipa and ipa_server_mode should be true.

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustAgentCheck",
  "severity": ERROR,
  "kw": {
    "key": "ipa_server_mode_false",
    "attr": "ipa_server_mode",
    "sssd_config": "/etc/sssd/sssd.conf",
    "domain": "ipa.example.com",
    "msg": "{attr} is not True in {sssd_config} in the domain {domain}"
  }
}

IPATrustDomainsCheck

Ensure that the IPA domain is in the output of sssctl domain-list and the trust domains matches the sssd domains.

If the domain lists don't match:

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustDomainsCheck",
  "result": "ERROR",
  "kw": {
    "key": "domain-list",
    "sslctl": "/usr/sbin/sssctl",
    "sssd_domains": "ad.vm",
    "trust_domains": "",
    "msg": "{sslctl} {key} reports mismatch: sssd domains {sssd_domains} trust domains {trust_domains}"
  }
}

IPATrustCatalogCheck

This resolves an AD user, Administrator@REALM. This populates the AD Global catalog and AD Domain Controller values in sssctl domain-status output.

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustCatalogCheck",
  "result": "ERROR",
  "kw": {
    "key": "AD Global Catalog",
    "output": "Active servers:\nAD Domain Controller: root-dc.ad.vm\nIPA: ipa.example.com",
    "sssctl": "/usr/sbin/sssctl",
    "domain": "ad.vm",
    "msg": "{key} not found in {sssctl} 'domain-status' output: {output}"
  }
}

IPAsidgenpluginCheck

Verifies that the sidgen plugin is enabled in the IPA 389-ds instance.

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPAsidgenpluginCheck",
  "result": "ERROR",
  "kw": {
    "key": "IPA SIDGEN",
    "error": "no such entry",
    "msg": "Error retrieving 389-ds plugin {key}: {error}"
  }
}

IPATrustAgentMemberCheck

Verify that the current host is a member of cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.

{ "source": "ipahealthcheck.ipa.trust", "check": "IPATrustAgentMemberCheck", "result": "ERROR", "kw": { "key": "ipa.example.com", "group": "adtrust agents", "msg": "{key} is not a member of {group}" } }

IPATrustControllerPrincipalCheck

Verify that the current host cifs principal is a member of cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustControllerPrincipalCheck",
  "result": "ERROR",
  "kw": {
    "key": "cifs/[email protected]",
    "group": "adtrust agents",
    "msg": "{key} is not a member of {group}"
  }
}

IPATrustControllerServiceCheck

Verify that the current host starts the ADTRUST service in ipactl.

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustControllerServiceCheck",
  "result": "ERROR",
  "kw": {
    "key": "ADTRUST",
    "msg": "{key} service is not enabled"
  }
}

IPATrustControllerConfCheck

Verify that ldapi is enabled for the passdb backend in the output of net conf list:

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustControllerConfCheck",
  "result": "ERROR",
  "kw": {
    "key": "net conf list",
    "got": "",
    "expected": "ipasam:ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket",
    "option": "passdb backend",
    "msg": "{key} option {option} value {got} doesn't match expected value {expected}"
  }
}

IPATrustControllerGroupSIDCheck

Verify that the admins group's SID ends with 512 (Domain Admins RID).

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustControllerGroupSIDCheck",
  "result": "ERROR",
  "kw": {
    "key": "ipantsecurityidentifier",
    "rid": "S-1-5-21-1078564529-1875285547-1976041503-513",
    "msg": "{key} is not a Domain Admins RID"
  }
}

IPATrustPackageCheck

If not a trust controller and AD trust is enabled verify that the trust-ad pkg is installed.

{
  "source": "ipahealthcheck.ipa.trust",
  "check": "IPATrustPackageCheck",
  "result": "WARNING",
  "kw": {
    "key": "adtrustpackage",
    "msg": "trust-ad sub-package is not installed. Administration will be limited."
  }
}

ipahealthcheck.meta.services

Return the status of required IPA services

The following services are monitored:

  • certmonger
  • dirsrv
  • gssproxy
  • httpd
  • ipa_custodia
  • ipa_dnskeysyncd
  • ipa_otpd
  • kadmin
  • krb5kdc
  • named
  • pki_tomcatd
  • sssd

The value of check is the name of the IPA service. Note that dashes are replaced with underscores in the service names.

An example of a stopped service:

{
  "source": "ipahealthcheck.meta.services",
  "check": "httpd",
  "result": "ERROR",
  "kw": {
    "status": false,
    "msg": "httpd: not running"
  }
}

ipahealthcheck.meta.core

Provide basic information about the IPA master itself.

MetaCheck

Output includes the FQDN and the version of IPA.

{
  "source": "ipahealthcheck.meta.core",
  "check": "MetaCheck",
  "result": "SUCCESS",
  "kw": {
    "fqdn": "ipa.example.test",
    "ipa_version": "4.8.0",
    "ipa_api_version": "2.233"
  }
}

ipahealthcheck.system.filesystemspace

Check on available disk space. Running low can cause issues with logging, execution and backups.

FileSystemSpaceCheck

Both a percentage and raw minimum values are tested.

It is possible there is some overlap depending on mount points.

The minimum free is 20 percent and is currently hard coded.

The following paths are checked:

Path free MB /var/lib/dirsrv/ 1024 /var/lib/ipa/backup/ 512 /var/log/ 1024 /var/log/audit/ 512 /var/tmp/ 512 /tmp 512

For example a full /tmp would be reported as:

{
  "source": "ipahealthcheck.system.filesystemspace",
  "check": "FileSystemSpaceCheck",
  "result": "ERROR",
  "kw": {
    "msg": "/tmp: free space percentage under threshold: 0% < 20%",
    "store": "/tmp",
    "percent_free": 0,
    "threshold": 20
  }
},
{
  "source": "ipahealthcheck.system.filesystemspace",
  "check": "FileSystemSpaceCheck",
  "result": "ERROR",
  "kw": {
    "msg": "/tmp: free space under threshold: 0 MiB < 512 MiB",
    "store": "/tmp",
    "free_space": 0,
    "threshold": 512
  }
}

freeipa-healthcheck's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

freeipa-healthcheck's Issues

Human output can return a KeyError for certmonger tracking issues

If an expected tracking cert is not found in certmonger then the request is added as a string to the msg kw.

In human output this is displayed as msg.format(**kw) which will raise KeyError: "'cert-database'" because the literal string in msg the converted dict and {} are being interpreted as a variable.

pytest warnings

Pytest reports about several warnings:

====================================== warnings summary =======================================
tests/test_cluster_ruv.py:15
  /usr/src/RPM/BUILD/freeipa-healthcheck/tests/test_cluster_ruv.py:15: PytestCollectionWarning: cannot collect test class 'TestRegistry' because it has a __init__ constructor (from: tests/test_cluster_ruv.py)
    class TestRegistry(ClusterRegistry):

tests/test_ipa_nssvalidation.py::TestNSSValidation::test_nss_validation_bad
tests/test_ipa_nssvalidation.py::TestNSSValidation::test_nss_validation_ok
  /usr/src/RPM/BUILD/freeipa-healthcheck/.tox/py3/lib/python3/site-packages/ipahealthcheck/ipa/certs.py:553: DeprecationWarning: Use 'ipapython.ipautil.remove_file'
    installutils.remove_file(ca_pw_fname)

The first one is trivial.
As for the second warning:
installutils.remove_file has been deprecated since freeipa 4.8.
As I know ipa-healthcheck officially supports 4.8+ and thus, ipapython.ipautil.remove_file can be used instead. Am I wrong?

'ipa-healthcheck --failures-only' when run on newly installed ipa-server lists ERROR for IPACertTracking check

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1774032

'ipa-healthcheck --failures-only' when run on newly installed ipa-server lists ERROR for IPACertTracking check

# ipa-healthcheck --failures-only
[
  {
    "source": "ipahealthcheck.ipa.certs",
    "check": "IPACertTracking",
    "result": "ERROR",
    "uuid": "1a21e9ab-6b88-40b1-a279-d5c4607e192a",
    "when": "20191119130346Z",
    "duration": "0.303834",
    "kw": {
      "msg": "Missing tracking for cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent, cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad, cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert \"caSigningCert cert-pki-ca\", template-profile=None"
    }
  },
  {
    "source": "ipahealthcheck.ipa.certs",
    "check": "IPACertTracking",
    "result": "WARNING",
   "uuid": "486c5905-b00b-4b74-9250-c4ef00f7665d",
    "when": "20191119130346Z",
    "duration": "0.425676",
    "kw": {
      "key": "20191118100649",
      "msg": "Unknown certmonger id 20191118100649"
    }
  }
]

Return value isn't non-zero on error

I'm seeing a failure in the replication checking plugin that is correctly reporting an error but not setting the return code to 1.

# ipa-healthcheck --failures-only
[
  {
    "source": "ipahealthcheck.ds.replication",
    "check": "ReplicationConflictCheck",
    "severity": 1,
    "uuid": "28cd5454-b4ed-4eed-b5c7-6bfc818d77d7",
    "when": "20190624183048Z",
    "duration": "0.000035",
    "kw": {
      "exception": "type object 'LDAPClient' has no attribute 'from_realm'"
    }
  }
]
# echo $?
0

So we need to fix the underlying exception and ensure that exceptions cause a non-zero error to be returned.

Report FIPS status in meta plugin

It could be useful to know if FIPS is enabled, report its status in the meta plugin.

Can either read /proc/sys/crypto/fips_enabled or use fips-mode-setup --check

Human output does not translate error severity to string

The human output module is not translating non-SUCCESS messages into a string and reporting the numeric value instead.

ipa-healthcheck --failures-only --output-type human
20: ipahealthcheck.ipa.certs.IPACertTracking: Missing tracking for cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent, cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad, cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca", template-profile=None
10: ipahealthcheck.ipa.certs.IPACertTracking.20190920140751: Unknown certmonger id 20190920140751

ipa-healthcheck use in ansible-freeipa roles

I would like to use ipa-healthcheck in ipaserver and ipareplica roles to detect the parts that have been configured. Which of the parts are working correctly and which are not working correctly.

Using the ipaserver or ipareplica role again with a different configuration for the same node should adapt the configuration of the node to the newly given configuration. Therefore it will be needed to be able to identify the parts that need to be adapted, installed and uninstalled.

A list of the installed parts would be therefore needed.

ipa-healthcheck and ipv6

ipa-healthcheck.service fails on systems having ipv6.

systemctl start ipa-healthcheck

[root@ipa ~]# LANG=C systemctl status --no-pager -l ipa-healthcheck
* ipa-healthcheck.service - Execute IPA Healthcheck
   Loaded: loaded (/lib/systemd/system/ipa-healthcheck.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2020-07-03 17:44:52 MSK; 3min 38s ago
  Process: 15523 ExecStart=/usr/libexec/ipa/ipa-healthcheck.sh (code=exited, status=1/FAILURE)
 Main PID: 15523 (code=exited, status=1/FAILURE)

Jul 03 17:44:46 ipa.qwetest.qwedom systemd[1]: Started Execute IPA Healthcheck.
Jul 03 17:44:52 ipa.qwetest.qwedom python3[15524]: GSSAPI client step 1
Jul 03 17:44:52 ipa.qwetest.qwedom python3[15524]: GSSAPI client step 1
Jul 03 17:44:52 ipa.qwetest.qwedom python3[15524]: GSSAPI client step 1
Jul 03 17:44:52 ipa.qwetest.qwedom python3[15524]: GSSAPI client step 2
Jul 03 17:44:52 ipa.qwetest.qwedom ipa-healthcheck.sh[15523]: Unhandler rdtype 28
Jul 03 17:44:52 ipa.qwetest.qwedom systemd[1]: ipa-healthcheck.service: Main process exited, code=exited, status=1/FAILURE
Jul 03 17:44:52 ipa.qwetest.qwedom systemd[1]: ipa-healthcheck.service: Failed with result 'exit-code'.

(Pdb) w
  /usr/bin/ipa-healthcheck(11)<module>()
-> load_entry_point('ipahealthcheck==0.5', 'console_scripts', 'ipa-healthcheck')()
  /usr/lib/python3/site-packages/ipahealthcheck/core/main.py(28)main()
-> sys.exit(ipachecks.run_healthcheck())
  /usr/lib/python3/site-packages/ipahealthcheck/core/core.py(252)run_healthcheck()
-> options.source, options.check))
  /usr/lib/python3/site-packages/ipahealthcheck/core/core.py(118)run_plugins()
-> for result in run_plugin(plugin, available):
  /usr/lib/python3/site-packages/ipahealthcheck/core/core.py(43)run_plugin()
-> for result in plugin.check():
  /usr/lib/python3/site-packages/ipahealthcheck/core/plugin.py(18)wrapper()
-> for result in f(*args, **kwds):
> /usr/lib/python3/site-packages/ipahealthcheck/ipa/idns.py(65)check()
-> logger.error("Unhandler rdtype %d", rd.rdtype)
(Pdb) rd
<DNS IN AAAA rdata: 2a0c:88c0:2:2000:94c2:a55:12cf:3654>
(Pdb)

I can patch sources and add AAAA, but I wonder why is not already there? Design limitation?

input-file throws an exception

# ipa-healthcheck --input-file /var/log/ipa/healthcheck/healthcheck.log --output-type human 2>&1
[proper results]
Traceback (most recent call last):
  File "/usr/bin/ipa-healthcheck", line 11, in <module>
    load_entry_point('ipahealthcheck==0.3', 'console_scripts', 'ipa-healthcheck')()
  File "/usr/lib/python3.7/site-packages/ipahealthcheck/core/main.py", line 224, in main
    for result in results.results:
AttributeError: 'NoneType' object has no attribute 'results'

The reason is there are no real results to see what the exit code should be.
Reconsidering this it would be nice if input-file wasn't limited to the type of output. It would be handy to be able to find failures in older runs using this as well, in the JSON output type too.
Being able to also limit to source and check would be nice as well. The tricky bit is that for the normal case only those sources/checks are executed but in the loading from file the output needs to be parsed.

Check that all IPA server certs have a SAN

Browsers have been pushing for SAN for years. We should make sure that all IPA certs have a SAN entry. Older versions of IPA did not issue certs with a DNS SAN by default, relying on CN=$HOSTNAME.

Dealing with expected failures

It would be useful to be able to:

  • have a CLI knob like --expected-failures-file=
  • have a configuration item like expected_failures =

to deal with expected check failures.
The default path for such a file should be /etc/ipahealthcheck/expected_failures.json

Tuple object has no attribute items

Hi,
I use ipa-healthcheck on centos-8 and have such output:

{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "CRITICAL",
"uuid": "a2e82449-934a-444c-be68-66cdd99b8e0c",
"when": "20191212104501Z",
"duration": "0.001813",
"kw": {
"exception": "'tuple' object has no attribute 'items'"
}
}

Please advise how to fix it.

Checking permissions

Currently healthcheck only logs a warning if a file's permissions are not equal to the expected perms.
It should be WARNING if a file's permissions are more permissive and an ERROR if they are less permissive than expected.

Look for dangling RUVs

RUVs of old replicas can cause issues with replication. See if there is a way to identify them so they can be removed (or recommend running cleanallruv).

Determine if all checks have executed

Ideally there should be a way to know that all checks have executed. Implement a counter to count the expected vs received results. If they don't match add a new ERROR result.

May need to add a SKIPPED return result in order for this to work.

merge systemd/README and logrotate/README

Once #42 is merged we'll have three READMEs.
AI: add at least:

  • a blurb about the systemd healthcheck timer
  • how to enable the healthcheck timer
  • how logrotate is configured

to README.md

Unrecognized arguments: --output-type human

Package:
freeipa-healthcheck-0.5-1.fc31.noarch

As per man page:

 OPTIONAL ARGUMENTS
... 
  40        --output-type=TYPE
  41               Set the output type. The default is JSON.
...

Example from man page:

  83        Display in human-readable output a previous report:
  84 
  85         ipa-healthcheck --output-format human --input-file

Actual run:

ipa: ERROR: stderr: usage: ipa-healthcheck [-h] [--debug] [--list-sources] [--source SOURCE]
                       [--check CHECK] [**--output-type** {json,human}]
                       [--output-file OUTFILE] [--input-file INFILE]
                       [--failures-only]
                       [--severity {SUCCESS,WARNING,ERROR,CRITICAL}]
                       [--indent INDENT]
ipa-healthcheck: error: unrecognized arguments: --output-type human

package
ipa-healthcheck-0.4-4.module+el8.2.0+5489+95477d9f.noarch

works with --output-type human just fine

Config object has a recursive attribute

@SilleBille found an issue with the Config object: it's recursive.

    from ipahealthcheck.core.config import read_config
     
    '''
    # cat /etc/pki/healthcheck.conf
    [default]
    instance=pki-tomcat
     
    [dogtag]
    ca_instance=pki-ca
    kra_instance=pki-kra
    ocsp_instance=pki-ocsp
    '''
     
    config = read_config('/etc/pki/healthcheck.conf')
     
    print(config._Config__d['_Config__d'])
    print(config._Config__d['_Config__d']['_Config__d'])
    print(config._Config__d['_Config__d']['_Config__d']['_Config__d'])
    print(config._Config__d['_Config__d']['_Config__d']['_Config__d']['_Config__d'])

Use the DN class to compare certificate subjects

There can be at least a case difference with certificate subjects vs what is expected and what is issued. Use the DN class to do the comparison.

From a user report:

{
    "source": "ipahealthcheck.ipa.certs",
    "check": "IPARAAgent",
    "result": "ERROR",
    "uuid": "30876792-422b-4ef0-ac6f-e8eaa4742850",
    "when": "20191121140955Z",
    "duration": "0.008288",
    "kw": {
      "expected": "2;6;CN=IPA-IPASERVER-CA;CN=IPA RA,O=IPA.CORP-DOMAIN",
      "got": "2;6;cn=IPA-IPASERVER-CA;CN=IPA RA,O=IPA.CORP-DOMAIN",
      "msg": "RA agent description does not match 2;6;cn=IPA-IPASERVER-CA;CN=IPA RA,O=IPA.CORP-DOMAIN in LDAP 
and 2;6;CN=IPA-IPASERVER-CA;CN=IPA RA,O=IPA.CORP-DOMAIN expected"
    }

error when no tty

$ ssh  -i  config/id_rsa -o StrictHostKeyChecking=no
[email protected] ipa-healthcheck
Output raised OSError: [Errno 6] No such device or address: '/dev/tty'

It works correctly with an option -t:

$ ssh -t  -i  config/id_rsa -o StrictHostKeyChecking=no
[email protected] ipa-healthcheck
[
  {
    "source": "ipahealthcheck.meta.services",
    "check": "certmonger",
    "result": "SUCCESS",
    "uuid": "b9a530a8-82df-4690-b789-39d5a3cd3455",
    "when": "20190918140724Z",
    "duration": "0.016964",
    "kw": {
      "status": true
    }
  },
<snip>

RFE: add a check for working anacron

check that:

  • rpms cronie-anacron, crontabs, cronie, logrotate are installed
  • systemd unit crond is active+enabled

this will make sure (via manual execution and via sosreport integration) that logrotate is properly installed and running every day which is necessary for many IPA services (like httpd for instance, not to mention healthcheck itself).

add log rotation

As it stands healthcheck logs have no rotation.
I suppose adding a file in /etc/logrotate.d/ is the right way to do it.

RFE: Add certificate serial number uniqueness check

Moved from https://pagure.io/freeipa/issue/8231

In a recent customer case, IPA RA certificate authentication to pki-tomcatd was failing. It was quite hard to diagnose, but turned out to be that the IPA RA cert had the same serial number as the LDAP service certificate. pki-tomatd had already seen the LDAP certificate (due to ldaps connection). As a consequence, when it saw the IPA RA certificate with the same serial number, it rejected it.

(The duplicate serial number probably arose due to replication and/or range conflicts).

Update health check tool to detect cases of duplicate issuer/serial on IPA infra system certificates. It should load the whole set of relevant certificates on the host, and check for duplicates.

AD trust agent and controller not getting initialized

IPA provides two roles for AD trust: agent and controller.

These are looked up in the IPA Plugin initialization but ONLY if the api hasn't been finalized yet. If it was finalized elsewhere then these roles aren't being set.

The lookup of these should not be dependent upon the initialization status of the IPA API.

when root has an expired ticket ipa-healthcheck service fails

when root has an expired ticket:

# klist
Ticket cache: KCM:0
Default principal: [email protected]
 
Valid starting       Expires              Service principal
06/24/2019 16:21:07  06/25/2019 16:21:03  HTTP/[email protected]
06/24/2019 16:21:05  06/25/2019 16:21:03  krbtgt/[email protected]

starting the service with 'systemctl start ipa-healthcheck' leads to:

# systemctl status ipa-healthcheck
โ— ipa-healthcheck.service - Execute IPA Healthcheck
   Loaded: loaded (/usr/lib/systemd/system/ipa-healthcheck.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2019-07-18 23:43:46 CEST; 11min ago
  Process: 29703 ExecStart=/usr/libexec/ipa/ipa-healthcheck.sh (code=exited, status=1/FAILURE)
 Main PID: 29703 (code=exited, status=1/FAILURE)
 
Jul 18 23:43:38 f29-idm0.laptop.example.org systemd[1]: Started Execute IPA Healthcheck.
Jul 18 23:43:46 f29-idm0.laptop.example.org python3[29704]: GSSAPI client step 1
Jul 18 23:43:46 f29-idm0.laptop.example.org python3[29704]: GSSAPI client step 1
Jul 18 23:43:46 f29-idm0.laptop.example.org python3[29704]: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Ticket expired)
Jul 18 23:43:46 f29-idm0.laptop.example.org systemd[1]: ipa-healthcheck.service: Main process exited, code=exited, status=1/FAILURE
Jul 18 23:43:46 f29-idm0.laptop.example.org systemd[1]: ipa-healthcheck.service: Failed with result 'exit-code'.

If AD trust is enabled warn if package is not installed

If AD trust is enabled and the master does not have the freeipa-server-trust-ad package installed then the master will able to resolve users/groups via extdom plugin and sssd but won't be able to do framework-specific operations.

This should be a WARNING level issue.

Change DNA plugin to return WARNING if no range is set

Current ipahealthcheck.ipa.dna returns SUCCESS both when a range is set and when one is not set.

Elevate the not set version to WARNING so admins can be aware in advance that with no range then uid/gid cannot be allocated from this master. This is particularly important if the only master with a range defined is retired.

[RFE] Check for certs in stuck status

I noticed one of the certs on a CentOS 8 server got stuck:

Request ID '20200123083218':
        status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN
        stuck: yes
        key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key'
        certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt'
        CA: IPA
        issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
        subject: CN=ipa2.ipa.example.com,O=IPA.EXAMPLE.COM
        expires: 2021-12-19 18:32:27 UTC
        dns: ipa2.ipa.example.com
        principal name: HTTP/[email protected]
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command:
        post-save command: /usr/libexec/ipa/certmonger/restart_httpd
        track: yes
        auto-renew: yes

ipahealthcheck.ipa.certs doesn't complain about this. It would be useful if the module checked for the stuck status of each certificate request.

pki-healthcheck fails with 'Namespace' object has no attribute 'failures_only' with 0.6

Reported against Fedora 31 with freeipa-healthcheck-0.6-1 and pki-server-10.9.0-0.2.fc31

# pki-healthcheck
Traceback (most recent call last):
  File "/usr/sbin/pki-healthcheck", line 11, in <module>
    load_entry_point('pkihealthcheck==0.1', 'console_scripts', 'pki-healthcheck')()
  File "/usr/lib/python3.8/site-packages/pki/server/healthcheck/core/main.py", line 31, in main
    sys.exit(checks.run_healthcheck())
  File "/usr/lib/python3.8/site-packages/ipahealthcheck/core/core.py", line 280, in run_healthcheck
    output = out(options)
  File "/usr/lib/python3.8/site-packages/ipahealthcheck/core/output.py", line 102, in __init__
    super(JSON, self).__init__(options)
  File "/usr/lib/python3.8/site-packages/ipahealthcheck/core/output.py", line 40, in __init__
    self.failures_only = options.failures_only
AttributeError: 'Namespace' object has no attribute 'failures_only'

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.