Troubleshooting 1 Capítulo 1 Localización y resolución de problemas

1
Troubleshooting
Capítulo 1 Localización y resolución de problemas - Guía General
Nota especial
Este cuaderno utiliza un formato un poco diferente a los cuadernos anteriores en el
currículum de Red Hat Academy. En lugar de ejercicios en cada unidad, los ejercicios
se implementan como parte del programa que será instalado en la máquina del
estudiante. Para mayor información consulte la última lección.
Conceptos clave
•
•
•
Para solucionar problemas de cualquier sistema complejo se debe emplear un
enfoque metódico y razonado.
Cuando hay problemas en el sistema de Linux, el problema suele registrarse en
el error estándar o en algún archivo de registro.
Varios problemas generales suelen presentarse, incluyendo un sistema de
archivos lleno, una carga pesada o propiedades y permisos de archivos.
Localización y resolución de problemas
Es el proceso de rastrear o solucionar un problema ya sea porque esté arreglando un
computador, un carro o cualquier cosa. En términos de hardware y software, un
computador es un sistema. Es decir, es un grupo de componentes que interactúan con
otro en formas predecibles. Si algo sale mal con un componente del sistema tendrá un
efecto en los otros componentes. La clave para la resolución de problemas es entender
lo suficientemente bien el sistema como para volver atrás a través de la cadena de
eventos desde los primeros componentes que observe que están funcionando mal (los
síntomas) hasta el problema original.
Su enfoque general debería verse usualmente así:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Catálogo de síntomas.
Listar los componentes del sistema relacionados con estos síntomas.
Desde la lista de componentes, determinar el posible alcance del problema.
Idear una serie de pruebas para que cada una verifique si cada componente
específico está funcionando correctamente.
Mediante estas pruebas, reducir el campo a uno o dos orígenes posibles.
Suponer que uno de esos dos es el problema y desarrollar una solución posible.
Implementar la solución.
Ensayar la solución. Si falla, tratar de suponer otra posible causa o iniciar de
nuevo el proceso.
Documentar quién solucionó el problema, cuándo se solucionó, cómo se arregló,
qué sintomas tenía y qué lo ocasionó.
Este último paso es vital no sólo porque ahorra tiempo valioso en caso de presentarse un
problema similar, sino porque también da a su equipo un indicio de dónde empezar por
si la "solución" termina causando problemas a otro más tarde.
2
Troubleshooting
Solución de problemas de sistemas de Linux
En esta sección, mencionamos temas que suelen aplicarse a los sistemas de Linux y
Unix y algunos comandos básicos que deben estar al alcance de cualquier administrador
que esté solucionando algún problema.
Archivos de registro (less /var/log/algo)
La complejidad de un sistema de Linux puede intimidar. Se espera que bajo el directorio
/etc haya miles de archivos que estén mal configurados. La interdependencia es
numerosa y suele ser sutil, complicando aún más las cosas.
Afortunadamente, los administradores tienen al menos una herramienta a su favor: el
registro. Precisamente porque el sistema de Linux es complejo, los programas de Linux
tienden a emitir mensajes cada vez que algo anormal o inesperado sucede. Si el proceso
está siendo utilizado de modo interactivo, dichos mensajes suelen aparecer en el flujo de
error estándar. Si los programas están siendo utilizados como demonios, los mensajes
aparecen en el archivo de registro.
Cada vez que un sistema de Linux parece funcionar mal, el primer instinto del
administrador debería ser "revisar el registro". Como resultado, los solucionadores de
problemas exitosos probablemente sabrán lo siguiente.
•
•
•
•
Dónde se registran los servicios. Cada servicio se registra en un archivo de
registro determinado. Si el servicio es lo bastante complejo, tal como el demonio
de impresión cupsd, puede registrarse en un archivo de registro personal. De lo
contrario, /var/log/messages es siempre un buen lugar para empezar. En el
sistema Red Hat Enterprise Linux, el archivo de registro siempre se localizará
bajo el directorio /var/log.
Revisar archivos de registro antes de que las cosas empeoren. Los
administradores deben acostumbrarse a revisar ocasionalmente los archivos de
registro, incluso antes de que comiencen a presentarse errores. De esta manera,
los administradores se familiarizarán con la conducta "normal" del sistema,
ayudando a reconocer más rápido cuando se presente algo anormal.
Producir rápidamente la salida. Muchos de los servicios más complejos
permiten a los administradores especificar la cantidad de información que
registra un servicio. Si un registro determinado está causando problemas,
determine si hay una forma de iniciar el servicio en un modo de depuración o
"debug mode".
Para sistemas servidor/cliente de red, revise el servidor. Como regla, cuando
algo anda mal, los servidores de red no reportan muchos detalles al cliente. La
mejor manera de buscar un reporte de error detallado es en el archivo de registro
del servidor.
El siguiente cuadro resume algunos de los archivos de registro más utilizados por
sistemas vistos en este curso.
3
Troubleshooting
Table 1. Archivos de registro comunes de Red Hat Enterprise Linux
Nombre de archivo
Sistemas pertinentes
/var/log/messages
Mensajes de kernel, scripts de servicio,
demonios generales, autenticación.
/var/log/secure
sshd, autenticación
/var/log/boot.log
scripts de servicio
/var/log/cron
El demonio crond
/var/log/cups/{access,error}_log El demonio cupsd
/var/log/maillog
Servicios de correo electrónico
/var/log/xorg.pantalla.log
El servidor X
Aunque la lista parece larga, tenga en cuenta que el cuadro puede reproducirse
esencialmente con un sólo comando.
[root@station root]# ls /var/log
...
Comando para mantener a la mano: less /var/log/algo
Espacio de disco (df)
A Linux no le gustan los sistemas de archivos llenos. Los procesos están
constantemente escribiendo archivos cortos al sistema de archivos y suprimiéndolos en
muy corto tiempo. Sin la habilidad de escribir ese archivo corto, siempre se presentan
problemas.
Probablemente los directorios que inesperadamente se llenaron son precisamente
aquellos con permisos de escritura para usuarios estándar: /home, /tmp, y /var/tmp.
Además, los archivos de sistema dinámicos, siempre están bajo el directorio /var. Un
trabajo de impresión inesperado para /var/spool/cups, por ejemplo, podría impedir a
los usuarios almacenar temporalmente el correo recibido en /var/spool/mail (o
impedir a un administrador la lectura de los archivos en /var/log).
Comando para mantener a la mano: df
Uso de uptime y top
Los sistemas que tienen una carga pesada, en términos de CPU o uso de memoria
pueden no responder. En teoría, esto no debería causar ningún error, sino algunas
molestias. En la práctica, cualquier acción que tenga un tiempo asociado puede pausar
antes de terminar. Vea si el problema persiste bajo una carga liviana.
4
Troubleshooting
Comandos para mantener a la mano: uptime, top
Propiedades y permisos (ls -l)
Los problemas más comunes en Linux y Unix radican en las propiedades y permisos de
archivos. Recuerde que no todos los demonios se ejecutan como root. Las propiedades y
permisos comunes incluyen lo siguiente.
•
•
•
Un demonio que no tiene permisos de lectura para su propio archivo de
configuración (o ejecuta permisos en el directorio que lo contiene).
Cualquier proceso tratando de ejecutar un subcomando para el cual no tiene
permisos de ejecución.
Cualquier proceso tratando de crear un archivo en un directorio para el cual no
tiene permisos de escritura.
Comando para mantener a la mano: ls -l
Capítulo 2 Cosas para revisar: servidor X
Conceptos clave
•
•
•
•
•
•
Los
servidores
X
dependen de un archivo de configuración
/etc/X11/xorg.conf correctamente configurado.
El arranque X puede estar mal configurado por cualquiera de los siguientes
archivos en un directorio de inicio de usuario: ~/.xinitrc, ~/.xsession, o
~/.Xclients.
Tras el arranque el servidor se registra en error estándar y luego en el archivo
/var/log/xorg.0.log (donde 0 es el número de pantalla del servidor X).
El demonio xfs debe estar ejecutándose para iniciar un servidor X.
Los directorios llenos /tmp o /home pueden evitar que el servidor X inicie.
Cambiar una configuración de red del sistema puede interferir con un servidor X
ejecutándose actualmente.
Localización y solución de problemas X
La mayoría de los problemas X se deben a algún error del archivo xorg.conf. Si usted
no está utilizando ninguna opción de configuración infrecuente del montaje X, entonces
simplemente ejecutando el comando system-config-display creará un nuevo archivo
xorg.conf válido. También considere que los usuarios con archivos personalizados
.xinitrc, .xsession o .Xclients pueden introducir problemas que los afectan a
ellos, pero no a otros usuarios.
Cuando el servidor X inicia, éste imprime en pantalla una gran cantidad de salida de
diagnóstico. Esta salida también es el archivo almacenada en un archivo
/var/log/xorg.0.log (el número 0 se refiere al número de pantallla del servidor X).
Observe a continuación el extracto de un archivo de registro X:
5
Troubleshooting
(II)
(==)
(==)
(II)
(II)
(**)
(**)
(II)
(II)
(II)
(II)
(II)
(II)
(II)
(II)
(==)
(II)
(II)
(II)
(II)
(II)
(II)
(II)
(II)
(II)
(II)
(II)
(**)
(**)
(**)
(**)
(**)
(**)
(**)
(**)
(**)
(**)
(II)
(**)
(**)
(**)
(**)
(**)
(**)
(**)
(**)
(**)
(II)
(II)
(II)
(II)
RADEON(0): Acceleration enabled
RADEON(0): Backing store disabled
RADEON(0): Silken mouse enabled
RADEON(0): Using hardware cursor (scanline 770)
RADEON(0): Largest offscreen area available: 1024 x 3322
Option "dpms"
RADEON(0): DPMS enabled
RADEON(0): X context handle = 0x00000001
RADEON(0): [drm] installed DRM signal handler
RADEON(0): [DRI] installation complete
RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
RADEON(0): [drm] Mapped 32 vertex/indirect buffers
RADEON(0): [drm] dma control initialized, using IRQ 11
RADEON(0): [drm] Initialized kernel agp heap manager, 5111808
RADEON(0): Direct rendering enabled
RandR enabled
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension XKEYBOARD
Initializing built-in extension LBX
Initializing built-in extension XC-APPGROUP
Initializing built-in extension SECURITY
Initializing built-in extension XINERAMA
Initializing built-in extension xorg-Bigfont
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Option "Protocol" "PS/2"
Mouse0: Protocol: "PS/2"
Option "CorePointer"
Mouse0: Core Pointer
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "yes"
Mouse0: Emulate3Buttons, Emulate3Timeout: 50
Option "ZAxisMapping" "4 5"
Mouse0: ZAxisMapping: buttons 4 and 5
Mouse0: Buttons: 5
Keyboard "Keyboard0" handled by legacy driver
Option "Protocol" "IMPS/2"
DevInputMice: Protocol: "IMPS/2"
Option "AlwaysCore"
DevInputMice: always reports core events
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
DevInputMice: ZAxisMapping: buttons 4 and 5
DevInputMice: Buttons: 5
XINPUT: Adding extended input device "DevInputMice" (type: MOUSE)
XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
Mouse0: ps2EnableDataReporting: succeeded
DevInputMice: ps2EnableDataReporting: succeeded
¡No se asuste! No necesita saber todo lo que esto significa. De hecho, X facilita recoger
las entradas de registro de una falla. Observe cómo cada línea en el extracto inicia con
un conjunto de dos caracteres en paréntesis. Una clave con el significado de cada una de
6
Troubleshooting
estas combinaciones de caracteres siempre aparece cerca del la parte superior de la
salida de X:
Marcadores: (--) sondeado, (**) del archivo de configuración, (==)
configuración predeterminada,
(++) de la línea de comandos, (!!) anuncio, (II) informativo,
(WW) advertencia, (EE) error, (NI) no implementado, (??) desconocido.
(==) archivo de registro: "/var/log/xorg.0.log", Hora: Martes Mayo 4
18:11:28 2004
(==) Usando el archivo de configuración: "/etc/X11/xorg.conf"
Al utilizar la clave usted puede escudriñar a través de las entradas de registro y
rápidamente hallar cuáles describen un problema real. Los extractos anteriores son de
un inicio normal y por lo tanto no hay nada que cause alarma. Las entradas (**) son
solamente líneas que están siendo leídas del archivo de configuración y todas las
entradas (II) son mensajes del servidor X que son puramente informativas y no indican
ningún problema. Como verá en los siguientes ejemplos, las líneas (WW) y (EE) son los
mensajes que usted no debe perder de vista, ya que estos representan advertencias y
errores, respectivamente.
Abandone el nivel de ejecución 5
Mientras depura los problemas del servidor X, tener a init tratando persistentemente de
iniciar servidores X en el segundo plano es molesto como mucho y propenso a error en
el peor de los casos. Como regla general, abandone el nivel de ejecución 5 mientras
depura problemas de X e inicie manualmente el servidor X (con el comando startx, por
ejemplo).
Problemas comunes del servidor X
El servicio xfs no está ejecutando
El servidor X depende del demonio xfs para información de fuente, la cual en Red Hat
Enterprise Linux es administrada por el servicio xfs. Si este servicio está inhabilitado, el
servidor X no podrá iniciar, quejándose porque no encuentra la información de fuente.
Sistemas de archivos llenos /tmp o /home
En la lección anterior identificamos los sistemas de archivos llenos como una fuente
común de problemas. Cuando arranque una máquina de Red Hat Enterprise Linux, la
primera víctima evidente de un directorio /tmp lleno es el servidor X. (Una de las
primera víctimas no evidentes es el demonio xfs, el cual causa la primera víctima
evidente). Un directorio de inicio lleno también ocasionará problemas.
Cambio de configuraciones de red
Recuerde que el servidor X es una red consciente por lo tanto, el cambio de la
configuración de red (particularmente el nombre de host de una máquina) puede
7
Troubleshooting
ocasionar problemas. El primer síntoma es un servidor X que continúa ejecutándose, sin
que se inicie ningún cliente. (Después de cambiar el nombre de host de la máquina, el
servidor X puede tratar solicitudes de nuevo cliente como si llegaran de un host
"diferente" y así hacer cumplir los requisitos de autenticación de una manera más
estricta. Como resultado, cualquier mensaje de error por lo general se relacionará con la
autenticación).
La forma más fácil de resolver este problema es simplemente saliendo y volviendo a
entrar, de este modo, reiniciando el servidor X.
Ejemplos
Localización y solución de problemas X cuando el servidor de fuente X no está
ejecutando
Con el fin de que X visualice texto, debe tener acceso a la biblioteca de fuente. Los
servidores X modernos obtienen toda la información de fuente desde el servidor de
fuente X (xfs). Si un xfs no está disponible, X fallará y algo como lo siguiente se hallará
en su salida y archivo de registro:
Could not init font path element unix/:7100, removing from list!
Fatal server error:
could not open default font 'fixed'
Primero, observe que no hay líneas (EE) útiles para guiarnos en este ejemplo. Sin
embargo, se debe deducir fácilmente que cualquier línea comenzando por "Fatal server
error:" (error fatal) no es nada bueno. La siguiente línea: "could not open default font
'fixed'", se lee no se pudo abrir la fuente predeterminada establecida". "fixed" es el
nombre de una fuente que X intenta recuperar del servidor de fuente. Como no pudo
hacerlo, el servidor falló.
Ahora observe la primera línea: "Could not init font path element unix/:7100, removing
from list!". (¡No se puede iniciar el elemento de fuente de ruta Unix/:7100, suprimiendo
de la lista!). "Unix/:7000" se refiere al socket de unix, el cual es un componente del
sistema operativo utilizado entre procesos de comunicación. 7000 denota la ubicación
predeterminada donde xfs escucha conexiones. Evidentemente, xfs no está escuchando
donde se supone que debe estar. La única forma de arreglar esto es determinar el porqué
xfs no está ejecutándose y corregirlo.
Esta ubicación se puede especificar (incluso para un puerto de escucha tcp o udp a
través de la red) al establecer la variable FontPath en /etc/X11/xorg.conf por lo que
es posible que la variable se configuró incorrectamente. Puesto que "unix/:7000" es el
valor predeterminado esto parece poco probable, pero una consulta rápida al
administrador de red debe responder con autoridad. Supongamos que el xfs
sencillamente no está funcionando. El siguiente comando probaría la hipótesis.
[root@station root]# service xfs status
8
Troubleshooting
xfs is stopped
Tratemos de corregir el problema iniciando xfs asegurándonos que éste se reinicie tras
el arranque:
[root@station root]# service xfs start
Starting xfs:
[root@station root]# chkconfig xfs on
[root@station root]# chkconfig --list xfs
xfs
0:off
1:off
2:on
3:on
[
4:on
5:on
OK
]
6:off
Si el sistema no es un servidor de producción, podría reiniciarlo sólo para estar seguro.
Capítulo 3 Cosas que se deben revisar: red
Conceptos clave
•
•
•
Un aspecto importante de la localización y resolución de problemas de
configuración de red es identificar el alcance del problema. ¿Está el problema
afectando una aplicación?, ¿una máquina?, ¿la red local? o ¿las redes IP
externas?
Las utilidades de diagnóstico clave para recordar son ifconfig, ping, route, host,
y tcpdump.
Los archivos de configuración clave para tener en cuenta son
/etc/sysconfig/network,
/etc/sysconfig/network-scripts/ifcfgifname, /etc/resolv.conf, y /etc/hosts.
Localización y solución de problemas de red
La localización y resolución de problemas de red pueden ser lo que más consume
tiempo, debido a que hay muchos componentes para tratar. Por consiguiente, es muy
importante determinar temprano el alcance del problema. Las siguientes preguntas
pueden ayudar a limitar dicho alcance.
1.
2.
3.
4.
5.
¿El problema está restringido a una aplicación?
¿El problema está restringido a una máquina?
¿Se han afectado todas las máquinas en la subred?
¿Se han afectado todas las máquinas en la red?
Si es un problema de conectividad, ¿se aplica a todos los destinos o sólo a uno?
Incluso si el orden exacto en el que se revisan estos campos difiere, tener un
procedimiento que vaya a través de la lista anterior y contestar si o no a la pregunta
ayudará a reducir los componentes del sistema que ameritan la revisión. Por ejemplo, si
el problema del que se está quejando el usuario parece ser únicamente en su máquina (el
usuario no puede conectarse con www.redhat.com pero el vecino sí) entonces, no es
necesario afectar a todo el grupo. Por el contrario, si el problema parece ser de mucha
gente, entonces no hay necesidad de chequear la configuración de red, la instalación
NIC u otros componentes que únicamente afectan a un sistema específico. A
9
Troubleshooting
continuación presentamos una lista de campos del problema y algunos sitios comunes
dónde buscar las causas.
Problemas específicos de aplicación
Varía dependiendo de la apariencia de la aplicación para reparar cualquier cosa del
archivo(s) de registro y/o preferencias de aplicación.
Aspectos específicos de máquina
•
•
•
•
•
¿Está la interfaz configurada correctamente?
¿Está el DNS configurado correctamente?
¿Está la gateway por defecto configurada correctamente?
¿Está el cable conectando bien el sistema a la pared?
¿Está el puerto en el hub o interruptor dentro de la máquina bien conectado?
Red específica de IP local
Si todas las máquinas en una subred tienen problemas pero el resto de su red no está
afectada, entonces hay sólo unas pocas cosas que pueden estar en cuestión:
•
•
•
¿Está el interruptor en el cual está conectada la subred, configurado
correctamente?
¿Está su enrutador de red configurado correctamente?
¿Podría el cortafuegos de su compañía estar bloqueando el acceso?
Red específica de IP externa
Si la red entera tiene problemas, las causas posibles incluyen todas las causas listadas
bajo problemas específicos de subred como también:
•
•
¿La ISP de su compañía tiene problemas?
¿Falló un servicio vital, tal como el servidor DNS de red?
Destino específico
Si el problema parece ser solamente con un destino específico (todos los usuarios
pueden acceder a foo.com, pero no a bar.com), probablemente se debe a un problema
con la red asociada a ese servidor. Las herramientas como traceroute sirven para
diagnosticar dónde se rompe la comunicación y confirmar esta teoría. Cuando el
problema es con la red de alguien más, hay muy poco que hacer, solamente tratar de
notificar a los administradores pertinentes y esperar. Si un destino particular no está
disponible, pero no parece que haya ningún problema con el destino (imagine que un
colega utilizando otro ISP puede acceder bar.com, aunque nadie en su red puede), el
cortafuegos o el direccionamiento en su red podría ser la cuestión.
Diagnóstico de red y utilidades de configuración
10
Troubleshooting
A continuación presentamos una síntesis de la mayoría de las herramientas de
diagnostico de red incluidas en Red Hat Enterprise Linux. Estas y otras se examinan a
fondo en el capítulo 5 del cuaderno 6.
•
•
•
•
•
Para probar la conectividad entre dos máquinas, utilice ping o traceroute.
Para ver la configuración de interfaz de red de sistema, utilice ifconfig.
Para ver el cuadro de direccionamiento, utilice route.
Para probar resolución dns, utilice host.
Para analizar tráfico de red, utilice tcpdump o ethereal.
También es importante recordar las herramientas y archivos utilizados para establecer la
configuración de red del sistema de Red Hat Enterprise Linux cuando localice y
resuelva problemas de red:
•
La
información
de
configuración
de
interfaz
es
almacenada
en
/etc/sysconfig/network-scripts/ifcfg-*.
•
•
•
•
Las configuraciones de red global como la gateway predeterminada se
almacenan en /etc/sysconfig/network.
Las resoluciones dns estáticas se listan en /etc/hosts y el servidor de nombre
para su máquina a utilizar se especifica en /etc/resolv.conf.
Las interfaces se pueden subir o bajar con ifup y ifdown.
Todas las interfaces pueden ser recargadas simultáneamente con service
network restart.
Ejemplos de localización y solución de problemas de red
Recuerde que el capítulo 5, "Utilidades de diagnóstico de red", del cuaderno 6,
"Configuración de red", proporcionó muchos ejemplos de resolución de problemas de
red, los cuales probablemente valen la pena repasar en este momento.
Resolución de problemas de configuración de direccionamiento
Suponga que usted es el administrador de una red que está configurada según las
siguientes especificaciones:
•
•
•
•
Todas las máquinas están configuradas con DHCP.
Todas las máquinas están en la red 192.168.0.X (192.168.0.0/255.255.255.0).
El servidor DNS está en 192.168.0.200.
La gateway predeterminada está en 192.168.0.254.
Un usuario se queja que no puede entrar a http://www.redhat.com con su navegador de
red. Su tarea es determinar la causa del problema y luego resolverlo.
Su primer paso debe ser establecer el alcance del problema. ¿Podría ser el problema
únicamente con la red de redhat.com? Se puede ensayar algo sencillo para averiguarlo:
trate de visitar otro sitio. Suponga que el intento de acceder a http://www.linux.org falla.
11
Troubleshooting
Ahora podemos suponer que el problema no es sólo de la red de Red Hat y que puede
haber un error de configuración local.
Por lo tanto, el problema quizás está afectando toda la red. Para probar esta teoría podría
intentar acceder http://www.redhat.com desde otra máquina. Si su intento tiene éxito,
entonces el problema está en toda la red. Si no, entonces el problema está afectando un
sólo sistema. Si éste fuera el caso se eliminaría una gran cantidad de alcance.
Hasta ahora hemos hecho todas nuestras pruebas con el navegador de red. ¿Qué tal si el
problema es específico de la aplicación? Quizás, por ejemplo, este sistema esté
utilizando un proxy de web mal configurado, haciendo que únicamente el navegador de
red funcione incorrectamente. Podemos determinar si éste es el caso o no utilizando otra
herramienta para probar la conectividad. La herramienta más sencilla para realizar dicha
prueba es el comando ping. Las herramientas más sencillas son la mejor elección para
la localización y resolución de problemas debido a que su simplicidad significa que
menos cosas puede salir mal. Sin embargo, se advierte que muchos sitios en Internet no
responden al comando ping por razones de seguridad. Siempre es bueno saber un poco
acerca de los sitios que aceptan ping. Dichos sitios incluyen www.yahoo.com y
www.google.com. (Sin embargo, tenga cuidado, porque algunos sitios incluyendo
www.redhat.com, no retornarán un ping incluso cuando la red local esté trabajando).
Tratemos de hacer ping en Google.
[user@station user]$ ping www.google.com
ping: unknown host www.google.com
El resultado de este comando ping no sólo ha demostrado que el problema no es una
aplicación específica, sino que nos ha dado la clave de la raíz del problema. Si Linux no
puede determinar la dirección IP para www.google.com ("unknown host"), debe haber
algo interfiriendo con DNS. Observemos las configuraciones DNS del usuario:
[user@station user]$ cat /etc/resolv.conf
nameserver 192.168.0.200
El archivo resolv.conf parece estar configurado normalmente. Por lo tanto, ¿el
problema reside entre la máquina y el servidor DNS? Probemos la conectividad:
[user@station user]$ ping 192.168.0.200
connect: Network is unreachable
Primero, observe que este error es diferente al que encontró cuando trató de comprobar
la conexión con www.google.com. Esto se debe a que aquí estamos omitiendo DNS al
comprobar la conexión de la IP. Esto nos acerca un paso más a la causa de root y en este
caso también ofrece una gran ayuda. El error de "Network unreachable" (red
inalcanzable) significa que usted le ha pedido a la máquina contactar una red que no
sabe cómo acceder. Esto no debe suceder nunca debido a que el sistema debe tener
siempre una configuración de "gateway predeterminada"que señale a un enrutador todo
el tráfico destinado a donde una red desconocida debería ir. Si usted ve un error de
"Network is unreachable" entonces probablemente hay alguna falla con su
12
Troubleshooting
configuración de gateway predeterminada, la cual es provista por DCHP. Observemos
las configuraciones de usuario:
[user@station user]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.0.6
NETMASK=255.255.255.0
ONBOOT=yes
[user@station user]$ cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=station6.mynetwork.com
GATEWAY=192.168.10.254
Hay dos cosas extrañas aquí. Primero, se supone que las estaciones en esta red están
utilizando DHCP para configuración, pero este usuario tiene configurada su estación de
modo estático. No solamente eso, sino que ha cometido un error. Observando de cerca
la configuración de GATEWAY en /etc/sysconfig/network. Esta gateway
predeterminada de usuario se ha configurado incorrectamente a 192.168.10.254 en lugar
de 192.168.0.254. Puesto que la máquina no tiene interfaces en la red 192.168.10.X
rehusa crear la ruta por defecto en la gateway 192.168.10.254. Sin una gateway por
defecto el sistema queda imposibilitado para comunicarse con las redes a las que no está
directamente conectado. Una revisión sencilla de la tabla de direccionamiento puede
confirmar esto:
[user@station user]$ route -n
Kernel IP routing table
Destination
Gateway
Use Iface
192.168.2.0
0.0.0.0
0 eth0
127.0.0.0
0.0.0.0
0 lo
Genmask
Flags Metric Ref
255.255.255.0
U
0
0
255.0.0.0
U
0
0
Ahora está seguro de que no hay una gateway por defecto (si estuviera allí estaría
listada con un destino de "0.0.0.0") para esta máquina debido a que el usuario definió
una gateway inválida. La solución a este problema es sencilla: reconfigure el sistema
para utilizar DHCP, ejecute y reprenda al usuario por experimentar con las
configuraciones (en gran medida DHCP) que fueron puestas allí por ¡alguna buena
razón!
Capítulo 4 Cosas para revisar: arranque
Conceptos clave
•
•
Para la resolución de problemas en un sistema de no arranque, es vital
diagnosticar la etapa en la que se produce el problema.
Para los sistemas que se obtienen mediante el inicio del proceso /sbin/init,
GRUB puede servir para pasar parámetros de arranque de kernel los cuales
hacen que /sbin/init interrumpa el proceso de arranque en las primeras etapas.
13
Troubleshooting
•
•
Pasar el parámetro de arranque de kernel emergency hace que init solicite al
usuario una contraseña y si tiene éxito, lleva al usuario a una shell de root, sin
ejecutarrc.sysinit.
Pasar el parámetro de arranque de kernel 1 hace que init, ejecute rc.sysinit, pero
luego después de entrar en el nivel de ejecución 1, lleva al administrador al
interior de una shell de root sin pedir una contraseña de root.
Localización y solución de problemas del proceso de arranque
Para solucionar problemas del proceso de arranque es vital recordar el proceso por el
cual el sistema arranca.
1. BIOS
a. El BIOS del computador carga la primera etapa del cargador de arranque
desde el registro de arranque maestro (MBR) en uno de los
controladores.
2. Gestor de arranque GRUB
a. El gestor de arranque de primera etapa accede a su partición root y carga
el gestor de arranque de segunda etapa.
b. El gestor de arranque de segunda etapa presenta un menú de todos los
kernel disponibles.
c. Cuando el usuario elige el kernel, el gestor de arranque de segunda etapa
descomprime el ramdisk inicial de selección (initrd) en RAM y carga el
kernel de selección con la línea de comandos del kernel especificado.
3. Kernel
a. Mediante bibliotecas y controladores desde el initrd donde sea necesario,
el kernel detecta dispositivos de bajo nivel tales como pci bus, cpu y
discos duros.
b. El kernel monta la partición root de sólo lectura y ejecuta el primer
proceso (por lo general /sbin/init).
4. /sbin/init
a. El proceso init lee /etc/inittab y (por defecto) ejecuta
/etc/rc.d/rc.sysinit.
b. El script de arranque /etc/rc.d/rc.sysinit inicializa RAID, LVM y cuotas,
monta las otras particiones en /etc/fstab, vuelve a montar la partición
root de lectura-escritura y hace otras tareas asociadas con alistar el
sistema para servicios de host.
c. Cuando rc.sysinit termina de ejecutar, init revisa el nivel de ejecución
por defecto en inittab y utiliza el script /etc/rc.d/rc para iniciar todos
los servicios "S" en ese directorio de nivel de ejecución
(/etc/rc.d/rc3.d para nivel de ejecución 3, por ejemplo).
d. Por último, cuando rc termina de ejecutar init, inicia 6 consolas virtuales
y un gestor de pantalla X (si el sistema está en nivel de ejecución 5) y
solicita al usuario que inicie sesión.
Aunque este proceso puede parecer complicado, si usted sabe lo que busca, es fácil
decir dónde se inicia y se detiene cada parte. Mientras el kernel carga todo lo que usted
14
Troubleshooting
ve es texto gris en negro. Cuando rc.sysinit ejecuta, usted comienza a ver estados de
actualizaciones verdes "[ OK ]" (como también el rojo en ocasiones "[ FAILED ]") al
final de cada línea. En un cierto momento el mensaje visualiza: "Entering noninteractive startup". Esto señala la transición desde rc.sysinit hasta rc. Notará en este
momento que los servicios han cambiado de los componentes de nivel inferior como
RAID, LVM y cuotas, a servicios de nivel superior como httpd, sendmail y nfs.
Saber dónde se presenta el problema en la secuencia de arranque, puede ser muy útil en
el seguimiento de la causa de root. Por ejemplo, si el problema se presenta antes de que
rc.sysinit logre ejecutar, sabemos de inmediato que no necesitamos revisar los servicios
o incluso las particiones además de la partición root porque ellos se actualizan hasta
después de que rc.sysinit termine.
Diagnóstico y solución de problemas de niveles de ejecución
Cuando el problema es tan grave que no permite arrancar el sistema o iniciar sesión a
los usuarios, hay dos niveles de ejecución muy importantes que pueden ayudar. Estos
son llamados "modo monousuario" y "modo de emergencia".
Modo de emergencia
En modo de emergencia, el proceso de arranque es bastante simplificado. Una vez el
kernel es cargado, se le solicita al usuario su contraseña de root. Si la contraseña es
correcta, se crea una shell root y se deja al usuario hacer el resto. Debido a que
rc.sysinit no ejecuta, no monta ninguna partición aparte de la partición root y no inicia
ningún servicio de nivel inferior. Como rc no ejecuta, no se inicia servicios de nivel
superior. Evidentemente, este no es un nivel de ejecución de uso diario. Sin embargo,
como omite tanto del proceso de arranque, hay sólo unas pocas cosas para entrar en el
modo de emergencia:
•
•
•
•
•
•
•
Debe haber un gestor de arranque presente para cargar el kernel.
Debe haber un kernel presente para cargar.
La partición root debe ser montable.
El archivo /etc/passwd debe estar intacto.
El comando /sbin/sulogin (y sus bibliotecas asociadas) deben estar disponibles
para solicitar la contraseña.
El usuario debe tener la contraseña correcta.
Debe haber una shell de trabajo para el usuario autenticado.
Comparado con el número de elementos implicados en un arranque normal, ésta es una
lista relativamente corta. Si usted puede entrar un modo de emergencia, entonces sabrá
que ninguno de estos es el culpable y puede comenzar a resolver problemas de otros
elementos del sistema (probablemente iniciar con rc.sysinit y rc). Si no puede, entonces
ha reducido significativamente el campo de su investigación.
El modo de emergencia es introducido al pasar argumentos al kernel a través de su
gestor de arranque. Cuando el menú de GRUB aparece, elija el kernel que desea
15
Troubleshooting
arrancar y presione "a" para agregar a la línea de comando de kernel. Agregue un nuevo
argumento, "emergency", y presione enter para arrancar.
(También recuerde que init por sí mismo puede ser omitido al pasar el parámetro de
arranque de kernel init=/bin/sh - no root password needed!)
Modo monousuario
En modo monousuario, el sistema carga el kernel, ejecuta rc.sysinit y luego envía al
usuario a una shell de root, omitiendo toda la autenticación. Dependiendo de cómo es
llamado, el modo monousuario también puede ejecutar scripts de inicialización en el
directorio /etc/rc.d/rc1.d/ (más adelante ampliaremos este tema).
El modo monousuario puede ser muy útil en el caso de que la contraseña de root se
pierda, el archivo passwd se dañe o suceda otra cosa que impida al usuario iniciar
sesión. Puede utilizarse también para omitir los servicios de nivel superior como
apache, sendmail y nfs.
El modo monousuario se introduce de forma similar al modo de emergencia, a través
del gestor de arranque. En el menú de GRUB, seleccione el kernel que desea arrancar y
presione "a" para añadir argumentos de kernel. Si añade el número "1", entonces su
sistema entrará en modo monousuario y ejecutará los scripts de inicialización en
/etc/rc.d/rc1.d. Si usted añade la letra "s" (o "S") entonces su sistema entrará en
modo monousuario y no se iniciarán servicios de nivel superior.
Tenga en cuenta que, como el modo monousuario permite el control del sistema sin
requerir contraseña, se pueden presentar serios problemas de seguridad a menos que se
tenga la precaución adecuada. El acceso físico a máquinas sensibles debe restringirse a
sólo aquellos que lo necesiten y el gestor de arranque siempre debe tener contraseña
protegida. Recuerde que proteger a GRUB con una contraseña no evita que otros
sistemas inicien normalmente, sólo evita que usuarios no autorizados pasen argumentos
de kernel adicionales.
Con el fin de cargar, el modo monousuario requiere todo lo que el modo de emergencia
hace (kernel, shell, etc) a excepción del archivo leíble passwd y del ejecutable sulogin.
Comparación de niveles de ejecución especial
Puede aprender mucho sobre el problema que se presenta en su sistema al ver cuáles de
estos niveles de ejecución especiales se pueden introducir. Por ejemplo, si puede
introducir un modo monousuario pero no un modo de emergencia, es casi seguro que el
problema tenga que ver con un componente de su mecanismo de autenticación del
sistema. Si usted puede especificar el modo emergencia, pero no el modo monousuario,
el problema probablemente está en rc.sysinit o algo que éste llame, porque rc.sysinit
ejecuta en modo monousuario, pero no en modo de emergencia. Si usted no puede
arrancar en ningún nivel de ejecución, el problema debe radicar en algo que tengan en
común: el gestor de arranque, la partición de root, el kernel o la shell.
16
Troubleshooting
Ejemplos
Recobrar desde una contraseña de root olvidada
El administrador instaló una máquina que fue configurada en un apuro y luego olvidada.
Tres semanas más tarde, al arrancar la máquina, el administrador se da cuenta que no
tiene idea para qué estableció la contraseña.
El administrador reinicia rápidamente con CONTROL-ALT-DELETE y en el menú
de GRUB presiona a (para "añadir"). GRUB responde con el siguiente aviso, en el que
el administrador añade un "1" y presiona ENTER.
grub append> ro root=LABEL=/ 1
El sistema procede a cargar el kernel, inicia /sbin/init, ejecuta /etc/rc.d/rc.sysinit, y
después de entrar al nivel de ejecución 1, lleva al administrador a una shell de root. El
administrador establece la contraseña de root a un valor conocido y continúa el proceso
cambiándose al nivel de ejecución 5.
sh-2.05b# passwd
Changing password for user root.
New password: *******
Retype new password: ******
passwd: all authentication tokens updated successfully.
sh-2.05b# init 5
Capítulo 5 Recuperar sistemas que utilizan el entorno de rescate
Conceptos clave
•
•
•
•
•
•
Cuando un sistema de no-arranque no puede hallar el gestor de arranque ni la
imagen de kernel apropiada o no puede montar el sistema de archivos de root, se
requiere un medio de arranque alterno.
Un disquete de arranque puede ser creado con el comando mkbootdisk. El
disquete de arranque contiene un gestor de arranque y una imagen de kernel,
pero hace referencia a la partición root del disco duro.
El entorno de rescate de Red Hat Enterprise Linux se puede iniciar desde el CD
# 1 de la distribución de Red Hat Enterprise Linux. El entorno de rescate se
especifica añadiendo el parámetro de arranque rescue a la línea de comandos
del gestor de arranque del instalador.
El entorno de rescate utiliza su propia imagen de sistema de archivos root,
montado como un disco RAM. De esta manera, se puede iniciar una shell de
rescate sin nunca haber tocado el disco duro de un sistema.
Después de arrancar, el entorno de rescate de Red Hat Enterprise intenta
reconstruir el sistema del disco duro bajo el punto de montaje /mnt/sysimage.
Si todo sale bien, al iniciar un cambio de shell de root (con /mnt/sysimage
como el nuevo directorio de root) se produce un entorno muy parecido a un
sistema de arranque normal.
17
Troubleshooting
Los peores casos
Como se ilustró en la lección anterior, el gestor de arranque GRUB es una herramienta
muy útil para resolver problemas en un sistema de no-arranque. La mayoría de
problemas se pueden resolver con sólo reiniciar la máquina y modificar la configuración
de GRUB sobre la marcha. Infortunadamente, hay tres situaciones en las que GRUB no
es útil.
•
•
•
El gestor de arranque está dañado o falta. Naturalmente, cuando GRUB
mismo está mal instalado, dañado, o perdido, éste no se puede utilizar para
solucionar el problema.
El kernel está dañado o perdido. La primera tarea del gestor de arranque es
hallar y cargar el kernel. Si la única imagen de kernel disponible
(/boot/vmlinuz-versión) o alguno de sus archivos de soporte como por
ejemplo, una imagen de disco RAM (/boot/initrd-versión.img), están
perdidos o dañados, entonces GRUB no será útil.
La partición root es inutilizable. Si la partición root está dañada hasta el punto
de que no puede ser montada por el kernel, GRUB no es útil.
En estas situaciones, un administrador necesita recurrir a otros medios de arranque para
iniciar el sistema. Afortunadamente, hay dos formas de ayuda disponibles.
Disquetes de arranque
Un administrador puede crear un disquete de arranque con el comando mkbootdisk.
Cuando es llamado con una versión de kernel como su único argumento (obligatorio),
éste crea un disquete que puede ser utilizado para arrancar el sistema.
[root@station root]# mkbootdisk 2.4.21-4.EL
Insert a disk in /dev/fd0. Any information on the disk will be lost.
Press <Enter> to continue or ^C to abort:
20+0 records in
20+0 records out
Recordando el comando uname, la siguiente línea sirve para crear un disco de arranque
para el kernel que está ejecutándose actualmente.
[root@station root]# mkbootdisk $(uname -r)
Un examen del disquete resultante revela los siguientes componentes.
[root@station root]# mount /dev/fd0 /mnt/floppy/
[root@station root]# ls /mnt/floppy/
boot.msg initrd.img ldlinux.sys
syslinux.cfg vmlinuz
[root@station root]# cat /mnt/floppy/syslinux.cfg
default linux
prompt 1
display boot.msg
timeout 100
label linux
18
Troubleshooting
kernel vmlinuz
append initrd=initrd.img ro
root=/dev/hda2
El gestor de arranque SYSLINUX. El gestor de arranque syslinux tiene la misma
función de GRUB, pero es mucho mas sencilla y pequeña.
La imagen de kernel.
Una referencia a la partición root adecuada.
Para utilizar el disquete de arranque, reinicie la máquina con el disquete en el
controlador (posiblemente modificando BIOS para incorporar el disquete en la lista de
dispositivos de arranque). Las siguientes acciones deben ocurrir.
1. El gestor SYSLINUX carga y brinda al administrador la oportunidad de omitir
los parámetros por defecto del tiempo de carga del kernel.
2. Después de unos 10 segundos (suponiendo que los parámetros por defecto no
fueron modificados), el gestor de carga cargará la imagen de kernel.
3. Cuando el kernel esté listo para arrancar el sistema de archivos, éste montará la
partición root a la que se hace referencia (/dev/hda2 en la muestra anterior)
desde el disco duro.
4. El arranque del sistema continúa utilizando el sistema de archivos de root
montado para lanzar el primer proceso (probablemente /sbin/init). En este punto
el sistema debe seguir su proceso de arranque normal.
Suponiendo que todo está en orden, el sistema debe arrancar a un estado de
funcionamiento total. De hecho, una vez que arranca el sistema, hay sólo un aspecto del
sistema que difiere de cuando el sistema inicia directamente desde el disco duro. ¿Qué
es? La respuesta se encuentra a continuación:
Rastreando los pasos listados anteriormente, ¿cuál de los siguientes escenarios
problemáticos superará un disquete de arranque?
Table 1. Problemas de arranque superados por el disquete de arranque
Problema
¿Efectivo?
Comentario
missing/mangled bootloader
si
El disquete proporciona su propio gestor de
arranque
missing/mangled kernel
si
El disquete proporciona su propio kernel
partición root inutilizable
no
El kernel intenta montar la partición root
fuera del disco duro.
no
Puesto que el kernel está utilizando la
partición root fuera del disco duro, se
encontrará el mismo archivo mal
configurado.
El archivo de configuración
del núcleo está mal
configurado
Un disquete de arranque no resuelve todos los problemas, pero los que puede resolver
los resuelve con facilidad. De hecho, hemos tenido el cuidado de no llamarlo de
19
Troubleshooting
"emergencia", porque en algunas situaciones el procedimiento normal de arranque es
iniciar el sistema de Linux desde un disquete (por lo general, cuando otro gestor de
arranque debe ser preservado en el disco duro).
No obstante, la mayor desventaja del disquete de arranque es que raras veces el
administrador tiene la previsión de crear uno.
Respuesta a la Pregunta: La imagen de kernel es la única diferencia entre un sistema
iniciado correctamente desde un disquete de arranque y otro iniciado correctamente
desde el disco duro. Todos los componentes "visibles" del sistema deben ser idénticos.
Entorno de rescate
El entorno de rescate de Red Hat Enterprise Linux es un sistema operativo provisto por
el instalador Anaconda que arranca sin siquiera haber tocado el disco duro. Para lograr
esto, el entorno de rescate provee su propio gestor de arranque, su imagen de kernel y
algo muy importante, su propia imagen de sistema de archivos de root.
Cuándo utilizar el entorno de rescate
El entorno de rescate es primordialmente útil para los dos tipos de problemas siguientes:
•
•
Una partición root dañada. Cuando la partición root no está disponible, se
debe proporcionar una partición root alterna. El entorno de rescate es su única
alternativa.
Un gestor de arranque o kernel dañados. En esencia, los problemas que un
disquete de arranque habría resuelto trivialmente, si fue precavido de crear uno.
Pero probablemente no lo hizo.
Cómo utilizar el entorno de rescate
El entorno de rescate es provisto por el CD # 1 de la distribución de Red Hat Enterprise
Linux. El entorno de rescate se inicia exactamente como se iniciaría la instalación de
Red Hat Enterprise Linux, excepto que la palabra clave rescue es provista como
parámetro de tiempo de carga en el intérprete de arranque del instalador. (Recuerde que
cada vez que un parámetro se pasa al instalador, la línea debe iniciar con la palabra
clave linux.)
arranque: rescate Linux
El instalador avanzará como si iniciara una instalación, solicitando la asignación
apropiada del idioma y del teclado. No obstante, cuando llega el momento de cargar la
segunda etapa del instalador, el entorno de rescate es cargado en su lugar.
Cuando entra al entorno de rescate, se hacen dos preguntas.
20
Troubleshooting
1. ¿Quiere iniciar interfaces de red? Si usted quisiera utilizar los recursos desde
la red (tales como un sistema de archivos NFS, o FTP algún archivo), entonces
debe especificar su configuración de red, mediante DHCP o manualmente,
proporcionando la información necesaria. La configuración de red es utilizada
únicamente para esta sesión de entorno de rescate.
2. ¿Quiere reconstruir automáticamente su sistema de archivos? Por defecto,
el entorno de rescate intentará reconstruir su sistema de archivos bajo el punto
de montaje /mnt/sysimage. Usted puede modificar para que el sistema de
archivos sea montado de sólo lectura, o que el entorno de rescate no intente
reconstruirlo todo. Recuerde que probablemente usted está en el entorno de
rescate por alguna razón. Si su partición root no se puede montar, entonces el
intento de reconstruir su sistema de archivos probablemente fallará.
Una vez se haya dado respuesta a estas preguntas, usted entrará en la shell de rescate.
El sistema de archivos del entorno de rescate
Recuerde que el entorno de rescate proporciona su propia imagen de sistema de
archivos de root, lo cual puede ser confuso para las personas que no estén familiarizadas
con la shell de rescate. Para ayudar a entender este sistema de archivos de root,
comenzamos suponiendo que usted eligió no reconstruir automáticamente su sistema de
disco duro después de entrar al entorno de rescate. En este caso, después de entrar la
shell de rescate, el comando df entregará lo siguiente:
sh-2.05b# df
Filesystem
rootfs
/dev/root.old
/tmp/cdrom
1K-blocks
6120
6120
143360
Used Available Use%
2464
3306 43%
2464
3306 43%
143360
0 100%
Mounted on
/
/
/mnt/source
La partición root está provista de un dispositivo llamado rootfs, el cual es la imagen
del sistema de archivos montada desde un disco RAM en memoria (¡no en el disco
duro!)
El CD # 1 de Red Hat Enterprise Linux utilizado para arrancar el entorno de rescate
es montado en /mnt/source.
Figure 1. El entorno de rescate de Red Hat Enterprise Linux
21
Troubleshooting
Si elige montar automáticamente el sistema de archivos de disco duro y el entorno de
rescate tiene éxito, se hallará bajo el punto de montaje /mnt/sysimage. El comando df
entregaría algo parecido a lo siguiente:
sh-2.05b# df
Filesystem
rootfs
/dev/root.old
/tmp/cdrom
/dev/hda2
/dev/hda1
/mnt/sysimage/boot
/dev/hda5
/mnt/sysimage/home
/dev/hda6
/mnt/sysimage/var
1K-blocks
6120
6120
143360
8254272
124427
Used Available Use% Mounted on
2615
3155 46% /
2615
3155 46% /
143360
0 100% /mnt/source
2961928
4873048 38% /mnt/sysimage
9230
108773
8%
4128320
2480452
1438080
64%
14428456
9309732
4385784
68%
La partición root ha sido montada en /mnt/sysimage y las particiones restantes han
sido montadas en el contexto de esa partición de root.
Figure 2. Un sistema de archivos de disco montado bajo /mnt/sysimage
22
Troubleshooting
En este punto, usted es libre de indagar y resolver problemas. Mientras prosigue, tenga
en cuenta que ahora hay dos versiones de los archivos más comunes de Linux: uno
perteneciente al entorno de rescate y otro al disco duro. Si /etc/passwd no le es
familiar, pruebe con /mnt/sysimage/etc/passwd en su lugar.
Uso de cambio de shell de root: chroot /mnt/sysimage
Con el fin de recuperar un entorno más conocido, muchos administradores prefieren
ejecutar chroot a su disco duro montado. El comando chroot inicia una nueva shell,
donde la nueva shell trata al directorio especificado como el nuevo directorio raiz.
sh-2.05b# chroot /mnt/sysimage
sh-2.05b#
Aunque la nueva shell no parece de inmediato diferente, ésta reside en el contexto de su
sistema de archivos y ha dejado atrás el sistema de archivos de entorno de rescate
montado. Observe cómo ha cambiado la salida del comando df.
sh-2.05b# df
Filesystem
/dev/hda2
/dev/hda1
1K-blocks
8254272
124427
Used Available Use% Mounted on
2961928
4873048 38% /
9230
108773
8% /boot
23
Troubleshooting
/dev/hda5
/dev/hda6
4128320
14428456
2480452
9309732
1438080
4385784
64% /home
68% /var
Figure 1. Un comando de shell chroot ejecutado en el entorno de rescate.
Usted debe poder ejecutar desde el interior de la shell de rescate de la misma forma que
lo haría dentro de un sistema que ha sido arrancado normalmente. No obstante, observe
que todo lo que se deja dentro del sistema de archivos del entorno de rescate no está
disponible ahora.
¿Cómo abandona usted el cambio de entorno de root? Salga de la shell sometida a
chroot.
sh-2.05b# exit
exit
sh-2.05b# df
Filesystem
rootfs
/dev/root.old
/tmp/cdrom
/dev/hda2
/dev/hda1
/mnt/sysimage/boot
1K-blocks
6120
6120
143360
8254272
124427
Used Available Use% Mounted on
2615
3155 46% /
2615
3155 46% /
143360
0 100% /mnt/source
2961928
4873048 38% /mnt/sysimage
9230
108773
8%
24
Troubleshooting
/dev/hda5
/mnt/sysimage/home
/dev/hda6
/mnt/sysimage/var
4128320
2480452
1438080
64%
14428456
9309732
4385784
68%
Usted está otra vez en la shell de entorno de rescate. ¿Qué sucede si usted vuelve a
salir?
sh-2.05b# exit
exit
Sending termination signals... done.
Sending kill signals... done.
...
Rebooting the system.
El juego ha terminado. Cuando sale de su shell original de rescate, el sistema
automáticamente reinicia. Necesitará reiniciar el entorno de rescate para recobrarla.
Funcionamiento dentro del entorno de rescate
El entorno de rescate proporciona un puñado de las utilidades más requeridas para
realizar un trabajo de rescate. A continuación se listan las utilidades disponibles dentro
del entorno de rescate mismo (y por lo tanto son utilizables incluso cuando su sistema
de archivos del disco duro no lo esté).
•
•
•
•
•
Editores de texto: vi, emacs, joe, pico, less, ...
Mantenimiento del sistema de archivos: fdisk, fsck, mkfs, mkswap, tune2fs,
badblocks, ...
Mantenimiento de RAID/LVM: mkraid, pvcreate, lvdisplay, ...
Configuración de red y clientes: ifconfig, ping, ssh, ftp, wget, NFS mounts, ...
Comandos de manipulación de archivo: rpm, tar, cpio, dd, chmod, ...
Aunque puede que usted no tenga todo lo que desea, seguramente tendrá un conjunto
robusto de herramientas. El cliente ssh es particularmente útil para obtener archivos
dentro o fuera del entorno de rescate. Aunque el editor de texto nano no está disponible,
su pariente cercano pico lo está.
Si su disco duro que ha vuelto a montar está disponible, usted tiene aún más. Usted
siempre tendrá la libertad de operar ejecutables desde él directamente.
sh-2.05b# /mnt/sysimage/usr/bin/nano -w /mnt/sysimage/etc/fstab
O si se cansa de teclear /mnt/sysimage..., inicie un cambio de shell de root.
Resumen de herramientas de localización y solución de problemas de arranque
En síntesis, listamos algunas situaciones problemáticas y las herramientas más útiles en
la localización y resolución del problema.
25
Troubleshooting
Table 1. Herramientas apropiadas para configuraciones problemáticas
Situación
Herramienta apropiada
Partición root que no se puede montar
entorno de rescate
kernel no utilizable
entorno de rescate, disquete de
arranque
gestor de arranque inutilizable
entorno de rescate, disquete de
arranque
partición root mal especificada (montaje de kernel)
editar GRUB: (specificar partición
apropiada)
archivo de configuración mal configurado utilizado añadir GRUB: emergencia (o
por rc.sysinit
init=/bin/sh)
partición root mal especificada (rc.sysinit remount)
añadir GRUB: emergencia (o
init=/bin/sh)
archivo de configuración mal configurado utilizado
Añadir GRUB: 1 (o "s")
por scripts de servicio
autenticación mal configurada (o contraseña de root
Añadir GRUB: 1 (o "s")
perdida)
Observe que la partición root debe especificar consistentemente dos sitios diferentes.
Una vez que esté en /boot/grub/grub.conf (el kernel puede montarlo de sólo
lectura), y cuando esté en /etc/fstab (rc.sysinit puede volverlo a montar delectura y
escritura). ¿Cuáles son los archivos de configuración utilizados por rc.sysinit? Los
archivos más editados incluyen los archivos /etc/fstab y /etc/raidtab, mientras
que los archivos menos editados incluyen al mismo /etc/rc.d/rc.sysinit y el
archivo /etc/inittab responsable de iniciarlo.
Aunque esta lección ocupa bastante tiempo discutiendo el entorno de rescate, hacemos
hincapié en que hay sólo algunas situaciones en que éste realmente se necesita. No
olvide la flexibilidad de GRUB para localizar y solucionar problemas de un sistema de
no-arranque.
Ejemplos
Reinstalación de un kernel perdido
Un administrador novato accidentalmente borró el archivo /boot/vmlinuz-2.4.214.EL y agravó el problema al reiniciar la máquina. Tras el arranque, GRUB, expidió el
siguiente mensaje problemático:
...
kernel /vmlinuz-2.4.21-4.EL ro root=LABEL=/
Error 15: File not found
26
Troubleshooting
Press any key to continue...
Al darse cuenta del error, deseó haber tenido un disquete desde el cual simplemente
habría podido reiniciar la máquina e instalar el nuevo kernel. Sin embargo, al no haber
previsto la creación de un disquete de arranque, decide utilizar el entorno de rescate de
Red Hat Linux Enterprise. El administrador reinicia la máquina con el CD #1 como el
dispositivo de arranque. En el intérprete de arranque del instalador, especifica el modo
de rescate.
arranque: rescate Linux
Después de iniciar el entorno de rescate, el administrador pide que su interfaz de red sea
configurada por DCHP y que su sistema se vuelva a montar. Cuando llega a la shell de
rescate, primero ejecuta chroot en el disco duro.
sh-2.05b# chroot /mnt/sysimage
El administrador sabe que hay una distribución de Red Hat Enterprise disponible por ftp
anónimo en el servidor server1, en el directorio /pub/es4. Él útiliza el cliente FTP
sencillo para descargar un archivo de paquete RPM de kernel y despúes forzar la
instalación del paquete.
sh-2.05b# ftp server1
Connected to server1 (172.16.63.242).
220 (vsFTPd 1.2.0)
Name (server1:root): anonymous
331 Please specify the password.
Password: ********
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /pub/es4/RedHat/RPMS
250 Directory successfully changed.
ftp> mget kernel-2*.i686.rpm
mget kernel-2.4.21-4.EL.i686.rpm? y
227 Entering Passive Mode (172,16,63,242,242,147)
150 Opening BINARY mode data connection for kernel-2.4.214.EL.i686.rpm (7159467 bytes).
226 File send OK.
7159467 bytes received in 0.624 secs (1.1e+04 Kbytes/sec)
ftp> quit
221 Goodbye.
sh-2.05b# rpm -ihv --force kernel-2.4.21-4.EL.i686.rpm
Preparing...
########################################### [100%]
1:kernel
########################################### [100%]
Observando rápidamente en /boot, confirma que el nuevo kernel está presente.
sh-2.05b# ls /boot
config-2.4.21-4.EL
lost+found
System.map-2.4.21-4.EL
27
Troubleshooting
grub
initrd-2.4.21-4.EL.img
kernel.h
message
message.ja
System.map
vmlinux-2.4.21-4.EL
vmlinuz-2.4.21-4.EL
Satisfecho, sale del cambio de shell de root y luego del entorno de rescate. Tras
reiniciar, GRUB encuentra el nuevo kernel.
Capítulo 6 Scripts de Red Hat Academy para localización y solución de problemas
Los ejercicios para este cuaderno no se implementan a través de la aplicación de red de
Red Hat Academy, sino en su lugar, como scripts instalados en su máquina local. Los
scripts no se "califican", sino se ofrecen como una experiencia de aprendizaje.
Instalación de scripts para localización y solución de problemas
Los scripts de localización y solución de problemas están incorporados en los archivos
de paquete RPM rha-ts en el directorio http://rha-server/pub/rha/rha130/ts/. Como root,
descargue e instale este paquete RPM, luego cierre y vuelva a iniciar sesión.
Si por alguna razón su máquina está vinculada a un dominio NIS para autenticación de
usuario, debe desvincularla del dominio.
Querrá tener un CD #1 de la instalación de Red Hat Enterprise disponible.
Uso de los scripts de localización y solución de problemas
Cada uno de los scripts de localización y solución de problemas dañan o configuran mal
su máquina y luego lo dejan con una instrucción simple tal como "la máquina se debe
arrancar sin errores". Su tarea es diagnosticar el problema e implementar la solución, de
tal modo que las condiciones especificadas se cumplan.
La localización y solución de problemas entra en una de las tres categorías siguientes.
El cuadro a continuación muestra las categorías y el número de problemas en cada
categoría.
Table 1. Categorías de scripts de localización y solución de problemas
Categoría Número de problemas
local
4
network
1
boot
3
El paquete rha-ts proporciona los siguientes comandos:
Table 2. Comandos de Red Hat Academy para localización y solución de
problemas
28
Troubleshooting
Comando
Uso
tslocal problemnum
Implementa el número del problema problemnum desde la
categoría local.
tsnetwork problemnum
Implementa el número del problema problemnum desde la
categoría de red.
tsboot problemnum
Implementa el número de problema problemnum desde la
categoría de arranque.
tshint categoría
problemnum hintnum
Muestra el número de ayuda hintnum para el problema de
categoría número problemnum.
tslesson categoría
problemnum
Muestra un resumen final de las lecciones reforzadas para
el problema de categoría número problemnum.
Una muestra de sesión de localización y solución de problemas
Primero, el problema es implementado mediante el comando apropiado (tsboot, tslocal,
o tsnetwork).
[root@station root]# tslocal 1
Setting up problem 1 of 4 . . .
Instructions for problem 1:
Begin at runlevel 3 with the X server down.
X fails to start on this system. Discover why
and fix it.
done.
Fix the local problem.
Ahora que el problema se ha implementado, su tarea es depurar y solucionar el
problema. Si olvidó el área del problema, también está almacenada en el archivo
/etc/ts.
Por el camino, se puede utilizar el comando tshint para ver progresivamente más
información de ayuda. El siguiente comando muestra la ayuda número 2 para el
problema de categoría local número 1.
[root@station root]# tshint local 1 2
Troubleshooting Hints
Hint 2 for local problem 1
The X server marks error messages in its output with the
characters "(EE)". Any lines so marked should be noted.
29
Troubleshooting
Evidentemente, su máquina debe mostrar ayudas. Para la categoría de arranque, éste
puede no ser el caso.
Por último, un resumen de la lección a aprender de este caso puede visualizarse con el
comando tslesson.
[root@station root]# tslesson local 1
Troubleshooting Lessons
Lesson for local problem 1
The X server spews out many lines of error messages
(which are also placed in /var/log/xorg.0.log).
This has several implications, summarized in the
lessons below.
Lessons:
-
The more familiar you are with X server
...
Usted debe ahora iniciar con el primer problema local, mediante tslocal 1 y seguir
con el resto.
¡Diviértase!