I tried running the automatic upgrade script for TWiki on a site I own, and the new data is rather messy.
So the deal is that I may upgrade our TWiki installation at some point, or I may not and call the current stuff good enough for our purposes. It will be more of a heavy lifting effort than the upgrade script makes it out to be, though (probably because we’re running a rather old version of TWiki).
Now that we’ve got new tapes, and I’ve learned a bit more about NetBackup, I’ve got a working image duplication.
First, collect the backup IDs, using some variant of bpimagelist: bpimagelist -hoursago 120 -L -st FULL -client client. Collect the backup IDs in a file, one ID per line.
Choose a new retention level for the duplicates. This is the important part. If a retention level is not specified, it uses the one from the original, which (a) may not be what we want for off-site archives, and (b) if the retention levels differ amongst the images, they’ll be put on different tapes from the duplicates pool (if there are enough tapes available). Specifying the retention level allows us to put all of the user and business data from PACO and ROJ on the same tape.
Retention levels:
| level | retention time |
|---|---|
| 0 | 1 week |
| 1 | 2 weeks |
| 2 | 3 weeks |
| 3 | 1 month |
| 4 | 2 months |
| 5 | 3 months |
| 6 | 6 months |
| 7 | 9 months |
| 8 | 1 year |
| 9 | infinite |
| 10 or higher | immediate expiration |
The actual command for duplication is thus:
bpduplicate -Bidfile file -dstunit eyewi-hcart2-robot-tld-1 -L bpduplicate.log -mpx -rl level -v
We got new tapes for the tape library.
We got them without barcodes, so I had ordered some barcodes from SpectraLogic. Unfortunately, they sent barcodes for cleaning tapes (which would work fine, probably, but would confuse me — on the other hand, the library could decide that they were all cleaning tapes and not let me write to them). So I found GNU-barcode, which spits out pretty decent barcodes.
Facts about LTO barcodes:
I munged the PS output of GNU-barcode from the default with the text below the code in an upward-indented area to the text above the code in something that’s more like the SpectraLogic labels. Applied them to the tapes, and they work fine.
I installed the latest stable snapshot of Moodle 1.4.2+ this morning.
I copied the data directory, made a new database and ran last night’s dump on it, and put 1.4.2+ in its own directory. The system upgraded from the data copy just fine. I had to add the dialogue and ldap2307 modules and munge the TeX input filter, but those are minor.
Mark will be playing with it over break, and if it presents no difficulties, we’ll apply the changes to production the first week in January.
Playing with stylesheets and MovableType templates with the eye towards making a WebDB-like display for MT blogs.
I made a breakthrough today via this document from RPI that explains how to add a Samba-accessible printer from MacOS X.
The trick is to hit Add while holding down Option, and then the drawback is that you have to put in your password as part of the printer URI. It works fine, though. This means we’re very close to being able to put a printer in a 24 hour accessible location for student printing from the dorms.
We’re now using the SCode MovableType plugin to take a cut out of comment spam.
This plugin requires the addition of a security code which is displayed in picture form during the comment submission process. It works across all blogs, but we have to modify the templates to actually display the code picture.
Comment spam is killing us.
Quite literally, someone decided it would be amusing to try to run some 20,000 comment spams through us last night. The posts were coming in at somewhere between 2 and 10 per second and completely bogging down the web server. The remote addresses were from all over, including .it, .mil, and broadband addresses. I suspect that someone was controlling a large botnet or spyware infestation and having them point to us, since it seems a slight stretch for an automated worm to deduce the comment CGI.
So, you may notice that comments (viewing and posting) are currently disabled.
Got some touches made yesterday to the queue manager web app and put it in limited production for the department.
One of our lasers is now set to autohold and all the department has admin access to the queue manager. It seems to be working just fine.
Late last night I had an idea for how to manage the load balancing queues — if the current printer is a load balancing queue or a list of printers, have it extract the queue information for the load balancing queue and the queues it feeds. Then we don’t have to worry about a job disappearing into the fed queue and then getting stalled without any obvious way to kill it. Will work on that next week.
Well, back from the last entry, I’ve got the basic workup of a print queue web application that can be run on kiosk stations.
I stole the stylesheet from WebDB and fit an LPRng queue manager on top of it. The basic idea is that connections from kiosk IP addresses will be automatically shown to the queue for the printer that they’re at. Connections from other addresses will get “UNKNOWN” as the printer, on the assumption that they’re actually admins calling in (and if they’re not, it’s not a problem).
There are two levels of admins: first, general admins are able to choose which queues to look at. Queue-specific admins can view all the contents of the queue rather than just their own jobs. (So this isn’t so much sub/super-set relationship in the admin levels as it is overlapping sets.)
The queue display automatically refreshes every 30 seconds. After 2 minutes for regular users and 1 hour for admins it will automatically log out.
The queue display shows held jobs, printing jobs, pending jobs (jobs that have already been sent and will print after the currently printing one is out), and stalled jobs (with the option to delete).
The printers list shows a list of all printers that the user may admin. Click a printer to choose it, and then switch back to the queue tab to see the entries.
I’m going to let it percolate for a few days as I clean off the rough edges. We may deploy it in a limited fashion over break in the Lilly lab.