T2786 90052 Hpux Errores

Guía del usuario de Distributed Systems
Administration Utilities
Edición 1.0
N° de referencia: T2786-90052
©Copyright 2006 Hewlett-Packard Company.
Aviso legal
Software informático confidencial. Se precisa una licencia válida de HP en
relación con la posesión, la utilización o la copia del mencionado software.
De acuerdo con la normativa FAR 12.211 y 12.212, se concede al Gobierno
de EE. UU. la licencia del Software Informático Comercial, de la
Documentación sobre el Software Informático y de los Datos Técnicos
relativos a Artículos Comerciales conforme a los términos de la licencia
comercial estándar del proveedor.
La información que recoge este documento está sujeta a cambios sin
previo aviso. Las únicas garantías existentes para los productos y los
servicios de HP son las expuestas en las declaraciones de garantía
expresa que acompañan a dichos productos y servicios. Ninguna parte de
este documento debe interpretarse como constituyente de garantía
adicional alguna. HP no será responsable de los errores o las omisiones de
carácter técnico o editorial que pueda contener este documento.
Avisos de marcas comerciales

HP-UX revisión 10.20, y posteriores, y HP-UX revisión 11.00, y
posteriores, (configuraciones de 32 y 64 bits) de todos los equipos HP 9000
son productos de la marca Open Group UNIX 95.
UNIX es una marca registrada de The Open Group.
Java es una marca comercial en Estados Unidos de Sun Microsystems,
Inc.
Intel e Itanium son marcas comerciales o marcas registradas de Intel
Corporation o de sus filiales en Estados Unidos y otros países.
Microsoft y Windows son marcas registradas en EE. UU. de Microsoft
Corporation.
2
Contenido
1. Introducción
Comandos de Distributed Systems Administration Utilities . . . . . . . . . . . . . . . . . . . . 14
Componentes de código fuente abierto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Páginas de manual de Distributed Systems Administration Utilities . . . . . . . . . . . . . 17
2. Sincronización de la configuración
Descripción general de cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Demonios y comandos de cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Modelos de distribución del servidor maestro de cfengine . . . . . . . . . . . . . . . . . . . . . . 26
Configuración de cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Utilización del asistente de sincronización de la configuración (Configuration
Synchronization Wizard) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Configuración manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Notas sobre la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Intercambio de claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Uso del puerto de red csync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Alertas de suma de comprobación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Deshabilitación del uso de cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Opciones de registro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Solución de problemas de cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3. Registro consolidado
Introducción a syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Formato de los mensajes de syslog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Filtrado de mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Descripción general de la consolidación de archivos de registro . . . . . . . . . . . . . . . . . . 73
Consolidación de archivos de registro mejorada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Coexistencia con syslog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Configuración de la consolidación de archivos de registro. . . . . . . . . . . . . . . . . . . . . . . 79
Utilización del asistente de consolidación de archivos de registro
(Log Consolidation Wizard) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Configuración manual de la consolidación de archivos de registro . . . . . . . . . . . . . . 97
3
Contenido
Deshabilitación de la consolidación de archivos de registro . . . . . . . . . . . . . . . . . . . . 128

Deshabilitación de un sistema de consolidación de archivos de registro autónomo 128
Deshabilitación de un sistema de consolidación de archivos de registro de
un clúster Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Deshabilitación de un cliente de reenvío de archivos de registro autónomo . . . . . . 130
Deshabilitación de un cliente de reenvío de archivos de registro de un clúster
Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Seguridad de los archivos de registro consolidados . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Medidas de protección de los archivos de registro . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Reenvío a través de un puerto ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Uso del puerto de red de clog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Utilización de Bastille para fortalecer el sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Consulta de los archivos de registro consolidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Inicio de System Management Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Utilización del System Log Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4. Cargabilidad de salida de comandos

Parallel Distributed Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Empaquetadores de utilidades para pdsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Configuración de la seguridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Solución de problemas de cargabilidad de salida de comandos (Command Fanout) . 149
Índice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4
Tablas
Tabla 1. Convenciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Tabla 2. Historial de publicación de DSAU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Tabla 1-1. Comando de la sincronización de la configuración . . . . . . . . . . . . . . . . . . .14
Tabla 1-2. Comandos del registro consolidado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Tabla 1-3. Comandos de la cargabilidad de salida de comandos . . . . . . . . . . . . . . . . .14
Tabla 1-4. Comando de la configuración de utilidades. . . . . . . . . . . . . . . . . . . . . . . . .15
Tabla 1-5. Comandos cfengine de código fuente abierto. . . . . . . . . . . . . . . . . . . . . . . .16
Tabla 1-6. Comandos pdsh de código fuente abierto . . . . . . . . . . . . . . . . . . . . . . . . . .16
Tabla 1-7. Comando syslog-ng de código fuente abierto. . . . . . . . . . . . . . . . . . . . . . . .16
Tabla 1-8. Secciones de las páginas de manual de DSAU . . . . . . . . . . . . . . . . . . . . . .17
Tabla 2-1. Datos de configuración para csync_wizard . . . . . . . . . . . . . . . . . . . . . . . . .28
Tabla 3-1. Niveles de prioridad de syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Tabla 3-2. Mensajes de dispositivo de syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Tabla 3-3. Datos de configuración del asistente clog_wizard. . . . . . . . . . . . . . . . . . . .80
5
Figuras
Figura 2-1. Descripción general de cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Figura 3-1. Configuración del reenvío de archivos de registro de syslog-ng . . . . . . . .76
Figura 3-2. Configuración del consolidador de archivos de registro de syslog-ng . . .78
Figura 4-1. Arquitectura de la herramienta pdsh . . . . . . . . . . . . . . . . . . . . . . . . . . .144
6
Acerca de este documento
Distributed Systems Administration Utilities aporta herramientas que
sirven para simplificar la administración de grupos de sistemas y
clústeres Serviceguard. Este documento facilita información sobre cada
una de las herramientas componentes en capítulos independientes.
Público destinatario
Este documento se ha elaborado para los administradores de sistemas a
fin de ayudarles con el aprendizaje del conjunto de herramientas
Distributed Systems Administration Utilities y con su uso.
Convenciones tipográficas
Tabla 1 Convenciones
Título de libro El título de un libro o de otro documento.
comando El nombre de un comando o una expresión de comandos calificada.
entrada del Comandos y otro tipo de texto que escribe el usuario.

usuario
salida del equipo Texto que muestra el equipo.
Entrar El nombre de una tecla del teclado. Tenga en cuenta que Retorno y
Entrar hacen referencia a la misma tecla. Una secuencia como Ctrl+A
indica que se debe mantener presionada la tecla con la etiqueta Ctrl
al mismo tiempo que se presiona la tecla A.
variable El nombre de una variable de entorno, por ejemplo, PATH o errno.
valor Valor que se sustituye en un comando o una función, o información

de una pantalla que representa varios valores posibles.
find(1) Página de manual de HP-UX. En este ejemplo, “find” es la página de

manual y “1” es la sección de la página de manual.
7
Información conexa
Los siguientes documentos también resultan útiles para ampliar los
conocimientos sobre Distributed Systems Administration Utilities
(DSAU).
• Las páginas de manual de DSAU

• La ayuda en línea de la interface gráfica de usuario de DSAU
• Las notas de la revisión de DSAU
Historial de publicación
Tabla 2 Historial de publicación de DSAU
Versión de Fecha de
Nº de referencia Edición
DSAU publicación
T2786-90052 1.2 1.0 Septiembre de 2006
Para obtener las versiones específicas de HP-UX y Serviceguard, y el

número de kit de DSAU, consulte el documento Distributed Systems
Administration Utilities V1.2 Release Notes for HP-UX 11i v2
September 2006.
8
Soporte técnico del producto
Para obtener soporte técnico del producto, póngase en contacto con el
representante del soporte técnico de HP, el representante de los servicios
de HP o el revendedor autorizado de HP. Para obtener más información
sobre los servicios de soporte técnico, visite la dirección
http://welcome.hp.com/country/es/es/support.html.
HP fomenta el envío de comentarios

HP fomenta el envío de comentarios respecto a este documento. Tenemos
el auténtico empeño de proporcionar una documentación que satisfaga
sus necesidades. Envíe sus comentarios a:
http://docs.hp.com/es/feedback.html
Le rogamos que incluya la siguiente información:
• El título del documento (Guía del usuario de Distributed Systems

Administration Utilities)
• El número de referencia (T2786-90052)
• Cualquier comentario, error detectado o sugerencia de mejora que
pueda tener en relación con este documento.
9
10
1 Introducción
Distributed Systems Administration Utilities aporta varias herramientas

que sirven para simplificar la administración de los grupos de sistemas y
los clústeres Serviceguard.
Consta de tres utilidades:
• Configuration Synchronization (Sincronización de la configuración):
con esta utilidad, que se basa en la herramienta de código abierto
cfengine [abreviatura en inglés de “configuration engine”, (motor de
configuración)], el administrador puede definir centralmente las
acciones administrativas que han de aplicarse en un conjunto de
sistemas administrados. cfengine es una herramienta basada en
cliente/servidor. El sistema maestro de configuración central alberga
el archivo de descripción de la configuración que define las acciones
administrativas que han de efectuarse en cada cliente administrado.
El maestro de configuración también alberga los archivos de “imagen
dorada”, que son copias maestras de los archivos que se distribuyen a
los clientes. El administrador puede utilizar cfengine para llevar a
cabo tareas como, por ejemplo:
— Garantizar que los sistemas cliente utilizan un conjunto correcto
de archivos de configuración
— Deshabilitar archivos configurados de forma inapropiada en el
cliente
— Comprobar los permisos de acceso a los archivos y la titularidad,
y realizar un seguimiento de los cambios de la suma de
comprobación
— Efectuar modificaciones en los archivos
— Ejecutar comandos de shell arbitrarios en cada cliente
— Buscar procesos, procesos de señal
Se facilita un Configuration Synchronization Wizard (asistente de
sincronización de la configuración) para ayudar al administrador
a configurar rápidamente cfengine a fin de administrar un
conjunto de sistemas distribuidos o de configurarlo como un
servicio de alta disponibilidad en un clúster Serviceguard.
Este asistente se describe en el capítulo 2, “Sincronización de la
configuración” en la página 19 de este manual. Para obtener
información adicional, consulte las páginas de manual de
cfengine y csync_wizard.
Capítulo 1 11
Introducción
• Consolidated Logging (Registro consolidado): actualmente, el

comando UNIX syslogd estándar ofrece reenvío de archivos de
registro según el protocolo UDP a un consolidador de archivos de
registro central. Las utilidades DSAU proporcionan la herramienta
de código abierto syslog-ng o “syslog next-generation” (syslog de
próxima generación). syslog-ng ofrece características adicionales
que la convierten en una herramienta eficaz para el reenvío de
archivos de registro y la centralización y consolidación de archivos de
registro.
El Configuration Synchronization Wizard (asistente de configuración
de la sincronización) contribuye a configurar syslog-ng en un
servidor de consolidación de archivos de registro y en clientes de
reenvío de archivos de registro. La consolidación de archivos de
registro centralizada presenta las siguientes ventajas:
— Análisis de archivos de registro más fácil
Un archivo de registro centralizado proporciona una sola
ubicación para que el administrador efectúe el análisis de los
archivos de registro. Presenta una sola vista de los sucesos que
repercuten en varios sistemas.
Las utilidades DSAU se han diseñado específicamente para
optimizar este método a fin de administrar un clúster
Serviceguard. Los archivos syslog y los archivos de registro de
paquetes de los miembros se pueden centralizar para simplificar
el acceso a los archivos de registro y su análisis. Las utilidades
DSAU también posibilitan que el clúster ofrezca un servicio de
registro consolidado de alta disponibilidad.
— Mayor seguridad
Una infracción de la seguridad podría afectar a los archivos de
registro locales pero no a la copia centralizada.
— Archivo de archivos de registro simplificado
En general, es más sencillo archivar un conjunto de archivos de
registro centralizados que los archivos de registro de cada
sistema.
Este asistente se describe en el capítulo 3, “Registro consolidado”
en la página 69 de este manual. Para obtener información
adicional, consulte las páginas de manual de clog_wizard y
syslog-ng.
12 Capítulo 1
Introducción
• Command fanout (Cargabilidad de salida de comandos) se basa en la

herramienta de código abierto Parallel Distributed Shell (pdsh). pdsh
permite al administrador ejecutar comandos de shell en paralelo en
un conjunto de sistemas. Puede utilizar remsh o ssh como programas
de transporte en la red. La herramienta csshsetup se facilita para
simplificar la distribución de las claves ssh. La utilidad
complementaria Parallel Distributed Copy (pdcp) permite efectuar
copias de archivos y directorios en paralelo en un conjunto de sistemas
remotos. El filtro dshbak permite dar formato a la salida de varios
sistemas y consolidarla para mejorar la presentación en pantalla.
Las herramientas cexec, ccp, ckill, cps y cuptime son
empaquetadores en torno a los comandos pdsh y pdcp, optimizados
para utilizarlos en un clúster Serviceguard. Dichas herramientas
adoptan por defecto la ejecución de comandos en todo el clúster. Estos
empaquetadores hacen lo siguiente:
— cexec: Como pdsh, pero con características adicionales de
generación de informes y reintento
— ccp: Copia archivos en todo el clúster
— ckill: Termina el proceso nombrado en todo el clúster o en los
sistemas especificados
— cps: Ejecuta un comando ps en todo el clúster o en los sistemas
especificados
— cuptime: Ejecuta el comando uptime en todo el clúster
Estos comandos también se pueden utilizar fuera de un clúster, pero
como en el caso de pdsh y pdcp, el usuario debe especificar una lista
de sistemas host de destino. El comando cexec funciona como pdsh y
agrega capacidades de generación de informes. Los informes
guardados se pueden utilizar para volver a ejecutar comandos
anteriores y ceñirse sólo a los sistemas donde el comando haya dado
error en un principio o donde se haya ejecutado con éxito en un
principio, o ambos. La cargabilidad de salida de comandos se describe
más detalladamente en el capítulo 4, “Cargabilidad de salida de
comandos” en la página 141 de este manual.
La siguiente sección describe los comandos proporcionados con cada
componente DSAU.
Capítulo 1 13
Introducción
Comandos de Distributed Systems Administration Utilities
Comandos de Distributed Systems

Tabla 1-1 Comando de la sincronización de la configuración
Comando Función Uso
csync_wizard Ayuda a configurar el entorno Al configurar el maestro de

cfengine. configuración.
Tabla 1-2 Comandos del registro consolidado
clog Muestra archivos de registro. Para examinar archivos de registro.
clog_wizard Ayuda a configurar los servidores Al configurar la consolidación de

y clientes de consolidación de archivos de registro.
archivos de registro.
Tabla 1-3 Comandos de la cargabilidad de salida de comandos
ccp Copia archivos en varios sistemas Para realizar la sincronización a

host en paralelo. En un clúster solicitud de archivos en un conjunto
Serviceguard, copia archivos en de sistemas o en un clúster
todo el clúster. Serviceguard.
cexec Ejecuta comandos en varios Para ejecutar un comando de shell

sistemas host en paralelo. En un no interactivo en un conjunto de
clúster Serviceguard, ejecuta el sistemas o clúster. Para consolidar
comando en todo el clúster. una salida idéntica, canalizar la
salida a dshbak -c.
ckill Distribuye un comando kill a Para enviar una señal a un proceso

varios sistemas host en paralelo. nombrado a través de varios
En un clúster Serviceguard, sistemas o un clúster.
ejecuta por defecto el comando en
todo el clúster.
14 Capítulo 1
Introducción
Comandos de Distributed Systems Administration Utilities
Tabla 1-3 Comandos de la cargabilidad de salida de comandos
cps Distribuye un comando ps(1) a Para recopilar simultáneamente

varios sistemas host en paralelo. información sobre el proceso
En un clúster Serviceguard, procedente de grupos de sistemas.
todo el clúster.
cuptime Notifica información de uptime(1) Para comprobar las medias de

en relación con varios sistemas. En tiempo de actividad, usuarios y
un clúster Serviceguard, ejecuta carga.
por defecto el comando en todo el
clúster.
cwall Muestra un mensaje de difusión de Para difundir un mensaje a todos
wall(1M) en varios sistemas host. los usuarios conectados en un grupo
En un clúster Serviceguard, de sistemas.
todo el clúster.
Tabla 1-4 Comando de la configuración de utilidades
csshsetup Para el usuario actual, ejecuta una Para simplificar en gran medida la
distribución de claves públicas distribución de claves ssh. pdsh y los
mediante el programa secure shell comandos de cargabilidad de salida
(ssh) a varios sistemas. de comandos (relacionados con cexec)
cuentan todos con una distribución de
claves ssh correcta El asistente
csync_wizard necesita que ssh
tenga acceso a los clientes
administrados. Por ejemplo, en un
clúster Serviceguard, esto permite
que ssh tenga acceso desde cualquier
miembro a cualquier otro miembro, de
modo que pdsh y cexec se puedan
utilizar desde cualquier miembro del
clúster.
Capítulo 1 15
Introducción
Componentes de código fuente abierto
Componentes de código fuente abierto

Los componentes de código fuente abierto y sus comandos se describen en
la siguiente tabla. Estos componentes de código fuente abierto que utiliza
el conjunto de utilidades DSAU se basan en el lenguaje cfengine de alto
nivel. Para obtener información adicional sobre cfengine, consulte la
página de manual de cfengine; para obtener los comandos individuales,
consulte las páginas manuales respectivas y la documentación de código
fuente abierto ubicada en /opt/dsau/doc.
Tabla 1-5 Comandos cfengine de código fuente abierto
Comando Función
cfagent Agente de configuración del sistema que lleva a cabo las acciones de
configuración definidas en un archivo de directivas de configuración.
cfexecd Servicio de programación y notificación. Es un componente adicional.
cfkey Herramienta de generación de claves de seguridad. cfkey se ejecuta una
vez en cada sistema host para crear un par de claves pública/privada.
cfrun Herramienta para activar un cfagent remoto.
cfservd Servidor de archivos y servicio de activación remoto.
Tabla 1-6 Comandos pdsh de código fuente abierto
Comando Función
dshbak Da formato a la salida de los comandos pdsh; consolida una salida idéntica
de varios sistemas host.
pdcp Herramienta para efectuar copias de archivos y directorios en paralelo a
un conjunto de sistemas remotos.
pdsh Herramienta para ejecutar comandos de shell en paralelo en un conjunto
de sistemas.
Tabla 1-7 Comando syslog-ng de código fuente abierto
Comando Función
syslog-ng Herramienta que realiza un registro consolidado.
16 Capítulo 1
Introducción
Páginas de manual de Distributed Systems Administration Utilities
Páginas de manual de Distributed Systems

Además de las páginas de manual de código fuente abierto (páginas man)
para los componentes de código fuente abierto de DSAU, el conjunto de
utilidades DSAU también proporciona las siguientes páginas de manual:
Tabla 1-8 Secciones de las páginas de manual de DSAU
Página de
Sección
manual
ccp 1
cexec 1
ckill 1
clog 1m
clog_wizard 1m
cps 1
csshsetup 1
csync_wizard 1m
cuptime 1
cwall 1m
Capítulo 1 17
Introducción
Páginas de manual de Distributed Systems Administration Utilities
18 Capítulo 1
2 Sincronización de la
configuración
Administrar la configuración y la deriva de configuración de un conjunto
de sistemas distribuidos es un reto constante para los administradores de
sistemas. Se dispone de una variedad de herramientas para ayudar a
manejar diversos aspectos de la administración de la configuración
multisistema. Por ejemplo, para la administración de cuentas, las
soluciones estándar abarcan el sistema NIS (Network Information
System) y el protocolo LDAP (Lightweight Directory Access Protocol -
Protocolo ligero de acceso a directorios). Para la sincronización a nivel de
archivos, se dispone de herramientas como rdist (consulte la página de
manual de rdist (1)) y rsync. HP Systems Insight Manager ayuda a
detectar, supervisar y administrar grupos de sistemas.
Una herramienta nueva de este kit de herramientas es Configuration
Engine (cfengine). cfengine es una popular herramienta de código
abierto para la sincronización de la configuración. Posibilita la
administración de la configuración basada en directivas o basada en
metas que permite al administrador definir las acciones de
administración que han de aplicarse a los grupos de sistemas para que
dichos sistemas alcancen un estado deseado.
cfengine es una herramienta basada en cliente/servidor. Un sistema
maestro de configuración central o servidor de directivas alberga un
archivo de directivas de configuración que define las acciones
administrativas que han de efectuarse en cada cliente administrado.
El maestro de configuración también alberga los archivos de “imagen
dorada” o las copias de referencia que deben distribuirse a los clientes.
El administrador puede utilizar cfengine para llevar a cabo tareas como,
por ejemplo:
• Asegurarse de que los sistemas cliente utilizan un conjunto correcto

de archivos de configuración copiando archivos o directorios de
referencia.
• Deshabilitar archivos configurados de forma inapropiada en el cliente.
• Comprobar los permisos de acceso a los archivos y la titularidad, y
realizar un seguimiento de los cambios de la suma de comprobación.
• Modificar los archivos.
• Ejecutar comandos de shell especificados en cada cliente.
• Buscar procesos o procesos de señal.
• Buscar montajes de sistemas de archivos específicos.
Capítulo 2 19
Sincronización de la configuración
Se facilita un asistente de sincronización de la configuración

(Configuration Synchronization Wizard, csync_wizard) para ayudar al
administrador a configurar rápidamente cfengine a fin de administrar
un conjunto de sistemas distribuidos o de configurarlo como un servicio de
alta disponibilidad en un clúster Serviceguard.
20 Capítulo 2
Descripción general de cfengine

El administrador empieza por definir un sistema o clúster Serviceguard
central para que haga de servidor maestro de configuración o de servidor
de directivas. El asistente de sincronización de la configuración
(Configuration Synchronization Wizard, csync_wizard) es un servidor de
solicitudes de cliente fácil de utilizar con el proceso de configuración
inicial. Este sistema central albergará los archivos de directivas maestros
(por ejemplo, cfagent.conf), que definen las directivas de configuración
deseadas, y también copias de referencia o copias maestras de archivos
que deben distribuirse a los clientes administrados.
Cada cliente administrado copia las copias maestras de los archivos de
directivas desde el servidor central de configuración y evalúa su estado
actual en comparación con el estado deseado definido por el archivo de
directivas. Las diferencias existentes hacen que se ejecuten las normas de
configuración para volver a sincronizar el cliente.
El administrador puede iniciar operaciones de sincronización en los
clientes administrados de dos formas: mediante una operación de
inserción (push) o de extracción (pull).
• Utilizando el comando cfrun (consulte la página de manual de cfrun
(1) para obtener más información) desde el servidor de configuración
maestro, el administrador puede insertar cambios. cfrun lee el
archivo cfrun.hosts para determinar la lista de clientes
administrados. A continuación, llama al comando cfagent en cada
cliente administrado para efectuar una ejecución de sincronización.
Por tanto, las operaciones de inserción (push) en realidad son
solicitudes dirigidas a los clientes administrados para realizar una
extracción (pull) inmediata.
• Las operaciones de extracción (pull) se realizan utilizando el demonio
cron o el propio demonio de cfengine parecido a cron: cfexecd.
Cualquiera de las dos técnicas llama al comando cfagent a intervalos
fijos para efectuar una sincronización de la configuración iniciada por
un cliente. El administrador define qué intervalo es apropiado para
cada grupo de clientes administrados. Por ejemplo, cada cinco
minutos, una vez a la hora o una vez al día. El administrador también
puede llamar directamente a cfagent para realizar ejecuciones de
sincronización a solicitud.
Capítulo 2 21
Demonios y comandos de cfengine

cfengine emplea varios demonios y comandos para efectuar operaciones
de sincronización de la configuración. En la siguiente lista, se describen
los componentes de cfengine primarios.
• cfagent: El comando cfagent es el caballo de tiro de cfengine. Se

ejecuta en cada cliente administrado y realiza una secuencia de
arranque en sí mismo utilizando el archivo update.conf, que
describe el conjunto de archivos para transferir del servidor maestro
al cliente administrado local. Los archivos transferidos incluyen el
archivo de directivas principal, cfagent.conf, y los archivos de
directivas conexos. En la implementación DSAU, cfagent.conf
importa el archivo cf.main, el cual contiene ejemplos de muchas
características de cfengine.
Después de transferir los archivos de configuración, cfagent evalúa
las instrucciones de configuración de dichos archivos. Si la
configuración actual del sistema cliente se desvía de la configuración
deseada, cfagent ejecuta las acciones definidas para devolver el
cliente al estado correcto.
• cfservd: El demonio cfservd tiene dos funciones:
— cfservd se ejecuta en el servidor de configuración maestro y es la

cámara de compensación para las solicitudes de transferencia de
archivos procedentes de los clientes administrados. cfagent se
pone en contacto en los clientes administrados con el demonio
cfservd del servidor maestro y solicita copias de los archivos de
directivas maestros, y copias de todo archivo de referencia que sea
necesario, formando parte de las operaciones de sincronización de
configuración definidas. El demonio cfservd maestro es
responsable de autenticar los clientes remotos utilizando un
mecanismo de intercambio de claves pública/privada y de cifrar
opcionalmente los archivos que se transfieran a los clientes
administrados.
— cfservd se puede ejecutar opcionalmente en cada cliente
administrado para procesar las solicitudes de cfrun. cfrun permite
al administrador insertar cambios en los clientes administrados
en lugar de esperar a que los clientes sincronicen mediante algún
intervalo de tiempo definido por el cliente. El comando cfrun debe
iniciarse desde el servidor de configuración maestro. Dicho
comando se pone en contacto con cada cliente administrado
22 Capítulo 2
enumerado en los archivos cfrun.hosts y conecta con el demonio

cfservd del cliente administrado pidiéndole que llame a cfagent
para llevar a cabo el trabajo de sincronización.
cfservd se configura utilizando cfservd.conf y se inicia
utilizando /sbin/init.d/cfservd.
• cfexecd: cfexecd es una herramienta de programación y generación
de informes. Si el administrador utiliza el demonio cron para realizar
ejecuciones de sincronización a intervalos fijos, cfexecd es el comando
que se ubica en el archivo crontab para empaquetar la llamada de
cfagent. cfexecd almacena la salida de la ejecución de cfagent en el
directorio de salidas (consulte el archivo cfagent.conf para obtener
detalles) y, opcionalmente, envía un correo electrónico.
cfexecd tiene sus propias características parecidas al demonio cron
que se basan en las clases de tiempo de cfengine. El administrador
puede optar por ejecutar cfexecd en modo demonio y utilizarlo para
llamar al comando cfagent a intervalos definidos en lugar de cron. El
valor por defecto es llamar a cfagent cada hora. HP recomienda
agregar una entrada para cfexecd en el archivo crontab para la
configuración inicial.
• cfrun: El comando cfrun se pone en contacto con los clientes
administrados pidiéndole a cada uno de ellos que realice una
ejecución de sincronización inmediata. Específicamente, conecta con
el demonio cfservd opcional en cada cliente administrado que, a su
vez, inicia cfagent.
La figura 2-1, “Descripción general de cfengine”, ilustra la relación de los
comandos y demonios de cfengine, y muestra un ejemplo del
administrador utilizando cfrun. Las líneas punteadas del diagrama
indican las secuencias de llamada (por ejemplo, A llama a B). Las líneas
continuas indican que los datos se están leyendo desde los archivos de
configuración.
Capítulo 2 23
Figura 2-1 Descripción general de cfengine
1. El administrador inicia una sesión en el servidor maestro de

sincronización de la configuración y efectúa un cambio para que se
difunda a los clientes administrados, utilizando el comando cfrun.
cfrun comprueba el archivo cfrun.hosts para ver la lista de clientes
administrados. Tenga en cuenta que el servidor maestro puede ser un
cliente de sí mismo. En este diagrama, hay dos clientes, el servidor
maestro y un cliente remoto.
2. cfrun se pone en contacto con cfservd en cada cliente administrado,
que a su vez llama a cfagent.
3. cfagent comprueba primero el servidor maestro para obtener una
copia actualizada del archivo update.conf y la transfiere al cliente,
si procede.
4. Si el servidor maestro es un sistema autónomo, la copia maestra de
update.conf se ubica por defecto en
/var/opt/dsau/cfengine_master/inputs/. Las copias maestras de
otros archivos de configuración, por ejemplo, cfagent.conf,
cfservd.conf, cf.main y cfrun.hosts, también se ubican allí. Si el
servidor maestro es un clúster Serviceguard, los archivos de
configuración maestros se ubican en el punto de montaje asociado al
paquete. Por ejemplo, si dicho punto de montaje se llamara csync, la
ruta sería /csync/dsau/cfengine_master/inputs.
24 Capítulo 2
5. Al copiar los archivos de configuración en el sistema local, cfagent los

coloca en /var/opt/dsau/cfengine/inputs tanto para sistemas
autónomos como para clústeres. cfagent evalúa primero el contenido
de update.conf para actualizar los archivos binarios de cfengine
modificados (si los hubiere) y obtiene la versión más reciente de los
archivos de directivas (cfagent.conf y los archivos conexos).
cfagent evalúa, a continuación, cfagent.conf para determinar si el
cliente está en el estado deseado. Si hay deltas, cfagent lleva a cabo
las acciones definidas para corregir la configuración del cliente.
Capítulo 2 25
Modelos de distribución del servidor maestro de cfengine
Modelos de distribución del servidor maestro

