Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Guía de iniciación

Red Hat Network Satellite 5.5

Aprovisionamiento e Implementación con Red Hat Network Satellite

Edición 2

Red Hat Engineering Content Services

Resumen

Este documento contiene detalles concisos e instrucciones para usar la funcionalidad de aprovisionamiento de kickstart en Red Hat Network Satellite. Para obtener más información sobre fundamentos de Satélite, consulte la Guía de usuario de satélite.

Capítulo 1. Introducción

Aprovisionamiento es el proceso de configuración de una máquina física o virtual a un estado conocido predefinido. Satélite de RHN aprovisiona sistemas mediante el proceso de kickstart. Para usar la funcionalidad de aprovisionamiento, se requieren una o más máquinas de destino, las cuales pueden ser físicas, sistemas vacíos, o máquinas virtuales. Para usar la funcionalidad de aprovisionamiento de Satélite de RHN, cree las máquinas virtuales mediante XEN o KVM.

Definiciones

Algunos términos a través de este libro:
Kickstarting
El proceso de instalación automática de un sistema de Red Hat que requiere una mínima intervención del usuario. En términos técnicos, kickstart se refiere a un mecanismo en el programa de instalación de Anaconda que permite la escritura en el instalador de una descripción concisa del contenido y configuración de una máquina , en la que luego actúa. La definición concisa del sistema se conoce como Perfil Kickstart.
Perfil Kickstart
El archivo kickstart es un archivo de texto que especifica todas las opciones necesarias para instalar una máquina con kickstart, incluidas la información sobre particiones, configuración de red y paquetes a instalar. En Satélite de RHN, un perfil de Kickstart es un superconjunto de una definición kickstart de Anaconda tradicional, ya que la implementación de Satélite se crea en mejoras de Cobbler para instalación con kickstart. Un perfil Kickstart presume la existencia de un árbol de Kickstart.
Árbol Kickstart
Los archivos de software y soporte necesarios para kickstart una máquina. Este árbol también se llama un "árbol de instalación". Es por lo general la estructura de directorio y archivos obtenidos de los medios de instalación que se distribuyen con un lanzamiento determinado. En terminología de Cobbler, un árbol de Kickstart es parte de una Distro - abreviación de distribution.
PXE (Preboot eXecution Environment)
Un protocolo de bajo nivel que hace posible instalar con kickstart máquinas vacías (por lo general físicas o reales,) encendidas sin preconfiguración de la máquina de destino. PXE depende de un servidor DHCP para informar a clientes acerca de servidores bootstrap (para propósitos de este documento, instalaciones de Satélite 5.5 o superiores). PXE debe estar soportado en el firmware de la máquina de destino para poder ser utilizado. Es posible usar las herramientas de virtualización y reinstalación de Satélite sin PXE, aunque PXE es muy útil para arrancar nuevas máquinas físicas o reinstalar máquinas que no están registradas al Satélite.

Aprovisionamiento de escenarios

Tipos de escenarios de aprovisionamiento soportados por el Servidor de satélite de RHN:
Nuevas instalaciones
Aprovisionar un sistema que no haya tenido un sistema operativo instalado (también se conoce como instalaciones en vacío).
Instalaciones virtuales
Satélite soporta huéspedes KVM y Xen totalmente virtualizados y huéspedes Xen para-virtualizados.
Reaprovisionamiento
Los sistemas físicos y huéspedes pueden ser re-aprovisionados, siempre y cuando estén registrados a la misma instancia de Satélite. Consulte la Sección 2.5.2, “Re-aprovisionamiento”.

Capítulo 2. Kickstart

2.1. Paquetes requeridos

Si está utilizando una distribución personalizada, requerirá los siguientes paquetes, los cuales están disponibles desde cualquier canal de Red Hat Network (RHN) rhn-tools
  • koan
  • spacewalk-koan
Es aconsejable clonar el canal rhn-tools existente para acceder a estos paquetes desde su canal personalizado.
Satélite de RHN espera que los archivos kernel e initrd estén en lugares específicos dentro del árbol kickstart. Sin embargo, estos sitios difieren según la arquitectura. La tabla a continuación explica las diferentes ubicaciones:

Tabla 2.1. Archivos de distribución requeridos por arquitectura

Arquitectura kernel Imagen inicial de disco de RAM
IBM System z RUTA_de_ÁRBOL/images/kernel.img RUTA_de_ÁRBOL/images/initrd.img
PowerPC RUTA_DE_ÁRBOL/ppc/ppc64/vmlinuz RUTA_DE_ÁRBOL/images/pxeboot/vmlinux
Todas las demás arquitecturas RUTA_DE_ÁRBOL/images/pxeboot/vmlinuz RUTA_DE_ÁRBOL/images/pxeboot/initrd.img

2.2. Árboles Kickstart

Debe tener instalado al menos un árbol kickstart en su Satélite para usar aprovisionamiento de kickstart. Los árboles kickstart pueden instalarse de forma manual o automática.

Procedimiento 2.1. Instalación automática de árboles kickstart

Para todas las distribuciones que tienen un canal en RHN;, los árboles kickstart pueden ser instalados de forma automática. Esto sucede como parte de la sincronización normal de canales a través satellite-sync.
  1. Elija la distribución en la que desea basar sus kickstart y ubique ese canal de base de distribución junto con el canal de herramientas de RHN correspondiente.
    Por ejemplo, si desea utilizar Red Hat Enterprise Linux 5 para arquitectura x86, necesitará el canal rhel-i386-server-5 y su correspondiente canal de herramientas de RHN rhn-tools-rhel-i386-server-5.
  2. Si se trata de un Satélite conectado, sincronice el Servidor satélite con los servidores de Red Hat directamente mediante satellite-sync. Si el Servidor satélite se desconecta, deberá obtener los vaciados de canal desconectados desde los servidores de Red Hat y sincronizarlos con ellos.
  3. La sincronización del canal automáticamente creará el árbol kickstart correspondiente a esa distribución.

Procedimiento 2.2. Instalación manual de árboles kickstart

