source _:A source request. -1 foot view (ticket lock files, editing header files, etc) +{section: 1 foot view (ticket lock files, editing header files, etc)} -<disclaimer> +{quote:<disclaimer>} Potentially dangerous information is included in this section. Please only use this knowledge if you really need it, and do so with great caution. -</disclaimer> +{quote:</disclaimer>} There are a few cases that call for really low-level mucking with RUST. In particular, you might have to remove a RUST lock file, if RUST doesn't properly clean up after itself in certain fatal conditions. You might also need to edit the ticket meta-data directly, also known as the ticket "headers". This is all the stuff you see at the beginning of the message when you show a ticket, under the heading "Ticket Information". This info is kept in a separate file from the ticket history itself. The lock files and header files are kept in the same location, described below. After that, there are separate sections which describe how to actually manipulate these files. -Location of Lock and Header Files + +{subsection: Location of Lock and Header Files} RUST headers and lock files are kept in the following directory tree: -/p/condor/home/rust/headers + /p/condor/home/rust/headers In there, there are subdirectories for each queue. Within those directories, there is one more level of directories, to try to prevent there from being single directories with too many files. So, the full path to a given ticket's headers would be something like: -/p/condor/home/rust/headers/condor-(admin|support|mm)/X/Y + /p/condor/home/rust/headers/condor-(admin|support|mm)/X/Y The "Y" is the actual ticket number (e.g. 1697). The "X" is a subdirectory (e.g. 1000). Tickets 1-999 go into "1", 1000-1999 go into "1000", and so on. The lock files live in the same directory with the ticket headers, but are named "Y.lock". So for example, the lock file for condor-admin ticket #1697 would be: -/p/condor/home/rust/headers/condor-admin/1000/1697.lock + /p/condor/home/rust/headers/condor-admin/1000/1697.lock -Manipulating Lock Files +{subsection: Manipulating Lock Files} Lock files don't contain any information, they only exist or don't exist. If the lock file exists, RUST won't do anything to the ticket. Sometimes you'll see lock files left around by RUST (processes or machines die in the middle of doing a RUST action or something), and nothing will work on that ticket again until you remove the lock file. If, when trying to do something to a ticket, you see something like: -wright@perdita% statusa 1511 bug -Try # 1 to lock... -Try # 2 to lock... -Try # 3 to lock... -... + wright@perdita% statusa 1511 bug + Try # 1 to lock... + Try # 2 to lock... + Try # 3 to lock... + ... chances are good you've got to go delete the lock file. Nothing RUST does should leave a lock around for more than a second... if you're upto try #3, you're almost certainly in a situation with a lock file leak. The other reason you might want to manipulate a lock file is to create a lock while you edit the header file directly (which is described below). To create a lock, simply touch the appropriate file. Just remember to remove the lock when you're done editing the ticket headers. -Manipulating Header Files + +{subsection: Manipulating Header Files} The most common reason to edit the header files directly is to change who RUST thinks should get email about a given ticket, usually to remove people from the "Cc" line. Header fields are of the form: -attribute_name::value + attribute_name::value For example, the ticket user (the person who created the ticket) is listed in the line: -user::email@address + user::email@address The people who RUST will CC are listed in the line: -email::email1@address1, email2@address2, etc + email::email1@address1, email2@address2, etc If no one is getting CC'ed, you'd just have a blank entry: -email:: + email:: You may need to edit either of these fields, especially if someone CC'ed lab@cs.wisc.edu on their ticket, since having the two email robots talking to each other is a bad thing. It's possible you'd want to edit another field, but generally, there are better ways to do that (using assign*, status*, etc) than direct editing. There's no tool for manipulating the user and email fields though, so that's fairly common. So if you ever need to change something about a ticket and there's no other good way to do it, just edit the headers file. Just BE CAREFUL. :) RUST will start to do bad things if you mess up something in there. If you want to be extra paranoid^H^H^H^H^H^H^H^Hcareful, you could lock the ticket before you edit it, just in case RUST is trying to edit it too (a new message comes in from the user, someone on the team is trying to assign the ticket to someone else, etc). Creating a ticket lock is described in the previous section. If you don't want to be that careful (I rarely am), just be quick... i.e. don't leave a ticket header open in an emacs buffer for days on end. -Never automatically add a CS email address to the CC list + +{subsection: Never automatically add a CS email address to the CC list} If someone is CCed on a Rust message, Rust automatically adds those addresses to the CC list (the "email" value) for the ticket. This is usually the Right Thing, but occasionally is wrong when the CCed person is a mailing list or something similar. (Also note that anyone who is a Rust user; that is who can be assigned tickets and run the Rust commands, is also exempt from this behavior.) To avoid this for cs.wisc.edu addresses, see /p/condor/home/rust/etc/dont_make/*. Copy an existing entry like "csl" to the name of the recipient you don't wnat to email, say, "condor-world". Edit the file so the REAL_NAME is more descriptive. Check the file in ("cvs add newfilename; cvs ci newfilename") and you should be set. -Adding a Rust user + +{subsection: Adding a Rust user} Go to /p/condor/home/rust/etc/auth, copy one of the exiting files and name it with your login name, then edit the file to update all information that's specific to you (REAL_NAME, and the comments that reference a login name). You must also add their login name to the list in: /p/condor/home/rust/etc/RUST.names. Finally, please commit any changes you make to these files into CVS, since all of the RUST configuration files are controlled by CVS. A typical sequence of commands might look like this: -cd /p/condor/home/rust/etc/auth -cp adesmet yourusername -vim yourusername -cvs add yourusername -cd .. -vim RUST.names -cvs ci RUST.name auth/yourusername + cd /p/condor/home/rust/etc/auth + cp adesmet yourusername + vim yourusername + cvs add yourusername + cd .. + vim RUST.names + cvs ci RUST.name auth/yourusername condor-mm and req