Linux internet printing protocol

CUPS/Printer sharing

This article contains instruction on sharing printers from a GNU/Linux system.

Client support

Protocol	Linux	Windows	macOS
Discovery (DNS-SD/mDNS)	CUPS with Avahi	Native support since Windows 10	Bonjour
Internet Printing Protocol	CUPS	Control Panel > Programs > Turn Windows features on or off > Print and Document Services > Internet Printing Client	Native support
SMB shared printer	Samba with CUPS	Native support	Native support
Line Printer Daemon protocol	CUPS	Control Panel > Programs > Turn Windows features on or off > Print services > LPD Print Service and LPR Port Monitor	Native support

Contents

Creating class for multiple printers

In CUPS, a class is a group of printers which appears to clients as a single printer. When a client selects to print to the class, CUPS selects any printer in the group to accept the print job. This may be especially useful when one printer from the class must be removed. If it is excluded from the class, end users will not notice any change because the print job will be queued to another printer in the class. Creating and managing classes can be done from CUPS Web GUI.

Printer sharing

This article or section needs expansion.

DNS-SD advertisement

To announce the printer to the network over DNS-SD/mDNS (Bonjour in Apple world), Avahi must be installed and running on the server.

To enable it, either select Share printers connected to this system in the web interface, or manually set Browsing On in /etc/cups/cupsd.conf :

Note that «browsing» at the print server is a different thing from «browsing» at a remote networked host. On the print server, cupsd provides the DNS-SD protocol support which the avahi-daemon broadcasts. The cups-browsed service is unnecessary on the print server, unless also broadcasting the old CUPS protocol, or the print server is also «browsing» for other networked printers. On the remote networked host, the cups-browsed service is required to «browse» for network broadcasts of print services, and running cups-browsed will also automatically start cupsd .

The cups.service service will be automatically started when a USB printer is plugged in, however this may not be the case for other connection types. If cups.service is not running, avahi-daemon does not broadcast the print services, so in that case the systemd unit service file must be modified to start on boot, and then the service must again be «enabled/installed» with the new dependency. To do this, edit the service file [Install] section to add a WantedBy=default.target dependency, and then enable and start the cups.service service.

Sharing via Internet Printing Protocol

The server can be configured using either the web interface or by manually editing /etc/cups/cupsd.conf .

Open up the web interface to the server, select the Administration tab, look under the Server heading, and enable the «Share printers connected to this system» option. Save your change by clicking on the Change Settings button. The server will automatically restart.

On the server computer (the one directly connected to the printer), allow access to the server by modifying the location directive. For instance:

Also make sure the server is listening on the IP address the client will use:

There are more configuration possibilities, including automatic methods, which are described in detail in Using Network Printers and cupsd.conf(5) .

After making any modifications, restart cups.service .

If CUPS is started using socket activation, create a drop-in snippet for cups.socket so that socket activation also works for remote connections:

Sharing via Samba

Samba is an implementation of the Windows file and printer sharing protocols, even the most vintage ones.

To configure Samba on the Linux server, edit /etc/samba/smb.conf file to allow access to printers. File smb.conf can look something like this:

That should be enough to share the printer, yet adding an individual printer entry may be desirable:

Please note that this assumes configuration was made so that users must have a valid account to access the printer. To have a public printer, set guest ok to yes , and remove the valid users line. To add accounts, set up a regular GNU/Linux account and then set up a Samba password on the server. See Samba#User management.

After this, restart smb.service and nmb.service .

See Samba’s documentation Setting up Samba as a Print Server for more details.

Sharing via Line Printer Daemon protocol

Remote administration

Once the server is set up as described in #Printer sharing, it can also be configured so that it can be remotely administered. Add the allowed hosts to the block in /etc/cups/cupsd.conf , using the same syntax as described in #Sharing via Internet Printing Protocol. Note that three levels of access can be granted:

To give remote hosts access to one of these levels, add an Allow statement to that level’s section. An Allow statement can take one or more of the forms listed below:

Deny statements can also be used. For example, to give full access to all hosts on your local network interfaces, edit /etc/cups/cupsd.conf to include this:

You might also need to disable the HTTPS requirement, when using the default self-signed certificate generated by CUPS:

This should avoid the error: 426 — Upgrade Required when using the CUPS web interface from a remote machine.

Kerberos

Kerberos can be used to authenticate users accessing a remote CUPS server. This assumes that your machine has a keytab and it will need a ticket for «HTTP». Instead of using http://localhost:631 you must use https://host.example.co.uk:631 — encryption is required for auth (hence https) and the full hostname is needed so that Kerberos/Negotiate can work. In addition, the server must be configured in /etc/cups/cupsd.conf to use a DefaultAuthType of Negotiate .

