mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
0b08043c37
The KRA backend has been simplified since most of the tasks have been moved somewhere else. The transport certificate will be installed on the client, and it is not needed by KRA backend. The KRA agent's PEM certificate is now generated during installation due to permission issue. The kra_host() for now is removed since the current ldap_enable() cannot register the KRA service, so it is using the kra_host environment variable. The KRA installer has been modified to use Dogtag's CLI to create KRA agent and setup the client authentication. The proxy settings have been updated to include KRA's URLs. Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 has been renamed to DOGTAG_ADMIN_P12 since file actually contains the Dogtag admin's certificate and private key and it can be used to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed to KRA_AGENT_PEM since it can only be used for KRA. The Dogtag dependency has been updated to 10.2.1-0.1. https://fedorahosted.org/freeipa/ticket/4503 Reviewed-By: Petr Viktorin <pviktori@redhat.com>
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.