Norm Jacobs's Weblog From the chipper...

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