• No se han encontrado resultados

Red Hat Network Satellite 5.5 Gu a de Instalaci n de Proxy

N/A
N/A
Protected

Academic year: 2021

Share "Red Hat Network Satellite 5.5 Gu a de Instalaci n de Proxy"

Copied!
38
0
0

Texto completo

(1)

Red Hat Equipo de documentación

Red Hat Network Satellite 5.5

Gu

�a de Instalaci�n de Proxy

Red Hat Network Satellite

Edición 3

(2)

Red Hat Network Satellite 5.5 Gu�a de Instalaci�n de Proxy

Red Hat Network Satellite

Edición 3

(3)

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

Abstract

(4)

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

Table of Contents

Capítulo 1. Introducción

1.1. Red Hat Network

1.2. Terminologías utilizadas frecuentemente 1.3. Servidor proxy de RHN

1.4. Forma como funciona proxy Capítulo 2. Requerimientos

2.1. Requerimientos de software 2.2. Requerimientos de hardware

2.3. Requerimientos de espacio de disco 2.4. Requerimientos adicionales

Capítulo 3. Topologías de ejemplo 3.1. Topología con un único Proxy

3.2. Topología de múltiples Proxy ordenados horizontalmente 3.3. Topología de múltiples Proxy ordenados verticalmente 3.4. Proxy con Servidor satélite RHN

Capítulo 4 . Instalación 4.1. Instalación de base

4.2. Proceso de instalación del Servidor proxy RHN. 4.2.1. El archivo Answer

Capítulo 5. Gestor de paquetes de RHN y Paquetes locales en servicio 5.1. Creación de un canal privado

5.2. Actualización de paquetes

Capítulo 6. Mejoras de la instalación 6.1. Prerrequisitos

6.2. Mejorar el proceso de instalación

Capítulo 7. Detección y resolución de problemas 7.1. Administración del servicio Proxy

7.2. Archivos de registro 7.3. Preguntas y respuestas 7.4. Problemas generales

7.5. Host No Encontrado/No se pudo determinar FQDN 7.6. Errores de conexión

7.7. Problemas relacionados con cache 7.8. Depuración del Proxy por Red Hat

Ejemplo del archivo de configuración del Servidor proxy de RHN Historial de revisiones Índice A C D 4 4 4 5 6 8 8 9 9 9 12 12 12 13 14 15 15 15 19 20 22 22 24 24 24 25 25 25 25 26 27 28 28 29 31 32 33 33 33 33 Table of Contents

(5)

P R T V 34 35 35 35

(6)
(7)

Capítulo 1. Introducción

1.1. Red Hat Network

Red Hat Network (RHN) es el entorno para soporte a nivel del sistema, administración de sistemas y redes de sistemas de Red Hat . Red Hat Network reune las herramientas, los servicios y los depósitos de información necesarios para maximizar la confiabilidad, seguridad y rendimiento de sus sistemas. Para poder utilizar RHN, los administradores del sistema registran los perfiles de software y hardware de sus sistemas clientes, conocidos como perfiles del sistema, en Red Hat Network. Cuando un sistema solicita una actualización de paquetes, se retornarán tan sólo los paquetes aplicables para el cliente (con base en los perfiles de software almacenados en los servidores de RHN).

Entre las ventajas de usar Red Hat Network se incluyen:

Escalabilidad — con Red Hat Network, un solo administrador del sistema puede configurar y

mantener cientos o miles de sistemas Red Hat con una facilidad, certeza y rapidez mayor de la que tendría al mantener un sistema individual sin Red Hat Network.

Protocolos estándar — los protocolos estándar sirven para mantener la seguridad e incrementar la capacidad. Por ejemplo, XML-RPC le permite a Red Hat Network realizar muchas más operaciones además de la descarga de archivos.

Seguridad — todas las comunicaciones entre los sistemas registrados y Red Hat Network se realizan a través de conexiones seguras de Internet.

Vista de las alertas de erratas — las alertas de erratas para todos sus sistemas cliente son fácilmente visibles a través de un sitio web.

Acciones programadas — utilice el sitio web para programar acciones, incluyendo actualizaciones de erratas, instalación de paquetes y actualizaciones del perfil de software.

Simplificación — el mantenimiento de un sistema Red Hat se convierte en un sencillo proceso automatizado.

1.2. Terminologías utilizadas frecuentemente

Antes de entender el funcionamiento del Servidor proxy de RHN, es importante familiarizarse con los siguientes términos de Red Hat Network:

Canal

Un canal es una lista de paquetes de software. Hay dos clases de canales: canales base y canales hijo. Un canal base está conformado por una lista de paquetes basada en una

arquitectura específica y una versión de Red Hat . Un canal hijo es un canal que está asociado a un canal base y que contiene paquetes adicionales.

Administrador de la organización

El administrador de organización es un rol de usuario que goza del más alto nivel de control sobre la cuenta Red Hat Network de una organización. Los miembros de este rol pueden añadir otros usuarios, otros sistemas y grupos de sistemas a la organización, así como

también eliminarlos. Una cuenta Red Hat Network de una organización debe tener por lo menos un administrador de organización.

Administrador de canales

Un administrador de canales es un rol de usuario que tiene acceso total a las funciones de administración de los canales. Los usuarios con este rol tienen la capacidad de crear canales y

(8)

asignar paquetes a éstos. Este rol puede ser asignado por un administrador de organización a través de la pestaña Usuarios del sitio web de RHN.

Agente de actualización de Red Hat

El Agente de actualización de Red Hat es la aplicación cliente de Red Hat Network (up2date o yum ) que permite a los usuarios recibir e instalar paquetes actualizados para el sistema cliente en el cual se ejecuta la aplicación.

Trazabilidad

La trazabilidad es la descripción detallada de "qué salió mal"; sirve para identificar y solucionar los errores del Servidor proxy de RHN. La trazabilidad se genera automáticamente cuando ocurre un error crítico y se envían por correo a la persona designada en el archivo de configuración del Servidor proxy de RHN.

Para una explicación más detallada de estos y otros términos, consulte la Guía de Referencia de Red

Hat Network disponible en http://www.redhat.com/docs/manuals/satellite/ y en la página de Ayuda en la interfaz de usuario de la web de Satélite.

1.3. Servidor proxy de RHN

Un Servidor proxy de RHN es un mecanismo de almacenamiento de paquetes en cache que reduce los requerimientos de ancho de banda para RHN y permite, además, la implementación de paquetes personalizados. Los usuarios de Proxy guardan en cache los RPM, tales como las actualizaciones de erratas de Red Hat o los RPM personalizados generados por la organización, en un servidor interno y centralizado. Los sistemas clientes reciben las actualizaciones desde el Proxy en vez de acceder individualmente a la Internet.

Aunque el Proxy sirve los paquetes, los perfiles de sistemas de clientes y la información del usuario se almacenan de forma segura en los servidores centrales de RHN . el cual también sirve al sitio web RHN (rhn.redhat.com). El Proxy actúa como un intermediario entre los sistemas cliente y Red Hat Network (o un Servidor satélite de RHN). Solamente los archivos de paquetes son almacenados en el Servidor proxy de RHN. Cada transacción es autenticada y el Agente de Actualización de Red Hat, revisa la firma GPG de cada paquete recuperado desde el servidor proxy de RHN local.

Además de almacenar paquetes oficiales de Red Hat, el Servidor proxy de RHN puede ser configurado para repartir los paquetes personalizados de una organización desde canales privados de RHN, mediante el Gestor de paquetes de RHN. Por ejemplo, una organización puede desarrollar su propio software, empaquetarlo en un RPM, firmarlo con su propia firma GPG y usar el Servidor proxy de RHN local para actualizar todos los sistemas individuales en la red con las últimas versiones del software personalizado.

Ventajas de usar el Servidor proxy RHN:

Escalabilidad — puede haber múltiples servidores proxy de RHN dentro de una organización. Seguridad — Se mantiene una conexión segura de punta a punta: desde el sistema cliente al Servidor proxy de RHN local a los servidores de Red Hat Network.

[1]

(9)

cada paquete a cada sistema cliente.

Actualizaciones personalizadas — crea un sistema de entrega de paquetes automatizado para paquetes de software personalizado, así como de los paquetes oficiales de Red Hat requeridos por el sistema cliente. Los canales de RHN personalizados y privados le permiten a una organización la entrega automatizada de paquetes dentro de la empresa.

