can we please make spammers harder to post new tickets?
Hi, On avg. we get 2 spam tickets a day on Trac. Can you add some level of spam protection to add a ticket? *CAPTCHA *login required < this barrier is the quickest... (and is the same as other osmocom tracs) *changed ticket flow ( ticket not visible before approval) Best, Allard
Hi all, On Sun, Aug 28, 2011 at 05:08:34PM +0200, Allard Dijk wrote:
On avg. we get 2 spam tickets a day on Trac. Can you add some level of spam protection to add a ticket?
as Patrick is currently busy with the netfilter workshop, I have removed TICKET_{CREATE,APPEND} for anonymous users. I've also deleted tickets 22-75 as well as 77-84 In the process I also discovered that the trac.db is _very_ large (5.1GB) since it contains all the changes of a linux kernel .git tree going back to when Linus started to use git. I guess this might experience some of the performance problems I'm sometimes experiencing on the machine... Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Am 28.08.2011 20:51, schrieb Harald Welte:
Hi all,
On Sun, Aug 28, 2011 at 05:08:34PM +0200, Allard Dijk wrote:
On avg. we get 2 spam tickets a day on Trac. Can you add some level of spam protection to add a ticket?
as Patrick is currently busy with the netfilter workshop, I have removed TICKET_{CREATE,APPEND} for anonymous users.
I've also deleted tickets 22-75 as well as 77-84
Thanks.
In the process I also discovered that the trac.db is _very_ large (5.1GB) since it contains all the changes of a linux kernel .git tree going back to when Linus started to use git. I guess this might experience some of the performance problems I'm sometimes experiencing on the machine...
Yes, its very slow interacting with git. Do you any hints how to avoid this except disabling trac<->git interaction entirely?
Hi Patrick, On Thu, Sep 08, 2011 at 11:37:26AM +0200, Patrick McHardy wrote:
Yes, its very slow interacting with git. Do you any hints how to avoid this except disabling trac<->git interaction entirely?
I think for something as large as the linux kernel tree it might make sense to disable it completely. Unfortunately the support for 'inceremntal repositories' was never fully implemented in git. This way you could have a small repo on dect.osmocom.org containing only those few commits that relate to DECT. Another option would be to go for mysql or postgresql as database backend. But even then, the load on the system (hosting dozens of virtual machines for various projects) is probably still going to be quite big... Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Am 08.09.2011 12:53, schrieb Harald Welte:
Hi Patrick,
On Thu, Sep 08, 2011 at 11:37:26AM +0200, Patrick McHardy wrote:
Yes, its very slow interacting with git. Do you any hints how to avoid this except disabling trac<->git interaction entirely?
I think for something as large as the linux kernel tree it might make sense to disable it completely. Unfortunately the support for 'inceremntal repositories' was never fully implemented in git. This way you could have a small repo on dect.osmocom.org containing only those few commits that relate to DECT.
Another option would be to go for mysql or postgresql as database backend. But even then, the load on the system (hosting dozens of virtual machines for various projects) is probably still going to be quite big...
I don't think I need that, the gitweb interface should be enough, I'll just disable it completely. Thanks!
participants (3)
-
Allard Dijk -
Harald Welte -
Patrick McHardy