Red Hat Network Satellite 5 Hat Network Satellite 5.4 Gu a de configuraci n de cliente Red Hat Network Satellite Edición 2 Red Hat Documentation Team

Red Hat Network Satellite 5.4

Gu�a de configuraci�n de cliente

Red Hat Network Satellite

Edición 2

Last Updated: 2017-10-06

Red Hat Network Satellite 5.4 Gu�a de configuraci�n de cliente

Red Hat Network SatelliteEdición 2

Red Hat Documentation Team

Legal Notice

Copyright © 2010 Red Hat, Inc.

This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0Unported License. If you distribute this document, or a modified version of it, you must provideattribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all RedHat 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 Infinitylogo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and othercountries.

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 UnitedStates and/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally relatedto 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 marksor trademarks/service marks of the OpenStack Foundation, in the United States and othercountries 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.

Resumen

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

http://creativecommons.org/licenses/by-sa/3.0/

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table of Contents

CAPÍTULO 1. INTRODUCCIÓN

CAPÍTULO 2. APLICACIONES DE CLIENTE2.1. IMPLEMENTACIÓN DE LOS ÚLTIMOS RPM CLIENTES DE RED HAT NETWORK2.2. CONFIGURACIÓN DE LAS APLICACIONES CLIENTE

2.2.1. Registrar clientes al servidor satélite de RHN2.2.2. Registro con las llaves de activación2.2.3. Opción up2date --configure2.2.4. Actualización manual de los archivos de configuración2.2.5. Implementación del servidor alternativo

2.3. PROGRAMA ACTUALIZADOR DE PAQUETES2.4. CONFIGURACIÓN DE LA RED HAT NETWORK ALERT NOTIFICATION TOOL CON SATÉLITE.

CAPÍTULO 3. INFRAESTRUCTURA DEL SSL3.1. UNA BREVE INTRODUCCIÓN AL SSL3.2. USO DE RHN SSL MAINTENANCE TOOL

3.2.1. Explicación de la generación de SSL3.2.2. Opciones de RHN SSL Maintenance Tool3.2.3. Generación del par de llaves CA SSL.3.2.4. Generación del juego de llaves SSL del servidor web

3.3. IMPLEMENTACIÓN DEL CERTIFICADO PÚBLICO CA SSL A LOS CLIENTES3.4. CONFIGURACIÓN DE LOS SISTEMAS CLIENTE

CAPÍTULO 4. IMPORTACIÓN DE LAS LLAVES GPG PERSONALIZADAS

CAPÍTULO 5. USO DE RHN BOOTSTRAP5.1. PREPARACIÓN5.2. GENERACIÓN5.3. USO DEL SCRIPT5.4. OPCIONES DE RHN BOOTSTRAP

CAPÍTULO 6. CREACIÓN MANUAL DEL SCRIPT DE CONFIGURACIÓN

CAPÍTULO 7. IMPLEMENTACIÓN DE KICKSTART

APÉNDICE A. SCRIPT DE EJEMPLO BOOTSTRAP

APÉNDICE B. HISTORIAL DE REVISIONES

ÍNDICE

3

445567899

10

11111213141819

2020

22

2323242525

28

30

32

37

38

Table of Contents

1

Guía de configuración de cliente

2

CAPÍTULO 1. INTRODUCCIÓNEste manual tiene la intención de asistir de una forma sencilla a los usuarios del RHN Satellite Server ydel RHN Proxy Server en la configuración de sus sistemas clientes.

Por defecto, todas las aplicaciones cliente de Red Hat Network están configuradas para comunicarsecon los servidores centrales de Red Hat Network. Algunos de los parámetros de los sistemas clientedeben ser alterados cuando se conectan con el servidor satélite de RHN o el servidor proxy de RHN. Essencillo modificar uno o dos sistemas; pero un entorno empresarial grande puede contener cientos omiles de sistemas que podrían beneficiarse de los pasos de reconfiguración en masa descritos en estemanual.

Debido a la complejidad de esta tarea, los usuarios pueden utilizar un script existente que automaticemuchas de las tareas necesarias para acceder a sus servidores Satellite o Proxy. Consulte el Capítulo 5,Uso de RHN Bootstrap para obtener mayor información. Red Hat cree que entender las implicacionesde estos cambios es útil y por lo tanto, describe los pasos de reconfiguración manual en los primeroscapítulos. Tenga en cuenta las necesidades de su organización para determinar la solución ideal.

Aunque muchos de los comandos proporcionados dentro de esta guía pueden ser aplicados tal y comoaparecen, es imposible predecir todas las posibilidades de configuraciones de red adoptados por losusuarios. Por lo tanto, Red Hat recomienda usar estos comandos como referencias que deben sertenidas en cuenta en la configuración individual de su empresa.

NOTA

La información de la configuración de los clientes Unix puede encontrarse en la Guía dereferencia del RHN Satellite Server en el capítulo Soporte para Unix.

CAPÍTULO 1. INTRODUCCIÓN

3

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

IMPORTANTE

Red Hat recomienda que los clientes conectados al Servidor proxy o al servidor satélitede RHN estén ejecutando la actualización más reciente de Red Hat Enterprise Linuxpara asegurar una apropiada conectividad.

Adicionalmente, si el cortafuegos del cliente está configurado, los puertos 80 y 443deben estar abiertos para permitir una apropiada funcionalidad con Red Hat Network.

2.1. IMPLEMENTACIÓN DE LOS ÚLTIMOS RPM CLIENTES DE RED HATNETWORK

El Actualizador de paquete (pup), yum, y Red Hat Network Registration Client (rhn_register) enRed Hat Enterprise Linux 5 (up2date en versiones anteriores a Red Hat Enterprise Linux) sonprerrequisitos para utilizar muchas de las funciones empresariales de Red Hat Network. Es importanteinstalarlos en sistemas de cliente antes de intentar utilizar el servidor proxy o satélite de RHN en suentorno.

Hay varios métodos para abordar la actualización del software cliente RHN. Uno de ellos tiene que vercon el almacenamiento de los RPM en un lugar accesible a todos los sistemas cliente y laimplementación de paquetes con el comando más sencillo. En casi todos los casos, la implementaciónmanual de yum, pup, y rhn_register (up2date si existe una versión anterior a Red Hat EnterpriseLinux) no es necesaria. Dichas herramientas de cliente no deben tener ningún problema paraconectarse al satélite de RHN o su entorno Proxy. La discusión a continuación asume que yum "out ofbox", pup, y rhn_register (o up2date) no son las últimas y no funcionan para su entorno.

Recuerde, únicamente los sistemas que están ejecutando Red Hat Enterprise Linux 5 deben estarregistrados con RHN en firstboot después de la instalación o utilizar rhn_register. Los sistemas enejecutando Red Hat Enterprise Linux 3 y 4 pueden utilizar la función de registro dentro de Red HatUpdate Agent.

Este documento presupone que el usuario ha instalado al menos un RHN Satellite Server y/o un RHNProxy Server en su red. El siguiente ejemplo demuestra una manera sencilla de implementar porprimera vez yum, pup, y rhn_register (o up2date) por un administrador asumiendo que lasmáquinas no tienen aún el RHN funcionando. El administrador ha poblado el directorio /var/www/html/pub/ con una copia de los RPM yum, pup, y rhn_register (o up2date) que lossistemas de cliente necesitan y luego simplemente ha implementado los RPM en los sistemas decliente con un comando simple rpm -Uvh. Ejecutado desde un cliente, este comando instala los RPMpara ese cliente, asumiendo que el nombre de dominio, rutas, y versiones de RPM son correctas(observe que este comando se ha dividido en varias líneas para propósitos de impresión y PDF, pero sedebe escribir como una línea en el shell de intérprete de comandos):

