Install as another (administrative) user on Windows XP

Gotta love it when you get an install package as an .exe file - right click and "Run As" to install it as an admin account. All good. But when you get an .msi do you really have to log out, then log in as an administrative user, just to install it? I've always known there must be a better way to do it, but it finally irritated me enough to find out. The trick is to use the runas command:

C:\Documents and Settings\myUser>runas /user:domain\admin-account "msiexec /i \"C:\Documents and Settings\myUser\My Documents\Downloads\someInstaller.msi\""

Some gotchas:

• you must include the whole command you're passing to runas in quotes
• if the path to the MSI file has spaces in it, you must put it in quotes
• you can't nest quotes, so you'll have to use a backslash to escape the inner set of quotes

For the record, some bright sparks have suggested some simple reg hacking to create an "Install as" menu item in the right-click context menu. Nice idea, and it appeals to my sense of order and neatness. I'll have to try that next time it irritates me enough.

Nagios UPTIME errors for a Windows 2003 client

We have a Windows 2003 server - one of a farm of 5 similar machines - that suddenly started reporting errors in Nagios:

nagios# /usr/local/libexec/nagios/check_nt -H mq-citrix-5 -v UPTIME 
NSClient - ERROR: Could not get value

Looks like the issue was with the underlying Windows counters that nagios client uses to get this info - this was useful reading: http://nsclient.org/nscp/discussion/message/1066

So I did this to verify we had the same issue:

cd "\Program Files\NSClient++ "

nsclient++.exe /test 

(error output) 

To fix (on w2k3) we need to force a counter rebuild:

cd \windows\system32 

lodctr /R 

I had to re-start the NSClient++ service, then test again from nagios:

nagios# /usr/local/libexec/nagios/check_nt -H mq-citrix-5 -v UPTIME 

System Uptime - 0 day(s) 9 hour(s) 7 minute(s) 

And we are happy again. In hindsight, I guess this server crashing 6 times in an hour must have corrupted the counters. Wait a couple of minutes, and this hits my inbox:

** RECOVERY alert - mq-citrix-5/UPTIME is OK **

Yay!

Courier IMAP - migrating all users' email

So we have a project underway to move all our users off our old postfix+courier+squirrelmail system to Microsoft Exchange 2010. Now, you might think this would be easy, but you would be wrong.

Some bits are okay - getting a list of all users and their job titles, photos etc. from LDAP is easy - ldapsearch is a pretty powerful tool. But the bit that I assumed would be easiest of all - importing all their existing mail into Exchange - has proved a little more difficult.

Exchange seems not to have any native tools to import Maildir (which is of course what we use) so I planned to use imapsync. Good theory, and some useful blog posts here and here point the way to setting up one user account as an administrator who can connect to any mailbox. But after several hours of flailing around, I failed. Here's what I tried:

In /etc/courier/authldaprc, set LDAP_AUXOPTIONS sharedgroup=group

In LDAP, use the (previously unused) sharedgroup attribute:

# ldapsearch -h ldap -x -b 'ou=People,dc=example,dc=com,dc=au' '(uid=migrate1)' sharedgroup -LLL
dn: uid=migrate1,ou=People,dc=example,dc=com,dc=au
sharedgroup: administrators

Then test:

# courieruserinfo migrate1
uid=10381
gid=100
home=/home/migrate1
authaddr=migrate1
authfullname=Email Migration User
maildir=
quota=
options=

Hmmm... options isn't set. OK, try the same with userdb:

# userdb migrate1 set options=group=administrators
# userdb -show migrate1
options=group=administrators
root@zappa:~# courieruserinfo migrate1
uid=10381
gid=100
home=/home/migrate1
authaddr=migrate1
authfullname=Email Migration User
maildir=
quota=
options=

Still not set! Why not? Ahhhh, bugger, we're using PAM auth (in /etc/courier/authdaemonrc, I've set authmodulelist="authpam")

and if you read the documentation carefully enough:
"The authentication library has a facility for keep arbitrary “name=value”-type settings, called “options”, for individual accounts. This feature is only available with userdb, LDAP, MySQL, and PostgresSQL modules. Individual account options are not supported with system-based authentication modules (password/shadow files, or PAM)."

Well that explains why it doesn't work... now how do we fix that? I can see a few options, which I guess I'll be trying out in the next few weeks. More to come.

Disable offline files on Windows XP

For some reason, the GUI way of disabling offline files was greyed out, regardless of me logging in as local admin or a domainadmin. Maybe because it was set up with the computer in a previous domain? Don't know, don't care. A regedit fixes it all: edit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters\CSCEnabled and set it to 0x0. Reboot. Sorted.

Kudos to http://offlinefiles.blogspot.com.au/2010/10/disable-offline-files-registry-key.html for this info.

