The apk-*-linux-ub versions are compatible with the following OS distros:
To install APK you need either:
The image must be with the ext3 file system, if the APK-provided kernel and initrd files will be used.
The Linux versions of APK supports HVM boot for both VMware and for Xen hypervisors. The CA AppLogic supplied PVM kernel is optional.
If the CA AppLogic®-supplied kernel is unpacked prior to running APK install, it will be configured automatically as the kernel to boot when the appliance is booted in PVM mode – a new boot/grub/menu.lst file is created for this. The installed OS-provided kernel will be used in HVM boot (the default OS grub configuration file for Red Hat-compatible operating systems is boot/grub/grub.conf).
If the CA AppLogic®-supplied kernel is unpacked prior to installing APK, it will be set up as the boot kernel in boot/grub/menu.lst. The original GRUB configuration file will be backed up as boot/grub/menu.lst.apkbk. The appliance creator can rename the saved backup and re-configure the GRUB bootloader to use the alternate file name as the configuration file, so that it is picked up when the appliance boots in HVM mode. When booting in PV mode, boot/grub/menu.lst is always used.
If the APK install is executed without unpacking the CA AppLogic®-supplied kernel, the GRUB configuration will remain intact. It is assumed that the appliance will run in HVM mode, or that the OS-provided kernel is capable of booting in Xen PV mode (many of the newer OS distros provide a Xen-PV kernel build, which can be installed and configured as the default).
The following steps may vary, depending on how the OS was originally installed. They are not performed by the APK setup script, and are left to the discretion of the administrator, because some of them are invasive and may be destructive, if accidentally done on a live system (rather than on the image being prepared) - therefore running them in an automated script may be inadvisable. Skip any steps that are not appropriate.
To prepare the image
run tune2fs -j
To use ext2 (or any filesystem other than ext3), the initrd file shipped with APK has to be re-built.
/dev/hda1
The installer will also verify and print a warning if it finds the root device is specified by label or by UUID.
Note: If you need to run other 32-bit executables other than those in APK itself, consider installing the ia32-libs meta-package. The meta-package installs all packages containing 32-bit libraries.
Important! Uninstall or disable NetworkManager. This program will interfere with the CA AppLogic® network configuration. Exception: If setting up a VPS server with graphical user interface, the Network Manager applet may be used to perform manual IP configuration (but it has to be set up in the manual mode prior to booting the new OS installation in CA AppLogic®).
Note: After it is cleaned up, the volume may be shrunk to produce a smaller boot volume image for the appliance, however verify that at least 10-15MB of free space is left, to have space for installing the Xen DomU kernel and APK, and to have some headroom for log files, temporary files, and so on.
APK uses a simple initial ramdisk image (initrd) created with the Red Hat 'nash' bootstrap program. It does not load any kernel modules and its only purpose is to set up the ramdisk-based /dev/ directory for the udev program and populate it.
It works fine in booting an Ubuntu-based virtual appliance and there is no need to create a ubuntu-style initrd image for the appliance. The Ubuntu 6/7 initrd images are heavier and have more advanced functionality, which is not necessary in most appliances. If desired, a Ubuntu-specific initrd file can be created and used. Simply edit the /boot/grub/menu.lst file to point to an alternate initrd image. Note that this change will have to be re-applied should you re-install APK in the future.
The installation instructions given here assume that APK install is being done an OS image that is not actually running, but has been prepared ahead of time, either by installing a clean OS, shutting it down and taking the boot disk image, or an existing CA AppLogic® appliance is being upgraded with a new version of APK.
Live install (on a running OS) is also possible, and can be used with the iso2class utility provided in CA AppLogic® Service Pack 2.4.5 and later. To install on a live system, follow the steps below, but use / as the current directory for all operations. This is best done in a Xen virtual machine (for example, using iso2class). If the APK is installed only with the CA AppLogic® Xen PV kernel, this will result in an unbootable machine.
Mount the operating system image in your file system. If you already installed the image as a volume on a CA AppLogic® grid, access it using the vol manage command. Copy the APK files to the /tmp directory on the image itself, or copy the files to a temporary directory on the host that contains the mounted image. If the image is already on a grid, copy the files to the image itself using the Web interface. The following operations require user root if you are not doing this task on a grid.
To install the APK
cd /mnt/vol tar -zxf tmp/domu-linux-2.6.18.8.i386.tar.gz tar -zxf tmp/apk-2.0.14-ub.tar.gz
The setup script will be unpacked into the ./tmp directory.
Important! Use the correct domu-linux archive for your distro architecture. Installing a 32-bit kernel will not work on a 64-bit distro.
tmp/apk-install
Note: The APK-supplied init scripts no longer support appliance-specific scripts installed in /appliance. If present, the install script stops and prompts for user input. If no appliance-specific customization was done in this directory, it is safe to delete it. For example, its contents are the same or similar to what is found on LUX. All of the standard functionality that used to be installed there is now provided by APK. Otherwise, click save to /tmp and proceed with the install.
You can remove the setup script and the tar files, if they were copied to the image itself:
rm tmp/apk-install = =tmp/domu-linux-*.tar.gz = tmp/apk-*.tar.gz=
vol manage
For full details refer to the User Guide.
If the file /etc/sysconfig/applogic_init is present, the APK init script reads it as a shell include script (with the "." command). The following parameters can be defined in /etc/sysconfig/applogic_init :
|
APK_AUTH_KEY_PATH |
Specifies the 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 /root/.ssh. If set to an empty string, the key will not be stored anywhere. |
|
APK_CONFIG_EXTIFC |
Enables automatic IP configuration of external interfaces, if it is provided in the application. Set this value to no to disable the IP configuration of external interface. This value also makes APK behave such as the previous version that did not have support for the external interfaces configuration. Default: Yes Important! Set APK_CONFIG_EXTIFC=no if you installed the new CA AppLogic® 3.5 APK into an appliance with an external interface that is designed to work on a pre-3.5 grid. These appliances use properties to configure the external network. This setting has no effect for appliances without external interfaces. |
|
APK_CONFIG_FILES |
Specifies a space-separated list of files to which to apply appliance properties. This replaces the config file list specified in the Modify Boundary dialog in the GUI (for appliances that are not using APK). An appliance outfitted with APK will use the APK_CONFIG_FILES list found on the appliance itself, not the list specified in the GUI. Important: If installing APK in an existing appliance - check in the class descriptor (using the editor GUI) for the presence of configuration files in the Config Files tab found in the View Class / Modify Boundary dialog. Transfer the list of files to the APK_CONFIG_FILES setting in the appliance. |
Important! The /etc/sysconfig/applogic_init file is executed before any configuration data is retrieved or applied, therefore the script cannot rely on the presence of any of the appliance's configuration files. Do not use this file for executing initialization code, only for the configuration variables defined above.
Example /etc/sysconfig/applogic_init:
APK_CONFIG_FILES=/etc/httpd/conf.d/myconfig.conf APK_AUTH_KEY_PATH=/root/.ssh/alternate_keys
If the file /etc/sysconfig/applogic_appliance is present, the APK late init script reads it as a shell include script (with the "." command), after all 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 will be used as the error message sent to the controller.
Example post-start check file, for a web server appliance - 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
Important! Some appliances in the system catalog use a customized script located in /appliance to initialize services. This is no longer supported. A warning is printed when APK is installed, to keep the root directory structure clean and compliant with the Filesystem Hierarchy Standard. One could move the code from such scripts to /etc/sysconfig/applogic_appliance, to emulate the old behavior but this is not the intention of the post-start check file and is not recommended. Instead, an installed service should have its own init script and in general should be able to operate entirely outside of CA AppLogic®.
|
Copyright © 2012 CA.
All rights reserved.
|
|