661640 - SVN/Hg inactivity checker may be disabling new/re-activated accounts too aggressively

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[:Gavin Sharp [email: [e-mail]]]

I've seen it happen a few times that people who just recently got access (e.g. bug 660615 comment 2) run into the "account disabled due to inactivity" warning. I've also seen this happen for people who request re-activation but then don't use their account soon enough after that occurs (e.g. bug 648707 comment 4).

My understanding of the inactivity script (implemented in bug 524153) is that it's a cron job that runs every 24 hours, checks user activity, and disables accounts that haven't had activity for >6 months (or some other threshold).

My theory is that perhaps the script only checks actual push activity, so new accounts or recently re-enabled accounts can get re-disabled before the person has a chance to actually use them if the script runs shortly after the creation/re-activation.

Ideally the auto-disable functionality would:
- use account creation date instead of last-push date to determine "activity" for accounts that have no activity (haven't yet been used)
- treat account re-activation as "activity"

Either of those may already be happening, but I've seen enough cases where accounts get mysteriously disable again that I thought it'd be useful to investigate.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Another example: bug 647250 comment 3

Comment 2

[Justin Dow [:jabba]]

The script is /root/bin/vcs_accounts_disable.py 

Aravind had originally written the script in clojure and then re-wrote it in python right before he departed and I don't think he had time to test it well or verify that it is working properly. I do remember him mentioning that he dialed up its sensitivity, but haven't looked myself yet, as my python skillz aren't great.

Noahm, could you take a look at it?

Comment 3

[Noah Meyerhans [:noahm]]

/me cries

Comment 4

[cmtalbert]

Any news on this?  I just had someone on my team hit it, and I would not want this to happen to one of our volunteer contributors.  It'd be terrible.  I'll happily volunteer my services as python developer if I can help expedite this in any way.

Comment 5

[Rob Tucker [:rtucker]]

I've got a fix in place on my dev box that does the following:

If an account goes from being disabled to enabled it sets the svnAccessDate attribute to the time the account was activated again.

This fixes the issue of people getting locked out again in 24 hours if there's no push activity, it could however have a bad effect if anyone else is tracking svnAccessDate. I would think though that the most important thing here is that accounts work, verses some sort of reporting metric based on svnAccessDate.

Clint:
You know more about the effects of this than I do, does this sound acceptable? 

If so then I'll push it.

Comment 6

[Rob Tucker [:rtucker]]

After talking with jabba, I decided to put the fix in place. I tested it this morning, after reenabling a previously disabled account, the [svn|hg]AccessDate property now gets set to the time the account was activated again, thus solving the problem. If anyone has an issue with this please let me know.

Comment 7

[cmtalbert]

(In reply to Rob Tucker [:rtucker] from comment #5)
> I've got a fix in place on my dev box that does the following:
> 
> If an account goes from being disabled to enabled it sets the svnAccessDate
> attribute to the time the account was activated again.
> 
> This fixes the issue of people getting locked out again in 24 hours if
> there's no push activity, it could however have a bad effect if anyone else
> is tracking svnAccessDate. I would think though that the most important
> thing here is that accounts work, verses some sort of reporting metric based
> on svnAccessDate.
> 
> Clint:
> You know more about the effects of this than I do, does this sound
> acceptable? 
> 
> If so then I'll push it.

That sounds fine to me.  Thanks for pushing it, and thanks for the fix!