[Systems] [Sugar-devel] trac breakage

[Samuel Cantero]

Hello everyone,

In an effort to fix our user spam problem with bugs.sl.o I've added the
reCaptcha plugin [1] for users registration. I've had to use the forked
version on github because the official one was not working. I've also had
to fix the SSL support in the reCaptcha plugin. The plugin was loading
insecure content in a our secure page, therefore, the browser was blocking
the captcha image. The fixed version is in my github [2].

In order to check the verification by email in the registration module, I've
enabled the trac logging and I've found two problems:

1) The email was being sent by trac but sunjammer was not sending it. I've
found the following error in /var/log/mail.log:

auth-worker(25213): Error: pam(socialhelp,18.85.44.59): pam_acct_mgmt()
failed: Authentication token is no longer valid
warning: rev-18-85-44-59.sugarlabs.org[18.85.44.59]: SASL PLAIN
authentication failed: Password expired

I've checked the *shadowLastChange* value in our LDAP and I found 16316.
I've check the current numbers of days since Jan 1st 1970 and it is 16874.
So, It has been 558 days since the last time we've changed socialhelp
password. According to ShadowMax, it expires every 365 days. I fixed this.

2) Sometimes trac was trying to send emails to the username instead of the
user email. However this does not happen always. This is a bug in the
Account Manager Plugin [3]. I've cloned the svn official repo in my github
[4] and I've applied the patch from [3] in order to fix it. Now we are
using my repo instead of the official one. It is important to notice that
the verification email will be send after the first login. Apparently now
it is fixed.

Regarding to the inability to access the user page, I've checked our
current users and I found 97426 users. We had a lot of spam here. I've
checked this by doing:

sqlite> select count(*) from session;
97426

In addition, there was some integrity issues with our sqlite database. I've
checked it by doing:

$ sqlite3 trac.db "pragma integrity_check"
wrong # of entries in index session_last_visit_idx
wrong # of entries in index sqlite_autoindex_session_1
wrong # of entries in index sqlite_autoindex_session_attribute_1

Those integrity issues do not enable us to remove users using the
trac-admin utility. I fixed this by:

$ sqlite3 trac.db "reindex session"
$ sqlite3 trac.db "reindex session_attribute"

I tried to remove all suspicious users with the trac-admin utility and
directly by database but this is almost imposible. I guess we should delete
all users and ask them to re-register again. However, *I don't want
to proceed before your approval.*

Finally, I couldn't build the trac image with the I've had to use plugin.
This is used for rejecting contributions that contain spam. Apparently the
official repo is down. Maybe this is a temporary problem. I'll try it again
within a few hours in order to enable it again.

Best regards,

Samuel C.

[1] https://trac-hacks.org/wiki/RecaptchaRegisterPlugin
[2] https://github.com/scanterog/trac-recaptcharegister
[3] https://trac-hacks.org/ticket/12228
[4] https://github.com/scanterog/acct_mgr-0.4.4

On Wed, Mar 9, 2016 at 11:05 AM, Samuel Cantero <scanterog at gmail.com> wrote:

> On Wed, Mar 9, 2016 at 10:03 AM, Walter Bender <walter.bender at gmail.com>
> wrote:
>
>>
>> On Wed, Mar 9, 2016 at 4:34 AM, Sam Parkinson <sam.parkinson3 at gmail.com>
>> wrote:
>>
>>> Hi Walter,
>>>
>>> The immediate issues with trac (and also socialhelp) sending emails is a
>>> configuration issue.  Right now it is a horrible configuration where it
>>> sends emails via smpt.sugarlabs.org, but the password that both
>>> services use for that (socialhelp account on sunjammer) expired.
>>>
>>> Really, the mail situation could probably fixed by adding a "postfix"
>>> container and letting anybody on freedom link to it and use it.  The
>>> password thing was probably not the best setup, sorry.
>>>
>>> Other than trac not sending emails, was there anything else?  Or just
>>> looking for something a little more shiny?
>>>
>>
>> I am not looking for something shiny, just something that works and that
>> someone is maintaining. I don't have the knowledge or the cycles to help
>> with this myself. It is unfortunate that during GSoC recruitment, when many
>> new users are trying to set up accounts, that is has been broken.
>>
>> My simple rule of thumb is that if we can find an equivalent service
>> somewhere else that someone else maintains and it does not impinge on our
>> freedoms, we should consider it, as sysadmin time is of a premium. Git Hub
>> issues come to mind.
>>
>
> Thanks Walter for the notification. I didn't know about the problems that
> has been arisen with trac. Certainly, it is a pity to provide an unreliable
> and unstable service to our community and specially in a huge event as GSoC.
>
> We should work on it in order to apply the anti spam features and fix the
> email problem. What else is annoying with our current trac instance?
>
> Best regards,
>
>
>>
>>> Thanks,
>>> Sam
>>>
>>>
>>> On Wed, Mar 9, 2016 at 8:19 AM, Walter Bender <walter.bender at gmail.com>
>>> wrote:
>>>
>>> I was going to bring this up at the last SLOB meeting but we ran out of
>>> time. We have serious problems with b.sl.o regarding user management. While
>>> I can assign new users unmoderated status, I cannot actually enable their
>>> accounts since I cannot access the user page (it is so full of spam users
>>> that it times out before loading -- even though Sam increased the timeout a
>>> few months back). The verification by email is broken, hence the need to
>>> find a different way to validate.
>>>
>>> My recommendation is that we look into alternatives to trac. We can keep
>>> the old system running as an archive, but it seems time to move on. (I've
>>> been told -- although I have not confirmed -- that trac is not regularly
>>> maintained upstream any more, which would be all the more reason to move
>>> on.)
>>>
>>> Does the sysadmin team have any recommendations? Any thoughts from the
>>> devel community?
>>>
>>> regards.
>>>
>>> -walter
>>>
>>> --
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>> <http://www.sugarlabs.org>
>>>
>>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>> <http://www.sugarlabs.org>
>>
>> _______________________________________________
>> Systems mailing list
>> Systems at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/systems
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/systems/attachments/20160314/e997dd31/attachment.html>