Instalación del <APK> para distribuciones de RedHat y CentOS Linux

Creación de dispositivos › Instalaciones de distribución › Instalación del kit para dispositivos para distribuciones de RedHat y CentOS Linux

Instalación del kit para dispositivos para distribuciones de RedHat y CentOS Linux

Archivos

apk-ver-linux-rg.tar.gz: el kit para dispositivos
domu-linux-lver.tar.gz: kernel paravirtualizado y biblioteca de módulos

Compatibilidad

Las versiones de apk-*-linux-rh son compatibles con las distros de los SO siguientes:

Fedora Core (3 y posteriores)
Red Hat EL 4 y 5
CentOS 4.x y CentOS 5.x.

Para instalar el APK necesita una de las siguientes:

Una imagen de dispositivo de CA 3Tera AppLogic anterior (con o sin APK instalado)
Una instalación de la distro del SO original

La imagen debe estar con el sistema de archivos ext3, si se van a utilizar el kernel proporcionado por el APK y los archivos initrd.

Preparación de la imagen

Importante: Las versiones del APK para Linux únicamente son compatibles con la instalación de máquina virtual PVM, usando la compilación del kernel de Linux proporcionada por CA 3Tera AppLogic. El script de instalación borrará todos los archivos de configuración de GRUB que encuentre en la imagen de destino, de modo que no podrá arrancar en modo HVM. Guardar el archivo de GRUB (y no borrar el kernel del SO predeterminado como se documenta más adelante) podría permitir el uso del APK en un dominio de Linux, pero no se admite y no se garantiza que funcione. En concreto, el cierre del dispositivo limpio no funcionará en modo HVM, ni tampoco el montaje automático de volúmenes según las rutas de montaje especificadas en el descriptor de clase de CA 3Tera AppLogic.

Los pasos siguientes pueden variar, en función de cómo se instaló el SO originalmente. El script de instalación del APK no los lleva a cabo, sino que su realización se efectúa según el criterio del administrador, porque algunos de ellos son invasivos y pueden ser destructivos si accidentalmente se llevan a cabo en un sistema en vivo (en lugar de en la imagen que se está preparando); por lo tanto, no se aconseja ejecutarlos en un script automatizado. Omita los pasos que no sean apropiados.

Para preparar la imagen

Compruebe que la imagen de disco es un sistema de archivos ext3.
Si el SO se ha instalado como ext2, ejecute el comando siguiente para convertir la imagen en ext3.
```
tune2fs -j
```
Para utilizar ext2 (o cualquier sistema de archivos distinto de ext3), es preciso volver a generar el archivo initrd que se distribuye con el APK.
Ejecute el comando siguiente para eliminar los archivos de configuración de red:
```
rm /etc/sysconfig/network-scripts/ifcfg-eth* 
```
Edite el archivo etc/fstab y cambie el nombre del dispositivo raíz por /dev/hda1.
El instalador también comprueba e imprime una advertencia si detecta que el dispositivo raíz se ha especificado mediante etiqueta o UUID.
Ejecute el comando siguiente para suprimir el paquete de kernel (omita este paso si se va a generar una imagen para ejecutarla en modo de emulación de hardware).
```
rpm --root path/to/image -e --nodeps kernel
```
O bien, si el proceso se realiza en un shell de "vol manage":
```
chroot  path/to/image rpm -e --nodeps kernel 
```
Desinstale todos los servicios del SO que no se vayan a usar.

Nota: Después de limpiarse, el volumen se puede encoger para producir una imagen de volumen de inicio más pequeña para el dispositivo; sin embargo, hay que comprobar que se dejan al menos 10-15 MB de espacio libre, de modo que haya espacio para instalar el APK y el kernel de XEN DomU y para los archivos de registro, archivos temporales, etc.

Instalación del APK

En las instrucciones de instalación que se facilitan aquí se da por hecho que la instalación del APK se lleva a cabo en una imagen del SO que no está realmente en ejecución pero se ha preparado con antelación, ya sea instalando un SO limpio, cerrándolo y tomando la imagen del disco de arranque, o bien actualizando un dispositivo de CA 3Tera AppLogic existente con una nueva versión del APK.

También se puede realizar la instalación en vivo (en un SO en ejecución) y se puede utilizar con la utilidad iso2class suministrada en CA 3Tera AppLogic Service Pack 2.4.5 y posteriores. Sin embargo, tenga en cuenta que iso2class creará un dispositivo HVM automáticamente, y que el APK no funciona en modo HVM; el dispositivo se tiene que cambiar al modo paravirtualizado después de instalar el APK. Para instalar en un sistema en vivo, siga los pasos siguientes, pero utilice / como directorio actual para todas las operaciones. Esto se hace mejor en una máquina virtual XEN (por ejemplo, utilizando "iso2class"); si se lleva a cabo en un sistema bare-metal (instalación directamente en el hardware), se obtendrá una máquina no de arranque.

Para instalar el APK

Monte la imagen del SO en el sistema de archivos.
Si la imagen ya está instalada como un volumen en un grid de CA 3Tera AppLogic, se puede acceder a ella mediante el comando vol manage.
Copie los archivos del APK en el directorio /tmp de la propia imagen o en un directorio provisional en el host donde se monta la imagen. Si la imagen ya está en un grid, copie los archivos en la propia imagen utilizando la interfaz Web. (Si el proceso no se lleva a cabo en un grid: tenga en cuenta que las operaciones siguientes se deberán ejecutar como raíz de usuario).

Importante: El APK necesita el paquete dhclient para funcionar. No se instala de forma predeterminada en CentOS5. Instale el paquete dhclient en su imagen antes de instalar el APK.