rpm -Uvhhttp://your_proxy_or_sat.your_domain.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm


4

http://your_proxy_or_sat.your_domain.com/pub/yum-3.2.8-9.el5.i386.rpmhttp://your_proxy_or_sat.your_domain.com/pub/pirut-1.3.28-13.3l5.noarch.rpm

Observe que la arquitectura (en este caso, i386) puede necesitar algunas alteraciones dependiendodel los sistemas que va a servir.

2.2. CONFIGURACIÓN DE LAS APLICACIONES CLIENTE

No todos los usuarios deben estar conectados de forma segura a su Servidor satélite o proxy de RHNdentro de su organización. No todos los clientes necesitan construir e implementar una llave GPG paralos paquetes personalizados. (Estos dos temas se explicarán con más detalle posteriormente). Cadausuario que utilice el servidor satélite de RHN o el RHN Proxy Server debe reconfigurar el Red HatUpdate Agent (up2date) y posiblemente el Red Hat Network Registration Client (rhn_register)para redirigirlo desde Red Hat Network a su Servidor satélite o proxy.

IMPORTANTE

Aunque no sea configurable, observe que el puerto usado por up2date es 80 para HTTPy 443 para HTTP (HTTPS) segura. Por defecto, yum en Red Hat Enterprise Linux 5 usaSSL únicamente. Por esta razón, los usuarios deben asegurarse de que sus cortafuegospermitan conexiones al puerto 443. Para desviar u omitir SSL, cambie el protocolo para serverURL desde https a http en /etc/sysconfig/rhn/up2date. Igualmente,para utilizar la función Monitoring de RHN y sondeos que requieren Red Hat NetworkMonitoring Daemon, observe que los sistemas de cliente deben permitir conexiones enpuerto 4545 (o puerto 22, si se utiliza sshd en su lugar).

Por defecto, el rhn_register y up2date se refieren a los servidores Red Hat Network principales.Los usuarios deben reconfigurar los sistemas de cliente para referirser a sus servidores satélite oproxy.

Observe que las últimas versiones del Red Hat Update Agent pueden ser configuradas para acomodarvarios servidores RHN, para así proporcionar protección contra fallos en caso de que el servidorprimario no se pueda acceder. Consulte la Sección 2.2.5, “Implementación del servidor alternativo”para obtener instrucciones sobre cómo activar esta función.

Las secciones siguientes describen los diferentes métodos para configurar los sistemas de cliente paraacceder al servidor satélite o proxy de RHN.Para ver cómo poner virtualmente en script, consulte elCapítulo 6, Creación manual del script de configuración.

2.2.1. Registrar clientes al servidor satélite de RHN

Para registrar un sistema al Servidor satélite de RHN se necesita su nombre de dominio totalmentecalificado (FQDN) y el certificado SSL del Servidor satélite de RHN.

1. Descargar el certificado SSL para el cliente:

cd /usr/share/rhn/wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT

2. Edite el archivo /etc/sysconfig/rhn/up2date:

CAPÍTULO 2. APLICACIONES DE CLIENTE

5

serverURL=https://satellite.example.com/XMLRPCnoSSLServerURL=http://satellite.example.com/XMLRPCsslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT

3. Registrar la máquina:

rhn_register

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 quese conectan con un Servidor de proxy o satélite de RHN. Las llaves de activación sirven para registrar,autorizar, y suscribir sistemas por lotes. Para mayor información, consulte la sección sobre "llaves deactivación" en la Guía de referencia del Servidor satélite de RHN.

El proceso de registro con llaves de activación tiene cuatro pasos básicos:

1. Generar una llave de activación.

2. Importar llaves GPG personales

3. Descargar e instalar el RPM del certificado SSL del directorio /pub/ del servidor satélite oservidor proxy de RHN. El comando para este paso es similar a:

rpm -Uvh http://your-satellite-FQDN/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm

4. Registrar el sistema con el servidor satélite o proxy de RHN. El comando para este paso essimilar a:

rhnreg_ks --activationkey mykey --serverUrl https://your-satellite-FQDN/XMLRPC

Alternativamente, la mayoría de los pasos anteriores pueden combinarse en un script de shell queincluya las siguientes líneas (observe que este comando ha sido dividido en varias líneas parapropósitos de impresión y PDF, pero debe escribirse en una sola línea en el shell de intérprete decomandos).

wget -0 - http://your-satellite-FQDN/pub/bootstrap.sh | bash&& rhnreg_ks --activation-key my_key --serverUrlhttps://your-satellite-FQDN/XMLRPC

El script bootstrap, generado al momento de la instalación y disponible tanto para RHN Satellite Servercomo para RHN Proxy Server es el script mencionado. La discusión sobre el script y RHN Bootstrapque lo genera se aborda en detalle en el Capítulo 5, Uso de RHN Bootstrap.


6

AVISO

Los sistemas que están ejecutando Red Hat Enterprise Linux 2.1 y versiones deRed Hat Linux anteriores a la 8.0 pueden experimentar problemas al usar las llavesde activación para migrar la configuración del certificado SSL de rhn_register aup2date. Por lo cual, la información del certificado SSL en esos sistemas debe serestablecida manualmente. Todas las otras transferencias de parámetros, como laURL del servidor, funcionan correctamente.

2.2.3. Opción up2date --configure

Red Hat Update Agent en Red Hat Enterprise Linux 3 y 4 proporciona una interfaz para establecervarias configuraciones. Para ver una lista completa de estas configuraciones, consulte la página demanual up2date (man up2date en la línea de comandos).

Para reconfigurar el Red Hat Update Agent , ejecute el siguiente comando como root:

up2date --configure

Se le presentará una caja de diálogo con varios parámetros que pueden ser reconfigurados. En lapestaña General, bajo Seleccionar servidor de Red Hat Network a utilizar remplace elvalor por defecto con su nombre de dominio completamente calificado (FQDN) del Servidor satélite deRHN o el Servidor proxy de RHN, tal como https://your_proxy_or_sat.your_domain.com/XMLRPC. Mantenga el /XMLRPC al final. Alfinalizar, haga clic en OK.


7

Figura 2.1. Configuración de la interfaz gráfica de usuario Red Hat Update Agent

Asegúrese de haber ingresado el nombre de dominio correcto de su RHN Satellite Server o RHN ProxyServer. El ingreso incorrecto de un nombre de dominio o si se deja un espacio en blanco, evitará ellanzamiento de up2date --configure. Sin embargo, esto se puede solucionar si modifica el valor enel archivo de configuración up2date. Consulte la Sección 2.2.4, “Actualización manual de los archivosde configuración” para obtener instrucciones precisas.

AVISO

Sistemas ejecutando Red Hat Enterprise Linux 3 o 4 tienen incorporada la funciónde registro Red Hat Update Agent y por lo tanto no se necesita instalar Red HatNetwork Registration Client. Los sistemas ejecutando Red Hat Enterprise Linux 5no usan up2date, y necesitan rhn_register para registrar sus sistemas a RHN oSaté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 GUI descrita en la sección anterior, los usuarios pueden tambiénreconfigurar Red Hat Update Agent al editar los archivos de configuración de la aplicación.

