Guía de configuración de cliente


Red Hat Network Satellite 5.5

Red Hat Network Satellite

Edición 3

Resumen

Bienvenido a la Guía de configuración de cliente de Red Hat Network Satellite.

Capítulo 1. Introducción

Esta guía de prácticas tiene como objeto ayudar a los usuarios del Servidor satélite de RHN y Servidor proxy de RHN a configurar sus sistemas clientes.
Todas las aplicaciones de clientes de Red Hat Network están configuradas para comunicarse con los servidores centrales de Red Hat Network. Cuando los clientes se conectan a un Servidor satélite o a un servidor proxy de RHN en su lugar, los parámetros predeterminados cambian. Este documento tiene como objeto ofrecer los pasos de comunicación de reconfiguración, los cuales ayudarán grandes entornos empresariales que contienen cientos o miles de sistemas, a aplicar los cambios de parámetros predeterminados.
Debido a la complejidad de esta tarea, los usuarios pueden utilizar un script prellenado que automatice muchas de las tareas necesarias para acceder a sus servidores satélite o proxy. Consulte el Capítulo 5, Uso de RHN Bootstrap para obtener mayor información. Red Hat cree que el entendimiento de las implicaciones de estos cambios es útil y por lo tanto, describe los pasos de reconfiguración manual en los primeros capítulos. Tenga en cuenta las necesidades de su organización para determinar la solución ideal.
Aunque muchos de los comandos provistos dentro de esta guía pueden ser aplicados tal y como aparecen, es imposible predecir todas las posibilidades de configuraciones de red adoptados por los usuarios. Por lo tanto, Red Hat le recomienda usar estos comandos como referencias que deben ser tenidas en cuenta en la configuración individual de su empresa.

Nota

La información de configuración de los clientes Unix puede encontrarse en la Guía de referencia del Servidor satélite de RHN en el capítulo Soporte para Unix.

Capítulo 2. Aplicaciones de cliente

Para poder utilizar la mayoría de las funciones de clase empresarial de Red Hat Network, tales como el registro de sistemas con el satélite de RHN, se requiere la configuración de las aplicaciones cliente más recientes. El obtener estas aplicaciones antes de que el cliente se haya registrado con Red Hat Network puede ser difícil. Esta paradoja es especialmente problemática para usuarios que migran un número amplio de antiguos sistemas a Red Hat Network. Este capítulo identifica varias técnicas para resolver este problema.

Importante

Red Hat recomienda que el cliente conectado al Servidor satélite de RHN o al Servidor Proxy de RHN, ejecute la actualización más reciente de Red Hat Enterprise Linux para asegurar una conexión correcta.
Adicionalmente, si el cortafuegos del cliente está configurado, los puertos 80 y 443 deben estar abiertos para permitir una apropiada funcionalidad con Red Hat Network.

2.1. Implementación de los últimos RPM clientes de Red Hat Network

El Actualizador de paquetes (pup), yum, el complemento yum RHN (yum-rhn-plugin) y el Cliente de registro de Red Hat Network (rhn_register) son prerrequisitos en Red Hat Enterprise Linux 5 y 6 por usar mucha funcionalidad empresarial de Red Hat Network. Es crucial instalar los sistemas clientes antes de intentar usar en su entorno el Servidor proxy de RHN o el Servidor satélite de RHN.
Hay varios métodos para abordar la actualización del software cliente RHN. Uno de ellos tiene que ver con el almacenamiento de los RPM en un lugar accesible a todos los sistemas cliente y la implementación de paquetes con el comando más sencillo. En casi todos los casos, la implementación manual de yum, pup, y rhn_register no es necesaria. Esas herramientas de cliente no deben tener ningún problema para conectarse al satélite de RHN o su entorno Proxy. La información a continuación asume que yum "out of box", pup, y rhn_register no son las más recientes y no funcionan para su entorno.
Observe que los sistemas que se ejecutan en Red Hat Enterprise Linux 5 y 6 deben estar registrados con RHN, ya sea con firstboot después de la instalación o mediante el comando rhn_register.
Este documento presume que el cliente ha instalado en la red por lo menos uno de los servidores, ya sea el Servidor satélite de RHN o el Servidor Proxy de RHN. El siguiente ejemplo, demuestra un enfoque sencillo para implementar por primera vez yum, pup, y rhn_register (o up2date) por un administrador, y asume que las máquinas no tienen ningún servidor RHN funcionando:
rpm -Uvh
http://satellite.example.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm
http://satellite.example.com/pub/yum-3.2.8-9.el5.i386.rpm
http://satellite.example.com/pub/pirut-1.3.28-13.3l5.noarch.rpm
Copy to Clipboard Toggle word wrap
El administrador ya ha prellenado el directorio /var/www/html/pub/, en el entorno de satélite RHN o proxy RHN, con una copia de los RPM de yum, pup, y rhn_register que los sistemas clientes necesitan y luego, al ejecutar el comando anterior, los RPM han sido ejecutados en los sistemas clientes con una muestra del comando rpm -Uvh. Cuando se ejecuta desde un cliente, el comando rpm -Uvh, instala los RPM en el cliente, y asume que el nombre de dominio, las rutas y las versiones de RPM son correctas (observe que el comando ha sido dividido en varias líneas para propósitos de impresión y PDF, pero se debe escribir como una sola línea en el indicador de comandos):
Observe que la arquitectura (en este caso, i386) puede necesitar algunas alteraciones dependiendo del sistema que se va a servir.

2.2. Configuración de las aplicaciones cliente

Aunque no es necesario que cada usuario dentro de su organización se conecte de modo seguro al Servidor satélite de RHN o al Servidor Proxy de RHN ; ni que todos los clientes necesitan crear e implementar una llave GPG para paquetes personalizados; cada cliente que use el Servidor satélite de RHN o el Servidor Proxy de RHN debe reconfigurar el Agente de actualización de Red Hat (up2date) y posiblemente el Cliente de registro de Red Hat Network (rhn_register) para redirigirlo desde Red Hat Network hasta su Servidor satélite o Servidor proxy de RHN.

Importante

Aunque no sea configurable, observe que el puerto usado por up2date es 80 para HTTP y 443 para HTTP segura (HTTPS). Por defecto, yum en Red Hat Network 5 usa SSL únicamente. Por esta razón, los usuarios deben asegurarse de que sus cortafuegos permitan conexiones al puerto 443. Para desviar u omitir SSL, cambie el protocolo a serverURL de https a http en /etc/sysconfig/rhn/up2date. Igualmente, para utilizar la función de Monitorización de RHN y sondeos que requieran el Demonio de monitorización de RHN, observe que los sistemas de cliente deben permitir conexiones en puerto 4545 (o puerto 22, si se utiliza sshd en su lugar).
Por defecto, los comandos rhn_register y up2date se refieren a los servidores principales de Red Hat Network. Los usuarios deben reconfigurar los sistemas de cliente para referirse a sus Servidores satélite de RHN o Servidores proxy de RHN
Observe que las versiones más recientes del Agente de mantenimiento de Red Hat pueden ser configuradas para acomodar varios servidores RHN, y de este modo proporcionar protección contra fallos en caso de que el servidor primario no se pueda acceder. Consulte la Sección 2.2.5, “Implementación del servidor alternativo” para obtener instrucciones sobre cómo activar esta funcionalidad.
Las secciones siguientes describen los diferentes métodos para configurar los sistemas de cliente para que puedan acceder al servidor satélite o proxy de RHN. Para ver cómo prácticamente toda configuración puede ponerse en script, consulte el Capítulo 6, Creación manual del script de configuración Bootstrap de RHN.
Para registrar un sistema con el Servidor satélite de RHN, se requieren el nombre de dominio completamente calificado (FQDN) del servidor y el certificado SSL del Servidor satélite de RHN. Cuando se completan estos requerimientos, continúe con los siguientes pasos.
  1. Descargar el certificado SSL para el cliente:
    cd /usr/share/rhn/
    wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
    
    Copy to Clipboard Toggle word wrap
  2. Edite el archivo /etc/sysconfig/rhn/up2date:
    serverURL=https://satellite.example.com/XMLRPC
    noSSLServerURL=http://satellite.example.com/XMLRPC
    sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
    
    Copy to Clipboard Toggle word wrap
  3. Registrar la máquina:
    rhn_register
    
    Copy to Clipboard Toggle word wrap

2.2.2. Registro con las llaves de activación

Red Hat recomienda el uso de llaves de activación para registrar y configurar los sistemas cliente que acceden a los servidores proxy y satélite de RHN. Las llaves de activación sirven para registrar, autorizar, y suscribir sistemas en un lote. Para mayor información, consulte la sección sobre "llaves de activación" en la Guía de referencia del Servidor satélite de RHN.
Para registrar con una llave de activación:
  1. Genere una llave de activación. (Consulte la sección "Llaves de activación" en la Guía de referencia de servidor satélite de RHN)
  2. Importar llaves GPG personales
  3. Descargue e instale el RPM del certificado SSL desde el directorio /pub/ del servidor satélite o servidor proxy de RHN. El comando para este paso es similar a:
    rpm -Uvh http://satellite.example.com/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
    
    Copy to Clipboard Toggle word wrap
  4. Registre el sistema con el Servidor proxy RHN o con el Servidor proxy de RHN::
     rhnreg_ks --activationkey mykey --serverUrl https://satellite.example.com/XMLRPC 
    Copy to Clipboard Toggle word wrap
