Linux Client Deployment Solaris, too

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.

However, if you are missing dependancies, rpm will not resolve them, and they can be a pain to manage manually. Additionally, you may think you have the prerequisites installed, but rpm says otherwise due to bitness or version. In such cases, use this command to allow yum to resolve the issues:

sudo yum --nogpgcheck localinstall KeyAccess-version-build.platform.rpm

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.

Custom Settings

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 7.4.1.0 and earlier the supported customization options are:

KA_SERVERHOST: sets the host name of the KeyServer to which the client will connect
KA_NAMESOURCE: sets the source of the value used as login name
     0: KeyAccess will use user name as login name
     1: KeyAccess will use computer name as login name
     3: KeyAccess will use full name as login name
KA_IDENTPATH: provides the path to a custom ident.xml file that will be copied to the proper location

Starting with version 7.4.1.1 the supported customization options are:

PROP_HOSTNAME: sets the host name of the KeyServer to which the client will connect
PROP_USERNAME: sets the source of the value used as login name
     0: KeyAccess will use user name as login name
     1: KeyAccess will use computer name as login name
     3: KeyAccess will use full name as login name
PROP_COMPNAME: sets the source of the value used for computer name
     0: default setting
     1: host name as returned by gethostname
     2: canonical host name, as retrieved from DNS
     3: first component of canonical host name (i.e., “myhost” instead of “myhost.domain.org”)
PROP_LOCKED: locks the hostname in the KeyAccess Setup utility
0: unlock the host name
1: lock the host name
PROP_SITE: sets the string that is sent to the server as the Department field for this computer
KA_IDENTPATH: provides the path to a custom ident.xml file that will be copied to the proper location

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.

For other custom properties, you can use the names of various keys and the desired string values as found in the documents on custom properties and Secure settings. For example, you could add this to the ka.xml file:

<key>site</key>
<string>Baltimore</string>

<key>assetOwner</key>
<string>Bill Smith</string>

<key>trust</key>
<string>1</string>

<key>security</key>
<string>1</string>

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.

Client Startup

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.:

/usr/libexec/KeyAccess &

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.

Click here for special info for IBM LSF

Using the above bashrc technique when using an IBM LSF environment will result in duplicate processes that fail to terminate. Per one of our customer sites: "Instead, add the launch command to LSF's JOB_STARTER line for the job queue (the collection of hosts used for a certain group, or purpose. Queues have their own configuration that can be set). JOB_STARTER allows for a command to be run when any job is started, including what we call an 'interactive session', which is the ssh connection that isn't quite ssh as we know it."

Other Files

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.

Tracked Programs

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:

/opt
/usr

The KeyAccess 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.