Hello! Today I found that my shell access to dev.gentoo.org and mail access via pop3/smtp is blocked due to "expired account" by an unknown entity. I find this the utter and absolutely unacceptable abuse of power. I made no misuse of these services and there is no valid reason to block my access to them. I demand the full access to be restored and an entity responsible for such atrocity to be taken liable for this action.
Strong words, but you will, just like everyone else, be able to wait until it is fixed by infra.
(In reply to Andrew Savchenko from comment #0) > Hello! > > Today I found that my shell access to dev.gentoo.org and mail access via > pop3/smtp is blocked due to "expired account" by an unknown entity. > > I find this the utter and absolutely unacceptable abuse of power. I made no > misuse of these services and there is no valid reason to block my access to > them. > > I demand the full access to be restored and an entity responsible for such > atrocity to be taken liable for this action. On #gentoo-council-private people point out it's a widespread problem across gentoo dev accounts. Probably just an infrastructure failure and not and explicit action against you.
Okay, looks like I overreacted. My apologies. But the timing is really bad since just yesterday evening I received a personal threat from one person linked with the infra team member to limit my access due to disagreements we have.
To confirm this is some kind of PAM related issues on woodpecker affecting dozens of developers. -A
Our current suspicion is that a number of developers have shadowExpire set on their ldap records and this is causing PAM to reject any logins for those users. The plan is to drop shadowExpire from their records and restart nscd and sasl to fix authentication. -A
This is fixed now.
(In reply to Jorge Manuel B. S. Vicetto from comment #6) > This is fixed now. Just pasting what Robin wrote IRC as to the root cause. In 2012 we set perl_ldap to set ShadowExpire to Jan 2020. For developers onboarded after 2012, this would set their accounts to all expire around this time. This is why only a subset of developers were affected. Note that in the past shadowexpire was a required LDAP attribute (but is no longer) and so it had to be set to something; hence setting it to a date 'far in the future' like 2020 ;) We still use shadowexpire for temporary accounts (like GSOC students) but not for developer accounts. -A
(In reply to Alec Warner from comment #7) > (In reply to Jorge Manuel B. S. Vicetto from comment #6) > > This is fixed now. > > Just pasting what Robin wrote IRC as to the root cause. > > In 2012 we set perl_ldap to set ShadowExpire to Jan 2020. For developers > onboarded after 2012, this would set their accounts to all expire around > this time. This is why only a subset of developers were affected. > > Note that in the past shadowexpire was a required LDAP attribute (but is no > longer) and so it had to be set to something; hence setting it to a date > 'far in the future' like 2020 ;) We still use shadowexpire for temporary > accounts (like GSOC students) but not for developer accounts. A part was missed here: The FIRST version of perl_ldap that infra has in version control, at which point it was already a well-baked script, but not version-tracked, dating to 2006, already used shadowExpire, and this caused an outage in 2012 because that was the hardcoded default value. At that point the hardcoded value was bumped to 2020/02/01, which triggered this bug. It's not a required attribute anymore, and default value will be removed in perl_ldap.
