Setting up from scratch CUPS print server with and without domain authorization on a network with different operating systems

So. Presumably, the CUPS printing service is a powerful solution that allows you to organize centralized management of printers in the company. This is true, but during the setup process, you will need to spend some time in search of a solution to Google of many small, unobvious problems, especially if your need goes beyond the standard configuration guides.

The article will describe the installation of a CUPS print server on a Ubuntu Server on a network with a working Active Directory domain, although its presence is completely optional and instructions for setting up interaction with it can be safely skipped, setting it up, and setting up Linux and Windows clients to interact with this print server.


In the instructions, the domain will be named example.com , the printserver itself is cupsserver ( cupsserver.example.com ) with the IP address 10.10.100.50, and the linux1 , linux2 , linux3 , etc. client machines for Linux and windows1 , windows2 , and windows3 client machines etc. for Windows client machines, respectively.
')

Print server setting

First of all, we set up a print server, or rather we set up administrative access to it, then we set up printing on it, and then we describe the configuration of the client machines.

We go to the print server in any convenient way and update the packages on it:

root@cupsserver:~# apt update && apt uprgrade -y 

Next, check to see if CUPS is installed on the server:

 root@cupsserver:~# which cupsd 

If the output looks something like this:

  /usr/bin/cupsd 

then CUPS is installed, if there is no output - install CUPS:

  root@cupsserver:~# apt install cups -y 

Now let's configure administrative access to the cups web interface. All configuration files are in the path / etc / cups / . To begin with, just in case, we will make backup copies of the main CUPS configuration files:

 root@cupsserver:~# cp /etc/cups/cupsd.conf /etc/cups/cupsd.conf.original root@cupsserver:~# cp /etc/cups/cups-files.conf /etc/cups/cups-files.conf.original root@cupsserver:~# cp /etc/cups/cups-browsed.conf /etc/cups/cups-browsed.conf.original 

However, if you did not do it, it doesn’t matter, the default samples of these files are along the path / usr / share / cups . You also need to mention that you can check any added options in the CUPS configuration files with the command:

 root@cupsserver:~# cupsd -t 

If you have misled something, sealed up or used an option that is no longer supported by CUPS, the output of the command will reflect these errors.

But let's get down to finally setting up. After any changes to the files in the / etc / cups / folder, you must restart the CUPS service to get the effect:

 root@cupsserver:~# service cups restart  root@cupsserver:~# systemctl restart cups  root@cupsserver:~# /etc/init.d/cups restart 

And if you edited the /etc/cups/cups-browsed.conf file, then a separate cups-browsed service is responsible for it, which also needs to be restarted:

 root@cupsserver:~# service cups-browsed restart  root@cupsserver:~# systemctl restart cups-browsed  root@cupsserver:~# /etc/init.d/cups-browsed restart 

Execute the command

 root@cupsserver:~# nano /etc/cups/cupsd.conf 

The first uncommented option is

 LogLevel warn 

It determines the minimum information content of the CUPS logs. CUPS log files are located at / var / log / cups / . At the time of installation, configuration, and debugging of the print server, it will be reasonable to switch the logging to debug mode. To do this, change warn to debug2:

 LogLevel debug2 

By default, CUPS listens for incoming connections only from localhost , that is, on the loopback interface. To make sure of this, you can execute the command

 root@cupsserver:~# netstat -plutn 

One of the lines would look something like this:

 tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 737/cupsd 

Further actions depend on the degree of your paranoia. You can add in the block that conditionally begins with the comment #Only listen for connections from the local machine several lines with IP addresses or subnets, where CUPS will be allowed to listen to connections.

 # Only listen for connections from the local machine. Listen localhost:631 Listen /run/cups/cups.sock #    IP  Listen 10.10.100.67:631 #     Listen 172.168.0.0:631 

Or you can allow CUPS to listen for connections from all addresses.

 # Only listen for connections from the local machine. Listen localhost:631 Listen /run/cups/cups.sock Port 631 

The next setting point is the discovery of network and shared printers.

 # Show shared printers on the local network. Browsing Off BrowseLocalProtocols dnssd 