De modo alternativo, la mayoría de los pasos anteriores pueden combinarse en un script de shell que incluya las siguientes líneas:
wget -0 - http://satellite.example.com/pub/bootstrap.sh | bash
&& rhnreg_ks --activation-key my_key --serverUrl
https://satellite.example.com/XMLRPC
Copy to Clipboard Toggle word wrap
Note que el comando ha sido dividido en varias líneas para propósitos de impresión y PDF pero debe escribirse en una sola línea en el indicador de comandos.
El script bootstrap, generado en el momento de la instalación y disponible tanto para el Servidor satélite como para el Servidor proxy de RHN. La discusión sobre el script y la herramienta RHN Bootstrap que lo genera se aborda en detalle en el Capítulo 5, Uso de RHN Bootstrap.

2.2.3. Opción up2date --configure

El Agente de actualización de Red Hat en Red Hat Enterprise Linux 3 y 4 proporciona una interfaz para establecer varios parámetros. Para ver una lista completa de estos parámetros, consulte la página de manual up2date (man up2date en la línea de comandos).
Para reconfigurar el Agente de actualización de Red Hat, ejecute el siguiente comando como root:
 up2date --configure 
Copy to Clipboard Toggle word wrap
Aparecerá un cuadro de diálogo con varios parámetros que pueden ser reconfigurados. En la pestaña General, en Seleccionar servidor de Red Hat Network a utilizar, remplace el valor predeterminado por el nombre de dominio completamente calificado (FQDN) del Servidor satélite de RHN o del Servidor proxy de RHN, tal como https://su_proxy_o_sat.su_dominio.com/XMLRPC. Retenga el /XMLRPC al final. Cuando termine, haga clic en Aceptar.

Figura 2.1. Configuración de la interfaz gráfica de usuario Agente de actualización de Red Hat

Asegúrese de haber ingresado el nombre de dominio correcto de su servidor satélite o proxy. El ingreso incorrecto de un nombre de dominio o si se deja el espacio en blanco, evitará el lanzamiento de up2date --configure. Esto se puede solucionar si modifica el valor en el archivo de configuración up2date. Consulte la Sección 2.2.4, “Actualización manual de los archivos de configuración” para obtener instrucciones precisas.

Aviso

Los sistemas que ejecutan Red Hat Enterprise Linux 3 o 4 tienen incorporada la función de registro Agente de actualización de Red Hat y por lo tanto no se necesita instalar el Cliente de registro de Ret Hat Network. Los sistemas que ejecutan Red Hat Enterprise Linux 5 y 6 no usan up2date, y necesitan ejecutar rhn_register para registrar sus sistemas a Red Hat Network o Satélite y yum y pup para actualizar sus paquetes.

2.2.4. Actualización manual de los archivos de configuración

Como una alternativa a la interfaz gráfica de usuario, GUI descrita en la sección anterior, los usuarios pueden también reconfigurar el Agente de actualización de Red Hat al editar el archivo de configuración de la aplicación.
Para configurar el Agente de actualización de Red Hat en los sistemas cliente que se conectan al servidor satélite o proxy de RHN, modifique los valores de los parámetros serverURL y noSSLServerURL en el archivo de configuración /etc/sysconfig/rhn/up2date (como root). Remplace el valor predeterminado de la URL de Red Hat Network con el nombre de dominio completamente calificado (FQDN) del Servidor proxy de RHN o del servidor satélite de RHN. Por ejemplo:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC

noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC
Copy to Clipboard Toggle word wrap

Aviso

El parámetro httpProxy en /etc/sysconfig/rhn/up2date no hace referencia al Servidor proxy de RHN. Se utiliza para configurar un proxy HTTP opcional para el cliente. Con un Servidor proxy de RHN en su sitio, el parámetro httpProxy debe estar en blanco (no se debe establecer ningún valor).

2.2.5. Implementación del servidor alternativo

Al comenzar con up2date-4.2.38, el Agente de actualización de Red Hat puede ser configurado para buscar actualizaciones desde una serie de servidores de RHN. Esto puede ser bastante útil para mantener el abastecimiento de actualizaciones en caso de que su servidor satélite o proxy de RHN primario estén desconectados.
Para usar esta funcionalidad:
  1. Verifique si está ejecutando la versión más reciente o requerida de up2date como también si está ejecutando Red Hat Enterprise Linux 5 o 6.
  2. Añada de forma manual los servidores secundarios a los parámetros de serverURL y noSSLServerURL en el archivo de configuración /etc/sysconfig/rhn/up2date (como root).
  3. Añada el nombre de dominio calificado completo (FQDN) para el proxy o satélite inmediatamente después del servidor primario, separado por punto y coma (;). Por ejemplo:
    serverURL[comment]=Remote server URL
    serverURL=https://satellite.example.com/XMLRPC; 
    https://your_secondary.your_domain.com/XMLRPC;
    
    noSSLServerURL[comment]=Remote server URL without SSL
    noSSLServerURL=http://satellite.example.com/XMLRPC; 
    http://your_secondary.your_domain.com/XMLRPC;
    
    Copy to Clipboard Toggle word wrap
    La conexión a los servidores se intenta en el orden provisto aquí. Incluya cuantos servidores sean necesarios

2.3. Programa actualizador de paquetes

Red Hat Enterprise Linux 5 ofrece un programa de ejecución en el panel gráfico de escritorio que periódicamente busca actualizaciones desde el servidor de RHN o Satélite y alerta a los usuarios cuando hay una nueva actualización disponible.

Figura 2.2. Programa actualizador de paquetes

La Miniaplicación del programa actualizador de paquetes permanece en la bandeja de notificaciones del panel de escritorio y busca periódicamente nuevas actualizaciones. La miniaplicación también permite realizar tareas de mantenimiento de paquetes al hacer clic y elegir entre las siguientes acciones:
  • Refresh — Busca nuevas actualizaciones de RHN o Satélite
  • View Updates — lanza la aplicación del actualizador de paquetes para que se puedan ver en detalle las actualizaciones disponibles y configurar las actualizaciones para las especificaciones.
  • Apply Updates — Descarga e instala todos los paquetes actualizados.
  • Quit — cierra la aplicación

Capítulo 3. Infraestructura del SSL

Para los usuarios de Red Hat Network, la seguridad es un tema de suma importancia. Una de las fortalezas de Red Hat Network es la habilidad de procesar cada una de las solicitudes a través de Capa de conexión segura/Secure Sockets Layer o SSL. Para mantener este nivel de seguridad, los usuarios que instalan Red Hat Network dentro de sus infraestructuras deben generar las llaves y certificados SSL personalizados.
La creación e implementación manual de las llaves y certificados SSL pueden ser bastante engorrosas. Tanto el Servidor proxy de RHN como el Servidor satélite de RHN le permitirán construir sus propias llaves y certificados SSL durante la instalación, con base en sus propios certificados de Autoridad Certificadora (conocida como CA por sus siglas en inglés). Además, la Herramienta de mantenimiento SSL de RHN para la línea de comandos ha sido creada para este fin. Estas llaves y certificados deben ser implementados en todos los sistemas dentro de la infraestructura administrada. En muchos casos, la implementación de estas llaves y certificados SSL es automatizada. Este capítulo describe métodos eficientes para realizar todas estas tareas.
Por favor tenga en cuenta que este capítulo no explica en profundidad SSL. La Herramienta de mantenimiento SSL de RHN fue diseñada para ocultar la complejidad que envuelve la creación y el mantenimiento de esta infraestructura de llaves públicas (PKI). Para obtener mayor información, consulte algunas de las referencias disponibles en la librería más cercana.

3.1. Una breve introducción al SSL

SSL, por Secure Sockets Layer, es un protocolo que permite a los clientes pasar información de una forma segura. SSL utiliza un sistema de pares de llaves pública y privada para encriptar la comunicación pasada entre el cliente y el servidor. Los certificados públicos pueden ser accesibles a cualquier persona, pero las llaves privadas deben permanecer en un lugar seguro. Es la relación matemática (una firma digital) entre el certificado público y la llave privada lo que hace que este sistema funcione. A través de esta relación se establece una conexión confiable.

Nota

En este documento se discutirá acerca de las llaves privadas SSL y los certificados públicos. Ambos conocidos como llaves, una pública y otra privada. Sin embargo, al tratar SSL, por convención nos referimos a la mitad pública de un par de llaves SSL (o conjunto de llaves) como un certificado público.
La infraestructura SSL de una organización está conformada generalmente por estas llaves y certificados:
  • Llave privada y certificado público SSL de Autoridad certificadora (CA) — generalmente se crea un solo par por organización. El certificado público es firmado digitalmente por su llave privada. El certificado público se distribuye a cada sistema.
  • Llave privadas y certificado público SSL del servidor web — un set por servidor de aplicaciones. El certificado público es firmado en forma digital tanto por la llave privada como por la llave privada CA SSL. Generalmente nos referimos al juego de llaves del servidor web; ya que se genera un intermediario de una petición de certificado SSL. Los detalles de uso no son importantes en esta discusión. Todos los tres se ejecutan en un servidor de RHN.
