For Windows 2008 Server (32-bit and 64-bit).
The apk-*-windows versions are compatible with the following OS distros:
To install the APK you need the following:
The following steps may vary, depending on how the OS was originally installed. The APK setup script does not perform these steps, which are up to the discretion of the operator to perform. Some of these steps require GUI access and an automated script may not be able to execute them. Other steps are invasive and may be destructive. Therefore running these steps in an automated script may be inadvisable.
Skip any steps that are not appropriate.
Note: Failure to install the updates on Windows 2008 can cause the APK to fail.
Note: Enabling remote administration is different from configuring the OS as a Terminal Server. Configuring the OS as a Terminal Server requires paid licenses for each client. Enable remote administration only if this is the intended use of the installation.
Note: The minimum Windows 2003 installation requires over 1GB of disk space. Windows 2008 needs nearly 8GB for the full installation (less for the server core). Leave adequate room for installing CygWin and the Windows Update hotfixes (keep in mind that Windows will retain All previous versions of the binary files replaced by the hotfixes). Verify that at least 5 to10MB of free space is available for installing the APK and for extra space for log files, temporary files, and so on.
Install the APK on a live system. You cannot install the APK for Windows into a mounted OS disk image that is not actually running. For best results, use an OS image that has external network access configured and log into it using a remote desktop client from your favorite OS (for example, rdesktop). This provides better interactive operation than using VNC to see the HVM emulated video screen.
cd / gtar -zxf tmp/apk-2.0.10-windows.tar.gz
bash tmp/apk-install
This should complete without any error messages. If there are any error messages, check the preparation steps above and retry the procedure.
Note: It is safe to rerun the install script multiple times, it will not damage the installation in any way.
The setup script and the APK tar file can be removed by performing the following:
rm tmp/apk-install tmp/apk-*.tar.gz
If the image preparation was done outside of a CA AppLogic® grid, the image can now be copied into a grid and used to create an appliance.
If the image was created on a grid as a new OS installation: disable the unmanaged appliance option by unchecking the Field Engineering Code check box.
Verify that the Device Schema is set to hda/hdb/hdc/hdd for IDE disk drives or sda/sdb/sdc/sdd for SCSI disk drives (in the Editor: Modify Boundary, General, Virtualization Mode, Advanced).
File Names
Unless otherwise stated, names in this document are in the CygWin file namespace, which emulates a Posix system.
Note: These names cannot be used with any non-Cygwin utilities. This includes the APK binaries themselves (vme and udlparse), and all of the native Windows command line tools. Most Cygwin utilities will accept either a CygWin name (posix-style) or a Windows name (for example, C:\path\), with the exception of those that consider strings with ":" in them to mean computername:filename, for example, scp, rsync, and notably tar. The latter can be forced to accept a Windows name with the --force-local option.
To convert a file name between the Windows and Cygwin namespaces, use cygpath.
windowspath=`cygpath -w /var/applogic/appliance.desc`
Disk Mounts
When specifying a mount point for disks, use the following names, as desired:
X - a single letter (A,B,D-Z) will make the disk accessible as X:\.
X:\ - same as X
C:\dir1\[dir2\...] - makes the disk accessible in the given sub-directory of the boot file system. If the directory does not exist, it will be created.
Note: It is not recommended to allow the APK to create the directory, because the default directory permissions may not be what you want them to be.
Leaving a disk without a mount point specified in the class descriptor will cause APK to ignore the disk and leave its mount assignment in Windows as-is. In this case, any mount point assignment for that disk done manually from Windows itself is persistent and takes priority over assignment of the same mount point to another disk via the class descriptor (the latter assignment will have no effect and will leave the disk unmounted). For example, if you have specified this in the class editor / Modify dialog:
disk 0 -> (boot)
disk 1 -> (no mount assigned)
disk 2 -> Z:\
and you log into the appliance, remove Z from disk2 and assign it to disk1, then Z will stay assigned to disk1 across reboots and the 'disk2 -> Z' assignment in the class descriptor will not take effect. Disk2 will not be mounted anywhere, until Z is removed from disk1 or something other than Z is set for disk2.
C:\ is reserved and cannot be assigned as the mount point for any disk. Any assignment for the boot disk will be ignored and it will be reported as mounted on C:\ in the appliance instance descriptor.
Do not use mount paths with sub-directories on any drive except C:. Doing this may cause your mount not to be useable, as it depends on the order in which the disks are mounted.
Keep in mind that Windows will not refuse to mount an unformatted disk (or one formatted with a file system that is not understood by Windows). There will be no error or warning at all when the mount is assigned by APK, but attempts to access the mount point and any subpaths of it will fail.
User Names
The APK installation script will make the CygWin alias for the Administrator be root. Therefore, root will be the user name seen by any CygWin binary and will show up as the current user name in a CygWin shell, and in directory listings. This setting allows accessing the appliance using the remote shell command ( 3t ssh component-name).
Note that the mapping between CygWin user names and Windows user names is not automatic, it is described in the /etc/passwd and /etc/group files, which are not automatically updated when adding/removing Windows users. CygWin includes utilities to maintain the /etc/passwd and /etc/group files. When using these utilities, take care to preserve the special mapping for root created by APK, otherwise ssh login from the grid will stop working.
Appliance Init Configuration
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 |
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. |
|
APK_CONFIG_FILES |
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. |
|
APK_HOSTNAME_UPDATE |
Setting this parameter to No will disable the default behavior of changing the hostname (also known as computer name in Windows) to a string derived from the appliance's instance name. |
|
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. |
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
Appliance Post-start Check
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 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 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
Avoid using /etc/sysconfig/applogic_appliance, as startup script to launch appliance services. Doing this will prevent your setup form being used or tested outside of an appliance which has APK installed.
Important: Windows-specific note: Unlike the other platforms supported by APK, 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. Things are further complicated by the fact that in Windows 2003/2008 some services are started by other services using an API call, rather than as an explicit dependency (and therefore cannot be accounted for simply by waiting on the automatic services load completion event). Therefore any 'startup check' code added to the /etc/sysconfig/applogic_appliance file must account for this and wait for any of the services that it needs to monitor, in case they haven't yet initialized.
|
Copyright © 2012 CA.
All rights reserved.
|
|