Norm Jacobs's Weblog From the chipper...

Over the years, I have been asked by several peiple about using the LP service to archive print jobs.  Most recently, someone asked how they might go about using  an LP queue to create an archive directory of PDF files.  The goal was to setup a print queue that they could print to, have the print service generate PDF files, and store them somewhere. 

This time, I have decided to write a short description here in my blog for others to hopefully benefit from.

 Before we begin, there are a few things that you should know about LP.

• It performs backend job processing using a shell script (interface script) to do final job processing and send it to the printer.
  
• It runs "slow" filters out of band prior to scheduling the print job to print and "fast" filters are expected to be run by the interface script.
  
• It will construct a filter chain (of commands) to run to convert from the input format to the print queue's content type
• filter definitions are not configured in the system by default.
• filters and interface scripts run as the submitting user if they originated on the local host and 'lp' if they did not.
  

So the above request can be broken into two tasks: converting job data to PDF and archiving it.

Converting job data to PDF can be done a few ways, but the easiest way is to define a filter to convert from 'postscript' to 'pdf' and make the print queue's content type 'pdf'.  This way, lpsched will create a filter chain, perform the conversion, and queue the job for printing.  If it can't perform the conversion, the job will not be accepted.

To define the filter, we need to create a filter definition file and import it into LP:

# cat <<EOF >/etc/lp/fd/ps2pdf.fd
Input types: postscript
Output types: pdf
Printer types: any
Printers: any
Filter type: slow
Command: /usr/bin/ps2pdf14 - -
EOF
# for i in *.fd ; do ; lpfilter -f `basename $i .fd` -F $i ; done

Next we need to create an interface script that archives the job data.  More or less, interface scripts are run by lpsched as follows:

/etc/lp/interfaces/{printer} "{request_id}" "{user_name}" "{title}" "{copies}" "{options_list}" {file_list}...

Our interface script should log the arguments and copy file files in the file_list somewhere.  An example can be found here

To define a print queue that uses this script and will cause the pdf filtering to run:

# cp /tmp/archive-interface-script to /usr/lib/lp/model
# lpadmin -p test -v /dev/null -Ipdf -Tunknown -m archive
# accept test
# /usr/bin/enable test

That's it.

 One of these days I will have to dig up my old audio alerts package for LP that tells you when the printer runs out of paper or needs attention. (I got tired of walking to the printer only to find that it had been neglected, so I made it annoying enough for people to want to fix it.)

So last night my daughter came in the room absolutely beaming.  You see, she had forgotten to copy down her homework in one of her classes.  She wasn't happy that she had forgotten to copy it down and therefore would not be able to complete it.  No, her school provides online access to homework assignments via a third party website.  She was happy because she was able to retrieve her homework, open it, and print it from her computer running OpenSolaris while her mom wasn't from her computer running Windows Vista.

Apparently, her teacher uses MS Office 2007 and as a result, generates .docx files by default.  Naturally, there are no associations for them when you use an older version of MS Office, so it simply doesn't recognize them.  On the other hand, OpenSolaris with OpenOffice recognizes what they are and opens them right up.  So it seams that OpenSolaris/OpenOffice does a better job here than Windows Vista/MS Office.

Actually, this wasn't the first time that we have run across this, we have received several Office 2007 files that end up forwarded to me to convert to Office 97/2000 files.  It's just that the expression of joy on my daughter's face motivated me to share.

About a year and a half ago I blogged about CUPS being available in build 87 and later of OpenSolaris.  A couple of weeks ago Ghee blogged about How to turn on CUPS on OpenSolaris.  I thought that I would recap and add a little to the discussions.

First, installing and enabling CUPS on OpenSolaris

opensolaris% pfexec pkg install SUNWhal-cups-utils
opensolaris% pfexec svccfg import /var/svc/manifest/application/cups.xml
opensolaris% pfexec /usr/sbin/print-service -s cups

Once you have CUPS running on your system, you can start to configure it using the GUI print management tool that comes with the OpenSolaris Desktop.  The tool is launched via the Desktop menus by selecting "System" -> "Administration" -> "Print Manager".  An example follows:

When you use the management application to perform a privileged action (like creating a new print queue, modifying print queue properties, or deleting an existing print queue), you will prompted for the "root" password.

Once you have authenticated, the action will be performed.  Before you ask, yes this needs to be better integrated with RBAC.

If you have forgotten the root password that you set when you installed the system, you can login using the account that you created during installation and from a shell execute:

opensolaris% pfexec passwd root

This will prompt you to set a new root password.  The reason this works is because the initial account is given the "root" role when it's created.  Note that this only works for accounts with the "root" role.

