<div dir="ltr"><font color="#000000">Hello everyone,</font><div><font color="#000000"><br></font></div><div><font color="#000000">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].</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">In order to check the verification by email in the registration module,</font><span style="color:rgb(0,0,0)"> I've enabled the trac logging and I've found two problems:</span></div><div><font color="#000000"><br></font></div><div><font color="#000000">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:</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">a<font face="monospace, monospace">uth-worker(25213): Error: pam(socialhelp,18.85.44.59</font><span style="font-family:monospace,monospace">): pam_acct_mgmt() failed: Authentication token is no longer valid</span></font></div><div><font color="#000000"><font face="monospace, monospace">warning: <a href="http://rev-18-85-44-59.sugarlabs.org">rev-18-85-44-59.sugarlabs.org</a>[18.85.44.59]: SASL PLAIN authentication failed: Password expired</font><br></font></div><div><font color="#000000"><br></font></div><div><font color="#000000">I've checked the <i>shadowLastChange</i> 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.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">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.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">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:</font></div><div><div><font color="#000000"><br></font></div><div><font face="monospace, monospace" color="#000000">sqlite> select count(*) from session;</font></div><div><font face="monospace, monospace" color="#000000">97426</font></div></div><div><font color="#000000"><br></font></div><div><font color="#000000">In addition, there was some integrity issues with our sqlite database. I've checked it by doing:</font></div><div><font color="#000000"><br></font></div><div><font face="monospace, monospace" color="#000000">$ sqlite3 trac.db "pragma integrity_check"<br></font></div><div><div><font face="monospace, monospace" color="#000000">wrong # of entries in index session_last_visit_idx</font></div><div><font face="monospace, monospace" color="#000000">wrong # of entries in index sqlite_autoindex_session_1</font></div><div><font face="monospace, monospace" color="#000000">wrong # of entries in index sqlite_autoindex_session_attribute_1</font></div></div><div><font color="#000000"><br></font></div><div><font color="#000000">Those integrity issues do not enable us to remove users using the trac-admin utility. I fixed this by:</font></div><div><font color="#000000"><br></font></div><div><span style="font-family:monospace"><font color="#000000">$ sqlite3 trac.db "reindex session"<br></font></span></div><div><font color="#000000"><span style="font-family:monospace">$ sqlite3 trac.db "reindex session_attribute"</span><span style="font-family:monospace"><br></span></font></div><div><font face="arial, helvetica, sans-serif" color="#000000"><br></font></div><div><font color="#000000"><font face="arial, helvetica, sans-serif">I tried to remove all suspicious users with the </font>trac-admin utility and directly by database<span style="font-family:arial,helvetica,sans-serif"> but this is almost imposible</span></font><font color="#000000" face="arial, helvetica, sans-serif">. I guess we should delete all users and ask them to re-register again. However, <b>I don't want to proceed before your approval.</b></font></div><div><font color="#000000"><br></font></div><div><font color="#000000">Finally, I couldn't build the trac image with the </font><span style="color:rgb(0,0,0)">I've had to use</span><font color="#000000"> plugin. This is used for rejecting contributions that contain spam.</font><span style="color:rgb(0,0,0)"> 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.</span></div><div><font color="#000000"><br></font></div><div><font color="#000000">Best regards,</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">Samuel C.</font></div><div><font color="#000000"><br></font></div><div><span style="color:rgb(0,0,0)">[1] <a href="https://trac-hacks.org/wiki/RecaptchaRegisterPlugin">https://trac-hacks.org/wiki/RecaptchaRegisterPlugin</a></span><font color="#000000"><br></font></div><div><font color="#000000">[2] <a href="https://github.com/scanterog/trac-recaptcharegister">https://github.com/scanterog/trac-recaptcharegister</a></font></div><div><font color="#000000">[3] <a href="https://trac-hacks.org/ticket/12228">https://trac-hacks.org/ticket/12228</a></font></div><div><font color="#000000">[4] <a href="https://github.com/scanterog/acct_mgr-0.4.4">https://github.com/scanterog/acct_mgr-0.4.4</a></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 9, 2016 at 11:05 AM, Samuel Cantero <span dir="ltr"><<a href="mailto:scanterog@gmail.com" target="_blank">scanterog@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Mar 9, 2016 at 10:03 AM, Walter Bender <span dir="ltr"><<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Mar 9, 2016 at 4:34 AM, Sam Parkinson <span dir="ltr"><<a href="mailto:sam.parkinson3@gmail.com" target="_blank">sam.parkinson3@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Walter,<div><br></div><div>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 <a href="http://smpt.sugarlabs.org" target="_blank">smpt.sugarlabs.org</a>, but the password that both services use for that (socialhelp account on sunjammer) expired.</div><div><br></div><div>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.</div><div><br></div><div>Other than trac not sending emails, was there anything else? Or just looking for something a little more shiny?</div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div></span><div><div>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.</div><div><br></div><div>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?</div></div><div><br></div><div>Best regards,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br></div><div>Thanks,</div><div>Sam<div><div><br><br>On Wed, Mar 9, 2016 at 8:19 AM, Walter Bender <<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>> wrote:<br>
<blockquote type="cite"><div dir="ltr">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.<div><br></div><div>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.)</div><div><br></div><div>Does the sysadmin team have any recommendations? Any thoughts from the devel community?</div><div><br></div><div>regards.</div><div><br></div><div>-walter<br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div>
</div></div>
</blockquote></div></div></div></blockquote></span></div><span><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div>
</span></div></div>
<br></span>_______________________________________________<br>
Systems mailing list<br>
<a href="mailto:Systems@lists.sugarlabs.org" target="_blank">Systems@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/systems" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/systems</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>