de cfengine
El servidor maestro de cfengine puede ser un sistema HP-UX autónomo
que preste servicio a grupos de clientes distribuidos. Los propios clientes
pueden ser sistemas autónomos o miembros de un clúster Serviceguard.
Si ya utiliza un servidor de administración central Systems Insight
Manager , éste puede ser un sistema ideal para utilizar como un servidor
maestro de cfengine. Los servidores maestros también pueden hacer de
clientes y las tareas de sincronización de la configuración se pueden llevar
a cabo en dichos sistemas, así como en los clientes remotos.
Si administra clústeres Serviceguard, cfengine se puede distribuir única
y exclusivamente para uso intraclúster a fin de sincronizar los miembros
de un solo clúster. En esta configuración, cfservd se configura como un
paquete para alta disponibilidad, pero los únicos clientes de cfengine son
los propios miembros del clúster. El nombre DNS/dirección IP del paquete
es el nombre para el servidor maestro de cfengine.
Además de ofrecer la sincronización de la configuración como un servicio
intraclúster, otra configuración Serviceguard tiene el clúster que ofrece el
servicio de sincronización de la configuración de alta disponibilidad a los
grupos de los sistemas cliente remotos. Dichos clientes pueden ser
sistemas autónomos o clústeres Serviceguard. El clúster que ofrece el
servicio de cfengine puede ser un cliente de sí mismo y, además, puede
sacar partido de las características de sincronización de la configuración
de cfengine.
Una configuración posible, aunque algo desacostumbrada, consiste en
hacer que un miembro fijo del clúster Serviceguard haga de servidor
maestro y en que no se configure ningún paquete, de modo que cfservd no
presente alta disponibilidad. Esta configuración es válida, pero no es
recomendable.
26 Capítulo 2
Configuración de cfengine
En las siguientes secciones se facilitan instrucciones detalladas para
configurar un servidor maestro de sincronización de la configuración y los
clientes del mismo. La forma más rápida de empezar consiste en utilizar
el asistente de sincronización de la configuración (Configuration
Synchronization Wizard, csync_wizard), que se describe en la siguiente
sección. También se describen configuraciones completamente manuales.
Utilización del asistente de sincronización de la

configuración (Configuration Synchronization
Wizard)
El asistente csync_wizard (consulte la página de manual de
csync_wizard (1)) automatiza la tarea de definir un servidor maestro de
sincronización de la configuración y sus clientes administrados. Permite
configurar como el servidor maestro un sistema autónomo o un clúster
Serviceguard. El asistente configura todos los clientes administrados
para ejecutar un demonio cfservd de forma que cfrun (consulte la
página de manual de cfrun (8)) se pueda utilizar en el servidor maestro.
Con el asistente csync_wizard, se llevan a cabo las siguientes tareas:
• Configurar un servidor maestro
• Agregar un cliente
• Quitar un cliente
• Administrar claves para los clientes cfengine
• Mostrar la configuración actual
Para obtener detalles, consulte las secciones apropiadas. La tabla 2-1
enumera la información que tendrá que recopilar antes de ejecutar el
asistente csync_wizard para configurar el servidor maestro.
Al ejecutar el asistente en un clúster Serviceguard, por defecto se
configura cfengine como un servicio de alta disponibilidad (paquete
Serviceguard). El administrador debe proporcionar el entorno de
almacenamiento para el paquete y la dirección IP de paquete y registro de
nombres DNS pertinentes. El asistente admite las configuraciones de
almacenamiento LVM. Las configuraciones que no sean LVM deben
completarse manualmente. La información sobre el paquete que el
asistente necesita se facilita en la tabla 2-1.
Capítulo 2 27
Tabla 2-1 Datos de configuración para csync_wizard
Datos de configuración Ejemplo Su valor
Grupo de volúmenes LVM /dev/vgcsync
Volumen lógico /dev/vcgsync/lvol1
Punto de montaje de sistema de archivos /csync
Opciones de montaje -o rw,largefiles
Tipo de sistema de archivos vxfs
Dirección IP de paquete (un nombre DNS 192.10.25.12

registrado)
Subred del paquete 192.10.25.0
NOTA Si ha utilizado previamente el asistente para configurar un servidor

maestro cfengine y lo ha vuelto a ejecutar para reconfigurar el servidor
maestro, detenga primero la configuración que se ejecute actualmente.
Por ejemplo, utilice el siguiente comando para detener el demonio cfservd
en ejecución: /sbin/init.d/cfservd stop
Si tiene cfagent en cron o utiliza cfexed, deshabilítelos para que no se
ejecuten mientras el asistente reconfigura el sistema.
La configuración de un solo nodo en un clúster Serviceguard como un

servidor maestro no es una configuración de alta disponibilidad y no se
recomienda. La configuración por defecto para crear un clúster consiste en
crear un paquete para el demonio cfservd de cfengine. (Para volver a
ejecutar el asistente en un clúster Serviceguard y cambiar la
configuración de una que sea de alta disponibilidad a otra que no lo sea,
detenga el paquete csync existente (utilice cmhaltpkg) y elimínelo antes
de ejecutar el asistente.)
Utilización del asistente para configurar un servidor de

sincronización autónomo
Para configurar un servidor de sincronización para un sistema autónomo,
ejecute el asistente csync_wizard(1) en el sistema autónomo que desee
configurar como el servidor de sincronización maestro:
28 Capítulo 2
# /opt/dsau/sbin/csync_wizard
El asistente presenta la siguiente pantalla preliminar:
Querying the system nombre_host_local for current status, one moment...
This Configuration Synchronization Wizard (csync_wizard) helps you set

up the Configuration Engine (cfengine) environment. Cfengine is a powerful
tool for performing policy-based management for groups of systems and
cluster environments.
csync_wizard is a client/server based utility. With csync_wizard, the

user can configure a standalone system or Serviceguard cluster as the
cfengine “master”. The master contains the configuration description and
configuration files that will be used by all the clients. Clients copy the
configuration description from the master and apply it to themselves.
The configuration description supports a rich set of management actions
such as copying configuration files from the master to the client,
performing edits to files, checking file ownerships, permissions, and
checksums, executing shell commands, checking for processes, etc.
For a detailed description of the cfengine management actions,

please refer to the cfengine man page.
The csync wizard helps you set up this system as a cfengine master,
add or remove cfengine-managed clients, and perform the required
security setup.
Press “Enter” to continue...

Presione la tecla Entrar para continuar; elija el elemento 1 en el siguiente
menú para configurar un servidor maestro:
Configuration Synchronization Wizard Menu
=========================================
(1) Set up a cfengine master server
(2) Add a client
(3) Remove a client
(4) Manage keys for cfengine clients
(5) Display current configuration
(9) Exit
Enter choice: 1
Capítulo 2 29
The cfengine master server is being configured on:
nombre_host_local
A continuación, el asistente le pregunta si también desea configurar los
clientes administrados inmediatamente después de configurar el servidor.
En este ejemplo, la respuesta es negativa. Los clientes administrados se
agregarán posteriormente.
You can optionally specify additional remote clients to manage at this
time. If you are running in an HA environment, you do not need to specify the
cluster members.
Would you like to manage clients? [N]: n

El asistente pasa a configurar el sistema como un servidor maestro:
******* WARNING!!!! ********
To protect against possible corruption of sensitive configuration files,

control-c has been disabled for the remainder of this configuration.
Configuration of the cfengine master server is starting.
Configuration files have been saved at /var/opt/dsau/cfengine/backups
cfengine keys are being created...
cfengine keys have been created, now distributing....
Verifying that the master has an entry in the /etc/hosts file

on each client...
Starting cfengine on the master server and any managed clients. This may
take a few minutes....
Cuando se completa la configuración, el asistente muestra las siguientes
pantallas de resumen que remiten al administrador al archivo de
directivas principal,
/var/opt/dsau/cfengine_master/inputs/cf.main, y al archivo de
respuestas grabadas para esta ejecución del asistente.
The Configuration Synchronization Wizard has completed the
configuration of cfengine:
- The master configuration description template is here:
</csync/dsau/cfengine_master/inputs/cf.main>
This default template has examples of typical configuration

synchronization actions performed in a cluster. For example
30 Capítulo 2
synchronizing critical files such as /etc/hosts, package

scripts, etc.
All the actions in the template are disabled by default

(commented out). Uncomment the lines corresponding to the desired
synchronization actions for the cluster. See the cfengine
reference documentation for a description of additional cfengine
features: /opt/dsau/doc/cfengine/
The cfengine environment consists of:
Master server (policy host):
nombre_host_local
Managed clients:
Tenga en cuenta que al configurar un servidor maestro sin agregar
ningún cliente administrado durante la configuración del servidor, la
entrada de los miembros [la lista de clientes administrados (Managed
clients)] está vacía, tal como se muestra en el ejemplo anterior.
A file containing the answers for this run of the Configuration
Synchronization Wizard is stored here...
/var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
This configuration can be reestablished by issuing the following command:
/opt/dsau/sbin/csync_wizard \
-f /var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
Utilización del asistente para configurar un servidor de

sincronización de un clúster Serviceguard
Para configurar un servidor de sincronización para un clúster
Serviceguard, existen dos opciones de configuración:
• Crear un paquete Serviceguard para que el servicio de configuración

asegure la alta disponibilidad.
• Configurar un solo miembro del clúster como si fuera un sistema
autónomo. El servicio de sincronización de la configuración no tendrá
alta disponibilidad y esta configuración tampoco funcionará
correctamente con las características de automatización Serviceguard
analizadas en la sección “Características de automatización
Serviceguard” en la página 38 y no se recomienda.
Capítulo 2 31
Esta sección se centra en el uso del asistente para configurar un servicio

de sincronización de la configuración de alta disponibilidad.
NOTA Antes de iniciar el asistente, todos los miembros actuales del clúster
deben estar instalados y en funcionamiento en el clúster. Asegúrese de
que el valor MAX_CONFIGURED_PACKAGES de este clúster puede
albergar el paquete adicional. Para obtener más información sobre este
valor, consulte el manual Managing Serviceguard, que forma parte del
juego de documentación de Serviceguard.
Empiece por ejecutar el asistente de sincronización de la configuración

(Configuration Synchronization Wizard), csync_wizard (1), ejecutando el
siguiente comando:
# /opt/dsau/sbin/csync_wizard
Querying the system nombre_host_local for current status, one moment...
This Configuration Synchronization Wizard (csync_wizard) helps you set

up the Configuration Engine (cfengine) environment. Cfengine is a powerful
tool used to perform policy-based management for groups of systems and
cluster environments.
csync_wizard is a client/server based utility. With csync_wizard, the

user can configure a standalone system or Serviceguard cluster as the
cfengine “master”. The master contains the configuration description and
configuration files that will be used by all the clients. Clients copy the
configuration description from the master and apply it to themselves.
The configuration description supports a rich set of management actions
such as copying configuration files from the master to the client,
performing edits to files, checking file ownerships, permissions, and
checksums, executing shell commands, checking for processes, etc.
For a detailed description of the cfengine management actions,

please refer to the cfengine man page.
The csync_wizard helps you set up this system as a cfengine master,

add or remove cfengine-managed clients, and perform the required
security setup.

Presione la tecla Entrar para continuar y elija el elemento 1 en el
siguiente menú para configurar un servidor maestro:
=========================================
32 Capítulo 2
(2) Add a client
(3) Remove a client
(9) Exit
Enter choice: 1
Después de elegir 1 y de presionar la tecla Entrar, el asistente muestra el
siguiente texto:
This system is a member of a Serviceguard cluster. The cfengine
configuration will be defined as a package for high availability
unless you answer no to the question below. If you answer no, for the
purposes of cfengine control, this machine will be treated as a single
machine without failover capability for cfengine.
If you accept the default answer of ‘HA’ to the question below,

cfengine will be configured as a highly available Serviceguard package.
This ensures that your cfengine master server is available as long
as one of the cluster members that can run the package is also available.
You will need a free IP address for this package and you must
configure storage for the package before proceeding. For details
on creating highly available file systems, please refer to the
Managing Serviceguard manual.
Will this master server be Highly Available (HA) [Y]:

El asistente nombra el nombre de paquete “csync” para la sincronización
de configuración. Se necesita el nombre de este paquete específico. La
configuración del almacenamiento LVM y la configuración de red para el
paquete deben prepararse antes de continuar o antes de ejecutar el
asistente. Todos los miembros del clúster también deben estar instalados
y disponibles. Para obtener detalles, consulte el manual Managing
Serviceguard (capítulo “Building an HA Cluster Configuration”, sección
“Creating a Storage Infrastructure with LVM”).
Capítulo 2 33
NOTA El asistente sólo permite crear paquetes en función de los grupos de

volúmenes LVM. Cuando se utiliza el sistema de archivos CFS o VxVM, es
necesaria la configuración manual. Para obtener detalles sobre la
configuración manual del paquete csync, consulte la sección
“Configuración manual de un servidor de sincronización de un clúster
Serviceguard” en la página 48.
El asistente pide lo siguiente, todo lo cual ya debe estar configurado:

• El nombre del grupo de volúmenes LVM (por ejemplo, /dev/vgcsync)
• El volumen lógico del grupo de volúmenes: debe ser el nombre de ruta
completo del volumen lógico (por ejemplo, /dev/vgcsync/lvol1)
• El punto de montaje del sistema de archivos (por ejemplo, /csync)
• Las opciones de montaje del sistema de archivos (por ejemplo, -o
rw,largefiles). Las opciones de montaje se utilizan al pie de la letra
en el campo FS_MOUNT_OPT[0] de la secuencia de comandos de
control del paquete Service. Tenga en cuenta que las opciones de
montaje deben coincidir con el sistema de archivos creado en el
volumen lógico. Por ejemplo, si el sistema de archivos se creó con
soporte para archivos grandes, la opción de montaje “largefiles” debe
especificarse.
• El tipo de sistema de archivos (por ejemplo, vxfs)
• La dirección IP del paquete. Esta dirección también debe ser un
nombre DNS registrado para que la sincronización de la configuración
sea fácil de configurar en los sistemas cliente.
• La subred del paquete. (Utilice netstat -i para determinar la
subred correcta.)
Después de configurar la infraestructura de almacenamiento y de obtener
la dirección IP, presione la tecla Retorno para obtener acceso a la
respuesta por defecto de “yes” y continúe con la creación del paquete.
El asistente pide a continuación la información sobre el paquete:
Configuring the csync Serviceguard package for a
highly available cfengine master.
The cfengine master server is being configured as a

HA Serviceguard Package on this cluster.
Please provide the following information for the package:
34 Capítulo 2
Enter the Volume group [/dev/vgcsync]:
Enter the Logical Volume [/dev/vgcsync/lvol1]:
Enter the Filesystem (Mount Point) [/csync]:
Enter the Mount Options [-o rw, largefiles]:
Enter the Filesystem Type [vxfs]:
Enter the IP address [192.10.25.12]:
Enter the Subnet [192.10.25.0]:

El asistente le pregunta, a continuación, si desea administrar clientes
remotos adicionales, es decir, sistemas ubicados fuera del clúster. El
asistente configura automáticamente los miembros actuales del clúster.
Éste es el motivo por el que todos los miembros deben estar activos y
accesibles cuando se ejecuta el asistente. En el ejemplo mostrado a
continuación, el administrador elige “no” para que, en un principio, sólo se
configuren como clientes miembros del clúster.
Tenga en cuenta que se pueden agregar fácilmente clientes remotos
adicionales con posterioridad utilizando el asistente. Al agregar miembros
al clúster, no es preciso ejecutar el asistente para especificar los miembros
nuevos como sistemas cliente nuevos. Dichos miembros se configuran
automáticamente para participar en la configuración de cfengine actual.
Para obtener detalles, consulte la sección “Características de
automatización Serviceguard” en la página 38.
You can optionally specify additional remote clients to manage at this
time. If you are running in an HA environment, you do not need to
specify the cluster members.
Would you like to manage clients? [N]:

El asistente ya tiene todos los datos que necesita para configurar el
clúster y así pasa a hacerlo:
******* WARNING!!!! ********

Configuring the “csync” Serviceguard package.
Applying the “csync” Serviceguard package configuration file.

This will take a moment.
Capítulo 2 35
Starting the “csync” Serviceguard package. This will take a few moments...
The “csync” Serviceguard package has been started on nombre_host_local.
Configuration of the cfengine master server is starting.
Configuration files have been saved at:

/var/opt/dsau/cfengine/backups
Verifying that the master has an entry in the /etc/hosts file

on each client...
Starting cfengine on the master server and any managed clients.

This may take a few minutes....
Cuando se completa la configuración, el asistente muestra las siguientes
pantallas de resumen que remiten al administrador al archivo de
directivas principal,
/punto_montaje/cfengine_master/inputs/cf.main, y al archivo de
respuestas grabadas para esta ejecución del asistente. Tenga en cuenta
que el archivo de directivas se ubica en el sistema de archivos recién
configurado que está asociado al paquete. En nuestro ejemplo, el
administrador opta por montar el sistema de archivos para el paquete
como /csync.
Si el administrador hubiera configurado previamente cfengine, antes de
sobrescribir ningún archivo de configuración existente, el asistente habría
creado copias de seguridad en el directorio:
/var/opt/dsau/cfengine/backups
Los archivos de nivel superior de este directorio son los archivos de copia
de seguridad más recientes. Las configuraciones anteriores se guardan en
los subdirectorios con marca de hora denominados v_marcadehora.
The Configuration Synchronization Wizard has completed the
configuration of cfengine:
- The master configuration description template is here:
</csync/dsau/cfengine_master/inputs/cf.main>
This default template has examples of typical configuration

synchronization actions performed in a cluster. Por ejemplo:
synchronizing critical files such as /etc/hosts and Serviceguard package
36 Capítulo 2
scripts.
All the actions in the template are disabled by default

(commented out).
Uncomment the lines corresponding to the desired
synchronization actions for this cluster. See the cfengine
reference documentation for a description of additional cfengine
features: /opt/dsau/doc/cfengine/
The cfengine environment consists of:

Master server (policy host): nombre_de_host_del_paquete
Master clients:
miembro_clúster_1, miembro_clúster_2, ...
A file containing the answers for this run of the Configuration

Synchronization Wizard is stored here:
/var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
This configuration can be reestablished by issuing the following command:
/opt/dsau/sbin/csync_wizard \
-f /var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
Notas sobre la configuración del clúster

En esta sección, se describen los detalles de una configuración de alta
disponibilidad de cfengine en un clúster Serviceguard. Para obtener más
información sobre la función de los diversos demonios y comandos de
cfengine, consulte la sección “Demonios y comandos de cfengine” en la
página 22. El paquete Serviceguard asegura que el demonio cfservd de
cfengine sigue presentando alta disponibilidad. Los archivos de
configuración update.conf y cfagent.conf de cfengine definen el
servidor maestro de sincronización de la configuración para que sea el
nombre DNS registrado para la dirección IP reubicable del paquete.
Cuando los clientes administrados ejecutan cfagent (consulte la página
de manual de cfagent (8)), cfagent se conecta al demonio cfservd en el
nodo adoptivo del paquete. Por tanto, los propios miembros del clúster son
todos clientes administrados. El miembro que alberga el paquete hace,
además, de servidor maestro para los archivos de directivas.
Capítulo 2 37
Cuando se inicia el clúster, cada miembro inicia un demonio cfservd

cliente. Éste es el demonio cfservd que contesta a las peticiones de
cfrun. Cuando el paquete se inicia en un miembro, ese demonio cfservd
tiene acceso al sistema de archivos del paquete y se convierte en el
demonio cfservd maestro que entrega los archivos de directivas a todos
los clientes administrados. El paquete supervisa dicho demonio cfservd.
Si cfservd da error, el paquete tratará de reiniciarse en otro miembro. El
demonio cfservd de dicho miembro se convertirá, a continuación, en el
cfservd maestro.
Tenga en cuenta que detener el paquete no implica detener el demonio
cfservd en el miembro adoptivo, puesto que la expectativa es que el
demonio esté presente para contestar a futuras peticiones de cfrun.
Asimismo, a diferencia de otros servicios de alta disponibilidad (HA -
High Availability), si el paquete csync no está activo o no está disponible,
no hay ningún impacto negativo en los clientes remotos. Los clientes
siguen ejecutando las configuraciones que tengan definidas actualmente.
El administrador tendría que asegurarse de que el paquete está instalado
y en funcionamiento para distribuir cualquier instrucción de
configuración nueva a los clientes administrados.
El asistente automatiza la distribución de claves de cfengine entre todos
los miembros del clúster. Para obtener una descripción detallada de los
pasos dados en relación con la distribución de claves, consulte la sección
“Notas sobre la seguridad” en la página 61.
Características de automatización Serviceguard

Las herramientas Distributed Systems Administration Utilities
necesitan Serviceguard 11.17 o posterior. Con Serviceguard 11.17 o
posterior, cuando se agregan o eliminan miembros en el clúster, las
herramientas de sincronización de la configuración adoptan
automáticamente las acciones de configuración apropiadas. De forma
específica:
• Al agregar un miembro al clúster, el miembro nuevo se configura

automáticamente para participar en la sincronización de la
configuración. Las siguientes acciones de configuración se producen
automáticamente en el miembro agregado:
1. /etc/rc.config.d/cfservd se cambia para definir

CSYNC_CONFIGURED en 1
38 Capítulo 2
2. Las claves pública/privada apropiadas de cfengine se crean para

el miembro nuevo y se ubican en el directorio
/var/opt/dsau/cfengine/ppkeys del miembro. Las claves
nuevas para este miembro también se distribuyen entre los
directorios /var/opt/dsau/cfengine/ppkeys de los demás
miembros del clúster.
3. El directorio /var/opt/dsau/cfengine/inputs del miembro
nuevo se ocupa.
4. cfservd se inicia en el miembro nuevo.
5. Los archivos del paquete se copian en /etc/cmcluster/csync/,
en el miembro nuevo.
6. Se efectúa una ejecución de sincronización cfagent en el maestro
para ocupar el directorio /var/opt/dsau/cfengine/inputs del
maestro.
7. Se realiza una ejecución de sincronización cfagent en el miembro
recién agregado.
Tenga en cuenta que si se produce algún error al realizar estas
acciones automáticas, los mensajes se colocan en syslog, en el
servidor maestro. Utilice cmviewcl -p csync para determinar qué
miembro es actualmente el servidor maestro. También, si el clúster
utiliza el registro consolidado, compruebe si hay mensajes en el
archivo syslog consolidado.
• Al eliminar un miembro en un clúster, la clave pública del miembro
eliminado se elimina del directorio
/var/opt/dsau/cfengine/ppkeys en todo el clúster.
• El administrador puede definir grupos o clases de cfengine que
enumeren todos los miembros de un clúster Serviceguard concreto.
Estas definiciones de clase no se actualizan automáticamente y el
administrador debe actualizar manualmente el archivo
cfagent.conf y los archivos conexos en relación con los cambios de
pertenencia al clúster.
Capítulo 2 39
NOTA Al agregar miembros en un clúster, considere los siguientes aspectos:

• Al agregar un miembro en un clúster que esté configurado como un
servidor maestro de alta disponibilidad, el paquete csync debe estar
en ejecución. La tarea de procesamiento de adición del miembro copia
los datos de configuración desde el sistema de archivos montado del
paquete en los directorios /var/opt/dsau/cfengine del nuevo
miembro. Si el paquete no está en ejecución, el sistema de archivos no
estará accesible y el nuevo miembro no se configurará correctamente.
En este caso, el administrador puede configurar manualmente el
nuevo miembro como sigue:
1. Asegúrese de que el paquete csync está en ejecución. En caso

negativo, inícielo.
2. Inicie una sesión en el miembro que ejecuta el paquete.
3. Ejecute el siguiente comando exactamente tal como se muestra:
/opt/dsau/bin/csync_dispatcher MEMBER_ADDED:
nombre_host_miembro
Por ejemplo, si el nombre de host incompleto del nuevo miembro

es hostnuevo, utilice el siguiente comando:
/opt/dsau/bin/csync_dispatcher MEMBER_ADDED: hostnuevo
• Al agregar un miembro en un clúster que esté configurado como un
servidor maestro de alta disponibilidad, la clave de seguridad de
cfengine del nuevo miembro se distribuye en todo el clúster. Esto
permite al nuevo miembro funcionar como un nodo adoptivo. Si el
paquete csync realiza una conmutación por error con el nuevo
miembro, éste manejará correctamente las solicitudes cfagent
procedentes de todos los clientes administrados.
No obstante, un comando cfrun ejecutado desde el nuevo miembro
dará error al ponerse en contacto con los clientes administrados. Para
que cfrun funcione correctamente, cada cliente administrado debe
tener una copia de la clave de cada miembro del clúster. (Esto se
diferencia de cfagent en el cliente administrado, que sólo necesita la
clave que corresponda a la dirección IP del paquete csync.)
Para que el nuevo miembro emita solicitudes cfrun, su clave debe
crearse manualmente en cada cliente administrado. Hay dos formas
de distribuir la clave:
40 Capítulo 2
— Utilice la función “Manage keys for cfengine clients” del asistente

csync_wizard que regenera las claves de todos los sistemas.
Todos los clientes administrados deben estar accesibles para que
se complete la regeneración.
— Copie las claves de los miembros existentes en el nuevo miembro.
Este planteamiento aprovecha el hecho de que la clave del nuevo
miembro es idéntica a las claves de los demás miembros del
clúster. En el cliente administrado, cualquiera de las claves de los
miembros del clúster existentes se puede copiar en el nombre
correcto para el miembro recién agregado.
Por ejemplo:
# cd /var/opt/dsau/cfengine/ppkeys
# cp root-dirección_IP_miembro_existente.pub \
root-dirección_IP_miembro_nuevo.pub
Utilización del asistente para configurar un cliente de

sincronización
El asistente de sincronización de la configuración (Configuration
Synchronization Wizard) se puede utilizar para agregar clientes
administrados a una configuración de cfengine existente. Ejecute el
asistente en el servidor maestro, no en el sistema cliente. Cuando un
clúster Serviceguard sea el servidor maestro, ejecute el asistente en el
nodo adoptivo para el paquete csync. Tenga en cuenta que cuando un
clúster Serviceguard se ha configurado como un servidor maestro de alta
disponibilidad, la adición de miembros nuevos en el clúster no requiere el
uso del asistente para configurar esos miembros nuevos. Se configurarán
automáticamente. Para obtener más información, consulte la sección
“Características de automatización Serviceguard” en la página 38.
Si el cliente no es miembro del clúster, para distribuir las claves cfengine
sin riesgo, el cliente debe configurarse para el acceso ssh no interactivo
por parte de la cuenta de usuario root del servidor maestro. La
herramienta csshsetup (consulte la página de manual de csshsetup(1))
simplifica la configuración del acceso ssh a un sistema remoto. Esta
herramienta se utiliza en los siguientes ejemplos.
Tenga en cuenta que un clúster Serviceguard remoto se puede configurar
como un cliente administrado. No obstante, cada miembro debe
configurarse individualmente. Repita las tareas de configuración
descritas más adelante para cada miembro del clúster.
Capítulo 2 41
Empiece por iniciar una sesión como usuario root en el servidor maestro y
configurar el acceso ssh al sistema remoto:
# csshsetup nombre_de_host_del_cliente_administrado
csshsetup prueba en primer lugar el acceso ssh al sistema remoto. Si la
herramienta no está configurada, ssh pide la contraseña del cliente
administrado.
Ejecute el asistente de sincronización de la configuración (Configuration
Synchronization Wizard) y elija la opción 2 para agregar un cliente nuevo:
=========================================
(2) Add a client
(3) Remove a client
(9) Exit
Enter choice: 2
Cuando se lo pida el sistema, escriba el nombre del cliente para agregar:
This option will configure additional clients to the cfengine domain.
Enter the name of the client to add: cliente_nuevo

El asistente pasa, a continuación, a configurar el cliente y a informar del
avance:
Verifying that the master has an entry in the /etc/hosts file on each client...

The client cliente_nuevo has been added to the cfengine domain
El asistente configura cada cliente nuevo para ejecutar cfservd de forma
que pueda contestar a las peticiones de cfrun y agrega el cliente en el
archivo cfrun.hosts del maestro.
42 Capítulo 2
Configuración manual
En las siguientes secciones se describen los pasos necesarios para
configurar manualmente los servidores maestros de sincronización de la
configuración o los clientes administrados de cfengine. Tenga en cuenta
que, en general, es más fácil empezar por utilizar el asistente
csync_wizard (consulte la página de manual de csync_wizard (1m)) y,
luego, modificar la configuración resultante que empezar desde cero. Esto
es particularmente cierto en un clúster Serviceguard, en cuyo caso el
asistente ayuda a configurar el paquete y se ocupa de difundir los archivos
de configuración correctos a todos los miembros del clúster.
Cuando se efectúan configuraciones manuales, es posible crear
configuraciones que posteriormente el asistente csync_wizard no pueda
administrar. A continuación, se presentan dos ejemplos:
• El asistente necesita que todos los clientes administrados tengan ssh

configurado de modo que las claves de seguridad de cfengine se
puedan distribuir al principio o cambiarse posteriormente.
• El asistente coloca todos los clientes administrados en el archivo
cfrun.hosts. Esta lista de clientes administrados se utiliza para
identificar los sistemas para operacioens como, por ejemplo, la
regeneración de claves de cfengine en todos los equipos. cfrun.hosts
es un archivo de configuración de cfengine opcional que el comando
cfrun utiliza. Las configuraciones manuales no tienen que utilizar
este archivo, pero el asistente sí lo necesita.
NOTA Puede utilizar csshsetup para configurar una relación de confianza entre
el servidor maestro y los clientes administrados. Esto le permitirá utilizar
los comandos de cargabilidad de salida de comandos (command fanout),
por ejemplo, cexec y ccp (consulte las páginas de manual de cexec (1) y ccp
(1)). El uso de dichos comandos puede simplificar los pasos de
configuración descritos más adelante cuando hay que distribuir archivos
entre los clientes administrados.
Configuración manual de un servidor de sincronización

autónomo
Dé los siguientes pasos puntuales para configurar un sistema autónomo
como un servidor maestro de cfengine:
Capítulo 2 43
1. Empiece por crear las copias maestras de los archivos de

configuración de cfengine. Estos archivos se ubican en un directorio
conocido y se distribuyen a cada cliente administrado. El directorio
por defecto es /var/opt/dsau/cfengine_master/inputs, al que se
alude en las plantillas por defecto. Empiece por crear el directorio:
# mkdir -p /var/opt/dsau/cfengine_master/inputs
2. Copie los archivos de las plantillas por defecto en los siguientes
directorios:
# cd /var/opt/dsau/cfengine_master/inputs
# cp /opt/dsau/share/cfengine/templates/cf.main.template cf.main
# cp /opt/dsau/share/cfengine/templates/update.conf.template update.conf
# cp /opt/dsau/share/cfengine/templates/cfagent.conf.template cfagent.conf
# cp /opt/dsau/share/cfengine/templates/cfrun.hosts.template cfrun.hosts
# cp /opt/dsau/share/cfengine/templates/cfservd.conf.template cfservd.conf
3. A continuación, modifique update.conf. Este archivo presenta un
formato parecido al archivo de configuración principal de cfengine:
cfagent.conf. Se utiliza para transferir y actualizar los archivos
binarios y los archivos de definiciones de configuración actualizados
(por ejemplo, cfagent.conf) de cfengine para los clientes
administrados. Reviste importancia crítica hacer que este archivo se
mantenga muy sencillo y evitar cometer errores. Los errores de este
archivo requerirán que se copie manualmente una versión nueva en
cada cliente administrado.
El archivo contiene signos con la forma de <%nombre del signo%>
que el asistente csync_wizard sustituye por las respuestas del
administrador a las preguntas. Sustituya los signos como sigue:
a. Sustituya el signo <%POLICYHOST_NAME%> por el nombre de

