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
[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 first stop CUPS by entering
sudo service cups stop
cupsd.conf change this content snippet, that
publishes local printers and allows access from all machine on the local network...
# Allow remote access Port 631 # Share local printers on the local network. Browsing On <Location /> # Allow access to the server... Order allow,deny Allow @LOCAL </Location>
... to this snippet that restricts CUPS access from
# Only listen for connections from the local machine. Listen localhost:631 # Disable printer sharing. Browsing Off <Location /> Order allow,deny </Location>
... and leave all other content as it is.
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
 file by setting the
Shared Yes option for a
To prevent remote printers that DNSSD broadcast themselves, to be discovered
by CUPS and synchronized into SavaPage, edit
file, and change it as
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:
This section gives you some background information about the ID that CUPS assigns to a print job. 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
<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
# 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>
The scheduler for CUPS is called cupsd. When run from
systemd some systems pass the
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
ExecStart must start
cupsd with the
-f parameter. If not, edit the CUPS service unit with
sudo systemctl edit cups
This launches a text editor for creating the file:
Add the following lines:
[Service] 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
systemctl edit command automatically did this for
you. You can check the effect of the override with this command:
systemctl cat cups.service | grep Exec
... it should show:
ExecStart=/usr/sbin/cupsd -l ExecStart= ExecStart=/usr/sbin/cupsd -f
You can check if
/usr/sbin/cupsd -f is active with this
systemctl status cups.service
When CUPS was stopped earlier you need to start CUPS again with this command:
sudo service cups start
Now you can test if the CUPS print queues to be used as Proxy Printer work as expected.