El siguiente escenario le ayudará a visualizar el concepto: Una organización con un Servidor satélite y cinco servidores proxy, generará un par de llaves CA SSL y seis juegos de llaves SSL del servidor web. El certificado público CA SSL es distribuido a todos los sistemas y usado por todos los clientes para establecer una conexión con sus respectivos servidores. Cada servidor tiene su propio juego de llaves SSL que está específicamente vinculado al nombre de host del servidor y generado con su propia llave privada SSL y por la llave privada CA SSL en conjunto. Esto establece una asociación digital verificable entre el certificado público SSL del servidor web y el par de llaves CA SSL y la llave privada del servidor. El juego de llaves del servidor de web no puede ser compartido con otros servidores.

Importante

La parte más crítica de este sistema es el par de llaves CA SSL. Desde esa llave privada y el certificado público un administrador puede regenerar cualquier juego de llaves SSL del servidor web. Este par de llaves CA SSL debe guardarse en un lugar seguro. Se recomienda que una vez la infraestructura de servidores RHN esté configurada y en ejecución, usted archive el directorio SSL creado generado por esta herramienta o por el instalador en un medio independiente, escriba la contraseña CA y guarde el medio y la contraseña en un lugar seguro.

3.2. La Herramienta de configuración de servicios

Red Hat Network proporciona una herramienta de línea de comandos que facilita el manejo de la infraestructura de seguridad de la organización: la Herramienta de mantenimiento SSL de RHN comúnmente conocida por su comando rhn-ssl-tool. Esta herramienta está disponible como parte del paquete rhns-certs-tools. Este paquete puede encontrarse dentro de los canales de software para las últimas versiones del Servidor proxy de RHN y el Servidor satélite de RHN (también para el ISO del servidor satélite de RHN). La Herramienta de mantenimiento SSL de RHN le permite generar su propio par de llaves CA SSL, así como el juego de llaves SSL del servidor web (algunas veces llamada par de llaves).
Esta herramienta es solamente una herramienta de construcción. Genera todas las llaves SSL y certificados que se requieren. También empaqueta los archivos en formato RPM para una rápida distribución e instalación de las máquinas cliente. Sin embargo, no las implementa. Esta tarea es asignada al administrador, o en muchos casos, automatizada por el Servidor satélite de RHN.

Nota

El archivo spacewalk-certs-tools, el cual contiene rhn-ssl-tool, puede ser instalado y ejecutado en cualquier sistema Red Hat Enterprise Linux con los mínimos requerimientos. Esto es conveniente para los administradores que deseen manejar su infraestructura SSL desde su estación de trabajo o cualquier otro sistema diferente al Servidor de RHN.
Estos son los casos en los que se requiere la herramienta:
  • Cuándo actualizar el certificado público de la Autoridad certificadora (CA)
  • Al instalar un Servidor proxy de RHN versión 3.6 o posterior que se conecta con los servidores centrales de RHN como su servicio de nivel superior - el servicio alojado, por razones de seguridad, no puede ser un repositorio de su certificado y llave CA SSL, los cuales son privativos de su organización.
  • Cuando se reconfigura una infraestructura RHN para usar SSL donde no existía.
  • Cuando se añaden varios servidores satélites de RHN a la infraestructura RHN - consulte con su representante de Red Hat para obtener instrucciones al respecto.
Estos son los casos en los que no se requiere la herramienta:
  • Durante la instalación de un Servidor satélite de RHN - todos los parámetros SSL son configurados durante el proceso de instalación. Las llaves y certificados SSL se construyen e implementan automáticamente.
  • Durante la instalación de un Servidor proxy RHN - versión 3.6 o superior conectado a un Servidor satélite de RHN 3.6 o superior como su servidor de nivel superior - el Servidor satélite de RHN contiene toda la información SSL necesaria para configurar, construir e implementar los certificados e implementar las llaves SSL del Servidor proxy de RHN.
Los procedimientos de instalación del Servidor satélite de RHN y del Servidor proxy de RHN garantizan que el certificado público sea implementado para el directorio /pub de cada servidor. Este certificado público es utilizado por los sistemas cliente para conectarse al Servidor de RHN. Consulte la Sección 3.3, “Implementación del certificado público CA SSL a los clientes” para obtener mayor información.
Para abreviar, si la infraestructura de las organizaciones de RHN presenta la última versión del Servidor satélite de RHN como su servicio de nivel superior, necesitará usar la herramienta.

3.2.1. Generación de certificados SSL

Seguridad, flexibilidad y portabilidad son los beneficios primarios del uso de la Herramienta de mantenimiento SSL de RHN . La seguridad se consigue mediante la creación de certificados y llaves SSL del servidor web para cada servidor de RHN, todos firmados por un único par de llaves CA SSL creado por su organización. La flexibilidad se consigue gracias a la posibilidad de ejecutar la herramienta en cualquier máquina que tenga instalado el paquete spacewalk-certs-tools. La portabilidad existe en la estructura construida que puede ser almacenada por seguridad en cualquier sitio y luego instalada cuando sea necesario.
De nuevo, si su infraestructura de nivel superior de RHN utiliza la versión más reciente del Servidor satélite de RHN, lo único que usted tendrá que hacer es restaurar el árbol ssl-build desde un archivo al directorio /root y utilizar las herramientas de configuración provistas dentro del sitio web del Servidor satélite de RHN.
Para hacer el mejor uso de la Herramienta de mantenimiento SSL de RHN, en el orden dado. Consulte las secciones restantes para obtener mayor información:
  1. Instale el paquete spacewalk-certs-tools en un sistema dentro de su organización, por ejemplo, en un Servidor satélite de RHN o un Servidor proxy de RHN.
  2. Cree una llave SSL de Autoridad certificadora para la organización e instale el RPM resultante o el certificado público en todos los sistemas cliente. Consulte la Sección 3.2.3, “Generación del par de llaves CA SSL.” para obtener mayor información.
  3. Cree un juego de llaves SSL de servidor web para cada uno de los Proxis y satélites que serán implementados e instale los RPM resultantes en los servidores de RHN
  4. Reinicie el servicio httpd:
     /sbin/service httpd restart 
    Copy to Clipboard Toggle word wrap
  5. Archive el árbol creado SSL - conformado por el directorio de construcción primario y todos los subdirectorios y archivos - en un medio de almacenamiento, ejemplo un CD o DVD (los requerimientos de espacio de disco son insignificantes).
  6. Verifique y luego almacene este archivo en un lugar seguro, tal como el descrito en la sección sobre copias de seguridad en Requerimientos adicionales de la Guía de instalación de Proxy o satélite.
  7. Registre y asegure la contraseña CA para un uso futuro.
  8. Borrar el árbol de construcción del sistema donde fue construido por razones de seguridad, pero únicamente después de que la infraestructura RHN ha sido establecida y esté configurada.

    Nota

    Cuando se necesiten una llave adicional SSL de servidor web, restaure el árbol creado en el sistema mediante la Herramienta de mantenimiento SSL de RHN y repita los pasos del 3 al 7.

3.2.2. Opciones de Herramienta de mantenimiento SSL de RHN

