Red Hat Bugzilla – 1939527 – RFE: Permanently Persistent Local (on-system) SSS Overrides both automating importation (such as after the SSS DB is cleared and SSSD restarted) and a standard location for the override export files
Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
RFE: Permanently Persistent Local (on-system) SSS Overrides both automating importation (such as after the SSS DB is cleared and SSSD restarted) and a standard location for the override export files
1. Proposed title of this feature request
Permanently Persistent Local (on-system) SSS Overrides - both automating importation (such as after the SSS DB is cleared and SSSD restarted) and a standard location for the override export files
2. What is the nature and description of the request?
Nominally SSS Overrides, ID Views and other, system-specific SSSD differences are stored in Enterprise IdM (FreeIPA). But for customers who have not yet implemented IdM/IPA, or are using another solution (e.g., AD-LDAP, RHDS/389 Server or possibly another LDAP source), Local SSS Overrides can still be used. This solution should be automated and the local (on-system) location for storing SSS Override Export files should be standardized.
Currently, Local SSS Overrides (e.g., users and groups) require 3 steps in sequence.
A) SSSD to be started to load
B) SSS Overrides to be loaded (e.g., sss_override import-users and/or import-groups)
C) SSSD to be restarted after load to become effective
The 'A-C aspect is a chicken-egg issue whereby SSSD has to be started, loaded, then restarted, for the loaded SSS Overrides to take effect.
I.e., there is no way to create a systemd sssd service unit file override (e.g., /etc/systemd/system/sssd.service.d/override.conf) with execStartPre=/execStartPost= lines to load SSS Overrides (e.g., via sss_override import-user file or sss_override import-group file) as SSSD has to be restarted after.
And although the SSS Overrides are stored in the DB going forward, if the local DB is ever cleared (a common troubleshooting solution), they are lost.
This is the major issue for customers without Red Hat Enterprise IdM (FreeIPA) implemented, and using another LDAP or POSIX attribute authority with SSSD.
This solution provides a Permanently Persistent means to always re-load SSS Overrides from local export files, even when the SSS DB has been cleared, and any prior SSS Overrides lost.
3. Why do you need this? (List the business requirements here)
Any customer that uses SSS Overrides, but does not use Red Hat Enterprise IdM (IPA), but another LDAP or other POSIX attribute store.
Currently all loaded SSS Overrides do not 'survive' a SSS DB clear, unless one has Enterprise IdM (IPA), and many Enterprises do not.
4. How would you like to achieve this? (List the functional requirements here)
Final design is left to Red Hat. However, one suggestion would be ...
A) Solve Chicken-Egg: Modify SSSD to it does not need to be restarted after User, Group, etc... SSS Override Importation (e.g., after a sss_override import-user file or sss_override import-group file is executed)
B) Standardize/Automate - Have SSSD look for override files in a standard location, and one that is not commonly 'blown away' in troubleshooting as well (i.e., under /var). E.g., possibly /etc/sssd/user.d/ and /etc/sssd/group.d/ for Users and Group SSS Override export files, respectively -- under /etc instead of /var, since they are static/user configuration files, and not variable.
5. Would you be able to assist in testing this functionality if implemented?
Absolutely. In fact, we currently have an Ansible Playbook we use to manually 'push out' SSS Overrides, but this is not automated/standardized, and does not solve the issue of knowing when troubleshooters clear the DB. It has to be manually identified and re-executed. This RFE is to put this functionality into the local (on-system) SSSD implementation. We would absolutely be able to test any RFE on our Dev/Test systems for Red Hat.
1. Proposed title of this feature request Permanently Persistent Local (on-system) SSS Overrides - both automating importation (such as after the SSS DB is cleared and SSSD restarted) and a standard location for the override export files 2. What is the nature and description of the request? Nominally SSS Overrides, ID Views and other, system-specific SSSD differences are stored in Enterprise IdM (FreeIPA). But for customers who have not yet implemented IdM/IPA, or are using another solution (e.g., AD-LDAP, RHDS/389 Server or possibly another LDAP source), Local SSS Overrides can still be used. This solution should be automated and the local (on-system) location for storing SSS Override Export files should be standardized. Currently, Local SSS Overrides (e.g., users and groups) require 3 steps in sequence. A) SSSD to be started to load B) SSS Overrides to be loaded (e.g., sss_override import-users and/or import-groups) C) SSSD to be restarted after load to become effective The 'A-C aspect is a chicken-egg issue whereby SSSD has to be started, loaded, then restarted, for the loaded SSS Overrides to take effect. I.e., there is no way to create a systemd sssd service unit file override (e.g., /etc/systemd/system/sssd.service.d/override.conf) with execStartPre=/execStartPost= lines to load SSS Overrides (e.g., via sss_override import-user file or sss_override import-group file) as SSSD has to be restarted after. And although the SSS Overrides are stored in the DB going forward, if the local DB is ever cleared (a common troubleshooting solution), they are lost. This is the major issue for customers without Red Hat Enterprise IdM (FreeIPA) implemented, and using another LDAP or POSIX attribute authority with SSSD. This solution provides a Permanently Persistent means to always re-load SSS Overrides from local export files, even when the SSS DB has been cleared, and any prior SSS Overrides lost. 3. Why do you need this? (List the business requirements here) Any customer that uses SSS Overrides, but does not use Red Hat Enterprise IdM (IPA), but another LDAP or other POSIX attribute store. Currently all loaded SSS Overrides do not 'survive' a SSS DB clear, unless one has Enterprise IdM (IPA), and many Enterprises do not. 4. How would you like to achieve this? (List the functional requirements here) Final design is left to Red Hat. However, one suggestion would be ... A) Solve Chicken-Egg: Modify SSSD to it does not need to be restarted after User, Group, etc... SSS Override Importation (e.g., after a sss_override import-user file or sss_override import-group file is executed) B) Standardize/Automate - Have SSSD look for override files in a standard location, and one that is not commonly 'blown away' in troubleshooting as well (i.e., under /var). E.g., possibly /etc/sssd/user.d/ and /etc/sssd/group.d/ for Users and Group SSS Override export files, respectively -- under /etc instead of /var, since they are static/user configuration files, and not variable. 5. Would you be able to assist in testing this functionality if implemented? Absolutely. In fact, we currently have an Ansible Playbook we use to manually 'push out' SSS Overrides, but this is not automated/standardized, and does not solve the issue of knowing when troubleshooters clear the DB. It has to be manually identified and re-executed. This RFE is to put this functionality into the local (on-system) SSSD implementation. We would absolutely be able to test any RFE on our Dev/Test systems for Red Hat.