Para configurar el Red Hat Update Agent en los sistemas cliente que se conectan al servidor satélite oproxy de RHN, edite los valores de los parámetros serverURL y noSSLServerURL en el archivo deconfiguración /etc/sysconfig/rhn/up2date. Remplace el valor predeterminado de la URL de Red


8

Hat Network con el nombre de dominio completamente calificado (FQDN) del Servidor proxy de RHN oel servidor satélite de RHN. Por ejemplo:

serverURL[comment]=Remote server URLserverURL=https://your_primary.your_domain.com/XMLRPC

noSSLServerURL[comment]=Remote server URL without SSLnoSSLServerURL=http://your_primary.your_domain.com/XMLRPC

AVISO

El parámetro httpProxy en /etc/sysconfig/rhn/up2date no hacereferencia al RHN Proxy Server. Sirve para configurar un proxy HTTP opcionalpara el cliente. Con un RHN Proxy Server en lugar, el parámetro httpProxy debeestar en blanco (no debe tener ningún valor establecido).

2.2.5. Implementación del servidor alternativo

Desde up2date-4.2.38, el Red Hat Update Agent puede ser configurado para buscaractualizaciones desde una serie de servidores RHN. Esto puede ser bastante útil para mantener elabastecimiento de actualizaciones en caso de que su servidor satélite o proxy de RHN primario esténdesconectados.

Para usar esta función, asegúrese de estar usando la versión requerida del up2date. Luego añadacomo root los servidores secundarios a los parámetros serverURL y noSSLServerURL en el archivode configuración /etc/sysconfig/rhn/up2date. Añada los nombres de dominio completamentecalificado (FQDN) del Proxy o el satélite inmediatamente después del servidor primario, separados porpuntos y comas (;). Por ejemplo:

serverURL[comment]=Remote server URLserverURL=https://your_primary.your_domain.com/XMLRPC; https://your_secondary.your_domain.com/XMLRPC;

noSSLServerURL[comment]=Remote server URL without SSLnoSSLServerURL=http://your_primary.your_domain.com/XMLRPC; https://your_secondary.your_domain.com/XMLRPC;

La conexión al servidor se intenta según el orden provisto aquí. Puede incluir tantos servidores comodesee. Puede también incluir los servidores centrales de RHN. Esto solo funciona, si los sistemasclientes tienen acceso directo a la Internet.

2.3. PROGRAMA ACTUALIZADOR DE PAQUETES

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


9

Figura 2.2. Programa actualizador de paquetes

La aplicación del programa actualizador de paquetes permanece en la bandeja de notificaciones delpanel de escritorio y busca periódicamente nuevas actualizaciones. La aplicación también permiterealizar tareas de mantenimiento de paquetes haciendo clic y eligiendo dentro de las siguientesacciones:

Refresh — Busca nuevas actualizaciones de RHN o Satélite

View Updates — lanza la aplicación de actualizador de paquetes para que se puedan verdetalladamente las actualizaciones disponibles y configurar las actualizaciones para susespecificaciones.

Apply Updates — Descarga e instala todos los paquetes actualizados.

Quit — cierra la aplicación

2.4. CONFIGURACIÓN DE LA RED HAT NETWORK ALERTNOTIFICATION TOOL CON SATÉLITE.

La Red Hat Network Alert Notification Tool , el icono circular en el panel de su escritorio Red HatEnterprise Linux 3 o 4, puede configurarse en sistemas que ejecutan Red Hat Enterprise Linux 3 oposteriores para que reconozcan actualizaciones disponibles en los canales personalizados en suServidor satélite de RHN. Debe asegurarse de que el Servidor satélite de RHN esté configurado parasoportar esta función. (El servidor proxy de RHN soporta la aplicación sin modificación de cliente oservidor.) Los pasos para configurar la Red Hat Network Alert Notification Tool son los siguientes:

1. Asegúrese de que la versión de su RHN Satellite Server sea 3.4 o superior y de que el paquete rhns-applet esté instalado en el satélite. El paquete puede encontrarse en el canal desoftware del satélite de RHN para las versiones 3.4 y posteriores.

2. Obtenga el paquete rhn-applet-actions con up2date o a través del canal deherramientas de software Red Hat Network. Instale el paquete en todos los sistemas de clienteRed Hat Enterprise Linux 3 y posteriores para ser notificado de actualizaciones personalizadascon los sistemas de cliente Red Hat Network Alert Notification Tool . Los sistemas de clientedeben estar actualizados para los niveles de servicio Management o Provisioning.

3. Dentro de la versión del satélite del sitio web de RHN, vaya a la página Información del sistema para cada sistema cliente y haga clic en el enlace dentro del área RHN Applet pararedirigir la Red Hat Network Alert Notification Tool al satélite.

La próxima vez que la aplicación sea iniciada, se aplicará la nueva configuración y la conexión paraactualizaciones se realizará al RHN Satellite Server.


10

CAPÍTULO 3. INFRAESTRUCTURA DEL SSLPara los usuarios de Red Hat Network, la seguridad es un tema de suma importancia. Una de lasfortalezas de Red Hat Network es la habilidad de procesar cada una de las solicitudes a través de SSL(Capa de conexión segura/Secure Sockets Layer). Para mantener este nivel de seguridad, los usuariosque instalan Red Hat Network dentro de sus infraestructuras deben generar las llaves y certificadosSSL personalizados.

La creación e implementación manual de las llaves y certificados SSL puede llegar a ser bastanteengorrosa. Tanto el Servidor proxy de RHN como el Servidor satélite de RHN le permitirán construirsus propias llaves y certificados SSL durante la instalación, basándose en sus propios certificados deAutoridad Certificadora (conocidos como CA por sus siglas en inglés). Además, una herramienta parala línea de comando, la RHN SSL Maintenance Tool , ha sido creada para este fin. Estas llaves ycertificados deben ser implementados en todos los sistemas dentro de su infraestructura. En muchoscasos, la implementación de estas llaves y certificados SSL es automatizada. Este capítulo describemétodos eficientes para conducir todas estas tareas.

Por favor tenga en cuenta que este capítulo no explica SSL en detalle. La RHN SSL Maintenance Toolfue diseñada para ocultar la complejidad que envuelve la creación y mantenimiento de estainfraestructura de llaves públicas (PKI). Para mayor información, consulte algunas de las referenciasdisponibles 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 unaforma segura. SSL utiliza un sistema de pares de llaves pública y privada para encriptar lacomunicación pasada entre el cliente y el servidor. Los certificados públicos pueden ser accesibles acualquier persona, pero las llaves privadas deben permanecer en un lugar seguro. Es la relaciónmatemática (una firma digital) entre el certificado público y la llave privada lo que hace que estesistema funcione. A través de esta relación se establece una conexión confiable.

NOTA

A lo largo de este documento se discutirá sobre las llaves privadas y los certificadospúblicos de SSL. Técnicamente, ambos pueden llamarse llaves (pública y privada). Peropor convención, cuando se habla de SSL, se refiere a la parte pública de un par de llavesde SSL (o juego de llaves) como el certificado público SSL.

La infraestructura SSL de una organización está conformada generalmente por estas llaves ycertificados:

Llave privada y certificado público SSL de Autoridad certificadora (CA) — generalmente secrea un solo par por organización. El certificado público es firmado digitalmente por su llaveprivada. El certificado público se distribuye a cada sistema.

Llaves privadas y certificados públicos SSL del servidor web — un set por servidor deaplicaciones. El certificado público es firmado digitalmente tanto por su llave privada como porsu llave privada CA SSL. Generalmente nos referimos al juego de llaves del servidor web; yaque hay una petición a un certificado SSL intermediario que es generado. Los detalles de usono son importante en esta discusión. Todos los tres son implementados en un servidor de RHN.