Configuración personalizada — la habilidad de restringir o conceder actualizaciones a arquitecturas específicas o diferentes versiones de sistema operativo.

Solamente se necesita una conexión a Internet — el sistema cliente se conecta a través del servidor Proxy con HTTP activado, por lo cual no necesita una conexión a la red externa (Internet), pero sólo requiere acceso a la red de área local (LAN) a la cual el Servidor proxy de RHN está conectado. Sólo el Servidor proxy de RHN necesita una conexión a Internet para contactar los servidores RHN, a menos que el Servidor proxy de RHN esté utilizando un servidor satélite de RHN, en dicho caso, sólo el satélite requerirá una conexión a Internet.

1.4. Forma como funciona proxy

El Agente de actualizaciones de Red Hat o el Actualizador de paquetes en el sistema cliente no contacta directamente a un servidor de Red Hat Network. En su lugar, el cliente (o los clientes) se conecta a un Servidor proxy de RHN que conecta a los servidores de Red Hat Network o a un Servidor satélite de RHN. Así, el sistema cliente accede directamente a la Internet. Solamente se necesita tener acceso al Servidor proxy de RHN.

Importante

Red Hat recomienda encarecidamente a los clientes conectados a un Servidor proxy de RHN, que ejecuten la versión más reciente de Red Hat Enterprise Linux para obtener una conexión correcta.

Los clientes se autentican de forma predeterminada directamente mediante los servidores de RHN. Los clientes que acceden al Servidor proxy de RHN aún se autentican mediante RHN, sin embargo, en este caso el proxy proporciona autenticación e información de la ruta a RHN. Después de una autenticación exitosa, el servidor de Red Hat Network informa al Servidor proxy de RHN que la ejecución de una acción para el cliente está permitida. El Servidor proxy de RHN descarga todas los paquetes actualizados (si aún no están en la memoria cache) y los entrega al sistema cliente.

Las solicitudes del Agente de Actualización de Red Hat o Actualizador de paquetes en los sistemas cliente aún se autentican en el servidor, pero la entrega de paquetes es significativamente más rápida ya que los paquetes están almacenados en el Servidor cache proxy de RHN (para paquetes locales); el Servidor proxy de RHN y el sistema cliente están conectados a través de LAN y su limitación depende de la velocidad de la red local.

La autenticación se realiza en el siguiente orden:

1. El cliente realiza una acción de identificación al comenzar la sesión del cliente. Esta identificación pasa a través de uno o más Servidores proxy de Red Hat Network hasta llegar a un servidor Red Hat Network.

2. El servidor de Red Hat Network intenta autenticar el cliente. Si la autenticación es satisfactoria, el servidor envía de regreso una señal de sesión a través de los Servidores proxy de RHN. Este identificador, el cual tiene una firma y fecha de vencimiento, contiene la información del usuario, incluidos el nombre de usuario, la suscripción a canales, etc.

(10)

/var/cache/rhn/. Al guardarlo se reduce el gasto de autenticación con el servidor Red Hat Network y mejora en gran medida el rendimiento de Red Hat Network.

4. Esta señal de sesión pasa de regreso a la máquina cliente y se utiliza en acciones subsecuentes en Red Hat Network.

Desde el punto de vista del cliente, no hay diferencia entre un Servidor proxy de Red Hat Network y un Servidor Red Hat Network. Desde el punto de vista del Servidor proxy de Red Hat Network, un Servidor proxy de RHN es una clase especial de cliente de RHN. Así, los clientes no se ven afectados por la ruta que toma la petición para llegar al Servidor Red Hat Network. Toda la lógica se implementa en el

Servidor proxy de RHN y los servidores de Red Hat Network.

Opcionalmente, el Gestor de paquetes de RHN se puede instalar y configurar para que sirva paquetes personalizados escritos especialmente para la organización. Los paquetes que no sean paquetes oficiales de Red Hat, incluidos los paquetes escritos específicamente para una organización, solamente pueden ser servidos desde un canal de software privado (conocido también como un canal de software personalizado). Después de crear un canal privado de RHN, los paquetes RPM son asociados a ese canal privado al descargar los encabezados de paquetes a los servidores RHN. Solamente se cargan los encabezados, no los archivos del paquete. Los encabezados se necesitan ya que contienen información importante sobre el RPM, tal como las dependencias de software que permiten a RHN automatizar la instalación de paquetes. Los paquetes RPM personalizados se almacenan en el Servidor proxy de RHN y se envían al sistema cliente desde el interior de la red de área local de la organización. Configurar una red de computadores para utilizar un Servidor proxy de RHN es fácil. Las aplicaciones de Red Hat Network en el sistema cliente deben ser configuradas para conectarse al Servidor proxy de RHN en vez de a los servidores Red Hat Network. Consulte la Guía de configuración de sistemas cliente

de RHN para mayor información. Del lado del proxy, se debe especificar el siguiente proxy en la cadena

(la cual terminará eventualmente en un servidor Red Hat Network). Si se utiliza el Gestor de paquetes de RHN, el sistema cliente debe estar suscrito al canal privado de RHN.

