CUPS Software Administrators Manual
CUPS-SAM-1.1.23
Easy Software Products
Copyright 1997-2005, All Rights Reserved
This software administrators manual provides printer administration information for the Common UNIX Printing SystemTM ("CUPS TM"), version 1.1.23.
CUPS provides a portable printing layer for UNIX®-based operating systems. It has been developed by Easy Software Products to promote a standard printing solution for all UNIX vendors and users. CUPS provides the System V and Berkeley command-line interfaces.
CUPS uses the Internet Printing Protocol ("IPP") as the basis for managing print jobs and queues. The Line Printer Daemon ("LPD") Server Message Block ("SMB"), and AppSocket (a.k.a. JetDirect) protocols are also supported with reduced functionality. CUPS adds network printer browsing and PostScript Printer Description ("PPD") based printing options to support real-world printing under UNIX.
CUPS includes an image file RIP that supports printing of image files to non-PostScript printers. A customized version of GNU Ghostscript 7.05 for CUPS called ESP Ghostscript is available separately to support printing of PostScript files within the CUPS driver framework. Sample drivers for Dymo, EPSON, HP, and OKIDATA printers are included that use these filters.
Drivers for thousands of printers are provided with our ESP Print Pro software, available at:
http://www.easysw.com/printpro/
CUPS is licensed under the GNU General Public License and GNU Library General Public License. Please contact Easy Software Products for commercial support and "binary distribution" rights.
This software administrators manual is organized into the following sections:
Various font and syntax conventions are used in this guide. Examples and their meanings and uses are explained below:
| Example | Description | |
|---|---|---|
lpstat
lpstat(1) | The names of commands; the first mention of a command or function in a chapter is followed by a manual page section number. | |
| /var
/usr/share/cups/data/testprint.ps | File and directory names. | |
| Request ID is Printer-123 | Screen output. | |
| lp -d printer filename ENTER | Literal user input; special keys like ENTER are in ALL CAPS. | |
| 12.3 | Numbers in the text are written using the period (.) to indicate the decimal point. |
This chapter provides an overview of how the Common UNIX Printing System works.
For years the printing problem has plagued UNIX. Unlike Microsoft® Windows® or Mac OS, UNIX has no standard interface or system in place for supporting printers. Among the solutions currently available, the Berkeley and System V printing systems are the most prevalent.
These printing systems support line printers (text only) or PostScript printers (text and graphics), and with some coaxing they can be made to support a full range of printers and file formats. However, because each varient of the UNIX operating system uses a different printing system than the next developing printer drivers for a wide range of printers and operating systems is extremely difficult. That combined with the limited volume of customers for each UNIX varient has forced most printer vendors to give up supporting UNIX entirely.
CUPS is designed to eliminate the printing problem. One common printing system can be used by all UNIX varients to support the printing needs of users. Printer vendors can use its modular filter interface to develop a single driver program that supports a wide range of file formats with little or no effort. Since CUPS provides both the System V and Berkeley printing commands, users (and applications) can reap the benefits of this new technology with no changes.
CUPS is based upon an emerging Internet standard called the Internet Printing Protocol. IPP has been embraced by dozens of printer and printer server manufacturers and is supported by Microsoft Windows 2000.
IPP defines a standard protocol for printing as well as managing print jobs and printer options like media size, resolution, and so forth. Like all IP-based protocols, IPP can be used locally or over the Internet to printers hundreds or thousands of miles away. Unlike other protocols, however, IPP also supports access control, authentication, and encryption, making it a much more capable and secure printing solution than older ones.
IPP is layered on top of the Hyper-Text Transport Protocol ("HTTP") which is the basis of web servers on the Internet. This allows users to view documentation, check status information on a printer or server, and manage their printers, classes, and jobs using their web browser.
CUPS provides a complete IPP/1.1 based printing system that provides Basic, Digest, and local certificate authentication and user, domain, or IP-based access control. TLS encryption will be available in future versions of CUPS.
Each file or set of files that is submitted for printing is called a job. Jobs are identified by a unique number starting at 1 and are assigned to a particular destination, usually a printer. Jobs can also have options associated with them such as media size, number of copies, and priority.
CUPS supports collections of printers known as classes. Jobs sent to a class are forwarded to the first available printer in the class.
Filters allow a user or application to print many types of files without extra effort. Print jobs sent to a CUPS server are filtered before sending them to a printer. Some filters convert job files to different formats that the printer can understand. Others perform page selection and ordering tasks.
CUPS provides filters for printing many types of image files, HP-GL/2 files, PDF files, and text files. CUPS also supplies PostScript and image file Raster Image Processor ("RIP") filters that convert PostScript or image files into bitmaps that can be sent to a raster printer.
Backends perform the most important task of all - they send the filtered print data to the printer.
CUPS provides backends for printing over parallel, serial, and USB ports, and over the network via the IPP, JetDirect (AppSocket), and Line Printer Daemon ("LPD") protocols. Additional backends are available in network service packages such as the SMB backend included with the popular SAMBA software.
Backends are also used to determine the available devices. On startup each backend is asked for a list of devices it supports, and any information that is available. This allows the parallel backend to tell CUPS that an EPSON Stylus Color 600 printer is attached to parallel port 1, for example.
Printer drivers in CUPS consist of one of more filters specific to a printer. CUPS includes sample printer drivers for Hewlett-Packard LaserJet and DeskJet printers and EPSON 9-pin, 24-pin, Stylus Color, and Stylus Photo printers. While these drivers do not generate optimal output for the different printer models, they do provide basic printing and demonstrate how you can write your own printer drivers and incorporate them into CUPS.
Printers and classes on the local system are automatically shared with other systems on the network. This allows you to setup one system to print to a printer and use this system as a printer server or spool host for all of the others. Users may then select a local printer by name or a remote printer using "name@server".
CUPS also provides implicit classes, which are collections of printers and/or classes with the same name. This allows you to setup multiple servers pointing to the same physical network printer, for example, so that you aren't relying on a single system for printing. Because this also works with printer classes, you can setup multiple servers and printers and never worry about a single point of failure unless all of the printers and servers go down!
This chapter shows how to build and install the Common UNIX Printing System. If you are installing a binary distribution from the CUPS web site, proceed to the section titled, Installing a Binary Distribution.
This section describes how to compile and install CUPS on your system from the source code.
You'll need ANSI-compliant C and C++ compilers to build CUPS on your system. As its name implies, CUPS is designed to run on the UNIX operating system, however the CUPS interface library and most of the filters and backends supplied with CUPS should also compile and run under Microsoft Windows.
For the image file filters and PostScript RIP, you'll need the JPEG, PNG, TIFF, and ZLIB libraries. CUPS will build without these, but with significantly reduced functionality. Easy Software Products maintains a mirror of the current versions of these libraries at:
ftp://ftp.easysw.com/pub/libraries
If you make changes to the man pages you'll need GNU groff or another nroff-like package. GNU groff is available from:
ftp://ftp.gnu.org/pub/groff
The documentation is formatted using the HTMLDOC software. If you need to make changes you can get the HTMLDOC software from:
http://www.easysw.com/htmldoc
Finally, you'll need a make program that understands the
include directive - FreeBSD, NetBSD, and OpenBSD
developers should use the gmake program.
CUPS uses GNU autoconf to configure the makefiles and source code for your system. Type the following command to configure CUPS for your system:
./configure ENTER
The default installation will put the CUPS software in the /etc
, /usr, and /var directories on your system, which
will overwrite any existing printing commands on your system. Use the
--prefix option to install the CUPS software in another location:
./configure --prefix=/some/directory ENTER
If the PNG, JPEG, TIFF, and ZLIB libraries are not installed in a
system default location (typically /usr/include and
/usr/lib) you'll need to set the CFLAGS,
CXXFLAGS, and LDFLAGS environment variables prior to
running configure:
setenv CFLAGS "-I/some/directory" ENTER setenv CXXFLAGS "-I/some/directory" ENTER setenv LDFLAGS "-L/some/directory" ENTER setenv DSOFLAGS "-L/some/directory" ENTER ./configure ... ENTER
or:
CFLAGS="-I/some/directory"; export CFLAGS ENTER CXXFLAGS="-I/some/directory"; export CXXFLAGS ENTER LDFLAGS="-L/some/directory"; export LDFLAGS ENTER DSOFLAGS="-L/some/directory"; export DSOFLAGS ENTER ./configure ... ENTER
To enable support for encryption, you'll also want to add the "--enable-ssl" option:
./configure --enable-ssl
SSL and TLS support require the OpenSSL library, available at:
http://www.openssl.org
If the OpenSSL headers and libraries are not installed in the
standard directories, use the --with-openssl-includes and
--with-openssl-libs options:
./configure --enable-ssl \
--with-openssl-includes=/foo/bar/include \
--with-openssl-libs=/foo/bar/lib
Once you have configured things, just type:
make ENTER
to build the software.
Use the "install" target to install the software:
make install ENTER
| WARNING:
Installing CUPS will overwrite your existing printing system. If you experience difficulties with the CUPS software and need to go back to your old printing system, you will need to reinstall the old printing system from your operating system CDs. |
Once you have installed the software you can start the CUPS server by typing:
/usr/sbin/cupsd ENTER
CUPS comes in a variety of binary distribution formats. Easy Software Products provides binaries in TAR format with installation and removal scripts ("portable" distributions), and in RPM and DPKG formats for Red Hat and Debian-based distributions. Portable distributions are available for all platforms, while the RPM and DPKG distributions are only available for Linux.
| WARNING:
Installing CUPS will overwrite your existing printing system. If you experience difficulties with the CUPS software and need to go back to your old printing system, you will need to remove the CUPS software with the provided script and/or reinstall the old printing system from your operating system CDs. |
To install the CUPS software from a portable distribution you will
need to be logged in as root; doing an su is good enough.
Once you are the root user, run the installation script with:
./cups.install ENTER
After asking you a few yes/no questions the CUPS software will be installed and the scheduler will be started automatically.
To install the CUPS software from an RPM distribution you will need
to be logged in as root; doing an su is good enough. Once
you are the root user, run RPM with:
rpm -e lpr rpm -i cups-1.1-linux-M.m.n-intel.rpm ENTER
After a short delay the CUPS software will be installed and the scheduler will be started automatically.
To install the CUPS software from a Debian distribution you will need
to be logged in as root; doing an su is good enough. Once
you are the root user, run dpkg with:
dpkg -i cups-1.1-linux-M.m.n-intel.deb ENTER
After a short delay the CUPS software will be installed and the scheduler will be started automatically.
This chapter describes how to add your first printer and how to manage your printers.
Each printer queue has a name associated with it; the printer name must start with any printable character except " ", "/", and "@". It can contain up to 127 letters, numbers, and the underscore (_). Case is not significant, e.g. "PRINTER", "Printer", and "printer" are considered to be the same name.
Printer queues also have a device associated with them. The device
can be a parallel port, a network interface, and so forth. Devices
within CUPS use Uniform Resource Identifiers ("URIs") which are a more
general form of Uniform Resource Locators ("URLs") that are used in
your web browser. For example, the first parallel port in Linux usually
uses a device URI of parallel:/dev/lp1.
You can see a complete list of supported devices by running the
lpinfo(8) command:
lpinfo -v ENTER network socket network http network ipp network lpd direct parallel:/dev/lp1 serial serial:/dev/ttyS1?baud=115200 serial serial:/dev/ttyS2?baud=115200 direct usb:/dev/usb/lp0 network smb
The -v option specifies that you want a list of
available devices. The first word in each line is the type of device
(direct, file, network, or serial) and is followed by the device URI or
method name for that device. File devices have device URIs of the form
file:/directory/filename while network devices use the more
familiar method://server or method://server/path
format.
Finally, printer queues usually have a PostScript Printer Description ("PPD") file associated with them. PPD files describe the capabilities of each printer, the page sizes supported, etc., and are used for PostScript and non-PostScript printers. CUPS includes PPD files for HP LaserJet, HP DeskJet, EPSON 9-pin, EPSON 24-pin, and EPSON Stylus printers.
CUPS provides two methods for adding printers: a command-line program
called lpadmin(8) and a Web interface. The lpadmin
command allows you to perform most printer administration tasks from
the command-line and is located in /usr/sbin. The Web
interface is located at:
http://localhost:631/admin
and steps you through printer configuration. If you don't like command-line interfaces, try the Web interface instead.
Run the lpadmin command with the -p option
to add a printer to CUPS:
/usr/sbin/lpadmin -p printer -E -v device -m ppd ENTER
For a HP DeskJet printer connected to the parallel port this would look like:
/usr/sbin/lpadmin -p DeskJet -E -v parallel:/dev/lp1 -m deskjet.ppd ENTER
Similarly, a HP LaserJet printer using a JetDirect network interface at IP address 11.22.33.44 would be added with the command:
/usr/sbin/lpadmin -p LaserJet -E -v socket://11.22.33.44 -m laserjet.ppd ENTER
As you can see, deskjet.ppd and laserjet.ppd
are the PPD files for the HP DeskJet and HP LaserJet drivers included
with CUPS. You'll find a complete list of PPD files and the printers
they will work with in Appendix C, "Printer
Drivers".
For a dot matrix printer connected to the serial port, this might look like:
/usr/sbin/lpadmin -p DotMatrix -E -m epson9.ppd \
-v serial:/dev/ttyS0?baud=9600+size=8+parity=none+flow=soft ENTER
Here you specify the serial port (e.g. S0,S1, d0, d1), baud rate (e.g. 9600, 19200, 38400, 115200, etc.), number of bits, parity, and flow control. If you do not need flow control, delete the "+flow=soft" portion.
The CUPS web server provides a user-friendly "wizard" interface for adding your printers. Rather than figuring out which device URI and PPD file to use, you can instead click on the appropriate listings and fill in some simple information. Enter the following URL in your web browser to begin:
http://localhost:631/admin
Click on the Add Printer button to add a printer.
The lpadmin command enables you to perform most printer
administration tasks from the command-line. You'll find lpadmin
in the /usr/sbin directory.
Run the lpadmin command with the -p option
to add or modify a printer:
/usr/sbin/lpadmin -p printer options ENTER
The options arguments can be any of the following:
lpinfo command with the -m option.
A list of printer drivers included with CUPS can be found in
Appendix C, "Printer Drivers".enable(1) and accept(8) commands
on the printer.Run the lpadmin command with the -x option
to delete a printer:
/usr/sbin/lpadmin -x printer ENTER
Run the lpadmin command with the -d option
to set a default printer:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends print jobs to another machine for final printing. Clients can also be servers if they communicate directly with any printers of their own.
CUPS supports several methods of configuring client machines:
The most tedious method of configuring client machines is to
configure each remote queue by hand using the lpadmin
command:
lpadmin -p printer -E -v ipp://server/printers/printer ENTER
The printer name is the name of the printer on the
server machine. The server name is the hostname or IP
address of the server machine. Repeat the lpadmin command
for each remote printer you wish to use.
| NOTE:
Manual configuration of print queues is not recommended for large numbers of client machines because of the administration nightmare it creates. For busy networks, consider subnetting groups of clients and polling and relaying printer information instead. |
CUPS can be configured to run without a local spooler and send all jobs to a single server. However, if that server goes down then all printing will be disabled. Use this configuration only as absolutely needed.
The default server is normally "localhost". To override the default server create a file named /etc/cups/client.conf and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
The default server can also be customized on a per-user basis. To set a user-specific server create a file named ~/.cupsrc and add a line reading:
ServerName server
to the file. The server name can be the hostname or IP address of the default server.
CUPS supports automatic client configuration of printers on the same subnet. To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.
If you want to see printers on other subnets as well, use the
BrowsePoll directive as described next.
| NOTE:
The Use the |
If you have CUPS servers on different subnets, then you should configure CUPS to poll those servers. Polling provides the benefits of automatic configuration without significant configuration on the clients, and multiple clients on the same subnet can share the same configuration information.
Polling is enabled by specifying one or more
BrowsePoll directives in the /etc/cups/cupsd.conf
file. For information on making these changes, see
Chapter 6, "Printing System Management".
Multiple BrowsePoll lines can
be used to poll multiple CUPS servers. To limit the amount of polling
you do from client machines, you can have only one of the clients do
the polling and relay that information to the others on the same subnet
(described next).
When you have clients and servers spread across multiple subnets, the
polling method is inefficient. CUPS provides a
BrowseRelay directive that enables a single client to relay
(broadcast) the polled printer information to the local subnet.
For example, Server A and Server B are on subnet 1 and subnet 2, while the clients are on subnet 3. To provide printers to all of the clients in subnet 3, client C will be configured with the following directives in /etc/cups/cupsd.conf:
# Poll the two servers BrowsePoll ServerA BrowsePoll ServerB # Relay the printers to the local subnet BrowseRelay 127.0.0.1 192.168.3.255
The BrowseRelay line
specifies a source address and mask. Any browse packets coming from a
matching address wil be sent to the given broadcast address. In this
case, we want the packets from the local machine (127.0.0.1) relayed to
the other clients.
As printers are found using polling, they are relayed from client C to the rest of the clients through a broadcast on subnet 3. The rest of the clients can use the standard cupsd.conf configuration.
The BrowseRelay directive can
also be used to relay browsing packets from one network interface to
another. For example, if client C in the previous example had network
interfaces attaches to both subnet 1 and subnet 2, it could use the
BrowseRelay directive exclusively:
# Relay the printers from subnet 1 and 2 to subnet 3 BrowseRelay 192.168.1 192.168.3.255 BrowseRelay 192.168.2 192.168.3.255
When using server polling or broadcasting, CUPS clients can automatically merge identical printers on multiple servers into a single implicit class queue. Clients assume that printers with the same name on multiple servers are in fact the same printer or type of printer being served by multiple machines.
If you have two printers, LaserJet@ServerA and LaserJet@ServerB, a
third implicit class called LaserJet will be created
automatically on the client that refers to both printers. If the client
also has a local printer with the name LaserJet and the
ImplicitAnyClasses directive is enabled, then an
implicit class named AnyLaserJet will be created instead.
Otherwise, the local printer will prevent the creation of an implicit
class, since CUPS will assume that the local printer will always be
more available than a remote one.
The client will alternate between servers and automatically stop sending jobs to a server if it goes down, providing a load-balancing effect and fail-safe operation with automatic switchover.
| NOTE:
Note that implicit classes ( |
This chapter shows how you can configure the CUPS server.
Several text files are used to configure CUPS. All of the server configuration files are located in the /etc/cups directory:
/usr/sbin/lpadmin -d printer ENTER
The default printer can be overridden by the user using the
lpoptions(1) command.
The enable and disable commands start and
stop printer queues, respectively:
/usr/bin/enable printer ENTER /usr/bin/disable printer ENTER
Printers that are disabled may still accept jobs for printing, but won't actually print any files until they are restarted. This is useful if the printer malfunctions and you need time to correct the problem. Any queued jobs are printed after the printer is enabled (started).
The accept and reject commands accept and
reject print jobs for the named printer, respectively:
/usr/sbin/accept printer ENTER /usr/sbin/reject printer ENTER
As noted above, a printer can be stopped but accepting new print jobs. A printer can also be rejecting new print jobs while it finishes those that have been queued. This is useful for when you must perform maintenance on the printer and will not have it available to users for a long period of time.
CUPS supports page and size-based quotas for each printer. The quotas are tracked individually for each user, but a single set of limits applies to all users for a partiuclar printer. For example, you can limit every user to 5 pages per day on an expensive printer, but you cannot limit every user except Johnny.
The job-k-limit, job-page-limit, and job-quota-peiod options determine whether and how quotas are enforced for a printer. The job-quota-period option determines the time interval for quota tracking. The interval is expressed in seconds, so a day is 86,400, a week is 604,800 and a month is 2,592,000 seconds. The job-k-limit option specifies the job size limit in killobytes. The job-page-limit option specifies the number of pages limit.
For quotas to be enforced, the period and at least one of the limits must be set to a non-zero value. The following options will enable quotas:
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-k-limit=1024 ENTER
/usr/sbin/lpadmin -p printer -o job-quota-period=604800 \
-o job-page-limit=100 ENTER
Or, you can combine all three options on the same line.
The -u option of the lpadmin command
controls which users can print to a printer. The default configuration
allows all users to print to a printer:
/usr/sbin/lpadmin -p printer -u allow:all ENTER
CUPS supports allow and deny lists so that you can specify a list of users who are allowed to print or not allowed to print. Along with your list of users, you can specify whether they are allowed or not allowed to use the printer:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary ENTER
This command allows peter, paul, and mary to print to the named printer, but all other users cannot print. The command:
/usr/sbin/lpadmin -p printer -u deny:peter,paul,mary ENTER
has the opposite effect. All users except peter, paul, and mary will be able to print to the named printer.
You can control access by UNIX groups as well by placing an "@" character before each group name. The command:
/usr/sbin/lpadmin -p printer -u allow:peter,paul,mary,@printgods ENTER
allows the users peter, paul, and mary to print, as well as any user in the printgods group to print.
| NOTE:
The allow and deny options are not cummulative. That is, you must provide the complete list of users to allow or deny each time. Also, CUPS only maintains one list of users - the list can allow or deny users from printing. If you specify an allow list and then specify a deny list, the deny list will replace the allow list - only one list is active at any time. |
The Web interface is located at:
http://localhost:631/admin
From there you can perform all printer management tasks with a few simple mouse clicks.
This chapter describes what printer classes are and how to manage them.
CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. Classes can themselves be members of other classes, so it is possible for you to define very large, distributed printer classes for high-availability printing.
CUPS also supports implicit classes. Implicit classes work just like printer classes, but they are created automatically based upon the available printers and classes on the network. This allows you to setup multiple print servers with identical printer configurations and have the client machines send their print jobs to the first available server. If one or more servers go down, the jobs are automatically redirected to the servers that are running, providing fail-safe printing.
Run the lpadmin command with the -p and
-c options to add a printer to a class:
/usr/sbin/lpadmin -p printer -c class ENTER
The class is created automatically if it doesn't exist. To
remove a printer from a class use the -r option:
/usr/sbin/lpadmin -p printer -r class ENTER
To remove the entire class just use the -x option:
/usr/sbin/lpadmin -x class ENTER
The Web interface is located at:
http://localhost:631/admin
The Add Class and Modify Class interfaces provide a list of available printers; click on the printers of interest to add them to the class.
A noted earlier, implicit classes are created automatically from the
available network printers and classes. To disable this functionality,
set the ImplicitClasses
directive to Off in the cupsd.conf file. You
will find more information on doing this in
Chapter 6, "Printing System Management".
This chapter discusses several ways to configure CUPS clients for printing.
A client is any machine that sends