In my opinion, this option should remain off, since it determines whether broadcast information will be sent over the network about printers connected to the print server. And after all they will be connected to it all. And accordingly, all client machines will display all printers at once. Our print server should search and detect all printers on the network, but not send them mindlessly across the entire network.

Next come the authentication settings.

 # Default authentication type, when authentication is required... DefaultAuthType Basic 

Defines access rights to the CUPS web interface, as well as its administrative part. In order for the user user to administer CUPS, it must be added to the lpadmin system group:

 root@cupsserver:~# usermod -a -G lpadmin user 

In general, the groups that are allowed administrative access to CUPS are defined in the cups-files.conf configuration file in the

 # Administrator user group, used to match @SYSTEM in cupsd.conf policy rules... # This cannot contain the Group value for security reasons... SystemGroup lpadmin 

If you want to add a certain linux user group with rights to administer a print server, for example printadmins , then simply add them through the space to lpadmin . If the group is domain, then it is a bit more complicated and will be described later.

Now let's go to the <Location /> block:

 # Restrict access to the server... <Location /> Order allow,deny </Location> 

Order allow, deny means that connections are prohibited from anywhere, unless permission is specifically indicated. Ie, you must first specify Deny from all , and then IP addresses, subnets, hosts or hosts by mask ( * .example.com ):

 # Restrict access to the server... <Location /> Order allow,deny Allow from cupsserver #         Allow from cupsserver.example.com #       FQDN Allow from localhost #       loopback  Allow from 10.10.100.* #    Allow from linux4.example.com #     Allow from 172.168.5.125 #  , IP   </Location> 

For complete confidence and debugging, you can leave it until you configure everything else, such a design that allows printing from anywhere:

 # Restrict access to the server... <Location /> Order allow,deny Allow from all </Location> 

Let's proceed to setting up administrative access to CUPS on the print server. Decide which IP / subnet IP address and / or subnet will be connected to CUPS, and add it by analogy with the <Location /> block:

 # Restrict access to the admin pages... <Location /admin> Order allow,deny Allow from localhost Allow from 10.10.100.* Allow from admin.example.com </Location> # Restrict access to configuration files... <Location /admin/conf> Order allow,deny Allow from localhost Allow from 10.10.100.* Allow from admin.example.com </Location> # Restrict access to log files... <Location /admin/log> Order allow,deny Allow from localhost Allow from 10.10.100.* Allow from admin.example.com </Location> 

Optionally, you can add a default interface language. The list of available languages ​​can be viewed using the command:

 root@cupsserver:~# ls /usr/share/cups/locale 

If you need localization, for example, ru, add a line to /etc/cups/cupsd.conf :

 DefaultLanguage ru 

In order for your cupsserver.example.com printserver to be accessed by its hostname (hostname), you need to create a client.conf file with the following contents in the / etc / cups / folder:

 ServerName _ 

The easiest way to do this is as follows:

 root@cupsserver:/etc/cups# echo "ServerName $(cat /etc/hostname)" > /etc/cups/client.conf 

Since we assume that there is a DNS server on the network, it will be preferable that you can contact the print server by its domain name ( cupsserver.example.com ). The server can also be assigned a CNAME alias on the DNS server, for example print or cups . In order for the print server to accept connections for such calls, you need to add such a line to the /etc/cups/cupsd.conf file:

 ServerAlias cupsserver.example.com print cups 

If you want the print server to accept any calls, or don’t want to bother, you can add this:

 ServerAlias * 

You also need to look inside the /etc/cups/cups-browsed.conf file. This file controls how the printer server will look for printers on the network and broadcast its printers. I propose to completely disable the mailing option. The print server will search for a printer on the network, but from it printers will be manually connected to client machines. Below will be described why. In the meantime, we find the BrowseRemoteProtocols dnssd cups line :

 # Which protocols will we use to discover printers on the network? # Can use DNSSD and/or CUPS and/or LDAP, or 'none' for neither. BrowseRemoteProtocols dnssd cups 

