Overview

Purpose

 To improve Solaris approachability, specifically the print service, by automatically (or as automatically as possible) discovering and configuring access to directly attached, network attached, and remotely served printers.

Key Goals

• Provide users with a more hands off/automatic mechanism for using printers that they plug into their host or local network.
• Provide a mechanism for automatically recognizing and configuring access to existing print queues as they move across networks.
• Use SMF for managing network queue discovery/advertising services
• Tighter desktop integration.

High Level Overview

 Solaris includes a system event notification service that allows applications to register and receive events that they are interested in.  As part of the Tamarack Project, the Hardware Abstraction Layer (HAL), commonly used on Linux, will be integrating into Solaris shortly.  It will contain support for recognizing sysevent device add/remove events.
 Support for directly attached printers will come in two varieties.  First, there is the hotplug variety where a device is plugged into an interface or bus that is capable of detecting the event an propagating it to the event notification service.  This applies to USB attached printers.  Next, there is the traditional, polling variety where a device is plugged into an interface that doesn't detect the printer attachment/detachment, but instead requires the interface to be periodically polled and then queried for information about the attached device.  This applies to ecpp (parallel) printer interfaces.  Finally, there are the polling variety that don't support a standard mechanism for retrieving information about the attached device.  This would include centronics parallel printers and serially attached printers.  Devices attached through these interfaces are out of scope.
 Support for for network attached printers will come from a variety of sources.  Many of the newer models of printers available today provide support for advertising their availability on the network via protocols like mDNS and SLPv2.  When attached, these printers will broadcast (or multicast) information about themselves to the local network.  Some newer printers and most older printers are not capable of announcing themselves to the network.  In order to detect their attachment/detachment, a polling service must run somewhere on the local network.
 Support for finding available print queues on the network already exists in Solaris in the form of network name service printer maps.  These maps publish a list of "advertised" print queues that client systems can access.  In a larger network with one or more dedicated administrators, these maps are likely to be populated and reasonably current.  In a home, small office, or ad hoc network environment, these maps are very unlikely to exist.  As a result, a broadcast or multicast mechanism may be a desirable alternative. Currently CUPS includes a broadcast print queue advertisement capability that allows just such sharing.  Windows and MacOS/X also provide something similar.  In order to provide maximal interoperability, these mechanisms should be implemented instead of inventing yet another mechanism.
 Printers found through the system hotplug support should be recognized by HAL as it integrates into Solaris.  Polling and network printer detection will require the addition of "addon" module(s).  Printer property probing will require the inclusion of a printer probe program.
 Once a printer has been "found" and probed  or removed by HAL, a D-BUS message for the printer add/remove will be generated.  This message may be received in the user's desktop session by the gnome-volume-manager, causing a desktop notification and potentially launching a print management application to handle the event.

More Detailed Information

  Locally attached Hotplug printers

Currently, hotplug events are generated for "disk" and "network" interface devices.  It appears that the intention was to include "printer" and other device support.
         6450793 printer hotplug events should be handled properly
 introduces private hotplug events for EC_dev_add/ESC_printer and EC_dev_remove/ESC_printer that will be generated for printers that are attached to and removed from the USB interface on a host.  The hotplug events can supply the following HAL printer properties:

• printer.device (dev_name)
• printer.vendor (prop-usb-vendor-name)
• printer.product (prop-usb-product-name)
• printer.serial (prop-usb-serialno)
• printer.description (n/a)
• printer.commandset (n/a)

This interface will go through architectural review and be made available for consumption by applications through a contract.  A contract for this will be needed before HAL is made to recognize it.

  Locally attached Polling for printers

HAL provides an Addon mechanism that allows plugin "daemons" to run within HAL and poll or search for device add/remove events.  Since ecpp interfaces don't support a hotplug mechanism to determine if a printer has been attached, this project will build an appropriate HAL Addon module to poll for newly attached ecpp parallel printers.  Because the ecpp driver allows the retrieval of the IEEE 1284 device id string, this module can also supply the following HAL printer properties:

• printer.device (/dev/printers/... or /dev/ecpp*)
• printer.vendor (IEEE 1284 Device ID "MFG" or "MANUFACTURER")
• printer.product (IEEE 1284 Device ID "MDL" or "MODEL")
• printer.serial (N/A)
• printer.description (IEEE 1284 Device ID "DES", "DESC" or "DESCRIPTION")
• printer.commandset (IEEE 1284 Device ID "CMD" or "COMMAND SET")

  Network attached Polling for printers

Since there are a large number of network attached printers in use today that don't have the capability of announcing themselves to the network, A HAL Addon module will be created that will be capable of broadcasting out either an ICMP Echo request or an SNMP get operation on the network. Further attempts will be made to interogate new printers for Manufacturer, Model, and Serial number information, as well as a preferred means of communicating with the device.  The results of this detection and interogation will cause associated HAL printer properties to be filled in as follows:

• printer.device (device-uri, eg. socket://ip:port/)
• printer.vendor (SNMP IEEE 1284 Device ID "MANUFACTURER")
• printer.product (SNMP equiv. IEEE 1284 Device ID "MODEL")
• printer.serial (SNMP vendor specific MIB emement)
• printer.description (SNMP equiv. IEEE 1284 Device ID "DESCRIPTION")
• printer.commandset (SNMP equiv IEEE 1284 Device ID "COMMAND SET")

If this is not possible through a HAL Addon module, it can be done as a seperate service that generates appropriate D-BUS messages for the desktop monitoring agent to subscribe to.

  Network attached Hotplug (mDNS)

More on this as mDNS support makes it's way into Solaris, but the jist of it is that we want to be able to detect printers that support mDNS as a means of advertising their availability on the network.  mDNS is the underlaying technology used for Zeroconf on Linux and Bonjour/Rendezvous on MacOS/X.  With mDNS, network attached printers will announce their Make/Model information, as well as their preferred method of communication.

  Network attached Hotplug (SLPv2)

Not at this time, but maybe later.

  Network attached Hotplug (UPNP)

Not at this time, maybe later.

  Network attached print queues (CUPS Browse)

inetd udp listening.  This is prototyped and will be made available for comment and testing shortly.  There is also a companion advertising service that goes with it.

  Network attached print queues (SMB/Network Neighborhood)

In the Microsoft Windows printing model, print client systems generate printer ready output and pass this output to a print queue on the host were the printer is attached.  As a result, Solaris must treat these print queues as network attached printers instead of remote print queues.  Discovery (browsing) of printers through this mechanism will be integrated into the add printer management tool instead of via a separate service using  libsmbclient / smbclient

  Network attached print queues (mDNS/Bonjour)

More on this as mDNS support makes it's way into Solaris, but the jist of it is that we want to be able to detect printers that support mDNS as a means of advertising their availability on the network.  mDNS is the underlaying technology used for Zeroconf on Linux and Bonjour/Rendezvous on MacOS/X.  With mDNS, network attached printers will announce their Make/Model information, as well as their preferred method of communication.

  Desktop Integration

The bulk of the discovery and notification work will be happening within and around HAL and D-BUS.  As a result, the gnome-volume-manager will be receiving printer add/remove events.  It is believed to be capable of launching an arbitrary application upon receipt of these events.  For initial prototyping work, it can be used to simply launch the current printmgr application, however, this will need to prompt the user for the root (privileged user) password to be able to complete the work. We will need to spend some time identifying specific roles and working on improving RBAC support within the print service and print management tools as part of the deliverables of this project.

  Add Printer Event Handling

Printer add events will generally occur when the system and/or detection services detects that a printer was attached to the host (or network). Attaching a printer should attempt to reattach the device to an existing queue if there was one or create a new queue if one is needed.  The creation of a new print queue should be as automatic as possible, but will most likely require user interaction to provide specific preferences and data.

  Remove Printer Event Handling

Printer removal events can be generated for

• printer unplug
• printer power off (looks the same to the system)
• network unplug (for network attached)
• network partitioning (for network attached)

We need to look into when to notify the user that the printer is no longer attached and ask them if they want to remove it's queue.  If there are pending jobs, they will need to be asked what to do with them (remove or move to an alternate queue).