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 500               
PreserveJobHistory 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?

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.

Figure 2.1. CUPS Job Privacy

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>

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>
...

The scheduler for CUPS is called cupsd. When run from systemd some systems pass the -l parameter, so cupsd is run on demand by socket and path activation. The advantage of this setup is that CUPS is activated when needed, saving precious boot time and resources, and deactivated again after being idle for a while. This lazy activation scenario is efficient for desktop systems that print occasionally and for which printing is not time critical. However, dedicated print systems like SavaPage, that intensively use IPP to communicate with CUPS, need CUPS to be full-time activated. Therefore the systemd cups.service unit must effectively start cupsd with the -f parameter, so it runs steadily in the foreground.

Check the /lib/systemd/system/cups.service unit: ExecStart must start cupsd with the -f parameter. If not, edit the CUPS service unit with this command:

sudo systemctl edit cups

This launches a text editor for creating the file:

/etc/systemd/system/cups.service.d/override.conf

Add the following lines:

[Service]
Type=simple
ExecStart=
ExecStart=/usr/sbin/cupsd -f

Save the file and close the editor. Usually, after you edited a systemd unit file, for it to take effect, you need to run:

sudo systemctl daemon-reload

However, the systemctl edit command automatically did this for you. You can check the effect of the override with this command:

systemctl cat cups.service

... the last lines should show:

# /etc/systemd/system/cups.service.d/override.conf
[Service]
Type=simple
ExecStart=
ExecStart=/usr/sbin/cupsd -f 

You can check if /usr/sbin/cupsd -f is active with this command:

systemctl status cups.service

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.