dominio completo del servidor maestro. Tenga en cuenta que
reviste importancia crítica que este nombre de dominio sea
completo. Este archivo se copia y evalúa en los clientes
administrados. Si un cliente administrado está en un dominio
DNS diferente del servidor maestro, el cliente no podrá comunicar
con el servidor maestro si el nombre de host no es completo.
b. Tenga en cuenta que la variable de dominio cfengine se define
como sigue:
domain = ( ExecResult(/bin/sh “/usr/bin/nslookup
‘/bin/hostname‘| /bin/awk ‘/Name:/ {print $2}’ |
/bin/sed ‘s/^[^\.]*\.//’”) )
44 Capítulo 2
La variable de dominio la utiliza la acción de resolución (“resolve”)

de cfagent. El comando ExecResult anterior da por sentado que
los archivos /etc/resolve.conf y /etc/nsswitch.conf del cliente ya se
han configurado apropiadamente. El comando espera obtener un
nombre de host completo, al utilizar nslookup, del propio nombre
de host del cliente. Si este supuesto no es apropiado para su
entorno, existen otras técnicas para definir el dominio. Por
ejemplo, el dominio del cliente podría determinarse según la
dirección IP o subred del cliente, como sigue:
classes:
# host in these ip address ranges
xyz_domain = ( IPRange(10.0.0.1-15) )
abc_domain = ( IPRange(192.0.0.1-254) )
control:
xyz_domain::
domain = ( “xyz.example.com” )
abc_domain::
domain = ( “abc.example.com”)
Utilice el indicador cfagent -p (o --parse-only) para comprobar
la sintaxis de update.conf.
4. Distribuya el archivo update.conf maestro a cada cliente
administrado. Este paso se describe en la sección “Configuración de
un cliente administrado de sincronización” en la página 57.
5. Cree las claves de seguridad del servidor maestro. cfengine utiliza
un intercambio de claves pública/privada para autenticar los clientes
remotos. Se genera un par de claves pública/privada en el servidor
maestro y en todos los clientes administrados. La clave pública de
cada cliente administrado se copia en el servidor maestro y desde éste
en los clientes administrados. Es importante intercambiar las claves
de forma segura por medio de una herramienta como “secure copy”
(copia segura) (consulte scp (1)) o por medio de una cinta o un
CD-ROM. Empiece por generar las claves del servidor maestro:
# /opt/dsau/sbin/cfkey
# cd /var/opt/cfengine/ppkeys
Esto crea los archivos localhost.pub y localhost.priv.
Copie la clave pública en
root-dirección_IP_del_servidor_maestro.pub. Por ejemplo, en
el supuesto de que la dirección IP de este sistema sea 10.0.0.5,
utilice este comando:
Capítulo 2 45
# cp hostlocal.pub root-10.0.0.5.pub
Para obtener detalles sobre cómo copiar las claves de cliente en este
servidor maestro, consulte la sección “Configuración de un cliente
administrado de sincronización” en la página 57.
6. En el servidor maestro, configure el demonio cfservd para que se
inicie al arrancar el sistema. Modifique /etc/rc.config.d/cfservd
y cambie la línea CSYNC_CONFIGURED=0 por CSYNC_CONFIGURED=1.
También, si desea tener capacidad para extender los cambios a los
clientes administrados utilizando cfrun, reproduzca este cambio en
todos los clientes administrados.
7. cfrun necesita que los clientes administrados se enumeren en el
archivo cfrun.hosts. En la configuración por defecto, este archivo se
ubica en /var/opt/dsau/cfengine_master/inputs. Modifíquelo y
agregue los nombres de host de cada cliente administrado, uno por
cada línea. Es lo más sencillo para asegurarse de que todos los
nombres de host están completos. Cuando se utilizan nombres de host
completos, la línea “domain = “ no es necesaria y se puede eliminar.
Si se utilizan nombres de host incompletos, busque las variables de la
línea “domain = “ y sustituya el signo por el dominio DNS de los
sistemas maestros. Esto limita a todos los clientes incompletos a ser
miembros de ese único dominio.
8. El archivo
/var/opt/dsau/cfengine_master/inputs/cfagent.conf es el
archivo de directivas maestro. El archivo cfagent.conf por defecto
incluye e archivo de plantilla por defecto cf.main con ejemplos de
acciones de sincronización comunes tanto para sistemas autónomos
como para clústeres Serviceguard. cf.main contiene las variables
POLICY HOST_NAME y “domain = “. Efectúe las mismas
modificaciones descritas en el paso 3 anterior.
Tenga en cuenta que este archivo cf.main por defecto no realiza
ninguna acción de administración. Todas las líneas de acción están
marcadas como comentario. Éste es un punto de partida para crear un
conjunto personalizado de directivas y acciones de cfengine para los
clientes administrados. El manual de referencia de cfengine que
documenta la sintaxis y todas las acciones de administración
definidas en este archivo se ubica en /opt/dsau/doc/cfengine.
Otros archivos de configuración de cfengine de ejemplo que se
incluyen en la distribución de cfengine de código fuente abierto se
ubican en /opt/dsau/share/cfengine/examples.
46 Capítulo 2
9. El archivo
/var/opt/dsau/cfengine_master/inputs/cfservd.conf controla
qué clientes administrados tienen acceso a los archivos atendidos por
el demonio cfservd en el maestro. Realice las siguientes
modificaciones en cfservd.conf.
• Sustituya el signo “<%CFSERVD_DOMAIN_LISTS%>“ por una lista

separada por comas de dominios DNS con caracteres comodín o
nombres de host para los sistemas que puedan obtener acceso a
este servidor. Por ejemplo:
domain_list = ( “*.abc.xyz.com,*.cde.xyz.com“ )
Esta instrucción permite a todos los sistemas host de los dominios
abc.xyz.com y cde.xyz.com obtener acceso al servidor maestro.
IMPORTANTE No se permiten espacios en esta lista separada por comas.
Agregue al principio a cada nombre de dominio el comodín “*.”.
NOTA El asistente csync_wizard sólo permite especificar nombres de

dominio con comodín en el archivo cfservd.conf. Si cfservd.conf se
modifica manualmente y se incluye una combinación de nombres
de host específicos o dirección IP y dominios con comodín, las
ejecuciones posteriores de csync_wizard sustituirán esta línea por
una lista de dominios con comodín basada en la lista de sistemas
host presentes en el archivo cfrun.hosts.
10. En el servidor maestro, inicie el demonio cfservd:

# /sbin/init.d/cfservd start
Repita este paso para cliente administrado.
NOTA cfservd.conf debe estar presente en

/var/opt/dsau/cfengine/inputs
antes de ejecutar este comando.
11. Pruebe la configuración dando los siguientes pasos:

a. En un cliente administrado, utilice el comando:
# cfagent --no-lock --verbose --no-splay
Capítulo 2 47
La salida detallada mostrará al cliente buscando copias

actualizadas de los archivos de directivas maestros, copiándolas
en /var/opt/cfengine/inputs, si procede, y ejecutando, a
continuación, el contenido de cfagent.conf/cf.main.
b. En el servidor maestro, pruebe el comando cfrun:
# cfrun -- --inform
La sintaxis --inform da instrucciones al cfagent remoto para
que utilice el indicador --inform, el cual generará mensajes para
todos los cambios que cfengine realice en el sistema. Para
obtener información adicional, el comando --verbose también
puede ser útil:
# cfrun -v -- --verbose
La opción -v le indica al propio cfrun que sea más detallado y la
opción --verbose se transmite al cfagent remoto.
Para obtener información adicional sobre la solución de problemas,
consulte la sección “Solución de problemas de cfengine” en la
página 66.
Configuración manual de un servidor de sincronización de un

clúster Serviceguard
Configurar cfengine para alta disponibilidad en un clúster Serviceguard
es parecido a configurarlo para un equipo autónomo, lo que se describe en
la sección “Utilización del asistente para configurar un servidor de
sincronización autónomo” en la página 28. Las principales diferencias son
la creación del paquete Serviceguard y el mecanismo utilizado para
distribuir las claves de seguridad de cfengine. Dé todos los pasos
descritos a continuación.
• Preparación inicial del paquete Serviceguard
1. Empiece por obtener una dirección IP para el paquete. Esta

dirección normalmente se registra en el sistema DNS para
simplificar la administración de los clientes remotos. Si utiliza
cfengine exclusivamente para uso intraclúster, basta con
asegurarse de que la dirección se agrega en el archivo /etc/hosts
de cada miembro.
48 Capítulo 2
2. A continuación, cree la infraestructura de almacenamiento

necesaria para un paquete nuevo. Las instrucciones para hacerlo
se documentan en el manual Managing Serviceguard (capítulo
“Building an HA Cluster Configuration”, sección “Creating a
Storage Infrastructure”). Por ejemplo, si utiliza una
infraestructura de almacenamiento LVM, ésta abarcaría los
siguientes pasos:
a. Crear el grupo de volúmenes (VG, del inglés “volume group”)

y los volúmenes lógicos (LV, del inglés “logical volume”) del
administrador LVM (por ejemplo, /dev/vgcsync/lvol1).
b. Exportar/importar el grupo de volúmenes en todo el clúster.
c. Definir un sistema de archivos en el volumen lógico.
d. Crear el punto de montaje del sistema de archivos (por
ejemplo, /csync) en todo el clúster.
Las plantillas por defecto dan por sentado que se utiliza el
almacenamiento basado en LVM. Para utilizar VxVM u otros
sistemas de archivos y almacenamiento en todo el clúster, efectúe
los cambios apropiados en las plantillas del paquete descritas a
continuación. Tenga en cuenta, asimismo, que la herramienta
Discos y sistemas de archivos (fsweb), a la que se tiene acceso en
la interface System Management Homepage, puede ayudar a
simplificar la configuración de los grupos de volúmenes y los
sistemas de archivos.
3. Asegúrese de que el sistema de archivos correspondiente al
paquete se monta en el miembro actual. Por ejemplo, si utiliza el
administrador LVM, haga lo siguiente:
# vgchange -a e /dev/vgcsync
# mount -o rw,largefiles /dev/vgcsync/lvol1 /csync
• Personalización inicial de los archivos de directivas
1. Cree un subdirectorio para los archivos de directivas maestros y

los archivos de referencia. Por ejemplo:
# mkdir -p /csync/dsau/cfengine_master/master_files
Estos directorios de ejemplo son los utilizados por el asistente
csync_wizard.
2. Copie las plantillas por defecto en el directorio de entradas
(inputs) maestro:
Capítulo 2 49
# cd /csync/dsau/cfengine_master/inputs
# cp /opt/dsau/share/cfengine/templates/cf.main.template cf.main
# cp /opt/dsau/share/cfengine/templates/update.conf.template update.conf
# cp /opt/dsau/share/cfengine/templates/cfagent.conf.template cfagent.conf
# cp /opt/dsau/share/cfengine/templates/cfrun.hosts.template cfrun.hosts
# cp /opt/dsau/share/cfengine/templates/cfservd.conf.template cfservd.conf
3. Modifique update.conf. Este archivo presenta un formato
parecido al archivo de configuración principal de cfengine:
cfagent.conf. Se utiliza para transferir y actualizar los archivos
binarios y los archivos de definiciones de configuración
actualizados (por ejemplo, cfagent.conf) de cfengine para los
clientes administrados. Reviste importancia crítica hacer que este
archivo se mantenga muy sencillo y evitar cometer errores. Los
errores de este archivo requerirán que se copie manualmente una
versión nueva en cada cliente administrado.
El archivo contiene signos con la forma de <%nombre del signo%>

que el asistente csync_wizard sustituye por las respuestas del
administrador a las preguntas. Sustituya los signos como sigue:
— Sustituya el signo <%POLICYHOST_NAME%> por el

nombre de dominio completo del paquete csync de
Serviceguard. Por ejemplo:
policyhost = ( “csync.abc.xyz.com” )
— Para obtener un análisis de la definición de la variable de
dominio cfagent, que la acción de resolución (resolve) de
cfagent utiliza, consulte la sección “Configuración manual de
un servidor de sincronización autónomo” en la página 43.
• Obtención de una lista de clientes administrados en
cfrun.hosts
cfrun necesita que todos los clientes administrados se enumeren en el
archivo cfrun.hosts. Puesto que cada miembro del clúster se
considera que es un cliente, asegúrese de que se enumera cada
miembro en /csync/dsau/cfengine_master/inputs/cfrun.hosts.
Modifíquelo y agregue los nombres de host de cada miembro, uno por
cada línea. Es lo más sencillo para asegurarse de que todos los
nombres de host están completos. Cuando se utilizan nombres de host
completos, la línea “domain =“ no es necesaria y se puede eliminar.
50 Capítulo 2
Esta especificación de dominio se concatena en cualquier nombre de

host completo. Si utiliza nombres de host incompletos, sustituya el
signo “<%DEFAULT_CLIENT_DNS_DOMAIN%>” por el nombre de
dominio simple. Por ejemplo:
domain = xyz.abc.com
Tenga en cuenta que el asistente csync_wizard siempre escribirá
nombres de host completos al agregar clientes administrados en este
archivo.
• Modificación del archivo de directivas maestro
El archivo /var/opt/dsau/cfengine_master/inputs/cfagent.conf
es el archivo de directivas maestro. El archivo cfagent.conf por
defecto incluye la plantilla por defecto cf.main, que es un archivo de
plantilla comentado con ejemplos de acciones de sincronización
comunes tanto para sistemas autónomos como para clústeres
Serviceguard. Modifique cf.main para sustituir el signo
<%POLICYHOST_NAME%> según se describe en el punto “Personalización
inicial de los archivos de directivas”. La declaración “domain =”
utilizada por la acción de resolución (resolve) también se analiza en la
misma sección.
Tenga en cuenta que esta plantilla por defecto no realiza ninguna
acción de administración. Todas las líneas de acción están marcadas
como comentario. La plantilla contiene muchos ejemplos específicos
de la sincronización de archivos en un clúster Serviceguard. Éste es
un punto de partida para crear un conjunto personalizado de
directivas y acciones de cfengine para el clúster y otros clientes
administrados.
El manual de referencia de cfengine que documenta la sintaxis y
todas las acciones de administración definidas en este archivo se
ubica en /opt/dsau/doc/cfengine/.
Otros archivos de configuración de cfengine de ejemplo que se
incluyen en la distribución de cfengine de código fuente abierto se
ubican en /opt/dsau/share/cfengine/examples.
• Modificación del archivo cfservd.conf
El archivo
/var/opt/dsau/cfengine_master/inputs/cfservd.conf controla
qué clientes administrados tienen acceso a los archivos atendidos por
el demonio cfservd en el maestro. Realice las siguientes
modificaciones en cfservd.conf.
Capítulo 2 51
— Sustituya el signo “<%CFSERVD_DOMAIN_LIST%>” por una lista

separada por comas de dominios DNS con caracteres comodín o
nombres de host para los sistemas que puedan obtener acceso a
este servidor. Por ejemplo:
domain_list = ( “*.abc.xyz.com,*.cde.xyz.com” )
Esta instrucción permite a todos los sistemas host de los dominios
abc.xyz.com y cde.xyz.com obtener acceso al servidor maestro. No
se permiten espacios en esta lista separada por comas. Cada
dominio debe ir precedido del comodín “*.”.
NOTA El asistente csync_wizard sólo permite especificar nombres de

dominio con comodín en el archivo cfservd.conf. Si cfservd.conf se
modifica manualmente y se incluye una combinación de nombres
de host específicos o dirección IP y dominios con comodín, las
ejecuciones posteriores de csync_wizard sustituirán esta línea por
una lista de dominios con comodín basada en la lista de sistemas
host presentes en el archivo cfrun.hosts.
Este ejemplo permite a todos los sistemas host de los dominios

enumerados obtener acceso a los archivos del servidor maestro.
También puede especificar listas de sistemas host específicos,
intervalos de direcciones IP, etcétera. Para obtener información
adicional, consulte el manual de referencia de cfengine.
Distribución del archivo maestro update.conf a cada miembro del
clúster
Utilice los siguientes comandos:
# cd /var/opt/dsau/cfengine/master_files/inputs
# ccp update.conf /var/opt/dsau/cfengine/inputs/
El propio cfengine se ocupará de distribuir los demás archivos en
todo el clúster y a todos los clientes administrados.
• Distribución de las claves de seguridad de cfengine
Puesto que cfengine utiliza un modelo de intercambio de claves
pública/privada para validar la autenticidad de los clientes
administrados, debe configurarse una clave que se asocie a la
dirección IP reubicable del paquete. Dicha dirección es la que los
clientes remotos perciben como el servidor maestro. Puesto que
cualquier miembro del clúster puede convertirse en el nodo adoptivo,
52 Capítulo 2
dicha clave debe ser idéntica en todos los miembros del clúster. cfkey
decfengine genera un par de claves pública/privada para el sistema
actual. cfkey crea los archivos localhost.priv y localhost.pub.
cfengine espera que las claves se denominen conforme a la siguiente
convención:
nombre_usuario-dirección_IP.pub
Por ejemplo:
root-10.0.0.3.pub
El administrador copia la clave localhost.pub en el nombre correcto
según la dirección IP del sistema. En el caso de un clúster, las claves
del miembro actual se utilizan para generar las claves en todo el
clúster dando los siguientes pasos:
1. Utilice cfkey para crear el par de claves pública y privada para

este miembro del clúster:
Esto creará las claves denominadas localhost.priv y localhost.pub
en el directorio /var/opt/dsau/cfengine/ppkeys.
2. La clave pública, localhost.pub, se copia a continuación en
root-dirección IP del paquete.pub. Por ejemplo:
# cp localhost.pub root-192.10.25.12.pub
donde 192.10.25.12 es la dirección IP reubicable del paquete
csync.
3. La clave pública localhost.pub de este miembro se utiliza a
continuación para crear claves específicas de miembro para cada
miembro:
# cp localhost.pub root-<dirección IP del miembro1>.pub
...
# cp localhost.pub root-<dirección IP del miembroN>.pub
4. Por último, todas las claves se copian en cada miembro.
# ccp * /var/opt/dsau/cfengine/ppkeys
Nota: ccp, un comando de cargabilidad de salida de comandos
(command-fanout), realiza una copia del clúster copiando un
comando en todos los miembros del clúster.
Capítulo 2 53
• Configuración e inicio de cfservd
1. Configure el demonio cfservd para que se inicie al arrancar el

sistema. Modifique /etc/rc.config.d/cfservd y cambie la
línea CSYNC_CONFIGURED=0 por CSYNC_CONFIGURED=1.
2. Propague este cambio en todo el clúster:
# ccp /etc/rc.config.d/cfservd /etc/rc.config.d/cfservd
3. En el servidor maestro, inicie el demonio cfservd:
4. Repita para el resto de los miembros del clúster. Si ha configurado
el clúster para que se utilice con las herramientas de cargabilidad
de salida de comandos (command fanout) de DSAU, utilice el
siguiente comando para iniciar los demonios en todo el clúster:
# cexec /sbin/init.d/cfservd start
• Creación del paquete csync
Para crear el paquete de sincronización de la configuración, modifique
los archivos de plantilla del paquete por defecto según proceda para el
entorno Serviceguard. Tenga en cuenta que es preciso que el paquete
se llame csync. De no llamarlo así, se impedirá que las operaciones
automatizadas de Serviceguard se lleven a cabo. Para obtener más
información, consulte la sección “Características de automatización
Serviceguard” en la página 38.
Empiece por efectuar los cambios descritos más adelante.
1. Cree el directorio del paquete en todo el clúster:

# cexec mkdir /etc/cmcluster/csync
2. Copie el archivo ASCII del paquete de plantilla y la secuencia de
comandos de control del paquete en el directorio
/etc/cmcluster/csync del miembro actual:
# cd /etc/cmcluster/csync
# cp /opt/dsau/share/serviceguard/templates/csync.conf.template csync.conf
# cp /dsau/share/serviceguard/templates/csync.script.template csync
# chmod +x csync
54 Capítulo 2
3. Modifique el archivo de configuración ASCII del paquete

csync.conf para sustituir los signos de marcador de posición por
los valores apropiados. Los signos presentan la forma <%nombre
del signo%>. Busque la línea “SUBNET <%SG_PKG_SUBNET%>” y
sustituya el signo por la subred del paquete csync. Utilice
netstat -i para ayudar a identificar la subred.
4. Modifique la secuencia de comandos de control del paquete y
sustituya los signos de marcador de posición por los valores
apropiados.
Nota: La plantilla de secuencia de comandos por defecto da por
sentado que se utiliza una configuración de almacenamiento
basado en LVM. Si utiliza VxVM y/o CFS, consulte el documento
Managing Serviceguard para obtener más información sobre la
configuración de paquetes mediante estos recursos técnicos.
Tendrá que marcar como comentarios las partes de LVM de la
plantilla descritas más adelante y sustituir las estrofas VxVM o
CFS apropiadas.
a. Busque la línea “VG[0]=“<%SG_PKG_VOL_GRP%>”” y sustituya
el signo por el nombre del grupo de volúmenes LVM del
paquete. Por ejemplo, ‘VG[0]“/dev/vgcsync”’.
b. Busque la línea “LV[0]=“<%SG_PKG_LOG_VOL%>”” y sustituya
el signo por el nombre completo del volumen lógico. Por
ejemplo, LV[0]=“/dev/vgcsync/lvol1”.
c. Busque la línea “FS[0]=“<%SG_PKG_FS%>”” y sustituya el
signo por el nombre del punto de montaje del sistema de
archivos creado para este paquete. Por ejemplo,
FS[0]=“/csync”.
Tenga en cuenta que este punto de montaje debería haberse
creado en cada miembro del clúster como parte de la
configuración de almacenamiento descrita más arriba.
d. Busque la línea “FS_MOUNT_OPT[0]=“<%SG_PKG_MNT_OPT%>””
y sustituya el signo por las opciones de montaje del sistema de
archivos. Por ejemplo, FS_MOUNT_OPT[0]=“-o
rw,largefiles”.
e. Busque la línea “FS_TYPE[0]=“<%SG_PKG_FS_TYPE%>”” y
sustituya el signo por el tipo de sistema de archivos. Por
ejemplo, FS_TYPE[0]=“vxfs”.
Capítulo 2 55
f. Busque la línea
“FS_UMOUNT_OPT[0]=“<%SG_PKG_FS_UMOUNT_OPT%>”” y
sustituya el signo por cualquier opción umount del sistema de
archivos. El signo se puede eliminar y esta opción se puede
dejar en blanco si no hay ninguna opción umount particular.
Por ejemplo, FS_UMOUNT_OPT[0]=“”.
g. Busque la línea
“FS_FSCK_OPT[0]=“<%SG_PKG_FS_FSCK_OPT%>”” y sustituya
el signo por cualquier opción fsck específica del sistema de
archivos. Como en el caso anterior, el signo se puede eliminar
y esta opción se puede dejar en blanco. Por ejemplo,
FS_FSCK_OPT[0]=“”.
h. Busque la línea “IP[0]=“<%SG_PKG_IP%>”” y sustituya el
signo por la dirección IP del paquete csync. Por ejemplo,
IP[0]= 123.456.789.3.
i. Busque la línea “SUBNET[0]=“<%SG_PKG_SUBNET%>”” y
sustituya el signo por la subred de la dirección IP del paquete.
Utilice netstat -i para ayudar a determinar la subred. Por
ejemplo, SUBNET[0]= 123.456.789.0.
5. Distribuya en todo el clúster la secuencia de comandos de control
del paquete y los archivos de configuración ASCII del paquete:
# ccp csync csync.conf /etc/cmcluster/csync/
6. Aplique el paquete e inícielo:
# cmapplyconf -P csync.conf
# cmmodpkg -e csync
• Prueba de la configuración del paquete csync

Pruebe la configuración dando los siguientes pasos:
1. En un cliente administrado, utilice el comando:
La salida detallada mostrará al cliente buscando copias
actualizadas de los archivos de directivas maestros, copiándolas
en /var/opt/cfengine/inputs, si procede, y ejecutando, a
2. En el servidor maestro, pruebe el comando cfrun:
# cfrun -- --inform
56 Capítulo 2
--inform da instrucciones al cfagent remoto para que utilice el

indicador --inform, el cual generará mensajes para todos los
cambios que cfengine realice en el sistema. Para obtener
información adicional, el comando --verbose también puede ser
útil:
# cfrun -v -- --verbose
La opción -v le indica al propio cfrun que sea más detallado y la
opción --verbose se transmite al cfagent remoto.
Para obtener información adicional sobre la solución de
problemas, consulte la sección “Solución de problemas de
cfengine” en la página 66.
Configuración de un cliente administrado de sincronización

Cuando se configuran manualmente clientes administrados, los pasos
básicos son:
• Intercambio de claves de seguridad. Esto establece la relación de

confianza entre el cliente administrado y el servidor maestro.
• Copia de update.conf desde el servidor maestro en el cliente
administrado.
• Definición de un programa para el que cfagent realizará operaciones
de sincronización.
Para un clúster Serviceguard, cada miembro debe configurarse
individualmente como un cliente cfengine. Después de configurar cada
miembro, si se agregan miembros nuevos en el clúster, también se deberá
configurar manualmente cada uno de los miembros nuevos. Repita las
tareas de configuración descritas más adelante en cada miembro del
clúster.
Para los demás clientes recién administrados, empiece por configurar la
relación de confianza entre el cliente y el servidor maestro. Los sistemas
maestro y cliente intercambian claves de seguridad para autenticarse.
La clave pública del servidor maestro tiene que copiarse en el cliente y la
clave pública del cliente se copia en el servidor maestro:
1. Como usuario root, utilice cfkey para crear el par de claves pública y
privada para este miembro del clúster:
Capítulo 2 57
Esto creará las claves denominadas localhost.priv y localhost.pub en

el directorio /var/opt/dsau/cfengine/ppkeys.
2. Copie la clave de este cliente en el servidor maestro. El servidor
maestro utiliza la siguiente convención de nomenclatura para las
claves de cliente:
<nombre_usuario>-<dirección_IP_cliente>.pub.
Mediante esta convención de nomenclatura, inserte la clave pública
del cliente en el directorio ppkeys del servidor maestro:
# scp localhost.pub servidor_maestro:\
/var/opt/cfengine/ppkeys/root-dirección_IP_cliente.pub
Tenga en cuenta que es importante usar una utilidad como secure
copy (copia segura) (consulte la página de manual de scp (1)) al
transferir la clave para proteger su integridad.
3. Por último, copie la clave del servidor maestro en este cliente
administrado:
# scp servidor_maestro:\
/var/opt/cfengine_master/ppkeys/localhost.pub \
root-dirección_IP_servidor_maestro.pub
4. A continuación, copie el archivo update.conf del servidor maestro en el
cliente administrado:
# mkdir -p /var/opt/dsau/cfengine/inputs
# cd /var/opt/dsau/cfengine/master_files/inputs
# cd /var/opt/dsau/cfengine/inputs
# scp servidor_maestro:\
/var/opt/dsau/cfengine/inputs/update.conf ./update.conf
Para permitir que este cliente acepte peticiones de cfrun, dé los
siguientes pasos:
1. Modifique /etc/rc.config.d/cfservd y defina la variable

CSYNC_CONFIGURED en “1”: esto iniciará cfservd en el momento del
inicio.
2. Inicie el demonio cfservd:
3. Pruebe la configuración con cfagent (consulte la página de manual de
cfagent (8)):
58 Capítulo 2

La salida detallada mostrará al cliente buscando copias actualizadas
de los archivos de directivas maestros, copiándolas en
/var/opt/cfengine/inputs, si procede, y ejecutando, a
Para obtener información adicional sobre la solución de problemas,
consulte la sección “Solución de problemas de cfengine” en la página 66.
Selección de un método de llamada a la sincronización

Como administrador, puede extender los cambios a los clientes
administrados con ayuda del comando cfrun (consulte la página de
manual de cfrun (8)). cfrun se pone en contacto con el demonio cfservd
en cada cliente administrado y cfservd llama a cfagent, que lleva a cabo
el trabajo de sincronización real.
También puede optar por que cfagent se ejecute a intervalos en el cliente.
Son dos los planteamientos:
• Ejecute cfagent desde un trabajo cron.

Cuando ejecute cfagent desde cron, llámelo con ayuda de cfexecd
-F. A continuación, se muestra un ejemplo de entrada crontab:
0 * * * * /var/opt/dsau/cfengine/bin/cfexecd -F
Esta entrada crontab hará que cfagent se ejecute cada hora.
En este ejemplo, cfexecd (consulte la página de manual de cfexecd
(8)) hace de empaquetador ("wrapper") para cfagent y recaba la
salida y la coloca en /var/opt/dsau/cfengine/outputs. cfexecd
también puede hacer que se envíe correo al administrador si se
especifica en el archivo cfagent.conf. Para obtener detalles,
consulte el manual de referencia de cfengine en
/opt/dsau/doc/cfengine.
Tenga en cuenta que el archivo cf.main por defecto tiene un ejemplo
para agregar automáticamente la línea anterior en el archivo
crontab de cada cliente administrado.
• Ejecute cfexecd en modo demonio.
cfexecd tiene características parecidas al demonio cron que se basan
en las clases de tiempo de cfengine y que se pueden utilizar en lugar
de cron para ejecutar cfagent. cfexecd adopta por defecto la
ejecución de cfengine cada hora. Al empezar a utilizar por primera
Capítulo 2 59
vez cfengine, probablemente lo más fácil sea utilizar cron para

programar la sincronización en el lado del cliente. Para obtener
detalles sobre el uso de cfexecd en modo demonio, consulte el tutorial
de cfengine ubicado en /opt/dsau/doc/cfengine/.
60 Capítulo 2
Notas sobre la seguridad

cfengine presenta muchas características de seguridad que abarcan
desde parámetros para controlar los ataques de denegación de servicio a
listas de control de acceso que impiden a los clientes administrados
obtener acceso a los directorios de archivos de referencia en el servidor.
Para obtener detalles sobre las características de seguridad de cfengine,
consulte el manual de referencia ubicado en /opt/dsau/doc/cfengine/.
Los temas de seguridad analizados a continuación abarcan:
• Intercambio de claves
• Uso del puerto de red
• Cifrado
• Alertas de suma de comprobación
Intercambio de claves
En todos los ejemplos de intercambio de claves mostrados hasta ahora se
ha utilizado la utilidad scp para transferir sin riesgos la clave pública del
servidor maestro al cliente administrado y la clave pública del cliente
administrado al servidor maestro. Este esquema aporta el máximo nivel
de seguridad, pero puede resultar inconveniente en determinadas
situaciones. Otras alternativas de distribución de claves incluyen las
siguientes:
• Al conectar con un cliente nuevo, cfrun tiene un modo interactivo

semejante a ssh, en el que se le pide al administrador que acepte la
clave del sistema remoto. Por ejemplo:
cfrun(0): .......... [ Hailing remote-host.abc.xyz.com ] ..........
WARNING - You do not have a public key from host remote-host.abc.xyz.com =
192.10.25.12
Do you want to accept one on trust? (yes/no)
-> yes
cfrun:<nombre de servidor maestro>: Trusting server identity and willing to accept
key
from remote-host.abc.xyz.com=192.10.25.12
Capítulo 2 61
• En el caso de una cantidad grande de clientes nuevos, este modo

interactivo puede ser ineficaz. cfrun admite una opción -T que le
indica a cfengine que confíe en todas las claves nuevas de los
sistemas host enumerados en cfrun.hosts.
• cfservd.conf admite una cláusula de control TrustKeysFrom. Por
ejemplo:
control:
TrustKeysFrom = ( 128.39.89.76 ) # Un host de confianza
TrustKeysFrom = ( 128.39.89.76/24 ) # Una subred de confianza
Se confiará implícitamente en el sistema host o direcciones de subred
enumerados y sus claves se aceptarán automáticamente.
Todas estas alternativas al intercambio de claves deben emplearse con
suma precaución y sólo en un entorno seguro donde la LAN sea de
confianza y los sistemas host remotos también lo sean. Una vez aceptada
una clave pública, no se actualizará a menos que se elimine manualmente
en el directorio /var/opt/dsau/cfengine/ppkeys del servidor maestro o
que se sustituya manualmente por una clave nueva, o que el asistente
csync_wizard se ejecute para actualizarla.
Uso del puerto de red csync

cfservd utiliza por defecto el puerto TCP 5308. Puede darle instrucciones
a cfagent para que conecte con cfservd mediante otro puerto
especificando un puerto en el archivo cfrun.hosts. Por ejemplo:
host1.abc.xyz.com # Utilizar puerto estándar
host2.abc.xyz.com # Utilizar puerto estándar
host3.abc.xyz.com:4444 # Utilizar puerto 4444
Asimismo, cfengine aceptará un puerto tcp cfengine definido en
/etc/services. Hay cambios correspondientes en /etc/services.
Cifrado
En general, el tráfico de transferencia de archivos entre el servidor
maestro y un cliente administrado no se cifra. Para muchos archivos de
configuración relacionados con la administración de sistemas esto es
aceptable. Para determinados archivos, es deseable una transferencia de
archivos cifrada. La acción de copia en cfagent.conf tiene una opción
“encrypt = true” para cifrar el archivo especificado. Para conocer opciones
de cifrado adicionales, consulte el manual de referencia de cfengine
ubicado en /opt/dsau/doc/cfengine.
62 Capítulo 2
Alertas de suma de comprobación

cfengine tiene una característica de alerta de suma de comprobación.
Para supervisar los cambios efectuados en la suma de comprobación de un
archivo, dé los siguientes pasos:
• Agregue la siguiente estrofa en

/var/opt/dsau/cfengine_master/inputs/cfagent.conf:
ChecksumUpdates = ( “on” )
• En la secuencia de acción “files” de cfagent.conf, agregue las
opciones checksum = md5 o checksum = sha para los archivos que
han de supervisarse. Por ejemplo:
files:
class::
/etc/example
mode = 644
checksum = md5
Tenga en cuenta que esta opción de suma de comprobación difiere de
la opción checksum = true utilizada en la secuencia de acción de
copia (“copy”). Dicha opción le indica a cfengine que utilice una suma
de comprobación en lugar de marcas de hora al decidir si los archivos
tienen que copiarse.
cfagent crea la base de datos de suma de comprobación en el cliente si
aún no existe. Cuando ChecksumUpdates se define en “on” o “true”, la
suma de comprobación actual para los archivos supervisados se agrega a
la base de datos de suma de comprobación o se actualiza en la misma.
Después de esta ejecución inicial para ocupar la base de datos de suma de
comprobación, cambie ChecksumUpdates a “off”. Al llegar a este punto,
cualquier cambio realizado en una suma de comprobación de un archivo
supervisado provoca una advertencia de seguridad. Por ejemplo:
host1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
host1: SECURITY ALERT: Checksum for /etc/example changed!
host1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Capítulo 2 63
Deshabilitación del uso de cfengine
Deshabilitación del uso de cfengine

El asistente csync_wizard no tiene una opción de anulación de
configuración (unconfigure) para que un sistema deje de ser servidor
maestro. Para deshabilitar un servidor maestro, basta con detener el
demonio cfservd:
# /sbin/init.d/cfservd stop
Para impedir que el demonio cfservd se inicie al arrancar el sistema,
modifique /etc/rc.config.d/cfservd y cambie
CSYNC_CONFIGURED a “0”.
Si se utilizó el asistente csync_wizard para crear la configuración de la
herramienta cfengine y agregar clientes administrados, se puede
utilizar para quitar clientes administrados. Ejecute el asistente en el
servidor maestro y seleccione la opción “Remove a client”. El asistente
necesita que el acceso ssh no interactivo al cliente administrado se haya
configurado según se describe en la sección “Utilización del asistente para
configurar un cliente de sincronización” en la página 41. El cliente
especificado se eliminará en el archivo cfrun.hosts y su clave pública se
borrará en el directorio ppkeys del servidor maestro, y la clave del
servidor maestro se eliminará en el directorio ppkeys del cliente.
64 Capítulo 2
Opciones de registro
Opciones de registro
cfengine es intencionadamente escueto en relación con la mayoría de los
cambios de configuración, pero hay varias opciones de configuración para
aumentar el nivel de detalle de la salida de cfengine como sigue:
• La mayoría de las acciones de cfagent.conf, como “copy”, “editfiles”

y “processes”, admiten una opción syslog = true para hacer que la
acción específica se registre en syslog.
• De modo parecido, la mayoría de las acciones admiten una opción
“inform = true” para hacer que cfagent informe de cualquier
cambio.
• La sección de control de cfagent.conf admite las opciones globales
“inform = (true)” y “syslog = true”.
• cfagent (consulte la página de manual de cfagent (8)) admite el
modificador --inform en la línea de comandos. Para obtener más
información, consulte el manual de referencia de cfengine en
/opt/dsau/doc/cfengine o la página de manual de cfagent.
Capítulo 2 65
Solución de problemas de cfengine

A continuación, se ofrecen sugerencias para solucionar problemas cuando
se trabaja con la herramienta cfengine.
1. Ejecute el demonio cfservd en el servidor maestro utilizando las
opciones --no-fork (-F) y --verbose (-v). Esto aportará información útil
para cualquier intento de solución de problemas.
2. Es posible que obtenga errores de autenticación. Al llevar a cabo una
operación “cfagent -K”, se muestran los siguientes mensajes:
cfengine:: BAD: key could not be accepted on trust
cfengine:: Authentication dialogue with <servidor
maestro>.abc.xyz.com failed
cfengine:client:/var/opt/dsau/cfengine/inputs/update.conf:
194: Warning:
actionsequence is empty
cfengine:client:/var/opt/dsau/cfengine/inputs/update.conf:
194: Warning: perhaps
cfagent.conf/update.conf have not yet been set up?
La causa más probable de este problema es la configuración de
seguridad de cfengine. Para solucionarlo, tendrá que intercambiar
las claves públicas de cfengine entre el cliente administrado y el
servidor maestro. El asistente csync_wizard (consulte la página de
manual de csync_wizard (8)) automatiza este proceso cuando se
agregan clientes. Para obtener instrucciones sobre la distribución
manual de las claves entre los clientes administrados, consulte la
sección “Configuración de un cliente administrado de sincronización”
en la página 57.
3. Mensajes de error “Warning: actionsequence is empty”
Utilice la opción cfagent -v para obtener más información. Una
posible causa de este mensaje es que update.conf no se ha agregado
al directorio /var/opt/dsau/cfengine/inputs del cliente.
4. Error de sintaxis debido a un espacio en blanco que falta.
# cfagent -K
cfengine::/var/opt/dsau/cfengine/inputs/update.conf:39:
syntax error
66 Capítulo 2
cfengine::/var/opt/dsau/cfengine/inputs/update.conf:Execut
ion terminated after
parsing due to errors in program
Compruebe si hay espacios en blanco en los archivos de configuración.
Como norma general, el uso de un espacio en blanco puede mejorar la
legibilidad. Un problema común es la omisión de un espacio en blanco
entre paréntesis. Por ejemplo, las funciones no deben tener ningún
espacio entre el nombre de la función y el paréntesis inicial, pero la
función en sí necesita un espacio en blanco inicial y otro final entre los
paréntesis envolventes. Por ejemplo, a continuación se muestra el uso
del espacio en blanco inicial y final necesario.
control:
my_variable = ( ExecResult(/bin/ls -l) )
En el ejemplo anterior, cfengine notifica (en la primera línea del
ejemplo) un error de sintaxis en la línea 39 del archivo update.conf.
Es posible que el error sea un error de espacio en blanco de la línea
anterior, línea 38, del archivo.
5. No se puede conectar con un cliente o servidor maestro de cfengine.
# cfrun
cfrun(0): .......... [ Hailing host1 ] ..........
cfrun(0): .......... [ Hailing host2 ] ..........
cfrun:host2: Couldn’t open a socket
cfrun:host2: socket: Connection refused
Compruebe que el demonio cfservd de host2 está configurado y en
funcionamiento. Utilice /sbin/init.d/cfservd start para iniciar
cfservd si no está en funcionamiento.
6. Mensajes “Can’t stat”
Cuando se trabaja utilizando cfrun o cfagent se pueden obtener
mensajes de error “can’t stat”. Por ejemplo:
host1: Can’t stat
/var/opt/dsau/cfengine_master/master_files/etc/test in copy
Compruebe el depósito de archivos maestros y asegúrese de que el
archivo en cuestión está disponible y tiene los permisos de acceso
correctos.
Capítulo 2 67
7. Mensajes de error “Couldn’t open a socket ”o “unable to establish

connection:”.
cfagent y cfrun pueden mostrar mensajes de error como:
cfengine:: Couldn’t open a socket
cfengine:: Unable to establish connection with host1
(failover)
host2: Couldn’t open a socket
Si el demonio cfservd del servidor maestro está en funcionamiento,
este mensaje de error podría indicar que hay un problema con un
servidor de seguridad o puerto de tal magnitud que el cliente no puede
llegar al puerto TCP 5308 en el servidor maestro. Cuando se utiliza
cfrun, el servidor maestro también debe poder llegar al puerto TCP
5308 en el cliente remoto. Compruebe que las normas del servidor de
seguridad permiten el acceso a estos puertos.
8. Los argumentos de la línea de comandos de cfengine distinguen
entre mayúsculas y minúsculas. Por ejemplo, cfagent admite tanto la
opción -k como la opción -K, teniendo ambas significados diferentes:
• -k da instrucciones a cfagent para que haga caso omiso de la

secuencia de acción de copia (“copy”)
• -K da instrucciones a cfagent para que haga caso omiso de los
bloqueos cuando se ejecute
9. ¿Cómo aumento el nivel de detalle de cfengine?
La mayoría de las herramientas y demonios de cfengine aceptan una
opción de nivel detallado (“verbose”) (-v) y varias opciones de
depuración (“debug”) (-d). Por ejemplo:
cfagent -d, -d1, -d2, or -d3
cfservd -v
cfrun -v
68 Capítulo 2
3 Registro consolidado
Distributed Systems Administration Utilities ofrece características de

registro consolidado, entre ellas las características de registro estándar
proporcionadas por syslogd y las características de syslog next
generation (syslog-ng) [syslog de próxima generación] en los entornos de
consolidación de archivos de registro autónomos y de clúster.
Las siguientes secciones de este documento describen el uso de dichas
características.
Capítulo 3 69
Registro consolidado
Introducción a syslog
syslogd (consulte la página de manual de syslogd (1M)) es un
componente omnipresente de los sistemas UNIX que lleva a cabo
actividades de registro en el sistema. syslogd lee un conjunto de orígenes
de registro, por ejemplo, /dev/log y /dev/klog, y procesa los mensajes de
registro según las instrucciones de /etc/syslog.conf. Las aplicaciones
registran mensajes en syslog con ayuda de la llamada de syslog()
(consulte la página de manual de syslog (3C)).
Formato de los mensajes de syslog

Los mensajes de syslog presentan un formato estándar que incluye un
nivel de prioridad y un dispositivo opcionales. El nivel de prioridad indica
la urgencia del mensaje. El dispositivo indica el subsistema que colocó el
mensaje. La tabla 3-1 enumera los niveles de prioridad y los dispositivos
definidos en /usr/include/syslog.h.
Tabla 3-1 Niveles de prioridad de syslog
Mensaje Descripción
LOG_EMERG Condición de emergencia; normalmente, se difunde a

todos los usuarios.
LOG_ALERT Condición que debe subsanarse inmediatamente, por
ejemplo, una base de datos de sistema dañada.
LOG_CRIT Condición crítica, por ejemplo, un error de un dispositivo
de hardware.
LOG_ERR Errores generales.
LOG_WARNING Mensajes de advertencia.
LOG_NOTICE Condiciones que no son condiciones de error, pero que
pueden exigir atención especial.
LOG_INFO Mensajes informativos.
LOG_DEBUG Mensajes que contienen información que normalmente
sólo se utiliza al depurar un programa.
70 Capítulo 3
La tabla 3-2 describe los mensajes de dispositivo de syslog.

Tabla 3-2 Mensajes de dispositivo de syslog
Mensaje Descripción
LOG_KERN Mensajes generados por el kernel. Ningún proceso de

usuario puede generar estos mensajes.
LOG_USER Mensajes generados por procesos de usuario aleatorios.

Éste es el identificador de dispositivo por defecto si no se
especifica ninguno.
LOG_MAIL Mensajes procedentes del sistema de correo.
LOG_DAEMON Mensajes procedentes de los demonios de sistema, por

ejemplo, inetd, ftpd (consulte las páginas de manual de
inetd (1M) y ftpd (1M)).
LOG_AUTH Mensajes procedentes del sistema de autorización,

incluidos login, su, getty (consulte las páginas de
manual de login (1), su (1) y getty (1M)).
LOG_SYSLOG Mensajes generados internamente por el demonio

syslogd.
LOG_LPR Mensajes procedentes del sistema de administración de

colas de impresión, por ejemplo, lp, lpsched (consulte las
páginas de manual de lp (1) y lpsched (1M)).
LOG_NEWS Mensajes procedentes del sistema de noticias.
LOG_UUCP Mensajes procedentes del sistema de protocolo UUCP.
LOG_CRON Mensajes procedentes del demonio CRON.
LOG_LOCAL0 - LOC_LOCAL7 Reservado para uso local.
Capítulo 3 71
Filtrado de mensajes
Los mensajes se pueden filtrar con ayuda de /etc/syslog.conf en
función del nivel de prioridad y del dispositivo. Los mensajes se pueden
remitir a:
• Archivos de registro específicos

• La consola
• Un usuario especificado. El mensaje se enviará al terminal del
usuario si éste ha iniciado una sesión.
• Todos los usuarios que hayan iniciado una sesión
• Se reenvían a los sistemas remotos. Para obtener más información,
consulte la sección “Descripción general de la consolidación de
archivos de registro” en la página 73.
Para obtener información adicional sobre la configuración de filtros de
mensajes, consulte la página de manual de syslogd (1M).
72 Capítulo 3
Descripción general de la consolidación de archivos de registro
Descripción general de la consolidación de

archivos de registro
El reenvío de archivos de registro es una característica del comando UNIX
syslogd estándar. Además de registrar mensajes en los archivos de
registro del host local, syslogd puede reenviar mensajes de registro a uno
o varios sistemas remotos. Se alude a estos sistemas como receptores de
archivos de registro o servidores de consolidación de archivos de registro.
La consolidación de archivos de registro ofrece ventajas como las
siguientes:
• Análisis de archivos de registro más fácil: El archivo de registro

centralizado proporciona una sola ubicación para que el
administrador efectúe el análisis de los archivos de registro. Presenta
una sola vista de los sucesos que repercuten en varios sistemas.
• Mayor seguridad: Una infracción de la seguridad podría afectar a los
archivos de registro locales pero no a la copia centralizada. El sistema
de consolidación de archivos de registro se puede fortalecer de formas
que es probable que sean inadecuadas para los clientes de reenvío de
• Almacenamiento simplificado de los archivos de registro: A veces es
más sencillo archivar un conjunto de archivos de registro
centralizados que los archivos de registro de cada sistema.
La utilización del syslogd estándar en un servidor de consolidación de
archivos de registro presenta varias desventajas:
• syslogd sólo admite el reenvío mediante el protocolo UDP.

El Protocolo de datagramas de usuario (UDP - Universal Datagram
Protocol) es un protocolo “sin conexión” y no ofrece control de flujo ni
entrega garantizada de mensajes. Así las cosas, es posible que los
mensajes de registro reenviados se pierdan.
• Las características de filtrado de syslogd son bastante sencillas: sólo
se puede filtrar según el dispositivo y la prioridad de un mensaje.
Capítulo 3 73
• Un sistema de consolidación de archivos de registro representa un

punto único de error. Si el sistema no está disponible, los mensajes
reenviados desde los clientes se pierden. Tenga en cuenta que los
mensajes aún existen en los sistemas cliente individuales. Sólo se
pierden en el archivo de registro consolidado.
Consolidación de archivos de registro mejorada

Distributed Systems Administration Utilities (DSAU) utiliza syslog-ng,
es decir, syslog “next generation” (próxima generación), para abordar los
puntos débiles mencionados más arriba del comando syslogd tradicional.
syslog-ng es una sustitución de código fuente abierto de syslogd.
Desempeña todas las funciones del syslogd estándar, además de
proporcionar características como las siguientes:
• Funcionalidad de filtrado mejorada. Además del filtrado según el

dispositivo/nivel de prioridad de syslog, syslog-ng puede efectuar
un filtrado de expresiones regulares en relación con el nombre del
programa, el nombre del host, el texto del propio mensaje, la dirección
IP del remitente, etcétera.
• Transporte mediante el protocolo TCP: Además del transporte
mediante el protocolo UDP de syslogd, syslog-ng admite un
transporte mediante TCP que ofrece mayor garantía de entrega.
NOTA Es importante tener en cuenta que la compatibilidad de syslog-ng

con un transporte mediante TCP no implica que sea una salvaguarda
contra la pérdida de mensajes en términos absolutos. Por ejemplo, si
el servidor de consolidación de archivos de registro está apagado, los
clientes de reenvío remotos experimentarán, de hecho, una pérdida de
paquetes después de que se sobrepasen los búferes (el tamaño del
búfer en el cliente se configura con syslog-ng). No obstante, el
protocolo TCP puede ofrecer mayor fiabilidad en general y mayor
seguridad. Por ejemplo, el tráfico de archivos de registro basado en el
protocolo TCP se puede cifrar con ayuda de ssh.
74 Capítulo 3
• Rotación de archivos de registro según los nombres de archivo de

salida: Los nombres de archivo de salida de los archivos de registro se
pueden basar en nombres de plantilla que admitan la expansión de
macros. Por ejemplo, si la plantilla de nombres de archivo de salida
contiene la macro “month”, se creará un nuevo nombre de archivo
cada mes.
• Inicio de programas: Un mensaje puede activar el inicio de un
programa, enviando el mensaje a la entrada estándar
correspondiente.
• Reenvío de archivos de registro para archivos de registro arbitrarios
basados en texto: Conjuntamente con la herramienta clog_tail de
DSAU, se puede utilizar syslog-ng para reenviar y consolidar
archivos de registro de aplicaciones arbitrarios basados en texto, como
los archivos de registro de paquetes de Serviceguard.
Coexistencia con syslog

Distributed Systems Administration Utilities configura syslog-ng para
coexistir y colaborar con el componente syslogd estándar. syslogd sigue
manejando todo el registro local para el sistema. syslog-ng se utiliza al
reenviar mensajes a un sistema de consolidación de archivos de registro y
en el consolidador de archivos de registro para recibir y filtrar mensajes.
Los siguientes diagramas ilustran la relación entre syslogd y syslog-ng.
La figura 3-1 representa la configuración en un sistema cliente
syslog-ng que reenvía archivos de registro a un servidor de consolidación
de archivos de registro remoto.
Capítulo 3 75
Figura 3-1 Configuración del reenvío de archivos de registro de syslog-ng
1. La zona gris representa una operación syslogd estándar.

Aplicaciones como el demonio cmcld de Serviceguard llaman a syslog
(consulte la página de manual de syslog (3C)) para enviar mensajes a
syslogd. syslog escribe los mensajes en el archivo
/var/adm/syslog/syslog.log y archivos conexos del sistema local.
Es frecuente que las aplicaciones también tengan archivos de registro
específicos de las aplicaciones. En este ejemplo, Serviceguard
mantiene un archivo de registro de las operaciones relativas a
paquetes en /etc/cmcluster/<nombre de paquete>/<nombre de
paquete>.log.
76 Capítulo 3
2. El demonio clog_tail de DSAU, que lleva la etiqueta “Lector de

archivos de registro” en el diagrama, supervisa los archivos de
registro basados en texto y envía líneas de registro nuevas a
syslog-ng para su procesamiento. En un clúster Serviceguard,
clog_tail adopta por defecto el valor de supervisar todos los archivos
de registro de paquetes.
3. log_reader envía todos los mensajes de registro nuevos a una
canalización convenida (log_consolidation_fifo), que es uno de los
orígenes del registro para syslog-ng.
4. El componente syslog-ng lee los datos nuevos de la canalización
convenida y los reenvía al servidor de consolidación de archivos de
registro.
5. El componente syslogd local, además de grabar los mensajes de
registro en el archivo /var/adm/syslog/syslog.log local, se
configura para reenviar también todos los mensajes a la instancia
local de syslog-ng. syslog-ng, a su vez, reenvía estos mensajes al
consolidador de archivos de registro. El administrador puede optar
por utilizar los protocolos UDP, TCP o TCP con ssh al reenviar los
mensajes.
La figura 3-2 ilustra la configuración en el servidor de consolidación de
Capítulo 3 77
Figura 3-2 Configuración del consolidador de archivos de registro de

syslog-ng
1. El servidor de syslog-ng lee los datos de registro entrantes

procedentes de los clientes conectados mediante el protocolo UDP o
TCP. Nota: Las flechas grises indican una operación de lectura; las
flechas negras denotan una operación de escritura.
2. La zona gris es idéntica a la configuración del cliente en la figura 3-1,
“Configuración del reenvío de archivos de registro de syslog-ng”.
En cuanto al sistema local, syslog-ng hace de cliente y procesa
localmente los mensajes de syslog y de clog_tail reenviados.
3. El servidor de syslog-ng procesa todos los mensajes y los filtra en los
archivos de registro consolidados apropiados. En este ejemplo
específico, el administrador ha creado un sistema de archivos llamado
“/clog” para albergar los archivos de registro consolidados.
/clog/syslog/ contendría el archivo consolidado relacionado con
syslog. /clog/packages incluiría los archivos de registro de
paquetes consolidados para un clúster Serviceguard.
78 Capítulo 3
Configuración de la consolidación de archivos de registro
Configuración de la consolidación de archivos

de registro
En las siguientes secciones se describe cómo configurar los servidores de
consolidación de archivos de registro y los clientes de reenvío de archivos
de registro. Configurar un servidor de consolidación es un proceso que
consta de varios pasos. La herramienta clog_wizard simplifica
enormemente el proceso de configuración. Si opta por no utilizar el
asistente, los pasos de configuración manual también se describen más
adelante.
Utilización del asistente de consolidación de archivos

de registro (Log Consolidation Wizard)
El asistente de consolidación de archivos de registro (Log Consolidation
Wizard) se instala como /opt/dsau/sbin/clog_wizard.
El asistente admite la creación de las siguientes configuraciones:
• un servidor de consolidación de archivos de registro autónomo
• un servidor de consolidación de archivos de registro de alta
disponibilidad para utilizar en un solo clúster Serviceguard (sólo uso
intraclúster)
• un servidor de consolidación de archivos de registro de alta
disponibilidad para que lo utilicen el clúster Serviceguard local y los
sistemas remotos, incluidos los clientes de clúster Serviceguard
• un sistema autónomo que reenvíe archivos de registro a un servidor
de consolidación de archivos de registro remoto
• un clúster Serviceguard que reenvíe archivos de registro a un servidor
de consolidación de archivos de registro remoto
Seleccione la opción de configuración apropiada.
El asistente detecta si se ejecuta en un sistema autónomo o un clúster
Serviceguard.
Al ejecutar el asistente en un clúster Serviceguard, por defecto se
configura clog como un servicio de alta disponibilidad (paquete
Serviceguard). El administrador debe proporcionar el entorno de
almacenamiento para el paquete y la dirección IP de paquete y el registro
Capítulo 3 79
de nombres DNS pertinentes. El asistente admite las configuraciones de

almacenamiento LVM. Las configuraciones que no sean LVM deben
realizarse manualmente. La información del paquete pertinente que el
asistente necesita se enumera en la siguiente tabla.
Tabla 3-3 Datos de configuración del asistente clog_wizard
Datos de configuración Ejemplo Su valor
Grupo de volúmenes LVM /dev/vgclog
Volumen lógico /dev/vgclog/lvol1
Punto de montaje de sistema de archivos /clog
Opciones de montaje -o rw
Tipo de sistema de archivos vxfs
Dirección IP de paquete (un nombre DNS 192.10.25.12

registrado)
Subred del paquete 192.10.25.0
Puertos libres para tcp y ssh 1775
Configuración de un servidor de consolidación de archivos de

registro autónomo con clog_wizard
Para iniciar el asistente de consolidación de archivos de registro (Log
Consolidation Wizard), ejecute el siguiente comando:
/opt/dsau/sbin/clog_wizard
Para un sistema autónomo, el asistente muestra en primer lugar unos
párrafos preliminares donde se explica la consolidación de archivos de
registro y, a continuación, pregunta:
Do you want to configure log consolidation? (y/n) [y]:
Conteste que sí (“y” de “yes”) o presione Entrar. La siguiente pregunta es:
You can configure this system nombre_host as either a:
- Consolidation server
- Client that forwards logs to a remote consolidation server
Do you want to configure nombre_host as a Consolidation Server? (y/n) [y]:
80 Capítulo 3
Conteste que sí (y).

El asistente pregunta a continuación:
Enter the fully qualified directory where the consolidated
logs should be stored []:
Normalmente, lo mejor es seleccionar un sistema de archivos dedicado
para los archivos de registro consolidados. Puesto que los archivos de
registro consolidados como syslog pueden aumentar de tamaño
rápidamente, HP también recomienda que el sistema de archivos se
configure para archivos grandes (“largefiles”). En este ejemplo se utiliza
un sistema de archivos que se llama “/clog”.
A continuación, el asistente solicita el tipo de transporte del cliente:
You can choose to have the clients forward logs to this
consolidation server using either the UDP protocol or the TCP protocol (recommended).
Do you want to use the TCP protocol? (y/n) [y]:
Tenga en cuenta que seleccionar el protocolo TCP no tiene por qué impedir
el uso por los clientes de los mensajes de registro reenviados mediante el
protocolo UDP. Que el consolidador de archivos permita exclusivamente
los mensajes de registro mediante el protocolo TCP depende de si el
sistema está consolidando o no su propio archivo syslog local. Para
obtener más detalles, consulte más adelante.
You need to choose a free port on this system for receiving logs. The port chosen
should be free on all cluster nodes.
Note: When configuring log consolidation on the clients,
this port will need to be specified.
Enter the TCP port to be used for receiving logs [1776]:
No hay ningún puerto reservado para el transporte mediante TCP de
syslog-ng. Se puede elegir cualquier puerto que no esté en uso.
HP recomienda que el administrador elija un puerto del intervalo
reservado, es decir, entre los puertos por debajo de 1024. A los puertos
privilegiados sólo pueden conectarse procesos privilegiados de un sistema
remoto. Tenga en cuenta que esto brinda tan sólo una garantía leve de
seguridad, puesto que implica que el administrador confía en el sistema
remoto. Consulte la sección ssh de la sección del cliente de reenvío de
archivos de registro para fijar unas garantías de seguridad más sólidas.
El archivo /etc/services documenta los puertos reservados conocidos.
Al elegir un puerto reservado, el asistente comprobará ambos
/etc/services y utilizará “netstat -an” para comprobar que el puerto
no está en uso.
Capítulo 3 81
Tenga en cuenta que syslogd utiliza el puerto UDP 514. El puerto

TCP 514 se reserva para que lo utilice remsh. remsh no es un protocolo
seguro y se deshabilita en muchas instalaciones. Si remsh se ha
deshabilitado en el consolidador, podría utilizar el puerto TCP 514. Esto
presenta la ventaja de que es un puerto privilegiado y que es igual que el
número de puerto UDP, por lo que es fácil acordarse de él y administrarlo.
No obstante, si el administrador cambia el sistema para rehabilitar el uso
de remsh, syslog-ng tendría que volver a configurarse para utilizar un
puerto nuevo y todos los sistemas cliente que reenvían a dicho sistema
tendrían que actualizarse.
A diferencia del protocolo UDP, TCP es un protocolo orientado a la
conexión. Cada cliente de reenvío de archivos de registro que utilice el
protocolo TCP tendrá una conexión con el servidor de consolidación de
archivos de registro. Para evitar ataques de denegación de servicio, el
número por defecto de las conexiones TCP aceptadas por syslog-ng se
limita a 10 conexiones. Para una cantidad grande de clientes, modifique el
archivo /etc/syslog-ng.conf.server del servidor de consolidación.
Busque la línea de origen de TCP en el archivo:
source s_syslog_tcp { tcp(port(puerto_tcp)
keep-alive(yes));};
y agregue un atributo max-connections() como sigue:
source s_syslog_tcp { tcp(port(puerto_tcp) keep-alive(yes)
max-connections(N)); };
donde N es el número previsto de clientes.
A continuación, el asistente pregunta qué archivos de registro locales
deben consolidarse:
Log files that reside on this system can be consolidated.
Would you like to consolidate this system's syslogs? (y/n)
[y]:
Contestar que sí (“y”) coloca los datos del propio syslog local de este
sistema de consolidación de archivos de registro en el archivo de registro
consolidado junto con los datos del syslog del sistema cliente. Para
conservar la prioridad y el dispositivo de entradas de syslog, se utiliza el
bucle invertido local UDP y syslog se configura para reenviar entradas
también a su puerto UDP 514 local. syslog-ng se configura para leer
dicho puerto. Por tanto, consolidar los archivos syslog de este sistema
permite a los clientes conectarse también a este servidor de consolidación
de archivos de registro a través del puerto UDP 514, aun cuando se haya
82 Capítulo 3
especificado anteriormente el transporte mediante el protocolo TCP. Si

opta por no consolidar los archivos syslog de este sistema, la elección
previa de un transporte mediante TCP requerirá que se configuren todos
los clientes de reenvío de archivos de registro para utilizar el transporte
mediante TCP.
El asistente muestra un resumen de todas las opciones de configuración
efectuadas por el administrador:
Summary of Log Consolidation Configuration:
You have chosen to configure nombre_host as a Log

Consolidation Server.
Logs will be forwarded from the remote consolidation
clients to local port 1776 using the TCP protocol.
The consolidated logs will be stored under directory:

/clog
The following logs from the local system will be

consolidated:
Syslog
Si estas opciones con correctas, continúe:
Do you want to continue? (y/n) [y]: y
El asistente muestra el avance describiendo qué archivos se están
modificando y avisa de que Ctrl/C se deshabilita hasta que se termine la
configuración. Para obtener una descripción completa de los archivos
modificados, consulte la sección “Configuración manual de la
consolidación de archivos de registro” en la página 97.
Copying files that will be modified by the wizard to
/var/opt/dsau/root_tmp/clog. These files will be used to
restore the system to its current log consolidation
configuration, in the event of a failure.
Configuring nombre_host as a log consolidation server.
Creating the /etc/syslog-ng.conf.server configuration

file.
Creating a symbolic link from /etc/syslog-ng.conf to the

/etc/syslog-ng.conf.server configuration file.
Creating /etc/rc.config.d/syslog-ng, the log
consolidation configuration file.
Updating the syslog configuration:

Updating the /etc/rc.config.d/syslogd file to add
Capítulo 3 83
-N SYSLOGD_OPTS. This stops syslogd from

listening to UDP port 514.
Updating the /etc/syslog.conf file for UDP local

loopback.
Starting syslogd for the configuration changes to

take effect.
Registering the log consolidation ports in the

/etc/services file.
Starting syslog-ng.
Successfully configured nombre_host as a log consolidation

server.
Configuración de un clúster Serviceguard como un servidor de

consolidación de archivos de registro con clog_wizard
Cuando vaya a ejecutar el asistente clog_wizard (consulte la página de
manual de clog_wizard (1M)) en un clúster, antes asegúrese de que todos
los miembros del clúster están activos y en funcionamiento. El asistente
necesita llevar a cabo operaciones de configuración en cada uno de los
miembros. Sólo se tiene que ejecutar una vez, desde cualquier miembro
del clúster. Si ejecuta el asistente más de una vez, es posible que
aparezcan símbolos del sistema adicionales.
El asistente se configurará y creará un paquete Serviceguard para el
servicio de registro consolidado. Asegúrese de que el valor
MAX_CONFIGURED_PACKAGES de este clúster puede albergar el
paquete adicional. Para obtener más información sobre este valor,
consulte el manual Managing Serviceguard, que forma parte del juego de
documentación de Serviceguard.
El asistente muestra en primer lugar unos párrafos preliminares donde se
explica la consolidación de archivos de registro (la salida del asistente se
puede ajustar de forma diferente a la mostrada a continuación):
Consolidated logging (clog) lets you combine the log entries from multiple
remote systems into a single file. This feature is used to
consolidate syslog data from several systems. Each remote system
continues to write entries to its local syslog.log and additionally
forwards the entries to the consolidating host. The systems forwarding
log entries are consolidation clients. The system to which they send
entries is the consolidation server. In addition to syslog data,
clog can also consolidate arbitrary text log files.
84 Capítulo 3
In a Serviceguard cluster, clog can help you automate package log

file consolidation. Log consolidation is especially useful in a
Serviceguard cluster, because it enables you to look at a single
consolidated file instead of the per-member logs. The clog wizard needs
to be run only once in the cluster and not on each cluster member.
All cluster members should be up when running this wizard.
clog_wizard will prompt you for information to configure log file

consolidation. Some questions display a default answer in square
brackets. If you press <Return/Enter>, the clog_wizard uses the
default answer.
Press Enter.
Querying the system miembro_clúster for current status, one moment...

El siguiente símbolo del sistema es:
You can configure this cluster nombre_clúster as either a:
Do you want to configure miembro_clúster as a Consolidation

Server? (y/n) [y]:
To configure this cluster as a log consolidation server, the wizard

will create a Serviceguard package called “clog”. The package
requires the following:
- Dedicated storage for failover between cluster members. The
consolidated logs will be stored here. This includes an LVM
volume group, LVM logical volume, a filesystem, filesystem
mount point, and the desired mount options. this storage
infrastructure needs to be configured cluster-wide before
proceeding.
- An IP address and subnet address pair for the package. IPv4
of IPv6 addresses can be used. The IP address should be registered
in DNS, if this cluster will consolidate logs from remote clients.
This should be appropriately configured on each cluster member before
proceeding with the consolidation server configuration.
Conteste que sí (y).
Capítulo 3 85
En un clúster, el asistente configura syslog-ng para que presente alta

disponibilidad utilizando un paquete Serviceguard. Para el registro
consolidado, el nombre del paquete es clog. La configuración del
almacenamiento LVM y la configuración de red para el paquete deben
prepararse antes de continuar o antes de ejecutar el asistente. Para
obtener detalles adicionales, consulte la sección “Creating a Storage
Infrastructure with LVM” del capítulo “Building an HA Cluster
Configuration”, del manual Managing Serviceguard.
NOTA El asistente sólo permite crear paquetes en función de los grupos de

volúmenes LVM. Cuando se utiliza el sistema de archivos CFS o VxVM, es
necesaria la configuración manual. Para obtener detalles, consulte la
sección “Configuración manual de la consolidación de archivos de
registro” en la página 97.
El asistente pide lo siguiente, todo lo cual ya debe estar configurado:

1. El nombre del grupo de volúmenes LVM (por ejemplo, /dev/vgclog)
2. El volumen lógico del grupo de volúmenes (por ejemplo,
/dev/vgclog/lvol1)
3. El punto de montaje del sistema de archivos (por ejemplo, /clog)
4. Las opciones de montaje del sistema de archivos (por ejemplo, –o
rw,largefiles). Las opciones de montaje se utilizan al pie de la letra
en el campo FS_MOUNT_OPT[0] de la secuencia de comandos de control
del paquete Service. Tenga en cuenta que las opciones de montaje
deben coincidir con el sistema de archivos creado en el volumen lógico.
Por ejemplo, si el sistema de archivos se creó con soporte para archivos
grandes, la opción de montaje “largefiles” debe especificarse. Puesto
que los archivos consolidados tienden a ser grandes, se recomienda
configurar sistemas de archivos VxFS con la opción “largefiles”.
5. El tipo de sistema de archivos (por ejemplo, vxfs)
6. La dirección IP del paquete. Esta dirección también debe ser un
nombre DNS registrado para que el reenvío de archivos de registro
sea fácil de configurar en los sistemas cliente.
7. La subred del paquete. (Utilice el comando netstat -i para
determinar la subred correcta.)
A continuación, el asistente solicita el tipo de transporte del cliente.
86 Capítulo 3
You can choose to have the clients forward logs to this consolidation
server using either the UDP or the TCP protocol (recommended).
Do you want to use the TCP protocol? (y/n) [y]: y
You need to choose a free port on this cluster for receiving logs. The
port chosen should be free on all cluster nodes.
Note: When configuring log consolidation on the clients, this port

will need to be specified.
Enter the TCP port to be used for receiving logs []: 1776
Tenga en cuenta que seleccionar el protocolo TCP no tiene por qué impedir
el uso por los clientes de los mensajes de registro reenviados mediante el
protocolo UDP. Que el consolidador de archivos permita exclusivamente
los mensajes de registro mediante el protocolo TCP depende de si el
sistema está consolidando o no su propio archivo syslog local. Para
obtener más detalles, consulte más adelante.
Al contestar afirmativamente (“y”) al uso del protocolo TCP, deberá
seleccionar un puerto TCP libre. Este puerto deberá estar libre en todos
los miembros del clúster. Para obtener detalles sobre la elección de un
puerto TCP con ayuda del asistente clog_wizard, consulte la sección
“Configuración de un cliente de reenvío de archivos de registro con
clog_wizard” en la página 93.
A continuación, el asistente pregunta qué archivos de registro locales
deben consolidarse:
Log files that reside on this cluster can be consolidated.
Would you like to consolidate this cluster's syslogs? (y/n) [y]:
Would you like to consolidate this cluster's package logs? (y/n) [y]:
En un clúster Serviceguard, se pueden consolidar todos los archivos
syslog específicos de los miembros en un solo syslog consolidado que
contenga syslog.log, mail.log y syslog-ng.log. También se puede
consolidar cada archivo de paquete específico de los miembros.
Tenga en cuenta que si opta por consolidar los archivos syslog del clúster,
los clientes remotos también pueden reenviar mensajes de syslog
mediante el protocolo UDP al clúster, al margen de la respuesta a la
pregunta “Do you want to use the TCP protocol”. Si opta por no consolidar
Capítulo 3 87
los archivos syslog de este clúster, la elección previa de un transporte

mediante TCP requiere que se configuren todos los clientes de reenvío de
archivos de registro para utilizar el transporte mediante TCP.
Los archivos de registro consolidados se colocan en el sistema de archivos
asociado al paquete. Partiendo del ejemplo anterior, el archivo
syslog.log consolidado se ubicaría aquí:
/clog/syslog/syslog.log,mail.log,syslog-ng.log
Los archivos de registro de paquetes consolidados se colocarían aquí:
/clog/package/paquete1.log, paquete2.log, ..., paqueteN.log
El asistente ya tiene todos los datos que necesita para configurar el
paquete de registro consolidado. Por tanto, muestra una pantalla
sinóptica de confirmación y, a continuación, lleva a cabo la configuración:
You have chosen to configure nombre_clúster as a Log Consolidation Server.
Logs will be forwarded from the remote consolidation clients
to local port número_puerto using the TCP protocol.
For high availability the Serviceguard package "clog" will be

configured with the following attributes:
Volume Group: /dev/vgclog
Logical Volume: /dev/vgclog/lvol1
Filesystem: /clog
Mount Options: -o rw,largefiles
Filesystem Type: vxfs
IP Address: 192.10.25.12
Subnet: 192.10.25.0
The following logs on this cluster will be consolidated:

Syslog
Serviceguard package logs
Do you want to continue? (y/n) [y]:
******* WARNING!!!! ********

Copying files that will be modified by the wizard

to /var/opt/dsau/root_tmp/clog on each cluster node.
These files will be used to restore the cluster to its
current log consolidation configuration, in the event
of a failure.
Configuring miembro_clúster as a log consolidation server.
88 Capítulo 3
The configuration will be done on all cluster nodes.

It will take a few minutes....
Creating the /etc/syslog-ng.conf.server configuration file.
Creating the /etc/syslog-ng.conf.client configuration file.

/etc/syslog-ng.conf.client configuration file.
[Halting the "clog" Serviceguard package if it is up.]
Creating /etc/rc.config.d/syslog-ng, the log consolidation

configuration file.
Updating the /etc/rc.config.d/syslogd file to add -N to
SYSLOGD_OPTS. This stops syslogd from listening to UDP port
514.
Updating the /etc/syslog.conf file for UDP local loopback.
Starting syslogd for the configuration changes to take effect.
Registering the log consolidation ports in the /etc/services file.
Starting syslog-ng.
Setting up the log consolidation server to be highly available.
Configuring the "clog" Serviceguard package.
Applying the "clog" Serviceguard package configuration file.

This will take a moment.
Starting the "clog" Serviceguard package. This will take a few moments...
The "clog" Serviceguard package has been started on miembro_clúster.
Successfully created the "clog" Serviceguard package.
Successfully configured miembro_clúster as a log consolidation server.
Notas sobre la configuración del clúster

En un clúster Serviceguard, el nodo adoptivo del paquete clog desempeña
las funciones de consolidación de archivos de registro. Los demás
miembros del clúster participan en forma de clientes de reenvío de
archivos de registro y envían mensajes de registro a la dirección IP
reubicable del paquete clog.
Capítulo 3 89
El conjunto de utilidades DSAU mantiene dos archivos de configuración

que controlan si la instancia de syslog-ng en un miembro concreto del
clúster funciona como un servidor de consolidación o un cliente de reenvío
de archivos de registro: /etc/syslog-ng.conf.server y
/etc/syslog-ng.conf.client. El enlace simbólico
/etc/syslog-ng.conf señala uno de los archivos de configuración.
Cuando se inicia el clúster, todos los miembros empiezan como clientes de
reenvío de archivos de registro con syslog-ng ejecutándose en cada
miembro. La secuencia de comandos de inicio /sbin/init.d/syslog-ng
define el enlace simbólico /etc/syslog-ng.conf para que señale
/etc/syslog-ng.conf.client.
Cuando el paquete clog se inicia, el nodo adoptivo reinicia esa instancia
de syslog-ng como una instancia de servidor de consolidación de archivos
de registro. La secuencia de comandos de paquetes reinicia el enlace
simbólico /etc/syslog-ng.conf para que señale
/etc/syslog-ng.conf.server.
Si el paquete clog se detiene, el enlace simbólico (symlink) se cambia
para señalar /etc/syslog-ng.conf.client y la instancia de syslog-ng
en ese miembro se reinicia. Tenga en cuenta que cuando un clúster es un
servidor de consolidación de archivos de registro, y el paquete está
desactivado, no se produce ninguna consolidación de archivos de registro
y los mensajes de registro reenviados se pierden.
Tenga en cuenta que los miembros del clúster pueden reenviar mensajes
de registro al consolidador mediante el protocolo UDP o el protocolo TCP.
En un clúster Serviceguard, el reenvío a través de un puerto ssh no se
utiliza. El reenvío a través de un puerto ssh se puede utilizar para
asegurar el tráfico de archivos de registro reenviado por clientes remotos
fuera del clúster. Para obtener información adicional, consulte la sección
“Reenvío a través de un puerto ssh” en la página 133.
Características de automatización Serviceguard

El conjunto de herramientas Distributed Systems Administration
Utilities necesita Serviceguard 11.17 o posterior. Con Serviceguard 11.17
o posterior, cuando se agregan o eliminan miembros en el clúster o se
agregan y eliminan paquetes, las herramientas de registro consolidado de
DSAU adoptan automáticamente las acciones de configuración
apropiadas. De forma específica:
90 Capítulo 3
• Al agregar un miembro al clúster, el miembro nuevo se configura

automáticamente para participar en la consolidación de archivos de
registro según la configuración del clúster. Los siguientes archivos se
configuran automáticamente en el miembro agregado:
— /etc/rc.config.d/syslog-ng
— /etc/rc.config.d/syslogd
— /etc/syslog.conf
— /etc/syslog-ng.conf.client, /etc/syslog-ng.conf.server
y el enlace simbólico /etc/syslog-ng.conf
— /etc/services
• Al eliminar un miembro de un clúster:
— El miembro se sigue configurando como un cliente de reenvío de

archivos de registro y continuará reenviando mensajes de syslog
al clúster si se ha seleccionado esa opción durante la ejecución
inicial del asistente clog_wizard. Si el sistema debe dejar de
reenviar mensajes de registro al clúster, vuelva a ejecutar el
asistente para configurar el sistema de modo que reenvíe a un
consolidador diferente o deshabilite por completo la consolidación
de archivos. Para obtener información adicional, consulte la
sección “Deshabilitación de la consolidación de archivos de
registro” en la página 128.
— Los archivos de registro de paquetes del miembro eliminado se
siguen supervisando hasta que se produce un reinicio. Puesto que
dicho miembro ya no forma parte del clúster, los archivos de
registro de paquetes no estarán activos.
• Al agregar o eliminar un paquete, se producen las siguientes acciones
automáticas:
— El paquete se agrega o elimina en el archivo de configuración

/etc/syslog-ng.conf.server, en todo el clúster. Existe una
sección reservada de estos archivos de configuración que se dedica
al uso por parte de las herramientas DSAU. Las estrofas de
configuración agregadas en esta sección indican a syslog-ng que
filtre los mensajes de registro de paquetes en los archivos de
registro de paquetes consolidados apropiados.
— El monitor de registro clog_tail agrega o elimina el archivo de
registro de paquetes en su lista de archivos para supervisar.
Capítulo 3 91
Minimización de la pérdida de mensajes durante la conmutación

por error
Cuando se produce un error en el nodo adoptivo, el proceso de
conmutación por error del paquete “clog” a otro miembro del clúster dura
una cantidad finita de tiempo. Cuanto más dure la conmutación por error,
mayor probabilidad habrá de que se pierdan mensajes en el archivo de
registro consolidado. Aplique las siguientes pautas para minimizar la
pérdida de mensajes durante la conmutación por error.
• Configure los clientes para utilizar el transporte mediante TCP en

lugar del transporte mediante UDP. Los mensajes reenviados
mediante UDP se perderán incondicionalmente cuando el paquete
esté desactivado. El protocolo TCP contiene mecanismos de reintento,
control de congestión, etcétera, que ayudan a minimizar la pérdida de
mensajes.
• syslog-ng puede guardar en el búfer del lado del cliente los mensajes
reenviados mediante TCP. El número de mensajes guardados en el
búfer se controla con el valor syslog-ng log_fifo_size(). Esto fija
un límite superior en relación con el número de mensajes que se
pueden guardar en el búfer. El archivo /etc/syslog-ng.conf() por
defecto define log_fifo_size en 10000.
• syslog-ng tiene una opción time_reopen() para configurar el
tiempo que debe esperarse antes de restablecer una conexión inactiva.
El archivo /etc/syslog-ng.conf tiene definida la opción
time_reopen() en 10 segundos.
• Serviceguard ofrece diversas opciones de configuración para mejorar
la duración de la conmutación por error, por ejemplo:
HEARTBEAT_INTERVAL y NODE_TIMEOUT. También se dispone
de Serviceguard Extension for Faster Failover (SGeFF) para
optimizar la duración de la conmutación por error para los clústeres
binodo. Puesto que el propio componente syslog-ng se inicia
rápidamente, SGeFF es un candidato ideal para mejorar la duración
de la conmutación por error y para minimizar la pérdida de mensajes.
92 Capítulo 3
Configuración de un cliente de reenvío de archivos de registro

con clog_wizard
Hay dos formas de configurar un cliente de reenvío de archivos de
registro: como un equipo autónomo o como un clúster Serviceguard.
Al configurar un clúster como un cliente de reenvío de archivos de
registro, todos los miembros del clúster se configurarán de forma idéntica
como clientes. El asistente plantea las mismas preguntas y lleva a cabo
las mismas acciones de configuración en el caso de los sistemas
individuales y en el caso de los clústeres. Los ejemplos presentados más
adelante muestran el uso del asistente clog_wizard en un clúster
Serviceguard.
Después de iniciar el asistente clog_wizard, conteste que “sí” (“y” de
“yes”) a la siguiente pregunta:
Do you want to configure log consolidation? (y/n) [y]:
o presione Entrar. La siguiente pregunta es:
You can configure this cluster miembro_clúster as either a:
Do you want to configure miembro_clúster as a Consolidation Server? (y/n) [y]: n

Conteste que “no” (“n”) en este caso. Al llegar a este punto, se está
configurando un cliente de reenvío de archivos de registro. El asistente
muestra lo siguiente:
You now need to specify which system will be the
consolidator. If the consolidator is a Serviceguard
cluster, specify the IP address of the "clog"
Serviceguard package for this question. The "clog"
package makes log consolidation highly
available on the consolidator.
The consolidation server must already be configured.
Enter the hostname or IP address of the consolidator

[]: clog.usa.xyz.com
Después de escribir el nombre de host o la dirección IP del servidor de
consolidación de archivos de registro, el asistente le pregunta si desea
utilizar el transporte mediante el protocolo TCP al reenviar los mensajes
de registro:
Capítulo 3 93
You can choose to forward logs to the consolidator using

either the UDP protocol or the TCP protocol (recommended).
Do you want to use the TCP protocol? (y/n) [y]:

El componente syslogd estándar reenvía los mensajes mediante el
protocolo UDP. UDP es un protocolo orientado a la difusión de alto
rendimiento sin ningún control de flujo ni comprobación de entrega de
mensajes. syslog-ng admite el protocolo UDP de syslogd y un protocolo
TCP. El transporte mediante el protocolo TCP ofrece tanto control de flujo
como comprobaciones de entrega de mensajes. Sin embargo, puesto que el
TCP es un protocolo orientado a la conexión, necesita recursos adicionales
en el servidor de consolidación de archivos de registro. El atributo
max-connections() del servidor de consolidación debe definirse
conforme al número máximo de clientes previstos. Consulte la sección
“Configuración de un servidor de consolidación de archivos de registro
autónomo con clog_wizard” en la página 80 para obtener un análisis del
valor max-connections().
Si contesta que “sí” (“y”) al uso del protocolo TCP, la siguiente pregunta le
pedirá el puerto TCP al que reenviar los mensajes:
Ask the administrator of the consolidation server which
TCP port was configured for receiving logs.
Enter the TCP port configured on the CONSOLIDATOR for

receiving logs []: 1776
Deberá utilizar el puerto TCP seleccionado por el administrador del
sistema del servidor de consolidación de archivos de registro. Si se utilizó
el asistente clog_wizard para configurar el servidor, el número de puerto
está guardado en /etc/rc.config.d/syslog-ng como la variable
CLOG_TCP_PORT. En este ejemplo, se utiliza el puerto TCP 1776.
Si contesta que “sí” (“y”) a la pregunta sobre el protocolo TCP, aparecerá la
siguiente pregunta:
The TCP protocol can be used together with Secure
Shell port forwarding to enhance security. Each member
of this cluster must already have non interactive Secure
Shell Authentication set up with the consolidator. You
can use the tool /opt/dsau/bin/csshsetup to configure
non interactive Secure Shell Authentication.
Do you want to configure Secure Shell port forwarding? (y/n) [y]:
94 Capítulo 3
Seleccione “y” (sí) para utilizar el reenvío a través de un puerto ssh. Esto
cifrará todo el tráfico enviado desde este cliente de reenvío de archivos de
registro local al consolidador de archivos de registro.
NOTA Se necesita una configuración de seguridad basada en ssh especial en el

servidor cuando el servidor de consolidación de archivos de registro es un
clúster Serviceguard. Para obtener detalles, consulte la sección “Reenvío a
través de un puerto ssh” en la página 133.
El reenvío a través de un puerto ssh necesita un puerto TCP libre

adicional en el sistema de cliente local:
Tiene que elegir un puerto libre en este clúster para el reenvío a través de
un puerto ssh. El puerto elegido deberá estar libre en todos los nodos del
clúster.
Enter the ssh port to be used for port forwarding []: 1775
A este puerto se aplican las mismas pautas que para seleccionar un puerto
TCP de syslog-ng libre. Para obtener detalles, consulte la sección
autónomo con clog_wizard” en la página 80. En este ejemplo, se utiliza el
puerto local 1775.
Para un cliente de reenvío de archivos de registro de un clúster
Serviceguard, los archivos syslog y los archivos de paquetes del clúster se
pueden reenviar al servidor de consolidación de archivos de registro. Para
un sistema autónomo, el asistente sólo pregunta sobre el reenvío de
mensajes de syslog:
Log files that reside on this cluster can be forwarded to the consolidator.
Would you like to forward this cluster's syslogs? (y/n) [y]:
Would you like to forward this cluster's package logs? (y/n) [y]:
Tenga en cuenta que al reenviar los archivos de registro de paquetes de un
clúster, se precisa configuración manual en el servidor de consolidación
para agregar las líneas de filtrado del componente syslog-ng a fin de
hacer que estos archivos de registro de paquetes se consoliden en sus
propios archivos exclusivos. Para obtener detalles, consulte la sección
“Configuración manual de los clientes de reenvío de archivos de registro”
en la página 113.
Capítulo 3 95
Una vez contestadas todas las preguntas, el asistente clog_wizard

presenta la siguiente pantalla sinóptica:
You have chosen to configure nombre_clúster as a Log Consolidation Client.

Logs will be forwarded to the remote consolidation server
clog.usa.xyz.com on port 1776 using the TCP protocol.
The TCP protocol will be used together with Secure Shell

Port Forwarding using port 1775, for added security.
The following logs will be forwarded for consolidation:

Syslog
Serviceguard package logs
Do you want to continue? (y/n) [y]:

Confirme las respuestas contestando con una “y” (sí) y el asistente
resumirá los pasos de configuración que da:
Copying files that will be modified by the wizard to /var/opt/dsau/root_tmp/clog
on each cluster node.
These files will be used to restore the cluster to its current log consolidation
configuration, in the event of a failure.
Configuring nombre_clúster as a log consolidation client.
The configuration will be done on all cluster nodes.

It will take a few minutes....
Creating the /etc/syslog-ng.conf.client configuration file.

/etc/syslog-ng.conf.client configuration file.
Creating /etc/rc.config.d/syslog-ng, the log consolidation configuration file.

Updating the /etc/rc.config.d/syslogd file to add -N to SYSLOGD_OPTS.
This stops syslogd from listening to UDP port 514.
Updating the /etc/syslog.conf file for UDP local loopback.
Starting syslogd for the configuration changes to take effect.
Registering the log consolidation ports in the /etc/services file.
Starting syslog-ng.
Successfully configured nombre_clúster as a log consolidation client.
96 Capítulo 3
Para obtener información adicional sobre las acciones de configuración

efectuadas por el asistente clog_wizard, consulte la sección
“Configuración manual de un clúster Serviceguard como un servidor de
consolidación de archivos de registro” en la página 102.
Configuración manual de la consolidación de archivos

de registro
Si opta por no utilizar el asistente de consolidación de archivos de registro
(Log Consolidation Wizard), utilice las siguientes secciones para dar los
pasos manuales necesarios para configurar un servidor de consolidación
de archivos de registro y clientes de reenvío de archivos de registro.
Puesto que configurar los clientes y servidores conlleva dar muchos pasos,
HP recomienda utilizar el asistente clog_wizard.
La configuración manual es necesaria en los siguientes casos:
• Cuando un clúster es un cliente de reenvío de archivos de registro y

reenvía archivos de registro de paquetes, se necesita la configuración
manual en el servidor de consolidación (autónomo o clúster) para
filtrar apropiadamente los archivos de registro de paquetes.
• Al configurar un clúster Serviceguard como un consolidador de
archivos de registro y necesitar:
— Una personalización especial del paquete “clog”

— El uso de VxVM en lugar de LVM
— El uso del sistema de archivos CFS (Cluster File System)
A menudo, lo más sencillo consiste en ejecutar el asistente y dejar que éste
complete la configuración básica, para, a partir de este punto,
personalizar.
Las siguientes secciones describen los pasos necesarios para configurar
manualmente los sistemas de consolidación de archivos de registro.
Los sistemas que se pueden configurar manualmente son:
• Un servidor de consolidación de archivos de registro autónomo

• Un servidor de consolidación de archivos de registro de clúster
Serviceguard
Capítulo 3 97
Configuración manual de un servidor de consolidación de

archivos de registro autónomo
Empiece por configurar el componente syslogd estándar para coexistir
con un consolidador syslog-ng. Por defecto, el demonio syslogd está a la
escucha de mensajes de registro entrantes en el puerto UDP 514. Si desea
aceptar mensajes UDP de syslog procedentes de clientes remotos o
consolidar los archivos syslog locales de este servidor, syslog-ng deberá
escuchar en el puerto UDP 514. Modifique /etc/rc.config.d/syslogd y
cambie SYSLOGD_OPTS para agregar el modificador -N, que impide que
syslogd escuche en el puerto 514. Por ejemplo:
SYSLOGD_OPTS=“-D -N”
Si desea que los mensajes de syslog locales procedentes del propio
servidor de consolidación de archivos de registro formen parte del archivo
syslog consolidado, modifique el archivo /etc/syslog.conf del
consolidador para reenviar mensajes de registro al puerto 514 del host
local donde syslog-ng los leerá. Tomando como ejemplo el archivo HP-UX
/etc/syslog.conf por defecto, agregue las siguientes líneas:
mail.debug @<servidor de consolidación de archivos de registro>
*.info;mail.none @<servidor de consolidación de archivos de registro>
donde <servidor de consolidación de archivos de registro> es el
nombre de dominio completo del servidor de consolidación. El nombre
debe estar completo o syslogd no reenviará correctamente los mensajes.
Tenga en cuenta que debe haber una <tabulación> antes de cada signo de
arroba, @.
Si ha personalizado el archivo syslog.conf, asegúrese de que también
agrega las líneas de reenvío para las personalizaciones.
syslogd debe detenerse y reiniciarse para que estos cambios surtan
efecto con ayuda de los siguientes comandos:
# /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start
Con syslogd convenientemente configurado, configure ahora syslog-ng.
Empiece por las mismas plantillas de syslog-ng.conf utilizadas por el
asistente clog_wizard.
98 Capítulo 3
Copie
/opt/dsau/share/clog/templates/syslog-ng.conf.server.template
en /etc/syslog-ng.conf.server. Este archivo tiene signos que se llaman
<%nombre_del_signo%> y que el asistente sustituye según las respuestas
del administrador a las preguntas del asistente.
Sustituya los signos como sigue:
• Cuando utilice el protocolo TCP y configure el servidor de

consolidación para consolidar sus propios archivos syslog, sustituya
el signo <%UDP_LOOPBACK_SOURCE%> por:
source s_syslog_udp { udp(port(514)); };
Sustituya el signo <%UDP_LOOPBACK_LOG%> por:
log { source(s_syslog_udp); destination(d_syslog_tcp); };
Esto hace que el consolidador syslog-ng lea los mensajes reenviados
mediante el protocolo UDP del demonio syslogd local y que los envíe
al syslog-ng ubicado en el puerto TCP local. También puede definirse
el destino para que sea directamente el archivo de consolidación local
(destination(d_syslog) en esta plantilla por defecto), pero esto
configura los componentes cliente del servidor de consolidación del
mismo modo que un cliente remoto. En otras palabras, cuando el
consolidador es cliente de sí mismo, se configura de forma idéntica a
los clientes remotos.
Si utiliza el protocolo UDP o no consolida los archivos syslog locales
de este servidor, elimine los signos <%UDP_LOOPBACK_SOURCE%> y
<%UDP_LOOPBACK_LOG%>.
• Sustituya los signos <%TYPE%> por udp o tcp, según el transporte de
archivos de registro deseado que haya de admitirse. Tenga en cuenta
que aun cuando se utilicen clientes TCP, los clientes UDP también se
admiten si se configura la consolidación de los archivos syslog locales
del servidor. Hay varias líneas con el signo <%TYPE%> y todas deben
modificarse apropiadamente.
• Para la línea “source s_syslog_<%TYPE%> ”, sustituya los signos
<%PORT%> y <%KEEP_ALIVE%> por los valores apropiados, como sigue:
source s_syslog_<%TYPE%> { <%TYPE%>(port(<%PORT%>)
<%KEEP_ALIVE%>); };
Para el transporte mediante el protocolo TCP, el puerto tiene que ser
un puerto TCP disponible. Para obtener un análisis de la selección de
un puerto disponible, consulte la sección “Configuración de un
Capítulo 3 99
servidor de consolidación de archivos de registro autónomo con

clog_wizard” en la página 80. Para el transporte mediante el protocolo
UDP, utilice el puerto 514.
<%KEEP_ALIVE%> sólo se aplica cuando se selecciona el protocolo TCP
como el transporte de los archivos de registro. Sustituya este signo por
“keep-alive(yes)”, que le da instrucciones a syslog-ng para que
mantenga abiertas las conexiones cuando vuelva a leer su archivo de
configuración. Si utiliza el transporte mediante el protocolo UDP,
elimine este signo.
• Para la línea “destination d_syslog_<%TYPE%>”, sustituya los
signos <%IP%> y <%PORT%>:
destination d_syslog_<%TYPE%> { <%TYPE%>(“<%IP%>”
port(<%PORT%>)); };
Por ejemplo, para el transporte mediante el protocolo TCP:
destination d_syslog_tcp { tcp(“nombre de host local”
port(1776)); };
donde <%IP%> se sustituye por la dirección IP del servidor o el nombre
de host local y el signo <%PORT%> se sustituye por el número de puerto
TCP seleccionado.
Para el transporte mediante el protocolo UDP:
destination d_syslog_udp { udp(“nombre de host local”
port(514)); }
donde <%IP%> se sustituye por la dirección IP del servidor o el nombre
de host local y el signo <%PORT%> se sustituye por 514, el puerto UDP
estándar de syslog.
• Sustituya el signo <%FS%> por el sistema de archivos o el directorio
donde se vayan a guardar los archivos de registro consolidados. Por
ejemplo:
destination d_syslog { file(“<%FS%>/syslog/syslog.log”); };
se convierte en:
destination d_syslog { file(“/clog/syslog/syslog.log”); };
Asegúrese de que este directorio existe o de que el sistema de archivos
apropiado está montado. Puesto que los archivos de registro
consolidados pueden llegar a ser bastante grandes, HP recomienda
que este sistema de archivos utilice la opción “largefiles” y que haya
suficiente espacio para la ampliación.
100 Capítulo 3
• Cuando utilice el protocolo TCP, deje constancia del número de puerto

que elija más arriba en el archivo /etc/services.
Por ejemplo, agregue la línea:
clog_tcp 1776/tcp # Registro consolidado con syslog-ng
• Cree el siguiente enlace simbólico:
ln -sf /etc/syslog-ng.conf.server /etc/syslog-ng.conf
• El procedimiento de arranque de syslog-ng,
/sbin/init.d/syslog-ng, se basa en varias variables de
configuración. Modifique /etc/rc.config.d/syslog-ng como sigue:
— Cambie la línea CLOG_CONFIGURED a:

CLOG_CONFIGURED=1
— Agregue las siguientes líneas:
CLOG_CONSOLIDATOR=1
CLOG_FS=<directorio donde se almacenarán los archivos de
registro consolidados>
Si utiliza el protocolo TCP, agregue:
CLOG_TCP=1
CLOG_TCP_PORT=<puerto tcp elegido para la consolidación
de archivos de registro>
en caso contrario, si utiliza el protocolo UDP, agregue:
CLOG_TCP=0
Si consolida los archivos syslog locales, agregue:
CLOG_SYSLOG=1
en caso contrario, agregue:
CLOG_SYSLOG=0
Para un consolidador autónomo, agregue lo siguiente:
CLOG_SYSTEM_LOG_CONSOLIDATION_DIR=<directorio de
archivos de registro consolidados/syslog>
CLOG_SERVICEGUARD_PACKAGE_LOG_CONSOLIDATION_DIR=
<directorio de archivos de registro
consolidados/paquetes>
— Agregue los dos valores siguientes que utiliza el System Log
Viewer:
Capítulo 3 101
CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog
• Pruebe la configuración dando los siguientes pasos:
1. Ejecute /opt/dsau/sbin/syslog-ng con la opción -s o
--syntax-only para comprobar la sintaxis del archivo
/etc/syslog-ng.conf. Éste debería ser un enlace simbólico con
el archivo /etc/syslog-ng.conf.server, tal como se describe
más arriba.
2. Inicie syslog-ng con ayuda del comando
/sbin/init.d/syslog-ng start.
3. Si consolida los archivos syslog locales, utilice logger <mensaje
de prueba> y asegúrese de que este mensaje está en el archivo
syslog.log consolidado. Si no consolida los archivos de registro
locales, utilice el comando logger desde un cliente de reenvío de
archivos de registro. Tenga en cuenta que los mensajes de “logger”
se envían primero al syslog local, que los reenvía a syslog-ng.
syslogd suprime por defecto los mensajes duplicados. Si emite
varios mensajes de prueba de “logger”, asegúrese de que cada uno
de ellos es único.
Configuración manual de un clúster Serviceguard como un

servidor de consolidación de archivos de registro
Los pasos para configurar un clúster Serviceguard como un servidor de
consolidación de archivos de registro son parecidos a los pasos para un
sistema individual. Todos los miembros del clúster deben estar activos y
accesibles antes de continuar.
Cree los archivos de configuración descritos más adelante en todos los
miembros del clúster. El enfoque más sencillo consiste en configurar un
miembro completamente y, a continuación, copiar cada archivo de
configuración en todo el clúster. Las herramientas cexec y ccp pueden
simplificar la reproducción de los cambios en todo el clúster.
Para la configuración de un clúster, syslog-ng se configura como un
paquete para que el servicio de consolidación de archivos de registro
presente alta disponibilidad. El paquete debe llamarse clog y los archivos
de configuración del paquete necesitan la siguiente información:
• La dirección IP y el nombre DNS registrados para el paquete clog

• La subred asociada a esa dirección IP
102 Capítulo 3
• La configuración del almacenamiento en todo el clúster mediante

LVM o VxVM
• Un sistema de archivos configurado en el almacenamiento de todo el
clúster, que puede ser VxFS o CFS. Puesto que los archivos de registro
consolidados aumentan rápidamente de tamaño, HP recomienda que
se configure el sistema de archivos con la opción “largefiles” y que
haya espacio para la ampliación.
Complete el registro de la dirección IP y la configuración del
almacenamiento/sistema de archivos antes de continuar. Para obtener
información adicional sobre cómo crear la configuración del
almacenamiento/sistema de archivos Serviceguard para un paquete,
consulte el manual Managing Serviceguard.
Para obtener una descripción general de cómo configurar el registro
consolidado en un clúster, consulte la sección “Notas sobre la
configuración del clúster” en la página 89.
Paso 1. Si desea que los mensajes del syslog local del propio clúster formen parte
del syslog consolidado, complete las siguientes tareas:
a. Empiece por configurar el componente syslogd estándar para

coexistir con un consolidador syslog-ng. Por defecto, el demonio
syslogd está a la escucha de mensajes de registro entrantes en el
puerto UDP 514. Para utilizar el protocolo UDP o consolidar los
archivos syslog locales de este servidor, syslog-ng deberá escuchar
en el puerto UDP 514. Modifique /etc/rc.config.d/syslogd y
cambie SYSLOGD_OPTS para agregar el modificador -N a fin de impedir
que syslogd escuche en el puerto 514. Por ejemplo:
b. Modifique el archivo /etc/syslog.conf para reenviar los mensajes
de registro al puerto UDP 514 del host local donde syslog-ng los
leerá. Tomando como ejemplo el archivo HP-UX /etc/syslog.conf
por defecto, agregue las siguientes líneas:
mail.debug @<servidor de consolidación de archivos de registro>
*.info;mail.none @<servidor de consolidación de archivos de registro>
donde <servidor de consolidación de archivos de registro> es
el nombre de dominio completo del miembro del clúster local.
El nombre debe estar completo o syslogd no reenviará correctamente
los mensajes.
Capítulo 3 103
Si ha personalizado el archivo syslog.conf, asegúrese de que

también agrega las líneas de reenvío para las personalizaciones.
c. Puesto que /etc/rc.config.d/syslogd es genérico, puede
distribuirse como sigue en todo el clúster con ayuda de ccp:
# cpp /etc/rc.config.d/syslogd /etc/rc.config.d/
d. El archivo /etc/syslog.conf es específico de cada miembro y las
modificaciones descritas más arriba deben realizarse en todos los
e. Al efectuar los cambios anteriores en cada miembro del clúster,
syslogd debe reiniciarse para que dichos cambios surtan efecto.
Utilice cexec para hacerlo en todos los miembros del clúster:
# cexec “/sbin/init.d/syslogd stop;/sbin/init.d/syslogd
start”
Paso 2. Para configurar syslog-ng, empiece con las mismas plantillas de

syslog-ng.conf que las utilizadas por el asistente clog_wizard. En un
miembro del clúster, copie
/opt/dsau/share/clog/templates/syslog-ng.conf.server.template
en /etc/syslog-ng.conf.server. A continuación, copie

/opt/dsau/share/clog/templates/syslog-ng.conf.client.template
en /etc/syslog-ng.conf.client. Ambos archivos tienen signos que se

llaman <%nombre_del_signo%> y que el asistente sustituye según las
respuestas del administrador a las preguntas del asistente.
Sustituya manualmente los signos en /etc/syslog-ng.conf.server

como sigue:
a. Cuando utilice el protocolo TCP y configure el servidor de

consolidación para consolidar sus propios archivos syslog, sustituya
el signo <%UDP_LOOPBACK_SOURCE%> por:
log { source(s_syslog_udp); destination(d_syslog_tcp); };
Esto hace que el consolidador syslog-ng lea los mensajes reenviados
mediante el protocolo UDP del demonio syslogd local y que los envíe
al syslog-ng ubicado en el puerto TCP local. También puede definirse
el destino para que sea directamente el archivo de consolidación local
104 Capítulo 3
(destination(d_syslog) en esta plantilla por defecto), pero la

configuración anterior define los componentes cliente del servidor de
consolidación del mismo modo que un cliente remoto. En otras
palabras, cuando el consolidador es cliente de sí mismo, se configura de
forma idéntica a los clientes remotos.
Si utiliza el protocolo UDP o no consolida los archivos syslog locales
de este clúster, elimine los signos <%UDP_LOOPBACK_SOURCE%> y
b. Sustituya los signos <%TYPE%> por udp o tcp, según el transporte de
archivos de registro deseado que haya de admitirse. Tenga en cuenta
que aun cuando se utilicen clientes TCP, los clientes UDP también se
admiten si se configura la consolidación de los archivos syslog locales
del clúster. Hay varias líneas con el signo <%TYPE%> y todas deben
modificarse apropiadamente.
c. Para la línea “source s_syslog_<%TYPE%>”, sustituya los signos
<%PORT%> y <%KEEP_ALIVE%> por los valores apropiados:
source s_syslog_<%TYPE%> { <%TYPE%>(port(<%PORT%>)
<%KEEP_ALIVE%>); };
Para el transporte mediante el protocolo TCP, el puerto tiene que ser
un puerto TCP disponible en todos los miembros del clúster. Para
obtener un análisis de la selección de un puerto disponible, consulte la
sección “Configuración de un servidor de consolidación de archivos de
registro autónomo con clog_wizard” en la página 80. Para el transporte
mediante el protocolo UDP, utilice el puerto 514.
<%KEEP_ALIVE%> sólo se aplica cuando se selecciona el protocolo TCP
como el transporte de los archivos de registro. Sustituya este signo por
“keep-alive(yes)”, que le da instrucciones a syslog-ng para que
mantenga abiertas las conexiones cuando vuelva a leer su archivo de
configuración. Si utiliza el transporte mediante el protocolo UDP,
elimine este signo.
d. Para la línea destination d_syslog_<%TYPE%>, sustituya los signos
<%IP%> y <%PORT%>:
destination d_syslog_<%TYPE%> { <%TYPE%>(“<%IP%>”
port(<%PORT%>)); };
Por ejemplo, para el transporte mediante el protocolo TCP:
destination d_syslog_tcp { tcp(“IP de paquete” port(1776));
};
Capítulo 3 105
donde el signo <%IP%> se sustituye por la dirección IP del paquete

clog o el nombre de host y el signo <%PORT%> se sustituye por el
número de puerto TCP seleccionado.
Para el transporte mediante el protocolo UDP:
destination d_syslog_udp { udp(“IP de paquete” port(514)); };
donde <%IP%> se sustituye por la dirección IP del paquete “clog” o el
nombre de host local y el signo <%PORT%> se sustituye por 514, el
puerto UDP estándar de syslog.
e. Sustituya el signo <%FS%> por el sistema de archivos o el directorio
donde se vayan a guardar los archivos de registro consolidados. Este
sistema de archivos/directorio es el administrado por el paquete
Serviceguard. Por ejemplo:
destination d_syslog { file(“<%FS%>/syslog/syslog.log”); };
se convierte en:
destination d_syslog { file(“/clog/syslog/syslog.log”); };
Asegúrese de que el punto de montaje de este sistema de archivos
existe en todo el clúster y de que el almacenamiento conmuta
correctamente en todo el clúster si hay algún error. Puesto que los
archivos de registro consolidados pueden llegar a ser bastante
grandes, HP recomienda que este sistema de archivos utilice la opción
“largefiles” y que haya suficiente espacio para la ampliación.
Para obtener información adicional sobre cómo crear la configuración
del almacenamiento/sistema de archivos Serviceguard para un
paquete, consulte el manual Managing Serviceguard.
Paso 3. Sustituya manualmente los signos en /etc/syslog-ng.conf.client
como sigue:
a. Si configura el clúster para consolidar sus propios archivos syslog,

sustituya el signo <%UDP_LOOPBACK_SOURCE%> por:
log { source(s_syslog_udp); destination(d_syslog_<tipo>); };
donde <tipo> es tcp o bien udp, según el transporte de archivos de
registro deseado.
106 Capítulo 3
Esto hace que syslog-ng lea los mensajes reenviados mediante el

protocolo UDP del syslogd local y que los envíe al servidor de
consolidación de archivos de registro.
Si no desea consolidar los archivos syslog locales de este clúster,
elimine los signos <%UDP_LOOPBACK_SOURCE%> y
b. Sustituya todos los signos <%TYPE%> por tcp o bien udp, según el
transporte de archivos de registro deseado.
c. Busque la línea: “destination d_syslog_<%TYPE%>{
<%TYPE%>(“<%IP%>”port(<%PORT>%>)); };.”
Sustituya el signo <%IP%> por la dirección IP del paquete clog. Para el
transporte mediante el protocolo TCP, sustituya <%PORT%> por el
puerto TCP utilizado para el reenvío de archivos de registro
(seleccionado más arriba). Para el transporte mediante el protocolo
UDP, sustituya <%PORT%> por 514, el puerto UDP estándar.
Paso 4. El procedimiento de arranque de syslog-ng, /sbin/init.d/syslog-ng,

se basa en varias variables de configuración. Modifique
/etc/rc.config.d/syslog-ng como sigue:
a. Cambie la línea CLOG_CONFIGURED a:

CLOG_CONFIGURED=1
b. Agregue las siguientes líneas:
CLOG_CONSOLIDATOR=1
Si utiliza el protocolo TCP, agregue:
CLOG_TCP=1
CLOG_TCP_PORT=<puerto tcp elegido para la
consolidación de archivos de registro>
CLOG_TCP=0
CLOG_SYSLOG=1
CLOG_SYSLOG=0
Capítulo 3 107
Si consolida los archivos de registro del paquete de este clúster,

agregue:
CLOG_PACKAGE=1
CLOG_PACKAGE=0
c. Agregue los dos valores siguientes que utiliza el System Log Viewer:
Paso 5. Todos los archivos modificados hasta ahora tienen que distribuirse en
todo el clúster:
# ccp /etc/syslog-ng.conf.server /etc/
# ccp /etc/syslog-ng.conf.client /etc/
# ccp /etc/rc.config.d/syslog-ng /etc/rc.config.d/
Paso 6. Cuando utilice el protocolo TCP, deje constancia del número de puerto que
eligió más arriba en el archivo /etc/services. Por ejemplo, agregue la
línea:
clog_tcp 1776/tcp # Registro consolidado con syslog-ng
Agregue esta línea en /etc/services para cada miembro del clúster.
Creación del paquete “clog”

Para crear el registro consolidado o el paquete clog, empiece por copiar
las plantillas del paquete:
# mkdir /etc/cmcluster/clog
# cd /etc/cmcluster/clog
# cp /opt/dsau/share/serviceguard/templates/clog.conf.template clog.conf
# cp /opt/dsau/share/serviceguard/templates/clog.script.template clog
# chmod +x clog
Tanto el archivo de configuración del paquete clog.conf como la
secuencia de comandos de control del paquete clog tienen que
modificarse para sustituir los signos marcadores por los valores correctos.
Para clog.conf, sólo hay un signo para sustituir: <%SG_PKG_SUBNET%>.
Este signo identifica la subred del paquete. Es igual que el valor de subred
de la secuencia de comandos de control del paquete. Utilice netstat -i
para ayudar a identificar la subred correcta correspondiente a la dirección
IP del paquete.
108 Capítulo 3
Para la secuencia de comandos de control del paquete, clog, efectúe los

cambios descritos a continuación.
La plantilla de secuencia de comandos por defecto da por sentado que se
utiliza una configuración de almacenamiento basado en LVM. Sustituya
según proceda y tal como se indica a continuación los signos relacionados
con el grupo de volúmenes/sistema de archivos para la configuración del
almacenamiento del paquete:
Paso 1. Busque la línea “VG[0]=“<%SG_PKG_VOL_GRP%>”” y sustituya el signo por

el nombre del grupo de volúmenes LVM del paquete. Por ejemplo:
VG[0]=“vgclog”
Si utiliza VxVM, agregue marcas de comentario a la línea del grupo de

volúmenes LVM, VG[0]=”<%SG_PKG_VOL_GRP%>”. Quite la marca de
comentario de la línea “VXVM_DG[0]=” e introduzca el grupo de discos
VxVM.
Paso 2. Busque la línea “LV[0]=“<%SG_PKG_LOG_VOL%>”” y sustituya el signo por

el nombre completo del volumen lógico. Por ejemplo:
LV[0]=“/dev/vgclog/lvol1”
Paso 3. Busque la línea “FS[0]=“<%SG_PKG_FS%>”” y sustituya el signo por el

nombre del sistema de archivos creado para este paquete. Por ejemplo:
FS[0]=“/clog”
Todos los archivos de registro consolidados se ubicarán en este sistema de

archivos. La ubicación específica de los archivos de registro de paquete
consolidados y de los archivos syslog consolidados se especifica en el
archivo /etc/syslog-ng.conf.server. Tomando /clog como ejemplo,
las ubicaciones por defecto basadas en el archivo de plantilla
/etc/syslog-ng.conf.server son:
/clog/syslog/syslog.log
/clog/packages/<nombre_paquete>.log
Paso 4. Busque la línea “FS_MOUNT_OPT[0]=“<%SG_PKG_MNT_OPT%>”: ” y

sustituya el signo por las opciones de montaje del sistema de archivos. Por
ejemplo:
FS_MOUNT_OPT[0]=-o rw,largefiles
Paso 5. Busque la línea “FS_TYPE[0]=“<%SG_PKG_FS_TYPE%>”” y sustituya el

signo por el tipo de sistema de archivos. Por ejemplo:
Capítulo 3 109
FS_TYPE[0]=vxfs
Paso 6. Busque la línea “FS_UMOUNT_OPT[0]=“<%SG_PKG_FS_UMOUNT_OPT%>”” y

sustituya el signo por cualquier opción umount del sistema de archivos. El
signo se puede eliminar y esta opción se puede dejar en blanco si no hay
ninguna opción umount particular. Por ejemplo:
FS_UMOUNT_OPT[0]=“”
Paso 7. Busque la línea “FS_FSCK_OPT[0]=“<%SG_PKG_FS_FSCK_OPT%>”” y

sustituya el signo por cualquier opción “fsck” específica del sistema de
archivos. El signo se puede eliminar y esta opción se puede dejar en
blanco. Por ejemplo:
FS_FSCK_OPT[0]=
Paso 8. Busque la línea “IP[0]=“<%SG_PKG_IP%>”” y sustituya el signo por la

dirección IP del paquete “clog”. Por ejemplo:
IP[0]= 192.119.152.3
Paso 9. Busque la línea “SUBNET[0]=“<%SG_PKG_SUBNET%>”” y sustituya el signo

por la subred de la dirección IP del paquete. Utilice netstat -i para ayudar
a determinar la subred. Por ejemplo:
SUBNET[0]= 192.119.152.0
Ahora tendrá que distribuir los archivos del paquete por todo el clúster.
Para ello, dé los siguientes pasos:
Paso 1. Distribuya los archivos del paquete por todo el clúster. En primer lugar,
cree el directorio del paquete en los demás miembros.
# cexec mkdir /etc/cmcluster/clog
Paso 2. Copie la secuencia de comandos de control del paquete y el archivo de

configuración ASCII del paquete:
# ccp clog clog.conf /etc/cmcluster/clog/
Paso 3. Actualice el archivo /etc/rc.config.d/syslog-ng agregando las

siguientes líneas:
CLOG_PKG_VOL_GRP=<grupo de volúmenes LVM>
CLOG_PKG_LOG_VOL=<volumen lógico (ruta completa)>
CLOG_PKG_FS=<punto de montaje del sistema de archivos donde se
almacenan los archivos de registro consolidados>
CLOG_PKG_MNT_OPT=<opciones de montaje de los sistemas de
110 Capítulo 3
archivos, por ejemplo, -o rw,largefiles>

CLOG_PKG_FS_TYPE=<tipo de sistema de archivos>
CLOG_PKG_IP=<dirección IP del paquete clog>
CLOG_PKG_SUBNET=<subred de la dirección IP del paquete clog>
CLOG_SYSTEM_LOG_CONSOLIDATION_DIR=<punto de montaje del sistema
de archivos/syslog>
CLOG_SERVICEGUARD_PACKAGE_LOG_CONSOLIDATION_DIR=<punto de
montaje del sistema de archivos/paquetes>
CLOG_PKG_RETRY_TIMES=1
CLOG_PKG_MONITOR_INTERVAL=5
Paso 4. Distribúyalo en todo el clúster:

Prueba e inicio del paquete “clog”

Antes de iniciar el paquete, pruebe la configuración realizada hasta
ahora:
Paso 1. Ejecute /opt/dsau/sbin/syslog-ng con la opción -s o --syntax-only

para comprobar la sintaxis de los archivos
/etc/syslog-ng.conf.server y /etc/syslog-ng.conf.client. Para
el nodo adoptivo del paquete, se creará un enlace simbólico llamado
/etc/syslog-ng.conf y este enlace simbólico señalará el archivo
.server. Para el resto de los miembros del clúster, el enlace simbólico
señalará el archivo .client. Puesto que el paquete aún no se ejecuta,
utilice syslog-ng para comprobar explícitamente cada archivo como
sigue:
# /opt/dsau/sbin/syslog-ng --syntax-only --cfgfile /etc/syslog-ng.conf.server
# /opt/dsau/sbin/syslog-ng --syntax-only --cfgfile /etc/syslog-ng.conf.client
Si todas las modificaciones se han realizado correctamente, no debería

mostrarse ningún error.
Paso 2. Inicie syslog-ng en cada miembro del clúster. Cada syslog-ng se

iniciará como un cliente de reenvío de archivos de registro:
# cexec /sbin/init.d/syslog-ng start
Utilice el comando “ps” accesible en el clúster, cps, para validar que se

han iniciado correctamente todos los demonios:
# cps -ef | grep syslog-ng
Capítulo 3 111
Debería ver un demonio syslog-ng ejecutándose en cada miembro del

clúster.
Paso 3. Cree el paquete “clog”:

# cd /etc/cmcluster/clog/
# cmapplyconf -P clog.conf
Serviceguard validará la configuración del paquete e informará de

cualquier error. Subsane los errores y vuelva a intentarlo.
Paso 4. Inicie el paquete “clog”:

# cmmodpkg -e clog
A continuación, utilice “cmviewcl” para asegurarse de que se está

ejecutando:
# cmviewcl -p clog
Si surge algún problema al ejecutar el paquete, compruebe los archivos

/etc/cmcluster/clog/clog.log de cada miembro para contribuir a
solucionarlo.
Paso 5. Compruebe que el reenvío de archivos de registro funciona correctamente.

Si consolida los archivos syslog locales del clúster, utilice “logger
<mensaje de prueba>” y asegúrese de que este mensaje está en el archivo
syslog.log consolidado. Si no consolida los archivos de registro locales,
utilice el comando logger desde un cliente de reenvío de archivos de
registro.
Tenga en cuenta que los mensajes de logger se envían primero al

syslogd local, que los reenvía a syslog-ng. Por defecto, syslogd suprime
los mensajes duplicados. Si emite varios mensajes de prueba de logger,
asegúrese de que cada uno de ellos es único. El mensaje de logger debe
aparecer en el archivo syslog.log consolidado ubicado en el directorio
especificado en el archivo /etc/syslog-ng.conf.server. Según los
ejemplos anteriores, dicho directorio sería /clog/syslog/syslog.log.
Si consolida los archivos de registro de paquetes para este clúster, toda

acción de los paquetes que genere información sobre los archivos de
registro de paquetes, por ejemplo, la conmutación por error de un paquete,
debe hacer que se muestre un archivo de registro consolidado de paquetes
en el archivo /clog/packages.
112 Capítulo 3
Utilización de VxVM en lugar de LVM

La plantilla de secuencia de comandos del paquete “clog” por defecto da
por sentado que se utiliza el almacenamiento basado en LVM. Para, en
cambio, utilizar VxVM, deberá modificar la secuencia de comandos del
paquete clog debajo de /etc/cmcluster/clog/clog. Agregue marcas de
comentario en la línea del grupo de volúmenes LVM, “VG[0]=“xxx””,
quite la marca de comentario de la línea “VXVM_DG[0]=” e introduzca el
grupo de discos VxVM.
Configuración manual de los clientes de reenvío de archivos de

registro
Se puede configurar bien un sistema autónomo o bien un clúster
Serviceguard como clientes de reenvío de archivos de registro. También se
pueden configurar manualmente archivos de registro de paquetes
Serviceguard si existen datos syslog. Para cada caso, se configura tanto
syslogd como syslog-ng.
Configuración manual de un cliente autónomo de reenvío de

Paso 1. Empiece por configurar el componente syslogd estándar para coexistir

con un reenviador syslog-ng.
a. Por defecto, el demonio syslogd está a la escucha de mensajes de

registro entrantes en el puerto UDP 514. Si desea reenviar los archivos
syslog de este sistema, syslog-ng deberá escuchar en el puerto UDP
514. Modifique /etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS
para agregar el modificador -N, que impide que syslogd escuche en el
puerto 514. Por ejemplo:
b. Modifique el archivo /etc/syslog.conf del sistema para reenviar los
mensajes de registro al puerto 514 del host local donde syslog-ng los
leerá. Tomando como ejemplo el archivo HP-UX /etc/syslog.conf
por defecto, agregue las siguientes líneas:
mail.debug @<nombre de host completo>
*.info;mail.none @<nombre de host completo>
donde <nombre de host completo> es el nombre de host completo de
este sistema. El nombre debe estar completo o syslogd no reenviará
correctamente los mensajes.
Capítulo 3 113

c. Detenga y reinicie syslogd para que estos cambios surtan efecto:

syslog-ng.conf que las utilizadas por el asistente clog_wizard.
Copie
/opt/dsau/share/clog/templates/syslog-ng.conf.client.template
en /etc/syslog-ng.conf.client. Este archivo tiene signos que se llaman
<%nombre del signo%> y que el asistente sustituye según las respuestas
del administrador a las preguntas del asistente.
Sustituya manualmente los signos en /etc/syslog-ng.conf.client

como sigue:
a. Si configura el sistema para que reenvíe sus archivos syslog al

servidor de consolidación, sustituya el signo
<%UDP_LOOPBACK_SOURCE%> por:
registro deseado.
Esto hace que syslog-ng lea los mensajes reenviados mediante el
protocolo UDP del syslogd local y que los envíe al servidor de
consolidación de archivos de registro. Si no desea consolidar los
archivos syslog locales de este sistema, elimine los signo
<%UDP_LOOPBACK_SOURCE%> y <%UDP_LOOPBACK_LOG%>.
c. Busque la línea:
“destination d_syslog_<%TYPE%>{<%TYPE%>(“<%IP%>”
port(<%PORT%>)); };”
Si utiliza el protocolo UDP, sustituya <%IP%> por la dirección IP del
servidor de consolidación de archivos de registro y <%PORT%> por 514,
el puerto UDP estándar.
114 Capítulo 3
Si utiliza el protocolo TCP con reenvío a través de un puerto ssh,

sustituya <%IP%> por 127.0.0.1 y <%PORT%> por el puerto elegido para
el reenvío a través de un puerto ssh. A este puerto se aplican las
mismas pautas que para seleccionar un puerto TCP de syslog-ng
libre. Para obtener detalles, consulte la sección “Configuración de un
servidor de consolidación de archivos de registro autónomo con
clog_wizard” en la página 80. La autenticación no interactiva
mediante la herramienta Secure Shell debe configurarse entre este
sistema y el consolidador de archivos de registro (puede utilizar la
herramienta /opt/dsau/bin/csshsetup para la configuración). Para
obtener detalles, consulte la sección “Reenvío a través de un puerto
ssh” en la página 133.
Si utiliza el protocolo TCP sin reenvío a través de un puerto ssh,
sustituya <%IP%> por la dirección IP del servidor de consolidación de
archivos de registro y <%PORT%> por el puerto TCP elegido en el
consolidador de archivos de registro utilizado para la consolidación de
d. Cree el siguiente enlace simbólico:
ln -sf /etc/syslog-ng.conf.client /etc/syslog-ng.conf


CLOG_CONFIGURED=1
CLOG_CONSOLIDATOR=0
CLOG_CONS_IP=<dirección IP del consolidador de archivos de
registro>
c. Si utiliza el protocolo TCP, agregue las siguientes líneas:
CLOG_TCP=1
CLOG_TCP_PORT=<puerto tcp del servidor de consolidación de
archivos de registro>
Si utiliza el reenvío a través de un puerto ssh, agregue:
CLOG_SSH=1
CLOG_SSH_PORT=<puerto ssh elegido>
Capítulo 3 115
en caso contrario, utilice:

CLOG_SSH=0
en caso contrario, si usa el protocolo UDP, utilice:
CLOG_TCP=0
Si consolida los archivos syslog locales, utilice:
CLOG_SYSLOG=1
en caso contrario, utilice:
CLOG_SYSLOG=0
Paso 4. Cuando utilice el protocolo TCP con reenvío a través de un puerto ssh,
deje constancia del número de puerto ssh elegido más arriba en el archivo
/etc/services. Por ejemplo, agregue la línea:
clog_ssh 1776/tcp # Registro consolidado con reenvío a
través de un puerto ssh
Agregue esta línea al archivo /etc/services de este sistema.
Paso 5. Pruebe la configuración dando los siguientes pasos:
a. Ejecute /opt/dsau/sbin/syslog-ng con la opción -s o

/etc/syslog-ng.conf. Éste debería ser un enlace simbólico con el
archivo /etc/syslog-ng.conf.client, tal como se describe más
arriba.
b. Inicie syslog-ng con ayuda del siguiente comando:
# /sbin/init.d/syslog-ng start
c. Si consolida los archivos syslog locales, utilice “logger <mensaje de
prueba>” y asegúrese de que este mensaje está en el archivo
syslog.log consolidado del servidor de consolidación de archivos de
registro. Tenga en cuenta que los mensajes de logger se envían
primero al syslog local, que los reenvía a syslog-ng. syslogd
suprime por defecto los mensajes duplicados. Si emite varios mensajes
de prueba de logger, asegúrese de que cada uno de ellos es único.
116 Capítulo 3
Configuración manual de un clúster Serviceguard como un

cliente de reenvío de archivos de registro
Configurar un clúster Serviceguard como un cliente de reenvío de
archivos de registro es parecido a configurar un sistema individual. Todos
los miembros del clúster deben estar activos y accesibles antes de
continuar. Se configura en primer lugar syslogd y, a continuación,
syslog-ng.
Cree los archivos de configuración descritos más adelante en todos los
miembros del clúster. El enfoque más sencillo consiste en configurar un
miembro completamente y, a continuación, copiar cada archivo de
configuración en todo el clúster. Las herramientas cexec y ccp pueden
simplificar la reproducción de los cambios en todo el clúster.
Paso 1. Si desea que los mensajes de syslog para el clúster se reenvíen al

consolidador de archivos de registro, dé los siguientes pasos:
a. Empiece por configurar el componente syslogd estándar para

coexistir con un reenviador syslog-ng. Por defecto, el demonio
syslogd está a la escucha de mensajes de registro entrantes en el
puerto UDP 514. Para reenviar los archivos syslog de este clúster,
syslog-ng deberá escuchar en el puerto UDP 514. Modifique
/etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS para agregar el
modificador -N: esto impide que syslogd escuche en el puerto 514. Por
ejemplo:
b. Modifique el archivo /etc/syslog.conf del sistema para reenviar los
mensajes de registro al puerto 514 del host local donde syslog-ng los
leerá. Tomando como ejemplo el archivo HP-UX /etc/syslog.conf por
defecto, agregue las siguientes líneas:
donde <nombre de host completo> es el nombre de host completo de
este miembro del clúster. Este nombre debe estar completo o syslogd
no reenviará correctamente los mensajes.
c. syslogd debe detenerse y reiniciarse para que estos cambios surtan
efecto:
Capítulo 3 117
d. Puesto que /etc/rc.config.d/syslogd es genérico, puede
distribuirse en todo el clúster con ayuda de ccp:
# cpp /etc/rc.config.d/syslogd /etc/rc.config.d/
e. El archivo /etc/syslog.conf es específico de cada miembro y las
modificaciones descritas más arriba deben realizarse en todos los
f. Al efectuar los cambios anteriores en cada miembro del clúster,
syslogd debe reiniciarse para que dichos cambios surtan efecto.
Utilice cexec para hacerlo en todos los miembros del clúster:
# cexec “/sbin/init.d/syslogd stop;/sbin/init.d/syslogd
start”

syslog-ng.conf que las utilizadas por el asistente clog_wizard.
En un miembro del clúster, copie

/opt/dsau/share/clog/templates/syslog-ng.conf.client.templat
e en /etc/syslog-ng.conf.client. Este archivo contiene signos que se
llaman <%nombre_del_signo%> y que el asistente sustituye según las
respuestas del administrador a las preguntas del asistente.
Sustituya manualmente los signos en /etc/syslog-ng.conf.client

como sigue:
a. Si configura el clúster para que reenvíe sus archivos syslog al

servidor de consolidación, sustituya el signo
<%UDP_LOOPBACK_SOURCE%> por:
registro deseado. Esto hace que syslog-ng lea los mensajes
reenviados mediante el protocolo UDP del syslogd local y que los
envíe al servidor de consolidación de archivos de registro. Si no desea
consolidar los archivos syslog locales de este clúster, elimine los
signos<%UDP_LOOPBACK_SOURCE%> y <%UDP_LOOPBACK_LOG%>.
118 Capítulo 3
c. Busque la línea:
“destination d_syslog_<%TYPE%>{<%TYPE%>(“<%IP%>”
port(<%PORT%>)); };”
Si utiliza el protocolo UDP, sustituya <%IP%> por la dirección IP del
servidor de consolidación de archivos de registro y <%PORT%> por 514,
el puerto UDP estándar. Si utiliza el protocolo TCP con reenvío a
través de un puerto ssh, sustituya <%IP%> por 127.0.0.1 y <%PORT%>
por el puerto elegido para el reenvío a través de un puerto ssh. A este
puerto se aplican las mismas pautas que para seleccionar un puerto
TCP de syslog-ng libre. Para obtener detalles, consulte la sección
autónomo con clog_wizard” en la página 80. (Tenga en cuenta que el
puerto ssh elegido debe ser un puerto libre en todos los miembros del
clúster.) La autenticación no interactiva mediante la herramienta
Secure Shell debe configurarse entre cada miembro de este clúster y el
consolidador de archivos de registro (puede utilizar la herramienta
/opt/dsau/bin/csshsetup para la configuración). Para obtener
detalles, consulte la sección “Reenvío a través de un puerto ssh” en la
página 133.
Si utiliza el protocolo TCP sin reenvío a través de un puerto ssh,
sustituya <%IP%> por la dirección IP del servidor de consolidación de
archivos de registro y <%PORT%> por el puerto TCP elegido en el
consolidador de archivos de registro utilizado para la consolidación de

CLOG_CONFIGURED=1
CLOG_CONSOLIDATOR=0
CLOG_CONS_IP=dirección IP del consolidador de archivos de
registro
c. Si utiliza el protocolo TCP, agregue las siguientes líneas:
Capítulo 3 119
CLOG_TCP=1
CLOG_TCP_PORT=puerto tcp del servidor de consolidación de
Si utiliza el reenvío a través de un puerto ssh, agregue:
CLOG_SSH=1
CLOG_SSH_PORT=<puerto ssh elegido>
CLOG_SSH=0
CLOG_TCP=0
CLOG_SYSLOG=1
CLOG_SYSLOG=0
Si consolida los archivos de registro del paquete de este clúster,
agregue:
CLOG_PACKAGE=1
CLOG_PACKAGE=0
Paso 4. Todos los archivos modificados hasta ahora tienen que distribuirse en
todo el clúster:
# ccp /etc/syslog-ng.conf.client /etc/
Cree el siguiente enlace simbólico en cada miembro del clúster:

# ln -sf /etc/syslog-ng.conf.client /etc/syslog-ng.conf
Paso 5. Cuando utilice el protocolo TCP con reenvío a través de un puerto ssh,
deje constancia del número de puerto ssh elegido más arriba en el archivo
/etc/services. Por ejemplo, agregue la línea:
clog_ssh 1776/tcp # Registro consolidado con reenvío a través
de un puerto ssh
Agregue esta línea en el archivo /etc/services de cada miembro del

clúster.
120 Capítulo 3
Paso 6. Para consolidar los archivos de registro del paquete de este clúster, hay
que dar pasos manuales adicionales en el servidor de consolidación de
archivos de registro. Cada vez que se crea o elimina un paquete en este
clúster, deben darse dichos pasos. Consulte la sección “Consolidación de
archivos de registro de paquetes en el servidor de consolidación de
archivos de registro” en la página 126.
Paso 7. Pruebe la configuración dando los siguientes pasos:
a. Ejecute /opt/dsau/sbin/syslog-ng con la opción -s o

/etc/syslog-ng.conf. Éste debería ser un enlace simbólico con el
archivo /etc/syslog-ng.conf.client, tal como se describe más
arriba.
b. Inicie syslog-ng en todos los miembros del clúster con ayuda de
# cexec “/sbin/init.d/syslog-ng start”
c. Si consolida los archivos syslog locales, utilice “logger <mensaje de
prueba>” y asegúrese de que este mensaje está en el archivo
syslog.log consolidado del servidor de consolidación de archivos de
registro. Tenga en cuenta que los mensajes de logger se envían
primero al syslog local, que los reenvía a syslog-ng. Por defecto, syslogd
suprime los mensajes duplicados. Si emite varios mensajes de prueba
de “logger”, asegúrese de que cada uno de ellos es único.
Reenvío de datos de registro ASCII

El asistente de registro consolidado (Consolidated Logging Wizard) puede
configurar automáticamente archivos de registro de paquetes
Serviceguard para que se supervisen y reenvíen como si fueran datos de
syslog. Estos archivos de registro son archivos de registro ASCII
estándar. Para las configuraciones manuales, el valor
CLOG_PACKAGE=1, según se describe en la sección “Configuración
manual de un clúster Serviceguard como un cliente de reenvío de archivos
de registro” en la página 117, se ocupa automáticamente del reenvío de
archivos de registro de paquete.
La consolidación de archivos de registro se puede configurar
manualmente para archivos de registro ASCII arbitrarios aplicando los
siguientes procedimientos de:
Capítulo 3 121
• Reenvío de archivos de registro de texto para consolidación

• Consolidación de archivos de registro de texto en el servidor de
consolidación de archivos de registro
Reenvío de Este procedimiento consta de varios pasos:

archivos de
registro de texto 1. Asegúrese de que el sistema se ha configurado como un cliente o
para servidor de consolidación de archivos de registro. (Consulte el archivo
consolidación /etc/rc/config.d/syslog-ng: si CLOG_CONFIGURED=1, el
sistema se ha configurado.) En caso contrario, utilice el asistente de
registro consolidado (Consolidated Logging) o los métodos de
configuración manuales descritos en este documento para configurar
el sistema para la consolidación de archivos de registro.
2. Modifique el archivo /etc/rc.config.d.syslog-ng del sistema.
Para cada archivo de registro ASCII que prevea consolidar, dé los
siguientes pasos:
• Agregue una entrada en la matriz CLOG_TEXT_LOG[],

comenzando en el índice de matriz 0. El valor de la entrada de
matriz debe ser una ruta completa al archivo de registro ASCII.
Por ejemplo:
CLOG_TEXT_LOG[0]=/var/opt/myapp/myapp.log
CLOG_TEXT_LOG[1]=/var/adm/logs/mylog.log
• Por defecto, puesto que cada línea de archivo de registro de texto
se reenvía al consolidador de archivos de registro, los valores de
varios parámetros se agregan previamente a cada registro para
hacer que el registro sea compatible con el formato de registro
syslog.
— Si el sistema forma parte de un clúster Serviceguard, se

agregan previamente los siguientes valores: fecha
marcadehora nombredehost
nombredeclúster_nombredearchivoderegistro
— Si el sistema no forma parte de un clúster Serviceguard, se
agregan previamente los siguientes valores: fecha
marcadehora nombredehost
nombredehost_nombredearchivoderegistro
Esto equivale a especificar lo siguiente:
CLOG_TEXT_FORMAT[n]=”custom”
122 Capítulo 3
Por ejemplo, en el supuesto de que los archivos de registro

myapp.log y mylog.log no estuvieran en el formato syslog, el
ejemplo original podría haberse especificado completamente del
modo siguiente:
CLOG_TEXT_LOG[0]=/var/opt/myapp/myapp.log
CLOG_TEXT_FORMAT[0]=”custom”
CLOG_TEXT_LOG[1]=/var/adm/logs/mylog.log
CLOG_TEXT_FORMAT[1]=”custom”
Si el archivo de texto ya se ha formateado utilizando el formato
compatible con syslog mostrado más arriba, agregue la entrada
CLOG_TEXT_FORMAT[n] correspondiente con un valor de “syslog”.
Por ejemplo,
CLOG_TEXT_LOG[2]=/var/adm/app/logs/app.log
CLOG_TEXT_FORMAT[2]=”syslog”
Si no se realiza ninguna entrada CLOG_TEXT_FORMAT[] para una
entrada CLOG_TEXT_LOG[] correspondiente, el valor por defecto
es “custom”.
Para obtener un ejemplo de un archivo en formato syslog,
consulte el archivo de registro del sistema real
/var/adm/syslog/syslog.log.
3. Después de completar las modificaciones necesarias, hay dos formas
de iniciar el reenvío para los archivos de registro nuevos:
• Reiniciando syslog-ng (recomendado, si no se trata de un

entorno de producción)
• Mediante un reinicio manual, que no interrumpa syslog-ng
Los procedimientos son:
• Reinicie syslog-ng. Por ejemplo, ejecute el siguiente comando:

/sbin/init.d/syslog-ng restart
Esto interrumpirá syslog-ng y puede causar la pérdida de los
mensajes que se estén enviando o consolidando. Si el sistema no es
un entorno de producción, y la pérdida de algunos mensajes es
asumible, este método es preferible a utilizar el reinicio natural
que entraña mayor dificultad.
• Inicie manualmente el proceso clog_tail para el archivo de
registro de texto.
Capítulo 3 123
Si el archivo de registro de texto está en el formato syslog, utilice

el siguiente comando:
/opt/dsau/bin/clog_tail -q -n 0 -p
ruta_archivo_registro
Si el archivo de registro de texto está en un formato personalizado,

utilice el siguiente comando:
/opt/dsau/bin/clog_tail -q -n 0 -p -a
ruta_archivo_registro
donde ruta_archivo_registro es la ruta completa al archivo de
registro ASCII.
Por ejemplo, para un archivo de registro denominado myapp.log
en un formato personalizado, el siguiente comando inicia
clog_tail:
# /opt/dsau/bin/clog_tail -q -n 0 -p -a
/var/opt/myapp/myapp.log
Si el sistema es un clúster Serviceguard, copie el archivo
/etc/rc.config.d/syslog-ng modificado en todo el clúster con
el siguiente comando:
Reinicie syslog-ng o bien inicie el proceso clog_tail del
text-log en todos los nodos del clúster.
Consolidación de Para consolidar los archivos de registro de texto reenviados desde los
archivos de clientes a un servidor de consolidación de archivos de registro, complete
registro de texto las siguientes tareas en el servidor de consolidación de archivos de
en el servidor de registro:
consolidación de
archivos de 1. Para cada archivo de registro de texto que se vaya a reenviar desde un
registro cliente, agregue las siguientes líneas de destino (destination), filtro
(filter) y archivo de registro (log) en el archivo
syslog-ng.conf.server, después de la sección
HP_AUTOMATED_LOG_FILE_CONSOLIDATION:
Para la línea de destino (destination):
destination d_nodo1_texto1 {
file(“sa/dirtext/nodo1_texto1.log”); };
Para la línea de filtro (filter):
filter f_nodo1_texto1 { program(nodo1_texto1.log); };
124 Capítulo 3
Para la línea de archivo de registro (log):

log { source(s_syslog_tipo); filter
(f_nodo1_texto1);destination(d_nodo1_texto1);
flags(final);};
donde texto1 es el nombre de archivo de registro de texto, nodo1 es
la dirección IP reubicable (para un clúster Serviceguard) o el
nombre_host (para un clúster que no sea Serviceguard) que reenvía
este archivo de registro de texto, sa es el sistema de archivos del
consolidador de archivos de registro donde se almacenarán los
archivos de registro consolidados, tipo es la definición de “s_source”
(_tcp o _udp, según el transporte de archivos de registro
seleccionado) y dirtext es el nombre del directorio donde se prevé
almacenar todos los archivos de registro de texto.
2. Si el consolidador de archivos de registro es un clúster Serviceguard,
asegúrese de que copia el archivo /etc/syslog-ng.conf.server
modificado en todo el clúster con el siguiente comando:
3. Utilice sighup syslog-ng en el consolidador de archivos de registro
para que vuelva a leer su archivo de configuración. (sighup es un
método de UNIX para reiniciar un proceso.) En un consolidador de
archivos de registro Serviceguard, utilice sighup syslog-ng sólo en el
nodo adoptivo del paquete clog.
Detención de la Para detener la consolidación de archivos de registro de texto, complete

consolidación de las siguientes tareas para cada sistema donde prevea detener la
archivos de consolidación de archivos de registro:
registro de texto
1. Modifique el archivo /etc/rc.config.d/syslog-ng del sistema.
Para cada archivo de registro ASCII cuya consolidación prevea
detener, dé los siguientes pasos:
• Elimine CLOG_TEXT_LOG[] y la entrada

CLOG_TEXT_FORMAT[] correspondiente de dicho archivo de
registro de texto, si está presente.
Por ejemplo, para detener la consolidación del archivo de registro

de texto myapp.log, elimine las siguientes entradas en el archivo
/etc/rc.config.d/syslog-ng:
CLOG_TEXT_LOG[4]=/var/opt/myapp.log
CLOG_TEXT_FORMAT[4]=”syslog”
Capítulo 3 125
2. Después de efectuar las modificaciones necesarias, reinicie

syslog-ng mediante el comando: /sbin/init.d.syslog-ng
restart de modo que los cambios del archivo
/etc/rc/config.d/syslog-ng surtan efecto.
Si el sistema es un clúster Serviceguard, copie el archivo

/etc/rc.config.d/syslog-ng modificado en todo el clúster con el
siguiente comando:
Reinicie syslog-ng en todos los nodos del clúster.
3. Para cada archivo de registro de texto que se elimine en un cliente que
reenvíe sus archivos de registro de texto, elimine las líneas de destino
(destination), filtro (filter) y archivo de registro (log) correspondientes
en el archivo /etc/syslog-ng.conf.server del consolidador de
archivos de registro. Debe utilizarse el método sighup con syslog-ng
en el consolidador de archivos de registro para que vuelva a leer este
archivo de configuración.
En un consolidador de archivos de registro Serviceguard, el archivo

/etc/syslog-ng.conf.server actualizado deberá distribuirse en
todo el clúster. No obstante, sólo tiene que utilizarse sighup con
syslog-ng en el nodo adoptivo del paquete clog.
Consolidación de archivos de registro de paquetes en el servidor

de consolidación de archivos de registro
Cuando clústeres Serviceguard remotos reenvían datos de registro de
paquetes a un servidor de consolidación de archivos de registro, el valor
por defecto es colocar todos los mensajes de archivos de registro
reenviados del archivo syslog.log consolidado en el servidor de
consolidación. Puede resultar mucho más práctico colocar estos mensajes
en archivos de registro de paquete consolidados específicos del clúster que
en el archivo syslog.log consolidado. Esto se puede conseguir aplicando
las reglas de filtrado de syslog-ng como sigue:
Paso 1. Para cada paquete que se vaya a reenviar desde un cliente del clúster,
agregue las siguientes líneas de destino (destination), filtro (filter) y
archivo de registro (log) en el archivo syslog-ng.conf.server, después
de la sección HP_AUTOMATED_LOG_FILE_CONSOLIDATION.
126 Capítulo 3
destination d_<clu1>_<pqte1> { file(“<sa>/packages/<clu1>_<pqte1>.log”); };

filter f_<clu1>_<pqte1> { program(<clu1>_<pqte1>.log); };
log { source(s_syslog_<tipo>);
filter(f_<clu1>_<pqte1>);destination(d_<clu1>_<pqte1>); flags(final);};
donde <pqte1> es el nombre del paquete, <clu1> es la dirección IP

reubicable del paquete que reenvía este archivo de registro de paquete,
<tipo> es _tcp o _udp, según el transporte de archivos de registro
seleccionado, y <sa> es el sistema de archivos del consolidador de archivos
de registro donde se almacenarán los archivos de registro consolidados.
Paso 2. Si el consolidador de archivos de registro es un clúster Serviceguard,

asegúrese de que copia el archivo /etc/syslog-ng.conf.server
modificado en todo el clúster como sigue:
Paso 3. Utilice sighup syslog-ng en el consolidador de archivos de registro para

que vuelva a leer su archivo de configuración. (sighup es un método de
UNIX para reiniciar un proceso.) En un consolidador de archivos de
registro Serviceguard, utilice sighup syslog-ng sólo en el nodo adoptivo
del paquete clog.
Paso 4. Para cada paquete que se elimine en un cliente de clúster que reenvíe sus
archivos de registro de paquete, elimine las líneas de destino
(destination), filtro (filter) y archivo de registro (log) correspondientes en
el archivo /etc/syslog-ng.conf.server del consolidador de archivos de
registro. Debe utilizarse el método sighup con syslog-ng en el
consolidador de archivos de registro para que vuelva a leer este archivo de
configuración. En un consolidador de archivos de registro Serviceguard, el
archivo /etc/syslog-ng.conf.server actualizado tendrá que
distribuirse en todo el clúster. No obstante, sólo tiene que utilizarse
sighup con syslog-ng en el nodo adoptivo del paquete clog.
Capítulo 3 127
Deshabilitación de la consolidación de archivos de registro
Deshabilitación de la consolidación de
El asistente clog_wizard habilita las configuraciones de la consolidación
de archivos de registro, pero no cuenta con una opción de anulación de la
configuración o de desconfiguración. Por tanto, la participación de un
sistema en la consolidación de archivos de registro deberá deshabilitarse
manualmente conforme a las siguientes instrucciones.
Deshabilitación de un sistema de consolidación de

archivos de registro autónomo
Dé los siguientes pasos para deshabilitar la consolidación de archivos de
registro:
Paso 1. Si los archivos syslog locales se consolidaban, o se utilizaba el protocolo

UDP, modifique /etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS
para eliminar el modificador -N. Por ejemplo, realice la siguiente
modificación:
SYSLOGD_OPTS=“-D”
Paso 2. Si los archivos syslog locales se consolidaban, modifique también el

archivo /etc/syslog.conf del sistema para eliminar las siguientes
líneas:
donde <nombre de host completo> es el nombre de host completo de este

sistema.
Paso 3. Reinicie syslogd con ayuda de los siguientes comandos:

#/sbin/init.d/syslogd stop
#/sbin/init.d/syslogd start
Paso 4. Detenga syslog-ng:

# /sbin/init.d/syslog-ng stop
128 Capítulo 3
Paso 5. Modifique el archivo /etc/rc.config.d/syslog-ng como sigue:
a. Cambie la línea CLOG_CONFIGURED a CLOG_CONFIGURED=0.

b. Quite las demás líneas CLOG, excepto las siguientes:
Paso 6. Si se utilizaba el protocolo TCP, elimine la siguiente línea en el archivo

/etc/services:
clog_tcp <puerto>/tcp # Registro consolidado con syslog-ng
Deshabilitación de un sistema de consolidación de

archivos de registro de un clúster Serviceguard
Dé los siguientes pasos para deshabilitar la consolidación de archivos de
registro en un clúster Serviceguard. Estos pasos deben darse en cada
miembro del clúster:
Paso 1. Si los archivos syslog locales se consolidaban, o se utilizaba el protocolo

UDP, modifique /etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS
para eliminar el modificador-N. Por ejemplo:
SYSLOG_OPTS="-D"

Paso 3. Si los archivos syslog locales se consolidaban, modifique el archivo

/etc/syslog.conf del sistema para eliminar las siguientes líneas:

sistema. Fíjese en que a cada signo de arroba, @, le precede una
<tabulación>.
Paso 4. Detenga el paquete clog con el comando:
#/usr/sbin/cmhaltpkg clog
Capítulo 3 129
Paso 5. Detenga syslog-ng con ayuda del siguiente comando:

(Tenga en cuenta que esto detiene el demonio syslog-ng y la

consolidación de archivos de registro de paquetes, si está configurada.)
Paso 6. Modifique el archivo /etc/rc.config.d/syslog-ng y cambie la línea

CLOG_CONFIGURED como sigue:
CLOG_CONFIGURED=0
Quite las demás líneas CLOG, excepto:

Paso 7. Elimine el paquete “clog” con el siguiente comando:

# cmdeleteconf -p clog
Deshabilitación de un cliente de reenvío de archivos

de registro autónomo
Dé los siguientes pasos para deshabilitar el reenvío de archivos de
registro en un cliente autónomo:
Paso 1. Si se reenviaban mensajes de syslog al consolidador de archivos de

registro, modifique /etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS
para eliminar el modificador -N. Por ejemplo:
SYSLOGD_OPTS=“-D”
Paso 2. Modifique el archivo /etc/syslog.conf del sistema para quitar las

siguientes líneas:

sistema. Fíjese en que hay una <tabulación> antes de cada signo de
arroba, @.
130 Capítulo 3
Paso 4. Detenga syslog-ng con ayuda del siguiente comando:

(Tenga en cuenta que esto detendrá el demonio syslog-ng y también el

reenvío a través de un puerto ssh, si estaba configurado.)

CLOG_CONFIGURED como sigue:
CLOG_CONFIGURED=0
Quite las demás líneas CLOG, excepto las siguientes:

Paso 6. Si el reenvío a través de un puerto ssh estaba configurado, quite la

siguiente línea en el archivo /etc/services:
clog_ssh <puerto>/tcp # Registro consolidado con reenvío a
Deshabilitación de un cliente de reenvío de archivos

de registro de un clúster Serviceguard
Dé los siguientes pasos para desconfigurar el reenvío de archivos de
registro. Estos pasos tienen que darse en cada miembro del clúster:
Paso 1. Si se reenviaban mensajes de syslog al consolidador de archivos de

registro, modifique /etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS
para eliminar el modificador -N. Por ejemplo, SYSLOGD_OPTS=“-D”.
Paso 2. Modifique el archivo /etc/syslog.conf del sistema para quitar las

siguientes líneas:

sistema.
Paso 3. Detenga y reinicie syslogd con ayuda de los siguientes comandos:

Capítulo 3 131
Paso 4. Detenga syslog-ng:

(Tenga en cuenta que esto detendrá el demonio syslog-ng, el reenvío a

través de un puerto ssh, si estaba configurado, y el reenvío de archivos de
registro de paquetes, si estaba configurado.)

CLOG_CONFIGURED por CLOG_CONFIGURED=0. Quite las demás líneas CLOG,
excepto las siguientes:
Paso 6. Si el reenvío a través de un puerto ssh estaba configurado, quite la

siguiente línea en el archivo /etc/services:
clog_ssh <puerto>/tcp # Registro consolidado con reenvío a
132 Capítulo 3
Seguridad de los archivos de registro consolidados
Seguridad de los archivos de registro

consolidados
En un sistema HP-UX estándar, todos los usuarios ven el archivo
/var/adm/syslog/syslog.log local del sistema. El acceso a los archivos
de registro consolidados normalmente está restringido. El propio sistema
servidor de consolidación de archivos de registro habitualmente es un sis-
tema de acceso restringido con estrictas directrices de seguridad en vigor.
Medidas de protección de los archivos de registro

Un grado de protección abarca los permisos de los propios archivos de
registro consolidados. Esto se controla por medio del archivo sys-
log-ng.conf.server. Se pueden especificar permisos específicos para
cada destino del “archivo” syslog-ng. Si no existe el directorio de registro
para un archivo consolidado, se le pueden dar instrucciones a syslog-ng
para que lo cree (create_dirs(yes)) y definir la titularidad del directorio,
así como los permisos correspondientes al directorio. Por ejemplo:
destination d_file { file(“/clog/test/example.log” );
dir_owner(root);
dir_group(sys);
dir_perm(0600);
owner(root);
group(sys);
perm(0600);
};
Reenvío a través de un puerto ssh

El reenvío a través de un puerto ssh configura un túnel para el tráfico de
archivos de registro entre el cliente de reenvío de archivos de registro de
syslog-ng y el servidor de consolidación de archivos de registro de
syslog-ng. Este túnel basado en ssh sólo está disponible cuando se
utiliza el transporte mediante el protocolo TCP, no el transporte mediante
el protocolo UDP. Tampoco se utiliza el reenvío a través de un puerto ssh
cuando se reenvía el tráfico de archivos de registro en el marco de un
clúster Serviceguard (de un miembro a otro). Para el tráfico de archivos de
registro intraclúster, se utiliza el transporte mediante el protocolo TCP o
UDP estándar.
Capítulo 3 133
El reenvío a través de un puerto ssh es transparente para syslog-ng.

El archivo /etc/syslog-ng.conf.client se configura de modo que
syslog-ng reenvíe el tráfico de archivos de registro a un puerto local
administrado por ssh. El puerto ssh local conecta con el demonio sshd
remoto en el servidor de consolidación de archivos de registro y sshd abre
el puerto TCP de syslog-ng estándar. La consolidación de archivos de
registro remota cree que tiene un cliente de reenvío de archivos de registro
estándar y no es consciente de la realización del túnel.
Un problema con la definición del túnel basado en ssh está relacionado
con los errores del servidor de consolidación de archivos de registro. Si el
servidor de syslog-ng se detiene o se bloquea, los túneles ssh remotos se
desconectan. Los túneles ssh cliente volverán a intentar la conexión a
intervalos de un minuto. El tiempo de reconexión es configurable.
Cada intento de reconexión infructuoso se registra en el archivo
syslog.log local del cliente. Durante este tiempo, el archivo de registro
de cliente (/var/adm/syslog/syslog-ng.log) de syslog-ng mostrará a
éste tratando de volver a conectar con el túnel. El tiempo de reconexión
por defecto es de 10 segundos. Este valor se puede configurar con ayuda
del ajuste global “time_reopen(<segundos>)” de syslog-ng. Para
obtener detalles, consulte el manual de referencia de código fuente abierto
de syslog-ng (/opt/dsau/doc/syslog-ng).
Reenvío a través Cuando se utiliza el reenvío a través de un puerto ssh teniendo como
de un puerto ssh a servidor de consolidación de archivos de registro un clúster Serviceguard,
un consolidador se precisa una configuración especial de ssh.
de archivos de
En general, el uso del reenvío a través de un puerto ssh necesita que el
registro de un
servidor de consolidación de archivos de registro efectúe un intercambio
clúster
de claves con el cliente de reenvío de archivos de registro. En concreto, la
Serviceguard
clave pública de ssh para el cliente de reenvío de archivos de registro
remoto debe agregarse en el archivo de claves autorizadas del servidor de
consolidación. Además, se agrega la huella dactilar correspondiente al
servidor de consolidación de archivos de registro en el archivo
/.ssh/known_hosts del cliente de reenvío de archivos de registro.
El reenviador de archivos de registro cliente es un sistema de confianza
después de este intercambio de claves y el servidor de consolidación no
necesita solicitar ninguna contraseña ssh al llegar a este punto.
134 Capítulo 3
Puesto que el servidor de consolidación es un paquete, en potencia puede

ejecutarse en todos los miembros del clúster. Este intercambio de claves
entre el cliente de reenvío de archivos de registro remoto y un miembro del
clúster debe repetirse para cada miembro del clúster. Cada miembro del
clúster tiene que establecer la misma relación de confianza con los clientes
de reenvío de archivos de registro.
Puede surgir un problema con las huellas dactilares del archivo
known_host del cliente de reenvío de archivos de registro. Al utilizar una
dirección IP reubicable de un paquete para el intercambio de claves ssh
inicial, se agregará la huella dactilar del nodo adoptivo en el archivo
/.ssh/known_hosts local del cliente. Cuando el paquete realice una
conmutación por error y la conexión ssh se restablezca, el nuevo nodo
adoptivo tendrá una huella dactilar diferente y ssh detectará esto como
un ataque “man-in-the-middle” (hombre en el medio) y se negará a
restablecer el túnel ssh.
Para evitarlo, debe parecer que cada miembro del clúster es el mismo
sistema desde el punto de vista de los clientes de reenvío de archivos de
registro. Esto se puede conseguir haciendo que cada miembro del clúster
utilice una clave de host idéntica. Las claves de host de ssh se ubican en
el directorio /opt/ssh/etc y las contienen los siguientes archivos:
• ssh_host_key
• ssh_host_key.pub
• ssh_host_dsa_key
• ssh_host_dsa_key.pub
• ssh_host_rsa_key
• ssh_host_rsa_key.pub
Elija uno de los miembros del clúster y copie estos archivos en el mismo
directorio ubicado en los demás miembros del clúster. El uso de la
herramienta “cluster copy” o ccp agiliza esta acción:
# cd /opt/ssh/etc/
# ccp ssh_host_* /opt/ssh/etc/
A continuación, en cada cliente de consolidación de archivos de registro,
efectúe un intercambio de claves ssh estándar con la dirección IP
reubicable del paquete clog. Una forma de hacerlo consiste en utilizar la
herramienta csshsetup (consulte la página de manual de csshsetup (1))
como sigue:
Capítulo 3 135
# csshsetup <nombre DNS del paquete clog>

csshsetup solicitará la contraseña del clúster para efectuar el
intercambio de claves inicial.
Uso del puerto de red de clog

syslog y syslog-ng necesitan que haya disponibles puertos de red
específicos para que el funcionamiento sea correcto. Estos puertos son:
• UDP 514: Este puerto lo utilizan los clientes de syslogd para

reenviar mensajes de registro.
• Puerto TCP <puerto seleccionado>: El administrador elige qué puerto
TCP utiliza un consolidador de archivos de registro de syslog-ng
para recibir mensajes.
• Puerto TCP 22: Al utilizar el reenvío a través de un puerto ssh para
crear túneles cifrados, los clientes remotos establecen comunicación
con el demonio sshd del servidor de consolidación de archivos de
registro. En una configuración por defecto, dicho demonio escucha en
el puerto TCP 22.
Utilización de Bastille para fortalecer el sistema

Bastille es una herramienta de cierre para el fortalecimiento de la
seguridad que se puede utilizar para aumentar la seguridad del sistema
operativo HP-UX. Ofrece cierre personalizado sistema a sistema al
permitir al administrador elegir qué características de seguridad han de
habilitarse o deshabilitarse en las listas de comprobación de
fortalecimiento/cierre.
Bastille se puede utilizar para fortalecer un servidor de consolidación de
archivos de registro habilitando herramientas de seguridad, por ejemplo,
el filtrado IP. Si el filtrado IP está habilitado, los puertos descritos en la
sección “Uso del puerto de red de clog” en la página 136 no deben
bloquearse.
Asimismo, Bastille plantea las siguientes preguntas que repercuten en un
sistema de consolidación de archivos de registro:
Do you want to BLOCK incoming Secure Shell connections with
IPFilter?
136 Capítulo 3
Al configurar un servidor de consolidación de archivos de registro,

conteste No a la pregunta si prevé admitir clientes que utilicen las
conexiones con el servidor utilizando transporte mediante el protocolo tcp
y el túnel configurado por ssh.
Would you like to restrict the system logging daemon to local
connections?
Al contestar sí (“yes”) a esta pregunta, se agrega la opción -N a
/etc/syslog.conf. Al configurar un servidor de consolidación de
archivos de registro, se necesita esta opción. El asistente clog_wizard la
agrega automáticamente; las instrucciones de la configuración manual
también explican las modificaciones apropiadas de /etc/syslog.conf.
Capítulo 3 137
Consulta de los archivos de registro consolidados
Consulta de los archivos de registro

consolidados
Utilice el visor System Log Viewer de System Management Homepage
para filtrar y ver los archivos de registro syslog locales de un sistema.
Para un sistema que también sea consolidador de archivos de registro,
System Log Viewer también filtra y muestra los archivos de registro
consolidados.
Inicio de System Management Homepage

Para iniciar una sesión en System Management Homepage, obtenga
acceso a:
http://nombrehost:2301
Escriba un nombre de usuario y una contraseña. El inicio de sesión
habilitado por defecto es el del usuario root. Para obtener información
adicional sobre el arranque de System Management Homepage y el inicio
de una sesión en esta interface, consulte el documento HP Systems
Management Homepage User Guide.
Después de iniciar una sesión en System Management Homepage,
seleccione la ficha Logs y, a continuación, “System Log Viewer”.
138 Capítulo 3
Utilización del System Log Viewer

System Log Viewer mostrará los archivos de registro relacionados con
syslog para el sistema. Por defecto, dichos archivos incluyen los archivos
de registro locales para el sistema procedentes de /var/adm/syslog. Si
este sistema es, además, consolidador de archivos de registro, los archivos
de registro consolidados también se mostrarán.
NOTA En un clúster Serviceguard configurado como servidor de consolidación de

archivos de registro, los archivos de registro consolidados se colocan en el
sistema de archivos asociado al paquete “clog”. Para obtener detalles,
consulte la sección “Notas sobre la configuración del clúster” en la
página 89. Cuando se utilizan las configuraciones de conmutación por
error de almacenamiento LVM y VxVM, esto significa que a los archivos
de registro consolidados sólo puede obtener acceso un miembro del clúster
a la vez. Cuando se utiliza la técnica http://nombre_host:2301 para
iniciar SMH en un clúster, el administrador tiene que saber qué miembro
del clúster alberga actualmente el paquete y debe utilizar dicho nombre
de host en la dirección URL.
Afortunadamente, hay una solución más sencilla. System Management
Homepage admite direcciones IP virtuales como las utilizadas por los
paquetes Serviceguard. Esto permite al administrador utilizar la
dirección IP o el nombre DNS virtual del paquete en la dirección URL de
inicio automático (http://dirección_IP_virtual:2301) para iniciar
el visor en el sistema que albergue los archivos de registro consolidados.
Para obtener información adicional, consulte el documento HP Systems
Management Homepage User Guide.
Seleccione un archivo de registro para ver en la ficha principal Select.

Utilice la ficha Filter para especificar expresiones de filtro a fin de buscar
entradas específicas y, a continuación, seleccione la ficha Display para ver
el contenido del archivo de registro. Para obtener información adicional
sobre el uso del visor System Log Viewer, utilice la ayuda en línea que se
facilita en la aplicación.
Capítulo 3 139
140 Capítulo 3
4 Cargabilidad de salida de
comandos
Las utilidades de cargabilidad de salida de comandos (Command Fanout)
permiten al administrador del sistema reproducir los comandos del shell
en varios sistemas. Tradicionalmente, los administradores han creado
empaquetadores (“wrappers”) en torno a protocolos como remote shell
(consulte la página de manual de remsh (1)) y secure shell (consulte la
página de manual de ssh (1)) para proporcionar funciones de cargabilidad
de salida de comandos.
Capítulo 4 141
Cargabilidad de salida de comandos
Parallel Distributed Shell

El conjunto de utilidades Distributed Systems Administration Utilities
(DSAU) incluye la herramienta de código fuente abierto Parallel
Distributed Shell (pdsh). pdsh formaliza el uso de remsh y ssh para
distribuir comandos entre los grupos de sistemas. A diferencia de los
empaquetadores remsh/ssh, pdsh ofrece las siguientes ventajas:
• Alto rendimiento
Los comandos se ejecutan en paralelo a los grupos del sistema de
destino. pdsh admite una ventana deslizante o ajuste de cargabilidad
de salida (“fanout”) para controlar el número de comandos
concurrentes.
• Valores de tiempo de espera de comandos
pdsh admite un tiempo de espera de ejecución de comandos que
controla cuánto tiempo se puede ejecutar un comando remoto antes de
ser desconectado (para evitar el problema de los comandos que se
quedan enganchados). También admite un tiempo de espera de
conexión que impide el bloqueo cuando los sistemas remotos están
inaccesibles.
• Procesamiento de la salida y estado de retorno
pdsh maneja correctamente el procesamiento de “stdout” y “stderr”, y
admite la devolución de un estado de retorno “peor” para que el que
llama pueda detectar errores de los sistemas remotos.
• Especificaciones flexibles del sistema de destino
pdsh admite varios mecanismos para especificar los sistemas host de
destino en los que trabajar. Se pueden especificar en la línea de
comandos, en stdin, en un archivo conocido (/etc/machines) o en un
archivo señalado por la variable de entorno WCOLL. Asimismo, se
pueden excluir de la línea de comandos sistemas específicos.
• Expresiones de listas de hosts
Para los grupos de sistemas que utilizan una convención de
nomenclatura prefijoNNN (por ejemplo, h1, h2, ..., hN), pdsh permite
especificar los nodos de destino mediante expresiones de listas de
hosts, por ejemplo, “h[1-10]”, que distribuiría un comando a los hosts
denominados h1 a h10.
142 Capítulo 4
• Filtrado inteligente de la salida

pdsh introduce cada línea de salida con el nombre de host del sistema
de origen. dshbak (consulte la página de manual de dshbak (8)) es un
filtro que puede dar formato a la salida de pdsh estándar de varias
formas diferentes. El indicador dshbak -c busca la salida de
diferentes hosts que sea idéntica y la consolida en lugar de duplicarla.
El encabezado indicará los hosts a los que se aplica la salida
consolidada.
• Opción de transporte de comandos
pdsh puede utilizar el protocolo remote shell rcmd (consulte la página
de manual de rcmd (3)) o bien el protocolo ssh como medio de
transporte de comandos. Tenga en cuenta que el transporte mediante
ssh ofrece una seguridad muy mejorada. Para obtener detalles,
consulte la sección “Configuración de la seguridad” en la página 147.
• Comando de copia paralela
El comando pdcp aporta un comando de copia paralela que sirve para
copiar un archivo de origen local en varios destinos.
La figura 4-1, “Arquitectura de la herramienta pdsh” muestra los
componentes de pdsh y su arquitectura.
Capítulo 4 143
Figura 4-1 Arquitectura de la herramienta pdsh
Para obtener más información sobre pdsh y dshbak, consulte las páginas
de manual de referencia correspondientes.
144 Capítulo 4
Empaquetadores de utilidades para pdsh

Los administradores pueden crear comandos empaquetadores
(“wrappers”) en torno a pdsh para los comandos que se utilicen con
frecuencia en varios sistemas y clústeres Serviceguard. Se facilitan varios
comandos empaquetadores de este tipo con las herramientas DSAU. Estos
empaquetadores son compatibles con los clústeres Serviceguard y
adoptan como valor por defecto la cargabilidad de salida (“fanout”) en todo
el clúster cuando se utilizan en un entorno Serviceguard. Asimismo,
admiten la mayoría de las opciones de línea de comandos estándar de
pdsh y las opciones largas (sintaxis --opción).
cexec cexec es un empaquetador pdsh polivalente. Además de
las características de pdsh estándar, cexec incluye una
característica de generación de informes. Utilice la
opción --report_loc para que cexec muestre la
ubicación del informe de un comando. El informe del
comando deja constancia del comando ejecutado,
además de los nodos donde el comando se ejecutó
fructuosa o infructuosamente, o de los nodos que
estaban inaccesibles. El informe se puede utilizar con la
opción --retry para reproducir el comando en relación
con los nodos que dieron error, que se ejecutaron
fructuosamente o que estaban inaccesibles, o en
relación con todos los nodos.
ccp ccp es un empaquetador para pdcp y copia los archivos
en todo el clúster o en el conjunto de sistemas
especificado.
cps cps distribuye un comando ps en un conjunto de
sistemas o un clúster.
ckill ckill permite al administrador señalar un proceso por
el nombre, puesto que la identificación de proceso (pid)
de un proceso específico variará en un conjunto de
sistemas o entre los miembros de un clúster.
cuptime cuptime muestra las estadísticas relativas al tiempo de
actividad de un conjunto de sistemas o de un clúster.
cwall cwall muestra un mensaje de difusión de wall(1M) en
varios sistemas host.
Capítulo 4 145
Todos los empaquetadores admiten la variable de entorno

CFANOUT_HOSTS cuando no se ejecutan en un clúster Serviceguard. La
variable de entorno especifica un archivo que contiene la lista de hosts a
los que enfocar, un nombre de host por línea. Este archivo se utilizará si en
la línea de comandos no hay ninguna otra especificación de host. Cuando
no se utiliza ninguna opción de línea de comandos nodelist de destino y
CFANOUT_HOSTS no está definida, el comando se ejecuta en el host
local.
Para obtener más información sobre estos comandos, consulte las páginas
de manual de referencia correspondientes.
146 Capítulo 4
Configuración de la seguridad
Las herramientas de cargabilidad de salida de comandos (Command
Fanout) admiten tanto el transporte mediante remote shell (rsh o rcmd)
como el transporte mediante ssh. Cada transporte requiere dar unos
pasos de configuración de la seguridad concretos para autorizar el inicio
por parte del usuario de la operación de cargabilidad de salida de
comandos a fin de ejecutar un comando en los sistemas de destino
remotos. Las herramientas de cargabilidad de salida de comandos
necesitan que el sistema remoto no solicite una contraseña. Ambos
transportes, rsh y ssh, deben preconfigurarse en cada sistema remoto
para posibilitar el acceso no interactivo. En las siguientes secciones se
describen los pasos de configuración necesarios para habilitar las
operaciones de cargabilidad de salida de comandos para cada transporte.
Configuración de Cuando se utiliza el transporte de comandos mediante el protocolo remote

seguridad de shell, el usuario local debe tener configurado un archivo $HOME/.rhosts
remote shell en cada sistema de destino remoto. Consulte la página de manual de
referencia de rhosts (4) para obtener detalles sobre la configuración del
archivo $HOME/.rhosts.
Configuración de ssh utiliza claves de host públicas para autenticar los hosts remotos y
seguridad de ssh admite la autenticación de claves públicas para autenticar usuarios.
Cuando las claves públicas de los usuarios están configuradas
correctamente en un conjunto de sistemas remotos, los usuarios pueden
tener acceso a dichos sistemas sin que se les pida una contraseña.
Configurar manualmente ssh para el acceso no interactivo es un proceso
que consta de varios pasos y en que los archivos de configuración de ssh se
modifican en cada sistema. La herramienta csshsetup simplifica
enormemente la configuración de las relaciones de confianza de ssh.
Por ejemplo, cuando se utilizan las herramientas de cargabilidad de
salida de comandos en un clúster Serviceguard, normalmente se desea
poder ejecutar comandos desde cualquier miembro y enfocar cualquier
otro miembro. Esto requiere una distribución n^2 de las claves públicas
de ssh. Empiece por crear un archivo de texto en que se relacionen los
miembros del clúster, uno por línea. Llame a csshsetup utilizando dicho
archivo. Tenga en cuenta que este comando tiene que ejecutarse sólo una
vez, puesto que configura todos los miembros del clúster:
# csshsetup -r -f members_list.txt
Capítulo 4 147
La opción -r da instrucciones a csshsetup para distribuir las claves de

modo cíclico o n^2. Al usuario se le pedirá su contraseña en cada host
remoto. csshsetup automatiza, a continuación, todo el proceso de
distribución de claves públicas.
Tenga en cuenta que csshsetup no es específico de los clústeres
Serviceguard, ya que se puede utilizar para grupos arbitrarios de
sistemas. Asimismo, la relación de confianza no tiene que ser
bidireccional. Omita la opción -r cuando configure una relación de
confianza unidireccional entre el host actual y un conjunto de hosts de
destino remotos. Para obtener detalles adicionales, consulte la página de
manual de referencia de csshsetup (1).
Notas sobre la El protocolo remote shell es un protocolo intrínsecamente no seguro. Es el

seguridad protocolo que utilizan los “comandos r”, (rlogin, rcp, remsh, etcétera) de
Berkeley. Muchos administradores de sistemas deshabilitan el uso de los
comandos “r” por principio. Por ejemplo, la herramienta de
fortalecimiento de la seguridad Bastille ofrece una opción por defecto para
deshabilitar estos servicios no seguros. Si se deshabilitan, la opción pdsh
-R rsh para utilizar el transporte mediante el protocolo remote shell no
funcionará.
Si los servicios “r” no están deshabilitados, el uso de la opción pdsh -R rsh
por los usuarios carentes de privilegios seguirá estando deshabilitado por
defecto, debido al riesgo intrínseco para la seguridad. Por defecto, sólo los
usuarios que tienen privilegios de usuario root pueden utilizar la opción
pdsh -R rsh. Esto se debe a que la llamada de la biblioteca rcmd de remote
shell exige el uso de un puerto reservado. Aun cuando los usuarios con
privilegios puedan utilizar -R rsh, se sigue prefiriendo el transporte
mediante el protocolo ssh.
Si en su entorno se confía en los hosts y los usuarios, puede habilitar el uso
de la opción pdsh -R rsh para los usuarios carentes de privilegios con los
siguientes comandos:
# cd /opt/dsau/bin/pdsh
# chown root:bin pdsh
# chmod u+s pdsh
148 Capítulo 4
Solución de problemas de cargabilidad de salida de comandos (Command Fanout)
Solución de problemas de cargabilidad de

salida de comandos (Command Fanout)
En esta sección se ofrecen consejos para solucionar los problemas
indicados en los mensajes de error comunes generados por pdsh y los
comandos empaquetadores (“wrapper”).
Al utilizar el transporte mediante el comando ssh, puede obtener los
siguientes mensajes de error:
• Mensajes del transporte mediante el comando ssh:
— pdsh@<nombre de host local>: <nombre de host de

destino>: ssh exited with exit code 1
Razón: El sistema de destino está inaccesible.
destino>: ssh exited with exit code 255
Razón: Este mensaje se genera cuando se desconoce el nombre de
host de destino o la dirección IP del host de destino en /etc/hosts
es incorrecta. Tenga en cuenta que 255 es un código de salida
utilizado por ssh cuando el propio protocolo ssh detecta un error.
• Mensajes del transporte mediante el comando rsh:
— pdsh@<nombre de host local>: gethostbyname(“<nombre de

host de destino>”) failed
Razón: Se desconoce el nombre de host.
destino>: connect: Connection refused
Razón: El sistema de destino está inaccesible. Es posible que los
servicios “r” estén deshabilitados para este sistema.
destino>: connect: timed out
Razón: El nombre de host existe (por ejemplo, la búsqueda de la
dirección IP tuvo éxito), pero el sistema no está activo o no está
accesible.
Capítulo 4 149
Solución de problemas de cargabilidad de salida de comandos (Command Fanout)
— rresvport: bind: Permission denied pdsh@<nombre de host

local>: <nombre de host local>: rcmd: socket:
Permission denied
Razón: Un usuario carente de privilegios trata de utilizar el
transporte mediante remote shell. Consulte la sección “Notas
sobre la seguridad” para obtener detalles sobre cómo permitir que
los usuarios carentes de privilegios utilicen pdsh con el transporte
mediante remote shell.
— nombre de host de destino: remshd: Login incorrect.
remote
Razón: El archivo $HOME/.rhosts del usuario en el sistema
remoto no permite el acceso.
• Mensajes de error del nodo de destino:
— nombre de host de destino: sh: nombre de comando: not

found
Razón: El comando no existe en el nodo de destino. Tenga en
cuenta que el protocolo remote shell llamado por pdsh sólo tiene
una ruta mínima. Las secuencias de comandos de inicio de sesión
del usuario no se ejecutan en los nodos remotos. Asegúrese de que
especifica los comandos utilizando las rutas completas.
150 Capítulo 4
Índice
A cfrun, comando, 21
administrado cfrun.hosts, 42
cliente, 41, 57 CFS, 34
adoptivo, nodo, 41, 89 cfservd, 22, 26
demonio, 54
alerta
suma de comprobación, 63 cifrado, 62
clase, definiciones, 39
anular configuración, 64 clave
archivo
copia de seguridad, 36 integridad, 58
intercambio, 61
de directivas maestro, 56
pública/privada, 39, 52
directiva, 36
archivo de directivas, 36, 56 seguridad, 43, 57
archivos de registro claves de seguridad, 45, 57
paquete, 120 cfengine, 43
archivos de registro consolidados cliente
asegurar, 133 administrado, 41, 57
consultar, 138 reenvío de archivos de registro, 93
asegurar los archivos de registro remoto, 35
consolidados, 133 cliente de sincronización
asistente de sincronización de la configurar, 41
configuración (Configuration clog_wizard, 79
Synchronization Wizard), 20 clúster
autenticación, errores, 66 miembros, 35
Serviceguard, 26, 31, 43
B CMS, 26
comandos
Bastille, 136 Berkeley, 148
Berkeley, comandos, 148
configuración de almacenamiento
LVM, 33
C configuración de la seguridad
can’t stat, mensajes, 67 cfengine, 66
cargabilidad de salida de comandos consolidación de archivos de registro, 89
(Command Fanout), 141 configuración, 79
ccp, 53 descripción general, 73
cfagent, 22, 24, 58 deshabilitar, 128
cfagent.conf, 25, 44, 50 consolidador
CFANOUT_HOSTS, variable, 146 syslog-ng, 98
cfengine, 19, 26, 36, 41 copia de seguridad, archivo, 36
claves de seguridad, 43
copy
configuración de la seguridad, 66 secure, 58
configurar, 27 csshsetup, 42, 43
deshabilitar, 64 herramienta, 148
error, 68 csync, paquete, 54
solucionar problemas, 66 csync_wizard, 20, 27, 43
cfengine_master, 24
cfexecd, 59 D
cf.main, 30, 59
cfrun, 27, 59 definiciones
151
Índice
clase, 39 grupos de volúmenes, 34

demonio
cfservd, 54 M
sshd, 136
maestro
deshabilitar archivo de directivas, 56
consolidación de archivos de registro, 128
servidor, 41, 45
reenvío de archivos de registro, 130, 131
update.conf, 45
detalle de cfengine, 68 marca de hora, subdirectorios, 36
dirección IP
paquete, 34 marcadores, signos, 108
mensajes
reubicable, 89 can’t stat, 67
dshbak, 143 mensajes, pérdida, 74
miembros
E clúster, 35
errores
autenticación, 66 N
cfengine, 68 nodo
puerto TCP, 68 adoptivo, 41, 89
espacio en blanco, 67 nombre DNS, 34, 37
expresiones nsswitch.conf, 45
lista de hosts, 142
P
G
paquete
grupos de volúmenes archivos de configuración, 56
LVM, 34 archivos de registro, 120
csync, 54
H dirección IP, 34
herramienta de cierre secuencia de comandos de control, 56
Bastille, 136 Serviceguard, 37
HP-UX autónomo, 26 sistema de archivos, 36
huella dactilar parallel distributed shell, 142
known_host, 135 pdcp, 143
pdsh, 142
I pérdida
mensaje, 74
intraclúster, tráfico de archivos de registro, POLICYHOST_NAME, 44
133
proceso, reinicio, 127
protocolo
K TCP, 94
known_host, huella dactilar, 135 UDP, 94
pública/privada, clave, 39, 52
L puerto
libre, 95
libre, puerto, 95
lista de hosts, expresiones, 142 TCP, 62, 81
LVM TCP o UDP, 136
configuración de almacenamiento, 33 UDP, 82, 98, 113
152
Índice
R introducción, 70
rcmd, 143 syslogd, 70, 75
reenvío a través de un puerto syslog-ng, 75
ssh, 134 consolidador, 98
reenvío de archivos de registro, 89 System Management Homepage, 138
cliente, 93 Systems Insight Manager, 26
deshabilitar, 130
reinicio de un proceso, 127 T
relaciones de confianza, 148 TCP
remoto errores de puerto, 68
cliente, 35 protocolo, 94
shell, 141, 147 puerto, 62
remsh, 141 transporte, 133
resolve.conf, 45 TCP, puerto, 81
reubicable, dirección IP, 89 tráfico de archivos de registro
intraclúster, 133
S transporte
secure TCP o UDP, 133
copy, 58
shell, 141 U
Serviceguard UDP
características de automatización, 38 protocolo, 94
paquete, 37 puerto, 82, 98, 113
Serviceguard, clúster, 26, 31, 43, 48 update.conf, 24, 45, 50, 58
configurar manualmente, 48
servicios de alta disponibilidad (HA), 38 V
servidor
maestro, 41 variable de entorno
servidor de administración central, 26 CFANOUT_HOSTS, 146
sighup, 127 VxVM, 34
signos
marcadores, 108
SIM, 26
sistema de archivos
paquete, 36
SMH, 138
solucionar problemas
cfengine, 66
ssh, 141, 143
reenvío a través de un puerto, 134
transportes, 147
sshd, demonio, 136
subdirectorios
con marca de hora, 36
suma de comprobación, alerta, 63
syslog
formato de mensaje, 70
153
Índice
154

T2786 90052 Hpux Errores

Cargado por

Copyright:

Formatos disponibles

T2786 90052 Hpux Errores

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

T2786 90052 Hpux Errores

Cargado por

Copyright:

Formatos disponibles

Guía del usuario de Distributed Systems

Avisos de marcas comerciales

Deshabilitación de la consolidación de archivos de registro . . . . . . . . . . . . . . . . . . . . 128

4. Cargabilidad de salida de comandos

Figura 2-1. Descripción general de cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Título de libro El título de un libro o de otro documento.

comando El nombre de un comando o una expresión de comandos calificada.

entrada del Comandos y otro tipo de texto que escribe el usuario.

salida del equipo Texto que muestra el equipo.

variable El nombre de una variable de entorno, por ejemplo, PATH o errno.

valor Valor que se sustituye en un comando o una función, o información

find(1) Página de manual de HP-UX. En este ejemplo, “find” es la página de

• Las páginas de manual de DSAU

Tabla 2 Historial de publicación de DSAU

T2786-90052 1.2 1.0 Septiembre de 2006

Para obtener las versiones específicas de HP-UX y Serviceguard, y el

HP fomenta el envío de comentarios

• El título del documento (Guía del usuario de Distributed Systems

Distributed Systems Administration Utilities aporta varias herramientas

• Consolidated Logging (Registro consolidado): actualmente, el

• Command fanout (Cargabilidad de salida de comandos) se basa en la

Comandos de Distributed Systems

Comando Función Uso

csync_wizard Ayuda a configurar el entorno Al configurar el maestro de

Tabla 1-2 Comandos del registro consolidado

Comando Función Uso

clog Muestra archivos de registro. Para examinar archivos de registro.

clog_wizard Ayuda a configurar los servidores Al configurar la consolidación de

Tabla 1-3 Comandos de la cargabilidad de salida de comandos

Comando Función Uso

ccp Copia archivos en varios sistemas Para realizar la sincronización a

cexec Ejecuta comandos en varios Para ejecutar un comando de shell

ckill Distribuye un comando kill a Para enviar una señal a un proceso

Tabla 1-3 Comandos de la cargabilidad de salida de comandos

Comando Función Uso

cps Distribuye un comando ps(1) a Para recopilar simultáneamente

cuptime Notifica información de uptime(1) Para comprobar las medias de

Tabla 1-4 Comando de la configuración de utilidades

Comando Función Uso

Componentes de código fuente abierto

Tabla 1-6 Comandos pdsh de código fuente abierto

Tabla 1-7 Comando syslog-ng de código fuente abierto

syslog-ng Herramienta que realiza un registro consolidado.

Páginas de manual de Distributed Systems

Tabla 1-8 Secciones de las páginas de manual de DSAU

• Asegurarse de que los sistemas cliente utilizan un conjunto correcto

Se facilita un asistente de sincronización de la configuración

Descripción general de cfengine

Demonios y comandos de cfengine

• cfagent: El comando cfagent es el caballo de tiro de cfengine. Se

— cfservd se ejecuta en el servidor de configuración maestro y es la

enumerado en los archivos cfrun.hosts y conecta con el demonio

Figura 2-1 Descripción general de cfengine

1. El administrador inicia una sesión en el servidor maestro de

5. Al copiar los archivos de configuración en el sistema local, cfagent los

Modelos de distribución del servidor maestro

Utilización del asistente de sincronización de la

Tabla 2-1 Datos de configuración para csync_wizard

Datos de configuración Ejemplo Su valor