URL: https://github.com/SSSD/sssd/pull/70
Title: #70: check_duplicate: check name member before using it
lslebodn commented:
"""
On (10/02/17 08:35), Jakub Hrozek wrote:
>I'm not sure if it's even possible to write an integration test because even
>after the patch, sssd doesn't start, it
URL: https://github.com/SSSD/sssd/pull/70
Title: #70: check_duplicate: check name member before using it
jhrozek commented:
"""
I'm not sure if it's even possible to write an integration test because even
after the patch, sssd doesn't start, it 'just' doesn't segfault.
"""
See the full
URL: https://github.com/SSSD/sssd/pull/70
Title: #70: check_duplicate: check name member before using it
Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to
URL: https://github.com/SSSD/sssd/pull/70
Title: #70: check_duplicate: check name member before using it
Label: -Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to
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
Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To
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: closed
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch
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
jhrozek commented:
"""
master:
a5ecc93abb01cece628fdef04ebad43bba267419
sssd-1-14:
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
jhrozek commented:
"""
We can add a debug message about the duplicates, but unfortunately some admins
had to keep the
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: closed
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/144/head:pr144
git
URL: https://github.com/SSSD/sssd/pull/144
Title: #144: SSSD does not start if using only the local provider and services
line is empty
Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to
URL: https://github.com/SSSD/sssd/pull/144
Title: #144: SSSD does not start if using only the local provider and services
line is empty
jhrozek commented:
"""
master:
00c0b7bc6969d31deab9e8e7541b4a6483b78b3e
040ade7b2e11fecf615aedf58592cc7245900e86
"""
See the full comment
URL: https://github.com/SSSD/sssd/pull/137
Title: #137: Initial pkinit support
lslebodn commented:
"""
On (09/02/17 02:50), sumit-bose wrote:
>Thank you for running the tests, the valgirind issue was the same as the last
>coverity warning.
>
The function get_pkinit_identity is defined inside
URL: https://github.com/SSSD/sssd/pull/144
Title: #144: SSSD does not start if using only the local provider and services
line is empty
jhrozek commented:
"""
Plus, probably nothing will change in this patch.
"""
See the full comment at
URL: https://github.com/SSSD/sssd/pull/144
Title: #144: SSSD does not start if using only the local provider and services
line is empty
Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to
Hi,
are there any SSSD users who actively use a configuration with:
id_provider=local ?
If so, what is your use-case?
We're considering deprecating and eventually removing this provider
upstream. The replacemant for id_provider=local would be id_provider=files:
El 10/02/17 a las 09:28, Jakub Hrozek escribió:
> On Thu, Feb 09, 2017 at 09:50:18PM +0100, Victor Tapia wrote:
I've been testing a scenario with a time shift of an hour to the past,
and even though the watchdog detects the shift and restarts, the
scheduled events are still stuck
On Thu, Feb 09, 2017 at 09:50:18PM +0100, Victor Tapia wrote:
> >> I've been testing a scenario with a time shift of an hour to the past,
> >> and even though the watchdog detects the shift and restarts, the
> >> scheduled events are still stuck until the time passes.
> >
> >What kind of scheduled
17 matches
Mail list logo