La Herramienta de mantenimiento SSL de RHN ofrece una plétora de opciones de línea de comandos para generar su par de llaves de la Autoridad certificadora SSL y administrar sus llaves y certificados SSL del servidor. La herramienta ofrece esencialmente tres opciones de listados de ayudas para la línea de comandos: rhn-ssl-tool --help (general), rhn-ssl-tool --gen-ca --help (Autoridad Certificadora), y rhn-ssl-tool --gen-server --help (Servidor web). La página de manual para la rhn-ssl-tool también está descrita y disponible como ayuda: man rhn-ssl-tool.
Las dos tablas siguientes dividen las opciones de acuerdo a su tarea respectiva, ya sea CA o la generación del juego de llaves de servidor web.
Este conjunto de opciones debe estar precedido por el argumento --gen-ca:
Expand
Tabla 3.1. Opciones SSL de Autoridad certificadora (CA) (rhn-ssl-tool --gen-ca --help)
Opción Descripción
--gen-ca Genera un par de llaves CA (Autoridad certificadora) y RPM público. Este debe ser ejecutado con cualquiera de las opciones restantes de la tabla.
-h, --help Muestra la pantalla de ayuda con una lista de opciones básicas específicas para generar y administrar un CA (Autoridad certificadora).
-f, --force Fuerza la creación de una llave privada CA y/o de un certificado público.
-p=, --password=CONTRASEÑA La contraseña CA. Se le pedirá que introduzca esta opción si no se encuentra. Guárdela de una forma segura.
-d=, --dir=DIRECTORIO Requerido para la mayoría de comandos - El directorio donde el certificado y el RPM serán construidos. Por defecto es ./ssl-build.
--ca-key=ARCHIVO El nombre del archivo de la llave privada CA. Por defecto es RHN-ORG-PRIVATE-SSL-KEY.
--ca-cert=ARCHIVO El nombre del archivo del certificado público CA. Por defecto es RHN-ORG-TRUSTED-SSL-CERT.
--cert-expiration=EXPIR_CERT La fecha de caducidad del certificado público CA. Por defecto es el número de días hasta un día antes del cambio de época (o 01-18-2038).
--set-country=CÓDIGO_PAÍS El código de dos letras del país. Por defecto es US.
--set-state=ESTADO_O_PROVINCIA El estado o provincia del CA. Por defecto es ''.
--set-city=CIUDAD_O_LOCALIDAD La ciudad o localidad. Por defecto es ''.
--set-org=ORGANIZACIÓN La compañía u organización, tal como Red Hat. Por defecto es Example Corp. Inc.
--set-org-unit=CONFIG_UNIDAD_ORG La unidad corporativa, tal como RHN. Por defecto es ''.
--set-common-name=NOMBREDEHOST Generalmente no se establece para el CA. - El nombre común.
--set-email=CORREO-E Generalmente no se establece para el CA. - dirección de correo-e.
--rpm-packager=EMPAQUETADOR Empaquetador del RPM generado, tal como "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=DISTRIBUIDOR El distribuidor del RPM generado, tal como "IS/IT Example Corp."
-v, --verbose Muestra mensajes verbosos. Esta opción es acumulativa - por cada "v" añadida se conseguirá un mayor grado de verbosidad.
--ca-cert-rpm=CERT_RPM Rara vez cambia - el nombre del RPM que contiene el certificado CA (El nombre de archivo base únicamente, no el nombre que incluye la versión: filename-version-release.noarch.rpm)
--key-only Rara vez usado - Genera una llave privada CA únicamente. Revise --gen-ca --key-only --help para obtener mayor información.
--cert-only Rara vez usado - Genera un certificado público CA únicamente. Revise --gen-ca --cert-only --help para obtener mayor información.
--rpm-only Rara vez usado - Genera un RPM para implementación únicamente. Revise --gen-ca --rpm-only --help para obtener mayor información.
--no-rpm Rara vez usado - Realiza todos los pasos relacionados con el CA excepto la generación del RPM.
El siguiente set de opciones debe estar precedido de un argumento --gen-server:
Expand
Tabla 3.2. Opciones del SSL de servidor web (rhn-ssl-tool --gen-server --help)
Opción Descripción
--gen-server Genera el juego de llaves SSL de servidor web, el RPM y el archivo tar. Esta opción debe ser usada con cualquiera de las opciones restantes de esta tabla.
-h, --help Muestra la pantalla de ayuda con una lista de opciones básicas especificas para la generación y administración de un par de llaves de servidor.
-p=, --password=CONTRASEÑA La contraseña CA. Se le pedirá que introduzca esta opción si no se encuentra. Guárdela de una forma segura.
-d=, --dir=DIRECTORIO Requerido para la mayoría de comandos - El directorio donde el certificado y el RPM serán construidos. Por defecto es ./ssl-build.
--server-key=ARCHIVO El nombre del archivo de la llave privada SSL de servidor web. Por defecto es server.key.
--server-cert-req=ARCHIVO El nombre de archivo solicitado del certificado SSL de servidor web. Por defecto es server.csr.
--server-cert=ARCHIVO El nombre de archivo del certificado SSL del servidor web. Por defecto es server.crt.
--startdate=YYMMDDHHMMSSZ La fecha de inicio para validar el certificado de servidor en el formato ejemplificado: año, mes, día, hora, minuto, segundo (dos caracteres por valor). Z significa Zulú y es requerido. Por defecto es una semana antes de la generación.
--cert-expiration=EXPIR_CERT_SERVIDOR La fecha de caducidad del certificado de servidor. Por defecto es el número de días hasta un día antes del cambio de época (o 01-18-2038).
--set-country=CÓDIGO_PAÍS El código de dos letras del país. Por defecto es US.
--set-state=ESTADO_O_PROVINCIA El estado o provincia. Por defecto es "North Carolina".
--set-city=CIUDAD_O_LOCALIDAD La ciudad o localidad. Por defecto es Raleigh.
--set-org=ORGANIZACIÓN La compañía u organización, tal como Red Hat. Se predetermina como Example Corp. Inc.
--set-org-unit=CONFIG_UNIDAD_ORG La unidad corporativa, tal como RHN. Por defecto es "unit."
--set-hostname=NOMBREDEHOST El nombre de host del servidor de RHN que recibirá la llave. Por defecto se establece dinámicamente con el nombre de host de la máquina de construcción.
--set-email=CORREO-E La dirección de correo-e del contacto del certificado. Por defecto es admin@example.corp.
--rpm-packager=EMPAQUETADOR Empaquetador del RPM generado, tal como "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=DISTRIBUIDOR El distribuidor del RPM generado, tal como "IS/IT Example Corp."
-v, --verbose Muestra mensajes verbosos. Esta opción es acumulativa - por cada "v" añadida se conseguirá un mayor grado de verbosidad.
--key-only Rara vez usado - Genera únicamente una llave privada de servidor. Revise --gen-server --key-only --help para obtener mayor información.
--cert-req-only Rara vez usado - Genera únicamente una petición de certificado de servidor. Revise --gen-server --cert-req-only --help para mayor información.
--cert-only Rara vez usado - Genera únicamente un certificado de servidor. Revise --gen-server --cert-only --help para obtener mayor información.
--rpm-only Rara vez usado - Genera únicamente un RPM para implementación. Revise --gen-server --rpm-only --help para obtener mayor información.
--no-rpm Rara vez usado - Ejecuta todos los pasos relacionados con el servidor excepto la generación del RPM.
--server-rpm=SERVIDOR_RPM Rara vez cambiado - El nombre del RPM que contiene el juego de llaves SSL del servidor web (el nombre de archivo base, no el nombre de archivo y versión: filename-version-release.noarch.rpm).
--server-tar=SERVIDOR_TAR Rara vez se cambia - Nombre del archivo tar del juego de llaves SSL de servidor web y certificado CA que es utilizado únicamente por las rutinas de instalación del Servidor proxy de RHN hospedado (el nombre de archivo de base, no filename-version-release.tar).

3.2.3. Generación del par de llaves CA SSL.

Antes de crear el juego de llaves del servidor web, usted debe generar un par de llaves SSL de Autoridad certificadora (CA). Un certificado público CA SSL se distribuye a los sistemas cliente del satélite o del Proxy. La Herramienta de mantenimiento SSL de RHN le permitirá generar un par de llaves CA SSL cuando sea necesario y reutilizarlas para implementaciones de servidores de RHN posteriores.
El proceso de construcción crea automáticamente el par de llaves y el RPM público para ser distribuido a los sistemas cliente. Todos los componentes terminan en el directorio de construcción especificado en la línea de comandos, generalmente /root/ssl-build (o /etc/sysconfig/rhn/ssl para satélites y Proxies antiguos). Para generar un par de llaves CA SSL, ejecute un comando como el siguiente:
rhn-ssl-tool --gen-ca --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example Inc." \
--set-org-unit="SSL CA Unit"
Copy to Clipboard Toggle word wrap
Remplace los valores de este ejemplo con los de su organización. Esto dará como resultado los siguientes archivos relevantes en el directorio de construcción especificado:
  • RHN-ORG-PRIVATE-SSL-KEY — la llave privada CA SSL
  • RHN-ORG-TRUSTED-SSL-CERT — El certificado público CA SSL
  • rhn-org-trusted-ssl-cert-VERS-LANZAMIENTO.noarch.rpm — El RPM preparado para ser distribuido a los sistemas cliente. Contiene el certificado público CA SSL y lo instala en: /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
  • rhn-ca-openssl.cnf — el archivo de configuración CA SSL
  • latest.txt — siempre lista la versión más reciente de los archivos pertinentes.
Cuando termine, estará listo para distribuir los RPM a los sistemas cliente. Para obtener mayor información, consulte la Sección 3.3, “Implementación del certificado público CA SSL a los clientes”.

3.2.4. Generación del juego de llaves SSL del servidor web