CUPS also has a web based management interface that you can access via http://localhost:631/admin/.  The web interface provides similar functionality to the desktop GUI, but the desktop GUI is also integrated with USB hotplug support, so when you plug in a USB printer, it should automatically create a queue for you and offer you the opportunity to modify it's configuration via a notification area notice on your desktop.

If you have problems printing to your USB attached printer using the CUPS built in "usb" backend you can also try the "hal" backend supplied as part of hal-cups-utils.  To switch, you need to bring up the properties sheet by right-clicking the printer icon.

The properties sheet should look something like this

Note that the "Device URI" starts with "usb://".  This indicates that the CUPS usb backend module is configured to communicate with the printer.  To change backend modules, you can press the "Change..." button.  A dialog will popup allowing you to select from discovered devices.

 At this point you can select the device that matches your printer and press "Apply"

The properties sheet will change to reflect the new "Device URI" for the printer.

Notice that the "Device URI" now starts with "hal:///".  This indicates that the HAL backend module supplied by hal-cups-utils will be used to communicate with the printer.

About a month ago, I integrated CUPS 1.3.7 into Solaris. It shows up in snv_87 and later. For some, this is bound to cause some pain and suffering. For others, it is a welcome addition. For me, it's an exchange of one set of issues for another. Solaris LP has some strengths and CUPS has some strengths, but in the end CUPS has the momentum and adoption going for it that make it a better choice moving forward.

So, now we have CUPS and you are probably asking yourself, “How do I use it?”. Some of the specifics of how it's integrated are outlined in the ARC case PSARC/2008/130 CUPS 1.3.6. The highlights are that CUPS integrated as 2 smf(5) services and a command to allow you to switch from the default LP based print service to using CUPS.

The new smf(5) services are as follows:

• svc:/application/cups/scheduler

  The scheduler service is roughly analogous to the application/print/server and application/print/ipp-listener services. Because the CUPS scheduler conflicts with these services, it is marked as incompatible in the smf repository and won't start if the LP scheduler is running.

• svc:/application/cups/in-lpd

  The in-lpd service is the CUPS replacement for in.lpd (application/print/rfc-1179). Like the scheduler, it is marked as incompatible with the LP based rfc-1179 service.

These smf services require root privilege or “solaris.smf.manage.cups” authorization to manipulate.

The new command that switches the “active” print service is called print-service(1m). Ex:

# svcs '*print*' '*cups*'
STATE STIME FMRI
disabled May_16 svc:/network/device-discovery/printers:snmp
disabled May_16 svc:/application/print/cswcups:default
disabled 16:36:59 svc:/application/cups/in-lpd:default
disabled 16:36:59 svc:/application/cups/scheduler:default
online May_16 svc:/application/cde-printinfo:default
online May_16 svc:/application/print/ppd-cache-update:default
online 16:36:59 svc:/application/print/server:default
online 16:36:59 svc:/application/print/rfc1179:default
online 16:36:59 svc:/application/print/ipp-listener:default
# print-service -q
active print service: lp
# print-service -s cups
disabling LP services...
enabling CUPS services...
# svcs '*print*' '*cups*'
STATE STIME FMRI
disabled May_16 svc:/network/device-discovery/printers:snmp
disabled May_16 svc:/application/print/cswcups:default
disabled 16:37:43 svc:/application/print/rfc1179:default
disabled 16:37:43 svc:/application/print/ipp-listener:default
disabled 16:37:43 svc:/application/print/server:default
online May_16 svc:/application/cde-printinfo:default
online May_16 svc:/application/print/ppd-cache-update:default
online 16:37:44 svc:/application/cups/scheduler:default
online 16:37:44 svc:/application/cups/in-lpd:default
# print-service -q
active print service: cups
#

Before you go switching to CUPS, I would upgrade to snv_88 or later to start with. There is a GhostScript bug in snv_87 that makes it pretty much unusable and the GTK+ print dialog support didn't go in until snv_88.

If you have switched to CUPS, you will find that the commands are similar and have many options in common, but do not have the exact same set of arguments and do not necessarily generate identical output. The same is true for LP/CUPS features. At any rate, CUPS does come with it's own lpadmin(1m) and you can use it to create print queues, but it also has a web based management interface that is roughly analogous to the printmgr(1m). You can access the web management interface through the Gnome desktop menus under “All Applications -> System Tools -> Manage Printing” or point your browser at http://localhost:631/.

At the backend of all of this, CUPS is using the same Foomatic, gimp-print, hpijs, ... that LP uses, so the printer support should be very similar right now.

Depending on your needs, CUPS may not be the right answer for you. If you use Trusted Printing, attach printers to a SunRay, or share configuration in NIS, you may need to stay on LP for the short term. There are other integration issues with things like Presto yet to be addressed. We will work to address some of these things, improve the management experience, and improve the integration moving forward.

