Using a more restrictive configuration you can get rid of long printer lists in your printing frontends so that you only see the printers you really need.
Possible locations are:. The locations behave like a directory hierarchy, if a sublocation does not exist, the access rules of the parent location apply. Print queue manipulation is even only allowed from the local machine.
So the admin must trust the users at the machines to which he exports printers or not allow them to be root on the client. Replacing a client by a machine with faked MAC address is still possible. The "ipp" backend cannot be simply removed, as it is needed for a CUPS client to talk to a CUPS server when printing through a queue broadcasted by the server.
Access cannot only be restricted per-network or per-machine but also per-user. For user-wise access restrictions the " AuthType " and " AuthClass " rules are used. This means that in this case " AuthType Digest " has to be used and passwords have to be defined with " lppasswd ". It can also be " User ", to give all Unix or Digest users on the server access or " Group " to give access to the users in the group specified by the " AuthGroupName " rule.
But queue manipulation can only be done by the members of the Unix System group, usually this is only "root". Therefore you need to log in as "root" in the web interface to set up queues. In CUPS it is also easy to set up high availability by having redundant printers or servers. You define a queue with the same configuration to each of these printers, for example with the names "laser1", "laser2", and "laser3".
Now you set up a so-called printer class. This is a queue which does not point to a printer, but to a set of other queues. In this case you let it point to outr three queues "laser1", "laser2", and "laser3".
Let us call the class "laser". If a user would send a job to "laser2" the job has to wait until all other jobs on "laser2" are ready and "laser2" must be ready to print turned on, paper and toner loaded. Otherwise the user's job waits in the queue, even if "laser1" and "laser3" are doing nothing. If the user sends the job to the class "laser".
The first printer which gets free will take the job. So if "laser1" is printing a page job and "laser2" is out of paper, the user's one-page letter goes to "laser3" and so it comes out quickly. The problem would be if the server fails. Then none of the printers is available and the users cannot print. So we connect each printer to another computer, which means that if one of the computers fails, the other two printers are still available.
But there is one problem: On which server do we define the class "laser"? If this server fails, the printers are all not available again. The solution is a so called "implicit class", a class automatically defined by CUPS.
Therefore we do not call the three queues on the three servers "laser1", "laser2", and "laser3". It is much simpler, we call them all "laser" and let them get broadcasted into our network. Now the clients receive broadcasts of three equally-named queues. For the users of the clients only one queue named "laser" appears. And this queue behaves as a class: the first of the three printers which gets free takes the job.
Also there is no single point of failure which defines the class "laser". If you have an ethernet-connected printer you could define a queue for it on every client, so the clients are their own CUPS servers and do not depend on a single server. But imagine the number of print queues you see in graphical printing frontends when every queue has another name, and that in a network with only one printer. And imagine also the administration nightmare when the IP of the printer has to be changed.
So here you better choose three machines and define equally-named queues pointing to this one printer. You get an implicit class which will be the only one visible queue on the CUPS clients. And you do not need to rely on one server, you can print if at least one of the three is running. Also combinations of this are possible: For example two servers and three ethernet printers, where on each of the two servers is exactly the same CUPS configuration: Three queues pointing to the three printers and a class putting together the three queues.
The two classes on the two servers form an implicit class and so printing into this implicit class works with any arbitrary pair of server and printer. The system is based on the CUPS filters. They simply analyse the PostScript data stream to determine the number of pages. And there fore it depends on the quality of the PostScript generated by the applications whether the pages get correctly counted. And if there is a paper jam, pages are already counted and do not get printed.
Also Jobs which get rendered printer-ready on the client Windows will not get accounted correctly, as CUPS does not understand the proprietary language of the printer. In addition, one can restrict the amount of pages or kBytes which a user is allowed to print in a certain time frame.
Such restrictions can be applied to the print queues with the " lpadmin " command. The second command restricts printing on "printer2" to pages per week. One can also give both " job-k-limit " and " job-page-limit " to one queue. Then both limits apply so the printer rejects jobs when the user already reaches one of the limits, either the 1 MByte or the pages. This is a very simple quota system: Quotas cannot be given per-user, so a certain user's quota cannot be raised independent of the other users, for example if the user pays his pages or gets a more printing-intensive job.
Also counting of the pages is not very sophisticated as it was already shown above. So for more sophisticated accounting it is recommended to use add-on software which is specialized for this job. This software can limit printing per-user, can create bills for the users, use hardware page counting methods of laser printers, and even estimate the actual amount of toner or ink needed for a page sent to the printer by counting the pixels.
The most well-known and complete free software package for print accounting and quotas id PyKota:. A simple system based on reading out the hardware counter of network printers via SNMP is accsnmp:. For inetd add the line. So every user and every machine can print via LPD on your server. At first check whether the needed Samba server packages are installed and that your Samba version is linked against the CUPS library should be the case in most modern Linux distributions.
If " libcups " is listed as shown in this example, your Samba is OK. You also need to take care that the names of all your printers are not longer than 12 characters. CUPS has no on-board tool to rename print queues, but some other printer setup tools, like " printerdrake " in Mandriva Linux, have. All lines not supposed to be modified are not shown. Do not touch that lines, otherwise you could loose other Samba services, like file sharing or so.
If some of the directories referred to in the lines shown above does not exist, create it. Let the ownerships of these directories be root and the ntadmins group. Set permissions for everyone to read and execute and for user and group to write into the directories. Create Samba accounts for "root" and every user in the "ntadmins" group with " smbpasswd ":. Therefore Samba needs its own passwords. Use always the Samba passwords for authentication against Samba. Most important in the smb. This means they will all be detected in the network Neighborhood or in the Add Printer Wizard under Windows.
To really print with these printers under Windows one can use the Windows drivers which came with the printers and set up queues with them on each client. This approach of printing has the disadvantage that once many different printer drivers are on each Windows client and this can compromise the stability of Windows. Another problem is that CUPS does not understand the job data which passes through it and so it cannot count the printed pages. This prevents print accounting from working correctly.
The better way is to let our server emulate PostScript printers, as it does for Unix applications. This way every Windows client has only one printer driver installed and CUPS gets data on which it can do accounting and other types of processing.
Home Subscribe Search Twitter. General Networking. Till Kamppeter, linuxprinting. Connecting your printer Connect your printer to the parallel port or USB. You should get something like Your distribution's printer setup tool First, try to go the way your distribution does. To use the web interface, you must give a digest password to root at first, using the command "lppasswd": lppasswd -a -g sys root and enter a password not necessarily the normal root password.
PPDs for PostScript printers PostScript is a platform-independent page description language which is used by many mid-range and high-end laser printers and even by some high-end inkjets. There are different types of drivers: GhostScript built-in This driver concept is the oldest one.
IJS plug-in Like filters IJS plug-ins are also separate executables and so they also do not require GhostScript to be patched and recompiled to add support for a new printer. Uniprint This method is not common any more. When accessed for the first time, all are set to Printer Default , which means no printer language commands will be sent from the driver to affect the printers existing settings. Please provide additional comments. Thank you for your feedback! Don't see what you're looking for?
Ask the Community. Submit a Case. Copyright Privacy Policy Terms of service. Establishing connection, please wait while we connect you. Start Chatting. Thanks for chatting with us. Ask me anything. Managing Services Overview. Managing Services Tasks. Using the Fault Manager. Managing System Information Tasks. Managing System Processes Tasks. Monitoring System Performance Tasks. Managing Software Packages Tasks.
Managing Disk Use Tasks. Scheduling System Tasks Tasks. How to Modify the Properties of a Configured Printer. Managing System Crash Information Tasks.
Managing Core Files Tasks. Troubleshooting System and Software Problems Tasks. This section provides a brief description of the CUPS commands and describes how to set up and administer your printers. CUPS provides various commands to set up printers and make those printers accessible to systems on the network. In addition, CUPS supports several printer-specific options that enable you to control printer configuration.
The following table lists frequently used CUPS commands. Consult the printer vendor's installation documentation for information about hardware switches and cabling requirements. Only the most commonly used options of the CUPS lpadmin command are shown here.
For information about other options, see the lpadmin 8 man page. Sets the PPD file for the printer from the model directory or by using one of the driver interfaces. To add a dot matrix printer that is connected to the serial port, you would type the following command:.
Specify the serial port, baud rate, number of bits, parity, and flow control. For instructions on setting up a default printer by specifying the environment variables, see How to Set a Default Printer at the Command Line.
Use this command to display or set printer options and defaults.
0コメント