With this option, the print server searches for shared printers on the network. We leave it enabled, since it is in our interest that the print server look for a printer on the network. But we absolutely do not need the print server to send out all the printers connected to it at all, otherwise there will be a lot of confusion. To prevent such a scenario, we find the following option #BrowseLocalProtocols none and uncomment it:

 # Which protocols will we use to broadcast shared local printers to the network? # Can use DNSSD and/or CUPS, or 'none' for neither. # Only CUPS is actually supported, as DNSSD is done by CUPS itself (we ignore DNSSD in this directive). BrowseLocalProtocols none 

At this point, we suspend the configuration of the print server and proceed to the configuration of the Windows and Linux client machines. Requirements for them are - to allow print jobs to be sent to a print server, and to send print jobs specifically (and only) to a print server if printing is necessary on a network printer.

As an example, let's set up printing through a print server between two Linux client machines (hostname linux1 ) and Windows 8, respectively (hostname windows1 ). Let's start with setting windows1 as a print destination from the print server. I have a Canon i-SENSYS MF4410 printer connected to it and working properly. The printer name is Canon-MF4400. The easiest way to actually print from a print server to windows1 is to go to Control Panel> Programs> Programs and Features> Turn Windows features on or off . There we include the Print and Document Services> LPD Print Service component. This allows you to connect this printer to the print server using the address lpd: // windows1 / Canon-MF4400 . Of course, the question is brewing, why not connect using SMB? Nobody forbids. If you have debugged this method, you can share the printer in this way, and connect to the print server via SMB protocol. Instructions on this connection, in my opinion, are beyond the scope of this article, which is already quite voluminous. In the meantime, we believe that the reader successfully logged in at http: // cupsserver: 631 / admin clicked on the button “Add a new printer” and, following the intuition, logic and previous manuals, successfully connected the printer from windows1 using LPD protocol to the print server cupsserver [example. com] and the printer page is available at http: // cupsserver: 631 / printers / Canon-MF4400 .

Now we will perform a similar operation on a Linux client with the host name linux1 . In general, this part will be much more voluminous, since the client machine has its own CUPS service and needs to be configured in much the same way as the print server, except for its subordinate role in the organization of printing.

Configuring CUPS Connection Listening Addresses

We go to linux1 in any convenient way. Edit the file /etc/cups/cupsd.conf :

 user@linux1:~$ sudo nano /etc/cups/cupsd.conf 

We find, add or change the lines in it:

 DefaultLanguage ru #      /usr/share/cups/locale ServerAlias linux1.example.com linux1 [CNAME    DNS ]  ServerAlias * #      Listen localhost:631 #  localhost Listen 10.10.100.50:631 # IP   . Listen cupsserver:631 #   .   IP  ,    Listen linux1:631 #  Port 631 #       Browsing off # .       BrowseLocalProtocols dnssd # DefaultAuthType Basic #  .     Kerberos,      WebInterface Yes # 

Configuring CUPS Connection Listening Addresses

In the previous block, we configured the ability to connect to CUPS. Now let's move on to setting permissions for access to printing, as well as to the administrative pages of the CUPS service on the linux1 host. Reopen, if closed, the /etc/cups/cupsd.conf file and proceed to editing the <Location /> , <Location / admin> , <Location / admin / conf> , <Location / log> blocks:

 # Restrict access to the server... <Location /> Order allow,deny #    "  ,  " Allow from localhost #    linux1 Allow from linux1 #  .        Allow from cupsserver #  CUPS    DNS,  . ,     Allow from cupsserver.example.com # FQDN  Allow from 10.10.100.50 #     IP  <b>cupsserver</b> </Location> # Restrict access to the admin pages... <Location /admin> Order allow,deny #   Allow from localhost #      Allow from linux1 #   Allow from 10.10.101.71 # ,  IP  Allow from 10.20.50.* # ,    IT  AuthType Default #   CUPS    .   Require user @SYSTEM #     CUPS </Location> # Restrict access to configuration files... <Location /admin/conf> #   Order allow,deny #   Allow from localhost #      Allow from linux1 #   Allow from 10.10.101.71 # ,  IP  Allow from 10.20.50.* # ,    IT  AuthType Default #   CUPS    .   Require user @SYSTEM #     CUPS </Location> # Restrict access to log files... <Location /admin/log> #   Order allow,deny #   Allow from localhost #      Allow from linux1 #   Allow from 10.10.101.71 # ,  IP  Allow from 10.20.50.* # ,    IT  AuthType Default #   CUPS    .   Require user @SYSTEM #     CUPS </Location> 