At any rate, right now, it's an option and it should be familiar for experienced with the current Linux, *BSD, or MacOS/X environments.

I work from home and have been doing so for about 12 years now. I have used a number of different methods of connecting to work to get my work done. They range from a Wyse terminal and moden, tip(1) and a modem on a workstation, slow dialup, "fast" dialup with PPP, ISDN,DSL, Cable Internet, Sun.Net, CiscoVPN and the ultimate solution "punchin". Punchin is a Sun created VPN solution using IPSec and IKE to setup and tear down an IPSec protected tunnel into the SWAN (Sun internal network)

I rebooted my system earlier this afternoon and had to reconnect to the Sun Wide Area Network (SWAN). Normally, I wouldn't have given it a second thought. I would have simply run punchin, authenticated, brought up my ipsec protected tunnel, and continued on my merry way. This time around, punchin reminded my that my certificate is about to expire (in about 3 months). Apparently I have been using punchin for just under 4 years now. At this point, it's getting hard to remember life without it. Punchin is easy to use and it just works (tm). Even living on the bleading edge. As my fourth anniversary of punchin use approaches, I just want to thank the Solaris IPSec team for creating such a great piece of technology and a means for us to use it.

I really like to use some of the bits available from the Companion CD/DVD/Project/..., but I have found it kind of a pain to install at times. There are two things that I find difficult to deal with.

• I have to manually download the various packages to install.
• I have to install them in the “right” order.

The instructions on the Companion project page definitely make it relatively easy to do this in a few steps, but I was recently on a quest to make it easier. Here is what I came up with (thus far).

I developed a tool, pkg-install, that downloads packages (if necessary), determines the package dependencies, and recursively downloads/installs (if necessary) the dependencies before installing the requested package(s). The tool is similar to Blastwave's pkg-get, but it doesn't use a catalog for it's package information and doesn't handle upgrade/version mismatches. However, it does analyze dependencies on the fly and will download what it needs, as it needs it. It has a default search list for repositories with http://dlc.sun.com/osol/companion/downloads/current/pkgs/$arch as a default package repository.

While pkg-install actually solves my dependency problem, I wanted a simple way to install all of the Companion bits. To simplify the installation, I came up with a pseudo package, SFWCompanion, that contains nothing more that a list of Companion packages as dependencies. This allows me to specify a single package on the command line and have it expand to the bits that I really want.

To try it out all you have to do is download a copy of pkg-install, make it executable, and invoke it as follows:

# pkg-install –repository=http://blogs.sun.com/jacobs/resource/toys SFWCompanion

-Norm

PS.

Maybe later tonight, I will get a chance to blog about how I have been using pkg-install to install current builds of Solaris using ZFS boot without destroying my previous Nexenta or Nevada ZFS boot images.

Since this is been an area that I have wanted to address for several years now, I thought it was as good a place as any to start blogging...

Over the last several years we have been working to improve the printing experience on Solaris.

Since Solaris 2.0, printing has been a on or near the top of the dissatisfiers for users of Solaris. Over the various releases, we have made architectural changes, added features, and made advancements to ease the most common complaint...configuring the service. We have created GUI tools to hide complexity, we have made client support name service aware, we have added open source driver support, ...

While we have made changes to ease the burden of printing management, a while back, we came to the realization that it's still too difficult. Why? Well, the tools are too dificult to locate and often they require specialized knowledge to create a print queue or access one on a remote system.

A few months ago, I proposed project Presto on opensolaris-discuss@opensolaris.org. Presto is intended to take print service management to the next level. It is intended to address local and network printer device discovery, automatic print queue configuration, network print queue advertising and network print queue discovery.

We are nearing that next stage of evolution. The Solaris Printing team and the Desktop team have been moving forward to achieve the objectives of Presto. With the help of Artem Kachitchkin from the Tamarack team, I integrated the first piece of infrastructure to handle USB printer detection inside of HAL in Solaris Nevada build 53. Since then, several improvements and bug fixes have been made to the print service, HAL, and devfsadmd in order to pave the way for additional Presto support.

We have reached a point where we have a working prototype of part of the functionality. This includes a desktop component using the HAL support to automatically create print queues. It also includes and SMF service that provides print queue discovery support which is compatible with Linux/CUPS and MaxOS X print queue advertisements. While the prototype is a very small subset of what we ultimately hope Presto to cover, it's at a point where the functionality has become somewhat useful.

Improvements to the desktop applet, network printer device discovery and network print queue advertisements are in the works.

At any rate... watch the movie..., download the bits, play with them, join the fun, and let us know what you think at presto-discuss@opensolaris.org. Constructive comments are always welcome, if not encouraged.

-Norm