Copyright 2004, NC State University
Refer to the installer license dialog for license information.
Hua Ying Ling - Code, design,
Everette Gray Allen - Concept,
direction, testing and documentation.
The authors wrote the printer dialog extension in this
package. The cups backend was modifed from work done by the
Patrick Powell wrote LPRng. See http://www.lprng.org/ Our cups
backend is a version of the lpr command line tool from LPRng version
3.8.12 modified to accept cups style options and a path to the ticket
Sam Hartman wrote the modifications of LPRng version 3.8.12 to make it
work with the MacOS X kerberos model. The source distribution contains
his modifications with his permission.
The klprPDE package is a Printer Dialog Extension(PDE) and cups backend
implements printing to a kerberized LPRng print server. The PDE
runs in user space at print time and loads whenever the standard Apple
print dialog is called to get and file cache a kerberos ticket for the
configured print server(s). The cups klpr backend is a modification of
the LPRng lpr client which takes cups arguments and reads the needed
kerberos service tickets from the kerberos cache file in /private/tmp.
This works around an issue with macho chains and ticket access under
MacOS X 10.3 to provide kerberized printing for GUI applications.
free software is released free under a BSD type license.
MacOS X 10.3. klprPDE will not work on earlier versions of MacOS
X due to a known bug in kerberos where file cache can not be
used. There is no version for MacOS
9 or 10.0/1 since cups is not available in those OS versions.
There never will be a port to any other operating system.
It is possible to use the klprPDE derivative of our work from Reed
University on other versions of MacOS X.
Binary Installer - http://www.ncsu.edu/mac/downloads/klprPDE.zip
Source - http://www.ncsu.edu/mac/downloads/klprPDE.src.zip
License - http://www.ncsu.edu/mac/software/license.html
Run the installer and let it do the work. The installer should:
1) Put klprPDE.plugin in /Library/Printers/PPD Plugins
2) Put lpd.conf into /usr/local/etc
3) Put klpr, the cups backend, in /usr/libexec/cups/backend
The configuration files are at /Library/Printers/PPD
/usr/local/etc/lpd.conf. There is no GUI
interface to edit these files. Edit the files with a
text editor like TextEdit, BBEdit, pico, vi, emacs, etc. Text
enclosed in /* */ is ignored (C style comments) for Settings.strings
Settings.strings is within the klprPDE bundle and should look like this:
/*====== These strings are CASE SENSITIVE ========*/
/* these strings are matched in this order
- print server
- printer type
- service name
at least one of these must match or the PDE will not load*/
/*if the print server matches the first string then the use the second
string as the service name*/
/*if the printer type matches the first string then use the second
string as the service name*/
"klpr" = "lpr/printservername.whatever.dom@REALM.WHATEVER.DOM";
/*use this by default eg.
/*"Service Name" =
The lpd.conf should look like this:
Refer to the LPRng documentation for details on other client side
1) There is no preference interface. Preference changes must be
made by editing /Library/Printers/PPD
/usr/local/etc/lpd.conf with a text editor like BBEdit, pico, vi,
2) Applications with custom print dialogs like some major Adobe apps.
will never load Apple's default print dialog which means the PDE code
will never execute. The work-around is to use the Printer button
in the custom dialogs to get the standard Apple print dialog so the PDE
3) The /usr/local/etc/lpd.conf must be configured to contain the
correct auth and kerberos ticket format for the target print servers in
addition to setting the format in /Library/Printers/PPD
someone can show us a way to get around this without serious rewrite of
the lprNG lpr client we would love to see it.
4) The configuration assumes that either a) you have only one
printserver or b) you have a group of print servers which answer to a
single cname and share a common kerberos ticket for the service.
This is mostly a limitation of the lpd.conf as
Settings.stings could match anything in theory but we have not done
much testing in this area.