If you are using Samba’s winbind NSS support, you can add an AD group name to /etc/cups/cups-files.conf — in the following example sysadmin might be an AD group:

Troubleshooting

See CUPS/Troubleshooting for general troubleshooting tips.

Cannot print with GTK applications

If you get a getting printer information failed message when you try to print from GTK applications, add this line to your /etc/hosts :

Permission errors on Windows

Some users fixed NT_STATUS_ACCESS_DENIED (Windows clients) errors by using a slightly different syntax:

Источник

Using Network Printers

This help document describes how to discover, configure, and use TCP/IP network printers with CUPS.

Automatic Configuration Using Bonjour

Most network printers support a protocol known as Bonjour, which is a combination of zero-configuration networking («ZeroConf»), multicast DNS (mDNS), and DNS service discovery (DNS-SD) standards published by the Internet Engineering Task Force (IETF), the same group that defined TCP/IP and all of the networking we use today.

A printer that supports Bonjour can be found automatically using the dnssd backend. Run the lpinfo(8) command to find your printer’s URI:

You can then add a printer using the URI reported.

Manual Configuration Using IP Addresses

You can also manually configure a printer using its Internet Protocol v4 (IPv4) address. This address is either configured manually («static IP») through the printer’s control panel or set using an automatic network protocol such as the Dynamic Host Control Protocol (DHCP) or ZeroConf.

Note: Configuring a printer using an IP address set using DHCP or ZeroConf is not recommended since the address will change every time the printer is turned on or after long periods of inactivity. Thus, every time the address changes you will need to modify the print queue using the lpadmin command.

Finding the IP Address

You can normally find the IP address of a printer on the printer’s control panel or by printing the configuration or status page. The Simple Network Management Protocol (SNMP) can also be used to get the IP address remotely. To test that the IP address has been successfully assigned and that the printer is properly connected to your LAN or Wi-Fi network, type:

where «ip-address» is the address reported by the printer’s control panel, configuration page, and/or status page. If the connection is working properly you will see something like:

If the connection is not working properly you will see something like:

Press CTRL+C to quit the ping command.

Note: If the command does not show responses from the printer, verify that the printer or print server is powered on and connected to the same LAN or Wi-Fi network as your computer. For LAN connections, also verify that your network cabling is good.

Choosing a Network Protocol (Backend)

CUPS supports most network printers using one of three TCP/IP-based protocols: AppSocket, Internet Printing Protocol, and Line Printer Daemon. The following sections describe the options for each of the backends.

AppSocket Protocol (aka JetDirect)

The AppSocket protocol (sometimes also called the JetDirect protocol, owing to its origins with the HP JetDirect network interfaces) is the simplest and fastest network protocol used for printers. AppSocket printing normally happens over port 9100 and uses the socket backend. Device URIs for the socket backend look like this:

The «contimeout» option controls the number of seconds that the backend will wait to obtain a connection to the printer. The default is 1 week or 604800 seconds.

The «waiteof» option controls whether the socket backend waits for the printer to complete the printing of the job. The default is to wait ( waiteof=true ). Add waiteof=false to the URI to tell the backend not to wait.

Note: While the AppSocket protocol is simple and fast, it also offers no security and is often an attack vector with printers. Consider using the Internet Printing Protocol which supports encryption and other security features.

Internet Printing Protocol (IPP)

IPP is the only protocol that CUPS supports natively and is supported by most network printers and print servers. IPP supports encryption and other security features over port 631 and uses the http (Windows), ipp , and ipps backends. Device URIs for these backends look like this:

The backends supports many options, which are summarized in Table 2. Like all backends, options are added to the end of the URI using the URL form encoding format, for example:

Table 2: IPP URI Options

Option	Description
contimeout= seconds	Specifies the number of seconds to wait for the connection to the printer to complete (default 1 week or 604800 seconds).
encryption=always	Specifies that the connection to the IPP printer should be encrypted using SSL.
encryption=ifrequested	Specifies that the connection to the IPP printer should only be encrypted if the printer requests it.
encryption=never	Specifies that the connection to the IPP printer should not be encrypted.
encryption=required	Specifies that the connection to the IPP printer should be encrypted using TLS.
version=1.0	Specifies that version 1.0 of the IPP protocol should be used instead of the default version 2.0.
version=1.1	Specifies that version 1.1 of the IPP protocol should be used instead of the default version 2.0.
version=2.1	Specifies that version 2.1 of the IPP protocol should be used instead of the default version 2.0.
waitjob=false	Specifies that the IPP backend should not wait for the job to complete.
waitprinter=false	Specifies that the IPP backend should not wait for the printer to become idle before sending the print job.

