Time  Nick      Message
11:54 pdurbin   ventz: we use the heck out of rnapshots but i'm not familiar with the error you posted: http://irclog.perlgeek.de/crimsonfu/2012-10-10#i_6048702 . did you ever solve your problem?
11:55 pdurbin   agoddard: just above that you wrote up your findings about raid and lvm. thanks!
12:11 pdurbin   hmm, openlava-2.0-209.2.x86_64.rpm via http://download.opensuse.org/repositories/home:/alescc/RedHat_RHEL-6/x86_64/ via http://hpc.admin-magazine.com/Articles/openlava-Hot-Resource-Manager
13:13 pdurbin   hmm, *slightly* different fu made it into our internal docs than what i posted at http://irclog.perlgeek.de/crimsonfu/2012-04-03#i_5390098 ... tar -C mysource -cpf - . | tar -C /path/to/destination -xvf -
14:06 pdurbin   dotplus: spam coming into RT. any tips on fighting it?
14:06 pdurbin   whorka: you know about fighting spam and RT too...
14:06 pdurbin   agperson: and don't you run RT?
14:07 agperson  we haven't had to deal with any spam yet in our very limited deployment
14:07 agperson  but i assume pre-filtering with something like spam assassin in the best way to go
14:07 pdurbin   (note to self that we're talking about spam in RT #29553)
14:08 pdurbin   yeah, we have spamassassin running
14:08 pdurbin   anyway, i don't know a ton about how our RT is set up. just thought i'd throw this issue out there
14:08 agperson  you can limit things like what domains to receive messages from
14:09 pdurbin   yeah... for particularly abusive domains
14:11 larsks    pdurbin: We run email through our normal spam filtering mechanisms, and front RT with procmail.
14:12 larsks    So procmail eats messages marked as spam.
14:12 pdurbin   larsks: yum. yeah, i forgot you run RT too. thanks
14:12 agperson  yeah, i think all the decent solutions are just running standard spam interference before hitting RT
14:12 agperson  but hey, maybe theres some cool plugin or something if you look
14:13 pdurbin   that makes sense... nothing RT-specific. just general spam fighting
14:15 pdurbin   larsks: did you end up using those RT 4 RPMs?
14:19 dotplus   pdurbin: as with everything, depends on your usage. Can you take "create ticket" away from unauthenticated users? How about just from email addresses that don't already exist?
14:20 larsks    pdurbin: Not yet.  Not sure it's really going to happen here, so I've mostly been futzing about with RT4 under Fedora just to see how it works.
14:21 pdurbin   dotplus: can't, really. but good thoughts
14:22 pdurbin   larsks: https://admin.fedoraproject.org/pkgdb/acls/name/rt4 is a 404 but there's a https://admin.fedoraproject.org/pkgdb/acls/name/rt3 ...
14:22 dotplus   who are the permitted requestors? do you have to be able to accept tickets from anyone in the world? if the answer to that is "yes" which it sometimes is (and e.g. was at my my previous job, @cmu.edu), then you can't stop spam, you just have to fight the spam arms race.
14:22 dotplus   greylisting++
14:23 pdurbin   dotplus: yes. anyone in the world :)
14:24 larsks    dotplus: You can still fight spam, even if you're accepting new tickets from everybody.  Our spam filters do a reasonably good job of it.
14:25 dotplus   then there's ~nothing RT can really do to help you. depending on legit volume/spam volume, you could possibly create a "suspicious" queue that gets messages above a certain spam score, but not high enough to get quarantined/ditched by your filter
14:25 agperson  i've had success with greylisting…except when it causes pain and confusion
14:25 dotplus   larsks: yes, but *RT* can't really help much.
14:25 larsks    You could then auto-expire messages in your suspicious queue after X days to prevent it from getting unwieldy.
14:25 larsks    True dat.
14:26 dotplus   exactly
14:26 dotplus   trouble is you need to triage the suspicios queue to requeue good messages and put spam messages to train your filters.
14:29 dotplus   in practice the result for us was that we got it down to a level where we went from hundreds or thousands of spam tickets/day to ~0 false positives and < a couple of dozen false negatives
14:30 dotplus   which I considered to be (temporary) victory.
14:32 whorka    we never tuned our spam filter that tightly and erred on the side of false negatives, using the procmail+spamassassin approach, but it was easy enough to add a one-click "Report as Spam" action to RT4 for user convenience.
14:35 pdurbin   whorka: that sounds pretty awesome. the one click action
14:38 whorka    it's pretty easy. here's how it's done: http://people.hmdc.harvard.edu/~whorka/rt4.hmdc.actions.patch
14:40 pdurbin   heh. reportasspam :)
14:48 dotplus   as whorka says/shows, 1-click report as spam (meaning move to spam queue) is trivial. making the 1-click action also feed it into a spam filter trainer was a little more difficult. It's long enough ago now that I forget exactly how we did that.
14:49 dotplus   The first thing that springs to mind was "take the original message and mail it to a special address using a filesystem-based mailstore, and cron sa-learn --spam against that directory hierarchy.
17:37 * pdurbin reads through sjoeboo's gluster fu: http://irclog.perlgeek.de/gluster/2012-10-11#i_6052740