Table of Contents
This section is a supplement to the Install Guide (see Chapter 2, Server Installation). It provides an in-depth explanation of the GNU/Linux installation process, the directory layout and tools involved.
Information in this chapter is technical in nature. It is expected that readers have prior experience with:
The Unix command line environment
Unix file permissions
SavaPage is supplied as a pre-compiled self-installing application. The installation process is designed to work with all major GNU/Linux distributions. To be sure if your GNU/Linux distro is supported out of the box, please check Section 1.2, “System Requirements”. Due to the varied nature of some installations and administrator preferences, often some manual configuration is required. This section describes the installation process in detail as well as some additional options available to system administrators.
SavaPage is supplied in a self-extracting, self-installing archive. The
archive is simply a
tar archive compressed with
gzip, and headed with a shell script to facilitate
self-extracting. After extraction is complete, the installation script named
install is executed to begin the install process in the
directory where the archive resides (usually
/opt/savapage). Some system administrators may
like to inspect the contents of the archive, and possibly the installation
process itself prior to the actual install.
The self-extracting installer takes a number of command line arguments. The
-e option will extract the archive into the current working
directory ready for inspection. With the
-n switch the
-i install will be non-interactive. With this mode you
implicitly agree with the AGPL license, and root tasks are collected in a
MUST-RUN-AS-ROOT script located in the install
directory. This script must be run manually as
root after the
installation. Further usage information is available via the
_____________________________________________________________________________ SavaPage Install (c) 2010-2018, Datraverse B.V. License: GNU AGPL version 3 or later <https://www.gnu.org/licenses/agpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Usage: savapage-setup-0.9.11-linux-x64.bin [-h|-i|-e|-l] [-n] [-v] [FILE]... -h This help text. -i Install after extracting the files (default). -n Non-interactive install: execute MUST-RUN-AS-ROOT afterwards. -e Extract all files or a FILE list and exit without installing. -l List the contents of the archive and exit without extracting. -v Verbose. Print the names of the files as they are extracted.
Even though the majority of the installation process is completed under the
identity of the system user account called
savapage, most administrators would like to
know what the install process does. The main steps are outlined in the next
The first stage in the install process extracts the archive to
/tmp or a location as defined by an environment
TMPDIR. The command-line programs
tar and gunzip are used during
After extraction is complete the install script is
called. The current directory is passed as
argument, to be used as install location. Also, the
switch, used at the setup binary, is propagated to this script. The
extracted files are copied to the install location. Care is taken not to overwrite any existing data or configuration files
if this is an install-over-the-top
_____________________________________________________________________________ SavaPage Install (c) 2010-2018, Datraverse B.V. License: GNU AGPL version 3 or later <https://www.gnu.org/licenses/agpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Usage: install [OPTION]... -d <dir> The target location, usually the /opt/savapage directory. -h This help text. -n Non-interactive install: execute MUST-RUN-AS-ROOT afterwards.
To ensure the default installation is secure by default, permissions are
applied to key files. The following area of the application are restricted
savapage user only:
|Contains server configuration properties. See Section 10.3, “Advanced Configuration”.|
|Contains the hashed password of the reserved internal
|Contains Google Cloud Print configuration properties. See Section 4.10.6, “Google Cloud Printer”.|
|Contains the plain text password of the reserved JMX
|The private keystore used by the JMX Agent.|
|This directory contains application data including database files. Some of this data may contain sensitive information.|
|This directory contains the
Table 10.1. Secured Application Areas
Permissions can be checked and re-applied any time after the installation by running the script:
The SavaPage Application Server runs in a Java Virtual Machine (JVM)
process and listens on ports 8631 and 8632 (SSL).
These ports are used for Web App access, printing and other services. Ensure
that any firewall or local IP filtering software such as
iptables is set to allow local network traffic access
to this ports.
A small part of the install process needs to run as the
root account. The tasks conducted as root include:
binary as setuid-root. This binary is used for password
binary as CUPS event notifier. This binary is used to send CUPS
printer and print job status events to the central
Setting up a systemd unit for
GNU/Linux systems that use the systemd service manager. This
is done by creating a
in the systemd unit library. Depending on the distribution the
unit will either be created in the
/usr/lib/systemd/system/ directory. The
unit is started and enabled.
Setting up a custom systemd unit for the CUPS scheduler cupsd.
When the scheduler is 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 a custom systemd
cups.service unit is
override the default
shipped with the CUPS package. This custom unit
cupsd with the
-f parameter so it runs
steadily in the foreground (without dependencies for
Setting up SysV style start scripts for Debian based systems that use the SysV service manager. This is done by placing symlinks in the:
/etc/init.d/ /etc/rc3.d/ /etc/rc5.d/ and so on...
If the administrator decides not to run the root-level tasks during the install process, the tasks can be run again post-install by executing the shell scripts:
Alternatively the administrator can view the script and make the required changes by hand.