En este punto, ya deben de haberse generado un par de llaves SSL de CA. Sin embargo, es posible que las llaves SSL de servidor Web se establezcan con más frecuencia, en especial si hay más de un proxy o satélite implementado. Un conjunto de llaves y certificado distintos debe haberse generado e instalado para cada nombre de host de servidor RHN, por lo tanto observe que el valor de --set-hostname es diferente para cada servidor.
El proceso de construcción del certificado de servidor funciona de un modo muy similar al usado para generar el par de llaves CA SSL. Hay, sin embargo, una excepción: todos los componentes del servidor terminan en subdirectorios del directorio creado que indican el nombre de la máquina del sistema creado, tal como /root/ssl-build/NOMBRE_MAQUINA. Para generar certificados de servidor, ejecute un comando similar al siguiente:
rhn-ssl-tool --gen-server --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example	Inc." \
--set-org-unit="IS/IT" --set-email="admin@example.com" \
--set-hostname="rhnbox1.example.com
Copy to Clipboard Toggle word wrap
Remplace los valores del ejemplo con los apropiados para su organización. Como resultado se obtendrán los siguientes archivos relevantes en el subdirectorio específico a la máquina en el directorio creado:
  • server.key — la llave privada de servidor SSL de servidor web.
  • server.csr — la petición de certificado SSL de servidor web.
  • server.crt — el certificado público SSL de servidor web.
  • rhn-org-httpd-ssl-key-pair-NOM-VERS-LANZ_MÁQUINA.noarch.rpm — el RPM preparado para ser distribuido a los servidores de RHN. También se genera el archivo src.rpm asociado. Este RPM contiene los siguientes tres archivos. Se instalarán en estos lugares:
    • /etc/httpd/conf/ssl.key/server.key
    • /etc/httpd/conf/ssl.csr/server.csr
    • /etc/httpd/conf/ssl.crt/server.crt
  • rhn-server-openssl.cnf — el archivo de configuración SSL de servidor web
  • latest.txt — siempre lista la versión más reciente de los archivos pertinentes.
Una vez completado, podrá distribuir e instalar el RPM en los respectivos servidores de RHN. Observe que el servicio httpd debe ser reiniciado después de la instalación:
 /sbin/service httpd restart 
Copy to Clipboard Toggle word wrap

3.3. Implementación del certificado público CA SSL a los clientes

Tanto el proceso de instalación del Servidor proxy como del servidor satélite de RHN facilitan relativamente la implementación de los sistemas cliente al generar el RPM y el certificado público CA SSL. Estos procesos de instalación dejan a disposición pública una copia del RPM en el directorio /var/www/html/pub/ del servidor RHN.
Este directorio público puede ser fácilmente inspeccionado a través del navegador de web: http://proxy-or-sat.example.com/pub/.
El certificado público CA SSL en ese directorio puede ser descargado a un sistema cliente mediante wget o curl. Por ejemplo:
curl -O	http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
wget http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Copy to Clipboard Toggle word wrap
Alternativamente, si el RPM del certificado público CA SSL está en el directorio /pub, puede ser instalado en un sistema cliente directamente:
rpm -Uvh \
http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VERS-LANZ.noarch.rpm
Copy to Clipboard Toggle word wrap
Confirme el nombre real del certificado o RPM antes de ejecutar este comando.

3.4. Configuración de los sistemas cliente

Una vez el RPM o certificado crudo ha sido implementado al sistema cliente, el administrador de ese sistema debe modificar el archivo de configuración del Agente de actualización de Red Hat y el Cliente de registro de RHN (de ser necesario) para usar el nuevo archivo de certificado CA SSL y para conectarse al Servidor proxy o al servidor satélite de RHN apropiado. El lugar generalmente aceptado para el certificado público CA SSL es el directorio /usr/share/rhn.
Los servidores proxy y satélite de RHN tienen instalada de forma predeterminada RHN Bootstrap, la cual puede reducir en gran medida estos pasos repetitivos y simplificar el proceso de registro y configuración de sistemas cliente. Por favor consulte el Capítulo 5, Uso de RHN Bootstrap para obtener mayor información.

Capítulo 4. Importación de las llaves GPG personalizadas

Para los usuarios que desean construir y distribuir sus propios RPM de una forma segura, se recomienda que todos los RPM personalizados estén firmados con GPG (GNU Privacy Guard). La generación y construcción de llaves GPG y la construcción de paquetes firmados con GPG se describen en la Guía de administración de canales de Red Hat Network.
Una vez el paquete haya sido firmado, la llave pública puede ser implementada en todos los sistemas que reciben esos RPM. Esta tarea tiene dos pasos: primero, crear una ubicación central para la llave pública con el fin de que los clientes puedan obtenerla; y segundo, añadir la llave al llavero de GPG local para cada sistema.
El primer paso es común y puede ser manejado mediante el método recomendado para implementar aplicaciones de cliente de RHN. (Consulte la Sección 2.1, “Implementación de los últimos RPM clientes de Red Hat Network”.) Para llevar a cabo este procedimiento, cree un directorio público en el servidor web y colóquele la firma pública GPG:
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
Copy to Clipboard Toggle word wrap
La llave puede ser descargada desde los sistemas cliente mediante wget:
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/YOUR-RPM-GPG-KEY
Copy to Clipboard Toggle word wrap
La opción -O- envía los resultados a la salida estándar mientras que la opción -q activa el modo silencioso en wget. No olvide remplazar la variable SU-LLAVE-GPG-RPM por el nombre de archivo de su llave.
Una vez la llave está disponible en el sistema de archivos del sistema cliente, impórtela al llavero de GPG local. Sistemas operativos diferentes requieren diferentes métodos.
Para Red Hat Enterprise Linux 3 o superior, utilice el siguiente comando:
rpm --import /path/to/YOUR-RPM-GPG-KEY
Copy to Clipboard Toggle word wrap
Una vez la llave GPG ha sido añadida correctamente al cliente, el sistema debe estar en la capacidad de validar RPM personalizados firmados con la llave correspondiente.

Nota

Cuando utilice canales y RPM, cree siempre una llave GPG personal para estos paquetes. El sitio de la llave GPG también necesita ser añadido al perfil de Kickstart.
La llave GPG personal debe ser agregada a los sistemas clientes o si no la instalación fallará.

Capítulo 5. Uso de RHN Bootstrap

Red Hat Network proporciona la herramienta RHN Bootstrap para automatizar varios de los pasos de la reconfiguración manual descrita en los capítulos anteriores. RHN Bootstrap juega un papel integral en el Programa de instalación del servidor satélite de RHN, al permitir la generación del script bootstrap durante la instalación.
Los usuarios del Servidor proxy de RHN y aquellos usuarios con parámetros de satélite actualizados, requieren una herramienta bootstrap que pueda ser usada de forma independiente. RHN Bootstrap, invocada con el comando /usr/bin/rhn-bootstrap, sirve para cumplir este propósito y viene instalado de forma predeterminada tanto en el Servidor satélite como en el Servidor proxy de RHN.
Si se utiliza correctamente, el script generado por esta herramienta puede ejecutarse desde cualquier sistema cliente para que realice las siguientes tareas:
  • Redirigir aplicaciones cliente al Proxy o satélite de RHN
  • Importar llaves GPG personalizadas
  • Instalar certificados SSL
  • Registrar el sistema a RHN y a los grupos de sistemas y canales particulares con ayuda de las llaves de activación.
  • Realizar diferentes actividades posteriores a la instalación, incluyendo la actualización de paquetes, ejecución de reinicios y la modificación de la configuración de RHN.
Los usuarios deben tener en cuenta, sin embargo, los riesgos inherentes de la utilización de un script para llevar a cabo la configuración. Las herramientas de seguridad, como los certificados SSL, son instaladas por el mismo script; por lo cual no existen aún y no sirven para procesar transacciones. Esto conlleva a la posibilidad de que alguien se haga pasar por el satélite y envíe datos nocivos. El uso de los cortafuegos del usuario y el hecho de que tanto el satélite como todos los sistemas cliente están restringidos de tráfico exterior mitiga este problema. El proceso de registro se lleva a cabo a través de SSL, siendo así protegido.
El script bootstrap.sh se sitúa de forma automática en el directorio /var/www/html/pub/bootstrap del servidor RHN. Desde ahí puede descargarse y ejecutarse en todos los sistemas clientes. Observe que se requiere alguna preparación y modificación de posgeneración, como se identificó en las siguientes secciones. Consulte la Sección 5.4, “Configuración de opciones de RHN Bootstrap para obtener una lista completa de opciones. Por último, consulte el Apéndice A, Script de ejemplo Bootstrap

5.1. Preparación para instalar RHN Bootstrap

Ya que RHN Bootstrap (rhn-bootstrap) depende de otros componentes de la infraestructura de Red Hat Network para configurar los sistemas cliente, esos componentes deben estar preparados antes de la generación del script. La siguiente lista identifica las medidas iniciales que se deben tomar:
  • Genere las llaves de activación que van a ser llamadas por el script. Las llaves de activación sirven para registrar sistemas de Red Hat Enterprise Linux, concederles derechos a uno de los niveles de servicio de RHN y suscribirlos a canales y grupos de sistemas. Todo ello en tan solo una acción. Observe que la cuenta de la organización debe tener derechos administrativos disponibles para usar una llave de activación, en tanto que la inclusión de múltiples llaves de activación requiere derechos de aprovisionamiento. Genere las llaves de activación a través de la página Llaves de activación dentro de la categoría Sistemas del sitio web de RHN (tanto para los servidores centrales de RHN para el Proxy o para el nombre de dominio completamente calificado del satélite). Consulte los capítulos sobre el Agente de actualización y los capítulos del sitio web de RHN en la Guía de referencia de RHN para obtener instrucciones sobre creación y uso.
  • Red Hat le recomienda firmar sus RPM con una llave personalizada de GNU Privacy Guard (GPG). Cree la llave disponible para que pueda referirse a ella desde el script. Genere la llave tal y como se describe en la Guía de administración de canales de RHN y colóquela en el directorio /var/www/html/pub/ del servidor de RHN, de acuerdo con el Capítulo 4, Importación de las llaves GPG personalizadas.
  • Si desea utilizar el script para implementar su certificado público CA SSL, tenga disponible el certificado o el paquete RPM que lo contiene en ese servidor de RHN e inclúyalo durante la generación del script con la opción --ssl-cert. Consulte el Capítulo 3, Infraestructura del SSL para obtener mayor información.
  • Tenga los valores listos para desarrollar uno o más scripts bootstrap, según la variedad de sistemas a ser reconfigurados. Como RHN Bootstrap proporciona un conjunto completo de opciones de reconfiguración, utilícelas para generar diferentes scripts bootstrap a fin de acomodar cada tipo de sistema. Por ejemplo, bootstrap-web-servers.sh podría servir para reconfigurar sus servidores de web, en tanto que bootstrap-app-servers.sh podría manejar los servidores de aplicaciones. Consulte la Sección 5.4, “Configuración de opciones de RHN Bootstrap para obtener una lista completa.