Line Printer Daemon (LPD) Protocol (aka lpr)

LPD is the original network printing protocol created for the Berkeley UNIX line printer daemon (spooler) and is supported by many network printers. LPD printing normally happens over port 515 and uses the lpd backend. Device URIsfor the lpd backend look like this:

Table 3 summarizes the options supported by the lpd backend.

Note: Due to limitations in the LPD protocol, we do not recommend using it if the printer or server supports any of the other protocols. Like AppSocket, LPD offers no security and is a common attack vector. LPD also, by default, requires that the computer save a copy of the entire print job before sending it to the printer — this can result in gigabytes of print data being saved to disk before any printing happens, delaying print jobs and shortening the life of your mass storage device!

Table 3: LPD URI Options

Option	Description
banner=on	Specifies that a banner page should be printed by the printer.
contimeout= seconds	Specifies the number of seconds to wait for the connection to the printer to complete (default 1 week or 604800 seconds).
format=f	Specifies that the print data is a plain text file.
format=o	Specifies that the print data is a PostScript file.
format=p	Specifies that the print data is a plain text file that should be «pretty» printed with a header and footer.
mode=stream	Specifies that the backend should stream print data to the printer and not wait for confirmation that the job has been successfully printed.
order=data,control	Specifies that the print data files should be sent before the control file.
reserve=none	Specifies that the backend should not reserve a source port.
reserve=rfc1179	Specifies that the backend should reserve a source port from 721 to 731 as required by RFC 1179.
sanitize_title=no	Specifies that the job title string should not be restricted to ASCII alphanumeric and space characters.
sanitize_title=yes	Specifies that the job title string should be restricted to ASCII alphanumeric and space characters.
timeout= seconds	Specifies the number of seconds to wait for LPD commands to complete (default 5 minutes or 300 seconds).

Finding Printers Using SNMP

Whenever you view the administration web page or a list of supported device URIs, the snmp backend can probe the local network(s) using Simple Network Management Protocol (SNMP) v1 broadcasts. Printers that respond to these broadcasts are then interrogated for the make, model, and supported protocols, yielding a device URI that can be used to add the printer.

The /etc/cups/snmp.conf file configures the snmp backend. Add the following line to enable discovery using the snmp backend:

If you don’t use «public» as your community name, change the Community line as well:

Note: The snmp backend will not be able to find any printers on your network if SNMP v1 or broadcasting are disabled on your network. Also, broadcasts are typically limited to the local subnet, so printers on different networks cannot be discovered using SNMP.

Troubleshooting SNMP Problems

The snmp backend sometimes exposes problems in vendor implementations. If you are experiencing long delays in loading the CUPS web interface administration page, or if you don’t see your printer listed, the following instructions will help you to diagnose those problems and/or provide important feedback to the CUPS developers so that we can correct problems and improve the snmp backend in future releases.

The SNMP backend supports a debugging mode that is activated by running it from a shell prompt. Run the following command to get a verbose log of the snmp backend:

On macOS you’ll find the backend in /usr/libexec/cups/backend instead:

The output will look something like this:

The first two lines are just informational and let you know that the default community name and address are being used. Lines 3-15 contain the initial SNMP query for the device type OID (.1.3.6.1.2.1.25.3.2.1.2.1) from the Host MIB.

Lines 16-31 show the response we got from an HP LaserJet 4000 network printer. At this point we discover that it is a printer device and then send another SNMP query (lines 32-43) for the device description OID (.1.3.6.1.2.1.25.3.2.1.3.1) from the Host MIB as well.

Lines 44-58 show the response to the device description query, which tells us that this is an HP LaserJet 4000 Series printer.

On line 59 we start our active connection probe and discover that this print server supports the AppSocket (JetDirect) protocol on port 9100.

Finally, line 63 shows the device information line for the print server that is sent to CUPS.

If you don’t see your printer listed, or the wrong information is listed, then you need to gather more information on the printer. The easiest way to do this is to run the snmpwalk command:

where «ip-address» is the IP address of the printer or print server. You should see a lot of values stream by — the ones you want to see are:

The hrDeviceType line should show hrDevicePrinter; if not, then your printer or print server doesn’t identify itself as a printer. The hrDeviceDescr line should provide a human-readable string for the make and model of the printer, although in some cases you’ll just see something less useful like «Axis OfficeBASIC Parallel Print Server».

Once you have collected the snmpwalk output, you should go to the CUPS Issue Tracker page to submit a feature request to support your printer or print server. Be sure to attach those two log files you created — they will help us to identify the SNMP values we need to look for.

Источник