Custom Query (332 matches)
Results (274 - 276 of 332)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#274 | fixed | Enhanced run_email2trac to support supplementary groups | bas | Dennis McRitchie <dmcr@…> |
Description |
Hi Bas, We are now using a more secure approach to group ownership and file permissions that supports 1) webserver r/w access, 2) r/w access by selected users who are logged in via ssh, and 3) no other r/w access. The idea is to create a supplementary group whose only members are the webserver user, and the selected ssh users. World access is then removed from all dual-access files (i.e., files writable via webserver and ssh). Thus, with a umask of 007 and the gid bit set, all created dual-access files are group-writable by users belonging to the special supplementary group, and to no one else. Currently, besides the uid, run_email2trac sets only the gid associated with the trac user. This patch will cause it to also set the supplementary groups associated with the trac user, thus supporting a "best practices" approach to dual-access. Let me know if you have any questions. Dennis McRitchie? |
|||
#276 | fixed | mail list labels not stripped created | bas | bas |
Description |
The doc string of ticket_update_by_subject claims to strip mail list labels, but doesn't. I can provide a patch, but I want to check what's acceptable first. The form of labels it claims to strip is "(<Mail list label>:)+ ", but I'm familiar with mailman-style "[label]", so should it be a regex config item? Note: This ticket was deleted. Was fighting spam tickets and also deleted this ticket. So i have created the ticket again, but do not have the email address of the reporter;-( |
|||
#277 | fixed | "database locked" issue | bas | thomas.moschny@… |
Description |
Hi, I thought I'd ask per mail first, before creating a ticket; maybe this is a (configuration) error on our side, or something like that. Here's the issue: Occasionally we lose mails in our email2trac -> Trac setup, and get trackbacks like this in the syslog: Oct 26 11:35:00 <hostname> email2trac <prjname>: subject: u'#4951: XXX' Oct 26 11:35:11 <hostname> email2trac <prjname>: Traceback (most recent call last): Oct 26 11:35:11 <hostname> email2trac <prjname>: File "/opt/trac/bin/email2trac", line 2553, in ? tktparser.parse(sys.stdin) Oct 26 11:35:11 <hostname> email2trac <prjname>: File "/opt/trac/bin/email2trac", line 1689, in parse if not self.ticket_update(m, result.group('reply')[:-1], spam_msg): Oct 26 11:35:11 <hostname> email2trac <prjname>: File "/opt/trac/bin/email2trac", line 985, in ticket_update tkt.save_changes(self.author, body_text, when, None, str(cnum)) Oct 26 11:35:11 <hostname> email2trac <prjname>: File "/trac/opt/lib/python2.4/site- packages/Trac-0.11.8dev_r10236-py2.4.egg/trac/ticket/model.py", line 293, in save_changes db.commit() Oct 26 11:35:11 <hostname> email2trac <prjname>: File "/usr/lib64/python2.4/site-packages/sqlite/main.py", line 540, in commit self.db.execute("COMMIT") Oct 26 11:35:11 <hostname> email2trac <prjname>: OperationalError: database is locked As you can see, we are using Python 2.4 (well, we are on Centos5), Trac 0.11.8dev and email2trac 2.4.0 (I know there's a later version, will try it, but couldn't find anything relevant in the changelog). It seems clear that email2trac might not be causing the issue, but is suffering from it: something else might be blocking the DB while email2trac tries to insert or update a ticket. So the question is: Can email2trac repeat and try again for a while, or else save the message somewhere so it doesn't get lost? Best regards, Thomas |