mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-24 16:10:02 -06:00
7995518921
The latest version of caIPAserviceCert profile includes a feature that is not available before Dogtag 10.4, and this version of the profile is intended for new installs only (otherwise, problems will arise in topologies containing CA replicas at an earlier version). But IPA versions before v4.2 did not use LDAP-based profiles, so the new version of the profile gets imported when upgrading from pre-v4.2 to v4.5 or later. We do not yet have a proper version- and topology-aware profile update mechanism, so to resolve this issue, ship the older version of the profile alongside the newer version, and make sure we use the older version when importing the profile in an upgrade context. https://pagure.io/freeipa/issue/7097 Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com> |
||
|---|---|---|
| .. | ||
| certmonger | ||
| conf | ||
| 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.