PrinterDriverAutoDownload

Differences between revisions 9 and 34 (spanning 25 versions)
Revision 9 as of 2006-11-08 02:06:58
Size: 6381
Editor: 207
Comment:
Revision 34 as of 2008-08-06 16:35:34
Size: 8114
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Packages affected''': printerdrake, other printer setup tools, foomatic-db, foomatic-db-engine, printer drivers/PPDs shipped on the CDs  * '''Packages affected''': system-config-printer, Jockey, printer drivers/PPDs shipped on the CDs
Line 9: Line 9:
The printer setup tool of Ubuntu 7.04 and later should automatically download LSB-packaged printer drivers from linuxprinting.org (will be the FSG OpenPrinting database then). This way we do not need to ship all drivers on the CDs, we are prepared for printers being launched after our release or being supported only by closed-source drivers which we are not allowed to distribute, driver updates, ... Printer drivers are continually being created or updated - especially as new printers can come out at any time between distribution releases. It is not reasonable to expect all distributions to be completely up to date all of the time, yet users expect to be able to use a brand new printer straight away.

== Rationale ==

Many printers do not get set up automatically straight away due to their drivers not being shipped with the distribution. Giving easy access to drivers from an external source will widen the scope of printers which will 'just work' a lot.
Line 13: Line 17:
- User A has a not very common printer for which there are no drivers on the CDs, but drivers exist and are listed on linuxprinting.org
- User B has a printer for which the manufacturer supplies a closed-source driver which Ubuntu cannot ship on the CDs
- User C has a printer whose driver came out after the last release of Ubuntu came out.
 * User A has an uncommon printer for which there are no drivers in their distribution.
 * User B has a printer for which the manufacturer supplies a closed-source driver which distributions cannot ship
 * User C has a new printer whose driver is not yet in the release of the distribution that they are using.
Line 19: Line 23:
All Ubuntu distributions, depending on implementation progress Feisty or Feisty+1. All Linux distributions, depending on implementation progress starting with Ubuntu Intrepid.
Line 23: Line 27:
This is based on new functionality which I am currently adding to linuxprinting.org resp. FSG OpenPrinting. See the [https://wiki.ubuntu.com/PrinterDriverAutoDownload?action=AttachFile&do=view&target=FSGOpenPrintingPresentation.pdf attached presentation] ([https://wiki.ubuntu.com/PrinterDriverAutoDownload?action=AttachFile&do=view&target=FSGOpenPrintingPresentation.odp OOo 2.0]) and also The automatic download will be triggered by the auto-detection and/or manual selection of a printer by the hal-cups-utils or by using the add-printer wizard of system-config-printer. In any case functions of system-config-printer will try to assign a locally installed driver to the printer and set up a CUPS queue. In the case that these functions do not find an appropriate driver, a DBUS request will be sent telling that a piece of hardware was found for which there is no driver. The call is accompanied by identity information about the printer (IEEE-1284 device ID, if not available make and model).
Line 25: Line 29:
 * http://www.freestandards.org/en/OpenPrinting/SummitLexington
 * http://www.freestandards.org/wordpress/?p=224
A driver manager, in our case Jockey, will catch the DBUS call and query the OpenPrinting database via its web query API to get answered back which drivers are available for the printer. It can be no driver, one or several. Then descriptions (and if needed also license text) of the drivers are presented to the user in a GUI, containing the info in the gray boxes at the top of a [[http://openprinting.org/show_driver.cgi?driver=splix|driver entry page on the OpenPrinting web site]]. The user selects the driver, accepts the license (if needed for the driver), and if he agrees with the download and installation of the driver he clicks "OK" or "Next" and the driver gets downloaded and installed. After that, or if the user cancels or if no driver was found, the driver manager closes and returns a success or failure, in success case also which driver was loaded, via DBUS.
Line 28: Line 31:
=== Principle === Now system-config-printer gets triggered to go on, so that the queue gets set up or the setup gets aborted if the printer is unsupported or the user did not like the available driver.
Line 30: Line 33:
 * Add requirements for common printer driver interfaces to LSB 3.2: Driver/renderer (currently GhostScript interfaces IJS, CUPS raster, OpenPrinting Vector, FHS (File System Hierarchy) extension for printer drivers and PPDs.
 * Make use of other LSB standards, like packaging
 * Make distribution independent driver packages which work with every LSB-3.2-compliant distro
 * Attach these packages as downloadable files to the driver entries of the Foomatic database at linuxprinting.org (FSG OpenPrinting)
 * Make the access both human- and machine-readable
 * Provide an API for client software to access: List of all printers, drivers, driver packages, available/recommended drivers for a given printer (specified by device ID or Foomatic printer entry), driver free/non-free?, digital signatures, driver download
 * A printer setup tool could for example detect a printer, check local driver availability and in addition ask the FSG OpenPrinting database for available drivers for this printer. Then install the remote driver if there is no local driver is available or if the local driver is older (update).
The driver packages are distribution-independent LSB-based RPMs. To fulfill security and quality standards of the distributions we will apply the following
Line 38: Line 35:
=== Integrity/security/reliability issues === Binary printer driver packages and also PPD files (for PostScript printers) will be hosted on the OpenPrinting web site. Binary packages will be available as distribution-independent LSB-3.2-based packages. The packages will be automatically alienized to also have .debs (the LSB DDK takes care that the maintainer scripts work with both RPM and DEB). Then the package directories get indexed for apt-get, yum, and urpmi (so that most common distros can manage and auto-update them with their package managers) and the index files get signed to protect against faked packages. Also PostScript PPD files (which cannot be managed with package managers) get signed. In addition, printer manufacturers and driver developers who upload have to follow strict quality, integrity, compatibility, and security guidelines (like for example issuing security updates).
Line 40: Line 37:
- IanJackson 7./9. 11. 2006 apropos of discussion in the BoFs on Sunday and Tuesday on the UDS in Mountain View. Some driver packages are already available for testing work, but they are not yet indexed.
Line 42: Line 39:
It is not clear that automatically downloading software from a website like this, and running it as root, is a good idea. This is probably OK for ppd files (which are more like data) but driver programs (which convert raster data into a stream for the printer) run as root in the printing system, installing packages might accidentally break unrelated aspects of the system (or the whole system), and there are some worries about whether it's always reasonable for us to decide on our users' behalf to wholly trust the originators of these drivers. === Description of the printer driver download service at OpenPrinting ===
Line 44: Line 41:
''Remark'': Drivers will not run as root, as the CUPS filter chain is usually executed as a special user like "cupsys" or "lp". They also run in user space and never in kernel space (they are PS --> printer's language filters, so they have more the character of an application and not of a driver). ''Note'': This service is completely independent from Ubuntu and is provided to all distributions and also to end users.
Line 46: Line 43:
So, to be consistent with our efforts to ensure that post-release our systems are stable and secure, it would be sensible to arrange that these programmatic drivers should be blessed by Ubuntu itself. In which case it probably makes most sense to distribute them via our normal package distribution channels. These features are already implemented:
Line 48: Line 45:
To still make use of driver packages from FSG OpenPrinting but provide Ubuntu-approved drivers one could suggest the following approach:  * The LSB 3.2 has requirements for common printer driver interfaces: Driver/renderer interfaces: IJS, CUPS Raster, OpenPrinting Vector, Ghostscript driver pxlmono/pxlcolor, foomatic-rip, libcupsimage library, FHS (File System Hierarchy) extension for printer drivers and PPDs.
 * LSB-compliant binary executables, Adobe-compliant PPDs
 * Make distribution-independent binary RPMs which work with every LSB-3.2-compliant distro (RPMs get converted to Debian packages with alien).
 * Attach these packages as downloadable files to the driver entries of the Foomatic database at OpenPrinting
 * Database entries contain the following information so that users can easily choose the most suitable driver:
   * Driver name
   * Supported printers
   * Release version
   * Does it come from the manufacturer
   * Is it free or non-free?
   * License, with license text if needed
   * Possible patent issues
   * Contact info to get support, report bugs, ...
   * Ratings for typical printing tasks
Line 50: Line 60:
* A daily process checks whether there are new drivers at FSG OpenPrinting and adds them to a TODO list
* QA people at Ubuntu test the driver by installing it and doing some tests (which do not require the printer, like printing into a file)
* If all is fine, they make a Debian package of this driver and do perhaps small adaptations
* The Debian package gets into the Ubuntu repositories
* The printer setup tool in Ubuntu looks for into the Ubuntu repositories for driver auto downloads
 * Access is both human- and machine-readable
 * Web API for client software to access: List of all printers, drivers, driver packages, available/recommended drivers for a given printer (specified by device ID, make/model, or Foomatic printer entry), driver free/non-free?, digital signatures, driver download
Line 56: Line 63:
The user can still on his own responsibility download drivers from FSG OpenPrinting and install them. These feature will be added:
Line 58: Line 65:
- Additional remarks  * Alienizing the RPMs to also get DEBs, this is needed to index for apt-get.
 * Make three indices for apt-get, yum, and urpmi. This allows package manager use with most common distros (Debian, Ubuntu, Red Hat/Fedora, SUSE/Novell, Mandriva, and many derivatives of these).
 * Sign the indices (or the packages), sign also unpackaged PostScript PPDs.
 * Automatically extract PPDs, Foomatic XMLs, CUPS DDK DRVs and generate Foomatic XMLs (driver, perhaps also printer) so that the printers supported by the packages get listed on the OpenPrinting web site and so found both via the web query API and the human-readable web site (and via Google).
 * Publish QA and security guidelines for uploaders (printer manufacturers and driver developers). Driver design guidelines are [[https://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers#What_to_do_and_what_not_to_do|already available]].
Line 60: Line 71:
Some security considerations about printer drivers: For more details see:
 * [[http://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers|Making distribution-independent printer driver packages based on the LSB]]
 * [[http://www.linux-foundation.org/en/OpenPrinting/Database/Query|Web API for printer setup tools to query the OpenPrinting database and download printer drivers]]
 * [[https://www.linux-foundation.org/images/e/e4/Distro-Independent-Packages.pdf|Presentation from OpenPrinting Summit 2007]]
Line 62: Line 76:
 * On all distros printer drivers do not run as root, but as the special users "cupsys" or "lp"
 * Printer drivers never run in kernel mode
 * Printer drivers are filters which generate the printer's native language from PostScript input
Line 66: Line 77:
Every driver package should provide the following data: === Driver download by Ubuntu ===
Line 68: Line 79:
 * Release version
 * Release date
 * Is it free or non-free?
 * Contact info to get support, report bugs, ...
 * Digital signature of the supplier (for example printer manufacturer)

The driver supplier should overtake responsibility (like support) for the driver he has issued.
In Ubuntu the driver download will get performed by the driver management tool Jockey. See "Design" section above.
Line 78: Line 83:
Implementation on the FSG OpenPrinting side will soon be started by Till Kamppeter Web API for database queries and packaging method for distribution-independent binary packages are already implemented. system-config-printer already contains a facility to auto-download pure PPD files (for PostScript printers). Also infrastructure for driver lookup is already in system-config-printer.
Line 80: Line 85:
Implementation on the Ubuntu will start when all needed APIs and specs are published by FSG. As the actual query and download will be done by Jockey, Jockey will use code from system-config-printer as a base to start the query implementation in Jockey.
Line 82: Line 87:
Printer setup tool in which implementation of this feature will be done principally is printerdrake. Next steps of the implementation are the setup of the package repositories and the automatic alienization, indexing, signing and Foomatic-entry generating infrastructure on the OpenPrinting server. One Google Summer of Code student and a volunteer are doing work on the server.
Line 84: Line 89:
== Comments ==

The drivers do need to be on the cd, not all people have a broadband internet connection.
 * The most important drivers (HPLIP, GutenPrint, GhostScript built-in, ...) will continue to be on the CD, only less important drivers or drivers which cannot be shipped due to copyright reasons will be supplied via internet. The automatic internet download also serves for driver updates.
--
CategorySpec

Automatic download of printer drivers through the internet

Summary

Printer drivers are continually being created or updated - especially as new printers can come out at any time between distribution releases. It is not reasonable to expect all distributions to be completely up to date all of the time, yet users expect to be able to use a brand new printer straight away.

Rationale

Many printers do not get set up automatically straight away due to their drivers not being shipped with the distribution. Giving easy access to drivers from an external source will widen the scope of printers which will 'just work' a lot.

Use cases

  • User A has an uncommon printer for which there are no drivers in their distribution.
  • User B has a printer for which the manufacturer supplies a closed-source driver which distributions cannot ship
  • User C has a new printer whose driver is not yet in the release of the distribution that they are using.

Scope

All Linux distributions, depending on implementation progress starting with Ubuntu Intrepid.

Design

The automatic download will be triggered by the auto-detection and/or manual selection of a printer by the hal-cups-utils or by using the add-printer wizard of system-config-printer. In any case functions of system-config-printer will try to assign a locally installed driver to the printer and set up a CUPS queue. In the case that these functions do not find an appropriate driver, a DBUS request will be sent telling that a piece of hardware was found for which there is no driver. The call is accompanied by identity information about the printer (IEEE-1284 device ID, if not available make and model).

A driver manager, in our case Jockey, will catch the DBUS call and query the OpenPrinting database via its web query API to get answered back which drivers are available for the printer. It can be no driver, one or several. Then descriptions (and if needed also license text) of the drivers are presented to the user in a GUI, containing the info in the gray boxes at the top of a driver entry page on the OpenPrinting web site. The user selects the driver, accepts the license (if needed for the driver), and if he agrees with the download and installation of the driver he clicks "OK" or "Next" and the driver gets downloaded and installed. After that, or if the user cancels or if no driver was found, the driver manager closes and returns a success or failure, in success case also which driver was loaded, via DBUS.

Now system-config-printer gets triggered to go on, so that the queue gets set up or the setup gets aborted if the printer is unsupported or the user did not like the available driver.

The driver packages are distribution-independent LSB-based RPMs. To fulfill security and quality standards of the distributions we will apply the following

Binary printer driver packages and also PPD files (for PostScript printers) will be hosted on the OpenPrinting web site. Binary packages will be available as distribution-independent LSB-3.2-based packages. The packages will be automatically alienized to also have .debs (the LSB DDK takes care that the maintainer scripts work with both RPM and DEB). Then the package directories get indexed for apt-get, yum, and urpmi (so that most common distros can manage and auto-update them with their package managers) and the index files get signed to protect against faked packages. Also PostScript PPD files (which cannot be managed with package managers) get signed. In addition, printer manufacturers and driver developers who upload have to follow strict quality, integrity, compatibility, and security guidelines (like for example issuing security updates).

Some driver packages are already available for testing work, but they are not yet indexed.

Description of the printer driver download service at OpenPrinting

Note: This service is completely independent from Ubuntu and is provided to all distributions and also to end users.

These features are already implemented:

  • The LSB 3.2 has requirements for common printer driver interfaces: Driver/renderer interfaces: IJS, CUPS Raster, OpenPrinting Vector, Ghostscript driver pxlmono/pxlcolor, foomatic-rip, libcupsimage library, FHS (File System Hierarchy) extension for printer drivers and PPDs.

  • LSB-compliant binary executables, Adobe-compliant PPDs
  • Make distribution-independent binary RPMs which work with every LSB-3.2-compliant distro (RPMs get converted to Debian packages with alien).
  • Attach these packages as downloadable files to the driver entries of the Foomatic database at OpenPrinting

  • Database entries contain the following information so that users can easily choose the most suitable driver:
    • Driver name
    • Supported printers
    • Release version
    • Does it come from the manufacturer
    • Is it free or non-free?
    • License, with license text if needed
    • Possible patent issues
    • Contact info to get support, report bugs, ...
    • Ratings for typical printing tasks
  • Access is both human- and machine-readable
  • Web API for client software to access: List of all printers, drivers, driver packages, available/recommended drivers for a given printer (specified by device ID, make/model, or Foomatic printer entry), driver free/non-free?, digital signatures, driver download

These feature will be added:

  • Alienizing the RPMs to also get DEBs, this is needed to index for apt-get.
  • Make three indices for apt-get, yum, and urpmi. This allows package manager use with most common distros (Debian, Ubuntu, Red Hat/Fedora, SUSE/Novell, Mandriva, and many derivatives of these).
  • Sign the indices (or the packages), sign also unpackaged PostScript PPDs.

  • Automatically extract PPDs, Foomatic XMLs, CUPS DDK DRVs and generate Foomatic XMLs (driver, perhaps also printer) so that the printers supported by the packages get listed on the OpenPrinting web site and so found both via the web query API and the human-readable web site (and via Google).

  • Publish QA and security guidelines for uploaders (printer manufacturers and driver developers). Driver design guidelines are already available.

For more details see:

Driver download by Ubuntu

In Ubuntu the driver download will get performed by the driver management tool Jockey. See "Design" section above.

Implementation

Web API for database queries and packaging method for distribution-independent binary packages are already implemented. system-config-printer already contains a facility to auto-download pure PPD files (for PostScript printers). Also infrastructure for driver lookup is already in system-config-printer.

As the actual query and download will be done by Jockey, Jockey will use code from system-config-printer as a base to start the query implementation in Jockey.

Next steps of the implementation are the setup of the package repositories and the automatic alienization, indexing, signing and Foomatic-entry generating infrastructure on the OpenPrinting server. One Google Summer of Code student and a volunteer are doing work on the server.

-- CategorySpec

PrinterDriverAutoDownload (last edited 2008-08-06 16:35:34 by localhost)