5.2. Generación de scripts RHN Bootstrap

Ahora que todos los componentes necesarios están en su lugar, puede usar RHN Bootstrap para generar los scripts requeridos. Inicie una sesión como root en su servidor satélite o servidor proxy de RHN y ejecute el comando rhn-bootstrap seguido por las opciones y valores deseados. Si no se incluye ninguna opción, se creará un archivo bootstrap.sh en el subdirectorio bootstrap/ que contiene los valores esenciales derivados del servidor, incluidos el nombre de host, el certificado SSL, las configuraciones SSL y GPG, en caso de que existan, y una llamada al archivo client-config-overrides.txt.
Como mínimo, Red Hat recomienda que su script contenga también llaves de activación, llaves GPG y opciones avanzadas de configuración de la siguiente manera:
  • Utilice la opción --activation-keys para incluir llaves, teniendo en cuenta los derechos requeridos señalados en la Sección 5.1, “Preparación para instalar RHN Bootstrap”.
  • Utilice la opción --gpg-key para identificar la ruta de la llave y el nombre del archivo durante la generación del script. De lo contrario, utilice la opción --no-gpg para desactivar esta verificación en los sistemas cliente. Red Hat le recomienda retener esta medida de seguridad.
  • Incluya la opción --allow-config-actions para habilitar la administración de configuración remota en todos los sistemas cliente influenciados por el script. Esta función es útil para reconfigurar varios sistemas simultáneamente.
  • Incluya la opción --allow-remote-commands para habilitar el uso de scripts remotos en todos los sistemas cliente. Como la administración de configuración, esta función facilita la reconfiguración simultánea de varios sistemas.
Al finalizar, su comando se verá así:
	rhn-bootstrap --activation-keys KEY1,KEY2 \
		--gpg-key /var/www/html/pub/MY_CORPORATE_PUBLIC_KEY \
		--allow-config-actions \
		--allow-remote-commands
Copy to Clipboard Toggle word wrap
No olvide incluir los nombres reales de las llaves. Consulte la Sección 5.4, “Configuración de opciones de RHN Bootstrap para obtener una lista completa de las opciones.

5.3. Uso del script RHN Bootstrap

Cuando termine la preparación del script, estará listo para ejecutarse. Inicie una sesión en el Servidor de Satélite de RHN o el Servidor proxy de RHN, vaya al directorio /var/www/html/pub/bootstrap/ y ejecute el siguiente comando, alterando el nombre de host y el nombre del script cuando sea necesario para ajustarse al tipo de sistema:
cat bootstrap-EDITED-NAME.sh | ssh root@CLIENT_MACHINE1 /bin/bash
Copy to Clipboard Toggle word wrap
Una alternativa menos segura es el uso de wget o curl para descargar y ejecutar el script desde cada sistema cliente. Inicie una sesión en cada sistema cliente y ejecute el siguiente comando, modificando el nombre de host y del script según sea necesario:
wget -qO - \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Copy to Clipboard Toggle word wrap
O con curl:
curl -Sks \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Copy to Clipboard Toggle word wrap
Una vez el script haya sido ejecutado en cada sistema cliente, todos deben estar configurados para utilizar el servidor RHN.

5.4. Configuración de opciones de RHN Bootstrap

RHN Bootstrap ofrece varias opciones de la línea de comandos para la creación de scripts bootstrap. Aunque la descripción de estas opciones se encuentra en la siguiente tabla, asegúrese de que esté disponible en la versión de la herramienta instalada en su servidor de RHN mediante este comando rhn-bootstrap --help o al consultar la página de manual.
Expand
Tabla 5.1. Opciones de RHN Bootstrap
Opción Descripción
-h, --help Muestra una pantalla de ayuda con una lista de las opciones específicas para generar el script bootstrap.
--activation-keys=LLAVES_ACTIVACIÓN Las llaves de activación tal y como se definen en el sitio web de RHN con varias entradas separadas por comas y sin espacios.
--overrides=ANULA Nombre de archivo de sobrescritura de la configuración. Por defecto es client-config-overrides.txt.
--script=SCRIPT El nombre de archivo del script bootstrap. Por defecto es bootstrap.sh.
--hostname=NOMBREDEHOST El nombre de dominio completamente calificado (FQDN) del servidor al cual los sistemas cliente se conectarán.
--ssl-cert=CERT_SSL La ruta al certificado público SSL de su organización, ya sea un paquete o un certificado crudo. Será copiada a la opción --pub-tree. Un valor de "" forzará una búsqueda de --pub-tree.
--gpg-key=GPG_KEY Es la ruta a la llave pública GPG de su organización, en caso de que se utilice. Será copiada en el sitio especificado por la opción --pub-tree.
--http-proxy=HTTP_PROXY La configuración del HTTP proxy para el sistema cliente de la forma hostname:port. Un valor de "" desactiva este parámetro.
--http-proxy-username=HTTP_PROXY_NOMBREUSUARIO Si se está utilizando un HTTP proxy, especifique un nombre de usuario. Un valor de "" desactiva esta opción.
--http-proxy-password=HTTP_PROXY_CONTRASEÑA Si se está usando una autenticación HTTP proxy, especifique una contraseña.
--allow-config-actions Valor booleano; incluyendo esta opción se establecerá la posibilidad de realizar todas las acciones de configuración a través de RHN. Esto requiere la instalación de ciertos paquetes rhncfg-*, posiblemente a través de una llave de activación.
--allow-remote-commands Valor booleano, incluyendo esta opción el sistema habilitará los comandos remotos arbitrarios a través de RHN. Esto requiere la instalación de ciertos paquetes rhncfg-*, posiblemente a través de una llave de activación.
--no-ssl No recomendada - valor booleano; incluyendo esta opción se desactivará SSL del sistema cliente.
--no-gpg No recomendada - valor booleano; incluyendo esta opción se desactivará la revisión de llaves GPG en el sistema cliente.
--no-up2date No recomendada - valor booleano; incluyendo esta opción se asegurará que up2date no sea ejecutado una vez el script bootstrap haya sido ejecutado en el sistema.
--pub-tree=ÁRBOL_PÚB Cambio no recomendado - el árbol de directorio público donde el certificado CA SSL y los paquetes serán ubicados; el directorio del bootstrap y scripts. Por defecto es /var/www/html/pub/.
--force No recomendado - valor booleano; incluyendo esta opción se forzará la generación del script bootstrap sin tener en cuenta las advertencias.
-v, --verbose Muestra mensajes verbosos. Esta opción es acumulativa, -vvv producirá una verbosidad extrema.
Observe que este capítulo proporciona un método alternativo al uso de RHN Bootstrap para generar el script bootstrap. Las instrucciones a continuación le ayudarán a crear un script bootstrap a partir de cero.
Todas las técnicas iniciales comparten un tema común: la implementación de archivos necesarios en un lugar centralizado que serán recibidos e instalados usando comandos simples que pueden ser incluidos en un script que se ejecuta en cada sistema cliente. En este capítulo, exploraremos la forma de organizar todas las piezas para crear un script único que puede ser invocado por cualquier sistema en su organización.
Al combinar todos los comandos aprendidos en el capítulo anterior y al ponerlos en un orden razonable, podremos producir el siguiente script:
# First, install the latest client RPMs to the system.
rpm -Uvh \
	http://proxy-or-sat.example.com.com/pub/rhn_register-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/rhn_register-gnome-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-3.0.7-1.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-gnome-3.0.7-1.i386.rpm

# Second, reconfigure the clients to talk to the correct server.

perl -p -i -e 's/s/www\.rhns\.redhat\.com/proxy-or-sat\.example\.com/g' \
	/etc/sysconfig/rhn/rhn_register \
	/etc/sysconfig/rhn/up2date


# Third, install the SSL client certificate for your company's 
# RHN Satellite Server or RHN Proxy Server.
rpm -Uvh http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-*.noarch.rpm

# Fourth, reconfigure the clients to use the new SSL certificate.
perl -p -i -e 's/^sslCA/#sslCA/g;' \
	/etc/sysconfig/rhn/up2date /etc/sysconfig/rhn/rhn_register
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/up2date
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/rhn_register