Configuring distribution and receiving broadcast network printers

Another Linux client, in this case linux1 , needs to edit the /etc/cups/cups-browsed.conf file:

 user@linux1:~$ sudo nano /etc/cups/cups-browsed.conf BrowseRemoteProtocols none #  none      . BrowseLocalProtocols cups #     . DNSSD   ,    cupsd.conf BrowseOrder Allow,Deny #   Order  cupsd.conf -   ,        BrowseAllow 10.10.100.50 # IP  BrowseAllow cupsserver #    BrowseAllow cupsserver.example.com #     

Administrative access setup

Just a few words about administrative access, both on the CUPS WEB interface on the print server, and on any Linux client machine. Even with the presence of 30-50 computers, you need to unify the authorization on CUPS, and not keep in mind or else where the passwords of each machine. And this is important on all Linux machines, because to add a printer to the server, you must first install it locally. I see several paths.

First, on each Linux system, create a printeradmin user (for example) and add to the lpadmin group:

 user@linux1:~$ sudo usermod -a -G lpamin printeradmin 

and login to http: // hostname: 631 / admin using his credentials.

The second option is almost identical and offers to create a group in the system, for example, printersadmins , add the required CUPS administrator ( printeradmin , user ) there:

 user@linux1:~$ sudo groupadd printersadmins user@linux1:~$ sudo usermod -a -G printersadmins printeradmin user@linux1:~$ sudo usermod -a -G printersadmins user 

Then you need to find the line in /etc/cups/cups-files.conf

 # Administrator user group, used to match @SYSTEM in cupsd.conf policy rules... # This cannot contain the Group value for security reasons... SystemGroup lpadmin 

and add one or more user groups with the right to administer CUPS through a space.

 # Administrator user group, used to match @SYSTEM in cupsd.conf policy rules... # This cannot contain the Group value for security reasons... SystemGroup lpadmin printersadmins somegroup 

And finally, the third option. Make administrators print server and CUPS'ov client machines domain user group. To do this, the print server and linux client machines must be joined to the AD domain. There are several methods for connecting linux to the Windows domain, but as far as I know, the basic is connecting using winbind and using SSSD (realmd). The description of these methods is not included in the article, so I’ll dwell only on the points that relate specifically to CUPS.

Configure use of domain user groups for CUPS administration

Each method of connecting to the centralized authorization system in Linux creates a special file- “pipe” (pipe) through which applications can see a list of domain users. In order for CUPS to do this, you must allow it to use the pipe in AppArmor to authenticate users. AppArmor - Linux security module for access control. Limits certain programs to a set of files listed in its policies. To add the right to use CUPS users and domain groups via winbindd, add the following line to the /etc/apparmod.d/local/usr.sbin.cupsd file:

 /var/lib/samba/winbindd_privileged rw 

If Linux is entered into the domain via SSSD, then you must specify the location of its pipe in /etc/apparmod.d/local/usr.sbin.cupsd , adding the line there:

 /var/lib/sss/pipes/private/pam rw 

In addition, in the case of SSSD, this allows authentication (find out who comes in), but in order to pass authorization (find out if the user has the right to manage CUPS), you must also add the line to the SSSD configuration file /etc/sssd/sssd.conf :

 ad_gpo_map_interactive = +cups 

This, conditionally expressed, gives CUPS the right to “look in” SSSD.

Authorization can be configured differently, but the principle (pipe file) is generally universal and there is a chance to configure it for LDAP, FreeIPA and other directory services by analogy.

Installing a printer in Linux

