On 03/26/2015 10:30 AM, Lukas Slebodnik wrote:
>On (26/03/15 10:22), Pavel Reichl wrote:
>>On 03/26/2015 10:19 AM, Lukas Slebodnik wrote:
>>>On (26/03/15 10:11), Jakub Hrozek wrote:
>>>>On Thu, Mar 26, 2015 at 09:55:46AM +0100, Pavel Reichl wrote:
>>>>>On 03/26/2015 09:48 AM, Lukas Slebodnik wrote:
>>>>>>On (26/03/15 09:26), Pavel Reichl wrote:
>>>>>>>On 03/25/2015 09:53 PM, Lukas Slebodnik wrote:
>>>>>>>>On (25/03/15 14:35), Pavel Reichl wrote:
>>>>>>>>>On 03/25/2015 02:21 PM, Lukas Slebodnik wrote:
>>>>>>>>>>On (25/03/15 14:05), Pavel Reichl wrote:
>>>>>>>>>>>On 03/25/2015 01:51 PM, Lukas Slebodnik
wrote:
>>>>>>>>>>>>On (25/03/15 12:01), Pavel Reichl wrote:
>>>>>>>>>>>>>Hello please see attached patch.
>>>>>>>>>>>>>
>>>>>>>>>>>>>The need for this patch was discussed
in thread: SDAP: Lock out ssh keys when
>>>>>>>>>>>>>account naturally expires
>>>>>>>>>>>>>This patch implements point number 3.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>I would prefer if we
didn't add a new option as well, but since we
>>>>>>>>>>>>>>>released
>>>>>>>>>>>>>>>a version that only supported
the lockout and not any other semantics,
>>>>>>>>>>>>>>>I don't think we can get
away with just changing the functionality. A
>>>>>>>>>>>>>>>minor version can break
functionality. But a major version can
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>So I propose the following:
>>>>>>>>>>>>>>>1) Add a new value for
ldap_access_order called "ppolicy" that would
>>>>>>>>>>>>>>>evaluate the
pwdAccountLockedTime fully, including the new
>>>>>>>>>>>>>>>functionality in this
patchset
>>>>>>>>>>>>>>>2) In 1.12, deprecate the
"lockout" option and log a warning that it
>>>>>>>>>>>>>>>will be removed in future
relase and users should migrate to "ppolicy"
>>>>>>>>>>>>>>>option
>>>>>>>>>>>>The feature was introduced in sssd-1.12.1
and deprecated in sssd-1.12.5
>>>>>>>>>>>>That's really fast progres. The
deprecating the features
>>>>>>>>>>>>after half a year.
>>>>>>>>>>>>
>>>>>>>>>>>>Could someone exaplain me why do we need
to do such ritual dances?
>>>>>>>>>>>>
>>>>>>>>>>>>LS
>>>>>>>>>>>First there was user ho wanted lockout
functionality that is being dropped
>>>>>>>>>>>now.
https://fedorahosted.org/sssd/ticket/2364
>>>>>>>>>>>
>>>>>>>>>>>Then a few months later there came another
user with
>>>>>>>>>>>https://fedorahosted.org/sssd/ticket/2534 who
wished to do something similar
>>>>>>>>>>>but different.
>>>>>>>>>>>
>>>>>>>>I checked bugzilla tickets and the same user requested
both features.
>>>>>>>But we can't be sure there are other users using it, can
we? IMO we can't
>>>>>>>break their configuration at least not in minor release.
>>>>>>You wrote in previous mail:
>>>>>>"""
>>>>>>First there was user ho wanted lockout functionality that is being
dropped
>>>>>>now.
https://fedorahosted.org/sssd/ticket/2364
>>>>>>
>>>>>>Then a few months later there came another user with
>>>>>>https://fedorahosted.org/sssd/ticket/2534 who wished to do
something similar
>>>>>>but different.
>>>>>>
>>>>>>We think that user case addressed in 1st ticket can be handled by
>>>>>>functionality introduced for 2nd ticket.
>>>>>>"""
>>>>>>
>>>>>>So if use case addresed in the 1st ticket can be handled by
functionality
>>>>>>introduced for 2nd ticket then we can simply drop the 1st
functionality
>>>>>>and make an alias from "lockout" to
"ppolicy".
>>>>>>
>>>>>>This is very elegant solution which does not break old
configurations.
>>>>>Yes, it sounds definitely better as configuration would not break.
Only
>>>>>problem I see is the fact that after update some users would not be
allowed
>>>>>to log in but they were allowed to do so before update. That's not
a
>>>>>security issue and with proper debug message I suppose it could be OK.
But I
>>>>>still think that the best think to do is to discuss it on devel
meeting.
>>>>Yes, I really don't want to remove functionality in a .z release.
>>>>
>>>>I don't think we need to be bound by the bugzilla either. Let's
do
>>>>upstream what's best for upstream -- in my opinion it's
deprecating the
>>>>option in sssd-1-12 so that existing users might migrate until they
>>>>prepare for sssd-1-13. Then removing the option in sssd-1-13.
>>>>
>>>>Is that acceptable for /upstream/ ?
>>>I still don't understand why we need to deprecate the option.
>>>
>>>Pavel claims:
>>>"""
>>> We think that user case addressed in 1st ticket can be handled by
>>> functionality introduced for 2nd ticket.
>>>"""
>>Lukas I also wrote:
>>>Only problem I see is the fact that after update some users would not be
>>>allowed to log in but they were allowed to do so before update.
>>It similar but not the same.
>>
>It wasn't mentioned at the beginning.
>
>If they are not the same the I do not agree with removing this feature.
>Because they can be user which can rely on such behaviour and
>it could be considered as a REGRESSION.
>
>So please decide if they are the same or aren't.
>
>
Lukas you are quoiting just part of my message:
"""
First there was user ho wanted lockout functionality that is being dropped
now.
https://fedorahosted.org/sssd/ticket/2364
Then a few months later there came another user with
https://fedorahosted.org/sssd/ticket/2534 who wished to do something similar
but different.
^^^^^^^^^^^^^^^^^^^^^^
We think that user case addressed in 1st ticket can be handled by
functionality introduced for 2nd ticket.
"""
You also said:
"""
I mentioned it as a part of review a month ago.
So you needn't explain it to me.
"""
So I supposed you knew the difference between the options.
Yes I know the
difference.
IMHO we can simply drop feature #2364 and make an alias
from "lockout" to "ppolicy".
But I know that other people can have different opinion.
That's the reason why I asked you to decide.
I really don't want to have any REGRESSIONS in sssd.
LS