Learn more about these different git repos.
Other Git URLs
When making a change to the sssd.conf file, changes appear to be dynamic and applied automatically without restarting sssd. However, a change to userObjectClass and userAttributeName, gets read in dynamically and appears in config.ldb, but subsequent searches are still using the previous values.
Steps to reproduce: ( My ldap be is connecting to an Active Directory Server ) 1. current config
ldapUri = ldap://jennyv3.bos.redhat.com:389 defaultBindDn = cn=Administrator,cn=Users,dc=bos,dc=redhat,dc=com userSearchBase = cn=users,dc=bos,dc=redhat,dc=com userObjectClass = user userAttributeName = cn userName = cn provider = ldap
debug search output
[sssd[be[ldap]]] [sdap_get_users_transaction] (5): calling ldap_search_ext with [(&(cn=*)(objectclass=user))].
Modify sssd.config and change userObjectClass to person and userAttributeName to uid
debug output of dynamic configuration change
[sssd] [monitor_signal_reconf] (1): Configuration has changed. Reloading. [sssd] [confdb_create_ldif] (6): Processing config section [services] [sssd] [confdb_create_ldif] (6): Processing attribute [description] [sssd] [confdb_create_ldif] (6): Processing attribute [activeServices] [sssd] [confdb_create_ldif] (6): Processing config section [services/nss] [sssd] [confdb_create_ldif] (6): Processing attribute [description] [sssd] [confdb_create_ldif] (6): Processing attribute [filterGroups] [sssd] [confdb_create_ldif] (6): Processing attribute [filterUsers] [sssd] [confdb_create_ldif] (6): Processing config section [services/dp] [sssd] [confdb_create_ldif] (6): Processing attribute [description] [sssd] [confdb_create_ldif] (6): Processing config section [services/pam] [sssd] [confdb_create_ldif] (6): Processing attribute [description] [sssd] [confdb_create_ldif] (6): Processing config section [services/monitor] [sssd] [confdb_create_ldif] (6): Processing attribute [description] [sssd] [confdb_create_ldif] (6): Processing attribute [sbusTimeout] [sssd] [confdb_create_ldif] (6): Processing config section [domains] [sssd] [confdb_create_ldif] (6): Processing attribute [description] [sssd] [confdb_create_ldif] (6): Processing attribute [domains] [sssd] [confdb_create_ldif] (6): Processing config section [domains/LDAP] [sssd] [confdb_create_ldif] (6): Processing attribute [description] [sssd] [confdb_create_ldif] (6): Processing attribute [enumerate] [sssd] [confdb_create_ldif] (6): Processing attribute [minId] [sssd] [confdb_create_ldif] (6): Processing attribute [maxId] [sssd] [confdb_create_ldif] (6): Processing attribute [legacy] [sssd] [confdb_create_ldif] (6): Processing attribute [cache-credentials] [sssd] [confdb_create_ldif] (6): Processing attribute [ldapUri] [sssd] [confdb_create_ldif] (6): Processing attribute [defaultBindDn] [sssd] [confdb_create_ldif] (6): Processing attribute [userSearchBase] [sssd] [confdb_create_ldif] (6): Processing attribute [userObjectClass] [sssd] [confdb_create_ldif] (6): Processing attribute [userAttributeName] [sssd] [confdb_create_ldif] (6): Processing attribute [userName] [sssd] [confdb_create_ldif] (6): Processing attribute [provider] [sssd] [confdb_create_ldif] (6): Processing attribute [timeout] [sssd] [confdb_init_db] (7): LDIF file to import: dn: cn=config version: 1
dn: cn=services,cn=config cn: services description: Local Service Configuration activeServices: nss, dp, pam
dn: cn=nss,cn=services,cn=config cn: nss description: NSS Responder Configuration filterGroups: root filterUsers: root
dn: cn=dp,cn=services,cn=config cn: dp description: Data Provider Configuration
dn: cn=pam,cn=services,cn=config cn: pam description: PAM Responder Configuration
dn: cn=monitor,cn=services,cn=config cn: monitor description: Service Monitor Configuration sbusTimeout: 30
dn: cn=domains,cn=config cn: domains description: Domains served by SSSD domains: LDAP
dn: cn=LDAP,cn=domains,cn=config cn: LDAP description: Proxy request to our LDAP server enumerate: 3 minId: 1000 maxId: 1010 legacy: FALSE cache-credentials: FALSE ldapUri: ldap://jennyv3.bos.redhat.com:389 defaultBindDn: cn=Administrator,cn=Users,dc=bos,dc=redhat,dc=com userSearchBase: cn=users,dc=bos,dc=redhat,dc=com userObjectClass: person userAttributeName: uid userName: cn provider: ldap timeout: 30
subsequent getent -s sss passwd search filter is still:
[sssd[be[ldap]]] [sdap_get_users_transaction] (5): calling ldap_search_ext with [(&(cn=*)(objectclass=user))]
SSSD VERSION: sssd-2009072913-0.fc11.i586
Cleaning up the summary and assigning to myself.
Right now live updates of the configuration file affect only the monitor. The data provider, backends and responders do not update live.
description: When making a change to the sssd.conf file, changes appear to be dynamic and applied automatically without restarting sssd. However, a change to userObjectClass and userAttributeName, gets read in dynamically and appears in config.ldb, but subsequent searches are still using the previous values.
Steps to reproduce: ( My ldap be is connecting to an Active Directory Server ) 1. current config ldapUri = ldap://jennyv3.bos.redhat.com:389 defaultBindDn = cn=Administrator,cn=Users,dc=bos,dc=redhat,dc=com userSearchBase = cn=users,dc=bos,dc=redhat,dc=com userObjectClass = user userAttributeName = cn userName = cn provider = ldap
debug search output [sssd[be[ldap]]] [sdap_get_users_transaction] (5): calling ldap_search_ext with [(&(cn=*)(objectclass=user))].
SSSD VERSION: sssd-2009072913-0.fc11.i586 => When making a change to the sssd.conf file, changes appear to be dynamic and applied automatically without restarting sssd. However, a change to userObjectClass and userAttributeName, gets read in dynamically and appears in config.ldb, but subsequent searches are still using the previous values.
Steps to reproduce: ( My ldap be is connecting to an Active Directory Server ) 1. current config {{{ ldapUri = ldap://jennyv3.bos.redhat.com:389 defaultBindDn = cn=Administrator,cn=Users,dc=bos,dc=redhat,dc=com userSearchBase = cn=users,dc=bos,dc=redhat,dc=com userObjectClass = user userAttributeName = cn userName = cn provider = ldap }}} 1. debug search output {{{ [sssd[be[ldap]]] [sdap_get_users_transaction] (5): calling ldap_search_ext with [(&(cn=*)(objectclass=user))]. }}} 1. Modify sssd.config and change userObjectClass to person and userAttributeName to uid
dn: cn=LDAP,cn=domains,cn=config cn: LDAP description: Proxy request to our LDAP server enumerate: 3 minId: 1000 maxId: 1010 legacy: FALSE cache-credentials: FALSE ldapUri: ldap://jennyv3.bos.redhat.com:389 defaultBindDn: cn=Administrator,cn=Users,dc=bos,dc=redhat,dc=com userSearchBase: cn=users,dc=bos,dc=redhat,dc=com userObjectClass: person userAttributeName: uid userName: cn provider: ldap timeout: 30 }}} 1. subsequent getent -s sss passwd search filter is still: {{{ [sssd[be[ldap]]] [sdap_get_users_transaction] (5): calling ldap_search_ext with [(&(cn=*)(objectclass=user))] }}}
owner: somebody => sgallagh
Bumping up the priority on this, as I'd like to get it into 0.5.0.
The reason behind this is that the backends are not currently doing anything with the "reloadConfig" method that they are sent.
component: SSSD => Service Monitor milestone: SSSD 1.0 => Iteration 6 priority: minor => critical status: new => assigned
Reducing severity to 'major'. I think we'll just document that the dynamic configuration update is not working yet and that they should restart the SSSD service when making changes.
priority: critical => major
Fields changed
milestone: SSSD 0.5.0 => SSSD 0.6.0
doc: => 0 docupdated: => 0 tests: => 1 testsupdated: => 0
milestone: SSSD 0.6.0 => SSSD 0.6.1
milestone: SSSD 0.6.1 => SSSD 0.7.0
Live update of the configuration can be deferred.
milestone: SSSD 0.7.0 => SSSD Deferred
status: assigned => new
I've been rethinking our decision to have config file changes automatically update the running configuration. This has the potential to cause great havoc. I think it's safer as it currently exists, requiring a restart of the service to pick up config file changes.
proposed: => resolution: => wontfix status: new => closed
If dynamic updates will not be implemented, it will not be tested ;-)
tests: 1 => 0
Metadata Update from @jgalipea: - Issue assigned to sgallagh - Issue set to the milestone: SSSD Patches welcome
Metadata Update from @jhrozek: - Custom field rhbz adjusted to 0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1133
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.