Platform-specifics: Linux (x86)

Service applications on Linux

When running a service application on Linux, there are some platform-specific issues to consider, as follows.

• Single-user configuration is not suitable for a host which is running service applications. Use Multi-user configuration.
• Create a dedicated system user for each service (or at least, each service type). The idea is that, if the application gets subverted by an attacker who can then perform arbitrary actions with the privileges of the application, it's a good idea to limit those privileges. In particular, Don't run service applications as root either, unless you really have to.
• In theory, service users can be locked down hard: they don't need a shell, you can disable logins as that user (if you use the headless server techique) and they don't even need a home folder. In practice, a slightly looser policy may make life easier while configuring the service, without significantly impacting security. [Well-written Java applications are inherently rather resistant to OS-level breaches, since they resist buffer overruns better than C/C++ ones.]. Consult your system administration guide for more on this. In particular, man adduser may be helpful.
• Where possible, don't listen on "well-known" ports numbered 1024 or below: this requires root privileges. (See the previous point.) Instead, listen on a higher, non-privileged port, and have your firewall port-forward requests from the well-known port.
• Put the service application's CDBs in its home folder (or a subfolder thereof).
• Make sure your startup scripts start the Checkpoint Daemon before starting any applications. There is usually a suitable skeleton script in /etc/init.d/skeleton; if you know what you're doing, you can customise this to start the Daemon and any service applications automatically when the system boots. Otherwise, start them all manually, or get some help. The format of boot scripts varies from distro to distro, so we can't provide ready-to-use ones.

  If you get boot scripts wrong, you can make your system unbootable. Proceed at your own risk!

• Startup scripts contain login credentials, and should therefore be chmod 700 root .
• The command to start the service is of the form shown below. Most services require Checkpoint credentials to be supplied as parameters. For example, a Chameleon might be started like this:

  su -c "/opt/cpoint/bin/chameleon -conf myglint.conf chamel@server password chamelsubsys &" chameld
  	

  Don't confuse the Checkpoint user ID (here chamel@server), used for Checkpoint access-control, with the system user ID (here chameld) used for file-level access-control. The -conf option is covered in Application configurations.
• man su if you don't understand the incantation above.
• If you're using Checkpoint Dumper to backup the Checkpoint root and shadow databases on a multi-user installation (recommended) then that instance of Dumper will have to run as the Checkpoint system user, cpoint. Don't run other services as cpoint.

Killing service applications

If possible, you should shut down a service application using the special mechanisms provided; these ensure a clean shutdown.

If these fail, fall back to using the techniques for killing generic applications.

Killing generic applications

It may happen that you need to kill the Checkpoint Daemon, or any other java app.

In a modern Linux environment, most (Checkpoint) applications which are not services will have some sort of GUI; even browser-fronted applications can be configured to have a small "front panel" GUI. (As, indeed, can service applications.) This can be used to shut down the application. This method is greatly to be preferred since it allows the application to shut down cleanly.

However, it can happen that an application gets "wedged" and cannot shut itself down cleanly. If this happens, you have no choice but to cut it off at the knees instead, and hope it doesn't do too much damage. (Depending on the application, you should get away with this. Usually!)

In order to do this, you need to use the unix kill command. In order to do that, you need to identify the process ID of the process in question. Unfortunately, this is not always easy; it can depend both on the application in question and on the Java VM implementation. Running ps aux |grep java in a shell is usually a good place to start; further details are a matter of general administration for your particular Linux distribution and are beyond the scope of this guide.

Method of last resort:

1. Manually shut down every Java application you can (including all Checkpoint applications), using the usual methods.
2. Run killall java.

Alternatively, you could just ignore the wedged application and wait for it to go away next time you reboot.

The Checkpoint Daemon is a service application. Don't kill it until you have shut down all (other) Checkpoint applications; this ensures that it's not in use and can therefore be killed safely.

To shut down the Checkpoint Daemon, use pasistop -daemon.

Headless installations