# Fifth, download the GPG key needed to validate custom packages.
wget -O - -q http://proxy-or-sat.example.com.com/pub/YOUR-RPM-GPG-KEY


# Sixth, import that GPG key to your GPG keyring.
rpm --import /path/to/YOUR-RPM-GPG-KEY
Copy to Clipboard Toggle word wrap

Nota

Recuerde, el sexto paso se documenta aquí, ya que pertenece a sistemas que ejecutan Red Hat Enterprise Linux 3 o posteriores.
Este script abarca un proceso transparente y repetible que puede ser configurado totalmente en cualquier cliente potencial de RHN potencial, en preparación para ser registrado a un Servidor proxy o un servidor satélite de RHN. Recuerde, los valores claves, tales como la URL de su servidor RHN, su directorio público y su llave GPG actual, deben ser insertados en los lugares listados en el script. Asimismo, dependiendo de su entorno, se podrían requerir modificaciones adicionales. Aunque este script puede funcionar en la mayoría de los casos, debe ser usado como una guía.
Al igual que sus componentes, este script puede tener una ubicación central. Si se ubica el script en el directorio del servidor /pub/, ejecutando wget -O- en él y creando una tubería de salida a una sesión de shell; se puede ejecutar un proceso bootstrap en su totalidad con un único comando desde cada cliente:
wget -O - http://proxy-or-sat.example.com.com/pub/bootstrap_script | bash
Copy to Clipboard Toggle word wrap

Aviso

La ejecución de un script de shell directamente desde una tubería a través de una conexión Web, conlleva por obvias razones a riesgos de seguridad. Por lo cual, es importante garantizar la seguridad del servidor fuente en este caso.
Este comando de una sola línea puede luego ser invocado a través de todos los sistemas en una red. Si el administrador tiene acceso SSH a todos los sistemas en cuestión, sería posible ejecutar el comando de forma remota cada uno de ellos. Este script también sería de gran utilidad en la sección %post de un script kickstart existente.

Capítulo 7. Implementación de Kickstart

El mejor momento para hacer cambios de configuración a un sistema es cuando ese sistema se construye por primera vez. Para los usuarios que ya utilizan kickstart de forma eficiente, el script bootstrap es una adición ideal a ese proceso.
Una vez que todos los problemas de configuración hayan sido resueltos, puede registrar el sistema con Servidores de Red Hat Network locales mediante la herramienta rhnreg_ks que viene con los RPM up2date y rhn_register. Este capítulo discute el uso apropiado de rhnreg_ks para registrar sistemas.
La herramienta rhnreg_ks utiliza las llaves de activación para registrar, dar derechos y suscribir los sistemas a canales específicos. Para obtener mayor información sobre las llaves de activación, consulte el Agente de actualización de Red Hat y los capítulos sobre el sitio web de RHN de la Guía de referencia de Administración de Red Hat Network.
El siguiente archivo kickstart comentado es un excelente ejemplo de cómo se puede configurar un sistema de principio a fin mediante Red Hat Network.
# Generic 7.2 kickstart for laptops in the Widget Corporation (widgetco)

# Standard kickstart options for a network-based install. For an
# explanation of these options, consult the Red Hat Linux Customization 
# Guide.

lang en_US
langsupport --default en_US en_US
keyboard defkeymap
network --bootproto dhcp
install
url --url ftp://ftp.widgetco.com/pub/redhat/linux/7.2/en/os/i386
zerombr yes
clearpart --all
part /boot	 --size 128 --fstype ext3 --ondisk hda
part /			 --size 2048 --grow --fstype ext3 --ondisk hda
part /backup --size 1024 --fstype ext3 --ondisk hda
part swap		--size 512 --ondisk hda
bootloader --location mbr
timezone America/New_York
rootpw --iscrypted $1$78Jnap82Hnd0PsjnC8j3sd2Lna/Hx4.
auth --useshadow --enablemd5 --krb5realm .COM --krb5kdc auth.widgetco.com \
	--krb5adminserver auth.widgetco.com
mouse --emulthree genericps/2
xconfig --card "S3 Savage/MX" --videoram 8192	--resolution 1024x768 \
	--depth 16 --defaultdesktop=GNOME --startxonboot --noprobe \
	 --hsync 31.5-48.5 --vsync 40-70

reboot

# Define a standard set of packages.	Note: Red Hat Network client 
# packages are found in Base.	This is quite a minimal set of packages;
# your mileage may vary.

%packages
@ Base
@ Utilities
@ GNOME
@ Laptop Support
@ Dialup Support
@ Software Development
@ Graphics and Image Manipulation
@ Games and Entertainment
@ Sound and Multimedia Support


# Now for the interesting part.

%post
( # Note that we run the entire %post section as a subshell for logging.

# Remember that nifty one-line command for the bootstrap script that we
# went through? This is an ideal place for it. And assuming that the
# script has been properly configured, it should prepare the system
# fully for usage of local Red Hat Network Servers.

wget -O- http://proxy-or-sat.example.com/pub/bootstrap_script | /bin/bash

# The following is an example of the usage of rhnreg_ks, the kickstart
# utility for rhn_register. This demonstrates the usage of the 
# --activationkey flag, which describes an activation key. For example,
# this activation key could be set up in the Web interface to join this 
# system to the "Laptops" group and the local Widgetco "Laptop Software" 
# channel. Note that this section applies only to Proxy users, as this 
# step is handled by the Satellite bootstrap script. 
#
# For more information about activation keys, consult the Red Hat Network
# Management Reference Guide.

/usr/sbin/rhnreg_ks --activationkey=6c933ea74b9b002f3ac7eb99619d3374

# End the subshell and capture any output to a post-install log file.
) 1>/root/post_install.log 2>&1
Copy to Clipboard Toggle word wrap

Apéndice A. Script de ejemplo Bootstrap