[1] A través d e este d o cumento , " RHN" p ued e referirse al sitio d ed icad o d e RHN (http ://rhn.red hat.co m) o a un Servid o r satélite d e RHN.

(11)

Capítulo 2. Requerimientos

Estos requerimientos deben cumplirse antes de la instalación. Recuerde que el Satélite debe ser una versión mayor o igual a la versión del Proxy que va a instalar. Por ejemplo, si desea instalar el Servidor proxy de RHN 5.4, la versión de Satélite debe ser 5.4 o posterior y no puede ser 5.3 o inferior.

2.1. Requerimientos de software

Para realizar una instalación, los siguientes componentes relacionados con el software deben estar disponibles:

Sistema operativo base — el Servidor proxy de RHN tiene soporte en Red Hat Enterprise Linux 5 y 6. El sistema operativo puede ser instalado desde disco, imagen ISO local, kickstart o cualquier otro método soportado por Red Hat.

El Servidor proxy de RHN puede instalarse en Red Hat Enterprise Linux 5 y 6 en cualquier entorno virtualizado que tenga soporte de Red Hat, incluidos XEN, KVM, y VMware.

Observe que para implementaciones de producción, le recomendamos usar el Servidor proxy de RHN como una única aplicación en ejecución en el hardware físico subyacente para evitar problemas de contención. También, tenga en cuenta que el soporte funcional para entornos virtualizados no siempre iguala al rendimiento de ejecución en un hardware físico, por lo tanto, necesita considerar con detenimiento su entorno virtualizado preferido y ajustarse a los lineamientos recomendados.

Nota

Cada producto RHN Proxy adquirido incluye una instancia soportada del Servidor de Red Hat Enterprise Linux. RHN Proxy debe ser instalado en una instalación fresca de Red Hat

Enterprise Linux en la que RHN Proxy sea la única aplicación y servicio provistos por el Sistema Operativo. El uso del SO de Red Hat Enterprise Linux incluido en RHN Proxy para ejecutar otros demonios, aplicaciones o servicios dentro de su entorno no tiene soporte.

Cada versión de Red Hat Enterprise Linux requiere ciertas series de paquetes para soportar el Servidor proxy de RHN. Añadir otros paquetes puede causar errores durante la instalación. Por lo tanto, Red Hat le recomienda obtener la serie de paquetes que desea de la siguiente manera:

Nota

Para instalaciones kickstart, especifique el siguiente grupo de paquetes: @ Base

Para instalar Red Hat Enterprise Linux mediante CD o imágenes ISO, seleccione el siguiente grupo de paquetes: Mínimo

Un derecho disponible del Servidor proxy de RHN dentro de la cuenta del Servidor satélite de RHN. Un derecho de aprovisionamiento dentro de la cuenta del Servidor satélite de RHN (el cual debe venir empaquetado junto con el derecho del Servidor proxy de RHN).

Acceso al canal de Herramientas de Red Hat Network para la versión de Red Hat Enterprise Linux instalada. Este canal incluye el paquete spacewalk-proxy-installer que contiene el programa de instalación configure-proxy.sh requerido para instalar Servidor proxy de RHN.

Todos los paquetes rhncfg* instalados en el Proxy (desde el canal de herramientas de RHN). Ya sea el paquete rhns-certs-tools instalado en el Proxy (desde el canal Herramientas de RHN) o la contraseña del certificado de la autoridad certificadora (CA) de capa de conexiones

(12)

seguras,SSL, utilizada para generar el certificado del servidor principal para usuarios de Servidor satélite de RHN.

La configuración del sistema para que acepte los comandos remotos y la administración de

configuración mediante Red Hat Network si utiliza el método de IU de web descontinuado. Consulte la Sección 4.2, “Proceso de instalación del Servidor proxy RHN.” para obtener instrucciones.

2.2. Requerimientos de hardware

La siguiente configuración de hardware es requerida por el Servidor proxy de RHN: Procesador Pentium IV o equivalente

512 MB de memoria

Al menos 5 GB de almacenamiento para la instalación base de Red Hat Enterprise Linux Almacenaje de 6 GB por distribución/canal

La carga del Servidor de web APACHE está directamente relacionada con la frecuencia con la cual los sistemas clientes se conectan al Proxy. Si reduce el intervalo predeterminado de cuatro horas (o 240 minutos) como se establece en el archivo de configuración /etc/sysconfig/rhn/rhnsd de los sistemas cliente, la carga en este componente aumentará de modo significativo.

2.3. Requerimientos de espacio de disco

El mecanismo de cache usado por el Servidor proxy de RHN es el proxy HTTP Squid, el cual economiza significativamente el ancho de banda para los clientes. Debe tener una cantidad razonable de espacio disponible. Los paquetes en cache se almacenan en /var/spool/squid. La asignación de espacio libre requerido es de 6 GB de almacenamiento por distribución/canal.

Si el Servidor proxy de RHN está configurado para distribuir paquetes locales o personalizados, verifique si el punto de montaje /var en el sistema que almacena los paquetes locales tiene suficiente espacio de disco para guardar todos los paquetes personalizados, los cuales se guardan en

/var/spool/rhn-proxy. El espacio de disco requerido para los paquetes locales depende del número de paquetes personalizados servidos.

2.4. Requerimientos adicionales

Los siguientes requerimientos adicionales deben cumplirse antes de considerar la instalación del Servidor proxy de RHN completa:

Acceso total

Los sistemas cliente necesitan acceso total de red a los servicios y puertos del Servidor proxy de RHN.

Reglas de cortafuegos

RHN recomienda usar un cortafuegos en el Servidor proxy de RHN contra Internet. Sin

embargo, algunos puertos TCP deben estar abiertos en el Proxy, según la implementación del Servidor proxy de RHN:

(13)

Tabla 2.1. Puertos a abrir en el Proxy

Puerto Dirección Razón

80 Saliente Proxy usa este puerto para conectar

rhn.redhat.com, xmlrpc.rhn.redhat.com, y su URL de satélite (ya sea que Proxy de RHN esté comunicándose con RHN dedicado o con el Servidor Satélite). 80 Entrante Las solicitudes de los clientes vienen a

través de http o https

443 Entrante Las solicitudes de los clientes vienen a través de http o https

443 Saliente El Proxy usa este puerto para

comunicarse con rhn.redhat.com,

xmlrpc.rhn.redhat.com, y su URL de Satélite (dependiendo de si el Proxy se está comunicando con RHN Hosted o con Satellite Server).

4545 Saliente Si su Proxy está conectado a un

Servidor satélite de RHN, el servicio de monitorización se conectará a rhnmd en el sistema cliente a través de este puerto TCP si el servicio de

monitorización está activado y los sondeos están configurados en los sistemas registrados.

5222 Entrante Al abrir este puerto se permiten la conexiones de cliente osad al demonio jabberd en el Proxy utilizando la tecnología RHN Push.

5269 Saliente Si el Proxy está conectado a un

Servidor satélite de RHN, este puerto debe estar abierto para permitir conexiones de servidor a servidor a través de jabberd para la tecnología de RHN Push.

Tiempos del sistema sincronizados

Hay una gran susceptibilidad relacionada en el momento en el que se realizan las conexiones a un servidor Web ejecutando SSL (Capa de conexiones seguras). Es importante que la

configuración de tiempo de los clientes y el servidor sean razonablemente similares para evitar que el certificado SSL no expire antes o durante su uso. Se recomienda el uso de Protocolo de tiempo de red (NTP) para sincronizar los relojes.

Nombres de dominios completamente calificados (FQDN)

El sistema en el cual el Servidor proxy de RHN será instalado deberá resolver correctamente su Nombre completo (FQDN).

(14)

Los usuarios que se conectarán a los servidores centrales de Red Hat Network para recibir actualizaciones incrementales necesitarán una cuenta en Red Hat Network. El representante de ventas lo asistirá con esta configuración durante el momento de la adquisición del producto.

Copias de seguridad de la información de inicio de sesión

Es imperativo que los usuarios lleven un registro de toda la información primaria de inicio de sesión. Para el Servidor proxy de RHN, esto incluye los nombres de usuarios y contraseñas para la cuenta del administrador de la organización y la generación del certificado SSL. Red Hat recomienda que esta información sea copiada en dos disquetes separados, impresa en papel y almacenada en una caja de seguridad.

Localización de las distribuciones

Puesto que el Proxy reenvía virtualmente todas las peticiones HTTP locales a los servidores centrales de RHN, debe tener cuidado en poner los archivos destinados para cada distribución (tal como en un árbol de instalación kickstart) en la localización no reenviable del Proxy: /var/www/htm l/pub/. Los archivos ubicados en este directorio pueden ser descargados directamente del Proxy. Esto puede ser util para distribuir llaves GPG o establecer árboles de instalación kickstart.

Además, Red Hat recomienda que el sistema que ejecuta el código no esté disponible públicamente. Ningún usuario a excepción del administrador del sistema, debe tener acceso de shell a estas máquinas. Todos los servicios innecesarios deben ser desactivados. Ejecute ntsysv o chkconfig para desactivar servicios.

Finalmente, debe tener la siguiente documentación técnica a la mano para usar en un orden similar al siguiente:

1. La Guía de instalación del Servidor proxy de RHN — Es la guía que está leyendo en estos momentos. Esta guía proporciona los pasos necesarios para tener su Servidor proxy de RHN instalado y en ejecución.

2. La Guía de configuración de sistemas cliente de RHN — Esta guía explica cómo se deben configurar los sistemas que van a ser servidos por un Servidor proxy o por un Servidor satélite de RHN. (Es muy probable que requiera también consultar la Guía de referencia de RHN, la cual contiene los pasos para registrar y actualizar los sistemas).

3. La Guía de administración de canales de RHN — Esta guía describe con gran detalle los métodos recomendados para construir paquetes personalizados, crear canales personalizados y manejar erratas privadas.

4. La Guía de referencia de RHN — Esta guía describe la manera de crear cuentas RHN, registrar y actualizar los sistemas y el uso del sitio web de RHN. Este manual es bastante útil durante el proceso de instalación y configuración.

(15)

Capítulo 3. Topologías de ejemplo

El Servidor proxy de RHN puede ser configurado de diferentes formas. Seleccione un método dependiendo de los siguientes factores:

1. El número total de sistemas cliente a ser servidos por el Servidor proxy de RHN

2. El número máximo de clientes que se espera se conecten concurrentemente al Servidor proxy de RHN.

3. El número de canales y paquetes personalizados a ser servidos por el Servidor proxy de RHN. 4. El número de Proxis a ser usados en el entorno del usuario.

El resto de este capítulo describe las posibles configuraciones y explica sus beneficios.

3.1. Topología con un único Proxy

La configuración más sencilla es la utilización de un Servidor proxy de RHN individual para servir toda la red. Esta configuración es adecuada para servir un grupo pequeño de clientes y una red que se

beneficiará de la cache de los RPM de Red Hat y del almacenamiento de paquetes personalizados en el servidor local.

La desventaja de usar un Servidor proxy de RHN individual es que el rendimiento se verá afectado cuando aumente el número de clientes que soliciten paquetes.

Figura 3.1. Topología con un único Proxy

3.2. Topología de múltiples Proxy ordenados horizontalmente

Para redes grandes, se necesitará un método más distribuido, tal como el ofrecido por múltiples Proxis conectados individualmente a Red Hat Network. Esta configuración de ordenamiento horizontal equilibra la carga de las solicitudes de los clientes y permite a cada Proxy sincronizarse simultáneamente con RHN.

Una desventaja de esta estructura horizontal es que los paquetes personalizados cargados a un Proxy individual deben ser distribuidos a todos los demás Proxy. Esta situación puede solucionarse de dos

(16)

formas:

El programa de transferencia de archivo rsync sirve para sincronizar paquetes entre Proxy

Se puede establecer un sistema de archivos de red (NFS) compartido entre los Proxy y el repositorio del canal personalizado.

Cualquiera de estas soluciones le permitirá a cualquier cliente de cualquier Servidor proxy de RHN recibir todos los paquetes personalizados.

Figura 3.2. Topología de múltiples Proxy ordenados horizontalmente

3.3. Topología de múltiples Proxy ordenados verticalmente

Un método alternativo para múltiples Servidores proxy de RHN es establecer un proxy primario que los demás conectarán a los RPM desde Red Hat Network y paquetes personalizados creados localmente. En esencia, Los Proxis secundarios actuarán como clientes de los Proxis primarios. Esto solucionará la necesidad de establecer un mecanismo de sincronización entre los Servidores Proxy de RHN ya que usan la función up2date inherente al producto.

Al igual que la configuración ordenada de forma horizontal, este método vertical permite que cualquier cliente reciba los paquetes personalizados de Servidores proxy de RHN. El Proxy busca en su repositorio para ver si puede encontrar el paquete en su sistema de archivos. Si no lo encuentra, buscará el paquete en el nivel superior.

Esta configuración ordenada verticalmente asegura que los Proxy secundarios dependan de los primarios para recibir actualizaciones de RHN y actualizaciones de los paquetes personalizados. Asimismo, todos los canales y paquetes personalizados deben ser ubicados únicamente en los Proxy primarios para asegurar la distribución a los Proxy hijos. Finalmente, los archivos de configuración de los proxy secundarios deben apuntar a los primarios en vez de apuntar directamente a Red Hat

(17)

Figura 3.3. Topología de múltiples Proxy ordenados verticalmente

3.4. Proxy con Servidor satélite RHN

Además de los métodos descritos en este capítulo, los usuarios tienen la opción de usar el Servidor proxy de RHN junto con el Servidor satélite de RHN. Esta estructura funciona de un modo similar a la configuración de Proxy en orden vertical pero la capacidad incrementa significativamente, ya que el Satélite puede servir un número mayor de sistemas cliente.

Para una descripción más detallada de esta combinación, consulte el ejemplo en el capítulo de topologías en la Guía de instalación del Servidor satélite de RHN. La forma de enlazar los certificados SSL de ambos productos se describe en la Guía de configuración de sistemas cliente de RHN. Para entender cómo se comparten entre sí los paquetes y canales, consulte la Guía de administración de

(18)

Capítulo 4. Instalación

Este capítulo describe la instalación inicial del Servidor proxy de Red Hat Network . Presupone que los requisitos listados en el Capítulo 2, Requerimientos han sido cumplidos. Sin embargo, si está

actualizando su servidor a una nueva versión del Servidor proxy de Red Hat Network, contacte a su

representante de Red Hat para recibir asistencia.

4.1. Instalación de base

El Servidor proxy de RHN está diseñado para ser ejecutado en el sistema operativo Red Hat Enterprise Linux. Por lo tanto, el primer paso es instalar el sistema operativo, ya sea desde un disco, una imagen ISO o mediante la función kickstart. Durante y después de la instalación del sistema operativo,

asegúrese de:

Asignar suficiente espacio a la partición que va a ser usada para almacenar paquetes, de acuerdo con los requisitos de hardware establecidos anteriormente. La ubicación predeterminada para guardar paquetes de Red Hat es /var/spool/squid, mientras que los paquetes personalizados están ubicados en /var/spool/rhn-proxy.

Nota

El programa de instalación calcula automáticamente el espacio disponible en la partición en donde se monta /var/spool/squid y asigna hasta el 60 por ciento del espacio libre para uso del Servidor proxy de RHN.

Instalar los paquetes requeridos por el Servidor proxy de RHN

Importante

Se deben instalar únicamente los paquetes base, ya que otros paquetes pueden causar que la instalación del Servidor proxy de RHN falle.

Consulte la Sección 2.1, “Requerimientos de software” para obtener el método con el cual se puede obtener el paquete correcto necesario para cada versión de Red Hat Enterprise Linux.

Active el Protocolo de Tiempo de red, NTP, en el proxy y seleccione el huso horario apropiado. Todos los sistemas clientes ya deben estar ejecutando el demonio ntpd y tener configurado el huso horario correcto.

Desactive los servicios ipchains y iptables después de la instalación.

4.2. Proceso de instalación del Servidor proxy RHN.

Las siguientes instrucciones describen el proceso de instalación del Servidor proxy de RHN: 1. Ingrese como usuario root en el sistema del Servidor proxy RHN.

2. Registre el sistema recién instalado de Red Hat Enterprise Linux con Red Hat Network (ya sea a los servidores centrales de RHN o en el Servidor satélite de RHN ) mediante la cuenta de la

(19)

yum install spacewalk-proxy-installer 5. Realizar la instalación:

configure-proxy.sh

Nota

Para realizar este paso correctamente, debe acceder como root al servidor de Satélite. Alternativamente, añada la opción --force-own-ca al comando.

El programa de instalación de la línea de comandos conduce a los usuarios a través de una serie de peticiones relacionadas con la instalación del Servidor proxy de RHN y la información de configuración inicial como por ejemplo, las opciones de instalación y la creación del certificado SSL. Las siguientes instrucciones describen el proceso de instalación:

Consejo

Si presiona la tecla Intro en un intérprete de comandos en lugar de teclear en una entrada, el programa de instalación de línea de comandos del Servidor proxy de RHN usará la respuesta predeterminada encerrada entre paréntesis.

También, si desea utilizar respuestas predeterminadas sin ninguna interacción de usuario, use la opción --non-interactive, la cual usará todas las respuestas predeterminadas.

6. La primera serie de peticiones es información específica del sitio acerca de la instalación. Proxy version to activate [5.4]:

La Versión de Proxy le pedirá confirmar la versión del Servidor proxy de RHN que desea instalar.

RHN Parent [satserver.example.com]:

El Servidor principal de RHN es el nombre de dominio o dirección del sistema servidor del Proxy que podrían ser ser los servidores RHN Hosted (xmlrpc.rhn.redhat.com), o un servidor Servidor satélite.

Traceback email []:

El Traceback email/Correo-e de rastreo es la dirección de correo-e a la que se envían los mensajes de seguimiento de errores, por lo general el correo-e del administrador de Proxy. Use comas para separar más de una dirección de correo-e en esta petición.

7. Las siguientes series de peticiones se relacionan con la configuración de la información para generar un certificado SSL, el cual se recomienda para asegurar el tráfico desde y hacia el Servidor proxy de RHN.

Use SSL [Y/n]: y

(20)

CA Chain [/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT]:

En la petición de Cadena CA, presione Enter para usar la ruta predeterminada para la Cadena de autoridad certificadora (CA), la cual por lo general, si el Proxy de RHN está comunicándose con el Satélite de RHN será /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT y si el proxy se está comunicando con RHN Hosted, será el archivo /usr/share/rhn/RHNS-CA-CERT. Los certificados SSL deben estar localizados en el directorio /usr/share/rhn/.

HTTP Proxy []:

Si el Servidor proxy de RHN se conecta a través de un proxy HTTP, ingrese el nombre de host de proxy y el número de puerto, tal como corporate.proxy.example.com:3128

Escriba la información requerida para generar un certificado de servidor SSL apropiado, incluyendo el nombre de la Organización, la Unidad de organización (tal como Ingeniería), el Nom bre com ún (el nombre de dominio), como también detalles de ciudad, estado y país. Por último, escriba la dirección de correo-e para contactar el administrador o técnico a cargo de los certificados SSL.

Independiente de si tiene SSL activado para la conexión al Servidor principal Proxy, se le solicitará generar un certificado SSL.

Este certificado SSL le permitirá a los sistemas clientes conectarse a este Spacewalk Proxy

en forma segura. Consulte la Guía de Instalación de Spacewalk Proxy para obtener mayor información.

Organización: Compañía de ejemplo

Unidad de organización [proxy1.example.com]: Nombre común: proxy1.example.com

Ciudad: Nueva York Estado: Nueva York Código de país: US

Correo-e [admin@example.com]:

8. Como resultado de la ejecución del programa de instalación del Servidor proxy RHN, el programa de instalación de línea de comandos:

Solicita la instalación del soporte de monitorización para el Servidor proxy RHN

Permite a la organización crear y poblar un canal de configuración para instalaciones seguras del Servidor de proxy RHN.

Finaliza la configuración SSL.

Reinicia los demonios del servicio que tienen configuraciones modificadas. Usted no tiene instalada la monitorización. ¿Desea instalarla? Ejecutará 'yum install spacewalk-proxy-monitoring'. [S/n]:n Confirme si desea o no instalar el soporte de Monitoring en el servidor Proxy.

(21)

Generando llave CA y certificado público: Contraseña de CA:

Confirmación de contraseña de CA:

Copiando el certificado público de CA en /var/www/html/pub para distribución a clientes:

Generando llave SSL y certificado público: Contraseña de CA:

Copia de seguridad hecha: 'rhn-ca-openssl.cnf' --> 'rhn-ca-openssl.cnf.1' Rotada: rhn-ca-openssl.cnf --> rhn-ca-openssl.cnf.1

Instalando certificado SSL para Apache y Jabberd: Preparando paquetes para instalación...

rhn-org-httpd-ssl-key-pair-proxy1.example-1.0-1

El programa configure-proxy.sh luego configura SSL, pidiéndole crear una contraseña de Autoridad certificadora y confirmarla antes de generar las llaves SSL y el certificado público.

Crear y llenar canal de configuración rhn_proxy_config_1000010000? [Y]: Utilizando nombre de servidor satserver.example.com

Nombre de usuario de Red Hat Network: admin Contraseña:

Creando canal de configuración rhn_proxy_config_1000010000 Canal de configuración rhn_proxy_config_1000010000 creado usando nombre de servidor satserver.example.com

Enviando al canal rhn_proxy_config_1000010000:

Archivo local /etc/httpd/conf.d/ssl.conf -> archivo remoto /etc/httpd/conf.d/ssl.conf

Archivo local /etc/rhn/rhn.conf -> archivo remoto /etc/rhn/rhn.conf

Archivo local /etc/rhn/cluster.ini -> archivo remoto /etc/rhn/cluster.ini Archivo local /etc/squid/squid.conf -> archivo remoto /etc/squid/squid.conf Archivo local /etc/httpd/conf.d/cobbler-proxy.conf ->archivo Archivo local /etc/httpd/conf.d/cobbler-proxy.conf

Archivo local /etc/httpd/conf.d/rhn_proxy.conf -> archivo remoto /etc/httpd/conf.d/rhn_proxy.conf

Archivo local /etc/httpd/conf.d/rhn_broker.conf -> archivo remoto /etc/httpd/conf.d/rhn_broker.conf

Archivo local /etc/httpd/conf.d/rhn_redirect.conf -> archivo remoto /etc/httpd/conf.d/rhn_redirect.conf

Archivo local /etc/jabberd/c2s.xml -> archivo remoto /etc/jabberd/c2s.xml Archivo local /etc/jabberd/sm.xml -> archivo remoto /etc/jabberd/sm.xml El instalador luego le pregunta si desea o no crear un canal de configuración basado en los archivos de configuración creados mientras ejecuta configure-proxy.sh. Después, el

instalador creará un canal de configuración de Servidor satélite de RHN basado en el nombre del cliente en el que el sServidor proxy de RHN está instalado (en el ejemplo anterior el sysID es 1000010000), y recogerá los archivos de servidor httpd, SSL, squid y jabberd que comprimirán el canal de configuración para el servidor de Proxy.

9. Por último, el instalador inicia y reinicia todos los servicios relacionados con el Servidor proxy de RHN y sale cuando termina.

(22)

Enabling Satellite Proxy Shutting down rhn-proxy...

Shutting down Jabber router: [ OK ] Stopping httpd: [ OK ] Stopping squid: [ OK ] Done.

Starting rhn-proxy...

init_cache_dir /var/spool/squid... Starting squid: . [ OK ] Starting httpd: [ OK ] Starting Jabber services [ OK ] Done.

4.2.1. El archivo Answer

Si desea automatizar algunos de los procesos de instalación del Servidor proxy de RHN en sus sistemas, el programa configure-proxy.sh permite a los administradores crear archivos de

respuestas que contienen respuestas pre-llenadas a las preguntas en el programa de instalación.

El siguiente es un ejemplo de archivo de respuestas que contiene ya las respuestas relacionadas con el número de versión, el servidor satélite de RHN que sirve como el servidor primario, SSL y otros parámetros de configuración. Para obtener más información sobre la creación y uso de archivos de respuestas, consulte la página de manual proxy.sh escribiendo man configure-proxy.sh en el intérprete de comandos.

# ejemplo de archivo de respuestas para configure-proxy.sh

# para obtener una lista completa de las opciones posibles, consulte # man configure-proxy.sh VERSION=5.2 RHN_PARENT=rhn-satellite.example.com TRACEBACK_EMAIL=jsmith@example.com USE_SSL=1 SSL_ORG="Red Hat" SSL_ORGUNIT="Spacewalk" SSL_CITY=Raleigh SSL_STATE=NC SSL_COUNTRY=US INSTALL_MONITORING=N ENABLE_SCOUT=N CA_CHAIN=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT POPULATE_CONFIG_CHANNEL=Y

Para usar un archivo de respuesta (llamado answers.txt por ejemplo) con configure-proxy.sh, escriba lo siguiente:

configure-proxy.sh --answer-file=answers.txt

(23)

Capítulo 5. Gestor de paquetes de RHN y Paquetes locales en

servicio

El Gestor de paquetes de RHN es una herramienta de línea de comandos que permite a una organización servir los paquetes locales asociados con un canal RHN privado mediante el Servidor proxy RHN. Para actualizar únicamente los paquetes oficiales de Red Hat para el Servidor proxy RHN, no instale el Gestor de paquetes de RHN.

Para usar el Gestor de paquetes de RHN, instale el paquete rhns-proxy-package-manager y sus dependencias.

Solamente la información de los encabezados para los paquetes es cargada a los servidores de RHN. Los encabezados se requieren para que RHN pueda resolver las dependencias de los paquetes para los sistemas cliente. Los archivos de paquetes completos (*.rpm) se almacenan en el Servidor proxy de RHN.

El Gestor de paquetes de RHN utiliza la misma configuración que el Proxy, tal y como se define en el archivo de configuración /etc/rhn/rhn.conf.

Un resumen de todas las opciones de línea de comandos para rhn_package_manager del Gestor de paquetes de RHN:

(24)

Tabla 5.1. Opciones de rhn_package_manager

Opciones Descripción

-v, --verbose Aumentar verbosidad.

-dDIR, --dir=DIR Procesar paquetes desde el directorio DIR.

-cCHANNEL, --channel=CHANNEL Administrar este canal — puede estar presente varias veces.

-nNUMBER, --count=NUMBER Procese este número de encabezados por llamada — por defecto son 32

-l, --list Crear una lista con el nombre del paquete, el número de versión, el número de lanzamiento y la arquitectura, del canal(es) especificado.

-s, --sync Revisar si el directorio local está sincronizado con el servidor.

-p, --printconf Imprimir la configuración actual y salir.

-XPATTERN, --exclude=PATTERN Excluir los archivos que coincidan con esta expresión global — puede estar presente varias veces.

--newest Enviar únicamente los paquetes que son más nuevos que los paquetes ya enviados al servidor para el canal

especificado.

--stdin Leer el nombre del paquete desde stdin.

--nosig Enviar canales sin firma. Por defecto, el Gestor de paquetes de RHN intenta enviar únicamente los paquetes firmados. --usernam e=USERNAME Especificar nombre de usuario de RHN. Si no lo proporciona

se le preguntará por él.

--password=PASSWORD Especificar contraseña de RHN. Si no proporciona una con esta opción, se le preguntará luego.

--source Cargar fuente de encabezados del paquete.

--dontcopy En el paso posterior a la carga, no copie los paquetes a su ubicación final en el árbol de paquetes.

--test Únicamente imprime los paquetes a ser enviados.

--no-ssl No recomendada — Desactivar SSL.

-?, --usage Describir brevemente las opciones.

--copyonly Copiar los archivos listados en el argumento en el canal especificado. Es útil cuando a un canal en el Proxy le falta un paquete y usted no desea importar de nuevo todos los paquetes en el canal. Por ejemplo,

rhn_package_m anager -cCHANNEL --copyonly /RUTA/AL/ARCHIVO/EXTRAVIADO

-h, --help Mostrar la pantalla de ayuda con una lista de las opciones.

Consejo

(25)

Para que el Gestor de paquetes de RHN pueda servir paquetes locales, realice los siguientes pasos: 1. Creación de un canal privado

2. Descargue los paquetes locales en el canal.

Los pasos se discutirán más adelante en las siguientes secciones.

5.1. Creación de un canal privado

Antes de que los paquetes locales sean proporcionados por el Servidor proxy de RHN, se necesita un canal privado para almacenarlos. Ejecute los siguientes pasos para crear una canal privado:

1. Inicie una sesión en la interfaz web de RHN en https://rhn.redhat.com.

2. Haga clic en Canales en la barra de navegación superior. Si la opción Administrar canales no está presente en la barra de navegación izquierda, asegúrese de que el usuario tiene el conjunto de permisos de edición de canal. Realice esto a través de la categoría Usuarios accesible a través de la barra de navegación superior.

3. En la barra de navegación izquierda, haga clic en Administrar canales de Software y luego en el botón crear nuevo canal en la esquina superior izquierda de la página.

4. Seleccione un canal principal y una arquitectura de canal base, luego introduzca un nombre, una etiqueta, un resumen y una descripción para el nuevo canal privado. La etiqueta del canal debe: tener al menos seis caracteres, iniciar con una letra y tener sólo letras minúsculas, dígitos, guiones (-) y puntos (.). Introduzca también la URL de la llave GPG del canal. Aunque este campo no es requerido, se recomienda para reforzar la seguridad. Para obtener instrucciones sobre cómo generar las llaves GPG, consulte la Guía de administración de canales de RHN.

5. Haga clic en Crear canal

5.2. Actualización de paquetes

Nota

Usted debe ser un Administrador de organización para cargar paquetes a canales privados de RHN. El script le preguntará su nombre de usuario y contraseña.

Después de crear el canal privado, cargue los encabezados del paquete de sus RPM binarios y códigos fuente al Servidor RHN y copie los paquetes al RHN Proxy Broker Server. Para cargar los encabezados del paquete para los RPM binarios a través de la línea de comandos, ejecute el siguiente comando:

rhn_package_manager -c "label_of_private_channel" pkg-list

Este comando cargará el encabezado del paquete al nombre del canal especificado, y el paquete a /var/spool/rhn-proxy/rhn.

pkg-list es la lista de paquetes que van a ser cargados. Asimismo puede utilizar la opción -d para

especificar el directorio local que contiene los paquetes a añadir al canal. Asegúrese de que el

directorio contenga únicamente los paquetes que va a incluir y no otros archivos. El Gestor de paquetes de RHN también puede leer la lista de paquetes desde la entrada estándar (utilizando --stdin). Para cargar los encabezados de los paquetes de los RPM de código fuente:

(26)

rhn_package_manager -c "label_of_private_channel" --source pkg-list

Si tiene más de un canal especificado (usando la opción -c o --channel), los encabezados de paquetes cargados serán enlazados a todos los canales listados.

Nota

Si no se especifica un nombre de canal, el paquete no se añade a ningún canal. Los paquetes pueden ser luego añadido a algún canal mediante la interfaz web de Red Hat Network. La interfaz también sirve para modificar canales privados existentes.

Después de cargar los paquetes, puede revisar inmediatamente la interfaz web de RHN para verificar su presencia. Haga clic en Canales en la barra de navegación superior, luego en Administrar canales de Software en la barra de navegación izquierda y posteriormente en el nombre del canal personalizado. A continuación, haga clic en la sub-pestaña Paquetes. Cada RPM debe ser listado. También puede revisar si el directorio local está sincronizado con la imagen del Servidor RHN de los canales en la línea de comandos:

rhn_package_manager -s -c "label_of_private_channel"

La opción -s listará todos los paquetes faltantes, (los paquetes cargados en el Servidor RHN, pero que no están presentes en el directorio local. Debe ser un Administrador de organización para poder utilizar esta opción. El script le pedirá el nombre de usuario y la contraseña de RHN.

Si está utilizando el Gestor de paquetes de RHN para actualizar los paquetes locales, debe ir al sitio web de RHN para suscribir el sistema al canal privado.

(27)

Capítulo 6. Mejoras de la instalación

Este capítulo describe cómo mejorar su instalación del Servidor proxy RHN. Presupone que usted está ejecutando el Servidor proxy RHN en su totalidad como también los derechos que se requieren.

6.1. Prerrequisitos

Para obtener la última versión del Servidor proxy RHN, se requiere:

Red Hat Enterprise Linux 5 (32-bit o 64-bit) o Red Hat Enterprise Linux 6 (64-bit únicamente). El borrado del perfil del sistema del Servidor de proxy de Red Hat Network Classic o el Servidor satélite padre (si aplica).

6.2. Mejorar el proceso de instalación

1. Haga una copia de seguridad de su Servidor proxy. Si es aplicable, restaure la dirección de la creación de SSL del respaldo del directorio /root/ssl-build.

2. Registre el Servidor proxy a Red Hat Network Classic o al Servidor satélite padre (Si aplica) Asegúrese de que el Servidor proxy esté suscrito tanto al Canal de base del servidor Red Hat Enterprise Linux como al canal hijo de Herramientas de Red Hat Network.

3. Instale el paquete spacewalk-proxy-installer del canal hijo de herramientas de Red Hat Network:

# yum install spacewalk-proxy-installer

4. Instale la versión más reciente de Proxy, como se documenta en Sección 4.2, “Proceso de instalación del Servidor proxy RHN.”.

Nota

Si el servidor proxy está registrado a Red Hat Network Classic y al Servidor Proxy anteriormente manejado por los canales predeterminados, necesitará restaurar el

repositorio de paquetes personalizados desde la copia de seguridad de 'pre-upgrade'. Los permisos y pertenencia también se deberán configurar correctamente.

# chmod 0750 /var/spool/rhn-proxy

# chown apache:apache /var/spool/rhn-proxy # mkdir -m 0750 -p /var/spool/rhn-proxy/list # chown apache:apache /var/spool/rhn-proxy/list

El repositorio de paquetes personal predeterminado suele ser /var/spool/rhn-proxy.

5. Después de la instalación, actualice el servidor a las últimas actualizaciones de erratas: # yum update

6. Reinicie los servicios de Servidor proxy RHN y pruebe la funcionalidad del Servidor proxy RHN: # /usr/sbin/rhn-proxy restart

(28)

Capítulo 7. Detección y resolución de problemas

Este capítulo proporciona consejos para determinar la causa y resolver los errores más comunes asociados con el Servidor proxy de RHN. Si necesita ayuda adicional, contacte el equipo de soporte de Red Hat Network en https://rhn.redhat.com/help/contact.pxt. Inicie la sesión con su cuenta de derechos de Satélite para ver la lista completa de opciones.

7.1. Administración del servicio Proxy

Puesto que el Servidor proxy de RHN está constituido por varios componentes individuales, Red Hat proporciona un script llamado rhn-proxy, que permitirá a los administradores detener, iniciar o recuperar el estado en el Proxy.

Tabla 7.1. Comandos de rhn-proxy

Comando Función

/usr/sbin/rhn-proxy start

Este comando iniciará el Servidor proxy de RHN si aún no se ha iniciado.

/usr/sbin/rhn-proxy stop Este comando detendrá el Servidor proxy RHN si aún no se ha detendido.

/usr/sbin/rhn-proxy restart

Este comando detendrá el Servidor proxy de RHN que se está ejecutando en este momento y lo reiniciará. Si el Servidor proxy de RHN está detenido, simplemente lo reiniciará.

/usr/sbin/rhn-proxy status

Este comando desplegará el estatus actual del Servidor proxy de RHN.

7.2. Archivos de registro

Virtualmente, cada paso en la detección y solución de problemas debe empezar con la revisión de los archivos de registro asociados. Estos proporcionan valiosa información sobre las actividades que se han llevado a cabo en el dispositivo o en la aplicación usada para monitorizar el rendimiento y asegurar la configuración adecuada. Consulte la Tabla 7.2, “Archivos de registro” para obtener las rutas de todos los archivos de registro asociados:

Tabla 7.2. Archivos de registro

Componentes Ubicación de los archivos de registro

Servidor Web Apache Directorio /var/log/httpd/

Squid Directorio /var/log/squid/

Servidor RHN Proxy Broker /var/log/rhn/rhn_proxy_broker.log Servidor RHN SSL Redirect /var/log/rhn/rhn_proxy_redirect.log Agente de actualización de Red

Hat

/var/log/yum .log

(29)

P: R: P: R: P: R: P: R: P: R:

Después de configurar el Gestor de paquetes de RHN, ¿cómo puedo determinar si el paquete local ha sido añadido correctamente al canal privado de RHN?

Utilice el comando rhn_package_manager -l -c "name_of_private_channel" para listar los paquetes del canal privado conocidos por los servidores de RHN. También puede utilizar la interfaz de web de RHN.

Después de suscribir un sistema registrado al canal privado, usted también puede ejecutar el comando up2date -l --showall en el sistema registrado y buscar los paquetes del canal privado de RHN.

He cambiado la configuración del nombre de DNS de mi servidor Proxy, y ahora mis sistemas cliente no pueden actualizarse, ¿cómo puedo corregir esto?

Ejecute el comando up2date -u en el sistema cliente para que el cambio de nombre se efectúe.

¿Cómo puede determinar si los clientes están conectados al servidor Squid?

Los archivos /var/log/squid/access.log registran todas las conexiones al servidor Squid.

El Agente de actualizaciones de Red Hat en el sistema cliente no se conecta con el Servidor proxy de RHN. ¿Cómo puedo corregir este error?

Asegúrese de que la última versión del Agente de actualizaciones de Red Hat esté instalada en el sistema cliente. La versión más reciente tiene funciones contiene las características necesarias para conectarse a través del Servidor proxy de RHN. Esta versión puede obtenerse a través de Red Hat Network al ejecutar el comando yum update yum como root o desde

http://www.redhat.com/support/errata/.

El Servidor proxy de RHN es una extensión de Apache. Consulte la Tabla 7.2, “Archivos de registro” para obtener la ubicación de los archivos de registro.

Mi configuración del Servidor proxy de RHN no está funcionando. ¿Dónde puedo iniciar el proceso de solución de errores?

Asegúrese de que /etc/sysconfig/rhn/systemid es propiedad del usuario root.apache y que tenga los permisos 0640.

Lea los archivos de registro. Encontrará una lista disponible en la Tabla 7.2, “Archivos de registro”.

7.4. Problemas generales

Para iniciar la detección y solución de los problemas generales, examine los archivos de registro relacionados con el componente que muestra la falla. Un ejercicio útil es ejecutar el comando tail en todos los archivos de registro y después ejecutar up2date --list. Luego podrá examinar todas las nuevas entradas de los registros para buscar pistas potenciales.

El espacio de disco lleno es un problema común. Una prueba casi irrefutable de este problema es la interrupción de la escritura en los archivos de registro. Cuando el registro se detiene durante la escritura, como en la mitad de una palabra, es muy probable que usted tenga el disco lleno. Para confirmarlo, ejecute este comando y revise el porcentaje en la columna Use%:

(30)

df -h

Además de los archivos de registro, usted puede obtener valiosa información al obtener el estado de los diferentes componentes. Esto puede realizarse para el servidor Web APACHE y Squid.

Para obtener el estado del Servidor Web APACHE ejecute el comando:

service httpd status

Para obtener el estado de Squid, ejecute el comando:

service squid status

Si el administrador no está recibiendo los correos-e del Servidor proxy de RHN, confirme la dirección de correo-e que ha sido establecida para traceback_mail en /etc/rhn/rhn.conf.

7.5. Host No Encontrado/No se pudo determinar FQDN

Ya que los archivos de configuración de RHN dependen exclusivamente de nombres de dominio completamente calificado (FDQN), es imprescindible que las aplicaciones clave puedan resolver el nombre del Servidor proxy de RHN en una dirección IP. El Agente de actualizaciones de Red Hat, el Cliente de registro de red de Red Hat y el Apache Web server son particularmente propensos a este problema con las aplicaciones de RHN que presentan errores del tipo "host no hallado" y los servidores Web que muestran "No pudo determinar el nombre de dominio completamente calificado" tras un inicio fallido.

Este problema se origina generalmente en el archivo /etc/hosts. Puede confirmarlo al examinar el archivo /etc/nsswitch.conf, el cual define los métodos y el orden bajo los cuales se resuelven los nombres de dominios. Por lo general, el archivo /etc/hosts es el primero en ser revisado, seguido por el Servicio de información de red (NIS) si se está usando, seguido por DNS. Uno de estos debe servir para que el Servidor Web de APACHE inicie y para que las aplicaciones cliente de RHN funcionen. Para resolver este problema, identifique el contenido de el archivo /etc/hosts. Debe ser similar a:

127.0.0.1 this_machine.example.com this_machine localhost.localdomain \ localhost

En un editor de textos, elimine la información de host de la máquina. Se deberá ver así:

127.0.0.1 localhost.localdomain.com localhost

Guarde el archivo y vuelva a ejecutar las aplicaciones cliente de RHN o el Servidor Web APACHE. Si fallan, identifique explícitamente la dirección IP del Proxy en el archivo, por ejemplo:

127.0.0.1 localhost.localdomain.com localhost 123.45.67.8 this_machine.example.com this_machine

Remplace aquí el valor con la dirección IP real del Proxy. Esto debería resolver el problema. Recuerde, Capítulo 7. Detección y resolución de problemas

(31)

7.6. Errores de conexión

Si está experimentando problemas que puedan estar relacionados con la conexión, siga los pasos siguientes:

Confirme que el paquete correcto:

rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm

está instalado en el Servidor proxy de RHN y el rhn-org-trusted-ssl-cert-*.noarch.rpm correspondiente o certificado crudo CA SSL público (cliente) está instalado en todos los sistemas cliente.

Verifique que los sistemas cliente están configurados para utilizar el certificado apropiado. Si está utilizando uno o más Servidores proxy de RHN, verifique si cada certificado SSL del Proxy está preparado correctamente. Si está utilizando el Servidor proxy de RHN junto con un Servidor satélite de RHN, el proxy debe tener tanto su propio par de llaves SSL como el certificado CA SSL público (cliente) instalados, ya que tendrá ambas funciones. Consulte el capítulo sobre certificados SSL en la Guía de configuración de sistemas cliente de RHN para obtener instrucciones específicas. Si el Servidor proxy de RHN se está conectando a través de un Proxy HTTP, asegúrese de que la URL listada sea válida. Por ejemplo, el campo URL del Proxy HTTP no debe contener referencias al protocolo, http:// o https://. Sólo el nombre de host y el puerto deben ser incluidos en la forma hostname:port, tal como your-gateway.example.com:8080.

Asegúrese de que los sistemas cliente no estén usando cortafuegos por su cuenta que estén bloqueando los puertos requeridos, como se señala en la Sección 2.4, “Requerimientos adicionales”.

7.7. Problemas relacionados con cache

Si una entrega de paquetes falla o un objeto parece incompleto, y el problema no está relacionado con errores de conexión, debería considerar la limpieza de la cache. El Servidor proxy de RHN tiene dos cache importantes en estos casos: uno para Squid y el otro para autenticación.

La cache Squid se localiza en /var/spool/squid/. Para eliminarla: 1. Detenga el Servidor Web Apache: service httpd stop 2. Detenga el servidor Squid: service squid stop

3. Borre el contenido de ese directorio: rm -fv /var/cache/rhn/* 4. Reinicie los dos servicios:

service squid start service httpd start

La misma tarea puede realizarse con solo limpiar el directorio y reiniciar Squid, pero este método probablemente resultará en un número de mensajes de rastreo de RHN.

El mecanismo de cache interno usado para autenticación por el Proxy podría también necesitar limpieza. Para hacerlo, ejecute el siguiente comando:

rm -fv /var/cache/rhn/*

Aunque el Demonio de autenticación de RHN se descontinuó en el lanzamiento del Servidor proxy de RHN -3.2.2 y se remplazó por el mecanismo de cache de autenticación interna, el demonio podría estar

(32)

aún ejecutándose en su Proxy. Para apagarlo, ejecute los siguientes comandos en el siguiente orden:

chkconfig --level 2345 rhn_auth_cache off service rhn_auth_cache stop

Para limpiar cache, ejecute:

rm /var/up2date/rhn_auth_cache

Si debe conservar el Demonio de autenticación de RHN, lo cual no es recomendable ni tiene soporte de Red Hat, observe que su rendimiento puede sufrir de registros verbosos. Por esta razón, su registro (a /var/log/rhn/rhn_auth_cache.log) está, por defecto, apagado. Si usted ejecuta el demonio y desea registro, puede activarlo al añadir la siguiente línea al archivo /etc/rhn/rhn.conf del Proxy:

auth_cache.debug = 2

7.8. Depuración del Proxy por Red Hat

Si ya ha realizado todos los pasos para solucionar el problema o si desea diferirlos a profesionales de Red Hat Network, Red Hat recomienda que usted aproveche el soporte integral que viene con el Servidor proxy de RHN.

Una forma de acceder a esa experiencia es a través de la Base de conocimientos de Red Hat , la cual proporciona las soluciones para la mayoría de los problemas encontrados por usuarios y tiene una interfaz sólida y navegador para buscar respuestas a los problemas de su Proxy. Acceda a la Base de conocimientos de Red Hat en http://kbase.redhat.com.

Además, Red Hat proporciona una herramienta de línea de comandos llamada SoS Report, conocida por su comando sosreport. Dicha herramienta recolecta sus parámetros de configuración de Proxy, archivos de registro e información de base de datos y los envía directamente a Red Hat.

Para usar esta herramienta de información del Servidor satélite de RHN debe tener ya instalado el paquete sos. Escriba sosreport -o rhn como root en el servidor Satélite para crear un informe. Por ejemplo:

[root@satserver ~]# sosreport -o rhn sosreport (version 1.7)

This utility will collect some detailed information about the hardware and setup of your Red Hat Enterprise Linux system. The information is collected and an archive is packaged under /tmp, which you can send to a support representative.

Red Hat will use this information for diagnostic purposes ONLY and it will be considered confidential information.

This process may take a while to complete. No changes will be made to your system. Press ENTER to continue, or CTRL-C to quit.

(33)
(34)

Ejemplo del archivo de configuración del Servidor proxy de

RHN

El archivo de configuración /etc/rhn/rhn.conf para el Servidor proxy de RHN proporciona un medio para que los administradores establezcan parámetros claves. Tenga en cuenta, sin embargo, que los errores introducidos en este archivo pueden causar fallos en el Proxy. Realice los cambios de

configuración con cuidado.

Si usted está usando también un Servidor satélite de RHN, debe tener particular cuidado con los siguientes parámetros: traceback_mail y proxy.rhn_parent. Revise el ejemplo y sus comentarios (los cuales inician con #), para una mayor información.

Nota

Usted puede añadir el parámetro use_ssl a rhn.conf para prueba únicamente. Establezca el valor a 0 para apagar temporalmente SSL entre el Proxy y el servidor del nivel superior. Observe que esta acción compromete en gran medida la seguridad. Establezca el parámetro a su valor predeterminado (1) para reactivar SSL, o simplemente remueva la línea del archivo de

configuración.

# Automatically generated RHN Management Proxy Server configuration file. # ---# SSL CA certificate location

proxy.ca_chain = /usr/share/rhn/RHNS-CA-CERT

# Corporate HTTP proxy, format: corp_gateway.example.com:8080 proxy.http_proxy =

# Password for that corporate HTTP proxy proxy.http_proxy_password =

# Username for that corporate HTTP proxy proxy.http_proxy_username =

# Location of locally built, custom packages proxy.pkg_dir = /var/spool/rhn-proxy

# Hostname of RHN Server or RHN Satellite proxy.rhn_parent = rhn.redhat.com

# Destination of all tracebacks, etc.

traceback_mail = user0@domain.com, user1@domain.com

(35)

Historial de revisiones

Revisión 3-5.2.4 00 2013-10-31 Rüdiger Landmann

Rebuild with publican 4.0.0

Revisión 3-5.2 Mon Apr 22 2013 Gladys Guerrero-Lozano

Revisión completa

Revisión 3-5.1 Thu Mar 21 2013 Gladys Guerrero-Lozano

Los archivos de traducción sincronizados con fuentes XML 3-5

Revisión 3-5 Wed Sept 19 2012 Dan Macpherson

Empaquetamiento final para 5.5

Revisión 3-4 Wed Jul 4 2012 Athene Chan

Preparado para lanzamiento de 5.5

Se incorporaron modificaciones de la revisión técnica

BZ#491007Se añadió capítulo sobre mejoras de instalación

Revisión 3-0 Wed Jul 4 2012 Athene Chan

Preparado para lanzamiento de 5.5

Se incorporaron modificaciones de la revisión técnica

BZ#491007Se añadió capítulo sobre mejoras de instalación

Revisión 2-5 Thu Jan 5 2012 Lana Brindley

BZ#682996 - Capítulo de instalación - Actualizar instrucciones BZ#705755 - Capítulo Gestor de paquetes - Información adicional BZ#722193 - Capítulo de requerimientos - Error corregido

BZ#729617 - Capítulo de instalacción - Error corregido BZ#729663 - Capítulo de instalación - Amonestación añadida

Revisión 2-4 Mon Aug 15 2011 Lana Brindley

Lanzamiento de z-stream incorporado en y-stream

Revisión 2-3 Wed Jun 22 2011 Lana Brindley

BZ#713527 - Se añadieron referencias de RHEL 6

Revisión 2-2 Wed Jun 15 2011 Lana Brindley

Preparado para traducción

Revisión 2-1 Fri May 27 2011 Lana Brindley

Actualizaciones de traductores

Revisión 2-0 Fri May 6 2011 Lana Brindley

Preparado para traducción

Revisión 1-9 Wed April 27 2011 Lana Brindley

(36)

Revisión 1-8 Mon Feb 7 2011 Lana Brindley Instalación -BZ#646176

Índice

A

Administrador de canal, Terminologías utilizadas frecuentemente

Administrador de organización, Terminologías utilizadas frecuentemente

Administrador de paquetes RHN

- opciones de línea de comandos, Gestor de paquetes de RHN y Paquetes locales en servicio

Agente de actualización de Red Hat, Terminologías utilizadas frecuentemente, Forma como funciona proxy

Almacenamiento de autenticación

- limpieza, Problemas relacionados con cache

Almacenar problemas en cache, Problemas relacionados con cache

Almacenar squid en cache, Problemas relacionados con cache

archivos de registro, Archivos de registro

Autenticación, Forma como funciona proxy

C

Canal, Terminologías utilizadas frecuentemente

- crear un canal privado, Creación de un canal privado

Canal privado, Creación de un canal privado

Cómo funciona el proxy, Forma como funciona proxy

Configuración de clientes

- suscribir a canal privado, Actualización de paquetes

D

Demonio de autenticación de RHN, desactivando

- rhn_auth_cache, deteniendo, Problemas relacionados con cache

Depuración de satellite, Depuración del Proxy por Red Hat

Detección y resolución de problemas, Detección y resolución de problemas

(37)

G

Gestor de paquetes de RHN, Forma como funciona proxy

- archivo de configuración, Gestor de paquetes de RHN y Paquetes locales en servicio

- canales, especificación, Actualización de paquetes

- cargar encabezados de paquetes, Actualización de paquetes

- configuración, Creación de un canal privado

- crear canal privado, Creación de un canal privado

- instalación, Gestor de paquetes de RHN y Paquetes locales en servicio

- verificar lista de paquetes locales, Actualización de paquetes

Gestor de paquetes RHN, Gestor de paquetes de RHN y Paquetes locales en servicio

H

HTTP Proxy Caching Server

- requerimientos de espacio de disco, Requerimientos de espacio de disco

I

Instalación

- base, Instalación de base

- del Servidor proxy de RHN, Proceso de instalación del Servidor proxy RHN.

N

No se encontró error de host

- no se pudo determinar FQDN, Host No Encontrado/No se pudo determinar FQDN

P

Preguntas y respuestas, Preguntas y respuestas

Problemas generales, Problemas generales

Puerto

- 443, Requerimientos adicionales

- 5222, Requerimientos adicionales

- 80, Requerimientos adicionales

Puerto 4 4 3, Requerimientos adicionales

Puerto 4 54 5, Requerimientos adicionales

Puerto 80, Requerimientos adicionales

Puertos de entrada, satellite

- 5222, Requerimientos adicionales

Puertos de salida

Referencias

Documento similar

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

Esto viene a corroborar el hecho de que perviva aún hoy en el leonés occidental este diptongo, apesardel gran empuje sufrido porparte de /ue/ que empezó a desplazar a /uo/ a

[r]

SVP, EXECUTIVE CREATIVE DIRECTOR JACK MORTON

Social Media, Email Marketing, Workflows, Smart CTA’s, Video Marketing. Blog, Social Media, SEO, SEM, Mobile Marketing,

Missing estimates for total domestic participant spend were estimated using a similar approach of that used to calculate missing international estimates, with average shares applied

We have created this abstract to give non-members access to the country and city rankings — by number of meetings in 2014 and by estimated total number of participants in 2014 —