Previous Topic: Customizing Linux Appliance BehaviorNext Topic: Linux APK

Using CA AppLogic › Appliance Developer Guide › Appliance OS Installations › Common Components › Customize Appliance Behavior › Customizing Appliance Behavior

Customizing Appliance Behavior

You can customize the automatic behavior of the startup script to provide the appliance with custom functionality

Define the following parameters in one of the following files:

 /etc/sysconfig/applogic_init 
\applogic\config\applogic_init

You can modify the existing file or, if needed, create a new file.

Appliance Init Configuration

If the file /etc/sysconfig/applogic_init or \applogic\config\applogic_init is present, the APK init script reads it as a shell include script with the "." command. If not present, it is simply skipped.

Important: The /etc/sysconfig/applogic_init file is executed before any configuration data is retrieved or applied. The script cannot rely on the presence of any appliance configuration files. Do not use this file for executing initialization code. Use the file only for defining the following configuration variables.

Example /etc/sysconfig/applogic_init: 

APK_CONFIG_FILES=/etc/httpd/conf.d/myconfig.conf
APK_AUTH_KEY_PATH=/root/.ssh/alternate_keys

For additional information on the appliance startup scripts, refer to Appliance Startup and Hooks in the Tie Boundary to Interior section of this guide. For instructions on creating, configuring, and finalizing appliances, begin with the Appliance Overview section. The overview provides procedures and diagrams as well as the concepts about appliance creation.

You can define the following parameters:

Parameter

Description

APK_AUTH_KEY_PATH

Location in which to store the appliance SSH access public key. The 3t comp ssh command connects to appliances using the matching private key. Default is /home/Administrator/.ssh . If set to an empty string, the key will not be stored anywhere.

The value for this parameter should be a full path (must begin with '/') and may be either an existing directory or a file name.

If the specified value is an existing directory, the key will be stored in a file named

$APK_AUTH_KEY_PATH/authorized_keys

Otherwise, it is assumed to be a literal file name where the key should be stored.

If the specified location is an existing file, its owner and permissions will be preserved. Otherwise the file will be created with owner root.

APK_CONFIG_FILES

Space separated list of files to which to apply appliance properties.

An appliance using the APK will used the APK_CONFIG_FILES list located on the appliance itself, not the list specified in the GUI.

If the appliance is not using the APK, this replaces the config file list specified in the Modify Boundary dialog in the GUI.

Important: If installing the APK in an existing appliance, verify the configuration files in the class descriptor. The class descriptor is located on the Config Files tab of the Modify Boundary dialog in the Infrastructure Editor. Transfer the list of files to the APK_CONFIG_FILES setting in the appliance.

APK_CONFIG_DNS

Controls the updates of the system name resolver configuration.

Values:

  • yes - the APK updates the system resolver configuration (/etc/resolv.conf file on Linux and DNS settings using netsh command on Windows) with the values configured on the CA AppLogic grid. (Default)
  • no - the APK will not perform any updates.

APK_DISABLE_NTPCONFIG

Disables the NTP daemon from synchronizing to the time on the server that is hosting the appliance.

Values:

  • no - enables the time sync (default)
  • yes - disables the time sync

If NTP is installed and APK_DISABLE_NTPCONFIG is set to No or not defined, the APK configures the NTP daemon to synchronize to the time on the server that is hosting the appliance.

The APK does not attempt to start the NTP daemon, only prepares the configuration.

APK_CONFIG_EXTIFC

Enables the APK configuration of external raw interfaces

  • yes - enables the configuration (default)
  • no - disables the configuration

If installing a new version of the APK on an old appliance that was created before the APK auto-configured external interfaces, set to value to No.

These appliances do not expect the APK to configure the external interface and usually fail if it does.

APK_HOSTNAME_UPDATE

Setting this parameter to No disables the default behavior of changing the hostname to a string derived from the instance name of the appliance. In Windows, the hostname is also known as the computer name.

Disabling the automatic hostname change may be desirable for Virtual Private/Dedicated Server appliances, where the appliance owner maintains all aspects of its configuration, including the hostname.

Important! If APK_HOSTNAME_UPDATE is set to Yes or not set at all, the hostname change triggers a reboot of the OS. This occurs on the first start, or whenever the instance name of the appliance is changed and restarted.

Because this reboot is done before APK reports successful start, the observed effect of this is that the appliance appears as if it takes twice as long to start.

If a reboot was triggered by the APK, a message about entering maintenance mode in the startup progress detail displays.

APK_AUTOMOUNT

Setting this parameter to No disables the automatic assignment of drive letters or mount points, as specified in the appliance class. This also disables all volume state checks in APK.

Important! This option must be used if the appliance is outfitted with a CD-ROM device configured by assigning an ISO-formatted image as one of its virtual disks. APK auto-mounting does not work in this particular combination and will cause the appliance start to fail.

Appliance Post Start Check

If the file /etc/sysconfig/applogic_appliance or \applogic\config\applogic_appliance is present, the APK late init script reads it as a shell include script with the "." command, after all other services on the appliance have been started. The return status from the script indicates whether the appliance is to be considered started OK or failed.

If the script prints a message to stderr and returns an error, the last line from this message is used as the error message sent to the controller.

Example post-start check file for a web server appliance. This verifies that the server is up and responds to HTTP GET to the home page: 

if ! wget -q -O /dev/null http://localhost/ ; then
echo "start failed - Web server is not responding" >&2
return 1
fi
return 0

Avoid using /etc/sysconfig/applogic_appliance as startup script to launch appliance services. Doing this will prevent your setup from being used or tested outside of an appliance which has APK installed.

Important: The applogic_appliance, post-start check is initiated after the Windows SCM (service control manager) has loaded all services - NOT when they have completed initializing. This is different from other platforms supported by the APK.

In Windows, some services are started by other services using an API call, rather than as an explicit dependency. These cannot be accounted for simply by waiting on the automatic services load completion event. Any 'startup check' code added to the /etc/sysconfig/applogic_appliance file must account for this and wait for any services that it needs to monitor in case they have not yet initialized.