« December 2007 | Main | February 2008 »

January 29, 2008

SPSS 16 Site License Activation

Having a site license instead of a network license for SPSS 16, we found it difficult to deploy, since each computer must have its own unique activation code in order to use the software. With 900 computers, no one wants to activate all of them by hand. To that end, we pursued a way of activating it without manually touching the computer. After some e-mails with our on-campus SPSS support representative, we found that the spssactivator.jar file that came on our media does not support running non-interactively. We downloaded a new version from SPSS, which works quite well. By creating a StartupItem that activates the product, we're able to license each of our machines without going around and doing them by hand.

The first step in setting this kind of thing up when you're using Radmind is to identify where the license is stored. In this case, it's /Applications/SPSSInc/SPSS16/SPSS16.0.app/Contents/bin/lservrc. (Note: this is the default installation directory. Yours may vary.) By creating a negative file with this line in it:

f ./Applications/SPSSInc/SPSS16/SPSS16.0.app/Contents/bin/lservrc 0644     0    80 1201558821       0 2jmj7l5rSw0yVb/vlWAYkK/YBwk=

we can tell Radmind to ignore the contents of that file. (Note: if the file does not exist, Radmind will create it, but it will be empty.) Then in our StartupItem, we check to see if that file has data in it, and if not, we run the activation command. Here is our StartupItem:

#!/bin/sh

##
# Activate SPSS 16 site license
# The license is stored in the file lservrc
##

. /etc/rc.common

workingfolder="/Applications/SPSSInc/SPSS16/SPSS16.0.app/Contents/bin"
licensefile="/Applications/SPSSInc/SPSS16/SPSS16.0.app/Contents/bin/lservrc"
jarfile="/Applications/SPSSInc/SPSS16/SPSS16.0.app/Contents/bin/spssactivator.jar"
authcode=
spssserverport=80
spssserver=lm.spss.com
logfile="/private/var/log/spssactivator.log"

StartService ()
{
    if [ -s "$workingfolder/lservrc" ]; then
            # since the file already exists and has data, don't do anything
            exit 0
    else
            # first, do some pinging to ensure network connectivity
            ping -c 10 $spssserver

            # activate the license with SPSS.  Must be done from this folder.
            cd $workingfolder
            java -jar $jarfile CONSOLEMODE codes=$authcode proxyport=$spssserverport proxyhost=$spssserver > $logfile 2>&1
    fi

    # ensure that the license code isn't readable by users
    chmod 700 $logfile
}

StopService ()
{
    return 0
}

RestartService ()
{
    return 0
}

RunService "$1"

Our activation code (not displayed here for security reasons) is after authcode=.

Posted by slauncha at 03:41 PM | Comments (0) | TrackBack

January 24, 2008

Revamping the Print Queue Monitors

We had been having problems with our print queue monitors recently, the most common of which being that the display, instead of being the print queue, was a blank white screen. To fix this, we changed how they display. Before, there was a local user, printmonitor, which would log in and start the program Teremok, a kiosk browsing application. Now, instead of there even being a printmonitor user, there is a StartupItem that launches Teremok, giving us both more reliability and the added security of a user actually being logged in.

The first problem that this resolves is that the print monitors weren't receiving nightly updates. This was a side effect of the way the printmonitor user logged in: /Library/Preferences/loginwindow.plist specified that it should login automatically. So, when the system started up, LoginWindow started and printmonitor logged in. The nightly radmind script includes this portion:

if who | grep console > /dev/null; then
    logger -si -t $0 User logged in, radmind session will begin on next logout.
    exit 0
fi

So, since printmonitor was always logged in, this script never ran. The solution that was in place was a daily script that ran before the radmind script:

#! /bin/sh

# kill the loginwindow so the radmind.hook will run

PATH=/bin:/usr/bin; export PATH

logger -i -t $0 Killing loginwindow...
killall loginwindow 2> /dev/null

# give the loginwindow a chance to relaunch
sleep 30

exit 0

This script had the effect of killing loginwindow, which woulld of course restart loginwindow. As loginwindow restarted, it read /Library/Preferences/loginwindow.plist and logged the user printmonitor in, which then started Teremok. Then the radmind script ran and detected a user logged in, so it failed to run. So on and so forth until the end of time–one of the print monitors I updated had an uptime of 156 days.

The fix for this was creating a StartupItem, which we call PrintMonitor, that starts Teremok. To get around the whitescreen problem, which we believe to be caused by Teremok starting before the network was ready, we start Teremok, wait 5 seconds, kill Teremok, wait 5 more seconds, and start Teremok again. The StartupItem also does power management settings. Since no user is logged in–root runs Teremok over the LoginWindow (which won't work in Leopard)–the radmind script gleefully updates the computer every night, and everything runs smoothly.

There is also a launchd job set up to run every three minutes that checks to see if Teremok is running and, if it isn't, tells the StartupItem to restart. This ensures the display is always showing what we want.

Posted by slauncha at 10:40 AM | Comments (0) | TrackBack

January 09, 2008

Radmind update to 1.11.0

With the update to the new Radmind version, 1.11.0, we are going to have to ensure that the Radmind tools go out to the clients before the servers are upgraded. The new version changes the server port from 6662 to 6222, the new IANA-registered standard. The client versions of the tools (fsdiff and lapply are the most relevant or our daily purposes) will fail through to 6662 if 6222 is unavailable, but if the server is running 1.11.0 while the clients are running an older version, the clients will only look for the old port and never find the new one. In short, the client and server will miss each other completely. The transition should work just fine as long as we ensure that all stations receive the new tools before the servers.

We may investigate forwarding port 6662 to port 6222 on the servers as we upgrade them in order to prevent this failover from affecting older or nonworking stations that don't receive the update from getting new updates.

Posted by slauncha at 11:25 AM | Comments (0)