Por ejemplo: si tiene un satélite y cinco Proxies, generará un par de llaves CA SSL y seis juegos dellaves SSL del servidor web. El certificado público CA SSL es distribuido a todos los sistemas y usadopor todos los clientes para establecer una conexión a sus respectivos servidores. Cada servidor tienesu propio juego de llaves SSL que está específicamente ligado al nombre de host del servidor y

CAPÍTULO 3. INFRAESTRUCTURA DEL SSL

11

generado con la llave privada SSL y la llave privada CA SSL en conjunto. Esto establece una asociacióndigital verificable entre el certificado público SSL del servidor web y el par de llaves CA SSL y la llaveprivada del servidor. El juego de llaves del servidor de web no puede ser compartido con otrosservidores.

IMPORTANTE

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

3.2. USO DE RHN SSL MAINTENANCE TOOL

Red Hat Network proporciona una herramienta de línea de comandos que facilita el manejo de su lainfraestructura de seguridad: la RHN SSL Maintenance Tool comúnmente conocida por su comando rhn-ssl-tool. Esta herramienta está disponible como parte del paquete rhns-certs-tools. Estepaquete puede encontrarse dentro de los canales de software para las últimas versiones del Servidorproxy de RHN y el Servidor satélite de RHN (también para el ISO del servidor satélite de RHN). LaRHN SSL Maintenance Tool le permite generar su propio par de llaves CA SSL, así como el juego dellaves SSL del servidor web (algunas veces llamada par de llaves).

Esta herramienta es solamente una herramienta de construcción. Genera todas las llaves y certificadosSSL que se requieren. También empaqueta los archivos en formato RPM para una rápida distribución einstalación de las máquinas cliente. Sin embargo, no las implementa. Esta tarea es asignada aladministrador, o en muchas ocasiones, automatizada por el Servidor satélite de RHN.

NOTA

El rhns-certs-tools, que contiene rhn-ssl-tool, puede ser instalado y ejecutadoen cualquier sistema Red Hat Enterprise Linux con los mínimos requerimientos. Esto esconveniente para los administradores que deseen manejar su infraestructura SSL desdesu estación de trabajo o cualquier otro sistema diferente al servidor RHN.

Estos son los casos en los que se requiere la herramienta:

Cuando se actualizan los certificados públicos CA - esto es raro.

Cuando se instala un Servidor proxy de RHN versión 3.6 o posterior que se conecta con losservidores centrales de RHN como su servicio de nivel superior - el servicio hospedado, porrazones de seguridad, no puede ser un repositorio de su certificado y llave CA SSL, los cualesson privativos de su organización.

Cuando se reconfigura una infraestructura RHN para usar SSL donde no existía.

Cuando se añaden Sevidores proxy de RHN de una versión anterior a la 3.6 dentro de suinfraestructura RHN.

Cuando se añade más de un RHN Satellite Server a una infraestructura RHN - consulte con surepresentante Red Hat para obtener instrucciones al respecto.


12

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 sonconfigurados durante el proceso de instalación. Las llaves y certificados SSL son construidos eimplementados automáticamente.

Durante la instalación de un Servidor proxy RHN - versión 3.6 o superior conectado a unservidor satélite de RHN 3.6 o superior como su servidor de nivel superior - el servidor satélitede RHN contiene toda la información SSL necesaria para configurar, construir e implementarlos certificados y llaves SSL del Servidor proxy de RHN.

El proceso de instalación del Servidor satélite de RHN y del Servidor proxy de RHN aseguran que elcertificado público SSL se implemente en el directorio /pub de cada servidor. Este certificado públicoes usado por los sistemas cliente para conectarse al servidor RHN. Consulte la Sección 3.3,“Implementación del certificado público CA SSL a los clientes” para obtener mayor información.

En resumen, si la infraestructura RHN de su organización implementa la última versión del Servidorsatélite de RHN como el servicio de nivel superior, usted no tendrá necesidad de usar la herramienta.De lo contrario, deberá familiarizarse con su uso.

3.2.1. Explicación de la generación de SSL

Seguridad, flexibilidad y portabilidad son los beneficios primarios del uso de la RHN SSL MaintenanceTool. La seguridad se consigue mediante la creación de certificados y llaves SSL del servidor web paracada 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 quetenga el paquete rhns-certs-tools instalado. La portabilidad nace en la existencia de unaestructura construida que puede ser almacenada por seguridad en cualquier lugar y luego instaladacuando sea necesario.

Nuevamente, si su infraestructura RHN utiliza la última versión del RHN Satellite Server comoservidor de nivel superior, lo único que usted tendrá que hacer es restaurar su árbol ssl-build desdeun archivo al directorio /root y utilizar las herramientas de configuración provistas dentro del sitioweb del Servidor satélite de RHN.

Para Utilizar la RHN SSL Maintenance Tool de la forma más adecuada, complete las siguientes tareasde nivel superior siguiendo aproximadamente el orden dado. Consulte las secciones restantes paraobtener mayor información:

1. Instale el paquete rhns-certs-tools en un sistema dentro de su organización; por ejemploen un Servidor satélite de RHN o un Servidor proxy de RHN.

2. Cree un par de llaves CA SSL para su organización e instale el RPM resultante o certificadopúblico en todos los sistemas cliente.

3. Cree un juego de llaves SSL de servidor web para cada uno de los Proxies y satélites que seránimplementados e instale los RPM resultantes en los servidores de RHN; reinicie el servicio httpd después de esta acción:

/sbin/service httpd restart

4. Archive el árbol de construcción SSL - conformado por el directorio de construcción primario ytodos los subdirectorios y archivos - en un medio de almacenamiento, por ejemplo un disquete(los requerimientos de espacio de disco son insignificantes).


13

5. Verifique y luego almacene este archivo en un lugar seguro, tal como el descrito en la secciónsobre copias de seguridad en Requerimientos adicionales de la Guía de instalación de Proxy osatélite.

6. Registre y asegure la contraseña CA para un uso futuro.

7. 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.

8. Cuando se necesiten llaves SSL de servidor web adicionales, restaure el árbol de construcciónen el sistema ejecutando la RHN SSL Maintenance Tool y repita los pasos del 3 al 7.

3.2.2. Opciones de RHN SSL Maintenance Tool

La RHN SSL Maintenance Tool ofrece una plétora de opciones de línea de comandos para generar supar de llaves CA SSL y administrar sus llaves y certificados SSL del servidor. La herramienta ofreceesencialmente tres opciones de listados de ayudas para la línea de comandos: rhn-ssl-tool --help (general), rhn-ssl-tool --gen-ca --help (CA - Certificate Authority/ AutoridadCertificadora), y rhn-ssl-tool --gen-server --help (Servidor web). La página de manual parala rhn-ssl-tool también está bien detallada y disponible: man rhn-ssl-tool.

Las dos tablas siguientes dividen las opciones de acuerdo a su tarea respectiva, ya sea CA o lageneración del juego de llaves de servidor web.

Este conjunto de opciones debe estar precedido por el argumento --gen-ca:

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 (Autoridadcertificadora) y RPM público. Este debe serejecutado con cualquiera de las opcionesrestantes de la tabla.

-h, --help Muestra la pantalla de ayuda con una lista deopciones básicas específicas para generar yadministrar un CA (Autoridad certificadora).

-f, --force Fuerza la creación de una llave privada CAy/o de un certificado público.

