 |
» |
|
|
|
Las herramientas Distributed Systems Administration Utilities
(DSAU) se pueden utilizar para enviar archivos y comandos a sistemas
designados del clúster o la red. Las herramientas DSAU
proporcionan: Sincronización
de la configuración (Configuration Synchronization) Registro consolidado (Consolidated
Logging) Cargabilidad de salida de
comandos (Command Fanout)
Con la sincronización de la configuración
(Configuration Synchronization), se puede confiar en que los sistemas
del clúster o la red se mantienen conforme a un estándar
que se adopte. A medida que se efectúan cambios en el maestro
de configuración, dichos cambios se propagan a todos los
sistemas cliente. Con el registro consolidado (Consolidated Logging), se puede
examinar un solo archivo de registro que contenga las entradas de
todos los sistemas de la configuración, según
el orden de las marcas de hora, para buscar fácilmente
una entrada específica. Con la cargabilidad de salida de comandos (Command Fanout),
se puede enviar el mismo comando desde un sistema designado a todos
los sistemas de la configuración definida. Esto acaba con
la visita a todos los sistemas de la configuración y con
muchas operaciones manuales. Introducción
a la sincronización de la configuración (Configuration
Synchronization) | |
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. System Insight Manager de HP 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
directrices 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 directrices alberga
un archivo de directrices 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. Ejecutar comandos de shell
especificados en cada cliente. Buscar procesos o procesos
de señal. Buscar montajes de sistemas
de archivos específicos.
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. Descripción
general de cfengineEl administrador empieza por definir un sistema o clúster
Serviceguard central para que haga de servidor maestro de configuración
o de servidor de directrices. 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 directrices maestros
(por ejemplo, cfagent.conf), que definen las directrices 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 directrices 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 directrices. 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
cfexecd parecido a cron de cfengine. 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.
Demonios
y comandos de cfenginecfengine 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 directrices principal, cfagent.conf, y los archivos de directrices 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 directrices 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. Se pone en contacto con cada cliente administrado 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. Al empezar a utilizar cfengine, lo más sencillo es comenzar por usar cron. 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 3-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. 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. cfrun se pone en contacto con cfservd en cada cliente administrado, que a su vez llama a cfagent. cfagent comprueba primero el servidor maestro para obtener una copia
actualizada del archivo update.conf y la transfiere al cliente, si es necesario. 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 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. 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 directrices (cfagent.conf) y los archivos conexos. cfagent evalúa, a continuación, cfagent.conf para determinar que el cliente está en el estado
deseado. Si hay deltas, cfagent lleva a cabo las acciones definidas para corregir la
configuración de los clientes.
Modelos
de distribución del servidor maestro de cfengineEl 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 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. 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 más adelante. 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 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 cfrun(8)) se pueda utilizar en el
servidor maestro. Para obtener detalles, consulte las secciones apropiadas que
se presentan más adelante. Utilización
del asistente para configurar un servidor de sincronización
autónomoPara 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: # /opt/dsau/sbin/csync_wizard El asistente presenta la siguiente pantalla preliminar: Querying the system <nombre de host local> for current status, one moment...This Configuration Synchronization 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.It is a client/server based utility. A standalone system or Serviceguard cluster can be configured 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 cfengine man page.
This wizard will help you set up this system as a cfengine master or to add or remove a cfengine client, and to perform the required security setup.
Press ‘Return’ to continue... Presione la tecla de retorno para continuar y 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) Key management for cfengine users
(9) Exit
Enter choice: 1
The cfengine master server is being configured on:
<nombre de 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.
Verifying the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
Starting cfengine on the master and any pertinent client machines. 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 directrices 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:
</var/opt/dsau/cfengine_master/inputs/cf.main>
This default template has examples of typical configuration synchronization actions performed in cfengine. For example, 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 this configuration. See the cfengine reference documentation for a description of additional cfengine features: /opt/dsau/doc/cfengine/
Press ‘Return’ to continue...
The cfengine environment has been created with Master Host:
<nombre de host local> and members: Tenga en cuenta que al configurar un servidor maestro sin
agregar ningún cliente administrado durante la configuración
del servidor, los miembros (la lista de clientes administrados)
estarán vacíos tal como se muestra en el ejemplo
anterior. A file recording 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 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 ServiceguardPara 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” y no se recomienda.
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: 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. Asimismo, antes
de iniciar el asistente, todos los miembros actuales del clúster
deben estar instalados y en funcionamiento en el clúster. | | | | |
Empiece por ejecutar el asistente de sincronización
de la configuración (Configuration Synchronization Wizard),
csync_wizard(1): # /opt/dsau/sbin/csync_wizard
Querying the system <nombre de host local> for current status, one moment...
This Configuration Synchronization 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.
It is a client/server based utility. A standalone system or Serviceguard cluster can be configured 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 cfengine man page.
This wizard will help you set up this system as a cfengine master or to add or remove a cfengine client, and to perform the required security setup.
Press ‘Return’ to continue... Presione la tecla de retorno para continuar y 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) Key management for cfengine users
(9) Exit
Enter choice: 1 Después de elegir 1 y de presionar la tecla de retorno,
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 below question. 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 below question, cfengine will be configured as a highly available Serviceguard package. This will ensure 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 need to configure storage for the package before proceeding. For details on creating highly available file systems, please refer to ‘Creating a Storage Infrastructure’ chapters of the Managing Serviceguard documentation.
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”). | | | | | 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. Consulte la sección sobre la configuración
manual de un clúster Serviceguard para obtener detalles sobre
cómo configurar manualmente el paquete csync. | | | | |
El asistente pide lo siguiente, todo lo cual ya debe estar
configurado: El nombre del
grupo de volúmenes LVM (por ejemplo, vgcsync) El volumen lógico
del grupo de volúmenes (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:
Enter the Volume group? []: vgcsync
You need to enter a fully qualified Logical Volume, for example: /dev/vgname/lvol1 Enter the fully qualified Logical Volume? []: /dev/vgcsync/lvol1
Enter the Filesystem (Mount Point)? []: /csync
Enter the Mount Options? [-o rw,largefiles]:<return>
Enter the Filesystem Type? [vxfs]: <return>
Enter the IP address? []: 12.345.6.78
Enter the Subnet? []: 12.345.7.8 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.
No es necesario utilizar el asistente para agregar clientes nuevos
cuando se agregan miembros adicionales al clúster. Para
obtener detalles, consulte la sección sobre las características
de automatización Serviceguard. 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]: <return> El asistente ya tiene todos los datos que necesita para configurar
el clúster y así pasa a hacerlo: ******* WARNING!!!! ******** To protect against possible corruption of sensitive configuration files, control-c has been disabled for the remainder of this configuration.
Configuring the ‘csync’ Serviceguard package.
Applying the ‘csync’ Serviceguard package configuration file, this will take a moment.
Starting the ‘csync’ Serviceguard package, this will take a few moments...
The ‘csync’ Serviceguard package has been started on <nombre de host local>.
Configuration of the cfengine master server is starting.
Verifying the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
Starting cfengine on the master and any pertinent client machines.
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 directrices 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 directrices 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. For example, 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 this cluster. See the cfengine reference documentation for a description of additional cfengine features: /opt/dsau/doc/cfengine/
Press ‘Return’ to continue...
The cfengine environment has been created with Master Host: <nombre de host de paquete> and members: <miembro1 del clúster>, <miembro2 del clúster>, ...
A file recording 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 command:
/opt/dsau/sbin/csync_wizard \
-f /var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt Notas sobre
la configuración del clústerEn 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». 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 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 directrices. 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 directrices 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». Características
de automatización ServiceguardLas 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: etc/rc.config.d/cfservd se cambia para definir CSYNC_CONFIGURED en 1 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. El directorio /var/opt/dsau/cfengine/inputs del miembro nuevo se ocupa. cfservd se inicia en el miembro nuevo. Los archivos del paquete
se copian en /etc/cmcluster/csync/, en el
miembro nuevo. Se efectúa una ejecución
de sincronización cfagent en el maestro para ocupar el directorio /var/opt/dsau/cfengine/inputs del maestro. Se efectúa una ejecución
de sincronización cfagent en el cliente remoto.
Al eliminar un miembro en un clúster, la
clave pública del miembro eliminado se elimina del directorio /var/opt/dsau/cfengine/ppkeys de todo el clúster.
Tenga en cuenta que 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 actualizarán
automáticamente y el administrador deberá actualizar
manualmente el archivo cfagent.conf y los archivos conexos en relación con los
cambios de pertenencia al clúster. Configuración
de un cliente de sincronizaciónEl 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 la
adición en forma de cliente de un miembro nuevo del clúster
en una configuración de alta disponibilidad se hace automáticamente.
Para obtener más información, consulte la sección «Características
de automatización Serviceguard». Asimismo, para distribuir sin riesgos las claves de cfengine,
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 csshsetup(1)) simplifica la configuración
del acceso ssh a un sistema remoto. Esta
herramienta se utiliza en los siguientes ejemplos. Actualmente, el asistente sólo puede administrar
clientes cuando éstos se hallan en el mismo dominio DNS
que el servidor maestro. Para las configuraciones multidominio,
consulte la sección «Configuración
manual » a fin de obtener instrucciones sobre la adición manual
de clientes. Observe que si se agrega un clúster Serviceguard
como un cliente administrado, cada miembro del clúster
deberá agregarse individualmente. 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 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: Configuration Synchronization Wizard Menu
=========================================
(1) Set up a cfengine master server
(2) Add a client
(3) Remove a client
(4) Key management for cfengine users
(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 the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
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. 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 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. Por ejemplo, el asistente admite
sólo configuraciones de un solo dominio DNS. Al configurar
manualmente configuraciones multidominio, no se puede utilizar el
asistente para agregar y eliminar clientes. | | | | | 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 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ónomoDé los siguientes pasos puntuales para configurar
un sistema autónomo como un servidor maestro de cfengine: 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 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 |
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: Sustituya
<%HOST_NAMER%> por el nombre de host incompleto del servidor
maestro. Sustituya <%DOMAIN_NAMER%> por el nombre de dominio del servidor maestro.
Por ejemplo: host_name = ( «master-server-name» )
domain_name = ( «abc.xyz.com» ) |
Tenga en cuenta que esta plantilla update.conf da por sentado que el servidor maestro y sus clientes
están todos en un solo dominio DNS. Si el servidor maestro
va a tener clientes administrados en varios dominios DNS, cambie update.conf como sigue: Sustituya <%HOST_NAMER%> por el nombre de host completo del servidor maestro. Elimine la variable
<domain_name>. Sustituya la línea «domain = ( “${domain_name}” )» por lo siguiente: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) ) |
Esto define apropiadamente la variable de dominio en el cliente. Tenga
en cuenta que esta técnica da por sentado que /etc/resolv.conf está correctamente configurado en cada cliente
administrado. Estas mismas modificaciones del dominio también deben realizarse
en cf.main y cfservd.conf. Consulte los pasos siguientes. Utilice el indicador cfagent -p (o --parse-only) para comprobar la sintaxis de update.conf.
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». 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: # cp localhost.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 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. 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 la línea “
domain = <%DOMAIN_NAMER%>” y sustituya el signo por el dominio
DNS de los sistemas cliente. Esto limita a todos los clientes a
ser miembros de ese único dominio. El archivo /var/opt/dsau/cfengine_master/inputs/cfagent.conf es el archivo de directrices 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. cf.main contiene los mismos signos <%HOST_NAMER%> y <%DOMAIN_NAMER%> que los de update.conf. 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 directrices 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 abierto se ubican en /opt/dsau/share/cfengine/examples. 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. Elimine por completo la siguiente
línea: domain_name = ( “<%DOMAIN_NAMER%>” ) Cambie la línea que reza domain = ( “${domain_name}” ) por lo siguiente: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) ) La estrofa “admit:” controla qué clientes remotos
tienen acceso a los archivos en el servidor. Cambie cada “*.${domain_name}” por una lista separada por espacios
de dominios DNS de clientes administrados. Por ejemplo: /var/opt/dsau/cfengine_master/master_files *.abc.xyz.com *.cde.xyz.com Este ejemplo permite a todos los hosts de los dominios enumerados
obtener acceso a los archivos del servidor maestro. También
se pueden especificar listas de hosts, intervalos de direcciones
IP, etcétera, específicos. Para obtener información adicional,
consulte el manual de referencia de cfengine.
En el servidor maestro, inicie el demonio cfservd: # /sbin/init.d/cfservd start Esto se repite para cada cliente administrado. Pruebe la configuración dando los siguientes
pasos: En un cliente administrado, utilice
el comando: # cfagent --no-lock --verbose --no-splay La salida detallada mostrará al cliente buscando
copias actualizadas de los archivos de directrices maestros, copiándolas en /var/opt/cfengine/inputs, si procede, y ejecutando, a continuación,
el contenido de cfagent.conf/cf.main. 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».
Configuración
manual de un servidor de sincronización de un clúster
ServiceguardConfigurar 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». Las principales diferencias son la creación
del paquete Serviceguard y el mecanismo utilizado para distribuir
las teclas de seguridad de cfengine. Dé todos los pasos
descritos a continuación. Preparación
inicial del paquete Serviceguard 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. 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: 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). Exportar/importar el grupo
de volúmenes en todo el clúster. Definir un sistema de archivos
en el volumen lógico. 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. 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 directrices Cree un subdirectorio para los archivos
de directrices 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. Copie las plantillas por defecto en el directorio
de entradas (inputs) maestro: # 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 |
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 <%HOST_NAMER%> por
el nombre de host incompleto del paquete Serviceguard. Sustituya <%DOMAIN_NAMER%> por
el nombre de dominio DNS del paquete. Por ejemplo: host_name = ( «package-hostname»)
domain_name = ( «abc.xyz.com») |
Tenga en cuenta que esta plantilla update.conf da por sentado que el servidor maestro y sus clientes
están todos en un solo dominio DNS. Si el servidor maestro
va a tener clientes administrados en varios dominios DNS, cambie update.conf como sigue: Sustituya <%HOST_NAMER%> por
el nombre de host completo del paquete Serviceguard. Elimine la variable «domain_name». Sustituya la línea domain = ( “${domain_name}” ) por lo siguiente: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) ) |
Esto define apropiadamente la variable de dominio en el cliente.
Estas mismas modificaciones del dominio también deben realizarse
en cf.main y cfservd.conf. Consulte más adelante. Utilice el indicador -p (--parse-only, sólo analizar) de cfagent para comprobar la sintaxis de update.conf.
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. Si se
utilizan nombres de host incompletos, busque la línea «domain = <%DOMAIN_NAMER%>» y sustituya el signo por el dominio DNS
de los miembros del clúster. Esto limita a todos los clientes
a ser miembros de ese único dominio. Modificación del
archivo de directrices maestro El archivo /var/opt/dsau/cfengine_master/inputs/cfagent.conf es el archivo de directrices 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 los siguientes signos: cf.main contiene los mismos signos <%HOST_NAMER%> y <%DOMAIN_NAMER%> que los de update.conf. Realice las mismas modificaciones que las descritas
en el paso 3 del punto anterior “Personalización
inicial de los archivos de directrices”. 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 directrices
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
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. Elimine por completo la siguiente
línea: domain_name = ( “<%DOMAIN_NAMER%>” ) Cambie la línea que reza domain = ( “${domain_name}” ) por lo siguiente: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) ) La estrofa “admit:” controla qué clientes remotos
tienen acceso a los archivos en el servidor. Cambie cada “*.${domain_name}” por una lista separada por espacios
de dominios DNS de clientes administrados. Por ejemplo: /var/opt/dsau/cfengine_master/master_files *.abc.xyz.com *.cde.xyz.com Este ejemplo permite a todos los hosts de los dominios enumerados
obtener acceso a los archivos del servidor maestro. También
se pueden especificar listas de hosts, intervalos de direcciones
IP, etcétera, específicos. 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, dicha
clave debe ser idéntica en todos los miembros del clúster.
cfkey de cfengine 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: nombreusuario-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: Utilice cfkey para crear el par de claves pública y privada
para este miembro del clúster: # mkdir -p /var/opt/dsau/cfengine/ppkeys
# cd /var/opt/dsau/cfengine/ppkeys
# /opt/dsau/sbin/cfkey |
Esto creará las claves denominadas localhost.priv
y localhost.pub. 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-10.116.9.74.pub |
donde 10.116.9.74 es la dirección IP reubicable del
paquete csync. 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 miembro2>.pub
# cp localhost.pub root-<dirección IP del miembro3>.pub
...
# cp localhost.pub root-<dirección IP del miembroN>.pub |
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.
Configuración e
inicio de cfservd 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. Propague este cambio en todo el clúster: # ccp /etc/rc.config.d/cfservd /etc/rc.config.d/cfservd |
En el servidor maestro, inicie el demonio cfservd: # /sbin/init.d/cfservd start |
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». Empiece por efectuar los cambios descritos más adelante. Cree el directorio del paquete en todo
el clúster: # cexec mkdir /etc/cmcluster/csync |
Copie el archivo ASCII del paquete de plantilla
y la secuencia de comandos de control del paquete en el directorio /etc/cmcluster/cysnc 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 |
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. 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. 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]“vgcsync”. 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”. 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. 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”. 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”. 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]=“”. 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]=“”. 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. 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.
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/ 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: En un cliente administrado, utilice
el comando: # cfagent --no-lock --verbose --no-splay La salida detallada mostrará al cliente buscando
copias actualizadas de los archivos de directrices maestros, copiándolas en /var/opt/cfengine/inputs, si procede, y ejecutando, a continuación,
el contenido de cfagent.conf/cf.main. En el servidor maestro, pruebe el comando cfrun: # cfrun -- --inform --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».
Configuración
de un cliente administrado de sincronizaciónCuando 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 configurar un clúster Serviceguard como un cliente
de un servidor maestro existente de cfengine, se trata a cada miembro del clúster como si
fuera un sistema autónomo, configurándose individualmente.
Si agrega miembros nuevos al clúster, cada uno de ellos
debe configurarse apropiadamente.Si agrega un miembro nuevo a un
clúster Serviceguard y este clúster ejecuta el
paquete csync, los miembros del clúster se configuran automáticamente
como clientes administrados de cfengine. En este marco hipotético, el paquete csync hace de servidor maestro. Los miembros nuevos se configurarán
automáticamente como clientes administrados y también
podrán manejar la conmutación por error para el
paquete. La infraestructura de almacenamiento y el sistema de archivos
del paquete deben configurarse antes de agregar el miembro al clúster. Para
agregar un cliente administrado nuevo, empiece por configurar la relación
de confianza entre el cliente y el servidor maestro. Los dos sistemas
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: Como usuario root, cree la clave
de seguridad del cliente utilizando cfkey: # mkdir -p /var/opt/cfengine/ppkeys
# cd /var/opt/cfengine/ppkeys
# /opt/dsau/sbin/cfkey |
Esto crea los archivos localhost.pub y localhost.priv para
este cliente. 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:
<nombreusuario>-<dirección_IP_cliente>.pub. Inserte la clave pública del cliente en
el directorio ppkeys del servidor maestro aplicando la siguiente
convención de nomenclatura: # 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 scp(1)) al transferir la clave
para proteger su integridad. 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 |
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: Modifique
/etc/rc.config.d/cfservd y defina la variable CSYNC_CONFIGURED en «1»: esto iniciará cfservd en el momento
del inicio. Inicie el demonio cfservd: # /sbin/init.d/cfservd start Pruebe la configuración con cfagent (consulte cfagent(8)): # cfagent --no-lock --verbose --no-splay La salida detallada mostrará al cliente buscando
copias actualizadas de los archivos de directrices maestros, copiándolas
en /var/opt/cfengine/inputs, si procede, y ejecutando, a continuación,
el contenido de cfagent.conf/cf.main.
Para obtener información adicional sobre la solución
de problemas, consulte la sección «Solución
de problemas de cfengine». Selección
de un método de llamada a la sincronizaciónComo administrador, usted puede extender los cambios a los
clientes administrados con ayuda del comando cfrun (consulte cfrun(8)). cfrun se pone en contacto con el demonio cfservd en cada cliente administrado y el demonio cfservd llama al comando cfagent para realizar 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 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 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/.
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: Alertas de suma de comprobación
Intercambio de clavesEn 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. Un esquema como este
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 = 12.345.678.90
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=12.345.678.90 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
hosts 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 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 hosts 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. Uso del puerto de redcfservd 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
en /etc/services. CifradoEn 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. Alertas de suma de comprobacióncfengine presenta una característica de alerta de suma
de comprobación parecida a Tripwire. 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: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Deshabilitación
del uso de cfengineEl asistente csync_wizard no tiene una opció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 CSCYN_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 tal como se describe en la sección «Configuración
de un cliente de sincronización». 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. 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 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.
Solución
de problemas de cfengine | |
A continuación,
se ofrecen sugerencias para solucionar problemas cuando se trabaja
con la herramienta cfengine. 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. 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 trustcfengine:: 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 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». Mensaje 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. Error de sintaxis debido a un espacio en blanco
que falta. # cfagent -K
cfengine::/var/opt/dsau/cfengine/inputs/update.conf:39: syntax error
cfengine::/var/opt/dsau/cfengine/inputs/update.conf: \
Execution 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 informa de un error de sintaxis
en la línea 39 de update.conf. Es posible que el error sea un error de espacio en
blanco de la línea 38 del archivo. No se puede conectar con un cliente o servidor maestro
de cfengine. # cfruncfrun(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. 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. 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. 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
¿Cómo aumento el nivel de detalle
de cfengine? La mayoría de las utilidades y demonios de cfengine
aceptan una opción de nivel detallado (“verbose”)
y varias opciones de depuración (“debug”).
Por ejemplo: cfagent -d, -d1, -d2, -d3, or -d4 # para salida de depuración
cfservd -v
cfrun -v
Introducción
a syslog | |
syslogd (consulte 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 tal como se indique
en /etc/syslog.conf. Las aplicaciones registran mensajes en syslog con ayuda de la llamada de syslog() (consulte syslog(3C)). Formato
de los mensajes de syslogLos 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. En la Tabla 3-1, «Niveles de prioridad de syslog» se relacionan 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. |
En la Tabla 3-2, «Mensajes de dispositivo de syslog» se describen
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 inetd(1M) y ftpd(1M)). | LOG_AUTH | Mensajes procedentes del sistema de autorización,
incluidos login, su, getty (consulte 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 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. |
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: Para obtener información adicional sobre la configuración
de filtros de mensajes, consulte la página de manual de syslogd(1M). Descripción
general de la consolidación de archivos de registro (Log
Consolidation) | |
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 archivos
de registro. 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. Un sistema de consolidación
de archivos de registro representa un solo punto 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 mejoradaDistributed Systems Administration Utilities (DSAU) utiliza syslog-ng, es decir syslog “Next Generation” (Siguiente 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 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.
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.
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. En los siguientes diagramas se
ilustra la relación entre syslogd y syslog-ng. En la Figura 3-2, «Configuración del reenvío
de archivos de registro de syslog-ng» se
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. 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 graba 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. 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. El comando 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. 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. 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.
En la Figura 3-3, «Configuración del consolidador de
archivos de registro de syslog-ng» se ilustra
la configuración en el servidor de consolidación de
archivos de registro. 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. La zona gris es idéntica
a la configuración del cliente en la Figura 3-2, «Configuración del reenvío
de archivos de registro de syslog-ng» En relación con el sistema local,
syslog-ng hace de cliente y procesa localmente los mensajes de
syslog y los mensajes de clog_tail reenviados. 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.
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 utiliza un sistema autónomo
o un clúster Serviceguard, tal como se describe en las
siguientes secciones. Configuración
de un servidor de consolidación de archivos de registro
autónomo con 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 simplemente presione Entrar. La siguiente pregunta es: You can configure this system hostname as either:
- Consolidation server
- Client that forwards logs to a remote consolidation server Do you want to configure hostname as a Consolidation Server? (y/n) [y]: Conteste que sí (“y” de “yes”). 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 parte de que 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 via 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 log receiving. Note: When configuring log consolidation on the clients, this port will need to be specified. Enter the TCP port to be used for log receiving? []: 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. 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” de “yes”)
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 desde 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 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 hostname 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. 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». 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 hostname 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
-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 hostname 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 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.
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: Log file consolidation allows you combine the log entries from multiple remote systems into a single file. The standard use of this feature is 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 system's forwarding log entries are consolidation clients. The system they are sending the entries to is the consolidation server. In addition to syslog data, arbitrary textual log files can also be consolidated. In a Serviceguard cluster, this tool can help you automate package log file consolidation. Log consolidation is especially useful in a Serviceguard cluster, since it allows you to look at a single consolidated file instead of the per-member logs. This tool 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 of these questions have a default answer contained within square brackets. If you press Return, the default answer is assumed. Do you want to configure log consolidation? (y/n) [y]: Conteste que sí (“y” de “yes”)
o simplemente presione Entrar. La siguiente pregunta es You can configure this cluster <nombre del clúster> as either:
- Consolidation server
- Client that forwards logs to a remote consolidation server
Do you want to configure <nombre del clúster> as a Consolidation Server? (y/n) [y]: Conteste que sí (“y” de “yes”). En un clúster, el asistente configura syslog-ng para que presente alta disponibilidad utilizando un paquete
Serviceguard. El nombre del paquete es “clog” para
el registro consolidado. 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 el manual Managing Serviceguard (capítulo
5 “Building an HA Cluster Configuration”, sección “Creating
a Storage Infrastructure with LVM”). El asistente pide lo siguiente, todo lo cual ya debe estar
configurado: El nombre
del grupo de volúmenes LVM (por ejemplo, vgclog) El volumen lógico
del grupo de volúmenes (por ejemplo, /dev/vgclog/lvol1) El punto de montaje del sistema
de archivos (por ejemplo, /clog) 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”. 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 el reenvío de archivos de registro sea
fácil de configurar en los sistemas cliente. La subred del paquete. Utilice
netstat -i para determinar la subred correcta.
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 via 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. Al contestar afirmativamente (“y” de “yes”)
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». 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 los archivos syslog
de este clúster, 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. 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: |
Summary of Log Consolidation Configuration:
You have chosen to configure <nombre del clúster> as a Log Consolidation
Server.
Logs will be forwarded from the remote consolidation clients to local
port port-number using the TCP protocol.
For high availability the Serviceguard package "clog" will be
configured with the following attributes:
Volume Group: vgclog
Logical Volume: /dev/vgclog/lvol1
Filesystem: /clog
Mount Options: -o rw,largefiles
Filesystem Type: vxfs
IP Address: 123.456.789.10
Subnet: 123.456.788.0
The following logs on this cluster will be consolidated:
Syslog
Serviceguard package logs Do you want to continue? (y/n) [y]:
Do you want to continue? (y/n) [y]:
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 del clúster> as a log consolidation server.
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.
Creating a symbolic link from /etc/syslog-ng.conf to the
/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 syslog configuration:
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 cluster-member.
Successfully created the "clog" Serviceguard package.
Successfully configured <nombre del 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. 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». 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
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:
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/syslog-ng.conf.client, /etc/syslog-ng.conf.server y el enlace simbólico /etc/syslog-ng.conf
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». 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.
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 de
dos nodos. 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.
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 simplemente presione Entrar. La siguiente pregunta es: You can configure this cluster <nombre del clúster> as either:
- Consolidation server
- Client that forwards logs to a remote consolidation server
Do you want to configure <nombre del 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 what system will be the consolidator. If the consolidator is a Serviceguard cluster, you should specify the IP address of the "clog" Serviceguard package for this question. The "clog" package is used to make 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: You can choose to forward logs to the consolidator via
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 gran rendimiento sin control de flujo ni comprobación
de entrega de mensajes. syslog-ng admite el protocolo UPD 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» para obtener un análisis del valor max-connections().
Si contesta que “sí” (“y” de “yes”)
al uso del protocolo TCP, la siguiente pregunta le pedirá el
puerto TCP al que reenviar los mensajes: You need to find out from the administrator of the consolidation server the TCP port that was configured for log receiving.
Enter the TCP port configured on the CONSOLIDATOR for log receiving? []: 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” de “yes”)
a la pregunta sobre el protocolo TCP, aparecerá la siguiente
pregunta: The TCP protocol can be used in conjunction 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]: 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. 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? []: 1175 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 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». Una vez contestadas todas las preguntas, el asistente clog_wizard presenta la siguiente pantalla sinóptica: Summary of Log Consolidation Configuration:
You have chosen to configure nombre del 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 in conjunction 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 itscurrent
log consolidation configuration, in the eventof a failure.
Configuring <nombre del 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.
Creating a symbolic link from /etc/syslog-ng.conf to the
/etc/syslog-ng.conf.client 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 -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 del clúster> as a log consolidation client. |
|
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». Configuración
manual de la consolidación de archivos de registroSi 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. Configuración
manual de un servidor de consolidación de archivos de registro
En las siguientes secciones se describen los pasos
detallados necesarios para configurar manualmente un sistema autónomo
o un clúster Serviceguard como un servidor de consolidación
de archivos de registro.
Configuración manual de un cliente autónomo de
reenvío de archivos de registroEmpiece 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 los mensajes de syslog reenviados
mediante UDP procedentes de los 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, el cual impide que el demonio 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. 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 servidor de consolidación de archivos de registro
autónomo con clog_wizard». 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. 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: 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: Si consolida los archivos syslog locales, agregue: en caso contrario, agregue: 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: CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog |
Pruebe la configuración
dando los siguientes pasos: 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. Inicie syslog-ng con ayuda del comando /sbin/init.d/syslog-ng start. 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 registroLos 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 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». Si desea que los mensajes del syslog local del propio clúster formen parte del syslog consolidado, complete las siguientes tareas: 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 debe escuchar en el puerto UDP 514. Modifique etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS para agregar el modificador -N para impedir que el demonio syslogd escuche en el puerto 514. Por ejemplo: 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. Si ha personalizado el archivo syslog.conf, asegúrese de que también agrega las
líneas de reenvío para las personalizaciones. 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/ |
El archivo /etc/syslog.conf es específico de cada miembro y las modificaciones
descritas más arriba deben realizarse en todos los miembros
del clúster. 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”
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 un archivo /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: 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 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 <%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 clúster. 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:
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». 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(“IP de paquete” port(1776)); }; |
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. 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.
Sustituya manualmente los signos en /etc/syslog-ng.conf.client como sigue: Si configura el clúster 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_<tipo>); }; |
donde <tipo> es tcp o bien udp, según el transporte de archivos de 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%>. Sustituya todos los signos
<%TYPE%> por tcp o bien udp, según el transporte de archivos de registro
deseado. 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.
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: Agregue las siguientes líneas: 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: Si consolida los archivos syslog locales, agregue: en caso contrario, agregue: Si consolida los archivos de registro del paquete de este
clúster, agregue: en caso contrario, agregue: Agregue los dos valores siguientes que utiliza el System
Log Viewer: CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog |
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/ |
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. 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: 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: 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. 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” |
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: 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 del paquete>.log |
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 |
Busque la línea «FS_TYPE[0]=“<%SG_PKG_FS_TYPE%>”» y sustituya el signo por el tipo de sistema
de archivos. Por ejemplo: 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: 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: Busque la línea «IP[0]=“<%SG_PKG_IP%>”» y sustituya el signo por la dirección
IP del paquete “clog”. Por ejemplo: 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:
Ahora tendrá que distribuir los archivos del paquete
por todo el clúster. Para ello, dé los siguientes
pasos: 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 |
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/ |
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
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 |
Realice la distribución en todo el clúster: # ccp /etc/rc.config.d/syslog-ng /etc/rc.config.d/ |
Prueba e inicio del paquete “clog”Antes de iniciar el paquete, pruebe la configuración
realizada hasta ahora: 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. 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 |
Debería ver un demonio syslog-ng ejecutándose en cada miembro del clúster. 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. Inicie el paquete “clog”: A continuación, utilice “cmviewcl” para
asegurarse de que se está ejecutando: Si surge algún problema al ejecutar el paquete, compruebe
los archivos /etc/cmcluster/clog/clog.log de cada miembro para contribuir a solucionarlo. 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.
Utilización de VxVM en lugar de LVMLa 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 el 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 registroAl configurar un cliente de reenvío de archivos de
registro, puede configurarlo como un sistema autónomo o
como un clúster Serviceguard. Para cada caso, se configura
tanto syslogd como syslog-ng. Configuración manual de un cliente autónomo de
reenvío de archivos de registro 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. Si desea reenviar los archivos syslog de este
sistema, syslog-ng debe estar escuchando en el puerto UDP 514. Modifique /etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS para agregar el modificador -N, el cual impide que el demonio syslogd escuche en el puerto 514. Por ejemplo: 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. Si ha personalizado el archivo syslog.conf, asegúrese de que también agrega las
líneas de reenvío para las personalizaciones. Detenga y reinicie syslogd para que estos cambios surtan efecto: # /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start |
Para configurar syslog-ng, empiece con las mismas plantillas de 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: Si configura el sistema para que reenvíe
sus archivos syslog al servidor de consolidación, 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_<tipo>); }; donde <tipo> es tcp o bien udp, según el transporte de archivos de 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 signos <%UDP_LOOPBACK_SOURCE%> y <%UDP_LOOPBACK_LOG%>. Sustituya todos los signos <%TYPE%> por
tcp o bien udp, según el transporte de archivos de registro
deseado. 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 «Configuración
de un servidor de consolidación de archivos de registro
autónomo con clog_wizard». 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». 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 archivos
de registro. Cree el siguiente enlace simbólico: ln -sf /etc/syslog-ng.conf.client /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: Agregue las siguientes líneas: CLOG_CONSOLIDATOR=0
CLOG_CONS_IP=<dirección IP del consolidador de archivos de
registro> |
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> |
en caso contrario, utilice: en caso contrario, si usa el protocolo UDP, utilice: Si consolida los archivos syslog locales, utilice: en caso contrario, utilice:
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. Pruebe la configuración dando los siguientes
pasos: 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.client, tal como se describe más arriba. Inicie syslog-ng con ayuda del siguiente comando: # /sbin/init.d/syslog-ng start |
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.
Configuración manual de un clúster Serviceguard como
un cliente de reenvío de archivos de registroConfigurar 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. Si desea que los mensajes de syslog para el clúster se reenvíen al consolidador
de archivos de registro, dé los siguientes pasos: 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 debe estar escuchando en el puerto UDP 514. Modifique /etc/rc.config.d/syslogd y cambie SYSLOGD_OPTS para agregar el modificador -N, el cual impide que el demonio syslogd escuche en el puerto 514. Por ejemplo: 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 miembro
del clúster. Este nombre debe estar completo o syslogd no reenviará correctamente los mensajes. 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: # /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start |
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/ |
El archivo /etc/syslog.conf es específico de cada miembro y las modificaciones
descritas más arriba deben realizarse en todos los miembros
del clúster. 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” |
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.client.template 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: Si configura el clúster para que
reenvíe sus archivos syslog al servidor de consolidación,
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_<tipo>); }; |
donde <tipo> es tcp o bien udp, según el transporte de archivos de 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%>. Sustituya todos los signos
<%TYPE%> por tcp o bien udp, según el transporte de archivos de registro
deseado. 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 «Configuración
de un servidor de consolidación de archivos de registro
autónomo con clog_wizard». (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/csshetup para la configuración). Para obtener detalles,
consulte la sección «Reenvío
a través de un puerto ssh». 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 archivos
de registro.
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: Agregue las siguientes líneas: CLOG_CONSOLIDATOR=0
CLOG_CONS_IP=<dirección IP del consolidador de archivos de registro> |
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> |
en caso contrario, agregue: en caso contrario, si utiliza el protocolo UDP, agregue: Si consolida los archivos syslog locales, agregue: en caso contrario, agregue: Si consolida los archivos de registro del paquete de este
clúster, agregue: en caso contrario, agregue:
Todos los archivos modificados hasta ahora tienen que
distribuirse en todo el clúster: # ccp /etc/syslog-ng.conf.client /etc/
# ccp /etc/rc.config.d/syslog-ng /etc/rc.config.d/ |
Cree el siguiente enlace simbólico en cada miembro
del clúster: # ln -sf /etc/syslog-ng.conf.client /etc/syslog-ng.conf |
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. 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». Pruebe la configuración dando los siguientes
pasos: 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.client, tal como se describe más arriba. Inicie syslog-ng en todos los miembros del clúster con ayuda
de # cexec “/sbin/init.d/syslog-ng start” |
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.
Consolidación de archivos de registro
de paquetes en el servidor de consolidación de archivos
de registroPara consolidar los archivos de registro de paquetes reenviados
desde los clientes del clúster a un servidor de consolidación
de archivos de registro, deben darse los siguientes pasos en el
servidor de consolidación de archivos de registro: 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. 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 el alias del clúster que reenvía
este archivo de registro del paquete y <sa> es el sistema de archivos del consolidador de
archivos de registro donde se almacenarán los archivos
de registro consolidados. 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: # ccp /etc/syslog-ng.conf.server /etc/ |
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. Para cada paquete que se elimine en un cliente del clúster
que reenvía sus archivos de registro de paquetes, elimine
las líneas de destino (destination), filtro (filter) y
archivo de registro (log) del archivo /etc/syslog-ng.conf.server del consolidador de archivos de registro. Habrá que
utilizar 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.
Deshabilitación
de la consolidación de archivos de registro | |
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ónomoDé los siguientes pasos para desconfigurar la consolidación
de archivos de registro: 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: Si los archivos syslog locales se consolidaban, modifique
también el archivo /etc/syslog.conf del sistema para eliminar 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. Reinicie syslogd con ayuda de los siguientes comandos: #/sbin/init.d/syslogd stop
#/sbin/init.d/syslogd start |
Detenga syslog-ng: # /sbin/init.d/syslog-ng stop |
Modifique el archivo /etc/rc.config.d/syslog-ng como sigue: Cambie la línea
CLOG_CONFIGURED a CLOG_CONFIGURED=0. Quite las demás líneas CLOG, excepto las siguientes: CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog |
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 ServiceguardDé 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: 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: Reinicie syslogd con ayuda de los siguientes comandos: #/sbin/init.d/syslogd stop
#/sbin/init.d/syslogd start |
Si los archivos syslog locales se consolidaban, modifique
el archivo /etc/syslog.conf del sistema para eliminar 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.
Fíjese en que a cada signo de arroba, @, le precede una <tabulación>. Detenga el paquete clog con el comando: #/usr/sbin/cmhaltpkg clog |
Detenga syslog-ng con ayuda del siguiente comando: # /sbin/init.d/syslog-ng stop |
(Tenga en cuenta que esto detiene el demonio syslog-ng y la consolidación de archivos de registro de
paquetes, si está configurada.) Modifique el archivo /etc/rc.config.d/syslog-ng y cambie la línea CLOG_CONFIGURED como sigue: Quite las demás líneas CLOG, excepto: CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog |
Elimine el paquete “clog” con el siguiente
comando:
Deshabilitación
de un cliente de reenvío de archivos de registro autónomoDé los siguientes pasos para deshabilitar el reenvío
de archivos de registro en un cliente autónomo. 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: Modifique el archivo /etc/syslog.conf del sistema para quitar 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.
Fíjese en que hay una <tabulación> antes
de cada signo de arroba, @. Reinicie syslogd con ayuda de los siguientes comandos: #/sbin/init.d/syslogd stop
#/sbin/init.d/syslogd start |
Detenga syslog-ng con ayuda del siguiente comando: # /sbin/init.d/syslog-ng stop |
(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.) Modifique el archivo /etc/rc.config.d/syslog-ng y cambie la línea CLOG_CONFIGURED como sigue: Quite las demás líneas CLOG, excepto las siguientes: CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog |
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
través de un puerto ssh |
Deshabilitación
de un cliente de reenvío de archivos de registro de un
clúster ServiceguardDé los siguientes pasos para desconfigurar el reenvío
de archivos de registro. Estos pasos tienen que darse en cada miembro
del clúster: 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”. Modifique el archivo /etc/syslog.conf del sistema para quitar 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. Detenga y reinicie syslogd con ayuda de los siguientes comandos: # /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start |
Detenga syslog-ng: # /sbin/init.d/syslog-ng stop |
(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.) Modifique el archivo /etc/rc.config.d/syslog-ng y cambie la línea CLOG_CONFIGURED por CLOG_CONFIGURED=0. Quite las demás líneas CLOG, excepto las siguientes: CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog |
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
través de un puerto ssh |
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 sistema de acceso restringido con estrictas directrices de
seguridad en vigor. Medidas
de protección de los archivos de registroUn grado de protección abarca los permisos de los
propios archivos de registro consolidados. Esto se controla por
medio del archivo syslog-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 sshEl reenvío a través de un puerto ssh configura
un túnel cifrado 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. 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 abierto de syslog-ng (/opt/dsau/doc/syslog-ng). Reenvío a través de
un puerto ssh a un consolidador de archivos de registro de un clúster ServiceguardCuando se utiliza el reenvío a través de
un puerto ssh teniendo como servidor de consolidación de archivos
de registro un clúster Serviceguard, se precisa una configuración
especial de ssh. En general, el uso del reenvío a través
de un puerto ssh necesita que el servidor de consolidación de
archivos de registro efectúe un intercambio de claves con
el cliente de reenvío de archivos de registro. En concreto,
la 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. 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: 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 cpp agiliza esta acción: # 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: # csshsetup <nombre DNS del paquete clog> |
csshsetup solicitará la contraseña del clúster
para efectuar el intercambio de claves inicial. Utilización
de Bastille para fortalecer el sistemaBastille 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. Al habilitar el
filtrado IP, tenga en cuenta que los siguientes puertos deben dejarse
abiertos para syslog y syslog-ng: 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.
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 HomepagePara 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”. Utilización del System Log ViewerSystem 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 adicionales,
consulte la sección “Notas sobre la configuración
del clúster”. 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. Utilice “cmvviewcl” para
determinar en qué miembro del clúster se ejecuta
actualmente el paquete “clog” e inicie System
Management Homepage en ese sistema para ver los archivos de registro
consolidados. | | | | |
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. Introducción
a la cargabilidad de salida de comandos (Command Fanout) | |
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. Parallel
Distributed ShellLas herramientas
Distributed Systems Administration Utilities (DSAU) incluyen la
herramienta de código 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. 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 formatear 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». 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 3-4, «Arquitectura de la herramienta pdsh » muestra
los componentes de pdsh y su arquitectura. Para obtener más información sobre pdsh y dshbak, consulte las páginas de manual de referencia
correspondientes. Empaquetadores
de utilidades para pdshLos 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. |
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. Configuración
de la seguridadLas 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 seguridad de Remote ShellCuando se utiliza el transporte de comandos mediante el protocolo
remote shell, el usuario local debe tener configurado un archivo $HOME/.rhosts 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 seguridad de sshssh utiliza claves de host públicas para autenticar
los hosts remotos y 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 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 seguridadEl protocolo remote shell es un protocolo intrínsecamente
no seguro. Es el protocolo que utilizan los «comandos r» de
Berkeley: rlogin, rcp, remsh, etcétera. 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 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. pdsh@<nombre de host local>: <nombre de host de 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. pdsh@<nombre de host local>: <nombre de host de destino>: connect: Connection refused Razón: El sistema de destino está inaccesible.
Es posible que los servicios “r” estén
deshabilitados para este sistema. pdsh@<nombre de host local>: <nombre de host de 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. 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.
|
Versión para imprimir