Installing a printer on Linux is often a specific task, different for different brands and even models. Therefore, I see no point in describing the installation of the printer and take it as a fact that a Kyocera-1024FP printer with the name Kyocera- 1024FP is installed on the linux1 host, and the printer page is available at i> http: // linux1: 631 / printers / Kyocera-1024FP.

Now that the Linux server and client machines are configured, printers are attached to some of them, and there are also Windows machines that you need to print with and with, and the whole system should be stable even if you need to replace the printer on one of the PCs then this should not entail a reconfiguration of a good half of all PCs, if not all. In addition, you need as few driver problems as possible. And it is quite possible.

Printer Groups (Classes)

Above we described the connection of Canon-MF4400 from the windows1 host via the LPD protocol. The printer is still connected and its status can be viewed on the page http: // cupsserver: 631 / printers / Canon-MF4400 . And now let us pay close attention to the cupsserver http: // cupsserver: 631 / admin main administration page. On this page there is a “Add Group” button. Click on it. In it, you will see the fields "Name", "Description", "Location", similar to the same when setting up a regular printer. In the lower block, you will see a list of all printers connected to the print server. Select Canon-MF4400 or whatever you want, then in the “Name” field, enter, for example printer-windows1 , “Description” and “Location” at your discretion, and click “Add Group”.

Now we have a printer-windows1 group with a Canon-MF4400 printer in it. The page of this group is accessible just like the page of the Canon-MF4400 printer with a reservation for a slightly different way - http: // cupsserver: 631 / classes / printer-windows1 .

We still have a Kyocera-1024FP printer connected to linux1. Connect it to the print server via HTTP. Select the connection method "Internet Printing Protocol (http)" [Internet Printing Protocol (http)], from the list of drivers, select the brand "Generic", model "IPP Everywhere". We call it whatever you want, as we call it on the linux1 host, Kyocera-1024FP . Now the printer is available on the printserver at http: // cupsserver: 631 / printers / Kyocera-1024FP . Similar to setting up the printer-windows1 group, we create the group printer-linux1 with the Kyocera-1024FP printer in it. Her link is accordingly http: // cupsserver: 631 / classes / printer-linux1 .

Now we connect the Kyocera-1024FP printer from the linux1 host via the cupsserver printer server to the windows1 host with the Windows 8 system on board without any additional (!) Driver installation. To do this, when connecting a printer, we select “Select a shared printer by name”. In general , we write http: // print_server_name: 631 / classes / group_name . In our particular case, http: // cupsserver: 631 / classes / printer-linux1 . When requesting a driver, we indicate the “Generic” brand, the model is “MS Publisher Imagesetter”. , «printer-linux1 cupsserver :631». , Kyocera-1024FP.

Canon-MF4400 windows1 cupsserver linux1 Linux (!) . , Kyocera-1024FP cupsserver . linux1select the connection method “Internet Printing Protocol (http)”, as the location of the printer ( Canon-MF4400 ) the link to its group on the print server is http: // cupsserver: 631 / classes / printer-windows1 . When requesting a driver, we indicate the “Generic” brand, the model is “IPP Everywhere”. We call it anything you like, you can call it the same way as a group - printer-windows1 . The printer is now available on linux1 at http: // linux1: 631 / printers / printer-windows1 , and we can already send documents to print.

The main charm of this method is that if a printer is replaced on any PC, the computer itself is replaced, or both, it does not affect those who were connected to them through the group on the print server. The only setting is made on the print server - a new printer is connected to the print server, then it is removed from the group in which the old printer was located, and a new printer is added to replace the old one. And no additional settings on any number of PCs, only on the printserver and the PC itself on which the printer was changed. The “IPP Everywhere” and “MS Publisher Imagesetter” drivers contain a large number of paper settings, printing, etc., so there is no problem to set up the desired type of printing through them.

Conclusion

The topic is too extensive to spell out in any detail, and even so the article came out extremely voluminous. Any clarifications, indications of errors, unresolved questions and advice given in the comments to this article will be taken into account and, if necessary, included in the article.