There are several client installers built for specific Linux and Solaris platforms. All of these installers support the same basic settable options, described below. The details of running the installation utilities differ based on which type of installer you are using, and whether the installation is new or an upgrade. For the RPM installer, the basic command for both new and upgrade installs is:
sudo rpm -U KeyAccess-version-build.platform.rpm
You can alternatively use -i for new installs, but -U should work in both cases on most RedHat variants.
For the DEB installer, the basic command for both new and upgrade installs is:
sudo dpkg -i KeyAccess_version-build_platform.deb
For the Solaris PKG installer, the basic command for new installs is:
sudo pkgadd -d KeyAccess-version-platform.pkg
Notice that in all case the installation must be run with elevated permissions. These examples use sudo, but it is also possible to use other methods.
While the client installers for Linux and Solaris do not have a matching configuration tool like the Windows and Mac OS X installers, it is possible to set various configuration options when installing the client. These options are set using temporary environment variables.
To set custom options during an install, you simply set some environment variables as part of the install command. The easiest way to do this is with the env command. For example, to set the KeyServer host you would use the KA_SERVERHOST variable:
sudo env KA_SERVERHOST=keyserver.sample.net [appropriate install command from above]
In versions 184.108.40.206 and earlier the supported customization options are:
Starting with version 220.127.116.11 the supported customization options are:
The environment variable settings are used by the client installers to write values into the file /usr/share/ka/ka.xml, which is a text-based XML file. As an alternative to the environment variable method, you could edit this file directly once the client has been installed.
Note that for upgrade installs, these settings will override existing values. For upgrades where none of these values needs to change, there is no need to set them again — the upgrade process will preserve the values that are already in place.
The installers will create scripts in standard locations that start the client processes automatically. The locations vary based on the system, and might not be used in systems that are not configured in a standard way. If you have systems that do not use standard daemon and agent startup scripts you will need to create these scripts in the appropriate locations.
There are three processes that are started by these scripts.
The client daemon, installed at /usr/libexec/karl, is started whenever the computer restarts, before any users have logged in. This process continues to run while the computer is powered up, regardless of whether any users are logged in.
On Linux systems, the daemon is started by a script in /etc/init.d (on Solaris either a similar script will be used, or the daemon will be installed to run as a "service"). This is a standard mechanism on Unix systems for starting a process that will run independent of user sessions.
The client agent, installed at /usr/libexec/KeyAccess, is started whenever a user logs in. A separate KeyAccess process runs for each logged in user, and stops when that user logs out.
For “Desktop” sessions (Gnome, KDE, or anything else that has X windows as its underpinnings), this process is started by a script installed into /etc/X11/xinit/xinitrc.d, /etc/X11/Xsession.d, or /usr/dt/config/Xsession.d.
If you need to track usage or programs that are run within terminal sessions (anything without X windows), you will need to add /usr/libexec/KeyAccess to an appropriate session startup script. Where you install this command depends on your particular needs, so there is no location that would be correct for all scenarios. Common locations to consider are /etc/bash.bashrc or the analogous per-user shell startup scripts. Note that this process should always be put in the background so that it doesn't block any further login steps, e.g.:
The client UI process, installed at /usr/libexec/kamsg, is also started whenever a user logs in, but is only needed for windowed sessions. This process is responsible for displaying alerts and dialogs related to software usage.
This process is started alongside the client agent when a user logs into a Desktop session. There is no need to start this process in a non-GUI session.
Two non-essential client programs are installed: KeyAccess Setup (/usr/bin/kasetup) for changing client settings, and KeyVerify (/usr/bin/keyverify) for testing the connection to KeyServer. Both are GUI programs. If needed, you can create launch icons for either of these programs so they are easier to access by users.
During operation, the client processes use several filesystem objects to communicate with each other. These IPC objects are kept in /var/tmp/com.sassafras.pipes and /var/tmp/com.sassafras.semaphores, and must remain in place while the client is installed and running. Some additional persistent files stored in /var/lib/KeyAccess should also be left in place for proper and efficient operation.
The Linux client implements most of the same functionality as the Windows and Mac clients. On Linux, “interesting programs” are defined by the client as those the make use of the X11 libraries in order to display a graphic user interface. In addition, the default configuration will only pay attention to executables within either of these two directories:
The K2 client for Linux will report such “interesting programs” to KeyServer and they will appear in KeyConfigure's programs window. Usage events (launch and quit) will be reported if a Product and Policy are configured. The definition of “interesting programs” can be changed so it goes beyond X11 or includes more paths (or even specific executables). Contact Sassafras for details appropriate to various Linux client environments on how to customize the /usr/share/ka/ident.xml config file.