mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
c6a1bd591e
If sssd user does not exist, it means SSSD does not run as sssd user. Currently SSSD has too tight check for keytab permissions and ownership. It assumes the keytab has to be owned by the same user it runs under and has to have 0600 permissions. ipa-getkeytab creates the file with right permissions and 'root:root' ownership. Jakub Hrozek promised to enhance SSSD keytab permissions check so that both sssd:sssd and root:root ownership is possible and then when SSSD switches to 'sssd' user, the former becomes the default. Since right now SSSD 1.13 is capable to run as 'sssd' user but doesn't create 'sssd' user in Fedora 22 / RHEL 7 environments, we can use its presence as a version trigger. https://fedorahosted.org/freeipa/ticket/5136 Reviewed-By: Tomas Babej <tbabej@redhat.com> |
||
|---|---|---|
| .. | ||
| certmonger | ||
| conf | ||
| ffextension | ||
| html | ||
| migration | ||
| oddjob | ||
| po | ||
| restart_scripts | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| wsgi | ||
| configure.ac | ||
| 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.