-p=, --password=CONTRASEÑA La contraseña CA. Se le pedirá queintroduzca esta opción si no se encuentra.Guárdela de una forma segura.

-d=, --dir=DIRECTORIO Requerido para la mayoría de comandos - Eldirectorio donde el certificado y el RPM seránconstruidos. Por defecto es ./ssl-build.


14

--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úblicoCA. Por defecto es RHN-ORG-TRUSTED-SSL-CERT.

--cert-expiration=EXPIR_CERT La fecha de caducidad del certificado públicoCA. Por defecto es el número de días hasta undí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 defectoes 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 RedHat. Por defecto es Example Corp. Inc.

--set-org-unit=CONFIG_UNIDAD_ORG La unidad corporativa, tal como RHN. Pordefecto es ''.

--set-common-name=NOMBREDEHOST Generalmente no se establece para el CA. - Elnombre 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 ([email protected])."

--rpm-vendor=DISTRIBUIDOR El distribuidor del RPM generado, tal como"IS/IT Example Corp."

-v, --verbose Muestra mensajes verbosos. Esta opción esacumulativa - por cada "v" añadida seconseguirá un mayor grado de verbosidad.

--ca-cert-rpm=CERT_RPM Rara vez cambia - el nombre del RPM quecontiene el certificado CA (El nombre dearchivo base únicamente, no el nombre queincluye la versión: filename-version-release.noarch.rpm)



15

--key-only Rara vez usado - Genera una llave privada CAúnicamente. Revise --gen-ca --key-only --help para obtener mayorinformación.

--cert-only Rara vez usado - Genera un certificado públicoCA únicamente. Revise --gen-ca --cert-only --help para obtener mayorinformación.

--rpm-only Rara vez usado - Genera un RPM paraimplementación solamente. Revise --gen-ca --rpm-only --help para obtenermayor información.

--no-rpm Rara vez usado - Realiza todos los pasosrelacionados con el CA excepto la generacióndel RPM.


El siguiente set de opciones debe estar precedido de un argumento --gen-server:

Tabla 3.2. Opciones del SSL de servidor web ( rhn-ssl-tool --gen-server --help)


--gen-server Genera el juego de llaves SSL de servidorweb, el RPM y el archivo tar. Esta opción debeser usada con cualquiera de las opcionesrestantes de esta tabla.

-h, --help Muestra la pantalla de ayuda con una lista deopciones básicas especificas para lageneración y administración de un par dellaves de servidor.

-p=, --password=CONTRASEÑA La contraseña CA. Se le pedirá queintroduzca esta opción si no se encuentra.Guárdela de una forma segura.

-d=, --dir=DIRECTORIO Requerido para la mayoría de comandos - Eldirectorio donde el certificado y el RPM seránconstruidos. Por defecto es ./ssl-build.

--server-key=ARCHIVO El nombre del archivo de la llave privada SSLde servidor web. Por defecto es server.key.


16

--server-cert-req=ARCHIVO El nombre de archivo solicitado delcertificado SSL de servidor web. Por defectoes server.csr.

--server-cert=ARCHIVO El nombre de archivo del certificado SSL delservidor web. Por defecto es server.crt.

--startdate=YYMMDDHHMMSSZ La fecha de inicio para validar el certificadode servidor en el formato ejemplificado: año,mes, día, hora, minuto, segundo (doscaracteres por valor). Z significa Zulú y esrequerido. Por defecto es una semana antesde la generación.

--cert-expiration=EXPIR_CERT_SERVIDOR La fecha de caducidad del certificado deservidor. Por defecto es el número de díashasta 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 defectoes US.

--set-state=ESTADO_O_PROVINCIA El estado o provincia. Por defecto es "NorthCarolina".

--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 RedHat. Por defecto es Example Corp. Inc.

--set-org-unit=CONFIG_UNIDAD_ORG La unidad corporativa, tal como RHN. Pordefecto es "unit."

--set-hostname=NOMBREDEHOST El nombre de host del servidor de RHN querecibirá la llave. Por defecto se establecedinámicamente con el nombre de host de lamáquina de construcción.

--set-email=CORREO-E La dirección de correo-e del contacto delcertificado. Por defecto [email protected].

--rpm-packager=EMPAQUETADOR Empaquetador del RPM generado, tal como"RHN Admin ([email protected])."

--rpm-vendor=DISTRIBUIDOR El distribuidor del RPM generado, tal como"IS/IT Example Corp."



17

-v, --verbose Muestra mensajes verbosos. Esta opción esacumulativa - por cada "v" añadida seconseguirá un mayor grado de verbosidad.

--key-only Rara vez usado - Genera únicamente una llaveprivada de servidor. Revise --gen-server --key-only --help para obtener mayorinformación.

--cert-req-only Rara vez usado - Genera únicamente unapetición de certificado de servidor. Revise --gen-server --cert-req-only --help para mayor información.

--cert-only Rara vez usado - Genera únicamente uncertificado de servidor. Revise --gen-server --cert-only --help paraobtener mayor información.

--rpm-only Rara vez usado - Genera únicamente un RPMpara implementación. Revise --gen-server --rpm-only --help paraobtener mayor información.

--no-rpm Rara vez usado - Ejecuta todos los pasosrelacionados con el servidor excepto lageneración del RPM.

--server-rpm=SERVIDOR_RPM Rara vez cambiado - El nombre del RPM quecontiene el juego de llaves SSL del servidorweb (el nombre de archivo base, no el nombrede archivo y versión: filename-version-release.noarch.rpm).

