[SSSD] [sssd PR#143][synchronized] Explicitly add ordering dependency for the responders' sockets

URL: https://github.com/SSSD/sssd/pull/143 Author: fidencio Title: #143: Explicitly add ordering dependency for the responders' sockets Action: synchronized To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/143/head:pr143 git checkout pr143

[SSSD] [sssd PR#143][edited] Explicitly add ordering dependency for the responders' sockets

URL: https://github.com/SSSD/sssd/pull/143 Author: fidencio Title: #143: Explicitly add ordering dependency for the responders' sockets Action: edited Changed field: body Original value: """ This patch set is intended to solve https://fedorahosted.org/sssd/ticket/3298 and more details can

[SSSD] [sssd PR#143][synchronized] Explicitly add ordering dependency for the responders' sockets

URL: https://github.com/SSSD/sssd/pull/143 Author: fidencio Title: #143: Explicitly add ordering dependency for the responders' sockets Action: synchronized To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/143/head:pr143 git checkout pr143

[SSSD] [sssd PR#144][opened] SSSD does not start if using only the local provider and services line is empty

URL: https://github.com/SSSD/sssd/pull/144 Author: fidencio Title: #144: SSSD does not start if using only the local provider and services line is empty Action: opened PR body: """ SSSD has to notify systemd whenever its startup is finished. Currently it has been done only when a service

[SSSD] [sssd PR#144][synchronized] SSSD does not start if using only the local provider and services line is empty

URL: https://github.com/SSSD/sssd/pull/144 Author: fidencio Title: #144: SSSD does not start if using only the local provider and services line is empty Action: synchronized To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/144/head:pr144

[SSSD] [sssd PR#145][opened] Fix storing a sudoRule attriubute in a case-insensitive domain when the attriubute values differ only by case

URL: https://github.com/SSSD/sssd/pull/145 Author: jhrozek Title: #145: Fix storing a sudoRule attriubute in a case-insensitive domain when the attriubute values differ only by case Action: opened PR body: """ I guess because different versions of sssd placed different constraints on the

[SSSD] [sssd PR#127][-Changes requested] ssh: use cache_req

URL: https://github.com/SSSD/sssd/pull/127 Title: #127: ssh: use cache_req Label: -Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Avoid running two instances of the same service (#3300)

I've spent some amount of time trying to properly deal with this issue and I really need the opinion/suggestion of more experienced developers. Basically, as explained in #3300 this situation can happen is two scenarios were the admin is mixing up socket-activated and explicitly configured

[SSSD] [sssd PR#145][comment] Fix storing a sudoRule attriubute in a case-insensitive domain when the attriubute values differ only by case

URL: https://github.com/SSSD/sssd/pull/145 Title: #145: Fix storing a sudoRule attriubute in a case-insensitive domain when the attriubute values differ only by case fidencio commented: """ @jhrozek, There's one thing I didn't understand quite well. In the case you gave as problematic: