OS Details & System Requirements

Approximate resource requirements for various K2 components are listed in the following table.

The operating system compatibility notes listed below assume that you are using the latest shipping versions of each component: Client, Admin, Server, and Reporter. Older component versions are "backward compatible". If you want to check "forward compatibility" of an older component running on a newer OS, consult the Component History document for specific warnings.

Consult the File Locations document for a complete list of files and directory paths which implement each component. The functionality of K2 components is nearly identical on the various platforms. Installation details, special considerations, exceptional behaviors, or limitations under a specific operating system version are detailed in the comments below the table. Click on the component name to jump to the comments.

  KeyAccess (Client)

OS Versions Size Data
  Windows XP, Vista, 7, 8, 8.1, 10;
Server 2003, 2008, 2008 R2, 2012, 2012 R2, 2016; App-V
3 MB 1 MB
 RDS 1 Server 2003, 2008, 2008 R2, 2012 R2, 2016; Citrix 3 MB 1 MB + 10KB/client
  Mac OS X OS X 10.6 – 10.13 6 MB 1 MB
  Linux 2.2 Kernel and higher 2 MB 1 MB
  Solaris Solaris 9 and higher 2 2 MB 1 MB

  KeyConfigure (Admin)

OS OS Versions Size Data Scratch Space 3
  Windows XP, Vista, 7, 8, 8.1, 10;
Server 2003, 2008, 2008 R2, 2012, 2012 R2, 2016
50 MB 1 MB 1 GB
  Mac OS OS X 10.6 – 10.13 150 MB 1 MB 1 GB

  KeyServer (Server)

Host OS 4 OS Versions Size Data: 6 Months
  /1,000 Clients
5
Scratch Space 3
  Windows XP, Vista, 7, 8, 8.1, 10;
Server 2003, 2008, 2008 R2, 2012, 2012 R2, 2016, Nano
5 MB 4 GB 1 GB
  Mac OS X OS X 10.6 – 10.13 20 MB 4 GB 1 GB
  Linux (or BSD Unix) 2.2 Kernel and higher 5 MB 4 GB 1 GB
  Solaris Solaris 10 and higher 5 MB 4 GB 1 GB

KeyReporter (Reporter) normally installed as part of KeyServer

Host OS 6 OS Versions Size Data Scratch Space 3
  Windows XP, Vista, 7, 8, 8.1, 10;
Server 2003, 2008, 2008 R2, 2012, 2012 R2, 2016, Nano
50 MB 1 MB 1 GB
  Mac OS OS X 10.6 – 10.13 100 MB 1 MB 1 GB
  Linux (or BSD Unix) 2.2 Kernel and higher 50 MB 1 MB 1 GB
  Solaris Solaris 10 and higher 50 MB 1 MB 1 GB
  1. Windows Remote Desktop Server, RDS (formerly Windows Terminal Server, WTS), and Citrix XenApp (formerly MetaFrame etc.), can be configured to use a single copy of the KeyAccess client software on behalf of all the remote desktop sessions which it serves out to its clients. Some of the various Windows operating system versions that may include these technologies are listed.

  2. Unlike the Windows or Macintosh client, the Solaris client has not been widely deployed by customers so full function compatibility on all Solaris hardware and software variants has yet to be demonstrated.

  3. When running reports, KeyConfigure and KeyReporter will create temporary files to store and sort data. The size of these temp files corresponds to the amount of data being selected for the report, so they will be larger when reporting on a large number of client computers, a large number of programs, and a long time range. For a 100 client KeyServer, 100 MB is a good estimate. This will suffice for many reports even for a large KeyServer since only selected records are fetched. But when a specific report needs to pull down all the data from a large KeyServer supporting tens of thousands of client computers, 1 GB or more may be needed: see the estimates below.

  4. Standard computer hardware running a desktop OS is all that is required for the KeyServer process. There are no database services or other server class OS features required. Processor demands are highly optimized and prioritized so license management services take precedence over admin responsiveness or report generation (see Server Requirements notes in the Installation documentation). The KeyServer process (on all platforms) uses UDP port 19283 for client and admin connections. KeyConfigure, KeyReporter, and ksODBC use TCP on this same port. A KeyShadow process uses 19315. As described in the Installation documentation, KeyShadow and KeyServer are essentially identical, distinguished only by the license certificate (and KeyShadow's first launch password requirement). The KeyShadow process uses port 19315 for client connections and it probes KeyServer periodically using ping packets. The KeyServer comments below generally apply to both KeyServer and KeyShadow. KeyReporter is installed by default with KeyServer. KeyReporter opens standard HTTP and HTTPS ports, so ideally the computer you choose to host KeyServer will not already have a web server installed. The ports can be changed if needed.

  5. The exact space required for KeyServer data will vary greatly depending on the values assumed:

    1,000
    computers managed by KeyServer
    1,000
    computers to be audited
    500
    managed products
    30
    daily program launches/quits per computer
    12
    months of usage data

    The estimates in the table above assume a 1000 client KeyServer with auditing enabled for all. The audit is assumed to reference about 1,000 programs on each client. KeyServer's default action of "ignored" is assumed for most program usage, but we assume about 500 products are managed which lead to 30 launches and quits of monitored programs each day (except weekends) for all computers (on average).

    To avoid unlimited growth of the usage database, you may want to discard or split off old records from the database after a fixed time period, perhaps after a year or two. For a year, the total estimated data storage requirement comes to about 7 GB. This includes a constant base value of 1 GB for the audit/computer/program/policy databases plus about .5 GB per month for usage data. This estimate should be scaled in accordance with the values at your site for the variables listed above. Note: you may want to configure data export to a remote database server where storage is “unlimited” and perhaps optimized for faster query response on very large data sets.

  6. KeyReporter is installed by default with KeyServer and will be sub-launched if configured to do so. It can be installed as a standalone on a different computer but it will have reduced functionality when running on its own. Like KeyServer, KeyReporter does not depend on a server OS and has no special hardware requirements. However, the default configuration does make use of TCP port 80, the standard web service port, so unless KeyReporter is customized to use a different port, it cannot be hosted on a computer that is also acting as a standard web server.


Windows

 KeyAccess

The Windows KeyAccess is available as either 32 bit or 64 bit. You should install the bitness that matches your OS. See Deployment for more.

The Windows client OS must include the Windows Management Interface (WMI) in order to fully support K2's hardware audit functionality. However, WMI is not necessary for gathering just basic hardware information (e.g., ethernet hardware address and free disk space) or for auditing software.

By default, KeyAccess settings are stored globally for all users in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KeyAccess

The KeyAccess installer provides an option to install settings individually for each user account. When present, these per-user settings will take precedence:

HKEY_CURRENT_USER\Software\Sassafras\KeyAccess

A third option is to store all settings in the "keyacc.ini" file located in the WINDOWS (or WINNT) directory. Unless a site has a specific reason to avoid the registry altogether the keyacc.ini file (which is created in all cases) should be left with its default entry that simply points to the KeyAccess registry location.

The client installer (K2Client.exe or K2Client-x64.exe) contains both an .exe and an .msi-based installer. The .msi is used unless the OS is older (Windows 9x or NT) and has not been retrofitted with MSI support. Sites using a GPO or other means of distribution may need to extract the MSI in order to facilitate deployment. In the Installers\Windows Installers\Misc folder of the K2 image archive, there is a tool called "k2clientconfig.exe" that will do the extraction and also allow customization of the MSI-based installer. Type "k2clientconfig.exe" at the command prompt to see all the various available options including the ability to customize for a silent install with the correct server address. Note: k2clientconfig only customizes the MSI portion of the installer (regardless of whether it has been extracted), so when you run the customized installer on a system that does not have MSI support, the custom configuration will not be honored. For more details, see the k2clientconfig.exe documentation.

When you upgrade KeyAccess, the installer will preserve the previous settings. If the old Version of KeyAccess was older than 6.1.3, the default setting was for KeyAccess to run as a user program and not as a service. Typically this means a newer KeyAccess install will preserve this old behavior, whereas the new default and recommended setting is to run KeyAccess as a service. If you want KeyAccess to run as a service, uninstall the pre-6.1.3 KeyAccess version before installing the newer version. Alternatively, after upgrading to the new version, remove the startup item and then enter "keyacc32.exe -install" into the Run item in the Start menu.

 KeyConfigure

The Windows Admin installer, K2Admin.exe, also installs the KeyServer ODBC driver. You don't have to install KeyConfigure to use the ODBC driver (K2Admin.exe will let you install just the driver).

Note: KeyConfigure's internal reports can be used to query usage data exported through KeyServer's export feature. An appropriate Windows ODBC driver matching the external database server must be installed on the KeyConfigure computer.

 KeyServer

When hosting KeyServer on Windows (using K2Server.exe to install ks.exe and supporting components), the installer will configure KeyServer as a service set to start "automatically" whenever your system starts up. If you install the KeyServer as a service on any drive other than your system drive (typically C:), you may have to change the default privileges: the SYSTEM account (used by KeyServer) must have "Full Control" rights for all folders in the resulting path (e.g., D:\Program Files\Sassafras K2\Server). It's easiest to install the KeyServer in the default location of C:\Program Files\..., if that is possible.

KeyServer must be hosted on Windows in order to support:

  • Active Directory authentication method
  • Windows NT authentication method
  • SQL authentication method
  • Data export through ODBC

 KeyReporter

KeyReporter is installed by default with KeyServer and will be sub-launched if configured to do so. It can be installed standalone on a different computer but it will have reduced functionality when running on its own. When hosting a standalone KeyReporter on Windows, the installer will configure KeyReporter as a service set to start "automatically" whenever your system starts up. If you install KeyReporter as a service on any drive other than your system drive (typically C:), you may have to change the default privileges: The SYSTEM account (used by KeyReporter) must have "Full Control" rights for all folders in the resulting path (e.g., D:\Program Files\Sassafras K2\Reporter). It's easiest to install the KeyReporter in the default location of C:\Program Files\..., if that is possible.

KeyReporter uses port 80 by default (the standard HTTP port). If you have a web server running on the same computer you should change the port used by the web server or KeyReporter.

Remote Desktop Server (RDS)

All KeyServer components are compatible with Windows Remote Desktop Server, Citrix XenApp, and all known Thin Client environments.  The KeyServer client (KeyAccess) must be installed on each thin client server you want to support, while the other KeyServer components are optional. The installation essentials are given below. You may also want to read our blog post about how many KeyServer seats will be required for your Thin Client environments.

 KeyAccess

Any Admin account will have sufficient privileges to install KeyAccess as intended (i.e., as a Windows Service).  Run K2Client.exe (the client installer) once on each Remote Desktop Server, entering the proper KeyServer address, and otherwise taking the defaults.  If you ignore the prompt to reboot and instead manually start the KeyAccess Service, KeyAccess will work properly but not as efficiently as it will after a reboot, so it's best to run the installer at a time when you can reboot the server once the install completes.

If you're installing a new version of KeyAccess over a very old one (pre-6.1.3), uninstall the existing KeyAccess first.  You can cancel the prompt to reboot between uninstalling the old version and installing the new one.

KeyAccess has been optimized for minimal processor overhead so even on a Remote Desktop Server running 20 instances of KeyAccess on a single cpu (i.e., with 20 thin client sessions active) it will not tie up undue system resources.

 KeyConfigure

KeyConfigure does not have to be installed on the RDS Server but if installed it will run like any other application program. You may want to restrict access to specific users and make it available to only a few, if any, thin client accounts.

 KeyServer

KeyServer will function properly when hosted on a computer that is also acting as a Remote Desktop Server, and it will provide license management to both thin and regular clients. However, we recommend that you host the KeyServer process on a different computer in order to ensure the best performance from both RDS and KeyServer.

 KeyReporter

KeyReporter is installed by default with KeyServer and will be sub-launched if configured to do so. It can be installed as a standalone on a different computer but it will have reduced functionality when running on its own. KeyReporter will function properly when hosted on a Remote Desktop Server. However, we recommend that you host the KeyReporter process on a different computer in order to ensure the best performance from both RDS and KeyReporter.

Mac OS X

The operating systems "Mac OS X" and "Mac OS X Server" are distinguished only by the different sets of optional applications and OS services included and this makes no difference to any of the K2 components.

 KeyAccess

The client installer is a “flat package” and is named K2Client.pkg. It can be installed on Intel Macs running OS 10.6 and later. It is signed, so that it can be opened on 10.8 (Mountain Lion) and higher with the default Gatekeeper settings. It can be modified using the k2clientconfig script, which will remove the digital signature. An admin password is required to install. Unless you are using a customized installer, the IP address (or DNS name) of the KeyServer will be requested during installation – it can also be entered later in the KeyAccess System Preference interface.

Uninstall

KeyAccess client software for Mac OS X uses a pkg based uninstaller. You will need admin permissions to run the uninstaller, just as you do for the installer. The uninstaller can be found within the full K2 archive:

Installers/Macintosh Installers/Misc/K2Client-Remove.pkg

 KeyConfigure

The Macintosh Admin installer, K2Admin.pkg, also installs the KeyServer ODBC driver in order to support customized reports written in reporting tools such as FileMaker. The OS utility, ODBC Administrator, is used to configure the DSN, ”KeyServer Datasource“, with the correct KeyServer IP address, report account name, and password.

Note: KeyConfigure's "internal reports" can be used to query usage data exported through KeyServer's export feature. An appropriate ODBC driver matching the external database server must be installed on the KeyConfigure computer.

Be aware that ODBC is much more difficult to configure properly and use successfully on OS X than it is on Windows. Be prepared to spend some time getting it to work properly.

 KeyServer

To install KeyServer on Mac OS X, run the K2Server.pkg installer. It will install new components or update any previously installed components to the latest version while preserving your custom configuration information.

The KeyServer installer will offer to start the KeyServer process when the install has completed. You can also do this manually using the AppleScript applet, “ks-StartStop”. To disable KeyServer's automatic startup, use the terminal command:

sudo launchctl unload -w /Library/LaunchDaemons/com.sassafras.KeyServer.plist

Since ks is just a unix program, you can also start it by typing "sudo /Library/KeyServer/ks" in a terminal window. This is useful when you want to see diagnostic output (or when installing a shadow and starting it for the first time), but without being daemonized (the -d option), the ks process will quit when the terminal window is closed.

Command Line options:
The KeyServer program recognizes a few command line options that you can use to control how it runs. The most useful options are listed below. If you need to use any of these options for your KeyServer you should modify the ProgramArguments array in /Library/LaunchDaemons/com.sassafras.KeyServer.plist.

-b <dir>
By default, KeyServer looks for its data folder (KeyServer Data Folder or KSDATA) in the current working directory. If you want to store the data folder in a different location, use this option to specify the directory in which the data folder is stored.
-d
By default, KeyServer runs as a simple console program, and writes basic status information to the terminal in which it was started. If the terminal is closed, the KeyServer will stop running. To run KeyServer as a "daemon" process, use this option. When running as a daemon, KeyServer does not write status information to the terminal, and continues to run even after the originating terminal is closed.
-e <log-file-path>
KeyServer can optionally write some status messages to a separate log file, other than the KeyServer log (where program usage information is stored) and the system log (where startup and shutdown information is written). If you want a simple log of KeyServer's startups and shutdowns, specify the log's location using this option.
-n <hostname>
When KeyServer is running on a multi-homed host (a host with more than one IP address assigned to it as in the case of multiple NIC interfaces), it will by default answer client requests to any of the associated addresses. Use the -n option to force KeyServer to open its service port on a specific IP address. E.g., change the final command in the StartService() routine to also have the -n option, something like: /Library/KeyServer/ks -d -n 123.456.78.9

To use the Unix Authentication method, KeyServer must run on Mac OS X or Linux.

If the KeyServer is supporting third party add-in libraries and/or hardware dongles for custom secure management of pre-keyed third party programs, there will be support libraries with names like rf_xxxx in the KeyServer Data Folder. These third party libraries may need to be upgraded when moving the KeyServer process to different hardware. In particular, older versions of the rf_xxxx files may not be compiled in Universal Binary format in which case they cannot be used on a Macintosh Intel platform.

 KeyReporter

KeyReporter is installed by default with KeyServer and will be sub-launched if configured to do so. It can be installed as a standalone on a different computer but it will have reduced functionality when running on its own. To install a standalone KeyReporter on Mac OS X, run the installer K2Reporter.pkg installer. It will install new components or update any previously installed components to the latest version while preserving your custom configuration information.

KeyReporter uses port 80 by default (the standard HTTP port). If you have a web server running on the same computer you should change the port used by the web server or KeyReporter.

Linux

The KeyAccess, KeyServer, and KeyReporter components can be hosted on Linux. The complete image archive includes rpm and deb installers. There is no KeyConfigure for Linux. KeyAccess and KeyServer have 64 bit installers.

 KeyAccess

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

However, the definition of “interesting programs” can be changed so it goes beyond X11 or includes more paths (or even specific executables). There are also customizable options to trigger auditing without an active user account logged in (e.g., for server audits). Contact Sassafras for details appropriate to various Linux client environments on how to customize and deploy the relevant config file:

/usr/share/ka/ident.xml

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. Note: since there is no KeyConfigure for Linux, there is no way to “key” a Linux program. Of course you can still Manage (and report on) a Linux program on any computer that has the Linux K2 client installed, but without using the keyed option.

On some types of Linux, you can simply double-click the deb or rpm file, and it will be opened by an installer manager and installed. On some other types of Linux, you may instead have to use the command line, e.g., one of the following:

sudo rpm -i KeyAccess-7.4.0.0-201608.i386.rpm sudo rpm -i KeyAccess-7.4.0.0-201608.x86_64.rpm sudo dpkg -i KeyAccess_7.4.0.0-201608_i386.deb sudo dpkg -i KeyAccess_7.4.0.0-201608_amd64.deb

This will install some KeyAccess components in /usr/libexec and will also install kasetup, the program for configuring an address for KeyAccess, in /usr/bin. Once you have installed, you should restart your computer. After you login again, run kasetup from the terminal and enter the KeyServer address, then click Logon. Alternatively, you can set the KeyServer address during the install, if you use the command line to do the install. Use env to set a value for KA_SERVERHOST, for example:

sudo env KA_SERVERHOST=keyserver.domain.com rpm -i KeyAccess-7.4.0.0-201608.i386.rpm sudo env KA_SERVERHOST=keyserver.domain.com rpm -i KeyAccess-7.4.0.0-201608.x86_64.rpm sudo env KA_SERVERHOST=keyserver.domain.com dpkg -i KeyAccess_7.4.0.0-201608_i386.deb sudo env KA_SERVERHOST=keyserver.domain.com dpkg -i KeyAccess_7.4.0.0-201608_amd64.deb

Upgrade

To upgrade using an rpm, you should use the -U command line switch instead of -i:

sudo rpm -U KeyAccess-7.4.0.0-201608.i386.rpm sudo rpm -U KeyAccess-7.4.0.0-201608.x86_64.rpm

Uninstall

To uninstall Linux KeyAccess, use one of the following, depending on your OS:

sudo rpm -e KeyAccess sudo dpkg -r KeyAccess

After a reboot, KeyAccess will no longer be active.

 KeyServer

The KeyServer process requires kernel version 2.2 or higher, version 2.3 or better of the glibc library, and OpenSSL 0.9.8.

The KeyServer components are packaged in an RPM or DEB file. To install the server, use one of the following command lines:

sudo rpm -i KeyServer-7.4.0.0-201608.i386.rpm sudo rpm -i KeyServer-7.4.0.0-201608.x86_64.rpm sudo dpkg -i KeyServer_7.4.0.0-201608_i386.deb sudo dpkg -i KeyServer_7.4.0.0-201608_amd64.deb

This will install the files into /usr/local/k2 with a subdirectory called KeyServer Data Folder. It will also install a startup script in /etc/init.d and configure the computer to run the KeyServer process (ks) at system startup. All files will be installed with root as the owner.

Upgrade

To upgrade using an rpm, you should use the -U command line switch instead of -i:

sudo rpm -U KeyServer-7.4.0.0-201608.i386.rpm sudo rpm -U KeyServer-7.4.0.0-201608.x86_64.rpm

If you are upgrading to K2 7.4 from version 6.1.x or lower, you must move the data folder first, since the standard location is different for KeyServer 6.1:

sudo cp -R /usr/local/KeyServer /usr/local/k2

Starting / Stopping

Once KeyServer is installed, you can start it either by rebooting the host computer or by using a manual command — one of the following, depending on OS:

sudo /sbin/service KeyServer start sudo invoke-rc.d KeyServer start sudo /etc/init.d/KeyServer start

To stop a running KeyServer process, use one of the commands below:

sudo /sbin/service KeyServer stop sudo invoke-rc.d KeyServer stop sudo /etc/init.d/KeyServer stop

Do not use kill -9 unless absolutely necessary, since this does not give KeyServer a chance to flush its file buffers.

Permissions

KeyServer files are installed with root as the owner, and the commands above assume the process will run as root. If you wish to run the KeyServer process in a different account you will need to change the ownership or permissions of the files in /usr/local/k2.

Command Line options:
The KeyServer program recognizes a few command line options that you can use to control how it runs. The most useful options are listed below. If you need to use any of these options for your KeyServer you should modify the startup script that was installed in /etc/init.d.

-b <dir>
By default, KeyServer looks for its data folder (KeyServer Data Folder or KSDATA) in the current working directory. If you want to store the data folder in a different location, use this option to specify the directory in which the data folder is stored.
-d
By default, the "sudo ks" command will run KeyServer as a simple console program and write basic status information to the terminal in which it was started. Running in a terminal window is often useful for diagnostic purposes but when the terminal is closed, the KeyServer will stop. Use the -d option to run KeyServer as a "daemon" process so it will continure to run even after the originating terminal is closed.
-e <log-file-path>
KeyServer can optionally write some status messages to a separate log file, other than the KeyServer log (where program usage information is stored) and the system log (where startup and shutdown information is written). If you want a simple log of KeyServer's startups and shutdowns, specify the log's location using this option.
-n <hostname>
When KeyServer is running on a multi-homed host (a host with more than one IP address assigned to it), it will open its service port on the default IP address. Use this option to force KeyServer to open its service port on a specific IP address.

To use the Unix Authentication method, KeyServer must run on Mac OS X or Linux.

 KeyReporter

The KeyReporter process requires kernel version 2.2 or higher, version 2.3 or better of the glibc library, and OpenSSL 0.9.8.

KeyReporter is installed by default with KeyServer and will be sub-launched if configured to do so. It can be installed as a standalone on a different computer but it will have reduced functionality when running on its own. To install just KeyReporter, use an RPM or DEB installer, and one of the following command lines:

sudo rpm -i KeyReporter-7.4.0.0-201608.i386.rpm sudo dpkg -i KeyReporter_7.4.0.0-201608_i386.deb

Upgrade

To upgrade, you should use the -U command line switch instead of -i:

sudo rpm -U KeyReporter-7.4.0.0-201608.i386.rpm sudo rpm -U KeyReporter-7.4.0.0-201608.x86_64.rpm

Ports

KeyReporter uses port 80 by default (the standard HTTP port). If you have a web server running on the same computer you should change the port used by the web server or KeyReporter.

Solaris

The “Installers/Solaris Installers” folder in the archive includes installers for the Solaris client, server, and reporter. There is no KeyConfigure for Solaris.

 KeyAccess

The Solaris client is compiled from the same source as the Linux client with appropriate adjustments for Solaris OS calls and linked libraries. It implements most of the same functionality as the Windows and Mac clients.

On Solaris, “interesting programs” are defined by the client as those that 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 one of two directories:

/opt /usr

However, more paths (or specific executables) can be added by editing the config file on each client computer:

/usr/share/ka/ident.xml

The K2 client for Solaris 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. Note: since there is no KeyConfigure for Solaris, there is no way to “key” a Solaris program. Of course you can still Manage (and report on) a Solaris program on any computer that has the Solaris K2 client installed, but without using the keyed option.

The client installer for Solaris is a Solaris package compressed for downloading:

KeyAccess-<version>-<platform>.pkg.gz

where <version> is the KeyAccess version (e.g., 7.4.0.0) and <platform> is one of "i386" or "sparc". To install it, do this as root (assuming the KeyAccess-<version>-<platform>.pkg.gz file was downloaded to /tmp):

cd /tmp gunzip KeyAccess-<version>-<platform>.pkg.gz pkgadd -d KeyAccess-<version>-<platform>.pkg

The pkgadd program will ask which package you want to install.  Select "KeyAccess", then answer "y" (yes) to the subsequent questions.  The first question just confirms that you want to install KeyAccess, and the second question asks permission to run the installer script.

This will install some KeyAccess components in /usr/libexec and will also install kasetup, the program for configuring an address for KeyAccess, in /usr/bin.

Once pkgadd has finished installing KeyAccess, you must log out of any desktop sessions (and then re-login) in order to get the KeyAccess user agent to run. After you login again, run kasetup from the terminal and enter the KeyServer address, then click Logon. Alternatively, you can set the KeyServer address during the install, by using env to set a value for KA_SERVERHOST, for example:

sudo env KA_SERVERHOST=keyserver.domain.com pkgadd -d KeyAccess-<version>-<platform>.pkg

Uninstall

To uninstall Solaris KeyAccess, run the following command line as root:

pkgrm KeyAccess

After a reboot, KeyAccess will no longer be active.

 KeyServer

The KeyServer process requires Solaris 9 or higher and OpenSSL. The sparc executable requires OpenSSL 0.9.8 while the i386 compile requires OpenSSL 0.9.7. The server installer for Solaris is a Solaris package compressed for downloading:

KeyServer-<version>-<platform>.pkg.gz

where <version> is the KeyServer version (e.g., 7.4.0.0) and <platform> is one of "i386" or "sparc". To install it, do this as root (assuming the KeyServer-<version>-<platform>.pkg.gz file was downloaded to /tmp):

cd /tmp gunzip KeyServer-<version>-<platform>.pkg.gz pkgadd -d KeyServer-<version>-<platform>.pkg

The pkgadd program will ask which package you want to install.  Select "KeyServer", then answer "y" (yes) to the subsequent question, which asks permission to run the installer script.

This will install some KeyServer components in /opt/sfw/k2, and attempt to start the server. You can determine if the KeyServer has started by using ps with the option to include processes owned by all users, and looking for the ks command. If it has not started, you can look at the services log file to determine what might be wrong. It is usually found in:

/var/svc/log

In order to manually start KeyServer, use the svcadm command:

sudo svcadm enable application/keyserver

In order to manually stop KeyServer, use the svcadm command:

sudo svcadm disable application/keyserver

Do not use kill -9 unless absolutely necessary, since this does not give KeyServer a chance to flush its file buffers.

KeyServer files are installed with root as the owner, and the commands above assume the process will run as root. If you wish to run the KeyServer process in a different account you will need to change the ownership or permissions of the files in /usr/local/k2.

Command Line options:
The KeyServerprogram recognizes a few command line options that you can use to control how it runs. The most useful options are listed below. If you need to use any of these options for your KeyServer you should modify the service file that was installed at /var/svc/manifest/application/keyserver.xml.

-b <dir>
By default, KeyServer looks for its data folder (KeyServer Data Folder or KSDATA) in the current working directory. If you want to store the data folder in a different location, use this option to specify the directory in which the data folder is stored.
-d
By default, the "sudo ks" command will run KeyServer as a simple console program and write basic status information to the terminal in which it was started. Running in a terminal window is often useful for diagnostic purposes but when the terminal is closed, the KeyServer will stop. Use the -d option to run KeyServer as a "daemon" process so it will continure to run even after the originating terminal is closed.
-e <log-file-path>
KeyServer can optionally write some status messages to a separate log file, other than the KeyServer log (where program usage information is stored) and the system log (where startup and shutdown information is written). If you want a simple log of KeyServer's startups and shutdowns, specify the log's location using this option.
-n <hostname>
When KeyServer is running on a multi-homed host (a host with more than one IP address assigned to it), it will open its service port on the default IP address. Use this option to force KeyServer to open its service port on a specific IP address.

Uninstall

To uninstall Solaris KeyServer, run the following command line as root:

pkgrm KeyServer

 KeyReporter

KeyReporter is installed by default with KeyServer and will be sub-launched if configured to do so. It can be installed as a standalone on a different computer but it will have reduced functionality when running on its own. The KeyReporter process requires Solaris 9 or higher and OpenSSL. The sparc executable requires OpenSSL 0.9.8 while the i386 compile requires OpenSSL 0.9.7. The reporter installer for Solaris is a Solaris package compressed for downloading:

KeyReporter-<version>-<platform>.pkg.gz

where <version> is the KeyReporter version (e.g., 7.4.0.0) and <platform> is one of "i386" or "sparc". To install it, do this as root (assuming the KeyReporter-<version>-<platform>.pkg.gz file was downloaded to /tmp):

cd /tmp gunzip KeyReporter-<version>-<platform>.pkg.gz pkgadd -d KeyReporter-<version>-<platform>.pkg

The pkgadd program will ask which package you want to install.  Select "KeyReporter", then answer "y" (yes) to the subsequent question, which asks permission to run the installer script.

This will install some KeyReporter components in /opt/sfw/k2, and attempt to start KeyReporter. You can determine if the KeyReporter has started by using ps with the option to include processes owned by all users, and looking for the 'kr' command. If it has not started, you can look at the services log file to determine what might be wrong. It is usually found in:

/var/svc/log

In order to manually start KeyReporter, use the svcadm command:

sudo svcadm enable application/keyreporter

In order to manually stop KeyReporter, use the svcadm command:

sudo svcadm disable application/keyreporter

KeyReporter uses port 80 by default (the standard HTTP port). If you have a web server running on the same computer you should change the port used by the web server or KeyReporter.

Uninstall

To uninstall Solaris KeyReporter, run the following command line as root:

pkgrm KeyReporter