Setting up and administering print queues within the CUPS printing system. Aimed at a stretch installation, but most of the material should apply to jessie and buster too.
- Print Queues and Printers
- The device-uri
- The device-uri for a Networked Printer
- Configuring the Choice of Backend
- Printer Drivers
- Non-free Printer Drivers and Firmware
- Avoiding Non-free Printer Drivers and Firmware
- The PPD File
- Creating a Print Queue with lpadmin
- Creating a Print Queue with the CUPS Web Interface
- Creating a Print Queue with HPLIP
- Creating a Print Queue with system-config-printer
- Double Filtering
- Printing and GTK Applications
- Printing Without a Local CUPS Server
- Configuration Files for the Scheduler, cupsd
- See Also
Print Queues and Printers
A document destined for a printer is frequently called a print job. On its way to the printer it is first put into a queue before being processed. The queue has certain properties which determine how the print job is dealt with and may be queried with lpoptions and lpstat for a list of these properties and the queue status repectively.
The properties specified when the queue is created are not immutable. Quite a few of them can be altered by a user when the print job is submitted to the queue. An administrator who hoped to confine users to duplex (two-sided) printing would have to look outside the CUPS framework for a solution to add to the system.
Several queues can point to the same physical device, the printer, but it is very common for print queue and printer to be used interchangably. Generally no harm comes from this, but it pays to give careful attention to whether a CUPS print server or a printer is being contacted.
Ultimately, a print job has to go somewhere; most users expect the job to go to a printer. However, the job is only going to get to the printer (after being taken out of the queue) if the device-uri is one recognised by CUPS and the printer. lpinfo allows you to see which device-uris are associated with a print server or printer:
The backends in /usr/lib/cups/backends are now used in discovery mode in an endeavour to locate printers. Here is the output of one such command when two printers are attached to a stretch machine via a USB and parallel port and two are available over the network:
network lpd network ipp network http network socket network beh network ipp14 network https network ipps direct parallel:/dev/lp0 serial serial:/dev/ttyS0?baud=115200 serial serial:/dev/ttyS1?baud=115200 direct usb://hp/psc%201300%20series?serial=HU3AFBQ28Y9F&interface=1 direct hp:/usb/psc_1300_series?serial=HU3AFBQ28Y9F direct hpfax network dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2 network dnssd://LaserJet-300%20%40%20desktop._ipp._tcp.local/cups?uuid=0fee6c87-f32d-3868-7a84-0d35d978f299 network socket://192.168.7.211 network socket://192.168.7.235:9100
The USB-connected printer and the networked ones have definitely been discovered. They have device-uris
direct usb://hp/psc%201300%20series?serial=HU3AFBQ28Y9F&interface=1 direct hp:/usb/psc_1300_series?serial=HU3AFBQ28Y9F network dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2 network dnssd://LaserJet-300%20%40%20desktop._ipp._tcp.local/cups?uuid=0fee6c87-f32d-3868-7a84-0d35d978f299 network socket://192.168.7.211 network socket://192.168.7.235:9100
The USB connected printer has been located by two backends; usb and hp. The first comes from CUPS and the second from HPLIP. The CUPS backends, dnssd and socket, have discovered the networked LaserJet (at 192.168.7.211) and ENVY 4500 (at 192.168.7.235).
A parallel port has also been found by the cups-filters parallel backend. Its device-uri is
For more detail and to identify the makes and models of the printers you will want to do
lpinfo -l -v
In this case, an edited output is
Device: uri = usb://hp/psc%201300%20series?serial=HU3AFBQ28Y9F&interface=1 class = direct info = hp psc 1300 series make-and-model = hp psc 1300 series device-id = MFG:hp;MDL:psc 1300 series;CMD:LDL,MLC,PML,DYN;CLS:PRINTER;1284.4DL:4d,4e,1;SN:HU3AFBQ28Y9F;S:0380008000020020112fff8d800fff8d800;Z:007; location = Device: uri = hp:/usb/psc_1300_series?serial=HU3AFBQ28Y9F class = direct info = HP psc 1300 series USB HU3AFBQ28Y9F HPLIP make-and-model = HP psc 1300 series device-id = MFG:hp;MDL:psc 1300 series;CLS:PRINTER;DES:psc 1300 series;SN:HU3AFBQ28Y9F; location = Device: uri = parallel:/dev/lp0 class = direct info = EPSON Stylus COLOR 740 LPT #1 make-and-model = EPSON Stylus COLOR 740 device-id = MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus COLOR 740;CLS:PRINTER; location = Device: uri = dnssd://LaserJet-300%20%40%20desktop._ipp._tcp.local/cups?uuid=0fee6c87-f32d-3868-7a84-0d35d978f299 class = network info = LaserJet-300 @ desktop make-and-model = HP HP LaserJet 2200 device-id = MFG:HP;MDL:LaserJet 2200;CMD:PDF,PS,JPEG,PNG,PWG,URF; location = Device: uri = socket://192.168.7.211 class = network info = HP LaserJet 2200 make-and-model = HP LaserJet 2200 device-id = G:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:HP LaserJet 2200;CLS:PRINTER;DES:Hewlett-Packard LaserJet 2200;MEM:8MB location = Device: uri = socket://192.168.7.235:9100 class = network info = ENVY 4500 series make-and-model = HP ENVY 4500 series device-id = MFG:HP;MDL:ENVY 4500 series;CMD:PCL3GUI,PJL,Automatic,JPEG,PCLM,AppleRaster,DW-PCL,802.11,DESKJET,DYN;CLS:PRINTER;DES:A9T87B;CID:HPIJVIPAV4;LEDMDIS:USB#FF#CC#00,USB#07#01#02,USB#FF#04#01;IPP-HTTP:T;IPP-E:FF-CC-00,07-01-02,FF-04-01;SN:CN56G332DT060D;S:038080C484a01021002c1f3000ac2880014;J: ;Z:0102,05034ee800aaa8,0600,0c0,0e000c0000,0f01000000,10000008000008,12000,147,150,16361a34ee000116da17d40001,1700005a000000,180; location = Study Device: uri = dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2 class = network info = ENVY4500 make-and-model = HP ENVY 4500 series device-id = MFG:HP;MDL:ENVY 4500 series;CMD:PCL,JPEG,URF; location =
The dnssd://... entries are either Bonjour-broadcasted print queues from a CUPS server on a remote machine or Bonjour-enabled printers; DNS-SD has located them with the help of Avahi. In general, queues created with a dnssd://... device-uri should be set up on the client as raw queues so that the filtering takes place entirely on the remote server.
If it is known that a queue on the remote machine is itself a raw one or the device-uri points to a printer, you might have to consider whether setting up a local raw queue achieves what you want (see Tea4CUPS for situations in which you would want a local raw queue).
A Bonjour-enabled printer would almost certainly require a local non-raw queue to be set up for it.
Which dnssd://... entries are queues and which are printers?
/usr/lib/cups/backend/dnssd > dnssd.log grep "local/cups" dnssd.log (These are print queues). grep "local/?uuid" dnssd.log (These are printers). grep "Unknown" dnssd.log (These are raw print queues).
The device-uri for a Networked Printer
CUPS can use at least one of the AppSocket, Internet Printing (IPP) and Line Printer (LPD) protocols for connecting to printers and print servers over a network connection. For a view of which services a device supports there is thenmap command:
The output will vary from printer to printer. For an HP Envy 4500 it is
PORT STATE SERVICE 80/tcp open http 443/tcp open https 631/tcp open ipp 8080/tcp open http-proxy 9100/tcp open jetdirect 9220/tcp open unknown
The choice of protocol will be driven by your needs and what is offered by the printer or print server. AppSocket is non-complex, usually well-implemented, low overhead and reliably gets the data from point A to point B, but doesn't do much else. IPP provides bidirectional communication for feedback and control, secure authentication services, access control and printer discovery and status. Its use is mandatory on AirPrint and IPP Everywhere printers. LPD is a popular protocol older than IPP and with a feature set less extensive than it. Secure access, detailed error status reports and the ability to query a printer are lacking, for example.
Also known as the JetDirect or RAW protocol, this is the most basic protocol that can be supported by a printer. The URI scheme is
The standard port number is 9100 and this will be used by default if omitted from the device-uri. Print servers with three outputs would require three port numbers; for example, 9100, 9101 and 9102.
It is questionable whether AppSocket is a protocol. There is no specified standard for it; no queue management; no aborting of jobs; no querying of printer supplies; no encryption. All it does is shovel the data for a print-ready file over the network and then close the connection. Because the only overhead is TCP/IP the data transfer is generally fast. Also, it has been in widespread use for a long time so the printer implementations of AppSocket are good.
Printing normally takes place over port 631 with the URI scheme being
Unfortunately, the resource path has never been standardised and it may require some experimentation to determine what a printer or server will accept, especially if the device is not on the local network. Apparently, newer printers use /ipp/print in the path but for older products it could be something entirely different, like ipp/port1 or ipp. Maybe the printer's front panel will help. Or
could give suitable output if there is explicit information from the Port Monitor MIB (Management Information Base) database of the printer. In the absence of an MIB the probing is for AppSocket, then LPD and the first that works is reported. Because AppSocket is supported by most network printers it would likely be the protocol given for use in a URI.
If an IPP printer has registered itself using Avahi (DNS-SD/mDNS), more success with obtaining an IPP URI could be achieved by installing avahi-utils, running avahi-browse and looking at the rp TXT Record Key:
ippfind (Shows IPP printers and print queues). ippfind -T 5 (Possibly more reliable). ippfind ! --txt printer-type (Show IPP printers only).
A CUPS server can always be reached with
In theory, the handshaking and status monitoring done by the IPP protocol should ensure reliable printing but, in practice, there are older printers which do not implement some aspects of IPP very well. However, these days, a more optimistic view of the situation can be taken.
This is the original network protocol. It has a URI scheme of
and a default port of 515. Even though AppSocket and IPP are seen as better alternatives, it is regarded as a reliable protocol for sending a job to a printer. CUPS itself has some limited functionality for LPD-based clients
Configuring the Choice of Backend
The cups package provides a debconf method for selecting backends which are used for printer discovery and connection to the device. It basically gives a convenient way of copying the backends which come with CUPS between /usr/lib/cups/backend-available/ and /usr/lib/cups/backend/. Run
Note that not every backend on the system is managed with this command because they are not all in the cups package. For example, the parallel and beh backends are in the cups-filters package.
Be careful about which backends are removed from the debconf list. Deleting the dnssd backend would still allow remote Bonjour broadcasted queue discovery via cups-browsed but Bonjour broadcasted printers would not seen by CUPS. An AppSocket-enabled printer would be discoverable with the snmp backend but, if the socket backend was deleted, trying to set up a queue using a socket://... URI would give the error Bad device-uri scheme "socket".
Drivers are in the printer-driver-* packages plus various other packages. The print server task in Debian Installer gives you a full complement of these drivers. You may decline this task at install time but after first boot can do either
apt-get install task-print-server
apt-get install cups
If a driver/PPD for your printer is not in any of the installed packages you have various choices open to you:
Consult openprinting for ideas on available drivers.
- Hunt down an appropriate package with
apt-cache search search_term
Go to the printer manufacturer's website
Non-free Printer Drivers and Firmware
Driver software distributed with quite a few printers does not meet the criterion of being DFSG-free, so users will have to rely completely on what the printer manufacturer has to offer to get their printer working. Also, even though their drivers are almost all DFSG-free, some HP printers require a proprietary host-based driver or firmware to allow full access to printer and scanner features and enhanced performance. The firmware is uploaded to the printer when it is powered-on attached to the computer.
It may also be necessary to go to the manufacturer's website if the printer is a new model and drivers for it are not yet in a Debian package.
Solutions for Linux is a good place to start for assessing what support your printer has from Brother. Generally, you will need .deb files for the cupswrapper and the lpr driver. Follow the instructions to install them; alternatively, there is linux-brprinter-installer to do that for you.
There is a wiki page dealing with Canon URF-II printers which should suffice for installing all Canon's package offerings.
Linux support for a Samsung printer can be searched for from either the HP or Samsung web sites. Many, but not all, Samsung printer models use the Unified Linux Driver (ULD). ULD contains PPDs for Linux supported printers, a printer driver to use with the PPDs and a library to use with the driver. It comes in a .tar.gz package and only supports the i386 and amd64 platforms. No source code is provided.
Extract the files in the tarball and install them by entering the directory created and running install-printer.sh
tar zvxf uld_v1.00.xx_xx.xx.tar.gz cd uld ./install-printer.sh
Samsung does not provide ULD as a .deb but the The Samsung Unified Linux Driver Repository does. It also has a good deal of information on the installation of ULD and its interaction with a Debian system. SULDR is not affiliated with Samsung.
A relatively small number of HP devices require a plugin to be installed on the computer for them to operate at all or to function at their full potential for one or more of the device's printing, scanning or faxing modes. For a handful of HP printers the plugin contains firmware which has to be uploaded to a printer. Without a firmware requirement the plugin software can still be needed to interact with the printer. Effectively, the print job is processed by the plugin to produce a file in a language the printer understands. In technical literature the printer would be described as host-based. See whether the plugin is needed and use HP's home page search facility to see a printer's details and find out what any firmware is required for.
Any needed firmware can be installed when hplip is installed and the command hp-plugin -i is issued to get the plugin (firmware) file for the particular HPLIP release. HPLIP can probably be removed after this is done if the hp backend is not preferred for printing or if hp-setup is not needed to establish a print queue.
Plugin software can be installed (as root) without the hplip package being on the system.
Download the appropriate file to a chosen directory.
sh hplip-<version>-plugin.run --tar vxf
foo2zjs (firmware and colour profiles)
getweb | less getweb p1008
give a list of what is available and download the firmware file for an HP LaserJet P1008. Hannah is a graphical firmware downloader which uses getweb. Re-plug the connection to the printer to upload the firmware to it.
Avoiding Non-free Printer Drivers and Firmware
A non-free filter generally gets used at the last stage of the filtering process after cups-filters has done its job. The process ends with something that is sometimes termed host-based (and which is often proprietary) rather than letting the printer itself take care of the final conversion. It makes sense to the printer manufacturer to do this (probably on legal, technical or economic grounds) but it disrupts the free software ecosystem within which CUPS and cups-filters operate.
+----------------------+ +-----------------+ File in -> |CUPS and cups-filters | -> | Non-free driver | -> Printer +----------------------+ +-----------------+
The final stage of this process could be dispensed with if what was sent to the printer was something it could understand.
+------------------------+ +-----------------------+ | Something the printer | File in -> | CUPS and cups-filters | -> | understands sent by | -> Printer +-----------------------+ | CUPS and cups filters. | +------------------------+
Recent developments in printer technology see printers understanding MIME types image/pwg-raster and image/urf. These file types are also referred to as PWG and Apple raster data formats respectively.
+--------------+ +-----------------------+ | Apple raster | File in -> | CUPS and cups-filters | -> | or | -> Printer +-----------------------+ | PWG raster | +--------------+
From CUPS 2.2.2 and cups-filters 1.13.0 onwards it is possible to send a job in Apple and PWG raster to a printer which understands either data format. This is dealt with in more detail on the driverless printing page.
The PPD File
PostScript Printer Description (PPD) files were originally used by printers which operated with PostScript as a Page Description Language (PDL) for printing. They have been adapted to cope with other standard printer languages such as HP's Printer Command Language (PCL) and special (often proprietary) languages. Driver packages include PPDs in their contents.
A searchable list of PPDs on your system is obtained with
/usr/sbin/lpinfo -m | less
If there is only one for your printer the choice is made for you! If there is more than one, go for the PPD which is marked Recommended. If none are recommended use common sense or seek help from the openprinting database.
Some Generic PPDs are listed with lpinfo -m and one could be a solution when every driver package is installed and your printer model is not in the list. You can also resort to the printer manufacturer's website or a CD which came with the printer.
It is convenient (and probably sensible) to put a PPD obtained from elsewhere in /usr/share/ppd/custom. It will then be displayed in the outputs of lpinfo -m, the web interface and system-config-printer.
Creating a Print Queue with lpadmin
This is the basic method to set up a queue. It is used behind the scenes with programs like system-config-printer, HPLIP and the web interface. There are four essentials to provide when setting up a working, accepting print queue with lpadmin.
The queue name (-p): The printing system treats the name in a case-insensitive manner; LaserJet-300 is the same queue as laserjet-300.
The device-uri (-v): The destination for a print job; usually a printer.
The PPD file (-m or -P): Determines how the print job is handled by the filtering system to produce data which can be successfully printed by the printer.
- Whether the queue is enabled (-E}: Must be specified explicitly.
With this information:
lpadmin -p <queue_name> -v <device-uri> -m PPD_file -E
sets up the queue.
Sometimes it is necessary or desirable to establish a raw queue. That is, a queue where the filtering system is not involved and the print job goes directly to a printer or another queue.
lpadmin -p <queue_name> -v <device-uri> -m raw
lpoptions is the command to use to see default printer-specific options (obtained from the PPD) for the queue.
lpoptions -p <queue_name> -l
The previous lpadmin command is about as simple as it gets for setting up a queue quickly but it can be tweaked just as simply by giving the command some printer-specific options to add with -o.
Setting up a queue with lpadmin or the web interface requires either root privileges or for the user to be a member of the lpadmin group. If you installed CUPS using the printserver task in the Debian installer, the first user is put in the lpadmin group.
Check for user membership of the lpadmin group with the command
Creating a Print Queue with the CUPS Web Interface
http://localhost:631 is the location of the interface and from there you can administer print queues, including their installation. Administration tasks are able to be completed by giving the root name and password or the user name and password of an lpadmin group member.
The Add Printer button could produce a first page with something like this on it:
Local Printers: CUPS-BRF (Virtual Braille BRF Printer) Serial Port #1 Serial Port #2 HP psc 1300 series USB HU3AFBQ28Y9F (HP psc 1300 series) hp psc 1300 series (HP psc 1300 series) HP Fax (HPLIP) EPSON Stylus COLOR 740 LPT #1 (EPSON Stylus COLOR 740) Discovered Network Printers: ENVY4500 (HP ENVY 4500 series) LaserJet-300 @ desktop (HP HP LaserJet 2200) HP LaserJet 2200 (HP LaserJet 2200) ENVY 4500 series (HP ENVY 4500 series) Other Network Printers: AppSocket/HP JetDirect Internet Printing Protocol (ipps) Internet Printing Protocol (ipp14) Internet Printing Protocol (https) Internet Printing Protocol (http) LPD/LPR Host or Printer Internet Printing Protocol (ipp)
Which doesn't look significantly different from what lpinfo gave previously.
Under Local Printers: are the discovered printers which are directly connected to the machine being used. Discovered Network Printers: are networked printers on the same subnet as your machine. Or they could be print queues which the dnssd backend has found on the same subnet. In both cases backends have been run in discovery mode to find printers. The device-uri found is on the second page of the interface.
Other Network Printers: gives you the opportunity to provide the device uri and PPD for a printer or queue which falls into neither of the previous two categories. The information is provided on the second and third pages.
Having made a selection from Local Printers: or Discovered Network Printers: you should find a queue name based on the printer make and model has been filled in for you on the next page. Change it by all means if you wish. Once it is done it cannot be modified later because a new name would imply setting up a different, new queue.
Share printers connected to this system on the Administration page is the basic facility to allow (or not allow) DNS-SD broadcasting of the queue on Debian 8.x Debian 9.x. Ticking Share This Printer on the second page designates your queue as one to add to this facility.
Moving on to the third page you should find that a PPD has been selected for you, unless
- The printer provides no make and model information to CUPS.
- There is no PPD for the printer on the system.
Other Network Printers: is being used.
The final page has the default printer-specific options from the PPD and a few non-specific printer options. This should suit the needs of many users.
Creating a Print Queue with HPLIP
HPLIP is a one-stop solution for printing, scanning and faxing with appropriate HP devices and designed to work with CUPS. Only the printing aspect is dealt with here. USB scanning is the subject of another wiki page and network scanning is linked from it. HPLIP uses its own printer backend, hp:/..., and URI scheme for printer discovery and sending a print-ready job to the printer. For a graphical user interface (GUI) to HPLIP there is a hplip-gui, which contains very similar utilities to the ones in the hplip package.
- URI scheme: USB printer.
- URI scheme: networked printer.
hp:/net/<printer_model>?ip=<IP_address> hp:/net/<printer_model>?hostname=<DNS_hostname> hp:/net/<printer_model>?zc=<zeroconf(avahi, Bonjour)_hostname>
- URI scheme: parallel port printer.
Each printer model supported by the installed verion of HPLIP is listed in /usr/share/hplip/data/models/models.dat. Model names are enclosed in square brackets; like so, [envy_4500_series].
Printer discovery and setting up a print queue can be done from the command line with hp-setup. For USB and printers on the network:
hp-setup -i -busb hp-setup -i -bnet
You will be led through the rest of the procedure.
hp-setup uses one of two methods to find printers on the network - Service Location Protocol (SLP) and mdns (Bonjour) broadcasts from suitable printers.
The SLP service agent runs on port 427 of a printer; do you have such a service?
nmap -sU -p 427 <ip_address>
will tell you.
The command hp-setup -i -bnet uses only SLP for discovery. If you want to setup a queue for an mdns advertised printer it is suggested to do
- hp-probe -mmdns (This provides a Device URI).
hp-setup -i -d<Device URI>
A problem with firewall settings could lead to the first command failing.
Note that HP printing devices can be set up with backends and device-uri schemes other than hp:/..., provided CUPS and printer-driver-hpcups have, as a minimum, been installed. Printer discovery would be done through any of lpadmin, the CUPS web interface or system-config-printer.
Creating a Print Queue with system-config-printer
The idea of system-config-printer is to provide functionality similar to lpadmin and the CUPS web interface but with GTK+ widgets and greater desktop integration. Anyone familiar with the CUPS web interface should feel at home with it but note that there is a difference in the way adminstrator privileges for the printing system are gained.
A default system-config-printer installs cups-pk-helper as a recommended package to further the aim of desktop integration. cups-pk-helper is intended to give fine-grained control of aspects of CUPS management via policykit. Unlike lpadmin, the CUPS web interface and HPLIP cups-pk-helper does not respect the SystemGroup lpadmin directive in /etc/cups/cups-files.conf and an adminstrator password will be requested to see remote print queues and to administer them and local queues.
Almost nothing is administratively possible for an ordinary user when cups-pk-helper is on the machine. A user is entitled to cancel her own jobs but without the machine's administrator altering policykit's view of who is entitled to administer printers nothing else is available.
This can be done with a file ending with .pkla put into /etc/polkit-1/localauthority/50-local.d. With the contents
[Printer configuration] Identity=unix-user:milly;unix-user:molly;unix-user:mandy Action=org.opensuse.cupspkhelper.mechanism.* ResultAny=no ResultInactive=no ResultActive=yes
the users milly, molly, mandy would have privileges granted similar to those granted to a member of the lpadmin group and not have to provide a password. Removing the cups-pk-helper package would be an alternative strategy to allow users in the lpadmin group administrative privileges.
The initial screen seen when system-config-printer is run displays icons and names for local print queues; that is, queues which been set up by a user or by cups-browsed. The Add button is for printer discovery and creating a new queue for a printer. A greyed-out button indicates a lack of some administrative privilege, so go to Server-->Connect-->Connect. Hopefully, the device-uri section will be found useful for interpreting the discovered printers display.
The CUPS web interface and the command /usr/sbin/lpinfo -v give a list of printers and print queues discovered on the network. Any of the entries in the list can be installed as a local print queue. In other words they will listed in /etc/cups/printers.conf on your machine.
For example, under Discovered Network Printers in the web interface you might see
testq @ desktop (DCP-9020CDW)
and the next web page shows a Connection beginning dnssd://.
The dnssd:// and @ desktop tell you this is a print queue discoverd by avahi-daemon. The (DCP-9020CDW) tells you the make and model of the printer. The latter information is obtained from the *Product line in the queue's PPD, so it implies the queue is not a raw queue and a job sent to it undergoes filtering on the server. The same information is given in the make-and-model field of the output of /usr/sbin/lpinfo -l -v.
On the third web page you should choose Raw as the Make. With lpadmin you should have -m raw. Then the client passes the data through without filtering and all filtering is done correctly on the server.
Alternatively, you can get such queues automatically set up locally by running cups-browsed on the client.
Upstream CUPS has something to say about double filtering. Quoting:
The issue is the MIME typing on the CUPS server - if the server doesn't recognize the MIME media type then you may end up with extra filtering. I'm not saying it can't work (because we have customers that use that configuration all of the time), it is just that we get a lot of support calls when people try to do Microsoft-style printer sharing to a server that is also hosting a CUPS printer driver on the same queue.
Reinforcing the previous point:
The issue is that for IPP we actually get to use MIME media types, and the filters in the PPD file specify what the final output type is. We then try to match things up on the remote system, which is where the problems typically occur. For example, if the local driver has a filter that specifies application/vnd.hp-pcl" as the destination MIME media type but the server does not have that MIME media type defined/supported for its queue, we have to revert to "application/octet-stream" (auto-detect). You can "fix" this with .types and .convs files on the server to specify a "-" filter for the affected MIME media types to application/vnd.cups-raw) but ultimately you are better off letting the server do the filtering...
You are strongly advised not to do double filtering. Set up the queue on the client as a raw queue if the remote queue is doing the filtering.
This package was introduced for CUPS 1.6.x and is necessary on a Debian 8.x or 9.x client machine if you want
* to discover print queues broadcast with DNS-SD (Bonjour broadcasting) and * have them automatically available in the print dialogues of GUI applications and usable by command line programs.
The change in CUPS 1.6.x came about because upstream CUPS abandoned CUPS browsing as a way of broadcasting and discovering print queues and printers. There are a number of issues inherent in this method, as this mail explains. cups-browsed was devised to bring about backward compatibility but does not intend to be available in perpetuity.
Comprehensive documention is in /usr/share/doc/cups/README.Debian.gz, /etc/cups/cups-browsed.conf, cups-browsed and cups-browsed.conf. There are significant differences in the cups-browsed facilities provided on jessie, stretch and buster.
The avahi-daemon package also needs to be installed on the client. The default cups-browsed.conf is set to do both DND-SD (Bonjour) discovery (CUPS only offers Bonjour broadcasting) and, for legacy purposes, CUPS IPP discovery of print queues.
A server with a CUPS version of 1.6.x or greater does not need cups-browsed to do DNS-SD broadcasting but avahi-daemon is required.
DNS-SD Broadcasting (Server)
DNS-SD Discovery (Client)
jessie and stretch
jessie and stretch
Legacy CUPS Broadcasting (Server)
Legacy CUPS Discovery (Client)
jessie and stretch
jessie and stretch
Printing and GTK Applications
The section on cups-browsed might give the impression that printers and print queues cannot be discovered (and printing cannot take place from Debian 8.x and 9.x clients), without it. This is not quite the case; it all depends on what you are printing from. Nevertheless it is worth repeating that cups-browsed promotes printing from all applications and from the command line.
Firefox, Evince and gedit (to name but three applications) use the GTK print dialog as a printing subsystem. The subsystem gets print queue information directly from Avahi and the queues appear in the print dialogues of the applications. cups-browsed isn't needed and neither for that matter is CUPS. This actually follows CUPS upstream practice and the PWG standards. This means that printers and print queues get broadcasted via Bonjour and an application's print dialog browses the Bonjour broadcasts to add available remote printers and queues to its list.
Printing Without a Local CUPS Server
Print queue availability by browsing the Bonjour broadcasts from a server is a dynamic process. Queues will come and go as they are enabled and disabled or as a client is moved from network to network. In a world which more and more has a focus on mobile devices there are benefits to be gained from avahi-daemon and cups-browsed or from a print dialogue which implements Avahi discovery itself.
However, it is possible a static configuration is entirely suitable for some purposes. In other words, no avahi-daemon, no cups-browsed and no cupsd running on a machine and instead connecting directly to a designated server. The first step is to read this manual. Then
apt-get install cups-client
followed by making the directory ~/.cups and putting a file client.conf in it.
mkdir ~/.cups touch ~/.cups/client.conf
The content of client.conf could be as simple as
The local queue is eliminated and print jobs from all applications and the command line go straight to ServerName for processing. There is the bother of changing ServerName when moving from network to network but this may be balanced by not having to run three daemons,
Even a client.conf may be dispensed with if the only printing to take place is from the command line. At its simplest:
lp -h <server_IP_or_hostname> -d <print_queue_on_server> <print_job?
Configuration Files for the Scheduler, cupsd
These are located in /etc/cups as cupsd.conf and cups-files.conf. The existence of two files arises from a Debian bug report which lead to the fixing of a privilege escalation from lpadmin to root on systems with all options contained in cupsd.conf, as they were at that time.
cups-files is editable only by root. cupsd.conf can be edited by root and, from the web interface only, by a user who is a member of the lpadmin group. After editing either file cupsd has to be restarted:
service cups restart
It can be very convenient to change some of the cupsd.conf settings with cupsctl (as root only). The current settings displayed by
_debug_logging=0 _remote_admin=0 _remote_any=0 _share_printers=0 _user_cancel_any=0 BrowseLocalProtocols=dnssd DefaultAuthType=Basic JobPrivateAccess=default JobPrivateValues=default MaxLogSize=0 SubscriptionPrivateAccess=default SubscriptionPrivateValues=default WebInterface=Yes
Change a displayed setting with
and, for a setting which is not displayed:
More than one line in cupsd.conf can be changed with some commands and cupsd is restarted when cupsctl is used. cups-files cannot be altered with cupsctl.