March 28, 2008

Installing IPP Printers from the Command Line in Mac OS X

We've rolled out some scripts for departments using our IPP printers that install these printers via the command line. I thought I'd share the syntax in case anyone else needs to do this. First, you need to install the driver (obviously) and get the .PPD for the printer. Then, use the lpadmin command:

lpadmin -p "Printer_Name" -v "ipp://" -D "Printer Name" -E -P "/path/to/ppd"

That will install the printer as an IPP printer using the specified PPD.

Posted by slauncha at 02:08 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

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

December 04, 2007

Poster Printing **Update**

Throughout our roll-out of the BETA version of the poster printer, we have noticed many erroneous jobs were sent our large format device. Sometimes users would inform us of their mistake, other times we'd have to contact them to give them a rebate. We quickly identified this as a problem and with the help of Kevin Jones (developer of the hold queue), were able to launch a solution. Sites Printing developed the poster printer hold queue.

The hold queue can be accessed here:

Users are now forced to go to the advertised webpage to either release their job to the poster printer, or delete the job. If jobs are not addressed, they are purged from the queue after 24 hours. This page has resolved the most glaring issue we've encountered with our poster printer, but we aren't finished with development.

It is our hopes to implement a pop-up message that informs users of their decision to use our poster printer as well as gives them next steps for releasing or deleting the job. We are currently in development of the pop-up but do not have an eta as to its deployment.

-Sites Printing

Posted by rjonesii at 02:16 PM | Comments (0)

October 08, 2007

Copy Card Program

Sites Printing has been in development with the Entrée Plus office for almost a year, the end result is the copy card program. This new service is finally available at Angell Hall and allows students to make photocopies on Campus Computing Sites multi-fuction devices (MFD’s) with a simple swipe of their mcard. The real capstone of this new service is the mcard serves as authentication as well as a portal to the BCP of 400 “free? page sides. Therefore student’s can make copies without ever having to set up a pre-funded account, purchase an exclusive “copy-only card?, or dig for loose change to make copies. Sites Printing also worked to ensure that these MFD’s serve as printers as well, the days of a copy-only machine are behind us. Sites Printing plans on a more widespread deployment of these devices sometime after the new year.

Copy Card Tips and Facts:

*After successfully completing copies or inactivity, the reader times
out after 15 seconds. This is to protect users from being taken advantage of by other users.
*Users can only copy up to 50 pages before being forced to swipe
their cards again. Another form of protection.
*Users are encouraged to press the quit button at the bottom right of
the copy-card reader to "end their sessions". This will prevent
other users jumping in to steal any available copies, (up-to 50 pages).
*There is a hold button on the reader that will allow users to
increase the 15 second timeout, the reader will remain in a hold
state until copying begins.
*The readers will hold up to 500 jobs without network activity, then
report an error. Once it reconnects with the network, it will send
the 500 jobs appropriately.
*Nightly, an Entree Plus office server will send charging data to an
AFS location designated for pickup but Sites.
*ABS generates a list of who is allowed to use this service daily.
An anticipated question is 'the card reader says my account is
invalid', these people should be directed to the AO.

For further questions and inquiries please contact

Posted by rjonesii at 01:38 PM | Comments (0)

Poster Printing @ Sites

Campus Computing Sites now provides poster printing. You can print up to 42? wide B & W and/or Color. Currently poster printing is only available at Angell Hall and costs $8.40 per linear foot. We will NOT provide ANY refunds based on any issue other than technical issues with the printer, i.e. bad ink cartridge, paper jam, etc.

Poster (large format printing) came as a result of several meetings with colleges and departments throughout the university. Groups had voiced their desire to have more readily available large format printing using our charging system and we were able to provide. Our solution works very similar to that of our color printing model, however we charge by the liner foot for poster printing.

For tips on poster printing at Sites:

To learn how to load your favorite Adobe swatch colors on a Sites machine:

Want to use the official University of Michigan CMYK color swatches?

Posted by rjonesii at 10:24 AM | Comments (0)

October 03, 2007

Angell Hall Cyberstation Large Jobs Bug Fix

We identified a problem where print jobs sent from Angell Hall Cyberstations to the 'Angell Large Jobs' queue were inadvertently printing in large format (11" x 17"). Upon further inspection, the Angell Large Jobs PPD deployed to the cyberstations was out-of-date compared with the PPD deployed to the floor machines. Updating the PPD appeared to correct the problems. Machines will receive the updated PPD on next logout/nightly update, whichever should occur first.

Posted by rdevine at 03:34 PM | Comments (0)

October 02, 2007

Universal Photoshop CS3 Printing Issues

In response to recently reported Photoshop CS3 color printing woes on Intel iMacs, we have found that others are encountering similar problems:

As a workaround, we have deployed a setting that will cause Photoshop to run in Rosetta emulation until we can get some new HP drivers that behave properly.

Posted by rdevine at 04:11 PM | Comments (0)

September 24, 2007

mPrint is officially released

It seems silly to say since mPrint ( has been around for years now, but we've finally gotten to a point where we are comfortable doing an official release and advertising campaign.

We had gone from very beta to sorta beta to sorta released and then hung around at the 'sorta released' phase for about a year. The thing that finally pushed us to start officially advertising was the added support of Microsoft Office formats.

Here are The University Record and Michigan Daily articles about the roll out:

For those who don't know, mPrint is a web application provided by Sites that allows students, faculty & staff to upload jobs and print to Sites managed printers. Jobs printed this was are charged to users BCP allocation. Until this summer we only supported uploading PDF and PostScript files. We require people to upload jobs (as opposed to printing directly to the print service) because we need to verify their identity. A CoSign protected web page lets us do that.

In order for mPrint to support different file formats, it needs to be able to convert files from the submitted format to something printers or our print server(CUPS) can handle. In a normal printing environment your client application (Word/Excel/PhotoShop/etc.) does that for you. The print server has no understanding of these formats. This is why we had users convert to PDF or PostScript for so long. Those are formats the server understands.

Unfortunately this was a huge limitation. Having to convert to PDF before uploading just didn't cut it. It interrupted the user's workflow too much. So we hit upon the idea of moving the client conversion component to the server. Since the majority of our printing comes from Microsoft Office, we thought we'd start there. We just couldn't come up with a workable solution for having our linux-based servers convert Office file formats. We thought about running print jobs through OpenOffice but didn't trust OpenOffice's rendering of Microsoft Office documents to be 100% robust. We thought about using WINE or one of CodeWeaver's products, but we had no experience with that and it felt a little kludgy.

We ended up building our own somewhat kludgy solution using components we are very familiar with. In short, the web server receives the uploaded job and sftp's it over to a Windows server. the Windows server is running a service that picks up the job, converts it using Office's COM objects and sends it back to the print server. For most jobs this takes less than 10 seconds and is quite effective. The best thing about this solution is that it doesn't just limit us to Office file formats. Within the next month or so we should be able to support various image formats (through PhotoShop) as well as AutoCAD file types.

Posted by kcjones at 08:51 AM | Comments (0)