Los RPM de dhclient se pueden instalar en una imagen del SO no en vivo (por ejemplo, montado en el shell de "vol manage"), mediante chroot. El RPM debería estar disponible en cualquiera de los sitios duplicados de CentOS (por ejemplo, http://mirror.stanford.edu/yum/pub/centos/5.1/os/i386/CentOS/dhclient-3.0.5-7.el5.i386.rpm).

Para instalar el paquete dhclient

Desempaquete el kernel de DomU y el archivo de archivado binario del APK en el directorio raíz de la imagen. A continuación se muestra un ejemplo de los comandos que se deben ejecutar:
```
cd /mnt/vol 
tar -zxf tmp/domu-linux-2.6.18.8.386.tar.gz # ** ¡véase la nota más adelante! 
tar -zxf tmp/apk-2.0.14-rh.tar.gz 
```
El script de instalación se desempaquetará en el directorio ./tmp.

Importante: Use el archivo de archivado de domu-linux correcto para su arquitectura de distro. La instalación de un kernel de 32 bits no funcionará con una distro de 64 bits.
Ejecute el script de instalación siguiente:
```
tmp/apk-install 
```
El script de instalación (y los archivos tar, si se copiaron en la propia imagen) se pueden eliminar ahora ejecutando el comando siguiente:
```
rm tmp/apk-install tmp/domu-linux-*.tar.gz tmp/apk-*.tar.gz 
```
Nota: Los scripts de init proporcionados por el APK ya no son compatibles con los scripts específicos del dispositivo instalados en "/appliance". Si está presente, el script de instalación se detendrá y solicitará información al usuario. Si no se ha llevado a cabo ninguna personalización específica del dispositivo en este directorio (esto es, su contenido es el mismo o similar al de LUX), se puede suprimir sin riesgo. Toda la funcionalidad estándar que se solía instalar allí la proporciona ahora el APK. De lo contrario, haga clic en guardar para guardarlo en /tmp y continuar con la instalación.
Desmonte la imagen e impórtela a su grid de CA 3Tera AppLogic (o bien, cierre el shell de vol manage, si la imagen estaba ya en su grid y se ha editado mediante vol manage).
Si la imagen era la de un dispositivo existente, realice lo siguiente:
1. Edite la clase (mediante el editor de GUI) y elimine los nombres de archivo initrd y del kernel.
2. Establezca el modo de configuración como dhcp.

Configuración del dispositivo init

Si el archivo /etc/sysconfig/applogic_init está presente, el script init del APK lo interpreta como un shell que incluye un script (con el comando "."). Los parámetros siguientes se pueden definir en /etc/sysconfig/applogic_init:

APK_AUTH_KEY_PATH

Ubicación en la que se almacenan la clave pública de acceso de SSH del dispositivo. El comando 3t comp ssh se conecta a los dispositivos mediante la clave privada correspondiente. El valor predeterminado es /root/.ssh. Si se establece como una cadena vacía, la clave no se almacenará en ningún sitio.
Si la ubicación especificada es un archivo existente, se conservarán el propietario y los permisos. De lo contrario, el archivo se creará con el propietario "raíz".

APK_CONFIG_FILES

Lista de archivos separados por espacios a los que se aplican propiedades de dispositivo. Sustituye la lista de archivos de configuración especificada en el cuadro de diálogo Modificar límite de la GUI (para los dispositivos que no están utilizando APK). Un dispositivo equipado con el APK utilizará la lista APK_CONFIG_FILES que se encuentra en el propio dispositivo, y no la lista especificada en la GUI.
Importante: Si se instala el APK en un dispositivo existente, compruebe en el descriptor de clase (mediante el editor de GUI) la presencia de archivos de configuración en la ficha Archivos de configuración del cuadro de diálogo Ver clase / Modificar límite. Transfiera la lista de archivos a la configuración APK_CONFIG_FILES en el dispositivo.

Importante: El archivo /etc/sysconfig/applogic_init se ejecuta antes de recuperar o aplicar cualquier dato de configuración, por lo tanto el script no puede confiar en la presencia de ninguno de los archivos de configuración del dispositivo. No utilice este archivo para ejecutar código de inicialización, solamente para las variables de configuración definidas anteriormente.

Ejemplo /etc/sysconfig/applogic_init:

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

Comprobación del dispositivo después del inicio

Si el archivo /etc/sysconfig/applogic_appliance está presente, el script late init del APK lo interpreta como un shell que incluye un script (con el comando "."), después de que todos los servicios del dispositivo se hayan iniciado. El estado de retorno del script indica si se considerará que el dispositivo se ha iniciado correctamente (started OK) o no se pudo iniciar (failed). Si el script imprime un mensaje en stderr y devuelve un error, la última línea de este mensaje se utilizará como el mensaje de error que se envíe al controlador.

Ejemplo de un archivo de comprobación después del inicio para un dispositivo de servidor Web; comprueba que el servidor está en funcionamiento y responde a HTTP GET a la página principal:

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

Importante: Algunos dispositivos del catálogo del sistema usan un script personalizado que se encuentra en /appliance para inicializar servicios. Esto ya no se admite. Este directorio se suprime cuando se instala el APK, para mantener limpia la estructura del directorio raíz y que sea compatible con el Estándar de Jerarquía de Sistema de Archivos. Se puede mover el código de estos scripts a /etc/sysconfig/applogic_appliance, a fin de emular el comportamiento anterior, pero no es intención del archivo de comprobación después del inicio y no se recomienda. En cambio, un servicio instalado debería tener su propio script init y en general debería ser capaz de funcionar completamente fuera de CA 3Tera AppLogic.

Enviar correo electrónico a CA Technologies acerca de este tema