spama sets the ETA on a ticket to be 'spam', and then resolves it. We can later look through and calculate how much of our ticket traffic is spam. There's an equivalent =spams= command for condor-support.
-If it looks like a given spammer is hitting us repeatedly with the same source email address, consider adding them to /p/condor/home/rust/scripts/filter_mail. Search for "spam" to find them.
+If it looks like a given spammer is hitting us repeatedly with the same source email address, consider adding them to /p/condor/home/rust/scripts/filter_mail. Search for "spam" to find them. See the filter_mail section for more on how to edit filter_mail.
{subsection: Merging tickets}
@@ -363,8 +363,16 @@
qm, showm
/p/condor/home/req/bin/gtkreq
+
+
+
{subsection: Emergency maintenance}
-{subsubsection: Breaking mail loops (also, who filters the mail?)}
+
+
+
+
+
+{subsubsection: filter_mail}
condor-admin@cs.wisc.edu is a global alias that points to condor-admin@chopin.cs.wisc.edu:
@@ -380,7 +388,17 @@
filter_mail is a script that Nate M wrote. It steers mail into either the condor-admin, condor-support, the vdt-support queues. It also pulls out the download logs from the binary CGIs and the Condor pool reports (one of the data sources for the condor world maps). It also runs spamassasin on the incoming mail and drops spam. It logs to /tmp/filter_mail.log on chopin.
-A quick way to break mail loops is to change filter_mail to drop messages with a known sender, which is what I did. This way, filter_mail never invokes the RUST program, so no autoresponse is generated.
+A broken filter_mail is very bad. Rust will bounce. Always test your changes. You can test that it compiles at all by using "perl -c filter_mail"; if that fails complaining about Mail::Audit, temporarily uncomment the line "use lib 'test-lib/site-perl';". You can also try sending message to condor-admin from a non-CS address and verify that it creates a new ticket.
+
+filter_mail is currently in CVS and should be checked in after any changes.
+
+Open issue: How is Mail::Audit ending up in filter_mail's path when invoked by the CSL?
+
+
+
+{subsubsection: Breaking mail loops}
+
+A quick way to break mail loops is to change filter_mail to drop messages with a known sender, which is what I did. This way, filter_mail never invokes the RUST program, so no autoresponse is generated. See the filter_mail section for more on editing filter_mail.
Another way, which I've never done, is to set
@@ -390,92 +408,38 @@
(chopin's /etc/mail/aliases file is a little bit wrong, since it's got two entries for condor-mm. This could potentially be a problem after an upgrade. The correct one is an alias for the cndr-rst user, which uses procmail to decide where to send messages. cndr-rst has an AFS token, so it can insert into postgres. Currently, filter_mail runs without an AFS token, which is why /p/condor/home/rust/active is net:cs write)
-{subsection: RUST script setup}
-(From Erik Paulson)
-{code}
-condor-admin@cs.wisc.edu is a global alias that points to
-condor-admin@chopin.cs.wisc.edu:
-
-karadi(539)% getalias condor-admin
-condor-admin aliased to:
- condor-admin@chopin.cs.wisc.edu
-on chopin, condor-admin is locally overridden by the lab's configuration
-scripts:
-chopin(1)% getalias condor-admin
-condor-admin aliased to:
- "|/p/condor/home/rust/scripts/filter_mail"
-
-filter_mail is a script that Nate M wrote. It steers mail
-into either the condor-admin, condor-support, the vdt-support queues.
-It also pulls out the download logs from the binary CGIs and the
-Condor pool reports (one of the data sources for the condor world maps).
-It also runs spamassasin on the incoming mail and drops spam. It logs
-to /tmp/filter_mail.log on chopin.
-
-A quick way to break mail loops is to change filter_mail to drop
-messages with a known sender, which is what I did. This way, filter_mail
-never invokes the RUST program, so no autoresponse is generated.
-
-Another way, which I've never done, is to set
-do_initial_autoreply=0
-in
-/p/condor/home/rust/etc/rust_configs
-
-but that squashes everything for that queue.
-
-(chopin's /etc/mail/aliases file is a little bit wrong, since it's
-got two entries for condor-mm. This could potentially be a problem
-after an upgrade. The correct one is an alias for the cndr-rst user,
-which uses procmail to decide where to send messages. cndr-rst has
-an AFS token, so it can insert into postgres. Currently, filter_mail
-runs without an AFS token, which is why /p/condor/home/rust/active is
-net:cs write)
-{endcode}
+{subsection: RUST script setup}
*More recent information from epaulson*
-{code}
-We're most of the way to having SpamAssassin in front of RUST. We've
-reached the point where I don't really know what I'm doing with procmail,
-and am not sure how much of the existing infrastructure we want to keep,
-so I'd like to have someone else involved with it.
+We're most of the way to having SpamAssassin in front of RUST. We've reached the point where I don't really know what I'm doing with procmail, and am not sure how much of the existing infrastructure we want to keep, so I'd like to have someone else involved with it.
Right now, there are 4 RUST queues:
-condor-admin
-condor-support
-vdt-support
-condor-mm
-
-Tickets, for the most part, enter RUST via email to those addresses. RUST
-stores all of it's data in files in AFS. Each address is really an
-alias to a script:
+*: condor-admin
+*: condor-support
+*: vdt-support
+*: condor-mm
+
+Tickets, for the most part, enter RUST via email to those addresses. RUST stores all of it's data in files in AFS. Each address is really an alias to a script:
-cobalt(28)% ssh chopin getalias condor-admin
-condor-admin aliased to:
+ % ssh chopin getalias condor-admin
+ condor-admin aliased to:
"|/p/condor/home/rust/scripts/filter_mail"
-(condor-admin and condor-mm are locally delievered to chopin, and then chopin
-runs the script. condor-support and vdt-support are still on perdita.)
+(condor-admin and condor-mm are locally delievered to chopin, and then chopin runs the script. condor-support and vdt-support are still on perdita.)
+
+Because the filter_mail script is forked off right by sendmail, it runs without an AFS token. This is why we have 'net:cs write' permission on the RUST data.
-Because the filter_mail script is forked off right by sendmail, it runs
-without an AFS token. This is why we have 'net:cs write' permission on
-the RUST data.
-
-To get rid of the net:cs permissions, we need to have the filter_mail script
-be run by a real user. The lab setup a user for us, cndr-rst, which will
-automatically get a new Kerberos ticket on chopin every hour.
-
-I had the lab switch the condor-mm queue to point to the cndr-rst user.
-condor-admin is moved to chopin but running the old way under sendmail at
-the moment - by having it on chopin already, we can update the alias file
-in one place during the day and test it, instead of waiting for the CSL
-scripts to update everything at 4am and hoping for the best for a few hours.
+To get rid of the net:cs permissions, we need to have the filter_mail script be run by a real user. The lab setup a user for us, cndr-rst, which will automatically get a new Kerberos ticket on chopin every hour.
+
+I had the lab switch the condor-mm queue to point to the cndr-rst user. condor-admin is moved to chopin but running the old way under sendmail at the moment - by having it on chopin already, we can update the alias file in one place during the day and test it, instead of waiting for the CSL scripts to update everything at 4am and hoping for the best for a few hours.
cndr-rst has the following .procmailrc:
+{code}
export LOGFILE=/scratch/cndr-rst/logs/procmaillog
:0
@@ -486,48 +450,32 @@
:0w:/scratch/cndr-rst/logs/procmail.lock
* ^To.*condor-mm*
| /s/std/bin/runauth /p/condor/home/rust/scripts/condor-mm
+{endcode}
+
+
+(as an aside, Todd's spam assassin is out of date - it only scores the diploma spam a 4.8 :( )
+The /p/condor/home/rust/scripts/condor-mm script dumps the message into RUST. It's a much simpler version of the script that runs condor-admin and condor-support. The condor-mm script looks for the X-Spam-Flag, and if it sees it doesn't put the message into RUST (which in turn means that there is no autoresponder)
-(as an aside, Todd's spam assassin is out of date - it only scores the
-diploma spam a 4.8 :( )
+The condor-admin/support script does a bunch of stuff to figure out which queue it's going to, and also if it's license information from the Italian mirror site or weekly updates from collectors in the wild, so we probably want to keep that script in place, and just have spam assassin sit in front of the script. It could either drop things on the floor it believes are spam, or set the X-Spam-Flag and let filter_mail kill it. I don't know which way is better.
-The /p/condor/home/rust/scripts/condor-mm script dumps the message into
-RUST. It's a much simpler version of the script that runs condor-admin
-and condor-support. The condor-mm script looks for the X-Spam-Flag, and if
-it sees it doesn't put the message into RUST (which in turn means that
-there is no autoresponder)
-
-The condor-admin/support script does a bunch of stuff to figure out which
-queue it's going to, and also if it's license information from the
-Italian mirror site or weekly updates from collectors in the wild, so we
-probably want to keep that script in place, and just have spam assassin sit
-in front of the script. It could either drop things on the floor it
-believes are spam, or set the X-Spam-Flag and let filter_mail kill it.
-I don't know which way is better.
-
-Also, my procmailrc script will need to be a bit smarter - currently, it
-will not figure out that mail to condor-mm is meant for condor-mm unless it's
-explicitly To: condor-mm - if you CC condor-mm, it doesn't figure that out.
-I'm not sure that just looking for condor-mm in the header is the right thing
-to do, we've been burned by things like this before.
-
-If you want to edit the cndr-rst user's stuff, it's a bit of jumping through
-hoops. In order to have cndr-rst always have a Kerberos ticket, we can't
-have know what the password is. (We could change our mind, and just stash
-a condor ticket for cndr-rst every 30 days, but it's better if we let
-something automatically generate this ticket)
+Also, my procmailrc script will need to be a bit smarter - currently, it will not figure out that mail to condor-mm is meant for condor-mm unless it's explicitly To: condor-mm - if you CC condor-mm, it doesn't figure that out. I'm not sure that just looking for condor-mm in the header is the right thing to do, we've been burned by things like this before.
-condor:condor-admin has permission to edit the cndr-rust users home
-directory. If you want to get an actual cndr-rst token:
+If you want to edit the cndr-rst user's stuff, it's a bit of jumping through hoops. In order to have cndr-rst always have a Kerberos ticket, we can't have know what the password is. (We could change our mind, and just stash a condor ticket for cndr-rst every 30 days, but it's better if we let something automatically generate this ticket)
+condor:condor-admin has permission to edit the cndr-rust users home directory. If you want to get an actual cndr-rst token:
+
+{code}
ksu
su - cndr-rst
(probably figure out what the KRB5CCNAME is supposed to be and set it)
k52token
source ~/.cshrc
+{endcode}
or
+{code}
ksu
su - cndr-rst
/s/std/bin/runauth /bin/tcsh