--server-tar=SERVIDOR_TAR Rara vez se cambia - Nombre del archivo tardel juego de llaves SSL de servidor web ycertificado CA que es utilizado únicamentepor las rutinas de instalación del Servidorproxy de RHN hospedado (el nombre dearchivo de base no el nombre y versión: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 deAutoridad certificadora (CA). Un certificado público CA SSL se distribuye a los sistemas cliente delsatélite o del Proxy. La RHN SSL Maintenance Tool le permitirá generar un par de llaves CA SSLcuando sea necesario y reutilizarlas para todas las implementaciones de servidores de RHNposteriores.


18

El proceso de construcción crea automáticamente el par de llaves y el RPM público para ser distribuidoa los sistemas cliente. Todos los componentes terminan en el directorio de construcción especificadoen la línea de comandos, generalmente /root/ssl-build (o /etc/sysconfig/rhn/ssl parasatélites y Proxies antiguos). Para generar un par de llaves CA SSL, ejecute un comando como elsiguiente:

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"

Remplace los valores de este ejemplo con los de su organización. Esto dará como resultado lossiguientes 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 paraser 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 sistemas cliente. 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

Aunque debe generar un par de llaves CA SSL, es probable que usted genere el juego de llaves delservidor web con mayor frecuencia, especialmente si se está implementando más de un Proxy osatélite. Observe que el valor de --set-hostname es diferente para cada servidor. En otras palabras,un juego único de llaves y certificados SSL debe ser generado e instalado por cada nombre de host deservidor RHN.

El proceso de construcción del certificado de servidor funciona de un modo muy similar al usado paragenerar el par de llaves CA SSL. Hay, sin embargo, una excepción: todos los componentes del servidorterminan en subdirectorios del directorio creado que indican el nombre de la máquina del sistemacreado, 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="[email protected]" \--set-hostname="rhnbox1.example.com

Remplace los valores del ejemplo con aquellos apropiados para su organización. Como resultado seobtendrán los siguientes archivos relevantes en el subdirectorio específico a la máquina en eldirectorio de construcción:

server.key — la llave privada de servidor SSL de servidor web.


19

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 RPMpreparado para ser distribuido a los servidores de RHN. También se genera el archivo src.rpmasociado. 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 finalizado, usted 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

3.3. IMPLEMENTACIÓN DEL CERTIFICADO PÚBLICO CA SSL A LOSCLIENTES

Tanto el proceso de instalación del Servidor proxy como del servidor satélite de RHN facilitanrelativamente la implementación de los sistemas cliente al generar el RPM y el certificado público CASSL. Ambos procesos de instalación dejan a disposición pública una copia del RPM y/o del certificadoen 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-CERTwget http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT

Alternativamente, si el RPM del certificado público CA SSL está en el directorio /pub, puede serinstalado en un sistema cliente directamente:

rpm -Uvh \http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VERS-LANZ.noarch.rpm

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 esesistema debe modificar el archivo de configuración del Red Hat Update Agent y el Red Hat Network


20

Registration Client (de ser necesario) para usar el nuevo archivo de certificado CA SSL y paraconectarse al Servidor proxy o al servidor satélite de RHN apropiado. El lugar generalmente aceptadopara el certificado público CA SSL es el directorio /usr/share/rhn.

Los servidores proxy y de satélite de RHN tienen la aplicación RHN Bootstrap instalada por defecto, locual puede reducir en gran medida estos pasos repetitivos y simplificar el proceso de registro yconfiguración de sistemas cliente. Por favor consulte el Capítulo 5, Uso de RHN Bootstrap para obtenermayor información.


21

CAPÍTULO 4. IMPORTACIÓN DE LAS LLAVES GPGPERSONALIZADASPara los usuarios que desean construir y distribuir sus propios RPM de una forma segura, serecomienda que todos los RPM personalizados estén firmados con GPG (GNU Privacy Guard). Lageneración y construcción de llaves GPG y la construcción de paquetes firmados con GPG se tratan enla 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 sistemasque reciben esos RPM. Esta tarea tiene dos pasos: primero, crear una ubicación central para la llavepública con el fin de que los clientes puedan obtenerla; y segundo, añadir la llave al llavero de GPGlocal para cada sistema.

El primer paso es común y puede ser manejado mediante el método recomendado para implementaraplicaciones cliente de RHN. (Consulte la Sección 2.1, “Implementación de los últimos RPM clientes deRed Hat Network”.) Para llevar a cabo este procedimiento, cree un directorio público en el servidorweb y coloque en él la firma pública GPG:

cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/

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

La opción -O- envía los resultados a la salida estándar mientras que la opción -q activa el modosilencioso en wget. No olvide remplazar la variable SU-LLAVE-GPG-RPM por el nombre de archivo de sullave.

Una vez la llave está disponible en el sistema de archivos del sistema cliente, impórtela al llavero deGPG 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

Para Red Hat Enterprise Linux 2.1, use el siguiente comando:

gpg $(up2date --gpg-flags) --import /path/to/YOUR-RPM-GPG-KEY

Una vez la llave GPG ha sido añadida correctamente al cliente, el sistema debe estar en la capacidad devalidar RPM personalizados firmados con la llave correspondiente.


22

CAPÍTULO 5. USO DE RHN BOOTSTRAPRed Hat Network proporciona una herramienta que automatiza muchos de los pasos de lareconfiguración manual descrita en los capítulos previos: RHN Bootstrap . Esta herramienta juega unrol integral en el Programa de instalación del servidor satélite de RHN , permitiendo la generación delscript bootstrap durante la instalación.

Los usuarios del RHN Proxy Server y aquellos con la configuración actualizada del satélite requierenuna herramienta bootstrap que pueda ser usada independientemente. RHN Bootstrap , la cual seinvoca con el comando /usr/bin/rhn-bootstrap, está diseñada para cumplir esta tarea y vieneinstalada por defecto tanto en el servidor satélite de RHN como en el servidor proxy de RHN.

Si se utiliza correctamente, el script generado por esta herramienta puede ser ejecutado desdecualquier sistema para realizar 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 lasllaves de activación.

Realizar diferentes actividades posteriores a la instalación, incluyendo la actualización depaquetes, 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 scriptpara llevar a cabo la configuración. Las herramientas de seguridad, como los certificados SSL, soninstaladas por el mismo script; por lo cual no existen aún y no sirven para procesar transacciones. Estoconlleva a la posibilidad de que alguien se haga pasar por el satélite y envíe datos nocivos. El uso de loscortafuegos del usuario y el hecho de que tanto el satélite como todos los sistemas cliente estánrestringidos de tráfico exterior mitiga este problema. El proceso de registro se lleva a cabo a través deSSL, siendo así protegido.

El script de bootstrap bootstrap.sh se ubica automáticamente en el directorio /var/www/html/pub/bootstrap/ del servidor de RHN. Desde allí puede ser descargado yejecutado en todos los sistemas cliente. Observe que es necesario una preparación y una edición trasla generación del script, tal y como se muestra en las siguientes secciones. Consulte la Sección 5.4,“Opciones de RHN Bootstrap” para ver la lista completa de opciones. Por último, consulte elApéndice A, Script de ejemplo Bootstrap para ver un script de ejemplo.

5.1. PREPARACIÓN

Ya que RHN Bootstrap (rhn-bootstrap) depende de otros componentes de la infraestructura deRed Hat Network para configurar apropiadamente los sistemas cliente, esos componentes debenprepararse antes de la generación del script. La siguiente lista identifica las medidas iniciales que sedeberían tomar:

Generar las llaves de activación que serán llamadas por el script. Las llaves de activaciónsirven para registrar sistemas Red Hat Enterprise Linux, concederles derechos a uno de losniveles de servicio RHN y suscribirlos a un canal y grupo de sistemas específico. Todo ello entan solo una acción. Tenga en cuenta que debe tener derechos Management disponibles parausar una llave de activación, mientras que la inclusión de múltiples llaves de activaciónrequiere derechos Provisioning. 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 (ya sean los

CAPÍTULO 5. USO DE RHN BOOTSTRAP

23

servidores centrales de RHN para el Proxy o el nombre de dominio completamente calificadodel satélite). Consulte los capítulos sobre el Red Hat Update Agent y el sitio web de RHN en laGuía de referencia de RHN para instrucciones sobre creación y uso.

Red Hat le recomienda firmar sus RPM con una llave de GNU Privacy Guard (GPG)personalizada. Cree la llave disponible para que pueda referirse a ella desde el script. Genere lallave tal y como se describe en la Guía de administración de canales de RHN y colóquela en eldirectorio /var/www/html/pub/ del servidor RHN, por Capítulo 4, Importación de las llavesGPG personalizadas.

Si desea utilizar el script para implementar su certificado público CA SSL, tenga disponible elcertificado o el paquete RPM que lo contiene en el servidor de RHN e inclúyalo durante lageneración del script con la opción --ssl-cert. Consulte el Capítulo 3, Infraestructura delSSL para obtener mayor información.

Tenga los valores listos para desarrollar uno o más scripts bootstrap, dependiendo de lavariedad de sistemas a ser reconfigurados. Ya que RHN Bootstrap , proporciona un conjuntocompleto de opciones de reconfiguración, puede usarlo para generar diferentes scriptsbootstrap para acomodar cada tipo de sistema. Por ejemplo, bootstrap-web-servers.shpuede servir para reconfigurar sus servidores de web, mientras que bootstrap-app-servers.sh puede manejar los servidores de aplicaciones. Consulte la Sección 5.4,“Opciones de RHN Bootstrap” para obtener una lista completa.

5.2. GENERACIÓN

Ahora que todos los componentes necesarios están en su lugar, puede usar RHN Bootstrap paragenerar los scripts requeridos. Inicie una sesión como root en su servidor satélite de o servidor proxyde RHN y ejecute el comando rhn-bootstrap seguido por las opciones y valores deseados. Si no seincluye ninguna opción, se creará un archivo bootstrap.sh en el subdirectorio bootstrap/ quecontiene los valores esenciales derivados del servidor, incluyendo el nombre de host, el certificadoSSL, las configuraciones SSL y GPG, si éstas existen, y una llamada al archivo client-config-overrides.txt.

Como mínimo, Red Hat recomienda que su script contenga también las llaves de activación, llaves GPGy opciones avanzadas de configuración de la siguiente manera:

Utilice la opción --activation-keys para incluir llaves, teniendo en cuenta los derechosrequeridos señalados en la Sección 5.1, “Preparación” .

Utilice la opción --gpg-key para identificar la ruta de la llave y el nombre del archivo durantela generación del script. De lo contrario, utilice la opción --no-gpg para desactivar estaverificació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 deconfiguració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 entodos los sistemas cliente. Como la administración de configuración, esta función facilita lareconfiguració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 \


24

--allow-config-actions \ --allow-remote-commands

Obviamente, incluya los nombres reales de las llaves. Consulte la Sección 5.4, “Opciones de RHNBootstrap” para obtener una lista completa de las opciones.

5.3. USO DEL SCRIPT

Finalmente, cuando termine la preparación del script, éste estará listo para ser usado. Inicie una sesiónen el RHN Satellite Server o el RHN Proxy Server, vaya al directorio /var/www/html/pub/bootstrap/ y ejecute el siguiente comando, alterando el nombre de host y elnombre del script según sea necesario de acuerdo con el tipo de sistema:

cat bootstrap-EDITED-NAME.sh | ssh root@CLIENT_MACHINE1 /bin/bash

Una alternativa menos segura es el uso de wget o curl para descargar y ejecutar el script desde cadasistema cliente. Inicie una sesión en cada sistema cliente y ejecute el siguiente comando, modificandoel 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

O con curl:

curl -Sks \https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \| /bin/bash

Una vez el script haya sido ejecutado en cada sistema cliente, todos deben estar configurados parautilizar el servidor RHN.

5.4. OPCIONES DE RHN BOOTSTRAP

RHN Bootstrap ofrece varias opciones de la línea de comando para la creación de script bootstrap.Aunque la descripción de estas opciones puede encontrarse en la siguiente tabla, asegúrese de queestén disponibles en su versión de la herramienta instalada en su servidor de RHN ejecutando elsiguiente comando rhn-bootstrap --help o revisando las páginas man.

Tabla 5.1. Opciones de RHN Bootstrap


-h, --help Muestra una pantalla de ayuda con unalista de las opciones específicas paragenerar el script bootstrap.


25

--activation-keys=LLAVES_ACTIVACIÓN Las llaves de activación tal y como sedefinen en el sitio web de RHN con variasentradas separadas por comas y sinespacios.

--overrides=ANULA Nombre de archivo de sobrescritura de laconfiguración. Por defecto es client-config-overrides.txt.

--script=SCRIPT El nombre de archivo del scriptbootstrap. Por defecto es bootstrap.sh.

--hostname=NOMBREDEHOST El nombre de dominio completamentecalificado (FQDN) del servidor al cual lossistemas cliente se conectarán.

--ssl-cert=CERT_SSL La ruta al certificado público SSL de suorganización, ya sea un paquete o uncertificado crudo. Será copiado a laubicación dada por la opción --pub-tree. Un valor de "" forzará unabúsqueda de --pub-tree.

--gpg-key=GPG_KEY La ruta a la llave pública GPG de suorganización, si se utiliza. Será copiadaen el sitio especificado por la opción --pub-tree.

--http-proxy=HTTP_PROXY La configuración del HTTP proxy para elsistema 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. Unvalor de "" desactiva esta opción.

--http-proxy-password=HTTP_PROXY_CONTRASEÑA Si se está usando una autenticaciónHTTP proxy, especifique una contraseña.

--allow-config-actions Valor booleano; incluyendo esta opciónse establecerá la posibilidad de realizartodas las acciones de configuración através de RHN. Esto requiere lainstalación de ciertos paquetes rhncfg-*,posiblemente a través de una llave deactivación.



26

--allow-remote-commands Valor booleano, incluyendo esta opciónel sistema habilitará los comandosremotos arbitrarios a través de RHN.Esto requiere la instalación de ciertospaquetes rhncfg-*, posiblemente atravé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á larevisión de llaves GPG en el sistemacliente.

--no-up2date No recomendada - valor booleano;incluyendo esta opción se asegurará que up2date no sea ejecutado una vez elscript bootstrap haya sido ejecutado enel sistema.

--pub-tree=ÁRBOL_PÚB Cambio no recomendado - el árbol dedirectorio público donde el certificadoCA SSL y los paquetes serán ubicados; eldirectorio del bootstrap y scripts. Pordefecto es /var/www/html/pub/.

--force No recomendado - valor booleano;incluyendo esta opción se forzará lageneración del script bootstrap sin teneren cuenta las advertencias.

-v, --verbose Muestra mensajes verbosos. Esta opciónes acumulativa, -vvv producirá unaverbosidad extrema.



27

CAPÍTULO 6. CREACIÓN MANUAL DEL SCRIPT DECONFIGURACIÓNNote que este capítulo proporciona un método alternativo al uso de RHN Bootstrap para generar elscript bootstrap. Con estas instrucciones, usted podrá crear su propio script bootstrap desde cero.

Todas las técnicas iniciales comparten un tema común: la implementación de archivos necesarios enun lugar centralizado que serán recibidos e instalados usando comandos simples que pueden serincluidos en un script que se ejecuta en cada sistema cliente. En este capítulo, exploraremos la formade organizar todas las piezas para crear un script único que puede ser invocado por cualquier sistemaen su organización.

Cuando se combinan todos los comandos de los capítulos anteriores siguiendo un orden razonable,obtenemos el siguiente script. Recuerde que, rhn_register no existe en Red Hat Enterprise Linux 3o 4:

# 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_registerecho "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \ >> /etc/sysconfig/rhn/up2dateecho "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

Recuerde, el sexto paso se documenta aquí, ya que pertenece a sistemas que ejecutan Red HatEnterprise Linux 3 o posteriores.


28

Este script abarca un proceso transparente y repetible que puede ser configurado totalmente encualquier cliente de RHN potencial, en preparación para ser registrado a un Servidor proxy o unservidor satélite de RHN. Recuerde, los valores claves, tales como la URL de su servidor RHN, sudirectorio 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 estescript 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 eldirectorio /pub/ del servidor, ejecutando wget -O- en él y creando una tubería de la salida de estecomando a una sesión de shell; se puede ejecutar un proceso bootstrap en su totalidad con un únicocomando desde cada cliente:

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

AVISO

La ejecución de un script de shell directamente desde una tubería a través de unaconexión Web, conlleva por obvias razones a riesgos de seguridad. Por lo cual, esimportante garantizar la seguridad del servidor fuente en este caso.

Este comando único puede luego ser invocado en todos los sistemas de una red. Si el administradortiene acceso SSH a todos los sistemas en cuestión, sería posible ejecutar el comando remotamente encada uno de ellos. Este script también sería de gran utilidad en la sección %post de un script kickstartexistente.

CAPÍTULO 6. CREACIÓN MANUAL DEL SCRIPT DE CONFIGURACIÓN

29

CAPÍTULO 7. IMPLEMENTACIÓN DE KICKSTARTObviamente, el mejor momento para hacer cambios de configuración a un sistema es cuando esesistema se construye por primera vez. Para los usuarios que ya utilizan kickstart de forma eficiente, elscript bootstrap es una adición ideal a ese proceso.

Una vez todos los problemas de configuración han sido resueltos, un sistema puede registrarse con losServidores 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 registrarsistemas.

La herramienta rhnreg_ks utiliza las llaves de activación para registrar, dar derechos y suscribir lossistemas a canales específicos. Para obtener mayor información sobre las llaves de activación,consulte el Red Hat Update Agent y los capítulos sobre el sitio web de RHN de la Guía de referencia deManagement de Red Hat Network.

El siguiente archivo kickstart comentado es un excelente ejemplo de cómo se puede configurar unsistema 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_USlangsupport --default en_US en_USkeyboard defkeymapnetwork --bootproto dhcpinstallurl --url ftp://ftp.widgetco.com/pub/redhat/linux/7.2/en/os/i386zerombr yesclearpart --allpart /boot --size 128 --fstype ext3 --ondisk hdapart / --size 2048 --grow --fstype ext3 --ondisk hdapart /backup --size 1024 --fstype ext3 --ondisk hdapart swap --size 512 --ondisk hdabootloader --location mbrtimezone America/New_Yorkrootpw --iscrypted $1$78Jnap82Hnd0PsjnC8j3sd2Lna/Hx4.auth --useshadow --enablemd5 --krb5realm .COM --krb5kdc auth.widgetco.com \ --krb5adminserver auth.widgetco.commouse --emulthree genericps/2xconfig --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


30

@ 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

CAPÍTULO 7. IMPLEMENTACIÓN DE KICKSTART

31

APÉNDICE A. SCRIPT DE EJEMPLO BOOTSTRAPEl script /var/www/html/pub/bootstrap/bootstrap.sh generado por el programa deinstalación del Servidor satélite de RHN proporciona la capacidad de reconfigurar los sistemasclientes para acceder fácilmente a su servidor de RHN. Está disponible para los clientes del servidorsatélite y del servidor proxy de RHN a través de la herramienta RHN Bootstrap . Después de modificarel script para su uso particular, este puede ser ejecutado en cada máquina cliente.

Revise el ejemplo y sus comentarios que comienzan por el signo de número (#) para obtenerinformación adicional. Siga los pasos en Capítulo 5, Uso de RHN Bootstrap para preparar el script parasu uso.

#!/bin/bashecho "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


32

# 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.

echoechoecho "MINOR MANUAL EDITING OF THIS FILE MAY BE REQUIRED!"echoecho "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."echoecho "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."echoecho "Enable this script: comment (with #'s) this block (or, at least just"echo "the exit below)"echoexit 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_hereORG_GPG_KEY=insert_org_gpg_pub_key_here

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

ORG_CA_CERT=RHN-ORG-TRUSTED-SSL-CERT


33

ORG_CA_CERT_IS_RPM_YN=0

USING_SSL=1USING_GPG=1

REGISTER_THIS_BOX=1

ALLOW_CONFIG_ACTIONS=0ALLOW_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 fifi

HTTP_PUB_DIRECTORY=http://${HOSTNAME}/pubHTTPS_PUB_DIRECTORY=https://${HOSTNAME}/pubif [ $USING_SSL -eq 0 ] ; then HTTPS_PUB_DIRECTORY=${HTTP_PUB_DIRECTORY}fiechoecho "UPDATING RHN_REGISTER/UP2DATE CONFIGURATION FILES"echo "-------------------------------------------------"echo "* downloading necessary files"


34

echo " client_config_update.py..."rm -f client_config_update.py$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/client_config_update.pyecho " ${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 1fiif [ ! -f "${CLIENT_OVERRIDES}" ] ; then echo "ERROR: ${CLIENT_OVERRIDES} was not downloaded" exit 1fi

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}fiecho " . 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 fifi

echoecho "* 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/ fifi

echoecho "REGISTRATION"echo "------------"


35

# 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 1fi

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 ***" echoelse echo "* explicitely not registering"fi

echoecho "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"fiecho "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 -pif [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then /usr/sbin/up2date -uffiecho "-bootstrap complete-"


36


Revisión 2-2.2.400 2013-10-31 Rüdiger LandmannRebuild with publican 4.0.0

Revisión 2-2.2 Wed May 15 2013 Gladys Guerrero-Lozanolibro revisado

Revisión 2-2.1 Tue May 14 2013 Chester ChengLos archivos de traducción sincronizados con fuentes XML 2-2

Revisión 2-2 Mon Aug 15 2011 Lana BrindleyFolded z-stream release into y-stream

Revisión 2-1 Wed Jun 15 2011 Lana BrindleyPreparado para traducción

Revisión 2-0 Fri May 7 2011 Lana BrindleyPrepared for translation

Revisión 1-8 Mon Feb 7 2011 Lana BrindleyCertificados - BZ#662876

Revisión 1-7 Tue Feb 1 2011 Lana BrindleyÚltimos clientes - BZ#636703


37

ÍNDICE

Símbolos

--configure

uso de, Opción up2date --configure

A

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

C

Certificados SSL

configuración de, Configuración de los sistemas cliente

generación, Uso de RHN SSL Maintenance Tool

instalación de, Implementación del certificado público CA SSL a los clientes

Configuración , Registrar clientes al servidor satélite de RHN

creación de script completamente, Creación manual del script de configuración

manual, Actualización manual de los archivos de configuración

configuración

conmutación de servidor, Implementación del servidor alternativo

Configuración de cliente

Red Hat Update Agent , Opción up2date --configure

K

kickstart

uso de, Implementación de Kickstart

L

Llaves de activación

registro con, Registro con las llaves de activación

Llaves GPG


38

importación de, Importación de las llaves GPG personalizadas

R

Red Hat Network Alert Notification Tool

configuración para Satélite, Configuración de la Red Hat Network Alert Notification Tool conSatélite.

Red Hat Update Agent

configuración para usar el servidor satélite o proxy de RHN, Actualización manual de losarchivos de configuración

RHN Bootstrap

generar el script, Generación

opciones de línea de comandos, Opciones de RHN Bootstrap

preparación, Preparación

uso, Uso de RHN Bootstrap

uso del script, Uso del script

RHN SSL Maintenance Tool

explicación de generación, Explicación de la generación de SSL

generar certificado, Generación del par de llaves CA SSL.

generar el certificado del servidor, Generación del juego de llaves SSL del servidor web

opciones, Opciones de RHN SSL Maintenance Tool

rhn-ssl-tool , Uso de RHN SSL Maintenance Tool

rhn-ssl-tool

explicación de generación, Explicación de la generación de 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.

opciones, Opciones de RHN SSL Maintenance Tool

RHN SSL Maintenance Tool , Uso de RHN SSL Maintenance Tool

S

SSL (Secure Sockets Layer)

introducción, Una breve introducción al SSL

ÍNDICE

39

Documents

Red Hat Network Satellite 5 Hat Network Satellite 5.4 Gu a de configuraci n de cliente Red Hat Network Satellite Edición 2 Red Hat Documentation Team