There are several client installers built for specific Linux 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. See also OS Details for additional requirements.
For the RPM installer, the basic command new installs is:
sudo rpm -i KeyAccess-version-build.platform.rpm
You may be able to use -U for an upgrade depending on the distro. When trying to reinstall the same version, you will likely need to uninstall first.
sudo rpm -e KeyAccess
Note that uninstalling with rpm will set aside the settings files documented below, so a re-install will have default configuration.
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
To remove, use these commands to uninstall and then remove the left over config files:
sudo dpkg -r KeyAccess sudo dpkg -P KeyAccess
Note the -P command is only needed to remove the config files documented below. That is, if you want to then have a clean install with default settings. Otherwise, dpkg leaves those settings behind and they would be used by a re-install.
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. After installing, you must reboot so the service starts up. The installer will not trigger or prompt for reboot.
Note that we do not have packages for Arch (aur), Void (xbps), or Solus (eopkg). We can not directly support these, but you are free to attempt to convert our rpm or deb packages and install them on those distributions. Features may be limited in those cases.
While the client installers for Linux 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:
Starting with version 7.4.1.1 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. For example, you can edit the file to put in the server address:
<key>host</key> <string>mykeyserver.company.com</string>
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, using env settings will override existing values. If nothing needs to be changed just apply the new package. 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.:
/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
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. If your OS has a GUI environment, using kasetup to launch the KeyAccess utility is very handy. Much like on Mac and Windows, you can see the server address and connection status, force a logon, and open up KeyVerify.
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. As of 7.7.0.5 we have enhanced the linux client to scan more locations for binaries in Audits, as well as being able to identify variants based upon the rpm, dpkg, and snap receipts. We scan these locations by default for executables:
/opt /usr /snap (7.7.0.5 and later) /var/lib/flatpak/app/ (7.7.0.5 and later) Any location with "java" in the path
Items found in these locations will be visible in the Programs window in KeyConfigure along with using Show Installs on a given Computer. Note that in some cases the item in the standard location will be a script, and the actual binary may be in a different directory.
You can add other locations to scan if you install applications outside of these standards. Note that variant information is dependent on the package managers, so an install by other methods will be versionless. To scan another location edit /usr/share/ka/ident.xml and add another entry based on the ones mentioned above. The flags for the path entries are as follows:
i = ignore everything in this location j = look at java (jar) files in this location e = look at ELF executable files in this location x = look at files marked as "executable" in this location X = look at files that import X11 libraries in this location m = include this location in scans even if it is a mount point (7.7.0.5 and later)
As with other platforms, usage events (launch and quit) will be recorded if a Product and Policy are configured. Launches outside of a policy will still result in Last Used information in Audits, and the appearance of the application in the Programs window.