The second LTO-2 drive for the Spectra T120 arrived after lunch, and after some initial hiccups it’s online.
Configuring the drive in the library was painless, but for some reason the PCI SCSI card on EYEWI was not happy when we daisy chained the two drives together. It kept giving parity errors and never found the second drive (probe-scsi-all saw the drives just fine, of course). I solved this by finding another cable and terminator and connecting the second drive to the second channel on the SCSI card. EYEWI was happy with this, and NetBackup understood the situation just fine. I’m currently doing a backup of PACO just to test things, but everything’s looking dandy at the moment.
The Lilly Alpine completed its dying process over night and we made a scramble to get the building back on the net this morning.
A couple of spare switches helped, and then the new chassis for the Alpine arrived and we were able to mount and populate it with the old cards by lunch. At this point, though, the gigabit blade seems to be dying, so we’ve moved the Black Diamond uplink to a 100 Mbit port.
After patching NetBackup so that it recognizes the new library, I changed all the policies to use it and successfully tested a backup and restore for ASHTI.
I grabbed the latest drive and robot mappings patch file from the Veritas web site and put the new files in /usr/openv/share/external_drive_mappings.txt and /usr/openv/share/external_robot_mappings.txt while saving the originals. After that the GUI autuoconf wizard happily recognized the library and the LTO-2 drive. Importing the tape media we currently have was a snap with the barcode reader — just inventory the robot and have it update its configuration.
I then changed all the policies that used the Overland library to using the new library, initiated a backup of ASHTI, and then restored from that backup onto EYEWI. All worked well, and the process was nice and speedy.
As soon as the second drive gets here, we should be able to start making tape copies.
Finally got the SCSI PCI card on EYEWI working and got the T120 library attached to it.
Turns out we needed the SUNWqus family of drivers for the Qlogic QLA10162 card. After finding them from the Sun downloads site and installing them, I’m now able to see another tape drive and the T120 changer. I did end up making some modifications to the /kernel/drv/st.conf file, but I’m not sure if I really needed to.
Apparently VMware ESX 2.1.2 does not support USB in virtual machines.
Which puts a crimp in our style for running the GIS USB dongle off of a VM. Annoying, but not a huge problem, as there’s a couple of other boxes that could accept the dongle.
For some reason, ecto and MT are adding 5 hours to my post times. Probably a time zone issue, and this post is testing a change in ecto.
Had to make some modifications to the standard Apache::AuthenLDAP module to get it to bind as a specific searcher object for authentication.
Added AuthenBindDN and AuthenBindPW variables, along with AuthenLDAPSecretsFile where these can also be specified. Bumped the version number from 1.00 to 1.10, just for kicks. It’s working fine now.
Had to do this because the AuthenIMAP module was making imapd on KE fall over, so the LDAP module was needed. Need to specify a bind DN and PW so that it can find our confidential users when they connect.
EIRENE has been a nameserver for a while now, but I’ve finally tightened it down and made it official, replacing MIR.
MIR will be retired in its current incarnation in a while, and the next incarnation is unlikely to have a nameserver running on it. So it needs to be taken out of the domain records and something needs to replace it. EIRENE seemed like a good choice, at least for the time being. I tweaked the startup options a bit and added logging for BIND so that maybe way can start tracking suspicious queries like we ought to.
I’ve got VMware installed on SERE and have a W2K instance set up for Sophos EM Library updates.
The VMware install and management is a piece of cake.
The Sophos EM Library is a bit tricker, mostly because I have to deal with Windows. Be sure to properly install Windows — this helps. I have the EM Library set up and running under the domain user sophos, and I have the CID locations set to \PAX\InterChk.... The user used for connecting to the CID share has to be the domain user: DOMAIN\sophos, otherwise it defaults to a local account, and that won’t work with a remote CID location.
Sophos EM Library keeps running as a system task and does not require any logon at system startup — just what we needed. We’ve tested installing FreeBSD, MacOS X, and W2K versions of Sophos. Windows seems to require UNC access to the CID location for updates (at present, although others are looking into this), while the others will happily use web updates.
I have changed both BARIS and KE to use Sophos/sophie for the MIMEDefang virus scanner, and they seem to be working well.
icald, the iCal to Sun ONE calendar program, is up and working.
The primary thing left to code on it is access logging. I’m going to try to do something close to W3C common log format.
From the note I sent out to the department, the access methods are as follows:
In all cases, the URL may begin with http://server:port/login/ in order to force authentication for accessing the calendar.
| Publish name | USERNAME |
| Base URL | http://server:port/ |
| Login | USERNAME |
| Publish name | CALENDAR |
| Base URL | http://server:port/USERNAME/ |
| Login | USERNAME |
| Publish name | CALENDAR |
| Base URL | http://server:port/ |
| Login | USERNAME |
| Publish name | OTHERUSER |
| Base URL | http://server:port/OTHERUSER/ |
| Login | USERNAME |
| Publish name | CALENDAR |
| Base URL | http://server:port/OTHERUSER/ |
| Login | USERNAME |
Well, I’ve got a basic iCal to Sun ONE publisher script.
It’s a standalone web server using the HTTP::Daemon module and friends. On a PUT request it does a standard Basic auth system, checking the auth against the login WCAP command. If that succeeds, it deletes all the events in the specified calendar, and then uploads the new calendar as a POST request to the import WCAP command. Getting the POST request was tricky — it needs to have the POST data specify a Content-Type of text/calendar, which the doc never seems to mention (if it doesn’t, it crashes the Sun ONE web server).
At the moment the app only deals with PUT requests, does not understand SSL, and only does mild argument parsing. It’s also single threaded. Ideally I’d like to have this replace the previous subscribe CGI (understanding GET requests and parsing the arguments better) and become multithreaded after some fashion. It’s fast right now, but if too many people start using it, particularly over slow links, it could become a bottleneck if it’s not threaded better (probably just forking for each request).
Just enabled DAV on my laptop to play with iCal publishing.
Did some packet captures, and it appears that when iCal publishes, all it does is issue a PUT for the base URL plus the calendar name with a .ics extension, using Basic auth for the authentication (if needed). So, for example, if you say your publishing location is http://www.example.edu/cal and your calendar is named “test”, iCal will issue a “PUT /cal/test.ics HTTP/1.1” followed by the headers and then the entire calendar. It will send the entire calendar for each publish (even if the calendar is set to publish after each modification).
All of this bodes pretty well for an iCal to WCAP publish script. We don’t really need to implement a full DAV protocol — all we need to do is have a script that answers to a PUT request, does Basic auth, and then does the right thing with the filename and the user given to upload the file to the Sun ONE calendar. Looks like the appropriate WCAP command is import, which is a POST of the text/calendar file that the script will have received from iCal. This all looks quite doable.
Kinda quiet in here recently. I’ve been devoting most of my spare time to building an anti-spam/anti-virus gateway appliance.
Building on the LDAP routing work in Sendmail, I’ve been putting together the appropriate pieces to make a mostly stand-alone gateway appliance for filtering, quarantining, dropping, etc. spam and viruses. The main pieces are
The MIMEDefang filter is where most of the glue resides — identifying local recipients, getting their SA prefs from a MySQL database, doing the right actions for identified spam (tagging, or quarantining), etc. WebUserPrefs needed some tweaks to make it SA 3.0 compliant, and I needed to write an auth mechanism for the user database. Also an interface to the quarantine queue — message details are stored in the database, and then a program can be called to pass the message along or to delete it entirely.
At this point I’ve got it all pretty much working. I need to tie a few ends together and redeploy it to a clean test system, then have people start testing it.