RH342 Red Hat Enterprise Linux Diagnostics and Troubleshooting

RED HAT®
TRAINING
Capacitación integral y práctica que resuelve los problemas del mundo

real
Red Hat Enterprise

Linux Diagnostics and
Troubleshooting
Manual del alumno (ROLE)
© 2016 Red Hat, Inc. RH342-RHEL7.2-es-1-20160321

RED HAT
ENTERPRISE LINUX
DIAGNOSTICS AND
TROUBLESHOOTING
Red Hat Enterprise Linux Diagnostics and Troubleshooting
Red Hat Enterprise Linux 7.2 RH342

Edición 1 20160321
Autores: Wander Boessenkool, Chen Chang, George Hacker

Editor: Steven Bonneville
Copyright © 2016 Red Hat, Inc.
The contents of this course and all its modules and related materials, including handouts
to audience members, are Copyright © 2016 Red Hat, Inc.
No part of this publication may be stored in a retrieval system, transmitted or

reproduced in any way, including, but not limited to, photocopy, photograph, magnetic,
electronic or other record, without the prior written permission of Red Hat, Inc.
This instructional program, including all material provided herein, is supplied without
any guarantees from Red Hat, Inc. Red Hat, Inc. assumes no liability for damages or legal
action arising from the use or misuse of contents or details contained herein.
If you believe Red Hat training materials are being used, copied, or otherwise improperly
distributed please e-mail training@redhat.com or phone toll-free (USA) +1 (866) 626-2994
or +1 (919) 754-3700.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, Hibernate, Fedora, the
Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States
and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other
countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a registered trademark of Silicon Graphics International Corp. or its subsidiaries

in the United States and/or other countries.
The OpenStack® Word Mark and OpenStack Logo are either registered trademarks/
service marks or trademarks/service marks of the OpenStack Foundation, in the United
States and other countries and are used with the OpenStack Foundation's permission.
We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the
OpenStack community.
All other trademarks are the property of their respective owners.
Colaboradores: Andrew Blum

Convenciones del documento ix
Notas y advertencias .............................................................................................. ix
Introducción xi
Red Hat Enterprise Linux Diagnostics and Troubleshooting ....................................... xi
Orientación sobre el entorno del trabajo de laboratorio en el aula ............................ xii
Internacionalización .............................................................................................. xiv
1. ¿Qué es la solución de problemas? 1

Uso del método científico ........................................................................................ 2
Ejercicio guiado: Uso del método científico ............................................................... 5
Recopilación de información .................................................................................... 8
Ejercicio guiado: Recopilación de información ......................................................... 11
Uso de los recursos de Red Hat ............................................................................. 14
Ejercicio guiado: Uso de los recursos de Red Hat .................................................... 22
Trabajo de laboratorio: ¿Qué es la solución de problemas? ...................................... 25
Resumen .............................................................................................................. 31
2. Ser proactivo 33

Monitoreo de sistemas .......................................................................................... 34
Ejercicio guiado: Monitoreo de sistemas ................................................................. 39
Configuración del registro remoto .......................................................................... 42
Ejercicio guiado: Configuración de registros remotos ............................................... 46
Uso de la gestión de configuraciones ..................................................................... 49
Ejercicio guiado: Uso de gestión de configuraciones ................................................ 54
Configuración de seguimiento de cambios .............................................................. 57
Ejercicio guiado: Configuración de seguimiento de cambios ..................................... 63
Trabajo de laboratorio: Ser proactivo ...................................................................... 65
Resumen .............................................................................................................. 71
3. Solución de problemas de arranque 73

Resolución de problemas del cargador de arranque en sistemas BIOS ...................... 74
Ejercicio guiado: Resolución de problemas del cargador de arranque en sistemas
BIOS ..................................................................................................................... 78
Resolución de problemas del cargador de arranque en sistemas UEFI ...................... 80
Prueba: Resolución de problemas del cargador de arranque en sistemas UEFI ........... 84
Tratamiento de servicios con fallas ......................................................................... 86
Ejercicio guiado: Tratamiento de servicios con fallas ................................................ 90
Recuperación de la contraseña de root .................................................................. 93
Ejercicio guiado: Recuperación de una contraseña de root ....................................... 96
Trabajo de laboratorio: Solución de problemas de arranque .................................... 99
Resumen ............................................................................................................. 102
4. Identificación de problemas de hardware 103

Identificación de problemas de hardware ............................................................. 104
Ejercicio guiado: Identificación de problemas de hardware ..................................... 109
Administración de los módulos del kernel ............................................................. 111
Ejercicio guiado: Administración de módulos del kernel ......................................... 114
Gestión de problemas de virtualización ................................................................ 116
Ejercicio guiado: Gestión de problemas de virtualización ........................................ 120
Trabajo de laboratorio: Identificación de problemas de hardware ........................... 122
Resumen ............................................................................................................. 125
5. Solución de problemas de almacenamiento 127
RH342-RHEL7.2-es-1-20160321 v
Orientación sobre la stack (pila) de almacenamiento de Linux ................................ 128

Prueba: Orientación sobre la pila de almacenamiento de Linux .............................. 137
Recuperación de archivos dañados del sistema ..................................................... 139
Ejercicio guiado: Recuperación de archivos dañados del sistema ............................ 147
Recuperación de accidentes de LVM ..................................................................... 151
Ejercicio guiado: Recuperación de accidentes de LVM ............................................ 155
Tratamiento de problemas de LUKS ..................................................................... 158
Ejercicio guiado: Tratamiento de problemas de LUKS ............................................. 162
Resolución de problemas de iSCSI ........................................................................ 166
Ejercicio guiado: Resolución de problemas de iSCSI ............................................... 173
Trabajo de laboratorio: Solución de problemas de almacenamiento ........................ 177
Resumen ............................................................................................................. 186
6. Solución de problemas de RPM 187

Resolución de problemas de dependencia ............................................................ 188
Ejercicio guiado: Resolución de problemas de dependencia ................................... 191
Recuperación de una base de datos dañada de RPM ............................................. 194
Ejercicio guiado: Recuperación de una base de datos dañada de RPM ..................... 196
Identificación y recuperación de archivos cambiados ............................................. 200
Ejercicio guiado: Identificación y recuperación de archivos cambiados ..................... 204
Suscripción de sistemas a actualizaciones de Red Hat ........................................... 207
Prueba: Suscripción de sistemas a actualizaciones de Red Hat ............................... 217
Trabajo de laboratorio: Solución de problemas de RPM ......................................... 219
Resumen ............................................................................................................. 223
7. Solución de problemas de red 225

Prueba de conectividad ....................................................................................... 226
Ejercicio guiado: Prueba de conectividad .............................................................. 232
Resolución de problemas de conectividad ............................................................ 239
Ejercicio guiado: Resolución de problemas de conectividad .................................... 247
Inspección del tráfico de red ................................................................................ 254
Ejercicio guiado: Inspección del tráfico de red ....................................................... 258
Trabajo de laboratorio: Solución de problemas de red ........................................... 264
Resumen ............................................................................................................. 269
8. Solución de problemas de la aplicación 271

Resolución de dependencias de la librería ............................................................ 272
Ejercicio guiado: Resolución de dependencias de la librería .................................... 276
Depuración de fugas de memoria ........................................................................ 280
Ejercicio guiado: Depuración de fugas de memoria ................................................ 282
Depuración de ejecuciones de la aplicación .......................................................... 285
Ejercicio guiado: Depuración de ejecuciones de la aplicación .................................. 290
Trabajo de laboratorio: Solución de problemas de la aplicación .............................. 293
Resumen ............................................................................................................. 297
9. Tratamiento de problemas de seguridad 299

Solución de problemas de SELinux ....................................................................... 300
Ejercicio guiado: Resolución de problemas de SELinux ........................................... 305
Gestión de problemas de autenticación ................................................................ 307
Ejercicio guiado: Gestión de problemas de autenticación ....................................... 310
Resolución de problemas de Kerberos y LDAP ...................................................... 313
Ejercicio guiado: Resolución de problemas de Kerberos y LDAP .............................. 318
Trabajo de laboratorio: Tratamiento de problemas de seguridad ............................ 322
vi RH342-RHEL7.2-es-1-20160321
Resumen ............................................................................................................. 327
10. Solución de problemas de kernel 329
Volcados de error de kernel ................................................................................. 330
Ejercicio guiado: Creación de volcados de error de kernel ...................................... 340
Depuración de kernel con SystemTap ................................................................... 344
Ejercicio guiado: Depuración de kernel con SystemTap .......................................... 350
Trabajo de laboratorio: Solución de problemas de kernel ....................................... 354
Resumen ............................................................................................................. 361
11. Revisión integral de Red Hat Enterprise Linux Diagnostics and Troubleshooting 363
Revisión integral de Red Hat Enterprise Linux Diagnostics and Troubleshooting ....... 364
Trabajos de laboratorio de revisión integral .......................................................... 367
Trabajo de laboratorio: Ámsterdam — La aplicación personalizada no funciona ....... 368
Trabajo de laboratorio: Tokio — Problemas para registrarse en la consola ............... 373
Trabajo de laboratorio: París — Problemas de autenticación .................................. 376
Trabajo de laboratorio: Londres — Problema en el servidor web ............................ 381
Trabajo de laboratorio: Nueva York — Demoras en la red ...................................... 389
RH342-RHEL7.2-es-1-20160321 vii
viii
Convenciones del documento
Notas y advertencias
Nota
Las "notas" son consejos, atajos o enfoques alternativos para una tarea
determinada. Omitir una nota no debería tener consecuencias negativas, pero
quizás se pase por alto algún truco que puede simplificar una tarea.
Importante
En los cuadros "importantes", se detallan cosas que se olvidan con facilidad:
cambios de configuración que solo se aplican a la sesión actual o servicios que
se deben reiniciar para poder aplicar una actualización. Omitir un cuadro con la
etiqueta "Importante" no provocará pérdida de datos, pero puede causar irritación y
frustración.
Advertencia
No se deben omitir las "advertencias". Es muy probable que omitir las advertencias
provoque la pérdida de datos.
Referencias
En las "referencias", se describe el lugar donde se puede encontrar documentación
externa relevante para un tema.
RH342-RHEL7.2-es-1-20160321 ix
x
Introducción
Red Hat Enterprise Linux Diagnostics and
Troubleshooting
En Red Hat Enterprise Linux Diagnostics and Troubleshooting (RH342) los administradores
de sistemas podrán encontrar herramientas y técnicas que necesitan para diagnosticar y
solucionar correctamente una variedad de problemas que puedan surgir. Los estudiantes
examinarán problemas de varios subsistemas para diagnosticar y solucionar problemas
comunes. Este enfoque luego se utiliza para solucionar varios tipos de problemas, incluidos
problemas de arranque, problemas de hardware, problemas de almacenamiento, problemas
de RPM, problemas de red, problemas con aplicaciones de terceros, problemas de
seguridad y problemas de kernel. Al final del curso, los estudiantes pueden completar varios
laboratorios de revisión integrales para evaluar sus conocimientos.
Objetivos
• Diagnosticar problemas en varios subsistemas en sistemas RHEL7 mediante herramientas
proporcionadas con la distribución.
• Recopilar información para ayudar al Soporte de Red Hat en el diagnóstico y la solución de

problemas que puedan surgir en un sistema Red Hat Enterprise Linux.
• Solucionar problemas en una máquina de Red Hat Enterprise Linux mediante las
herramientas proporcionadas por la distribución.
• Preparar a los estudiantes para el Examen de certificación de Red Hat Enterprise Linux
Diagnostics and Troubleshooting (EX342).
Destinatarios
• El curso Red Hat Enterprise Linux Diagnostics and Troubleshooting está diseñado para
los administradores de sistemas sénior que desean aprender más sobre la solución de
problemas.
Requisitos previos
• Se requiere una certificación RHCSA, o conocimientos equivalentes, para asistir a este
curso.
• Se recomienda una certificación RHCE, o conocimientos equivalentes, para asistir a este

curso.
RH342-RHEL7.2-es-1-20160321 xi
Introducción
Orientación sobre el entorno del trabajo de

laboratorio en el aula
En este curso, los estudiantes realizarán la mayor parte de los ejercicios prácticos
y el trabajo de laboratorio con tres sistemas informáticos, que se denominarán
workstation, servera y serverb. Estas máquinas tienen los siguientes nombres
de host: workstation.lab.example.com, servera.lab.example.com, y
serverb.lab.example.com. Todas las máquinas tienen una cuenta de usuario, student, con
la contraseña student. La contraseña root de los dos sistemas es redhat.
En un aula de aprendizaje en línea de Red Hat, se asignarán a los estudiantes computadoras

remotas a las que accederán mediante una aplicación web alojada en rol.redhat.com. Los
estudiantes deberán iniciar sesión en esta máquina con las credenciales de usuario que se
proporcionaron cuando se registraron en la clase.
Los sistemas que utilizan los estudiantes emplean una subred IPv4 privada. Para cada
estudiante, su red IPv4 es 172.25.250.0/24.
Máquinas del aula

Nombre de la máquina Direcciones IP Rol
workstation.lab.example.com 172.25.250.254 Computadora “cliente” del
estudiante
servera.lab.example.com 172.25.250.10 Primera computadora
“servidor” del estudiante
serverb.lab.example.com 172.25.250.11 Segunda computadora
“servidor” del estudiante
Control de sus estaciones

En la parte superior de la consola se describe el estado de su máquina.
Estados de la máquina
Estado Descripción
none (ninguno) Todavía no se ha iniciado su máquina. Cuando se inicie, su máquina
arrancará en un estado recientemente inicializado (el disco se habrá
reiniciado).
starting (en inicio) Su máquina está por arrancar.
running (en Su máquina se está ejecutando y está disponible (o bien, cuando
ejecución) arranque, pronto lo estará).
stopping (en Su máquina está por apagarse.
detención)
stopped (detenida) Su máquina se ha apagado completamente. Al iniciarse, su máquina
arrancará en el mismo estado en el que estaba cuando se apagó (el
disco se habrá preservado).
impaired (afectada) No se puede realizar una conexión de red en su máquina. En
general, este estado se logra cuando un estudiante ha corrompido
las reglas de conexión de la red o del cortafuegos. Si se restablece la
xii RH342-RHEL7.2-es-1-20160321
Orientación sobre el entorno del trabajo de laboratorio en el aula
Estado Descripción
máquina y el estado permanece, o si es intermitente, deberá abrir
un caso de soporte.
Según el estado de su máquina, tendrá disponibles una selección de las siguientes acciones.
Acciones de la máquina
Acción Descripción
Start Station (Iniciar Iniciar ("encender") la máquina.
estación)
Stop Station Detener ("apagar") la máquina y preservar el contenido del disco.
(Detener estación)
Reset Station Detener ("apagar") la máquina y restablecer el disco de modo que
(Restablecer vuelva a su estado original. Precaución: Se perderá cualquier
estación) trabajo generado en el disco.
Actualización Si se actualiza la página, se volverá a realizar un sondeo del estado
de la máquina.
Increase Timer Agrega 15 minutos al temporizador para cada clic.
(Aumentar
temporizador)
Temporizador de la estación
Su inscripción al aprendizaje en línea de Red Hat le da derecho a una cierta cantidad de
tiempo de uso del equipo. Para ayudarlo a conservar su tiempo, las máquinas tienen un
temporizador asociado, que se inicializa en 60 minutos cuando se inicia su máquina.
El temporizador funciona como un "switch de seguridad", que disminuye mientras funciona

su máquina. Si el temporizador se reduce por debajo de 0, puede optar por incrementar el
temporizador.
RH342-RHEL7.2-es-1-20160321 xiii
Introducción
Internacionalización
Compatibilidad de idioma
Red Hat Enterprise Linux 7 admite oficialmente 22 idiomas: inglés, asamés, bengalí, chino
(simplificado), chino (tradicional), francés, alemán, guyaratí, hindi, italiano, japonés, canarés,
coreano, malayalam, maratí, oriya, portugués (brasileño), panyabí, ruso, español, tamil y
telugú.
Selección de idioma por usuario

Es posible que los usuarios prefieran usar un idioma diferente para su entorno de escritorio
distinto al predeterminado del sistema. Quizás también quieran definir su cuenta para usar
una distribución del teclado o un método de entrada distinto.
Configuración de idioma
En el entorno de escritorio GNOME, posiblemente el usuario deba definir el idioma de su
preferencia y el método de entrada la primera vez que inicie sesión. Si no es así, la manera
más simple para un usuario individual de definir el idioma de su preferencia y el método de
entrada es usando la aplicación Region & Language (Región e idioma). Ejecute el comando
gnome-control-center region o en la barra superior, seleccione (User) (Usuario) >
Settings (Parámetros). En la ventana que se abre, seleccione Region & Language (Región e
idioma). El usuario puede hacer clic en la casilla Language (Idioma) y seleccionar el idioma
de su preferencia de la lista que aparece. Esto también actualizará la configuración Formats
(Formatos) mediante la adopción del valor predeterminado para ese idioma. La próxima vez
que el usuario inicie sesión, se efectuarán los cambios.
Estas configuraciones afectan al entorno de escritorio GNOME y todas las aplicaciones,

incluida gnome-terminal, que se inician dentro de este. Sin embargo, no se aplican a la
cuenta si el acceso a ella es mediante un inicio de sesión ssh desde un sistema remoto o
desde una consola de texto local (como tty2).
nota
Un usuario puede hacer que su entorno de shell use la misma configuración de
LANG que su entorno gráfico, incluso cuando inician sesión mediante una consola
de texto o mediante ssh. Una manera de hacer esto es colocar un código similar al
siguiente en el archivo ~/.bashrc del usuario. Este código de ejemplo definirá el
idioma empleado en un inicio de sesión en interfaz de texto, de modo que coincida
con el idioma actualmente definido en el entorno de escritorio GNOME del usuario.
i=$(grep 'Language=' /var/lib/AccountService/users/${USER} \

| sed 's/Language=//')
if [ "$i" != "" ]; then
export LANG=$i
fi
Es posible que algunos idiomas, como el japonés, coreano, chino y otros con un
conjunto de caracteres no latinos, no se vean correctamente en consolas de texto
locales.
xiv RH342-RHEL7.2-es-1-20160321
Selección de idioma por usuario
Se pueden crear comandos individuales para utilizar otro idioma mediante la configuración
de la variable LANG en la línea de comandos:
[user@host ~]$ LANG=fr_FR.utf8 date

jeu. avril 24 17:55:01 CDT 2014
Los comandos subsiguientes se revertirán y utilizarán el idioma de salida predeterminado del

sistema. El comando locale se puede usar para comprobar el valor actual de LANG y otras
variables de entorno relacionadas.
Valores del método de entrada

GNOME 3 en Red Hat Enterprise Linux 7 emplea de manera automática el sistema de
selección de método de entrada IBus, que permite cambiar las distribuciones del teclado y
los métodos de entrada de manera rápida y sencilla.
La aplicación Region & Language (Región e idioma) también se puede usar para habilitar
métodos de entrada alternativos. En la ventana de la aplicación Region & Language (Región
e idioma), la casilla Input Sources (Fuentes de entrada) muestra los métodos de entrada
disponibles en este momento. De forma predeterminada, es posible que English (US) (Inglés
[EE. UU.]) sea el único método disponible. Resalte English (US) (Inglés [EE. UU.]) y haga clic en
el ícono de keyboard (teclado) para ver la distribución actual del teclado.
Para agregar otro método de entrada, haga clic en el botón +, en la parte inferior izquierda
de la ventana Input Sources (Fuentes de entrada). Se abrirá la ventana Add an Input Source
(Añadir una fuente de entrada). Seleccione su idioma y, luego, el método de entrada o la
distribución del teclado de su preferencia.
Una vez que haya más de un método de entrada configurado, el usuario puede alternar entre
ellos rápidamente escribiendo Super+Space (en ocasiones denominado Windows+Space).
Un indicador de estado en la barra superior de GNOME con dos funciones: por un lado, indica
el método de entrada activo; por el otro lado, funciona como un menú que puede usarse
para cambiar de un método de entrada a otro o para seleccionar funciones avanzadas de
métodos de entrada más complejos.
Algunos de los métodos están marcados con engranajes, que indican que tienen opciones de
configuración y capacidades avanzadas. Por ejemplo, el método de entrada japonés Japanese
(Kana Kanji) (japonés [Kana Kanji]) le permite al usuario editar previamente texto en latín
y usar las teclas de Down Arrow (flecha hacia abajo) y Up Arrow (flecha hacia arriba) para
seleccionar los caracteres correctos que se usarán.
El indicador también puede ser de utilidad para los hablantes de inglés de Estados Unidos.
Por ejemplo, dentro de English (United States) (Inglés [Estados Unidos]) está la configuración
del teclado English (international AltGr dead keys), que trata AltGr (o la tecla Alt derecha)
en un teclado de 104/105 teclas de una PC como una tecla "Bloq Mayús secundaria" y tecla
de activación de teclas muertas para escribir caracteres adicionales. Hay otras distribuciones
alternativas disponibles, como Dvorak.
RH342-RHEL7.2-es-1-20160321 xv
Introducción
nota
Cualquier carácter Unicode puede ingresarse en el entorno de escritorio GNOME,
si el usuario conoce el código Unicode del carácter, escribiendo Ctrl+Shift+U,
seguido por el código. Después de ingresar Ctrl+Shift+U, aparecerá una u
subrayada que indicará que el sistema espera la entrada del código Unicode.
Por ejemplo, la letra del alfabeto griego en minúscula lambda tiene el código U
+03BB y puede ingresarse escribiendo Ctrl+Shift+U, luego 03bb y, por último,
Enter.
Valores de idioma predeterminado en todo el

sistema
El idioma predeterminado del sistema está definido en US English, que utiliza la codificación
UTF-8 de Unicode como su conjunto de caracteres (en_US.utf8), pero puede cambiarse
durante o después de la instalación.
Desde la línea de comandos, root puede cambiar la configuración local de todo el sistema con
el comando localectl. Si localectl se ejecuta sin argumentos, mostrará la configuración
local de todo el sistema actual.
Para configurar el idioma de todo el sistema, ejecute el comando localectl set-locale

LANG=locale, donde locale es el $LANG adecuado de la tabla "Referencia de códigos de
idioma" en este capítulo. El cambio tendrá efecto para usuarios en su próximo inicio de
sesión y se almacena en /etc/locale.conf.
[root@host ~]# localectl set-locale LANG=fr_FR.utf8
En GNOME, un usuario administrativo puede cambiar esta configuración en Region &

Language (Región e idioma) y al hacer clic en el botón Login Screen (Pantalla de inicio de
sesión) ubicado en la esquina superior derecha de la ventana. Al cambiar la opción de
Language (Idioma) de la pantalla de inicio de sesión, también ajustará el valor de idioma
predeterminado de todo el sistema en el archivo de configuración /etc/locale.conf.
xvi RH342-RHEL7.2-es-1-20160321
Paquetes de idiomas
Importante
Las consolas de texto locales como tty2 están más limitadas en las fuentes
que pueden mostrar que las sesiones gnome-terminal y ssh. Por ejemplo, los
caracteres del japonés, coreano y chino posiblemente no se visualicen como se
espera en una consola de texto local. Por este motivo, es posible que tenga sentido
usar el inglés u otro idioma con un conjunto de caracteres latinos para la consola de
texto del sistema.
De manera similar, las consolas de texto locales admiten una cantidad de métodos
de entrada también más limitada y esto se administra de manera separada desde
el entorno de escritorio gráfico. La configuración de entrada global disponible se
puede configurar mediante localectl tanto para consolas virtuales de texto
locales como para el entorno gráfico X11. Para obtener más información, consulte
las páginas del manual localectl(1), kbd(4) y vconsole.conf(5).
Paquetes de idiomas
Si utiliza un idioma diferente al inglés, posiblemente desee instalar "paquetes de idiomas"
adicionales para disponer de traducciones adicionales, diccionarios, etcétera. Para ver la
lista de paquetes de idiomas disponibles, ejecute yum langavailable. Para ver la lista de
paquetes de idiomas actualmente instalados en el sistema, ejecute yum langlist. Para
agregar un paquete de idioma adicional al sistema, ejecute yum langinstall code, donde
code (código) es el código en corchetes después del nombre del idioma en el resultado de
yum langavailable.
Referencias
Páginas del manual: locale(7), localectl(1), kbd(4), locale.conf(5),
vconsole.conf(5), unicode(7), utf-8(7) y yum-langpacks(8).
Las conversiones entre los nombres de las configuraciones X11 del entorno de
escritorio gráfico y sus nombres en localectl se pueden encontrar en el archivo /
usr/share/X11/xkb/rules/base.lst.
RH342-RHEL7.2-es-1-20160321 xvii
Introducción
Referencia de códigos de idioma

Códigos de idioma
Idioma Valor $LANG
Inglés (EE. UU.) en_US.utf8
Asamés as_IN.utf8
Bengalí bn_IN.utf8
Chino (simplificado) zh_CN.utf8
Chino (tradicional) zh_TW.utf8
Francés fr_FR.utf8
Alemán de_DE.utf8
Guyaratí gu_IN.utf8
Hindi hi_IN.utf8
Italiano it_IT.utf8
Japonés ja_JP.utf8
Canarés kn_IN.utf8
Coreano ko_KR.utf8
Malayalam ml_IN.utf8
Maratí mr_IN.utf8
Odia or_IN.utf8
Portugués (brasileño) pt_BR.utf8
Panyabí pa_IN.utf8
Ruso ru_RU.utf8
Español es_ES.utf8
Tamil ta_IN.utf8
Telugú te_IN.utf8
xviii RH342-RHEL7.2-es-1-20160321
TRAINING
CAPÍTULO 1
¿QUÉ ES LA SOLUCIÓN DE
PROBLEMAS?
Visión general
Meta Describa una estrategia generalizada para la solución de
problemas.
Objetivos • Identificar un enfoque sistemático para resolver
problemas mediante el método científico.
• Recopilar información del sistema para ayudar en la

solución de problemas.
• Usar los recursos de Red Hat para ayudar en la solución

de problemas.
Secciones • Uso del método científico (y ejercicio guiado)
• Recopilación de información (y ejercicio guiado)
• Uso de los recursos de Red Hat (y ejercicio guiado)

Trabajo de laboratorio • ¿Qué es la solución de problemas?
RH342-RHEL7.2-es-1-20160321 1
Capítulo 1. ¿Qué es la solución de problemas?
Uso del método científico
Objetivos
Después de completar esta sección, los estudiantes podrán utilizar un enfoque sistemático a
la solución de problemas mediante el método científico.
¿Qué es la solución de problemas?

La solución de problemas es el arte de tomar un problema, recopilar información sobre él,
analizarlo y, por último, resolverlo. Aunque algunos problemas son intrínsecamente “más
difíciles” que otros, se puede usar el mismo enfoque básico para todos los problemas.
El uso de un enfoque fijo garantiza que no se olviden los pasos importantes y que la solución
de problemas se vuelva un proceso repetible.
No solo una solución

Aunque solucionar un problema es una de las partes más importantes de la solución de
problemas, hay otras partes que no pueden descuidarse: documentar el problema (y la
solución) y realizar un análisis de causa raíz (RCA).
Documentar el problema (y la solución) puede ayudar en el futuro cuando otro administrador

(o posiblemente el mismo) se enfrente al mismo problema o a uno similar. Realizar un
análisis de causa raíz puede ayudar a prevenir problemas similares en el futuro.

Un buen esquema para seguir cuando se resuelven problemas es el método científico:
1. Definir el problema con claridad
Aléjese un paso y vea el panorama completo; luego, defina el problema real con claridad.
La mayoría de los problemas que se informan son síntomas de otro problema, no el
problema real.
Por ejemplo, un usuario puede llamar porque no puede iniciar sesión en una máquina.
Aunque es un problema para el usuario, el problema real puede ser una contraseña
olvidada, una máquina configurada de manera incorrecta, un problema de red, etc. Se
necesita realizar una investigación para determinar la causa de este síntoma.
Una acción típica durante este proceso es intentar recrear el problema u observar el
problema cuando sucede.
2. Recopilar información
El próximo paso es recopilar la mayor cantidad de información (relevante) como sea

posible. Esta información puede provenir de una gran variedad de fuentes: lectura de
archivos de registro, información mostrada en la pantalla o en una GUI, preguntas de
seguimiento para la persona que informó el problema, etc.
Durante este paso, “información relevante” es un término relativamente amplio; la

información de subsistemas aparentemente desconectados puede resultar útil.
2 RH342-RHEL7.2-es-1-20160321
Por otro lado, recopilar demasiada información también es innecesario y puede resultar
contraproducente, ya que se deberá ver, evaluar e interpretar toda la información.
3. Formular una hipótesis
Después de observar toda la información recopilada, y los síntomas observados/

informados, es hora de formular una hipótesis sobre la causa del problema.
A veces puede ser fácil; por ejemplo, cuando un usuario olvida su contraseña. Otras
veces puede ser más difícil; por ejemplo, cuando un único servicio en un clúster de alta
disponibilidad tiene fallas en el arranque los lunes durante los meses que contienen
una "e" en su nombre. La clave que debe recordar durante este paso es que la hipótesis
es solo eso, una hipótesis: una conjetura con respecto a cuál puede ser la causa del
problema. Durante los siguientes pasos, se evaluará esta hipótesis. Si resulta que la
hipótesis era incorrecta, se puede formular una nueva.
4. Probar la hipótesis
Cuando formula una hipótesis inicial, se puede probar su validez. La manera en que se
realizan las pruebas depende del problema y de la hipótesis.
Por ejemplo, cuando la hipótesis para un problema de inicio de sesión indica que “la
conexión de red entre la estación de trabajo y el KDC se interrumpe por un firewall,”
las pruebas serán diferentes a las de una hipótesis para un servidor que se reinicia
espontáneamente y que incluye un UPS con fallas.
Si, después de las pruebas, la hipótesis parece ser verdadera, se realizará un intento
para solucionar el problema. Si se llega a la conclusión de que la hipótesis no es válida,
deberá formular una nueva hipótesis, posiblemente mediante el uso de información
adicional encontrada durante la prueba de la hipótesis anterior.
5. Solucionar el problema
Si no se llega a la conclusión de que la hipótesis no es válida, se realiza un intento para

solucionar el problema. Durante esta etapa, es fundamental cambiar solo una variable a
la vez, documentando todos los cambios realizados y probando cada cambio de manera
individual.
También es vital guardar las copias de seguridad de los archivos de configuración

cambiados y revertir esas copias de seguridad si se descubre que un cambio no fue
efectivo. Por lo general, modificar varias configuraciones a la vez solo genera más
problemas, no soluciones.
Después de cualquier cambio, deberá evaluar la configuración completa para ver si se

resolvió el problema. Deberá revertir los cambios y, posiblemente, formular una nueva
hipótesis si se llega a la conclusión de que un cambio no resolvió el problema.
6. Limpiar y repetir
RH342-RHEL7.2-es-1-20160321 3
Si las soluciones propuestas no resolvieron el problema, deberá reanudar el proceso

desde el inicio. Esta vez, puede agregar cualquier información nueva descubierta
durante este ciclo para formular una nueva hipótesis.
4 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Uso del método científico
Ejercicio guiado: Uso del método científico
En este trabajo de laboratorio, resolverá un problema de inicio de sesión mediante el método

científico.
Recursos
Máquinas • workstation
• servera
Resultados
Deberá poder resolver un problema de inicio de sesión mediante el método científico.
Andes de comenzar
En su sistema workstation, ejecute el comando lab scientificmethod setup para
preparar sus sistemas para este ejercicio.
[student@workstation ~]$ lab scientificmethod setup
Durante el fin de semana, algunos de sus colegas han estado realizando mantenimiento
de usuarios. Esta mañana, uno de sus usuarios, student, llama al centro de ayuda para
reclamar que su inicio de sesión ya no está funcionando en servera.
Por lo general, el usuario inicia sesión con el nombre de cuenta student y, en contra de
todos los protocolos de seguridad, el usuario le informó que su contraseña también es
student.
Además, el usuario también le informó que el inicio de sesión sin contraseña en ssh
normalmente funciona desde la cuenta student en workstation.
Buscando los ajustes predeterminados para los usuarios de esta clase, descubre que el
directorio de inicio de este usuario debería estar configurado en /home/student, la UID y
GID deberían estar en 1000, y que el usuario prefiere la shell bash.
1. Comience por reproducir el problema, observando la mayor cantidad de detalles e

información posible acerca del problema.
1.1. Desde un prompt de comando en workstation, intente utilizar ssh para iniciar
sesión en la cuenta student en servera. ¿Qué observa, y qué le indica esto?
[student@workstation ~]$ ssh student@servera

Last login: Wed Dec 9 14:02:23 from workstation.lab.example.com
Connection to server closed.
La conexión se cierra inmediatamente, pero la autenticación se efectúa.
1.2. Abra una ventana de la consola de servera e intente iniciar sesión como student
con la contraseña student. ¿Qué ocurre?
El inicio de sesión parece efectuarse sin errores de autenticación, pero la sesión se

cierra de inmediato.
RH342-RHEL7.2-es-1-20160321 5
2. Ahora que sabemos que student puede autenticarse correctamente, pero la sesión
resultante se cierra de inmediato, es hora de recopilar más información sobre el sistema
servera.
2.1. Intente aplicar ssh en la cuenta root en el sistema servera desde workstation. Si
se necesita una contraseña, debería ser redhat.
[student@workstation ~]$ ssh root@servera
2.2. Como root en servera, intente utilizar su - para cambiar a la cuenta student.
[root@servera ~]# su - student

Last login: Wed Dec 9 14:32:08 CET 2015 from workstation.lab...
2.3. Dado que la cuenta root aún funciona, puede usar eso para recopilar información
adicional sobre la cuenta student. Compruebe la última vez que student inició
sesión correctamente.
[root@servera ~]# lastlog -u student

Username Port From Latest
student pts/0 workstation.lab. Wed Dec 9 14:32:08 +0100 2015
Según este resultado, el usuario student inició sesión correctamente durante

nuestras pruebas anteriores, lo que confirma la sospecha de que algo está
finalizando la sesión antes de tiempo.
2.4. Como root en servera, utilice la herramienta getent para inspeccionar los ajustes
del usuario student.
[root@servera ~]# getent passwd student

student:x:1000:1000:Student User:/home/student:/bin/false
3. A través de la información recopilada en el paso anterior, formule una hipótesis sobre

qué es lo que está ocurriendo con la cuenta student.
3.1. Observando el resultado getent, se da cuenta de que la shell del usuario está
configurada en /bin/false. Esta no es una shell válida, ni tampoco la shell que el
usuario prefiere.
4. Restablezca la shell para student a /bin/bash y verifique que se haya resuelto el

problema.
4.1. Restablezca la shell para student en servera a /bin/bash.
[root@servera ~]# chsh -s /bin/bash student

Changing shell for student.
Shell changed.
4.2. Intente aplicar ssh desde workstation a student en servera.
[student@workstation ~]$ ssh student@servera
6 RH342-RHEL7.2-es-1-20160321
5. Verifique su trabajo ejecutando el comando lab scientificmethod grade en
workstation.
[student@workstation ~]$ lab scientificmethod grade
Si este ejercicio no completó correctamente, inténtelo de nuevo o utilice el comando lab

scientificmethod solve para resolver el problema.
[student@workstation ~]$ lab scientificmethod solve
RH342-RHEL7.2-es-1-20160321 7
Recopilación de información
Objetivos
Después de completar esta sección, los estudiantes podrán recopilar varios fragmentos de
información del sistema para ayudar en la solución de problemas.
Varias formas de información

Cuando intente resolver un problema, hay varios datos que pueden o deben recopilarse
antes de formular una hipótesis. Es posible que deba recopilar parte de esta información del
informe del problema, como “¿Qué estaba haciendo cuando ocurrió el problema?” y “¿Vio
algún mensaje de error?”.
Puede recopilar otra información de primera mano; por ejemplo, cuando recrea el problema,
cuando consulta la base de datos de RPM, cuando lee archivos de registro, etc. No toda
esta información estará disponible prontamente; a menudo, deberá configurar un servicio
para aumentar la cantidad de registros que realiza, o necesitará configurar el sistema para
almacenar información que normalmente se descartaría en un reinicio.
Uso del diario (journal) del sistema

Por defecto, un sistema Red Hat Enterprise Linux 7 utiliza dos servicios de registro para los
registros del sistema: systemd-journald, que se configura solo para conservar a los registros
en la memoria, y rsyslogd, que recibe mensajes de systemd-journald (y otros) y los almacena
en el disco.
Para ver los mensajes del diario (journal) del sistema, puede usar una herramienta llamada
journalctl. Si se utiliza sin parámetros, mostrará todo el contenido del diario (journal) del
sistema, presentado en un paginador (por defecto, se utiliza less).
El resultado de journalctl puede modificarse al utilizar ambas opciones y ambos filtros.

Puede usar las opciones para cambiar la cantidad de líneas mostradas, activar el modo de
seguimiento, cambiar el campo mostrado, especificar un rango de tiempo, etc.
Puede usar los filtros para modificar para qué servicios y unidades se muestra la información,
para qué ejecutables se muestra información, etc.
Ejemplos de journalctl
journalctl -ef
Salta al final del diario (journal) (-e, y habilita el modo de seguimiento -f). Esto
mantendrá al diario (journal) abierto en la pantalla, mostrando nuevos mensajes a
medida que llegan.
journalctl _SYSTEMD_UNIT=sshd.service
Esto mostrará todos los mensajes generados por la unidad de systemd sshd.service.
journalctl -u sshd.service
Esto mostrará todos los mensajes generados por, y acerca de, la unidad de systemd
sshd.service.
8 RH342-RHEL7.2-es-1-20160321
Preservación del diario (journal)
journalctl -p emerg..err
Muestra todos los mensajes en el diario (journal) con una prioridad en el rango de emerg
hasta, e incluido, err.
Si se especifica una única prioridad, por ejemplo, -p err, se mostrarán todos los
mensajes hasta, e incluido, ese nivel.
journalctl -b -1
Solo muestra los mensajes del último arranque del sistema. Esto es útil para buscar
información acerca de un fallo en el sistema.
Esto requiere la configuración de un diario (journal) persistente.
journalctl --since "2015-02-02 20:30:00" --until "2015-03-31 12:00:00"

Muestra todos los mensajes entre el 2 de febrero, a las ocho y media de la noche, y el
mediodía del 31 de marzo.
Esto requiere la configuración de un diario (journal) persistente.
journalctl -o verbose
Utiliza el modo de resultado detallado (-o verbose). Esto mostrará todos los campos
almacenados en el diario (journal) con su nombre de campo y contenido.
Todos los nombres de campo pueden utilizarse como filtros en la línea de comandos
journalctl.
Para ver una lista completa de opciones y filtros, consulte la página del manual
journalctl(1).
Preservación del diario (journal)

Por defecto, Red Hat Enterprise Linux 7 almacena el diario (journal) del sistema en /run/
log/journal, que se almacena en un tmpfs. Esto implica que en un reinicio se perderá
toda la información almacenada. Si el directorio /var/log/journal está presente, el diario
(journal) se almacenará allí y, de este modo, habilitará un diario (journal) persistente en todos
los reinicios.
Siga estos pasos para habilitar un diario (journal) persistente:
1. Cree el directorio /var/log/journal.
[root@demo ~]# mkdir /var/log/journal
2. Configure la propiedad del grupo del nuevo directorio en systemd-journal, y los

permisos en 2755.
[root@demo ~]# chown root:systemd-journal /var/log/journal

[root@demo ~]# chmod 2755 /var/log/journal
3. Informe a systemd-journald que se debe utilizar la nueva ubicación al enviarle una

señal USR1. También bastará con un reinicio.
[root@demo ~]# killall -USR1 systemd-journald
RH342-RHEL7.2-es-1-20160321 9
Habilitación de información detallada

Muchas herramientas y servicios pueden aumentar la cantidad de registros que realizan,
así como la cantidad de información que muestran cuando se ejecutan desde la línea de
comandos, al utilizar varias opciones de configuración o indicadores de línea de comandos.
Por lo general, las opciones de la línea de comandos incluyen -v, que a menudo puede
especificarse varias veces, para aumentar los detalles, o incluir una opción --debug que
puede utilizarse.
Normalmente, los servicios tienen opciones de configuración, ya sea en su archivo de

configuración principal o en /etc/sysconfig/SERVICENAME, que también pueden utilizarse
para aumentar el nivel de registros o detalles.
Consulte los documentos de estos servicios individuales para aumentar los niveles de
detalles y registros.
Advertencia
Cuando utiliza la opción de depuración para un servicio en /etc/
sysconfig/SERVICENAME, a menudo esa opción también evitará que el daemon
se desconecte de la terminal. Cuando se inicia dicho servicio mediante systemctl,
y el tipo de servicio se configura en forking, no se devolverá el comando
systemctl hasta que se borre el servicio al presionar Ctrl+C. En estos casos,
ejecutar un servicio manualmente desde la línea de comandos también puede ser
una opción.
Referencias
Páginas del manual journalctl(1), systemd.journal-fields(7) y systemd-
journald.service(8).
10 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Recopilación de información
Ejercicio guiado: Recopilación de información
En este trabajo de laboratorio, utilizará archivos de registro para resolver un problema con un
servidor web.
Recursos
Archivos /var/www/html/test.html
• servera
Resultados
Deberá poder utilizar archivos de registro para resolver un problema con un servidor web.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab logread setup en su
máquina workstation.
[student@workstation ~]$ lab logread setup
Su máquina servera está ejecutando un servidor web, que sirve al archivo http://
servera.lab.example.com/test.html. Recibió un ticket de su gerente de pruebas
en el que indicó que no se puede acceder a este archivo desde un explorador web. No se
proporcionó información adicional en el ticket.
Investigue este problema mediante los archivos de registro en servera y, luego,

resuelva el problema. Para probar la línea de comandos en workstation, si no
desea abrir un explorador gráfico, puede usar el comando elinks -dump http://
servera.lab.example.com/test.html.
1. Comience por intentar reproducir el problema.
1.1. Como student en workstation, intente acceder a http://

servera.lab.example.com/test.html. Puede hacerlo al utilizar un explorador
Firefox o al ejecutar el siguiente comando:
[student@workstation ~]$ elinks -dump http://servera.lab.example.com/test.html
1.2. Piense en las posibles causas del error de prohibición HTTP 403 que encontró.
Este error puede tener varias razones: permisos de archivos, tipos de SELinux,
configuraciones httpd internas, etc.
Sabe que el servidor web está ejecutándose, recibió una respuesta, y que el firewall
está abierto.
2. Recopile información de los registros del servidor web en servera. Los registros
principales para httpd son /var/log/httpd/access_log para todos los intentos de
acceso, y /var/log/httpd/error_log para todos los errores.
2.1. Inspeccione /var/log/httpd/access_log en busca de algún mensaje relacionado

con esta falla.
RH342-RHEL7.2-es-1-20160321 11
[root@servera ~]# grep test.html /var/log/httpd/access_log

...
172.25.250.254 - - [10/Dec/2015:11:28:34 +0100] "GET /test.html HTTP/1.1" 403
211 "-" "Elinks/0.12pre6 (textmode; Linux; -)"
...
El 403 en el resultado es el código de estado HTTP. Aparte de eso, puede ver la URL
solicitada, la fecha y hora de la solicitud y el agente usuario utilizado, pero esta
información no lo ayuda con el problema.
2.2. Inspeccione /var/log/httpd/error_log en busca de algún mensaje relacionado

con esta falla.
[root@servera ~]# tail /var/log/httpd/error_log

...
[Thu Dec 10 11:28:34.378778 2015] [core:error] [pid 2028] (13)Permission Denied:
[client 172.25.250.254:57245] AH00132: file permissions deny server access: /
var/www/html/test.html
...
Este mensaje le indica que httpd está bloqueado por los permisos del archivo y no
puede leer el archivo test.html. Esto descarta un error de configuración interno
para httpd, pero deja a los permisos del archivo y a SELinux como los posibles
acusados.
3. Inspeccione los permisos del archivo en /var/www/html/test.html y corríjalos en

caso de ser necesario.
3.1. Inspeccione los permisos del archivo en /var/www/html/test.html.
[root@servera ~]# ls -l /var/www/html/test.html

-rw-------. 1 root root 5 Dec 10 11:27 /var/www/html/test.html
3.2. Esos permisos no parecen ser correctos. Permita que todos puedan leer el archivo.
[root@servera ~]# chmod 644 /var/www/html/test.html
3.3. Pruebe el acceso al archivo nuevamente, con Firefox o elinks.
3.4. Los permisos del archivo eran un problema, pero el problema aún no está resuelto.
Esto deja solo un posible acusado: SELinux.
4. Inspeccione el registro de SELinux en busca de denegaciones que hayan sucedido hoy y

corrija los problemas que detecta.
4.1. Inspeccione el registro de SELinux en busca de denegaciones que hayan sucedido

hoy.
[root@servera ~]# ausearch -i -m avc -ts today
12 RH342-RHEL7.2-es-1-20160321
...
type=AVC msg=audit(12/10/2015 10:41:19.890:3045) : avc: denied {open} for
pid=32712 comm=httpd path=/var/www/html/test.html dev="vda1" ino=25245202
scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0
tclass=file
...
Esto muestra que el archivo test.html tiene un tipo SELinux de tmp_t, que httpd
no tiene permitido abrir.
4.2. Solucione este problema al ejecutar un restorecon recursivo en /var/www.
[root@servera ~]# restorecon -Rv /var/www
4.3. Pruebe si ahora puede acceder a http://servera.lab.example.com/test.html

desde workstation.
5. Evalúe su trabajo y, luego, realice una limpieza en sus sistemas para el próximo ejercicio.
5.1. Evalúe su trabajo.
[student@workstation ~]$ lab logread grade
5.2. Realice una limpieza en sus sistemas para el próximo ejercicio.
[student@workstation ~]$ lab logread reset
RH342-RHEL7.2-es-1-20160321 13
Uso de los recursos de Red Hat
Objetivos
Después de completar esta sección, los estudiantes podrán utilizar los recursos de Red Hat
para solucionar problemas.
Portal de clientes de Red Hat

Con el portal de clientes de Red Hat (https://access.redhat.com), los clientes obtienen
acceso a todo lo que se ofrece con su suscripción a través de una práctica ubicación. Los
clientes pueden buscar soluciones, preguntas frecuentes y artículos a través de la base de
conocimientos. Se otorga acceso a la documentación oficial de los productos. Se pueden
enviar y administrar tickets de asistencia. Las suscripciones a productos de Red Hat pueden
asignarse a sistemas registrados, o puede anularse la asignación a ellos; también pueden
obtenerse descargas, actualizaciones y evaluaciones de software. Hay algunas secciones del
sitio de acceso público y otras exclusivas para clientes con suscripciones activas. Para obtener
ayuda con el acceso al Portal de clientes, visite https://access.redhat.com/help/.
Los clientes pueden trabajar con el portal de clientes de Red Hat a través de un navegador
web. En esta sección se presentará una herramienta de línea de comandos que también
puede utilizarse para obtener acceso a los servicios del portal de clientes de Red Hat,
redhat-support-tool.
Figura 1.1: Base de conocimientos en el portal de clientes de Red Hat
Recopilación de información con sosreport

Red Hat incluye una herramienta llamada sosreport en el paquete sos. Esta herramienta
puede recopilar varios fragmentos de información del sistema, incluidos archivos de registro
y archivos de configuración, y agruparlos en un tarball listo para enviarse al Soporte de Red
Hat.
Los administradores de sistema también pueden usar esta herramienta para recopilar
rápidamente información sobre sus propios sistemas.
Cuando se queda sin opciones, sosreport le pedirá al usuario sus iniciales, un número
de caso y, luego, recopilará un conjunto predeterminado de archivos y ajustes en un
tarball. Las opciones de la línea de comandos pueden utilizarse para habilitar o deshabilitar
complementos (plug-ins), configurar opciones de complementos (plug-ins) y hacer que el
proceso no sea interactivo.
Con sosreport -l puede solicitar una descripción completa de todos los complementos
(plug-ins), y si están habilitados o deshabilitados actualmente, junto con las opciones de
complementos (plug-ins). Cuando ejecuta un informe, puede usar la opción -e PLUGINS
para habilitar complementos adicionales, y puede usar la opción -k PLUGOPTS para
14 RH342-RHEL7.2-es-1-20160321
Uso de redhat-support-tool para realizar búsquedas en la base de conocimientos
configurar opciones de complementos. Se puede usar la opción -n NOPLUGINS para

deshabilitar complementos no deseados.
Uso de redhat-support-tool para realizar búsquedas

en la base de conocimientos
La utilidad Red Hat Support Tool redhat-support-tool proporciona una interfaz de
consola de texto para los servicios Red Hat Access que se basan en suscripciones. Hay que
tener acceso a Internet para poder acceder al portal de clientes de Red Hat. La herramienta
redhat-support-tool se basa en texto para su uso desde cualquier terminal o conexión
SSH; no se proporciona ninguna interfaz gráfica.
El comando redhat-support-tool puede utilizarse como una shell interactiva o invocarse

como si fuera un comando que se ejecuta en forma individual con opciones y argumentos.
La sintaxis disponible de la herramienta es idéntica para los dos métodos. De manera
predeterminada, el programa se inicia en modo de shell. Utilice el subcomando help
proporcionado para ver todos los comandos disponibles. El modo de shell admite la
compleción con el tabulador y la capacidad de solicitar programas en la shell principal.
[student@demo ~]$ redhat-support-tool

Welcome to the Red Hat Support Tool.
Command (? for help):
Cuando se invoca por primera vez, redhat-support-tool solicita la información necesaria

de inicio de sesión como suscriptor a Red Hat Access. Para evitar proporcionar esta
información en reiteradas ocasiones, la herramienta le pregunta si desea almacenar la
información de la cuenta en el directorio de inicio del usuario (~/.redhat-support-
tool/redhat-support-tool.conf). Si varios usuarios comparten una cuenta de Red Hat
Access, la opción --global permite guardar la información de la cuenta en /etc/redhat-
support-tool.conf, junto con la configuración de todo el sistema. El comando config
modifica los valores de configuración de la herramienta.
La herramienta redhat-support-tool permite que los suscriptores busquen y muestren

el mismo contenido de la base de conocimientos que se ve cuando están en el portal de
clientes de Red Hat. La base de conocimientos permite realizar búsquedas por palabras
claves, similar al comando man. Los usuarios pueden ingresar códigos de error, sintaxis de
archivos de registro o cualquier combinación de palabras clave para producir una lista de
documentos de soluciones relevantes.
A continuación se incluye una demostración de búsqueda básica y configuración inicial:

Command (? for help): search How to manage system entitlements with subscription-manager
Please enter your RHN user ID: subscriber
Save the user ID in /home/student/.redhat-support-tool/redhat-support-tool.conf (y/n): y
Please enter the password for subscriber: password
Save the password for subscriber in /home/student/.redhat-support-tool/redhat-support-
tool.conf (y/n): y
La herramienta, tras solicitarle al usuario la configuración de usuario requerida, continúa con

la solicitud de búsqueda original.
Type the number of the solution to view or 'e' to return to the previous menu.
RH342-RHEL7.2-es-1-20160321 15
1 [ 253273:VER] How to register and subscribe a system to Red Hat Network

(RHN) using Red Hat Subscription Manager (RHSM)?
2 [ 17397:VER] What are Flex Guest Entitlements in Red Hat Network?
3 [ 232863:VER] How to register machines and manage subscriptions using Red
Hat Subscription Manager through an invisible HTTP proxy / Firewall?
3 of 43 solutions displayed. Type 'm' to see more, 'r' to start from the beginning
again, or '?' for help with the codes displayed in the above output.
Select a Solution:
Pueden seleccionarse secciones específicas de documentos de soluciones para su

visualización.
Select a Solution: 1
Type the number of the section to view or 'e' to return to the previous menu.
1 Title
2 Issue
3 Environment
4 Resolution
5 Display all sections
End of options.
Section: 1
Title
===============================================================================
How to register and subscribe a system to Red Hat Network (RHN) using Red Hat
Subscription Manager (RHSM)?
URL: https://access.redhat.com/site/solutions/253273
(END) q
Acceso directo a artículos de la base de conocimientos por ID de documento

Encuentre artículos en línea en forma directa con el comando kb de la herramienta con la ID
de documento de la base de conocimientos. Los documentos arrojados pasan por la pantalla
sin paginación, lo que le permite al usuario redirigir el resultado obtenido mediante el uso de
otros comandos locales. En este ejemplo, se puede ver el documento con el comando less.
[student@demo ~]$ redhat-support-tool kb 253273 | less
Title: How to register and subscribe a system to Red Hat Network (RHN) using Red Hat
Subscription Manager (RHSM)?
ID: 253273
State: Verified: This solution has been verified to work by Red Hat Customers and
Support Engineers for the specified product version(s).
URL: https://access.redhat.com/site/solutions/253273
: q
Los documentos arrojados en formato sin paginar pueden enviarse fácilmente a una
impresora, convertirse a PDF o a otro formato de documento, o redirigirse a un programa de
entrada de datos para seguimiento de incidentes o sistema de administración de cambios,
mediante el uso de otras utilidades instaladas y disponibles en Red Hat Enterprise Linux.
Uso de redhat-support-tool para administrar casos

de asistencia
Un beneficio de la suscripción a un producto es el acceso a asistencia técnica a través del
portal de clientes de Red Hat. Según el nivel de soporte de suscripción del sistema, Red Hat
puede comunicarse mediante herramientas en línea o por teléfono. Consulte https://
16 RH342-RHEL7.2-es-1-20160321
Uso de redhat-support-tool para administrar casos de asistencia
access.redhat.com/site/support/policy/support_process para obtener enlaces a

información detallada acerca del proceso de soporte.
Preparación de un informe de error

Antes de comunicarse con la asistencia de Red Hat, reúna información relevante para un
informe de errores.
Defina el problema. Indique el problema y los síntomas con claridad. Sea lo más específico
posible. Detalle los pasos que reproducirían el problema.
Reúna información básica. ¿Qué producto y versión se ven afectados? Esté preparado para
brindar información de diagnóstico relevante. Esto puede incluir el resultado de sosreport,
que se abordó anteriormente en esta sección. En el caso de problemas del kernel, dicha
información podría incluir un vuelco de errores de kdump del sistema o una fotografía digital
del seguimiento de kernel mostrado en el monitor de un sistema bloqueado.
Determine el nivel de gravedad. Red Hat utiliza cuatro niveles de gravedad para clasificar
los problemas. Después de los informes de problemas con gravedad urgente y alta, debe
realizarse una llamada telefónica al centro de asistencia local pertinente (visite https://
access.redhat.com/site/support/contact/technicalSupport).
Gravedad Descripción
Urgente (Gravedad 1) Un problema que afecta gravemente al uso del software en un
entorno de producción (como la pérdida de datos de producción o
la parada de los sistemas de producción). La situación interrumpe
las operaciones empresariales y no existe un procedimiento de
resolución.
Alta (Gravedad 2) Un problema donde el software funciona, pero el uso en un entorno
de producción se ve gravemente reducido. La situación tiene un
gran impacto en parte de las operaciones empresariales y no existe
un procedimiento de resolución.
Media (Gravedad 3) Un problema que implica una pérdida parcial no fundamental de
la capacidad de uso del software en un entorno de producción o
desarrollo. Para los entornos de producción, hay un impacto de
mediano a bajo en el negocio, pero el negocio sigue funcionando,
incluso mediante el uso de una solución de proceso. Para entornos
de desarrollo, donde la situación está causando que el proyecto
continúe o no migre a la producción.
Baja (Gravedad 4) Un asunto de uso general, la comunicación de un error de
documentación o una recomendación para una mejora o
modificación futura del producto. Para entornos de producción,
el impacto en su negocio, en el rendimiento o en la funcionalidad
del sistema es de bajo a cero. Para los entornos de desarrollo, hay
un impacto de mediano a bajo en el negocio, pero el negocio sigue
funcionando, incluso mediante el uso de una solución de proceso.
Administración de un informe de errores con redhat-support-tool

Los suscriptores pueden crear, ver, modificar y cerrar casos de asistencia de Red Hat
Support mediante el uso de redhat-support-tool. Cuando se abren y se mantienen
casos de asistencia, los usuarios pueden incluir archivos o documentación, como informes
de diagnóstico (sosreport). La herramienta carga y adjunta archivos a casos en línea. Los
RH342-RHEL7.2-es-1-20160321 17
detalles del caso, como producto, versión, resumen, descripción, gravedad y grupo de caso,
pueden asignarse con opciones de comandos o si se deja la solicitud de la herramienta de
información necesaria. En el siguiente ejemplo, se especifican las opciones --product y
--version, pero redhat-support-tool proporcionará una lista de elecciones para esas
opciones si el comando opencase no las especificó.

Command (? for help): opencase --product="Red Hat Enterprise Linux" --version="7.0"
Please enter a summary (or 'q' to exit): System fails to run without power
Please enter a description (Ctrl-D on an empty line when complete):
When the server is unplugged, the operating system fails to continue.
1 Low
2 Normal
3 High
4 Urgent
Please select a severity (or 'q' to exit): 4
Would you like to assign a case group to this case (y/N)? N
Would see if there is a solution to this problem before opening a support case? (y/N) N
-------------------------------------------------------------------------------
Support case 01034421 has successfully been opened.
Inclusión de información de diagnóstico con el archivo de informe de SoS adjunto

La inclusión de información de diagnóstico cuando un caso de asistencia se crea por primera
vez contribuye a una resolución más rápida del problema. El comando sosreport genera un
archivo tar comprimido de información de diagnóstico reunida del sistema en ejecución. La
herramienta redhat-support-tool le pide que incluya uno en caso de que un archivo se
haya creado previamente:
Please attach a SoS report to support case 01034421. Create a SoS report as
the root user and execute the following command to attach the SoS report
directly to the case:
redhat-support-tool addattachment -c 01034421 path to sosreport
Would you like to attach a file to 01034421 at this time? (y/N) N

Command (? for help):
Si todavía no hay un informe SoS actual preparado, un administrador puede generar y

adjuntar uno más tarde con el comando addattachment de la herramienta, como se
recomendó anteriormente.
Usted puede ver, modificar y cerrar los casos de asistencia como suscriptor:
Command (? for help): listcases
Type the number of the case to view or 'e' to return to the previous menu.
1 [Waiting on Red Hat] System fails to run without power
No more cases to display
Select a Case: 1
Type the number of the section to view or 'e' to return to the previous menu.
1 Case Details
2 Modify Case
3 Description
4 Recommendations
5 Get Attachment
6 Add Attachment
18 RH342-RHEL7.2-es-1-20160321
Trabajos de laboratorio
7 Add Comment
End of options.
Option: q
Select a Case: q
Command (? for help):q
[student@demo ~]$ redhat-support-tool modifycase --status=Closed 01034421

Successfully updated case 01034421
[student@demo ~]$
La herramienta Red Hat Support cuenta con capacidades avanzadas de análisis y diagnóstico
de aplicaciones. Mediante el uso de los archivos principales del vuelco de errores de kernel,
redhat-support-tool puede crear y extraer un seguimiento, un informe de tramas de pila
activas en el momento en que se realiza un vuelco de errores, para proporcionar diagnóstico
in situ y abrir un caso de asistencia.
La herramienta también proporciona análisis de archivo de registro. Mediante el uso

del comando analyze de la herramienta, los archivos de registro de muchos tipos,
como de sistema operativo, JBoss, Python, Tomcat, oVirt, etc., pueden analizarse para
reconocer síntomas de problemas que pueden verse y diagnosticarse de manera individual.
Proporcionar análisis preprocesado, en oposición a datos sin procesar, como archivos de
registro o vuelcos de errores, permite que se abran los casos de asistencia y que se pongan a
disposición de ingenieros más rápidamente.
Trabajos de laboratorio
Los trabajos de laboratorio de Red Hat Access, que se pueden encontrar en https://
access.redhat.com/labs, proporcionan varias herramientas basadas en la Web para
ayudar en la configuración, las implementaciones, la seguridad y la solución de problemas.
Esto incluye scripts de prueba para vulnerabilidades de seguridad como Shellshock y
Heartbleed, pero también scripts de configuración para clientes y servidores de NFS,
analizadores de archivos de registro, una herramienta para ayudar a enviar una revisión de
arquitectura para clústeres de alta disponibilidad, y mucho más.
RH342-RHEL7.2-es-1-20160321 19
Figura 1.2: Trabajos de laboratorio en el portal de clientes de Red Hat
Red Hat Insights

Red Hat Insights es un servicio de alojamiento que les proporciona a los gerentes y
administradores de sistemas una herramienta para ayudarlos a administrar sus sistemas
de manera proactiva. Red Hat Insights carga (de manera segura) información clave desde
un sistema a Red Hat, donde se analiza y se realiza un conjunto de recomendaciones
personalizadas. Estas recomendaciones pueden ayudar a mantener la estabilidad y el
funcionamiento de los sistemas, detectando cualquier problema potencial y proporcionando
asesoramiento de reparación antes de que se convierta en un problema más grande.
Figura 1.3: Red Hat Insights
La interfaz web de https://access.redhat.com/insights proporciona una descripción

general de todos los posibles problemas que afectan sistemas registrados, ordenados por
gravedad y tipo. Los administradores pueden examinar los problemas a fondo para obtener
recomendaciones personalizadas. Los administradores también pueden elegir ignorar
permanentemente ciertas reglas.
Registro de sistemas con Red Hat Insights

Registrar sistemas con Red Hat Insights requiere solo dos pasos:
1. Asegurarse de que el paquete redhat-access-insights está instalado:
[root@demo ~]# yum -y install redhat-access-insights
2. Registrar el sistema con Red Hat Insights.
20 RH342-RHEL7.2-es-1-20160321
Red Hat Insights
[root@demo ~]# redhat-access-insights --register

Successfully registered demo.lab.example.com
Attempting to download collection rules

Attempting to download collection rules GPG signature from https://cert-
api.access.redhat.com/r/insights/v1/static/uploader.json.asc
Successfully downloaded GPG signature
Verifying GPG signature of Insights configuration
Starting to collect Insights data
Uploading Insights data, this may take a few minutes
Upload completed successfully
Inmediatamente después de registrar un sistema, los datos de Insights se ponen a

disposición en la interfaz web.
Referencias
Página del manual (1)sosreport
Acceso a Red Hat Access: Herramienta de soporte de Red Hat

https://access.redhat.com/site/articles/445443
Primer uso de la herramienta de soporte de Red Hat

https://access.redhat.com/site/videos/534293
Contacto con la Asistencia técnica de Red Hat

https://access.redhat.com/site/support/policy/support_process/
Ayuda: Portal de clientes de Red Hat

https://access.redhat.com/site/help/
Trabajos de laboratorio de Red Hat Access

https://access.redhat.com/labs
Red Hat Insights

https://access.redhat.com/insights
RH342-RHEL7.2-es-1-20160321 21
Ejercicio guiado: Uso de los recursos de Red

Hat
En este trabajo de laboratorio, generará e inspeccionará un sosreport en su sistema

servera.
Recursos
• servera
Resultados
Deberá poder generar un sosreport para ayudar al Soporte de Red Hat a resolver un
problema.
Mientras resolvía un problema en su sistema servera, contactó al Soporte de Red Hat para
obtener ayuda. El soporte ha solicitado que genere un sosreport con el módulo xfs activo y
la opción xfs.logprint habilitada.
A fines de este ejercicio, su nombre es "student" y su número de caso es 123456.
1. Compruebe que tiene el paquete sos instalado en su sistema servera. En caso de no

tenerlo, instálelo.
1.1. Compruebe que tiene el paquete sos instalado en su sistema servera.
[root@servera ~]# rpm -q sos

sos-3.2-35.el7.noarch
1.2. Si el comando anterior devolvió package sos is not installed (el paquete sos
no está instalado), instale el paquete sos.
[root@servera ~]# yum -y install sos
2. Vea las opciones, los complementos y las opciones de complementos disponibles para
sosreport.
2.1. Vea las opciones disponibles para sosreport.
[root@servera ~]# sosreport --help | less
2.2. Vea los complementos y las opciones de complementos disponibles para

sosreport.
[root@servera ~]# sosreport -l | less
3. Genere un sosreport en servera. Asegúrese de incluir la opción xfs.logprint.
22 RH342-RHEL7.2-es-1-20160321
3.1. Ejecute la herramienta sosreport con la opción -k xfs.logprint. Use los avisos
interactivos para ingresar toda la información requerida. Este proceso puede tardar
un tiempo en completarse.
[root@servera ~]# sosreport -k xfs.logprint

sosreport (version 3.2)
This command will collect diagnostic and configuration information from

this Red Hat Enterprise Linux system and installed applications.
An archive containing the collected information will be generated in

/var/tmp and may be provided to a Red Hat support representative.
Any information provided to Red Hat will be treated in accordance with

the published support policies at:
https://access.redhat.com/support/
The generated archive may contain data considered sensitive and its
content should be reviewed by the originating organization before being
passed to any third party.
No changes will be made to system configuration.
Press ENTER to continue, or CTRL-C to quit. Enter

Please enter your first initial and last name [servera.lab.example.com]: student
Please enter the case id that you are generating this report for []: 123456
Setting up archive ...

Setting up plugins ...
Running plugins. Please wait ...
Running 1/82: abrt...

Running 2/82: acpid...
...
Running 81/82: xfs...
Running 82/82: yum...
Creating compressed archive...
Your sosreport has been generated and saved in:

/var/tmp/sosreport-student.123456-20151210132339.tar.xz
The checksum is: d0459a202c5c456be00a3dac7b92567a
Please send this file to your support representative.
4. Copie el archivo generado al directorio de inicio para student en workstation, y

extráigalo.
4.1. Copie el archivo generado al directorio de inicio para student en workstation.
[student@workstation ~]$ scp root@servera:/var/tmp/sosreport-

student.123456*.tar.xz .
4.2. Extraiga el archivo generado. Puede ignorar de manera segura los errores
relacionados a la creación de los nodos del dispositivo.
RH342-RHEL7.2-es-1-20160321 23
[student@workstation ~]$ tar xvf sosreport-student.123456*.tar.xz
5. Inspeccione el sosreport extraído. Algunos archivos de interés:
• etc/
• sos_commands/
• sos_reports/sos.html
• sos_commands/xfs/xfs_logprint_-c.dev.vda1
Este archivo se generó mediante la opción -k xfs.logprint.
24 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: ¿Qué es la solución de problemas?
Trabajo de laboratorio: ¿Qué es la solución

de problemas?
En este trabajo de laboratorio, resolverá un problema con transferencias de FTP en servera.
Recursos
• servera
Resultados
Deberá poder resolver un problema de transferencia de archivos y conectividad de FTP
mediante el método científico.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab
troubleshootingintro setup en su máquina workstation.
[student@workstation ~]$ lab troubleshootingintro setup
Uno de sus usuarios informó un problema con el servidor FTP que se ejecuta en servera. El
usuario experimenta los siguientes síntomas:
• El usuario no puede conectarse desde workstation a través de lftp.
• El usuario puede conectarse a localhost a través de lftp cuando se registra en una shell
en servera.
• Cuando está conectado, el archivo pub/noclip sí se transfiere, pero el archivo pub/

getall no.
Para realizar sus pruebas, se ha instalado lftp en workstation y servera. Recuerde que
lftp no intentará conectarse hasta que se emita el primer comando.
El daemon del FTP (vsftpd.service) en servera registra todas las transferencias de archivos
en /var/log/xferlog. Si el último carácter en una línea de ese archivo es c, la transferencia
se completó correctamente; si el último carácter es i, la transferencia no se completó.
1. Intente recrear el problema.
2. Recopile información acerca del servicio de FTP que se ejecuta en servera. Incluya
puertos de red, información de firewall, raíz de documentos, permisos de archivos,
denegaciones de SELinux, etc.
3. Formule una hipótesis con respecto a cuáles podrían ser los problemas.
4. Implemente una solución para todos los problemas encontrados.
5. Compruebe que los problemas informados ahora están resueltos.
RH342-RHEL7.2-es-1-20160321 25
6. Evalúe su trabajo ejecutando el comando lab troubleshootingintro grade desde

workstation.
[student@workstation ~]$ lab troubleshootingintro grade
7. Reinicie todas sus máquinas para proveer un entorno limpio para los siguientes
ejercicios.
26 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, resolverá un problema con transferencias de FTP en servera.
Recursos
• servera
Resultados
Deberá poder resolver un problema de transferencia de archivos y conectividad de FTP
mediante el método científico.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab
troubleshootingintro setup en su máquina workstation.
[student@workstation ~]$ lab troubleshootingintro setup
Uno de sus usuarios informó un problema con el servidor FTP que se ejecuta en servera. El
usuario experimenta los siguientes síntomas:
• El usuario no puede conectarse desde workstation a través de lftp.
• El usuario puede conectarse a localhost a través de lftp cuando se registra en una shell
en servera.
• Cuando está conectado, el archivo pub/noclip sí se transfiere, pero el archivo pub/

getall no.
Para realizar sus pruebas, se ha instalado lftp en workstation y servera. Recuerde que
lftp no intentará conectarse hasta que se emita el primer comando.
El daemon del FTP (vsftpd.service) en servera registra todas las transferencias de archivos
en /var/log/xferlog. Si el último carácter en una línea de ese archivo es c, la transferencia
se completó correctamente; si el último carácter es i, la transferencia no se completó.
1. Intente recrear el problema.
1.1. Intente utilizar lftp desde workstation para conectarse al servicio de FTP que se
ejecuta en servera.
[student@workstation ~]$ lftp servera

lftp servera:~> ls
'ls' at 0 [Delaying before reconnect: 30]Ctrl+C
Interrupt
lftp servera:~> bye
ejecuta en servera/localhost.
[student@servera ~]$ lftp servera

lftp servera:~> ls
drwxr-xr-x 2 0 0 32 Dec 11 09:42 pub
RH342-RHEL7.2-es-1-20160321 27
lftp servera:~>
1.3. Intente ver el contenido del archivo pub/noclip.
lftp servera:~> cat pub/noclip

idspispopd
11 bytes transferred
lftp servera:~>
1.4. Intente ver el contenido del archivo pub/getall.
lftp servera:~> cat pub/getall

cat: Access failed: 550 Failed to open file. (pub/getall)
lftp servera:~> bye
2. Recopile información acerca del servicio de FTP que se ejecuta en servera. Incluya
puertos de red, información de firewall, raíz de documentos, permisos de archivos,
denegaciones de SELinux, etc.
2.1. Recopile información sobre dónde está escuchando vsftpd en la red.
[root@servera ~]# ss -tulpn | grep ftp

tcp LISTEN 0 32 :::21 :::* users:(("vsftpd",pid=30050,fd=3))
Esto muestra que vsftpd está escuchando en el puerto FTP predeterminado

(tcp:21) y acepta las conexiones de todas las direcciones IP.
2.2. Vea la configuración de firewall en servera:
[root@servera ~]# firewall-cmd --list-all

public (default, active)
interfaces: eth0 eth1
sources:
services: dhcpv6-client ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
Esto muestra que el servicio ftp no se abre en el firewall. Esto explica por qué
fallaron las conexiones remotas pero funcionaron las conexiones locales. Tome nota
de esto.
2.3. Consulte el contenido de la raíz del documento de FTP. La ubicación predeterminada

es /var/ftp.
[root@servera ~]# ls -lR /var/ftp

/var/ftp:
total 0
drwxr-xr-x. 2 root root 32 Dec 11 10:42 pub
/var/ftp/pub:
total 8
28 RH342-RHEL7.2-es-1-20160321
Solución
-rw-r--r--. 1 root root 6 Dec 11 10:42 getall

-rw-r--r--. 1 root root 11 Dec 11 10:42 noclip
Aparentemente, los permisos del archivo son correctos.
2.4. Inspeccione en busca de denegaciones de SELinux que hayan ocurrido el último día.
[root@servera ~]# ausearch -m avc -i -ts today

...
type=SYSCALL msg=audit(12/11/2015 11:01:01.997:2031) : arch=x86_64 syscall=open
success=no exit=-13(Permission denied) a0=0x7f91ba3da4f0 a1=O_RDONLY|O_NONBLOCK
a2=0x7f91ba3d9880 a3=0x566a9edd items=0 ppid=30406 pid=30408 auid=unset uid=ftp
gid=ftp euid=ftp suid=ftp fsuid=ftp egid=ftp sgid=ftp fsgid=ftp tty=(none)
ses=unset comm=vsftpd exe=/usr/sbin/vsftpd subj=system_u:system_r:ftpd_t:s0-
s0:c0.c1023 key=(null)
type=AVC msg=audit(12/11/2015 11:01:01.997:2031) : avc: denied
{ open } for pid=30408 comm=vsftpd path=/pub/getall dev="vda1"
ino=16828424 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
...
Esto muestra que el archivo /var/ftp/pub/getall tiene un contexto de SELinux

de tmp_t. Probablemente esto sea incorrecto.
3. Formule una hipótesis con respecto a cuáles podrían ser los problemas.
3.1. El firewall no se abre para el servicio de FTP, lo que resulta en conexiones fallidas
desde máquinas remotas.
3.2. El archivo /var/ftp/pub/getall tiene un contexto de SELinux incorrecto, lo que

deshabilita el acceso de lectura del daemon del FTP al archivo.
4. Implemente una solución para todos los problemas encontrados.
4.1. Abra el firewall para los servicios de FTP en servera.
[root@servera ~]# firewall-cmd --add-service=ftp

[root@servera ~]# firewall-cmd --permanent --add-service=ftp
4.2. Reinicie recurrentemente los contextos de SELinux en /var/ftp.
[root@servera ~]# restorecon -Rv /var/ftp
5. Compruebe que los problemas informados ahora están resueltos.
ejecuta en servera/localhost.
[student@workstation ~]$ lftp servera

lftp servera:~> ls
drwxr-xr-x 2 0 0 32 Dec 11 09:42 pub
lftp servera:~>
5.2. Intente ver el contenido del archivo pub/noclip.
RH342-RHEL7.2-es-1-20160321 29
lftp servera:~> cat pub/noclip

idspispopd
11 bytes transferred
lftp servera:~>
5.3. Intente ver el contenido del archivo pub/getall.
lftp servera:~> cat pub/getall

idkfa
6 bytes transferred
lftp servera:~> bye
6. Evalúe su trabajo ejecutando el comando lab troubleshootingintro grade desde

workstation.
[student@workstation ~]$ lab troubleshootingintro grade
ejercicios.
30 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
En este capítulo, aprendió lo siguiente:
• Cómo aplicar el método científico en la solución de problemas.
• Cómo utilizar journalctl para leer registros del sistema.
• Cómo configurar un diario (journal) del sistema persistente.
• Cómo utilizar redhat-support-tool.
• Cómo utilizar sosreport.
• Cómo configurar Red Hat Insights.
RH342-RHEL7.2-es-1-20160321 31
32
TRAINING
CAPÍTULO 2
SER PROACTIVO
Visión general
Meta Evitar que los pequeños problemas se conviertan en
grandes problemas al emplear técnicas proactivas de
administración de sistemas.
Objetivos • Monitorear las características vitales de los sistemas.
• Configurar sistemas para enviar mensajes de registro a

un host centralizado.
• Configurar la administración de ajustes para contribuir

a la administración de sistemas de gran tamaño.
• Implementar el seguimiento de cambios para mantener

la homogeneidad de los sistemas.
Secciones • Monitoreo de sistemas (y ejercicio guiado)
• Configuración de registros remotos (y ejercicio guiado)
• Uso de administración de configuración (y ejercicio

guiado)
• Configuración de seguimiento de cambios (y ejercicio

guiado)
Trabajo de laboratorio • Ser proactivo
RH342-RHEL7.2-es-1-20160321 33
Capítulo 2. Ser proactivo
Monitoreo de sistemas
Objetivos
Después de completar esta sección, los estudiantes podrán monitorear sistemas para
características fundamentales.
Monitoreo del sistema con cockpit

Cockpit es software desarrollado por Red Hat que proporciona una interfaz de administración
Linux interactiva basada en el navegador. Su interfaz gráfica permite que los administradores
de sistemas principiantes realicen tareas comunes de administración del sistema sin las
habilidades requeridas en la línea de comandos. Además de facilitar la gestión de los
sistemas por parte de los administradores principiantes, Cockpit también pone a disposición
datos de rendimiento y configuración del sistema sin la necesidad de tener conocimientos
sobre las herramientas de la línea de comandos.
Cockpit está disponible en el paquete cockpit en el repositorio de extras de Red Hat

Enterprise Linux 7. La instalación de Cockpit se realiza con el siguiente comando.
[root@demo ~]# yum install -y cockpit
Una vez instalado en el sistema, se debe iniciar cockpit antes de que se pueda acceder a
través de la red.
[root@demo ~]# systemctl start cockpit
Se puede acceder a Cockpit remotamente a través de HTTPS utilizando un navegador web

y conectándose al puerto TCP 9090. Este puerto debe abrirse en el firewall del sistema para
poder acceder a Cockpit de manera remota. El puerto está preestablecido como el cockpit
para firewalld, por lo que se puede conceder acceso a través del firewall, como se muestra
en el siguiente ejemplo.
[root@demo ~]# firewall-cmd --add-service=cockpit --permanent

[root@demo ~]# firewall-cmd --reload
Una vez que se establece una conexión con la interfaz web de Cockpit, un usuario debe
autenticarse para obtener acceso. La autenticación se realiza a través de la base de datos de
la cuenta del SO local del sistema. El acceso a funciones privilegiadas de administración del
sistema proporcionado por la interfaz de Cockpit, como la creación de usuarios, requerirá
que el usuario inicie sesión como el usuario root.
La pantalla Dashboard en la interfaz de Cockpit proporciona un resumen de las principales

métricas de rendimiento del sistema. Las métricas se informan por segundo y permiten que
los administradores monitoreen la utilización de subsistemas, como CPU, memoria, red y
disco.
Uso de Performance Co-Pilot

Red Hat Enterprise Linux 7 incluye un programa llamado Performance Co-Pilot,
proporcionado por el paquete RPM pcp. Performance Co-Pilot, o pcp, permite que los
administradores recopilen y consulten datos de varios subsistemas. Performance Co-Pilot
34 RH342-RHEL7.2-es-1-20160321
también se implementó en Red Hat Enterprise Linux 6, y está disponible en la versión 6.6 y
versiones posteriores.
Instalación de Performance Co-Pilot

Performance Co-Pilot se instala con el paquete pcp. Después de instalar pcp, la máquina
tendrá el daemon pmcd necesario para la recopilación de datos del subsistema. Además, la
máquina también tendrá varias herramientas de línea de comandos para consultar datos de
rendimiento del sistema.
[root@demo ~]# yum -y install pcp
Hay varios servicios que forman parte de Performance Co-Pilot, pero el que recopila datos del
sistema localmente es pmcd, el Daemon colector de métricas de rendimiento. Este servicio debe
estar en ejecución para poder consultar datos de rendimiento con las utilidades de la línea de
comandos de Performance Co-Pilot.
[root@demo ~]# systemctl start pmcd
[root@demo ~]# systemctl status pmcd

● pmcd.service - Performance Metrics Collector Daemon
Loaded: loaded (/usr/lib/systemd/system/pmcd.service; enabled; vendor preset:
disabled)
Active: active (exited) since Fri 2015-12-11 08:26:38 EST; 8s ago
... Output Truncated ...
[root@demo ~]# systemctl enable pmcd

Created symlink from /etc/systemd/system/multi-user.target.wants/pmcd.service to /usr/
lib/systemd/system/pmcd.service.
Uso de las utilidades de la línea de comandos pcp

El paquete pcp proporciona una variedad de utilidades de la línea de comandos para
recopilar y mostrar datos en una máquina.
El comando pmstat proporciona información similar a vmstat. Como vmstat, pmstat

admitirá opciones para ajustar el intervalo entre colecciones (-t) o la cantidad de muestras (-
s).
[root@demo ~]# pmstat -s 5

@ Fri Nov 7 15:00:08 2014
loadavg memory swap io system cpu
1 min swpd free buff cache pi po bi bo in cs us sy id
0.02 0 817044 688 480812 0 0 0 0 30 33 0 0 99
0.02 0 817044 688 480812 0 0 0 0 7 14 0 0 100
0.02 0 817044 688 480812 0 0 0 0 7 13 0 0 100
0.02 0 817044 688 480812 0 0 0 0 9 15 0 0 100
0.02 0 817044 688 480812 0 0 0 9 12 22 0 0 100
pmatop proporciona un resultado similar a top de datos y estadísticas de la máquina.

Incluye estadísticas de E/S de disco y estadísticas de E/S de red, así como información sobre
CPU, memoria y procesos proporcionada por otras herramientas. Por defecto, pmatop se
actualizará cada cinco segundos.
[root@demo ~]# pmatop

ATOP - Fri Nov 7 17:43:19 2014 0:00:05 elapsed
PRC | sys 0.06s | user 0.23s | #proc 214 | #zombie 0
RH342-RHEL7.2-es-1-20160321 35
CPU | sys 0% | user 2% | irq 0% | idle 97% | wait 0% |

cpu | sys 0% | user 2% | irq 0% | idle 47% | cpu01 0% |
CPL | avg1 0.05 | avg5 0.08 | avg15 0.07 | csw 211 | intr 390
|
MEM | tot 1885M | free 795M | cache 480M | buff 0M | slab 267M |
SWP | tot 0G | free 0G | | vmcom 1G | vmlim 0G |
PAG | scan 0 | steal 0 | stall 0 | swin 0 | swout 0 |
DSK | vda | busy 0% | read 0 | write 0 | avio 0 ms |
DSK | vdb | busy 0% | read 0 | write 0 | avio 0 ms |
NET | transport | tcpi 1M | tcpo 1M | udpi 0M | udpo 0M |
NET | network | ipi 1M | ipo 1M | ipfrw 0M | deliv 1M |
NET | eth0 | pcki 2M | pcko 2M | si 0 Kbps | so 0 Kpbs |
PID SYSCPU USRCPU VGROW RGROW RUID THR ST EXC S CPU CMD
27541 0.00s 0.21s 0K 264K root 1 -- - S 72% pmatop
9002 0.02s 0.00s 0K 0K root 1 -- - R 6% pmdaproc
1 0.00s 0.00s 0K 0K root 1 -- - S 0% systemd
2 0.00s 0.00s 0K 0K root 0 -- - S 0% kthreadd
3 0.00s 0.00s 0K 0K root 0 -- - S 0% ksoftirqd/0
5 0.00s 0.00s 0K 0K root 0 -- - S 0% kworker/0:0H
6 0.00s 0.00s 0K 0K root 0 -- - S 0% kworker/u4:0
Performance Co-Pilot también tiene un mecanismo de consultas basadas en texto para

interrogar métricas monitoreadas individualmente. Para obtener una lista de las métricas
almacenadas en la base de datos de Performance Co-Pilot, use el comando pminfo y, luego,
use el comando pmval con el nombre de métrica para recopilar datos acerca del elemento
deseado.
[root@demo ~]# pminfo

proc.nprocs
proc.psinfo.pid
[root@demo ~]# pminfo -dt proc.nprocs
proc.nprocs [instantaneous number of processes]

Data Type: 32-bit unsigned int InDom: PM_INDOM_NULL 0xffffffff
Semantics: instant Units: none
[root@demo ~]# pmval -s 5 proc.nprocs
metric: proc.nprocs
host: server1.example.com
semantics: instantaneous value
units: none
samples: 5
interval: 1.00 sec
133
133
133
133
130
Recuperación de datos históricos de rendimiento

Performance Co-Pilot también tiene la capacidad de almacenar datos en un registro. Esta
capacidad es proporcionada por el servicio pmlogger. Este servicio debe estar habilitado
para que Performance Co-Pilot archive los datos de rendimiento del sistema.
[root@demo ~]# systemctl start pmlogger
36 RH342-RHEL7.2-es-1-20160321
[root@demo ~]# systemctl status pmlogger

● pmlogger.service - Performance Metrics Archive Logger
Loaded: loaded (/usr/lib/systemd/system/pmlogger.service; enabled; vendor preset:
disabled)
[root@demo ~]# systemctl enable pmlogger

Created symlink from /etc/systemd/system/multi-user.target.wants/pmlogger.service to /
usr/lib/systemd/system/pmlogger.service.
Por defecto, pmlogger recopila datos por segundo y almacena datos registrados en el
directorio /var/log/pcp/pmlogger/HOSTNAME. Después de que se recopilan los datos en
un archivo pmlogger, se pueden usar herramientas, como pmval, para consultar datos.
El nombre del archivo de registro comenzará con la fecha con formato ISO. Además del
archivo de registro, se crean varios archivos para almacenar metadatos e información de
índice.
nota
Cuando exporta el registro a otro sistema, asegúrese de copiar el archivo de registro
y los archivos .meta asociados. Si falta alguno de estos archivos, las herramientas
de análisis no podrán utilizar los datos de registro.
Una vez que se crea el registro, las herramientas pcp de la línea de comando utilizarán la
opción -a para indicar que deben ejecutarse contra un archivo de datos en lugar de datos en
tiempo real. El comando pmval también tiene opciones para especificar las horas de inicio y
finalización que deben utilizarse si un administrador desea limitar los datos a un margen de
tiempo específico.
[root@demo ~]# pmval -a /var/log/pcp/pmlogger/serverX.example.com/20150224.00.10.0

kernel.all.load
...
03:03:46.197 0.1100 0.1700 0.1200
03:03:47.197 0.1100 0.1700 0.1200
03:03:48.197 0.1100 0.1700 0.1200
03:03:49.197 0.1100 0.1700 0.1200
...
Si un administrador está interesado en los promedios de carga desde las 03:03:00 hasta las
03:04:00 del 24 de febrero de 2015:
[root@demo ~]# pmval -a /var/log/pcp/pmlogger/serverX.example.com/20150224.00.10.0

kernel.all.load -S '@ Tue Feb 24 03:03:00 2015' -T '@ Tue Feb 24 03:04:00 2015'
metric: kernel.all.load
archive: /var/log/pcp/pmlogger/server0.example.com/20150224.00.10.0
host: server0.example.com
start: Tue Feb 24 03:03:00 2015
end: Tue Feb 24 03:04:00 2015
semantics: instantaneous value
units: none
samples: 61
interval: 1.00 sec
RH342-RHEL7.2-es-1-20160321 37
1 minute 5 minute 15 minute

03:03:00.000 0.3000 0.2100 0.1200
03:03:01.000 0.3000 0.2100 0.1200
03:03:02.000 0.3000 0.2100 0.1200
Puede encontrar las especificaciones de tiempo alternativas en la página del manual

PCPIntro(1).
Monitoreo de sistemas remotos con Nagios

Cuando trabaja con infraestructuras de TI grandes, la mayoría de las empresas medianas y
grandes requiere una solución de monitoreo centralizada capaz de encuestar el rendimiento
de los sistemas remotos de la red. Algunas organizaciones se basan en sistemas y servicios
de monitoreo/gestión de redes de proveedores como CA, HP, IBM y otros. Otras prefieren el
código abierto, opciones de GPL en esta área, como Nagios.
Nagios permite que los administradores monitoreen el rendimiento del sistema y de la red
en hosts conectados desde un servidor central. Se basa en técnicas de monitoreo activas y
pasivas, algunas de las cuales pueden involucrar la instalación de agentes en los sistemas
monitoreados.
Aunque Nagios es una buena herramienta de monitoreo de código abierto gratuita,

actualmente se proporciona a través del repositorio EPEL (Paquetes extras para Enterprise
Linux) desde el proyecto Fedora. Como tal, no es compatible con Red Hat.
Nagios es un sistema modular que consta de un paquete nagios central y funcionalidades

adicionales en la forma de complementos (plug-ins). Los complementos (plug-ins) pueden
ejecutarse en máquinas locales para proporcionar información que no está disponible a
través de la red, como uso de espacio en disco, etc. La configuración es muy flexible y permite
definiciones de períodos de tiempo, grupos de administradores, grupos de sistemas e,
incluso, conjuntos de comandos personalizados.
Hay una interfaz web en el servidor principal de Nagios que puede utilizarse para configurar
pruebas y ajustes para Nagios o para los hosts que está monitoreando. Los administradores
pueden establecer umbrales para los indicadores de rendimiento del sistema monitoreado
para que Nagios genere alertas cuando estas métricas de rendimiento queden fuera de los
rangos operativos normales.
Referencias
Para obtener más información acerca de Cockpit, consulte
Proyecto de Cockpit
http://www.cockpit-project.org
Para obtener más información acerca de Performance Co-Pilot, consulte las páginas
del manual pmstat(1), pmatop(1), pminfo(1), pmval(1) y PCPIntro(1).
Para obtener más información acerca de Nagios, consulte

Proyecto de Nagios
http://www.nagios.org
38 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Monitoreo de sistemas
Ejercicio guiado: Monitoreo de sistemas
En este trabajo de laboratorio, monitoreará el rendimiento del sistema actual e histórico a

través de Performance Co-Pilot.
Recursos
Archivos /root/cpuidle
Máquinas servera
Resultados
Deberá poder mostrar los indicadores de rendimiento actuales e históricos en un sistema a
través de Performance Co-Pilot.
Andes de comenzar
Inicie sesión en servera como el usuario root.
En este ejercicio, instalará y configurará el software de Performance Co-Pilot en servera.

Utilizará las utilidades proporcionadas por el software para recopilar estadísticas de
rendimiento actuales del sistema. También aprovechará la función de archivo del software y
recuperará estadísticas de rendimiento históricas.
1. Instale el software Performance Co-Pilot en servera al instalar el paquete pcp.
[root@servera ~]# yum install -y pcp
2. Inicie y habilite el servicio pmcd para habilitar la recopilación de métricas de rendimiento.
[root@servera ~]# systemctl start pmcd

[root@servera ~]# systemctl enable pmcd
Created symlink from /etc/systemd/system/multi-user.target.wants/pmcd.service to /
usr/lib/systemd/system/pmcd.service.
[root@servera ~]# systemctl status pmcd
disabled)
Docs: man:pmcd(8)
Main PID: 1896 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/pmcd.service
├─1942 /usr/libexec/pcp/bin/pmcd
├─1945 /var/lib/pcp/pmdas/root/pmdaroot
├─1946 /var/lib/pcp/pmdas/proc/pmdaproc -d 3
├─1947 /var/lib/pcp/pmdas/xfs/pmdaxfs -d 11
└─1948 /var/lib/pcp/pmdas/linux/pmdalinux
Dec 14 08:26:38 servera.lab.example.com systemd[1]: Starting Performance Metrics

Collector Daemon...
Dec 14 08:26:38 servera.lab.example.com pmcd[1896]: Starting pmcd ...
Dec 14 08:26:38 servera.lab.example.com systemd[1]: Started Performance Metrics
Collector Daemon.
3. Inicie y habilite el servicio pmlogger para configurar el registro persistente de métricas.
RH342-RHEL7.2-es-1-20160321 39
[root@servera ~]# systemctl start pmlogger

[root@servera ~]# systemctl enable pmlogger
Created symlink from /etc/systemd/system/multi-user.target.wants/pmlogger.service
to /usr/lib/systemd/system/pmlogger.service.
[root@servera ~]# systemctl status pmlogger
disabled)
Docs: man:pmlogger(1)
CGroup: /system.slice/pmlogger.service
└─6489 /usr/libexec/pcp/bin/pmlogger -P -r -T24h10m -c config.default -m
pmlogger_check 20151211.08.28
Dec 14 08:28:38 servera.lab.example.com systemd[1]: Starting Performance Metrics

Archive Logger...
Dec 14 08:28:38 servera.lab.example.com pmlogger[2535]: /usr/share/pcp/lib/pmlogger:
Warning: Performance Co-Pilot archive ...bled.
Dec 14 08:28:38 servera.lab.example.com pmlogger[2535]: To enable pmlogger, run the
following as root:
Dec 14 08:28:38 servera.lab.example.com pmlogger[2535]: # /usr/bin/systemctl enable
pmlogger.service
Dec 14 08:28:38 servera.lab.example.com pmlogger[2535]: Starting pmlogger ...
Dec 14 08:28:38 servera.lab.example.com systemd[1]: Started Performance Metrics
Archive Logger.
Hint: Some lines were ellipsized, use -l to show in full.
4. Consulte el daemon pmcd para mostrar el tiempo de inactividad por CPU para un minuto.
[root@servera ~]# pmval -T 1minute kernel.percpu.cpu.idle

metric: kernel.percpu.cpu.idle
host: servera.lab.example.com
semantics: cumulative counter (converting to rate)
units: millisec (converting to time utilization)
samples: 61
interval: 1.00 sec
cpu0 cpu1
0.9997 0.9997
0.9997 0.9997
... Output omitted ...
5. Recupere la ubicación del registro de archivos en el que el proceso pmlogger principal

está escribiendo.
[root@servera ~]# pcp | grep 'primary logger'

pmlogger: primary logger: /var/log/pcp/pmlogger/
servera.lab.example.com/20151211.08.28
6. A través del resultado del comando anterior, determine la iteración más reciente del
registro de archivos al examinar los datos de fecha y hora contenidos en el nombre del
archivo.
[root@servera ~]# ls -1 /var/log/pcp/pmlogger/

servera.lab.example.com/20151211.08.28.[0-9]* | tail -1
40 RH342-RHEL7.2-es-1-20160321
/var/log/pcp/pmlogger/servera.lab.example.com/20151211.08.28.0
7. Use el comando pmval para obtener estadísticas históricas del tiempo de inactividad
por CPU en intervalos de un minuto desde el registro de archivo más reciente. Guarde el
resultado en el archivo /root/cpuidle.
[root@servera ~]# pmval -t1minute kernel.percpu.cpu.idle -a /var/log/pcp/pmlogger/

servera.lab.example.com/20151211.08.28.0 > /root/cpuidle
pmval: pmFetch: End of PCP archive log
[student@workstation ~]$ lab pcp grade
[student@workstation ~]$ lab pcp reset
RH342-RHEL7.2-es-1-20160321 41
Configuración del registro remoto
Objetivos
Después de completar esta sección, los estudiantes podrán configurar sistemas para el
registro remoto en un host de registro central.
Registro remoto
La configuración estándar de la gestión de registros del sistema rota archivos de registro
todas las semanas y los conserva durante cuatro rotaciones. A veces se desea mantener
registros durante más de cuatro semanas (que es el valor predeterminado), especialmente
cuando establece tendencias de rendimiento del sistema relacionadas con tareas, como
cierres financieros al final del mes, que se ejecutan solo una vez por mes. Al enviar mensajes
de registro a un host de registro remoto con un almacenamiento masivo especializado,
los administradores pueden conservar grandes archivos de registros del sistema para sus
sistemas sin cambiar la configuración predeterminada de rotación de registros, que tiene
como intención evitar que los registros consuman almacenamiento en disco de manera
excesiva.
La recopilación central de los mensajes de registro del sistema también puede ser muy útil
para monitorear el estado de los sistemas e identificar rápidamente los problemas. Además,
proporciona una ubicación de copia de seguridad para los mensajes de registro en caso de
que el sistema tenga un error grave en el disco duro u otros problemas, que hacen que los
registros locales no estén disponibles. En estas situaciones, la copia de mensajes de registro
que residen en el host de registro central puede utilizarse para ayudar a diagnosticar el error
que causó el problema.
El registro estandarizado de sistemas es implementado en Red Hat Enterprise Linux 7 por el

servicio rsyslog. Los programas del sistema pueden enviar mensajes de syslog al servicio
rsyslogd local que, a su vez, redireccionará esos mensajes a los archivos que están en /
var/log, servidores de registro remotos u otras bases de datos, según los parámetros que
estén en su archivo de configuración, /etc/rsyslog.conf.
Los mensajes de registro tienen dos características que se usan para clasificarlos. La utilidad
(facility) de un mensaje de registro indica qué tipo de mensaje es. La prioridad (priority), por
otra parte, indica la importancia del evento registrado en el mensaje.
Niveles de prioridad de syslog

Prioridad (Priority) Significado
emerg El sistema no se puede usar.
alert Se requiere acción inmediata.
crit Condiciones críticas.
err Condiciones de error.
warning Advertencia.
notice Condiciones normales, pero importantes.
info Mensajes informativos
debug Mensajes de depuración.
42 RH342-RHEL7.2-es-1-20160321
Registro remoto
Configuración de un host de registro central

La implementación de un host de registro central requiere la configuración del servicio
rsyslog en dos tipos de sistemas: los sistemas remotos desde donde se originan los
mensajes de registro y el host de registro central que recibe los mensajes. En el host de
registro central, el servicio rsyslog debe configurarse para que se acepten los mensajes de
registro de hosts remotos.
Para configurar el servicio rsyslog en el host de registro central para que acepte registros
remotos, quite los comentarios de las líneas de recepción TCP o UDP en la sección de
módulos en el archivo /etc/rsyslog.conf.
Para la recepción UDP:
# Provides UDP syslog reception

$ModLoad imudp.so
$UDPServerRun 514
o para la recepción TCP:
# Provides TCP syslog reception

$ModLoad imtcp.so
$InputTCPServerRun 514
TCP proporciona una entrega más confiable de los mensajes de registro remoto, pero UDP es
compatible con una variedad más amplia de sistemas operativos y dispositivos de red.
Importante
El transporte TCP sin formato de los mensajes de syslog está bastante más
implementado, aunque todavía no está estandarizado. La mayoría de las
implementaciones actualmente usan el puerto TCP 514, que es el puerto rshd
heredado. Si el sistema tiene el paquete rsh-server instalado y está usando el
servicio rshd inseguro y antiguo, se producirá un conflicto con el puerto TCP
514 para la recepción de syslog de TCP sin formato. Configure el servidor de
registro para que use un puerto diferente; para hacerlo, cambie la configuración de
$InputTCPServerRun.
Las reglas contenidas en /etc/rsyslog.conf están configuradas por defecto para admitir
el registro de mensajes en un único host. Por lo tanto, ordena y agrupa los mensajes por
instalación. Por ejemplo, los mensajes de correo se envían a /var/log/maillog mientras
que los mensajes generados por el daemon crond se consolidan en /var/log/cron para
facilitar la búsqueda de cada tipo de mensaje.
Aunque el orden de los mensajes por instalación (facility) es ideal en un único host, produce
un resultado inapropiado en un host de registro central debido a que mezcla los mensajes
de diferentes hosts remotos. Por lo general, en un host de registro central es mejor que
los mensajes de registro de sistemas remotos permanezcan por separado. Esta separación
puede alcanzarse al definir nombres de archivos de registro dinámicos a través de la función
de plantilla de rsyslog.
Las plantillas se definen en /etc/rsyslog.conf y pueden utilizarse para generar reglas con
nombres de archivos de registro dinámicos. Una definición de plantilla consta de la directiva
RH342-RHEL7.2-es-1-20160321 43
$template, seguida del nombre de una plantilla y, luego, una cadena que representa el
texto de la plantilla. El texto de la plantilla puede ser dinámico a través del uso de valores
sustituidos de las propiedades de un mensaje de registro. Por ejemplo, para direccionar
mensajes de syslog cron de diferentes sistemas a un host de registro central, utilice la
siguiente plantilla para generar nombres de archivos de registro dinámicos en la propiedad
HOSTNAME de cada mensaje:
$template DynamicFile,"/var/log/loghost/%HOSTNAME%/cron.log"
El nombre de plantilla puede hacer referencia al archivo dinámico creado a través de la

definición de plantilla en una regla como la siguiente:
cron.* ?DynamicFile
En sistemas que realizan un registro extremadamente detallado, es recomendable desactivar

la sincronización del archivo de registro después de cada operación de lectura para mejorar
el rendimiento. La sincronización de un archivo de registro después de cada registro puede
omitirse al colocar el signo menos (-) como prefijo en el nombre del archivo de registro
en una regla de registro. Sin embargo, la compensación del rendimiento mejorado crea la
posibilidad de pérdida de datos de registro si el sistema colapsa inmediatamente después de
un intento de escritura.
A continuación se muestra otro ejemplo del uso de plantillas para generar nombres de
archivos de registro dinámicos. En este ejemplo, los mensajes de registro remotos se
ordenarán por su nombre de host y valores de instalación (facility) al hacer referencia a las
propiedades HOSTNAME y syslogfacility-test. Los mensajes de registro se escribirán en
los nombres de archivos de registro generados de manera dinámica, y no se realizará una
sincronización después de la operación de escritura.
$template DynamicFile,"/var/log/loghost/%HOSTNAME%/%syslogfacility-text%.log"
*.* -?DynamicFile
nota
Puede encontrar una lista completa de propiedades de mensajes de syslog
facilitada por rsyslog en la sección Propiedades disponibles de la página del
manual rsyslog.conf(5).
Una vez que se haya activado la recepción de syslog y el host haya creado las reglas deseadas
para la separación de registros, reinicie el servicio rsyslog para que se apliquen los cambios
de configuración. Además, agregue las reglas de firewall UDP o TCP para permitir el tráfico de
syslog entrante y, luego, actualice firewalld.
[root@loghost ~]# systemctl restart rsyslog

[root@loghost ~]# firewall-cmd --add-port=514/udp --permanent
[root@loghost ~]# firewall-cmd --add-port=514/tcp --permanent
[root@loghost ~]# firewall-cmd --reload
Cuando se crean nuevos archivos de registro, es posible que no se incluyan en el programa

de rotación de registros existente del host de registro. Esto debe solucionarse para garantizar
44 RH342-RHEL7.2-es-1-20160321
Registro remoto
que los nuevos archivos de registro no alcancen tamaños incontrolables. Por ejemplo, para
incluir nuevos archivos de registro de ejemplos anteriores en la rotación de registros, agregue
la siguiente entrada a la lista de archivos de registro en el archivo de configuración /etc/
logrotate.d/syslog.
/var/log/loghost/*/*.log
Redireccionamiento de registros al host de registro central

Una vez que se configura el host de registro central para aceptar registros remotos, el servicio
rsyslog puede configurarse en sistemas remotos para enviar registros al host de registro
central. Para configurar una máquina a fin de que envíe registros a un servidor rsyslog
remoto, agregue una línea a la sección de reglas en el archivo /etc/rsyslog.conf. En lugar
del nombre del archivo, use la dirección IP del servidor rsyslog remoto. Para usar UDP,
anexe la dirección IP con un solo signo @. Para usar TCP, anéxela con dos signos @ (@@).
Por ejemplo, para que todos los mensajes de prioridad info o de prioridad más alta se
envíen a loghost.example.com por medio de UDP, use la siguiente línea:
*.info @loghost.example.com
Para que todos los mensajes se envíen a loghost.example.com por medio de TCP, use la
siguiente línea:
*.* @@loghost.example.com
Otra opción es que el nombre de host de registro se anexe con :PORT, donde PORT es el
puerto que está usando el servidor remoto rsyslog. Si no se indica un puerto, se asume el
puerto 514 de forma predeterminada.
Una vez que haya agregado las reglas, reinicie el servicio rsyslog y envíe un mensaje de
prueba con el comando logger:
[root@logclient ~]# logger "Test from logclient"
Verifique los registros en el servidor remoto para asegurarse de que se haya recibido el
mensaje.
Referencias
Para obtener más información, consulte las páginas del manual rsyslog.conf(5),
rsyslogd(8) y logger(1).
RH342-RHEL7.2-es-1-20160321 45
Ejercicio guiado: Configuración de registros

remotos
En este trabajo de laboratorio, configurará el registro de sistemas en un host de registro

central.
Recursos
Archivos • /etc/rsyslog.conf
• /etc/logrotate.d/syslog
Máquinas • servera
• serverb
Resultados
Deberá poder centralizar el registro de sistemas remotos en un host de registro central.
Andes de comenzar
Inicie sesión como el usuario root en servera y serverb.
En servera, configure el servicio rsyslog para que funcione como un host de registro
central. Para una entrega de mensajes de syslog más confiable, configure el host de registro
central para aceptar la entrega de mensajes de hosts remotos a través de TCP.
Para organizar mejor los mensajes, cree una nueva regla que escriba los mensajes de syslog
generados por cada host en subdirectorios separados en el directorio /var/log/loghost.
Los subdirectorios recibirán su nombre de los nombres de host de cada host. Dentro del
subdirectorio de cada host, se conservará un archivo de registro separado para los mensajes
de cada instalación de syslog. Para un mejor rendimiento, configure el registro para que no se
realice una sincronización después de que se registra cada mensaje. Configure la rotación de
registros para los nuevos archivos de registro.
Configure serverb para el registro remoto del host de registro central. Pruebe la
configuración al generar un mensaje de prueba y verificar su presencia en el registro
adecuado en servera.
1. Verifique que el servicio rsyslog esté en ejecución y habilitado para iniciarse en el

arranque.
[root@servera ~]# systemctl is-active rsyslog

active
[root@servera ~]# systemctl is-enabled rsyslog
enabled
2. Configure el servicio rsyslog en servera para que se acepten los mensajes de syslog
de hosts remotos a través de TCP y para que se escriban los mensajes en archivos
separados para cada host.
2.1. Habilite la recepción de syslog TCP en /etc/rsyslog.conf al quitar los

comentarios de las siguientes líneas.
46 RH342-RHEL7.2-es-1-20160321
$ModLoad imtcp
2.2. En la sección "#### RULES ####", agregue la siguiente regla para los nombres
de archivos de registro dinámicos y, luego, cree una regla para usar el nombre
de archivo dinámico para separar los mensajes de registro por nombre de host e
instalación.
$template DynamicFile,"/var/log/loghost/%HOSTNAME%/%syslogfacility-text%.log"
*.* -?DynamicFile
2.3. Reinicie el servicio rsyslog para que se apliquen los cambios de configuración.
[root@servera ~]# systemctl restart rsyslog
3. Agregue la siguiente entrada a la lista de archivos en el archivo de configuración /etc/

logrotate.d/syslog para que se coloquen los nuevos archivos de registro en el
programa de rotación de registros.
/var/log/loghost/*/*.log
4. Modifique el firewall de servera para permitir que los mensajes de syslog entrantes de
hosts remotos se entreguen a través de TCP.
4.1. Habilite el tráfico entrante en el puerto TCP 514.
[root@servera ~]# firewall-cmd --add-port=514/tcp --permanent

success
4.2. Actualice firewalld para que se aplique el cambio de firewall.
[root@servera ~]# firewall-cmd --reload
5. Configure serverb para registrar los mensajes de syslog de manera remota en servera
a través del protocolo TCP.
5.1. En serverb, agregue la siguiente regla a /etc/rsyslog.conf para que todos los
mensajes de syslog se entreguen de manera remota a servera a través de TCP en el
puerto 514.
*.* @@servera.lab.example.com:514
5.2. Reinicie el servicio rsyslog para que se apliquen los cambios de configuración de
serverb.
[root@serverb ~]# systemctl restart rsyslog
RH342-RHEL7.2-es-1-20160321 47
6. Verifique que el registro remoto de serverb al host de registro central de servera esté
funcionando correctamente.
6.1. En serverb, genere un par de mensajes de syslog con diferentes instalaciones.
[root@serverb ~]# logger -p user.info "Test user.info message from serverb"

[root@serverb ~]# logger -p authpriv.crit "Test authpriv.crit message from
serverb"
6.2. En servera, verifique que el mensaje de syslog aparezca en los archivos adecuados
de /var/log/loghost/serverb.
[root@servera ~]# grep 'user\.info' /var/log/loghost/serverb/user.log

Dec 11 00:44:09 serverb root: Test user.info message from serverb
[root@servera ~]# grep 'authpriv\.crit' /var/log/loghost/serverb/authpriv.log
Dec 11 00:44:40 serverb root: Test authpriv.crit message from serverb
[student@workstation ~]$ lab loghost grade
[student@workstation ~]$ lab loghost reset
48 RH342-RHEL7.2-es-1-20160321
Uso de la gestión de configuraciones
Uso de la gestión de configuraciones
Objetivos
Después de completar esta sección, los estudiantes deberían poder implementar el cliente
Puppet para la gestión de configuraciones.
Soluciones de gestión de configuraciones

A medida que crece la infraestructura de TI de una organización, muchos administradores
descubren que el mantenimiento de las configuraciones del sistema se vuelven
incontrolables. A menudo, este es el resultado de los administradores que gestionan la
configuración de sus sistemas manualmente. A medida que crece la población del servidor
de una organización, un enfoque manual de la configuración del sistema no solo no puede
escalarse, sino que también se vuelve el principal punto de entrada de errores humanos, que
impactan negativamente en la estabilidad y el funcionamiento del sistema.
Una mejor alternativa al mantenimiento manual de la configuración del sistema es utilizar

una herramienta de gestión de configuraciones. Incluso las herramientas de gestión de
configuraciones simples pueden mejorar considerablemente la eficiencia y estabilidad
operativas. Estas herramientas pueden acelerar enormemente la implementación de
cambios de configuración en una gran cantidad de sistemas. Debido a que los cambios se
realizan mediante programación y de modo automatizado, también se garantiza la precisión
de los cambios.
Un ejemplo de una herramienta de gestión de configuraciones es la función de Canal de

configuración que se ofrece en Red Hat Satellite 5. Los canales de configuración de la red
de Red Hat proporcionan una manera fácil de implementar archivos de configuración en un
entorno empresarial. En lugar de realizar cambios del archivo de configuración en sistemas
individuales, los administradores pueden realizar cambios en un archivo de configuración
que se conserva en un Canal de configuración alojado en los servidores de Red Hat Satellite
5. Los cambios pueden implementarse en sistemas cliente suscritos al canal.
En los últimos años, las herramientas simples para gestionar archivos de configuración
fueron sustituidas por sistemas de gestión de configuraciones. Estos sistemas han
crecido considerablemente en los últimos años y ahora hay muchas soluciones de código
abierto disponibles para satisfacer las necesidades de gestión de configuraciones de una
organización. Las siguientes son opciones de herramientas de gestión de configuraciones que
están disponibles para los administradores.
• Ansible puede ser adecuado para las organizaciones con necesidades de gestión de
configuraciones simples. Ansible está basado en el lenguaje de programación de Python.
No tiene agente y se basa en SSH para implementar configuraciones en sistemas remotos.
• Chef y Puppet son soluciones de gestión de configuraciones pesadas que pueden

adaptarse mejor a las empresas con requisitos de gestión de configuraciones exigentes.
Ambas se basan en el lenguaje de programación de Ruby. Además, Chef y Puppet utilizan
arquitectura del servidor cliente, por lo que las implementaciones típicas requieren la
instalación de agentes en sistemas gestionados.
• Las última versión de Red Hat Satellite, Satellite 6, ofrece mucho más que la gestión de
archivos de configuración. Incorpora el uso de Puppet y proporciona un sistema de gestión
de configuraciones totalmente desarrollado para entornos empresariales.
RH342-RHEL7.2-es-1-20160321 49
Uso de Puppet para la gestión de configuraciones

Puppet permite que los administradores del sistema escriban infraestructura como código
a través de lenguaje descriptivo para configurar máquinas, en lugar de utilizar scripts
personalizados e individualizados para hacerlo. El lenguaje específico del dominio (DSL)
de Puppet se utiliza para describir el estado de la máquina, y Puppet puede imponer este
estado. Esto significa que si un administrador cambia un componente de la máquina por
error, Puppet puede imponer el estado y devolver la máquina al estado deseado. Por lo
tanto, el código de Puppet no solo puede utilizarse para configurar un sistema originalmente,
sino que también puede utilizarse para mantener el estado del sistema acorde con la
configuración deseada.
El administrador de un sistema tradicional necesitaría registrarse en cada máquina para

realizar tareas de administración en el sistema, pero esto no se escala bien. Quizás, el
administrador del sistema crearía un script de configuración inicial (p. ej., un archivo kickstart)
para una máquina, pero una vez que se haya ejecutado el script inicial, la máquina puede
comenzar (y comenzará) a apartarse de esa configuración de script inicial. En el mejor de los
casos, el administrador del sistema necesitaría revisar la máquina diariamente para verificar
la configuración. En el peor de los casos, el administrador del sistema necesitaría descubrir
por qué la máquina ya no funciona o volver a desarrollar la máquina y volver a implementar
la configuración.
Puppet se puede utilizar para establecer un estado deseado y hacer que la máquina coincida
con ese estado. El administrador del sistema ya no necesita un script para la configuración
inicial y un script separado (o peor aún, interacción humana) para la verificación del estado.
Puppet administra la configuración del sistema y comprueba que el sistema esté en el estado
deseado. Esto puede escalarse mucho mejor que el administrador de sistema tradicional que
utiliza scripts individuales para cada sistema.
Arquitectura de Puppet
Puppet utiliza un modelo servidor/cliente. Al servidor se lo llama Puppet maestro. El Puppet
maestro almacena instrucciones o manifiestos (código que contiene recursos y estados
deseados) para los clientes. A los clientes se los llama nodos de Puppet y ejecutan el software
del agente de Puppet. Por lo general, estos nodos ejecutan un daemon de Puppet (agent)
que se utiliza para conectarse al Puppet maestro. Los nodos descargarán la instrucción
asignada al nodo del Puppet maestro y aplicarán la configuración, en caso de ser necesaria.
50 RH342-RHEL7.2-es-1-20160321
Arquitectura de Puppet
Figura 2.1: Una ejecución de Puppet
Una ejecución de Puppet comienza con el nodo de Puppet (no el Puppet maestro). Por
defecto, el agente de Puppet inicia una ejecución de Puppet cada 30 minutos. Esta ejecución
utiliza servicios de transmisión segura (SSL) para pasar datos de un lado a otro entre el nodo
de Puppet y el Puppet maestro. El nodo se inicia al recopilar datos acerca del sistema a través
del comando facter. El comando facter incluye información sobre dispositivos de bloque,
sistemas de archivos, interfaz de la red, direcciones MAC, direcciones IP, memoria, sistema
operativo, CPU, virtualización, etc. Estos datos se envían del nodo al Puppet maestro.
Una vez que el Puppet maestro recibe los datos del nodo de Puppet, el Puppet maestro
compila un catalog, que describe el estado deseado de cada recurso configurado para el
nodo. El Puppet maestro verifica el nombre de host del nodo y lo vincula con la configuración
específica del nodo (llamada clasificación de nodos) o usa la configuración predeterminada
si el nodo no coincide. Este catálogo puede incluir información de dependencia para los
recursos (p. ej., ¿Puppet debería instalar el paquete primero o iniciar el servicio primero?).
Una vez que se compila el catálogo, el Puppet maestro envía el catálogo al nodo. El Puppet
aplicará el catálogo en el nodo de Puppet y configurará todos los recursos definidos en el
catálogo. Puppet es idempotentes; Puppet puede aplicar el catálogo a un nodo varias veces sin
afectar el estado resultante.
Una vez que el agente de Puppet aplica el catálogo al nodo, el nodo le informará al Puppet
maestro los detalles de la ejecución. Este informe incluye información sobre los cambios
que se realizaron en el nodo (si corresponde) y si la ejecución se completó correctamente.
La infraestructura de informes de Puppet tiene una API, para que otras aplicaciones puedan
descargar informes del Puppet maestro para almacenamiento o análisis adicional.
RH342-RHEL7.2-es-1-20160321 51
Configuración de un cliente de Puppet

Aunque Puppet puede ejecutarse en el modo independiente, donde todos los clientes de
Puppet tienen módulos de Puppet localmente que se aplican al sistema, la mayoría de los
administradores de sistemas descubren que Puppet funciona mejor con un Puppet maestro
centralizado. El primer paso en la implementación de un cliente de Puppet es instalar el
paquete puppet:
[root@demo ~]# yum install -y puppet
Una vez que se instala el paquete puppet, el cliente de Puppet debe configurarse con el
nombre de host del Puppet maestro. El nombre de host del Puppet maestro debe colocarse
en el archivo /etc/puppet/puppet.conf, en la sección [agent]. El siguiente fragmento
muestra un ejemplo donde el Puppet maestro es denominado puppet.lab.example.com:
[agent]
server = puppet.lab.example.com
nota
Cuando no se define un Puppet maestro explícito, Puppet utiliza un nombre de
host predeterminado de puppet. Si la ruta de búsqueda DNS incluye un host
denominado puppet, este host se utilizará automáticamente.
El paso final que se debe tomar en el cliente de Puppet es comenzar el servicio del agente de
Puppet y configurarlo para que se ejecute en el momento del inicio.
[root@demo ~]# systemctl start puppet.service

[root@demo ~]# systemctl enable puppet.service
ln -s '/usr/lib/systemd/system/puppet.service'
'/etc/systemd/system/multi-user.target.wants/puppet.service'
Cuando el servicio del agente de Puppet se inicia por primera vez, generará un certificado
de host y enviará una solicitud de firma de certificado al Puppet maestro. Una vez que se
haya enviado la solicitud de certificado cliente, la solicitud para firmar el certificado cliente
se puede ver en el Puppet maestro. Por defecto, la firma de certificados cliente se realiza
manualmente en el Puppet maestro. Sin embargo, el Puppet maestro también puede
configurarse para firmar automáticamente certificados cliente para que no se necesite una
intervención humana para nuevos registros de clientes. Una vez que el Puppet maestro
haya firmado el certificado, el agente de Puppet recibirá un catálogo y aplicará los cambios
necesarios.
nota
El paquete puppet viene con el repositorio de Satellite Tools 6.1.
52 RH342-RHEL7.2-es-1-20160321
Configuración de un cliente de Puppet
Referencias
Para obtener más información acerca de Puppet, consulte
Introducción a Puppet
https://docs.puppetlabs.com/puppet/3.6/reference/index.html
Para obtener más información acerca de facter, consulte la página del manual
facter(8).
Para obtener más información acerca de la configuración de un cliente de Puppet,

consulte
Instalación de Puppet: Tareas posteriores a la instalación
https://docs.puppetlabs.com/guides/install_puppet/post_install.html
RH342-RHEL7.2-es-1-20160321 53
Ejercicio guiado: Uso de gestión de

configuraciones
En este trabajo de laboratorio, configurará un sistema para la gestión de configuraciones a

través de Puppet.
Recursos
Archivos /etc/puppet/puppet.conf
• serverb
Resultados
Deberá poder instalar y configurar Puppet en un sistema y, luego, utilizar el agente de Puppet
para configurar el servicio web en el sistema.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab puppet setup en
su máquina workstation. Esto configurará los repositorios necesarios en sus sistemas y
configurará servera para que actúe como el Puppet maestro.
[student@workstation ~]$ lab puppet setup
1. Instale el software del agente de Puppet en serverb para implementarlo como el cliente
de Puppet.
[root@serverb ~]# yum install -y puppet
2. Configure el agente de Puppet para señalar al Puppet maestro,

servera.lab.example.com, al agregar la siguiente entrada a la sección agent del
archivo de configuración /etc/puppet/puppet.conf.
server = servera.lab.example.com
3. Compruebe si el paquete httpd está instalado en este sistema.
[root@serverb ~]# rpm -q httpd

package httpd is not installed
4. Habilite el servicio puppet para que el agente de Puppet se inicie en el arranque.
[root@serverb ~]# systemctl enable puppet

Created symlink from /etc/systemd/system/multi-user.target.wants/puppet.service to /
usr/lib/systemd/system/puppet.service.
5. En la ventana de un terminal separado, utilice el comando journalctl para monitorear

las nuevas entradas de registro generadas por el agente de Puppet.
54 RH342-RHEL7.2-es-1-20160321
[root@serverb ~]# journalctl -ef
6. En la ventana del terminal original, inicie el servicio puppet. El sistema se registrará con
el Puppet maestro y recuperará y aplicará su configuración.
[root@serverb ~]# systemctl start puppet
Observe las actividades del agente de Puppet al monitorear las nuevas entradas de
registro que aparecen en el diario (journal) del sistema.
Jan 12 23:13:42 serverb.lab.example.com systemd[1]: Started Puppet agent.

Jan 12 23:13:42 serverb.lab.example.com systemd[1]: Starting Puppet agent...
Jan 12 23:13:43 serverb.lab.example.com puppet-agent[1579]: Starting Puppet client
version 3.6.2
Jan 12 23:13:46 serverb.lab.example.com yum[1741]: Installed: apr-1.4.8-3.el7.x86_64
Jan 12 23:13:46 serverb.lab.example.com yum[1741]: Installed: apr-
util-1.5.2-6.el7.x86_64
Jan 12 23:13:47 serverb.lab.example.com yum[1741]: Installed: httpd-
tools-2.4.6-40.el7.x86_64
Jan 12 23:13:47 serverb.lab.example.com yum[1741]: Installed:
mailcap-2.1.41-2.el7.noarch
Jan 12 23:13:47 serverb.lab.example.com useradd[1751]: new group: name=apache,
GID=48
Jan 12 23:13:47 serverb.lab.example.com useradd[1751]: new user: name=apache,
UID=48, GID=48, home=/usr/share/httpd, shell=/sbin/nologin
Jan 12 23:13:49 serverb.lab.example.com systemd[1]: Reloading.
Jan 12 23:13:49 serverb.lab.example.com yum[1741]: Installed:
httpd-2.4.6-40.el7.x86_64
Jan 12 23:13:50 serverb.lab.example.com puppet-agent[1599]: (/Stage[main]/Main/
Node[serverb.lab.example.com]/Package[httpd]/ensure) created
Jan 12 23:13:50 serverb.lab.example.com systemd[1]: Starting The Apache HTTP
Server...
Jan 12 23:13:50 serverb.lab.example.com systemd[1]: Started The Apache HTTP Server.
Jan 12 23:13:50 serverb.lab.example.com systemd[1]: Reloading.
Jan 12 23:13:50 serverb.lab.example.com puppet-agent[1599]: (/Stage[main]/Main/
Node[serverb.lab.example.com]/Service[httpd]/ensure) ensure changed 'stopped' to
'running'
Jan 12 23:13:50 serverb.lab.example.com puppet-agent[1599]: Finished catalog run in
5.66 seconds
7. Compruebe que la configuración aplicada resultó en la instalación de httpdy la

habilitación y el inicio del servicio httpd.
[root@serverb ~]# rpm -q httpd

httpd-2.4.6-40.el7.x86_64
[root@serverb ~]# systemctl is-active httpd
active
[root@serverb ~]# systemctl is-enabled httpd
enabled
RH342-RHEL7.2-es-1-20160321 55
[student@workstation ~]$ lab puppet grade
[student@workstation ~]$ lab puppet reset
56 RH342-RHEL7.2-es-1-20160321
Configuración de seguimiento de cambios
Configuración de seguimiento de cambios
Objetivos
Después de completar esta sección, los estudiantes podrán implementar el seguimiento de
cambios para mantener la homogeneidad de los sistemas.
Uso de software de detección de intrusión para

monitorear cambios
La estabilidad del sistema se pone en riesgo cuando se eliminan o modifican archivos de
configuración sin autorización ni supervisión. ¿Cómo puede detectarse un cambio en un
archivo o directorio importante? El problema puede resolverse mediante el uso de software
de detección de intrusión para monitorear cambios en archivos. Entorno de detección de
intrusión avanzado (Advanced Intrusion Detection Environment) (AIDE) puede configurarse
para monitorear archivos para una variedad de cambios, incluidos cambios de permiso o
propiedad, cambios de marcas de tiempo (marcas de tiempo de acceso o modificación) o
cambios de contenido.
Instalación de AIDE
Para comenzar con AIDE, instale el paquete RPM que proporciona el software AIDE. Este
paquete brinda documentos útiles sobre el ajuste del software para monitorear cambios
específicos.
[root@demo ~]# yum install -y aide
Configuración de AIDE
Una vez que se instala el software, debe configurarlo. El archivo /etc/aide.conf es el
archivo de configuración primario de AIDE. Tiene tres tipos de directivas de configuración:
líneas de configuración, líneas de selección y líneas de macro.
Las líneas de configuración toman la forma de param = value. Cuando param no está
integrado en la configuración de AIDE, es la definición de un grupo que enumera los cambios
que se deben buscar. Por ejemplo, la siguiente definición de grupo puede encontrarse en /
etc/aide.conf instalado por defecto:
PERMS = p+i+u+g+acl+selinux
La línea anterior define un grupo denominado PERMS que busca cambios en permisos de
archivo (p), inode (i), propiedad de usuario (u), propiedad de grupo (g), ACLs (acl) o contexto
de SELinux (selinux).
Las líneas de selección definen las comprobaciones que deben realizarse en directorios
coincidentes. Las siguientes líneas son ejemplos de líneas de selección:
/dir1 group
=/dir2 group
!/dir3
La primera línea realiza el grupo de comprobaciones en /dir1 y todos los archivos y

directorios dependientes. La segunda línea realiza el grupo de comprobaciones especificado
RH342-RHEL7.2-es-1-20160321 57
en /dir2. El signo igual especifica que la comprobación se realizará solo en el directorio y

no en objetos dependientes. La tercera línea del ejemplo anterior excluye /dir3 y todos los
archivos dependientes de cualquier comprobación.
El tercer tipo de directiva son las líneas de macro. Definen variables y su definición tiene la
siguiente sintaxis:
@@define VAR value
@@{VAR} es una referencia al macro definido anteriormente.
El archivo de configuración aide.conf también puede incluir comentarios. Los comentarios

con líneas que comienzan con el carácter #.
Inicialización de la base de datos de AIDE

Ejecute el comando aide --init para iniciar la base de datos de AIDE. AIDE analizará el
sistema de archivos y registrará la información actual acerca de los archivos y directorios
especificados en el archivo de configuración /etc/aide.conf.
[root@demo ~]# aide --init
El comando anterior crea la base de datos en un archivo denominado /var/lib/aide/

aide.db.new.gz. Se debe cambiar el nombre de este archivo a /var/lib/aide/
aide.db.gz porque es aquí donde AIDE espera que esté la base de datos cuando realiza
comprobaciones del sistema de archivos.
Dado que la base de datos se puede actualizar desde la máquina, se recomienda copiar
aide.db.gz a otro sistema.
nota
Cuando los archivos que contienen ejecutables binarios se capturan en una base
de datos de AIDE, se debe deshabilitar la tarea prelink cron. De lo contrario,
la primera vez que se ejecute prelink, los binarios aparecerán como archivos
cambiados.
Revisión del sistema de archivos en busca de cambios

Después de que se crea la base de datos, se puede realizar una comprobación del sistema
de archivos al ejecutar el comando aide --check. Este comando analizará el sistema de
archivos y comparará el estado actual de los archivos con la información de la base de datos
de AIDE. Aparecerán las diferencias detectadas, donde se mostrarán el estado original del
archivo y la nueva condición.
[root@demo ~]# aide --check
Auditoría del sistema con auditd

auditd es el componente de espacio del usuario del subsistema de auditoría de Linux.
Cuando auditd está en ejecución, los mensajes de auditoría enviados por el kernel se
58 RH342-RHEL7.2-es-1-20160321
recopilarán en el archivo de registro configurado por auditd (por lo general, /var/log/

audit/audit.log). Si auditd no está en ejecución por algún motivo, los mensajes de
auditoría de kernel se enviarán a rsyslog.
Sin configuraciones adicionales, solo una cantidad limitada de mensajes se pasa por el
sistema de auditoría, principalmente mensajes de autenticación/autorización (inicios de
sesión de usuarios, uso de sudo, etc.) y mensajes de SELinux. Con una herramienta llamada
auditctl, los administradores (seguridad) pueden agregar reglas de auditoría en cualquier
llamada del sistema que deseen, incluidas todas las operaciones de archivos.
Redacción de reglas de auditoría personalizadas

Las reglas de auditoría pueden agregarse desde la línea de comandos a través de la
herramienta auditctl. Por defecto, las reglas de auditoría se agregarán a la parte inferior de
la lista actual, pero los reglas también pueden insertarse en la parte superior.
Importante
Dado que las reglas de auditoría están basadas en la primera coincidencia, el orden
es importante para que las reglas funcionen según lo previsto. Por ejemplo, si se
configura una regla para registrar todos los accesos a /etc y se configura otra regla
para registrar todos los accesos a /etc/sysconfig con una clave diferente, la
segunda regla nunca se activará debido a que la primera regla ya cubre ese acceso.
Cambiar el orden de las reglas permitirá que las reglas funcionen según lo previsto.
Una de las reglas más fáciles de agregar es una regla de visualización . Las visualizaciones
pueden establecerse en archivos y directorios y, opcionalmente, pueden activar ciertos tipos
de acceso (lectura, escritura, cambio de atributo y ejecución). Las visualizaciones se activan en
la llamada del sistema open y no en llamadas read o write individuales.
Algunos ejemplos de visualizaciones:
•
auditctl -w /etc/passwd -p wa -k user-edit
Agrega una visualización a /etc/passwd, para acceso de cambio de atributo y escritura, y

agrega una clave personalizada de user-edit a todos los mensajes de registro.
•
auditctl -w /etc/sysconfig/ -p rwa -k sysconfig-access
Agrega una visualización recursiva al directorio /etc/sysconfig y todos los archivos

y directorios dependientes. Visualiza accesos de lectura, escritura y cambio de atributo.
Etiqueta mensajes de registro con una clave personalizada de sysconfig-access.
•
auditctl -w /bin -p x
Audita todas las ejecuciones de binarios en /bin.
Eliminación de reglas
Las reglas de visualización del sistema de archivos pueden eliminarse al utilizar la opción -
W en lugar de -w con la regla original. Las reglas agregadas con -a o -A pueden eliminarse al
reemplazar -[aA] con -d.
RH342-RHEL7.2-es-1-20160321 59
Para eliminar todas las reglas, utilice el comando auditctl -D.
Reglas persistentes
Para que las reglas de auditoría sean persistentes, agréguelas al archivo /etc/audit/
rules.d/audit.rules. Este archivo contiene comandos auditctl como se ingresarían en
la línea de comandos, pero sin el propio comando auditctl delante. Las líneas vacías están
permitidas, y los comentarios están indicados con un carácter de numeral (#) al inicio de la
línea.
Cuando se inicia auditd, activa todas las reglas de /etc/audit/rules.d/audit.rules. El

comando auditctl puede destinarse a analizar un archivo con la opción -R.
Importante
Debido a un error, auditd no puede reiniciarse en este momento con systemctl
restart auditd. Por lo tanto, es necesario utilizar service auditd restart
para volver a cargar los cambios en las reglas persistentes.
Lectura de mensajes de auditoría

Los mensajes de auditoría registrados en /var/log/audit/audit.log contienen mucha
información. Los diferentes tipos de mensajes constan de diferentes campos, pero cada
campo tiene una etiqueta. A continuación se muestra un análisis minucioso de un registro de
auditoría típico directamente de /var/log/audit/audit.log.
type=SYSCALL msg=audit(1371716130.596:28708) : arch=c000003e syscall=2 success=yes
exit=4 a0=261b130 a1=90800 a2=e a3=19 items=1 ppid=2548 pid=26131 auid=500 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="aureport"
exe="/sbin/aureport" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key="audit-access"
type=CWD msg=audit(1371716130.596:28708): cwd="/root"
type=PATH msg=audit(1371716130.596:28708): item=0 name="/var/log/audit" inode=17998
dev=fd:01 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:auditd_log_t:s0
El type de mensaje de auditoría. En este caso, se audita una llamada del sistema, pero se
pueden encontrar diversos tipos.
La marca de tiempo y el ID del mensaje de auditoría. La parte anterior a los dos puntos
(en este caso, 1371716130.596) es la marca de tiempo en cantidad de segundos desde
la época, mientras que la parte posterior a los dos puntos (28708) es el número del
evento de auditoría.
Para convertir una marca de tiempo de la hora de época a la zona horaria local, use el
comando date --date=@<epoch-time>.
Como se muestra en el ejemplo, un único event puede desencadenar varias líneas de

registro con diferentes types.
El UID original, o Auditoría, del usuario que desencadenó este mensaje de auditoría. El
sistema de auditoría recordará el UID original cuando un usuario aumente sus privilegios
a través de herramientas como su o sudo.
El UID efectivo del usuario que desencadenó este mensaje de auditoría. Este puede ser
diferente al UID de auditoríae incluso al UID regular; por ejemplo, cuando ejecuta un
binario con el conjunto de bits SUID o SGID.
60 RH342-RHEL7.2-es-1-20160321
El nombre del ejecutable que desencadenó este mensaje de auditoría, como se

reportaría por herramientas como ps y top.
El nombre del binario en el disco para el proceso que desencadenó este mensaje de
auditoría.
Un identificador que puede utilizarse cuando busca eventos. Por lo general, las claves se
establecen por reglas de auditoría personalizadas que facilitan el filtrado de ciertos tipos
de eventos.
Búsqueda de eventos
El sistema de auditoría se envía con una herramienta potente para buscar registros de
auditoría: ausearch. ausearch no solo permite que los administradores busquen y filtren
diversos tipos de eventos fácilmente, sino que también puede interpretar eventos al traducir
valores numéricos a valores (más) legibles como nombres de usuario o nombres de llamadas
del sistema. En la siguiente tabla se enumeran algunas de las opciones más comunes para
ausearch, pero existen muchas más, incluidas opciones para buscar eventos basados en
usuarios, terminales o, incluso, máquinas virtuales.
Opción Descripción
-i Interpretar líneas de registros, traducir valores numéricos a
nombres.
--raw Imprimir entradas de registro, no colocar separadores de
registro entre entradas.
-a <EVENT-ID> Muestra todas las líneas del evento con <EVENT-ID> como
el ID de evento.
--file <FILENAME> Busca todos los eventos que tienen un nombre de archivo
específico.
-k <KEY> Busca todos los eventos con la etiqueta <KEY>.
--start [start-date] Solo busca eventos después de start-date y start-
[start-time] time. Si se deja vacía la hora de inicio, se supone que es
medianoche. Si se omite una fecha de inicio, se supone que
es el día de hoy.
El formato de hora que debería utilizarse depende de la

ubicación actual del sistema. Otros valores que pueden
utilizarse incluyen recent (últimos 10 minutos), this-
week, this-month y this-year.
--end también puede utilizarse con la misma sintaxis.
Como ejemplo, se puede utilizar ausearch para mostrar una versión interpretada del
ejemplo anterior buscado por el valor clave de audit-access.
[root@demo ]# ausearch -i -k audit-access

----
type=PATH msg=audit(06/20/2013 10:15:30.596:28708) : item=0 name=/var/log/
audit inode=17998 dev=fd:01 mode=dir,750 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:auditd_log_t:s0
type=CWD msg=audit(06/20/2013 10:15:30.596:28708) : cwd=/root
type=SYSCALL msg=audit(06/20/2013 10:15:30.596:28708) : arch=x86_64 syscall=open
success=yes exit=4 a0=261b130 a1=90800 a2=e a3=19 items=1 ppid=2548 pid=26131
auid=student uid=root gid=root euid=root suid=root fsuid=root egid=root
RH342-RHEL7.2-es-1-20160321 61
sgid=root fsgid=root tty=pts0 ses=1 comm=aureport exe=/sbin/aureport

subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=audit-access
Referencias
Para obtener más información acerca de aide, consulte las páginas del manual
aide(1) y aide.conf(5).
Para obtener más información acerca de auditd, consulte las páginas del manual
auditd(8), auditd.conf(5), auditctl(8), audit.rules(7) y ausearch(8).
62 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Configuración de seguimiento de cambios
Ejercicio guiado: Configuración de

seguimiento de cambios
En este trabajo de laboratorio, configurará y realizará una auditoría del sistema a través del
sistema de auditoría de Linus.
Recursos
Archivos /etc/audit/rules.d/audit.rules
Máquinas: • servera
• serverb
Resultados
Debería poder detectar cambios en el contenido y los atributos de archivos y directorios
ubicados en un sistema de archivos.
Andes de comenzar
Inicie sesión en servera con el usuario root.
1. Compruebe que el daemon de auditoría esté habilitado y ejecutándose en servera.
[root@servera ~]# systemctl status auditd

● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset:
enabled)
Active: active (running) since Mon 2015-12-14 16:45:54 EST; 6h ago
Process: 469 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Main PID: 468 (auditd)
CGroup: /system.slice/auditd.service
└─468 /sbin/auditd -n
Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: No rules

Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: enabled 0
Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: flag 1
Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: pid 0
Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: rate_limit 0
Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: backlog_limit 320
Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: lost 0
Dec 14 16:45:54 servera.ilt.example.com augenrules[469]: backlog 0
Dec 14 16:45:54 servera.ilt.example.com auditd[468]: Init complete, auditd 2.4.1
listening for events (startup state enable)
Dec 14 16:45:54 servera.ilt.example.com systemd[1]: Started Security Auditing
Service.
2. Cree una regla para auditar los cambios en el contenido de los archivos y directorios
ubicados en el directorio /etc. Para facilitar la identificación de registros creados por la
regla, asocie los registros con la palabra clave etc_content.
[root@servera ~]# auditctl -w /etc -p w -k etc_content
RH342-RHEL7.2-es-1-20160321 63
3. Cree otra regla para auditar los cambios en los atributos de archivos y directorios
ubicados en el directorio /etc. Para facilitar la identificación de registros creados por la
regla, asocie los registros con la palabra clave etc_attribute.
[root@servera ~]# auditctl -w /etc -p a -k etc_attribute
4. Agregue las siguientes entradas al final de /etc/audit/rules.d/audit.rules para

que las reglas de auditoría sean persistentes.
-w /etc -p w -k etc_content
-w /etc -p a -k etc_attribute
5. Copie el contenido del archivo /etc/shadow en un nuevo archivo llamado /etc/

shadow.copy.
[root@servera ~]# cp /etc/shadow /etc/shadow.copy
6. Cambie los permisos del archivo /etc/shadow.copy para que todos lo puedan leer.
[root@servera ~]# chmod +r /etc/shadow.copy
7. Utilice el comando ausearch para extraer los registros de auditoría para cambios en el
contenido de archivos y directorios del directorio /etc.
[root@servera ~]# ausearch -k etc_content
8. Utilice el comando ausearch para extraer los registros de auditoría para cambios en los
atributos de archivos y directorios del directorio /etc.
[root@servera ~]# ausearch -k etc_attribute
[student@workstation ~]$ lab audit grade
[student@workstation ~]$ lab audit reset
64 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Ser proactivo
Trabajo de laboratorio: Ser proactivo
En este trabajo de laboratorio, configurará sistemas para monitoreo, registro remoto, gestión
de configuraciones y auditoría.
Recursos
Archivos • /etc/puppet/puppet.conf
• /etc/rsyslog.conf
• /etc/audit/rules.d/audit.rules
• serverb
Resultados
Deberá poder configurar un servidor como un host de registro central y un Puppet maestro.
También deberá poder configurar otro host para monitoreo, registro en el host de registro,
comunicación con el Puppet maestro y auditoría para el acceso del sistema de archivos.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab proactive setup en
su máquina workstation.
[student@workstation ~#$ lab proactive setup
central para aceptar la entrega de mensajes de hosts remotos a través de TCP. Para organizar
mejor los mensajes, cree una nueva regla que escriba los mensajes de syslog generados
por cada host en archivos separados en el directorio /var/log/loghost. Cada archivo de
registro debe tener el nombre del host de cada sistema que genera los mensajes. Para un
mejor rendimiento, configure el registro para que no se realice una sincronización después
de que se registra cada mensaje. Agregue los nuevos archivos de registro al programa de
rotación de registros para que no lleguen a un tamaño incontrolable.
En serverb, cree una regla de auditoría para monitorear la ejecución del binario /usr/
sbin/useradd. Cada ejecución debe registrarse con la etiqueta add_user. Haga que la
regla de auditoría sea persistente para que se aplique a cada arranque del sistema. También,
instale y configure el software Performance Co-pilot para que se ejecute en serverb y pueda
ser utilizado para consultar las estadísticas actuales e históricas de rendimiento del sistema.
Para centralizar el registro, configure serverb para el registro remoto del host de registro
central. Por último, configure serverb para la gestión de configuraciones del Puppet maestro
que se ejecuta en servera.
de hosts remotos a través del protocolo TCP y para que se escriban los mensajes en
archivos separados para cada host.
RH342-RHEL7.2-es-1-20160321 65

/var/log/loghost/*.log
5. En serverb, cree una regla para auditar el acceso de ejecución del archivo /usr/sbin/
useradd.
6. En serverb, haga que la regla de auditoría sea persistente para que se aplique a cada
arranque del sistema.
7. Instale el software Performance Co-pilot en serverb al instalar el paquete pcp.
8. Inicie y habilite el servicio pmcd para recopilar métricas de rendimiento del sistema.
9. Inicie y habilite el servicio pmlogger para archivar las métricas de rendimiento del
sistema.
de Puppet.

13. Inicie el servicio puppet. El sistema se registrará con el Puppet maestro y recuperará y
aplicará su configuración.
14.1.Evalúe su trabajo.
[student@workstation ~]$ lab proactive grade
14.2.Reinicie todas sus máquinas virtuales para proveer un entorno limpio para los
siguientes ejercicios.
66 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, configurará sistemas para monitoreo, registro remoto, gestión
de configuraciones y auditoría.
Recursos
Archivos • /etc/puppet/puppet.conf
• /etc/rsyslog.conf
• /etc/audit/rules.d/audit.rules
• serverb
Resultados
Deberá poder configurar un servidor como un host de registro central y un Puppet maestro.
También deberá poder configurar otro host para monitoreo, registro en el host de registro,
comunicación con el Puppet maestro y auditoría para el acceso del sistema de archivos.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab proactive setup en
[student@workstation ~#$ lab proactive setup
central para aceptar la entrega de mensajes de hosts remotos a través de TCP. Para organizar
mejor los mensajes, cree una nueva regla que escriba los mensajes de syslog generados
por cada host en archivos separados en el directorio /var/log/loghost. Cada archivo de
registro debe tener el nombre del host de cada sistema que genera los mensajes. Para un
mejor rendimiento, configure el registro para que no se realice una sincronización después
de que se registra cada mensaje. Agregue los nuevos archivos de registro al programa de
rotación de registros para que no lleguen a un tamaño incontrolable.
En serverb, cree una regla de auditoría para monitorear la ejecución del binario /usr/
sbin/useradd. Cada ejecución debe registrarse con la etiqueta add_user. Haga que la
regla de auditoría sea persistente para que se aplique a cada arranque del sistema. También,
instale y configure el software Performance Co-pilot para que se ejecute en serverb y pueda
ser utilizado para consultar las estadísticas actuales e históricas de rendimiento del sistema.
Para centralizar el registro, configure serverb para el registro remoto del host de registro
central. Por último, configure serverb para la gestión de configuraciones del Puppet maestro
que se ejecuta en servera.
de hosts remotos a través del protocolo TCP y para que se escriban los mensajes en
archivos separados para cada host.
1.1. Habilite la recepción de syslog TCP en /etc/rsyslog.conf al quitar los

comentarios de las siguientes líneas.
RH342-RHEL7.2-es-1-20160321 67
$ModLoad imtcp
1.2. En la sección "#### RULES ####", agregue la siguiente regla para los nombres de
archivos de registro dinámicos.
$template DynamicFile,"/var/log/loghost/%HOSTNAME%.log"
*.* -?DynamicFile
1.3. Reinicie el servicio rsyslog para que se apliquen los cambios de configuración.
[root@servera ~]# systemctl restart rsyslog
2.1. Habilite el tráfico entrante en el puerto TCP 514.
[root@servera ~]# firewall-cmd --add-port=514/tcp --permanent

success
2.2. Actualice firewalld para que se aplique el cambio de firewall.
[root@servera ~]# firewall-cmd --reload

/var/log/loghost/*.log
4.1. En serverb, agregue la siguiente regla a /etc/rsyslog.conf para que todos los
mensajes de syslog se entreguen de manera remota a servera a través de TCP en el
puerto 514.
*.* @@servera.lab.example.com:514
4.2. Reinicie el servicio rsyslog para que se apliquen los cambios de configuración de
serverb.
[root@serverb ~]# systemctl restart rsyslog
5. En serverb, cree una regla para auditar el acceso de ejecución del archivo /usr/sbin/
useradd.
68 RH342-RHEL7.2-es-1-20160321
Solución
[root@serverb ~]# auditctl -w /usr/sbin/useradd -p x -k add_user
6. En serverb, haga que la regla de auditoría sea persistente para que se aplique a cada
arranque del sistema.
[root@serverb ~]# echo '-w /usr/sbin/useradd -p x -k add_user' >> /etc/audit/

rules.d/audit.rules
7. Instale el software Performance Co-pilot en serverb al instalar el paquete pcp.
[root@serverb ~]# yum install -y pcp
8. Inicie y habilite el servicio pmcd para recopilar métricas de rendimiento del sistema.
[root@serverb ~]# systemctl start pmcd

[root@serverb ~]# systemctl enable pmcd
Created symlink from /etc/systemd/system/multi-user.target.wants/pmcd.service to /
usr/lib/systemd/system/pmcd.service.
[root@serverb ~]# systemctl status pmcd
disabled)
Docs: man:pmcd(8)
CGroup: /system.slice/pmcd.service
├─1942 /usr/libexec/pcp/bin/pmcd
├─1945 /var/lib/pcp/pmdas/root/pmdaroot
├─1946 /var/lib/pcp/pmdas/proc/pmdaproc -d 3
├─1947 /var/lib/pcp/pmdas/xfs/pmdaxfs -d 11
└─1948 /var/lib/pcp/pmdas/linux/pmdalinux
Dec 14 08:26:38 serverb.lab.example.com systemd[1]: Starting Performance Metrics

Collector Daemon...
Dec 14 08:26:38 serverb.lab.example.com pmcd[1896]: Starting pmcd ...
Dec 14 08:26:38 serverb.lab.example.com systemd[1]: Started Performance Metrics
Collector Daemon.
9. Inicie y habilite el servicio pmlogger para archivar las métricas de rendimiento del
sistema.
[root@serverb ~]# systemctl start pmlogger

[root@serverb ~]# systemctl enable pmlogger
Created symlink from /etc/systemd/system/multi-user.target.wants/pmlogger.service
to /usr/lib/systemd/system/pmlogger.service.
[root@serverb ~]# systemctl status pmlogger
disabled)
Docs: man:pmlogger(1)
CGroup: /system.slice/pmlogger.service
└─6489 /usr/libexec/pcp/bin/pmlogger -P -r -T24h10m -c config.default -m
pmlogger_check 20151211.08.28
RH342-RHEL7.2-es-1-20160321 69
Dec 14 08:28:38 serverb.lab.example.com systemd[1]: Starting Performance Metrics

Archive Logger...
Dec 14 08:28:38 serverb.lab.example.com pmlogger[2535]: /usr/share/pcp/lib/pmlogger:
Warning: Performance Co-Pilot archive ...bled.
Dec 14 08:28:38 serverb.lab.example.com pmlogger[2535]: To enable pmlogger, run the
following as root:
Dec 14 08:28:38 serverb.lab.example.com pmlogger[2535]: # /usr/bin/systemctl enable
pmlogger.service
Dec 14 08:28:38 serverb.lab.example.com pmlogger[2535]: Starting pmlogger ...
Dec 14 08:28:38 serverb.lab.example.com systemd[1]: Started Performance Metrics
Archive Logger.
de Puppet.
[root@serverb ~]# yum install -y puppet

server = servera.lab.example.com
[root@serverb ~]# systemctl enable puppet

Created symlink from /etc/systemd/system/multi-user.target.wants/puppet.service to /
usr/lib/systemd/system/puppet.service.
13. Inicie el servicio puppet. El sistema se registrará con el Puppet maestro y recuperará y
aplicará su configuración.
[root@serverb ~]# systemctl start puppet
[student@workstation ~]$ lab proactive grade
14.2.Reinicie todas sus máquinas virtuales para proveer un entorno limpio para los
siguientes ejercicios.
70 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
• Una lista de los datos de rendimiento del sistema recopilados por el daemon colector de
métricas de rendimiento, pmcd, se puede mostrar con pminfo.
• El comando pmval puede utilizarse para recuperar datos actuales e históricos sobre el
rendimiento del sistema recopilados por pmcd.
• La implementación de un host de registro central requiere la configuración de rsyslog en el

host de registro central y en los clientes remotos.
• Los datos de registro de hosts remotos pueden registrarse por separado en el host de
registro central con el uso de plantillas para generar nombres de archivos de registro
dinámicos.
• El agente de Puppet, por defecto, intenta encontrar el Puppet maestro a través del nombre
puppet.lab.example.com.
• Para señalar el agente de Puppet a un Puppet maestro que tiene un nombre diferente,
configure el ajuste a través del parámetro server en la sección agente de /etc/puppet/
puppet.conf.
• La base de datos de AIDE se inicia con aide --init.
• Los cambios en el sistema de archivos pueden detectarse a través de una comparación con
la base de datos de AIDE con aide --check.
• Las reglas de auditoría se crean a través del comando auditctl.
• Los eventos en registros de auditoría pueden buscarse a través del comando ausearch.
RH342-RHEL7.2-es-1-20160321 71
72
TRAINING
CAPÍTULO 3
SOLUCIÓN DE PROBLEMAS DE
ARRANQUE
Visión general
Meta Identificar y resolver problemas que puedan afectar la
capacidad de arranque de un sistema.
Objetivos • Solucionar problemas de arranque en sistemas BIOS
tradicionales.
• Solucionar problemas en sistemas UEFI.
• Identificar y resolver errores de servicio que afecten al

arranque.
• Recuperar el control de root de un sistema.

Secciones • Resolución de problemas del cargador de arranque en
sistemas BIOS (y ejercicio guiado)
• Resolución de problemas del cargador de arranque en

sistemas UEFI (y prueba)
• Tratamiento de servicios con fallas (y ejercicio guiado)
• Recuperación de una contraseña root (y ejercicio

guiado)
Trabajo de laboratorio • Solución de problemas de arranque
RH342-RHEL7.2-es-1-20160321 73
Capítulo 3. Solución de problemas de arranque
Resolución de problemas del cargador de

arranque en sistemas BIOS
Objetivos
Después de completar esta sección, los estudiantes podrán reparar problemas de arranque
en sistemas BIOS tradicionales.
Una secuencia de arranque tradicional

Un sistema con tecnología de Sistema básico de entrada y salida (Basic Input Output System)
(BIOS) atraviesa varios pasos desde que se desconecta hasta que ejecuta un sistema Red Hat
Enterprise Linux. La siguiente lista proporciona un resumen de alto nivel de los pasos que
se llevan a cabo. La lista también se aplica a las máquinas virtuales que imitan a un sistema
BIOS tradicional. La lista supone que se está utilizando el cargador de arranque grub2. La
lista variará para cargadores de arranque diferentes.
1. El firmware de BIOS se inicia y realiza una prueba automática de encendido (Power On Self
Test) (POST).
2. BIOS busca (posibles) dispositivos de arranque y los ordena en función de la preferencia

configurada por el usuario.
3. Los dispositivos de arranque se analizan en orden para un firmware de arranque (como

PXE ROM en tarjetas de red), un registro de arranque maestro (Master Boot Record, MBR)
o una partición marcada como elemento de arranque. Si se encuentra, BIOS lo ejecuta.
4. El cargador de arranque de primera etapa almacenado en MBR carga el cargador de

arranque de etapa 1.5 (controladores) y etapa 2 desde el disco y lo ejecuta.
5. El cargador de arranque carga un archivo de configuración desde el disco. En el caso de

grub2, será /boot/grub2/grub.cfg.
6. El archivo de configuración se analiza y, según su contenido, se selecciona una entrada

de arranque automáticamente o por usuario.
7. El kernel y disco RAM inicial a los que se hacen referencia en la entrada de arranque se
cargan desde el disco, y se cede el control al kernel.
8. El kernel arranca e inicializa hardware a través de los controladores encontrados en el

disco RAM inicial. También se inicia un sistema init simple desde el disco RAM.
9. Los scripts del disco RAM inicial montan el sistema del archivo raíz del sistema de
destino, luego trasladan al archivo raíz al sistema de archivos instalado recientemente y
entregan el control a /sbin/init en el sistema del archivo raíz de destino.
10. El sistema init monta los sistemas de archivos e inicia los servicios en función a su
configuración.
74 RH342-RHEL7.2-es-1-20160321
GRUB2
GRUB2
El cargador de arranque utilizado en Red Hat Enterprise Linux es grub2, la segunda versión
importante del Gran gestor de arranque unificado (GRand Unified Bootloader). grub2 almacena
archivos en un sistema BIOS en una variedad de ubicaciones:
/boot/
Kernels y discos RAM iniciales. Los subdirectorios contienen otros archivos.
/boot/grub2/
Archivos de configuración, módulos de extensión y temas.
/boot/grub2/grub.cfg
El archivo de configuración grub2 principal. Este archivo se genera automáticamente y,
por lo general, no se debe editar manualmente.
Como conveniencia, /etc/grub2.cfg es un enlace simbólico a este archivo.
/etc/grub.d/
Este directorio contiene un script auxiliar para generar un archivo de configuración grub2
principal.
/etc/default/grub
Este archivo contiene variables utilizadas en la generación del archivo de configuración
grub2 principal.
/boot/grub2/grubenv
Un archivo de exactamente 1 KiB, utilizado como almacenamiento para variables, como la
entrada de arranque “guardada” o predeterminada.
La herramienta grub2-editenv puede utilizarse para leer y modificar estos ajustes.
El registro de arranque maestro (Master Boot

Record, MBR)
Para iniciar grub2 desde el disco en un sistema BIOS, hay dos opciones: almacenar la primera
parte del cargador de arranque grub2 en el registro de arranque maestro (Master Boot Record,
MBR) de un disco, o almacenarla en el primer sector de una partición que está marcada como
“elemento de arranque”.
El problema con el MBR

El uso del MBR tiene una gran restricción: Un MBR típico tiene solo 512 bytes de tamaño, y
parte de ese espacio se utiliza para la tabla de partición de ese disco, dejando solo 446 bytes
para el cargador de arranque.
Para solucionar este problema, grub2 puede usar el “seguimiento de arranque”, la “brecha
de MBR” o el “área incorporada” en el disco para almacenar módulos y archivos adicionales.
Este es el espacio entre el MBR y la primera partición del disco. Para trabajar de manera
confiable, se necesitan al menos 31 KiB de espacio disponible (63 sectores en un disco de
sectores de 512 bytes). Si anaconda ha particionado un disco, la primera partición por lo
general comenzará en el sector 2048, dejando aproximadamente 1 MiB de espacio para el
área incorporada, suficiente espacio para grub2.
RH342-RHEL7.2-es-1-20160321 75
Configuración de grub2
Bajo circunstancias normales, un administrador no debería configurar manualmente
el cargador de arranque de grub2. Cuando se instala un kernel nuevo, se agrega a la
configuración automáticamente, y cuando se elimina un kernel, la entrada correspondiente
en el menú del cargador de arranque también se elimina automáticamente.
Es posible que el administrador desee modificar algunos parámetros que grub2 pasa a kernel
en el inicio. La mejor manera de hacerlo es al editar /etc/default/grub y, luego, forzar una
recreación del archivo de configuración grub2 principal.
A continuación se enumeran los ajustes de /etc/default/grub de interés:
GRUB_TIMEOUT
La cantidad de segundos que se muestra grub2 antes de que se inicia automáticamente
la entrada predeterminada.
GRUB_DEFAULT
La cantidad de entradas predeterminadas que deben iniciarse cada vez que un usuario
no selecciona otra entrada. grub2 comienza a contar en 0.
Si esta variable se establece en la cadena guardado, la entrada se tomará de /boot/

grub2/grubenv.
GRUB_CMDLINE_LINUX
Esta variable contiene una lista de opciones adicionales de la línea de comando de kernel
que deben agregarse a cada kernel de Linux individual. Los usos típicos incluyen “rhgb
quiet” para un arranque gráfico, “console=xxxxxx” para seleccionar un dispositivo
de consola de kernel, y “crashkernel=xxxx” para configurar el volcado de memoria
automático de kernel.
Después de actualizar el archivo /etc/default/grub, ejecute el comando grub2-

mkconfig -o /boot/grub2/grub.cfg para que se apliquen los cambios. Esto generará
un archivo de configuración nuevo a través de los scripts de /etc/grub.d/ y los ajustes de /
etc/default/grub. Si no se especifica un archivo de salida con la opción -o, se escribirá un
archivo de configuración como salida estándar.
Reinstalación de grub2 en el MBR

Si, por algún motivo, se dañó el MBR o el área incorporada, un administrador tendrá que
reinstalar grub2 en el MBR. Dado que esto implica que el sistema no se puede iniciar
actualmente, por lo general se realiza desde dentro de un Live CD o desde dentro de un
entorno de recuperación proporcionado por el instalador anaconda.
El siguiente procedimiento explica cómo arrancar un entorno de recuperación y reinstalar

grub2 en el MBR desde ese lugar. Si un administrador aún está logueado en un sistema en
ejecución, el procedimiento puede reducirse solo al comando grub2-install.
1. Realice el arranque desde una fuente de instalación; esta puede ser una imagen de DVD,
un CD de netboot o PXE que proporciona un árbol de instalación RHEL.
2. En el menú de arranque del medio de instalación, seleccione la opción Rescue an

installed system o edite la línea de comandos de kernel para que incluya la palabra
rescue.
76 RH342-RHEL7.2-es-1-20160321
Reinstalación de grub2 en el MBR
3. Cuando se le pida montar los discos para el sistema de destino que se recuperará,
seleccione la opción 1 (Continuar). Esta acción montará el sistema en /mnt/sysimage.
4. Presione Intro para obtener una shell. Esta shell residirá dentro del entorno de
instalación/recuperación, con el sistema de destino montado en /mnt/sysimage.
Esta shell tiene una cantidad de herramientas disponibles para recuperar un sistema,
como todas las herramientas comunes de conexiones en red, LVM y sistema de archivos.
Los diversos directorios bin del sistema de destino también se agregan a la ruta de
búsqueda ejecutable predeterminada (${PATH}).
5. chroot en el directorio /mnt/sysimage.
sh-4.2# chroot /mnt/sysimage
6. Verifique que /boot esté montado. Según el tipo de instalación, /boot puede estar en
una partición separada o puede ser parte del sistema del archivo raíz.
sh-4.2# ls -l /boot
7. Utilice el comando grub2-install para volver a escribir las secciones del cargador de
arranque del MBR y del área incorporada. Este comando necesitará el dispositivo de
bloqueo que representa el disco principal como argumento. Si no recuerda el nombre del
disco principal, utilice lsblk y blkid para identificarlo.
sh-4.2# grub2-install /dev/vda
8. Reinicie el sistema. Puede hacerlo al cerrar la shell de chroot y la shell de recuperación.
9. Espere a que el sistema se reinicie dos veces. Después del primer reinicio, el sistema
realizará un nuevo etiquetado exhaustivo del sistema de archivos SELinux y, luego, se
reiniciará otra vez automáticamente para asegurarse de que se utilicen los contextos
adecuados. Este nuevo etiquetado se activa automáticamente por el sistema de
recuperación anaconda que crea el archivo /.autorelabel.
Referencias
El capítulo sobre el cargador de arranque grub2 en la Guía de administración
de sistemas de Red Hat Enterprise Linux que se encuentra en https://
access.redhat.com/documentation
Páginas de información y del manual grub2-install(1) y grub2-mkconfig(1)
RH342-RHEL7.2-es-1-20160321 77
Ejercicio guiado: Resolución de problemas

del cargador de arranque en sistemas BIOS
En este trabajo de laboratorio, restaurará el cargador de arranque en una máquina basada

en BIOS que produce un error en el arranque.
Recursos
• servera
Resultados
Deberá poder solucionar o reinstalar el cargador de arranque en un sistema basado en BIOS
a través del modo de recuperación (rescue) de anaconda.
Andes de comenzar
Desde su sistema workstation, ejecute el comando lab biosbootbreak setup. Este
comando modificará su sistema servera para que no pueda arrancar y, luego, lo reiniciará.
[student@workstation ~]$ lab biosbootbreak setup
Su servera no puede arrancar. Investigue y solucione el problema.
1. Consulte la consola de su sistema servera. ¿Qué información se muestra y qué se

puede deducir de esta información?
1.1.
Booting from Hard Disk...
Seguido de un cursor intermitente.
1.2. Esto indicaría un problema en el contenido del MBR. Si el problema hubiera ocurrido
en grub2.cfg, hubiese aparecido un mensaje de error más informativo.
2. Reinicie su servera en el sistema de recuperación anaconda.
2.1. Reinicie, o desconecte, y vuelva a conectar su máquina servera.
2.2. Cuando se muestre el menú de arranque, seleccione la entrada que desea arrancar
desde la red.
2.3. Resalte la línea Boot into rescue environment y presione Intro.
2.4. Espere que anaconda termine de cargarse y, cuando se le pida montar su sistema en
/mnt/sysimage, presione 1 y pulse Intro para continuar.
2.5. Cuando se le solicite, presione Intro para abrir una shell en su sistema.
3. Reinstale grub2 en el MBR de /dev/vda. Deberá aplicar chroot al sistema montado en

/mnt/sysimage para continuar.
78 RH342-RHEL7.2-es-1-20160321
3.1. chroot en el sistema en /mnt/sysimage.
sh-4.2# chroot /mnt/sysimage
3.2. Reinstale el cargador de arranque grub2 en /dev/vda.
sh-4.2# grub2-install /dev/vda

Installing for i386-pc platform.
Installation finished. No error reported.
4. Salga de anaconda y permita que el sistema se reinicie con normalidad.
4.1. Presione Ctrl+D para salir de la shell chroot.
4.2. Presione Ctrl+D para salir de anaconda. El sistema se reiniciará dos veces.
El segundo reinicio está forzado por el sistema después de realizar un nuevo
etiquetado completo de SELinux.
Importante
Durante el primer reinicio, puede parecer que su sistema no responde;
esto se debe a que se está realizando un nuevo etiquetado de SELinux en
segundo plano. No interrumpa el sistema, o reiniciará el nuevo etiquetado
en el próximo reinicio.
RH342-RHEL7.2-es-1-20160321 79
Resolución de problemas del cargador de

arranque en sistemas UEFI
Objetivos
Después de completar esta sección, los estudiantes podrán reparar problemas de arranque
en sistemas UEFI.
¿Qué es UEFI?
Presentada en 2005, la Unified Extensible Firmware Interface (UEFI) reemplaza la anterior
Extensible Firmware Interface (EFI) y el sistema BIOS. Se buscó un reemplazo del BIOS anterior
para solucionar los límites que BIOS imponía, como el modo de procesador de 16 bits y solo 1
MiB de espacio accesible.
UEFI también permite el arranque de discos superiores a 2 TiB, siempre y cuando estén
particionados con una GUID Partition Table (GPT).
Una de las grandes diferencias entre los sistemas UEFI y los sistemas BIOS es la manera
en que arrancan. Mientra que en un sistema BIOS, BIOS tiene que buscar dispositivos de
arranque, los sistemas operativos pueden “registrarse” con el firmware de UEFI. Esto permite
que sea más fácil para los usuarios finales seleccionar el sistema operativo que desean
arrancar en un entorno de varios arranques.
grub2 y UEFI
Para arrancar un sistema de UEFI a través de grub2, debe haber una EFI System Partition
(ESP) en el disco. Esta partición debe tener el UUID de GPT C12A7328-F81F-11D2-
BA4B-00A0C93EC93B o el tipo de MBR 0xEF. Esta partición debe estar formateada con un
sistema de archivos FAT y debe ser lo suficientemente grande para admitir todos los kernels
de arranque y el propio cargador de arranque. Se recomienda un tamaño de 512 MiB, pero
los tamaños más pequeños también funcionarán. Esta partición debe colocarse en /boot/
efi y, por lo general, será creada por el instalador anaconda.
La principal diferencia de grub2 entre BIOS y UEFI

Aunque la mayoría de las herramientas y sintaxis de configuración son iguales para los
arranques de BIOS y UEFI, se aplican algunos cambios pequeños:
linux16/initrd16 vs. linuxefi/initrdefi

Los comandos de configuración para cargar un kernel y el switch de disco RAM inicial de
linux16 y initrd16 a linuxefi y initrdefi, respectivamente.
Este cambio es necesario dado que los kernels necesitan cargarse de manera diferente
en un sistema UEFI que en un sistema BIOS. El comando grub2-mkconfig reconoce
automáticamente un sistema UEFI y realiza los cambios correctos.
/boot/grub2 vs. /boot/efi/EFI/redhat

En los sistemas UEFI, el directorio que tiene los archivos de configuración grub2 y los
extras se traslada a /boot/efi/EFI/redhat. Esta es una ubicación en el ESP, que la
hace accesible para el firmware de UEFI.
80 RH342-RHEL7.2-es-1-20160321
Reinstalación de grub2 en máquinas basadas en UEFI
grub2-install
Aunque el comando grub2-install es capaz de instalar un cargador de arranque en un
sistema UEFI, nunca debe utilizarse directamente.
Llamar a grub2-install en un sistema UEFI generará un archivo /boot/efi/EFI/

redhat/grubx64.efi nuevo. En los sistemas Red Hat Enterprise Linux 7, este archivo
debe ser la versión prefabricada del paquete grub2-efi.
El comando grub2-install también registrará un objetivo (target) de arranque en el

firmware de UEFI a través de esta aplicación grubx64.efi actualizada, en lugar de la
aplicación shim.efi.
Advertencia
El uso de grub2-install instalará un grubx64.efi personalizado. Si el
sistema se configuró para un arranque seguro, esto producirá un error en el
arranque.
/boot/grub2/grub.cfg vs. /boot/efi/EFI/redhat/grub.cfg

Incluido en el traslado de /boot/grub2 a /boot/efi/EFI/redhat/ se encuentra el
traslado del archivo de configuración grub2 principal.
El enlace simbólico /etc/grub.cfg también se traslada a /etc/grub2-efi.cfg.
Reinstalación de grub2 en máquinas basadas en

UEFI
Si, por algún motivo, se eliminó cualquiera de los archivos que se debían arrancar en /boot/
efi, o si se recreó la partición, estos archivos pueden recuperarse mediante la reinstalación
de los paquetes grub2-efi y shim.
[root@demo ~]# yum reinstall grub2-efi shim
Si se eliminó /boot/efi/EFI/redhat/grub.cfg, puede restaurarse con el siguiente

comando:
[root@demo ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Si se eliminó la entrada de Red Hat del menú de arranque de UEFI, arrancar desde el disco
que tiene la instalación de Red Hat Enterprise Linux 7 hará que se agregue automáticamente.
La cadena de arranque de UEFI

Para trabajar con sistemas de arranque seguro, donde las firmas de cargadores de arranque,
kernels, etc., pueden ser verificadas por el firmware para autenticar que solo se ejecuta el
software no modificado, Red Hat Enterprise Linux 7 utiliza el cargador de arranque shim de
UEFI.
La aplicación shim.efi se firma con una clave en la que confía la mayor parte del firmware
de UEFI. Cuando se inicia, intentará cargar grubx64.efi a través de las llamadas normales
de firmware de UEFI. Si el firmware de UEFI se niega a cargar la aplicación debido a una mala
RH342-RHEL7.2-es-1-20160321 81
firma, shim intentará verificar la aplicación a través de otras claves compiladas en shim o a
través de una clave generada por el usuario almacenada en la NVRAM (Machine Owner Key,
Clave de propietario de la máquina [MOK]). Cuando intenta iniciar una aplicación firmada para
la que no se registraron claves, la aplicación MokManager.efi se inicia automáticamente para
que un usuario final pueda registrar una clave personal.
La aplicación shim.efi también registra una nueva llamada del sistema UEFI que grub2 puede
utilizar para verificar firmas de kernel.
Si shim.efi no está registrado con el firmware de UEFI, arrancar desde el sistema que
contiene el ESP ejecutará la aplicación /boot/efi/EFI/BOOT/BOOTX64.efi. A su vez, esto
ejecutará la aplicación fallback.efi, que registra automáticamente la aplicación shim.efi y
arranca el sistema, en función de los ajustes de /boot/efi/EFI/redhat/BOOT.CSV.
Administración de objetivos de arranque de UEFI

Para administrar el orden de arranque lógico y los objetivos de arranque disponibles, Red
Hat Enterprise Linux 7 se proporciona con una herramienta llamada efibootmgr en el
paquete efibootmgr. En sistemas basados en UEFI, este paquete se instalará de manera
predeterminada.
Las herramientas efibootmgr permiten que los administradores gestionen la lista de

objetivos de arranque de UEFI disponibles, editen entradas individuales, y mucho más.
Visualización de objetivos actuales

Para ver objetivos actuales, puede invocar la herramienta sin opciones:
[root@demo ~]# efibootmgr

BootCurrent: 0016
Timeout: 0 seconds
BootOrder: 0016,000A,000D,0009,000B,000C,000E,0008,0007,0014,0015,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Lenovo Diagnostics
...
Boot0013* PCI LAN
Boot0014 Other CD
Boot0015 Other HDD
Boot0016* Red Hat
Esta lista define el orden en el que se intentarán las entradas de arranque; primero la
entrada más a la izquierda y, por último, la entrada más a la derecha. El número hace
referencia a varias entradas de BootXXXX que lo siguen.
Esta es una entrada de arranque individual; en este caso, número 0x0016. Los números
de entrada de arranque siempre se presentan (y usan) como números hexadecimales.
Los asteriscos (*) muestran que esta entrada está activa; es decir, se puede seleccionar
y arrancar.
Para obtener más información acerca de las entradas de arranque, puede utilizar la opción -
v.
[root@demo ~]# efibootmgr

BootCurrent: 0016
Timeout: 0 seconds
82 RH342-RHEL7.2-es-1-20160321
Administración de objetivos de arranque de UEFI
BootOrder: 0016,000A,000D,0009,000B,000C,000E,0008,0007,0014,0015,0013
Boot0000 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
...
Boot0016* Red Hat HD(1,GPT,c13391b4-a66f-4b9b-9deb-39da588d33a3,0x800,0x64000)/File(\EFI
\redhat\shim.efi)
La entrada de Boot0016 ahora muestra el disco duro, la partición y el archivo de esa

partición que deben utilizarse para arrancar.
Eliminación de una entrada

Para eliminar una entrada de la lista por completo, se puede usar la opción -B. Por ejemplo,
para eliminar la entrada 1E, se puede usar el siguiente comando:
[root@demo ~]# efibootmgr -b 1E -B
Selección de un objetivo de arranque temporal

Para sobrescribir el orden de arranque normal para un único arranque, se puede usar la
opción -n. Por ejemplo, para forzar al sistema a arrancar en la entrada 2C la próxima vez que
se inicia, se puede usar el siguiente comando.
[root@demo ~]# efibootmgr -n 2c
Agregar una entrada

Las entradas pueden agregarse a través de la opción -c. A menos que se especifique lo
contrario, esto supondrá que ESP es /dev/sda1, la etiqueta prevista es Linux, y la aplicación
del cargador de arranque se llama elilo.efi.
El siguiente ejemplo agrega una nueva entrada denominada Yippie, con /dev/sda2 como
el ESP, y con la aplicación /EFI/yippie.efi en el ESP. Tenga en cuenta que las barras
diagonales normales (/) deben reemplazarse con barras diagonales inversas (\).
[root@demo ~]# efibootmgr -c -d /dev/sda -p 2 -L "Yippie" -l "\EFI\yippie.efi"
Consulte la página del manual efibootmgr para obtener más información acerca de
seleccionar objetivos de arranque temporales, agregar y eliminar entradas, y actualizar
entradas.
Referencias
Las secciones de “Arranque seguro de UEFI” en la Guía de administración de
sistemas de Red Hat Enterprise Linux en https://access.redhat.com/
documentation
Página del manual (1)efibootmgr
RH342-RHEL7.2-es-1-20160321 83
Prueba: Resolución de problemas del

cargador de arranque en sistemas UEFI
Elija las respuestas correctas para las siguientes preguntas:
1. ¿Cuál es el uso principal de la aplicación shim.efi?
a. Comprobar que no se modifique el firmware de UEFI.

b. Verificar la firma de grubx64.efi y cargarla.
c. Cargar fallback.efi y registrarlo con el firmware de UEFI.
d. Realizar varios arranques en otro sistema operativo instalado.
2. La herramienta que administra las entradas de arranque de UEFI se llama:
a. grub2-install
b. fallback.efi
c. efibootmgr
d. grub2
3. En un sistema habilitado por UEFI, la ubicación del archivo de configuración grub2

principal es:
a. /boot/efi/EFI/redhat/grub.cfg
b. /boot/grub2/grub.cfg
c. /boot/efi/grub.cfg
d. /boot/efi/redhat/grub.cfg
84 RH342-RHEL7.2-es-1-20160321
Solución
Solución
1. ¿Cuál es el uso principal de la aplicación shim.efi?
a. Comprobar que no se modifique el firmware de UEFI.

b. Verificar la firma de grubx64.efi y cargarla.
c. Cargar fallback.efi y registrarlo con el firmware de UEFI.
d. Realizar varios arranques en otro sistema operativo instalado.
2. La herramienta que administra las entradas de arranque de UEFI se llama:
a. grub2-install
b. fallback.efi
c. efibootmgr
d. grub2
3. En un sistema habilitado por UEFI, la ubicación del archivo de configuración grub2

principal es:
a. /boot/efi/EFI/redhat/grub.cfg
b. /boot/grub2/grub.cfg
c. /boot/efi/grub.cfg
d. /boot/efi/redhat/grub.cfg
RH342-RHEL7.2-es-1-20160321 85
Tratamiento de servicios con fallas
Objetivos
Después de completar esta sección, los estudiantes podrán identificar y resolver fallas del
servicio que afectan el proceso de arranque.
Dependencias de servicio
Cuando se inicia un sistema Red Hat Enterprise Linux 7, también se inician diversos servicios
automáticamente en función del objetivo de arranque (boot target) seleccionado. Cada uno
de estos servicios tiene dependencias en otros servicios.
Estas dependencias están enumeradas en el archivo de configuración de las unidades en

el disco, un archivo de configuración directo (por lo general, un archivo en /etc/systemd/
system/<UNITNAME>.d/), o a través de un subdirectorio requires o wants como /etc/
systemd/system/<UNITNAME>.requires o /etc/systemd/system/<UNITNAME>.wants.
Tipos de dependencia
En la siguiente lista se detallan los diferentes tipos de dependencia que una unidad puede
tener. Para obtener más información, consulte la página del manual systemd.unit(5).
Requires=
Iniciar esta unidad agregará automáticamente las unidades requeridas en la transacción.
Detener la unidad requerida detendrá también esta unidad. A menos que también se
utilice After= o Before=, las unidades se iniciarán al mismo tiempo.
Este tipo de dependencia también puede configurarse al crear un directorio /etc/

systemd/system/<UNITNAME>.requires y agregarles enlaces simbólicos a las
unidades requeridas en ese directorio.
RequiresOverridable=
Como Requires, pero los requisitos con fallas no harán que la unidad falle cuando un
administrador la inicia explícitamente. Cuando se inician como una dependencia, por
ejemplo durante el arranque, los requisitos harán que esta unidad falle.
Requisite= , RequisiteOverridable=
Como Requires y RequiresOverridable, pero más sólido. Si Requires inicia una
unidad requerida que todavía no está en ejecución, Requisite fallará.
Wants=
Una versión más débil de Requires. Cuando una unidad deseada no puede iniciarse,
aún así esta unidad se iniciará.
El valor wants también puede configurarse al crear enlaces simbólicos en las unidades
deseadas de /etc/systemd/system/<UNITNAME>.wants/.
Conflicts=
Una dependencia negativa. Iniciar esta unidad detendrá las unidades en conflicto (si
corresponde), y viceversa.
86 RH342-RHEL7.2-es-1-20160321
Inspección de dependencias
Before= , After=
Estas dos entradas configuran el orden. Cuando no se usan, las unidades requeridas se
inician al mismo tiempo. Si la unidad a.service tiene una línea Before=b.service, la
ejecución de b.service se demorará hasta que a.service haya finalizado el inicio.
After= indica que las unidades enumeradas deben haber finalizado el inicio antes de
que se pueda iniciar esta unidad.
Inspección de dependencias
Hay tres maneras de ver las dependencias de una unidad: manual, automatizada y gráfica.
Para ver manualmente las dependencias de una unidad, se puede usar el comando
systemctl show UNIT. Un administrador buscaría las líneas de configuración relevantes y
repetiría este proceso para todas las dependencias enumeradas.
Una manera más automatizada es el uso del comando systemctl list-dependencies

UNIT. Esto mostrará un árbol de todas las dependencias enumeradas y sus dependencias,
etc. En un terminal capaz de mostrar resultados por colores, cada línea también mostrará un
punto verde o rojo para indicar si la unidad está activa o no.
[root@demo ~]# systemctl list-dependencies nfs-server.service

nfs-server.service
● ├─auth-rpcgss-module.service
● ├─nfs-config.service
● ├─nfs-idmapd.service
● ├─nfs-mountd.service
● ├─proc-fs-nfsd.mount
● ├─rpc-statd-notify.service
● ├─rpc-statd.service
● ├─system.slice
● ├─network.target
● └─rpcbind.target
nota
Una buena cantidad de unidades tiene una dependencia en un objetivo más grande
como basic.target. Ejecutar systemctl list-dependencies en esas unidades
también mostrará todas las dependencias para ese objetivo en el resultado.
En algunos casos, especialmente cuando se trabaja con cadenas de dependencias más

grandes, se puede requerir una representación gráfica de esas dependencias. Para
esos casos, se debe utilizar el comando systemd-analyze dot en combinación con el
comando dot del paquete graphviz. Por ejemplo, para crear una representación visual de las
dependencias en la unidad sshd.service:
[root@demo ~]# yum -y install graphviz

[root@demo ~]# systemd-analyze dot sshd.service | dot -Tsvg > sshd-dependencies.svg
Color legend: black = Requires
dark blue = Requisites
dark grey = Wants
red = Conflicts
green = After
RH342-RHEL7.2-es-1-20160321 87
s s h d .s o c k e t m u lt i-u s e r .t a r g e t
s s h d .s e r vic e
s s h d -k e yg e n .s e r vic e b a s ic .t a r g e t s ys t e m d -jo u r n a ld .s o c k e t s ys t e m .s lic e n e t w o r k .t a r g e t s h u t d o w n .t a r g e t
Problemas de dependencia
Es posible que un administrador configure dependencias de manera tal que el sistema nunca
pueda iniciarse mientras esté adherido a esas dependencias; por ejemplo, dos unidades
que tienen un Requires y un Before señalándose entre sí. Para que los sistemas puedan
arrancar, systemd detectará esos tipos de problemas y los intentará resolver. El método que
se utiliza para resolver estos problemas es bastante directo: Una de las unidades infractoras
se elimina de la transacción hasta que se alcance una configuración de arranque. Esto puede
significar que una cantidad de servicios que un administrador pensó que se iniciarían no se
están iniciando. Solo se muestra un breve mensaje en la consola en el momento del arranque
para esos problemas, por lo que es posible que se requiera una lectura adecuada de los
registros del sistema.
Después de localizar, y verificar, estos tipos de problemas, un administrador deberá

modificar las dependencias que aparecen enumeradas en las unidades afectadas para
corregir la situación. En muchos casos, cambiar un Requires a un Wants, o corregir un uso
incorrecto de Before o After, puede solucionar la situación.
Importante
Cuando cambia archivos de configuración en el disco, no se olvide de ejecutar
systemctl daemon-reload para informarle los cambios a systemd.
Shell de root temprana

En algunos casos, las tareas de inicio pueden tomar mucho más tiempo del previsto o incluso
no completarse después de minutos u horas. Para depurar esos tipos de problemas, el
comando systemctl list-jobs puede mostrar todas las tareas actuales que systemd
está ejecutando, lo que le permite al administrador detenerlas o cancelarlas, o corregir el
motivo por el cual estas tareas demoran tanto.
Para obtener una shell root durante el inicio, un administrador puede habilitar el servicio
debug-shell.service. Este servicio iniciará una consola virtual con una shell logueada
como root anexada en /dev/tty9, muy prematuramente durante el arranque, durante el
inicio del objetivo (target) sysinit.target.
A través de esta shell de root temprana, un administrador puede analizar, depurar y, a

menudo, corregir una unidad o un servicio con fallas.
88 RH342-RHEL7.2-es-1-20160321
Shell de root temprana
Advertencia
NO deje el servicio debug-shell.service habilitado y en ejecución después de
que haya finalizado la depuración. Cualquier persona con acceso a una consola, ya
sea físicamente o a través de una tarjeta de gestión o un switch KVM, tendrá acceso
completo y libre a la máquina.
Referencias
Descripción general de systemd para RHEL7
https://access.redhat.com/articles/754933
Páginas del manual: systemd-analyze(1), systemd.unit(5)
RH342-RHEL7.2-es-1-20160321 89
Ejercicio guiado: Tratamiento de servicios

con fallas
En este trabajo de laboratorio, resolverá un problema donde hay dos servicios que no
pueden iniciarse en el arranque.
Recursos
• servera
Resultados
Deberá poder resolver un problema donde hay dos servicios que no pueden iniciarse en el
arranque.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab bootservicefail
setup en su sistema workstation.
[student@workstation ~#$ lab bootservicefail setup
Como parte de un proyecto más grande, su máquina servera está configurada para
ejecutar contenido web y de FTP, a través de los daemons httpd y vsftpd respectivamente.
Las especificaciones para este proyecto requerían que ambos daemons estén siempre en
ejecución al mismo tiempo, en la misma máquina.
Uno de sus excolegas ha intentado cumplir con este requisito, pero ahora ambos servicios
se niegan a iniciar en el momento del arranque. Lo han llamado para solucionar este
problema. Por ahora, no necesita garantizar que los dos servicios siempre se ejecutarán
simultáneamente.
1. Intente recrear el problema al verificar el estado de httpd y vsftpd en su máquina

servera.
1.1. Verifique el estado del servicio httpd. Dado que algunas líneas de estado pueden
contener información útil que supera el límite de 80 caracteres, utilice la opción -l
para mostrar las líneas de estado completas.
[root@servera ~]# systemctl status -l httpd

● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor
preset: disabled)
Drop-In: /etc/systemd/system/httpd.service.d
└─10-dependencies.conf
Active: inactive (dead)
Docs: man:httpd(8)
man:apachectl(8)
Dec 14 10:40:00 servera.lab.example.com systemd[1]: Found ordering cycle on

httpd.service/start
Dec 14 10:40:00 servera.lab.example.com systemd[1]: Found dependency on
vsftpd.service/start
90 RH342-RHEL7.2-es-1-20160321
Dec 14 10:40:00 servera.lab.example.com systemd[1]: Found dependency on
httpd.service/start
Dec 14 10:40:00 servera.lab.example.com systemd[1]: Breaking ordering cycle by
deleting job vsftpd.service/start
1.2. Verifique el estado del servicio vsftpd. Dado que algunas líneas de estado pueden
contener información útil que supera el límite de 80 caracteres, utilice la opción -l
para mostrar las líneas de estado completas.
[root@servera ~]# systemctl status -l vsftpd

● vsftpd.service - Vsftpd ftp daemon
Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; enabled; vendor
preset: disabled)
Drop-In: /etc/systemd/system/vsftpd.service.d
└─10-dependencies.conf
Active: inactive (dead)
....
Dec 14 10:40:00 servera.lab.example.com systemd[1]: Job vsftpd.service/start
deleted to break ordering cycle starting with httpd.service/start
2. Parece que ambos servicios tienen una fuerte dependencia de inicio entre sí. Si
observa el resultado del paso anterior, ¿qué archivos podrían ser responsables de esta
dependencia? Investigue el contenido de esos archivos.
2.1. Desde el resultado de los comandos systemctl status, puede ver que se
agregaron dos archivos no estándares a las especificaciones del servicio systemd:
• /etc/systemd/system/httpd.service.d/10-dependencies.conf
• /etc/systemd/system/vsftpd.service.d/10-dependencies.conf
2.2. Investigue el contenido de estos dos archivos.
[root@servera ~]# cat /etc/systemd/system/httpd.service.d/10-dependencies.conf

[Unit]
After=vsftpd.service
Requires=vsftpd.service
[root@servera ~]# cat /etc/systemd/system/vsftpd.service.d/10-dependencies.conf
[Unit]
After=httpd.service
Requires=httpd.service
3. Formule una hipótesis acerca de por qué estos dos servicios no pueden iniciarse.
3.1. Ambos servicios tienen un valor Requires para otro servicio, pero esto solo
garantiza que si uno de ellos se inicia, el otro también lo hará.
3.2. Ambos servicios tienen un requisito de After en el otro servicio. Esto provocará una
dependencia cíclica, que systemd interrumpirá al no iniciar estos servicios.
4. Describa las dos soluciones posibles.
4.1. Eliminar ambos directorios/archivos completamente, luego actualizar systemd y, por

último, iniciar los servicios. Este enfoque eliminará todas las dependencias.
RH342-RHEL7.2-es-1-20160321 91
4.2. Cambiar una de las dos líneas After a Before garantizará que los servicios siempre
se inicien juntos, sin causar una dependencia cíclica.
5. Intente solucionar este problema al cambiar la línea After para el servicio

httpd.service a Before. Actualice systemd e inicie ambos servicios para comprobar
que todo funcione.
5.1. Cambie la línea After para el servicio httpd.service a Before. Abra /etc/
systemd/system/httpd.service.d/10-dependencies.conf en un editor de
texto y edítelo para que tenga el siguiente texto:
[Unit]
Before=vsftpd.service
Requires=vsftpd.service
5.2. Indíquele a systemd que vuelva a cargar todos los archivos de configuración del
disco.
[root@servera ~]# systemctl daemon-reload
5.3. Inicie los servicios httpd.service y vsftpd.service.
[root@servera ~]# systemctl start httpd.service vsftpd.service
5.4. Reinicie su sistema servera para comprobar que ambos servicios se iniciarán
durante el arranque.
6. Cuando finalice, verifique su trabajo ejecutando el comando lab bootservicefail

grade desde su máquina workstation.
[student@workstation ~]$ lab bootservicefail grade
7. Después de calificar sus sistemas, restablezca correctamente sus máquinas al estado que
tenían antes de iniciar el trabajo de laboratorio, al restablecer sus máquinas virtuales o al
ejecutar el siguiente comando en su sistema workstation.
[student@workstation ~]$ lab bootservicefail reset
92 RH342-RHEL7.2-es-1-20160321
Recuperación de la contraseña de root
Recuperación de la contraseña de root
Objetivos
Tras finalizar esta sección, los estudiantes podrán recuperar el control de root de un sistema.
Recuperación de una contraseña de root perdida

Cuando pierde u olvida la contraseña de root de un sistema, hay varias maneras en las
que un administrador puede restablecerla. Algunos de estos métodos pueden utilizarse de
manera remota (por ejemplo, a través de una conexión SSH), mientras que otros requieren
acceso a una consola física.
Si la cuenta root aún está registrada en un terminal desbloqueado, esa sesión puede
utilizarse para restablecer la contraseña; de manera similar, si una cuenta para la que se
conoce la contraseña tiene acceso sudo a una shell, o al comando passwd, ese acceso puede
utilizarse para restablecer la contraseña de root.
Algunos métodos un poco más complejos incluyen la edición manual del archivo /etc/
shadow con un hash de contraseña conocido de una cuenta que tiene acceso sudo a un
editor, o la edición de imágenes del disco de la máquina virtual con el comando guestfish.
Si ninguno de los métodos mencionados está disponible, habrá otros métodos a disposición.
El modo de recuperación anaconda permitirá que alguien que tiene acceso físico a una
máquina restablezca la contraseña de root (siempre y cuando el disco no esté cifrado o se
conozca la contraseña cifrada, y el firmware de BIOS/UEFI permita el arranque desde otro
dispositivo, o se conozca la contraseña de BIOS).
Restablecimiento de una contraseña de root sin

medios externos
Un método común para restablecer una contraseña de root perdida sin utilizar medios
externos involucra “descifrar” la secuencia de arranque del disco RAM inicial (initramfs). Este
método solo requiere acceso a la consola física (o acceso a una tarjeta de gestión remota o
un switch KVM) y conocer las contraseñas de cifrado de disco y contraseñas del cargador de
arranque que se utilizan.
Siga estos pasos para restablecer una contraseña de root perdida a través de este método:
1. Reinicie el sistema e interrumpa el temporizador de cuenta regresiva del cargador de

arranque al presionar cualquier tecla excepto Intro.
2. Busque la entrada que se arranca normalmente, cámbiela para detener la ejecución

durante el disco RAM inicial y proporcione una shell para el usuario.
2.1. Use las teclas del cursor para resaltar la entrada que normalmente se arrancaría y
presione e.
2.2. Use las teclas del cursor para ir a la línea que tiene el kernel y los argumentos de
kernel. Esta línea normalmente comienza con linux16 o linuxefi.
2.3. Mueva el cursor al final de la línea presionando End, y agregue rd.break.
RH342-RHEL7.2-es-1-20160321 93
nota
Las imágenes de la máquina virtual utilizadas en el aula tienen un ajuste
console= al final de la línea que configura una consola serial. Si no está
utilizando una consola serial, elimine este ajuste para que el disco RAM
inicial utilice la consola virtual regular.
2.4. Presione Ctrl+X para realizar el arranque con la estrofa modificada.
3. El sistema ahora arrancará, pero detendrá el proceso anticipadamente durante la

ejecución del disco RAM inicial. Si parece que el sistema no realiza una acción, presione
Intro; es posible que el resultado de kernel tape un mensaje.
4. Monte el sistema de archivos raíz con acceso de lectura-escritura. El sistema de archivos

se monta en /sysroot.
switch_root:/# mount -oremount,rw /sysroot
5. Cambie la raíz que funciona por el directorio /sysroot.
switch_root:/# chroot /sysroot
6. Restablezca la contraseña de root por un elemento conocido.
sh-4.2# echo redhat | passwd --stdin root
7. Corrija los problemas de SELinux. Una solución simple, pero extensa, es

touch /.autorelabel. Esto hará que el sistema realice un nuevo etiquetado de todos
los sistemas de archivos montados durante el arranque y, luego, lo reinicie. Un método
más rápido, pero más complejo, se destaca en los siguientes subpasos.
7.1. Fuerce al sistema a cargar la política de SELinux configurada actualmente.
sh-4.2# load_policy -i
7.2. Restaure todos los contextos de SELinux en /etc/.
sh-4.2# restorecon -Rv /etc
8. Reinicie el sistema al salir de la shell chroot y de la shell rd.break. Puede hacerlo al

escribir exit o al presionar Ctrl+D.
94 RH342-RHEL7.2-es-1-20160321
Restablecimiento de una contraseña de root sin medios externos
nota
Algunos administradores puede considerar que el orden de los pasos anteriores
puede ser “raro”. ¿Por qué no se carga la política de SELinux antes de ejecutar
el comando passwd? ¿Esto no ahorraría la molestia de ejecutar el comando
restorecon?
La respuesta reside en el hecho de que la política de SELinux, una vez cargada,

deshabilita el cambio de contraseñas de la shell rd.break, incluso después de
ejecutar un comando setenforce 0. Cargar la política después permite que un
administrador cambie la contraseña y corrija los contextos de SELinux sin tener que
realizar un nuevo etiquetado.
Referencias
Restablecimiento de una contraseña de root de RHEL-7/systemd
https://access.redhat.com/solutions/918283
RH342-RHEL7.2-es-1-20160321 95
Ejercicio guiado: Recuperación de una

contraseña de root
En este trabajo de laboratorio, restablecerá una contraseña de root perdida.
Recursos
• servera
Resultados
Deberá poder restablecer una contraseña de root perdida sin tener otra forma de acceso raíz
a una máquina.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab rootpw setup en su
[student@workstation ~#$ lab rootpw setup
Uno de sus estimados colegas se ha ido de su empresa. Uno de sus proyectos finales incluía
la configuración de su máquina servera. Aunque su excolega hizo un trabajo admirable en
la configuración del servidor, faltan los documentos de servera.
Uno de los datos que falta de la documentación es la contraseña de la cuenta de root de

servera. Le han pedido que restablezca esta contraseña a redhat.
Importante
Para este ejercicio, supongamos que no tiene acceso ssh sin contraseña a la cuenta
de root en servera, y que la cuenta student en servera no tiene acceso sudo
completo.
1. Abra una consola en servera y reiníciela. Diríjase al menú grub y fuerce al sistema a
pausar el arranque durante la ejecución del disco RAM inicial.
1.1. Reinicie su máquina servera desde la consola.
[root@servera ~]# reboot
1.2. Presione cualquier tecla para pausar el temporizador de cuenta regresiva del menú
grub cuando aparezca.
1.3. Resalte la entrada predeterminada y presione e para editarla.
1.4. Desplácese hacia abajo en la línea que comienza con linux16, presione End para ir
al final de la línea, elimine el último ajuste console= y anexe rd.break.
1.5. Presione Ctrl+X para realizar el arranque con estos ajustes modificados.
96 RH342-RHEL7.2-es-1-20160321
2. Cambie la contraseña de root de su sistema por redhat y asegúrese de hacerlo con
cuidado para no alterar los contextos de SELinux.
2.1. Vuelva a montar el sistema de archivos de /sysroot de solo lectura.
switch_root:/# mount -o remount,rw /sysroot
2.2. Cambie la raíz por el directorio /sysroot.
switch_root:/# chroot /sysroot
2.3. Establezca la contraseña de root en redhat.
sh-4.2# echo redhat | passwd --stdin root
2.4. Cargue la política de SELinux predeterminada. Si esto falla, asegúrese de que el

sistema realizará un nuevo etiquetado completo en el próximo reinicio.
sh-4.2# load_policy -i
Si el comando anterior falló:
sh-4.2# touch /.autorelabel
2.5. Restaure recurrentemente los contextos de SELinux en /etc.
sh-4.2# restorecon -Rv /etc
nota
Cargar la política de SELinux antes de cambiar la contraseña de root
provocará una denegación cuando intente actualizar la contraseña raíz.
En cambio, configurar la contraseña, luego cargar la política y corregir
los contextos sí funciona. Si se olvida de actualizar los contextos, ningún
usuario local podrá iniciar sesión después de un reinicio ya que habrá un
contexto de seguridad no válido en /etc/shadow.
3. Reinicie su sistema servera y compruebe que puede iniciar sesión como root con la
contraseña redhat.
3.1. Reinicie su sistema servera al presionar Ctrl+D dos veces.
sh-4.2# Ctrl+D
switch_root:/# Ctrl+D
RH342-RHEL7.2-es-1-20160321 97
Si tuvo que modificar /.autorelabel en el paso anterior, su sistema se reiniciará

dos veces; de lo contrario, solo ocurrirá un reinicio.
3.2. Intente iniciar sesión en la consola como root con la contraseña redhat.
4. En workstation, evalúe su trabajo ejecutando el comando lab rootpw grade.
[student@workstation ~]$ lab rootpw grade
98 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Solución de problemas de arranque
Trabajo de laboratorio: Solución de

problemas de arranque
En este trabajo de laboratorio, solucionará un problema donde un sistema no puede arrancar

después de la pantalla del cargador de arranque.
Recursos
• servera
Resultados
Deberá poder solucionar problemas donde un sistema no puede arrancar después del
cargador de arranque.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab bootissues setup en
su sistema workstation. Esto modificará la capacidad de su sistema servera para arrancar
y, luego, lo reiniciará.
[student@workstation ~]$ lab bootissues setup
Alguien decidió “agilizar” el proceso de arranque de su máquina servera. Al hacerlo, puso fin
a la capacidad que dicho sistema tenía para arrancar su objetivo (target) predeterminado.
Recibirá la tarea de lograr que servera pueda arrancar nuevamente.
1. Abra una consulta en su máquina servera y evalúe el problema.
2. Arranque temporalmente su sistema servera en una configuración que funciona.
3. Solucione el problema de manera permanente.
4. Evalúe su trabajo ejecutando el comando lab bootissues grade de su máquina

workstation.
[student@workstation ~]$ lab bootissues grade
ejercicios.
RH342-RHEL7.2-es-1-20160321 99
Solución
En este trabajo de laboratorio, solucionará un problema donde un sistema no puede arrancar
después de la pantalla del cargador de arranque.
Recursos
• servera
Resultados
Deberá poder solucionar problemas donde un sistema no puede arrancar después del
cargador de arranque.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab bootissues setup en
su sistema workstation. Esto modificará la capacidad de su sistema servera para arrancar
y, luego, lo reiniciará.
[student@workstation ~]$ lab bootissues setup
Alguien decidió “agilizar” el proceso de arranque de su máquina servera. Al hacerlo, puso fin
a la capacidad que dicho sistema tenía para arrancar su objetivo (target) predeterminado.
Recibirá la tarea de lograr que servera pueda arrancar nuevamente.
1. Abra una consulta en su máquina servera y evalúe el problema.
1.1. ¿Qué se muestra en la consola de servera? Si se muestra un menú grub, intente

arrancar la entrada (superior) predeterminada.
error: you need to load the kernel first
1.2. ¿Qué puede indicar esto?
Por lo general, esto indica que no hay un kernel definido en la entrada del menú, o
que se está cargando el disco RAM antes del kernel.
2. Arranque temporalmente su sistema servera en una configuración que funciona.
2.1. Aquí tiene dos opciones. Ver si arranca una segunda entrada, en este caso la entrada
de rescue, o editar manualmente la configuración en la memoria para resolver el
problema temporalmente.
2.2. Use el menú grub para arrancar la segunda entrada (rescue) (rescate).
3.1. Recree un /boot/grub2/grub.cfg que funciona a través de la lista de kernes

instalados.
[root@servera ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
100 RH342-RHEL7.2-es-1-20160321
Solución
3.2. Reinicie su máquina servera para verificar su trabajo.
4. Evalúe su trabajo ejecutando el comando lab bootissues grade de su máquina

workstation.
[student@workstation ~]$ lab bootissues grade
ejercicios.
RH342-RHEL7.2-es-1-20160321 101
Resumen
• Cómo recrear un archivo de configuración grub2.
• Cómo reinstalar grub2 en un MBR con el comando grub2-install.
• Cómo volver a configurar un sistema UEFI para que use el cargador de arranque shim de
EFI al eliminar entradas de arranque de EFI existentes a través de efibootmgr, y al reiniciar
desde el disco del sistema.
• Cómo inspeccionar y configurar dependencias de la unidad systemd a través de

systemctl list-dependencies.
• Cómo obtener una shell de root temprana al habilitar el servicio debug-shell.service,

permitiendo un diagnóstico precoz a través de systemctl list-jobs.
• Cómo recuperar una contraseña de root perdida con diversos métodos, incluido el uso de
rd.break en la línea de comandos de kernel.
102 RH342-RHEL7.2-es-1-20160321
TRAINING
CAPÍTULO 4
IDENTIFICACIÓN DE PROBLEMAS
DE HARDWARE
Visión general
Meta Identificar problemas de hardware que puedan afectar el
funcionamiento normal de un sistema.
Objetivos • Identificar el hardware y los problemas del hardware.
• Gestionar módulos de kernel y sus parámetros.
• Identificar y resolver problemas de virtualización.

Secciones • Identificación de problemas de hardware (y ejercicio
guiado)
• Administración de módulos kernel (y ejercicio guiado)
• Gestión de problemas de virtualización (y ejercicio

guiado)
Trabajo de laboratorio • Identificación de problemas de hardware
RH342-RHEL7.2-es-1-20160321 103
Capítulo 4. Identificación de problemas de hardware
Identificación de problemas de hardware
Objetivos
Tras finalizar esta sección, los estudiantes podrán identificar hardware y problemas de
hardware.
Identificación de hardware
Un paso importante en la solución de posibles problemas de hardware es saber exactamente
cuál es el hardware presente en el sistema. Para sistemas virtuales, esto parece menos útil
que para sistemas físicos, pero le puede indicar a un administrador si se han agregado los
dispositivos virtuales correctos.
Identificación de CPU
La CPU en un sistema en ejecución puede identificarse con el comando lscpu del paquete
util-linux.
[root@demo ~]# lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 60
Model name: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
Stepping: 3
CPU MHz: 3004.750
CPU max MHz: 3800.0000
CPU min MHz: 800.0000
BogoMIPS: 5587.29
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-7
Otro dato importante es cuáles son los indicadores que una CPU admite. Estos indicadores
señalan si una CPU admite ciertas tecnologías extendidas, como una aceleración AES,
virtualización asistida por hardware, y muchas más. Puede inspeccionar estos indicadores en
/proc/cpuinfo.
104 RH342-RHEL7.2-es-1-20160321
Identificación de hardware
nota
El hecho de que una CPU admita un determinado indicador no siempre significa
que la función esté disponible. Por ejemplo, el indicador vmx en una CPU Intel
señala que el procesador es capaz de admitir virtualización de hardware, pero la
función en sí puede estar deshabilitada en el firmware del sistema.
Identificación de memoria
La herramienta dmidecode puede utilizarse para recuperar información acerca de bancos
de memoria físicos, incluido el tipo, la velocidad y la ubicación del banco. Para recuperar esta
información, utilice el comando dmidecode -t memory.
[root@demo ~]# dmidecode -t memory

# dmidecode 2.12
...
Handle 0x0007, DMI type 17, 34 bytes

Memory Device
Array Handle: 0x0005
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: SODIMM
Set: None
Locator: ChannelA-DIMM1
Bank Locator: BANK 1
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MHz
Manufacturer: Hynix/Hyundai
Serial Number: 0E80EABA
Asset Tag: None
Part Number: HMT41GS6BFR8A-PB
Rank: Unknown
Configured Clock Speed: 1600 MHz
...
Identificación de discos
Para identificar discos físicos, un administrador puede usar el comando lsscsi del paquete
lsscsi. Esta herramienta puede enumerar todos los discos SCSI (y USB, SATA y SAS) adjuntados
a un sistema.
[root@demo ~]# lsscsi -v

[0:0:0:0] disk ATA SAMSUNG MZ7LN512 4L0Q /dev/sda
dir: /sys/bus/scsi/devices/0:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/
target0:0:0/0:0:0:0]
[5:0:0:0] cd/dvd HL-DT-ST DVDRAM GUB0N LV20 /dev/sr0
dir: /sys/bus/scsi/devices/5:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/
target5:0:0/5:0:0:0]
Para obtener más información, puede usar el comando hdparm del paquete hdparm en
discos individuales.
RH342-RHEL7.2-es-1-20160321 105
[root@demo ~]# hdparm -I /dev/sda

/dev/sda:
ATA device, with non-removable media

Model Number: SAMSUNG MZ7LN512HCHP-000L1
Serial Number: S1ZKNXAG806853
Firmware Revision: EMT04L0Q
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA
Rev 2.6, SATA Rev 3.0
...
Identificación de hardware PCI

Puede identificar hardware PCI adjuntado con el comando lspci. Agregar una o más
opciones -v aumentarán los detalles.
[root@demo ~]# lspci

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM
Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express
x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated
Graphics Controller (rev 06)
....
Identificación de hardware USB

Puede identificar hardware USB con el comando lsusb. Como con lspci, los detalles
pueden aumentar cuando se agregan las opciones -v.
[root@demo ~]# lsusb

Bus 003 Device 002: ID 8087:8000 Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 1058:083a Western Digital Technologies, Inc.
Bus 001 Device 009: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 008: ID 17a0:0001 Samson Technologies Corp. C01U condenser microphone
Bus 001 Device 006: ID 04f2:b39a Chicony Electronics Co., Ltd
....
Generación de informes sobre errores de hardware

Por lo general, los sistemas modernos vigilan varias deficiencias de hardware y alertan a un
administrador cuando ocurre una falla. Aunque algunas de estas soluciones son específicas
de un proveedor y requieren una tarjeta de gestión remota, otras pueden leer el SO de
manera estandarizada.
Red Hat Enterprise Linux 7 proporciona dos mecanismos para registrar fallas de hardware:
mcelog y rasdaemon.
mcelog
mcelog proporciona un framework (marco) para detectar y registrar excepciones de
comprobación de la máquina en sistemas x86. En sistemas compatibles, también puede
marcar automáticamente áreas deficientes de RAM para que no sean utilizadas.
Para instalar y habilitar mcelog, siga este procedimiento:
1. Instale el paquete mcelog.
106 RH342-RHEL7.2-es-1-20160321
Prueba de memoria
[root@demo ~]# yum install mcelog
2. Inicie y habilite el servicio mcelog.service.
[root@demo ~]# systemctl enable mcelog

[root@demo ~]# systemctl start mcelog
A partir de ahora, los errores de hardware detectados por el daemon mcelog aparecerán en
el diario (journal) del sistema. Puede consultar mensajes a través del comando journalctl
-u mcelog.service. Si el daemon abrt está instalado y activo, también se desencadenará
en varios mensajes mcelog.
De manera alternativa, para los administradores que no desean ejecutar un servicio

separado, se configura un cron, pero se convierte en comentario, en /etc/cron.hourly/
mcelog.cron que volcará eventos en /var/log/mcelog.
rasdaemon
rasdaemon es un reemplazo más moderno para mcelog que se conecta al subsistema de
detección del kernel. RAS significa fiabilidad, disponibilidad y facilidad de servicio (Reliability,
Availability, and Serviceability). rasdaemon se conecta al mecanismo de Detección y corrección
de errores (EDAC, Error Detection And Correction) para los módulos DIMM y los informa al
espacio del usuario, y también a los mensajes RAS que vienen del subsistema de detección
del kernel.
Para habilitar rasdaemon, siga estos pasos:
1. Instale el paquete rasdaemon.
[root@demo ~]# yum install rasdaemon
2. Inicie y habilite el servicio rasdaemon.service.
[root@demo ~]# systemctl enable rasdaemon

[root@demo ~]# systemctl start rasdaemon
Puede consultar información acerca de varios bancos de memoria a través de la herramienta

ras-mc-ctl. De especial interés son ras-mc-ctl --status para mostrar el estado actual y
ras-mc-ctl --errors para ver los errores registrados.
nota
Si no se registraron errores ni eventos, puede aparecer un mensaje de error
en el que se indique que falta una base de datos cuando ejecuta los comandos
anteriores.
Prueba de memoria
Cuando se presume que hay un error de memoria física, un administrador debe ejecutar una
prueba de memoria exhaustiva. En estos casos, se puede instalar el paquete memtest86+.
RH342-RHEL7.2-es-1-20160321 107
Dado que la prueba de memoria en un sistema real no es ideal, el paquete memtest86+

instalará una entrada de arranque separada que ejecute memtest86+ en lugar de un kernel
regular de Linux. En los siguientes pasos se indica cómo habilitar esta entrada de arranque.
1. Instale el paquete memtest86+; esto instalará la aplicación memtest86+ en /boot.
[root@demo ~]# yum install memtest86+
2. Ejecute el comando memtest-setup. Esto agregará una nueva plantilla en /etc/

grub.d/ para habilitar memtest86+.
[root@demo ~]# memtest-setup
3. Actualice la configuración del cargador de arranque de grub2.
[root@demo ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
Referencias
RHEL7: ¿Cuál de mcelog y rasdaemon debería usar para monitorear hardware, y
para qué casos de uso?
La sección de revisión de errores de hardware en la Guía para administradores de

sistemas de RHEL7 en https://access.redhat.com/docs.
108 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Identificación de problemas de hardware
Ejercicio guiado: Identificación de problemas

de hardware
En este trabajo de laboratorio, identificará un posible problema con la memoria de una

máquina.
Recursos
Resultados
Deberá poder identificar problemas de hardware con entradas de diario (journal).
Andes de comenzar
En su sistema workstation, ejecute el comando lab hardwareissues setup para
preparar su sistema servera para este ejercicio.
[student@workstation ~]$ lab hardwareissues setup
Uno de sus administradores junior le proporcionó un vaciado de texto de un archivo del

diario (journal) systemd-journald desde una máquina que ha estado teniendo errores
aleatorios y extraños. Le ha pedido que inspeccione el diario (journal) en busca de posibles
señales de fallas en el hardware debido a que la máquina seguía teniendo estos problemas
incluso después de una limpieza y reinstalación.
Este archivo está disponible en su máquina servera como /root/logdump.
1. Inspeccione el archivo de registro que recibió en servera e intente encontrar errores de

hardware.
1.1. Inspeccione el archivo, verifique que tiene permiso de lectura y que es un archivo de
registro.
[root@servera ~]# less /root/logdump
1.2. Limite su vista a los eventos que se generan a partir del servicio mcelog.service.
¿Esto proporciona información relevante?
[root@servera ~]# grep mcelog /root/logdump | less
Las siguientes líneas, y todas sus repeticiones, parecen indicar un problema de

memoria:
Dec 03 12:22:41 ouch.example.com mcelog[1037]: MCA: MEMORY CONTROLLER

RD_CHANNEL1_ERR
Dec 03 12:22:41 ouch.example.com mcelog[1037]: Transaction: Memory read error
Dec 03 12:22:41 ouch.example.com mcelog[1037]: STATUS 8c00004000010091 MCGSTATUS
0
Dec 03 12:22:41 ouch.example.com mcelog[1037]: MCGCAP 1000c1d APICID 20 SOCKETID
1
RH342-RHEL7.2-es-1-20160321 109
Dec 03 12:22:41 ouch.example.com mcelog[1037]: CPUID Vendor Intel Family 6 Model

62
Dec 03 12:22:41 ouch.example.com mcelog[1037]: Hardware event. This is not a
software error.
2. Dado que la máquina parece tener un problema de memoria, ha decidido ejecutar una
comprobación de memoria exhaustiva en ella. Pretenda que servera es la máquina en
cuestión y prepárela para ejecutar memtest86+.
Importante
No se recomienda ejecutar memtest86+ en una máquina virtual fuera del aula.
En circunstancias normales, memtest86+ debe ejecutarse en una máquina
hipervisor.
2.1. Instale el paquete memtest86+ en su máquina servera.
[root@servera ~]# yum install memtest86+
2.2. Ejecute el comando memtest-setup para agregar una nueva plantilla a /etc/
grub.d/
[root@servera ~]# memtest-setup
2.3. Genere una nueva configuración grub2 que incluya memtest86+.
[root@servera ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
3. Reinicie servera y seleccione memtest86+ desde el menú grub2. Déjelo ejecutar por
unos segundos, explore algunas de las opciones y, luego, reinicie Red Hat Enterprise
Linux 7.
4. Verifique su trabajo ejecutando el comando lab hardwareissues grade en su

sistema workstation.
[student@workstation ~]$ lab hardwareissues grade
110 RH342-RHEL7.2-es-1-20160321
Administración de los módulos del kernel
Objetivos
Tras finalizar esta sección, los estudiantes deberán ser capaces de administrar módulos del
kernel y sus parámetros.

El kernel de Linux tiene grandes partes de su funcionalidad divididas en módulos, pequeños
fragmentos de código que se pueden cargar y descargar a voluntad. Esto ayuda a que la
imagen base del kernel sea más pequeña, para que solo se cargue en la memoria el código
que es realmente necesario.
La mayoría de los controladores de dispositivo está divida en módulos del kernel,

pero también en controladores del sistema de archivos, algoritmos de cifrado y otras
partes del kernel. En el disco, estos módulos pueden encontrarse en el directorio /lib/
modules/<KERNEL_VERSION>/. Todos los módulos cargables tienen un nombre de archivo
que finaliza en .ko.
Aparte de sus nombres regulares, los módulos del controlador del dispositivo también
tienen alias incorporados, como usb:v0421p0434d0100dc*dsc*dp*ic*isc*ip*in*
o pci:v00008086d0000162Bsv*sd*bc03sc*i*. Estos alias permiten que el kernel
cargue automáticamente los controladores de hardware necesarios en función de los ID de
dispositivo y de los proveedores de USB o PCI.
Visualización de módulos cargados

Se puede utilizar el comando lsmod para ver una lista de módulos cargados actualmente. El
resultado contiene cuatro columnas: el nombre del módulo cargado, su tamaño en bytes, la
cantidad de veces que este módulo es utilizado por otro módulo y, opcionalmente, la lista de
otros módulos que utilizan este módulo.
Carga y descarga de módulos

Aunque a un nivel bajo, los comandos insmod y rmmod se utilizan para cargar y descargar
módulos, respectivamente; un administrador nunca debe utilizarlos directamente. En cambio,
los administradores deben utilizar el comando modprobe y el comando modprobe -r. Esta
herramienta de contenedor maneja cualquier dependencia del módulo que exista y utilizará
los archivos de configuración del módulo en /etc/modprobe.d/ para cualquier opción o
alias.
Al agregar la opción -v a un comando modprobe, se mostrarán los comandos insmod y

rmmod que están siendo utilizados.
nota
Los códigos de salida para el comando modprobe no reflejan si una acción se realizó
correctamente o no, sino que reflejan si se logró el resultado final deseado. Por
ejemplo, cuando carga un módulo que ya está cargado, devolverá 0, aunque no se
haya realizado ninguna acción.
RH342-RHEL7.2-es-1-20160321 111
Opciones de módulo
Muchos módulos del kernel pueden adoptar opciones, alternando la manera en que se
comportan. Estos parámetros se exponen de dos maneras, mediante el uso del comando
modinfo -p y en el sistema de archivos virtual /sys/module.
A través de modinfo -p <MODULE>, un administrador puede ver una lista de opciones

compatibles para un módulo. Por ejemplo:
[root@demo ~]# modinfo -p st

buffer_kbs:Default driver buffer size for fixed block mode (KB; 32) (int)
max_sg_segs:Maximum number of scatter/gather segments to use (256) (int)
try_direct_io:Try direct I/O between user buffer and tape drive (1) (int)
debug_flag:Enable DEBUG, same as setting debugging=1 (int)
try_rdio:Try direct read i/o when possible (int)
try_wdio:Try direct write i/o when possible (int)
Esto enumera el nombre de la opción, la descripción de la opción y el tipo de valor (entero,

booleano, cadena, etc.). A menudo, hay una descripción más detallada de estas opciones y
sus posibles valores en los archivos de documentos especializados en el paquete kernel-doc.
Otro método de trabajar con opciones de módulo es a través del directorio /sys/module/.
La mayoría de los módulos con opciones las mostrará en un directorio denominado /sys/
module/<MODULENAME>/parameters, donde las opciones individuales se convierten en
archivos separados. Si una opción se puede modificar en el tiempo de ejecución, el archivo
correspondiente tendrá permiso de escritura para root. Si solo puede configurar una opción
en el momento de carga del módulo, el archivo correspondiente será de solo lectura.
Gestión de las opciones de módulo

Para establecer una opción de módulo cuando se carga el módulo con modprobe, es
suficiente agregar solo name=value al comando modprobe. Por ejemplo, para establecer la
opción buffer_kbs para el módulo st en 64, se puede usar el siguiente comando:
[root@demo ~]# modprobe -v st buffer_kbs=64

insmod /lib/modules/3.10.0-327.el7.x86_64/kernel/drivers/scsi/st.ko buffer_kbs=64
Para establecer automáticamente esta opción cada vez que se carga este módulo, incluso
cuando se carga automáticamente, se puede usar un archivo de configuración en /etc/
modprobe.d/. Este archivo deberá tener un nombre de archivo que finalice en .conf, y los
archivos se analizarán en orden alfanumérico. Las opciones se agregan con una línea de
opciones como la que se muestra a continuación:
options st buffer_kbs=64 max_sg_segs=512
Se recomienda agrupar las opciones en archivos que correspondan a su módulo, por ejemplo
/etc/modprobe.d/st.conf, o en archivos relacionados a una función, por ejemplo, /etc/
modprobe.d/throughput.conf.
112 RH342-RHEL7.2-es-1-20160321
Referencias
El capítulo sobre trabajar con módulos de kernel en la Guía para administradores de
sistemas Red Hat Enterprise Linux 7 en https://access.redhat.com/docs.
Páginas del manual: lsmod(8) y modprobe(8).
RH342-RHEL7.2-es-1-20160321 113
Ejercicio guiado: Administración de módulos

del kernel
En este trabajo de laboratorio, configurará parámetros para un módulo del kernel.
Recursos
• workstation
Resultados
Deberá poder configurar opciones de módulo para módulos de kernel cargables.
Su sistema servera tiene un arreglo SAS RAID adjuntada al módulo de kernel

megaraid_sas.ko. Desafortunadamente, el rendimiento ha estado impredecible, y a veces
aparecen mensajes de error con respecto a interrupciones de MSI-X en sus registros.
Después de abrir un caso de soporte, ha recibido la instrucción de deshabilitar el manejo de

interrupciones de MSI-X en el controlador para ver si esto soluciona el problema.
1. Vea la lista de posibles opciones de módulo del kernel para el módulo del kernel
megaraid_sas.ko, busque la opción que corresponda al manejo de interrupciones de
MSI-X, cargue el módulo y verifique que el valor predeterminado indicado esté en efecto
aplicado. A continuación, descargue el módulo.
1.1. Vea las opciones del módulo de kernel megaraid_sas.ko:
[root@servera ~]# modinfo -p megaraid_sas
1.2. Busque la opción que corresponde al manejo de interrupciones de MSI-X.
[root@servera ~]# modinfo -p megaraid_sas | grep -i msi

msix_disable:Disable MSI-X interrupt handling. Default: 0 (int)
msix_vectors:MSI-X max vector count. Default: Set by FW (int)
De estos dos, msix_disable parece ser la opción que se necesita.
1.3. Cargue el módulo del kernel megaraid_sas.ko manualmente.
[root@servera ~]# modprobe -v megaraid_sas
1.4. Verifique que el valor predeterminado indicado (0) para la opción msix_disable
sea realmente el valor activo.
[root@servera ~]# cat /sys/module/megaraid_sas/parameters/msix_disable

0
1.5. Cargue el módulo megaraid_sas.ko.
114 RH342-RHEL7.2-es-1-20160321
[root@servera ~]# modprobe -rv megaraid_sas
2. Configure el módulo megaraid_sas.ko para que utilice siempre el ajuste

msix_disable=1. Esta opción debe aplicarse cuando el módulo se carga manualmente,
así como también cuando el módulo se carga automáticamente.
Esta configuración debería ser fácil de copiar a otros sistemas, por lo que es necesario un
archivo de configuración independiente.
Verifique que su nueva configuración funcione como pretende.
2.1. Cree un nuevo archivo denominado /etc/modprobe.d/megaraid.conf con el

siguiente contenido:
options megaraid_sas msix_disable=1
2.2. Cargue el módulo del kernel megaraid_sas.ko.
[root@servera ~]# modprobe -v megaraid_sas
2.3. Verifique que su nueva configuración se haya aplicado correctamente.
[root@servera ~]# cat /sys/module/megaraid_sas/parameters/msix_disable

1
3. Evalúe su trabajo ejecutando el comando lab kernelmodules grade en su sistema

workstation.
[student@workstation ~]$ lab kernelmodules grade
4. Limpie su trabajo al ejecutar el comando lab kernelmodules reset en su sistema

workstation.
[student@workstation ~]$ lab kernelmodules reset
RH342-RHEL7.2-es-1-20160321 115
Gestión de problemas de virtualización
Objetivos
Después de completar esta sección, los estudiantes podrán identificar y resolver problemas
de virtualización.
Problemas de virtualización
Cuando ejecuta (varias) máquinas virtuales con KVM y libvirt, pueden surgir diversos
problemas. Algunos están relacionados con hardware/firmware; otros pueden estar
relacionados meramente con software/configuración. En esta sección, se identifican varios
problemas posibles, sus síntomas y sus soluciones.
Soporte de virtualización de hardware

KVM requiere soporte de virtualización de hardware en la CPU y en el firmware del sistema
(BIOS/UEFI). Puede consultar el soporte de la CPU para KVM en la sección flags (indicadores)
de /proc/cpuinfo. Para máquinas Intel, el indicador vmx debería estar disponible, y para las
máquinas AMD, el indicador svm debería estar disponible.
Si el indicador de virtualización requerido está disponible, puede probar la compatibilidad

de KVM al cargar el módulo de kernel kvm-intel o kvm-amd manualmente. Si el módulo se
carga sin errores, o si ya está cargado, la compatibilidad con la virtualización de hardware
debería estar disponible. Si la carga del módulo produce un error con el siguiente mensaje,
significa que la CPU no es compatible con la virtualización de hardware o que la función está
deshabilitada en el firmware del sistema:
[root@demo ~]# modprobe -v kvm-intel

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported
También puede verificar la compatibilidad con la virtualización de hardware con el comando

virsh capabilities; esto mostrará todos los tipos posibles de máquinas virtuales que
pueden ejecutarse.
[root@demo ~]# virsh capabilities

<host>
....
</host>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine canonical='pc-i440fx-2.3' maxCpus='255'>pc</machine>
....
<machine maxCpus='255'>pc-0.13</machine>
<domain type='qemu'/>
<domain type='kvm'>
<emulator>/usr/bin/qemu-kvm</emulator>
<machine canonical='pc-i440fx-2.3' maxCpus='255'>pc</machine>
....
116 RH342-RHEL7.2-es-1-20160321
Recursos sobreutilizados
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
<disksnapshot default='on' toggle='no'/>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
</features>
</guest>
</capabilities>
Esto indica el tipo de hardware que se virtualizará; en este caso, una máquina x86 de 64
bits. El resultado contendrá varios de estos bloques en algunos casos; por ejemplo, se
pueden emular las máquinas virtuales de 32 bits y 64 bits.
Este bloque indica que este tipo de máquina se puede emular con una CPU con software
qemu. La emulación es mucho más lenta que una virtualización de hardware completa,
en función de la magnitud.
Este bloque indica compatibilidad con la virtualización de hardware a través de KVM.
Si falta, este tipo de máquina no puede virtualizarse en hardware, pero requiere una
emulación.
Importante
Si la virtualización de hardware no está disponible, y no se puede activar en el
firmware del sistema, las máquinas virtualizadas se ejecutarán en un procesador
emulado, que es más lento que una CPU virtualizada por hardware.
Recursos sobreutilizados
libvirt permite que los administradores asignen más recursos virtuales a las máquinas
virtuales que los que realmente están disponibles en el sistema host. En la mayoría de los
casos, esta acción no tiene consecuencias (hasta cierto grado). El uso típico de la CPU de una
máquina virtual no alcanza el 100 %, por lo que asignar más CPU virtuales que la cantidad
de núcleos físicos no es un problema, siempre y cuando el uso de CPU de la máquina virtual
se mantenga dentro de los límites. La memoria se puede sobreutilizar, y la memoria de
la máquina virtual puede intercambiarse en el disco, o el uso ser comprimido por Kernel
Samepage Merging (KSM), donde las páginas de memoria duplicadas se reducen a una única
página y se dividen nuevamente cuando una máquina virtual escribe en ella. Las imágenes
dispersas en el disco pueden tener un tamaño total superior al espacio disponible real en el
almacenamiento subyacente, siempre y cuando el tamaño utilizado total no supere el espacio
disponible real en el almacenamiento host.
Todos estos tipos de sobreutilización no deberían tener un impacto en el rendimiento general

de las máquinas virtuales en ejecución, hasta que se sobrecarga un recurso; por ejemplo,
cuando varias máquinas virtuales comienzan a utilizar todas sus CPU virtuales al 100 %, todas
las máquinas virtuales sentirán el aumento de utilización dado que las máquinas virtuales
ahora tienen que competir por la CPU.
Cuando los recursos son escasos, el rendimiento y la latencia generales pueden verse
afectados considerablemente. El host no solo necesita balancear los recursos disponibles
entre las diferentes máquinas virtuales, también necesita utilizar algunos de estos mismos
recursos para realizar el balanceo.
RH342-RHEL7.2-es-1-20160321 117
Visualización del uso de recursos

Debido a que las máquinas virtuales de KVM aparecen como procesos regulares en el host,
puede utilizar herramientas de métricas de rendimiento normales, como top, para ver
el uso de los recursos. También hay herramientas más especializadas disponibles en la
forma de virt-manager y varios subcomandos virsh, como virsh nodecpustats, virsh
nodememstats y virsh dommemstats <DOMAIN>.
Varias herramientas de monitoreo, como collectd y cockpit, también tienen complementos

(plug-ins) para monitorear el uso de recursos de las máquinas virtuales.
Trabajar con recursos escasos

Hay varias soluciones que puede utilizar para luchar contra recursos escasos. La primera es
agregar más recursos, ya sea en la forma de más memoria, CPU, disco, etc., o al agregar más
hosts de hipervisor y desplegarlos en las máquinas virtuales.
Otra opción es limitar el uso de recursos de varias máquinas virtuales, ya sea al reducir la
cantidad de recursos asignados a las máquinas o al imponer límites a través de cgroups.
Una tercera opción es detener las máquinas innecesarias o que no son críticas hasta que
disminuya nuevamente el uso de recursos.
Configuración XML de libvirt

libvirt almacena definiciones de máquina virtual (y otras configuraciones) como XML. Puede
validar estos archivos XML a través de los esquemas Relax NG almacenados en /usr/share/
libvirt/schemas.
Si solo se han utilizado herramientas libvirt, como virsh y virt-manager, para realizar
actualizaciones, todos los archivos deberían ser XML válidos y deberían validarse sobre
los archivos de esquema proporcionados. Pero, si un administrador ha realizado cambios
manuales en cualquiera de los archivos de /etc/libvirt/, es posible que se hayan
incorporado problemas.
Una manera simple de comprobar si un archivo es un XML válido que se valida sobre el
esquema libvirt, requiere dos pasos:
1. Primero, asegurarse de que el archivo es un XML válido. Para ello, se puede utilizar la
herramienta xmllint.
[root@demo ~]# xmllint --noout <FILENAME>
Por lo general, los errores informados por xmllint deberían ordenarse de manera
descendente, ya que los primeros errores pueden causar un número considerable de
falsos negativos más adelante.
2. Después de que se comprueba que el archivo es un XML bien estructurado, se puede

validar para cumplir con el esquema a través de la herramienta virt-xml-validate.
Esta herramienta intentará analizar el XML para descubrir el tipo de configuración que
tiene y, luego, lo validará contra el esquema correcto.
[root@demo ~]# virt-xml-validate <FILENAME>
118 RH342-RHEL7.2-es-1-20160321
Redes libvirt
Redes libvirt
Para proporcionar redes virtuales a máquinas virtuales, libvirt utiliza puentes por software.
Estos puentes actúan como switches virtuales que conectan todas las interfaces de red
(virtual) que tienen asignados.
Estas redes están definidas en archivos de /etc/libvirt/qemu/networks/, y pueden

configurarse para iniciar automáticamente con un enlace simbólico en /etc/libvirt/
qemu/networks/autostart/. Por lo general, estos archivos no se deben editar
manualmente, sino con herramientas como virsh o virt-manager.
Aparte de las redes virtuales creadas por libvirt, los administradores también pueden
configurar puentes regulares con una o más interfaces de red físicas asignadas a través de
NetworkManager.
Problemas con las redes virtuales

Si las redes de máquinas virtuales no están funcionando, o no están funcionando de la
manera prevista, puede haber una variedad de problemas en juego:
No se puede acceder a la máquina virtual desde fuera

Si no se puede conectar a una máquina virtual desde fuera de la máquina de hipervisor,
puede haber una variedad de problemas en juego: la red virtual puede ser del tipo
NAT; un firewall en el hipervisor, o en la máquina virtual, puede estar bloqueando las
conexiones; o la máquina cliente puede no tener una ruta definida para llegar a la
máquina virtual.
No se puede acceder al mundo exterior desde la máquina virtual

Si la máquina virtual no puede conectarse con el mundo exterior, también puede haber
una variedad de problemas presente. La red virtual puede ser del tipo aislado, o una
regla de firewall en el hipervisor puede estar bloqueando conexiones de salida.
Problemas de conexión en ambas direcciones

Para permitir que el tráfico de red en redes virtuales del tipo NAT y enrutadas, libvirt
crea reglas de firewall a través de iptables. Si un administrador elimina todas las reglas
de firewall o agrega reglas de bloqueo en las cadenas, esto puede interrumpir el tráfico
regular de la red hacia y desde máquinas virtuales. Por lo general, estos problemas se
resuelven al reiniciar la unidad libvirtd.service systemd o al reiniciar las redes
libvirt individuales que contenían el error.
Referencias
El capítulo sobre configuración de redes en la Guía de implementación y
administración de virtualización de Red Hat Enterprise Linux disponible en
https://access.redhat.com/docs.
El capítulo sobre puentes de red en la Guía de redes de Red Hat Enterprise Linux
disponible en https://access.redhat.com/docs.
RH342-RHEL7.2-es-1-20160321 119
Ejercicio guiado: Gestión de problemas de

virtualización
En este trabajo de laboratorio, solucionará una especificación XML de dominio no válida para
una máquina virtual.
Recursos
Archivos /root/somemachine.xml
Resultados
Deberá poder solucionar un archivo XML de dominio libvirt dañado.
Andes de comenzar
En su sistema workstation, ejecute el comando lab vmxml setup.
[student@workstation ~]$ lab vmxml setup
Uno de sus colegas ha estado teniendo problemas para importar una máquina
virtual en su sistema workstation. Esta máquina virtual está definida en el archivo
/root/somemachine.xml, pero si intenta importarla con virsh define /root/
somemachine.xml, se devuelven errores acerca de un archivo XML dañado.
Le han pedido que investigue, y solucione, este problema.
Importante: A efectos de este ejercicio, la máquina virtual solo necesita definirse, no iniciarse.
Las imágenes del disco a las que se hace referencia en la definición de la máquina virtual no
existen, y no necesitan ser creadas.
1. Comience por recrear el problema. Tome nota de los errores e intente interpretarlos.
1.1. Intente definir la máquina virtual a través del archivo proporcionado.
[root@workstation ~]# virsh define somemachine.xml

error: Failed to define machine from somemachine.xml
error: (domain_definition):20: Opening and ending tag mismatch: acpi line 17 and
features
</features>
-------------^
1.2. El primer error, Failed to define domain (No se pudo definir el

dominio), indica que la operación no se completó correctamente.
El segundo error, Opening and ending tag mismatch (Discrepancia de

etiqueta inicial y final), indica que el XML de somemachine está dañado.
2. Use xmllint para verificar el XML en somemachine.xml, luego corrija los errores.
2.1. Use xmllint para verificar somemachine.xml. Recuerde que el primer error que se
informa puede tener un efecto dominó; por esto, le recomendamos corregir un error
a la vez, comenzando por el primer error informado por xmllint.
120 RH342-RHEL7.2-es-1-20160321
[root@workstation ~]# xmllint somemachine.xml
Parece que hay una etiqueta <acpi> faltante en o cerca de la línea 20.
2.2. Con el editor de su elección, cambie la línea 17 de somemachine.xml a:
<acpi/>
2.3. Repita los dos pasos anteriores, esta vez cambiando la línea 87 para incluir una
comilla de cierre:
<memballoon model='virtio'>
2.4. Ejecute el comando xmllint nuevamente para verificar que no haya más problemas
de XML pendientes.
[root@workstation ~]# xmllint somemachine.xml
3. Verifique que el archivo somemachine.xml ahora se adhiere al esquema XML libvirt.
[root@workstation ~]# virt-xml-validate somemachine.xml

somemachine.xml validates
4. Defina una máquina virtual a través del archivo somemachine.xml.
[root@workstation ~]# virsh define somemachine.xml

Domain somemachine defined from somemachine.xml
5. Verifique su trabajo ejecutando el comando lab vmxml grade en workstation.
[student@workstation ~]$ lab vmxml grade
6. Limpie su máquina workstation ejecutando el comando lab vmxml reset.
[student@workstation ~]$ lab vmxml reset
RH342-RHEL7.2-es-1-20160321 121
Trabajo de laboratorio: Identificación de

problemas de hardware
En este trabajo de laboratorio, configurará opciones para el módulo del kernel usb-storage.
Recursos
Máquinas servera
Resultados
Deberá poder configurar una opción de módulo para el controlador usb-storage.
Andes de comenzar
Asegúrese de que su sistema servera esté funcionando. Si es necesario, reinicie su sistema
servera.
Su máquina servera ha estado teniendo problemas con un dispositivo de almacenamiento

extraíble que utiliza el controlador usb-storage. Después de algunas pruebas (y
búsquedas en Internet), usted y sus colegas han determinado que su dispositivo informa
incorrectamente que está protegido contra escritura.
El ID del proveedor de USB para este dispositivo es 0513 y el ID de dispositivo es 0132.
Puede encontrar documentación para la opción de módulo usb-storage en el archivo

kernel-parameters.txt del paquete kernel-doc.
Le han pedido que configure servera de manera tal que el módulo usb-storage ignore el
modo de protección contra escritura de ese dispositivo.
1. Instale el paquete kernel-doc y busque opciones relacionadas a usb-storage en el

archivo kernel-parameters.txt.
2. Cree una configuración permanente para habilitar siempre el indicador que se encuentra
en el paso anterior para el dispositivo USB con ID de proveedor 0513 e ID de producto
0132.
3. Evalúe su trabajo ejecutando el comando lab hardwarelab grade en su sistema

workstation.
[student@workstation ~]$ lab hardwarelab grade
ejercicios.
122 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, configurará opciones para el módulo del kernel usb-storage.
Recursos
Máquinas servera
Resultados
Deberá poder configurar una opción de módulo para el controlador usb-storage.
Andes de comenzar
Asegúrese de que su sistema servera esté funcionando. Si es necesario, reinicie su sistema
servera.
Su máquina servera ha estado teniendo problemas con un dispositivo de almacenamiento

extraíble que utiliza el controlador usb-storage. Después de algunas pruebas (y
búsquedas en Internet), usted y sus colegas han determinado que su dispositivo informa
incorrectamente que está protegido contra escritura.
El ID del proveedor de USB para este dispositivo es 0513 y el ID de dispositivo es 0132.
Puede encontrar documentación para la opción de módulo usb-storage en el archivo

kernel-parameters.txt del paquete kernel-doc.
Le han pedido que configure servera de manera tal que el módulo usb-storage ignore el
modo de protección contra escritura de ese dispositivo.
1. Instale el paquete kernel-doc y busque opciones relacionadas a usb-storage en el

archivo kernel-parameters.txt.
1.1. Instale el paquete kernel-doc.
[root@servera ~]# yum -y install kernel-doc
1.2. Abra el archivo /usr/share/doc/kernel-doc*/Documentation/kernel-

parameters.txt y busque usb-storage. ¿Qué parámetro podría ser útil, y qué
indicador debe utilizarse?
El parámetro quirks parece interesante, con el indicador w (NO_WP_DETECT)

agregado.
2. Cree una configuración permanente para habilitar siempre el indicador que se encuentra
en el paso anterior para el dispositivo USB con ID de proveedor 0513 e ID de producto
0132.
2.1. Cree un nuevo archivo denominado /etc/modprobe.d/usb-storage.conf con el

siguiente contenido:
options usb-storage quirks=0513:0132:w
3. Evalúe su trabajo ejecutando el comando lab hardwarelab grade en su sistema

workstation.
RH342-RHEL7.2-es-1-20160321 123
[student@workstation ~]$ lab hardwarelab grade
ejercicios.
124 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
• Cómo identificar CPU que utilizan el comando lscpu.
• Cómo identificar hardware que utiliza lsusb y lspci.
• Cómo identificar bancos de memoria con dmidecode -t memory.
• Cómo identificar discos duros con hdparm -I.
• Como iniciar y habilitar el servicio mcelog.service para recopilar registros cuando falla el
hardware.
• Como iniciar y habilitar rasdaemon.service para recopilar registros cuando falla el

hardware.
• Los tres pasos para habilitar memtest86+: Instale el paquete memtest86+, ejecute
memtest-setup y grub2-mkconfig -o /boot/grub2/grub.cfg.
• Cómo utilizar lsmod para ver los módulos de kernel cargados.
• Cómo utilizar modprobe y modprobe -r para cargar y descargar módulos de kernel.
• Cómo crear archivos en /etc/modprobe.d/ para habilitar persistentemente opciones de

módulo del kernel.
• Cómo identificar si una máquina admite la virtualización de hardware con virsh

capabilities.
• Cómo validar un archivo de configuración libvirt con xmllint y virt-xml-validate.
RH342-RHEL7.2-es-1-20160321 125
126
TRAINING
CAPÍTULO 5
ALMACENAMIENTO
Visión general
Meta Identificar y solucionar los problemas relacionados con el
almacenamiento.
Objetivos • Describir las funciones de las capas de la stack (pila) de
almacenamiento.
• Recuperar sistemas de archivos dañados.
• Recuperar configuraciones de gestión de volúmenes

lógicos (LVM) dañadas.
• Recuperar datos de sistemas de archivos cifrados.
• Identificar y solucionar problemas de iSCSI.

Secciones • Orientación sobre la stack (pila) de almacenamiento de
Linux
• Recuperación de archivos dañados del sistema (y

ejercicio guiado)
• Recuperación de accidentes de LVM (y ejercicio guiado)
• Tratamiento de problemas de LUKS (y ejercicio guiado)
• Resolución de problemas de iSCSI (y ejercicio guiado)

Trabajo de laboratorio • Solución de problemas de almacenamiento
RH342-RHEL7.2-es-1-20160321 127
Capítulo 5. Solución de problemas de almacenamiento
Orientación sobre la stack (pila) de

almacenamiento de Linux
Objetivos
Después de completar esta sección, los estudiantes podrán describir las capas del
subsistema de almacenamiento de Linux, explicar la función de cada capa e identificar
algunas herramientas que pueden utilizarse para examinar las actividades de las diferentes
capas.
La pila de almacenamiento de Linux

Para resolver problemas de almacenamiento en Red Hat Enterprise Linux, primero debe
comprender cómo se pasa la E/S desde aplicaciones a través de la pila de almacenamiento de
Linux hasta los dispositivos de almacenamiento.
Las aplicaciones leen y escriben desde el almacenamiento mediante el envío de llamadas

estandarizadas del sistema al kernel. El kernel procesa estas llamadas del sistema a través
de la pila de almacenamiento, varias capas de software y hardware, para asegurarse de que
los datos de la aplicación se almacenen correctamente y se pueda acceder a ellos en el
dispositivo de almacenamiento de hardware. La pila de almacenamiento permite que los
programadores de la aplicación accedan a datos en una manera estandarizada mientras se
deshacen del trabajo de escribir códigos para interactuar con implementaciones específicas
del sistema de archivos y dispositivos de almacenamiento para los programadores de
kernel. La pila de almacenamiento también proporciona varias funciones para mejorar el
rendimiento y la confiabilidad de las operaciones de E/S.
En esta sección se observarán varias capas de la pila de almacenamiento de Linux. Toda la

pila de almacenamiento de Linux puede estar representada por el siguiente diagrama:
128 RH342-RHEL7.2-es-1-20160321
El sistema de archivos virtual (VFS)
Figura 5.1: La pila de almacenamiento de Linux
El sistema de archivos virtual (VFS)

El sistema de archivos virtual (VFS) proporciona soporte para las llamadas del sistema
POSIX estándar que las aplicaciones usan para leer y escribir archivos. Implementa un
modelo de archivo común para que las aplicaciones puedan utilizar las mismas llamadas del
sistema, como creat(), open(), read(), write() y mmap(), para acceder a archivos sin la
necesidad de tratar con detalles de la implementación del sistema de archivos subyacente.
Esto significa que un usuario puede trabajar con archivos almacenados en diferentes
sistemas de archivos sin la necesidad de volver a escribir sus aplicaciones o herramientas
como cp o mv para admitir el nuevo sistema de archivos, siempre y cuando esos programas
usen el modelo de archivo común cuando trabajan con archivos.
A su vez, se pueden conectar implementaciones específicas del sistema de archivos, como

XFS, ext4, FAT32, etc., en VFS como módulos de código para poder utilizar el modelo de
archivo común para acceder a datos ubicados en el almacenamiento mediante estos
sistemas de archivos.
Por ejemplo, las aplicaciones de Linux suponen que los directorios pueden manejarse
como archivos. Los diferentes sistemas de archivos almacenan datos de directorio en
diferentes maneras. VFS se asegura de que las aplicaciones puedan tratar a los directorios
como archivos mientras trabajan con el código del sistema de archivos para gestionar
correctamente la verdadera implementación de directorios en ese sistema de archivos.
VFS también conserva varias cachés para mejorar el rendimiento de E/S del almacenamiento:
la caché de inodo, la caché de entrada de directorio, la caché de búfer y la caché de
RH342-RHEL7.2-es-1-20160321 129
página. De estas, la más importante es la caché de página. La caché de página se asigna

dinámicamente desde la memoria libre del sistema y se utiliza para almacenar páginas de
datos en caché desde archivos que están siendo leídos o escritos. A partir del kernel de Linux
2.4, la caché de búfer que almacena bloques del disco en caché se unifica principalmente
con la caché de página, con la excepción de una pequeña y poco importante cantidad de
datos que no está respaldada en los archivos (para E/S de bloques sin formato o metadatos).
La caché de inodo y la caché de entrada de directorio se utilizan para acelerar el acceso a
inodos (metadatos de archivos) y entradas de directorio, respectivamente, y se realiza un
seguimiento del uso de memoria de esas cachés en /proc/slabinfo.
La E/S directa (O_DIRECT) puede ser utilizada por aplicaciones que implementan su propia
caché, como algunas bases de datos, para evitar la caché de página. Por lo general, esto
se lleva a cabo si la aplicación es el único proceso que trabaja con un archivo y puede
hacer un mejor trabajo en administrar activamente su caché que lo que haría el sistema
automáticamente. Si se lleva a cabo de manera incorrecta o si otros procesos acceden al
archivo a través de la caché de página, es posible que se generen daños u otros problemas.
Hay varias restricciones y condiciones importantes en la E/S directa que no se debatirán en
este documento.
Herramientas de VFS
Por lo general, los problemas de esta capa están relacionados a problemas de rendimiento
debido a falta de memoria que limita la caché o a errores de ajuste de sysctl. Para obtener
un resumen del uso de la caché, puede ejecutar el comando free para ver un resumen
básico o cat /proc/meminfo para obtener información más detallada.
[root@demo ~]# cat /proc/meminfo

MemTotal: 1884120 kB
MemFree: 1337828 kB
MemAvailable: 1604580 kB
Buffers: 872 kB
Cached: 373040 kB
La caché se asignará dinámicamente desde la memoria libre según se necesite para admitir la
E/S, bajo la teoría de que la memoria no utilizada es un recurso malgastado y se liberará para
que las aplicaciones la utilicen si el sistema está bajo presión de la memoria. Puede ejecutar
lo siguiente para borrar las caché de página, inodo y entrada de directorio:
[root@demo ~]# echo 3 > /proc/sys/vm/drop_caches
Esto dañará el rendimiento del sistema hasta que el sistema pueda volver a completar las
caché con datos a los que se accede con frecuencia.
Hay una gran cantidad de parámetros ajustables sysctl de kernel expuestos en /proc/
sys/vm que afectan el rendimiento de la administración de memoria y cachés del disco en
general. Este curso no incluye un análisis más profundo.
Sistemas de archivos
El sistemas de archivos proporcionan las estructuras lógicas que determinan cómo se
organizan y se nombran los archivos y sus datos y metadatos en el almacenamiento, y cómo
se los protege de riesgos y daños. Diferentes sistemas de archivos pueden proporcionar
diferentes funciones, y pueden implementar funciones similares en diferentes maneras. Por
lo general, los sistemas de archivos utilizados para discos de sistemas de Linux, como XFS y
130 RH342-RHEL7.2-es-1-20160321
Asignador de dispositivos
ext4, compartirán un subconjunto común de funciones requeridas por el estándar POSIX que
les permitirá integrarse bien con VFS y el modelo de archivo común.
Los sistemas de archivos pueden estar respaldados por almacenamiento de bloque (XFS,
ext4, GFS2, FAT32), almacenamiento de red (NFS, SMB), o pueden ser "pseudosistemas de
archivos" sintéticos (procfs, sysfs) o sistemas de archivos para un propósito especial (tmpfs)
respaldados por memoria y presentados por el kernel como si fueran almacenamiento.
Un ejemplo de una situación de solución de problemas en la capa del sistema de archivos

sería la recuperación de un sistema de archivos dañado después de un fallo del sistema.
También, los errores cometidos en la alineación de datos de estructuras del sistema de
archivos con un tamaño de bloque de nivel inferior cuando se formatea el almacenamiento
pueden provocar problemas de rendimiento.
Asignador de dispositivos
El asignador de dispositivos (Device mapper) es un mecanismo potente del kernel para crear
asignaciones 1:1 de bloques en un dispositivo de bloque a bloques de otro dispositivo de
bloque lógico. Este capa se utiliza para implementar LVM, cifrado en disco de LUKS y RAID de
asignador de dispositivos, entre otras cosas. Su uso es opcional; es posible que un dispositivo
de bloque físico se formatee directamente con un sistema de archivos sin utilizar el asignador
de dispositivos en lo absoluto.
Por ejemplo, tomemos un volumen lógico de LVM denominado /dev/mapper/myvg1-

mylv1, que tiene dos volúmenes físicos, /dev/vdb1 y /dev/vdb2. Cuando se creó este
volumen lógico mediante utilidades normales de LVM, un asignador de dispositivos de nivel
inferior asignó las particiones del dispositivo de bloque físico /dev/vdb1 y /dev/vdb2 a
un dispositivo lógico asignador de dispositivos, /dev/dm-0 en este caso. Se puede usar el
comando dmsetup para ver las asignaciones del dispositivo:
[root@servera ~]# dmsetup ls

myvg1-mylv1 (252:0)
[root@servera ~]# ls -l /dev/mapper/myvg1-mylv1

lrwxrwxrwx. 1 root root 7 Feb 26 09:40 /dev/mapper/myvg1-mylv1 -> ../dm-0
[root@servera ~]# dmsetup table /dev/mapper/myvg1-mylv1

0 1015808 linear 253:17 2048
1015808 1015808 linear 253:18 2048
En esta tabla se indica que /dev/mapper/myvg1-mylv1 está formado por dos asignaciones.
La primera es una asignación lineal 1:1 del dispositivo de bloque con número principal/
secundario 253:17 a los primeros 1015808 bloques de /dev/mapper/myvg1-mylv1.
La segunda es una asignación lineal 1:1 del dispositivo de bloque con número principal/
secundario 253:18 a los siguientes 1015808 bloques de /dev/mapper/myvg1-mylv1
(comenzando por el bloque 1015808). Los números principal/secundario 253:17 y 253:18
corresponden a /dev/vdb1 y /dev/vdb2:
[root@servera ~]# ls -l /dev/vdb*

brw-rw----. 1 root disk 253, 16 Feb 26 09:31 /dev/vdb
brw-rw----. 1 root disk 253, 17 Feb 26 09:40 /dev/vdb1
brw-rw----. 1 root disk 253, 18 Feb 26 09:40 /dev/vdb2
El volumen lógico /dev/dm-0 resultante que el asignador de dispositivos crea tiene el

siguiente aspecto:
RH342-RHEL7.2-es-1-20160321 131
Figura 5.2: Bloques de asignación del asignador de dispositivos entre dos

dispositivos de almacenamiento y un dispositivo del asignador de dispositivos
El dispositivo lógico creado por el asignador de dispositivos en este ejemplo (/dev/dm-0)

tiene 2031616 sectores en tamaño (1015808 sectores de /dev/vdb1 y 1015808 sectores de /
dev/vdb2).
La capa de bloque genérico y los programadores de

E/S
Las aplicaciones realizan operaciones de lectura/escritura en archivos mediante el VFS y el
sistema de archivos. El VFS y el sistema de archivos convierten estas solicitudes para leer y
escribir archivos en el sistema de archivos en solicitudes para leer y escribir bloques en el
dispositivo de almacenamiento. A continuación, estas solicitudes se pasan a la capa de bloque
genérico La tarea de la capa de bloque es organizar estas solicitudes en una cola y enviarlas al
controlador del dispositivo.
Históricamente, el hardware de almacenamiento ha sido mucho más lento que el sistema.

El objetivo de la capa de bloque es maximizar el rendimiento mediante las siguientes tres
acciones:
• Combinar las solicitudes adyacentes para mejorar la cantidad de datos que se leen o se
escriben por solicitud.
• Ordenar las solicitudes para minimizar la sobrecarga del disco.
• Priorizar las solicitudes para administrar la latencia y asegurarse de que ninguna solicitud
espere demasiado tiempo en la cola antes de ser enviada al controlador y fuera del
almacenamiento.
En Red Hat Enterprise Linux 7, la mayoría de los dispositivos pasan las solicitudes de E/S de
bloques a través de uno de tres algoritmos del programador de E/S basado en solicitudes:
• deadline es el predeterminado para la mayoría de los dispositivos de bloque en RHEL

7 excepto los dispositivos SATA y el almacenamiento virtio_blk paravirtualizado. Se
centra en asegurarse de que las solicitudes se ordenen para enviarlas eficientemente
132 RH342-RHEL7.2-es-1-20160321
Multitrayecto del asignador de dispositivos (Device mapper multipath)
al dispositivo, a menos que las solicitudes hayan estado en espera durante demasiado
tiempo, en cuyo caso se envían inmediatamente, dándole prioridad a las solicitudes de
lectura por sobre las solicitudes de escritura.
• cfq ("cola completamente equitativa") es el predeterminado para los discos SATA y para
la mayoría de los discos en sistemas de RHEL 6. Cada proceso tiene una cola de solicitud
para escrituras síncronas, hay menor cantidad de colas para E/S asíncrona, y los procesos
del programador en los que cada uno de ellos utiliza Round Robin para una determinada
fracción de tiempo.
• noop es un programador simple con el método "primero en entrar, primero en salir" que
realiza una combinación básica de solicitudes, pero no las ordena antes de enviarlas al
dispositivo. Es ideal para dispositivos de acceso aleatorio o dispositivos que realizan su
propria programación (como controladores de almacenamiento empresarial).
El programador estándar de E/S se diseñó para rotar discos duros, trabajar con latencias
de milisegundos y cientos de operaciones de E/S por segundo. Un nuevo mecanismo de
varias colas de E/S de bloque denominado blk-mq omite los programadores tradicionales
y permite que ciertos controladores del dispositivo asignen solicitudes de E/S a varias colas.
Los dispositivos de almacenamiento /dev/vd* paravirtualizados virtio comenzaron a
utilizar este subsistema en Red Hat Enterprise Linux 7.1/kernel-3.10.0-183.el7, en lugar de
programadores tradicionales de E/S. A largo plazo, este nuevo sistema está diseñado para
manejar almacenamiento con latencias de microsegundos, millones de IOPS y un gran
paralelismo interno.
Capa de bloque genérico y herramientas de programador de E/S

Para ver cuál es el programador que se usa con un dispositivo en particular, inspeccione sysfs
para ese dispositivo de bloque:
[root@host1 ~]# cat /sys/block/sda/queue/scheduler

noop deadline [cfq]
Es posible rastrear E/S a través de la capa de bloque mediante el paquete blktrace. El

comando blktrace /dev/sda rastreará E/S en /dev/sda y guardará el resultado en un
archivo con un nombre parecido a sda.blktrace.0 en el directorio actual. A continuación,
los comandos blkparse y btt pueden utilizarse para analizar los resultados del rastreo.
Multitrayecto del asignador de dispositivos (Device

mapper multipath)
El multitrayecto del asignador de dispositivos (DM Multipath) se utiliza para configurar
varios trayectos de E/S entre los nodos del servidor y las arreglos de almacenamiento en un
único dispositivo. Estos trayectos de E/S pueden ser conexiones físicas de Red de área de
almacenamiento (SAN, Storage Area Network), que incluyen cables separados, switches y
controladores. El multitrayecto agrega varios trayectos de E/S, creando un nuevo dispositivo
que consta de los trayectos agregados.
RH342-RHEL7.2-es-1-20160321 133
Figura 5.3: Multitrayecto del asignador de dispositivos
En este diagrama, un servidor de Red Hat Enterprise Linux tiene dos adaptadores de bus
de host (HBA) adjuntados a SAN. Por lo general, esto se realiza mediante conexiones físicas
de canal de fibra. El SAN también tiene conexiones a dos controladores de almacenamiento
diferentes. Como resultado, esta configuración permite cuatro posibles "trayectos" al
almacenamiento de backend. Esto resulta útil para la tolerancia de fallas, pero también
puede utilizarse para mejorar el rendimiento.
En Red Hat Enterprise Linux, el mecanismo del asignador de dispositivos del kernel se utiliza
para generar dispositivos de bloque separados para representar diferentes trayectos al
mismo dispositivo de almacenamiento. Esto es administrado por el daemon multipathd y la
herramienta de línea de comandos multipath, desde el paquete device-mapper-multipath.
Puede acceder a estos trayectos a través de otro dispositivo de bloque multitrayecto. Ese
dispositivo de bloque administrativo enviará las solicitudes a uno de los dispositivos de
bloque subyacentes asociado que representa un trayecto particular.
Con fines administrativos, los dispositivos multitrayecto se crean en /dev/mapper. Pueden

recibir el nombre de /dev/mapper/mpathN[pM] si se eligen nombres sencillos , o pueden
tener el nombre de ID mundial (WWID) del dispositivo de almacenamiento. Un administrador
también puede configurar nombres personalizados para dispositivos multitrayecto.
Esta capa solo entra en juego si el dispositivo de bloque tiene varios trayectos disponibles y
se utiliza el multitrayecto del asignador de dispositivos.
La capa media de SCSI

La capa media de SCSI es la capa de puente común entre los controladores de SCSI de alto nivel
que presentan los archivos de dispositivos principales utilizados por el almacenamiento y los
controladores de bajo nivel que utilizan los adaptadores de bus de host individuales y otras
tarjetas de interfaz de hardware que se comunican con el dispositivo de almacenamiento.
134 RH342-RHEL7.2-es-1-20160321
Controladores de bajo nivel
Hay cuatro controladores principales de SCSI de alto nivel. Para los dispositivos de bloque,
los dos más importantes son el controlador de disco de SCSI (sd) y el controlador de CDROM
de SCSI (sr). Además, hay un controlador de SCSI de alto nivel para los dispositivos de cinta
de SCSI basados en caracteres (st) y uno para los dispositivos de SCSI genéricos como los
escáneres (sg).
Cualquier elemento que actúe como un dispositivo de SCSI y utilice el protocolo de SCSI
para comunicarse entre el controlador de bajo nivel y el controlador de alto nivel, utiliza
la capa media de SCSI. Esto puede incluir elementos que, a primera vista, no parecen
estar relacionados con SCSI, como almacenamiento USB y SATA y ciertos dispositivos de
almacenamiento paravirtualizados de bajo nivel. Estos se presentarán al sistema como
dispositivos de SCSI y utilizarán nombres de dispositivo adecuados (/dev/sda, por ejemplo).
Algunos dispositivos de almacenamiento omiten esta capa. Por ejemplo, los dispositivos /
dev/vd* son dispositivos paravirtualizados que hablan directamente al controlador de bajo
nivel virtio_blk, que no forma parte de la pila de SCSI y no reproduce el protocolo de SCSI.
Controladores de bajo nivel

Los controladores de bajo nivel se comunican directamente con el hardware físico
específico utilizado por el sistema. En muchos casos, son controladores de bajo nivel
de SCSI que pueden sacar provecho de la capa media de SCSI. Por ejemplo, estos
pueden incluir controladores para dispositivos Qlogic (qla2xxx), Adaptec (aacraid)
o Emulex (lpfc), o dispositivos USB o SATA locales mediante libata, ahci, etc. Un
dispositivo de iSCSI que utiliza TCP/IP como transporte también tendría un controlador
en este nivel (como iscsi_tcp) antes de pasar su tráfico a la pila de la red. Algunos
dispositivos paravirtualizados pueden presentarse como discos de SCSI, como aquellos
que utilizan controladores virtio_scsi y vmw_pvscsi. Sin embargo, hay controladores
paravirtualizados de bajo nivel como virtio_blk que no utilizan la capa media de SCSI pero
tienen un controlador de capa superior que interactúa directamente con el programador en
la capa de bloque.
Independientemente de si usa la capa media de SCSI, el controlador de bajo nivel recibe E/S
del programador en la capa de bloque y la envía al hardware de almacenamiento subyacente.
El controlador toma las solicitudes de E/S entrantes y las transforma en una forma aceptable
para el controlador de hardware subayacente. El controlador de bajo nivel no envía E/S a la
cola, pero rastrea las solicitudes de E/S en desarrollo. Este es el nivel más bajo de la pila de
almacenamiento que aún forma parte del kernel de Linux.
Hardware físico
Adaptadores de bus de host (HBA) y firmware
El adaptador de bus de host (host bus adapter) (HBA) es el hardware físico del servidor que se
utiliza para comunicarse con el dispositivo de almacenamiento. Puede ser un adaptador de
host de SCSI o SATA o una tarjeta de interfaz de canal de fibra. Ese dispositivo puede tener su
propio firmware que controla sus operaciones. En una máquina virtual huésped, se puede
presentar un dispositivo virtio_pci paravirtualizado en la máquina como su hardware.
Capa de transporte
La capa de transporte define el protocolo de conexión utilizado por el HBA para comunicarse
con el almacenamiento adjunto. Esta capa podría involucrar la comunicación a través de una
conexión de punto a punto de SATA o SAS, USB, canal de fibra o, incluso, iSCSI sobre TCP/IP.
RH342-RHEL7.2-es-1-20160321 135
Dispositivos de almacenamiento físico

Por último, el almacenamiento físico real es el dispositivo que contiene los datos. Este
puede ser un disco duro con discos magnéticos giratorios, un disco de estado sólido (SSD),
almacenamiento óptico como CD-ROM o DVD-ROM, o un arreglo de almacenamiento
empresarial compuesta potencialmente por alguna combinación de los elementos
mencionados. Estos dispositivos pueden tener su propio firmware o sistemas operativos de
almacenamiento sofisticados.
Referencias
Werner Fischer ha publicado un diagrama más detallado de la pila de
almacenamiento para los kernels de Linux recientes, bajo la licencia CC-BY-SA, en
Diagrama de la pila de almacenamiento de Linux
https://www.thomas-krenn.com/en/wiki/Linux_Storage_Stack_Diagram
Descripción general del sistema de archivos virtuales de Linux

https://access.redhat.com/labs/psb/versions/kernel-3.10.0-327.el7/
Documentation/filesystems/vfs.txt
• También disponible en el sistema local como /usr/share/doc/kernel-doc-*/
Documentation/filesystems/vfs.txt, proporcionado por el paquete kernel-
doc
Uso del programador de E/S de plazos

Comprensión del programador de E/S de plazos

Comprensión del programador de noop

No se puede cambiar el programador de E/S para el disco virtio /dev/vda en RHEL

7.1
Notas de la versión de Red Hat Enterprise Linux 7.2: Nuevas funciones.

Almacenamiento: "Programación de E/S en varias colas con blk-mq"
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/
html/7.2_Release_Notes/storage.html#idp1704576
Documentación del subsistema de SCSI

https://access.redhat.com/labs/psb/versions/kernel-3.10.0-327.el7/
Documentation/scsi/scsi.txt
• También disponible en el sistema local como /usr/share/doc/kernel-doc-
*/Documentation/scsi/scsi.txt, proporcionado por el paquete kernel-doc.
También hay otros documentos sobre kernel disponibles en este directorio.
Páginas del manual free(1), dmsetup(8), multipath(8), blktrace(8), blkparse(1)

y btt(1)
136 RH342-RHEL7.2-es-1-20160321
Prueba: Orientación sobre la pila de almacenamiento de Linux
Prueba: Orientación sobre la pila de

almacenamiento de Linux
1. Seleccione todos los elevadores de disco.
a. noop
b. cfq
c. virtio_blk
d. deadline
2. ¿Cuál de estos dispositivos se comunica a través de la capa media de SCSI?
a. Dispositivos de almacenamiento masivo USB

b. Discos duros IDE
c. Discos duros SATA
d. Dispositivos virtio_blk paravirtualizados
3. ¿Cuál subsistema de kernel se utiliza para asignar dispositivos de bloque lógico al

almacenamiento físico?
a. Multitrayecto DM (DM-Multipath)
b. LVM
c. device-mapper
d. vfs
4. ¿Cuáles de los siguientes enunciados sobre la capa VFS de kernel es verdadero?
a. La capa VFS mantiene varias cachés, como la caché de inodo, la caché de entrada
de directorio y la caché de página.
b. Las aplicaciones pueden omitir la caché de página al abrir archivos con el conjunto
de indicadores O_DIRECT.
c. La capa VFS solo se utiliza para algunos sistemas de archivos comunes como ext4,
pero no para otros, como XFS.
d. La capa VFS proporciona una interfaz genérica para aplicaciones de espacio de
usuario en implementaciones del sistema de archivos.
RH342-RHEL7.2-es-1-20160321 137
Solución
1. Seleccione todos los elevadores de disco.
a. noop
b. cfq
c. virtio_blk
d. deadline
2. ¿Cuál de estos dispositivos se comunica a través de la capa media de SCSI?
a. Dispositivos de almacenamiento masivo USB

b. Discos duros IDE
c. Discos duros SATA
d. Dispositivos virtio_blk paravirtualizados
3. ¿Cuál subsistema de kernel se utiliza para asignar dispositivos de bloque lógico al

almacenamiento físico?
a. Multitrayecto DM (DM-Multipath)
b. LVM
c. device-mapper
d. vfs
4. ¿Cuáles de los siguientes enunciados sobre la capa VFS de kernel es verdadero?
a. La capa VFS mantiene varias cachés, como la caché de inodo, la caché de

entrada de directorio y la caché de página.
b. Las aplicaciones pueden omitir la caché de página al abrir archivos con el
conjunto de indicadores O_DIRECT.
c. La capa VFS solo se utiliza para algunos sistemas de archivos comunes como ext4,
pero no para otros, como XFS.
d. La capa VFS proporciona una interfaz genérica para aplicaciones de espacio de
usuario en implementaciones del sistema de archivos.
138 RH342-RHEL7.2-es-1-20160321
Recuperación de archivos dañados del sistema
Recuperación de archivos dañados del

sistema
Objetivos
Tras finalizar esta sección, los estudiantes podrán detectar y recuperarse de archivos dañados
del sistema.
Opciones del sistema de archivos

Red Hat Enterprise Linux les ofrece a los administradores de sistemas una variedad de
sistemas de archivos que cumplen con los requisitos de carga de trabajo de su sistema.
En RHEL 6, ext4 era el sistema de archivos predeterminado y XFS se ofrecía como otra
opción. Sin embargo, con RHEL 7, XFS ahora reemplaza a ext4 como el sistema de archivos
predeterminado.
Red Hat Enterprise Linux 7 proporciona un controlador unificado que admite los sistemas
de archivos ext2, ext3 y ext4. Aunque el sistema de archivos ext2 ahora es admitido por el
controlador del sistema de archivos extendido unificado, ext2 se considera obsoleto. Por lo
tanto, los administradores deberían evitar el uso del sistema de archivos ext2, de ser posible.
La creación de diarios (journals) del sistema de archivos se incorporó en Red Hat Enterprise
Linux con la presentación de ext3. La creación de diarios (journals) de sistemas de archivos
mejora la integridad de datos en el caso de un corte de energía o una caída del sistema.
Después de dicho evento, un sistema de archivos con diarios (journals) puede usar su diario
para recuperar rápidamente información no guardada en un intento por evitar daños en los
metadatos del sistema de archivos.
Los sistemas de archivos XFS y ext4 también generan diarios (journals) de los sistemas de
archivos. Aunque los sistemas de archivos con diarios (journals) generados proporcionan una
mayor resistencia a las fallas, no lo protegen de daños del sistema de archivos. Aún pueden
ocasionarse daños en el sistema de archivos, incluso en sistemas de archivos con diarios
(journals), debido a fallas en el hardware, errores de administración de almacenamiento y
errores de software.
Identificación de daños en el sistema de archivos

Cuando se detecta o sospecha que el sistema de archivos está dañado, los administradores
pueden usar herramientas de verificación del sistema de archivos para realizar una
verificación de consistencia integral en todo el sistema de archivos. Una vez que se identifica
la naturaleza y el alcance de los daños en los datos, los administradores pueden usar
herramientas de reparación del sistema de archivos para intentar restaurar la consistencia
del sistema de archivos. A continuación se indican algunas prácticas recomendadas para
recuperarse de daños en el sistema de archivos.
• Si una falla en el hardware es la causa de los datos dañados, se debe resolver el problema
de hardware antes de ejecutar una verificación o reparación en el sistema de archivos.
Por ejemplo, si un disco de almacenamiento tiene fallas, mueva el sistema de archivos a
un disco funcional antes de realizar tareas de mantenimiento en el sistema de archivos.
La migración de datos puede realizarse con varias utilidades comunes, como dd. Esto
proporcionará la base funcional del hardware que se requiere para el mantenimiento del
sistema de archivos.
RH342-RHEL7.2-es-1-20160321 139
• Se debe realizar una verificación del sistema de archivos antes de repararlo. Esto funciona
como un simulacro para la reparación del sistema de archivos. Durante este simulacro,
la verificación del sistema de archivos informará cualquier problema que se detecte en el
sistema de archivos y se tomarán medidas correctivas.
• Se debe desmontar un sistema de archivos antes de la administración del sistema de

archivos. Para restaurar correctamente la consistencia del sistema de archivos, las
herramientas de reparación del sistema de archivos deben tener acceso único al sistema
de archivos. Desmontar un sistema de archivos garantiza que no se puedan realizar
operaciones de almacenamiento aparte de la reparación del sistema de archivos. Ejecutar
una reparación del sistema de archivos en un sistema de archivos montado puede
provocar mayores daños en los datos.
Verificación de sistemas de archivos ext3/ext4

Después de un corte de energía o una caída del sistema, la utilidad e2fsck se ejecutará
automáticamente en un sistema para realizar la recuperación de diarios (journals) para los
sistemas de archivos ext3 y ext4. La reproducción del diario (journal) garantiza la consistencia
del sistema de archivos después de una caída del sistema o un apagado incorrecto. Si las
inconsistencias de metadatos del sistema de archivos están registradas, e2fsck realizará una
verificación completa del sistema de archivos después de que se reproduce el diario (journal).
Durante la verificación del sistema de archivos, se requerirá la intervención del usuario si
e2fsck no puede resolver los problemas detectados de manera segura.
Aparte de la ejecución automática de e2fsck en el momento del arranque, los

administradores también pueden ejecutar manualmente e2fsck para iniciar una verificación
del sistema de archivos. Para realizar una verificación del sistema de archivos en un sistema
de archivos ext3 o ext4, desmonte el sistema de archivos y ejecute e2fsck con la opción -n y,
luego, especifique el nombre del dispositivo en el que reside el sistema de archivos.
[root@demo ~]# e2fsck -n /dev/vdb1
La opción -n le indicará a e2fsck que coloque el sistema de archivos en el modo de solo

lectura y que responda 'no' a todas las preguntas planteadas durante la verificación del
Cuando ejecuta una verificación de consistencia en un sistema de archivos ext3 o ext4, un

administrador puede enfrentarse a un superbloque dañado. Si el superbloque principal del
sistema de archivos está dañado, es posible que deba usar un superbloque alternativo para
realizar la verificación del sistema de archivos.
[root@demo ~]# e2fsck -n /dev/vdb1

e2fsck 1.42.9 (28-Dec-2013)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/vdb1
The superblock could not be read or does not describe a correct ext2
file system. If the device is valid and it really contains an ext2
file system (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
140 RH342-RHEL7.2-es-1-20160321
Identificación de daños en el sistema de archivos
La ubicación de los superbloques de respaldo varía según el tamaño del bloque del sistema
de archivos. Para determinar la ubicación de los superbloques de respaldo, use la utilidad
dumpe2fs.
[root@demo ~]# dumpe2fs /dev/vdb1 | grep 'Backup superblock'

dumpe2fs 1.42.9 (28-Dec-2013)
Backup superblock at 32768, Group descriptors at 32769-32769
Una vez que se identifican los superbloques alternativos, use la opción -b para especificar el
superbloque alternativo que se debe usar durante la verificación del sistema de archivos.
[root@demo ~]# e2fsck -n /dev/vdb1 -b 32768

e2fsck 1.42.9 (28-Dec-2013)
/dev/vdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vdb1: 11/65536 files (0.0% non-contiguous), 8859/261888 blocks
[root@demo ~]# echo $?

0
El resultado de una verificación de sistema de archivos puede estar determinado por el

estado de salida del comando e2fsck. El estado de salida informado es la suma de los
códigos de salida desencadenados en la siguiente tabla.
Código de Descripción
salida
0 No hay errores.
4 Los errores del sistema de archivos no están corregidos.
8 Error operativo.
16 Error de uso.
32 Cancelado por el usuario.
128 Error de librería compartida.
nota
Las utilidades e2fsck y dumpe2fs son proporcionadas por el paquete e2fsprogs.
Verificación de sistemas de archivos XFS

A diferencia de los sistemas de archivos ext3 y ext4, el sistema no inicia automáticamente la
verificación y reparación del sistema de archivos en el momento del arranque en sistemas
de archivos XFS. Para ejecutar la verificación de un sistema de archivos XFS, el administrador
necesita ejecutar manualmente la utilidad de verificación del sistema de archivos XFS, que es
proporcionada por el paquete xfsprogs.
RH342-RHEL7.2-es-1-20160321 141
En las versiones anteriores del paquete xfsprogs, se proporcionaba la utilidad xfs_check

para realizar verificaciones del sistema de archivos en sistemas de archivos XFS. Esta
utilidad era extremadamente lenta y no se ampliaba adecuadamente para los sistemas
de archivos más grandes. Desde entonces, la utilidad xfs_check se considera obsoleta
y las verificaciones de sistemas de archivos XFS ahora se realizan a través de la utilidad
xfs_repair.
El comando xfs_repair se invoca con la opción -n para realizar verificaciones del sistema
de archivos. La opción -n le indicará a xfs_repair que analice el sistema de archivos y que
solo informe las reparaciones que deben realizarse en lugar de realizar medidas correctivas.
El siguiente comando realiza una verificación del sistema de archivos en el sistema de
archivos XFS que reside en /dev/vdb1.
[root@demo ~]# xfs_repair -n /dev/vdb1
El comando xfs_repair solo se puede ejecutar en un sistema de archivos XFS con un

registro de diario (journal) limpio. Los sistemas de archivos XFS que no tienen un registro de
diario (journal) limpio debido a un apagado incorrecto del sistema o una caída del sistema
deben montarse y desmontarse primero para ser verificados por xfs_repair.
Como los sistemas de archivos ext3 y ext4, es posible que las verificaciones del sistema de
archivos no se ejecuten debido a un superbloque principal dañado. Sin embargo, a diferencia
de e2fsck, xfs_repair no requiere que el administrador especifique las ubicaciones de
los superbloques alternativos. Analizará automáticamente el sistema de archivos XFS hasta
que localice un superbloque secundario. Una vez localizado, se utilizará el superbloque
secundario para recuperar el superbloque principal.
[root@demo ~]# xfs_repair -n /dev/vdb1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan file system freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing file system ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping file system flush and exiting.

0
142 RH342-RHEL7.2-es-1-20160321
Reparación de sistemas de archivos
Una verificación del sistema de archivos XFS devolverá el código de salida 1 si se detectaron
los daños en el sistema de archivos. Si no se detectaron los daños del sistema de archivos, se
devolverá el código de salida 0.
Reparación de sistemas de archivos

Una vez que se realiza la verificación del sistema de archivos, un administrador habrá
identificado los errores del sistema de archivos y habrá sido informado sobre las acciones
correctivas que se pueden tomar para restaurar la integridad del sistema de archivos.
Los administradores pueden iniciar una reparación del sistema de archivos al ejecutar las
utilidades de reparación asociadas con un tipo de sistema de archivos.
Reparación de sistemas de archivos ext3/ext4

Los sistemas de archivos ext3 y ext4 se reparan con el mismo comando e2fsck utilizado para
realizar verificaciones de sistemas de archivos. Cuando no se especifica la opción -n, e2fsck
realizará todas las medidas correctivas que se puedan tomar de manera segura para reparar
el sistema de archivos. Para las operaciones que no se pueden realizar de manera segura, el
administrador verá un aviso en el que se le preguntará si la acción debe ejecutarse o no.
Como se mencionó anteriormente, se debe desmontar el sistema de archivos durante la

reparación del sistema de archivos para garantizar la consistencia del sistema de archivos
y para prevenir mayores daños. Según la naturaleza de los daños del sistema de archivos,
los administradores pueden elegir ejecutar e2fsck con algunas de las siguientes opciones
adicionales.
-b ubicación Utiliza el superbloque alternativo en la ubicación especificada.
-p Repara automáticamente el sistema de archivos. Solo le muestra un
aviso al usuario cuando los problemas no se pueden solucionar de
manera segura.
-v Modo detallado.
-y Se ejecuta en modo no interactivo y responde sí a todas las preguntas.
Esta opción no se puede usar junto con las opciones -p o -n.
A continuación se muestra una reparación de ejemplo en un sistema de archivos ext4

que utiliza las opciones -y y -b para ejecutar una verificación de sistema de archivos no
interactiva a través de un superbloque alternativo.
[root@demo ~]# e2fsck /dev/vdb1 -b 98304

e2fsck 1.42.9 (28-Dec-2013)
/dev/vdb1 was not cleanly unmounted, check forced.
Resize inode not valid. Recreate? yes
Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (28520, counted=28521).
Fix? yes
Free blocks count wrong (253028, counted=253029).

Fix? yes
RH342-RHEL7.2-es-1-20160321 143
/dev/vdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/vdb1: 11/65536 files (0.0% non-contiguous), 8859/261888 blocks

1
El resultado de la reparación del sistema de archivos puede estar determinado por el código
de salida del comando e2fsck. El estado de salida informado es la suma de los códigos de
salida desencadenados en la siguiente tabla.
Código de Descripción
salida
0 No hay errores.
1 Los errores del sistema de archivos están corregidos.
2 Los errores del sistema de archivos están corregidos. Se requiere un
reinicio.
4 Los errores del sistema de archivos no están corregidos.
8 Error operativo.
16 Error de uso.
32 Cancelado por el usuario.
128 Error de biblioteca compartida.
Reparación de sistemas de archivos XFS

Los sistemas de archivos XFS se reparan con el mismo comando xfs_repair utilizado
para realizar verificaciones de sistemas de archivos. Cuando no se especifica la opción -n,
xfs_repair realizará todas las medidas correctivas que se puedan tomar de manera segura
para reparar el sistema de archivos. Como se mencionó anteriormente, se debe desmontar
el sistema de archivos durante la reparación del sistema de archivos para garantizar la
consistencia del sistema de archivos y para prevenir mayores daños.
Como se indicó, xfs_repair solo se puede ejecutar en un sistema de archivos XFS con
un registro de diario (journal) limpio. Si montar y desmontar un sistema de archivos XFS
no genera un registro limpio, es posible que el registro esté dañado. Dado que se necesita
tener un registro limpio, puede ser necesario en estas situaciones utilizar la opción -L en
xfs_repair. Esta opción reduce a cero el registro de diario (journal). Aunque este paso
es necesario para continuar, los administradores deben tomar nota de que puede generar
mayores inconsistencias en el sistema de archivos, ya que descarta todos los metadatos del
sistema de archivos en el registro de diario (journal).
A diferencia de e2fsck, xfs_repair no es una utilidad interactiva. Una vez iniciada, la

reparación del sistema de archivos XFS realizará todas las operaciones automáticamente sin
aportes del usuario. Además, a diferencia de e2fsck, xfs_repair devolverá siempre un
código de salida de 0 cuando se completa la reparación del sistema de archivos, como se
demuestra en el siguiente ejemplo.
[root@demo ~]# xfs_repair /dev/vdb1

144 RH342-RHEL7.2-es-1-20160321
Copia de seguridad y recuperación del sistema de archivos
- zero log...
- scan file system freespace and inode maps...
- scan and clear agi unlinked lists...
- agno = 0
- agno = 1
Invalid inode number 0x499602d2
xfs_dir_ino_validate: XFS_ERROR_REPORT
Metadata corruption detected at block 0xa7e0/0x1000
entry "subscription-manager" at block 0 offset 456 in directory inode 144973 references
invalid inode 1234567890
clearing inode number in entry at offset 456...
entry at block 0 offset 456 in directory inode 144973 has illegal name "/ubscription-
manager": - process newly discovered i
nodes...
- agno = 0
- agno = 1
Phase 5 - rebuild AG headers and trees...
- reset superblock...
- resetting contents of realtime bitmap and summary inodes
- traversing file system ...
bad hash table for directory inode 144973 (no data entry): rebuilding
rebuilding directory inode 144973
disconnected inode 145282, moving to lost+found
Phase 7 - verify and correct link counts...
done

0
Durante la reparación de un sistema de archivos XFS, es posible descubrir archivos y

directorios a los que se asignaron inodos y están en uso, pero que no tienen la referencia
de sus directorios principales. Cuando se descubren estos archivos y directorios huérfanos
durante las verificaciones del sistema de archivos, se depositan en el directorio lost+found
ubicado en la raíz de ese sistema de archivos. Si faltan archivos después de una reparación
del sistema de archivos, inspeccione el directorio lost+found para ver si se depositaron allí.
Copia de seguridad y recuperación del sistema de

archivos
Aunque las utilidades mencionadas también pueden usarse para detectar y reparar
inconsistencias del sistema de archivos, los administradores no deben usarlas como
reemplazo de una buena estrategia de copia de seguridad y recuperación. Los comandos
e2fsck y xfs_repair se utilizan para realizar reparaciones del sistema de archivos, pero no
se garantizan sus resultados.
Si se encuentran inodos o directorios con daños severos durante la recuperación del sistema
de archivos, es posible que se descarten permanentemente si no tienen solución. Debido a la
posibilidad de dicha pérdida de datos, es importante que los administradores tengan copias
de seguridad recientes de los datos del sistema de archivos a las cuales acudir, para poder
recuperar datos perdidos de manera adecuada.
RH342-RHEL7.2-es-1-20160321 145
Referencias
Para obtener más información, consulte las páginas del manual e2fsck(8),
dumpe2fs(8) y xfs_repair(8).
146 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Recuperación de archivos dañados del sistema
Ejercicio guiado: Recuperación de archivos

dañados del sistema
En este trabajo de laboratorio, verificará un sistema de archivos y reparará los daños del
Recursos
Archivos /root/etc.tgz
Máquinas servera
Resultados
Deberá poder verificar y reparar un sistema de archivos XFS.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab xfs setup en su
[student@workstation ~#$ lab xfs setup
La partición /dev/vdb1 en servera contiene un sistema de archivos XFS que almacena

contenido del directorio /etc de otro sistema. Verifique la integridad del sistema de archivos
XFS en /dev/vdb1. Repare las inconsistencias del sistema de archivos que encuentre y,
luego, monte el sistema de archivos en /mnt/etc_restore. Si la reparación del sistema
de archivos deposita archivos en el directorio lost+found del sistema de archivos, use el
archivo de copia de seguridad, /root/etc.tgz, para determinar la ubicación y el nombre
adecuados para restaurar el archivo huérfano. Una vez validado, restaure el archivo huérfano
a su ubicación adecuada.
1. Realice una verificación del sistema de archivos XFS en la partición /dev/vdb1.
1.1. Desmonte el sistema de archivos /dev/vdb1 dado que no se puede realizar una
verificación del sistema de archivos en un sistema de archivos montado.
[root@servera ~]# umount /mnt/etc_restore
1.2. Use el comando xfs_repair con la opción -n para realizar la verificación del
sistema de archivos sin medidas correctivas.
[root@servera ~]# xfs_repair -n /dev/vdb1

- scan filesystem freespace and inode maps...
- agno = 0
- agno = 1
RH342-RHEL7.2-es-1-20160321 147
entry "subscription-manager" at block 0 offset 456 in directory inode 144973

references invalid inode 1234567890
would clear inode number in entry at offset 456...
- agno = 0
- agno = 1
would clear inode number in entry at offset 456...
- traversing filesystem ...
entry "subscription-manager" in directory inode 144973 points to non-existent
inode 1234567890, would junk entry
bad hash table for directory inode 144973 (no data entry): would rebuild
disconnected inode 145282, would move to lost+found
No modify flag set, skipping filesystem flush and exiting.
Tenga en cuenta los errores informados, ya que presentan información que puede
resultar útil para la recuperación del sistema de archivos.
2. Use la utilidad xfs_repair para reparar las inconsistencias del sistema de archivos.
[root@servera ~]# xfs_repair /dev/vdb1

- zero log...
- agno = 0
- agno = 1
entry at block 0 offset 456 in directory inode 144973 has illegal name "/
ubscription-manager": - process newly discovered i
nodes...
- agno = 0
- agno = 1
bad hash table for directory inode 144973 (no data entry): rebuilding
rebuilding directory inode 144973
148 RH342-RHEL7.2-es-1-20160321
done
3. Monte el sistema de archivos reparado en /mnt/etc_restore para poder analizar los

resultados de la reparación del sistema de archivos.
[root@servera ~]# mount /dev/vdb1 /mnt/etc_restore
4. Determine si la reparación del sistema de archivos depositó archivos en el directorio

lost+found del sistema de archivos.
[root@servera ~]# ls -la /mnt/etc_restore/lost+found

total 4
drwxr-xr-x. 2 root root 19 Jan 19 23:07 .
drwxr-xr-x. 4 root root 33 Jan 19 22:59 ..
-rw-r--r--. 1 root root 62 Oct 13 11:00 145282
5. Determine el nombre y la ubicación correctos del archivo huérfano en lost+found

utilizando los resultados generados anteriormente durante la reparación del sistema de
archivos.
5.1. Según el resultado generado durante la reparación del sistema de archivos,

subscription-manager debería ser el nombre del archivo huérfano.

Metadata corruption detected at block 0x258e0/0x1000
nodes...
5.2. Según el resultado generado durante la reparación del sistema de archivos,

determine el nombre de directorio para el archivo subscription-manager. Use el
comando find para encontrar el directorio con el número de inodo 144973.

Metadata corruption detected at block 0x258e0/0x1000
nodes...
[root@servera ~]# find /mnt/etc_restore -inum 144973
RH342-RHEL7.2-es-1-20160321 149
/mnt/etc_restore/etc/security/console.apps
6. Utilice la copia de seguridad del contenido del sistema de archivos ubicada en /root/
etc.tgz para validar el nombre y la ubicación correctos del archivo huérfano.
6.1. Extraiga el archivo de copia de seguridad para poder utilizar su contenido para
efectuar una comparación.
[root@servera ~]# tar -C /tmp -xzf /root/etc.tgz
6.2. Verifique el contenido del archivo huérfano frente a la copia de seguridad del archivo
identificado.
[root@servera ~]# diff -s /tmp/etc/security/console.apps/subscription-manager /

mnt/etc_restore/lost+found/145282
Files /tmp/etc/security/console.apps/subscription-manager and /mnt/etc_restore/
lost+found/145282 are identical
7. Una vez validado, restaure el archivo huérfano a su ubicación adecuada.
[root@servera ~]# mv /mnt/etc_restore/lost+found/145282 /mnt/etc_restore/etc/

security/console.apps/subscription-manager
[student@workstation ~]$ lab xfs grade
[student@workstation ~]$ lab xfs reset
150 RH342-RHEL7.2-es-1-20160321
Recuperación de accidentes de LVM
Recuperación de accidentes de LVM
Objetivos
Después de completar esta sección, los estudiantes deberán poder revertir errores de
administración de almacenamiento en volúmenes de LVM.
Administración de volúmenes lógicos

La Administración de volúmenes lógicos (LVM, Logical volume management) les proporciona
a los administradores un marco de virtualización de almacenamiento potente. Se agregan
uno o más contenedores de datos (volúmenes físicos) en un conjunto de almacenamiento
(grupo de volumen), desde los cuales se pueden repartir los volúmenes para que actúen
como dispositivos de bloque (volúmenes lógicos). La administración de volúmenes lógicos
también permite que se desmonten o se copien los datos entre volúmenes físicos.
Como dm-multipath, la administración de volúmenes lógicos utiliza el subsistema del kernel

Asignador de dispositivos para crear los dispositivos de LVM. Los volúmenes lógicos se crean
en /dev/ como nodos de dispositivos dm-*, pero con enlaces simbólicos en /dev/mapper y
/dev/<vgname>/ utilizando nombres más simples (y persistentes) para la administración.
Archivos de configuración
El comportamiento de LVM se configura en /etc/lvm/lvm.conf. Este archivo tiene ajustes
para controlar el comportamiento de bloqueo, el análisis de dispositivos y la asignación
de nombres de volúmenes físicos con varias rutas, así como otras funciones de LVM. En la
siguiente tabla, se enumeran algunas de las opciones más comunes.
/etc/lvm/lvm.conf Opciones
dir El directorio que se debe analizar para los
nodos de dispositivos de volumen físico.
obtain_device_list_from_udev Si se debe usar udev para obtener una lista
de los dispositivos de bloqueo elegibles para
el análisis.
preferred_names Una lista de expresiones regulares que
detallan los nombres de dispositivos
que deben tener preferencia cuando se
muestran los dispositivos. Si se encuentran
diversos nombres de dispositivos
(nodos) para el mismo volumen físico, las
herramientas de LVM le darán preferencia a
aquellos que aparecen primero en la lista.
filter (filtro) Una lista de expresiones regulares prefijadas
con a para Add (Agregar) o r para Remove
(Quitar). Esta lista determina los nodos
de dispositivos en los que se buscará la
presencia de una firma de volumen físico. El
valor predeterminado es [ "a/.*/" ], que
agrega todos los dispositivos. Puede usar
RH342-RHEL7.2-es-1-20160321 151
/etc/lvm/lvm.conf Opciones
esta opción para eliminar el dispositivo que
nunca debe analizarse.
backup (copia de seguridad) Este ajuste determina si se debe almacenar
una copia de seguridad basada en texto
de los metadatos del grupo de volúmenes
después de cada cambio. Puede usar esta
copia de seguridad para restaurar un grupo
de volúmenes si se dañan los metadatos en
el disco.
backup_dir Este ajuste especifica dónde se debe
almacenar la copia de seguridad de los
metadatos del grupo de volúmenes.
archive (archivo) Este ajuste determina si se deben archivar
los diseños o las configuraciones del
grupo de volúmenes para utilizarlos
posteriormente para revertir los cambios.
archive_dir Este ajuste especifica dónde se deben
almacenar los archivos de configuraciones
anteriores.
retain_min Este ajuste especifica la cantidad mínima de
archivos que se deben almacenar.
retain_days Este ajuste especifica la cantidad mínima de
días que se deben conservar los archivos.
Revertir cambios de LVM

En el curso de la administración de almacenamiento de rutina, es posible que los
administradores realicen un cambio en un grupo de volúmenes del que se arrepienten
inmediatamente, por ejemplo, reducir un volumen lógico antes de reducir el sistema de
archivos de ese volumen lógico. En este ejemplo de reducción, el administrador puede
intentar expandir el volumen lógico al tamaño anterior, pero no se garantiza que se utilicen
los mismos bloques que antes en el disco, lo que posiblemente resulte en daños del sistema
de archivos en el volumen lógico que sufrió cambios de tamaño.
La función de archivado de LVM puede ser muy útil en este tipo de situaciones. LVM puede
mantener copias archivadas de los metadatos del grupo de volúmenes. Si se establece la
opción de archive en 1 en /etc/lvm/lvm.conf, las herramientas de LVM crearán una
copia archivada de los metadatos del grupo de volúmenes actual antes de realizar cambios
en el disco. En una configuración predeterminada, puede encontrar estos archivos en /etc/
lvm/archive. Puede visualizar la lista de todos los metadatos archivados para un grupo de
volúmenes al examinar los archivos en /etc/lvm/archive y prestar atención a las líneas de
descripción. De manera alternativa, se puede ver la misma información con el comando
vgcfgrestore -l <vgname>.
[root@demo ~]# vgcfgrestore -l vg_example

File: /etc/lvm/archive/vg_example_00000-943759797.vg
VG name: vg_example
Description: Created *before* executing 'vgcreate vg_example /dev/sda5'
Backup Time: Mon Jan 19 07:01:47 2016
152 RH342-RHEL7.2-es-1-20160321
Revertir cambios de LVM
VG name: vg_example
Description: Created *before* executing 'lvcreate -L 1G -n lv_example vg_example'
VG name: vg_example
Description: Created *before* executing 'lvresize -L -256M /dev/vg_example/lv_example'
File: /etc/lvm/backup/vg_example
VG name: vg_example
Description: Created *after* executing 'lvresize -L -256M /dev/vg_example/lv_example'
En el ejemplo anterior, el resultado muestra la secuencia de acciones recientes realizadas en

el grupo de volúmenes vg_example. Primero, se crea el grupo de volúmenes vg_example
y, luego, se crea el volumen lógico lv_example en el grupo de volúmenes Por último, el
volumen lógico se reduce 256 MiB. El último bloque del resultado muestra la copia de
seguridad de los metadatos del grupo de volúmenes en /etc/lvm/backup, creada después
de reducir el volumen lógico.
Para deshacer un cambio de LVM, asegúrese de que el volumen lógico no esté en uso
actualmente (desmonte los sistemas de archivos que se crearon en el volumen lógico)
y, luego, utilice el comando vgcfgrestore nuevamente, pero esta vez con la opción -f
<archive_file>.
[root@demo ~]# vgcfgrestore -f /etc/lvm/archive/vg_example_00001-1528176681.vg

vg_example
Restored volume group vg_example
En algunos casos, puede ser necesario desactivar y, luego, reactivar el volumen lógico para
asegurarse de que todos los cambios se apliquen también en la memoria.
[root@demo ~]# lvchange -an /dev/vg_example/lv_example

[root@demo ~]# lvchange -ay /dev/vg_example/lv_example
RH342-RHEL7.2-es-1-20160321 153
Referencias
Guía de administración de almacenamiento de Red Hat
• Sección 4: LVM
Para obtener más información, consulte la

Guía del Administrador de volúmenes lógicos de Red Hat Enterprise Linux 7
html/Logical_Volume_Manager_Administration/
• Sección 2: Componentes de LVM
• Sección 4.3.12: Copias de seguridad de metadatos del grupo de volúmenes
• Sección 6.4: Recuperación de metadatos de volumen físico
Páginas del manual lvm.conf(5), vgbackup(8) y vgcfgrestore(8)
154 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Recuperación de accidentes de LVM
Ejercicio guiado: Recuperación de accidentes

de LVM
En este trabajo de laboratorio, resolverá un problema de LVM.
Recursos
Archivos /mnt/lvm
Máquinas servera
Resultados
Deberá poder identificar y revertir la causa de una falla de LVM.
Andes de comenzar
Prepare su sistema para este ejercicio ejecutando el comando lab lvm setup en su
[student@workstation ~#$ lab lvm setup
Recientemente se recibió una solicitud para asignar 20 MiB de almacenamiento adicionales

al directorio, /mnt/lvm, en servera. Después de que se completó la solicitud, los usuarios
informaron que ya no se puede acceder al directorio. Los usuarios piensan que, de algún
modo, el administrador que completó la solicitud eliminó accidentalmente los archivos
importantes. Se escaló el problema y se le pide que investigue e identifique la causa raíz del
problema. Una vez que se completa el análisis de causa raíz, intente restaurar el sistema al
estado de funcionamiento adecuado.
1. Inspeccione el directorio /mnt/lvm para confirmar el problema informado por el

usuario.
[root@servera ~]# ll /mnt/lvm

total 0
2. Revise el contenido del archivo /etc/fstab para determinar si el contenido del

directorio está montado desde un sistema de archivos independiente.
[root@servera ~]# grep /mnt/lvm /etc/fstab

/dev/vg00/lvol0 /mnt/lvm xfs defaults 0 0
3. Verifique que el sistema de archivos del volumen lógico esté montado en /mnt/lvm.
[root@servera ~]# mount | grep /mnt/lvm
4. Dado que el sistema de archivos no está montado, intente montarlo manualmente.
[root@servera ~]# mount /mnt/lvm

mount: /dev/mapper/vg00-lvol0: can't read superblock
RH342-RHEL7.2-es-1-20160321 155
5. Consulte la lista de archivos y copias de seguridad de metadatos para el grupo de

volúmenes en el que reside el volumen lógico /dev/vg00/lvol0 para determinar los
cambios, si corresponde, que se realizaron en la configuración del volumen lógico.
[root@servera ~]# vgcfgrestore -l vg00

File: /etc/lvm/archive/vg00_00002-1999295985.vg
VG name: vg00
Description: Created *before* executing 'lvresize -L20M /dev/vg00/lvol0'
Backup Time: Wed Jan 20 02:43:40 2016
File: /etc/lvm/backup/vg00
VG name: vg00
Description: Created *after* executing 'lvresize -L20M /dev/vg00/lvol0'
6. Analice las descripciones de cada registro de archivo e identifique el archivo que existió
antes de la asignación de espacio en el volumen lógico. Determine si el comando
registrado en el registro de archivo generó el problema observado por el usuario.
File: /etc/lvm/archive/vg00_00002-1999295985.vg
VG name: vg00
Description: Created *before* executing 'lvresize -L20M /dev/vg00/lvol0'
En lugar de asignar otros 20 MiB de espacio al volumen lógico con la opción -L+20M, el
administrador redujo por error el volumen lógico a 20 MiB.
7. Revierta la acción incorrecta que se ejecutó durante el intento de asignar espacio al

volumen lógico.
[root@servera ~]# vgcfgrestore -f /etc/lvm/archive/vg00_00002-1999295985.vg vg00

Restored volume group vg00
8. Desactive y vuelva a activar el volumen lógico /dev/vg00/lvol0 para asegurarse de que

todo esté actualizado.
[root@servera ~]# lvchange -an /dev/vg00/lvol0

[root@servera ~]# lvchange -ay /dev/vg00/lvol0
9. Monte el sistema de archivos para determinar si se resolvió el problema.
[root@servera ~]# mount /mnt/lvm

[root@servera ~]# ll /mnt/lvm
total 12
156 RH342-RHEL7.2-es-1-20160321
drwxr-xr-x. 94 root root 8192 Jan 19 22:26 etc
10. Complete correctamente la solicitud del usuario al asignar otros 20 MiB de espacio al
sistema de archivos /dev/vg00/lvol0.
[root@servera ~]# lvresize -L+20M /dev/vg00/lvol0

Size of logical volume vg00/lvol0 changed from 40.00 MiB (10 extents) to 60.00 MiB
(15 extents).
Logical volume lvol0 successfully resized.
[root@servera ~]# xfs_growfs /dev/vg00/lvol0
meta-data=/dev/mapper/vg00-lvol0 isize=256 agcount=2, agsize=5120 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=10240, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=853, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 10240 to 15360
[student@workstation ~]$ lab lvm grade
11.2.Realice una limpieza en sus sistemas para el próximo ejercicio.
[student@workstation ~]$ lab lvm reset
RH342-RHEL7.2-es-1-20160321 157
Tratamiento de problemas de LUKS
Objetivos
Tras finalizar esta sección, los estudiantes podrán recuperar datos de sistemas de archivos
cifrados.
Uso de volúmenes cifrados

La Configuración de Clave Unificada de Linux (LUKS, Linux Unified Key Setup) es el formato
estándar para el cifrado de dispositivos en Red Hat Enterprise Linux. Una partición o un
volumen cifrado por LUKS debe descifrarse antes de que se pueda montar el sistema de
archivos.
El montaje persistente de volumen cifrado que se lleva a cabo durante el arranque del
sistema consta de los siguientes pasos.
1. Se consulta el archivo /etc/crypttab por una lista de dispositivos que deben

desbloquearse durante el arranque. El archivo enumera un dispositivo por línea, con los
siguientes campos separados por espacios:
name /dev/vdaN /path/to/keyfile
donde name es el nombre que el asignador de dispositivos utilizará para el dispositivo

cifrado /dev/mapper/name, /dev/vdaN es el dispositivo "bloqueado" subyacente,
y /path/to/keyfile es el archivo de clave que debe utilizarse para desbloquear el
dispositivo. Si el último campo se deja en blanco (o se configura con el valor "ninguno"),
se le solicitará al usuario la contraseña de descifrado durante el inicio.
2. Con la frase de contraseña proporcionada por el usuario o con una clave contenida en
un archivo, el volumen cifrado se descifra y se asigna a un dispositivo del asignador de
dispositivos denominado /dev/mapper/name, que utiliza el nombre especificado en /
etc/crypttab.
3. Si el volumen cifrado se descifra correctamente, se creará el dispositivo asignado

descifrado y su contenido estará disponible. El sistema de archivos contenido en el
dispositivo asignado descifrado está montado en función de la entrada relevante en /
etc/fstab. Estas entradas pueden referirse a los contenidos del volumen descifrado
por el nombre del asignador de dispositivos o por su UUID.
/dev/mapper/name /secret ext4 defaults 1 2
UUID="2460ab6e-e869-4011-acae-31b2e8c05a3b" /secret ext4 defaults 1 2
Solución de problemas de volúmenes de LUKS

Configuración incorrecta de /etc/crypttab
Una fuente común de problemas de descifrado es la configuración incorrecta del archivo de
configuración /etc/crypttab. Las entradas de este archivo determinan cómo se descifran
los volúmenes cifrados y cómo se asignan después de un descifrado.
158 RH342-RHEL7.2-es-1-20160321
Solución de problemas de volúmenes de LUKS
El primer campo identifica el nombre del dispositivo asignado sin el prefijo /dev/mapper.
El segundo campo corresponde al dispositivo cifrado. El tercer campo de entradas puede
dejarse en blanco para la frase de contraseña solicitada, o se puede especificar un archivo de
clave para utilizar en el descifrado.
Si el descifrado tiene errores, verifique que el contenido del segundo campo y del tercer
campo sea correcto. Un nombre de dispositivo cifrado incorrecto y un archivo de clave
incorrecto resultarán en fallas en el descifrado.
Si el descifrado es exitoso pero el montaje del dispositivo asignado tiene errores, compruebe
que el contenido del primer campo de la entrada relevante sea correcto. Si hay una
discrepancia entre el nombre asignado especificado en /etc/crypttab y el nombre del
asignador de dispositivos correspondiente en /etc/fstab, el contenido descifrado no estará
disponible en el punto de montaje configurado.
Fallas en el descifrado
Aparte de las configuraciones incorrectas mencionadas en /etc/crypttab, el descifrado de
un dispositivo cifrado también puede ocurrir en las siguientes situaciones.
• Ha olvidado la frase de contraseña de LUKS o la ha cambiado por una contraseña

desconocida. Esta es posiblemente la situación más frecuente.
LUKS ofrece un total de ocho ranuras de clave para los dispositivos cifrados. Si hay otras
claves o frases de contraseña, pueden utilizarse para restablecer la contraseña olvidada
o desconocida. Las claves asociadas se pueden mostrar con el comando cryptsetup
luksDump.
[root@demo ~]# cryptsetup luksDump /dev/vdb1

LUKS header information for /dev/vdb1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 78 1a 67 57 7f b6 4e a3 60 40 fb 0b 76 91 ee 96 21 2e 09 d4
MK salt: bd c2 45 9d 30 32 4e 69 aa 6b a8 90 33 c5 f1 6a
4a f4 c7 fc e8 7f 21 ae a4 3b a2 91 74 dc f8 9e
MK iterations: 81000
UUID: 3d1d164c-569c-4809-ba6e-9b3de75ed223
Key Slot 0: ENABLED

Iterations: 324049
Salt: 30 95 87 15 61 c5 96 87 af 55 cd 9d 4a d0 59 22
61 12 89 9f 59 e5 80 1f ae f9 03 1d c2 01 46 44
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
RH342-RHEL7.2-es-1-20160321 159
Si hay una copia de respaldo del encabezado de LUKS, también puede resolver el problema
al restaurar el encabezado desde la copia de seguridad, que permitirá el descifrado
mediante la contraseña anterior.
• El encabezado de LUKS puede estar dañado. LUKS almacena un encabezado de metadatos

y ranuras de clave al comienzo de cada dispositivo cifrado. Por lo tanto, una falla en
el encabezado de LUKS puede hacer que los datos cifrados no estén accesibles. Si hay
una copia de seguridad del encabezado dañado de LUKS, puede resolver el problema al
restaurar el encabezado desde la copia de seguridad.
• Las funciones de hash y los códigos necesarios para ejecutar el cifrado no están en el
kernel. Se puede determinar una lista de códigos criptográficos admitidos por el kernel de
un sistema al examinar el contenido de /proc/crypto.
/etc/fstab configuración incorrecta

El dispositivo asignado descifrado está configurado para montarse en /etc/fstab. Un
nombre incorrecto del dispositivo especificado ocasionará una falla en el montaje. Un error
común es configurar el dispositivo cifrado, en lugar del dispositivo asignado, para el montaje.
Restauración de encabezados de LUKS

Para algunos problemas comunes de LUKS, las copias de respaldo de encabezados de LUKS
pueden marcar la diferencia entre una solución administrativa simple y datos irrecuperables
de manera permanente. Por lo tanto, los administradores de volúmenes cifrados por LUKS
deben llevar a cabo la buena práctica de realizar una copia de seguridad de sus encabezados
de manera habitual. Además, deben estar familiarizados con los procedimientos para
restaurar los encabezados desde la copia de seguridad, en caso de necesidad.
Copia de seguridad de encabezados de LUKS

Las copias de seguridad de encabezados de LUKS se llevan a cabo con la herramienta
cryptsetup en conjunto con el subcomando luksHeaderBackup. La ubicación del archivo
de copia de seguridad se especifica con la opción --header-backup-file.
[root@demo ~]# cryptsetup luksHeaderBackup /path/to/encrypted/device --header-backup-

file /path/to/backup/file
Como sucede con todas las tareas administrativas del sistema, las copias de seguridad de los
encabezados de LUKS deben llevarse a cabo antes de las tareas administrativas realizadas en
un volumen cifrado por LUKS.
Prueba y recuperación de encabezados de LUKS

Si se ha realizado una copia de seguridad del encabezado de LUKS de un volumen cifrado,
las copias de seguridad se pueden restaurar en el volumen para solucionar problemas
como contraseñas olvidadas o encabezados dañados. Antes de realizar una restauración
de encabezado, como buena práctica, los administradores deben realizar una copia de
seguridad del encabezado existente incluso si el encabezado está dañado o asociado con una
contraseña desconocida.
Si hay varias copias de seguridad para un volumen cifrado, un administrador necesita

identificar el que debe restaurar. En lugar de restaurar el encabezado y, luego, intentar un
descifrado, el administrador primero debe realizar un descifrado de prueba con un archivo de
encabezado. Esto se logra mediante el siguiente comando.
160 RH342-RHEL7.2-es-1-20160321
Restauración de encabezados de LUKS
[root@demo ~]# cryptsetup luksOpen /path/to/encrypted/device --header /path/to/backup/

file
Enter passphrase for /path/to/encrypted/device:
Si la prueba es exitosa, se puede restaurar el encabezado mediante el comando cryptsetup

junto con el comando luksHeaderRestore, como se demuestra en el siguiente ejemplo.
[root@demo ~]# cryptsetup luksHeaderRestore /path/to/encrypted/device --header-backup-

file /path/to/backup/file
WARNING!
========
Device /path/to/encrypted/device already contains LUKS header. Replacing header will
destroy existing keyslots.
Are you sure? (Type uppercase yes): YES
Referencias
Página del manual: cryptsetup(8)
Guía de seguridad de Red Hat Enterprise Linux 7: Uso de cifrado en disco de

LUKS
html/Security_Guide
Todo acerca de LUKS, cryptsetup y dm-crypt

Cómo recuperar una frase de contraseña o clave de LUKS perdida

Página del proyecto de cryptsetup

https://gitlab.com/groups/cryptsetup
RH342-RHEL7.2-es-1-20160321 161
Ejercicio guiado: Tratamiento de problemas

de LUKS
En este trabajo de laboratorio, resolverá problemas con el montaje de un sistema de archivos

cifrados.
Recursos
Archivos /root/luks_header_backup
Resultados
Deberá poder resolver problemas y recuperarse de una falla en el montaje de un volumen
cifrado.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab luks setup en su
[student@workstation ~#$ lab luks setup
Un volumen cifrado por LUKS montado en /mnt/secure en servera estaba protegido con
la contraseña RedHatR0cks!. Para cumplir con la política de contraseñas de la empresa, un
administrador junior cambió la contraseña por una nueva, JustMyLUK. Sin embargo, después
del cambio de contraseña, el administrador junior informa que la nueva contraseña no
funciona en el volumen cifrado. Por suerte, hace poco se realizó una copia de seguridad del
encabezado de LUKS para el volumen, que está disponible en /root/luks_header_backup.
Evalúe la situación y restaure el volumen al estado de funcionamiento. Utilice la copia de
seguridad del encabezado de LUKS, si es necesario, para restaurar la función del volumen
cifrado.
1. Determine la configuración del volumen cifrado del sistema.
1.1. Consulte /etc/fstab para determinar el volumen configurado para el montaje en /

mnt/secure.
[root@servera ~]# grep /mnt/secure /etc/fstab

/dev/mapper/secure /mnt/secure xfs defaults 1 2
1.2. Consulte /etc/crypttab para determinar cómo se configuran los dispositivos

cifrados en el sistema en el momento del arranque.
[root@servera ~]# cat /etc/crypttab

secure /dev/vdb1 none
2. Evalúe el estado actual del volumen cifrado. Utilice el comando dmsetup para determinar
si hay un dispositivo asignado en el dispositivo del bloque cifrado. Utilice el filtro --
target crypt para filtrar solo el dispositivo del bloque cifrado.
162 RH342-RHEL7.2-es-1-20160321
[root@servera ~]# dmsetup ls --target crypt
No devices found
3. Dado que el dispositivo asignado no existe, utilice el comando cryptsetup luksOpen

para abrir manualmente el volumen cifrado y crear el dispositivo asignado asociado
que está especificado en /etc/crypttab. Intente descifrar el volumen cifrado con la
nueva contraseña que el administrador junior configuró. Si eso no funciona, pruebe con
la contraseña anterior.
[root@servera ~]# cryptsetup luksOpen /dev/vdb1 secure

Enter passphrase for /dev/vdb1: JustMyLUK
No key available with this passphrase.
4. Utilice cryptsetup luksDump para determinar si hay otras claves para el volumen
cifrado para determinar si hay otras posibles contraseñas que pueda probar.
[root@servera ~]# cryptsetup luksDump /dev/vdb1

LUKS header information for /dev/vdb1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: d1 db 30 00 8d f4 f9 7a 4c 9f eb 7a 8c 2a 3a 0f 30 e0 75 d9
MK salt: c8 ca d5 90 5a f7 cd 5d b9 35 4e c5 83 b1 b4 f7
47 e3 4e b8 5b 36 bb f7 67 25 61 61 8e e5 9f de
MK iterations: 81250
UUID: b4b499bb-be72-4912-b9f6-0d23970aba6b

Key Slot 1: ENABLED
Iterations: 324049
Salt: 19 55 1a fa 00 ee 3f af fa 38 6d 18 90 c8 79 67
39 ed ef cd cd 3c a1 7a f0 3f 24 05 6e fa 26 66
Key material offset: 264
AF stripes: 4000
5. Dado que ni la contraseña nueva ni las contraseñas anteriores pueden descifrar

el volumen cifrado y dado que no hay otras claves, la única opción es reinstalar la
contraseña anterior al restaurar el encabezado de LUKS desde el archivo de copia de
seguridad del encabezado de LUKS, /root/luks_header_backup.
RH342-RHEL7.2-es-1-20160321 163
5.1. Dado que es una buena práctica realizar cambios administrativos reversibles, realice
una copia de seguridad del encabezado de LUKS actual antes de reemplazarlo con el
encabezado de LUKS de la copia de seguridad.
[root@servera ~]# cryptsetup luksHeaderBackup /dev/vdb1 --header-backup-file /

root/luks_header_new
5.2. Restaure el encabezado de LUKS anterior desde el archivo de copia de seguridad /

root/luks_header_backup para reinstalar la contraseña anterior.
[root@servera ~]# cryptsetup luksHeaderRestore /dev/vdb1 --header-backup-file /

root/luks_header_backup
WARNING!
========
Device /dev/vdb1 already contains LUKS header. Replacing header will destroy
existing keyslots.
6. Utilice el comando cryptsetup luksOpen una vez más para intentar abrir
manualmente el volumen cifrado y crear el dispositivo asignado asociado que está
especificado en /etc/crypttab. Intente descifrar el volumen cifrado con la contraseña
anterior.
[root@servera ~]# cryptsetup luksOpen /dev/vdb1 secure

Enter passphrase for /dev/vdb1: RedHatR0cks!
7. Utilice el comando dmsetup para determinar si ahora hay un dispositivo asignado

seguro en el dispositivo del bloque cifrado. Utilice el filtro --target crypt para filtrar
solo el dispositivo del bloque cifrado.
[root@servera ~]# dmsetup ls --target crypt

secure (252, 0)
8. Compruebe que el dispositivo asignado para el volumen cifrado ahora puede montarse
correctamente en /mnt/secure.
[root@servera ~]# mount /mnt/secure

[root@servera ~]# mount | grep /mnt/secure
/dev/mapper/secure on /mnt/secure type xfs (rw)
[student@workstation ~]$ lab luks grade
164 RH342-RHEL7.2-es-1-20160321
[student@workstation ~]$ lab luks reset
RH342-RHEL7.2-es-1-20160321 165
Resolución de problemas de iSCSI
Objetivos
de iSCSI.
Configuración de iniciadores de iSCSI

La Interfaz estándar de equipos pequeños de Internet (iSCSI) es un protocolo basado en
TCP/IP para emular un bus SCSI de almacenamiento local de alto rendimiento a través
de redes IP, que ofrece transferencia y administración de datos a dispositivos remotos de
almacenamiento en bloque. Como protocolo de red de área de almacenamiento (SAN), iSCSI
extiende SAN a través de amplias redes de área (LAN, WAN e Internet), y ofrece recuperación
de almacenamiento de datos independiente de la ubicación con servidores y arreglos
distribuidos.
Figura 5.4: Topologías de almacenamiento en bloque de SCSI e iSCSI
Terminología de componentes de iSCSI

Término Descripción
iniciador Un cliente iSCSI, en general disponible como software, pero también
(initiator) implementado como iSCSI HBA. Los initiators deben recibir nombres
únicos (consulte IQN).
destino Un recurso de almacenamiento de iSCSI, configurado para la conexión
(target) desde un servidor iSCSI. Los targets deben recibir nombres únicos
(consulte IQN). Un target ofrece uno o más dispositivos de bloque
numerados llamados unidades lógicas (consulte LUN). Un servidor iSCSI
puede ofrecer muchos targets al mismo tiempo.
ACL Una lista de control de accesos (entrada), una restricción de acceso que
utiliza el nodo IQN (habitualmente el nombre del iniciador de iSCSI) para
validar los permisos de acceso para un iniciador.
166 RH342-RHEL7.2-es-1-20160321
Término Descripción
detección Hacer consultas a un servidor de target para enumerar targets
(discovery) configurados. El uso del destino requiere de pasos de acceso adicionales
(consulte inicio de sesión).
IQN Un nombre calificado de iSCSI, un nombre único en el mundo utilizado
para identificar iniciadores y destinos, en el formato de nomenclatura
según las directivas:
iqn.YYYY-MM.com.reversed.domain[:optional_string]

iqn: significa que este nombre utilizará un dominio como su
identificador.
YYYY-MM: el primer mes en que se adquirió el nombre de dominio.
com.reversed.domain: el nombre de dominio invertido de la
organización que crea este nombre iSCSI.
optional_string: una cadena opcional con dos puntos antepuestos
asignada por el propietario del dominio según lo deseado que continúa
siendo única en todo el mundo. Puede incluir dos puntos para separar los
límites de la organización.
inicio Autenticar a un target o LUN para comenzar el uso del dispositivo de
de sesión bloqueo de cliente.
(login)
LUN Un número de unidad lógica, dispositivos de bloqueo numerados
conectados y disponibles a través de un destino. Uno o más LUN pueden
conectarse a un único target, a pesar de que, en general, un target
proporciona solo un LUN.
nodo Cualquier initiator de iSCSI o target de iSCSI, identificado por su IQN.
portal Una dirección IP y un puerto en un target o initiator utilizado para
establecer conexiones. Algunas implementaciones iSCSI utilizan portal y
nodo de manera intercambiable.
TPG Grupo de portal de destino, el conjunto de direcciones IP y puertos TCP de
la interfaz a los que escuchará un destino iSCSI específico. La configuración
de target (por ejemplo, ACL) se puede agregar al TPG para coordinar la
configuración de múltiples LUN.

El protocolo iSCSI funciona con una configuración cliente-servidor familiar. Los sistemas
cliente configuran software de initiator para enviar comandos SCSI a destinosde
almacenamiento de servidor remoto. Los targets iSCSI a los que se accede aparecen en el
sistema del cliente como dispositivos de bloque SCSI locales sin formato, idénticos a los
dispositivos conectados con cables SCSI, FC conectado directamente o un interruptor de FC.
En Red Hat Enterprise Linux, un iniciador de iSCSI normalmente se implementa en software

y funciona de manera similar a un adaptador de bus de host (HBA) iSCSI por hardware para
acceder a destinos desde un servidor de almacenamiento remoto. El uso de un initiator iSCSI
basado en software requiere la conexión con una red Ethernet existente que cuente con
ancho de banda suficiente para transportar el tráfico de almacenamiento esperado.
SCSI también puede implementarse mediante el uso de un iniciador por hardware que
incluya los protocolos necesarios en un adaptador de bus de host dedicado. Los HBA iSCSI
RH342-RHEL7.2-es-1-20160321 167
y los motores de descarga TCP (TOE), que incluyen la pila de red TCP en un NIC Ethernet,
trasladan la sobrecarga de procesamiento de iSCSI o TCP, y las interrupciones de Ethernet en
el hardware, lo que reduce la carga de las CPU del sistema.
La configuración de un iniciador requiere la instalación del paquete iscsi-initiator-utils ,

que incluye los servicios iscsi y iscsid, y los archivos de configuración /etc/iscsi/
iscsid.conf y /etc/iscsi/initiatorname.iscsi.
El cliente, como es un nodo iSCSI, requiere un IQN único. El archivo /etc/iscsi/

initiatorname.iscsi predeterminado contiene un IQN generado mediante el uso del
dominio de Red Hat. Generalmente, los administradores restablecen el IQN en su propio
dominio y una secuencia del sistema cliente adecuada.
El archivo /etc/iscsi/iscsid.conf contiene valores predeterminados para registros

de nodos creados durante la detección de destino nuevo. Los valores incluyen tiempos
de espera basados en iSCSI, parámetros de reintentos, así como nombres de usuario y
contraseñas de autenticación. Para cambiar el archivo es necesario reiniciar el servicio iscsi.
[root@serverX ~]# systemctl restart iscsi
Conexión a destinos de iSCSI

Para descubrir destinos, el cliente debe tener una conectividad de red funcional al host de
destino. Se debe instalar el paquete iscsi-initiator-utils y se debe iniciar y habilitar el servicio
iscsi. Los destinos deben detectarse antes de que se conecten y se usen los dispositivos. La
detección y el registro de destinos se realiza mediante la utilidad iscsiadm proporcionada
por el paquete iscsi-initiator-utils.
Opciones de autenticación
iSCSI utiliza ACL para enmascarar el LUN, al administrar el acceso de destinos apropiados y
LUN a los iniciadores. El acceso a los destinos también puede limitarse con la autenticación
CHAP. Las ACL de iSCSI son similares al uso de números mundiales (WWN) de dispositivos
de FC para restricciones de administración de creación de zonas flexibles . A pesar de que la
restricción obligatoria de puertos a nivel del interruptor de FC (creación de zonas permanentes)
no tiene un mecanismo similar a iSCSI, las VLAN de Ethernet pueden ofrecer una seguridad
de aislamiento similar.
El tráfico de red de área de almacenamiento, en general, se cifra, ya que el cableado de

servidor físico a almacenamiento normalmente se encierra en centros de datos seguros.
Para la seguridad WAN, iSCSI y canal de fibra a través de Ethernet (FCoE) pueden utilizar
la Seguridad del protocolo de Internet (IPsec), un conjunto de protocolos para asegurar el
tráfico de red IP.
iSCSI ofrece los nombres de usuario y las contraseñas con Protocolo de autenticación
por desafío mutuo (Challenge-Handshake Authentication Protocol) (CHAP) como un
mecanismo de autenticación para limitar la conectividad entre los initiators y los targets
elegidos. Por defecto, el iniciador de iSCSI en Red Hat Enterprise Linux se configura para
la no autenticación. El número de puerto puede omitirse cuando el servidor de target está
configurado en el puerto predeterminado 3260. Por lo tanto, si se desea una seguridad de
datos mejorada en la red, debe configurar la autenticación CHAP en el iniciador.
Si se habilitó y se configuró la autenticación de contraseña en el destino, se debe configurar

la autenticación coincidente en el iniciador. Los ajustes están ubicados en /etc/iscsi/
168 RH342-RHEL7.2-es-1-20160321
Solución de problemas del iniciador de iSCSI
iscsid.conf. Para la autenticación unidireccional que verifica el iniciador en el servidor

de destino, use las credencias de username y password. Para la autenticación bidireccional
que verifica adicionalmente el portal de destino en el iniciador, también se requieren las
credenciales username_in y password_in.
• Para la autenticación de detección, utilice estos parámetros:

discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = username
discovery.sendtargets.auth.password = password
discovery.sendtargets.auth.username_in = username_in
discovery.sendtargets.auth.password_in = password_in
• Para la autenticación normal, establezca estos parámetros:

node.session.auth.authmethod = CHAP
node.session.auth.username = username
node.session.auth.password = password
node.session.auth.username_in = username_in
node.session.auth.password_in = password_in
• Para la autenticación no, elimine todos los valores de la credencial y vuelva a comentar las
líneas authmethod.

Dado que iSCSI es un protocolo basado en red, los problemas del iniciador de iSCSI pueden
surgir de problemas o configuraciones incorrectas en la capa de la red. Se requiere una
conexión de red correcta al host de destino de iSCSI antes de que el iniciador de iSCSI pueda
descubrir sus destinos. Por lo tanto, la solución de problemas de detección debería comenzar
con una evaluación de las redes.
Identificación y resolución de problemas de red

La solución de problemas de red debería comenzar con la realización de una prueba básica
de la conectividad de red desde el iniciador al host de destino. Para garantizar que las
conexiones se realicen en el host de destino adecuado, comience primero por asegurarse de
que la resolución de nombres esté funcionado adecuadamente.
Verifique que el destino de las conexiones iniciadas por iscsiadm responden correctamente
a la dirección IP del host de destino. Si no es el caso, utilice dig para realizar una resolución
de nombres mediante DNS. Si se han eliminado los problemas con la resolución DNS,
inspeccione /etc/hosts y /etc/nsswitch.conf para ver si sus configuraciones son la
fuente de los mismos problemas de resolución.
Por defecto, los servidores de destino están configurados para que se escuchen en el puerto
3260. Si la resolución de nombres está funcionando adecuadamente, pruebe realizar una
conexión a este puerto mediante una utilidad como Netcat.
[root@serverX ~]# nc -z target_server_ip 3260
Por defecto, los servidores de destino están configurados para que se escuchen en el puerto
3260. Si la conexión falla, compruebe que las configuraciones del servidor de destino sean
correctas. Asegúrese de que el servidor de destino esté configurado para escucharse en el
puerto predeterminado y que firewalld esté configurado para las conexiones remotas al
puerto.
RH342-RHEL7.2-es-1-20160321 169
Si el componente de red ya no es la causa de los problemas de iSCSI, un iniciador debería

poder realizar una detección de los destinos en el servidor de iSCSI. La detección de destinos
puede analizarse con el siguiente comando. El número de puerto puede omitirse cuando el
servidor de target está configurado en el puerto predeterminado 3260.
[root@serverX ~]# iscsiadm -m discovery -t sendtargets -p target_server[:port]

172.25.X.11:3260,1 iqn.2016-01.com.example.lab:iscsistorage
Ejecute el siguiente comando para ver si los destinos se detectaron correctamente. El

comando devolverá una lista de nodos conocidos, junto con su puerto y dirección de portal
asociados.
[root@serverX ~]# iscsiadm -m node

172.25.250.254:3260,1 iqn.2016-01.com.example.lab:iscsistorage
Identificación y resolución de problemas de inicio de sesión

Si la detección es correcta, pero el iniciador experimenta un problema al iniciar sesión en el
destino detectado, es probable que el problema esté relacionado con la autenticación o el
control de acceso. El control de acceso a los destinos de iSCSI se concede en el servidor de
iSCSI al especificar los nombres de los iniciadores que deberían tener el acceso permitido.
El nombre del iniciador se configura en el cliente en /etc/iscsi/initiatorname.iscsi.
Una disparidad entre el nombre del iniciador del cliente y el nombre configurado en el
servidor provocará una falla en el inicio de sesión de destino. Si el problema se debe a
una configuración incorrecta del nombre del iniciador en el cliente, asegúrese de reiniciar
el servicio iscsid después de que se fija el nombre del iniciador en /etc/iscsi/
initiatorname.iscsi para que el cambio entre en efecto.
[root@serverX ~]# systemctl restart iscsid
Si el nombre del iniciador está configurado correctamente, las fallas del inicio de sesión
pueden atribuirse a la configuración incorrecta de la autenticación. Para autenticarse
correctamente, el iniciador debe estar configurado para utilizar el método de autenticación
requerido por el servidor de destino. Por defecto, no se configura un método de
autenticación en el servidor o el cliente. Si se configura el servidor para la autenticación CHAP,
se deben especificar las configuraciones CHAP del iniciador en /etc/iscsi/iscsid.conf,
como se mencionó anteriormente.
Para evaluar la causa de las fallas en el inicio de sesión, puede resultar útil ejecutar el inicio
de sesión en el modo detallado. La opción -d habilita el modo de depuración. El nivel de
depuración se puede configurar entre 0 y 8. Se requiere el nivel 8 para ver los detalles de
autenticación.
[root@serverX ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage --login -

d8
iscsiadm: updated 'node.session.auth.authmethod', 'None' => 'CHAP'
Si el problema se debe a una configuración CHAP incorrecta en el cliente, asegúrese de

reiniciar el servicio iscsid después de que se realizan los cambios en /etc/iscsi/
iscsid.conf para que los cambios entren en efecto.
170 RH342-RHEL7.2-es-1-20160321
[root@serverX ~]# systemctl restart iscsid
El proceso de detección almacena información de los nodos de target y valores en el

directorio /var/lib/iscsi/nodes, y utiliza los valores predeterminados de /etc/iscsi/
iscsid.conf. Puesto que el mismo target puede existir en múltiples portales, los registros
de nodos se almacenan para cada portal. Tras la detección, un registro de nodo se escribe en
/var/lib/iscsi/nodes y se utiliza para los inicios de sesión posteriores.
Cuando se realizan cambios en /etc/iscsi/iscsid.conf después del intento de inicio de

sesión inicial, es importante recordar que el proceso de inicio de sesión seguirá utilizando los
ajustes guardados en /var/lib/iscsi/nodes. Para iniciar sesión con los nuevos ajustes
configurados, los administradores pueden modificar los ajustes existentes guardados en /
var/lib/iscsi/nodes o eliminar toda la información guardada en ese directorio.
Puede visualizar los ajustes existentes para un destino mediante el siguiente comando.
[root@serverX ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage

# BEGIN RECORD 6.2.0.873-30
node.name = iqn.2016-01.com.example.lab:iscsistorage
node.tpgt = 1
node.conn[0].iscsi.HeaderDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No
Use el comando iscsiadm para modificar los ajustes existentes. Use la opción -o para
especificar la operación actualizar. También use la opción -n para especificar el parámetro
para modificar y usar la opción -v con el fin de especificar el valor del parámetro. Por
ejemplo, para cambiar el método de autenticación para deshabilitar la autenticación CHAP,
ejecute el siguiente comando.
[root@serverX ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage -o update

-n node.session.auth.authmethod -v None [-p target_server[:port]]
De manera alternativa, los administradores pueden elegir purgar toda la información

de nodos de la caché. Para purgar los ajustes del nodo existente de un destino, utilice el
comando iscsiadm junto con la opción -o para especificar la operación eliminar.
[root@serverX ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage -o delete

[-p target_server[:port]]
Los ajustes para todos los nodos conocidos se pueden purgar al utilizar el mismo comando y
no especificar un destino.
[root@serverX ~]# iscsiadm -m node -o delete [-p target_server[:port]]
RH342-RHEL7.2-es-1-20160321 171
Referencias
Página del manual: iscsiadm(8)
Guía de administración de almacenamiento en Red Hat Enterprise Linux 7:

Creación de un iniciador de iSCSI
html/Storage_Administration_Guide/index.html
172 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Resolución de problemas de iSCSI
Ejercicio guiado: Resolución de problemas de

iSCSI
En este trabajo de laboratorio, resolverá problemas con un iniciador de iSCSI.
Recursos
Resultados
Deberá poder identificar y resolver una configuración incorrecta de un iniciador de iSCSI en
un sistema cliente.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab iscsi setup en su
[student@workstation ~#$ lab iscsi setup
El sistema workstation se ha configurado con el destino iSCSI,

iqn.2016-01.com.example.lab:iscsistorage. El destino se ha
configurado con una ACL que permite el acceso a un iniciador denominado
iqn.2016-01.com.example.lab:servera. El destino se ha configurado para que no se
requiera la autenticación del iniciador.
Un administrador colega recibió la tarea de configurar servera para usar el destino

iqn.2016-01.com.example.lab:iscsistorage en workstation. El administrador
informó que, aunque puede detectar el destino, no puede iniciar sesión correctamente.
Identifique y solucione el problema para que el iniciador pueda entrar correctamente al
destino.
1. Comience por validar el problema informado.
1.1. Compruebe si el administrador descubrió correctamente el destino. El siguiente

comando enumerará todos los registros del nodo.
[root@servera ~]# iscsiadm -m node

1.2. Compruebe si hay sesiones o conexiones activas. Dado que el administrador informó
una falla en el inicio de sesión del destino, no se espera que haya sesiones activas.
[root@servera ~]# iscsiadm -m session

iscsiadm: No active sessions.
1.3. Intente iniciar sesión en el destino para verificar lo que el administrador informó y
también para ver la naturaleza de los errores generados.
[root@servera ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage

--login
RH342-RHEL7.2-es-1-20160321 173
Logging in to [iface: default, target: iqn.2016-01.com.example.lab:iscsistorage,

portal: 172.25.250.254,3260] (multiple)
iscsiadm: Could not login to [iface: default, target:
iqn.2016-01.com.example.lab:iscsistorage, portal: 172.25.250.254,3260].
iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization
failure)
iscsiadm: Could not log into all portals
2. Con la opción -d con el comando iscsiadm, intente iniciar sesión en el destino

nuevamente, pero genere también información de depuración detallada. Dado que los
mensajes de error están relacionados con la falla en la autorización, busque mensajes de
depuración que correspondan a esto.
[root@servera ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage --

login -d8
iscsiadm: updated 'node.session.queue_depth', '32' => '32'
iscsiadm: updated 'node.session.nr_sessions', '1' => '1'
iscsiadm: updated 'node.session.timeo.replacement_timeout', '120' => '120'
iscsiadm: updated 'node.session.err_timeo.abort_timeout', '15' => '15'
3. Los mensajes de depuración indican que el iniciador está configurado para usar la
autenticación CHAP. Dado que el destino no requiere autenticación, el método de
autorización del iniciador tiene una configuración incorrecta. Corrija la configuración en
/etc/iscsi/iscsid.conf al comentar la siguiente línea y, luego, reinicie iscsid para
que se apliquen los cambios.
# node.session.auth.authmethod = CHAP
[root@servera ~]# systemctl restart iscsid
4. Intente iniciar sesión en el destino otra vez para verificar si se ha resuelto el problema de
inicio de sesión.

login
portal: 172.25.250.254,3260] (multiple)
failure)
5. Dado que la falla continúa, use la opción -d con el comando iscsiadm e intente iniciar
sesión en el destino nuevamente, pero genere también información de depuración
detallada. Dado que los mensajes de error están relacionados con la falla en la
autorización, busque mensajes de depuración que correspondan a esto.

login -d8
174 RH342-RHEL7.2-es-1-20160321
6. Los mensajes de depuración indican que el iniciador aún está utilizando la autenticación
CHAP para iniciar sesión en el destino. Esto se debe a que el método de autorización
utilizado en los intentos de inicio de sesión anteriores se guardó para el destino. Utilice el
comando iscsiadm para cambiar el método de autenticación a None (Ninguno).
[root@servera ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage -o

update -n node.session.auth.authmethod -v None
inicio de sesión.

login
portal: 172.25.250.254,3260] (multiple)
failure)
8. Dado que la falla continúa, use la opción -d con el comando iscsiadm e intente iniciar
sesión en el destino nuevamente, pero genere también información de depuración
detallada. Dado que los mensajes de error están relacionados con la falla en la
autorización, busque mensajes de depuración que correspondan a esto.

login -d8
iscsiadm: updated 'node.session.auth.authmethod', 'None' => 'None'
9. Los mensajes de depuración indican que el iniciador ya no está utilizando la

autenticación para iniciar sesión en el destino. Con este problema descartado, la falla del
inicio de sesión en el destino puede deberse a una restricción de ACL. Vea si el nombre
del iniciador coincide con el nombre iqn.2016-01.com.example.lab:servera
permitido en la ACL.
[root@servera ~]# cat /etc/iscsi/initiatorname.iscsi

InitiatorName=iqn.2016-01.lab.example.com:servera
10. El nombre del iniciador está configurado incorrectamente. Corrija el nombre y reinicie
iscsid para que se aplique el cambio.
RH342-RHEL7.2-es-1-20160321 175

InitiatorName=iqn.2016-01.com.example.lab:servera
inicio de sesión.

login
portal: 172.25.250.254,3260] (multiple)
Login to [iface: default, target: iqn.2016-01.com.example.lab:iscsistorage, portal:
172.25.250.254,3260] successful.
[student@workstation ~]$ lab iscsi grade
13. Reinicie todos sus sistemas para proveer un entorno limpio para los siguientes ejercicios.
176 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Solución de problemas de almacenamiento

problemas de almacenamiento
En este trabajo de laboratorio, revolverá problemas de almacenamiento relacionados con

cifrado, sistemas de archivos, LVM e iSCSI.
Recursos
Archivos /mnt/save/luks/iscsistorage_luks_header
Resultados
Deberá poder resolver problemas con sistemas de archivos dañados, encabezados de LUKS,
administración de LVM y destinos de iSCSI.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab storage setup en su
[student@workstation ~#$ lab storage setup
El director financiero solicitó acceso a los datos financieros de la

empresa. Los datos residen en un volumen cifrado en el destino de iSCSI,
iqn.2016-01.com.example.lab:iscsistorage, proporcionado por workstation. El
destino no requiere autenticación y se ha configurado con una ACL que concede acceso al
iniciador iqn.2016-01.com.example.lab:servera.
Un administrador que trabaja sobre esta solicitud ha encontrado un problema al acceder al

volumen cifrado. Ayúdelo a resolver este problema y, luego, descifre el volumen con la última
contraseña conocida de RedHatR0cks!. Ponga el volumen a disposición como el dispositivo
asignado /dev/mapper/finance en el punto de montaje /mnt/finance en servera.
Si tiene problemas para descifrar el volumen cifrado, se realizó una copia de seguridad
del encabezado del volumen cifrado y se almacenó en el volumen lógico de LVM /dev/
save/old en servera. Monte el volumen lógico en /mnt/save en servera, y puede
ubicar el archivo de copia de seguridad del encabezado de LUKS en /mnt/save/luks/
iscsistorage_luks_header. Si, por cualquier motivo, no se puede acceder al archivo,
resuelva el problema y, luego, restaure el archivo en esa ubicación.
1. En servera, evalúe la situación al generar una lista de nodos conocidos y sesiones

activas de iSCSI.
2. Si no hay nodos conocidos ni sesiones, intente realizar una detección de destinos en

workstation. Si encuentra algún problema, resuélvalo para que la detección se lleve a
cabo de manera correcta.
3. Una vez que se realiza correctamente la detección del destino de iSCSI en workstation,
inicie sesión en el destino. Si encuentra algún problema, resuélvalo para que el inicio de
sesión se lleve a cabo de manera correcta.
4. Una vez que el inicio de sesión en el destino se realiza correctamente, descifre el

volumen cifrado con la última contraseña conocida.
RH342-RHEL7.2-es-1-20160321 177
5. Dado que el descifrado falló, monte el volumen lógico de LVM /dev/save/old en /mnt/
save para acceder al archivo de volcado del encabezado de LUKS. Si encuentra algún
problema con el volumen lógico, resuélvalo para que el volumen lógico esté disponible.
6. Busque y verifique el archivo de copia de seguridad del encabezado de LUKS ubicado

en /mnt/save/luks/iscsistorage_luks_header. Si encuentra algún problema
cuando verifica el archivo, resuélvalo para que el archivo esté disponible en la ubicación
especificada.
7. Con la copia de seguridad del encabezado de LUKS ubicado en /mnt/save/luks/

iscsistorage_luks_header, restaure el encabezado de LUKS en el volumen cifrado
ubicado en la partición /dev/sda1.
8. Descifre el volumen cifrado con la última contraseña conocida y asígnelo a /dev/

mapper/finance.
9. Ponga a disposición el contenido del volumen cifrado en el punto de montaje /mnt/

finance.
[student@workstation ~]$ lab storage grade
ejercicios.
178 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, revolverá problemas de almacenamiento relacionados con
cifrado, sistemas de archivos, LVM e iSCSI.
Recursos
Archivos /mnt/save/luks/iscsistorage_luks_header
Resultados
Deberá poder resolver problemas con sistemas de archivos dañados, encabezados de LUKS,
administración de LVM y destinos de iSCSI.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab storage setup en su
[student@workstation ~#$ lab storage setup
El director financiero solicitó acceso a los datos financieros de la

empresa. Los datos residen en un volumen cifrado en el destino de iSCSI,
iqn.2016-01.com.example.lab:iscsistorage, proporcionado por workstation. El
destino no requiere autenticación y se ha configurado con una ACL que concede acceso al
iniciador iqn.2016-01.com.example.lab:servera.
Un administrador que trabaja sobre esta solicitud ha encontrado un problema al acceder al

volumen cifrado. Ayúdelo a resolver este problema y, luego, descifre el volumen con la última
contraseña conocida de RedHatR0cks!. Ponga el volumen a disposición como el dispositivo
asignado /dev/mapper/finance en el punto de montaje /mnt/finance en servera.
Si tiene problemas para descifrar el volumen cifrado, se realizó una copia de seguridad
del encabezado del volumen cifrado y se almacenó en el volumen lógico de LVM /dev/
save/old en servera. Monte el volumen lógico en /mnt/save en servera, y puede
ubicar el archivo de copia de seguridad del encabezado de LUKS en /mnt/save/luks/
iscsistorage_luks_header. Si, por cualquier motivo, no se puede acceder al archivo,
resuelva el problema y, luego, restaure el archivo en esa ubicación.
1. En servera, evalúe la situación al generar una lista de nodos conocidos y sesiones

activas de iSCSI.
[root@servera ~]# iscsiadm -m session

iscsiadm: No active sessions.
[root@servera ~]# iscsiadm -m node
iscsiadm: No records found
2. Si no hay nodos conocidos ni sesiones, intente realizar una detección de destinos en

workstation. Si encuentra algún problema, resuélvalo para que la detección se lleve a
cabo de manera correcta.
2.1. Realice una detección de destinos en workstation.
[root@servera ~]# iscsiadm -m discovery -t st -p workstation.lab.example.com

iscsiadm: cannot make connection to 172.25.254.254: Connection refused
RH342-RHEL7.2-es-1-20160321 179

iscsiadm: connection login retries (reopen_max) 5 exceeded
iscsiadm: Could not perform SendTargets discovery: encountered connection
failure
2.2. Verifique que la dirección resuelta para workstation.lab.example.com durante

la detección sea correcta.
[root@servera ~]# dig +short workstation.lab.example.com

172.25.250.254
2.3. Dado que la dirección no coincide con la proporcionada por la resolución de

nombres de DNS, inspeccione /etc/hosts para determinar si esta es la fuente del
problema.
[root@servera ~]# grep workstation /etc/hosts

172.25.254.254 workstation.lab.example.com workstation
2.4. Corrija las entradas incorrectas en /etc/hosts para corregir el problema

de resolución de nombres que genera los errores de conectividad en
workstation.lab.example.com.
[root@servera ~]# grep workstation /etc/hosts

2.5. Vuelva a realizar una detección de destinos en workstation.
[root@servera ~]# iscsiadm -m discovery -t st -p workstation.lab.example.com

3. Una vez que se realiza correctamente la detección del destino de iSCSI en workstation,
inicie sesión en el destino. Si encuentra algún problema, resuélvalo para que el inicio de
sesión se lleve a cabo de manera correcta.
3.1. Inicie sesión en el destino en workstation.

--login
portal: 172.25.250.254,3260] (multiple)
failure)
3.2. Verifique el método de autenticación configurado en el iniciador para asegurarse de

que no haya una autenticación configurada.
180 RH342-RHEL7.2-es-1-20160321
Solución
[root@servera ~]# iscsiadm -m node -T iqn.2016-01.com.example.lab:iscsistorage |

grep authmethod
node.session.auth.authmethod = None
3.3. Dado que el método de autenticación está configurado correctamente, verifique que
la falla de autenticación no se deba a una restricción de ACL al comprobar que el
nombre del iniciador coincide con el acceso otorgado por la ACL de destino.

InitiatorName=iqn.com.example.lab:servera
3.4. Corrija el nombre incorrecto del iniciador en /etc/iscsi/initiatorname.iscsi

para resolver el problema de resolución de nombres para el inicio de sesión en el
destino que previene la autenticación en el destino.

InitiatorName=iqn.2016-01.com.example.lab:servera
3.5. Reinicie iscsid para que se aplique el cambio de nombre del iniciador.
3.6. Intente iniciar sesión otra vez en el destino.

--login
portal: 172.25.250.254,3260] (multiple)
Login to [iface: default, target: iqn.2016-01.com.example.lab:iscsistorage,
portal: 172.25.250.254,3260] successful.
4. Una vez que el inicio de sesión en el destino se realiza correctamente, descifre el

volumen cifrado con la última contraseña conocida.
[root@servera ~]# cryptsetup luksOpen /dev/sda1 finance

Enter passphrase for /dev/sda1:
5. Dado que el descifrado falló, monte el volumen lógico de LVM /dev/save/old en /mnt/
save para acceder al archivo de volcado del encabezado de LUKS. Si encuentra algún
problema con el volumen lógico, resuélvalo para que el volumen lógico esté disponible.
5.1. Monte el volumen lógico /dev/save/old.
[root@servera ~]# mkdir /mnt/save

[root@servera ~]# mount /dev/save/old /mnt/save
mount: special device /dev/save/old does not exist
5.2. Busque el volumen lógico /dev/save/old.
RH342-RHEL7.2-es-1-20160321 181
[root@servera ~]# lvs

LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
Convert
new save -wi-a----- 16.00m
5.3. Dado que el volumen lógico no está, investigue el registro de archivo de LVM para
determinar el motivo de su ausencia.
[root@servera ~]# vgcfgrestore -l save
File: /etc/lvm/archive/save_00000-1431778654.vg
Couldn't find device with uuid eYfFIc-HUFc-NxnQ-w0xq-QmnE-j6DC-36y0UY.
VG name: save
Description: Created *before* executing 'vgcreate save /dev/vdb1'
Backup Time: Fri Jan 22 13:34:33 2016
VG name: save
Description: Created *before* executing 'lvcreate -W y -L 15M -n old save'
VG name: save
Description: Created *before* executing 'lvcreate -W y -L 15M -n new save'
VG name: save
Description: Created *before* executing 'lvremove -f /dev/save/old'
File: /etc/lvm/backup/save
VG name: save
Description: Created *after* executing 'lvremove -f /dev/save/old'
5.4. Deshaga la eliminación del volumen lógico y, luego, monte el volumen en /mnt/
save.
[root@servera ~]# vgcfgrestore -f /etc/lvm/archive/save_00003-600513272.vg save

Restored volume group save
[root@servera ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
Convert
new save -wi-a----- 16.00m
old save -wi------- 16.00m

[root@servera ~]# lvchange -an /dev/save/old
[root@servera ~]# lvchange -ay /dev/save/old
6. Busque y verifique el archivo de copia de seguridad del encabezado de LUKS ubicado

en /mnt/save/luks/iscsistorage_luks_header. Si encuentra algún problema
182 RH342-RHEL7.2-es-1-20160321
Solución
cuando verifica el archivo, resuélvalo para que el archivo esté disponible en la ubicación
especificada.
6.1. Busque y verifique el archivo /mnt/save/luks/iscsistorage_luks_header.
[root@servera ~]# ls -la /mnt/save/luks

ls: cannot access /mnt/save/luks/iscsistorage_luks_header: Invalid argument
total 0
??????????? ? ? ? ? ? iscsistorage_luks_header
[root@servera ~]# file /mnt/save/luks/iscsistorage_luks_header
/mnt/save/luks/iscsistorage_luks_header: cannot open (Invalid argument)
6.2. Determine el tipo de sistema de archivos formateado en el volumen lógico y ejecute

una verificación del sistema de archivos.
[root@servera ~]# blkid /dev/save/old

/dev/save/old: UUID="c878808f-3c8e-45a3-abc1-0559694e5410" TYPE="xfs"
[root@servera ~]# umount /dev/save/old
[root@servera ~]# xfs_repair -n /dev/save/old
Only one AG detected - cannot validate filesystem geometry.
Use the -o force_geometry option to proceed.
[root@servera ~]# xfs_repair -n -o force_geometry /dev/save/old
- agno = 0
entry "iscsistorage_luks_header" in shortform directory 13800 references invalid
inode 1234567890
would have junked entry "iscsistorage_luks_header" in directory inode 13800
- agno = 0
inode 1234567890
would have junked entry "iscsistorage_luks_header" in directory inode 13800
6.3. Repare el sistema de archivos XFS.
[root@servera ~]# xfs_repair -o force_geometry /dev/save/old

- zero log...
RH342-RHEL7.2-es-1-20160321 183

- agno = 0
inode 1234567890
junking entry "iscsistorage_luks_header" in directory inode 13800
- agno = 0
done
Restored volume group save
6.4. Monte el sistema de archivos reparado. Según el informe de reparación del sistema
de archivos, esperamos encontrar el archivo iscsistorage_luks_header en el
directorio lost+found. Restáurelo en el directorio /mnt/save/luks.

[root@servera ~]# ls -la /mnt/save/lost+found/
ls -la /mnt/save/lost+found/
total 1028
-rw-r--r--. 1 root root 1052672 Jan 21 18:57 13801
[root@servera ~]# file /mnt/save/lost+found/13801
/mnt/save/lost+found/13801: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1]
UUID: b91a11a8-1bf1-4c9a-9f31-3cc2e8947476
[root@servera ~]# mv /mnt/save/lost+found/13801 /mnt/save/luks/
iscsistorage_luks_header
7. Con la copia de seguridad del encabezado de LUKS ubicado en /mnt/save/luks/

iscsistorage_luks_header, restaure el encabezado de LUKS en el volumen cifrado
ubicado en la partición /dev/sda1.
[root@servera ~]# cryptsetup luksHeaderRestore /dev/sda1 --header-backup-file /mnt/

save/luks/iscsistorage_luks_header
WARNING!
========
Device /dev/sda1 already contains LUKS header. Replacing header will destroy
existing keyslots.
8. Descifre el volumen cifrado con la última contraseña conocida y asígnelo a /dev/

mapper/finance.
184 RH342-RHEL7.2-es-1-20160321
Solución
[root@servera ~]# cryptsetup luksOpen /dev/sda1 finance

Enter passphrase for /dev/sda1:
9. Ponga a disposición el contenido del volumen cifrado en el punto de montaje /mnt/

finance.
[root@servera ~]# mkdir /mnt/finance

[root@servera ~]# mount /dev/mapper/finance /mnt/finance/
[root@servera ~]# ls -la /mnt/finance
total 0
drwxr-xr-x. 2 root root 6 Jan 21 14:57 accounts
drwxr-xr-x. 2 root root 6 Jan 21 14:57 customers
drwxr-xr-x. 2 root root 6 Jan 21 14:58 employees
drwxr-xr-x. 2 root root 6 Jan 21 14:57 loans
drwxr-xr-x. 2 root root 6 Jan 21 14:58 management
drwxr-xr-x. 2 root root 6 Jan 21 14:57 shareholders
[student@workstation ~]$ lab storage grade
ejercicios.
RH342-RHEL7.2-es-1-20160321 185
Resumen
• Los sistemas de archivos ext3 y ext4 se pueden verificar y reparar con el comando e2fsck.
• Los sistemas de archivos XFS se pueden verificar y reparar con el comando xfs_repair.
• Los archivos de LVM se guardan en /etc/lvm/archives.
• Los errores en la administración de LVM se pueden revertir con el comando

vgcfgrestore.
• Los encabezados de volumen de LUKS se pueden respaldar y restaurar con el comando

cryptsetup.
• Las fallas de descifrado de volumen de LUKS relacionadas con contraseñas desconocidas y

encabezados dañados pueden resolverse al restaurar el encabezado de LUKS al volumen
de LUKS.
• Por lo general, los problemas con las conexiones de iSCSI al servidor de destino son
generados por problemas de red en el caso de que la detección de destinos no se realice
correctamente.
• Por lo general, los problemas con las conexiones de iSCSI al servidor de destino son
generados por problemas de autenticación o ACL en el caso de que la detección de
destinos se realice correctamente.
186 RH342-RHEL7.2-es-1-20160321
TRAINING
CAPÍTULO 6
RPM
Visión general
Meta Identificar y resolver problemas en, y utilizando, el
subsistema de gestión de paquetes.
Objetivos • Resolver problemas de dependencia de la gestión de
paquetes manualmente.
• Recuperar una base de datos dañada de Red Hat

Package Management (RPM).
• Identificar y restaurar archivos cambiados a través del

subsistema de gestión de paquetes.
• Implementar las herramientas de gestión de

suscripciones de Red Hat para recibir actualizaciones.
Secciones • Resolución de problemas de dependencias (y ejercicio
guiado)
• Recuperación de una base de datos dañada de RPM (y

ejercicio guiado)
• Identificación y recuperación de archivos cambiados (y

ejercicio guiado)
• Suscripción de sistemas a actualizaciones de Red Hat (y

prueba)
Trabajo de laboratorio • Solución de problemas de RPM
RH342-RHEL7.2-es-1-20160321 187
Capítulo 6. Solución de problemas de RPM
Resolución de problemas de dependencia
Objetivos
de dependencia de paquetes.
Dependencias de paquetes
Las dependencias de paquetes ocurren cuando un paquete de RPM requiere una
funcionalidad proporcionada por otros paquetes de RPM. Estos requisitos de paquetes se
incluyen en los metadatos de cada paquete de RPM. El comando rpm no resuelve estas
dependencias. El comando yum resuelve dependencias y utiliza rpm para instalar o borrar un
paquete.
A pesar de los mejores intentos de Yum, a veces hay problemas de dependencias de RPM que
no se resolverán de manera predeterminada. Un ejemplo de esto puede observarse cuando
instala un paquete que requiere una versión específica de otro paquete, y una versión
incompatible diferente del paquete requerido ya está instalada en el sistema.
Cuando diagnostica problemas de dependencia de RPM, los registros del sistema no soy
muy útiles. Además de la base de datos de RPM, el registro /var/log/yum.log contiene un
historial de los paquetes instalados y eliminados. No hay mucha información detallada del
RPM. Invocar el comando rpm con la opción -v permite mostrar más información diagnóstica
en errores estándares cuando se ejecuta. Las opciones -v adicionales harán que rpm sea más
detallado.
Visualización de dependencias de paquetes

El comando yum deplist muestra una lista de dependencias del paquete que se pasan
como argumento en el comando. También imprime el nombre y la última versión del paquete
disponible para la instalación que cumple con cada dependencia.
[root@demo ~]# yum deplist yum

Loaded plugins: langpacks, search-disabled-repos, versionlock
package: yum.noarch 3.4.3-132.el7
dependency: /bin/bash
provider: bash.x86_64 4.2.46-19.el7
dependency: /usr/bin/python
provider: python.x86_64 2.7.5-34.el7
dependency: cpio
provider: cpio.x86_64 2.11-24.el7
dependency: diffutils
provider: diffutils.x86_64 3.3-4.el7
El comando rpm también puede utilizarse para mostrar información útil sobre la dependencia
de los paquetes. La opción --requires, o -R de manera abreviada, muestra los requisitos
para el paquete que se pasan como parámetro. No muestra tanta información como yum
deplist.
[root@demo ~]# rpm -q --requires yum

/bin/bash
/usr/bin/python
config(yum) = 3.4.3-132.el7
188 RH342-RHEL7.2-es-1-20160321
Uso de Yum para bloquear versiones de paquetes
cpio
diffutils
pygpgme
pyliblzma
python >= 2.4
python(abi) = 2.7
El comando rpm -q --provides muestra la lista de posibles requisitos que un paquete

proporciona para otros paquetes.
[root@demo ~]# rpm -q --provides yum

config(yum) = 3.4.3-132.el7
yum = 3.4.3-132.el7
yum-allow-downgrade = 1.1.20-0.yum
yum-basearchonly = 1.1.9.yum
yum-plugin-allow-downgrade = 1.1.22-0.yum
yum-plugin-basearchonly = 1.1.9.yum
yum-plugin-downloadonly = 3.4.3-44.yum
Resolución de dependencias de paquetes

Yum tiene un subcomando downgrade que instala la versión anterior de la versión instalada
actualmente para el paquete especificado como el argumento. Borra la versión más reciente
del paquete e instala la versión anterior en su lugar. Este comando puede instalar una
versión anterior de un paquete si se indicó la versión específica. Funciona para paquetes que
solo permiten que se instale una versión de un paquete a la vez en el sistema. No funciona
para paquetes de "solo instalación", como el kernel de Linux.
nota
Si la instalación de una versión anterior del paquete es un requisito previo para
otros paquetes instalados en el sistema, también se puede especificar e instalar una
versión anterior de los paquetes dependientes.
RPM proporciona una funcionalidad similar con la opción --oldpackage. Esta opción se
utiliza con el comando rpm -U. Le indica a la actualización de RPM que instale la versión
anterior de un paquete instalado.
El comando rpm -U --force es lo mismo que utilizar las opciones --oldpackage, --

replacepkgs y --replacefiles a la vez. La opción --replacepkgs le indica a RPM que
instale los paquetes especificados, incluso si algunos ya están instalados en el sistema. La
opción --replacefiles instalará los paquetes especificados, incluso si reemplazan archivos
de otros paquetes ya instalados.
Uso de Yum para bloquear versiones de paquetes

Yum tiene un complemento (plug-in) que permite que un administrador bloquee un paquete
(o un grupo de paquetes) con una versión específica. El paquete yum-plugin-versionlock
proporciona esa funcionalidad mejorada. Una vez que instala el paquete, el comando yum
admitirá un nuevo subcomando versionlock.
Comando Función
yum versionlock list Muestra la lista de versiones bloqueadas del
paquete.
RH342-RHEL7.2-es-1-20160321 189
Comando Función
yum versionlock add WILDCARD Bloquea las versiones actuales de los
paquetes que coinciden con el comodín.
yum versionlock delete WILDCARD Elimina los bloqueos que coinciden con el
comodín.
yum versionlock clear Elimina todos los bloqueos de versión del
paquete.
Una vez que se bloquea una versión específica de un paquete, Yum no intentará actualizar el
paquete cuando se ejecute el comando yum update.
El comando yum list --showduplicates puede utilizarse para encontrar todas las
versiones disponibles de un paquete.
Referencias
Páginas del manual: rpm(8), yum(8), yum-versionlock(1)
190 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Resolución de problemas de dependencia

dependencia
En este trabajo de laboratorio, resolverá un problema de dependencia de un paquete y,

luego, bloqueará el paquete de requisito previo con la versión específica requerida.
Recursos
• servera
Resultados
Deberá poder resolver problemas de dependencia de paquetes.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab package-
dependencies setup en su sistema workstation.
[student@workstation ~#$ lab package-dependencies setup
El equipo de seguridad actualizó los requisitos de su sistema para los hosts en el centro de
datos. Parte de esa actualización requiere la instalación de un paquete personalizado, rht-
main, en cada host.
Uno de sus colegas intentó instalar rht-main en servera sin éxito. Se le ha pedido que
resuelva este problema y que instale el paquete.
1. Utilice Yum para instalar el paquete rht-main. Revise los mensajes de error en busca de
información útil.
[root@servera ~]# yum -y install rht-main

Loaded plugins: langpacks, search-disabled-repos
Resolving Dependencies
--> Running transaction check
---> Package rht-main.noarch 0:0.1-1.el7 will be installed
--> Processing Dependency: rht-prereq = 0.1 for package: rht-main-0.1-1.el7.noarch
--> Finished Dependency Resolution
Error: Package: rht-main-0.1-1.el7.noarch (rht_lab)
Requires: rht-prereq = 0.1
Installed: rht-prereq-0.2-1.el7.noarch (@rht_lab)
rht-prereq = 0.2-1.el7
Available: rht-prereq-0.1-1.el7.noarch (rht_lab)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
2. El paquete rht-main requiere la instalación de una versión específica del paquete rht-
prereq, concretamente la versión 0.1. Se ha instalado una versión más reciente en el
sistema. Utilice Yum para instalar la versión anterior del paquete.
[root@servera ~]# yum -y downgrade rht-prereq

RH342-RHEL7.2-es-1-20160321 191
---> Package rht-prereq.noarch 0:0.1-1.el7 will be a downgrade
---> Package rht-prereq.noarch 0:0.2-1.el7 will be erased
3. Ahora que se instaló el software de requisito previo, utilice Yum para instalar el paquete
rht-main requerido.
[root@servera ~]# yum install -y rht-main

---> Package rht-main.noarch 0:0.1-1.el7 will be installed
Installed:
rht-main.noarch 0:0.1-1.el7
Complete!
4. Ahora que se instaló el paquete rht-main, intente actualizar el paquete de requisito

previo, rht-prereq. Yum intentará actualizar el paquete, pero debido a las dependencias,
generará mensajes de error y fallará.
[root@servera ~]# yum update rht-prereq

---> Package rht-prereq.noarch 0:0.1-1.el7 will be updated
--> Processing Dependency: rht-prereq = 0.1 for package: rht-main-0.1-1.el7.noarch
---> Package rht-prereq.noarch 0:0.2-1.el7 will be an update
Error: Package: rht-main-0.1-1.el7.noarch (@rht_lab)
Requires: rht-prereq = 0.1
Removing: rht-prereq-0.1-1.el7.noarch (@rht_lab)
Updated By: rht-prereq-0.2-1.el7.noarch (rht_lab)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
5. Yum tiene un complemento (plug-in) que permite que un administrador bloquee un

paquete con una versión específica. Utilice Yum para generar una lista de paquetes de
complementos (plug-ins) de Yum disponibles.
[root@servera ~]# yum list available yum-plugin*

Available Packages
yum-plugin-aliases.noarch 1.1.31-34.el7 rhel_dvd
yum-plugin-changelog.noarch 1.1.31-34.el7 rhel_dvd
yum-plugin-ovl.noarch 1.1.31-34.el7 rhel_dvd
yum-plugin-tmprepo.noarch 1.1.31-34.el7 rhel_dvd
yum-plugin-verify.noarch 1.1.31-34.el7 rhel_dvd
yum-plugin-versionlock.noarch 1.1.31-34.el7 rhel_dvd
192 RH342-RHEL7.2-es-1-20160321
El paquete yum-plugin-versionlock proporcionará la funcionalidad requerida. Use Yum
para instalarla.
[root@servera ~]# yum -y install yum-plugin-versionlock

Installed:
yum-plugin-versionlock.noarch 0:1.1.31-34.el7
Complete!
6. El paquete yum-plugin-versionlock agrega un subcomando versionlock al comando yum.

Si ejecuta yum versionlock list, se enumeran los paquetes que están bloqueados.
Inicialmente, no hay versiones de paquetes bloqueadas.
[root@servera ~]# yum versionlock list

versionlock list done
Especifique el nombre del paquete rht-prereq como un argumento para yum

versionlock add. Esto le indicará a Yum que bloquee la versión actual del paquete.
[root@servera ~]# yum versionlock add rht-prereq

Adding versionlock on: 0:rht-prereq-0.1-1.el7
versionlock added: 1
[root@servera ~]# yum versionlock list
0:rht-prereq-0.1-1.el7.*
versionlock list done
7. Intente actualizar el paquete rht-prereq.
[root@servera ~]# yum update rht-prereq

No packages marked for update
Yum lo ignorará y ya no imprimirá mensajes de error.
8. Cuando finalice, verifique su trabajo ejecutando el comando lab package-

dependencies grade desde su máquina workstation.
[student@workstation ~]$ lab package-dependencies grade
[student@workstation ~]$ lab package-dependencies reset
RH342-RHEL7.2-es-1-20160321 193
Recuperación de una base de datos dañada

de RPM
Objetivos
Después de completar esta sección, los estudiantes podrán identificar y volver a desarrollar
una base de datos dañada de RPM.
Base de datos dañada de RPM

Cuando utiliza yum o rpm para instalar o borrar paquetes en un sistema de Red Hat
Enterprise Linux, las bases de datos de RPM locales se actualizan con información acerca de
los paquetes que se administran. La base de datos de RPM consta de una variedad de filas en
el directorio /var/lib/rpm/. Estos son todos archivos de la base de datos Berkeley, excepto
los archivos de índice __db.*.
En algunas ocasiones, la base de datos de RPM puede dañarse por una variedad de razones.
Utilice los siguientes pasos para reparar una base de datos dañada. Preste atención a los
mensajes de error que aparecen.
1. Elimine los archivos de bloqueo obsoletos y elimine los índices de la base de datos para
evitar problemas de bloqueo adicionales.
[root@demo ~]# lsof | grep /var/lib/rpm

[root@demo ~]# rm /var/lib/rpm/__db*
rm: remove regular file `/var/lib/rpm/__db.001'? y
2. Realice una copia de seguridad de los archivos de la base de datos de RPM.
[root@demo ~]# tar cjvf rpmdb-$(date +%Y%m%d-%H%M).tar.bz2 /var/lib/rpm

tar: Removing leading `/' from member names
/var/lib/rpm/
/var/lib/rpm/.dbenv.lock
/var/lib/rpm/Packages
/var/lib/rpm/Name
/var/lib/rpm/Basenames
/var/lib/rpm/Group
/var/lib/rpm/Requirename
/var/lib/rpm/Providename
/var/lib/rpm/Conflictname
/var/lib/rpm/Obsoletename
/var/lib/rpm/Triggername
/var/lib/rpm/Dirnames
/var/lib/rpm/Installtid
/var/lib/rpm/Sigmd5
/var/lib/rpm/Sha1header
/var/lib/rpm/.rpm.lock
3. Verifique la integridad de la base de datos de RPM.
[root@demo ~]# cd /var/lib/rpm
194 RH342-RHEL7.2-es-1-20160321
Base de datos dañada de RPM
[root@demo rpm]# /usr/lib/rpm/rpmdb_verify Packages

rpmdb_verify: BDB0682 Page 32: bad prev_pgno 0 on overflow page (should be 31)
rpmdb_verify: BDB0683 Page 32: overflow item incomplete
rpmdb_verify: Packages: BDB0090 DB_VERIFY_BAD: Database verification failed
BDB5105 Verification of Packages failed.
4. Si es necesario, realice un volcado de la base de datos dañada y utilícelo para crear un

archivo de base de datos intacto.
[root@demo rpm]# mv Packages Packages.bad

[root@demo rpm]# /usr/lib/rpm/rpmdb_dump Packages.bad |
> /usr/lib/rpm/rpmdb_load Packages
[root@demo rpm]# /usr/lib/rpm/rpmdb_verify Packages
BDB5105 Verification of Packages succeeded.
5. Vuelva a desarrollar los índices de la base de datos de RPM.
[root@demo rpm]# rpm -v --rebuilddb

error: rpmdbNextIterator: skipping h# 4 region trailer: BAD, tag 0 type 0
offset 0 count 0
En este momento, las operaciones de RPM adicionales no deberían producir mensajes de

error.
Si la base de datos de RPM restaurada tiene un pequeño subconjunto de los paquetes

originales, consulte /var/log/yum.log para identificar los paquetes que faltan. Se puede
usar el comando rpm --justdb para actualizar la base de datos de RPM sin realizar cambios
al sistema de archivos del host.
Referencias
Página del manual: rpm(8)
Para obtener más información, consulte el

Documento de recuperación de base de datos de RPM
http://www.rpm.org/wiki/Docs/RpmRecovery
RH342-RHEL7.2-es-1-20160321 195
Ejercicio guiado: Recuperación de una base

de datos dañada de RPM
En este trabajo de laboratorio, reparará una base de datos dañada de un paquete de RPM.
Recursos
• servera
Resultados
Deberá poder diagnosticar y reparar una base de datos dañada de un paquete de RPM.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab package-database
[student@workstation ~#$ lab package-database setup
Uno de los administradores de sistemas junior recibió la tarea de instalar un servidor

web Apache en uno de los servidores en su organización. Cuando comenzó a instalar el
paquete httpd con Yum, apareció un mensaje de error que lo preocupó, por lo que detuvo la
instalación y lo llamó para que lo ayude a descubrir qué le ocurría al sistema.
1. Primero, vea si puede reproducir el error que el administrador junior observó. Comience
una instalación Yum del paquete httpd, pero decline la instalación antes de que Yum
realice cambios al sistema.
[root@servera ~]# yum install httpd

---> Package httpd.x86_64 0:2.4.6-40.el7 will be installed
--> Processing Dependency: httpd-tools = 2.4.6-40.el7 for package:
httpd-2.4.6-40.el7.x86_64
offset 0 count 0
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package:
httpd-2.4.6-40.el7.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package:
httpd-2.4.6-40.el7.x86_64
---> Package apr.x86_64 0:1.4.8-3.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-40.el7 will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
offset 0 count 0
Is this ok [y/d/N]: n
Exiting on user command
Your transaction was saved, rerun it with:
196 RH342-RHEL7.2-es-1-20160321
yum load-transaction /tmp/yum_save_tx.2016-01-11.17-24.mjLElP.yumtx
2. Revise los registros del sistema en busca de mensajes de error relacionados a este
problema. /var/log/messages y /var/log/yum.log son buenos lugares para
comenzar a buscar.
[root@servera ~]# tail /var/log/messages

Jan 11 20:23:16 servera systemd: Started Session 16 of user root.
Jan 11 20:23:16 servera systemd: Starting Session 16 of user root.
Jan 11 20:23:16 servera systemd-logind: Removed session 16.
Jan 11 20:24:28 servera systemd: Started Session 17 of user root.
Jan 11 20:24:28 servera systemd-logind: New session 17 of user root.
Jan 11 20:24:28 servera systemd: Starting Session 17 of user root.
Jan 11 20:24:29 servera dbus[507]: [system] Activating service
name='org.freedesktop.problems' (using servicehelper)
Jan 11 20:24:29 servera dbus-daemon: dbus[507]: [system] Activating service
Jan 11 20:24:29 servera dbus[507]: [system] Successfully activated service
'org.freedesktop.problems'
Jan 11 20:24:29 servera dbus-daemon: dbus[507]: [system] Successfully activated
service 'org.freedesktop.problems'
[root@servera ~]# tail /var/log/yum.log
Dec 15 15:25:26 Installed: cryptsetup-1.6.7-1.el7.x86_64
Dec 15 15:25:27 Installed: words-3.0-22.el7.noarch
Aparentemente no brindan información útil para resolver este tipo de problema.
3. Realice una consulta simple de paquete de RPM y vea si produce un mensaje de error.
[root@servera ~]# rpm -q redhat-release-server

redhat-release-server-7.2-9.el7.x86_64
No se muestra información de diagnóstico útil.
4. Realice una consulta de paquete de RPM más exhaustiva.
[root@servera ~]# rpm -qa

El comando rpm -qa generó un mensaje de error útil, pero desapareció de la pantalla
antes de que pudiera leerlo. Redireccionar el resultado estándar del comando le
permitirá ver solo los mensajes de error.
[root@servera ~]# rpm -qa > /dev/null

offset 0 count 0
5. Identifique y elimine los bloqueos obsoletos. Elimine los índices de la base de datos de
RPM.
[root@servera ~]# lsof | grep /var/lib/rpm

[root@servera ~]# rm /var/lib/rpm/__db*
rm: remove regular file ‘/var/lib/rpm/__db.001’? y
RH342-RHEL7.2-es-1-20160321 197

6. Realice una copia de seguridad de los archivos de la base de datos de RPM antes de
realizar más cambios.
[root@servera ~]# tar cjvf rpmdb-$(date +%Y%m%d-%H%M).tar.bz2 /var/lib/rpm

tar: Removing leading `/' from member names
/var/lib/rpm/
7. Utilice rpmdb_verify para verificar el contenido de la base de datos de RPM Packages.
[root@servera ~]# cd /var/lib/rpm

[root@servera rpm]# /usr/lib/rpm/rpmdb_verify Packages
rpmdb_verify: BDB0682 Page 32: bad prev_pgno 0 on overflow page (should be 31)
rpmdb_verify: BDB0683 Page 32: overflow item incomplete
rpmdb_verify: Packages: BDB0090 DB_VERIFY_BAD: Database verification failed
BDB5105 Verification of Packages failed.
8. Realice una copia de seguridad de la base de datos de RPM Packages. Utilice

rpmdb_dump y rpmdb_load para crear un archivo de base de datos de RPM Packages
intacto.
[root@host rpm]# mv Packages Packages.broken

[root@host rpm]# /usr/lib/rpm/rpmdb_dump Packages.broken | \
> /usr/lib/rpm/rpmdb_load Packages
[root@host rpm]# /usr/lib/rpm/rpmdb_verify Packages
BDB5105 Verification of Packages succeeded.
9. Utilice rpm --rebuilddb para crear nuevos índices de base de datos de RPM.
[root@servera rpm]# rpm --rebuilddb

offset 0 count 0
10. Ejecute el comando rpm -qa nuevamente y muestre solo los mensajes de error
estándar.
[root@servera rpm]# rpm -qa > /dev/null
No se muestran mensajes de error. Se corrige la base de datos dañada.
11. Cuando finalice, verifique su trabajo ejecutando el comando lab package-

dependencies grade desde su máquina workstation.
[student@workstation ~]$ lab package-database grade
198 RH342-RHEL7.2-es-1-20160321
[student@workstation ~]$ lab package-database reset
RH342-RHEL7.2-es-1-20160321 199
Identificación y recuperación de archivos

cambiados
Objetivos
Después de completar la sección, los estudiantes podrán identificar y restaurar archivos
cambiados que pertenecen a la administración de paquetes.
Verificación de paquetes instalados

Una de las principales ventajas de la administración de paquetes de RPM es la base de datos
de RPM local. Cada vez que se instala un paquete de RPM, la información acerca de cada uno
de los archivos que proporciona se registra en la base de datos de RPM. Esta información
incluye tamaños de archivos, marcas de tiempo de creación, sumas de control de contenido,
permisos y propiedades de usuarios/grupos. Los archivos proporcionados por los paquetes
de RPM pueden verificarse gracias a los datos que se encuentran en la base de datos de RPM.
Verificación de paquetes con RPM

La verificación de un paquete instalado compara los atributos de los archivos que
proporciona con la base de datos de RPM. Se informará cualquier tipo de inconsistencia. El
comando rpm -V verifica los paquetes especificados como argumentos del comando. rpm
-Va verificará los archivos de todos los paquetes instalados en el sistema. Por lo general, el
comando es silencioso, a menos que descubra discrepancias entre el sistema de archivos
y la base de datos de RPM. Cuando se encuentra una diferencia, rpm imprime el nombre
del archivo y una cadena que indica cuáles son los atributos del archivo que son diferentes.
Tenga en cuenta el siguiente resultado de muestra.
[root@demo ~]# rpm -Va

missing /var/run/wpa_supplicant
SM5....T. c /etc/ssh/sshd_config
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....L.... c /etc/pam.d/postlogin
....L.... c /etc/pam.d/smartcard-auth
....L.... c /etc/pam.d/system-auth
....L.... c /etc/rc.d/rc.local
S.5....T. c /etc/systemd/logind.conf
.M....... /var/lib/nfs/rpc_pipefs
.M....... /run/cloud-init
La primera cadena de caracteres es una máscara de los atributos del archivo. Los puntos
se muestran para los atributos que coinciden con la base de datos. En la siguiente tabla se
enumeran los campos más comunes de los atributos de archivo.
Letra Atributo de archivo

S Tamaño de archivo
M Modo (permisos, incluido el tipo de archivo)
5 Contenido (resumen, anteriormente el checksum de MD5)
L Un enlace simbólico que apunta a una ubicación diferente
200 RH342-RHEL7.2-es-1-20160321
Verificación de paquetes instalados
Letra Atributo de archivo

U Propiedad del usuario
G Propiedad del grupo
T Hora de modificación
De manera opcional, es posible que rpm -V muestre un carácter antes del nombre del
archivo. Este carácter representa el tipo de archivo de RPM que el desarrollador del paquete
especificó. En la siguiente tabla se enumeran los tipos de archivo de RPM más comunes
especificados.
Letra Tipo de archivo

c %config archivo de configuración
d %doc archivo de documentación
l %license archivo de licencia
r %readme archivo léame
Verificación de paquetes con Yum

Yum también puede verificar paquetes instalados. Esta funcionalidad no está disponible
de manera predeterminada. El paquete yum-plugin-verify agrega los subcomandos verify,
verify-rpm y verify-all al comando yum.
El comando yum verify muestra información detallada acerca de las diferencias de

archivos, pero excluye los archivos de configuración sin otras opciones. Este supuesto se basa
en el hecho de que los cambios del archivo de configuración son normales. El subcomando
verify-rpm incluye archivos de configuración cuando difieren de su estado original.
[root@demo ~]# rpm -V openssh-server

SM5....T. c /etc/ssh/sshd_config
[root@demo ~]# yum verify openssh-server
Loaded plugins: langpacks, search-disabled-repos, verify, versionlock
verify done
[root@demo ~]# yum verify-rpm openssh-server
Loaded plugins: langpacks, search-disabled-repos, verify, versionlock
==================== Installed Packages ====================
openssh-server.x86_64 : An open source SSH server daemon
File: /etc/ssh/sshd_config
Tags: configuration
Problem: checksum does not match
Current: sha256:0b94e3b6ef4f76f8d0c2b324bd5ba5b93aa778...
Original: sha256:bbd30bfaf820eeda7ab43b61a66d48a4d4fc67...
--------
Problem: size does not match
Current: 4386 B
Original: 4361 B
--------
Problem: mode does not match
Current: user:wr-, group:-r-, other:-r-
Original: user:wr-, group:---, other:---
--------
Problem: mtime does not match
Current: Tue Dec 15 12:26:40 2015 (81 days, 11:44:07 later)
Original: Fri Sep 25 00:42:33 2015
verify-rpm done
RH342-RHEL7.2-es-1-20160321 201
Tenga en cuenta que los comandos yum verify producen un resultado más legible. Además
de imprimir las diferencias de archivos, los comandos imprimen los valores comparables del
sistema de archivos y de la base de datos de RPM.
Recuperación de archivos cambiados

El comando rpm tiene una opción --setperms que restaurará los permisos de archivo de
los archivos instalados por los paquetes especificados como argumentos en el comando. La
siguiente secuencia de comandos muestra cómo rpm --setperms restablece los permisos
de archivos en un paquete.
[root@demo ~]# rpm -V setup

.M....G.. c /etc/motd
[root@demo ~]# rpm --setperms setup
......G.. c /etc/motd
Tenga en cuenta que la propiedad del grupo del archivo de ejemplo aún no coincide con su
propiedad original en la base de datos de RPM. El comando rpm --setugids restaura las
propiedades de usuario o grupo de los archivos en un paquete a sus valores originales.
[root@demo ~]# rpm --setugids setup

Se puede usar el comando yum reinstall para recuperar archivos modificados que
pertenecen a un paquete. Este comando reinstala la versión idéntica de un paquete que está
instalado actualmente. Funciona para paquetes que solo permiten que se instale una versión
de un paquete a la vez en el sistema. No funciona para paquetes de "solo instalación", como
el kernel de Linux.
El siguiente resultado de ejemplo muestra cómo yum reinstall restaura un ejecutable

modificado. El primer comando rpm -V confirma que el tamaño, el contenido y las marcas de
tiempo de /usr/sbin/vsftpd difieren de sus valores originales en la base de datos de RPM.
El segundo comando rpm -V no muestra resultados debido a que se reinstaló el archivo
modificado en el sistema de archivos.
[root@demo ~]# rpm -V vsftpd

S.5....T. /usr/sbin/vsftpd
[root@demo ~]# yum -y reinstall vsftpd
Transaction test succeeded
Running transaction
Installing : vsftpd-3.0.2-10.el7.x86_64 1/1
Verifying : vsftpd-3.0.2-10.el7.x86_64 1/1
Installed:
vsftpd.x86_64 0:3.0.2-10.el7
Complete!
[root@demo ~]# rpm -V vsftpd
202 RH342-RHEL7.2-es-1-20160321
Recuperación de archivos cambiados
Referencias
Páginas del manual: rpm(8), yum(8), yum-verify(1)
RH342-RHEL7.2-es-1-20160321 203
Ejercicio guiado: Identificación y

recuperación de archivos cambiados
En este trabajo de laboratorio, diagnosticará y corregirá permisos de archivos y archivos

dañados que pertenecen a paquetes.
Recursos
• servera
Resultados
Deberá poder diagnosticar y corregir problemas de permiso de archivos y archivos dañados a
través de rpm y yum.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab broken-commands
[student@workstation ~#$ lab broken-commands setup
Recibe informes en donde se indica que algunos de los comandos de servera están
dañados. Los usuarios no pueden enumerar archivos con ls, y el comando sudo no tiene un
comportamiento adecuado. Se le ha pedido que diagnostique y corrija estos problemas.
1. Inicie sesión como root en servera. Aparece un mensaje de error cuando inicia sesión
que le da una pista acerca del primer comando dañado que necesita solución.

Last login: Tue Jan 5 20:25:01 2016 from workstation.lab.example.com
-bash: /usr/bin/ls: Permission denied
[root@servera ~]#
2. Utilice rpm para identificar el paquete del que proviene el comando y verifique el
contenido del paquete.
[root@servera ~]# rpm -qf /usr/bin/ls

coreutils-8.22-15.el7.x86_64
[root@servera ~]# rpm -V coreutils
.M....... /usr/bin/ls
La M en el resultado indica un cambio en los permisos, o el modo, de /usr/bin/ls.

Todos los otros atributos acerca del archivo son los mismos que cuando se produjo la
instalación.
3. Utilice rpm para restaurar los permisos de los archivos en el paquete coreutils.
[root@servera ~]# rpm --setperms coreutils
204 RH342-RHEL7.2-es-1-20160321
4. Compruebe que se haya corregido el comando. Vuelva a verificar el paquete coreutils y
vea si ls está funcionando nuevamente.
[root@servera ~]# rpm -V coreutils

[root@servera ~]# ls
anaconda-ks.cfg
5. Ahora es el momento de resolver el problema con sudo. Inicie sesión como student en
servera e intente usar sudo para obtener acceso al conteo de palabras en /etc/ssh/
sshd_config.
[student@servera ~]$ sudo wc -l /etc/ssh/sshd_config

bash: /usr/bin/sudo: Permission denied
6. Determine el paquete que proporciona el comando sudo.
[student@servera ~]$ which sudo

/usr/bin/sudo
[student@servera ~]$ rpm -qf /usr/bin/sudo
sudo-1.8.6p7-16.el7.x86_64
7. Inicie sesión como root en servera. Utilice rpm -V para verificar el paquete que
proporciona el comando sudo.
[root@servera ~]# rpm -V sudo

S.5....T. c /etc/sudoers
..5....T. /usr/bin/sudo
[root@servera ~]# ls -l /usr/bin/sudo
---s--x--x. 1 root root 130712 Jan 5 20:52 /usr/bin/sudo
Indica que ha cambiado el contenido y la marca de tiempo del ejecutable.
8. Utilice el comando yum reinstall para reparar el paquete instalado. Verifique el

paquete cuando el comando termine de confirmar que se ha restaurado el ejecutable.
[root@servera ~]# yum -y reinstall sudo

Installed:
sudo.x86_64 0:1.8.6p7-16.el7
Complete!
[root@servera ~]# rpm -V sudo
S.5....T. c /etc/sudoers
El ejecutable no aparece en el resultado rpm -V, por lo que se ha restaurado.
9. Inicie sesión nuevamente como student en servera y compruebe que sudo esté
funcionando.
[student@servera ~]$ sudo wc -l /etc/ssh/sshd_config

[sudo] password for student: student
152 /etc/ssh/sshd_config
RH342-RHEL7.2-es-1-20160321 205
10. Cuando finalice, verifique su trabajo ejecutando el comando lab broken-commands

grade desde su máquina workstation.
[student@workstation ~]$ lab broken-commands grade
[student@workstation ~]$ lab broken-commands reset
206 RH342-RHEL7.2-es-1-20160321
Suscripción de sistemas a actualizaciones de Red Hat
Suscripción de sistemas a actualizaciones de

Red Hat
Objetivos
Después de completar esta sección, los estudiantes deberán poder registrar un sistema con
Red Hat y administrar suscripciones de Red Hat.
Los sistemas Red Hat Enterprise Linux deben estar autorizados para recibir paquetes
de software. Las aplicaciones de Red Hat Subscription Manager (RHSM) se utilizan para
administrar las autorizaciones de software de un host. Red Hat Subscription Manager utiliza
certificados X.509 en un host para controlar el estado de su suscripción. El proceso de
autorización es un proceso que consta de tres pasos.
1. Los productos se agregan a un sistema. Los certificados de productos del sistema

identifican los productos que ha instalado. Este paso se lleva a cabo cuando se instala el
sistema y cuando se instala software adicional.
2. Registre el sistema con Red Hat directamente o un servidor de Red Hat Satellite. Este
paso se lleva a cabo una vez y se coloca un certificado de identidad en el sistema.
3. Asocie suscripciones al sistema. Los certificados de autorización se almacenan

localmente una vez que se completa este paso.
Los certificados X.509 tienen fechas de caducidad y se pueden actualizar cuando se ponen
a disposición nuevos certificados. Yum tiene un complemento (plug-in) subscription-
manager que hace que funcione con el sistema de Red Hat Subscription Management. El
servicio rhsmcertd verifica regularmente la configuración del sistema para confirmar que los
certificados de autorización estén al día y para identificar actualizaciones de certificados.
El uso de certificados brinda beneficios en el momento de solucionar problemas. Este

enfoque permite que un administrador determine los productos que se instalan en un
sistema y las suscripciones que se consumen. El enfoque del Red Hat Subscription Manager
es la administración de suscripciones, no la administración de contenido o del sistema.
Los sistemas cliente de Red Hat Subscription Manager deben poder contactar al
servicio de administración de suscripciones y a la red de entrega de contenido. De
manera predeterminada, se puede acceder a ambos servicios de red a través del puerto
443. La configuración de Internet predeterminada define el servidor de RHSM como
subscription.rhn.redhat.com. El nombre de host para el servidor de entrega de
contenido es cdn.redhat.com.
subscription-manager-gui
En máquinas gráficas donde X está instalado, puede utilizar subscription-manager-
gui para configurar y administrar suscripciones de software de Red Hat. Puede ejecutar
subscription-manager-gui desde una shell o al seleccionar el elemento de menú
Applications (Aplicaciones) > System Tools (Herramientas del sistema) > Red Hat
Subscription Manager desde el escritorio.
Cuando se ejecuta subscription-manager-gui por primera vez, aparece una ventana

en la que se muestra el estado de RHSM del sistema actual. Se seleccionará la pestaña
RH342-RHEL7.2-es-1-20160321 207
My Installed Products (Mis productos instalados). Se mostrará una lista de productos

ya instalados en el sistema en el cuadro de la parte superior de la pantalla. Se mostrará
información adicional acerca del producto seleccionado actualmente en la ventana inferior.
Figura 6.1: Pestaña My Installed Products (Mis productos instalados) de subscription-manager-gui
Si hace clic en el botón Register (Registrarse) en esta pantalla, se iniciará el proceso de

registro de RHSM. Aparecerá el cuadro de diálogo System Registration (Registro del sistema).
Figura 6.2: Selección de host de registro
El host subscription.rhn.redhat.com se selecciona de manera predeterminada, pero un

administrador puede proporcionar el nombre de host para un servidor de Red Hat Satellite
en su lugar. Si la máquina que está registrando tiene que usar un proxy para acceder al
host de RHSM, debe seleccionar Configure Proxy (Configurar proxy) y debe proporcionar la
información de conexión del proxy.
Una vez que haya seleccionado el host de registro, si hace clic en Next (Siguiente), aparecerá
la próxima pantalla System Registration (Registro del sistema). Aquí se le pedirán las
208 RH342-RHEL7.2-es-1-20160321
subscription-manager-gui
credenciales de inicio de sesión del Portal de clientes de Red Hat, o una cuenta de Red Hat
Satellite si se seleccionó un servidor de Satellite.
Figura 6.3: Autenticación del Portal de clientes de Red Hat
nota
Si se seleccionó la casilla de verificación I will use an Activate Key (Utilizaré una
clave activa) en la pantalla anterior, el administrador puede proporcionar el nombre
de una clave de activación y la organización de Satellite en la que está definida.
Una vez que se registre el sistema con el RHSM, se mostrará la pestaña My Installed
Products (Mis productos instalados), pero el estado del producto cambiará de Unknown
(Desconocido) a Not Subscribed (No suscrito).
Figura 6.4: Host registrado, pero no suscrito
RH342-RHEL7.2-es-1-20160321 209
Aparecerá otra pestaña, All Available Subscriptions (Todas las suscripciones disponibles).
Haga clic en esta pestaña para ver las suscripciones de RHSM que se pueden asociar al
sistema.
Figura 6.5: Enumeración de suscripciones disponibles
Una vez que se selecciona la suscripción deseada, se hace clic en el botón Attach (Asociar).
Se asociará la suscripción al sistema, o aparecerá un cuadro de diálogo Contract Selection
(Selección de contrato) adicional si la suscripción tiene varios tipos de contratos asociados.
Figura 6.6: Elección del contrato específico
Si el host tiene varios productos instalados, es posible que deba asociar varias suscripciones
para cubrir todos los productos instalados. A medida que se cumple con cada requisito de la
suscripción, el estado de los productos cambiará a Subscribed (Suscrito).
210 RH342-RHEL7.2-es-1-20160321
subscription-manager
Figura 6.7: Host suscrito correctamente
Red Hat Subscription Management también tiene una utilidad basada en texto para
administrar suscripciones del sistema, subscription-manager. subscription-manager
proporciona todas las funcionalidades de subscription-manager-gui, pero se utilizan
opciones de línea de comandos para sobrescribir los valores predeterminados. Por ejemplo,
se puede especificar la opción --serverurl=HOSTNAME para que señale a un host de RHSM
diferente a subscription.rhn.redhat.com.
El comando subscription-manager register registra un host con RHSM. Se pueden

especificar el nombre de usuario y la contraseña del Portal de clientes de Red Hat con
las opciones --username y --password. Si no se especifican, subscription-manager
pedirá el nombre de usuario y la contraseña. También puede especificar las credenciales de
autenticación y el host proxy con estas opciones.
[root@demo ~]# subscription-manager register

Username: rhn-test-user
Password: SecretPassw0rd!
The system has been registered with ID: 89062c77-0deb-471b-92f2-586a60829017
Después del registro, el comando subscription-manager status mostrará una lista de

los productos instalados y sus estados actuales.
[root@demo ~]# subscription-manager status

+-------------------------------------------+
System Status Details
+-------------------------------------------+
Overall Status: Invalid
Red Hat Enterprise Linux Server:

- Not supported by a valid subscription.
Ahora, puede instalar suscripciones en los productos instalados. La opción --auto-attach

puede haber instalado suscripciones necesarias durante el registro del sistema, pero es
RH342-RHEL7.2-es-1-20160321 211
posible que tengan un efecto secundario no deseado de consumir suscripciones de alto

nivel de servicio de soporte en una máquina de no producción. En cambio, las suscripciones
específicas se pueden asociar manualmente. El siguiente comando subscription-manager
list enumera todas las suscripciones disponibles que pueden asociarse a este sistema. Las
entradas Provides (Proporciona) muestran los productos que cada suscripción admitirá.
[root@demo ~]# subscription-manager list --available

+-------------------------------------------+
Available Subscriptions
+-------------------------------------------+
Subscription Name: 60 Day Self-Supported Red Hat Enterprise Linux OpenStack
Platform Preview
Provides: Red Hat OpenStack
Red Hat Enterprise Linux Server
Red Hat Software Collections (for RHEL Server)
Oracle Java (for RHEL Server)
Red Hat Enterprise MRG Messaging
Red Hat Enterprise Linux High Availability (for RHEL Server)
Red Hat Enterprise Linux Load Balancer (for RHEL Server)
SKU: SER0123
Contract: 98765432
Pool ID: 0123456789abcdef0123456789abcdef
Available: Unlimited
Suggested: 1
Service Level: Self-Support
Service Type: L1-L3
Subscription Type: Standard
Ends: 01/28/2016
System Type: Virtual
El valor del campo Pool ID (ID de conjunto) de la suscripción deseada se pasa a

subscription-manager attach con la opción --pool.
[root@demo ~]# subscription-manager attach --pool 0123456789abcdef0123456789abcdef

Successfully attached a subscription for: 60 Day Self-Supported Red Hat
Enterprise Linux OpenStack Platform Preview
[root@demo ~]# subscription-manager status
+-------------------------------------------+
System Status Details
+-------------------------------------------+
Overall Status: Current
El comando subscription-manager repos administra los repositorios de software que los

productos suscritos ponen a disposición. La opción --list muestra todos los repositorios
de software disponibles con su estado actual. --enable REPO_ID habilita el repositorio
especificado. La opción --disable deshabilita el repositorio especificado. Puede especificar
comodines para vincular varios ID de repositorio.
[root@demo ~]# subscription-manager repos --list

+----------------------------------------------------------+
Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID: rhel-7-server-v2vwin-1-debug-rpms
Repo Name: Red Hat Virt V2V Tool for RHEL 7 (Debug RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basear
ch/v2vwin/debug
212 RH342-RHEL7.2-es-1-20160321
Enabled: 0
Repo ID: rhel-7-server-rpms

Repo Name: Red Hat Enterprise Linux 7 Server (RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basear
ch/os
Enabled: 1
El comando subscription-manager remove elimina las suscripciones asociadas. Hay

varias maneras diferentes de especificar las suscripciones que desea eliminar. El comando
--all vinculará todas las suscripciones asociadas. También puede eliminar suscripciones
al especificar sus números de serie. El comando subscription-manager list --
consumed muestra la lista de las suscripciones asociadas; luego, el número de serie se pasa a
subscription-manager remove mediante la opción --serial.
[root@demo ~]# subscription-manager list --consumed

+-------------------------------------------+
Consumed Subscriptions
+-------------------------------------------+
Subscription Name: 60 Day Self-Supported Red Hat Enterprise Linux OpenStack
Platform Preview
Provides: Red Hat OpenStack
Red Hat Enterprise Linux Server
Red Hat Software Collections (for RHEL Server)
Oracle Java (for RHEL Server)
Red Hat Enterprise MRG Messaging
Red Hat Enterprise Linux High Availability (for RHEL Server)
Red Hat Enterprise Linux Load Balancer (for RHEL Server)
SKU: SER0123
Contract: 98765432
Account: 543540
Serial: 7868709839063398548
Active: True
Quantity Used: 1
Service Level: Self-Support
Service Type: L1-L3
Status Details:
Subscription Type: Standard
Starts: 11/30/2015
Ends: 01/28/2016
System Type: Virtual
[root@demo ~]# subscription-manager remove --serial 7868709839063398548

Serial numbers successfully removed at the server:
7868709839063398548
1 local certificate has been deleted.
El comando subscription-manager unregister elimina el host actual de RHSM.

Elimina todas las suscripciones asociadas al sistema y elimina localmente los certificados de
suscripción y el ID del sistema.
RH342-RHEL7.2-es-1-20160321 213
Solución de problemas relacionados con la

administración de suscripciones de Red Hat
Examen de archivos de registro
Examinar archivos de registro en busca de errores es, por lo general, el primer paso para una
solución efectiva de problemas. Las aplicaciones de Red Hat Subscription Manager tienen dos
archivos de registro principales, ambos ubicados en el directorio /var/log/rhsm: rhsm.log
y rhsmcertd.log. Los mensajes de registro generados por las ejecuciones subscription-
manager y subscription-manager-gui se escriben en rhsm.log. rhsmcertd.log
contiene mensajes que pertenecen al daemon rhsmcertd.
Solución de problemas relacionados a los archivos de configuración

El archivo de configuración principal para Red Hat Subscription Manager es /etc/rhsm/
rhsm.conf. /etc/rhsm/pluginconf.d puede contener archivos de configuración
adicionales para los complementos (plug-ins) de RHSM. En los siguientes fragmentos de
rhsm.conf se muestran las variables clave que definen el comportamiento de las utilidades
de RHSM.
El archivo comienza con la sección [server] (servidor). Incluye las variables que señalan
al servidor de RHSM. Las variables de proxy_* definen el servidor proxy y la autenticación
proxy cuando se debe utilizar un proxy para acceder a Internet.
[server]
# Server hostname:
hostname = subscription.rhn.redhat.com
# Server prefix:
prefix = /subscription
# Server port:
port = 443
# an http proxy server to use

proxy_hostname =
# port for http proxy server
proxy_port =
# user name for authenticating to an http proxy, if needed
proxy_user =
# password for basic http proxy auth, if needed
proxy_password =
La sección rhsm define la URL para el servicio de red de entrega de contenido, baseurl. Los
directorios donde se almacenan los certificados X.509 también se definen en esta sección.
[rhsm]
# Content base URL:
baseurl= https://cdn.redhat.com
# Server CA certificate location:

ca_cert_dir = /etc/rhsm/ca/
# Where the certificates should be stored
214 RH342-RHEL7.2-es-1-20160321
Solución de problemas relacionados con la administración de suscripciones de Red Hat
productCertDir = /etc/pki/product
entitlementCertDir = /etc/pki/entitlement
consumerCertDir = /etc/pki/consumer
# Manage generation of yum repositories for subscribed content:

manage_repos = 1
# The directory to search for subscription manager plugins

pluginDir = /usr/share/rhsm-plugins
# The directory to search for plugin configuration files
pluginConfDir = /etc/rhsm/pluginconf.d
La sección rhsmcertd define los intervalos de tiempo de ejecución para el daemon

rhsmcertd.
[rhsmcertd]
# Interval to run cert check (in minutes):
certCheckInterval = 240
# Interval to run auto-attach (in minutes):
autoAttachInterval = 1440
El otro archivo de configuración que impacta el comportamiento de RHSM es el archivo

de configuración del complemento (plug-in) de Yum, /etc/yum/pluginconf.d/
subscription-manager.conf. Esto determina si Yum utiliza repositorios de RHSM. El
ajuste enabled (habilitado) debería ser 1.
[main]
enabled=1
Inspección de certificados
Todos los certificados X.509 se almacenan en subdirectorios en el directorio /etc/pki. El
subdirectorio consumer almacena el certificado y la clave de identidad del servidor.
[root@demo ~]# ls /etc/pki/consumer

cert.pem key.pem
Los subdirectorios product y product-default contienen los certificados de los productos

instalados. Los certificados de los productos suscritos están almacenados en el subdirectorio
entitlement.
[root@demo ~]# ls /etc/pki/product-default

69.pem
[root@demo ~]# ls /etc/pki/entitlement
7868709839063398548-key.pem 7868709839063398548.pem
El comando rct cat-cert muestra los campos y valores integrados en los certificados
X.509 de RHSM. Se puede utilizar para comparar el ID de certificados de autorización con el
ID de certificados de productos correspondientes.
[root@demo ~]# rct cat-cert /etc/pki/product-default/69.pem | grep 69

Path: /etc/pki/product/69.pem
ID: 69
[root@demo ~]# rct cat-cert /etc/pki/entitlement/7868709839063398548.pem |
RH342-RHEL7.2-es-1-20160321 215
> egrep 'ID|Serial'

Serial: 7868709839063398548
ID: 180
ID: 191
ID: 201
ID: 205
ID: 220
ID: 239
ID: 240
ID: 69
ID: 83
ID: 85
Diagnóstico de conectividad de red

Si subscription-manager se cuelga o no tiene respuesta, es posible que haya un problema
con la conectividad de red. El comando curl se puede utilizar para comunicarse con los
servidores de Red Hat. Si no puede conectarse, debe diagnosticar y corregir los problemas de
red antes de continuar con subscription-manager.
En el siguiente ejemplo se muestra una conexión exitosa a Red Had. La URL pasada como
argumento es una baseurl copiada de /etc/yum.repos.d/redhat.repo, excepto la parte
de $releasever/$basearch de la URL expandida.
[root@demo ~]# curl --head

> --key /etc/pki/entitlement/7868709839063398548-key.pem
> --cert /etc/pki/entitlement/7868709839063398548.pem
> --cacert /etc/rhsm/ca/redhat-uep.pem
> https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os
HTTP/1.1 403 Forbidden
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 340
Expires: Mon, 18 Jan 2016 16:40:13 GMT
Date: Mon, 18 Jan 2016 16:40:13 GMT
X-Cache: TCP_DENIED from a128-241-218-165.deploy.akamaitechnologies.com
(AkamaiGHost/7.4.0.1.1-16456689) (-)
Connection: keep-alive
EJ-HOST: Not_Set
X-Akamai-Request-ID: 111e1374
Ignore el error 403 HTTP. La conectividad de red es lo que se está revisando, y curl obtuvo
una respuesta HTTP de los servidores de Red Hat.
Referencias
Páginas del manual: subscription-manager(8), rct(8), rhsmcertd(8)
216 RH342-RHEL7.2-es-1-20160321
Prueba: Suscripción de sistemas a actualizaciones de Red Hat
Prueba: Suscripción de sistemas a

actualizaciones de Red Hat
A continuación se muestran los pasos para solucionar problemas de Red Hat Subscription
Manager. Indique el orden en que deben efectuarse los pasos.
a. Compruebe que el archivo de configuración /etc/rhsm/rhsm.conf tenga los valores

correctos.
b. Utilice curl para identificar posibles problemas de conectividad de red con

subscription.rhn.redhat.com.
c. Utilice el comando rct cat-cert para inspeccionar los certificados X.509 utilizados
por RHSM.
d. Examine el archivo /var/log/rhsm/rhsm.log en busca de mensajes de error útiles.
RH342-RHEL7.2-es-1-20160321 217
Solución
A continuación se muestran los pasos para solucionar problemas de Red Hat Subscription
Manager. Indique el orden en que deben efectuarse los pasos.
2 a. Compruebe que el archivo de configuración /etc/rhsm/rhsm.conf tenga los valores

correctos.
4 b. Utilice curl para identificar posibles problemas de conectividad de red con

subscription.rhn.redhat.com.
3 c. Utilice el comando rct cat-cert para inspeccionar los certificados X.509 utilizados
por RHSM.
1 d. Examine el archivo /var/log/rhsm/rhsm.log en busca de mensajes de error útiles.
218 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Solución de problemas de RPM

problemas de RPM
En este trabajo de laboratorio, corregirá un problema de paquete de software que provoca la

falla de un servicio de red recientemente instalado.
Recursos
URL de la aplicación http://servera.lab.example.com
• servera
Resultados
Deberá poder diagnosticar y reparar problemas del paquete que provocan la falla de un
servicio.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab package-issues
setup en su sistema workstation. Esto instalará e implementará un servidor web en su
sistema de servera.
[student@workstation ~]$ lab package-issues setup
Un miembro de su equipo instaló un servidor web en el servidor de servera. En lugar de

mostrar el contenido, se muestra el siguiente mensaje de error cuando quiere acceder.
[student@workstation ~]$ curl -4 http://servera.lab.example.com

curl: (7) Failed connect to servera.lab.example.com:80; Connection refused
Recibió la tarea de lograr que servera pueda publicar contenido web.
1. Conéctese a su máquina servera y evalúe el problema.
3. Evalúe su trabajo ejecutando el comando lab package-issues grade de su máquina

workstation.
[student@workstation ~]$ lab package-issues grade
ejercicios.
RH342-RHEL7.2-es-1-20160321 219
Solución
En este trabajo de laboratorio, corregirá un problema de paquete de software que provoca la
falla de un servicio de red recientemente instalado.
Recursos
URL de la aplicación http://servera.lab.example.com
• servera
Resultados
Deberá poder diagnosticar y reparar problemas del paquete que provocan la falla de un
servicio.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab package-issues
setup en su sistema workstation. Esto instalará e implementará un servidor web en su
sistema de servera.
[student@workstation ~]$ lab package-issues setup
Un miembro de su equipo instaló un servidor web en el servidor de servera. En lugar de

mostrar el contenido, se muestra el siguiente mensaje de error cuando quiere acceder.

curl: (7) Failed connect to servera.lab.example.com:80; Connection refused
Recibió la tarea de lograr que servera pueda publicar contenido web.
1. Conéctese a su máquina servera y evalúe el problema.
1.1. Primero, verifique el estado del servicio httpd para ver si se está ejecutando.
[root@servera ~]# systemctl status httpd

preset: disabled)
Active: failed (Result: exit-code) since Fri 2016-01-08 10:05:34 PST; 1min
43s ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 32644 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/
FAILURE)
Process: 32642 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited,
status=203/EXEC)
Main PID: 32642 (code=exited, status=203/EXEC)
Jan 08 10:05:34 servera.lab.example.com systemd[1]: Starting The Apache HTTP ...

Jan 08 10:05:34 servera.lab.example.com systemd[32642]: Failed at step EXEC s...
Jan 08 10:05:34 servera.lab.example.com systemd[1]: httpd.service: main proce...
Jan 08 10:05:34 servera.lab.example.com kill[32644]: kill: cannot find proces...
Jan 08 10:05:34 servera.lab.example.com systemd[1]: httpd.service: control pr...
Jan 08 10:05:34 servera.lab.example.com systemd[1]: Failed to start The Apach...
Jan 08 10:05:34 servera.lab.example.com systemd[1]: Unit httpd.service entere...
Jan 08 10:05:34 servera.lab.example.com systemd[1]: httpd.service failed.
220 RH342-RHEL7.2-es-1-20160321
Solución
El servicio está inactivo y los mensajes de error sugieren que no se pudo arrancar.
1.2. Dado que el servicio se instaló recientemente, revise el archivo de registro de Yum
para identificar los paquetes recientemente instalados. Es posible que su resultado
sea diferente, pero asuma que los siguientes paquetes se instalaron recientemente
en su sistema.
[root@servera ~]# tail /var/log/yum.log

Dec 15 15:25:26 Installed: cryptsetup-1.6.7-1.el7.x86_64
Dec 15 15:25:27 Installed: words-3.0-22.el7.noarch
Jan 08 10:05:32 Installed: apr-1.4.8-3.el7.x86_64
Jan 08 10:05:32 Installed: apr-util-1.5.2-6.el7.x86_64
Jan 08 10:05:33 Installed: httpd-tools-2.4.6-40.el7.x86_64
Jan 08 10:05:33 Installed: mailcap-2.1.41-2.el7.noarch
Jan 08 10:05:33 Installed: httpd-2.4.6-40.el7.x86_64
Verifique los paquetes recientemente instalados para ver si están intactos.
[root@servera ~]# rpm -V apr apr-util httpd-tools mailcap httpd

..5....T. /usr/sbin/httpd
El comando rpm -V indica que el contenido y la marca de tiempo de /usr/sbin/

httpd han cambiado desde la instalación. Identifique el paquete específico que
proporciona el archivo dañado.
[root@servera ~]# rpm -qf /usr/sbin/httpd

httpd-2.4.6-40.el7.x86_64
2.1. Utilice Yum para reinstalar el paquete afectado.
[root@servera ~]# yum -y reinstall httpd
2.2. Reinicie el servicio httpd.
[root@servera ~]# systemctl restart httpd
Compruebe que se inició correctamente.

preset: disabled)
Active: active (running) since Fri 2016-01-08 10:11:54 PST; 1s ago
Docs: man:httpd(8)
man:apachectl(8)
FAILURE)
Main PID: 2394 (httpd)
Status: "Processing requests..."
RH342-RHEL7.2-es-1-20160321 221
CGroup: /system.slice/httpd.service
├─2394 /usr/sbin/httpd -DFOREGROUND
Jan 08 10:11:54 servera.lab.example.com systemd[1]: Starting The Apache HTTP ...
Jan 08 10:11:54 servera.lab.example.com systemd[1]: Started The Apache HTTP S...
2.3. Confirme desde workstation que servera está proporcionando contenido web.

Lab is fixed.
3. Evalúe su trabajo ejecutando el comando lab package-issues grade de su máquina

workstation.
[student@workstation ~]$ lab package-issues grade
ejercicios.
222 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
• La información acerca de la dependencia de paquetes se puede mostrar con los comandos

yum deplist, rpm -q --requires y rpm -q --provides.
• Puede usar los comandos yum downgrade y rpm -U --oldpackage para instalar
versiones anteriores de paquetes instalados.
• El paquete yum-plugin-versionlock extiende Yum para que no se puedan actualizar versiones

específicas de paquetes.
• Se pueden usar las utilidades rpmdb_verify, rpmdb_dump y rpmdb_load para reparar

una base de datos de RPM levemente dañada. rpm --rebuilddb volverá a desarrollar los
archivos de índice __db.* de la base de datos de RPM.
• El comando rpm -V verificará los paquetes instalados. El paquete yum-plugin-verify

extiende Yum para que también pueda verificar los paquetes instalados.
• Los comandos rpm --setperms, rpm --setugids y yum reinstall pueden recuperar
archivos cambiados.
• Las suscripciones de software se pueden administrar con los comandos subscription-

manager-gui o subscription-manager.
• El comando rct cat-cert se puede usar para mostrar el contenido de los certificados de
autorización, productos e identidad de RHSM.
• curl se puede usar para confirmar la conectividad de red con el host de Red Hat
Subscription Manager.
RH342-RHEL7.2-es-1-20160321 223
224
TRAINING
CAPÍTULO 7
RED
Visión general
Meta Identificar y solucionar problemas de conectividad de red.
Objetivos • Comprobar la conectividad de la red con herramientas
estándares.
• Identificar y solucionar problemas de conectividad de

red.
• Inspeccionar el tráfico de la red para facilitar la solución

de problemas.
Secciones • Prueba de conectividad (y ejercicio guiado)
• Resolución de problemas de conectividad (y ejercicio

guiado)
• Inspección del tráfico de red (y ejercicio guiado)

Trabajo de laboratorio • Solución de problemas de red
RH342-RHEL7.2-es-1-20160321 225
Capítulo 7. Solución de problemas de red
Prueba de conectividad
Objetivos
Después de completar esta sección, los estudiantes podrán verificar la conectividad de red
con herramientas estándares.
Envío de solicitudes eco de IMCP

El Protocolo de Mensajes de Control de Internet (Internet Control Message Protocol) (ICMP) es
un protocolo de bajo nivel utilizado para probar la disponibilidad del host y enviar mensajes
de error. Uno de los primeros pasos para probar la conectividad es enviar solicitudes eco de
ICMP al host remoto. Por defecto, los hosts están configurados para enviar una respuesta
eco de ICMP para indicar que están presentes y en funcionamiento. Esto se logra mediante el
comando ping.
El comando ping toma el nombre de host, o la dirección IP, del host de interés como un
argumento. Cuando se utiliza la opción -b, el argumento del comando especificado es una
dirección de difusión (broadcast). Por defecto, ping enviará continuamente solicitudes eco
de ICMP cada segundo. Todas las respuestas que recibe se muestran con su número de
secuencia de paquete y tiempo de latencia. Cuando el usuario interrumpe el comando con un
Ctrl+C, ping muestra un resumen.
[user@demo ~]$ ping content.example.com

PING content.example.com (172.25.254.254) 56(84) bytes of data.
64 bytes from classroom.example.com (172.25.254.254): icmp_seq=1 ttl=63 time=0.426 ms
64 bytes from classroom.example.com (172.25.254.254): icmp_seq=2 ttl=63 time=0.545 ms
Ctrl+C
--- content.example.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.426/0.485/0.545/0.063 ms
Hay un par de opciones que hacen que ping sea útil en programas de shell. La opción -c
COUNT especifica un conteo que limita la cantidad de solicitudes eco que se puede enviar.
La opción -W TIMEOUT especifica la cantidad de segundos que se espera antes de que se
agote el tiempo de espera. El siguiente comando ping envía una solicitud eco y espera tres
segundos por una respuesta.
[user@demo ~]$ ping -c 1 -W 3 172.25.250.254

PING 172.25.250.254 (172.25.250.254) 56(84) bytes of data.
64 bytes from 172.25.250.254: icmp_seq=1 ttl=64 time=0.217 ms
--- 172.25.250.254 ping statistics ---

[user@demo ~]$ echo $?
0
ping devuelve un estado de salida cero cuando el host de destino responde, y un estado de
salida no cero cuando no se recibe una respuesta.
El comando ping6 es la versión IPv6 de ping. Dado que varias interfaces pueden tener una
dirección de conexión local IPv6 (fe80::), la opción -I INTERFACE especifica la interfaz para
enviar las solicitudes de eco.
226 RH342-RHEL7.2-es-1-20160321
Análisis de puertos de red
[user@demo ~]$ ping6 -I eth0 fe80::5054:ff:fe00:fa09

PING fe80::5054:ff:fe00:fa09(fe80::5054:ff:fe00:fa09) from fe80::5054:ff:fe00:fa0a eth0:
56 data bytes
64 bytes from fe80::5054:ff:fe00:fa09: icmp_seq=1 ttl=64 time=0.267 ms
64 bytes from fe80::5054:ff:fe00:fa09: icmp_seq=2 ttl=64 time=0.332 ms
Ctrl+C
--- fe80::5054:ff:fe00:fa09 ping statistics ---
No se necesita la opción -I cuando se utiliza una dirección IPv6 enrutable.
[user@demo ~]$ ping6 -n remote.example.com

PING remote.example.com(fd2a:6552:6448:6174::abc) 56 data bytes
64 bytes from fd2a:6552:6448:6174::abc: icmp_seq=1 ttl=64 time=0.372 ms
64 bytes from fd2a:6552:6448:6174::abc: icmp_seq=2 ttl=64 time=0.305 ms
Ctrl+C
--- remote.example.com ping statistics ---
La siguiente tabla enumera las opciones ping y ping6 utilizadas con mayor frecuencia.
-b Difunde (broadcast) a la red especificada como un argumento
-n Muestra información de host numéricamente
-i INTERVAL Especifica el intervalo de solicitudes eco en segundos (el valor
predeterminado es 1)
-I INTERFACE Envía solicitudes eco a INTERFACE
-c COUNT Envía solo solicitudes eco COUNT
-W TIMEOUT Espera TIMEOUT segundos antes de finalizar
Análisis de puertos de red

Nmap es un escáner de puertos de código abierto proporcionado por la distribución de
Red Hat Enterprise Linux. Es una herramienta que los administradores utilizan para analizar
rápidamente redes grandes, pero también puede realizar análisis de puertos más intensivos
en hosts individuales. Según la página del manual nmap(1),
Nmap utiliza paquetes IP sin formato en maneras innovadoras para

determinar los hosts que están disponibles en la red, los servicios (nombre
y versión de la aplicación) que esos hosts están ofreciendo, los sistemas
operativos (y versiones de SO) que están ejecutando, los tipos de filtro/
firewall de paquete que están en uso y otras tantas características.
El paquete nmap proporciona el ejecutable nmap.
En el siguiente ejemplo se muestra Nmap analizando la red privada 192.168.37.0/24. La

opción -n le indica mostrar la información de host numéricamente, no a través de DNS.
A medida que Nmap descubre cada host, analiza puertos TCP con privilegios en busca de
servicios. Muestra la dirección MAC, con el fabricante del adaptador de red correspondiente,
de cada host.
RH342-RHEL7.2-es-1-20160321 227
[root@demo-64 ~]# nmap -n 192.168.37.0/24
Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-28 15:05 PST

Nmap scan report for 192.168.37.1
Host is up (0.00030s latency).
Not shown: 996 filtered ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp closed http
631/tcp closed ipp
MAC Address: 52:54:00:D1:C3:F6 (QEMU Virtual NIC)

Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
Nmap done: 256 IP addresses (2 hosts up) scanned in 7.10 seconds
Puede deshabilitar los análisis del puerto con la opción -sn. Los administradores utilizan esta
opción cuando desean ver rápidamente los hosts que están en ejecución en una red.
[root@demo ~]# nmap -n -sn 192.168.37.0/24

Host is up.
La opción -sU le indica a nmap que debe realizar un análisis de puerto UDP. Este análisis lleva
considerablemente más tiempo en ejecutarse que el análisis de puerto TCP predeterminado.
Es útil cuando un administrador desea un panorama más completo de los servicios que un
host expone en la red.
[root@demo ~]# nmap -n -sU 192.168.37.1

PORT STATE SERVICE
53/udp open|filtered domain
67/udp open|filtered dhcps
631/udp open|filtered ipp
Nmap done: 1 IP address (1 host up) scanned in 1076.23 seconds
Nmap tiene muchas otras opciones útiles que superan el alcance de este curso.
228 RH342-RHEL7.2-es-1-20160321
Comunicación con un servicio remoto
Comunicación con un servicio remoto

Una herramienta de solución de problemas que permite que un administrador se comunique
con un servicio directamente es Ncat. Ncat puede usar TCP y UDP para comunicarse con un
servicio de red, y también admite la comunicación SSL. Ncat se invoca con el comando nc o el
comando ncat. El paquete nmap-ncat de Red Hat Enterprise Linux proporciona la utilidad de
Ncat.
Ncat tiene dos modos de funcionamiento. Actúa como un cliente de red por defecto, también
conocido como modo de conexión. El puerto y nombre de host al que se debe conectar se
especifican como argumentos en el comando.
[root@demo ~]# nc mailserver 25

220 mail.example.com ESMTP Postfix
EHLO host.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
221 2.0.0 Bye
Ctrl+C
[root@demo ~]#
Ncat actúa como un servidor cuando se invoca con la opción -l. Esto se conoce como el
modo de escucha. La opción hace que -k mantenga el puerto abierto para escuchar más
conexiones cuando se utiliza en este modo.
[root@demo ~]# nc -l 2510

line of text 1
line of text 2
El comportamiento adecuado de Ncat en el modo de escucha es mostrar cualquier texto que

recibe por la red en la pantalla. La opción -e COMMAND hace que Ncat pase tráfico de red
entrante al comando especificado con la opción. El siguiente comando ejecuta Ncat en modo
de escucha en el puerto 2510. Pasará todo el tráfico de red a /bin/bash.
[root@remote ~]# nc -l 2510 -e /bin/bash
El siguiente resultado muestra lo que sucede cuando se utiliza una sesión de modo de
conexión de Ncat para comunicarse con el agente de escucha anterior.
[root@demo ~]# nc remote.example.com 2510

ls
anaconda-ks.cfg
pwd
/root
uptime
05:30:49 up 4 days, 13:50, 1 user, load average: 0.02, 0.02, 0.05
hostname
remote.example.com
RH342-RHEL7.2-es-1-20160321 229
Ctrl+D
/bin/bash ejecuta cada línea de texto enviada al servidor. El resultado de los comandos se
envía de regreso al cliente de red.
Importante
Por razones obvias de seguridad, nunca se debe conectar directamente una shell a
un puerto de red. Se brindó el ejemplo anterior para demostrar la funcionalidad de
Ncat con la opción -e.
Ncat admite IPv4 e IPv6. Las opciones -4 y -6 obligan a Ncat a utilizar IPv4 o IPv6,
respectivamente.
Monitoreo del trafico de la red

IPTraf era un software de monitoreo de redes, desarrollado originalmente a mediados
de 1990. Red Hat Enterprise Linux incluye la versión de última generación de IPTraf,
proporcionada por el paquete iptraf-ng.
El comando iptraf-ng ejecuta la aplicación. El programa requiere acceso de superusuario,

por lo que debe ejecutarse con el usuario root. IPtraf-ng tiene una interfaz de menú de
curses. En la siguiente captura de pantalla, se muestra el menú principal que aparece cuando
la herramienta se ejecuta por primera vez.
Figura 7.1: Menú principal del monitor de redes iptraf-ng
Las selecciones se realizan con las teclas de flecha hacia arriba y hacia abajo. A continuación,
presione Enter (Intro) para ejecutar la selección actual. O bien, puede escribir el carácter
resaltado para ejecutar un comando.
IPtraf-ng puede monitorear conexiones de red actuales. Puede mostrar conteos resumidos o
detallados acerca de las interfaces de red en el sistema local. Puede mostrar información de
paquetes UDP e ICMP.
230 RH342-RHEL7.2-es-1-20160321
Monitoreo del trafico de la red
La selección del menú principal Filters... (Filtros…) permite que un administrador cree filtros
para incluir (o excluir) tipos específicos de tráfico de red. Cada filtro es un conjunto de reglas
que pueden seleccionar paquetes en función del tipo de protocolo IP, el puerto, la dirección,
la fuente o el destino.
Referencias
Páginas del manual icmp(7), iptraf-ng(8), ncat(1), nmap(1) y ping(8)
RH342-RHEL7.2-es-1-20160321 231
Ejercicio guiado: Prueba de conectividad
En este trabajo de laboratorio, utilizará algunas herramientas de software para probar la

conectividad de la red.
Recursos
URL de la aplicación http://content.example.com
• serverb
Resultados
Deberá poder utilizar herramientas de software para probar la conectividad de la red.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab network-testing
setup en su sistema workstation. Esto instalará software, abrirá puertos de firerwall y
configurará un servidor web en serverb.
[student@workstation ~#$ lab network-testing setup
1. El primer paso para probar la conectividad de la red es hacer ping en un host remoto.
Inicie sesión como root en servera. Utilice el comando ping para confirmar que puede
acceder a serverb.
[root@servera ~]# ping serverb.lab.example.com

PING serverb.lab.example.com (172.25.250.11) 56(84) bytes of data.
64 bytes from serverb.lab.example.com (172.25.250.11): icmp_seq=1 ttl=64 time=0.455
ms
ms
ms
Ctrl+C
--- serverb.lab.example.com ping statistics ---
2. El comando ping6 prueba la conectividad IPv6. Utilice el comando ping6 para ver si
puede acceder a serverb. La opción -n mostrará información de la dirección de host
numéricamente.
[root@servera ~]# ping6 -n serverb.lab.example.com

[root@servera ~]#
PING serverb.lab.example.com(fd37:5265:6448:6174::b) 56 data bytes
64 bytes from fd37:5265:6448:6174::b: icmp_seq=1 ttl=64 time=0.285 ms
Ctrl+C
232 RH342-RHEL7.2-es-1-20160321
3. Por lo general, el paquete nmap no se instala de manera predeterminada. Utilice Yum
para instalarlo en su host servera.
[root@servera ~]# yum -y install nmap
4. Analice la red lab.example.com, 172.25.250.0/24, y vea cuáles son las máquinas a las
que se puede acceder.
[root@servera ~]# nmap -sn 172.25.250.0/24

Nmap scan report for serverb.lab.example.com (172.25.250.11)
MAC Address: 52:54:00:00:FA:0B (QEMU Virtual NIC)
MAC Address: 52:54:00:CB:EE:60 (QEMU Virtual NIC)
Nmap scan report for workstation.lab.example.com (172.25.250.254)
MAC Address: 52:54:00:00:FA:09 (QEMU Virtual NIC)
Nmap scan report for servera.lab.example.com (172.25.250.10)
Host is up.
La opción -sn le indica a nmap que debe realizar un análisis de ping. No se realizan
análisis de puerto.
5. Realice un análisis de puerto de serverb.
[root@servera ~]# nmap serverb.lab.example.com

Nmap scan report for serverb.lab.example.com (172.25.250.11)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
Por defecto, nmap realiza un análisis de puerto IPv4. La opción -6 hace que analice
puertos de la dirección IPv6.
[root@servera ~]# nmap -6 serverb.lab.example.com

Nmap scan report for serverb.lab.example.com (fd37:5265:6448:6174::b)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
RH342-RHEL7.2-es-1-20160321 233
6. Otra herramienta útil para probar redes es Netcat, nc o ncat para abreviar. Instale el
paquete nmap-ncat en servera.
[root@servera ~]# yum -y install nmap-ncat
7. Utilice Netcat como un cliente IPv4 del servidor web que se ejecuta en serverb.
Conéctese al puerto 80 y emita el comando HTTP GET. Netcat mostrará lo que se envía
desde el servidor, y el servidor web no emite un aviso.
[root@servera ~]# nc serverb 80

GET
Main web page for serverb.
Ctrl+C
Conéctese al puerto 80 de serverb con Netcat a través de IPv6. La opción -6 le indica a

Netcat que utilice IPv6 en lugar de IPv4.
[root@servera ~]# nc -6 serverb.lab.example.com 80

GET
Main web page for serverb.
Ctrl+C
8. Netcat también puede utilizarse como un servicio de red que muestra todo el contenido
que recibe.
8.1. Inicie sesión como root en serverb. El script de configuración del trabajo de
laboratorio abrió el puerto TCP 4231, por lo que deberá ejecutar Netcat como
un servidor que escuchará en el puerto 4231. Debería seguir escuchando varias
conexiones.
[root@serverb ~]# nc -l -k 4231
8.2. Desde servera, use nmap para realizar un análisis de puerto de serverb.
[root@servera ~]# nmap -p4000-4999 serverb

Nmap scan report for serverb (172.25.250.11)
rDNS record for 172.25.250.11: serverb.lab.example.com
PORT STATE SERVICE
4231/tcp open unknown
8.3. Desde servera, use el cliente nc para conectarse al puerto 4231 de serverb.
Escriba una línea de texto y, luego, escriba Ctrl+C para salir.
234 RH342-RHEL7.2-es-1-20160321
[root@servera ~]# nc serverb 4231
this is a test
Ctrl+C
El texto que escribió debería mostrarse en la pantalla de serverb.
8.4. Por defecto, el servidor de Netcat escucha el puerto TCP en IPv4 e IPv6. Utilice el
cliente Netcat desde servera para conectarse al servidor Netcat que escucha en el
puerto 4231 de serverb a través de IPv6.
[root@servera ~]# nc -6 serverb.lab.example.com 4231

another test
Ctrl+C
Una vez más, el texto que escribió debería mostrarse en la pantalla de serverb.
9. Por lo general, el paquete iptraf-ng no se instala de manera predeterminada. Utilice Yum

para instalarlo en su host servera.
[root@servera ~]# yum -y install iptraf-ng
10. Inicie sesión como root en la consola servera (no utilice SSH en el servidor server).
Ejecute la aplicación iptraf-ng.
[root@servera ~]# iptraf-ng
Seleccione IP traffic monitor (Monitor de tráfico IP) en el menú principal. Utilice las teclas
de flecha para navegar y, luego, presione Enter (Intro) para elegir el elemento de menú
resaltado.
Cuando aparece el cuadro de diálogo Select Interface (Seleccionar interfaz), seleccione

All interfaces (Todas las interfaces) y Enter (Intro) para comenzar a monitorear el tráfico
de red de todas las interfaces. El cuadro superior muestra todas las conexiones de TCP. El
cuadro inferior muestra otros tipos de paquetes. Desde workstation, utilice SSH como
root en servera.
Aparecerá información acerca de la nueva conexión en el cuadro superior. Una de las

direcciones será 172.25.250.10:22; este es el puerto de servicio SSH de servera. La otra
dirección, 172.25.250.254, es la dirección de workstation y tendrá una asignación de
puerto aleatoria.
11. En la sesión SSH de servera, utilice Yum para instalar el paquete lftp. Observe las
ventanas de iptraf-ng mientras se instala el paquete.
Aparecerá otra conexión en el cuadro superior. Una de las direcciones de esa conexión
será 172.25.254.254:80. Esta es la conexión utilizada por Yum para descargar el paquete
RPM de lftp. Una vez que el paquete está instalado, el indicador de conexión cambiará a
CLOS.
RH342-RHEL7.2-es-1-20160321 235
Cierre la sesión de SSH. El otro indicador de conexión TCP cambiará a CLOS.
12. Desde workstation, haga ping en servera.
[student@workstation ~]$ ping servera.lab.example.com
Las solicitudes y respuestas de ping aparecerán en el cuadro inferior. Es posible que

vea tráfico UDP adicional en el cuadro inferior. Probablemente se trate de paquetes de
resolución DNS y coordinación de tiempo NTP.
13. Utilice SSH de serverb a servera a través de IPv6. Verá la conexión TCP al puerto 22
fd37:5265:6448:6174::a en el cuadro superior.
[student@serverb ~]$ ssh -6 servera.lab.example.com
14. En lugar de monitorear tráfico de red, muestra las estadísticas de interfaz de red. Escriba
X para salir de la ventana actual en iftraf-ng. Escriba X para salir de la ventana de
monitoreo; luego, seleccione General interface statistics (Estadísticas de interfaz
generales) o escriba S para mostrar las estadísticas de la interfaz.
En la ventana de SSH, genere tráfico de red.
[student@servera ~]$ ls -R /usr
Observe cómo cambian los contadores de tráfico. Los paquetes totales y los paquetes
IPv6 aumentarán. La actividad de eth1 aumentará y, luego, regresará a 0.00 kbps una vez
que se complete el comando ls.
Escriba X para salir de la ventana; luego, escriba X para salir de la aplicación y cerrar
sesión en la consola.
15. Cree otra sesión de SSH en servera. Inicie sesión como root y SSH desde workstation
a través de una red IPv4. Ejecute iptraf-ng en esa ventana.
[root@servera ~]# iptraf-ng
Seleccione IP traffic monitor (Monitor de tráfico IP) y, luego, seleccione All interfaces
(Todas las interfaces) desde el cuadro de diálogo Select Interface (Seleccionar interfaz).
Observe cómo aumentan los contadores continuamente en la sección TCP de SSH en el

cuadro superior. El tráfico de red genera una actualización de estado, que genera más
tráfico de red.
16. Cree un filtro para excluir tráfico de SSH, pero supervise todo el otro tráfico de red.
16.1.Escriba X para salir de la pantalla del monitor de tráfico de red.
16.2.Seleccione Filters... (Filtros…) y, luego, IP.... Esta pantalla le permite crear y gestionar
filtros de red IP.
236 RH342-RHEL7.2-es-1-20160321
16.3.Seleccione Define new filter... (Definir nuevo filtro…). Ingrese “Exclude SSH” (Excluir
SSH) para la descripción y, luego, presione Enter (Intro). Se mostrará una lista vacía
de reglas de filtrado.
16.4.Primero, cree una regla que elimine todo el tráfico de SSH entrante, el tráfico de TCP
destinado al puerto 22.
Escriba A para agregar una nueva regla a la lista de reglas para este filtro. Ingrese
“22” en el campo para el puerto Destination (Destino). Escriba Y en el campo TCP
protocol (Protocolo TCP). Escriba E en el campo Include/Exclude (Incluir/Excluir).
Presione Enter (Intro) para aceptar sus cambios.
16.5.Cree otra regla que incluya todos los otros tráficos de red.
Escriba A para agregar otra regla a la lista de reglas para este filtro. Escriba Y en el
campo del protocolo All IP (Todas las IP). Presione Enter (Intro) para aceptar sus
cambios.
16.6.Escriba X para salir de la pantalla de definición de reglas.
17. Aplique el nuevo filtro que se creó. Seleccione Apply filter... (Aplicar filtro…), seleccione el
filtro Exclude SSH (Excluir SSH) y presione Enter (Intro).
Escriba X para salir del menú Filters (Filtros). En el cuadro Filter Status (Estado de filtro),
IP filter active (Filtro IP activo) confirma que el filtro está en vigor.
18. Vea cómo funciona el filtro. Escriba X para salir del menú Filter Status (Estado de filtro).
Seleccione IP traffic monitor (Monitor de tráfico IP) y, luego, seleccione All interfaces
(Todas las interfaces) para la interfaz.
No aparecerá la conexión TCP de SSH en el cuadro superior. Aún así, el contador Packets
captured (Paquetes capturados), que se muestra en la parte inferior de la pantalla,
disminuirá.
19. En la otra ventana de SSH en servera, utilice lftp para conectarse a

content.example.com.
[student@servera ~]$ lftp http://content.example.com

cd ok, cwd=/
lftp content.example.com:/>
Aparecerá una conexión temporal a 172.25.254.254:80 en el cuadro superior. Esta

conexión TCP se utilizó para la conexión HTTP. Se muestra debido a que no coincide con
la primer regla del filtro activo.
20. En la ventana iptraf-ng, quite el filtro Exclude SSH (Excluir SSH).
20.1.Escriba X para ir al menú principal.
20.2.Seleccione Filter... (Filtro…), seleccione IP... y, luego, seleccione Detach filter (Quitar
filtro). iptraf-ng informará que el filtro está desactivado. Presione cualquier tecla
para continuar.
RH342-RHEL7.2-es-1-20160321 237
20.3.Escriba X para salir. El Filter status (Estado de filtro) cambió a No IP filter active (No
hay filtro de IP activo).
20.4.Escriba X para regresar al menú principal.
20.5.Seleccione IP traffic monitor (Monitor de tráfico IP) y, luego, seleccione All interfaces
(Todas las interfaces). El monitoreo muestra la conexión de SSH en ejecución debido
al tráfico de red causado por las actualizaciones de monitoreo.
20.6.Escriba X para regresar al menú principal y, luego, escriba X para salir de la

aplicación.
21. Cuando termine de probar la conectividad de red, restablezca sus máquinas al estado
que tenían antes de comenzar el trabajo de laboratorio. Reinicie sus máquinas virtuales o
ejecute el siguiente comando en su sistema workstation.
[student@workstation ~]$ lab network-testing reset
238 RH342-RHEL7.2-es-1-20160321
Resolución de problemas de conectividad
Resolución de problemas de conectividad
Objetivos
de conectividad de red.
Resolución de problemas con asignación de

nombres al dispositivo de red
Red Hat Enterprise Linux 7 admite nombres de dispositivos basados en atributos de
hardware. Este enfoque de asignación de nombres a dispositivos se implementa en sistemas
físicos. Requiere que el paquete biosdevname se haya instalado y que se haya especificado el
parámetro del kernel biosdevname=1. Está habilitado de manera predeterminada en todos
los sistemas Dell.
Los dispositivos de red incorporados reciben nombres similares a eno1. en es el prefijo de

Ethernet, y o significa "incorporado", seguido del número de un dispositivo. Los dispositivos
con ranura de conexión directa de PCI Express tienen nombres similares a ens1; s significa
"ranura". Otros dispositivos de red tienen nombres basados en la ubicación física del
conector de hardware, enp2s0. La asignación de nombres impredecible y tradicional, como
eth0, se utiliza si los métodos anteriores no funcionan.
nota
Los dispositivos de red de huéspedes virtuales utilizan la asignación de nombres de
red tradicional.
El archivo de reglas udev /etc/udev/rules.d/80-net-name-slot.rules implementa

la asignación de nombres persistentes. Este archivo se vincula simbólicamente con /
dev/null cuando se desea una asignación de nombres de dispositivo tradicional. Los
administradores del sistema también pueden escribir su propias reglas de asignación de
nombres de dispositivo udev en /etc/udev/rules.d/70-persistent-net.rules.
Estas reglas sobrescribirán la asignación de nombres de red predeterminada realizada por
systemd.
Los archivos de registro brindan información útil que ayuda a solucionar problemas de
asignación de nombres de dispositivos de red. El archivo /var/log/messages contiene
información de detección de dispositivos que se realiza en el momento del arranque.
También registra los mensajes que NetworkManager produce cuando intenta activar el
dispositivo. En el siguiente ejemplo se muestra eth1 con una configuración y activación
correctas.
[root@demo ~]# grep -n eth1 /var/log/messages

3904:Feb 3 05:29:25 host NetworkManager[610]: <info> (eth1): new
Ethernet device (carrier: OFF, driver: 'virtio_net', ifindex: 3)
3905:Feb 3 05:29:25 host NetworkManager[610]: <info> (eth1): device
state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
3906:Feb 3 05:29:25 host kernel: IPv6: ADDRCONF(NETDEV_UP): eth1:
link is not ready
3907:Feb 3 05:29:25 host NetworkManager[610]: <info> (eth1): link
RH342-RHEL7.2-es-1-20160321 239
connected
3914:Feb 3 05:29:25 host NetworkManager[610]: <info> (eth1): device
state change: unavailable -> disconnected (reason 'none') [20 30 0]
3942:Feb 3 05:29:25 host NetworkManager[610]: <info> (eth1): Activation:
successful, device activated.
3954:Feb 3 05:29:25 host nm-dispatcher: Dispatching action 'up' for eth1
Corrección de problemas de asignación de nombres a dispositivos de red

El nombre de un dispositivo de interfaz de red puede asignarse al ajustar valores en el
archivo de configuración ifcfg-*. La dirección MAC debe coincidir con la variable HWADDR.
El valor de la variable DEVICE determina el nombre del dispositivo de la interfaz de red que
corresponde a la dirección MAC especificada. El siguiente ejemplo demuestra cómo cambiar
el nombre del dispositivo que originalmente se llamó eth1 a test123.
[root@demo ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=test123
HWADDR=52:54:00:01:fa:0a
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=no
IPV6INIT=no
IPADDR=172.24.250.10
NETMASK=255.255.255.0
[root@demo ~]# ip addr show dev test123
3: test123: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 52:54:00:01:fa:0a brd ff:ff:ff:ff:ff:ff
inet 172.24.250.10/24 brd 172.24.250.255 scope global test123
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe01:fa0a/64 scope link
Tenga en cuenta que el nombre del archivo necesitaba comenzar con ifcfg-, pero no
tenía que coincidir con el nombre de dispositivo especificado, aunque esta es una práctica
recomendada. Una vez que se realizaron los cambios en el archivo de configuración, el
sistema se reinició para implementarlos.
Solución de problemas de configuración de la

interfaz
Una vez que se hayan resuelto los problemas de la asignación de nombres de dispositivos
de red, hay otros ajustes de la configuración de la interfaz de red que pueden afectar la
conectividad de la red. Los archivos de registro proporcionan información detallada acerca de
la configuración de red actual. El comando ip addr muestra los ajustes de la red activa para
las interfaces de red.
[root@demo ~]# ip addr show dev eth1

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
inet 172.24.250.10/24 brd 172.24.250.255 scope global eth1
240 RH342-RHEL7.2-es-1-20160321
Solución de problemas de configuración de la interfaz
El comando ip route muestra la tabla de enrutamiento actual. Debe revisar la ruta

predeterminada para asegurarse de que sea la dirección de puerta de enlace correcta para
esta subred.
[root@demo ~]# ip route

default via 172.25.250.254 dev eth0 proto static metric 100
172.24.250.0/24 dev eth1 proto kernel scope link src 172.24.250.10
metric 100
metric 100
Si el Protocolo de configuración dinámica de host (DHCP) se utiliza para configurar una

interfaz de red, NetworkManager ejecuta dhclient para manejar la configuración de esa
interfaz. Los ajustes de red de la interfaz, como la dirección IP, la máscara de red, la puerta
de enlace predeterminada y los servidores DNS, están determinados por los valores que
el servidor DHCP proporciona. Cuando una interfaz de red utiliza direcciones estáticas, el
administrador del sistema debe especificar esos valores correctamente.
Inspección de archivos de configuración de la interfaz de red

Los ajustes de la configuración de red IPv4 y IPv6 estática se definen en los archivos /etc/
sysconfig/network-scripts/ifcfg-*. Cuando no se utiliza NetworkManager, los valores
de estos archivos determinan los ajustes persistentes para las interfaces de red. En este caso,
los cambios de configuración de red se deben realizar en estos archivos. A continuación, se
debe reiniciar la red para aplicar los cambios.
[root@demo ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=fd37:5265:6448:6174::2931/64
IPADDR=192.168.25.31
NETMASK=255.255.255.0
La variable BOOTPROTO determina el tipo de configuración IPv4 que se realiza en la interfaz

de red. Un valor de none (ninguno) o static (estático) indica que las redes IPv4 se
configurarán de manera estática. Los valores dhcp o bootp hacen que dhclient se utilice
para administrar la configuración de la interfaz. Las variables para ajustar la configuración de
IPv4 estática incluyen IPADDR0 y PREFIX0. Para compatibilidad inversa, también se admiten
los ajustes IPADDR y GATEWAY. Cuando la interfaz de la red se conecta a una red externa, la
variable GATEWAY debería tener la dirección IP de la puerta de enlace predeterminada.
La variable IPV6INIT debe tener el valor yes (sí) para que se aplique cualquier configuración
IPv6 en la interfaz de la red. IPV6ADDR especifica la dirección IPv6 estática principal
y la máscara de red. Se pueden asignar direcciones IPv6 adicionales con la variable
IPV6_SECONDARIES. La variable IPV6_AUTOCONF determina si la configuración automática
de IPv6 se realiza en la interfaz de la red.
Administración de los ajustes de NetworkManager

Cuando se utiliza NetworkManager para administrar interfaces de red en un sistema,
el comando nmcli se puede usar para mostrar y cambiar los ajustes de la red. nmcli
RH342-RHEL7.2-es-1-20160321 241
conn show 'CONNECTION_NAME' muestra la configuración de la red actual para una

conexión NetworkManager. Los valores que comienzan con ipv4 o ipv6 corresponden a la
configuración de IPv4 o Ipv6, respectivamente, de una interfaz.
[root@demo ~]# nmcli conn show 'System eth0' | grep ipv

ipv4.method: manual
ipv4.dns: 172.25.250.254
ipv4.dns-search: example.com
ipv4.addresses: 172.25.250.11/24
ipv4.gateway: 172.25.250.254
ipv4.routes:
ipv4.route-metric: -1
ipv4.ignore-auto-routes: no
ipv4.ignore-auto-dns: no
ipv4.dhcp-client-id: --
ipv4.dhcp-send-hostname: yes
ipv4.dhcp-hostname: --
ipv4.never-default: no
ipv4.may-fail: yes
ipv6.method: manual
ipv6.dns:
ipv6.dns-search:
ipv6.addresses: fd37:5265:6448:6174::b/64
ipv6.gateway: --
ipv6.routes:
ipv6.may-fail: yes
ipv6.ip6-privacy: -1 (unknown)
Los ajustes de ipv4.method y de ipv6.method definen cómo se configuran las direcciones

IPv4 e IPv6 en la interfaz. Un valor auto indica que se utilizará DHCP para la configuración
de la red. Cuando se especifica manual para un protocolo IP, la información de IP debe
especificarse con ajustes de direcciones y puerta de enlace. NetworkManager actualiza
los archivos de configuración de la interfaz de red cuando se utiliza nmcli para cambiar y
asignar valores a estos ajustes. Otro enfoque sería cambiar los archivos de configuración
de /etc/sysconfig/network-scripts y, luego, utilizar nmcli conn reload para que
NetworkManager los lea para los cambios de configuración.
Los cambios de la configuración de interfaz de red de NetworkManager no se aplican a

una interfaz si ya está activa. En este caso, se debe reiniciar, desactivar y volver a activar la
interfaz para que se apliquen los cambios de configuración.
[root@demo ~]# nmcli conn down 'System eth1' ; nmcli conn up 'System eth1'
Connection 'System eth1' successfully deactivated (D-Bus active path:
/org/freedesktop/NetworkManager/ActiveConnection/2)
Connection successfully activated (D-Bus active path:
Reinicio de servicios de red afectados

Es posible que los servicios de red aún no estén disponibles cuando se realizan cambios de
configuración. Debe reiniciar los servicios afectados para que escuchen la nueva dirección en
una interfaz de red cambiada.
242 RH342-RHEL7.2-es-1-20160321
Resolución de problemas de resolución DNS
[root@demo ~]# systemctl restart httpd
Resolución de problemas de resolución DNS

Los problemas de resolución DNS del lado del cliente a menudo pueden hacer que los
servicios estén lentos o no disponibles. Por ejemplo, el daemon SSH tiene un ajuste SSH
UseDNS. Determina si sshd debe verificar si el nombre del host coincide con la dirección IP de
conexiones entrantes. Esta función está habilitada por defecto en Red Hat Enterprise Linux.
El archivo de configuración principal para la resolución DNS es /etc/resolv.conf. La

visualización de este archivo identifica los servidores DNS actuales. Puede consultar los
servidores de nombres enumerados explícitamente con el comando host para confirmar si
están disponibles y en funcionamiento.
[user@demo ~]$ cat /etc/resolv.conf

# Generated by NetworkManager
search example.com
nameserver 10.1.1.2
nameserver 10.1.1.3
[user@demo ~]$ host puppet.example.com 10.1.1.2
Using domain server:
Name: 10.1.1.2
Address: 10.1.1.2#53
Aliases:
puppet.example.com has address 192.168.2.43
Aunque /etc/resolv.conf es un buen punto de partida para la solución de problemas

de DNS, este archivo a menudo está administrado por otros scripts. Las variables DNS
definidas en los archivos de interfaz de red, /etc/sysconfig/network-scripts/ifcfg-*,
pueden definir las entradas nameserver en /etc/resolv.conf. La variable PEERDNS debe
configurarse con yes (sí) para que se apliquen estos ajustes.
Los siguientes ajustes de la configuración de red demuestran cómo se asignan los valores
DNS a este host. Dado que PEERDNS está configurado en yes (sí) en ifcfg-eth0, las
direcciones IP definidas por DNS1 y DNS2 definen las entradas de nameserver en /etc/
resolv.conf. El archivo de configuración de eth1 no afecta la configuración de DNS en
ningún modo.
[user@demo ~]$ grep -i dns /etc/sysconfig/network-scripts/ifcfg-*

/etc/sysconfig/network-scripts/ifcfg-eth0:PEERDNS=yes
/etc/sysconfig/network-scripts/ifcfg-eth0:DNS1=10.1.1.2
/etc/sysconfig/network-scripts/ifcfg-eth0:DNS2=10.1.1.3
/etc/sysconfig/network-scripts/ifcfg-eth1:PEERDNS=no
nota
El ajuste PEERDNS=yes también configura dhclient para modificar /etc/
resolv.conf cuando utiliza DHCP para asignar valores de red.
Cuando NetworkManager está activo, realiza cambios en los archivos de configuración

de la interfaz de red en /etc/sysconfig/network-scripts. En estos casos, los
RH342-RHEL7.2-es-1-20160321 243
cambios de configuración de DNS se deben realizar en la información de configuración de

NetworkManager. Esto se logra mediante el comando nmcli.
[root@demo ~]# nmcli conn show 'System eth0' | grep dns

ipv4.dns: 10.1.1.2,10.1.1.3
ipv6.dns:
ipv6.dns-search:
[root@demo ~]# nmcli conn mod 'System eth0' ipv4.dns '10.1.1.2'
[root@demo ~]# nmcli conn show 'System eth0' | grep dns
ipv4.dns: 10.1.1.2
ipv6.dns:
ipv6.dns-search:
Aunque el cambio de configuración se realizó en NetworkManager, /etc/resolv.conf aún

tiene su configuración original. Se debe usar el comando nmcli para reiniciar la conexión de
red para aplicar los cambios de configuración.
[root@demo ~]# cat /etc/resolv.conf

search example.com
nameserver 10.1.1.2
nameserver 10.1.1.3
[root@demo ~]# nmcli conn down 'System eth0' ; nmcli conn up 'System eth0'
[root@demo ~]# cat /etc/resolv.conf
search example.com
nameserver 10.1.1.2
Solución de problemas de firewall

Una vez que se confirma la conectividad de red básica, es posible que haya un servicio de
red no disponible debido a problemas de firewall. Es posible que las reglas de firewall en el
servidor que aloja el servicio de red hayan bloqueado los puertos utilizados para acceder
al servicio. Con menor frecuencia, los problemas de firewall pueden ser un problema en las
máquinas cliente.
Se puede utilizar el comando firewall-cmd para mostrar y ajustar configuraciones

de firewall actuales. Invocar el comando con la opción --list-all-zones brinda una
perspectiva general de la configuración firewalld.
[root@demo ~]# firewall-cmd --list-all-zones

internal
interfaces:
sources:
services: dhcpv6-client ipp-client mdns samba-client ssh
ports:
masquerade: no
244 RH342-RHEL7.2-es-1-20160321
Solución de problemas de firewall
forward-ports:
icmp-blocks:
rich rules:

sources:
services: dhcpv6-client http https ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
El uso de la opción --permanent con firewall-cmd muestra los ajustes persistentes.

Comparar ajustes de firewalld activos con ajustes persistentes a menudo puede identificar
problemas potenciales. El resultado de ejemplo anterior muestra que los puertos de los
servicios http y https no están bloqueados. El siguiente resultado demuestra que su
configuración actual no es persistente.
[root@demo ~]# firewall-cmd --list-all-zones --permanent

internal
interfaces:
sources:
services: dhcpv6-client ipp-client mdns samba-client ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
public (default)
interfaces:
sources:
services: dhcpv6-client ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
Una manera rápida de convertir reglas de tiempo de ejecución en reglas permanentes es con
el comando firewall-cmd --runtime-to-permanent
[root@demo ~]# firewall-cmd --runtime-to-permanent

success
Firewalld está desarrollado sobre la funcionalidad Netfilter. Esto significa que se puede usar
iptables para obtener información de firewall en un nivel inferior a firewall-cmd.
[root@demo ~]# iptables -L -t filter -n

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate
RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
RH342-RHEL7.2-es-1-20160321 245
INPUT_direct all -- 0.0.0.0/0 0.0.0.0/0

INPUT_ZONES_SOURCE all -- 0.0.0.0/0 0.0.0.0/0
INPUT_ZONES all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with
icmp-host-prohibited
Chain INPUT_ZONES (1 references)

IN_public all -- 0.0.0.0/0 0.0.0.0/0 [goto]
Chain IN_public (3 references)

IN_public_log all -- 0.0.0.0/0 0.0.0.0/0
IN_public_deny all -- 0.0.0.0/0 0.0.0.0/0
IN_public_allow all -- 0.0.0.0/0 0.0.0.0/0
Chain IN_public_allow (1 references)

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ctstate NEW
ctstate NEW
ctstate NEW
De manera similar, el comando ip6tables muestra y administra las tablas de firewall IPv6.
Referencias
Para obtener más información, consulte la
Guía de redes de Red Hat Enterprise Linux 7 - Asignación de nombres consistente
a dispositivos de red
html/Networking_Guide/ch-Consistent_Network_Device_Naming.html
Páginas del manual biosdevname(1), firewall-cmd(1), iptables(8), nmcli(1),

nmcli-examples(5) y resolv.conf(5)
246 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Resolución de problemas de conectividad

conectividad
En este trabajo de laboratorio, diagnosticará y resolverá problemas de conectividad de redes.
Recursos
• serverb
Resultados
Deberá poder diagnosticar y resolver problemas de conectividad de redes en un host de Red
Hat Enterprise Linux.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab network-fix setup
en su sistema workstation. Esto configurará IPv6 en servera y serverb e interrumpirá
parte de la conectividad de red de servera.
[student@workstation ~#$ lab network-fix setup
Se ha agregado una segunda interfaz de red a servera, pero no funciona correctamente. Se

conecta a una red privada y debe tener las siguientes asignaciones de dirección IP:
• Dirección IPv4 = 172.24.250.10/24
• Dirección IPv6 = fd37:5265:6448:6174::a/64
DNS dejó de funcionar cuando se configuró la segunda interfaz. 172.24.250.254 es la

dirección IP de un servidor DNS que funciona.
Su tarea es corregir los problemas de configuración de red en servera. Los ajustes de la

red deben perdurar cuando se reinicia la máquina. Cuando la red funciona adecuadamente,
servera debería hacer ping a la dirección IPv6 de serverb.lab.example.com a través de
su nombre de host.
[root@servera ~]# ping6 serverb.lab.example.com
1. Inicie sesión en servera como root. Intente hacer ping en serverb a través de IPv6 con
su nombre de host para confirmar que no funciona.

unknown host
2. Recopile más información sobre el sistema.
2.1. Use el comando ip para mostrar los ajustes actuales de IP para servera.
[root@servera ~]# ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
RH342-RHEL7.2-es-1-20160321 247
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
Observa que la interfaz eth0 está funcionando con una dirección IPv4 asignada y
una dirección IPv6 de conexión local, pero eth1 no tiene direcciones IP asignadas.
2.2. Use nmcli para mostrar las configuraciones de red de NetworkManager. Muestre la
información del dispositivo y de la conexión.
[root@servera ~]# nmcli conn

NAME UUID TYPE DEVICE
System enp2s0 8c6fd7b1-ab62-a383-5b96-46e083e04bb1 802-3-ethernet --
System eth0 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 802-3-ethernet eth0
[root@servera ~]# nmcli dev
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected System eth0
eth1 ethernet disconnected --
lo loopback unmanaged --
NetworkManager tiene dos conexiones: una asignada a eth0 y la otra denominada

System enp2s0 sin dispositivos asignados. Parece que hay un problema de
asignación de nombres en un dispositivo o una configuración.
2.3. Revise los mensajes de arranque en /var/log/messages para ver si hay otras
pistas. Salte a la parte inferior del archivo y desplácese hacia arriba hasta ver los
mensajes de inicialización de red.
Feb 1 09:39:34 servera systemd: Starting Network Manager...

Feb 1 09:39:34 servera NetworkManager[1549]: <info> NetworkManager
(version 1.0.6-27.el7) is starting...
Feb 1 09:39:34 servera NetworkManager[1549]: <info> Read config:
/etc/NetworkManager/NetworkManager.conf and conf.d: 00-server.conf,
10-ibft-plugin.conf
Feb 1 09:39:35 servera systemd: Started Network Manager.
Feb 1 09:39:35 servera systemd: Starting Network Manager Wait Online...
Feb 1 09:39:35 servera NetworkManager[1549]: <info> Loaded
settings plugin ifcfg-rh: (c) 2007 - 2015 Red Hat, Inc.
To report bugs please use the NetworkManager mailing
list. (/usr/lib64/NetworkManager/libnm-settings-plugin-ifcfg-rh.so)
Feb 1 09:39:35 servera NetworkManager[1549]: <info>
Loaded settings plugin iBFT: (c) 2014 Red Hat, Inc.
To report bugs please use the NetworkManager mailing list.
(/usr/lib64/NetworkManager/libnm-settings-plugin-ibft.so)
Feb 1 09:39:35 servera NetworkManager[1549]: <info> Loaded settings
plugin keyfile: (c) 2007 - 2015 Red Hat, Inc. To report bugs please
use the NetworkManager mailing list.
248 RH342-RHEL7.2-es-1-20160321
Feb 1 09:39:35 servera NetworkManager[1549]: <info> ifcfg-rh:
new connection /etc/sysconfig/network-scripts/ifcfg-enp2s0
(8c6fd7b1-ab62-a383-5b96-46e083e04bb1,"System enp2s0")
Feb 1 09:39:35 servera NetworkManager[1549]: <info> ifcfg-rh:
new connection /etc/sysconfig/network-scripts/ifcfg-eth0
(5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03,"System eth0")
Ha encontrado más evidencia útil. No hay dispositivos que coincidan con la interfaz
enp2s0.
3. Revise el estado actual de los archivos de configuración de la interfaz de red.
3.1. Cambie al directorio /etc/sysconfig/network-scripts donde se almacenan

los archivos de configuración de la interfaz de red. Registre el directorio para ver los
archivos de configuración existentes.
[root@servera ~]# cd /etc/sysconfig/network-scripts

[root@servera network-scripts]# ls ifcfg-*
ifcfg-enp2s0 ifcfg-eth0 ifcfg-lo
3.2. Muestre el contenido de la interfaz de red enp2s0.
[root@servera network-scripts]# cat ifcfg-enp2s0

DEVICE=en2ps0
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=fd37:5265:6448:6174::a/64
IPADDR=172.24.250.10
NETMASK=255.255.255.0
Los ajustes de la red parecen ser correctos, pero el archivo los define para una
interfaz que no existe. La segunda interfaz de red de este sistema se conoce como
eth1, no en2ps0.
4. Ajuste los archivos de configuración de red para que reflejen los dispositivos de red del
sistema.
4.1. Realice una copia del archivo ifcfg-enp2s0 original antes de hacer modificaciones.
La copia no puede estar en el directorio /etc/sysconfig/network-scripts; si
está allí, permanecerá en vigor.
[root@servera network-scripts]# cp ifcfg-enp2s0 ~
4.2. Cambie el nombre del archivo de configuración para que su nombre haga referencia
a la interfaz de red eth1.
[root@servera network-scripts]# mv ifcfg-enp2s0 ifcfg-eth1
RH342-RHEL7.2-es-1-20160321 249
4.3. Cambie el contenido del archivo para que la variable DEVICE haga referencia a la
interfaz de red correcta, eth1. El archivo ifcfg-eth1 resultante debería incluir el
siguiente contenido.
DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=fd37:5265:6448:6174::a/64
IPADDR=172.24.250.10
NETMASK=255.255.255.0
5. Use el comando nmcli para que NetworkManager relea los archivos de configuración de
la interfaz de red.
[root@servera network-scripts]# nmcli conn reload

[root@servera network-scripts]# nmcli conn
System eth1 9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04 802-3-ethernet eth1
Las conexiones de red parecen ser correctas. Use el comando ip para confirmar que los
ajustes de la red estén aplicados.
[root@servera network-scripts]# ip addr show dev eth1

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
inet6 fd37:5265:6448:6174::a/64 scope global
6. Haga ping en serverb con su dirección IPv6. Esto funciona, por lo que no se realizarán
cambios adicionales. Vuelva a su directorio de inicio.
[root@servera network-scripts]# ping6 -c 1 fd37:5265:6448:6174::b

PING fd37:5265:6448:6174::b(fd37:5265:6448:6174::b) 56 data bytes
--- fd37:5265:6448:6174::b ping statistics ---

[root@servera network-scripts]# cd
7. Intente hacer ping en serverb con su nombre de host. La resolución de nombres aún no
funciona, por lo que deberá recopilar información del sistema para resolver el problema.
250 RH342-RHEL7.2-es-1-20160321
unknown host
7.1. Muestre el contenido de /etc/resolv.conf. Define la manera en que se comporta

el DNS del lado del cliente.
[root@servera ~]# cat /etc/resolv.conf

search lab.example.com example.com
nameserver 172.25.250.11
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
7.2. Use el comando host para consultar los hosts que están enumerados en /etc/
resolv.conf.
[root@servera ~]# host -v -t aaaa serverb.lab.example.com 172.25.250.11

Trying "serverb.lab.example.com"
;; connection timed out; trying next origin
Trying "serverb.lab.example.com.lab.example.com"
;; connection timed out; trying next origin
Trying "serverb.lab.example.com.example.com"
;; connection timed out; no servers could be reached
[root@servera ~]# host -v -t aaaa serverb.lab.example.com 172.25.250.254
Trying "serverb.lab.example.com"
Using domain server:
Name: 172.25.250.254
Address: 172.25.250.254#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64858

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;serverb.lab.example.com. IN AAAA
;; ANSWER SECTION:
serverb.lab.example.com. 3600 IN AAAA fd37:5265:6448:6174::b
Received 69 bytes from 172.25.250.254#53 in 0 ms
Todos ellos tienen errores, excepto el último del archivo. Observe que
NetworkManager incluyó un comentario en el archivo que sugiere que se debería
ignorar la cuarta entrada.
7.3. Use el comando nmcli para ver cómo está configurado el DNS. Dado que eth0 es la
interfaz de red externa para servera, revise su configuración.
[root@servera ~]# nmcli conn show 'System eth0' | grep -i dns

ipv4.dns:
172.25.250.11,172.25.250.10,127.0.0.1,172.25.250.254
ipv4.dns-search: lab.example.com,example.com
ipv6.dns:
RH342-RHEL7.2-es-1-20160321 251
ipv6.dns-search:
IP4.DNS[1]: 172.25.250.11
IP4.DNS[2]: 172.25.250.10
IP4.DNS[3]: 127.0.0.1
IP4.DNS[4]: 172.25.250.254
Observe que el ajuste de ipv4.dns coincide con las entradas de nameserver del
DNS definidas en /etc/resolv.conf.
8. Corrija los ajustes de DNS definidos en NetworkManager. Los cambios realizados en /

etc/resolv.conf serán temporales debido a que NetworkManager administra ese
archivo.
[root@servera ~]# nmcli conn mod 'System eth0' ipv4.dns '172.25.250.254'

[root@servera ~]# nmcli conn show 'System eth0' | grep -i dns
ipv4.dns: 172.25.250.254
ipv6.dns:
ipv6.dns-search:
IP4.DNS[1]: 172.25.250.11
IP4.DNS[2]: 172.25.250.10
IP4.DNS[3]: 127.0.0.1
IP4.DNS[4]: 172.25.250.254
NetworkManager actualizó el archivo de configuración de la interfaz de red para eth0

con el cambio.
[root@servera ~]# grep -i dns /etc/sysconfig/network-scripts/ifcfg-eth0

DNS1=172.25.250.254
9. Intente hacer ping en serverb con su nombre de host. DNS aún no funciona.

unknown host
A pesar de los cambios de NetworkManager, /etc/resolv.conf aún hace referencia a

los servidores de nombres originales.

# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
10. Reinicie la conexión de NetworkManager para System eth0. Esto aplicará los cambios a
la conexión. Si utilizó SSH para conectarse al host, asegúrese de iniciar la conexión con la
misma línea de comando.
252 RH342-RHEL7.2-es-1-20160321
[root@servera ~]# nmcli conn down 'System eth0' ; nmcli conn up 'System eth0'
Muestre /etc/resolv.conf y compruebe que se haya cambiado el servidor de

nombres de DNS.

11. Use ping6 para hacer ping en serverb con su nombre de host.
[root@servera ~]# ping6 -c 1 serverb.lab.example.com

PING serverb.lab.example.com(serverb.lab.example.com) 56 data bytes
64 bytes from serverb.lab.example.com: icmp_seq=1 ttl=64 time=0.353 ms

Reinicie servera y confirme que los ajustes de la red son persistentes.
Espere que se complete el reinicio antes de seguir con el próximo paso de calificación.
12. Cuando finalice, verifique su trabajo ejecutando el comando lab network-fix grade
desde su máquina workstation.
[student@workstation ~]$ lab network-fix grade
[student@workstation ~]$ lab network-fix reset
RH342-RHEL7.2-es-1-20160321 253
Inspección del tráfico de red
Objetivos
Después de completar esta sección, los estudiantes podrán inspeccionar el tráfico de red
para solucionar problemas.
Inspección del tráfico de red con Wireshark

Wireshark es una aplicación gráfica de código abierto que captura, filtra e inspecciona
paquetes de redes. Anteriormente se denominaba Ethereal, pero por un problema de marca
registrada, el nombre del proyecto cambió. Wireshark puede realizar una detección de
paquetes promiscuos cuando es compatible con los controladores de la interfaz de red. Los
paquetes se colorean para identificarlos fácilmente.
Protocolo Color
HTTP Verde claro
TCP Gris
UDP Celeste
ARP Amarillo claro
ICMP Rosa
Con errores Negro
Red Hat Enterprise Linux 7 incluye el paquete wireshark-gnome. Esto proporciona la

funcionalidad de Wireshark en un sistema instalado con X.
[root@demo ~]# yum -y install wireshark-gnome
Una vez que se instala Wireshark, se puede ejecutar al seleccionar Applications

(Aplicaciones) > Internet > Wireshark Network Analyzer desde el escritorio de GNOME.
También se puede ejecutar directamente desde una shell.
[root@demo ~]# wireshark
Captura de paquetes con Wireshark

Wireshark puede capturar paquetes de redes. Debe ser ejecutado por root para capturar
paquetes, ya que el acceso directo a las interfaces de la red requiere el privilegio root. El
menú superior Capture (Capturar) permite que el usuario inicie o detenga Wireshark para
capturar paquetes. También permite que el administrador seleccione las interfaces en las que
desea capturar paquetes. La interfaz any coincide con todas las interfaces de red.
Una vez que se detiene la captura de un paquete, se pueden escribir los paquetes de red
capturados en un archivo para compartirlos o para analizarlos en otro momento. Los
elementos de menú File (Archivo) > Save (Guardar) o File (Archivo) > Save As… (Guardar
como…) permiten que el usuario especifique el archivo en el que desea guardar los paquetes.
Wireshark admite una variedad de formatos de archivo.
Wireshark también se puede utilizar para analizar paquetes capturados que se guardaron
anteriormente en archivos. No se requiere el privilegio root para analizar paquetes de
254 RH342-RHEL7.2-es-1-20160321
Captura de paquetes con tcpdump
archivos de captura existentes. El elemento de menú File (Archivo) > Open… (Abrir…)
selecciona el archivo que se cargará, o el usuario puede especificar el archivo como una
opción cuando ejecuta wireshark desde la línea de comandos.
[user@demo ~]$ wireshark -r yesterday-eth0,pcapng &
Inspección de paquetes con Wireshark

El cuadro Filter: (Filtrar:) permite que el usuario ingrese expresiones para limitar los paquetes
que se muestran en Wireshark. Wireshark reconoce una variedad de protocolos de red, de
bajo y alto nivel. Ingresar “http” filtrará los paquetes capturados para que se muestren solo
los paquetes HTTP TCP. Escribir “ip” o “ipv6” filtrará los paquetes para que se muestren solo
los paquetes IPv4 o IPv6, respectivamente.
El botón Expression… (Expresión…) lleva a los usuarios a un cuadro de diálogo que los ayuda
a crear expresiones de filtrado más sólidas. La expresión ip.src == 192.168.10.23
filtrará los paquetes para que solo se muestren los paquetes que se originan de
192.168.10.23.
Los cuadros de la pantalla principal de Wireshark permiten que el usuario inspeccione

el contenido de los paquetes. El cuadro superior muestra la lista de encabezados de los
paquetes capturados que se seleccionaron con el filtro actual. El paquete resaltado es el que
se está mostrando actualmente en el cuadro del medio y en el cuadro inferior. El cuadro
inferior muestra el paquete completo, ambos encabezados y datos, en formato hexadecimal
y ASCII.
El cuadro del medio muestra el paquete como fue analizado por Wireshark. Cada encabezado
de capa de la red se muestra en un formato breve legible por el ojo humano. Si expande
cada encabezado, el usuario puede ver información más detallada acerca de los datos de la
capa de red. Cada línea comienza con el nombre de campo del encabezado seguido por su
valor. Cuando es posible, Wireshark traduce valores a cadenas. Por ejemplo, cuando 22 es el
valor de una dirección de puerto TCP, se muestra como “ssh” con el valor bruto de 22 entre
paréntesis. Cuando se selecciona cada campo, los datos sin formato correspondientes se
resaltan en el cuadro inferior.
Wireshark también puede mostrar paquetes relacionados entre un cliente de protocolo y un

servidor en un formato mucho más legible. Esto se logra al hacer clic con el botón derecho
del mouse en un paquete y, luego, seleccionar Follow TCP Stream (Seguir flujo de TCP). Los
mensajes del cliente se muestran en un color y las respuestas del servidor se muestran en
otro color.

El comando tcpdump se puede utilizar para capturar y mostrar paquetes en un entorno no
gráfico. Es proporcionado por el paquete tcpdump y se instala en los sistemas del servidor de
Red Hat Enterprise Linux 7 de manera predeterminada.
Cuando se invoca sin argumentos, tcpdump captura y muestra información acerca de los
paquetes que salen de la interfaz de red principal y que llegan a esta. La ejecución continúa
hasta que el usuario interrumpe el programa al escribir Ctrl+C. La opción -c COUNT hace
que tcpdump se cierre después de que se capturan los paquetes COUNT. Cuando el programa
se cierra, muestra un resumen de la cantidad de paquetes capturados por el programa.
[root@demo ~]# tcpdump -c 3
RH342-RHEL7.2-es-1-20160321 255
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:17:58.499620 IP servera.lab.example.com.ssh > 172.25.250.250.56573:
Flags [P.], seq 861940776:861940972, ack 498126305, win 325, options
[nop,nop,TS val 56643816 ecr 1185210527], length 196
10:17:58.499680 IP 172.25.250.250.56573 > servera.lab.example.com.ssh:
Flags [.], ack 196, win 322, options [nop,nop,TS val 1185210632 ecr
56643816], length 0
10:17:58.499985 IP servera.lab.example.com.42442 >
workstation.lab.example.com.domain: 670+ PTR?
250.250.25.172.in-addr.arpa. (45)
3 packets captured
4 packets received by filter
0 packets dropped by kernel
tcpdump muestra la información del paquete en resultados estándares, a menos que se

utilice la opción -w FILE. La opción -w hace que los paquetes se escriban en el archivo
especificado como datos sin formato para un análisis posterior. Se recomienda otorgarle un
nombre a los archivos de captura de paquetes con una extensión .pcap, aunque tcpdump no
lo requiere. Puede invocar tcpdump con una opción -r FILE para leer un archivo de captura,
en lugar de escuchar las interfaces de red. No se requiere el privilegio root para procesar
archivos de paquetes existentes a través de tcpdump.
[user@demo ~]$ tcpdump -r http-test.pcap

reading from file http-test.pcap, link-type EN10MB (Ethernet)
serverb.lab.example.com.http: Flags [S], seq 981393578, win 29200,
options [mss 1460,sackOK,TS val 103035086 ecr 0,nop,wscale 7], length 0
11:52:54.699499 IP serverb.lab.example.com.http >
tcpdump puede filtrar el paquete que captura en función de una expresión que se pasa como
argumento. El siguiente comando solo captura paquetes que provienen del host denominado
ntpserver o que van hacia él.
[root@demo ~]# tcpdump 'host ntpserver'
El siguiente comando tcpdump captura paquetes ICMP que vienen desde y van hacia
192.168.32.7.
[root@demo ~]# tcpdump 'icmp and host 192.168.32.7'
Se pueden usar expresiones más complejas con operadores lógicos. El siguiente comando
tcpdump filtra todos los paquetes IP entre el host matrix y cualquier otro host, excepto
human175.
[root@demo ~]# tcpdump 'ip host matrix and not human175'
Puede encontrar más información acerca de la sintaxis para las expresiones de filtrado
tcpdump en la página del manual pcap-filter(7).
El comando tcpdump también tiene opciones que controlan la información que muestra
acerca de cada paquete capturado. La opción -x hace que tcpdump muestre la información
de datos y el encabezado del paquete como valores hexadecimales. La opción -X muestra los
256 RH342-RHEL7.2-es-1-20160321
datos como valores hexadecimales y ASCII. Esto es útil si el protocolo de red de más alto nivel
incluye comandos de texto. Wireshark puede leer y analizar el paquete que captura archivos
creados por tcpdump para realizar un análisis más profundo.
nota
Wireshark también tiene una versión basada en texto, denominada tshark. Este
programa es proporcionado por el paquete wireshark.
Referencias
Páginas del manual pcap-filter(7), tcpdump(8), tcpslice(8), tshark(1) y
wireshark-filter(4)
RH342-RHEL7.2-es-1-20160321 257
Ejercicio guiado: Inspección del tráfico de red
En este trabajo de laboratorio, instalará Wireshark y lo utilizará para capturar, filtrar e

inspeccionar paquetes de red. También utilizará tcpdump para realizar funciones similares en
un entorno de texto.
Recursos
URL de la • http://materials.example.com
aplicación
• http://materials.example.com/rh342-practice.tcpdump
• http://serverb.lab.example.com
Archivos • http-test.tcpdump.
• practice.pcapng
• rh342-practice.tcpdump
• serverb
• workstation
Resultados
Debería poder capturar, filtrar e inspeccionar paquetes de red a través de Wireshark y
tcpdump.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab network-traffic
setup en su sistema workstation. Esto instalará y configurará un servidor web en serverb.
[student@workstation ~#$ lab network-traffic setup
1. Inicie sesión como student en workstation. Abra una ventana del terminal como root
e instale los paquetes que proporciona Wireshark.
[root@workstation ~]# yum -y install wireshark-gnome
2. Ejecute Wireshark como root y configúrelo para capturar paquetes en todas las
interfaces de red.
2.1. Como root, use la shell para ejecutar Wireshark.
[root@workstation ~]# wireshark &
2.2. Seleccione Capture (Capturar) > Interfaces… para abrir el cuadro de diálogo
Wireshark: Capture Interfaces (Wireshark: Capturar interfaces). Haga clic en la
casilla que se encuentra junto a la interfaz any y, luego, haga clic en el botón Start
(Iniciar) para comenzar a capturar paquetes.
258 RH342-RHEL7.2-es-1-20160321
3. Genere tráfico de red en servera desde workstation.
3.1. Envíe algunas solicitudes ICMP.
[root@workstation ~]# ping servera.lab.example.com
3.2. Genere tráfico de NTP. Use ntpdate para actualizar el reloj del sistema.
[root@workstation ~]# ntpdate classroom.example.com
3.3. Genere tráfico de red HTTP. Inicie Firefox y examine http://

materials.example.com.
4. Detenga Wirwshark para que no capture más paquetes de red. Seleccione Capture
(Capturar) > Stop (Detener), o escriba Ctrl+E.
5. Realice un filtrado simple y una inspección en el tráfico de red capturado.
5.1. Filtre los paquetes para que solo se pueda ver el tráfico ICMP. Ingrese icmp en el
cuadro Filter: (Filtrar:). Use el cuadro del medio para inspeccionar los diferentes
valores de encabezado y datos para algunos de los paquetes mostrados.
5.2. Filtre los paquetes para que solo se pueda ver el tráfico NTP. Ingrese ntp en el
cuadro Filter: (Filtrar:). Inspeccione los encabezados y datos de algunos paquetes.
5.3. Filtre los paquetes para que solo se puedan ver los paquetes HTTP. Ingrese http en
el cuadro Filter: (Filtrar:).
Haga clic con el botón derecho del mouse en cualquier paquete HTTP y, luego,
seleccione Follow TCP Stream (Seguir flujo de TCP). El contenido del flujo se
mostrará en un formato mucho más legible. Los mensajes del cliente HTTP se
muestran en un color (rojo) y las respuestas del servidor HTTP se muestran en otro
color (azul).
6. Guarde los datos del paquete capturado para un análisis posterior. Seleccione File
(Archivo) > Save (Guardar), o escriba Ctrl+S para abrir el cuadro de diálogo Save
Capture File (Guardar archivo de captura). Seleccione el directorio de inicio de root para
el campo Guardar en la carpeta:. Especifique practice en el campo Name: (Nombre:).
Deje Wireshark/... - pcapng como el tipo seleccionado en el campo File Type: (Tipo de
archivo:). Haga clic en el botón Save (Guardar) para guardar los datos capturados.
Confirme que se haya creado el archivo de datos capturado.
[root@workstation ~]# ls practice*

practice.pcapng
[root@workstation ~]# file practice*
practice.pcapng: pcap-ng capture file - version 1.0
7. Inicie sesión como student en workstation. Descargue un archivo de captura

existente y ábralo con Wireshark. El archivo se puede descargar de la siguiente URL:
http://materials.example.com/rh342-practice.tcpdump.
7.1. Descargue el archivo de captura rh342-practice.tcpdump.
RH342-RHEL7.2-es-1-20160321 259
[student@workstation ~]$ curl -O http://materials.example.com/rh342-

practice.tcpdump
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 126k 100 126k 0 0 11.0M 0 --:--:-- --:--:-- --:--:-- 12.3M
[student@workstation ~]$ ls -l rh342-practice.tcpdump
-rw-r--r--. 1 student student 129205 Feb 4 11:10 rh342-practice.tcpdump
7.2. Ejecute Wireshark desde el escritorio de GNOME. Seleccione Applications

(Aplicaciones) > Internet > Wireshark Network Analyzer.
7.3. Abra el archivo de captura. Seleccione File (Archivo) > Open… (Abrir…), o escriba
Ctrl+O para abrir el cuadro de diálogo Open Capture File (Abrir archivo de captura).
Explore y seleccione el archivo rh342-practice.tcpdump. Haga clic en el botón
Open (Abrir).
8. Filtre los datos capturados para que solo se puedan ver los paquetes SMTP. Ingrese smtp
en el cuadro Filter: (Filtrar:).
9. Inspeccione el contenido de los paquetes de red. Haga clic en los iconos "+" en el cuadro
del medio para expandir diferentes partes del paquete de red. Trate de encontrar el texto
del mensaje de correo electrónico.
10. Haga clic con el botón derecho del mouse en el intercambio SMTP y, luego, seleccione
Follow TCP Stream (Seguir flujo de TCP). El contenido del flujo se mostrará en un formato
mucho más legible. Los mensajes del servidor SMTP se muestran en un color (azul) y los
mensajes del cliente SMTP se muestran en otro color (rojo). La cadena “GOLD RING HAS
BEEN CAUGHT” es la primera línea del cuerpo del mensaje de correo.
11. También puede usar la utilidad tcpdump para capturar y mostrar tráfico de red. Es útil en
entornos no gráficos.
11.1.Inicie sesión como root en serverb y compruebe que tcpdump está instalado en el
sistema.
[root@serverb ~]# rpm -q tcpdump

tcpdump-4.5.1-3.el7.x86_64
11.2.Ejecute tcpdump en serverb para que capture tráfico de red relacionado con
servera. Para capturar paquetes desde las interfaces de red, se necesita un
privilegio root.
[root@serverb ~]# tcpdump 'ip host servera'

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11.3.Inicie sesión como student en servera y ping serverb.
[student@servera ~]$ ping -c 3 serverb

PING serverb.lab.example.com (172.25.250.11) 56(84) bytes of data.
64 bytes from serverb.lab.example.com (172.25.250.11): icmp_seq=1 ttl=64
time=0.266 ms
260 RH342-RHEL7.2-es-1-20160321
time=0.303 ms
time=0.229 ms

11.4.Observe el resultado de tcpdump que se muestra en serverb.
11:37:54.013541 IP servera.lab.example.com > serverb.lab.example.com:

ICMP echo request, id 3657, seq 1, length 64
11:37:54.013598 IP serverb.lab.example.com > servera.lab.example.com:
ICMP echo reply, id 3657, seq 1, length 64
11.5.Salga de tcpdump en serverb.
Ctrl+C
6 packets captured
12. Utilice tcpdump para capturar tráfico de red que entra en un puerto específico. Guarde
los paquetes capturados en un archivo para un análisis posterior.
12.1.Ejecute tcpdump en serverb para que capture tráfico HTTP. Debería guardar los
paquetes de red capturados en un archivo llamado http-test.tcpdump.
[root@serverb ~]# tcpdump -w http-test.tcpdump 'port 80'

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
12.2.Desde servera, muestre el contenido web servido por serverb.
[student@servera ~]$ curl http://serverb.lab.example.com

serverb is providing web content.
12.3.Finalice tcpdump para completar la captura.
Ctrl+C
10 packets captured
13. Use tcpdump para mostrar el tráfico de red capturado.
RH342-RHEL7.2-es-1-20160321 261
13.1.La opción -r FILENAME hace que tcpdump lea datos de red desde un archivo en
lugar de desde interfaces de red. Sin otras opciones, solo se muestra la información
del encabezado del paquete.
[root@serverb ~]# tcpdump -r http-test.tcpdump

reading from file http-test.tcpdump, link-type EN10MB (Ethernet)
11:52:54.699499 IP serverb.lab.example.com.http >
servera.lab.example.com.51091: Flags [S.], seq 3953903445, ack
981393579, win 28960, options [mss 1460,sackOK,TS val 223556028 ecr
103035086,nop,wscale 7], length 0
serverb.lab.example.com.http: Flags [.], ack 1, win 229, options
serverb.lab.example.com.http: Flags [P.], seq 1:72, ack 1, win 229,
options [nop,nop,TS val 103035086 ecr 223556028], length 71
13.2.Muestre solo los paquetes entrantes que vinieron de servera. Se pueden usar
expresiones para filtrar los paquetes que se muestran. La opción -x hace que los
datos del paquete se muestren en formato hexadecimal.
[root@serverb ~]# tcpdump -x -r http-test.tcpdump 'src servera'

0x0000: 4500 003c d064 4000 4006 1e0e ac19 fa0a
0x0010: ac19 fa0b c793 0050 3a7e e0aa 0000 0000
0x0020: a002 7210 4c78 0000 0204 05b4 0402 080a
0x0030: 0624 30ce 0000 0000 0103 0307
0x0000: 4500 0034 d065 4000 4006 1e15 ac19 fa0a
0x0010: ac19 fa0b c793 0050 3a7e e0ab ebab c756
0x0020: 8010 00e5 4c70 0000 0101 080a 0624 30ce
0x0030: 0d53 31bc
13.3.La opción -X hace que los datos del paquete se muestren en formato hexadecimal y
ASCII. Intente reconocer algunas de las solicitudes HTTP que vinieron de servera.
[root@serverb ~]# tcpdump -X -r http-test.tcpdump 'src servera'

0x0000: 4500 003c d064 4000 4006 1e0e ac19 fa0a E..<.d@.@.......
0x0010: ac19 fa0b c793 0050 3a7e e0aa 0000 0000 .......P:~......
0x0020: a002 7210 4c78 0000 0204 05b4 0402 080a ..r.Lx..........
0x0030: 0624 30ce 0000 0000 0103 0307 .$0.........
262 RH342-RHEL7.2-es-1-20160321
0x0000: 4500 0034 d065 4000 4006 1e15 ac19 fa0a E..4.e@.@.......
0x0010: ac19 fa0b c793 0050 3a7e e0ab ebab c756 .......P:~.....V
0x0020: 8010 00e5 4c70 0000 0101 080a 0624 30ce ....Lp.......$0.
0x0030: 0d53 31bc .S1.
serverb.lab.example.com.http: Flags [P.], seq 0:71, ack 1, win 229,
options [nop,nop,TS val 103035086 ecr 223556028], length 71
0x0000: 4500 007b d066 4000 4006 1dcd ac19 fa0a E..{.f@.@.......
0x0010: ac19 fa0b c793 0050 3a7e e0ab ebab c756 .......P:~.....V
0x0020: 8018 00e5 4cb7 0000 0101 080a 0624 30ce ....L........$0.
0x0030: 0d53 31bc 4745 5420 2f20 4854 5450 2f31 .S1.GET./.HTTP/1
0x0040: 2e31 0d0a 5573 6572 2d41 6765 6e74 3a20 .1..User-Agent:.
0x0050: 6375 726c 2f37 2e32 392e 300d 0a48 6f73 curl/7.29.0..Hos
0x0060: 743a 2073 6572 7665 7262 0d0a 4163 6365 t:.serverb..Acce
0x0070: 7074 3a20 2a2f 2a0d 0a0d 0a pt:.*/*....
14. Copie los datos HTTP capturados en workstation para un análisis más profundo.
[root@serverb ~]# scp http-test.tcpdump student@workstation:

student@workstation's password: student
http-test.tcpdump 100% 1224 1.2KB/s 00:00
Use Wireshark en workstation para ver el tráfico de red HTTP capturado. Asegúrese de
“seguir” el flujo TCP para ver el intercambio HTTP en un formato mucho más legible.
RH342-RHEL7.2-es-1-20160321 263

problemas de red
En este trabajo de laboratorio, identificará y corregirá los ajustes de red mal configurados de
un servidor.
Recursos
URL de la aplicación http://serverb.lab.example.com
• serverb
Resultados
Deberá poder diagnosticar y reparar los problemas de configuración de red que causan que
un servicio de red no esté disponible.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab network-lab setup
en su sistema workstation. Esto implementará un servidor web y ajustará la configuración
de red de serverb.
[student@workstation ~]$ lab network-lab setup
Hay un servidor web ejecutándose en serverb que publica contenido. Se debería poder ver
el contenido en la siguiente URL: http://serverb.lab.example.com.
El administrador junior que configuró serverb perdió los documentos que contenían
las especificaciones de la red para el servidor. El equipo de la red ha configurado
adecuadamente la entrada DNS para serverb en sus servidores. Diagnostique y corrija la
configuración de la red de serverb para que el contenido web esté disponible. Asegúrese de
que las correcciones de la red perduren.
1. Determine cuáles se suponen que son los ajustes de la red IP pública de serverb.
2. Inicie sesión en serverb. Diagnostique y solucione los problemas de la red para que el
contenido web esté disponible.
3. Confirme que el contenido web esté disponible en serverb.
4. Evalúe su trabajo ejecutando el comando lab network-lab grade de su máquina

workstation.
[student@workstation ~]$ lab network-lab grade
ejercicios.
264 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, identificará y corregirá los ajustes de red mal configurados de
un servidor.
Recursos
URL de la aplicación http://serverb.lab.example.com
• serverb
Resultados
Deberá poder diagnosticar y reparar los problemas de configuración de red que causan que
un servicio de red no esté disponible.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab network-lab setup
en su sistema workstation. Esto implementará un servidor web y ajustará la configuración
de red de serverb.
[student@workstation ~]$ lab network-lab setup
Hay un servidor web ejecutándose en serverb que publica contenido. Se debería poder ver
el contenido en la siguiente URL: http://serverb.lab.example.com.
El administrador junior que configuró serverb perdió los documentos que contenían
las especificaciones de la red para el servidor. El equipo de la red ha configurado
adecuadamente la entrada DNS para serverb en sus servidores. Diagnostique y corrija la
configuración de la red de serverb para que el contenido web esté disponible. Asegúrese de
que las correcciones de la red perduren.
1. Determine cuáles se suponen que son los ajustes de la red IP pública de serverb.
1.1. Identifique la dirección IPv4 pública de serverb.
[student@servera ~]$ host serverb.lab.example.com

serverb.lab.example.com has address 172.25.250.11
serverb.lab.example.com has IPv6 address fd37:5265:6448:6174::b
1.2. Identifique la puerta de enlace y la máscara de red IPv4. (Sugerencia: Tanto servera
como workstation están configuradas para esa red).
[student@servera ~]$ ip addr show dev eth0

state UP qlen 1000
[student@servera ~]$ ip route
default via 172.25.250.254 dev eth0 proto static metric 100
metric 100
RH342-RHEL7.2-es-1-20160321 265

metric 100
La red es /24 con una puerta de enlace predeterminada de 172.25.250.254.
1.3. Determine un nombre DNS que el serverb pueda utilizar.
[student@servera ~]$ cat /etc/resolv.conf

2. Inicie sesión en serverb. Diagnostique y solucione los problemas de la red para que el
contenido web esté disponible.
2.1. Muestre los ajustes de la red actual. Esto identificará la cantidad de interfaces de red
actuales y mostrará su configuración inicial.
[root@serverb ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
state UP qlen 1000
link/ether 52:54:00:00:fa:0b brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe00:fa0b/64 scope link
state UP qlen 1000
inet6 fd37:5265:6448:6174::b/64 scope global
2.2. Hay dos interfaces de red física. Determine los nombres de conexión de
NetworkManager.
[root@serverb ~]# nmcli conn

System eth1 9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04 802-3-ethernet eth1
Una tercera conexión puede hacer referencia a eth1, pero no tiene un dispositivo
asociado en la última columna. Desaparecerá cuando serverb se reinicie y se
puede omitir tranquilamente. La interfaz asociada con eth0 está conectada a la red
externa, por lo que merece mayor atención.
2.3. Muestre los ajustes de NetworkManager IPv4 para eth0.
266 RH342-RHEL7.2-es-1-20160321
Solución
[root@serverb ~]# nmcli conn show 'System eth0' | grep ipv4

ipv4.method: manual
ipv4.dns: 172.25.250.254
ipv4.addresses: 172.25.251.11/24
ipv4.gateway: 172.25.251.254
ipv4.routes:
ipv4.may-fail: yes
Los ajustes del servidor DNS parecen correctos, pero la interfaz de red está
configurada para una subred equivocada. Debería estar configurada para la red
172.25.250.0/24. El administrador junior debe haber escrito el tercer octeto de la
dirección IP.
2.4. Realice una copia de respaldo de los archivos de configuración de la interfaz antes de
realizar cambios.
[root@serverb ~]# cp /etc/sysconfig/network-scripts/ifcfg-* .
2.5. Ajuste la conexión de red que corresponde al dispositivo eth0.
[root@serverb ~]# nmcli conn mod 'System eth0' \

> ipv4.addresses '172.25.250.11/24' ipv4.gateway 172.25.250.254
2.6. Confirme los nuevos ajustes.
[root@serverb ~]# nmcli conn show 'System eth0' | grep ipv4

ipv4.method: manual
ipv4.dns: 172.25.250.254
ipv4.addresses: 172.25.250.11/24
ipv4.gateway: 172.25.250.254
ipv4.routes:
ipv4.may-fail: yes
2.7. Reinicie la conexión para activar los nuevos ajustes.
[root@serverb ~]# nmcli conn down 'System eth0'

RH342-RHEL7.2-es-1-20160321 267
[root@serverb ~]# nmcli conn up 'System eth0'

[root@serverb ~]# ip addr show dev eth0
state UP qlen 1000
2.8. Confirme que los puertos del firewall HTTP están abiertos.
[root@serverb ~]# firewall-cmd --list-ports

443/tcp 80/tcp
2.9. Reinicie el servicio para que se una a la nueva dirección.
[root@serverb ~]# systemctl restart httpd
3. Confirme que el contenido web esté disponible en serverb.
[student@servera ~]$ curl http://serverb.lab.example.com

serverb is providing web content.
4. Evalúe su trabajo ejecutando el comando lab network-lab grade de su máquina

workstation.
[student@workstation ~]$ lab network-lab grade
ejercicios.
268 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
• ping y ping6 son herramientas útiles para enviar solicitudes de ICMP.
• nmap puede analizar rápidamente una red en busca de hosts, o puede realizar análisis de
puerto más exhaustivos que requieren mucho más tiempo.
• El comando ncat, o nc, puede utilizarse como un cliente de red simple o puede actuar
como un servidor simple para probar la conectividad de las redes.
• iptraf-ng es una herramienta basada en curses para monitorear tráfico de red.
• Para solucionar los nombres de dispositivos de red incorrectos, ajuste las variables DEVICE
y HWADDR en el archivo de configuración de la interfaz de red adecuado, ifcfg-*, y, luego,
reinicie.
• Se puede usar el comando nmcli para diagnosticar y corregir problemas de configuración

de red con NetworkManager. Debe reiniciar las interfaces activas para que se apliquen los
nuevos ajustes.
• Wireshark es una herramienta efectiva para capturar, filtrar e inspeccionar paquetes de

redes.
• El comando tcpdump puede capturar y, opcionalmente, mostrar paquetes en entornos no

gráficos.
RH342-RHEL7.2-es-1-20160321 269
270
TRAINING
CAPÍTULO 8
SOLUCIÓN DE PROBLEMAS DE LA
APLICACIÓN
Visión general
Meta Resolver los problemas de la aplicación.
Objetivos • Identificar las dependencias de la librería del software
de terceros.
• Identificar si una aplicación sufre fugas de memoria.
• Depurar una aplicación con herramientas estándares.

Secciones • Resolución de dependencias de la librería (y ejercicio
guiado)
• Depuración de fugas de memoria (y ejercicio guiado)
• Depuración de ejecuciones de la aplicación (y ejercicio

guiado)
Trabajo de laboratorio • Solución de problemas de la aplicación
RH342-RHEL7.2-es-1-20160321 271
Capítulo 8. Solución de problemas de la aplicación
Resolución de dependencias de la librería
Objetivos
Después de completar esta sección, los estudiantes podrán identificar dependencias de la
librería para software de terceros.
Uso de librerías compartidas con aplicaciones

La mayoría de las aplicaciones de Linux se vinculan dinámicamente con las librerías
compartidas que usan. Las librerías compartidas están diseñadas de manera tal que
permiten que se asignen sus funciones a la memoria de una aplicación cuando se ejecuta
la aplicación. Dado que el código requerido es proporcionado por la librería en el tiempo de
ejecución, no se copia a la propia aplicación.
Las aplicaciones de enlaces dinámicos con librerías compartidas tienen muchos beneficios:
• Los archivos ejecutables binarios de la aplicación son más pequeños debido a que el
código de la librería no se copia en ellos.
• La librería puede compartirse con varios programas que se están ejecutando

simultáneamente. Esto ocupa menos memoria del sistema.
• Las librerías compartidas facilitan la resolución de errores en el código de la librería. La

mayoría de las resoluciones en una librería compartida no requieren que se restablezcan
todas las aplicaciones vinculadas.
Vinculación con librerías compartidas

Cuando se crea una aplicación, se vincula con las librerías compartidas que proporcionan las
funciones que utiliza. El compilador revisa las librerías en busca de los símbolos requeridos y
confirma que existen.
La información de identificación acerca de cada librería requerida está incrustada en el

archivo ejecutable. Este puede ser el nombre de ruta absoluta de la librería, pero con mayor
frecuencia es el campo DT_SONAME de la librería compartida. El campo DT_SONAME incluye el
nombre y la versión de la librería compartida, para que la aplicación utilice la versión correcta
en el tiempo de ejecución. Este campo se configura cuando se crea la librería compartida
con la opción -soname en el enlazador ln. El comando objdump incluye este campo cuando
muestra información acerca de una librería compartida.
[user@demo ~]$ objdump -p /usr/lib64/libpthread-2.17.so | grep SONAME

SONAME libpthread.so.0
La librería compartida tiene un enlace simbólico que la señala y que coincide con su campo
DT_SONAME.
[user@demo ~]$ ls -l /usr/lib64/libpthread*

-rwxr-xr-x. 1 root root 142304 Aug 14 2015 /usr/lib64/libpthread-2.17.so
lrwxrwxrwx. 1 root root 18 Nov 2 11:16 /usr/lib64/libpthread.so.0 ->
libpthread-2.17.so
Cuando se ejecuta una aplicación, el enlazador de tiempo de ejecución identifica las librerías
compartidas requeridas y las asigna al espacio de memoria del programa. En Red Hat
Enterprise Linux 7, /lib64/ld-linux-x86-64.so* es el valor predeterminado, una versión
272 RH342-RHEL7.2-es-1-20160321
de 64 bits del enlazador de tiempo de ejecución. Viene con el paquete glibc.x86_64. La versión
de 32 bits de la librería glibc proporciona la versión de 32 bits del enlazador de tiempo de
ejecución cuando se instala.
[user@demo ~]$ rpm -qlp glibc-2.17-105.el7.i686.rpm | grep ld-linux

/lib/ld-linux.so.2
El enlazador de tiempo de ejecución utiliza los nombres de DT_SONAME incrustados en la

aplicación para determinar las versiones que la librería utiliza. A continuación, busca esas
librerías en el sistema a través de los siguientes pasos:
• Busca los directorios especificados en la variable del entorno LD_LIBRARY_PATH. Este
paso se omite para las aplicaciones setUID y setGID. Esta variable del entorno a menudo
se utiliza cuando se crea o se prueba una aplicación, y se deben usar las librerías de
desarrollo.
• Se consulta al archivo de caché /etc/ld.so.cache. Contiene una lista recopilada de

librerías candidatas que se encontraron anteriormente. El comando ldconfig -p imprime
la lista de librerías asignadas en /etc/ld.so.cache.
[user@demo ~]$ ldconfig -p

373 libs found in cache `/etc/ld.so.cache'
p11-kit-trust.so (libc6,x86-64) => /lib64/p11-kit-trust.so
libz.so.1 (libc6,x86-64) => /lib64/libz.so.1
libyaml-0.so.2 (libc6,x86-64) => /lib64/libyaml-0.so.2
libyajl.so.2 (libc6,x86-64) => /lib64/libyajl.so.2
libxtables.so.10 (libc6,x86-64) => /lib64/libxtables.so.10
libxslt.so.1 (libc6,x86-64) => /lib64/libxslt.so.1
• Por último, busca los directorios en las rutas de librerías predeterminadas. El cargador
de librería compartida de 64 bits señala las versiones de 64 bits de las ubicaciones
predeterminadas, /lib64 y /usr/lib64. /lib y /usr/lib son los directorios que el
enlazador de tiempo de ejecución de 32 bits busca.
[user@demo ~]$ strings /lib64/ld-linux-x86-64.so.2 | grep '^/'

/t6E
/~5D9
/var/tmp
/var/profile
/lib64/
/usr/lib64/
/etc/suid-debug
/%x %s
/proc/self/exe
/etc/ld.so.cache
/proc/sys/kernel/osrelease
/dev/full
/dev/null
/etc/ld.so.preload
El comando ldd muestra las librerías compartidas que una determinada aplicación requiere
en el tiempo de ejecución. Se muestra el nombre DT_SONAME de cada librería, seguido del
nombre de ruta de la librería en el sistema.
[user@demo ~]$ ldd /usr/sbin/httpd
RH342-RHEL7.2-es-1-20160321 273
linux-vdso.so.1 => (0x00007ffc4d377000)

libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa706100000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fa705edb000)
libaprutil-1.so.0 => /lib64/libaprutil-1.so.0 (0x00007fa705cb1000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa705a7a000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa705850000)
libdb-5.3.so => /lib64/libdb-5.3.so (0x00007fa705491000)
libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007fa705262000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa705046000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fa704e41000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa704a80000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fa70485b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa7065f1000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fa704655000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007fa704452000)
nota
El nombre de ruta absoluta de una librería está incrustado en un programa cuando
la librería compartida no tiene un campo DT_SONAME. En el ejemplo anterior, la
referencia /lib64/ld-linux-x86-64.so.2 señala al propio enlazador de tiempo
de ejecución.
Solución de problemas de dependencia de la librería

Pueden ocurrir problemas de dependencia de la librería en un sistema Red Hat Enterprise
Linux cuando se instala software de terceros sin utilizar Yum o RPM. El uso de las opciones --
force o --nodeps con rpm también puede causar problemas de dependencia de la librería.
Los problemas de dependencia de la librería son fáciles de identificar. Cuando una aplicación
hace referencia a una librería compartida que no está disponible, el enlazador de tiempo de
ejecución muestra un mensaje de error particular. Muestra el nombre de la primera librería
que no puede encontrar, luego sale de la aplicación con un estado de salida de 127.
[user@demo ~]$ application

application: error while loading shared libraries: library.so.X: cannot
open shared object file: No such file or directory
[user@demo ~]$ echo $?
127
Es posible, y muy probable, que haya otras librerías que el enlazador de tiempo de ejecución
no pueda resolver. Se puede usar el comando ldd para mostrar las librerías compartidas
utilizadas por una aplicación. Las librerías que no pueden resolverse en el tiempo de
ejecución se muestran como “no encontrada”.
[user@demo ~]$ which application

/usr/bin/application
[student@demo ~]$ ldd /usr/bin/application
linux-vdso.so.1 => (0x00007ffcbeba9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcbd3e7d000)
library1.so.2 => not found
library2.so.0 => not found
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fcbd409a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcbd4aa7000)
274 RH342-RHEL7.2-es-1-20160321
Una vez que se identifican las librerías compartidas que faltan, debe instalarlas en el
sistema. Esta es una tarea relativamente simple cuando las librerías son proporcionadas
por un paquete RPM. Los paquetes RPM incluyen información de dependencia de la librería
compartida dentro de los metadatos del paquete.
[user@demo ~]$ rpm -q --requires httpd | grep pthread

libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
El comando yum whatprovides identifica el paquete que proporciona la librería compartida

especificada.
[user@demo ~]$ yum whatprovides '*lib/libpthread.so.0'

glibc-2.17-105.el7.i686 : The GNU libc libraries
Repo : rhel_dvd
Matched from:
Filename : /lib/libpthread.so.0
Si la librería compartida no está incluida y distribuida por Red Hat, tendrá que comunicarse
con el proveedor externo para ver si puede proporcionarla. Cuando se instala o se
elimina una librería compartida del sistema, el comando ldconfig debería ejecutarse sin
argumentos. ldconfig actualiza la caché del enlazador de tiempo de ejecución, /etc/
ld.so.cache.
[user@demo ~]$ rpm -q --scripts libnl

postinstall program: /sbin/ldconfig
postuninstall program: /sbin/ldconfig
Referencias
Páginas del manual: ld(1), ldconfig(8), ld.so(8), ldd(1), nm(1) y objdump(1).
RH342-RHEL7.2-es-1-20160321 275
Ejercicio guiado: Resolución de dependencias

de la librería
En este trabajo de laboratorio, instalará un software de terceros y resolverá las dependencias

de la librería.
Recursos
Máquina • servera
Resultados
Debe poder identificar cuáles son las librerías que una aplicación necesita ejecutar en un
sistema.
Andes de comenzar
Prepárese para este ejercicio ejecutando el comando lab app-libdeps setup en su
sistema workstation. Esta acción descargará e instalará la aplicación genisoimage en
servera.
[student@workstation ~#$ lab app-libdeps setup
Otro administrador del sistema instaló la aplicación genisoimage y no pudo hacerla

funcionar. Usted tiene la tarea de hacerla funcionar.
1. Inicie sesión como student en servera. Intente ejecutar el programa instalado

recientemente para observar cómo se comporta.
[student@servera ~]$ genisoimage

genisoimage: error while loading shared libraries: libusal.so.0: cannot
[student@servera ~]$ echo $?
127
Se muestra un mensaje de error útil. Cuando el sistema no puede resolver una librería
compartida, el programa genera el mismo estado de salida que la shell cuando no puede
encontrar un comando.
2. Descubra cuáles son las librerías compartidas que el programa requiere. El mensaje
de error deja en claro que se requiere libusal.so.0, pero es posible que falten otras
librerías requeridas.
[student@servera ~]$ which genisoimage

/usr/bin/genisoimage
[student@servera ~]$ ldd /usr/bin/genisoimage
linux-vdso.so.1 => (0x00007ffcbeba9000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fcbd409a000)
libusal.so.0 => not found
librols.so.0 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcbd3e7d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcbd4aa7000)
276 RH342-RHEL7.2-es-1-20160321
En el resultado anterior, se pueden resolver todas las librerías exceptos dos:
libusal.so.0 y librols.so.0.
3. Utilice Yum para determinar si se pueden instalar paquetes que proporcionen esas
librerías.
[student@servera ~]$ yum whatprovides libusal.so.0

libusal-1.1.11-23.el7.i686 : Library to communicate with SCSI devices
Repo : rhel_dvd
Matched from:
Provides : libusal.so.0
[student@servera ~]$ yum whatprovides librols.so.0
libusal-1.1.11-23.el7.i686 : Library to communicate with SCSI devices
Repo : rhel_dvd
Matched from:
Provides : librols.so.0
4. Ambas librerías vienen con el paquete libusal. Inicie sesión como root en servera e
instálelo.
[root@servera ~]# yum -y install libusal
5. Como el usuario student, intente ejecutar el programa nuevamente.
[student@servera ~]$ genisoimage

genisoimage: Missing pathspec.
Usage: genisoimage [options] -o file directory ...
Use genisoimage -help

to get a list of valid options.
Report problems to debburn-devel@lists.alioth.debian.org.
El archivo ejecutable funciona. Imprimió un mensaje de uso debido a argumentos no

válidos.
6. Red Hat Enterprise Linux proporciona un paquete que brinda un comando

genisoimage. Utilice Yum para determinar cuál es el RPM que proporciona esa
funcionalidad.
[student@servera ~]$ yum whatprovides '*bin/genisoimage'

genisoimage-1.1.11-23.el7.x86_64 : Creates an image of an ISO9660 file-system
Repo : rhel_dvd
Matched from:
Filename : /usr/bin/genisoimage
7. Utilice el comando yumdownloader para descargar el paquete en el directorio de inicio

de student. No intente instalarlo.
RH342-RHEL7.2-es-1-20160321 277
[student@servera ~]$ yumdownloader genisoimage

Loaded plugins: langpacks
genisoimage-1.1.11-23.el7.x86_64.rpm | 298 kB 00:00
8. La gestión del paquete RPM simplifica la gestión del sistema. La dependencia de la

librería se habría detectado cuando se instaló el software al comienzo.
[student@servera ~]$ rpm -q --requires -p genisoimage-*.rpm

warning: genisoimage-1.1.11-23.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key
ID fd431d51: NOKEY
libbz2.so.1()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libmagic.so.1()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
librols.so.0()(64bit)
libusal = 1.1.11-23.el7
libusal.so.0()(64bit)
libz.so.1()(64bit)
Se identifican y se almacenan las librerías de tiempo de ejecución en los metadatos del

paquete cuando se crea un paquete.
9. Cuando finalice, verifique su trabajo ejecutando el comando lab app-libdeps grade

desde su máquina workstation.
[student@workstation ~]$ lab app-libdeps grade
10. Opcional: Elimine el paquete que proporciona las librerías necesarias.
10.1.Como root en servera, utilice yum para eliminar el paquete libusal.
[root@servera ~]# yum -y erase libusal
Yum no objetó cuando se le pidió eliminar las librerías requeridas.
10.2.Intente ejecutar la aplicación.
[root@servera ~]# genisoimage

genisoimage: error while loading shared libraries: libusal.so.0: cannot
El programa está dañado otra vez. Si la aplicación fue proporcionada por un paquete,
rpm y yum habrían estado al tanto de la dependencia de la librería.
278 RH342-RHEL7.2-es-1-20160321
11. Después de calificar su sistema, restablezca correctamente su máquina al estado que
tenía antes de iniciar el trabajo de laboratorio, al restablecer su máquina virtual o al
[student@workstation ~]$ lab app-libdeps reset
RH342-RHEL7.2-es-1-20160321 279
Depuración de fugas de memoria
Objetivos
Después de completar esta sección, los estudiantes podrán identificar si una aplicación sufre
de fugas de memoria.
Diagnóstico de fugas de memoria

A menudo, un proceso no libera memoria correctamente después de que termina de
utilizarla. Dado que kernel libera toda la memoria de un proceso cuando la cierra, este es un
problema grave cuando el proceso es uno breve, como ls o netstat. El problema puede
convertirse en uno grave cuando los procesos de larga duración fugan memoria. Imagine
un servidor web que fuga 8 KiB de memoria para cada solicitud HTTP que maneja. Dicho
proceso consumiría la mayor parte de la memoria disponible en un sistema en solo unas
horas. Además de finalizar y reiniciar un proceso, el administrador de un sistema no puede
hacer mucho para solucionar una fuga de memoria.
Identificar fugas de memoria es una de las responsabilidades de un administrador de

sistemas. Se pueden usar herramientas genéricas como ps, top, free, sar -r ysar -R
para identificar una fuga de memoria. También hay herramientas especializadas, como la
herramienta memcheck de valgrind, que identificará si una aplicación tiene una fuga de
memoria. El siguiente comando ejecutará un proceso mediante la herramienta memcheck.
[root@demo ~]# valgrind --tool=memcheck program [program arguments]
La opción --leak-check=full producirá información más detallada sobre cuál es la

función dentro del programa que está fugando memoria.
[root@demo ~]# valgrind --tool=memcheck --leak-check=full program [program arguments]
Debe estar atento a dos tipos diferentes de fugas de memoria. En el primer caso, un
programa solicita memoria con una llamada del sistema como malloc, pero no utiliza
realmente la memoria solicitada. Esto hace que el tamaño virtual del programa aumente
(VIRT en top). También aumentará la línea Committed_AS en /proc/meminfo, pero no se
utiliza una memoria física real. El tamaño residente (RSS en top) permanece (casi) igual.
Cuando un programa utiliza realmente la memoria que asigna, esto hace que el tamaño
residente aumente en función del tamaño virtual, lo que provoca una escasez de memoria.
Aunque fugar la memoria virtual no es bueno, fugar la memoria residente tendrá un mayor
impacto en el sistema.
Una vez que se detecta una fuga de memoria, comuníquese con el desarrollador de software
que desarrolló la aplicación. El código fuente requerirá mayor análisis, se deberán realizar
correcciones y se tendrá que restablecer y probar la aplicación para resolver este tipo de
problema.
280 RH342-RHEL7.2-es-1-20160321
Diagnóstico de fugas de memoria
Referencias
Páginas del manual: sar(1), valgrind(1)
Para obtener más información, consulte la sección Valgrind en la Guía para

desarrolladores de Red Hat Enterprise Linux 7, disponible en https://
access.redhat.com/docs
Para obtener más información, consulte la sección Valgrind en la Guía de

ajuste de rendimiento de Red Hat Enterprise Linux 7, disponible en
https://access.redhat.com/docs
Para obtener más información, consulte la sección Perfilado del uso de

memoria de la aplicación con Valgrind en la Guía de ajuste de
rendimiento de Red Hat Enterprise Linux 7, disponible en https://
access.redhat.com/docs
RH342-RHEL7.2-es-1-20160321 281
Ejercicio guiado: Depuración de fugas de

memoria
En este trabajo de laboratorio, identificará fugas de memoria.
Recursos
Resultados
Debería poder utilizar valgrind para identificar una fuga de memoria virtual y una fuga de
memoria residente.
Andes de comenzar
Prepárese para este ejercicio ejecutando el comando lab app-memleak setup en su
sistema workstation. Este comando instala el paquete bigmem en servera.
[student@workstation ~#$ lab app-memleak setup
El programa bigmem es conocido por fugar memoria (por diseño). Para verificarlo, ejecútelo
con la herramienta memcheck de valgrind.
1. Instale valgrind en servera.
[root@servera ~]# yum -y install valgrind
2. Ejecute el comando bigmem en valgrind y pida que se asigne 256 MiB de memoria
residente.
[root@servera ~]# valgrind --tool=memcheck bigmem 256

==3182== Memcheck, a memory error detector
==3182== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3182== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==3182== Command: bigmem 256
==3182==
Attempting to allocate 256 Mebibytes of resident memory...
Press <Enter> to exit Enter
==3182==
==3182== HEAP SUMMARY:
==3182== in use at exit: 268,435,456 bytes in 256 blocks
==3182== total heap usage: 256 allocs, 0 frees, 268,435,456 bytes allocated
==3182==
==3182== LEAK SUMMARY:
==3182== definitely lost: 265,289,728 bytes in 253 blocks
==3182== indirectly lost: 0 bytes in 0 blocks
==3182== possibly lost: 3,145,728 bytes in 3 blocks
==3182== still reachable: 0 bytes in 0 blocks
==3182== suppressed: 0 bytes in 0 blocks
==3182== Rerun with --leak-check=full to see details of leaked memory
==3182==
==3182== For counts of detected and suppressed errors, rerun with: -v
==3182== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
El resumen valgrind indica que se detectó una fuga de memoria.
282 RH342-RHEL7.2-es-1-20160321
3. Repita esta tarea con bigmem, y ahora pida que se asigne 256 MiB de memoria virtual.
[root@servera ~]# valgrind --tool=memcheck bigmem -v 256

[root@servera student]# valgrind --tool=memcheck bigmem -v 256
==3183== Memcheck, a memory error detector
==3183== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3183== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==3183== Command: bigmem -v 256
==3183==
Attempting to allocate 256 MebiBytes of virtual memory...
Press <Enter> to exit Enter
==3183==
==3183== HEAP SUMMARY:
==3183== in use at exit: 268,435,456 bytes in 256 blocks
==3183== total heap usage: 256 allocs, 0 frees, 268,435,456 bytes allocated
==3183==
==3183== LEAK SUMMARY:
==3183== definitely lost: 265,289,728 bytes in 253 blocks
==3183== indirectly lost: 0 bytes in 0 blocks
==3183== possibly lost: 3,145,728 bytes in 3 blocks
==3183== still reachable: 0 bytes in 0 blocks
==3183== suppressed: 0 bytes in 0 blocks
==3183== Rerun with --leak-check=full to see details of leaked memory
==3183==
==3183== For counts of detected and suppressed errors, rerun with: -v
==3183== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
El resultado valgrind es el mismo que el de la ejecución anterior.
4. valgrind detectó la fuga de memoria, pero no está claro qué tipo de fuga de memoria
tiene bigmem.
4.1. En un terminal independiente, ejecute el siguiente comando:
[root@servera ~]# watch -d -n1 'free -m; grep -i commit /proc/meminfo'
Esto proporcionará un resumen de la memoria asignada y confirmada.
4.2. Ahora que está seguro de que bigmem fuga memoria, ejecute los dos comandos
nuevamente, pero esta vez sin valgrind. Preste atención al resultado del comando
watch.
[root@servera ~]# bigmem 256

[root@servera ~]# bigmem -v 256
¿Puede explicar lo que ve?
Dado que bigmem utiliza realmente la memoria que solicita cuando se ejecuta sin
la opción -v, tanto la memoria confirmada como la memoria residente aumentan
según la cantidad solicitada.
Cuando se ejecuta con la opción -v, la memoria confirmada aumenta según la

cantidad solicitada, pero la memoria residente no aumenta tanto. (Aumenta un poco,
ya que debe utilizarse memoria para el archivo ejecutable, las tablas de su página,
etc.).
RH342-RHEL7.2-es-1-20160321 283
4.3. Utilice Ctrl+C para interrumpir el comando watch. Cierre la sesión del terminal.
5. Restablezca su máquina al estado que tenía antes de iniciar el trabajo de laboratorio,

al restablecer sus máquinas virtuales o al ejecutar el siguiente comando en su sistema
workstation.
[student@workstation ~]$ lab app-memleak reset
284 RH342-RHEL7.2-es-1-20160321
Depuración de ejecuciones de la aplicación
Depuración de ejecuciones de la aplicación
Objetivos
Después de completar esta sección, los estudiantes podrán depurar una aplicación a través
de las herramientas de software de Red Hat Enterprise Linux.
Solución de problemas de la ejecución de

aplicaciones
Algunas aplicaciones tienen problemas cuando se ejecutan. Los programas no siempre
producen mensajes de error útiles con información detallada que ayudan a diagnosticar el
problema. Otras aplicaciones dejan de responder silenciosamente. Se pueden atrapar en un
bucle, esperando que ocurra un evento externo, como la creación de un archivo o la conexión
de un cliente de red. Para solucionar problemas en estos tipos de aplicaciones, se necesita
más información acerca de su estado actual.
Los comandos strace y ltrace muestran la información actual de la ejecución de un

programa. Estas utilidades interceptan llamadas del sistema de una aplicación en ejecución,
señales o llamadas de una librería compartida en el caso de ltrace. A continuación,
muestran información detallada acerca del error en la ejecución de la aplicación.
Visualización de llamadas del sistema con strace

strace muestra información acerca de las llamadas y señales del sistema relacionadas con
una aplicación. Esta utilidad viene con el RPM strace. La manera más simple de usar strace
es utilizarlo para ejecutar una aplicación. La aplicación, con sus opciones y argumentos, se
pasa como argumentos para strace. Tenga en cuenta el siguiente comando strace.
[user@demo ~]$ strace pwd

execve("/bin/pwd", ["pwd"], [/* 17 vars */]) = 0
brk(0) = 0x11a1000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2e6ad66000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=28767, ...}) = 0
mmap(NULL, 28767, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2e6ad5e000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \34\2\0\0\0\0\0"..., 832) = 832
mmap(NULL, 3932736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f2e6a785000
mprotect(0x7f2e6a93b000, 2097152, PROT_NONE) = 0
mmap(0x7f2e6ab3b000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,
3, 0x1b6000) = 0x7f2e6ab3b000
mmap(0x7f2e6ab41000, 16960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x7f2e6ab41000
close(3) = 0
0x7f2e6ad5d000
0x7f2e6ad5b000
arch_prctl(ARCH_SET_FS, 0x7f2e6ad5b740) = 0
mprotect(0x7f2e6ab3b000, 16384, PROT_READ) = 0
RH342-RHEL7.2-es-1-20160321 285
mprotect(0x606000, 4096, PROT_READ) = 0

mprotect(0x7f2e6ad67000, 4096, PROT_READ) = 0
munmap(0x7f2e6ad5e000, 28767) = 0
brk(0) = 0x11a1000
brk(0x11c2000) = 0x11c2000
brk(0) = 0x11c2000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
mmap(NULL, 106065056, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2e6425e000
close(3) = 0
getcwd("/home/user", 4096) = 14
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
0x7f2e6ad65000
write(1, "/home/user\n", 14/home/user
) = 14
close(1) = 0
munmap(0x7f2e6ad65000, 4096) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++
strace se inicia mediante la ejecución del comando pwd. Esto se logra mediante el
comando execve. Las siguientes llamadas del sistema access, open, fstat, mmap y close
muestran el enlazador de tiempo de ejecución que asigna las necesidades pwd de las
librerías compartidas a su espacio de memoria. La llamada del sistema getcwd devuelve
el directorio de trabajo actual a la aplicación, luego write lo muestra en la pantalla. Cada
llamada del sistema se muestra con los argumentos que se pasaron, o devolvieron, con el
valor de retorno mostrado. Cuando falla una llamada del sistema, también se muestra el
valor numérico y simbólico de la variable errno. Esto puede ayudar a un administrador a
comprender por qué falló la llamada del sistema.
Por lo general, strace solo mostrará información acerca del proceso que se ejecuta. Si desea
seguir la ejecución de procesos secundarios generados por la aplicación, debe especificar la
opción -f.
strace también puede realizar un seguimiento de un proceso que ya está en ejecución. Si

invoca strace con una opción -p PID, se adjunta al proceso en ejecución y a los detalles
de resultado de las llamadas del sistema realizadas por ese proceso. Tenga en cuenta el
siguiente ejemplo.
[user@demo ~]$ ps -ef | grep httpd

user 1010 10243 0 09:28 pts/4 00:00:00 grep --color=auto httpd
apache 1552 1729 0 Feb22 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
root 1729 1 0 Feb10 ? 00:00:48 /usr/sbin/httpd -DFOREGROUND
[user@demo ~]$ strace -p 1552
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
El uso anterior de strace produjo un error. Solo root, o el usuario que es propietario de un
proceso, puede usar strace para adjuntarse a ese proceso.
[root@demo ~]# strace -p 1552

Process 1552 attached
accept4(4, Ctrl+CProcess 1552 detached
286 RH342-RHEL7.2-es-1-20160321
Solución de problemas de la ejecución de aplicaciones
<detached ...>
El proceso 1552 está suspendido en la ejecución de la llamada del sistema accept.

Probablemente esté esperando que se realice una conexión del cliente de red entrante. Si
interrumpe strace conectado a un proceso con Ctrl+C, se finaliza la detección, pero la
aplicación continúa su ejecución.
[root@demo ~]# strace -p 1729

Process 1729 attached
select(0, NULL, NULL, NULL, {0, 161417}) = 0 (Timeout)
wait4(-1, 0x7ffc71ec05dc, WNOHANG|WSTOPPED, NULL) = 0
select(0, NULL, NULL, NULL, {1, 0}Ctrl+CProcess 1729 detached
<detached ...>
El proceso 1729 está en un bucle que ejecuta la llamada del sistema select, lo que hace
que el proceso se suspenda por un segundo. Cada vez que se activa, ejecuta la llamada del
sistema wait4 para ver si han salido algunos de sus procesos secundarios.
El resultado de strace también puede guardarse en un archivo separado con la opción -o

FILENAME. Esto permite que un usuario interactúe normalmente con la aplicación sin que se
intercale el resultado con el resultado strace.
Para detectar solo llamadas del sistema específicas, puede usar la opción -e. Por ejemplo,
para detectar solo las llamadas del sistema open y stat, mientras se envía el resultado al
archivo /tmp/mytrace, se puede utilizar el siguiente comando:
[root@demo ~]# strace -o /tmp/mytrace -e open,stat mycommand
Visualización de llamadas de librería con ltrace

ltrace es similar a strace, excepto que realiza un seguimiento de llamadas de las
funciones de la librería compartida en lugar de llamadas del sistema. Además, mostrará
llamadas del sistema cuando se utiliza con la opción -S. Tenga en cuenta el siguiente
resultado ltrace. Muestra las funciones de la librería utilizadas por el comando pwd.
Compare el siguiente resultado con el resultado strace que se mostró antes en esta sección.
[root@demo ~]# ltrace pwd

__libc_start_main(0x401760, 1, 0x7ffd1251f0a8, 0x404a00 <unfinished ...>
getenv("POSIXLY_CORRECT") = nil
strrchr("pwd", '/') = nil
setlocale(LC_ALL, "") = "en_US.UTF-8"
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils") = "coreutils"
__cxa_atexit(0x4022f0, 0, 0, 0x736c6974756572) = 0
getopt_long(1, 0x7ffd1251f0a8, "LP", 0x606d00, nil) = -1
getcwd(nil, 0) = ""
puts("/root"/root
) = 6
free(0x21ba030) = <void>
exit(0 <unfinished ...>
__fpending(0x7f70c03c7400, 0, 64, 0x7f70c03c7eb0) = 0
RH342-RHEL7.2-es-1-20160321 287
fileno(0x7f70c03c7400) = 1
__freading(0x7f70c03c7400, 0, 64, 0x7f70c03c7eb0) = 0
__freading(0x7f70c03c7400, 0, 2052, 0x7f70c03c7eb0) = 0
fflush(0x7f70c03c7400) = 0
fclose(0x7f70c03c7400) = 0
__fpending(0x7f70c03c71c0, 0, 0x7f70c03c8a00, 0xfbad000c) = 0
fileno(0x7f70c03c71c0) = 2
__freading(0x7f70c03c71c0, 0, 0x7f70c03c8a00, 0xfbad000c) = 0
__freading(0x7f70c03c71c0, 0, 4, 0xfbad000c) = 0
fflush(0x7f70c03c71c0) = 0
fclose(0x7f70c03c71c0) = 0
+++ exited (status 0) +++
ltrace también se puede adjuntar a procesos que se están ejecutando actualmente.
[root@demo ~]# ltrace -p 1729

apr_proc_wait_all_procs(0x7ffc71ec06a0, 0x7ffc71ec069c, 0x7ffc71ec0698, 1) = 0x11176
apr_sleep(0xf4240, 0x7ffc71ec05dc, 3, 0) = 0
apr_proc_wait_all_procs(0x7ffc71ec06a0, 0x7ffc71ec069c, 0x7ffc71ec0698, 1) = 0x11176
apr_sleep(0xf4240, 0x7ffc71ec05dc, 3, 0Ctrl+C
Los usuarios sin privilegios solo pueden ejecutar, no leer, algunos programas binarios.
ltrace requiere acceso de lectura para que el ejecutable funcione.
[user@demo ~]$ ls -l /usr/bin/testprog

-rwx--x--x. 1 root root 57903 Feb 15 15:01 /usr/bin/testprog
[user@demo ~]$ ltrace testprog
Can't open /bin/testprog: Permission denied
strace funcionará cuando el ejecutable sea de ejecución y no de lectura, pero su resultado

proporciona información útil limitada. En el siguiente ejemplo, testprog intenta abrir
un archivo para el acceso de lectura. El archivo existe, pero el programa no puede abrir el
archivo para el acceso de lectura. Debido a que strace no puede leer el ejecutable, no puede
mostrar el nombre del archivo de interés.
[user@demo ~]$ strace testprog

execve("/bin/testprog", ["testprog"], [/* 17 vars */]) = 0
brk(0) = 0xb51000
mprotect(0x7f0f60157000, 4096, PROT_READ) = 0
munmap(0x7f0f6014e000, 28826) = 0
open(0x404515, O_RDONLY) = -1 EACCES (Permission denied)
write(2, 0x404528, 35Unable to open configuration file.
) = 35
exit_group(1) = ?
Auditoría de la ejecución del programa

El daemon de auditoría de Linux, auditd, también puede utilizarse para resolver problemas
de tiempo de ejecución de la aplicación. El comando auditctl gestiona las reglas que hacen
que el daemon registre información acerca de eventos del sistema en /var/log/audit/
audit.log. Estas reglas pueden desencadenarse en función de las llamadas del sistema con
fallas, la ejecución de una aplicación por parte del usuario o en la aplicación específica.
La siguiente sesión muestra cómo usar auditd para resolver problemas en una aplicación
que tiene fallas en el tiempo de ejecución.
288 RH342-RHEL7.2-es-1-20160321
Solución de problemas de la ejecución de aplicaciones
[root@demo ~]# example

Error: configuration file not found
[root@demo ~]# auditctl -a always,exit -F arch=b64 -S open -F success=0
[root@demo ~]# example
Error: configuration file not found
[root@demo ~]# tail /var/log/audit/audit.log
type=CONFIG_CHANGE msg=audit(1456381239.150:916): auid=0 ses=2
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="add_rule" key=(null)
list=4 res=1
type=SYSCALL msg=audit(1456381246.155:917): arch=c000003e syscall=2 success=no exit=-2
a0=404515 a1=0 a2=d a3=7fff048aae20 items=1 ppid=1484 pid=29841 auid=0 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="example" exe="/usr/
bin/example" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1456381246.155:917): cwd="/root"
type=PATH msg=audit(1456381246.155:917): item=0 name="/etc/example.conf" objtype=UNKNOWN
El mensaje de error sugiere que hay una falla en la apertura de un archivo, por lo que
se utiliza auditctl para activar una regla que audita llamadas del sistema open() que
tienen fallas (-F success=0). Con la nueva regla en vigor, la falla de la aplicación genera
un mensaje de error útil en el archivo audit.log. La aplicación no pudo abrir un archivo
denominado /etc/example.conf.
Una vez que se recopila la información necesaria, se puede utilizar el comando auditctl -d
para eliminar la regla auditd.
[root@demo ~]# auditctl -d always,exit -F arch=b64 -S open -F success=0
Referencias
Páginas del manual auditctl(8), auditd(8), ausearch(8), ltrace(1) y strace(1)
RH342-RHEL7.2-es-1-20160321 289
Ejercicio guiado: Depuración de ejecuciones

de la aplicación
En este trabajo de laboratorio, resolverá problemas en una aplicación que tiene errores en el
tiempo de ejecución.
Recursos
Resultados
Debe poder utilizar ltrace y strace para diagnosticar problemas de la aplicación en el
tiempo de ejecución.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab app-runtime setup
en su sistema workstation. Esta acción descargará e instalará la aplicación progress en
servera.
[student@workstation ~#$ lab app-runtime setup
Su Administrador ha oído hablar sobre una herramienta útil llamada progress. Después
de investigar en Internet, se ha descubierto que un archivo tar proporciona este programa
para Linux. Ha recibido la tarea de instalar el programa, con su documentación, en servera y
probarlo.
1. Ejecute el archivo ejecutable progress. Mostrará un mensaje de error que no es muy

útil.
[root@servera ~]# progress

Unable to open configuration file.
2. Busque errores de AVC en /var/log/messages. Si encuentra errores de AVC que se

relacionan con los errores de este programa, enviar una consulta a auditd podría
proporcionar información más útil.
[root@servera ~]# tail -n 5 /var/log/messages

Feb 15 19:36:06 servera systemd: Starting Session 2 of user root.
Feb 15 19:36:06 servera dbus-daemon: dbus[515]: [system] Activating
service name='org.freedesktop.problems' (using servicehelper)
Feb 15 19:36:06 servera dbus[515]: [system] Activating service
Feb 15 19:36:06 servera dbus[515]: [system] Successfully activated service
'org.freedesktop.problems'
Feb 15 19:36:06 servera dbus-daemon: dbus[515]: [system] Successfully
activated service 'org.freedesktop.problems'
El comando progress no produjo errores de AVC, por lo que debe buscar información
útil en otra parte.
3. Use el comando strace para ver las llamadas del sistema que progress realiza.
290 RH342-RHEL7.2-es-1-20160321
[root@servera ~]# strace progress
execve("/usr/bin/progress", ["progress"], [/* 25 vars */]) = 0
brk(0) = 0x1722000
mprotect(0x7fa05801b000, 4096, PROT_READ) = 0
munmap(0x7fa058012000, 28767) = 0
open("/etc/ntp.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "Unable to open configuration fil"..., 35Unable to open configuration file.
) = 35
exit_group(1) = ?
El programa intentó abrir /etc/ntp.conf para acceso de lectura. No se encontró el

archivo; es por esto que el programa se cerró.
4. La versión de progress instalada en servera requiere acceso a /etc/ntp.conf.

Adopte medidas para que este archivo esté disponible.
4.1. Use el comando yum whatprovides para determinar si /etc/ntp.conf es

proporcionado por un paquete.
[root@servera ~]# yum whatprovides /etc/ntp.conf

rhel_dvd | 4.1 kB 00:00
(1/2): rhel_dvd/group_gz | 136 kB 00:00
(2/2): rhel_dvd/primary_db | 3.6 MB 00:00
ntp-4.2.6p5-22.el7.x86_64 : The NTP daemon and utilities
Repo : rhel_dvd
Matched from:
Filename : /etc/ntp.conf
4.2. Es proporcionado por el paquete ntp. Instale ese paquete en servera.
[root@servera ~]# yum -y install ntp
5. Ejecute la utilidad progress nuevamente.
[root@servera ~]# progress

No command currently running: cp, mv, dd, tar, cat, rsync, grep, fgrep,
egrep, cut, sort, md5sum, sha1sum, sha224sum, sha256sum, sha384sum,
sha512sum, adb, gzip, gunzip, bzip2, bunzip2, xz, unxz, lzma, unlzma,
zcat, bzcat, lzcat, or wrong permissions.
[root@servera ~]# echo $?
0
Ejecuta y devuelve correctamente un estado de salida cero.
6. Observe lo que sucede cuando /etc/ntp.conf está presente, pero el usuario sin
privilegios no lo puede leer.
6.1. Cambie los permisos del archivo para que no se pueda leer.
[root@servera ~]# ls -l /etc/ntp.conf

-rw-r--r--. 1 root root 1992 Oct 16 01:46 /etc/ntp.conf
RH342-RHEL7.2-es-1-20160321 291
[root@servera ~]# chmod 600 /etc/ntp.conf

[root@servera ~]# ls -l /etc/ntp.conf
-rw-------. 1 root root 1992 Oct 16 01:46 /etc/ntp.conf
6.2. Inicie sesión como student en servera y ejecute el comando progress.
[student@servera ~]$ progress

Unable to open configuration file.
[student@servera ~]$ strace progress
execve("/bin/progress", ["progress"], [/* 17 vars */]) = 0
brk(0) = 0x144f000
mprotect(0x7f4fbe256000, 4096, PROT_READ) = 0
munmap(0x7f4fbe24d000, 28826) = 0
open(0x404515, O_RDONLY) = -1 EACCES (Permission denied)
write(2, 0x404528, 35Unable to open configuration file.
) = 35
exit_group(1) = ?
Aunque produciría el mismo mensaje de error poco útil, strace muestra el valor
errno que indica por qué falló la llamada del sistema open.
7. Como root en servera, instale el paquete ltrace.
[root@servera ~]# yum -y install ltrace
8. Como student, use ltrace para ejecutar progress.
[student@servera ~]$ ltrace progress

__libc_start_main(0x403554, 1, 0x7ffcc9485118, 0x403b40 <unfinished ...>
getenv("PROGRESS_ARGS") = nil
open64("/etc/ntp.conf", 0, 015) = -1
fwrite("Unable to open configuration fil"..., 1, 35, 0x7fc6e8d571c0Unable
to open configuration file.
) = 35
exit(1 <no return ...>
+++ exited (status 1) +++
ltrace produce información de diagnóstico similar a strace. El uso de progress

habría ayudado a identificar el problema.
9. Restablezca su máquina al estado que tenía antes de iniciar el trabajo de laboratorio,

al restablecer sus máquinas virtuales o al ejecutar el siguiente comando en su sistema
workstation.
[student@workstation ~]$ lab app-runtime reset
292 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Solución de problemas de la aplicación

problemas de la aplicación
En este trabajo de laboratorio, depurará una aplicación de un tercero.
Recursos
Resultados
Debe poder diagnosticar y resolver problemas de dependencia de la librería y de tiempo de
ejecución de la aplicación.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab app-lab setup en su
sistema workstation. Esta acción descargará e instalará la aplicación gdisk en servera.
[student@workstation ~#$ lab app-lab setup
Otro administrador del sistema instaló la aplicación gdisk y no pudo hacerla funcionar.
Usted tiene la tarea de hacerla funcionar.
1. Ejecute el programa instalado recientemente para observar cómo se comporta.
2. Identifique las librerías compartidas que el programa necesita. Instale los paquetes que
cumplirán con los requisitos de la librería compartida.
3. Resuelva los problemas de tiempo de ejecución adicionales que evitan que gdisk se
ejecute.
4. Cuando finalice, verifique su trabajo ejecutando el comando lab app-lab grade desde
[student@workstation ~]$ lab app-lab grade
5. Después de calificar correctamente su trabajo, reinicie las tres máquinas.
RH342-RHEL7.2-es-1-20160321 293
Solución
En este trabajo de laboratorio, depurará una aplicación de un tercero.
Recursos
Resultados
Debe poder diagnosticar y resolver problemas de dependencia de la librería y de tiempo de
ejecución de la aplicación.
Andes de comenzar
Configure sus sistemas para este ejercicio al ejecutar el comando lab app-lab setup en su
sistema workstation. Esta acción descargará e instalará la aplicación gdisk en servera.
[student@workstation ~#$ lab app-lab setup
Otro administrador del sistema instaló la aplicación gdisk y no pudo hacerla funcionar.
Usted tiene la tarea de hacerla funcionar.
1. Ejecute el programa instalado recientemente para observar cómo se comporta.
1.1. Inicie sesión como root en servera y ejecute el archivo ejecutable gdisk.
[root@servera ~]# gdisk

gdisk: error while loading shared libraries: libicuio.so.50: cannot open
shared object file: No such file or directory
1.2. Tenga en cuenta la dependencia de librería que falta, libicuio.so.50.

Posiblemente se necesiten más librerías para ejecutar este programa.
2. Identifique las librerías compartidas que el programa necesita. Instale los paquetes que
cumplirán con los requisitos de la librería compartida.
2.1. Identifique las librerías compartidas que el comando gdisk utiliza y que no pueden
resolverse.
[root@servera ~]# which gdisk

/usr/sbin/gdisk
[root@servera ~]# ldd /usr/sbin/gdisk
linux-vdso.so.1 => (0x00007ffe7d94b000)
libicuio.so.50 => not found
libicuuc.so.50 => not found
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fedd9a5f000)
Todas las librerías compartidas se resolvieron excepto dos: libicuio.so.50 y

libicuuc.so.50.
2.2. Utilice Yum para determinar si se pueden instalar paquetes que proporcionen esas
librerías.
[root@servera ~]# yum whatprovides libicuio.so.50

294 RH342-RHEL7.2-es-1-20160321
Solución
libicu-50.1.2-15.el7.i686 : International Components for Unicode - libraries

Repo : rhel_dvd
Matched from:
Provides : libicuio.so.50
[root@servera ~]# yum whatprovides libicuuc.so.50
libicu-50.1.2-15.el7.i686 : International Components for Unicode - libraries
Repo : rhel_dvd
Matched from:
Provides : libicuuc.so.50
2.3. Ambas librerías vienen con el paquete libicu. Instálelo.
[root@servera ~]# yum -y install libicu
2.4. gdisk se ejecuta correctamente, pero ahora muestra su propio mensaje de error.

GPT fdisk (gdisk) version 0.8.6
Fatal error: license not found.
3. Resuelva los problemas de tiempo de ejecución adicionales que evitan que gdisk se
ejecute.
3.1. El comando gdisk produce un mensaje de error poco claro: “Fatal error: license not
found.” Busque errores de AVC en /var/log/messages.
[root@servera ~]# tail -n 5 /var/log/messages

Feb 18 12:01:01 servera systemd: Started Session 464 of user root.
Feb 18 12:10:01 servera systemd: Started Session 465 of user root.
Feb 18 12:14:15 servera yum[2758]: Installed: libicu-50.1.2-15.el7.x86_64
No hay errores de AVC causados por el programa, por lo que no es necesario enviar
una consulta a auditd.
3.2. Use el comando strace o ltrace para ver las llamadas del sistema que gdisk
realiza. Esto aclarará un poco el problema.
nota
Es posible que deba instalar el paquete ltrace en servera, si decide
utilizarlo.
[root@servera ~]# strace gdisk

write(1, "GPT fdisk (gdisk) version 0.8.6\n"..., 33GPT fdisk (gdisk)
version 0.8.6
) = 33
open("/usr/share/doc/gdisk-0.8.6/GPL", O_RDONLY) = -1 ENOENT (No such
RH342-RHEL7.2-es-1-20160321 295
file or directory)
write(2, "Fatal error: license not found.\n", 32Fatal error: license
not found.
) = 32
exit_group(1) = ?
3.3. gdisk intentó abrir un archivo denominado GPL de su directorio de documentación

en /usr/share/doc. Cree el archivo que está buscando y vea si eso resuelve el
problema.
[root@servera ~]# touch /usr/share/doc/gdisk-0.8.6/GPL

GPT fdisk (gdisk) version 0.8.6
Type device filename, or press <Enter> to exit: Enter
4. Cuando finalice, verifique su trabajo ejecutando el comando lab app-lab grade desde
[student@workstation ~]$ lab app-lab grade
5. Después de calificar correctamente su trabajo, reinicie las tres máquinas.
296 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
• El comando objdump -p puede utilizarse para detectar el SONAME incrustado de una

librería compartida.
• Se utiliza ldconfig para actualizar e imprimir los contenidos de la caché del enlazador de
tiempo de ejecución /etc/ld.so.cache.
• El comando ldd APPLICATION muestra las librerías compartidas requeridas por una
aplicación.
• El comando valgrind --tool=memcheck puede identificar si un programa tiene una fuga

de memoria.
• Hay dos tipos de fugas de memoria: las que roban del espacio de dirección para un
proceso y las que consumen memoria física que afectan a todo el sistema.
• El comando strace puede realizar un seguimiento de las llamadas del sistema realizadas
por una aplicación.
• ltrace puede mostrar las llamadas de la librería compartida que una aplicación realiza.
• Se pueden agregar reglas de auditoría para que el daemon de auditoría registre

información de diagnóstico útil en /var/log/audit/audit.log.
RH342-RHEL7.2-es-1-20160321 297
298
TRAINING
CAPÍTULO 9
TRATAMIENTO DE PROBLEMAS
DE SEGURIDAD
Visión general
Meta Identificar y solucionar los problemas relacionados con
subsistemas de seguridad.
Objetivos • Identificar y solucionar los problemas relacionados con
SELinux.
• Identificar y solucionar problemas en la autorización y

autenticación de usuarios.
• Identificar y solucionar los problemas relacionados con

la gestión de identidades de LDAP y Kerberos.
Secciones • Resolución de problemas de SELinux (y ejercicio guiado)
• Gestión de problemas de autenticación (y ejercicio

guiado)
• Resolución de problemas de Kerberos y LDAP (y ejercicio

guiado)
Trabajo de laboratorio • Tratamiento de problemas de seguridad
RH342-RHEL7.2-es-1-20160321 299
Capítulo 9. Tratamiento de problemas de seguridad
Solución de problemas de SELinux
Objetivos
Después de completar esta sección, los estudiantes podrán identificar y corregir problemas
relacionados con SELinux.
Registros de SELinux
Cuando SELinux bloquea una acción, por ejemplo, cuando un servidor web intenta escribir
en /etc/shadow, esta acción se registra a través del daemon auditd. Puede ver estos
registros de auditoría en /var/log/audit/audit.log, o puede buscarlos con el comando
ausearch. El uso de ausearch permite que los administradores se centren exactamente en
los mensajes en los que están interesados.
[root@demo ~]# ausearch -m avc -ts recent

----
time->Mon Feb 22 10:55:49 2016
type=SYSCALL msg=audit(1456134949.107:5677): arch=c000003e syscall=2 success=no

exit=-13 a0=7f62712ebd40 a1=80000 a2=0 a3=7ffc267d3650 items=0 ppid=26656
pid=26658 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48
sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd"
subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1456134949.107:5677) : avc: denied { open } for

pid=26658 comm="httpd" path="/var/www/html/index.html" dev="vda1" ino=18259175
scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0
tclass=file
La opción -m avc le indica a ausearch que solo debería mostrar mensajes de Control
de vector de acceso (AVC, Access Vector Control), el tipo de mensaje asociado con las
denegaciones de SELinux.
La opción -ts recent especifica que se deben mostrar los mensajes de hace
10 minutos. También se pueden usar otras indicaciones, como today (hoy), yesterday
(ayer) y this-week (esta semana), así como horas reales.
Por lo general, se muestran dos líneas por cada denegación de SELinux; la acción que
causó la denegación, normalmente una llamada del sistema, y la propia denegación.
La línea type=SYSCALL tendrá información útil, como el ID de usuario real, original y
efectivo del proceso de llamada.
La denegación real tendrá type=AVC al comienzo.
La parte audit(1456134949.107:5677) enumera la hora a la que se pasó este
mensaje al sistema de auditoría. Esta hora está en segundos desde la época (hora
de UNIX); para convertirla a la zona horaria local, puede usar el comando date --
date=@timestamp.
Esto muestra la lista de acciones denegadas. Las acciones comunes incluyen read para
leer, open para abrir y getattr para solicitar información adicional del archivo.
Otros campos en la línea type=AVC identifican el nombre del proceso para el que se denegó
una acción, la ruta del sistema de archivos (no la ruta absoluta, sino la ruta de un sistema de
archivos individual), el dispositivo que almacena el sistema de archivos, el inodo del archivo
de destino, y los contextos de SELinux completos del proceso que intenta acceder a algo, y el
proceso, destino, archivo o puerto de red al que se está accediendo.
300 RH342-RHEL7.2-es-1-20160321
Herramientas para la solución de problemas de SELinux
Reglas dontaudit
Hay algunas acciones que se realizan con tanta frecuencia, pero son denegadas siempre, que
la política SELinux tiene una regla dontaudit especial para ellas. Esto significa que la acción
aún estará bloqueada, pero no se registrará.
Puede ver una lista completa de reglas dontaudit activas con el comando sesearch -D
desde el paquete setools-console.
Cuando un administrador sospecha que una regla dontaudit es la causa de un problema,

puede deshabilitar todas las reglas dontaudit temporalmente con el comando semanage
dontaudit off. Esto deshabilitará todas las reglas dontaudit hasta que se ejecute el
comando semanage dontaudit on.
Importante
Las reglas dontaudit existen por una razón. Por lo general, son acciones que se
realizan con frecuencia, deben estar siempre bloqueadas y no tienen un impacto
en el comportamiento del sistema. Sin embargo, hay muchas ocurrencias de estas
acciones. Mantener a dontaudit deshabilitado completará el registro de auditoría
rápidamente y hará que sea más difícil centrarse en las denegaciones importantes.
Herramientas para la solución de problemas de

SELinux
Aunque muchas denegaciones simples de SELinux, como archivos con etiquetas incorrectas
en /var/www/html, se pueden diagnosticar y solucionar al observar /var/log/audit/
audit.log y ejecutar restorecon en los archivos y directorios relevantes, algunos
problemas pueden ser más difíciles de diagnosticar y solucionar correctamente. En esos
casos, puede obtener más asistencia al instalar setroubleshoot-server.
El paquete setroubleshoot-server proporciona dos herramientas principales, el comando

sealert y el complemento (plug-in) sedispatch para auditd.
Cuando el daemon auditd recibe un mensaje, lo envía al complemento (plug-in)

sedispatch. A continuación, este complemento (plug-in) reenvía cualquier mensaje de AVC a
setroubleshootd a través del protocolo dbus.
nota
Es posible que deba reiniciar el daemon auditd antes de activar el complemento
(plug-in) sedispatch. A diferencia de otros servicios, este aún requiere el uso del
comando service: service auditd restart.
Cuando setroubleshootd recibe un mensaje de denegación, lo analizará con varios

complementos (plug-ins); luego, registrará la denegación, y una lista de posibles causas y
soluciones, en el registro del sistema.
RH342-RHEL7.2-es-1-20160321 301
Importante
setroubleshootd a menudo sugerirá desarrollar un módulo de políticas con
el comando audit2allow. En la mayoría de los casos, esta no será la solución
preferida. Solo se deben desarrollar módulos de políticas personalizadas cuando el
impacto de dicho módulo se comprende perfectamente. En la mayoría de los casos,
se puede encontrar una solución más simple y segura.
Se puede usar sealert de dos maneras: al utilizar el UUID de una denegación en

los registros del sistema, por ejemplo, sealert -l fdfe9d90-557b-4ad0-a1a3-
a6d09e065523, o al hacer que analice todos los mensajes de denegación de un archivo, por
ejemplo, sealert -a /var/log/audit/audit.log.
En ambos casos, se producirá el mismo resultado y se escribirá en los registros del sistema
por setroubleshootd.
Problemas comunes de SELinux

Los problemas de SELinux se pueden clasificar a grandes rasgos en cuatro categorías:
Uso de ubicaciones no estándares para datos de servicio

La política targeted tiene una gran lista de contextos de archivos predeterminados
para los servicios que se envían con Red Hat Enterprise Linux, incluidas ubicaciones
secundarias para la mayoría de los datos. Por ejemplo, la ubicación predeterminada
para los datos del servidor web /var/www y las ubicaciones secundarias en /srv/*/www
tendrán los contextos SELinux correctos aplicados cuando se ejecuta restorecon.
Estas listas de asignaciones entre nombres de archivos y contextos estándares pueden

inspeccionarse, y modificarse, con el comando semanage fcontext.
Cuando se utiliza una ubicación no estándar, deberá dar aviso al sistema. Por ejemplo,
para usar /mysites/sitea/www como raíz de documento (document root) para un
servidor web, deberá seguir estos pasos:
1. Agregue la nueva ubicación a la lista de contextos de archivos estándares a través de

semanage.
[root@demo ~]# semanage fcontext -a -t httpd_sys_content_t '/mysites/sitea/

www(/.*)?'
2. Aplique nuevos contextos de archivos.
[root@demo ~]# restorecon -Rv /mysites/sitea/www
Cambiar del modo disabled (deshabilitado) al modo enforcing (obligatorio).

Cuando un sistema se ejecuta con SELinux, los contextos del archivo deshabilitado
en archivos creados recientemente no se establecerán en función de la política.
Esto también incluye archivos que están editados con la mayoría de los editores de
texto, herramientas como sed, e incluso NetworkManager, ya que la mayoría de las
herramientas no escriben archivos en su lugar, sino que crean un archivo temporal y,
luego, mueven ese archivo al original.
302 RH342-RHEL7.2-es-1-20160321
Problemas comunes de SELinux
Por lo general, se crea automáticamente un archivo denominado /.autorelabel

cuando cambia al modo deshabilitado, pero es posible que un administrador, o una
herramienta automatizada, haya eliminado ese archivo. Sin ese archivo presente, el
sistema no volverá a etiquetar automáticamente todos los sistemas de archivos cuando
vuelva al modo obligatorio, lo que hará que el archivo aparezca con el tipo unlabeled_t.
Aunque los procesos, como shell root, que se ejecutan como unconfined_t pueden
acceder a estos archivos, los servicios confinados no pueden hacerlo. Esto resultará en
denegaciones que pueden afectar incluso la capacidad de arranque de un sistema.
Para solucionar estas situaciones, cree un archivo (vacío) denominado /.autorelabel

y reinicie el sistema. Esto hará que el sistema vuelva a etiquetar el sistema de archivos
completo en el siguiente arranque y que se vuelva a reiniciar.
Booleanos configurados incorrectamente

Muchos de los servicios confinados de Red Hat Enterprise Linux 7 están limitados en lo
que pueden hacer, pero tienen conmutadores (booleanos) que les permiten tener más
acceso cuando una configuración lo necesita. Por ejemplo, los servicios httpd no tienen
permitido crear conexiones de red salientes de manera predeterminada, pero puede
habilitarlo al configurar uno o más booleanos.
En el caso de httpd, hay booleanos específicos para casos de uso como conectarse a
varias bases de datos, memcached, servidores FTP, LDAP, y mucho más. También hay un
booleano para permitir todas las conexiones de red, por si un caso de uso específico no
está cubierto por uno de los otros booleanos.
Puede consultar una lista de booleanos, junto con el estado actual, el estado
predeterminado y la descripción, con el comando semanage boolean --list. Puede
consultar booleanos individuales y configurarlos con los comandos getsebool y
setsebool respectivamente.
Importante
A menos que se utilice el indicador -P cuando ejecuta setsebool, los valores
booleanos solo se actualizarán en la memoria, no sistemáticamente.
Uso de puertos de red no estándares para servicios

Por defecto, la política targeted solo permite que los servicios confinados se escuchen
en un conjunto predefinido de puertos de red. Por ejemplo, el daemon httpd solo tiene
permitido unirse a puertos etiquetados como http_port_t y http_cache_port_t.
Para etiquetar un puerto (sin etiqueta) con una nueva etiqueta, se puede usar el
comando semanage.
[root@demo ~]# semanage port -a -t http_port_t -p tcp 8001
Si se debe utilizar un puerto que ya está etiquetado con un tipo incompatible, por
ejemplo, hacer que sshd se escuche en un puerto 443/tcp, se deberá escribir un nuevo
módulo de políticas para permitir esta unión. Por lo general, no es recomendable.
RH342-RHEL7.2-es-1-20160321 303
Comprensión de las reglas de SELinux

La política targeted de SELinux que se utiliza en Red Hat Enterprise Linux 7 define muchos
tipos, reglas y booleanos. Para comprender mejor qué tipos y reglas se utilizan, y qué reglas
están habilitadas por booleanos, se puede instalar el paquete setools-console.
Este paquete proporciona varios ejecutables para ayudar en la solución de problemas de

SELinux, dos de los cuales se debaten aquí: seinfo y sesearch.
Se pueden usar los comandos seinfo -t y seinfo -b para enumerar todos los tipos y
booleanos, respectivamente. Cuando la opción -t recibe el nombre de un tipo, mostrará ese
tipo y todos los alias configurados para ese tipo.
[root@demo ~]# seinfo -thttpd_sys_content_t

httpd_sys_content_t
Aliases
httpd_fastcgi_content_t
httpd_httpd_sys_script_ro_t
httpd_fastcgi_script_ro_t
También se puede usar el comando seinfo para determinar los tipos de puerto asociados
con un puerto de red específico:
[root@demo ~]# seinfo --portcon=443 --protocol=tcp

portcon tcp 443 system_u:object_r:http_port_t:s0
portcon tcp 1-511 system_u:object_r:reserved_port_t:s0
Se puede usar el comando sesearch para buscar dentro de las reglas definidas en la política.
Esto resulta útil para ver las reglas que un determinado booleano habilita. Por ejemplo, para
ver todas las reglas allow habilitadas por el booleano httpd_can_connect_ldap, se puede
usar el siguiente comando:
[root@demo ~]# sesearch --allow -b httpd_can_connect_ldap

Found 1 semantic av rules:
allow httpd_t ldap_port_t : tcp_socket name_connect ;
Esta regla permite que los procesos del tipo httpd_t se conecten a sockets del tipo
ldap_port_t.
Referencias
Para obtener más información, consulte la Guía para usuarios y administradores de
SELinux disponible en https://access.redhat.com/docs.
Páginas del manual semanage(8), sesearch(1), getsebool(8), setsebool(8),

sealert(8), setroubleshootd(8), seinfo(1) y sesearch(1).
304 RH342-RHEL7.2-es-1-20160321
Ejercicio guiado: Resolución de problemas de SELinux

SELinux
En este trabajo de laboratorio, resolverá un problema de permisos para un sitio web.
Recursos
Resultados
Deberá poder resolver problemas de permiso de SELinux.
Andes de comenzar
Desde su sistema workstation, ejecute el comando lab selinuxts setup. De esta
manera, se establecerá este ejercicio en servera. Como parte del proceso de configuración,
su sistema servera se reiniciará dos veces.
[student@workstation ~]$ lab selinuxts setup
Uno de sus colegas realizó tareas de solución de problemas y mantenimiento de emergencia

en su sistema servera. Aunque se resolvió el problema original, el archivo /var/log/
audit/audit.log en servera ahora está aumentando rápidamente; esto se detectó
debido a que el daemon chronyd ahora tiene fallas en el inicio.
En contra de las políticas de su empresa, su colega no registró ninguno de los pasos llevados
a cabo. Cuando le preguntó, su colega no pudo recordar exactamente qué pasos realizó en el
sistema.
Investigue y solucione este problema.
1. Inspeccione los mensajes de SELinux que se registraron hoy. ¿Hay algún patrón?
1.1. Inspeccione los mensajes de SELinux que se registraron hoy.
[root@servera ~]# ausearch -m avc -ts today | less
1.2. ¿Hay algún patrón?
Hay muchas denegaciones para /etc/resolv.conf, junto con otras denegaciones

diversas. Todas estas denegaciones incluyen un tipo de contexto de destino de
unlabeled_t.
2. ¿Qué pudo haber generado tantos archivos sin etiquetas? ¿Cuáles son las posibles
soluciones? Implemente la solución más integral.
2.1. ¿Qué pudo haber generado tantos archivos sin etiquetas?
Los archivos sin etiquetas se crean cuando el sistema se ejecuta con SELinux
deshabilitado. Esto puede suceder cuando se recupera el sistema con el modo de
recuperación anaconda, o cuando un administrador ejecuta (temporalmente) un
RH342-RHEL7.2-es-1-20160321 305
sistema con SELinux deshabilitado. En ambos casos, se deberá haber eliminado

el archivo /.autorelabel creado automáticamente, ya que la presencia de este
archivo haría que se vuelva a etiquetar automáticamente el sistema completo la
próxima vez que se inicie con SELinux en modo obligatorio o permisivo.
2.2. ¿Cuáles son las posibles soluciones?
El sistema se puede recuperar a través de restorecon -Rv / o al crear un archivo

(vacío) /.autorelabel y reiniciar el sistema.
El segundo método es más integral y garantiza que se reinicie cualquier servicio que
pudo haber generado los problemas debido a archivos sin etiquetas.
2.3. Implemente la solución más integral.
[root@servera ~]# touch /.autorelabel

3. Evalúe su trabajo ejecutando el comando lab selinuxts grade en su sistema

workstation.
[student@workstation ~]$ lab selinuxts grade
4. Importante: Si no completó este ejercicio con éxito, pero desea continuar, limpie sus
sistemas al restablecer su sistema servera o al ejecutar el comando lab selinuxts
reset en su sistema workstation.
[student@workstation ~]$ lab selinuxts reset
306 RH342-RHEL7.2-es-1-20160321
Gestión de problemas de autenticación
Gestión de problemas de autenticación
Objetivos
en la autorización y autenticación de usuarios.
¿Qué es PAM?
Red Hat Enterprise Linux 7 utiliza un conjuntos de librerías denominado Módulos de
autenticación conectables (Pluggable Authentication Modules) (PAM) para proporcionar servicios
de autenticación, autorización, gestión de sesiones y cambio de contraseña a aplicaciones y
servicios.
Las aplicaciones que utilizan PAM realizan una llamada de librería a PAM cuando necesitan
realizar una acción; a continuación, interactúan con el usuario en función de las devoluciones
de llamadas (por ejemplo, solicitar una contraseña) y, luego, recibe un sí o un no de las
librerías de PAM.
PAM proporciona estos servicios a través de un conjunto de librerías de extensión para

gestionar varios casos y subsistemas; por ejemplo, vincularse con cuentas locales del sistema,
o siempre decir que no, y un conjunto de archivos de configuración.
PAM puede proporcionar servicios para cuatro casos de uso distintos:
• account: Comprueba si existe un usuario y le otorga permiso para acceder a un

determinado servicio.
• auth: Autentica credenciales de usuarios. Esto puede ser tan simple como verificar una
contraseña, o tan complejo como requerir una autenticación de dos factores con un token
de hardware y una frase de contraseña, o incluso una verificación biométrica.
• password: Actualizar contraseñas, normalmente vinculadas profundamente a la sección

auth de un servicio.
• session: Administración de sesiones. Esto incluye configurar contextos SELinux, registros

de auditoría y mucho más.
Configuración de PAM
PAM puede configurarse independientemente por cada servicio que lo usa. Esto se lleva
a cabo en archivos que llevan el nombre del servicio en /etc/pam.d/. Por ejemplo, el
servicio vsftpd se configurará en el archivo /etc/pam.d/vsftpd. Si no se encuentra una
configuración adecuada, se utiliza el archivo /etc/pam.d/other, que bloquea todos los
accesos.
Los archivos de configuración constan de líneas que tienen el siguiente formato:
type control module-path [module-arguments]
Donde type es account, auth, password o session.
control puede especificarse en la sintaxis historical, que puede ser required,

requisite, sufficient, optional, include o substack, o en el formato moderno de
RH342-RHEL7.2-es-1-20160321 307
[value1=action1 value2=action2 ...]. Para la mayoría de los usos, aún se utiliza

la notación histórica anterior, a menos que se necesite mayor libertad de expresión de la
sintaxis más reciente.
module-path puede ser un nombre de ruta absoluto o una ruta relativa a /lib/security/
o /lib64/security/. Esto especifica qué módulo debería utilizarse para realizar esta
verificación.
module-arguments puede ser una lista de argumentos separados por espacios para el
módulo especificado. Algunos módulos requieren el uso de algunos argumentos, mientras
que otros no proporcionan argumentos.
Cuando se consulta un servicio por un tipo específico, se analizan todas las líneas que
coinciden con ese tipo en el orden en que se encuentran en el archivo de configuración.
Aunque se permite combinar los tipos de servicios a lo largo de un archivo de configuración,
se recomienda mantener cuatro bloques separados para estos tipos para facilitar el
mantenimiento.
Un archivo de configuración de ejemplo, para vsftpd:
#%PAM-1.0
auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers
onerr=succeed
auth required pam_shells.so
auth include password-auth
account include password-auth
session optional pam_keyinit.so force revoke

session required pam_loginuid.so
session include password-auth
Este archivo de configuración depende considerablemente de otro servicio: password-

auth, y omite un bloque de password por completo. Para la autenticación, se realiza una
verificación required sobre el módulo de pam_listfile.so. Si falla una verificación
requerida, significa que todo el bloque fallará, pero aún así se ejecutará para prevenir
ataques de sincronización. En este caso, el módulo pam_listfile.so fallará para todos
los usuarios enumerados en el archivo /etc/vsftpd/ftpusers, y no fallará para todos
los demás. El módulo pam_shells.so fallará para todos los usuarios cuya shell de inicio
de sesión no está enumerada en /etc/shells, y no fallará para los usuarios cuya shell sí
aparece en el archivo.
Este servicio password-auth incluido se define en su propio archivo, /etc/pam.d/

password-auth. Este archivo, a su vez, es un enlace simbólico al archivo /etc/pam.d/
password-auth-ac, que es un archivo escrito por la familia de herramientas authconfig.
Se realiza una configuración similar para los archivos system-auth y system-auth-ac.
Esto permite que un administrador desvincule la autenticación de la autenticación de todo
el sistema, en caso de ser necesario, o realice cambios manuales en una configuración sin
temer que una herramienta automatizada la sobrescriba más adelante, simplemente al
romper el enlace simbólico.
308 RH342-RHEL7.2-es-1-20160321
Solución de problemas de PAM
Advertencia
En la mayoría de los casos, PAM no debe configurarse manualmente, sino mediante
la familia de herramientas authconfig.
Solución de problemas de PAM

Algunos de los errores más comunes en la configuración y el funcionamiento de PAM derivan
de los archivos de configuración manual. Puede detectar esos errores al examinar los
archivos de registro para el servicio que utiliza PAM, o al observar /var/log/secure. En
journalctl, los mensajes de PAM se registran como parte del diario (journal) de servicio,
mientras que para syslog, los mensajes de PAM se envían a /var/log/secure.
Errores comunes incluyen utilizar el tipo de control incorrecto, por ejemplo, requisite en
lugar de optional; orden incorrecto de reglas, por ejemplo, enumerar pam_deny.so antes
de cualquier otro elemento; e intentos de utilizar módulos que no admiten el tipo actual, por
ejemplo, intentar utilizar pam_pwhistory.so dentro del bloque auth.
Los módulos individuales de PAM pueden proporcionar su documentación que, entre otra
información, indica los tipos que admite en las páginas del manual y como archivos en /
usr/share/doc/pam-*/txts/. Esta documentación también puede incluir explicaciones de
mensajes de error y explicaciones sobre cómo habilitar una depuración más detallada para
módulos individuales.
Restauración de configuraciones authconfig

Cuando se configura la autenticación a través de cualquiera de las herramientas de la
familia authconfig (authconfig, authconfig-tui, authconfig-gtk), todos los ajustes
aplicados se almacenan en el archivo /etc/sysconfig/authconfig. Este archivo consta de
vinculaciones name=value para todos los ajustes que pueden realizarse con authconfig.
Para restaurar los ajustes authconfig anteriores después de que se realizaron cambios
manuales (no deseados), se puede usar el comando authconfig --updateall. Esto
aplicará la configuración almacenada en /etc/sysconfig/authconfig en el sistema, lo
que sobrescribirá cualquier cambio manual.
Referencias
El capítulo sobre el uso de módulos de autenticación conectables de la Guía de
autenticación de nivel del sistema disponible en https://access.redhat.com/
docs.
Páginas del manual pam(8), pam.conf(5) y authconfig(8).
RH342-RHEL7.2-es-1-20160321 309
Ejercicio guiado: Gestión de problemas de

autenticación
En este trabajo de laboratorio, diagnosticará y resolverá un problema relacionado con la

autenticación.
Recursos
• serverb
Resultados
Deberá poder resolver problemas relacionados con la autenticación.
Andes de comenzar
En su sistema workstation, ejecute el comando lab auth setup; esto preparará sus
sistemas workstation y serverb para este ejercicio.
[student@workstation ~]$ lab auth setup
Aunque sabe que no es seguro, su empresa proporciona acceso de FTP autenticado a

directorios de inicio en serverb.
Después de leer bastante en varios foros de Internet, uno de sus colegas decide intentar
aumentar la seguridad de serverb. El intento falló, así como también el intento de su
colega de limpiar el sistema posteriormente. Se le ha pedido que restaure el acceso de FTP
autenticado a directorios de inicio en serverb. Para probar, se le otorgó una cuenta de
usuario denominada ftpuser con la contraseña redhat.
1. Comience por intentar utilizar FTP autenticado como ftpuser.
1.1. Desde su sistema workstation, use lftp para iniciar sesión en la cuenta ftpuser
en serverb. Recuerde que lftp solo intenta iniciar sesión después de que se envía
el primer comando.
[student@workstation ~]$ lftp ftpuser@serverb.lab.example.com

Password: redhat
lftp ftpuser@serverb.lab.example.com:~> ls
ls: Login failed: 530 Login incorrect.
2. Recopile más información sobre el problema; en este caso, el diario (journal) del sistema
en serverb puede brindar información útil.
2.1. Vea los registros para vsftpd en serverb.
[root@serverb ~]# journalctl -u vsftpd.service

....
Fev 17 13:06:57 serverb.lab.example.com vsftpd[1640]: PAM unable to resolve
symbol pam_sm_acct_mgmt
Este mensaje parece indicar un problema con la configuración de PAM para vsftpd.
310 RH342-RHEL7.2-es-1-20160321
2.2. Use rpm para ver si los archivos que pertenecen al paquete vsftpd han cambiado
desde la instalación.
[root@serverb ~]# rpm -V vsftpd

S.5....T. c /etc/pam.d/vsftpd
Este resultado parece indicar que la configuración de PAM para vsftpd ha cambiado.
3. Restaure la configuración de PAM para vsftpd, asegurándose de realizar una copia de

seguridad del archivo actual dañado.
3.1. Quite el archivo dañado actual.
[root@serverb ~]# mv /etc/pam.d/vsftpd{,.broken}
3.2. Reinstale el paquete vsftpd.
[root@serverb ~]# yum reinstall vsftpd
nota
La razón por la que movemos, y no copiamos, el archivo dañado en el paso
anterior es que yum, por defecto, no sobrescribe archivos de configuración
al reinstalarse, por lo que el archivo dañado habría permanecido en el
sistema si lo hubiésemos copiado.
4. Compruebe si se restauró el acceso de FTP autenticado y, luego, realice un análisis sobre

por qué el archivo de configuración de PAM modificado no funcionó.
4.1. Pruebe si el acceso de FTP autenticado ahora funciona.
[student@workstation ~]$ lftp ftpuser@serverb.lab.example.com

Password: redhat
lftp ftpuser@serverb.lab.example.com:~> ls
-rw-r--r-- 1 0 0 12 Feb 17 12:05 README.txt
4.2. Compare /etc/pam.d/vsftpd con /etc/pam.d/vsftpd.broken; ¿cuáles son las

diferencias?
[root@serverb ~]# diff -u /etc/pam.d/vsftpd{,.broken}

...
+account required pam_ftp.so
...
Parece ser que el archivo dañado tenía un requisito adicional en las verificaciones de
la cuenta a través del módulo pam_ftp.so.
4.3. Lea la documentación de pam_ftp para descubrir qué se supone que debe hacer y
por qué falló en este caso.
RH342-RHEL7.2-es-1-20160321 311
[root@serverb ~]# man pam_ftp
Según la página del manual, el módulo pam_ftp.so se utiliza para proporcionar

asignaciones anónimas similares a FTP de nombres de usuarios a una cuenta
anónima, pero solo se puede usar dentro de un bloque auth, no en un bloque
account.
5. Evalúe su trabajo ejecutando el comando lab auth grade de su máquina

workstation.
[student@workstation ~]$ lab auth grade
6. Limpie sus máquinas al ejecutar el comando lab auth reset desde su máquina
workstation, o reinicie sus máquinas workstation y serverb.
[student@workstation ~]$ lab auth reset
312 RH342-RHEL7.2-es-1-20160321
Resolución de problemas de Kerberos y LDAP
Resolución de problemas de Kerberos y LDAP
Objetivos
Después de completar esta sección, los estudiantes podrán identificar y corregir problemas
relacionados con la administración de identidades de LDAP y Kerberos.
¿Qué es LDAP?
Protocolo Ligero de Acceso a Directorios (LDAP, Lightweight Directory Access Protocol) es un
protocolo para acceder, consultar y actualizar servicios de directorio. Se desarrolló en función
de la necesidad de simplificar el protocolo X.509 y los servicios relacionados.
LDAP organiza objetos, como cuentas de usuario, y sus atributos relacionados, como
contraseñas, nombres completos, etc., en un árbol. Los atributos que pueden utilizarse en un
objeto dependen de las clases de objeto asociadas con ese objeto. En un directorio normal,
todos los objetos que representan el mismo elemento, como un usuario o una computadora,
tendrán las mismas clases de objeto y los mismos atributos asociados.
LDAP es una parte fundamental de varias soluciones de administración de identidades, como

Red Hat Identity Management, Red Hat Directory Server, Microsoft Active Directory y muchas
más.
Hay varios conjuntos de herramientas para trabajar con servidores de LDAP desde la
línea de comandos. Uno de los más populares es el conjunto de herramientas OpenLDAP
proporcionado en el paquete openldap-clients.
El siguiente comando busca los servidores de LDAP configurados en /etc/openldap/

ldap.conf utilizando autenticación simple (-x), aplicando cifrado TLS (-ZZ) para todos los
objetos de la base de búsqueda definidos en /etc/openldap/ldap.conf que tienen un
atributo uid que coincide exactamente con ldapuser, y muestra solo los atributos cn y
homeDirectory. La opción -LL deshabilita comentarios extraños en el resultado.
[user@demo ~]$ ldapsearch -x -ZZ -LL '(uid=ldapuser)' cn homeDirectory

version: 1
dn:uid=ldapuser,ou=People,dc=lab,dc=example,dc=com
cn: LDAP Test User
homeDirectory: /home/guests/ldapuser
¿Qué es Kerberos?
Kerberos es un método de proporcionar servicios de autenticación y servicio Single Sign-On
(SSO) a usuarios y servicios. Kerberos supone que las máquinas individuales de la red son de
confianza, pero que la propia red es insegura, por lo que nunca se transmitirán contraseñas a
través de la red.
Una transacción típica de Kerberos involucrará tres partes (de ahí viene el nombre en honor
al perro de tres cabezas que protege la entrada a Hades):
• El Centro de distribución de claves de Kerberos (KDC, Key Distribution Center). Este es el

servidor que conoce todas las contraseñas para todos los usuarios y servicios. Los usuarios
y servicios están identificados por una entidad, un nombre y una contraseña.
RH342-RHEL7.2-es-1-20160321 313
• El usuario que desea autenticarse. Este usuario debería conocer su contraseña.
• El servicio con el que el usuario desea autenticarse. Dado que los servicios no pueden
escribir sus propias contraseñas de manera interactiva, la contraseña del servicio se
almacenará en un archivo denominado keytab.
Autenticación inicial
Cuando un usuario inicia sesión por primera vez en una sesión a través de Kerberos, deberá
obtener un Ticket de obtención de tickets (TGT, Ticket Granting Ticket). Este TGT permitirá que el
usuario obtenga tickets para otros servicios sin tener que escribir su contraseña nuevamente
durante el tiempo que el TGT sea válido (por lo general, algunas horas). Este ticket se puede
obtener automáticamente cuando inicia sesión de manera interactiva en una máquina que
usa Kerberos, o desde la línea de comandos a través de la herramienta kinit.
A continuación se indican los pasos para obtener un TGT:
1. El sistema al que el usuario está ingresando envía una solicitud para un TGT del usuario
al KDC.
2. El KDC responde con un nuevo TGT, cifrado con la contraseña del usuario.
3. Si el TGT se puede descifrar, el inicio de sesión es correcto y se almacena el TGT.
Autenticación con un ticket

Una vez que se obtiene un TGT, un usuario puede conectarse a otros servicios habilitados
por Kerberos sin tener que escribir una contraseña. A continuación se indican los pasos para
realizar una autenticación:
1. El cliente envía una solicitud a KDC de un ticket de servicio para la entidad del servicio al
que desea autenticarse.
2. El KDC responde con dos copias del mismo ticket de servicio: uno cifrado con el TGT del
usuario, el otro cifrado con la contraseña para el servicio.
3. El cliente descifra la versión cifrada con el TGT y utiliza el ticket descifrado para cifrar una
marca de tiempo.
4. El cliente envía la marca de tiempo cifrada, y el ticket cifrado con la contraseña de

servicio, al servicio.
5. El servicio descifra el ticket de servicio y lo utiliza para descifrar la marca de tiempo. Si

eso sucede, y la marca de tiempo se creó hace menos de dos minutos, el usuario está
autenticado.
Una nota sobre las entidades

En su forma más básica, el nombre de una entidad tiene un formato similar a
username@REALM; por ejemplo, vimes@EXAMPLE.COM. Por lo general, el nombre de usuario
coincidirá con el de un usuario definido en LDAP, o incluso localmente en un sistema,
mientras que el dominio está fijo en toda una organización.
Las entidades de computadora y servicio tienen una forma diferente: service/

hostname@REALM, por ejemplo: host/demo.example.com@EXAMPLE.COM, nfs/
demo.example.com@EXAMPLE.COM o http/www.example.com@EXAMPLE.COM. El nombre
del servicio está determinado por el tipo de servicio; los servicios de autenticación, como SSH,
314 RH342-RHEL7.2-es-1-20160321
Solución de problemas de LDAP
telnet, etc., utilizan host/, los servicios NFS utilizan nfs/, y los servicios web utilizan http/.
Otros servicios pueden utilizar, y utilizarán, diferentes prefijos.
Solución de problemas de LDAP

Los problemas de LDAP pueden caer en diversas categorías diferentes.
Conectividad de red
LDAP funciona en el puerto TCP 389 para texto sin formato y conexiones cifradas por
TLS. Las versiones anteriores del protocolo también admiten el puerto TCP 636 para las
conexiones cifradas por SSL. Si un firewall está bloqueando el acceso a estos puertos, o
si un cliente con versión anterior intenta conectarse al puerto 636/TCP mientras que el
servidor solo admite la versión STARTTLS moderna en el puerto 389/TCP, se generarán
problemas de conexión.
Ajustes de seguridad dispares

Los servidores LDAP pueden aplicar requisitos sobre las maneras en que los clientes
se conectan y se autentican. Algunos servidores pueden negarse a hablar con clientes
que no están utilizando una forma de cifrado TLS, y otros pueden requerir una forma de
autenticación, ya sea simple o SASL, antes de responder consultas. Las combinaciones
de estos requisitos también pueden establecerse en acciones individuales; por ejemplo,
un servidor puede permitir solo conexiones cifradas por TLS para las consultas, pero
también requerir autenticación para las actualizaciones.
Disparidades de certificado de TLS

Cuando se utiliza TLS para cifrar conexiones, los clientes necesitan una manera de
verificar el certificado utilizado por el servidor. Lo hace al verificar si un certificado
de CA de confianza ha firmado el certificado del servidor. Si estos certificados de CA
no se descargan en /etc/openldap/cacerts, y no se aplica hash al directorio con
cacertdir_rehash, los clientes no confiarán en el servidor y, por lo tanto, se negarán a
comunicarse con él.
Base de búsqueda incorrecta

Por lo general, los clientes no solicitan búsquedas en el árbol LDAP entero, sino en
la parte de ese árbol que almacena la información que se necesita en ese momento.
Por ejemplo, un programa de inicio de sesión debería consultar la parte del árbol que
contiene las cuentas del usuario, y no la parte con las cuentas de la computadora. Si la
base de búsqueda está configurada de manera incorrecta, es posible que las búsquedas
sean lentas o no devuelvan la información que necesita.
Los administradores pueden verificar estos ajustes al utilizar el comando ldapsearch. Para
resolver problemas relacionados con la información del usuario, también puede usar el
comando getent passwd.
nota
Cuando se utiliza sssd para la autenticación e información del usuario, el comando
getent passwd no enumerará a todos los usuarios disponibles, sino que solo
enumerará a los usuarios locales. Para realizar pruebas, se puede agregar el
nombre de una cuenta de red conocida para probar si los usuarios de la red
también se resuelven correctamente; por ejemplo: getent passwd ldapuser.
RH342-RHEL7.2-es-1-20160321 315
Solución de problemas de Kerberos

Los problemas de Kerberos pueden aparecer de dos maneras: los usuarios no pueden
obtener un TGT (y, por lo tanto, no pueden iniciar sesión), y los usuarios o servicios no
pueden autenticarse con servicios.
Para resolver problemas de inicio de sesión, un administrador puede verificar algunos

puntos:
• ¿Las horas entre todas las partes están sincronizadas? Una diferencia de más de dos
minutos provocará una falla en Kerberos.
• ¿Un kinit username para ese usuario funciona desde la misma máquina? Si eso no
funciona, hay un problema con la configuración de PAM para la autenticación que, por
lo general, puede solucionarse con la familia de herramientas authconfig. Si eso no
funciona, puede haber un problema con el KDC o con los archivos de configuración de
Kerberos en la máquina.
• ¿El ajuste default_realm y las diversas asignaciones de nombre de host a máquina en la

sección domain_realm de /etc/krb5.conf coinciden con la realidad?
• ¿Los registros de DNS SRV para Kerberos (si se utilizan) son correctos?
• Si se utiliza sssd, ¿los ajustes de krb5_realm y krb5_server en /etc/sssd/sssd.conf

coinciden con la realidad?
• /var/log/secure y journalctl tendrán mensajes con respecto a inicios de sesión

fallidos; ¿señalan una causa probable?
Cuando los usuarios pueden iniciar sesión, pero no pueden autenticarse a determinados
servicios, o la autenticación de servicio a servicio como NFSv4 falla, deberá verificar algunos
elementos adicionales.
• ¿Los servicios pueden leer su keytab? (/etc/krb5.keytab para servicios como SSH y NFS,
varios otros archivos para otros servicios).
• ¿Keytab está usando la versión más reciente de la contraseña? Las Keytabs se pueden
inspeccionar con el comando klist -ek <FILENAME>. La columna KVNO muestra la
versión de la contraseña almacenada. Cuando se agrega una entidad a una keytab, se
genera una contraseña nueva y aleatoria de manera automática.
Los usuarios con acceso a la herramienta de administración KDC de Kerberos kadmin (o

kadmin.local para root en el KDC) pueden usar el comando getprinc <PRINCIPAL>
desde kadmin para ver la versión de la contraseña conocida por el KDC.
• ¿Están las entidades correctas presentes en la keytab?
• ¿Los servicios están de acuerdo en la manera en que se debería utilizar Kerberos? Por
ejemplo, una exportación de NFS que especifica sec=krb5p solo se puede montar cuando
el cliente también especifica el mismo nivel de seguridad.
• ¿Están todos los servicios de ayuda necesarios en ejecución? Por ejemplo, un servidor de
NFS necesita un servicio nfs-secure-server.service, y un cliente de NFS necesita el
servicio nfs-secure.service cuando utiliza NFSv4 habilitada por Kerberos.
316 RH342-RHEL7.2-es-1-20160321
Solución de problemas de Kerberos
Referencias
Para obtener más información, consulte la Guía de políticas, autenticación e
identidad de dominios de Linux, y la Guía de autenticación de nivel del sistema en
https://access.redhat.com/docs.
Páginas del manual krb5.conf(5), sssd.conf(5) y kadmin(1).
RH342-RHEL7.2-es-1-20160321 317

Kerberos y LDAP
En este trabajo de laboratorio, resolverá un problema relacionado con la información del

usuario de LDAP o la autenticación de Kerberos.
Recursos
• servera
Resultados
Deberá poder diagnosticar y resolver problemas relacionados con la autenticación y la
información del usuario de Kerberos y LDAP.
Andes de comenzar
En su sistema workstation, ejecute el comando lab krb5ldap setup. Esto preparará sus
sistemas workstation y servera para este ejercicio.
[student@workstation ~#$ lab krb5ldap setup
Su sistema workstation está configurado para actuar como un servidor de LDAP para
brindar información del usuario (solo STARTTLS), y como un KDC de Kerberos para la
autenticación del usuario. Su sistema servera está configurado para actuar como un cliente
para ambos servicios.
Su sistema workstation también está configurado para actuar como un servidor de NFS
habilitado por Kerberos, y servir a los directorios de inicio de los usuarios configurados en
LDAP y Kerberos.
Después de una ventana de mantenimiento reciente, en la que se actualizaron keytabs de

Kerberos en todas las máquinas de su dominio, y se cambiaron todos los clientes a autofs en
lugar de montajes estáticos, el usuario ldapuser informa que su directorio de inicio ya no
está montado automáticamente cuando inicia sesión en servera. Los directorios de inicio de
servera para los usuarios de LDAP están montados automáticamente a través de autofs.
La contraseña de ldapuser es kerberos. A efectos de solución de problemas, su

administrador de seguridad ha desarrollado keytabs para todos sus sistemas disponibles por
FTP en ftp://workstation.lab.example.com/pub/. El certificado de CA para autenticar
las conexiones de LDAP también está disponible aquí, como example-ca.crt.
318 RH342-RHEL7.2-es-1-20160321
nota
Por defecto, ssh en sus sistemas está configurado para permitir automáticamente
cualquier inicio de sesión de la cuenta student en workstation a
cualquier cuenta en servera. Para iniciar sesión con una contraseña,
para obtener un ticket de Kerberos, se puede usar el comando ssh -o
PreferredAuthentications=keyboard-interactive,password USER@HOST.
Un contenedor que ejecuta este comando se instala en su sistema workstation
como passhwd.
1. Comience por recrear el problema y recopilar información.
1.1. Como student en workstation, use ssh para iniciar sesión en la cuenta ldapuser
en servera a través de la autenticación de contraseña para obtener un Ticket de
obtención de tickets (TGT) de Kerberos.
[student@workstation ~]$ ssh -o PreferredAuthentications=keyboard-

interactive,password ldapuser@servera
ldapuser@servera's password: kerberos
Last login: Wed Feb 17 09:40:55 2016 from workstation.lab.example.com
Could not chdir to home directory /home/guests/ldapuser: No such file or
directory
1.2. Compruebe que recibió un TGT como ldapuser.
-bash-4.2$ klist
Ticker cache: KEYRING:persistent:1701:krb_cache_sRRVnEH
Default principal: ldapuser@LAB.EXAMPLE.COM
Valid starting Expires Service principal

02/16/2016 16:37:03 02/17/2016 16:37:03 krbtgt/LAB.EXAMPLE.COM@LAB.EXAMPLE.COM
2. El paso anterior indicó que LDAP y Kerberos están funcionando con normalidad, por
lo que es posible que el problema esté en la configuración de NFS. Inspeccione la
exportación del servidor en workstation y la configuración cliente en servera en
busca de irregularidades.
2.1. Inspeccione la exportación en workstation.
[root@workstation ~]# cat /etc/exports /etc/exports.d/*

/home/guests *.lab.example.com(sec=krb5p,rw)
2.2. Verifique que el servicio nfs-server esté ejecutándose en workstation.
[root@workstation ~]# systemctl is-active nfs-server

active
2.3. Verifique que autofs esté ejecutándose en servera.
[root@servera ~]# systemctl status autofs
RH342-RHEL7.2-es-1-20160321 319
2.4. Consulte la configuración para autofs relacionada al directorio de inicio para

ldapuser.
[root@servera ~]# cat /etc/auto.master.d/guests.autofs

/home/guests /etc/auto.guests
[root@servera ~]# cat /etc/auto.guests

* -rw,sec=krb5p workstation.lab.example.com:/home/guests/&
3. El servidor de NFS y autofs parecen estar configurados correctamente, por lo que

es posible que el problema esté en la configuración de la seguridad. La exportación
especifica sec=krb5p, lo que significa que el servidor y el cliente necesitan entradas
de keytab host/ o nfs/. El servidor también debe ejecutar el servicio nfs-secure-
server, y el cliente debe ejecutar el servicio nfs-secure, para intercambiar información
clave.
3.1. Verifique el estado del servicio nfs-secure en servera.
[root@servera ~]# systemctl status nfs-secure

...
Feb 17 10:18:32 servera.lab.example.com rpc.gssd[1596]: ERROR: No credentials
found for connection to server workstation.lab.example.com
...
Este mensaje parece indicar un problema con la keytab.
3.2. Verifique el contenido del archivo /etc/krb5.keytab en servera.
[root@servera ~]# klist -ek /etc/krb5.keytab

KVNO Principal
---- ----------------------------------------------------------------
2 host/servera.lab.example.com@LAB.EXAMPLE.COM (aes-256-cts-hmac-sha1-96)
....
2 nfs/servera.lab.example.com@LAB.EXAMPLE.COM (aes-256-cts-hmac-sha1-96)
....
3.3. Inspeccione el contenido de la keytab más reciente que recibió de su administrador

de seguridad.
[root@servera ~]# wget ftp://workstation.lab.example.com/pub/servera.keytab

[root@servera ~]# klist -ek servera.keytab
KVNO Principal
---- ----------------------------------------------------------------
3 host/servera.lab.example.com@LAB.EXAMPLE.COM (aes-256-cts-hmac-sha1-96)
....
3 nfs/servera.lab.example.com@LAB.EXAMPLE.COM (aes-256-cts-hmac-sha1-96)
...
Parece que servera no está usando la keytab más reciente, lo que podría explicar el
mensaje de registro No credentials (Sin credenciales) que vimos antes.
4. Actualice /etc/krb5.keytab en servera; luego, reinicie los servicios autofs y nfs-

secure e inténtelo nuevamente.
320 RH342-RHEL7.2-es-1-20160321
4.1. Actualice la keytab /etc/krb5.keytab en servera.
[root@servera ~]# cp servera.keytab /etc/krb5.keytab
4.2. Reinicie los servicios nfs-secure y autofs en servera.
[root@servera ~]# systemctl restart nfs-secure autofs
4.3. Inténtelo nuevamente.
[student@workstation ~]$ ssh -o PreferredAuthentications=keyboard-

interactive,password ldapuser@servera
ldapuser@servera's password: kerberos
Last login: Wed Feb 17 10:18:55 2016 from workstation.lab.example.com
ldapuser@servera ~]$
5. Evalúe su trabajo ejecutando el comando lab krb5ldap grade de su máquina

workstation.
[student@workstation ~]$ lab krb5ldap grade
6. Importante: Limpie su trabajo al reiniciar sus sistemas workstation y servera.
RH342-RHEL7.2-es-1-20160321 321
Trabajo de laboratorio: Tratamiento de

problemas de seguridad
En este trabajo de laboratorio, resolverá problemas relacionados con uno o más subsistemas
de seguridad.
Recursos
• servera
Resultados
Deberá poder diagnosticar y solucionar problemas relacionados con subsistemas de
seguridad.
Andes de comenzar
En su sistema workstation, ejecute el comando lab security setup; esto preparará sus
[student@workstation ~#$ lab security setup
Se agregó un nuevo sistema recientemente a nuestra flota de servidores: servera.

Desafortunadamente, este sistema se configuró manualmente y no a través de un sistema
de administración de configuraciones y, como resultado, se deben realizar tareas finales de
Los dos principales problemas son los siguientes:
• Los usuarios que dependen de LDAP + Kerberos para autenticación e información

del usuario no pueden iniciar sesión. Por lo general, estos usuarios dependen del
servidor de LDAP en workstation para la información del usuario (en el árbol
dc=lab,dc=example,dc=com), y en el KDC de Kerberos que proporciona servicios para
el dominio LAB.EXAMPLE.COM que se ejecuta en workstation para sus necesidades de
autenticación e inicio de sesión único. Estos usuarios también tienen sus directorios de
inicio montados automáticamente desde workstation a través de NFSv4.
Ha recibido una cuenta de prueba denominada ldapuser con la contraseña kerberos.
• La parte de NFSv4 workstation.lab.example.com:/exports/importantfiles debe

estar montada automáticamente en /mnt/importantfiles, pero no lo está.
322 RH342-RHEL7.2-es-1-20160321
nota
Las máquinas de su aula están configuradas para que la cuenta student en
workstation pueda utilizar ssh en cualquier cuenta de servera sin una
contraseña. A efectos de prueba, necesitará iniciar sesión con la autenticación
de contraseña para probar la configuración de Kerberos. Para ello, puede
usar el comando ssh -o PreferredAuthentications=keyboard-
interactive,password. Para su comodidad, se delimitó este comando en un
script de utilidad denominado passhwd.
1. Aborde la autenticación primero. Recree el problema, recopile información, formule una

hipótesis y, luego, realice pruebas y solucione el problema.
2. Investigue el problema del montaje para /mnt/importantfiles, recopile información,

formule una hipótesis y, luego, solucione el problema.
3. Evalúe su trabajo ejecutando el comando lab security grade en su sistema

workstation.
[student@workstation ~]$ lab security grade
ejercicios.
RH342-RHEL7.2-es-1-20160321 323
Solución
En este trabajo de laboratorio, resolverá problemas relacionados con uno o más subsistemas
de seguridad.
Recursos
• servera
Resultados
Deberá poder diagnosticar y solucionar problemas relacionados con subsistemas de
seguridad.
Andes de comenzar
En su sistema workstation, ejecute el comando lab security setup; esto preparará sus
[student@workstation ~#$ lab security setup
Se agregó un nuevo sistema recientemente a nuestra flota de servidores: servera.

Desafortunadamente, este sistema se configuró manualmente y no a través de un sistema
de administración de configuraciones y, como resultado, se deben realizar tareas finales de
Los dos principales problemas son los siguientes:
• Los usuarios que dependen de LDAP + Kerberos para autenticación e información

del usuario no pueden iniciar sesión. Por lo general, estos usuarios dependen del
servidor de LDAP en workstation para la información del usuario (en el árbol
dc=lab,dc=example,dc=com), y en el KDC de Kerberos que proporciona servicios para
el dominio LAB.EXAMPLE.COM que se ejecuta en workstation para sus necesidades de
autenticación e inicio de sesión único. Estos usuarios también tienen sus directorios de
inicio montados automáticamente desde workstation a través de NFSv4.
Ha recibido una cuenta de prueba denominada ldapuser con la contraseña kerberos.
• La parte de NFSv4 workstation.lab.example.com:/exports/importantfiles debe

estar montada automáticamente en /mnt/importantfiles, pero no lo está.
nota
Las máquinas de su aula están configuradas para que la cuenta student en
workstation pueda utilizar ssh en cualquier cuenta de servera sin una
contraseña. A efectos de prueba, necesitará iniciar sesión con la autenticación
de contraseña para probar la configuración de Kerberos. Para ello, puede
usar el comando ssh -o PreferredAuthentications=keyboard-
interactive,password. Para su comodidad, se delimitó este comando en un
script de utilidad denominado passhwd.
1. Aborde la autenticación primero. Recree el problema, recopile información, formule una

hipótesis y, luego, realice pruebas y solucione el problema.
324 RH342-RHEL7.2-es-1-20160321
Solución
1.1. Recree el problema al intentar iniciar sesión en servera como el usuario ldapuser
con la contraseña kerberos.
[student@workstation ~]$ passhwd ldapuser@servera.lab.example.com

Warning: Permanently added 'servera.lab.example.com' (ECDSA) to the list of
known hosts.
ldapuser@servera.lab.example.com's password: kerberos
Permission denied, please try again.
1.2. Inspeccione los registros de sshd.service en servera para ver por qué el usuario
ldapuser no pudo iniciar sesión.
[root@servera ~]# journalctl -lu sshd.service

...
Feb 18 11:15:13 servera.lab.example.com sshd[1744]: Failed password for ldapuser
from 172.25.250.254 port 54303 ssh2
...
1.3. Verifique que la información del usuario esté disponible para el usuario ldapuser.
[root@servera ~]# getent passwd ldapuser

ldapuser:*:1701:1701:LDAP Test User:/home/guests/ldapuser:/bin/bash
1.4. Intente obtener un ticket de Kerberos para el usuario ldapuser.
[root@servera ~]# kinit ldapuser

kinit: Client 'ldapuser@LAB.EXMAPLE.COM' not found in Kerberos database while
getting initial credentials
Parece que se escribió el dominio de Kerberos con un error de tipeo mientras se

configuraba el sistema.
1.5. Corrija todos los casos de LAB.EXMAPLE.COM en /etc/krb5.conf y en /etc/

sssd/sssd.conf por LAB.EXAMPLE.COM; luego, reinicie el daemon sssd.
[root@servera ~]# sed -i 's/LAB.EXMAPLE.COM/LAB.EXAMPLE.COM/g' /etc/krb5.conf /

etc/sssd/sssd.conf
[root@servera ~]# systemctl restart sssd.service
1.6. Intente iniciar sesión nuevamente desde workstation a través de ssh.
[student@workstation ~]$ passhwd ldapuser@servera.lab.example.com

ldapuser@servera.lab.example.com's password: kerberos
Ahora funciona el inicio de sesión, y el directorio de inicio se monta

automáticamente.
2. Investigue el problema del montaje para /mnt/importantfiles, recopile información,

formule una hipótesis y, luego, solucione el problema.
2.1. Recree el problema al intentar montar /mnt/importantfiles en servera.
RH342-RHEL7.2-es-1-20160321 325
[root@servera ~]# mount /mnt/importantfiles

mount.nfs: access denied by server while mounting workstation.lab.example.com:/
exports/importantfiles
Este mensaje parece indicar que las opciones de exportación en workstation están
denegando el acceso.
2.2. Consulte las opciones de exportación en workstation para el sistema de archivos /

exports/importantfiles.
[root@workstation ~]# exportfs -sv

/home/guests *.lab.example.com(rw,wdelay,root_squash,no_subtree_check,sec=krb5p,
rw,secure,root_squash,no_all_squash)
/exports/importantfiles(rw,wdelay,root_squash,no_subtree_check,sec=krb5p,rw,secu
re,root_squash,no_all_squash)
2.3. Consulte las opciones de montaje definidas en /etc/fstab en servera para /mnt/
importantfiles.
[root@servera ~]# grep importantfiles /etc/fstab

workstation.lab.example.com:/exports/importantfiles /mnt/importantfiles nfs
sec=krb5i 0 0
2.4. ¿Las opciones de montaje que se encontraron en el paso anterior están alineadas
con las opciones de exportación encontradas? De no ser así, ¿cuál es el problema?
El cliente intenta montar el sistema de archivos con la verificación de integridad de

Kerberos, mientras que el servidor requiere un mínimo de verificación de integridad,
además de cifrado.
2.5. Cambie sec=krb5i por sec=krb5p en /etc/fstab para el montaje /mnt/

importantfiles; luego, intente realizar el montaje otra vez.
[root@servera ~]# sed -i /importantfiles/s/krb5i/krb5p/ /etc/fstab

[root@servera ~]# mount -a
3. Evalúe su trabajo ejecutando el comando lab security grade en su sistema

workstation.
[student@workstation ~]$ lab security grade
ejercicios.
326 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
• Las denegaciones de SELinux se registran en /var/log/audit/audit.log
• Instalar setroubleshoot-server concede acceso al comando sealert y a los mensajes de

solución de problemas automáticos en el registro del sistema.
• Se puede usar la herramienta semanage para actualizar asignaciones de contexto de

archivo y asignaciones de contexto del puerto de red.
• PAM se configura por servicio con archivos en /etc/pam.d.
• Los mensajes y errores de PAM se registran en el servicio que utiliza PAM.
• Se puede usar el comando ldapsearch para asistir en la solución de problemas de LDAP.
• Las librerías y los clientes de OpenLDAP esperan certificados de CA en /etc/openldap/

cacerts.
• Los clientes de Kerberos se configuran en /etc/krb5.conf, incluidas las asignaciones de

nombre de host a dominios.
• Las contraseñas de servicio se actualizan con una contraseña aleatoria nueva cada vez que
se agregan a una keytab.
• Se puede usar klist -ek para ver cuáles son las entidades de servicio, y las versiones,
que están en una keytab.
RH342-RHEL7.2-es-1-20160321 327
328
TRAINING
CAPÍTULO 10
KERNEL
Visión general
Meta Identificar problemas de kernel y ayudar al Soporte de
Red Hat a resolver problemas de kernel.
Objetivos • Crear volcados de memoria de kernel para ayudar al
Soporte de Red Hat a resolver problemas de kernel.
• Compilar y ejecutar módulos de SystemTap para ayudar

al Soporte de Red Hat a resolver problemas de kernel.
Secciones • Creación de volcados de memoria de kernel (y ejercicio
guiado)
• Depuración de kernel con SystemTap (y ejercicio guiado)

Trabajo de laboratorio • Solución de problemas de kernel
RH342-RHEL7.2-es-1-20160321 329
Capítulo 10. Solución de problemas de kernel
Volcados de error de kernel
Objetivos
Después de completar esta sección, los estudiantes podrán configurar sistemas para generar
volcados de error.
Volcados de error de kernel

Cuando una aplicación se interrumpe de manera anormal, se captura un volcado de la
imagen de la memoria del proceso en un archivo conocido como volcado de memoria (core
dump). Este archivo se envía al proveedor de la aplicación para que lo analice. Dado que el
archivo incluye el contenido del espacio de memoria de la aplicación en el momento de la
falla, puede proporcionar indicios con respecto a la causa de la interrupción anormal de la
aplicación.
De manera similar, cuando un sistema operativo experimenta un cuelgue o una caída del
sistema, también puede escribir el contenido de la imagen de la memoria del kernel en
un archivo conocido como volcado de error (crash dump). Dado que el volcado de error de
kernel incluye el contenido del espacio de la memoria del kernel en el momento de la falla
del sistema, su análisis puede proporcionar información acerca de su causa. Al configurar
sus sistemas para capturar volcados de error, los administradores pueden proporcionarle
a su proveedor de sistema operativo los elementos necesarios para determinar y resolver
correctamente la causa raíz de los cuelgues y las caídas del sistema.
kdump y kexec
Red Hat Enterprise Linux ofrece el software kdump para capturar los volcados de error
de kernel. El software kdump funciona al utilizar la herramienta kexec en un sistema en
ejecución para iniciar un kernel de Linux secundario sin tener que reiniciar el sistema.
kexec es un cargador de arranque de kernel a kernel que proporciona la funcionalidad de

iniciar el kernel secundario y omitir el BIOS. El kernel secundario, conocido como el kernel de
captura , se inicia desde un área de memoria reservada del kernel primario en ejecución para
proporcionar una plataforma para capturar contenido del espacio de memoria del kernel
principal en un archivo de volcado de error.
Otros mecanismos de error de kernel, como Linux Kernel Crash Dump (LKCD), realizan volcados
de error en el contexto de una falla y, por consiguiente, del kernel inestable. En cambio,
kdump captura volcados de error a través de un kernel recientemente iniciado. El uso de un
kernel de captura independiente hace que kdump sea un mecanismo de volcado de error
extremadamente confiable.
Configuración de kdump
El software kdump se instala por defecto en Red Hat Enterprise Linux 7 a través de la
instalación del paquete kexec-tools. El paquete proporciona las utilidades de línea de
comando y los archivos necesarios para administrar kdump desde la línea de comandos.
También puede instalar system-config-kdump para proporcionar una herramienta de
configuración gráfica para kdump.
Reserva de memoria
Como se mencionó anteriormente, el mecanismo kdump se basa en kexec para iniciar el
kernel de captura secundario desde un área de memoria reservada del kernel principal en
330 RH342-RHEL7.2-es-1-20160321
ejecución. El requisito de tamaño de esta memoria reservada varía según la arquitectura de

hardware del sistema y la cantidad total de memoria física instalada.
Para la arquitectura de máquina x86_64, la cantidad mínima de memoria reservada requerida

es 160 MB. Además, se requieren 2 bits adicionales de memoria reservada por cada 4 KB
de memoria RAM física instalada en el sistema. Como ejemplo, un sistema con 512 GB de
memoria física requeriría una memoria reservada total de 192 MB: 160 MB de memoria base
más 32 MB de memoria adicional debido a la cantidad de memoria RAM física instalada.
En la mayoría de los sistemas, kdump calcula y reserva automáticamente la cantidad de

memoria requerida. Este comportamiento es configurado por el ajuste crashkernel=auto
en el parámetro GRUB_CMDLINE_LINUX del archivo de configuración /etc/default/grub.
GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto no_timer_check net.ifnames=0

console=ttyS0,115200n8"
En los casos donde la cantidad de memoria reservada necesita definirse manualmente,

personalice la cantidad de memoria especificada para el parámetro crashkernel en /etc/
default/grub. Una vez que se completan los cambios en el archivo, vuelva a generar la
configuración GRUB2.
Utilice el siguiente comando para los sistemas que usan firmware BIOS.
[root@demo ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
Use el siguiente comando para los sistemas que utilizan firmware UEFI.
[root@demo ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Reinicie los sistemas posteriormente para que se aplique la cantidad de memoria reservada
especificada.
El servicio kdump
El mecanismo de volcado de error de kdump se proporciona a través del servicio kdump. Los
administradores interesados en habilitar la recopilación de volcados de error de kernel en
sus sistemas deben asegurarse de que el servicio kdump esté habilitado e iniciado en cada
sistema.
[root@demo ~]# systemctl enable kdump

Created symlink from /etc/systemd/system/multi-user.target.wants/kdump.service to /usr/
lib/systemd/system/kdump.service.
[root@demo ~]# systemctl start kdump
[root@demo ~]# systemctl status kdump
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset:
enabled)
Active: active (exited) since Thu 2016-02-18 00:40:38 EST; 4s ago
Process: 479 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Feb 18 00:40:38 serverX.lab.example.com systemd[1]: Starting Crash recovery kernel

arming...
Feb 18 00:40:38 serverX.lab.example.com kdumpctl[479]: kexec: loaded kdump kernel
Feb 18 00:40:38 serverX.lab.example.com kdumpctl[479]: Starting kdump: [OK]
RH342-RHEL7.2-es-1-20160321 331
Feb 18 00:40:38 serverX.lab.example.com systemd[1]: Started Crash recovery kernel

arming.
Con el servicio kdump habilitado e iniciado, los volcados de error de kernel comenzarán a
generarse durante los cuelgues y las caídas del sistema. El comportamiento de la recopilación
y el volcado de error de kernel puede modificarse de varias maneras al editar el archivo de
configuración /etc/kdump.conf.
Designación de objetivos de volcado de error

Por defecto, kdump captura volcados de error localmente en archivos de volcado de error
ubicados en subdirectorios en la ruta /var/crash.
[root@demo ~]# ls -la /var/crash

total 4
drwxr-xr-x. 3 root root 42 Feb 17 01:08 .
drwxr-xr-x. 20 root root 4096 Feb 17 01:07 ..
drwxr-xr-x. 2 root root 42 Feb 18 01:28 127.0.0.1-2016-02-17-01:07:02
[root@demo ~]# ls -la /var/crash/127.0.0.1-2016-02-17-01\:07\:02/
total 47468
-rw-------. 1 root root 48563396 Feb 17 01:07 vmcore
-rw-r--r--. 1 root root 39849 Feb 17 01:07 vmcore-dmesg.txt
El archivo vmcore contiene el volcado de error mientras que el archivo vmcore-dmesg.txt

contiene el registro de kernel en el momento del error. Dado que el archivo de volcado de
error contiene el volcado de memoria del kernel del sistema, puede tener un gran tamaño,
especialmente si el tamaño de las instalaciones de memoria física siguen aumentando en los
sistemas vigentes.
Debido a su gran tamaño, la entrega de este archivo al Soporte de Red Hat puede demorar
un tiempo. Para acelerar el análisis del volcado de error, se puede enviar primero el archivo
vmcore-dmesg.txt, que es mucho más pequeño, para facilitar una evaluación preliminar.
El comportamiento predeterminado de kdump de escribir volcados de error en el directorio

/var/crash, se configura con la siguiente opción de objetivo de volcado en /etc/
kdump.conf.
path /var/crash
Además de escribir en una ruta del sistema de archivos local, kdump también ofrece otros
tipos de objetivos de volcado de error con el uso de las siguientes opciones en /etc/
kdump.conf.
/etc/kdump.conf Opciones para configurar el objetivo de volcado

raw [partition] Use dd para copiar el volcado de error en la partición
especificada.
nfs [nfs share] Monte y copie el volcado de error en la ubicación
especificada por la opción path en el recurso compartido
de NFS.
ssh [user@server] Use scp para transferir el volcado de error a la ubicación
especificada por la opción path en el servidor remoto
332 RH342-RHEL7.2-es-1-20160321
especificado a través de la cuenta de usuario especificada
para la autenticación.
sshkey[sshkeypath] Se utiliza en conjunto con el tipo de volcado de error ssh
para especificar la ubicación de la clave SSH para utilizar
para la autenticación.
[fs type] [partition] Monte la partición especificada que contiene el tipo de
sistema de archivos especificado en /mnt y, luego, escriba
el volcado de error en la ubicación de la ruta especificada
por la opción path.
path [path] Especifica la ruta en la que se guardará el volcado de error
en el objetivo de volcado. Si no se especifica un objetivo
de volcado, se supone que la ruta proviene de la raíz del
sistema de archivos local.
Recopilación básica
Por defecto, la recopilación del volcado de error se realiza a través de la utilidad
makedumpfile. La opción core_collector se utiliza en /etc/kdump.conf para especificar
cómo se debe realizar la recopilación del volcado de error.
core_collector makedumpfile -l --message-level 1 -d 31
El ajuste anterior especifica que la recopilación del volcado de error se realizará a través de la
utilidad makedumpfile.
La utilidad makedumpfile ofrece las siguientes opciones para la compresión de volcados

de error. El ejemplo anterior usa el algoritmo de compresión lzo. En la siguiente tabla se
enumeran los algoritmos de compresión compatibles con makedumpfile.
makedumpfile Opciones de compresión

-c Use zlib para la compresión de datos del volcado de
error.
-l Use lzo para la compresión de datos del volcado de error.
-p Use snappy para la compresión de datos del volcado de
error.
La utilidad makedumpfile también ofrece opciones para personalizar los tipos de mensaje
que se incluyen en el resultado del error. El ejemplo anterior utiliza el nivel de mensaje 1, que
solo incluye un indicador de progreso en el mensaje de resultado del error. En la siguiente
tabla se enumeran algunos de los niveles de mensaje que se ofrecen.
nota
Puede consulta la lista completa de niveles de mensaje en la página del manual
makedumpfile(8).
RH342-RHEL7.2-es-1-20160321 333
makedumpfile Niveles de mensaje

Nivel de mensaje Descripción
0 No incluye mensajes.
l Solo incluye un indicador de progreso.
4 Solo incluye mensajes de error.
31 Incluye todos los mensajes.
La utilidad makedumpfile también ofrece opciones para filtrar el tipo de páginas incluidas en
el volcado de error. Los administradores pueden elegir la exclusión de páginas cero, páginas
en caché y páginas de datos de usuarios, así como también páginas libres, al especificar un
nivel de volcado. Este filtrado puede ayudar a disminuir considerablemente el tamaño del
volcado de error.
El ejemplo anterior utiliza el nivel de volcado 31, que excluye páginas cero, páginas en caché,
páginas de datos de usuarios y páginas libres. Este nivel de volcado ofrecería el volcado de
error más pequeño.
nota
Puede consultar la lista completa de niveles de volcado en la página del manual
makedumpfile(8).
makedumpfile Niveles de volcado

Nivel de volcado Descripción
0 Incluye todos los tipos de páginas.
l No incluye las páginas cero.
31 Excluye las páginas cero, páginas en caché, páginas de
datos de usuarios y páginas libres.
Para la recopilación de volcados de error a través de objetivos de volcado SSH, se debe

especificar la utilidad scp en lugar de makedumpfile.
core_collector scp
Uso de kdumpctl
El paquete kexec-tools incluye una utilidad de línea de comandos, kdumpctl, que puede
realizar algunas tareas de administración kdump comunes.
[root@demo ~]# kdumpctl -h

Usage: /bin/kdumpctl {start|stop|status|restart|propagate}
Puede utilizar la utilidad kdumpctl para verificar el estado del servicio kdump al utilizar el
subcomando status.
[root@demo ~]# kdumpctl status

Kdump is operational
Con el comando kdumpctl showmem, los administradores pueden mostrar la cantidad actual
de memoria reservada configurada para el kernel de captura.
334 RH342-RHEL7.2-es-1-20160321
Disparadores de volcados de error de kernel
[root@demo ~]# kdumpctl showmem

Reserved 161MB memory for crash kernel
Por último, puede utilizar el comando kdumpctl propagate para simplificar la

configuración de la autenticación basada en la clave SSH cuando se configura kdump para
entregar volcados de error en un servidor remoto a través de SSH. Consulta al parámetro
sshkey en /etc/kdump.conf para determinar la ubicación de las claves SSH que se debe
utilizar. Si la clave no existe, kdumpctl creará automáticamente el par de claves en el archivo
configurado. A continuación, ejecuta ssh-copy-id para transferir e instalar la clave pública
en el servidor de destino especificado por el parámetro ssh.
[root@demo ~]# kdumpctl propagate

WARNING: '/root/.ssh/kdump_id_rsa' doesn't exist, using default value '/root/.ssh/
kdump_id_rsa'
Generating new ssh keys... done.
The authenticity of host 'serverY.lab.example.com (172.25.250.11)' can't be established.
ECDSA key fingerprint is 62:88:d6:2a:57:b1:3b:cd:9e:3c:52:e6:e3:94:f9:59.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any
that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now
it is to install the new keys
root@serverY.lab.example.com's password: redhat
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@serverY.lab.example.com'"

and check to make sure that only the key(s) you wanted were added.
/root/.ssh/kdump_id_rsa has been added to ~root/.ssh/authorized_keys on

serverY.lab.example.com
nota
Para simplificar la configuración de kdump, los trabajos de laboratorio de Red Hat
ofrecen la herramienta en línea Kdump Helper. Esta herramienta está diseñada
para generar un script basado en las respuestas del usuario acerca del uso previsto
de sus volcados de error.
El script configura kdump para el objetivo deseado, así como el nivel de mensaje
y volcado. Además, también puede incluir configuraciones de sysctl para
desencadenar volcados de error para condiciones específicas como bloqueos de
software o eventos fuera de memoria.
Esta herramienta en línea está ubicada en https://access.redhat.com/labs/

kdumphelper/.

Cuando se configura kdump, un sistema generará un volcado de error cuando su kernel
detecte un error irrecuperable de software o hardware. Las fallas del sistema operativo que
no provocan un error irrecuperable no generarán un volcado de error. Si un volcado de error
es útil para solucionar estas fallas del sistema, los administradores pueden configurar el
sistema operativo de manera tal que desencadene volcados de error cuando ocurran.
RH342-RHEL7.2-es-1-20160321 335
Eventos OOM
Cuando un sistema se queda sin memoria, se puede invocar el eliminador Out of Memory
(OOM, Sin memoria) para eliminar los procesos y, de esa manera, liberar la memoria del
sistema y mantener el sistema en funcionamiento. Se puede configurar un sistema para
que active una rutina de pánico cuando ocurren eventos de eliminador OOM. La rutina de
pánico desencadenará la generación de un volcado de error. El contenido del volcado de
error puede proporcionar información acerca del estado de la memoria del sistema en el
momento en que se invocó al eliminador OOM.
Con el siguiente comando, los administradores pueden configurar temporalmente un sistema

para que entre en una rutina de pánico cuando ocurren eventos del eliminador OOM:
[root@demo ~]# echo 1 > /proc/sys/vm/panic_on_oom
Para que la configuración sea permanente, los administradores deben emitir los siguientes
comandos:
[root@demo ~]# echo "vm.panic_on_oom=1" >> /etc/sysctl.conf

[root@demo ~]# sysctl -p
Proceso colgado
Los sistemas también pueden configurarse para desencadenar un volcado de error cuando
se considera que un proceso está colgado. Esta condición ocurre cuando un proceso se
cuelga durante un determinado período, que por defecto es de 120 segundos. Puede
configurar el tiempo de espera para la tarea colgada, y puede ver el ajuste actual al consultar
el contenido del archivo /proc/sys/kernel/hung_task_timeout_secs.
[root@demo ~]# cat /proc/sys/kernel/hung_task_timeout_secs

120

para que entre en una rutina de pánico cuando los procesos se cuelgan durante más tiempo
que el valor de tiempo de espera:
[root@demo ~]# echo 1 > /proc/sys/kernel/hung_task_panic
comandos:
[root@demo ~]# echo "kernel.hung_task_panic=1" >> /etc/sysctl.conf

Bloqueo de software
Los bloqueos de software son el resultado de un error de software que provoca que el kernel
se repita en bucle en modo kernel durante una cantidad de tiempo irrazonable. También se
puede configurar la generación de un volcado de error de kernel cuando ocurren bloqueos
de software.

para que entre en una rutina de pánico cuando ocurren bloqueos de software:
336 RH342-RHEL7.2-es-1-20160321
[root@demo ~]# echo 1 > /proc/sys/kernel/softlockup_panic
comandos:
[root@demo ~]# echo "kernel.softlockup_panic=1" >> /etc/sysctl.conf

Interrupción no enmascarable (Non-maskable interrupt)

Cuando un sistema detecta una falla de hardware irrecuperable, se puede utilizar una
interrupción no enmascarable (NMI) para desencadenar una rutina de pánico de kernel y
generar un volcado de error. La NMI se puede generar automáticamente a través de la
vigilancia de NMI, si está habilitada. También se puede generar manualmente a través del
administrador al presionar el botón de NMI físico en el hardware del sistema o un botón NMI
virtual de la interfaz de gestión fuera de banda del sistema, como iLO de HP o iDRAC de Dell.

para que entre en una rutina de pánico cuando se detectan NMI:
[root@demo ~]# echo 1 > /proc/sys/kernel/panic_on_io_nmi
comandos:
[root@demo ~]# echo "kernel.panic_on_io_nmi=1" >> /etc/sysctl.conf

SysRq mágica
La clave SysRq "mágica" es una secuencia de claves que se puede utilizar en un sistema
que no responde para diagnosticar problemas relacionados con el kernel. Esta función está
deshabilitada por defecto y puede habilitarse temporalmente con el siguiente comando.
[root@demo ~]# echo 1 > /proc/sys/kernel/sysrq
comandos:
[root@demo ~]# echo "kernel.sysrq=1" >> /etc/sysctl.conf

Una vez que se habilita la instalación SysRq, se puede activar el sistema para ejecutar
los eventos SysRq con la entrada de comandos SysRq específicos. Puede ingresar estos
comandos con la secuencia Alt+PrintScreen+[CommandKey]. En la siguiente tabla se
resumen los comandos SysRq y sus eventos asociados.
Comandos SysRq y eventos asociados

Comando SysRq Evento
m Vuelca información acerca de la asignación de memoria.
t Vuelca información acerca del estado del subproceso.
p Vuelca indicadores y registros de la CPU.
RH342-RHEL7.2-es-1-20160321 337
Comando SysRq Evento

c Interrumpe el sistema.
s Sincroniza sistemas de archivos montados.
u Vuelve a montar sistemas de archivos de solo lectura.
b Activa el reinicio del sistema.
9 Apaga el sistema.
f Inicia el eliminador OOM.
w Vuelca procesos colgados.
Una alternativa al método mencionado de emitir comandos SysRq como una combinación
de claves es emitir comandos SysRq al escribir sus caracteres de clave SysRq asociados en
/proc/sysrq-trigger. Por ejemplo, el siguiente comando iniciará una interrupción del
sistema.
[root@demo ~]# echo 'c' > /proc/sysrq-trigger
Prueba de kdump
Una vez que se configura kdump, se debe reiniciar el servicio kdump para que se apliquen
los ajustes de configuración. Como se mencionó, puede utilizar kdumpctl para verificar el
estado del servicio kdump.
Para probar otros aspectos del mecanismo kdump, puede iniciar un volcado de error a través
de la instalación SysRq. Al habilitar la instalación SysRq y emitir el comando c, se puede iniciar
una secuencia de errores de kernel.
[root@demo ~]# echo 1 > /proc/sys/kernel/sysrq

[root@demo ~]# echo c > /proc/sysrq-trigger
[200167.888304] SysRq : Trigger a crash
[200167.888508] BUG: unable to handle kernel NULL pointer dereference at
(null)
[200167.888887] IP: [<ffffffff813b9716>] sysrq_handle_crash+0x16/0x20
[200167.889183] PGD 795be067 PUD 78575067 PMD 0
[200167.889405] Oops: 0002 [#1] SMP
Análisis de volcados de error de kernel

Aunque analizar volcados de error de kernel puede exigir trabajo muy especializado, con
conocimientos detallados sobre el kernel de Linux, hay algunos pasos de análisis básicos que
los administradores del sistema pueden realizar sin tener conocimientos expertos de kernel.
Esto incluye observar la lista de archivos abiertos en el momento de la caída, procesos en
ejecución en el momento de la caída, y mucho más.
Preparación de un sistema para el análisis de volcado de error

Debe instalar algunos paquetes antes de poder analizar un volcado:
• Los paquetes kernel-debuginfo que coinciden con la versión del kernel en la cual se realizó
el volcado. Puede encontrar esta información en el archivo vmcore-dmesg.txt que está
almacenado junto al volcado de error del kernel, o al ejecutar el comando strings en el
archivo vmcore.
338 RH342-RHEL7.2-es-1-20160321
Análisis de volcados de error de kernel
[root@demo 127.0.0.1-2016-03-15-08:28:06]# strings vmcore | head

KDUMP
Linux
demo.example.com
3.10.0-327.el7.x86_64
#1 SMP Thu Oct 29 17:29:29 EDT 2015
...
• El paquete crash.
Análisis de volcados de error con caídas

El comando crash necesita dos parámetros, la versión de “depuración” de la imagen del
kernel (instalada por el paquete kernel-debuginfo), y el archivo vmcore de volcado de error del
kernel. Si el archivo vmcore omite crash la sesión, se ejecutará contra el kernel que está en
ejecución actualmente.
[root@demo ~]# crash \

> /usr/lib/debug/modules/3.10.0-327.el7.x86_64/vmlinux \
> /var/crash/127.0.0.1-2016-03-15-08:28:06
El resultado mostrará información útil, incluido el motivo de la rutina de pánico del kernel.
Dentro del entorno crash, hay una variedad de comandos útiles a disposición. Siempre
puede obtener ayuda específica a través del comando help [COMMAND]. Para salir, solo
debe escribir exit en el aviso.
Los siguientes comandos pueden ser útiles para un administrador del sistema que está
investigando un volcado de error de kernel:
• files <PID>: Este comando mostrará los archivos abiertos para el proceso especificado.
La variación foreach files mostrará todos los archivos abiertos para cada proceso que
estaba ejecutándose en el momento de la caída del sistema.
• ps: Este comando mostrará una lista de todos los procesos que estaban ejecutándose en
el momento de la caída del sistema. Se pueden utilizar varios argumentos para modificar el
resultado; para ello, consulte help ps.
• fuser <PATHNAME>: Este comando funciona como el comando fuser regular, mostrando
qué procesos estaban usando un archivo o directorio determinado y en qué manera.
Como alternativa a un nombre de ruta, puede especificar un número inodo con formato
hexadecimal.
Referencias
Guía para volcados de error de kernel de Red Hat Enterprise Linux 7
html/Kernel_Crash_Dump_Guide/
Páginas del manual kdump(8), kexec(8), grub-mkconfig(1), kdump.conf(5) y

makedumpfile(8)
RH342-RHEL7.2-es-1-20160321 339
Ejercicio guiado: Creación de volcados de

error de kernel
En este trabajo de laboratorio, configurará y probará volcados de error de kernel.
Recursos
Archivos • /etc/kdump.conf
• /var/kdump
• serverb
Resultados
Deberá poder configurar kdump para volcar en un servidor remoto durante una caída de
kernel.
Andes de comenzar
Inicie sesión en servera y serverb a través de la consola como el usuario root.
Se le ha pedido que configure sus servidores para que generen volcados de error durante
una caída del sistema. Para una administración más simple y un uso más eficiente del
almacenamiento, ha decidido consolidar todos los volcados de error en un servidor central,
servera. Configure servera para que los sistemas remotos puedan escribir volcados de
error en el directorio /var/kdump.
Use serverb para probar su configuración kdump antes de implementarla en sus servidores
restantes. Los volcados de error de kernel deben generarse en el directorio /var/kdump en
servera a través de una sesión SSH con el comando scp.
1. En servera, cree el directorio /var/kdump para crear espacio para los volcados de error
de sistemas remotos.
[root@servera ~]# mkdir /var/kdump
2. En serverb, verifique si el servicio kdump está habilitado y activo. Si no es el caso,

habilite e inicie el servicio kdump.
2.1. Verifique el estado del servicio kdump para ver si el servicio está habilitado e iniciado.
Este servicio debe estar en ejecución para que se desencadene el mecanismo de
volcado de error de kernel durante una caída del sistema.
[root@serverb ~]# systemctl is-enabled kdump

disabled
[root@serverb ~]# systemctl is-active kdump
inactive
2.2. Dado que el servicio no está habilitado ni iniciado, habilite e inicie el servicio para
que habilitar los volcados de error de kernel y, luego, verificar el estado del servicio
para asegurarse de que se haya iniciado correctamente.
340 RH342-RHEL7.2-es-1-20160321
[root@serverb ~]# systemctl enable kdump
Created symlink from /etc/systemd/system/multi-user.target.wants/kdump.service
to /usr/lib/systemd/system/kdump.service.
[root@serverb ~]# systemctl start kdump
[root@serverb ~]# systemctl status kdump
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor
preset: enabled)
Active: active (exited) since Wed 2016-02-10 22:40:28 EST; 6s ago
Process: 1517 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/
SUCCESS)
Feb 10 22:40:27 serverb.lab.example.com systemd[1]: Starting Crash recovery k...

Feb 10 22:40:28 serverb.lab.example.com kdumpctl[1517]: kexec: loaded kdump k...
Feb 10 22:40:28 serverb.lab.example.com kdumpctl[1517]: Starting kdump: [OK]
Feb 10 22:40:28 serverb.lab.example.com systemd[1]: Started Crash recovery ke...
3. Edite /etc/kdump.conf para configurar kdump para que los volcados de error se
depositen en el directorio /var/kdump en servera.
3.1. Agregue la siguiente entrada para habilitar servera.lab.example.com como un

objetivo SSH para kdump.
ssh root@servera.lab.example.com
3.2. Agregue la siguiente entrada para especificar /root/.ssh/kdump_id_rsa como la

clave SSH que se utilizará para autenticar en servera.
sshkey /root/.ssh/kdump_id_rsa
3.3. Modifique la entrada core_collector para que se utilice scp para depositar
el volcado de error en servera. Esta línea debe reemplazar cualquier línea
core_collector existente.
core_collector scp
3.4. Modifique la entrada path para que los volcados de error se depositen en /var/
kdump en servera.
path /var/kdump
4. Utilice kdumpctl para generar e instalar remotamente la clave SSH que se utilizará para
transferir el volcado de error a servera.
[root@serverb ~]# kdumpctl propagate

WARNING: '/root/.ssh/kdump_id_rsa' doesn't exist, using default value '/root/.ssh/
kdump_id_rsa'
Generating new ssh keys... done.
The authenticity of host 'servera.lab.example.com (172.25.250.11)' can't be
established.
RH342-RHEL7.2-es-1-20160321 341
ECDSA key fingerprint is 62:88:d6:2a:57:b1:3b:cd:9e:3c:52:e6:e3:94:f9:59.

Are you sure you want to continue connecting (yes/no)? yes
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any
that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now
it is to install the new keys
root@servera.lab.example.com's password:redhat
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@servera.lab.example.com'"

and check to make sure that only the key(s) you wanted were added.
/root/.ssh/kdump_id_rsa has been added to ~root/.ssh/authorized_keys on

servera.lab.example.com
5. Reinicie el servicio kdump para que se apliquen los cambios de configuración.
[root@serverb ~]# systemctl restart kdump

Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset:
enabled)
Process: 3109 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Feb 10 23:33:15 serverb.lab.example.com dracut[5229]: -rw-r--r-- 1 root ...

Feb 10 23:33:15 serverb.lab.example.com dracut[5229]: drwxr-xr-x 3 root ...
Feb 10 23:33:15 serverb.lab.example.com dracut[5229]: drwxr-xr-x 2 root ...
Feb 10 23:33:15 serverb.lab.example.com dracut[5229]: -rw-r--r-- 1 root ...
Feb 10 23:33:15 serverb.lab.example.com dracut[5229]: lrwxrwxrwx 1 root ...
Feb 10 23:33:15 serverb.lab.example.com dracut[5229]: lrwxrwxrwx 1 root ...
Feb 10 23:33:15 serverb.lab.example.com dracut[5229]: =======================...
6. Desencadene una caída del sistema para probar la configuración kdump en serverb.
6.1. Habilite todas las funciones SysRq de kernel al establecer el valor dentro del archivo
/proc/sys/kernel/sysrq en 1.
[root@serverb ~]# echo 1 > /proc/sys/kernel/sysrq
6.2. Desencadene una caída del sistema al establecer el valor dentro del archivo /proc/
sysrq-trigger en c.
[root@serverb ~]# echo c > /proc/sysrq-trigger
7. Compruebe que el volcado de error de kernel se haya generado correctamente en

servera al buscar la presencia de un nuevo directorio en /var/kdump que contenga el
volcado de error de serverb.
[root@servera ~]# ll /var/kdump
342 RH342-RHEL7.2-es-1-20160321
total 0
[root@servera ~]# ll /var/kdump/172.25.250.10-2016-02-10-23\:55\:28/
total 1951732
-r--------. 1 root root 1998532608 Feb 10 23:55 vmcore
[student@workstation ~]$ lab kdump grade
[student@workstation ~]$ lab kdump reset
RH342-RHEL7.2-es-1-20160321 343
Depuración de kernel con SystemTap
Objetivos
Después de completar esta sección, los estudiantes podrán compilar scripts de SystemTap en
módulos de kernel para implementarlos en sistemas remotos.
Introducción a SystemTap
El framework (marco) de SystemTap permite el sondeo y la instrumentación simples de casi
todos los componentes dentro de kernel. Les proporciona a los administradores una librería y
un lenguaje de programación flexible al aprovechar la instalación kprobes dentro del kernel
de Linux.
A través del uso de kprobes, los programadores de kernel pueden adjuntar código de
instrumentación al inicio o final de cualquier función de kernel. Los scripts de SystemTap
especifican dónde adjuntar sondeos y qué datos recopilar cuando se ejecuta el sondeo. El
comando stap analiza el script en código fuente C generado dinámicamente para un módulo
de kernel personalizado, compila el módulo de instrumentación y, luego, llama a staprun
para insertar el módulo y, cuando es adecuado, elimina el módulo del kernel.
Instalación de SystemTap
Dado que SystemTap requiere una nomenclatura simbólica para las instrucciones dentro
de kernel, depende de los siguientes paquetes que, por lo general, no se encuentran en
sistemas de producción. Estos paquetes se desplegaran en cualquier dependencia requerida.
En particular, gcc es una depentencia del paquete systemtap.
nota
Las versiones del paquete relacionado al kernel deben coincidir con el número de
versión del kernel de destino.
• kernel-debuginfo
• kernel-devel
• systemtap
La mayoría de estos paquetes y sus dependencias se incluyen como parte de la distribución

de base de Red Hat Enterprise Linux. Sin embargo, kernel-debuginfo y su dependencia kernel-
debuginfo-common son proporcionados por el repositorio rhel-MAJOR_VERS-SPIN-debug-
rpms. Un administrador necesitará autorizar esta máquina en este repositorio antes de
instalar estos RPM a través de subscription-manager. A continuación se indica un ejemplo
de cómo un administrador podría utilizar el comando subscription-manager:
[root@demo ~]# subscription-manager repos --enable rhel-7-server-debug-rpms
En clase, estos RPM se proporcionan como parte del repositorio yum del contenido del curso.
344 RH342-RHEL7.2-es-1-20160321
Uso de stap para ejecutar scripts de SystemTap
nota
Uno de los comandos incluidos en el paquete systemtap-client, una dependencia
de systemtap, es stap-prep. stap-prep es útil después de que un administrador
haya instalado el paquete systemtap y registrado la máquina en el repositorio
correcto. Cuando se ejecuta, stap-prep examinará el kernel que está en ejecución
actualmente e instalará los paquetes kernel-devel y kernel-debuginfo coincidentes.
También se puede utilizar el comando debuginfo-install del paquete yum-utils

para instalar los paquetes *-debuginfo. Este comando habilitará automáticamente
cualquier repositorio debuginfo configurado e instalará los paquetes -debuginfo
para cualquier paquete requerido.
Uso de stap para ejecutar scripts de SystemTap

El paquete systemtap proporciona una variedad de scripts de muestra que pueden ser de
utilidad para los administradores para la recopilación de datos en sus sistemas. Estos scripts
se almacenan en /usr/share/doc/systemtap-client-*/examples. Los scripts están
divididos en diferentes subdirectorios en función del tipo de información que se les indicó
que recopilaran. Los scripts de SystemTap tienen una extensión de .stp.
Para compilar y ejecutar estos scripts de ejemplo, o cualquier script de SystemTap en este
sentido, los administradores usan el comando stap. El comando stap pasará por estos cinco
pasos:
1. Analizar el script de SystemTap para validar su sintaxis.
2. Ampliar el script para incluir sondeos y llamadas de función.
3. Traducir el script a C.
4. Compilar el script en un módulo de kernel.
5. Llamar al comando staprun para cargar el módulo del kernel, iniciar la ejecución del
programa y descargar el módulo al final de la ejecución del programa.
[root@demo ~]# stap /usr/share/doc/systemtap-client-*/examples/process/

syscalls_by_proc.stp
Collecting data... Type Ctrl-C to exit and display results
^C
#SysCalls Process Name
2208 pgrep
1477 stapio
842 ksmtuned
776 Xorg
584 tuned
Si ejecuta stap con la opción -v, se mostrarán las etapas que stap realiza para ejecutar el
programa.
[root@demo ~]# stap -v /usr/share/doc/systemtap-client-*/examples/process/

RH342-RHEL7.2-es-1-20160321 345
Pass 1: parsed user script and 101 library script(s) using

213896virt/31184res/2976shr/28836data kb, in 280usr/60sys/339real ms.
Pass 2: analyzed script: 396 probe(s), 18 function(s), 26 embed(s), 1 global(s) using
Pass 3: translated to C into "/tmp/stap7MUG27/
stap_820fd86a21675106576989f6c98eed6b_110418_src.c" using
Pass 4: compiled C into "stap_820fd86a21675106576989f6c98eed6b_110418.ko" in
14490usr/4680sys/19286real ms.
Pass 5: starting run.
#SysCalls Process Name
283 stapio
108 tuned
100 pool
42 gnome-shell
Pass 5: run completed in 20usr/26040sys/54119real ms.
En el resultado stap anterior, stap muestra explícitamente las etapas que utiliza para
pasar de un script basado en texto a cargar y ejecutar el módulo del kernel. Observe el
Paso 2; durante este paso, el script se expande y se traduce a C. En el Paso 3, el nuevo
programa C se compila del directorio de caché temporal al módulo del kernel. En el Paso 4,
el módulo del kernel se carga desde el directorio de caché. El Paso 5 maneja la ejecución de
la instrumentación de SystemTap y, cuando finaliza, la descarga del módulo del kernel.
Compilación de programas de SystemTap en

módulos de kernel portátiles
Como parte de una compilación SystemTap típica, el programa stap compilará un módulo
de kernel. Por defecto, esto se almacena en un directorio caché en el directorio de inicio del
usuario que ejecuta stap. Sin embargo, puede ser útil para los administradores que stap
detenga la ejecución de su programa después de haber creado este módulo de kernel, y
almacenar el módulo con un nombre específico en una ubicación de directorio alternativa.
Escribir el objeto de kernel con un nombre específico y en un directorio fuera del directorio
de caché normal facilitará que otros usuarios, con los permisos correctos, carguen y utilicen
estos módulos. Además, permitirá que estos módulos se copien fácilmente en otros
sistemas, siempre y cuando los otros sistemas de destino estén ejecutando la misma versión
del kernel que el sistema donde se compiló el módulo de SystemTap.
[root@demo ~]# stap -p 4 -v -m syscalls_by_proc \

> /usr/share/doc/systemtap-client-*/examples/process/syscalls_by_proc.stp
El ejemplo anterior detendrá la ejecución de stap después del Paso 4 (-p 4). El módulo
de kernel resultante se colocará en syscalls_by_proc.ko (-m syscalls_by_proc) en el
directorio de trabajo actual.
346 RH342-RHEL7.2-es-1-20160321
Ejecución de programas SystemTap como un usuario que no es root
nota
El nombre utilizado por el módulo de kernel puede contener solo los siguientes
caracteres:
• Caracteres alfabéticos ASCII en minúsculas (a-z)
• Dígitos (0-9)
• Guiones bajos (_)
Ejecución de programas SystemTap como un

usuario que no es root
El framework (marco) de SistemTap proporciona la capacidad de que los usuarios que
no son root ejecuten programas SystemTap que se compilaron en módulos de kernel. Se
debe agregar a los usuarios al grupo stapusr o stapdev. Según el grupo al que el usuario
pertenezca, se ajustará el nivel de privilegio con los módulos de kernel de instrumentación y
aplicaciones de SystemTap.
Grupo de Descripción
SystemTap
stapusr El usuario puede ejecutar módulos de instrumentación de
SystemTap, pero solo si existen en el directorio /lib/modules/
$(uname -r)/systemtap. Es posible que los usuarios de este
grupo no se compilen ni interactúen con SystemTap. Además, el
usuario root debe ser el propietario del directorio /lib/modules/
$(uname -r)/systemtap y tener permisos de escritura solo para
root.
El usuario solo puede usar staprun para cargar y ejecutar módulos

de kernel de SystemTap. Los usuarios de este grupo no tienen
permitido acceder a stap.
stapdev Los usuarios con una membresía del grupo stapdev pueden
compilar sus propios módulos del kernel de instrumentación
de SystemTap a través de stap. Si el usuario también tiene una
membresía stapusr, puede usar staprun para cargar un módulo,
incluso si no reside en el directorio /lib/modules/$(uname -r)/
systemtap.
Supongamos que un administrador compiló un módulo de instrumentación de SystemTap

denominado /root/syscalls_by_proc.ko. Para que este módulo esté disponible para los
usuarios del grupo stapusr, se realizarían estas acciones:
[root@demo ~]# mkdir /lib/modules/$(uname -r)/systemtap

[root@demo ~]# ls -ld /lib/modules/$(uname -r)/systemtap
drwxr-xr-x. 2 root root 6 Jan 26 17:26 /lib/modules/3.10.0-123.el7.x86_64/systemtap
[root@demo ~]# cp /root/syscalls_by_proc.ko /lib/modules/$(uname -r)/systemtap
Por su parte, un usuario que pertenece a stapusr ahora puede ejecutar su módulo de
instrumentación dividido en etapas.
RH342-RHEL7.2-es-1-20160321 347
[student@demo ~]$ staprun syscalls_by_proc

De manera alternativa, se puede proporcionar staprun con la ruta completa al módulo de

destino, pero cuando se ejecuta con un nombre de módulo vacío, buscará el archivo .ko
coincidente en el directorio /lib/modules/KERNELVERS/systemtap del kernel que está
ejecutándose.
Un usuario con membresías del grupo stapusr y del grupo stapdev puede ejecutar el
comando stap de la misma manera que el usuario root puede hacerlo.
[student@demo ~]$ stap -v /usr/share/doc/systemtap-client-*/examples/process/

nota
Debido a este privilegio root especial para compilar y cargar módulos de kernel
en el kernel en ejecución, se recomienda que los administradores concedan este
permiso con prudencia.
Preparación de una máquina con un entorno de

tiempo de ejecución de SystemTap
Los módulos de instrumentación de SystemTap son utilizados por el Soporte de Red Hat
y los clientes para recopilar datos y determinar la causa de los problemas. Son muy útiles,
pero, al tener que instalar el software necesario para compilar los módulos de SystemTap,
pueden no ser un paquete deseable configurado para ejecutarse en todas las máquinas.
Teniendo en cuenta la utilización del sistema de archivos, las actualizaciones adicionales de
paquetes, los recursos del sistema consumidos para compilar programas de SystemTap,
etc., los administradores deben ser cautelosos a la hora de implementar esta tecnología.
Sin embargo, es muy común tener solo el conjunto de compilación completo de SystemTrap
instalado en una única máquina. En esta máquina, los módulos de instrumentación se
compilan en módulos de kernel. Después de que se compilan los módulos, se copian en
los sistemas de destino, que solo tienen el entorno de tiempo de ejecución de SystemTap
instalado. El entorno de tiempo de ejecución de SystemTap proporciona staprun, que
cargará y ejecutará el módulo.
Para el entorno de tiempo de ejecución de SystemTap, una máquina necesita un único

paquete:
• systemtap-runtime
En Red Hat Enterprise Linux 7, systemtap-runtime es parte del grupo de paquetes Base, por lo
que debe instalarse en la mayoría de los sistemas de manera predeterminada.
Implementación de un módulo de instrumentación

de SystemTap
Después de copiar el módulo de instrumentación de SystemTap compilado al sistema de
destino, la única aplicación disponible para cargarlo y ejecutarlo es staprun. Como root, el
348 RH342-RHEL7.2-es-1-20160321
Implementación de un módulo de instrumentación de SystemTap
módulo puede ejecutarse desde cualquier ubicación de directorio. Como se observó en la

sección anterior, los usuarios que no son root pueden tener privilegios de membresías de
grupos en stapusr o stapdev para permitirles cargar y ejecutar el módulo.
Un usuario con membresía stapdev y stapusr en la máquina de entorno de tiempo de

ejecución podrá ejecutar el módulo desde cualquier parte del sistema de archivos.
Un usuario con la membresía de stapusr únicamente podrá cargar y ejecutar módulos

almacenados en el directorio /lib/modules/$(uname -r)/systemtap.
Referencias
Guía de principiantes de Red Hat Enterprise Linux 7
Base de conocimientos: "¿Cómo descargar paquetes debuginfo?"

Páginas del manual: stap(1), staprun(8)
RH342-RHEL7.2-es-1-20160321 349
Ejercicio guiado: Depuración de kernel con

SystemTap
En este trabajo de laboratorio, compilará y distribuirá un módulo de SystemTap.
Recursos
Archivos: • /usr/share/doc/systemtap-client-2.8/examples/
io/iotop.stp
• /lib/modules/3.10.0-327.el7.x86_64/systemtap
Máquinas: • servera
• serverb
Resultados
Deberá compilar un programa de SystemTap y distribuirlo para que un usuario u otro sistema
lo ejecute.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab systemtap setup en
[student@workstation ~#$ lab systemtap setup
Un desarrollador que trabaja con serverb se queja sobre el rendimiento deficiente del
sistema. Un administrador junior le informa que ya ha tratado de solucionar el problema y ha
determinado que el rendimiento deficiente se debe a un alto nivel de actividades de E/S de
disco del sistema. El administrador confirmó esto con la utilidad iostat que informa que el
nivel intenso de actividades de E/S ocurre en el disco secundario del sistema, /dev/vdb.
El administrador le pide ayuda porque no puede determinar cuál es el proceso responsable

por el nivel intenso de actividades de E/S en ese disco. Cree e instale un programa de
SystemTap que pueda ayudarlo a determinar la causa del problema. También, proporciónele
al desarrollador la capacidad de ejecutar el programa con su cuenta student para que
pueda resolver él mismo el problema si ocurre nuevamente en el futuro.
1. Instale el software systemtap.
1.1. Verifique si los paquetes kernel-debuginfo y kernel-devel que systemtap necesita están
instalados. Si no es el caso, instale los paquetes.
[root@servera ~]# rpm -q kernel-debuginfo kernel-devel

package kernel-debuginfo is not installed
package kernel-devel is not installed
[root@servera ~]# yum install -y kernel-debuginfo kernel-devel
1.2. Instale el paquete systemtap.
[root@servera ~]# yum install -y systemtap
350 RH342-RHEL7.2-es-1-20160321
2. Determine si hay un script de SystemTap para determinar el uso de E/S del disco por
proceso.
2.1. Échele un vistazo a los scripts de ejemplo de E/S incluidos en el paquete systemtap
para ver si alguno es adecuado.
[root@servera ~]# ls -la /usr/share/doc/systemtap-client-2.8/examples/io

total 176
-rw-r--r--. 1 root root 448 Sep 2 13:06 deviceseeks.meta
-rwxr-xr-x. 1 root root 771 Sep 2 13:06 deviceseeks.stp
-rw-r--r--. 1 root root 418 Sep 2 13:06 iotop.meta
-rwxr-xr-x. 1 root root 656 Sep 2 13:06 iotop.stp
-rwxr-xr-x. 1 root root 1681 Sep 2 13:06 ttyspy.stp
-rw-r--r--. 1 root root 455 Sep 2 13:06 ttyspy.txt
2.2. El script iotop.stp parece prometedor ya que su contenido indica que informará
los principales 10 procesos de E/S.
[root@servera ~]# cat /usr/share/doc/systemtap-client-2.8/examples/io/iotop.stp

# print top 10 IO processes every 5 seconds
probe timer.s(5) {
foreach (name in writes)
total_io[name] += writes[name]
3. Compile iotop.stp en un módulo de kernel portátil llamado iotop.
[root@servera ~]# cd /root; stap -v -p 4 -m iotop /usr/share/doc/systemtap-

client-2.8/examples/io/iotop.stp
347196virt/165800res/4216shr/162004data kb, in 1
Pass 3: translated to C into "/tmp/stapZRfkvF/iotop_src.c" using
347196virt/166144res/4560shr/162004data kb, in 10usr/30sys/41real
ms.
iotop.ko
Pass 4: compiled C into "iotop.ko" in 3660usr/680sys/4789real ms.
4. Distribuya el módulo de kernel iotop en serverb.
4.1. En serverb, verifique si el directorio del módulo de kernel de SystemTap ya existe.

Si no es el caso, cree el directorio para el módulo de SystemTap. Utilice el nombre de
la versión del kernel que se ejecuta en serverb para especificar un nombre para el
directorio del módulo.
[root@serverb ~]# ls -la /lib/modules/$(uname -r)/systemtap

ls: cannot access /lib/modules/3.10.0-327.el7.x86_64/systemtap: No such file or
directory
[root@serverb ~]# mkdir -p /lib/modules/$(uname -r)/systemtap
RH342-RHEL7.2-es-1-20160321 351
4.2. Copie el módulo de kernel iotop.ko de servera al directorio del módulo de kernel
de SystemTap en serverb.
[root@serverb ~]# rsync -avz -e ssh root@servera:/root/iotop.ko /lib/modules/

$(uname -r)/systemtap/
root@servera's password: redhat
receiving incremental file list
iotop.ko
sent 30 bytes received 34918 bytes 13979.20 bytes/sec

total size is 115531 speedup is 3.31
5. En serverb, configure la cuenta de usuario student para que pueda ejecutar el módulo
de kernel de SystemTap recientemente instalado. Debido a que la cuenta de usuario solo
necesitará ejecutar módulos de kernel de SystemTap, solo necesita agregarse al grupo
stapusr.
[root@serverb ~]# usermod -a -G stapusr student
6. En serverb, verifique que el usuario student pueda ejecutar correctamente el

programa de SystemTap recientemente instalado. Después de varias iteraciones de
resultados, finalice el programa al ingresar Ctrl-C.
[root@serverb ~]# su - student

[student@serverb ~]$ id
uid=1000(student) gid=1000(student) groups=1000(student),10(wheel),156(stapusr)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[student@serverb ~]$ staprun iotop
Process KB Read KB Written
dd 41758 885
cleandisk.sh 8831 0
systemd-udevd 0 0
stapio 0 0

dd 42094 892
cleandisk.sh 8901 0
irqbalance 3 0
sshd 0 0
stapio 0 0

dd 42060 891
cleandisk.sh 8895 0
sshd 0 0
stapio 0 0
master 0 0
pickup 0 0
Ctrl-C
7. Use el resultado del programa de SystemTap para determinar la causa de la actividad

intensa de E/S del disco y localizar su proceso principal.
[root@serverb ~]# ps -lef | grep cleandisk.sh

0 S root 12663 12662 18 82 2 - 28312 wait 22:22 ? 00:00:59 /bin/
bash /usr/local/bin/cleandisk.sh
352 RH342-RHEL7.2-es-1-20160321
[root@serverb ~]# cat /usr/local/bin/cleandisk.sh
#!/bin/bash
while true; do
dd if=/dev/zero of=/dev/vdb size=1024 count=1000000
done
[student@workstation ~]$ lab systemtap grade
[student@workstation ~]$ lab systemtap reset
RH342-RHEL7.2-es-1-20160321 353

problemas de kernel
En este trabajo de laboratorio, recopilará un módulo de SystemTap y configurará un sistema

para volcado de crash.
Recursos
Archivos • /usr/share/doc/systemtap-client-2.8/examples/
network/nettop.stp
• /etc/kdump.conf
• /var/crash
• serverb
Resultados
Deberá poder configurar un sistema para recopilar un volcado de error durante una caída de
kernel y compilar un programa de SystemTrap como un módulo de kernel portátil.
Andes de comenzar
Prepare su sistema para este ejercicio ejecutando el comando lab kernel setup en su
[student@workstation ~#$ lab kernel setup
Un administrador colega está experimentando problemas en serverb durante momentos

de elevada actividad de la red. El rendimiento del sistema se vuelve deficiente y, luego,
finalmente, este deja de responder. Para intentar determinar la causa del problema, le
gustaría poder determinar la cantidad de actividad de la red asociada con cada daemon de
red cuando se degrada el rendimiento del sistema.
El administrador observó que el script de SystemTap ubicado en /usr/share/doc/

systemtap-client-2.8/examples/network/nettop.stp proporcionaría el resultado
deseado. Ha instalado los paquetes kernel-debuginfo, kernel-devel y systemtap en servera.
Quería compilar el script en servera como un módulo de kernel portátil. Necesita su ayuda
porque no puede compilar el script de SystemTap de nettop.stp. Resuelva el problema de
compilación de SystemTap en servera.
Para ayudar al administrador a identificar la causa del problema en serverb, configúrelo

para que genere un volcado de error cuando el sistema deja de responder. Los volcados
se deben escribir localmente en el directorio /var/crash. Para reducir el tamaño de los
volcados de error, comprímalos con el algoritmo lzo y solo incluya páginas de datos de
usuario. Proporcione la máxima cantidad de información de diagnóstico haciendo que el
resultado generado durante el volcado de error incluya todos los tipos de mensaje.
1. En servera, intente compilar el script de SystemTap nettop.stp en un módulo de

kernel portátil para ver qué errores encontró su administrador colega.
354 RH342-RHEL7.2-es-1-20160321
2. Analice los mensajes de error y utilícelos para detectar y resolver el problema con la
compilación.
3. Compile el script de SystemTap en un módulo de kernel portátil. Almacene los módulos

compilados como /root/nettop.ko en servera.

5. Configure kdump para que los volcados de error se depositen en el directorio /var/
crash utilizando el algoritmo de compresión lzo y generando todos los tipos de
mensajes.

servera al buscar la presencia de un nuevo directorio en /var/crash que contenga el
[student@workstation ~]$ lab kernel grade
8.2. Reinicie todas sus máquinas para proveer un entorno limpio para los siguientes
ejercicios.
RH342-RHEL7.2-es-1-20160321 355
Solución
En este trabajo de laboratorio, recopilará un módulo de SystemTap y configurará un sistema
para volcado de crash.
Recursos
Archivos • /usr/share/doc/systemtap-client-2.8/examples/
network/nettop.stp
• /etc/kdump.conf
• /var/crash
• serverb
Resultados
Deberá poder configurar un sistema para recopilar un volcado de error durante una caída de
kernel y compilar un programa de SystemTrap como un módulo de kernel portátil.
Andes de comenzar
Prepare su sistema para este ejercicio ejecutando el comando lab kernel setup en su
[student@workstation ~#$ lab kernel setup
Un administrador colega está experimentando problemas en serverb durante momentos

de elevada actividad de la red. El rendimiento del sistema se vuelve deficiente y, luego,
finalmente, este deja de responder. Para intentar determinar la causa del problema, le
gustaría poder determinar la cantidad de actividad de la red asociada con cada daemon de
red cuando se degrada el rendimiento del sistema.
El administrador observó que el script de SystemTap ubicado en /usr/share/doc/

systemtap-client-2.8/examples/network/nettop.stp proporcionaría el resultado
deseado. Ha instalado los paquetes kernel-debuginfo, kernel-devel y systemtap en servera.
Quería compilar el script en servera como un módulo de kernel portátil. Necesita su ayuda
porque no puede compilar el script de SystemTap de nettop.stp. Resuelva el problema de
compilación de SystemTap en servera.
Para ayudar al administrador a identificar la causa del problema en serverb, configúrelo

para que genere un volcado de error cuando el sistema deja de responder. Los volcados
se deben escribir localmente en el directorio /var/crash. Para reducir el tamaño de los
volcados de error, comprímalos con el algoritmo lzo y solo incluya páginas de datos de
usuario. Proporcione la máxima cantidad de información de diagnóstico haciendo que el
resultado generado durante el volcado de error incluya todos los tipos de mensaje.
1. En servera, intente compilar el script de SystemTap nettop.stp en un módulo de

kernel portátil para ver qué errores encontró su administrador colega.
[root@servera ~]# stap -v -p 4 -m nettop /usr/share/doc/systemtap-client-2.8/

examples/network/nettop.stp
356 RH342-RHEL7.2-es-1-20160321
Solución
semantic error: while resolving probe point: identifier 'kernel' at /usr/share/

systemtap/tapset/linux/networking.stp:80:5
source: = kernel.function("dev_queue_xmit")
^
semantic error: missing x86_64 kernel/module debuginfo [man warning::debuginfo]

under '/lib/modules/3.10.0-327.el7.x86_64/build'
semantic error: while resolving probe point: identifier 'netdev' at /usr/share/doc/

systemtap-client-2.8/examples/network/nettop.stp
:6:7
source: probe netdev.transmit
^
2. Analice los mensajes de error y utilícelos para detectar y resolver el problema con la
compilación.
2.1. Dado que los mensajes de error informan que faltan las dependencias debuginfo
necesarias, verifique que estén instalados los paquetes de kernel correctos.
[root@servera ~]# rpm -qa | grep ^kernel

kernel-3.10.0-327.el7.x86_64
kernel-tools-3.10.0-327.el7.x86_64
kernel-debuginfo-common-x86_64-3.10.0-327.4.5.el7.x86_64
kernel-debuginfo-3.10.0-327.4.5.el7.x86_64
kernel-devel-3.10.0-327.el7.x86_64
kernel-tools-libs-3.10.0-327.el7.x86_64
2.2. Desinstale los paquetes kernel-debuginfo y kernel-debuginfo-common-x86_64

incorrectos e instale la versión del paquete que coincida con la versión instalada del
kernel.
[root@servera ~]# yum erase -y kernel-debuginfo kernel-debuginfo-common-x86_64

Removed:
kernel-debuginfo.x86_64 0:3.10.0-327.4.5.el7
kernel-debuginfo-common-x86_64.x86_64 0:3.10.0-327.4.5.el7
Complete!
[root@servera ~]# yum list kernel-debuginfo-$(uname -r) kernel-debuginfo-common-

x86_64-$(uname -r)
Available Packages
kernel-debuginfo.x86_64
3.10.0-327.el7 rhel_debug
kernel-debuginfo-common-x86_64.x86_64
3.10.0-327.el7 rhel_debug
[root@servera ~]# yum install -y kernel-debuginfo-3.10.0-327.el7.x86_64 kernel-

debuginfo-common-x86_64-3.10.0-327.el7.x86_64
RH342-RHEL7.2-es-1-20160321 357

Installed:
kernel-debuginfo.x86_64 0:3.10.0-327.el7 kernel-debuginfo-
common-x86_64.x86_64 0:3.10.0-327.el7
Complete!
3. Compile el script de SystemTap en un módulo de kernel portátil. Almacene los módulos

compilados como /root/nettop.ko en servera.
[root@servera ~]# stap -v -p 4 -m nettop /usr/share/doc/systemtap-client-2.8/

examples/network/nettop.stp
344104virt/162788res/4220shr/158912data kb, in 12
Pass 3: translated to C into "/tmp/stapdQMqAs/nettop_src.c" using
344104virt/163132res/4564shr/158912data kb, in 10usr/30sys/41real
ms.
nettop.ko
Pass 4: compiled C into "nettop.ko" in 3760usr/670sys/4390real ms.

4.1. Verifique el estado del servicio kdump para ver si el servicio está habilitado e iniciado.
Este servicio debe estar en ejecución para que se desencadene el mecanismo de
volcado de error de kernel durante una caída del sistema.
[root@serverb ~]# systemctl is-enabled kdump

disabled
[root@serverb ~]# systemctl is-active kdump
inactive
4.2. Dado que el servicio no está habilitado ni iniciado, habilite e inicie el servicio para
que habilitar los volcados de error de kernel y, luego, verificar el estado del servicio
para asegurarse de que se haya iniciado correctamente.
[root@serverb ~]# systemctl enable kdump

Created symlink from /etc/systemd/system/multi-user.target.wants/kdump.service
to /usr/lib/systemd/system/kdump.service.
[root@serverb ~]# systemctl start kdump
preset: enabled)
SUCCESS)
Feb 10 22:40:27 serverb.lab.example.com systemd[1]: Starting Crash recovery k...

358 RH342-RHEL7.2-es-1-20160321
Solución
5. Configure kdump para que los volcados de error se depositen en el directorio /var/
crash utilizando el algoritmo de compresión lzo y generando todos los tipos de
mensajes.
5.1. Edite /etc/kdump.conf y modifique la entrada core_collector para que se

utilice la compresión lzo y se incluyan todos los tipos de mensajes en el resultado.
Ademas, asegúrese de que solo se incluyan páginas de datos de usuario en el
volcado.
core_collector makedumpfile -l --message-level 31 -d 23
5.2. Reinicie el servicio kdump para que se apliquen los cambios de configuración.
[root@serverb ~]# systemctl restart kdump

preset: enabled)
Active: active (exited) since Tue 2016-02-16 02:48:58 EST; 6s ago
Process: 14158 ExecStop=/usr/bin/kdumpctl stop (code=exited, status=0/SUCCESS)
SUCCESS)
Feb 16 02:48:58 serverb.lab.example.com dracut[16307]: drwxr-xr-x 3 root

root 0 Feb 16 02:48 usr/share/zoneinfo
root 0 Feb 16 02:48 usr/share/zon...erica
Feb 16 02:48:58 serverb.lab.example.com dracut[16307]: -rw-r--r-- 1 root
root 3519 Oct 1 19:53 usr/share/zon..._York
root 0 Feb 16 02:48 var
Feb 16 02:48:58 serverb.lab.example.com dracut[16307]: lrwxrwxrwx 1 root
root 11 Feb 16 02:48 var/lock -> ..../lock
Feb 16 02:48:58 serverb.lab.example.com dracut[16307]: lrwxrwxrwx 1 root
root 6 Feb 16 02:48 var/run -> ../run
Feb 16 02:48:58 serverb.lab.example.com dracut[16307]:
========================================================================
Feb 16 02:48:58 serverb.lab.example.com kdumpctl[14167]: kexec: loaded kdump
kernel
Feb 16 02:48:58 serverb.lab.example.com systemd[1]: Started Crash recovery
kernel arming.
6.1. Habilite todas las funciones SysRq de kernel al establecer el valor dentro del archivo
/proc/sys/kernel/sysrq en 1.
[root@serverb ~]# echo 1 > /proc/sys/kernel/sysrq
6.2. Desencadene una caída del sistema al establecer el valor dentro del archivo /proc/
sysrq-trigger en c.
RH342-RHEL7.2-es-1-20160321 359
[root@serverb ~]# echo c > /proc/sysrq-trigger

servera al buscar la presencia de un nuevo directorio en /var/crash que contenga el
[root@serverb ~]# ll /var/crash

total 0
[root@serverb ~]# ll /var/crash/127.0.0.1-2016-02-10-23\:55\:28/
total 1951732
-r--------. 1 root root 1998532608 Feb 10 23:55 vmcore
[student@workstation ~]$ lab kernel grade
8.2. Reinicie todas sus máquinas para proveer un entorno limpio para los siguientes
ejercicios.
360 RH342-RHEL7.2-es-1-20160321
Resumen
Resumen
• La cantidad de memoria reservada para el kernel de error se puede mostrar con el

comando kdumpctl showmem.
• La cantidad de memoria reservada para el kernel de error se puede personalizar en el

archivo de configuración /etc/default/grub.
• El comportamiento del servicio kdump se configura en /etc/kdump.conf.
• Un volcado de error de kernel se puede configurar para que sea desencadenado por un
proceso de cuelgue de OOM, bloqueo de software y eventos NMI a través de la utilidad
sysctl.
• SystemTap requiere la instalación del paquete kernel-debuginfo.
• La utilidad stap se puede usar para ejecutar y compilar los scripts de SystemTap en
módulos kernel portátiles.
• La membresía del grupo stapusr permite que los usuarios ejecuten los módulos de
instrumentación de SystemTap.
• La membresía del grupo stapdev permite que los usuarios compilen los módulos de
instrumentación de SystemTap.
RH342-RHEL7.2-es-1-20160321 361
362
TRAINING
CAPÍTULO 11
REVISIÓN INTEGRAL DE RED HAT

ENTERPRISE LINUX DIAGNOSTICS
AND TROUBLESHOOTING
Visión general
Meta Practique y demuestre los conocimientos y las habilidades
que aprendió en Red Hat Enterprise Linux Diagnostics and
Troubleshooting.
Objetivos • Revise y recuerde los conocimientos y las habilidades
que aprendió en Red Hat Enterprise Linux Diagnostics
and Troubleshooting.
• Practique y demuestre los conocimientos y las

habilidades que aprendió en Red Hat Enterprise Linux
Diagnostics and Troubleshooting.
Secciones • Revisión integral de Red Hat Enterprise Linux
Diagnostics and Troubleshooting
• Trabajos de laboratorio de revisión integral

Trabajo de laboratorio • Trabajo de laboratorio: Ámsterdam - La aplicación
personalizada no funciona
• Trabajo de laboratorio: Tokio - Problemas para

registrarse en la consola
• Trabajo de laboratorio: París - Problemas de

autenticación
• Trabajo de laboratorio: Londres - Problema en el

servidor web
• Trabajo de laboratorio: Nueva York - Demoras en la red
RH342-RHEL7.2-es-1-20160321 363
Capítulo 11. Revisión integral de Red Hat Enterprise Linux Diagnostics and Troubleshooting
Revisión integral de Red Hat Enterprise Linux

Diagnostics and Troubleshooting
Objetivos
Tras finalizar esta sección, los estudiantes podrán revisar y refrescar conocimientos y
habilidades aprendidos en Red Hat Enterprise Linux Diagnostics and Troubleshooting.
Revisión de Diagnósticos y solución de problemas

de Red Hat Enterprise
Antes de comenzar la revisión integral de este curso, los estudiantes deberían sentirse
cómodos con los temas que se explicaron en cada capítulo.
Los estudiantes pueden consultar las secciones anteriores en el libro de textos para lecturas
complementarias.
Capítulo 1, ¿Qué es la solución de problemas?

Describa una estrategia generalizada para la solución de problemas.
• Identificar un enfoque sistemático para resolver problemas mediante el método científico.
• Recopilar información del sistema para ayudar en la solución de problemas.
• Usar los recursos de Red Hat para ayudar en la solución de problemas.
Capítulo 2, Ser proactivo

Evitar que los pequeños problemas se conviertan en grandes problemas al emplear técnicas
proactivas de administración de sistemas.
• Monitorear las características vitales de los sistemas.
• Configurar sistemas para enviar mensajes de registro a un host centralizado.
• Configurar la administración de ajustes para contribuir a la administración de sistemas de

gran tamaño.
• Implementar el seguimiento de cambios para mantener la homogeneidad de los sistemas.
Capítulo 3, Solución de problemas de arranque

Identificar y resolver problemas que puedan afectar la capacidad de arranque de un sistema.
• Solucionar problemas de arranque en sistemas BIOS tradicionales.
• Solucionar problemas en sistemas UEFI.
• Identificar y resolver errores de servicio que afecten al arranque.
• Recuperar el control de root de un sistema.
Capítulo 4, Identificación de problemas de hardware

Identificar problemas de hardware que puedan afectar el funcionamiento normal de un
sistema.
• Identificar el hardware y los problemas del hardware.
364 RH342-RHEL7.2-es-1-20160321
Revisión de Diagnósticos y solución de problemas de Red Hat Enterprise
• Gestionar módulos de kernel y sus parámetros.
• Identificar y resolver problemas de virtualización.
Capítulo 5, Solución de problemas de almacenamiento

Identificar y solucionar los problemas relacionados con el almacenamiento.
• Describir las funciones de las capas de la stack (pila) de almacenamiento.
• Recuperar sistemas de archivos dañados.
• Recuperar configuraciones de gestión de volúmenes lógicos (LVM) dañadas.
• Recuperar datos de sistemas de archivos cifrados.
• Identificar y solucionar problemas de iSCSI.
Capítulo 6, Solución de problemas de RPM

Identificar y resolver problemas en, y utilizando, el subsistema de gestión de paquetes.
• Resolver problemas de dependencia de la gestión de paquetes manualmente.
• Recuperar una base de datos dañada de Red Hat Package Management (RPM).
• Identificar y restaurar archivos cambiados a través del subsistema de gestión de paquetes.
• Implementar las herramientas de gestión de suscripciones de Red Hat para recibir

actualizaciones.
Capítulo 7, Solución de problemas de red

Identificar y solucionar problemas de conectividad de red.
• Comprobar la conectividad de la red con herramientas estándares.
• Identificar y solucionar problemas de conectividad de red.
• Inspeccionar el tráfico de la red para facilitar la solución de problemas.
Capítulo 8, Solución de problemas de la aplicación

Resolver los problemas de la aplicación.
• Identificar las dependencias de la librería del software de terceros.
• Identificar si una aplicación sufre fugas de memoria.
• Depurar una aplicación con herramientas estándares.
Capítulo 9, Tratamiento de problemas de seguridad

Identificar y solucionar los problemas relacionados con subsistemas de seguridad.
• Identificar y solucionar los problemas relacionados con SELinux.
• Identificar y solucionar problemas en la autorización y autenticación de usuarios.
• Identificar y solucionar los problemas relacionados con la gestión de identidades de LDAP y

Kerberos.
Capítulo 10, Solución de problemas de kernel

Identificar problemas de kernel y ayudar al Soporte de Red Hat a resolver problemas de
kernel.
RH342-RHEL7.2-es-1-20160321 365
• Crear volcados de memoria de kernel para ayudar al Soporte de Red Hat a resolver
problemas de kernel.
• Compilar y ejecutar módulos de SystemTap para ayudar al Soporte de Red Hat a resolver
problemas de kernel.
366 RH342-RHEL7.2-es-1-20160321
Trabajos de laboratorio de revisión integral
Trabajos de laboratorio de revisión integral
Objetivos
Después de completar esta sección, los estudiantes podrán practicar y demostrar
conocimientos y habilidades aprendidos en la Solución de problemas de Red Hat Enterprise
Linux.
Revisiones completas
En los siguientes ejercicios, usted es un administrador de sistemas sénior que trabaja para
una importante empresa internacional. Durante un recorrido reciente de sus principales
oficinas corporativas, se encontró con una variedad de problemas que requerían su
experiencia y sus conocimientos para encontrar una solución.
Los siguientes cinco ejercicios son algunos aspectos destacados de los problema que
descubrió. Algunos de estos ejercicios podrían contener más de un problema, debido a que
los intentos de arreglo anteriores pueden haber dejado las máquinas en un estado no tan
ideal.
Durante estos ejercicios, recuerde utilizar un enfoque estructurado y tomar muchas notas
sobre lo que descubre y cambia.
RH342-RHEL7.2-es-1-20160321 367
Trabajo de laboratorio: Ámsterdam — La

aplicación personalizada no funciona
En este trabajo de laboratorio, resolverá un problema en su sistema servera.
Recursos
Archivos /usr/local/bin/pre-upower-version
Máquinas servera
Resultados
Deberá poder resolver correctamente los problemas de su máquina servera.
Andes de comenzar
Prepare su máquina servera para este ejercicio ejecutando el comando lab amsterdam
setup en su máquina workstation.
[student@workstation ~]$ lab amsterdam setup
Otro administrador del sistema instaló una versión personalizada de la aplicación upower y
no pudo hacerla funcionar. Usted tiene la tarea de hacerla funcionar.
Ejecute los siguientes comandos para confirmar que la aplicación está lista para utilizarse:
[root@servera ~]# /usr/libexec/upowerd --help

[root@servera ~]# upower --version
El primer comando debe producir un mensaje de ayuda útil. El segundo comando debe
mostrar la versión actual de upower.
1. Investigue y proporcione una solución para los problemas que hacen que /usr/
libexec/upowerd --help tenga fallas. Se entiende que una solución será suficiente
hasta que el proveedor proporcione un arreglo más permanente.
2. Investigue, y corrija, el requisito del sistema necesario para que upower --version
funcione. Una vez que se identifica la condición de requisito previo, cree un script de shell
denominado /usr/local/bin/pre-upower-version que la implemente.
3. Evalúe su trabajo ejecutando el comando lab amsterdam grade en su sistema

workstation.
[student@workstation ~]$ lab amsterdam grade
4. Antes de continuar con el próximo ejercicio, reinicie su máquina virtual servera o

[student@workstation ~]$ lab amsterdam reset
368 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, resolverá un problema en su sistema servera.
Recursos
Archivos /usr/local/bin/pre-upower-version
Máquinas servera
Resultados
Deberá poder resolver correctamente los problemas de su máquina servera.
Andes de comenzar
Prepare su máquina servera para este ejercicio ejecutando el comando lab amsterdam
setup en su máquina workstation.
[student@workstation ~]$ lab amsterdam setup
Otro administrador del sistema instaló una versión personalizada de la aplicación upower y
no pudo hacerla funcionar. Usted tiene la tarea de hacerla funcionar.
Ejecute los siguientes comandos para confirmar que la aplicación está lista para utilizarse:

El primer comando debe producir un mensaje de ayuda útil. El segundo comando debe
mostrar la versión actual de upower.
1. Investigue y proporcione una solución para los problemas que hacen que /usr/
libexec/upowerd --help tenga fallas. Se entiende que una solución será suficiente
hasta que el proveedor proporcione un arreglo más permanente.
1.1. Primero, ejecute el comando para ver si se muestran mensajes de error útiles.

/usr/libexec/upowerd: error while loading shared libraries:
libimobiledevice.so.4: cannot open shared object file: No such file
or directory
Una librería compartida, libimobiledevice.so.4, no puede estar resuelta por el

enlazador de tiempo de ejecución.
1.2. Utilice ldd para identificar todas las librerías compartidas que no pueden resolverse
en este momento.
[root@servera ~]# ldd /usr/libexec/upowerd | grep 'not found'

libimobiledevice.so.4 => not found
libplist.so.1 => not found
1.3. Utilice Yum para identificar los paquetes que podrían proporcionar las librerías
compartidas, libimobiledevice.so.4 y libplist.so.1.
RH342-RHEL7.2-es-1-20160321 369
[root@servera ~]# yum whatprovides libimobiledevice.so.4 libplist.so.1

libimobiledevice-1.1.5-6.el7.i686 : Library for connecting to mobile devices
Repo : rhel_dvd
Matched from:
Provides : libimobiledevice.so.4
libplist-1.10-4.el7.i686 : Library for manipulating Apple Binary and XML
: Property Lists
Repo : rhel_dvd
Matched from:
Provides : libplist.so.1
1.4. Instale los paquetes que proporcionarán las librerías compartidas requeridas.
[root@servera ~]# yum -y install libimobiledevice libplist

1.5. Ejecute el comando /usr/libexec/upowerd --help nuevamente. Confirme que

funciona al producir un mensaje de uso útil.

Usage:
upowerd [OPTION...] upower daemon
Help Options:
-h, --help Show help options
Application Options:
--timed-exit Exit after a small delay
--immediate-exit Exit after the engine has loaded
-v, --verbose Show extra debugging information
2. Investigue, y corrija, el requisito del sistema necesario para que upower --version
funcione. Una vez que se identifica la condición de requisito previo, cree un script de shell
denominado /usr/local/bin/pre-upower-version que la implemente.
2.1. Ejecute el comando para ver si se muestran mensajes de error útiles.

Error: connect failed.: Connection refused
Hay un problema de tiempo de ejecución que necesita mayor investigación. Algún

tipo de conexión está fallando, y el mensaje de error no es muy útil.
2.2. Utilice strace para mostrar las llamadas del sistema que el programa está
realizando. Busque las llamadas del sistema que ocurrieron antes de que se imprima
el mensaje de error y tome nota de sus argumentos.
[root@servera ~]# strace upower --version

execve("/usr/bin/upower", ["upower", "--version"], [/* 24 vars */]) = 0
brk(0) = 0x7f03f8d89000
370 RH342-RHEL7.2-es-1-20160321
Solución

0x7f03f7615000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
mmap(NULL, 29146, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f03f760d000
close(3) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(8765),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
dup(2) = 7
fcntl(7, F_GETFL) = 0x8402 (flags O_RDWR|O_APPEND|
O_LARGEFILE)
write(7, "Error: connect failed.: Connecti"..., 43Error: connect failed.:
Connection refused
) = 43
close(7) = 0
munmap(0x7f03f7614000, 4096) = 0
exit_group(1) = ?
La llamada del sistema que falla es la llamada de connect(). Está intentando

conectarse a la dirección IPv4 127.0.0.1, puerto TCP 8765. Esto es lo que hace que
upower --version falle.
2.3. Utilice Yum para instalar el RPM nmap-ncat. Se utilizará para escuchar en el puerto
8765 en servera.
[root@servera ~]# yum -y install nmap-ncat

2.4. Abra otra ventana e inicie sesión en servera. Ejecute nc y haga que escuche el
puerto 8765 en la dirección 127.0.0.1.
[student@servera ~]$ nc -l 127.0.0.1 8765
Se colgará esperando una conexión TCP entrante.
2.5. En la primera ventana, ejecute el comando upower --version nuevamente.

Confirme que funciona.

UPower client version 0.99.2
UPower daemon version 0.99.2
2.6. Cree el programa /usr/local/bin/pre-upower-version para escuchar el

puerto TCP 8765 en 127.0.0.1. Use un editor para crear el archivo para que tenga el
siguiente contenido y facilitar su ejecución.
[root@servera ~]# cat /usr/local/bin/pre-upower-version

#!/bin/bash
ncat -l 127.0.0.1 8765
[root@servera ~]# chmod 755 /usr/local/bin/pre-upower-version
RH342-RHEL7.2-es-1-20160321 371
3. Evalúe su trabajo ejecutando el comando lab amsterdam grade en su sistema

workstation.
[student@workstation ~]$ lab amsterdam grade
4. Antes de continuar con el próximo ejercicio, reinicie su máquina virtual servera o

[student@workstation ~]$ lab amsterdam reset
372 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Tokio — Problemas para registrarse en la consola
Trabajo de laboratorio: Tokio — Problemas

para registrarse en la consola
En este trabajo de laboratorio, resolverá un problema en su sistema serverb.
Recursos
Máquinas • serverb
Resultados
Deberá poder resolver correctamente los problemas de su máquina serverb.
Andes de comenzar
Prepare su máquina serverb para este ejercicio ejecutando el comando lab tokyo setup
en su máquina workstation.
[student@workstation ~]$ lab tokyo setup
Uno de sus usuarios informó problemas al registrarse directamente en la consola de su

máquina serverb como el usuario student con la contraseña student.
El ticket de este problema se asignó a uno de sus administradores junior, quien intentó
solucionar el problema. Desafortunadamente, durante el proceso de “solución”, su máquina
serverb se volvió inaccesible.
Sorprendido por este resultado, su administrador junior no recuerda los pasos que tomó
hasta llegar a este punto.
Investigue el problema y solucione el problema original y el que desencadenó su

administrador junior.
1. Investigue y solucione el caso de la máquina serverb inaccesible.
2. Investigue y solucione el problema de registro original de la consola.
3. Evalúe su trabajo ejecutando el comando lab tokyo grade en su sistema

workstation.
[student@workstation ~]$ lab tokyo grade
4. Si no resolvió el problema correctamente, pero desea continuar con el siguiente ejercicio,

reinicie su sistema serverb.
RH342-RHEL7.2-es-1-20160321 373
Solución
En este trabajo de laboratorio, resolverá un problema en su sistema serverb.
Recursos
Máquinas • serverb
Resultados
Deberá poder resolver correctamente los problemas de su máquina serverb.
Andes de comenzar
Prepare su máquina serverb para este ejercicio ejecutando el comando lab tokyo setup
en su máquina workstation.
[student@workstation ~]$ lab tokyo setup
Uno de sus usuarios informó problemas al registrarse directamente en la consola de su

máquina serverb como el usuario student con la contraseña student.
El ticket de este problema se asignó a uno de sus administradores junior, quien intentó
solucionar el problema. Desafortunadamente, durante el proceso de “solución”, su máquina
serverb se volvió inaccesible.
Sorprendido por este resultado, su administrador junior no recuerda los pasos que tomó
hasta llegar a este punto.
Investigue el problema y solucione el problema original y el que desencadenó su

administrador junior.
1. Investigue y solucione el caso de la máquina serverb inaccesible.
1.1. Compruebe que no se pueda acceder al serverb.
[student@workstation ~]$ ping serverb.lab.example.com
1.2. Abra una consola en serverb.
Parece que serverb está atascado en la pantalla de menú de grub2. Intente iniciar
la entrada predeterminada; si eso no funciona, intente iniciar una entrada de
respaldo.
1.3. ¿Qué error recibió cuando intentó iniciar estas entradas?
error: can't find command `linux64'.

error: you need to load the kernel first.
Solucione este problema temporalmente: Presione e para editar la entrada

predeterminada, cambie linux64 por linux16 y, luego, presione Ctrl+x para
arrancar.
1.4. Intente iniciar sesión como root en la consola con la contraseña redhat.
374 RH342-RHEL7.2-es-1-20160321
Solución
Parece que el problema de registro original aún está presente. Intente iniciar sesión
como root por SSH.
[student@workstation ~]$ ssh root@serverb
Por suerte, SSH aún funciona. Solucione el problema de arranque de manera

permanente al recrear el archivo de configuración grub2.
[root@serverb ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
2. Investigue y solucione el problema de registro original de la consola.
2.1. Intente iniciar sesión en la consola de serverb como student, con la contraseña
student.
Por suerte, el acceso SSH no parece estar afectado.
2.2. Revise /var/log/secure o journalctl en busca de mensajes relevantes.
[root@serverb ~]# journalctl _COMM=login

...
login[1240]: FAILED LOGIN 1 FROM tty1 FOR student, Authentication failure
Este mensaje no indica una contraseña incorrecta, por lo que la falla se debe a otro
elemento.
2.3. ¿Cuál es el archivo que controla la autenticación para el proceso login? Revíselo y
verifique que no tenga ajustes extraños.
/etc/pam.d/login y /etc/pam.d/system-auth. Después de una inspección

breve, aparentan estar bien, pero parece que hubo cambios recientes en /etc/
pam.d/system-auth-ac.
2.4. Utilice authconfig para recrear todos los archivos de configuración.
[root@serverb ~]# authconfig --updateall
2.5. Verifique que el paso anterior haya resuelto el problema al iniciar sesión en la
consola de serverb como student, con la contraseña student.
3. Evalúe su trabajo ejecutando el comando lab tokyo grade en su sistema

workstation.
[student@workstation ~]$ lab tokyo grade
4. Si no resolvió el problema correctamente, pero desea continuar con el siguiente ejercicio,

reinicie su sistema serverb.
RH342-RHEL7.2-es-1-20160321 375
Trabajo de laboratorio: París — Problemas de

autenticación
En este trabajo de laboratorio, resolverá un problema relacionado con la autenticación.
Recursos
• servera
Resultados
Deberá poder diagnosticar y solucionar un problema relacionado con la autenticación.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab paris setup en su
[student@workstation ~]$ lab paris setup
Hace poco, se ha agregado un nuevo servidor, servera, a su dominio de autenticación;

desafortunadamente, este proceso no se completó correctamente. Los usuarios han estado
informando que no pueden ingresar a este sistema. Ha recibido una cuenta de prueba
ldapuser con una contraseña de kerberos.
En la siguiente tabla se enumeran todos los ajustes que se enviaron a la persona que unió
servera a su dominio de autenticación.
Configuración
Servidor LDAP ldap://workstation.lab.example.com
Base de búsqueda dc=lab,dc=example,dc=com
de LDAP
Certificado CA de ftp://workstation.lab.example.com/pub/example-ca.crt
LDAP
Dominio de Kerberos LAB.EXAMPLE.COM
KDC de Kerberos workstation.lab.example.com
Directorios de inicio workstation.lab.example.com:/home/guests/*
de NFSv4
Como con todos los otros sistemas de su organización, el uso de sssd.service es

obligatorio.
1. Reproduzca el problema y tome notas de los mensajes de error.
2. Recopile más información y, luego, formule una hipótesis.
3. Pruebe su hipótesis y, si es correcta, solucione el problema.
376 RH342-RHEL7.2-es-1-20160321
4. Evalúe su trabajo ejecutando el comando lab paris grade de su máquina
workstation.
[student@workstation ~]$ lab paris grade
5. Importante: Limpie su trabajo al reiniciar su workstation y su máquina servera.
RH342-RHEL7.2-es-1-20160321 377
Solución
En este trabajo de laboratorio, resolverá un problema relacionado con la autenticación.
Recursos
• servera
Resultados
Deberá poder diagnosticar y solucionar un problema relacionado con la autenticación.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab paris setup en su
[student@workstation ~]$ lab paris setup
Hace poco, se ha agregado un nuevo servidor, servera, a su dominio de autenticación;

desafortunadamente, este proceso no se completó correctamente. Los usuarios han estado
informando que no pueden ingresar a este sistema. Ha recibido una cuenta de prueba
ldapuser con una contraseña de kerberos.
En la siguiente tabla se enumeran todos los ajustes que se enviaron a la persona que unió
servera a su dominio de autenticación.
Configuración
Servidor LDAP ldap://workstation.lab.example.com
Base de búsqueda dc=lab,dc=example,dc=com
de LDAP
Certificado CA de ftp://workstation.lab.example.com/pub/example-ca.crt
LDAP
Dominio de Kerberos LAB.EXAMPLE.COM
KDC de Kerberos workstation.lab.example.com
Directorios de inicio workstation.lab.example.com:/home/guests/*
de NFSv4
Como con todos los otros sistemas de su organización, el uso de sssd.service es

obligatorio.
1. Reproduzca el problema y tome notas de los mensajes de error.
1.1. Intente iniciar sesión como ldapuser en servera, con la contraseña kerberos, a
través de ssh y en la consola.
1.2. El uso de ssh ldapuser@servera requiere una contraseña, pero falla cuando se
ingresa la contraseña.
1.3. El ingreso directo a la consola proporciona un mensaje de Inicio de sesión

incorrecto directamente después de ingresar el nombre de usuario.
2. Recopile más información y, luego, formule una hipótesis.
378 RH342-RHEL7.2-es-1-20160321
Solución
2.1. Lea los registros relacionados a sshd y login. ¿Qué se dice acerca del usuario
ldapuser?
[root@servera ~]# journalctl _COMM=sshd + _COMM=login
Las entradas para sshd y login enumeran a ldapuser como un usuario no válido.
2.2. Verifique que no haya un usuario llamado ldapuser en servera.
2.3. Use el comando ldapsearch para consultar el servidor LDAP configurado.
[root@servera ~]# ldapsearch -x

ldap_bind: Confidentiality required (13)
additional info: TLS confidentiality required
Este servidor requiere el uso de TLS; inténtelo de nuevo aplicando el uso de TLS.
[root@servera ~]# ldapsearch -x -ZZ

ldap_start_tls: Connect error (-11)
additional info: TLS error -8179:Peer's Certificate issuer is not
recognized.
2.4. Hipótesis: El certificado de CA para el servidor LDAP no está instalado

adecuadamente en servera.
3. Pruebe su hipótesis y, si es correcta, solucione el problema.
3.1. Inspeccione la ubicación para almacenar los certificados de CA OpenLDAP.
[root@servera ~]# ls -l /etc/openldap/cacerts
Este directorio parece estar vacío. Eso explicaría el hecho de no poder verificar el
certificado TLS para nuestro servidor LDAP.
3.2. Descargue el certificado correcto para esa ubicación, luego agregue los hash
requeridos por las herramientas cliente de OpenLDAP.
[root@servera ~]# wget -O /etc/openldap/cacerts/example-ca.crt ftp://

workstation/pub/example-ca.crt
[root@servera ~]# cacertdir_rehash /etc/openldap/cacerts
3.3. Verifique que ldapsearch ahora funcione de la manera esperada.
[root@servera ~]# ldapsearch -x -ZZ

....
dn: uid=ldapuser,ou=People,dc=lab,dc=example,dc=com
....
RH342-RHEL7.2-es-1-20160321 379
3.4. Reinicie sssd.service.
[root@servera ~]# systemctl restart sssd.service
3.5. Verifique que el problema está solucionado con getent.

ldapuser:*:1701:1701:LDAP Test User:/home/guests/ldapuser:/bin/bash
3.6. Reinicie el servicio autofs.service.
[root@servera ~]# systemctl restart autofs.service
3.7. Verifique que ahora puede iniciar sesión como ldapuser con la contraseña
kerberos. Cuando utiliza ssh desde workstation, se usará la autenticación basada
en clave de SSH y, por lo tanto, no se podrá acceder al directorio de inicio para
ldapuser. Pruebe con la autenticación basada en clave deshabilitada o pruébelo en
la consola de servera.
4. Evalúe su trabajo ejecutando el comando lab paris grade de su máquina

workstation.
[student@workstation ~]$ lab paris grade
5. Importante: Limpie su trabajo al reiniciar su workstation y su máquina servera.
380 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Londres — Problema en el servidor web
Trabajo de laboratorio: Londres — Problema

en el servidor web
En este trabajo de laboratorio, resolverá una falla del servicio y un sistema de archivos
dañado.
Recursos
Aplicación http://servera.lab.example.com
Resultados
Deberá poder resolver el error que produce un servicio para iniciarlo y recuperarlo de la
inconsistencia del sistema de archivos.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab london setup en su
[student@workstation ~]$ lab london setup
Después de que un administrador colega decidió fortalecer el servicio httpd en servera,

los usuarios se quejan de que el sitio web que se ejecuta en el servidor ya no está disponible.
Determine y resuelva la falla del servicio. Una vez que determina la fuente del problema,
asegúrese de verificar si el mismo problema está impactando otros componentes del
paquete httpd. Si hay otros componentes del paquete afectados, soluciónelos según
corresponda.
Una vez que el servicio httpd se inicia correctamente, compruebe que el contenido del sitio
web se pueda recuperar a través de http://servera.lab.example.com. Si no se puede
recuperar el contenido del sitio web, analice y resuelva el problema.
1. Constate las quejas del usuario al intentar conectarse al sitio web desde serverb.
2. En servera, busque la causa de la conexión fallida desde el servidor web serverb.
3. En servera, determine si el problema con el archivo /usr/sbin/httpd también

impacta otros archivos del mismo paquete.
4. En servera, solucione el problema con el archivo /usr/sbin/httpd, así como con

otros archivos afectados del mismo paquete.
5. En servera, determine si el servicio httpd ahora puede iniciarse correctamente.
6. En serverb, determine si el archivo index.html ahora puede recuperarse

correctamente desde servera.
7. En servera, determine por qué serverb no puede recuperar index.html.
8. En servera, solucione la incapacidad de acceder al archivo index.html.
RH342-RHEL7.2-es-1-20160321 381
9. En servera, restaure el acceso al archivo index.html.
10. Constate que las quejas del usuario estén resueltas al intentar conectarse al sitio web
desde serverb.
[student@workstation ~]$ lab london grade
[student@workstation ~]$ lab london reset
382 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, resolverá una falla del servicio y un sistema de archivos
dañado.
Recursos
Aplicación http://servera.lab.example.com
Resultados
Deberá poder resolver el error que produce un servicio para iniciarlo y recuperarlo de la
inconsistencia del sistema de archivos.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab london setup en su
[student@workstation ~]$ lab london setup
Después de que un administrador colega decidió fortalecer el servicio httpd en servera,

los usuarios se quejan de que el sitio web que se ejecuta en el servidor ya no está disponible.
Determine y resuelva la falla del servicio. Una vez que determina la fuente del problema,
asegúrese de verificar si el mismo problema está impactando otros componentes del
paquete httpd. Si hay otros componentes del paquete afectados, soluciónelos según
corresponda.
Una vez que el servicio httpd se inicia correctamente, compruebe que el contenido del sitio
web se pueda recuperar a través de http://servera.lab.example.com. Si no se puede
recuperar el contenido del sitio web, analice y resuelva el problema.
1. Constate las quejas del usuario al intentar conectarse al sitio web desde serverb.
1.1. Inicie sesión en serverb como el usuario student.
1.2. Intente recuperar el archivo index.html desde el servidor web que se ejecuta en
servera.
[student@serverb ~]$ curl http://servera.lab.example.com

curl: (7) Failed to connect to fd37:5265:6448:6174::a: Network is unreachable
2. En servera, busque la causa de la conexión fallida desde el servidor web serverb.
2.1. Verifique el estado del servicio httpd.

preset: disabled)
Active: failed (Result: exit-code) since Fri 2016-02-26 00:29:56 EST; 9min
ago
Docs: man:httpd(8)
man:apachectl(8)
FAILURE)
RH342-RHEL7.2-es-1-20160321 383
Process: 1631 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited,

status=203/EXEC)
Main PID: 1631 (code=exited, status=203/EXEC)
Feb 26 00:29:56 servera.lab.example.com systemd[1]: Starting The Apache HTTP

Server...
Feb 26 00:29:56 servera.lab.example.com systemd[1631]: Failed at step EXEC
spawning /usr/sbin/httpd: Permission denied
Feb 26 00:29:56 servera.lab.example.com systemd[1]: httpd.service: main process
exited, code=exited, status=203/EXEC
Feb 26 00:29:56 servera.lab.example.com kill[1633]: kill: cannot find process ""
Feb 26 00:29:56 servera.lab.example.com systemd[1]: httpd.service: control
process exited, code=exited status=1
Feb 26 00:29:56 servera.lab.example.com systemd[1]: Failed to start The Apache
HTTP Server.
Feb 26 00:29:56 servera.lab.example.com systemd[1]: Unit httpd.service entered
failed state.
Feb 26 00:29:56 servera.lab.example.com systemd[1]: httpd.service failed.
2.2. Determine por qué no se puede generar /usr/sbin/httpd.
[root@servera ~]# ls -la /usr/sbin/httpd

-rw-r--r--. 1 root root 507000 Sep 17 09:07 /usr/sbin/httpd
El archivo /usr/sbin/httpd no tiene permiso de ejecución.
3. En servera, determine si el problema con el archivo /usr/sbin/httpd también

impacta otros archivos del mismo paquete.
3.1. Determine el paquete que proporcionó el archivo /usr/sbin/httpd.
[root@servera ~]# rpm -qf /usr/sbin/httpd

httpd-2.4.6-40.el7.x86_64
3.2. Determine los archivos del paquete httpd en los que se han modificado los permisos.
[root@servera ~]# rpm -qV httpd

.M....... /usr/sbin/apachectl
.M....... /usr/sbin/fcgistarter
.M....... /usr/sbin/htcacheclean
.M....... /usr/sbin/httpd
.M....... /usr/sbin/rotatelogs
.M....... /usr/sbin/suexec
4. En servera, solucione el problema con el archivo /usr/sbin/httpd, así como con

otros archivos afectados del mismo paquete.
4.1. Use el comando rpm para restablecer los permisos de los archivos que pertenecen al
paquete httpd con sus ajustes originales.
[root@servera ~]# rpm --setperms httpd
4.2. Compruebe que se hayan solucionado los problemas de permiso.
384 RH342-RHEL7.2-es-1-20160321
Solución
[root@servera ~]# rpm -qV httpd
5. En servera, determine si el servicio httpd ahora puede iniciarse correctamente.
5.1. Reinicie el servicio httpd.
[root@servera ~]# systemctl restart httpd
5.2. Verifique el estado del servicio httpd.

preset: disabled)
Active: active (running) since Fri 2016-02-26 00:56:44 EST; 1s ago
Docs: man:httpd(8)
man:apachectl(8)
SUCCESS)
Main PID: 2563 (httpd)
Status: "Processing requests..."
CGroup: /system.slice/httpd.service
└─2568 /usr/sbin/httpd -DFOREGROUND
Feb 26 00:56:44 servera.lab.example.com systemd[1]: Starting The Apache HTTP

Server...
Feb 26 00:56:44 servera.lab.example.com systemd[1]: Started The Apache HTTP
Server.
6. En serverb, determine si el archivo index.html ahora puede recuperarse

correctamente desde servera.
6.1. Inicie sesión en serverb como el usuario student.
6.2. Intente recuperar el archivo index.html desde el servidor web que se ejecuta en
servera.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/
DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
<title>Test Page for the Apache HTTP Server on Red Hat
Enterprise Linux</title>
Dado que se recibe el contenido de la página de prueba de Apache en lugar del

contenido de la página index.html, algo no funciona bien con el servicio web de
servera.
RH342-RHEL7.2-es-1-20160321 385
7. En servera, determine por qué serverb no puede recuperar index.html.
7.1. Consulte el archivo de registro /var/log/httpd/error_log para los mensajes de

error.
[root@servera ~]$ tail /var/log/httpd/error_log

[Fri Feb 26 00:53:52.185570 2016] [mpm_prefork:notice] [pid 2545] AH00163:
Apache/2.4.6 (Red Hat Enterprise Linux) configured -- re
suming normal operations
[Fri Feb 26 00:53:52.185583 2016] [core:notice] [pid 2545] AH00094: Command
line: '/usr/sbin/httpd -D FOREGROUND'
caught SIGWINCH, shutting down gracefully
[Fri Feb 26 00:56:44.172637 2016] [core:notice] [pid 2563] SELinux policy
enabled; httpd running as context system_u:system_r:httpd
_t:s0
[Fri Feb 26 00:56:44.173107 2016] [suexec:notice] [pid 2563] AH01232: suEXEC
mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Feb 26 00:56:44.178433 2016] [auth_digest:notice] [pid 2563] AH01757:
generating secret for digest authentication ...
[Fri Feb 26 00:56:44.178855 2016] [lbmethod_heartbeat:notice] [pid 2563]
AH02282: No slotmem from mod_heartmonitor
Apache/2.4.6 (Red Hat Enterprise Linux) configured -- re
suming normal operations
[Fri Feb 26 00:56:44.180032 2016] [core:notice] [pid 2563] AH00094: Command
line: '/usr/sbin/httpd -D FOREGROUND'
[Fri Feb 26 00:57:36.538719 2016] [core:error] [pid 2564] (22)Invalid argument:
[client 172.25.250.11:33294] AH00036: access to /in
dex.html failed (filesystem path '/var/www/html/index.html')
Parece que hay un problema para acceder al archivo /var/www/html/index.html.
7.2. Intente enumerar el contenido del directorio /var/www/html.
[root@servera ~]$ ls -la /var/www/html

ls: cannot access /var/www/html/index.html: Invalid argument
total 12
-rw-r--r--. 1 root root 15 Feb 24 23:52 about.html
??????????? ? ? ? ? ? index.html
drwxr-xr-x. 2 root root 6 Feb 24 23:55 lost+found
-rw-r--r--. 1 root root 18 Feb 24 23:53 products.html
-rw-r--r--. 1 root root 17 Feb 24 23:52 support.html
8. En servera, solucione la incapacidad de acceder al archivo index.html.
8.1. Determine cuál es el sistema de archivos utilizado para /var/www/html.
[root@servera ~]$ df -T /var/www/html

Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/vdb1 XFS 98988 5296 93692 6% /var/www/html
8.2. Desmonte el sistema de archivos XFS montado en /var/www/html.
[root@servera ~]$ umount /var/www/html
386 RH342-RHEL7.2-es-1-20160321
Solución
8.3. Ejecute una comprobación del sistema de archivos en el sistema de archivos que
reside en la partición /dev/vdb1.
[root@servera ~]$ xfs_repair -n /dev/vdb1

entry "index.html" in shortform directory 128 references invalid inode 123456789
would have junked entry "index.html" in directory inode 128
8.4. Repare el sistema de archivos XFS que reside en la partición /dev/vdb1.
[root@servera ~]$ xfs_repair /dev/vdb1

- zero log...
entry "index.html" in shortform directory 128 references invalid inode 123456789
junking entry "index.html" in directory inode 128
done
9. En servera, restaure el acceso al archivo index.html.
9.1. Monte el sistema de archivos XFS contenido en la partición /dev/vdb1 en /var/

www/html.
[root@servera ~]$ mount /dev/vdb1 /var/www/html
9.2. Intente enumerar el contenido del directorio /var/www/html.
[root@servera ~]$ ls -la /var/www/html

total 12
-rw-r--r--. 1 root root 15 Feb 24 23:52 about.html
drwxr-xr-x. 2 root root 16 Feb 24 23:55 lost+found
-rw-r--r--. 1 root root 18 Feb 24 23:53 products.html
-rw-r--r--. 1 root root 17 Feb 24 23:52 support.html
9.3. Busque el archivo /var/www/html/index.html que falta.
[root@servera ~]$ ls -la /var/www/html/lost+found

total 4
RH342-RHEL7.2-es-1-20160321 387
-rw-r--r--. 1 root root 14 Feb 24 23:55 137
9.4. Restaure el archivo huérfano index.html en la ubicación /var/www/html.
[root@servera ~]$ mv /var/www/html/lost+found/137 /var/www/html/index.html
10. Constate que las quejas del usuario estén resueltas al intentar conectarse al sitio web
desde serverb.
10.1.Inicie sesión en serverb como el usuario student.
10.2.Intente recuperar el archivo index.html desde el servidor web que se ejecuta en

servera.

<h1>Home</h1>
[student@workstation ~]$ lab london grade
[student@workstation ~]$ lab london reset
388 RH342-RHEL7.2-es-1-20160321
Trabajo de laboratorio: Nueva York — Demoras en la red
Trabajo de laboratorio: Nueva York —

Demoras en la red
En este trabajo de laboratorio, resolverá un problema que involucra pausas de red extrañas.
Recursos
• servera
• serverb
Resultados
Deberá poder resolver un problema de red que involucra demoras aparentemente aleatorias.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab newyork setup en su
[student@workstation ~]$ lab newyork setup
Los usuarios informan pausas aleatorias cuando se conectan a los servicios de red
en su sistema serverb. Hasta hace poco, este sistema estaba bajo el control de otro
administrador, que se ha ido de la empresa. El exadministrador era conocido por desconfiar
de tecnologías nuevas y, contrario a la política de la empresa, nunca tomaba notas o realizaba
registros de su trabajo.
Los servicios httpd y sshd están disponibles para pruebas. Una máquina similar, servera,
no se ve afectada por el problema, pero ese servidor no está ejecutando los servicios httpd.
1. Recree el problema.
2. Recopile información.
3. Formule una hipótesis.
4. Pruebe su hipótesis.
5. Implemente una solución.
6. Evalúe su trabajo ejecutando el comando lab newyork grade de su máquina

workstation.
[student@workstation ~]$ lab newyork grade
7. Limpie sus máquinas ejecutando el comando lab newyork reset de su máquina

workstation. Si eso no funciona, reinicie sus máquinas.
RH342-RHEL7.2-es-1-20160321 389
[student@workstation ~]$ lab newyork reset
390 RH342-RHEL7.2-es-1-20160321
Solución
Solución
En este trabajo de laboratorio, resolverá un problema que involucra pausas de red extrañas.
Recursos
• servera
• serverb
Resultados
Deberá poder resolver un problema de red que involucra demoras aparentemente aleatorias.
Andes de comenzar
Prepare sus sistemas para este ejercicio ejecutando el comando lab newyork setup en su
[student@workstation ~]$ lab newyork setup
Los usuarios informan pausas aleatorias cuando se conectan a los servicios de red
en su sistema serverb. Hasta hace poco, este sistema estaba bajo el control de otro
administrador, que se ha ido de la empresa. El exadministrador era conocido por desconfiar
de tecnologías nuevas y, contrario a la política de la empresa, nunca tomaba notas o realizaba
registros de su trabajo.
Los servicios httpd y sshd están disponibles para pruebas. Una máquina similar, servera,
no se ve afectada por el problema, pero ese servidor no está ejecutando los servicios httpd.
1. Recree el problema.
1.1. Utilice ssh para conectarse a serverb. ¿Qué observó?
[student@workstation ~]$ ssh serverb
Hay una demora de un par de segundos antes de que se lleven a cabo las
conexiones.
1.2. Cronometre esta demora.
[student@workstation ~]$ time ssh serverb echo
real 0m3.190s
user 0m0.015s
sys 0m0.004s
Parece ser que la demora es de aproximadamente tres segundos.
1.3. Cronometre la carga de una página web desde serverb a través de curl.
[student@workstation ~]$ time curl http://serverb.lab.example.com
RH342-RHEL7.2-es-1-20160321 391
La demora es de tres segundos también.
2. Recopile información.
2.1. Ejecute el comando curl en strace para ver si se bloquea en algún lugar.
[student@workstation ~]$ strace curl http://serverb.lab.example.com
Parece ser que las demoras provienen de algunas llamadas del sistema poll, en un
socket creado con la siguiente llamada del sistema:
connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6,

"fd37:5265:6448:6174::b", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) =
-1 EINPROGRESS (Operation now in progress)
2.2. Eche otro vistazo al resultado de strace. ¿El socket se abre correctamente?
No, la conexión falla, y se abre un socket IPv4 regular correctamente después de

eso.
3. Formule una hipótesis.
3.1. Si serverb no tenía una dirección IPv6 en funcionamiento, o una entrada DNS
en funcionamiento para esa dirección, las herramientas como ssh y curl nunca
intentarían conectarse allí.
3.2. Lógicamente, aunque IPv6 esté configurado correctamente para serverb, algún
elemento está bloqueando el acceso.
4. Pruebe su hipótesis.
4.1. Realice una prueba al forzar ssh y curl a conectarse solo a través de IPv4. ¿Todavía
ve la demora?
[student@workstation ~]$ time ssh -4 serverb
[student@workstation ~]$ time curl -4 http://serverb.lab.example.com
La demora desapareció por completo.
5. Implemente una solución.
5.1. Busque reglas de firewall extrañas en serverb.
[root@serverb ~]# firewall-cmd --list-all

....
rich rules:
rule family="ipv6" source address="0::0/0" reject
392 RH342-RHEL7.2-es-1-20160321
Solución
5.2. Elimine la regla ilícita de la configuración del firewall en la memoria y de la

configuración permanente.
[root@serverb ~]# firewall-cmd --remove-rich-rule='rule family="ipv6" source

address="0::0/0" reject'
[root@serverb ~]# firewall-cmd --permanent --remove-rich-rule='rule
family="ipv6" source address="0::0/0" reject'
6. Evalúe su trabajo ejecutando el comando lab newyork grade de su máquina

workstation.
[student@workstation ~]$ lab newyork grade
7. Limpie sus máquinas ejecutando el comando lab newyork reset de su máquina

workstation. Si eso no funciona, reinicie sus máquinas.
[student@workstation ~]$ lab newyork reset
RH342-RHEL7.2-es-1-20160321 393
394

RH342 Red Hat Enterprise Linux Diagnostics and Troubleshooting

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RH342 Red Hat Enterprise Linux Diagnostics and Troubleshooting

Uploaded by

Copyright:

Available Formats

RED HAT®

Capacitación integral y práctica que resuelve los problemas del mundo

Red Hat Enterprise

© 2016 Red Hat, Inc. RH342-RHEL7.2-es-1-20160321

Red Hat Enterprise Linux 7.2 RH342

Autores: Wander Boessenkool, Chen Chang, George Hacker

Copyright © 2016 Red Hat, Inc.

No part of this publication may be stored in a retrieval system, transmitted or

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a registered trademark of Silicon Graphics International Corp. or its subsidiaries

All other trademarks are the property of their respective owners.

Colaboradores: Andrew Blum

1. ¿Qué es la solución de problemas? 1

2. Ser proactivo 33

3. Solución de problemas de arranque 73

4. Identificación de problemas de hardware 103

5. Solución de problemas de almacenamiento 127

Orientación sobre la stack (pila) de almacenamiento de Linux ................................ 128

6. Solución de problemas de RPM 187

7. Solución de problemas de red 225

8. Solución de problemas de la aplicación 271

9. Tratamiento de problemas de seguridad 299

• Recopilar información para ayudar al Soporte de Red Hat en el diagnóstico y la solución de

• Se recomienda una certificación RHCE, o conocimientos equivalentes, para asistir a este

Orientación sobre el entorno del trabajo de

En un aula de aprendizaje en línea de Red Hat, se asignarán a los estudiantes computadoras

Máquinas del aula

Control de sus estaciones

El temporizador funciona como un "switch de seguridad", que disminuye mientras funciona

Selección de idioma por usuario

Estas configuraciones afectan al entorno de escritorio GNOME y todas las aplicaciones,

i=$(grep 'Language=' /var/lib/AccountService/users/${USER} \

[user@host ~]$ LANG=fr_FR.utf8 date

Los comandos subsiguientes se revertirán y utilizarán el idioma de salida predeterminado del

Valores del método de entrada

Valores de idioma predeterminado en todo el

Para configurar el idioma de todo el sistema, ejecute el comando localectl set-locale

[root@host ~]# localectl set-locale LANG=fr_FR.utf8

En GNOME, un usuario administrativo puede cambiar esta configuración en Region &

Referencia de códigos de idioma

• Recopilar información del sistema para ayudar en la

• Usar los recursos de Red Hat para ayudar en la solución

• Recopilación de información (y ejercicio guiado)

• Uso de los recursos de Red Hat (y ejercicio guiado)

Uso del método científico

¿Qué es la solución de problemas?

No solo una solución

Documentar el problema (y la solución) puede ayudar en el futuro cuando otro administrador

Uso del método científico

1. Definir el problema con claridad

El próximo paso es recopilar la mayor cantidad de información (relevante) como sea

Durante este paso, “información relevante” es un término relativamente amplio; la

3. Formular una hipótesis

Después de observar toda la información recopilada, y los síntomas observados/

Si no se llega a la conclusión de que la hipótesis no es válida, se realiza un intento para

También es vital guardar las copias de seguridad de los archivos de configuración

Después de cualquier cambio, deberá evaluar la configuración completa para ver si se

Si las soluciones propuestas no resolvieron el problema, deberá reanudar el proceso

Ejercicio guiado: Uso del método científico

En este trabajo de laboratorio, resolverá un problema de inicio de sesión mediante el método

[student@workstation ~]$ lab scientificmethod setup

1. Comience por reproducir el problema, observando la mayor cantidad de detalles e

[student@workstation ~]$ ssh student@servera

La conexión se cierra inmediatamente, pero la autenticación se efectúa.