mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-23 15:40:01 -06:00
78298fd4e1
Configures PKI to remove expired certificates and non-resolved requests on a schedule. This is geared towards ACME which can generate a lot of certificates over a short period of time but is general purpose. It lives in ipa-acme-manage because that is the primary reason for including it. Random Serial Numbers v3 must be enabled for this to work. Enabling pruning enables the job scheduler within CS and sets the job user as the IPA RA user which has full rights to certificates and requests. Disabling pruning does not disable the job scheduler because the tool is stateless. Having the scheduler enabled should not be a problem. A restart of PKI is required to apply any changes. This tool forks out to pki-server which does direct writes to CS.cfg. It might be easier to use our own tooling for this but this makes the integration tighter so we pick up any improvements in PKI. The "cron" setting is quite limited, taking only integer values and *. It does not accept ranges, either - or /. No error checking is done in PKI when setting a value, only when attempting to use it, so some rudimentary validation is done. Fixes: https://pagure.io/freeipa/issue/9294 Signed-off-by: Rob Crittenden rcritten@redhat.com Reviewed-By: Florence Blanc-Renaud <flo@redhat.com> |
||
|---|---|---|
| .. | ||
| certmonger | ||
| custodia | ||
| html | ||
| migration | ||
| oddjob | ||
| restart_scripts | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| wsgi | ||
| Makefile.am | ||
| README.schema | ||
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.