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:
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.