Secure hard drive destruction (or: Fun With Power Tools)

Usually when I dispose of a hard drive, I wipe it using DBAN - Darik's Boot And Nuke - secure enough for our purposes. But what about when the hard drive electronics or motor are damaged so that the disk can't be wiped?

Well then it's time for physical destruction:

Physical destruction of Maxtor hard drives using a drill press

Very satisfying!

PHP DateInterval gotcha!

I did some quick PHP code a little while back to produce timesheets - pretty simple: given a fixed start date in the past for fortnightly time sheets (say, perhaps,2011-10-24) figure out what date the most recent time sheet should start at. So this function ought to be able to do that, right?

# this function is subtly wrong, do not use it!

function getCurrentTimesheetStartDate($ts_start_date)
{
        $current_date = date_create("now");
        $interval_from_start = date_diff($current_date, $ts_start_date);
        $interval_from_current = ($interval_from_start->d) % 14;
        $date_interval_spec = new DateInterval("P" . $interval_from_current . "D");
        $retval = date_sub($current_date, $date_interval_spec);
        return $retval;
}

Well, not quite :-( It turns out that $interval_from_start->d fetches the number of days between the two dates within the current month (that is, if the ts_start_date is in a previous month, it will be "wrong" unless you also consider that $interval_from_start->m will be higher than zero... ). It turns out the member I need is $interval_from_start->days (the actual number of days between these two dates). Doh! So the corrected code is:

function getCurrentTimesheetStartDate($ts_start_date)
{
        $current_date = date_create("now");
        $interval_from_start = date_diff($current_date, $ts_start_date);
        $interval_from_current = ($interval_from_start->days) % 14;
        $date_interval_spec = new DateInterval("P" . $interval_from_current . "D");
        $retval = date_sub($current_date, $date_interval_spec);
        return $retval;
}

 One long-running bug successfully squashed :-)

The Mysterious Case of the HP ProCurve PoE switch(es)

Lots of our sites use oldish Dell switches. They're nothing fancy, but they're pretty cheap, and they've stood the test of time - many of them are more than 5 years old, and never miss a beat. They just work.

One of our newer sites has a pair of fancy-pants HP ProCurve 2910al-48G-PoE switches (48 port, gigabit, power over ethernet). These switches were sufficiently expensive that we started joking that they must have gold-plated connectors and platinum cases. Still, we figured, you get what you pay for - spendy switches == extra good, right? Sadly not.

The first unpleasant surprise was when they arrived - both had chassis that were noticeably bent - as if someone had taken the "curve" part of ProCurve too literally. One was dead on arrival - wouldn't even power on. We kept the working-but-bent one, as we needed it ASAP. HP shipped the replacement for the DOA one, and life went on...

A year later another one died - quite spectacularly - the PoE power supply died, so while the switch kept on working, there was no power over ethernet, and any phones connected to it stopped working. I took out the power cord to power cycle the unit, and when I restored power, there was an unpleasant crackling noise, and acrid smoke issued from the unit. You've never seen two sysadmins move so quickly!

Again HP shipped a replacement, which died within a month, again with a fault in the PoE power supply. HP support asked us to run "show tech all" but we found this from "show log" most useful:

W 01/25/90 22:59:43 00576 chassis: 50V Power Supply 1 is Faulted. Failures: 2
W 01/25/90 22:59:44 00071 chassis: Power Supply failure:  Supply: 1, Failures: 1
W 01/25/90 22:59:45 00578 chassis: Co-processor Unrecoverable fault on PoE controller 1

Yep, another dead PoE power supply.  That was in 2010. Replacement shipped, life went on...

You guessed it... yesterday, I got a call to say that some of the phones at that site had stopped working. It wasn't too hard to guess the cause! The web UI showed no faults, but the port status display showed 5 ports were delivering PoE but had no ethernet link. Definitely not what I expect to see - once the phones are getting power, they boot and establish an ethernet link. So a 55 km drive to the site, and what do you know, another dead PoE power supply:

PoE fault lights on an HP ProCurve switch - a most unpleasant sight!

Just to be thorough, I also hooked up the LinkRunner to confirm what commonsense was already telling me - yep, no power being delivered. Sigh. Before calling HP I checked the warranty status and it told me the warranty expires in 2108 - 96 years from now! I assumed this was an error, but when I called HP to order the replacement, I was told that it is correct - these switches are covered for life (I doubt I have another 96 years on this mortal coil, so probably somewhat beyond my life-span). So that's nice, I guess, given how unreliable they are.

Anyway, the nice lady at HP is shipping out another one, so I guess I'll go to the site again, and replace it yet again. I wonder how long this one will last.

In summary: nice features, expensive switches, totally unreliable.

I'm contemplating buying or making some sort of PoE monitoring device that we could monitor from Nagios, so we know when it fails.