Table of Contents
- 13.1. The Installation Process
- 13.2. Logs
- 13.3. OpenPGP Settings
- 13.4. IP Address Restriction
- 13.5. Advanced Configuration
- 13.5.1. Alternative TCP/IP Settings
- 13.5.2. HTTP XFF Header Settings
- 13.5.3. Database Connection Settings
- 13.5.4. CUPS Settings
- 13.5.5. Server-side Download
- 13.5.6. RESTful Client
- 13.5.7. User Home Clean
- 13.5.8. Database Locking
- 13.5.9. pdf2cairo Image Strategy
- 13.5.10. Alternative File Locations
- 13.5.11. Miscellaneous Settings
- 13.5.12. System Environment
- 13.6. Upgrading SavaPage
- 13.7. Removing SavaPage from a GNU/Linux server
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 -h
switch.
_____________________________________________________________________________
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-1.0.0-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
paragraphs.
The first stage in the install process extracts the archive to
/tmp or a location as defined by an environment
variable TMPDIR. The command-line programs
tar and gunzip are used during
this phase.
After extraction is complete the install script is
called. The current directory is passed as -d option
argument, to be used as install location. Also, the -n
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
upgrade.
_____________________________________________________________________________
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
to the savapage user only:
| Area | Description |
|---|---|
/opt/savapage/server/server.properties | Contains server configuration properties. See Section 13.5, “Advanced Configuration”. |
/opt/savapage/server/admin.properties | Contains the hashed password of the reserved internal
admin user. |
/opt/savapage/server/jmxremote.password | Contains the plain text password of the reserved JMX
admin user. See Section 4.11.13.4, “JMX Agent”. |
/opt/savapage/server/jmxremote.ks | The private keystore used by the JMX Agent. |
/opt/savapage/server/data/ | This directory contains application data including database files. Some of this data may contain sensitive information. |
/opt/savapage/server/bin/linux-x64/ | This directory contains the
savapage-pam setuid-root
binary. Even though the binary is no use to an end-user
or hacker, good security practice stipulates that we
should only allow the
savapage user access
to this directory. |
Table 13.1. Secured Application Areas
Permissions can be checked and re-applied any time after the
installation by running the script:
/opt/savapage/server/bin/linux-x64/setperms
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:
-
Setting the
/opt/savapage/server/bin/linux-x64/savapage-pambinary as setuid-root. This binary is used for password verification. -
Installing the
/opt/savapage/providers/cups/linux-x64/savapage-notifierbinary as CUPS event notifier. This binary is used to send CUPS printer and print job status events to the central SavaPage server. See Section 13.5.4.1, “CUPS Notifier”. -
Setting up a systemd unit for GNU/Linux systems that use the systemd service manager. This is done by creating a
savapage.servicefile in the systemd unit library. Depending on the distribution the unit will either be created in the/lib/systemd/system/or/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
-lparameter socupsdis 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.serviceunit is installed in/etc/systemd/system/to override the default/lib/systemd/system/cups.serviceshipped with the CUPS package. This custom unit startscupsdwith the-fparameter so it runs steadily in the foreground (without dependencies forcups.socketandcups.path).
-
-
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:
/opt/savapage/server/bin/linux-x64/roottasks
and ...
/opt/savapage/providers/cups/linux-x64/roottasks
Alternatively the administrator can view the script and make the required changes by hand.