Make sure to not publish shared printers in CUPS and Samba. Publishing shared printers creates a loophole by which users can access a printer directly from their workstation and print outside the control of SavaPage.
For Samba, just edit the /etc/samba/smb.conf file and disable
the [printers] share definition.
In CUPS, do not enable the “Publish shared printers
connected to this system” option as offered in the Print Server Settings
dialog. When no such dialog is available you can make the adaption in the CUPS
Administrator Web interface (“Share printers connected to this
system”), or manually in the cupsd.conf
[6]file.
Important
Before editing cupsd.conf first stop CUPS by entering
this command:
sudo systemctl stop cups.service
Check if cupsd.conf contains the snippets below that restrict
CUPS to localhost only. If not, change the configuration file
accordingly and leave all other content as it is.
# Only listen for connections from the local machine. Listen localhost:631 # Disable printer sharing. Browsing Off # Restrict access from localhost only <Location /> Order allow,deny </Location>
Important
Each individual proxy candidate CUPS printer must be
shared locally so the
savapage system account can access it.
Enabling the shared option can be done in a printer GUI dialog, in the CUPS
Administrator Web interface, or directly in the
printers.conf
[7] file by setting the Shared Yes option for a
printer.
To prevent remote printers that DNSSD broadcast themselves, to be discovered
by CUPS and synchronized into SavaPage, edit
cups-browsed.conf
[8]file, and change it as
follows:
BrowseRemoteProtocols none
An active SavaPage server captures print job statuses real-time, but when the server is restarted it needs CUPS job history to catch up with the latest statuses. To avoid lost job statuses, CUPS must be told to “Preserve job history”.
You can set the Job History option in the Print Server Settings dialog
(“Preserve job history but not files”, or optionally
“Preserve job history (allow reprinting)”), in the CUPS
Administrator Web Interface (Advanced settings, “Retain Metadata :
Yes”, and optionally “Retain Documents : Yes”) , or
manually by changing the cupsd.conf file as follows:
MaxJobs 500PreserveJobHistory Yes
PreserveJobFiles No
|
|
|
|
|
|
The number of preserved history jobs can be checked with this command:
sudo find /var/spool/cups/ -maxdepth 1 -type f -name 'c*' | wc -l
The number of preserved job files can be checked with:
sudo find /var/spool/cups/ -maxdepth 1 -type f -name 'p*' | wc -l
This section gives you some background information about the ID that CUPS assigns to a print job[9]. There is nothing you need to configure for this, and you don't really need to consider this info at a first time SavaPage installation. However, do read carefully when Migrating to a New Server, or if you plan to meddle with CUPS cache.
The CUPS Job ID is a global integer that is incremented and assigned to each new print job. In this way, a Job ID refers to a single job within the CUPS cache. When a document is printed from SavaPage, its Job ID is persisted in the SavaPage database and used to retrieve CUPS job status information, or to link incoming CUPS status notifications to the printed document.
When you delete the content of the CUPS cache directory
/var/cache/cups/, the Job ID offset is reset to zero. If
SavaPage depends on this CUPS instance, the cache will be out-of-sync with
the CUPS Job ID range as persisted in the SavaPage database. This will
most likely result in newly issued job ID's that are already present in the
SavaPage database, and so introduce a non-unique relation between printed
document and CUPS job ID. Also, when SavaPage is moved to another server
an out-of-sync is very likely.
How does SavaPage deal with the possibility of an out-of-sync situation?
-
For incoming CUPS notifications, the most recent document that matches the provided Job ID, and has not yet reached final state (completed, cancelled, aborted), is updated with the provided status.
-
When retrieval of Job ID status information for a document with non-final state from CUPS fails, then print status is set to “unknown” and time completed to system time.
CUPS makes “job-name”, “job-originating-host-name” and “job-originating-user-name” private by default. This means that personal data are anonymized in the CUPS Web interface, as shown below.
You can restore the default by changing the
JobPrivateValues directive in the
cupsd.conf file as
follows:
<Policy default>
JobPrivateValues default
If you want to use the CUPS Web Interface for administration from all machines
on the local network you should adapt cupsd.conf as follows:
# Allow remote access Port 631 # Disable printer sharing. Browsing Off WebInterface Yes <Location /> # Allow shared printing... Order allow,deny Allow @LOCAL </Location> <Location /admin> Order allow,deny Allow @LOCAL </Location> <Location /admin/conf> AuthType Default Require user @SYSTEM Order allow,deny Allow @LOCAL </Location>
Note
The @LOCAL name will allow access from all
local interfaces. This can be
confusing since the host system running CUPS often belongs to a
different set of subnets from its clients. In that case you can specify
multiple Allow directives, one for each allowed
subnet. See the cupsd.conf
man page.
CUPS versions before 2.4.3 contain a security issue that allows users to
retrieve documents (pending or printed) without authentication [10]. If this CUPS version is installed, modify
cupsd.conf as shown below.
... <Policy default> ... # Remove the CUPS-Get-Document operation from <Limit> tag ... <Limit Send-Document ... CUPS-Get-Document > Require user @OWNER @SYSTEM Order deny,allow </Limit> # ... and insert <Limit> section below <Limit CUPS-Get-Document> AuthType Default Require user @OWNER @SYSTEM Order deny,allow </Limit> ... </Policy> ...
When CUPS was stopped earlier you need to start CUPS again with this command:
sudo systemctl start cups.service
Now you can test if the CUPS print queues to be used as Proxy Printer work as expected.
[6] On Debian, RHEL and openSUSE systems cupsd.conf is
located in the /etc/cups/ directory.
[7] On Debian, RHEL and openSUSE systems
printers.conf is located in the
/etc/cups/ directory.
[8] On Debian, RHEL and openSUSE systems
cups-browsed.conf is located in the
/etc/cups/ directory.
[9] CUPS NextJobId is held in
/var/cache/cups/job.cache
[10] CVE-2023-32360 [An unauthenticated user may be able to access recently printed documents] was reported by Gerhard Muth and explained in personal communication with the author of this manual. Also see About the security content of macOS Ventura 13.4 and RHSA-2023:4771 - Security Advisory.