El script /var/www/html/pub/bootstrap/bootstrap.sh generado por el programa de instalación del Servidor satélite de RHN proporciona la capacidad de reconfigurar los sistemas clientes para acceder fácilmente a su servidor de RHN. Está disponible para los clientes del servidor satélite y del servidor proxy de RHN a través de la herramienta RHN Bootstrap. Después de modificar el script para su uso particular, este puede ser ejecutado en cada máquina cliente.
Revise el ejemplo y los comentarios que comienzan por el signo de número (#) para obtener información adicional. Siga los pasos en el Capítulo 5, Uso de RHN Bootstrap para preparar el script para su uso.
#!/bin/bash
echo "RHN Server Client bootstrap script v3.6"

# This file was autogenerated. Minor manual editing of this script (and
# possibly the client-config-overrides.txt file) may be necessary to complete
# the bootstrap setup. Once customized, the bootstrap script can be triggered
# in one of two ways (the first is preferred):
#
#	 (1) centrally, from the RHN Server via ssh (i.e., from the
#			 RHN Server):
#				cd /var/www/html/pub/bootstrap/
#				cat bootstrap-<edited_name>.sh | ssh root@<client-hostname> /bin/bash
#
#	 ...or...
#
#	 (2) in a decentralized manner, executed on each client, via wget or curl:
#				wget -qO-
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash
#				 ...or...
#				curl -Sks
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash

# SECURITY NOTE:
#	 Use of these scripts via the two methods discussed is the most expedient
#	 way to register machines to your RHN Server. Since "wget" is used
#	 throughout the script to download various files, a "Man-in-the-middle"
#	 attack is theoretically possible.
#
#	 The actual registration process is performed securely via SSL, so the risk
#	 is minimized in a sense. This message merely serves as a warning.
#	 Administrators need to appropriately weigh their concern against the
#	 relative security of their internal network.

# PROVISIONING/KICKSTART NOTE:
#	 If provisioning a client, ensure the proper CA SSL public certificate is
#	 configured properly in the post section of your kickstart profiles (the
#	 RHN Satellite or hosted web user interface).

# UP2DATE/RHN_REGISTER VERSIONING NOTE:
#	 This script will not work with very old versions of up2date and
#	 rhn_register.


echo
echo
echo "MINOR MANUAL EDITING OF THIS FILE MAY BE REQUIRED!"
echo
echo "If this bootstrap script was created during the initial installation"
echo "of an RHN Satellite, the ACTIVATION_KEYS, and ORG_GPG_KEY values will"
echo "probably *not* be set (see below). If this is the case, please do the"
echo "following:"
echo "	- copy this file to a name specific to its use."
echo "		(e.g., to bootstrap-SOME_NAME.sh - like bootstrap-web-servers.sh.)"
echo "	- on the website create an activation key or keys for the system(s) to"
echo "		be registered."
echo "	- edit the values of the VARIABLES below (in this script) as"
echo "		appropriate:"
echo "		- ACTIVATION_KEYS needs to reflect the activation key(s) value(s)"
echo "			from the website. XKEY or XKEY,YKEY"
echo "		- ORG_GPG_KEY needs to be set to the name of the corporate public"
echo "			GPG key filename (residing in /var/www/html/pub) if appropriate."
echo
echo "Verify that the script variable settings are correct:"
echo "		- CLIENT_OVERRIDES should be only set differently if a customized"
echo "			client-config-overrides-VER.txt file was created with a different"
echo "			name."
echo "		- ensure the value of HOSTNAME is correct."
echo "		- ensure the value of ORG_CA_CERT is correct."
echo
echo "Enable this script: comment (with #'s) this block (or, at least just"
echo "the exit below)"
echo
exit 1

# can be edited, but probably correct (unless created during initial install):
# NOTE: ACTIVATION_KEYS *must* be used to bootstrap a client machine.
ACTIVATION_KEYS=insert_activation_key_here
ORG_GPG_KEY=insert_org_gpg_pub_key_here

# can be edited, but probably correct:
CLIENT_OVERRIDES=client-config-overrides.txt
HOSTNAME=your_rhn_server_host.example.com

ORG_CA_CERT=RHN-ORG-TRUSTED-SSL-CERT
ORG_CA_CERT_IS_RPM_YN=0

USING_SSL=1
USING_GPG=1

REGISTER_THIS_BOX=1

ALLOW_CONFIG_ACTIONS=0
ALLOW_REMOTE_COMMANDS=0

FULLY_UPDATE_THIS_BOX=1

#
# -----------------------------------------------------------------------------
# DO NOT EDIT BEYOND THIS POINT -----------------------------------------------
# -----------------------------------------------------------------------------
#

# an idea from Erich Morisse (of Red Hat).
# use either wget *or* curl
# Also check to see if the version on the 
# machine supports the insecure mode and format
# command accordingly.
if [ -x /usr/bin/wget ] ; then
		output=`/usr/bin/wget --no-check-certificate 2>&1`
		error=`echo $output | grep "unrecognized option"`
		if [ -z "$error" ] ; then
				FETCH="/usr/bin/wget -q -r -nd --no-check-certificate"
		else
				FETCH="/usr/bin/wget -q -r -nd"
		fi
		
else
		if [ -x /usr/bin/curl ] ; then
				output=`/usr/bin/curl -k 2>&1`
				error=`echo $output | grep "is unknown"`
				if [ -z "$error" ] ; then
						FETCH="/usr/bin/curl -SksO"
				else
						FETCH="/usr/bin/curl -SsO"
				fi
		fi
fi

HTTP_PUB_DIRECTORY=http://${HOSTNAME}/pub
HTTPS_PUB_DIRECTORY=https://${HOSTNAME}/pub
if [ $USING_SSL -eq 0 ] ; then
		HTTPS_PUB_DIRECTORY=${HTTP_PUB_DIRECTORY}
fi
echo
echo "UPDATING RHN_REGISTER/UP2DATE CONFIGURATION FILES"
echo "-------------------------------------------------"
echo "* downloading necessary files"
echo "	client_config_update.py..."
rm -f client_config_update.py
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/client_config_update.py
echo "	${CLIENT_OVERRIDES}..."
rm -f ${CLIENT_OVERRIDES}
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/${CLIENT_OVERRIDES}

if [ ! -f "client_config_update.py" ] ; then
		echo "ERROR: client_config_update.py was not downloaded"
		exit 1
fi
if [ ! -f "${CLIENT_OVERRIDES}" ] ; then
		echo "ERROR: ${CLIENT_OVERRIDES} was not downloaded"
		exit 1
fi

echo "* running the update scripts"
if [ -f "/etc/sysconfig/rhn/rhn_register" ] ; then
		echo "	. rhn_register config file"
		/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/rhn_register \
		 ${CLIENT_OVERRIDES}
fi
echo "	. up2date config file"
/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/up2date \
 ${CLIENT_OVERRIDES}

if [ ! -z "$ORG_GPG_KEY" ] ; then 
		echo
		echo "* importing organizational GPG key"
		rm -f ${ORG_GPG_KEY}
		$FETCH ${HTTPS_PUB_DIRECTORY}/${ORG_GPG_KEY}
		# get the major version of up2date
		res=$(rpm -q --queryformat '%{version}' up2date | sed -e 's/\..*//g')
		if [ $res -eq 2 ] ; then
				gpg $(up2date --gpg-flags) --import $ORG_GPG_KEY
		else
				rpm --import $ORG_GPG_KEY
		fi
fi

echo
echo "* attempting to install corporate public CA cert"
if [ $USING_SSL -eq 1 ] ; then
		if [ $ORG_CA_CERT_IS_RPM_YN -eq 1 ] ; then
				rpm -Uvh ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
		else
				rm -f ${ORG_CA_CERT}
				$FETCH ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
				mv ${ORG_CA_CERT} /usr/share/rhn/
		fi
fi

echo
echo "REGISTRATION"
echo "------------"
# Should have created an activation key or keys on the RHN Server's
# website and edited the value of ACTIVATION_KEYS above.
#
# If you require use of several different activation keys, copy this file and
# change the string as needed.
#
if [ -z "$ACTIVATION_KEYS" ] ; then
		echo "*** ERROR: in order to bootstrap RHN clients, an activation key or keys"
		echo "			must be created in the RHN web user interface, and the"
		echo "			corresponding key or keys string (XKEY,YKEY,...) must be mapped to"
		echo "			the ACTIVATION_KEYS variable of this script."
		exit 1
fi

if [ $REGISTER_THIS_BOX -eq 1 ] ; then
		echo "* registering"
		/usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS"
		echo
		echo "*** this system should now be registered, please verify ***"
		echo
else
		echo "* explicitely not registering"
fi

echo
echo "OTHER ACTIONS"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "up2date up2date; up2date -p; up2date -uf (conditional)"
else
		echo "up2date up2date; up2date -p"
fi
echo "but any post configuration action can be added here.	"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "* completely updating the box"
else
		echo "* ensuring up2date itself is updated"
fi
/usr/sbin/up2date up2date
/usr/sbin/up2date -p
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		/usr/sbin/up2date -uf
fi
echo "-bootstrap complete-"

Copy to Clipboard Toggle word wrap

Apéndice B. Revision History

Historial de revisiones
Revisión 3-5.2.402Fri Oct 25 2013Rüdiger Landmann
Rebuild with Publican 4.0.0
Revisión 3-5.2Wed Feb 27 2013Gladys Guerrero-Lozano
Revision completa
Revisión 3-5.1Fri Jan 4 2013Terry Chuang
Archivos de traducción sincronizados con fuentes XML 3-5
Revisión 3-5Wed Sept 19 2012Dan Macpherson
Paginación final para 5.5
Revisión 3-4Fri Aug 10 2012Athene Chan
En etapa de revisión
Revisión 3-0Tue Jun 28 2012Athene Chan
Preparado para la publicación de Satélite de RHN 5.5
Modificaciones de revisión técnica
BZ#837703 Se añadió nota para llave GPG
Revisión 2-2Mon Aug 15 2011Lana Brindley
Lanzamiento de z-stream incorporado dentro de y-stream
Revisión 2-1Wed Jun 15 2011Lana Brindley
Preparado para publicación
Revisión 2-0Fri May 7 2011Lana Brindley
Preparado para traducción
Revisión 1-8Mon Feb 7 2011Lana Brindley
Certificados - BZ#662876
Revisión 1-7Tue Feb 1 2011Lana Brindley
Últimos clientes - BZ#636703

Índice

Símbolos

--configure
uso de, Opción up2date --configure

A

Agente de actualización de Red Hat
Configuración para los servidores proxy y satélite de RHN, Actualización manual de los archivos de configuración
Aplicaciones de cliente
configuración de, Configuración de las aplicaciones cliente
instalación de, Implementación de los últimos RPM clientes de Red Hat Network

B

bootstrap.sh
archivo de muestra, Script de ejemplo Bootstrap
preparación y uso, Uso de RHN Bootstrap

H

Herramienta de mantenimiento SSL de RHN
Cómo generar CA, Generación del par de llaves CA SSL.
Cómo generar el certificado del servidor, Generación del juego de llaves SSL del servidor web
explicación de generación, Generación de certificados SSL
opciones, Opciones de Herramienta de mantenimiento SSL de RHN
rhn-ssl-tool , La Herramienta de configuración de servicios

K

kickstart
uso de, Implementación de Kickstart

L

Llaves de activación
registro con, Registro con las llaves de activación
Llaves GPG
importación de, Importación de las llaves GPG personalizadas

R

RHN Bootstrap
Cómo generar el script, Generación de scripts RHN Bootstrap
opciones de línea de comandos, Configuración de opciones de RHN Bootstrap
preparación, Preparación para instalar RHN Bootstrap
uso, Uso de RHN Bootstrap
uso del script, Uso del script RHN Bootstrap
rhn-ssl-tool
explicación de generación, Generación de certificados SSL
generación de certificado de servidor, Generación del juego de llaves SSL del servidor web
generar certificado, Generación del par de llaves CA SSL.
Herramienta de mantenimiento SSL de RHN , La Herramienta de configuración de servicios
opciones, Opciones de Herramienta de mantenimiento SSL de RHN

S

SSL (Secure Sockets Layer)
introducción, Una breve introducción al SSL

Aviso Legal

Copyright © 2010 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.
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red Hat
Volver arriba