Para instalar con kickstart una distribución personal, una distribución no soportada por Red Hat o la versión beta de Red Hat Enterprise Linux, necesitará crear de forma manual el árbol kickstart correspondiente. Requerirá una instalación ISO para la distribución que está instalando con Kickstart.
  1. Copie la instalación ISO a su Servidor satélite y móntela en /mnt/iso
  2. Copie el contenido de la ISO en un sitio personalizado. Se recomienda crear un directorio dentro de /var/satellite para todas sus distribuciones personalizadas. Por ejemplo, copie el contenido de la distribución RHEL beta en /var/satellite/custom-distro/rhel-i386-server-5.3-beta/
  3. Use la interfaz de red del Satélite de RHN para crear un canal de software personalizado. Utilice CanalesAdministrar canales de softwareCrear nuevo canal para crear un canal principal con un nombre y etiqueta apropiados. Para el ejemplo anterior, use la etiqueta rhel-5.3-beta.
  4. Empuje los paquetes de software del sitio del árbol al canal de software recién creado mediante el comando rhnpush:
    rhnpush --server=http://localhost/APP -c 'rhel-5.3-beta' \  -d /var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/
    El subdirectorio dentro del árbol podría diferir según la distribución.
  5. Una vez que los paquetes de software hayan sido empujados, pueden borrarse de la ruta de árbol mediante el comando rm. Los paquetes aún se almacenan en el servidor de Satélite dentro del canal y ya no se requieren en el árbol.
    rm /var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/*.rpm

    Nota

    Puede elegir dejar los paquetes de software dentro del árbol kickstart. Así podrán ser instalados con el comando yum más adelante.
  6. Use la interfaz de red del Satélite de RHN para crear la distribución. Utilice SistemasKickstartDistribucionesCrear nueva distribución para crear la distribución, con la etiqueta apropiada y la ruta de árbol completa (tal como /var/satellite/custom-distro/rhel-i386-server-5.3-beta/. Seleccione el canal base creado anteriormente y la Generación de instalador correcta (tal como Red Hat Enterprise Linux 5). Para completar la creación, seleccione Crear distribución Kickstart.
  7. Para mantener el mismo software a través de varios entornos y sistemas. el canal de herramientas de RHN de un canal base existente de Red Hat Enterprise Linux puede ser clonado como un canal hijo del canal base creado recientemente. La clonación de un canal hijo puede realizarse mediante:
    1. En la interfaz de red de Satélite, haga clic en CanalesAdministrar canales de softwareClonar canal
    2. Elija el canal hijo que desea clonar desde la cuadro desplegable Clonar desde: y elija el estado del clon.
    3. Haga clic en Crear canal
    4. Complete la información necesaria y elija el canal padre en el que debe estar el canal hijo.
    5. Haga clic en Crear canal
Creación de una distribución Kickstart

Figura 2.1. Creación de una distribución Kickstart

2.3. Perfiles Kickstart

Los perfiles kickstart especifican las opciones de configuración a ser usadas para la instalación.
Los perfiles Kickstart pueden crearse mediante una interfaz de Asistente, la cual genera un perfil con base en las respuestas que usted da a una serie de preguntas. Estas respuestas pueden crearse mediante el método crudo, el cual proporciona un control completo sobre el contenido del perfil.

Procedimiento 2.3. Creación de perfil Kickstart con un asistente

  1. Seleccione SistemasKickstartCrear un nuevo perfil Kickstart
  2. Proporcione una Etiqueta apropiada, y elija el Canal de base deseado y el árbol para Kickstart
  3. Seleccione el Tipo de virtualización. Consulte la Tipos de virtualización para obtener mayor información sobre tipos de virtualización. Haga clic en Siguiente para continuar.
  4. Seleccione el sitio de descarga para el perfil kickstart. Si está utilizando una distribución personalizada, ingrese el sitio de su árbol como una URL (HTTP y FTP son compatibles), de lo contrario, use la opción predeterminada. Haga clic en Siguiente para continuar.
  5. Ingrese la contraseña de root y haga clic en terminar para completar la creación de perfil.
  6. El perfil kickstart completo será creado. Para ver el perfil, haga clic en Archivo Kickstart.

Procedimiento 2.4. Creación de perfiles Kickstart con el método crudo

  1. Seleccione SistemasKickstartCargar un nuevo archivo Kickstart
  2. Proporcione una etiqueta apropiada, y elija la distribución deseada.
  3. Seleccione el Tipo de virtualización deseado. Consulte Tipos de virtualización para obtener mayor información sobre tipos de virtualización.
  4. Si tiene un perfil kickstart existente, cargue el archivo. De lo contrario, escriba el perfil kickstart en el cuadro de texto Contenido de archivo.
    A continuación, una muestra de Kickstart crudo que se puede utilizar como punto de partida:
    install
    text
    network --bootproto dhcp
    url --url http://$http_server/ks/dist/org/1/ks-rhel-i386-server-5
    lang en_US
    keyboard us
    zerombr
    clearpart --all
    part / --fstype=ext3 --size=200 --grow
    part /boot --fstype=ext3 --size=200
    part swap --size=1000   --maxsize=2000
    bootloader --location mbr
    timezone America/New_York
    auth --enablemd5 --enableshadow
    rootpw --iscrypted $1$X/CrCfCE$x0veQO88TCm2VprcMkH.d0
    selinux --permissive
    reboot
    firewall --disabled
    skipx
    key --skip
    
    %packages 
    @ Base
    
    %post
    $SNIPPET('redhat_register')
    
  5. Debido a que el servidor de Satélite de RHN no maneja la distribución especificada como la url en kickstart, necesitará incluir la opción url --url en su perfil, similar a lo siguiente:
    url --url http://satellite.example.com/ks/dist/org/1/my_distro
    Remplace my_distro por la etiqueta de distribución y 1 por su org id.
  6. Los perfiles crudos kickstart usan $http_server en lugar del nombre de host de Satélite. Este se completará cuando se procese la plantilla kickstart.
  7. El fragmento redhat_register se utiliza para manejar el registro.
Kickstart crudo

Figura 2.2. Kickstart crudo

Tipos de virtualización

Todos los perfiles Kickstart tienen un tipo de virtualización asociado a ellos. Esta tabla resume las diferentes opciones:

Tabla 2.2. Tipos de virtualización

Tipo Descripción Uso
ninguno No virtualización Use este tipo para aprovisionamiento normal de tipo, instalaciones vacías e instalación virtualizada que no son Xen o KVM (tales como VMware o Virtage)
Huésped virtualizado KVM Huéspedes KVM Use este tipo para aprovisionar huéspedes KVM
Huésped Xen totalmente virtualizado Huéspedes Xen Use este tipo para aprovisionar huéspedes Xen

Nota

Esta opción requiere soporte de hardware en el host, pero no requiere un sistema operativo en el huésped.
Huésped Xen para-virtualizado Huéspedes Xen Use este tipo para aprovisionar un huésped virtual con paravirtualización XEN. La paravirtualización es el modo más rápido de virtualización. Requiere un indicador PAE en la CPU del sistema, y un sistema operativo modificado. Red Hat Enterprise Linux 5 soporta huéspedes en paravirtualización.
Xen Virtualization Host Hosts Xen Use este tipo para aprovisionar un host virtual con para-virtualización Xen. Los huéspedes Xen para-virtualizados y hosts tienen soporte si el hardware es compatible.
Los perfiles Kickstart creados para hosts Xen deben incluir el paquete kernel-xen en la sección %packages.
Los perfiles Kickstart creados para hosts KVM deben incluir el paquete qemu en la sección %packages.
Los sistemas totalmente virtualizados requieren que el soporte de virtualización esté activado en el menú BIOS en el computador.

Nota

Para obtener mayor información sobre kickstart, consulte el capítulo titulado Instalaciones de Kickstart en la Guía de Instalación de Red Hat Enterprise Linux.

2.4. Plantilla

La plantilla de kickstart le permite incluir variables, fragmentos y declaraciones de control de flujo tales como bucles for y declaraciones if en los archivos kickstart. Esto se realiza mediante la herramienta cheetah.
Hay una variedad de razones por las cuales el uso de plantillas puede ser útil:
  • Para reutilizar una sección específica de un kickstart, tal como una sección de particionamiento de disco, entre múltiples kickstarts.
  • Para realizar algunas acciones %post de forma consistente a través de varios kickstarts.
  • Para definir un fragmento a través de varios roles de servidor tales como un servidor DNS, un servidor proxy y un servidor de red. Por ejemplo, un servidor de red tiene el siguiente fragmento definido:
    httpd
    mod_ssl
    mod_python
    
    Si desea crear un perfil de servidor de red, incluya el fragmento de servidor de red en la sección %package de su archivo Kickstart. Para que un perfil sea tanto servidor de red como servidor de proxy, incluya ambos fragmentos en la sección de paquetes. Si desea añadir otro paquete al fragmento de servidor de red, mod_perl por ejemplo, actualice el fragmento y todos los perfiles que lo están utilizando se actualizarán de forma dinámica.
Variables

La plantilla permite definir una variable que va a ser utilizada a través de un archivo kickstart. Las variables están sujetas a una forma de herencia que les permite establecerse en un nivel y sobrescribirse en niveles inferiores. Por lo tanto, si una variable se define a nivel del sistema, sobrescribirá la misma variable definida en el perfil o niveles de árbol kickstart. De la misma manera, si se define una variable en el nivel de perfil, sobrescribirá la misma variable definida en el nivel de árbol kickstart.

Nota

Observe que esas variables de árbol kickstart no pueden ser definidas para generar de forma automática árboles Kickstart, tales como los que se crearon durante la sincronización de satélite.
Fragmentos

Los fragmentos reutilizan partes del código entre varias plantillas kickstart. Estas pueden extender muchas líneas e incluir variables. Pueden incluirse en un perfil kickstart mediante el texto $SNIPPET('snippet_name'). Puede crear un fragmento para una lista de paquetes, para un %post script o para cualquier texto que normalmente se incluiría en un archivo kickstart.

Para manejar fragmentos, vaya a SistemasKickstartFragmentos Kickstart.
La página de Fragmentos Kickstart muestra varios fragmentos predeterminados que no se pueden modificar, pero que están disponibles para cualquier organización. Los fragmentos predeterminados pueden utilizarse en kickstarts que han sido ya sea escritos o cargados al servidor de Satélite de RHN. Los fragmentos predeterminados se almacenan en el sistema de archivos del servidor satélite de RHN en /var/lib/cobbler/snippets/. Hay una plantilla del kickstart con asistente de estilo en /var/lib/rhn/kickstarts/wizard/, la cual explica los diferentes fragmentos y su uso.
El fragmento redhat_register es un fragmento predeterminado que sirve para registrar máquinas a un servidor de Satélite de RHN como parte de un kickstart. Utiliza una variable especial llamada redhat_management_key para registrar la máquina. Para usar el fragmento, establezca la variable redhat_management_key en cualquier sistema, perfil o nivel de distribución y luego añada $SNIPPET('redhat_register') a una sección de kickstart %post. Cualquier kickstart con asistente de estilo generado por el servidor de Satélite de RHN ya incluirá el fragmento en la sección %post.
La pestaña de Fragmentos personalizados le permite ver y editar fragmentos creados para ser usados por su organización. Para crear nuevos fragmentos haga clic en Crear nuevo fragmento. Los fragmentos personalizados se almacenan en el directorio /var/lib/rhn/kickstarts/snippets/. El servidor de Satélite de RHN almacena fragmentos para diferentes organizaciones en diferentes directorios, con el fin de que los fragmentos personalizados sean almacenados con un nombre de archivo similar al siguiente, donde 1 es la ID de la organización:
$SNIPPET('spacewalk/1/snippet_name')
Si no está seguro de qué texto usar para insertar el fragmento en el kickstart, busque la columna Macro fragmento en la lista de fragmentos o en la página de información de fragmentos.

Nota

Los fragmentos existen en un nivel global y no comparten la misma estructura de herencia que las variables. Sin embargo, se pueden usar variables dentro de fragmentos para cambiar la forma en que se comportan cuando diferentes sistemas solicitan un kickstart.
Fragmentos Kickstart

Figura 2.3. Fragmentos Kickstart

Escape de caracteres especiales

Los caracteres $ y # se utilizan durante el plantillado para especificar variables y controlar el flujo. Si necesita estos caracteres para cualquier otro propósito en un script, necesitará escaparlos para que no sean reconocidos como variables. Esto se puede realizar en varias formas:

  • Sitúe un carácter de barra invertida (\) antes de cada instancia de $ o # que necesite ser ignorada durante el emplantillado.
  • Envuelva el script entero en #raw ... #end raw
    Todos los scripts %pre y %post creados mediante los Kickstarts con asistentes de estilo vienen en #raw...#end raw por defecto. Esto se puede alternar mediante la casilla de verificación de Plantilla disponible durante la edición de un script %post o %pre.
  • Incluya #errorCatcher Echo en la primera línea del fragmento.

Ejemplo 2.1. Escape de caracteres especiales en plantillas

Este ejemplo describe cómo escapar caracteres especiales en plantillas de kickstart.
El siguiente script de bash necesita insertarse en una sección %post:
%post 
echo $foo > /tmp/foo.txt
Sin escapar $, el motor de plantilla tratará de hallar una variable llamada $foo y fallará debido a que foo no existe como variable.
La forma más sencilla de escapar el $ es utilizar un caracter de doble barra invertida (\):
%post 
echo \$foo > /tmp/foo.txt
Esto hará que \$foo se procese como $foo.
Un segundo método es el de envolver el script entero en #raw ... #end raw, así
%post 
#raw  
echo $foo > /tmp/foo.txt 
#end raw
El método final es simplemente incluir #errorCatcher Echo en la primera línea de su plantilla kickstart. De este modo le pide al motor de plantilla que ignore las variables inexistentes y que imprima el texto tal como está. Esta opción ya se incluye en los kickstart con asistente de estilo, pero también se puede incluir en los kickstart crudos que usted mismo crea.

2.5. Instalación de una máquina con Kickstart

2.5.1. Kickstarting desde una máquina vacía

Cuando una máquina no tiene un sistema operativo existente o si tiene un sistema operativo instalado errado, se conoce como una máquina vacía. Hay dos formas de aprovisionar una maquina vacía:
  • Medios de instalación del sistema operativo estándar
  • Arranque PXE

Procedimiento 2.5. Arranque desde medios de instalación

  1. Inserte el medio de instalación en la máquina. Los medios deben coincidir con el kickstart que va a usar. Por ejemplo, si su kickstart estaba configurado para usar el árbol de kickstart ks-rhel-i386-server-5-u2, use el medio de instalación de Red Hat Enterprise Linux 5.2 i386.
  2. Cuando se le indique arrancar, active el kickstart con el siguiente comando:
    linux ks=http://satellite.example.com/path/to/kickstart
    
  3. Cuando el sistema arranque, descargará el kickstart e instalará en forma automática.

Procedimiento 2.6. Arranque PXE

Para poder realizar un arranque PXE, cada sistema debe tener soporte de arranque PXE en el nivel de BIOS. Casi todos los hardware recientes pueden hacerlo. Además, debe tener un servidor DHCP, incluso si sus sistemas se deben configurar de forma estática después de la instalación.
  1. Importante

    Si tiene un servidor DHCP implementado en otro sistema en la red, necesitará acceso administrativo al servidor DHCP para editar el archivo de configuración DHCP.
    Si sus máquinas residen en varias redes, necesitará asegurarse de que todas las máquinas puedan conectarse al servidor DHCP. Esto puede realizarse al multialojar al servidor DHCP (mediante un VLAN truncado o real) y configurar los enrutadores o interruptores para pasar el protocolo DHCP a través de los límites de red.
    Configure el servidor DHCP para que apunte al servidor PXE, estableciendo la dirección next-server para los sistemas que desea que sean administrados por el Satélite de RHN.
    Para usar nombres de host durante la instalación, configure el servidor DHCP para indicar el dominio y las direcciones IP, incluya las siguientes líneas:
    option domain-name DOMAIN_NAME;
    option domain-name-servers IP_ADDRESS1, IP_ADDRESS2;
    
  2. En el servidor DHCP, cambie a usuario root y abra el archivo /etc/dhcpd.conf. Añada una nueva clase con opciones para realizar una instalación de arranque PXE:
    allow booting;
    allow bootp;
    class "PXE" {
      match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
      next-server 192.168.2.1;
      filename "pxelinux.0";
    }
    
    Esta clase realizará las siguientes acciones:
    1. Habilita el arranque de red con el protocolo bootp.
    2. Cree una clase llamada PXE. Si un sistema está configurado para que tenga a PXE primero en su prioridad de arranque, se identificará como PXEClient.
    3. El servidor DHCP dirige el sistema al servidor de Cobbler en la dirección IP 192.168.2.1
    4. El servidor DHCP se refiere al archivo de imagen de arranque en /var/lib/tftpboot/pxelinux.0
  3. Configure Xinetd. Xinetd es un demonio que maneja un paquete de servicios, incluyendo TFTP, el servidor FTP utilizado para transferir la imagen de arranque al cliente PXE.
    Active Xinetd mediante el comando chkconfig:
    chkconfig xinetd on
    
    Alternativamente, puede pasar a usuario de root, abrir el archivo /etc/xinetd.d/tftp. Ubique la línea disable = yes y cámbiela a disable = no.
  4. Inicie el servicio Xinetd para que TFTP pueda comenzar sirviendo a la imagen de arranque pxelinux.0:
    chkconfig --level 345 xinetd on
    /sbin/service xinetd start
    
    El comando chkconfig activa el servicio xinetd para todos los niveles de ejecución y el comando /sbin/service activa inmediatamente xinetd.

2.5.2. Re-aprovisionamiento

La reinstalación de un sistema existente se conoce como Reaprovisionamiento. El re-aprovisionamiento se puede usar durante la interfaz de red del Servidor de satélite de RHN y el sistema usará el mismo perfil de sistema que tenía antes de ser re-aprovisionado. Así preservará una gran cantidad de información y los parámetros sobre el sistema.
Puede programar un reaprovisionamiento desde la pestaña Aprovisionamiento mientras ve un sistema. Para configurar opciones adicionales, vaya a la página de Configuraciones avanzadas, la cual le permite configurar información tal como las opciones de kernel, información de redes y sincronización de perfil de paquetes. La sección de Opciones de Kernel proporciona acceso a opciones de kernel utilizadas durante el kickstart y las Opciones Post Kernel utilizadas después de que kickstart termine y el sistema inicie por primera vez.

Ejemplo 2.2. Configuración de opciones de kernel y opciones de post kernel

Este ejemplo describe la diferencia entre las opciones de kernel y post kernel en el proceso de configuración de aprovisionamiento.
Si desea establecer una conexión VNC para monitorizar el kickstart de forma remota, incluya vnc vncpassword=CONTRASEÑA en la línea de Opciones de Kernel.
Si desea que el kernel del sistema resultante arranque con la opción de kernel noapic, añada noapic a la línea de Opciones Post Kernel.

Procedimiento 2.7. Preservación de archivos

La funcionalidad File Preservation puede servir para evitar que se pierdan los archivos durante el aprovisionamiento. Esta funcionalidad almacena archivos temporalmente durante el kickstart y los restaura cuando se haya completado el aprovisionamiento.

Nota

Las listas de preservación de archivos solamente están disponibles en los kickstarts con asistente de estilo y únicamente durante el aprovisionamiento.
  1. Vaya a SistemasKickstartPreservación de archivosCrear nueva lista de preservación de archivos y crear una lista de archivos a preservar.
  2. Vaya a SistemasKickstartPerfiles y asocie la lista de preservación de archivo con un kickstart seleccionando el perfil deseado.
  3. Vaya a Información de sistemaPreservación de archivo y seleccione la lista de preservación de archivo.

2.5.3. Aprovisionamiento de Huésped virtualizado

El aprovisionamiento de huésped virtual es compatible en Satélite de RHN 5.5 mediante las siguientes tecnologías de virtualización:
  • Huésped virtualizado KVM
  • Huésped Xen totalmente virtualizado
  • Huésped Xen para-virtualizado

Procedimiento 2.8. Aprovisionamiento de huésped virtualizado

  1. Verifique si el sistema de host tiene derecho de Virtualización o de Plataforma de virtualización.
  2. En la página Sistemas, seleccione el host virtual apropiado, luego seleccione VirtualizaciónAprovisionamiento. Seleccione el perfil kickstart apropiado e ingrese el nombre de huésped.
  3. Si desea configurar parámetros adicionales tales como memoria de huésped y uso de CPU, haga clic en el botón de Configuración avanzada. Las siguientes opciones pueden ser configuradas:
    • Red estática o DHCP
    • Opciones de kernel
    • Sincronización de perfil de paquetes: cuando el kickstart termina, el sistema sincronizará su perfil de paquete al del otro sistema o perfil almacenado
    • Asignación de memoria: (Predeterminada a 512MB)
    • Tamaño de disco virtual
    • CPU virtuales (Predeterminado a 1)
    • Puente virtual: El puente de red utilizado para instalación. Se predetermina a xenbr0 para aprovisionamiento Xen y virbr0 para KVM.

      Nota

      El puente de red virbr0 no permitirá conexión de red externa. Si requiere conexión de red externa, configure el host para crear un verdadero puente en su lugar. Sin embargo, xenbr0 es el puente real y se recomienda usarlo cuando sea posible.
    • Ruta de almacenamiento virtual: Ruta a otro archivo, Volumen lógico LVM, directorio o dispositivo de bloque con el cual almacenar la información de disco de huésped, como por ejemplo /dev/sdb, /dev/LogVol00/mydisk, VolGroup00, o /var/lib/xen/images/myDisk.
  4. Haga clic en Programar Kickstart y finalizar

2.5.4. Aprovisionamiento a través de un Proxy de RHN

Aprovisionamiento puede realizarse mediante un proxy de RHN que haya sido instalado y registrado al Servidor satélite de RHN.
  1. Durante el aprovisionamiento de un huésped virtual o al reaprovisionar un sistema, elija el proxy deseado desde la cajilla desplegable Seleccionar Satélite Proxy.
  2. Para una instalación en vacío, remplace el nombre de dominio completamente calificado (FQDN) del Satélite de RHN por el FQDN del proxy. Por ejemplo, si la URL para el archivo kickstart es:
    http://satellite.example.com/ks/cfg/org/1/label/myprofile
    
    Luego kickstart a través del proxy, use:
    http://proxy.example.com/ks/cfg/org/1/label/myprofile
    

Capítulo 3. Varios satélites

Sincronización intersatelital (ISS) le permite coordinar contenido entre satélites. Esta funcionalidad puede servir de varias formas, según las necesidades de su organización. Este capítulo contiene una sección sobre casos de uso y sobre cuál es la mejor forma de configurar ISS para que se ajuste a su organización.

Requerimientos de ISS

Las condiciones requeridas para usar ISS son las siguientes:
  • Dos o más servidores de Satélite de RHN
  • Por lo menos un Satélite de RHN poblado con un canal
  • Para conexiones seguras, cada Satélite de RHN esclavo también requerirá un certificado del Satélite de RHN maestro

3.1. Sincronización intersatelital (ISS)

Procedimiento 3.1. Configuración del servidor maestro

El servidor maestro se utiliza para determinar los archivo que se van a sincronizar para otros satélites.
  1. Habilite la funcionalidad de sincronización intersatelital (ISS). Abra el archivo /etc/rhn/rhn.conf y añada o corrija la siguiente línea para que se lea:
    disable_iss=0
    
  2. En el archivo /etc/rhn/rhn.conf, localice la línea allowed_iss_slaves=. Por defecto, no se especifican satélites esclavos para sincronización . Ingrese el nombre de host de cada servidor satélite esclavo, separado por comas:
    allowed_iss_slaves=slave1.satellite.example.org,slave2.satellite.example.org
    
  3. Guarde el archivo de configuración y reinicie el servicio httpd:
    service httpd restart
    

Procedimiento 3.2. Configuración de servidores esclavos

Los Servidores de satélite esclavo son las máquinas que tendrán su contenido sincronizado para el servidor maestro.
  1. Para configurar servidores esclavos de forma segura, requerirá el certificado ORG-SSL del servidor maestro. Puede descargar el certificado HTTP desde el directorio /pub/ de cualquier satélite. El archivo se llama RHN-ORG-TRUSTED-SSL-CERT, pero puede cambiarle el nombre y colocarlo en el sistema de archivos local del esclavo, como por ejemplo en el directorio /usr/share/rhn/.
  2. Vea la lista de canales disponibles para sincronización desde el servidor maestro con el siguiente comando. Se desplegarán los canales oficiales de Red Hat y los canales personalizados disponibles:
    satellite-sync --iss-parent=master.satellite.example.com --ca-cert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --list-channels
    
    Remplace master.satellite.example.com por el nombre de host del servidor maestro.

Procedimiento 3.3. Cómo se realiza una sincronización Intersatelital

Una vez que estén configurados los servidores esclavos y maestros, se podrá realizar una sincronización entre ellos.
  1. En los servidores esclavos, abra el archivo /etc/rhn/rhn.conf en su editor de texto preferido y añada el nombre de host de servidor maestro y la información de ruta de archivo del certificado SSL:
    iss_parent      = master.satellite.example.com
    iss_ca_chain    = /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
    
  2. Comience la sincronización ejecutando el comando satellite-sync:
    satellite-sync -c your-channel

    Nota

    Las opciones de línea de comandos que usted proporciona con el comando satellite-sync sobrescribirán cualquier parámetro personalizado en el archivo /etc/rhn/rhn.conf.

3.2. Sincronización empresarial

ISS también sirve para importar contenido a cualquier organización específica. Esto puede realizarse de forma local o por medio de sincronización remota. Esta función es útil para un satélite desconectado que tenga múltiples organizaciones, donde el contenido se recupere a través de vaciados de canal o exportándolo desde los satélites conectados y luego importándolo al satélite desconectado. La sincronización empresarial puede servir no solo para exportar canales personalizados desde satélites conectados, sino también para desplazar contenido entre múltiples organizaciones.
La sincronización empresarial tiene un conjunto de reglas claras a seguir para mantener la integridad de la organización de origen.
  • Si la fuente de contenido pertenece a la organización NULL (cualquier contenido de Red Hat;) se predeterminará a la organización NULL, incluso si se especifica la organización de destino. De esta manera, se garantiza que el contenido especificado esté siempre en esa organización privilegiada NULL.
  • Si una organización se especifica en la línea de comandos, se importará el contenido desde esa organización.
  • Si no se especifica ninguna organización, se predeterminará a la organización 1.
A continuación, tres ejemplos de escenarios en los que los ID empresariales (orgid) se utilizan para sincronizar satélites:

Ejemplo 3.1. Importar contenido del satélite maestro al satélite esclavo:

Este ejemplo importa contenido del satélite maestro al satélite esclavo:
satellite-sync --parent-sat=master.satellite.example.com -c channel-name --orgid=2

Ejemplo 3.2. Importar contenido desde un volcado exportado de una organización

Este ejemplo importa contenido desde un volcado exportado de una organización específica:
$ satellite-sync -m /dump -c channel-name --orgid=2

Ejemplo 3.3. Importar contenido desde Red Hat Network Hosted

Este ejemplo importa contenido desde Red Hat Network dedicado (suponiendo que el sistema está registrado y activado:
$ satellite-sync -c channel-name

3.3. Casos de uso ISS

ISS puede utilizarse en diferentes formas, según las necesidades de su organización. Esta sección proporciona ejemplos de cómo podría escoger ISS y los métodos para configurar y ejecutar estos casos.

Ejemplo 3.4. Satélite de ensayo

Este ejemplo usa un satélite como Satélite de ensayo para preparar contenido y realizar control de calidad en los paquetes a fin de garantizar que sean aptos para uso de producción. Cuando el contenido es aprobado para ir a producción, puede ser sincronizado por el satélite de producción desde el Satélite de ensayo.
  1. Ejecute el comando satellite-sync para sincronizar datos con rhn_parent (por lo general Red Hat Network Hosted):
    satellite-sync -c your-channel
    
  2. Ejecute el siguiente comando para sincronizar datos desde el servidor de ensayo:
    satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel

Ejemplo 3.5. Esclavos sincronizados

En este ejemplo, el satélite maestro proporciona datos directamente a los esclavos y los cambios se sincronizan regularmente.

Ejemplo 3.6. Contenido personalizado de esclavo

Este ejemplo utiliza el satélite maestro como un canal de desarrollo, desde el cual se distribuye el contenido a todos los satélites esclavos de producción. Algunos satélites esclavos no tienen contenido adicional presente en los canales de Satélite maestro. Estos paquetes se preservan, pero todos los cambios del satélite maestro se sincronizan para los esclavos.

Ejemplo 3.7. Sincronización bidireccional

En este entorno, los dos servidores de servidor Satélite de RHN actúan como maestros entre sí y pueden sincronizar su contenido.
  1. Asegúrese de que ambos satélites puedan compartir los certificados SSL.
  2. En el primer satélite, abra el archivo /etc/rhn/rhn.conf y establezca la opción iss_parent para señalar el nombre de host del segundo satélite.
  3. En el segundo satélite, abra el archivo /etc/rhn/rhn.conf y establezca la opción iss_parent para señalar al nombre de host del primer Satélite.

Capítulo 4. Métodos y comandos API avanzados

4.1. XML-RPC API

Satélite de RHN 5.5 soporta el aprovisionamiento mediante la API XML-RPC.
Los siguiente métodos de API sirve para el mantenimiento del árbol y perfil de kickstart:

Tabla 4.1. Métodos XML-RPC

Espacio de nombre XML-RPC Uso
kickstart Crea, importa y borra perfiles kickstart. También se usa para listar los árboles y perfiles de kickstart disponibles.
kickstart.tree Crea, renombra, actualiza y borra árboles kickstart.
kickstart.filepreservation Lista, crea y borra listas de preservación de archivos que pueden estar asociadas a un perfil kickstart. Una vez se haya creado una lista de preservación de archivos, puede asociarse a un perfil kickstart llamando al método API kickstart.profile.system.add_file_preservations.
kickstart.keys Lista, crea y elimina llaves criptográficas (GPG/SSL) que pueden asociarse a perfiles kickstart diferentes.

Nota

Una vez se haya creado la llave criptográfica, se puede asociar con un perfil kickstart llamando al método API kickstart.profile.system.add_keys.
kickstart.profile Manipula rangos IP, cambia el árbol kickstart y el canal de canales hijos, descarga archivos kickstart asociados a un perfil, manipula opciones avanzadas, manipula opciones personalizadas y añade pre/post scripts asociados a un perfil kickstart.
kickstart.profile.keys Lista, añade (asocia) y elimina (desasocia) llaves de activación asociadas con un perfil kickstart.
kickstart.profile.software Manipula la lista de paquetes asociados a un perfil kickstart.
kickstart.profile.system Maneja preservaciones de archivos, llaves criptográficas, activa/desactiva administración de configuración y comandos remotos, configura esquemas de particionamiento y establece la información regional asociada con un perfil de kickstart determinado.
Las siguientes llamadas de métodos API pueden servir para aprovisionar un host y programar instalaciones de huésped:
  • system.provision_system
  • system.provision_virtual_guest
Para obtener mayor información las llamadas API, consulte la documentación de API disponible en https://satellite.example.com/rpc/api.

4.2. Cobbler

Satélite de RHN utiliza Cobbler para aprovisionamiento. Cuando los perfiles de kickstart, árboles (distribuciones) y sistemas para aprovisionamiento se actualizan en el servidor satélite de RHN, se sincronizan para la instancia de Cobbler en el host del Satélite de RHN. Es decir, que Cobbler puede usarse directamente para administrar el aprovisionamiento.
La siguiente tabla describe los comandos Cobbler:

Tabla 4.2. Comandos de Cobbler

Comando Uso
cobbler profile list Ejecute este comando en el host del Satélite de RHN para mostrar la lista de perfiles
cobbler distro list Para obtener una lista de árboles Kickstart, discos RAM y otras opciones
cobbler system list Mostrar una lista de los registros de sistema, creados cuando se programa un kickstart
cobbler profile report --name=profile-name or cobbler system report --name=system-name Para mostrar salida más detallada acerca de un objeto específico
cobbler profile edit --name=profile-name --virt-ram=1024 Edita varios parámetros. Este ejemplo asignara a cada instalación virtualizada de un determinado perfil 1GB de RAM.
cobbler system edit --name=system-name --netboot-enabled=1 Forzar al sistema a ser reinstalado en el siguiente reinicio
cobbler system edit --name=system-name --profile=new-profile-name --netboot-enabled=1 Asignar un sistema a un nuevo perfil para reinstalación
cobbler system find --profile=profile-name Listar todos los sistemas asignados a un perfil
cobbler system find --profile="abc" | xargs -n1 --replace cobbler system edit \ --name={} --profile="def" --netboot-enabled=1 Asignar todos los sistemas actualmente configurados al perfil def y reinstalarlos la próxima vez que se reinicien
cobbler profile edit --name=profilename --kopts="variablename=3" --in-place Establecer una variable de plantilla adicional en un perfil sin modificar ninguna de las otras variables
cobbler system edit --name=systemname --kopts="selinux=disabled asdf=jkl" Asignar varias variables al registro del sistema, e ignorar las variables anteriores que podrían configurarse
cobbler profile find --name="*webserver*" | xargs -n1 --replace cobbler profile edit --name={} --profile="RHEL5-i386" Establecer todas las nuevas instalaciones de los perfiles que contengan webserver como una cadena para usar un perfil llamado RHEL5-i386
Otros parámetros de Cobbler

Solo hay unos pocos parámetros Cobbler que deben cambiarse directamente en /etc/cobbler/settings. Entre ellos está pxe_just_once (descrito en Procedimiento 4.3, “Configuración de Cobbler para usar PXE”). La opción server también puede cambiarse para reflejar la dirección o el nombre del servidor de Satélite de RHN.

Después de cambiar /etc/cobbler/settings, ejecute el siguiente comando para activar los cambios:
/sbin/service cobblerd restart
cobbler sync

Importante

No ajuste ningún otro parámetro en /etc/cobbler/settings. El servidor satélite de RHN requiere que este archivo permanezca con una cierta configuración, determinada por el instalador de Satélite de RHN. Del mismo modo, el archivo /etc/cobbler/modules.conf, debe permanecer como fue creado por el instalador del Satélite de RHN. En particular, el módulo de autenticación debe permanecer como authn_spacewalk y no se debe cambiar.

Procedimiento 4.1. Configuración de SELinux para usar con Cobbler

El soporte SELinux y cortafuegos seguro se instala por defecto en Red Hat Enterprise Linux. Para que el servidor de Red Hat Enterprise Linux pueda utilizar Cobbler, configure SELinux para que permita conexiones hacia y desde el servidor de Cobbler.
  1. Para habilitar SELinux para obtener soporte Cobbler, debe establecer el booleano que permita los componentes de servicio de red HTTPD, mediante el siguiente comando:
    setsebool -P httpd_can_network_connect true
    
    El interruptor -P es esencial, ya que permite la conexión persistente de HTTPD a través de los reinicios de sistema.
  2. Establezca las reglas de contexto del archivo SELinux para que TFTP sirva el archivo de imagen de arranque, mediante el siguiente comando en el servidor Cobbler:
    semanage fcontext -a -t public_content_t "var/lib/tftpboot/.*"
    
  3. Debe configurar IPTables para permitir el tráfico de red de entrada y salida en el servidor Cobbler.
    Si existe una serie de reglas de cortafuegos que usan IPTables, añada las siguientes reglas para abrir los puertos relacionados con Cobbler, así:
    Para TFTP:
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 69 -j ACCEPT
    /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT
    
    Para HTTPD:
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
    
    Para Cobbler:
    /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 25150 -j ACCEPT
    
    Para Koan:
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 25151 -j ACCEPT
    
  4. Guarde la configuración de firewall:
    /sbin/iptables-save
    
  5. Para asegurarse de que todos los archivos de configuración estén sincronizados ejecute el siguiente comando:
    cobbler sync
    
  6. Inicie el servidor de satélite:
    /usr/sbin/rhn-satellite start
    

    Aviso

    No inicie o detenga el servicio cobblerd independiente del servicio de Satélite que al hacerlo puede causar errores y otros problemas.
    Siempre utilice /usr/sbin/rhn-satellite para iniciar o detener el Satélite de RHN.

Procedimiento 4.2. Configuración de registros de sistema de Cobbler

Los registros de sistema de Cobbler son objetos dentro de Cobbler que mantienen el rastro de un sistema y su perfil kickstart asociado. Para realizar PXE Kickstarting necesitará estar vinculado a los registros de sistema de Cobbler correspondientes para las máquinas que intenta iniciar con kickstart.
  1. Vaya a Información del sistemaAprovisionamiento para cada sistema y seleccione el perfil kickstart con el que debe estar asociado.
  2. Haga clic en el botón Crear registro de sistema Cobbler para hacer la asociación.
  3. Esta asociación permanecerá indefinidamente en su lugar para establecer la opción pxe_just_once a verdadera para cualquiera de las máquinas dadas. En ese caso, la asociación se terminará después de un kickstart exitoso. Vea el Procedimiento 4.3, “Configuración de Cobbler para usar PXE” para obtener mayor información.

Procedimiento 4.3. Configuración de Cobbler para usar PXE

Cobbler se establece para generar configuraciones predeterminadas de PXE, pero para obtener el mejor flujo de trabajo PXE en el BIOS, puede ajustar la opción pxe_just_once.
  1. A menudo el orden BIOS se establecerá para que el arranque PXE sea primero. Esto no significa que el sistema no arrancará fuera del disco local a menos que el servidor PXE le instruya de forma remota. Esta configuración puede crear un bucle de arranque, donde el sistema se reinstale de forma continua.
    Para evitar bucles de arranque, abra el archivo /etc/cobbler/settings y añada la siguiente línea:
    pxe_just_once: 1
    
    Esta configuración añade un macro $kickstart_done en la plantilla kickstart, la cual le dice al sistema que arranque de forma local después de que haya completado la instalación, en lugar de arrancar desde la red.
  2. Si incluye el parámetro pxe_just_once: 1, y desea reinstalar el sistema posteriormente, no olvide cambiar el indicador netboot-enabled en el sistema. Esto puede realizarse mediante la interfaz de red del Satélite de RHN o directamente en Cobbler. Cuando el sistema vuelve a arrancar, realizará la instalación de PXE y luego volverá a arrancar desde el disco local hasta que se restablezca el indicador.
    Si el BIOS se establece para arrancar desde discos duros locales, no hay necesidad de tener activado pxe_just_once. Sin embargo, para reaprovisionar el sistema con PXE, será necesario llevar a cero el MBR (master boot record/Gestor de arranque maestro).

Denominación de convenciones

Para ayudar a mantener sincronizada la información entre Satélite de RHN y Cobbler, Satélite de RHN usa las convenciones de nomenclatura para distribuciones y perfiles. Estas convenciones de nomenclatura son importantes si desea interactuar con Cobbler mediante la interfaz de línea de comandos.
Distribuciones
$tree_name:$org_id:$org_name (si han sido creadas en forma manual)
$tree_name (Si es sincronizada por Satélite de RHN)
Perfiles
$profile_name:$org_id:$org_name

Importante

No altere los nombres que han sido generados automáticamente por Satélite de RHN. Si el nombre cambia, Satélite de RHN ya no podrá mantener esos elementos.

Nota

Para identificar y resolver problemas, Cobbler registra datos en el Satélite de RHN y en el archivo /var/log/cobbler/

4.3. Koan

La herramienta koan (kickstart en una red) es una herramienta de cliente que permite a Satélite de RHN ser accedido de forma remota desde hosts que ya han sido aprovisionados. Koan le permite realizar aprovisionamiento de kickstart, crear huéspedes virtuales (en hosts virtuales) y listar los kickstarts disponibles desde Satélite de RHN. Está disponible en el paquete de koan.

Tabla 4.3. Comandos Koan

Comando Uso
man koan Leer la página de manual koan
koan --replace-self --server=satellite.example.org --profile=profile-name o koan --replace-self --server=satellite.example.org --system=system-name Reaprovisionar un sistema existente. Reinicia después de ejecutar este comando para instalar el nuevo sistema operativo. También sirve para actualizar kickstarts (por ejemplo, para actualizar una gran cantidad de máquinas de una versión de Red Hat Enterprise Linux a la siguiente).
koan --virt --server=satellite.example.org --profile=profile-name o koan --virt --server=satellite.example.org --system=system-name Aprovisionar un huésped virtual
koan --list=profiles --server=satellite.example.org o koan --list=systems --server=satellite.example.org Llamar a Cobbler para mostrar una lista de perfiles o sistemas disponibles para instalación remota

Nota

Para identificar y resolver problemas, observe que Koan registra datos en /var/log/koan.

Capítulo 5. Detección y solución de problemas

5.1. Interfaz de red
P: Tengo problemas con la interfaz de usuario del Satélite de RHN. ¿Cuáles registros de archivo debo revisar?
5.2. Anaconda
P: Estoy recibiendo un error que dice Error downloading kickstart file. ¿Cuál es el problema y cómo debo corregirlo?
P: Estoy recibiendo un error de instalación de paquetes que dice The file chkconfig-1.3.30.1-2.i386.rpm cannot be opened.. ¿Cuál es el problema y cómo debo corregirlo?
5.3. Trazabilidad
P: Estoy recibiendo correos-e con "WEB TRACEBACK" en el asunto. ¿Qué debo hacer con ellos?
5.4. Registro
P: El comando rhnreg_ks falla cuando lo ejecuto, dice:ERROR: unable to read system id. ¿Cuál es el problema?
5.5. Kickstarts y Fragmentos
P: ¿Cuál es la estructura de directorio para kickstarts?
P: ¿Cuál es la estructura de directorio para fragmentos Cobbler?

5.1. Interfaz de red

P:
Tengo problemas con la interfaz de usuario del Satélite de RHN. ¿Cuáles registros de archivo debo revisar?
R:
Si encuentra errores al ver, programar o trabajar con kickstart en la interfaz de usuario del Satélite de RHN, revise el archivo de registro /var/log/tomcat5/catalina.out.
Para todos los errores de interfaz, revise el archivo de registro /var/log/httpd/error_log.

5.2. Anaconda

P:
Estoy recibiendo un error que dice Error downloading kickstart file. ¿Cuál es el problema y cómo debo corregirlo?
R:
Este error suele ser el resultado de un problema de red. Para localizar el problema, ejecute el comando cobbler check y lea la salida, la cual debería ser algo así:
# cobbler check
The following potential problems were detected:
#0: reposync is not installed, need for cobbler reposync, install/upgrade yum-utils?
#1: yumdownloader is not installed, needed for cobbler repo add with --rpm-list parameter, install/upgrade yum-utils?
#2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed
#3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them
Si cobbler check no proporciona ninguna respuesta, revise lo siguiente:
  • Verifique si httpd está ejecutando: service httpd status
  • Verifique si cobblerd está ejecutando: service cobblerd status
  • Verifique si puede obtener el archivo kickstart mediante wget desde un host diferente.
    wget http://satellite.example.com/cblr/svc/op/ks/profile/rhel5-i386-u3:1:Example-Org
P:
Estoy recibiendo un error de instalación de paquetes que dice The file chkconfig-1.3.30.1-2.i386.rpm cannot be opened.. ¿Cuál es el problema y cómo debo corregirlo?
R:
Los clientes obtendrán el contenido del Satélite de RHN basados en el parámetro --url en el kickstart. Por ejemplo:
url --url http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Si recibe errores de Anaconda diciendo que no puede encontrar imágenes o paquetes, verifique primero si la URL de arriba genera una respuesta 200 OK. Puede hacerlo ejecutando wget y el archivo localizado en esa URL:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
--2011-08-19 15:06:55--  http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Resolving satellite.example.com... 10.10.77.131
Connecting to satellite.example.com|10.10.77.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
Saving to: `ks-rhel-i386-server-5-u3.1'
2011-08-19 15:06:55 (0.00 B/s) - `ks-rhel-i386-server-5-u3.1' saved [0/0]
Si obtiene una respuesta diferente a 200 OK, revise el registro de errores para hallar el problema. También puede revisar el archivo real que Anaconda intentó descargar buscando el archivo access_log:
# grep chkconfig /var/log/httpd/access_log
10.10.77.131 - - [19/Aug/2011:15:12:36 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server-
5-u3/Server  /chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:12:36 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-
1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:14:20 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-  
1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.77.131 - - [19/Aug/2011:15:14:20 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server- 
5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
Si estas solicitudes no aparecen en el archivo access_log, el sistema puede estar teniendo problemas con la configuración de red. Si las solicitudes aparecen pero no generan errores, revise el registro de errores.
También puede tratar de descargar manualmente los archivos para ver si el paquete está disponible:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm

5.3. Trazabilidad

P:
Estoy recibiendo correos-e con "WEB TRACEBACK" en el asunto. ¿Qué debo hacer con ellos?
R:
Un correo-e típico de trazabilidad se vería algo como así:
Subject: WEB TRACEBACK from satellite.example.com
Date: Wed, 19 Aug 2011 20:28:01 -0400
From: RHN Satellite <dev-null@redhat.com>
To: admin@example.com

java.lang.RuntimeException: XmlRpcException calling cobbler.
	at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72)
	at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76)
	at com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreadedTestableTask.java:54)
	at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
	at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: redstone.xmlrpc.XmlRpcException: The response could not be parsed.
	at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:434)
	at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
	at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
	at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
	... 4 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://someserver.example.com:80/cobbler_api
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1236)
	at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
	... 7 more
Esto indica que hay un problema con la comunicación de Cobbler con el servicio taskomatic. Intente revisar lo siguiente:
  • Verifique si httpd está ejecutando: service httpd status
  • Verifique si cobblerd está ejecutando: service cobblerd status
  • Asegúrese de que no haya reglas de cortafuegos que pueden impedir conexiones de localhost

5.4. Registro

P:
El comando rhnreg_ks falla cuando lo ejecuto, dice:ERROR: unable to read system id. ¿Cuál es el problema?
R:
Al final del archivo kickstart, hay una sección %post que registra la máquina al Satélite de RHN:
# begin Red Hat management server registration
mkdir -p /usr/share/rhn/
wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT   
perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/*  
rhnreg_ks --serverUrl=https://satellite.example.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-c8d01e2f23c6bbaedd0f6507e9ac079d
# end Red Hat management server registration
Al interpretarlo en el orden en el que fue añadido:
  • Cree un directorio para albergar el certificado SSL personalizado por el Satélite de RHN.
  • Busque el certificado SSL para usar durante el registro:
  • Busque y remplace las cadenas del certificado SSL de los archivos de configuración rhn-register y luego regístrese al Satélite de RHN mediante el certificado SSL y una llave de activación. Cada perfil kickstart incluye una llave de activación que garantiza que el sistema sea asignado a la base y a los canales hijos correctos, y obtenga los derechos de sistema apropiados. Si se trata de un reaprovisionamiento de un sistema existente, la llave de activación también garantizará la asociación con el perfil del sistema anterior.
Si el comando rhnreg_ks falla, podría ver errores como este en en el registro de archivo ks-post.log:
ERROR: unable to read system id.
Estos errores también se presentarán si intenta realizar un rhn_check y el sistema no se ha registrado al Satélite de RHN.
La mejor forma de detectar y solucionar un problema es ver el archivo kickstart y copiar y pegar los cuatro pasos de arriba directamente en el indicador de comandos después de que kickstart haya completado. Esto generará mensajes de error más detallados para ayudarle a ubicar el problema.

5.5. Kickstarts y Fragmentos

P:
¿Cuál es la estructura de directorio para kickstarts?
R:
La ruta de base en la que los archivos kickstart están almacenados es /var/lib/rhn/kickstarts/. Dentro de este directorio, los kickstarts crudos residen en el subdirectorio upload y los kickstart generados con asistente están en el subdirectorio wizard:
Raw Kickstarts: /var/lib/rhn/kickstarts/upload/$profile_name--$org_id.cfg
Wizard Kickstarts: /var/lib/rhn/kickstarts/wizard/$profile_name--$org_id.cfg
P:
¿Cuál es la estructura de directorio para fragmentos Cobbler?
R:
Los fragmentos Cobbler se almacenan en /var/lib/rhn/kickstarts/snippets. Cobbler accede fragmentos mediante el enlace simbólico /var/lib/cobbler/snippets/spacewalk.
Snippets:  /var/lib/rhn/kickstarts/snippets/$org_id/$snippet_name

Importante

Los RPM del Satélite de RHN esperan que kickstart de Cobbler y los directorios de fragmentos estén en sus sitios predeterminados, no los cambie.

Apéndice A. Revision History

Historial de revisiones
Revisión 4-2.2.402Fri Oct 25 2013Rüdiger Landmann
Rebuild with Publican 4.0.0
Revisión 4-2.2Mon Apr 8 2013Gladys Guerrero-Lozano
Revisión completa
Revisión 4-2.1Thu Feb 21 2013Gladys Guerrero
Translation files synchronised with XML sources 4-2
Revisión 4-2Wed Sept 19 2012Dan Macpherson
Empaquetamiento final para 5.5
Revisión 4-1Thu Aug 9 2012Athene Chan
En etapa para lanzamiento
Revisión 4-0Mon June 25 2012Athene Chan
Se actualizaron los capítulos 1 y 2 para Satélite de RHN 5.5
Se modificaron los capítulos 3-5 para Satélite de RHN 5.5
BZ#787348 Línea de Iptables de Cobbler incorrecta
BZ#702529 Adición de información sobre Kickstart
BZ#797688 Cobbler Boot ISO no tiene soporte
Revisión 3-0Thu May 31 2012Athene Chan
BZ#826803 - Corrección de puntuación en la sección "Instalación de una máquina con Kickstart"
Cambios gramaticales menores en la sección de Kickstart.
Revisión 2-0Thu May 24 2012Athene Chan
BZ#783339 - Reestructuración de la sección "Provisioning Troubleshooting Taskomatic"
BZ#783340 - Actualización de "s390x" to "IBM System z"
Revisión 1-3Mon Aug 15 2011Lana Brindley
Lanzamiento de z-stream incorporado en y-stream
Revisión 1-2Wed Jun 15 2011Lana Brindley
Preparado para traducción
Revisión 1-1Fri May 27 2011Lana Brindley
Actualizaciones de traductores
Revisión 1-0Fri May 6, 2011Lana Brindley
Últimas modificaciones de revisión de QE
Preparado para traducción
Revisión 0-8Thu May 5, 2011Lana Brindley
Revisión de QE - BZ#701822
Revisión 0-7Thu April 14, 2011Lana Brindley
Comentarios de revisión técnica
Revisión 0-6Wed March 23, 2011Lana Brindley
Preparación para revisión técnica
Revisión 0-5Tue March 22, 2011Lana Brindley
BZ#666435
BZ#666846
BZ#678080
BZ#682364
Revisión 0-4Tue March 22, 2011Lana Brindley
Detección y solución de problemas
Revisión 0-3Mon March 21, 2011Lana Brindley
Varios satélites
Revisión 0-2Thu March 17, 2011Lana Brindley
Introducción
Kickstart
Comandos avanzados
Restructuración de capítulo
Revisión 0-1Wed Jan 5, 2011Lana Brindley
Nueva estructura de capítulo completa
Revisión 0-0Tue Dec 21, 2010Lana Brindley
Nuevo documento de creación de la Guía de implementación del Satélite de RHN.

Aviso Legal

Copyright © 2011 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.