Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=891356 (Red Hat Enterprise Linux 6)
Description of problem: Smart refresh doesn't notice a newly added "defaults" entry with OpenLDAP server. It gets noticed only after full refresh. Version-Release number of selected component (if applicable): libsss_idmap-1.9.2-59.el6.x86_64 sssd-client-1.9.2-59.el6.x86_64 sudo-1.8.6p3-6.el6.x86_64 sssd-1.9.2-59.el6.x86_64 libsss_sudo-1.9.2-59.el6.x86_64 openldap-servers-2.4.23-31.el6.x86_64 How reproducible: always Steps to Reproduce: 1. Use the attached sudo_defaults_openldap_test.ldif file to fill LDAP directory. 2. Use the attached sssd.conf as the base for SSSD configuration. 3. Execute the attached sudo_defaults_openldap_test script as root after modifying it to connect to the LDAP server. Actual results: sudo: no tty present and no askpass program specified initially: 1 sudo: no tty present and no askpass program specified smart_refresh_with_rule_added: 1 sudo: no tty present and no askpass program specified smart_refresh_with_defaults_added: 1 full_refresh_with_defaults_added: 0 Expected results: sudo: no tty present and no askpass program specified initially: 1 sudo: no tty present and no askpass program specified smart_refresh_with_rule_added: 1 smart_refresh_with_defaults_added: 0 full_refresh_with_defaults_added: 0 Additional info: This works with sssd sudo backend and 389-ds and with LDAP sudo backend and OpenLDAP server.
Fields changed
blockedby: => blocking: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => owner: somebody => pbrezina selected: => status: new => assigned testsupdated: => 0
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=891635 (Red Hat Enterprise Linux 6)
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356] => [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356], [https://bugzilla.redhat.com/show_bug.cgi?id=891635 891635]
milestone: NEEDS_TRIAGE => SSSD 1.9.4
https://bugzilla.redhat.com/show_bug.cgi?id=891635 was actually not a bug and it wasn't related to 891356 after all.
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356], [https://bugzilla.redhat.com/show_bug.cgi?id=891635 891635] => [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356]
I managed to reproduce this issue. The problem is that OpenLDAP check whether the filter contains schema-correct value for modifyTimestamp attribute.
So instead of modifyTimestamp>=0, we should use modifyTimestamp>=000101010000Z in smart refresh.
_comment0: I managed to reproduce this issue. The problem is that OpenLDAP check whether the filter contains schema-correct value for modify timestamp.
So instead of modifyTimestamp>=0, we should use modifyTimestamp>=000101010000Z. => 1357306071915858
Or we can just avoid using modifyTimestamp in filter at all when it is 0.
patch: 0 => 1
resolution: => fixed status: assigned => closed
Metadata Update from @jhrozek: - Issue assigned to pbrezina - Issue set to the milestone: SSSD 1.9.4
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/2778
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.