Capitulo 13 IT Essentials 2 Sistemas Operativos de Red - Español

Módulo 13: Detección de problemas en el sistema operativo

1

Índice

Descripción general ................................................................................................................................213.1 Identificación y Localización de Síntomas y Problemas ....................................................3

13.1.1 Problemas de Hardware ..................................................................................................313.1.2 Problemas del Kernel.......................................................................................................413.1.3 Software de aplicaciones ................................................................................................513.1.4 Configuración ....................................................................................................................613.1.5 Error del usuario ...............................................................................................................713.1.6 Uso de utilidades del sistema y uso de herramientas de estado del sistema.......813.1.7 Programas y procesos que no responden.................................................................1213.1.8 Cuándo iniciar, detener o reiniciar un proceso ...............................................................1213.1.8 Solución de problemas persistentes...........................................................................1313.1.9 Examen de los archivos log..........................................................................................1413.1.10 El comando dmesg ....................................................................................................1713.1.11 Detección de problemas basándose en el feedback del usuario ......................18

13.2 Errores de Arranque de LILO.................................................................................................2113.2.1 Códigos de error .............................................................................................................2113.2.2 Arranque de un sistema Linux sin LILO .....................................................................2413.2.3 Sistema de arranque de emergencia...........................................................................2513.2.4 Uso de un disco de arranque de emergencia en Linux ...........................................26

13.3 Reconocimiento de Errores Comunes .................................................................................3313.3.1 Diversas razones para los problemas de dependencia de los paquetes .............3313.3.2 Soluciones a problemas de dependencia de paquetes ...........................................3413.3.3 Errores de backup y restauración ...............................................................................3913.3.4 Fallos de aplicaciones en servidores Linux...............................................................41

13.4 Detección y Resolución de Problemas de Red ..................................................................4313.4.1 Pérdida de conectividad ................................................................................................4313.4.2 Error del operador ..........................................................................................................4413.4.3 Uso de utilidades TCP/IP ...............................................................................................4613.4.4 Directrices para resolver problemas ...........................................................................5213.4.5 Herramientas de diagnóstico de Windows 2000 .......................................................53

Resumen .................................................................................................................................................56


2

Descripción general

Detectar y resolver problemas en un sistema que ha manifestado algún nivel de fallo puede ser unode los trabajos más estresantes en informática. Cuando la oficina IT central de una compañíagrande llama por teléfono a un administrador de sistemas a las 3:00 de la mañana para quejarsepor conectividad de networking perdida, nadie está contento. También es un problema cuando unvicepresidente corporativo no puede imprimir el informe en el que ha venido trabajando porsemanas a tiempo para una reunión a las 7:00 de la mañana en un desayuno con el CEO. Todaslas partes no desean más que resolver el problema eficaz y rápidamente.

Los administradores de sistemas experimentados confían en una metodología probada ysistematizada para resolver problemas del sistema. Deben poder reconocer condiciones de errorcomunes y conocer sus causas usuales. Deben aprender a evaluar síntomas de manera tal quepuedan aislar su probable origen. Luego es necesario aplicar su experiencia en conocer qué clasede pruebas ejecutar y qué avenidas explorar para verificar hipótesis relativas al problema, o reunirmás datos. Necesitan saber qué hacer para arreglar el problema, o adónde dirigirse para obtenerasistencia rápidamente, luego seguir adelante y hacerlo. Deberán documentar lo que aprenden porel camino para hacer más fácil atacar cualquier recurrencia del problema. Finalmente, necesitaneducar a los usuarios de manera que se evite que el problema vuelva a ocurrir, o al menospermitirles proporcionar feedback significativo si lo hace.


3

13.1 Identificación y Localización de Síntomas y Problemas

13.1.1 Problemas de Hardware

Cuando un usuario afligido experimenta problemas de sistema, no es suficiente para él o ellalamentarse, "¡Esta computadora no funciona!" El problema puede ser real, y las emocionesexpresadas sobre él ser sinceras, pero no se ha proporcionado la suficiente información parapermitir al técnico que la arregla saber por dónde empezar.

Aunque unos pocos problemas se deben a una combinación de factores, la mayoría puede aislarseen uno de los siguientes orígenes:

• Hardware Un componente de hardware del sistema ha funcionado mal, o se lo esperapero no está presente.

• Kernel Un bug o falta de funcionalidad en el kernel del sistema a veces causa problemasde origen ambiguo.

• Software de aplicaciones El software de aplicaciones o utilidades de comandos a niveldel usuario pueden comportarse extrañamente, o simplemente colapsarse.

• Configuración Los servicios del sistema o el software de aplicaciones puede estar malconfigurado.

• Error del usuario Una de las más frecuentes fuentes de condiciones de error es causadapor usuarios de computadoras intentando hacer algo de la manera equivocada.

Cada tipo de condición de error puede categorizarse de una de dos maneras, consistente oinconsistente. Un problema consistente es uno que de forma demostrable y positivamente ocurreuna y otra vez. Los problemas inconsistentes son aquéllos que ocurren sólo esporádicamente, obajo condiciones indeterminadas.

El último tipo es mucho más difícil de atacar, porque factores desconocidos causan el problema.Antes de poder encontrar una solución, es necesario tener una clara definición de todas lascondiciones que pueden estar relacionadas. Por ejemplo, si el usuario de una pieza de software deoficina selecciona una opción del menú y el programa se cae cada vez, dejando una extracción delnúcleo, se trata de un problema reproducible. Por otro lado, si el usuario selecciona esa opción y aveces funciona, mientras que otras se cae, eso sugiere que algo desconocido podría estarinvolucrado acerca del camino que tomó el usuario para llegar a ese estado. Es necesaria másinformación para ver qué más podría haber hecho que puede haber causado el problema.

Algunos errores de hardware serán obvios. Si una unidad de disco comienza a sacudirse o deja deescucharse en absoluto, si se detecta humo, o las luces del equipo no se están encendiendo comolo hacen normalmente, es probable que haya un problema del dispositivo físico. Si un trabajo deimpresión en una impresora que ha estado funcionando bien resulta desteñido, en blanco, o concolores extraños, la impresora podría necesitar un nuevo cartucho, no diferente software decontroladores.

Otro hardware deja rastros que el kernel detecta y registra. Suponiendo que un error es tal que nohace caer el sistema, podría quedar evidencia en el archivo log /var/log/messages, con elmensaje prefijado por la palabra oops. Un ejemplo de este archivo log se muestra en la Figura .La presencia de tal mensaje no es necesariamente un error de hardware, aunque existe laposibilidad.

Es importante comprender lo que está localizado dentro del directorio /dev al tratar cómo detectarproblemas de hardware en Linux. El directorio /dev contiene archivos especiales conocidos comoarchivos de dispositivos, que se usan para acceder a todos los tipos diferentes de hardware de un


4

sistema Linux. Por ejemplo, el archivo /dev/mouse es para leer entradas del mouse. Organizandoel acceso a los dispositivos de hardware de esta manera, Linux eficazmente hace parecer lainterfaz de un dispositivo de hardware como cualquier otra pieza de software. El directorio /dev esun buen lugar para empezar a mirar al detectar problemas de hardware.

13.1.2 Problemas del Kernel

Los kernels Linux lanzados son considerablemente estables, a menos que se usen versionesexperimentales o se hagan modificaciones individuales. Los módulos de kernel descargables seconsideran parte del kernel también, al menos durante el periodo durante el que se los descarga. Aveces éstos también pueden ocasionar dificultades. La buena noticia con respecto a los móduloses que pueden desinstalarse y reemplazarse por versiones fijas mientras el sistema aún estáfuncionando.

Los problemas con los módulos a menudo se identifican en el transcurso del uso de una aplicaciónque los llama. Por ejemplo, si un usuario intenta reproducir un archivo de sonido que requiere unmódulo que no ha sido cargado, el kernel informará que el controlador o una función a la que llamano está presente en la memoria y necesita cargarse.


5

13.1.3 Software de aplicaciones

Los errores en paquetes de aplicaciones son más identificables por el hecho de que ocurrensolamente cuando se ejecuta la aplicación. Esto, en contraste a las condiciones de hardware okernel que afectan a todo el sistema. Algunas señales comunes de bugs en aplicaciones son elfallo al ejecutar y la caída del programa.

Fallo al ejecutarEl programa no iniciará en absoluto, sugiriendo que su archivo principal podría no tener permisopara su ejecución. O puede parecer iniciar, pero no inicializa enteramente, y se cierra o se queda amitad de camino, a veces con un mensaje de error mostrado en una ventana, en la línea decomandos, o en un archivo log.

Caída del programaCuando un programa en ejecución se cae, usualmente lo hace sin guardar los datos o archivos enlos que está trabajando un usuario. A veces se registran mensajes de error en uno de los lugaresde costumbre. En otros momento queda un archivo del núcleo, lo cual es una señal definida de quela aplicación en sí sufrió un fallo catastrófico. Un archivo del núcleo puede examinarlo con undebugger alguien que conozca la aplicación y que tenga código fuente disponible. En situacionesde emergencia, no obstante, los archivos del núcleo son generalmente de poco uso.

Una variante de este caso es un programa bloqueado. La aplicación sigue ejecutándose, pero noprocede hacia ningún sitio. Esto requiere que el proceso se elimine con kill desde una línea de


6

comandos. A veces eliminarlo con señal 3 (SIGQUIT) hará que termine y deje una imagen de sumemoria en un archivo del núcleo. Este archivo puede enviarse al fabricante del software con unadescripción del problema en espera de obtener una respuesta y solución a largo plazo. La realidades, no obstante, que la mayoría de los fabricantes de software no responden a las necesidades deusuarios desafortunados que han sido víctimas de su software fallido.

Algunas aplicaciones están diseñadas para mostrar una memoria al recibir ciertas señales, quepueden ser informativas, a veces incluso sin la disponibilidad del código fuente.Desafortunadamente, éste tiene que conocerse antes de que el problema surja.

Agotamiento de recursosLos recursos del sistema se refieren principalmente al tiempo de la CPU, memoria, y espacio endisco. Una aplicación puede consumir demasiada memoria del sistema y en última instanciacomenzar a intercambiar tanto que todo el sistema se ve afectado. Puede entrar en un bucle queconsume mucho espacio en el tiempo de la CPU. Puede comenzar a escribir archivos que sehacen muy grandes y hacer que el sistema de archivos se quede sin espacio. Tal malcomportamiento es generalmente un fallo de la aplicación, no del sistema.

Mal comportamiento específico de un programaAlgunos errores son causados por cosas que tienen que ver con la ejecución del programa en sí.Por ejemplo, si un procesador de texto tiene una función que permite al usuario saltar hasta unacierta página del documento, y se le indica que vaya a la página 999999999999 y se cae, a laaplicación probablemente le falta código para verificar desbordes de enteros.

13.1.4 Configuración


7

Muchos paquetes pueden y debe ajustarse para una instalación local antes de ser usados.Simplemente instalar el software en el sistema no es suficiente. Los problemas de configuracióntienden a afectar a subsistemas enteros, como subsistemas de gráficos, impresión, o networking.Por ejemplo, si una costosa terminal SVGA se conecta a una placa adaptadora gráfica de altapotencia en un sistema de escritorio y muestra solamente los gráficos de baja resolución másgranulados, es probable que el subsistema de gráficos X esté mal configurado. Tal vez el programaXconfigurator necesite ejecutarse. Programas que dependen de servicios de networking sonparticularmente responsables de causar problemas. Si el sistema se reinicia y un sistema dearchivos remoto que una vez estuvo presente no lo está, el primer lugar donde buscar es en elarchivo de configuración /etc/fstab para ver si se supone que el sistema de archivos se monte enel momento del arranque. Un ejemplo del archivo /etc/fstab se muestra en la Figura . Si se estáenviando e-mail, pero mailq muestra que el correo saliente simplemente espera en una cola ynunca sale del sistema, podría ser necesario investigar la configuración para el agente detransporte de correo.

Allí donde un problema de configuración ocurre en software de aplicaciones, deberá determinarsesi ocurre en todo el sistema, o a solamente un usuario. La mayoría del software configurableincluye archivos de configuración del sistema por defecto y permite a los usuarios individualespersonalizar el comportamiento del programa según sus gustos. Por ejemplo, si un navegador delsistema funciona bien para todo el mundo excepto para un usuario que ve tanto el texto como elfondo del mismo color. Es probable que esta persona haya estado experimentando con laspropiedades del navegador y puede necesitar un poco de asistencia para restaurar unafuncionalidad razonable.

13.1.5 Error del usuario


8

Es perdonable cometer un error al usar un programa informático o ignorar la forma correcta dehacer algo. Lo que es imperdonable es insistir en permanecer tozudamente así. Hay más paraconocer acerca de los detalles intrincados de operar casi cualquier paquete de software que lo quelos usuarios cotidianos jamás se preocupen o intenten aprender. A menos que un usuario tenga unparticular interés en un programa y una cantidad extra de tiempo para explorar funciones a las quepuede nunca dar uso, tendrá que conformarse con lo que funciona.

Por lo tanto es raramente una sorpresa cuando los usuarios se quedan atascados en el software osimplemente encuentran que son incapaces de ir del punto A al punto B. Supongamos: "no puedellegar allí desde aquí". A veces un poco de instrucción es todo lo necesario para ayudar a alguien asuperar un problema.

13.1.6 Uso de utilidades del sistema y uso de herramientas de estado del sistema

Los sistemas operativos Linux proporcionan diversas utilidades del sistema y herramientas deestado del sistema. Estas herramientas son útiles para ayudar a identificar o diagnosticar ciertosproblemas del sistema operativo. Las siguientes utilidades devuelven información acerca de laconfiguración actual del sistema y en algunos casos permiten cambiar la configuración si necesitaarreglarse. También es importante saber que estas utilidades son útiles a un grado que devolveráninformación acerca de cómo el sistema o un archivo "deberían" configurarse, pero no proporcionaninformación sobre qué archivo o configuración del sistema exactos están mal configurados.


9

• setserial Esta utilidad proporciona información y configura opciones para los puertos serialdel sistema. Los puertos serial en un sistema Linux son por lo común /dev/ttyS0 y/dev/ttyS1. Introduciendo el comando setserial -a /dev/ttyS0 en el shell, el sistemadevolverá información detallada incluyendo el tipo de hardware que está conectado alpuerto serial en particular, la velocidad del puerto, y los recursos de hardware usados porel puerto. Un ejemplo de la salida del comando setserial -a /dev/ttyS0 se muestra en laFigura .

• lpq Este comando ayuda a resolver problemas de impresión. El comando mostrará todoslos trabajos que están esperando para ser impresos. Es de ayuda porque puede usarsepara determinar si hay un problema en la cola de impresión, o determinar si el sistemaLinux no puede encontrar la impresora en absoluto. Si el trabajo de impresión que se enviódesaparece de la cola, hay algo mal en la cola de impresión. No obstante, si el trabajo deimpresión permanece en la cola entonces el problema más probable es que el sistematiene problemas para encontrar la impresora. Un ejemplo de la salida de este comando semuestra en la Figura .

• ifconfig Esta utilidad y sus usos se tratarán en más detalle posteriormente en estecapítulo. No obstante, este comando puede introducirse en el shell para que devuelva laconfiguración de interfaz de red actual del sistema. Este comando devolverá la dirección IPactual del sistema, la máscara de subred, el gateway por defecto, el servidor DNS, elservidor DHCP, la IRQ que usa la placa de red, etcétera. Un ejemplo de la salida delcomando ifconfig se muestra en la Figura .

• route Esta utilidad y sus usos también se tratarán en más detalle en este capítulo. Estecomando muestra o configura la información acerca del enrutamiento del sistema, queutiliza para enviar información a direcciones IP en particular. Este comando puede ser útilpara obtener información que puede ser de ayuda en la resolución de problemas deconectividad de red. Un ejemplo de la salida del comando route se muestra en la Figura .

Hay varios otros tipos de utilidades del sistema y herramientas de estado que pueden usarse paraexaminar problemas en un sistema Linux que ya se han tratado a lo largo de este curso. Éstasincluyen comandos como las utilidades para disco rígido du y df, el comando top, así como lautilidad del sistema de archivos fsck.


10


11


12

13.1.7 Programas y procesos que no responden

A veces hay programas o procesos que por diversas razones pueden no responder o "bloquearse".A veces solamente el programa o proceso en sí se bloquea y otras veces pueden ocasionar quetodo el sistema deje de responder. Un método para identificar y localizar el programa que noresponde y resolver eficazmente el problema es eliminar o reiniciar el proceso o programa. Algunosde los temas tratados en esta sección han sido tratados en otros capítulos, no obstante hay otrasconsideraciones de resolución de problemas a tener en cuenta en el caso de programas yprocesos que no responden.

13.1.8 Cuándo iniciar, detener o reiniciar un proceso

Como se mencionó en capítulos anteriores, a veces es necesario terminar el proceso que noresponde a sus funciones normales. Cuando un proceso no responde puede realmente hacermucho daño a un sistema informático. Lo más importante, estos procesos "colgados" puedenconsumir todos los recursos del sistema tomando control del tiempo de la CPU. Eventualmenteestos procesos que no responden pueden hacer que todo el sistema se caiga si no se los trataapropiadamente. Es importante estar seguros de que un proceso se ha bloqueado antes deeliminarlo aunque parezca bloqueado, porque algunos procesos se cuelgan un breve tiempocuando están procesando datos. Otras razones por las cuales se necesita terminar procesos que


13

no responden son si comienza a quedar fuera de control y está consumiendo espacio en disco,memoria y RAM del sistema.

Lo más fácil para terminar un programa es usar el comando kill, Otros procesos necesitanterminarse editando el script de inicio Sys V que se trató en el Capítulo 10. La razón por la cualalgunos programas y procesos necesitan detenerse editando el script de inicio Sys V en lugar desimplemente usar el comando kill, es que, algunos programas usan otros archivos llamadosarchivos de bloqueo. Los archivos de bloqueo indican que el programa está usando un recurso queno debería. Si un programa se termina usando el comando kill, el archivo de bloqueo quedará ycuando el programa se ejecute nuevamente, lo más probable es que falle. Si esto ocurriera, segenerará un mensaje de error. Los archivos log del sistema pueden verse para determinar lapresencia de un archivo de bloqueo. Si se muestra un mensaje de error, entonces se recomiendaverificar la documentación del programa para determinar dónde está almacenado el archivo debloqueo. Los archivos de bloqueo pueden simplemente borrarse y el problema se soluciona. Alreiniciar un programa, servicio, o daemon lo mejor es consultar primero la documentación porquediferentes programas tienen que reiniciarse de maneras diferentes. Algunos soportan el uso delcomando restart, algunos necesitan detenerse completamente y luego iniciarse otra vez, yotros pueden simplemente releer sus archivos de configuración sin necesitar detenerse y volversea iniciar, o reiniciarse.

13.1.8 Solución de problemas persistentes

Programas que ocasionan problemas persistentes y necesitan reiniciarse constantemente podríangenerar llamadas para la resolución de problemas recurrentes. Esto usualmente significa que elprograma tiene algún problema o bug interno. Una de las primeras cosas que pueden hacerse esverificar con el fabricante y ver si se ha lanzado alguna actualización o patches. Otro problema quepuede estar causando que un programa tenga problemas recurrentes es un problema de hardware.Problemas con la CPU, la RAM, el motherboard, y otros componentes de hardware pueden causarproblemas para algunos programas. En algunos casos de un fallo de hardware todo el sistema o elsistema de archivos del sistema operativo puede caerse.

La mejor forma de arreglar programas que se caen repetidamente es reemplazarlos con nuevosoftware o con un tipo diferente de software que realice la misma tarea. El software reemplazantepuede no ser una opción o ni siquiera estar disponible, sin embargo. La solución a esto es muchomás dificultosa. De ser posible, intente usar el software de manera diferente o si hay una tecla ocomando en particular que hace que el programa falle, deje de usarlos. La mayoría de las veceshabrá software de reemplazo disponible. Si se trata de un daemon que se cae regularmente intenteusar otros métodos para iniciarlo y ejecutarlo. Los diversos métodos para iniciar daemons en unsistema Linux se describieron en el Capítulo 10.


14

13.1.9 Examen de los archivos log

Los archivos log se mencionaron por primera vez y se introdujeron en la sección 11.4.4 delCapítulo 11. Las diversas actividades de un servidor Linux, el kernel del sistema operativo, y lasutilidades del sistema se registran en archivos log. También se mencionó en la sección 11.4.4 delCapítulo 11 que la mayoría de archivos log se localizan en el directorio /var/log o en unsubdirectorio. Algunos de los archivos log más importantes en un sistema Linux son los archivoslog /var/log/messages, /var/log/secure, y /var/log/syslog. La Figura muestra todos los archivoslog que están ubicados en el directorio /var/log. Examinar los archivos log puede ser de ayuda enla identificación de varios problemas en un servidor Linux. Los archivos log del sistema puedenusarse para monitorear cargas del sistema tales como cuántas páginas ha servido un servidor web.También pueden verificar rupturas de la seguridad tales como intentos de intrusión, verificar que elsistema esté funcionando apropiadamente, y anotar cualquier error que podría ser generado por elsoftware o los programas. Hay varios diferentes tipos de información que es bueno saber, que haráde la identificación de problemas usando los archivos log algo un poco más fácil. Algunas de estascosas se enumeran a continuación.

Monitoreo de Cargas del SistemaLos servidores están diseñados y construidos para aceptar solicitudes entrantes de otros usuariosde la red de área local (LAN) o externamente de usuarios remotos o de Internet. El servidornecesita estar construido de manera tal que pueda manipular estas solicitudes de manera eficiente.Los archivos log pueden usarse para determinar qué solicitudes se están haciendo que podríanhacer que el servidor se ralentice. Si el servidor recibe un gran incremento en la cantidad desolicitudes entrantes o los archivos transferidos se incrementan en tamaño, entonces seránecesario tomar las medidas apropiadas para incrementar la capacidad del servidor para manejarla carga. Esto podría incluir el agregado de otro servidor, router, o switch, en lugar de solamente


15

mejorar un servidor existente. Tenga en cuenta que estos archivos log mantendrán un rastreo deincrementos de carga solamente en los programas específicos del servidor. Esto significa quesolamente registrarán los eventos de los programas y servicios que se ejecutan en el servidor y nocualquier problema ocasionado por un incremento en las demandas de la estación de trabajo. Noobstante, puede ser fácil determinar si las demandas de la estación de trabajo se incrementaránporque un administrador del sistema sabría si los usuarios van a usar programas más intensivos enmateria de recursos.

Intentos de Intrusión y su DetecciónPuede ser difícil detectar una intrusión a una red o servidor. Un examen apropiado de los archivoslog del sistema puede ayudar a descubrir cómo y dónde ocurrió la intrusión, así como qué cambioshizo el atacante en el sistema o la red. Cuando una persona irrumpe en un sistema, intentarámodificar herramientas y utilidades del mismo. Esto afecta el desempeño o la confiabilidad. Losintrusos pueden tan sólo borrar archivos importantes y borrar archivos log para hacer difícilaveriguar qué daño han hecho al sistema. Por esta razón es una buena idea monitorearcontinuamente los archivos log para que cualquier cambio o entrada inusual llame la atención.

Funcionamiento Normal del SistemaLos archivos log también pueden examinarse para asegurarse de que el sistema está funcionandoen un estado normal. Si hay algo mal en el sistema, la información de los archivos log puedeayudar a identificar y eliminar posibles problemas. Por ejemplo, un sistema Linux puede estarconfigurado como servidor DHCP en el cual es posible distribuir direcciones IP a estaciones detrabajo cliente. Los archivos log pueden examinarse para ver si el servidor está recibiendosolicitudes y está distribuyendo préstamos de direcciones IP. Si las solicitudes se están recibiendoel problema puede reducirse a un problema del lado del cliente y no a un problema con el servidor.

Entradas FaltantesSi a cualquiera de los archivos log le faltan entradas, esto puede indicar que algo en el servidor noestá funcionando apropiadamente o está mal configurado. Entradas faltantes en archivos logtambién pueden indicar un problema en otro lugar que no sea el servidor. Por ejemplo, un servidorde archivos está configurado para ejecutar Samba para que los clientes que usan MicrosoftWindows puedan acceder al servidor Linux, y Samba está configurado para registrar intentos deacceso al servidor. Supongamos que el log se verifica después para ver quién está intentandoacceder al servidor y se descubre que faltan entradas. Estas entradas faltantes pueden indicar quehay un error de configuración en el daemon Samba del servidor. También podría significar que hayun problema externamente a la red con un router o firewall que está evitando el acceso. Lo cualsignifica que el servidor podría no ser el problema en absoluto.

Mensajes de ErrorMuchos de los archivos log de un sistema Linux contendrán diversos mensajes de error quepueden usarse para ayudar a localizar e identificar cualquier problema o mala configuración delservidor. Por ejemplo, un archivo log puede contener información sobre un error de autenticación.Este mensaje de error sería de utilidad porque le indica a un administrador del sistema dóndedeberían comenzar los esfuerzos de detección de problemas. Muchos programas y utilidades delservidor pueden configurarse para que registren información específica, lo cual puede ayudartambién en los esfuerzos de detección de problemas. Se recomienda consultar la documentaciónde los programas en cuanto a las opciones de configuración que están disponibles porque puedenvariar dependiendo del programa en particular.

Uso de tail y headLos comandos tail y head Linux pueden ser de ayuda para examinar archivos log del sistema.Algunos archivos log contienen numerosas páginas de información y texto. Usando los comandostail y head es posible procesar solamente una parte del archivo log para mostrar solamente lainformación o texto que se especifiquen, en lugar de todo el archivo log de una sola vez. Porejemplo, si deseara ver unas pocas líneas del principio o final del archivo log, usar el comando


16

head enviaría las primeras 10 líneas y el comando tail enviaría las últimas 10 líneas a la salidaestándar.

También es posible manipular más allá la salida deseada usando las diversas opciones delcomando. Visite las páginas man de los comandos tail y head para ver una lista más abarcativa delas opciones disponibles. Se puede cambiar la cantidad de líneas que estos comandos envían a susalida estándar con la opción -n. Para instruir a head o tail que usen bytes en lugar de líneas seusaría la opción -c en lugar de -n. Por ejemplo, para mostrar los primeros 200 caracteres delarchivo log, use el comando head -c 200 file, o use el comando -c 200 file para mostrar los últimos200 caracteres. Otras opciones incluyen agregar una b (por bloques) después de 200, lo quemultiplicaría el valor por 512. De manera similar, k (por kilobytes) multiplica el número dado por1024, y m (por megabytes) multiplica el número dado por 1048576 bytes.

Algunos archivos log continuarán procesando los datos y continuarán agregando datos mientrasestá instruyendo a head o tail para que lean datos del archivo específico. Un ejemplo de estoserían los archivos log para el servidor web Apache. Es enteramente posible que mientras seintenta ver inicios de sesión exitosos o fallidos al sitio web los usuarios, al mismo tiempo, estaránintentando acceder al sitio web. Usar la opción -f le indica a tail que siga leyendo los datos delarchivo especificado y alimente esos datos a su propia salida estándar. Esta opción es perfectapara monitorear logs del sistema. Por ejemplo, tail -f /var/log/access.log ejecutado en una ventanaterminal separada, seguirá imprimiendo nuevas entradas de inicio de sesión de acceso a Apache amedida que son agregadas después de cada intento hasta que lo detiene con Ctrl-C.

Examinar archivos log puede ser útil para identiifcar diversos problemas como problemas en elkernel, aplicaciones, configuración y también problemas del usuario. Los archivos log pueden serde mucha ayuda al intentar identificar y localizar problemas de software con el kernel, servidor,herramientas de inicio de sesión del usuario, y otras utilidades del sistema.


17

13.1.10 El comando dmesg

Parte de la información más importante y de más ayuda registrada en los archivos log que puedeser útil para detectar e identificar problemas son los mensajes de inicio del kernel. Estos mensajespueden ser de particular ayuda al identificar problemas de hardware y del kernel. El comandodmesg puede usarse para mostrar los mensajes recientes del kernel, también conocidos comobuffer anillo del kernel. Un ejemplo de la salida de este comando se muestra en la Figura . Noteque cuando el sistema arranca y Linux está comenzando a cargarse, una serie de mensajes delbuffer anillo del kernel se deslizan por la pantalla a medida que el sistema está inicializando losdispositivos y servicios. Estos mensajes contienen información importante acerca del hardwareinstalado en el sistema y los controladores. La información de estos mensajes se relaciona con silos controladores se están cargando exitosamente y qué dispositivos están controlando loscontroladores, como controladores [controllers] EIDE o SCSI, por ejemplo.

Hay diversas instancias en las cuales el comando dmesg puede ser muy útil. Pensemos en unservidor que contiene dos placas Ethernet, una de las cuales no están funcionando. Tipeando elcomando, dmesg | less, después del inicio del sistema puede verse información acerca de lasdos placas Ethernet que están instaladas en el sistema. Mirando los mensajes del kernel en elarchivo log puede determinarse si hay una entrada para la placa no funcional o no. Si no hay unaentrada para la placa, el problema podría ser que el controlador no se está cargando o podría serel controlador equivocado para la placa. Si hay una entrada para la placa pero aún así no funciona,el problema reside en algún lugar de la configuración de red de la placa. Use variables con elcomando dmesg para reducir la cantidad de mensajes que se muestran. Por ejemplo, usando elcomando grep, se mostrarán solamente las líneas que pertenecen a la placa Ethernet no


18

funcional. El comando usado para llevar a cabo esta operación sería dmesg | grep ethX,donde X es el dispositivo Ethernet en cuestión.

La información contenida en dmesg es tan valiosa para un sistema Linux que la mayoría de lasdistribuciones automáticamente envían la salida al archivo log /var/log/boot.messages . Si ladistribución no hace esto, puede arreglarse colocando la línea , /font> dmesg >/var/log/boot.messages en el script /etc/rc.d/rc.local.

13.1.11 Detección de problemas basándose en el feedback del usuario

A veces la mejor forma de identificar un problema con una computadora es localizar a la personaque usa el sistema más a menudo o la persona que usó el sistema cuando se informó acerca delproblema. No todos los usuarios tienen la capacidad de entregar apropiadamente la informacióncorrecta acerca de cuál es el problema o qué estaban haciendo cuando comenzaron aexperimentarlo. Por lo tanto, cualquier información que se obtenga de los usuarios deberá usarsecomo punto de partida pero se recomienda que el problema se investigue y reproduzca paraasegurarse de cuál es el problema. Muchos problemas que los usuarios informan provienensimplemente de su falta de comprensión y conocimiento de cómo funcionan los sistemasinformáticos. Hay varios tipos diferentes de problemas que los usuarios reportan. Algunos de losmás comunes se describen en esta sección.

Problemas de Inicio de SesiónUno de los tipos más comunes de problemas de los cuales se quejan los usuarios es que no


19

pueden iniciar sesión en el sistema. Frecuentemente cuando esto ocurre no se debe a que hayaocurrido ningún problema sino más bien a que han olvidado su contraseña, la han tipeadoincorrectamente, o la contraseña ha expirado. Recuerde que las contraseñas de un sistema Linuxson sensibles al uso de mayúsculas y minúsculas. Si la contraseña ha expirado entonces esnecesario re-habilitarla, para que el usuario pueda cambiar la contraseña o una nueva puedaasignarse.

Problemas de Permisos de ArchivosLos problemas de permisos de archivos no son tan comunes como los problemas de inicio desesión, no obstante podría haber un usuario que tenga problemas para acceder a un archivocompartido. Éste no es normalmente un problema si el usuario trabaja con archivos en sus propiosdirectorios, pero sí puede serlo cuando los usuarios necesitan acceso a archivos en otrosdirectorios. En algunos casos, puede ser necesario explicar cómo funcionan los permisos delsistema Linux para evitar estos tipos de problemas.

Problemas con Medios RemoviblesLinux maneja los medios removibles de manera muy diferente a otros sistemas operativos, comoWindows. Los usuarios muy a menudo tendrán muchas quejas. Incluso aunque la interfaz GUIpuede hacer parecer que se puede acceder a medios removibles como disqueteras y CD-ROMssimplemente insertando el medio y buscando los archivos, no puede hacerse. Aún tienen quemontarse y desmontarse. Es importante señalar esto a los usuarios y explicarles cómo usarapropiadamente los comandos mount y umount. Por defecto solamente la cuenta superusuariopuede usar los comandos mount y umount. Puede ser una buena idea modificar el archivo/etc/fstab para que los usuarios puedan montar y desmontar los medios removibles por símismos. Un ejemplo del archivo /etc/fstab se muestra en la Figura . La disquetera puedeeyectarse sin desmontarla primero, lo cual puede conducir a archivos corrompidos. La mayoría delos dispositivos, no obstante, como los CD-ROMs, se bloquearán para que no puedan eyectarse amenos que hayan sido desmontados primero. Los otros tipos de medios que no pueden eyectarsea menos que hayan sido desmontados pueden conducir a muchas llamadas de resolución deproblemas innecesarias a menos que se haya explicado a los usuarios cómo montar y desmontarapropiadamente unidades de medios removibles.

Problemas con el E-mailEl e-mail deberá funcionar para los usuarios cuando ha sido configurado correctamente. Esto esparticularmente cierto si todo lo que el usuario tiene que hacer es extraer su correo del servidorSMTP localmente. No obstante, si hay usuarios remotos podría ser una buena idea instruirlosrespecto a cómo configurar sus cuentas de correo para que éste pueda ser recuperado sinproblemas.

Errores en los ProgramasLos usuarios informarán a menudo que un programa se cayó. La mejor opción es enfocar estocaso por caso porque cada programa requerirá un diferente enfoque para resolver sus problemas.Obtenga tanta información del usuario como sea posible en cuanto a cualquier mensaje de errorque puede haber aparecido o a qué estaba haciendo cuando el programa se cayó para recrear loseventos que ocasionaron el error.

Problemas de ApagadoLinux siempre deberá apagarse usando el comando shutdown. Esto se explicó en capítulosanteriores. No obstante, solamente el usuario raíz puede usar este comando. A los usuarios queexperimentan problemas al apagar debería mostrárseles cómo usar la opción de apagado de laGUI que permitirá el apagado del usuario no raíz de un sistema Linux. Es importante que losusuarios sepan cómo apagar el sistema Linux apropiadamente porque un apagado inapropiadopuede ocasionar diversos problemas como procesos de inicio prolongados, seria corrupción dearchivos del sistema, y pérdida de datos. Si los usuarios se quejan de tales problemas puedehacerse la sugerencia de que el sistema debe apagarse apropiadamente.


20


21

13.2 Errores de Arranque de LILO

13.2.1 Códigos de error

El cargador de arranque LILO fue mencionado por primera vez en el Capítulo 9, por lo cual deberíahaber una firme comprensión de qué hace el cargador Linux (LILO) en un sistema Linux. Elcargador de arranque LILO es la primera pieza de código que toma control de proceso de arranquedesde el BIOS. Carga el kernel Linux, y luego cede el control enteramente al kernel Linux. Haymuchas instancias que ocasionarán errores de arranque de LILO. El sistema BIOS para la mayoríade las computadoras impulsadas por el procesador x86 fue diseñado en primer lugar para sistemasen los cuales la capacidad del disco rígido era de meramente 40 MB. Para estos sistemas, losprogramas y sistemas operativos de 32 bits o incluso de 64 bits que se están haciendo disponibleseran cosa de fantasía y ciencia ficción. No obstante, hoy sabemos que la tecnología de hardwarede computadoras evolucionó a velocidades sorprendentes, y como resultado la tecnología BIOS haevolucionado también. Los cambios en la tecnología combinados con las necesidades de LILOpueden desafortunadamente conducir a que LILO no funcione apropiadamente. Cuando LILO nofunciona correctamente puede ser frustrante porque usualmente significa que el sistema noarrancará. Los mensajes de error o códigos que produce LILO pueden ser difíciles de interpretar.Comprender cómo arreglar y sortear estos problemas puede ayudar a reparar el error de LILO yregresar el sistema a un orden funcional. Es importante que se comprenda cómo se instala yconfigura LILO antes de proceder con esta sección, así que podría ser una buena idea repasar lasección en particular del Capítulo 9. También es importante mencionar que incluso aunque otroscargadores de arranque pueden usarse para arrancar Linux, LILO se trata aquí porque es el que seusa en los sistemas x86. Éstos son los sistemas que se usarán en este curso y es el cargador dearranque que se instala en este curso. LILO no se usa en sistemas procesadores no x86.

El primer paso en la comprensión de los errores de arranque de LILO es poder comprender einterpretar los diversos códigos de error de LILO que pueden generarse. Cuando hay un problemacon LILO, se mostrará un código de error. Algunos de los diversos códigos de error que puedenmostrarse se enumeran y explican abajo.

• Ninguno• L código-error• LI• LI101010…• LIL-• LIL?• LILO

NingunoSi no hay ningún código de error esto significa que LILO no se ha cargado. Esto puede deberse aque LILO no se instaló o puede haberse instalado en la ubicación equivocada. Verifique el archivo/etc/lilo.conf y asegúrese de que la configuración sea correcta, luego use el comando lilo parainstalar LILO. Para obtener una mejor comprensión de qué significan las líneas del archivo/etc/lilo.conf es una buena idea mirar la página man de lilo.conf, que también se muestra en laFigura . LILO puede haber sido instalado en una partición diferente, en cuyo caso esa particiónen la que está instalado LILO deberá hacerse la partición de arranque. Todos estos tópicos setratan en el Capítulo 9.

L código-errorEsto significa que LILO ha comenzado a arrancar pero no puede arrancar el cargador de arranquede la segunda etapa. El código-error generado es un número de dos dígitos que es generado porel BIOS. Los códigos que estos números representan se detallan en la documentación de LILO. Lamayoría de los códigos de error representan fallos de hardware como un disco rígido defectuoso o


22

una discrepancia en cómo LILO y el BIOS acuerdan tratar las direcciones de disco. Si el discorígido está defectuoso, tome las medidas apropiadas para confirmar si el disco rígido falló. Si lasconfiguraciones de LILO y el BIOS son diferentes en cómo tratan las direcciones de disco, haga loscambios necesarios en el BIOS o en el archivo /etc/lilo.conf.

LIEsto significa que LILO ha iniciado y los cargadores de la primera y segunda etapa se han cargado,pero el cargador de la segunda etapa no funciona. Este tipo de código de error es usualmente elresultado de los mismos síntomas que la condición L código-error.

LI101010…Esto significa que LILO ha sido cargado y se está ejecutando apropiadamente pero no puedelocalizar la imagen en el kernel. Este código de error usualmente se verá cuando un nuevo kernelse ha cargado o actualizado y el comando lilo nunca se usó para reinstalar LILO.

LILEsto significa que los cargadores de la primera y segunda etapa han sido cargados exitosamente yestán funcionando de manera apropiada. No obstante, LILO es incapaz de leer la información quenecesita para funcionar. Este código de error es usualmente el resultado de algún fallo en elhardware o incoincidencia en la geometría del disco entre LILO y el BIOS. Este problema puedearreglarse configurando o corrigiendo la opción necesaria en /etc/lilo.conf o haciendo los cambiosnecesarios en el BIOS. Un ejemplo del archivo /etc/lilo.conf se muestra en la Figura .

LIL?Esto significa que el cargador de arranque de la segunda etapa ha sido cargado correctamentepero se encuentra en una dirección incorrecta. Este problema puede ser ocasionado al mover/boot/boot.b, que es el archivo cargador de arranque de la segunda etapa, sin usar el comandolilo para reinstalar LILO o por una incoincidencia en la geometría del disco entre LILO y el BIOS.

LIL-Esto significa que la tabla descriptora del disco (/boot/map) está corrompida. Este problema puedeser ocasionado al mover /boot/map, que es el archivo del cargador de arranque de la segundaetapa, sin usar el comando lilo para reinstalar LILO o por una incoincidencia en la geometría deldisco entre LILO y el BIOS.

LILOEsto significa que LILO se ha cargado exitosamente y está funcionando. En este punto no deberíahaber ningún problema con LILO que haga que el sistema no arranque. Si el sistema aún noarranca apropiadamente en este punto, el problema reside en alguna otra parte, posiblemente en elkernel, sus controladores o archivos de configuración del sistema.

Note que la mayoría de estos errores son el resultado de que LILO no puede leer archivos que hansido modificados o movidos. Cualquier cambio en LILO que incluya el movimiento o cambio dearchivos debe seguirse por el comando lilo para reinstalar LILO para que cualquiera de loscambios tenga efecto. Otros medios para arrancar Linux sin LILO se describen a continuación.


23


24

13.2.2 Arranque de un sistema Linux sin LILO

Podría haber algunos casos en los cuales LILO no puede usarse en absoluto para arrancar lacomputadora porque ha fallado del todo. Cuando esto ocurre es necesaria otra forma de arrancarel sistema. Hay unos pocos métodos por medio de los cuales es posible arrancar el sistema sinLILO. Usar el Sistema de Arranque de Emergencia y usar un Disco de Arranque de Emergenciapara arrancar el sistema en lugar de LILO se tratan en las siguientes dos secciones. No obstante,podría probarse primero algo más simple. Hay unas pocas opciones enumeradas a continuaciónque pueden usarse.

• LOADLIN• Kernel "en crudo" en un diskette• LILO en un diskette

Estas opciones se tratan en más detalle en los siguientes párrafos.

LOADLINÉsta es una utilidad DOS que puede usarse para arrancar Linux. Esta utilidad usualmente vienecon los CDs de instalación y está ubicada en el directorio dosutils. Para usar LOADLIN use unapartición DOS o un disco de arranque DOS, una copia de LOADLIN.EXE, y una copia del kernelLinux. Primero arranque DOS y luego tipee LOADLIN VMLINUZ root=/dev/rootdevice ro, dondeVMLINUZes el nombre del kernel y root=/dev/rootdevice es el nombre de la partición raíz como/dev/hda1.

Kernel "en crudo" en un disketteEs posible arrancar Linux si el kernel Linux "en crudo" está escrito en un diskette. Si se elige estemétodo, copie el kernel al diskette usando el comando dd if=vmlinuz of=/dev/fd0, dondenuevamente vmlinuz es el nombre del kernel. Una vez que el kernel ha sido copiado al diskette,simplemente inserte el diskette en la unidad y encienda la computadora. Asegúrese de que el BIOSesté configurado para arrancar desde la disquetera. Hay otro paso necesario para confirmar queesto funcione. Primero configure el kernel para que sepa la ubicación de la partición raíz. Parahacerlo use el comando rdev /dev/fd0 /dev/dispositivoraíz, donde /dev/dispositivoraízes elnombre de la partición raíz. Tenga en cuenta que estos discos parecerán no formateados en DOSo Windows y no podrán montarse en Linux porque no tienen ningún sistema de archivos.

LILO en un disketteÉste es uno de los métodos preferidos porque es el más rápido. Es mucho más rápido que usar elmétodo de LOADLIN o el método del kernel "en crudo" en un diskette porque el kernel aún está enla computadora. Para poder instalar LILO en un diskette edite el archivo lilo.conf. La línea dearranque en el archivo deberá cambiarse a boot=/dev/fd0. Después de esto, tipee lilo para queLILO se reinstale. Tenga en cuenta que esta línea necesitará volver a editarse para instalar LILOnuevamente en el disco rígido.

Hay algunas reglas generales e información extra que es de ayuda al usar estas técnicas paraarrancar un sistema Linux sin LILO. La técnica de LOADLIN es generalmente considerada como lamás flexible porque permite la creación o modificación de un disco de arranque usando DOS,usando un kernel por defecto desde un CD de instalación Linux. El método de kernel "en crudo" enun diskette es una técnica simple porque no requiere ninguna configuración para que sepa dóndese ubica la partición de arranque. No obstante, si la configuración del sistema cambiaespecíficamente dónde está ubicada la partición de arranque del sistema, será necesario hacermodificaciones en el kernel del diskette. Si esto no se hace el sistema no arrancará con laconfiguración del disco. Usar el método de LILO en un diskette es el menos útil pero puede ayudaren algunos casos. Por ejemplo, algunas personas prefieren configurar la partición de arranque para


25

que arranque en un sistema operativo no Linux. Entonces cuando el sistema necesita arrancarse aLinux todo lo que necesitan es insertar el diskette que tiene LILO en él. La Figura muestra unejemplo de la página de configuración de LILO que se presenta al usuario durante la instalación.Desde esta pantalla un diskette de arranque LILO puede crearse que puede usarse para arrancarLinux desde LILO usando el diskette.

13.2.3 Sistema de arranque de emergencia

Linux proporciona una copia del sistema de emergencia de LILO, que puede usarse para arrancarLinux en el caso de que el cargador de arranque LILO tenga errores o no esté funcionando. Esto seconoce como Sistema de Arranque de Emergencia. Para poder usar esta copia de LILO debenefectuarse cambios en la configuración en lilo.conf. Los pasos a dar para hacer estos cambios sonlos siguientes.

• Primero, cambie el lugar donde la partición raíz de los discos regulares está montada. Serecomienda montarla en algún lado del sistema de arranque de emergencia como/mnt/std. La Figura muestra un ejemplo de la pantalla de configuración de la GUI en lacual se puede efectuar este procedimiento.

• Segundo, asegúrese de que el directorio /boot esté en su propia partición. Móntelo enlugar de o además de la partición raíz.

• Los últimos cambios de configuración que necesitan hacerse son cambiar las imágenes delkernel y otras opciones de arranque respecto a lo que es normal. Por ejemplo, las opcionesboot y root deberán señalar al disco rígido regular.


26

Una vez completos estos pasos necesita usarse el comando lilo para volver a cargar LILO. Si todose configuró correctamente, el cargador de arranque deberá instalarse a sí mismo normalmente.Es posible que esto no funcione. Si la versión de LILO que usa el sistema de emergencia esdiferente a la versión que está actualmente instalada en el sistema regular, la instalación de LILOpuede no funcionar. Si esto ocurriera use el método de LOADLIN, que se explica en la secciónanterior y luego reinstale LILO usando las herramientas regulares del sistema.

.

13.2.4 Uso de un disco de arranque de emergencia en Linux

Hay algunos otros casos en los cuales un sistema Linux no arrancará. Hay varias razones y erroresque pueden ocasionar que un sistema Linux no arranque, además de problemas de LILO. Porejemplo, el archivo /etc/fstab que se usa para mapear particiones al sistema de archivos puedenestar corruptos. Errores del script de inicio pueden hacer que el sistema se bloquee o se apague enocasiones. Otras razones incluyen un fallo en el disco rígido y reemplazo del disco desde unbackup. Todos estos son errores comunes que aparecerán en un sistema Linux de tiempo entiempo, y LILO no es responsable. Para sortear estos tipos de problemas y arrancar exitosamenteel sistema obtenga o cree un Disco de Arranque de Emergencia. Un disco de arranque deemergencia habilitará el sistema para que arranque sin usar ninguna parte de la partición principal.Los discos de arranque de emergencia pueden ser un único diskette que contenga una cantidadmínima de archivos del sistema con los cuales arrancar el sistema, o instalaciones Linux completasque están almacenadas en medios removibles de alta capacidad como CD-ROMs. Unadministrador de sistemas debe saber cómo crear apropiadamente un disco de arranque deemergencia para que puedan responder a las llamadas de resolución de problemas necesarias.


27

También es importante saber qué herramientas están en el disco y cómo usarlas para resolverproblemas apropiadamente en un sistema Linux que no puede arrancar.

Búsqueda de un Disco de EmergenciaHay varias opciones de las cuales escoger en lo que se refiere a buscar un disco de arranque deemergencia ya preparado para Linux, la mayoría de los cuales están disponibles para descargar deInternet. Los siguientes discos de arranque de emergencia de Linux son fáciles de usar y a menudono requieren configuración para usarlos. Algunos de los discos de arranque de emergencia máspopulares disponibles para Linux se enumeran a continuación.

Los Discos de Instalación de LinuxUno de los lugares más obvios para buscar es en los discos o medios de instalación que se usaronpara instalar el sistema operativo en primera instancia. La mayoría de las distribuciones incluyen unsistema de disco de arranque de emergencia al que se puede tener acceso como opción al cargarlos medios de instalación. Por ejemplo, al iniciar el programa instalador para cargar Red Hat Linux,el comando linux rescue se tipearía en el prompt lilo:. Si se usa una distribución diferente,consulte la documentación relativa a cómo usar el disco de emergencia incluido con los medios deinstalación.

Disco Raíz/de Arranque de TomEl nombre oficial para esta distribución de disco de emergencia es tomsrtbt, que significa "eldiskette de Tom, que tiene un sistema de archivos raíz y también es booteable". Éste puededescargarse de Internet y puede entrar en un único diskette. Es un sistema Linux booteablecompleto que solamente puede usarse desde la línea de comandos. La GUI no se soporta. Ésteviene en paquetes para DOS también. Para obtener una copia y averiguar más acerca del DiscoRaíz/de Arranque de Tom, diríjase a http://www.toms.net/rb.

ZipSlackEsto está disponible para Slackware Linux. Puede instalarse en una partición pequeña o en unaunidad removible como un disco zip porque los 100 MB de tamaño de este disco de arranque deemergencia es mayor que la capacidad de un diskette, que tiene solamente 1,4 MB. La ventaja detener una versión más grande de Linux que la que está disponible en un único diskette es que esmás fácil de personalizar con herramientas de backup comerciales y controladores para el kernelpersonalizados.

Demo LinuxÉsta es una de las mejores utilidades de disco de arranque de emergencia disponibles porque es lamás completa. Es más grande que los 100 MB de ZipSlack y debe quemarse en un CD-R. Elarchivo de 650 MB puede descargarse desde la web en http://www.demolinux.org. Ofrece unaversión completa de Linux con la cual trabajar que incluso permite que la X GUI se ejecute en lamayor parte del hardware de video.

SuSE EvaluationÉsta es muy similar a Demo Linux en que es de alrededor del mismo tamaño y debe quemarse enun CD-R. No obstante, ésta es una versión de evaluación de SuSE Linux que puede descargarsedesde la web en http://www.suse.com.

Tenga en cuenta que éstas son solamente algunas de las opciones disponibles para discos dearranque de emergencia de un sistema Linux. Para averiguar qué otras están disponibles diríjase ahttp://www.linux.org/dist/english.html. Esta página y la página web para Raíz/Arranque de Tomcontienen otros vínculos para encontrar distribuciones pequeñas y especializadas para usar endiscos de arranque de emergencia.

http://www.toms.net/rb

http://www.demolinux.org

http://www.suse.com

http://www.linux.org/dist/english.html


28

Creación de un Disco de Arranque de EmergenciaEn su mayor parte, los discos de arranque de emergencia que se mencionan antes seránsuficientes para cualquier propósito. No obstante, hay algunos casos en los cuales será necesariohacer un disco de arranque de emergencia personalizado. Por ejemplo, si el sistema en el cual setrabaja contiene hardware que necesita controladores especiales, o usa un sistema de archivosespecial, funciones de networking especiales, o cualquier otra configuración que no se soportaríanormalmente en cualquiera de los discos de arranque de emergencia comunes, necesitarán undisco de arranque personalizado.

La creación de un disco de arranque de emergencia personalizado puede ser una tarea fácil odifícil dependiendo de los requisitos del sistema que necesita arrancarse y cómo se enfoca la tareade crear el disco. El método más simple y recomendado para crear un disco de arranque deemergencia personalizado para adaptarse a las necesidades de un sistema informático individuales modificar uno de los discos de arranque existentes. El disco existente puede modificarse demodo tal que las funciones especiales que un sistema puede requerir puedan agregarse. El discode arranque ZipSlack es una de las mejores opciones a elegir al crear un disco de arranque deemergencia personalizado. ZipSlack actúa de manera muy semejante a una distribución de Linuxregular, no obstante le faltan algunas funciones como una GUI. ZipSlack también permite a unusuario recompilar su kernel, agregar cualquier herramienta necesaria, o configurar muchos otrosaspectos para adaptar al sistema Linux que necesita arrancarse. Otra función que hace deZipSlack una buena opción es que hay cierto espacio para hacerle adiciones en un disco Zip de100 MB. También es posible sacar cualquier programa que no será necesario lo que libera un pocomás de espacio. Otra opción sería usar un disco de Zip de 250 MB para guardar ZipSlack en elcual dejaría mucho espacio para cualquier programa adicional o cambios de configuración que seanecesario efectuar.

No se recomienda el uso de ninguna de las otras opciones de discos de arranque de emergenciapara hacer un disco de arranque personalizado por diversas razones. El disco Raíz/de Arranque deTom es demasiado pequeño para ello. Con este disco de arranque de emergencia entrando en unpequeño diskette de 1,4 MB, no hay mucho espacio para agregar nada o hacer ningún cambio.Otro problema es que porque estas distribuciones son tan pequeñas, muchos de los archivos deprograma ya han sido cambiados para optimizarlos para esta pequeña cantidad de espacio. Estohace el cambiar o agregar cualquier cosa un proceso muy difícil porque es casi imposible hacerlosin exceder el tamaño máximo en el disco. Las distribuciones que pueden quemarse en un CD sondifíciles para crear un disco de emergencia personalizado debido al hecho de que no se puedenhacer cambios en los archivos de un CD. Para hacer un disco de emergencia personalizado conuna de las distribuciones que se queman en un CD, el contenido debe copiarse en un disco rígidode un sistema funcional, y luego los cambios deben efectuarse antesde quemar el CD nuevamente.

Herramientas de RecuperaciónIndependientemente del disco de arranque de emergencia que se use, hay varios tipos deherramientas de recuperación que deberán incluirse que pueden ayudar en el proceso dereparación. La siguiente lista de herramientas de recuperación es relativamente estándar y seránprogramas de Linux familiares. Tenga en cuenta que en el caso de que el sistema en particular quese está arrancando con el disco de arranque de emergencia puede haber algún programa especialinstalado o configuración que puede requerir una herramienta de recuperación especial además deuna que se nombre a continuación.

ControladoresEs importante recordar que los controladores para cualquier hardware y sistemas de archivos queson soportados en el sistema Linux debe incluirse en el disco de arranque de emergencia. Puedeser difícil incluirlos a todos en una de las distribuciones que encajan en un único diskette porque loscontroladores tienden a consumir más espacio en disco que lo que se permite en un diskette.Incluir controladores para el hardware y los sistemas de archivos soportados es importante porqueserán necesarios para usar o resolver problemas en cualquier pieza de hardware o el sistema de


29

archivos después de arrancar el sistema con el disco de arranque de emergencia. Esto esparticularmente importante si el sistema tiene adaptadores SCSI y discos rígidos o algún otrohardware inusual.

Un editor de textosEs importante que alguna clase de editor de textos como vi se incluya para que los archivos deconfiguración puedan verse y editarse apropiadamente. Cada distribución de disco de emergenciadeberá incluir un editor de textos y vi es una buena opción porque no es muy grande. Algunas delas distribuciones más grandes de los discos de arranque de emergencia tienen editores de textosmás grandes de los cuales elegir.

Utilidades de DiscoEl disco de arranque de emergencia deberá tener las utilidades de disco necesarias como fdisk,mkfs, y fsck, que pueden usarse para formatear un disco rígido para poder instalar Linux en él.Las Figuras , , y muestran ejemplos de estas tres utilidades. Un disco de arranque deemergencia con estas utilidades puede ser valioso en el caso de un fallo en el sistema de archivoso un problema en el cual el disco rígido o las particiones necesiten borrarse y prepararse para lainstalación de Linux. La utilidad fsck puede usarse para reparar sistemas de archivos dañados.

Software de BackupSiempre es importante incluir alguna clase de utilidad de software de backup. Si un cambio oreparación a algunos de los archivos de configuración necesita hacerse podría ser una buena ideaprimero hacer un backup. La mayoría de las distribuciones mencionadas antes vienen con algúntipo de utilidad de backup como tar, restore, cpio, y posiblemente otras. Las páginas man de estastres utilidades se muestran en las Figuras , , y . En el caso de que se use un software debackup diferente, comercial o de terceros será necesario incluirlo en el disco de arranque deemergencia.

Software de RedTener software o utilidades de red incluidos en el disco de arranque de emergencia es necesario sinecesita establecerse una conexión de red. Algunas redes tendrán datos almacenados a los quepuede accederse mediante una conexión de red y descargarlos del servidor puede restaurar losdatos. Tanto controladores serán necesarios para el hardware de red que está instalado en elsistema como para el paquete de cliente o servidor de red.

Una última cosa que es importante mencionar acerca de arrancar un sistema con un disco dearranque de emergencia es que algunos métodos de disco de recuperación requieren funcionesinusuales para acceder a disco de arranque en sí. Por ejemplo, si se está usando ZipSlack desdeuna unidad zip, que está conectada mediante un puerto paralelo, debe arrancarse desde un kernelalmacenado en un diskette de arranque. Ese kernel debe incluir soporte para unidades zipparalelas.


30


31


32


33

13.3 Reconocimiento de Errores Comunes

13.3.1 Diversas razones para los problemas de dependencia de los paquetes

Las dependencias de los paquetes se trataron en capítulos anteriores, por lo tanto ya hay unacomprensión del concepto. Cuando un paquete está instalado en un sistema Linux podría haberotros paquetes que es necesario instalar para que ese paquete en particular funcioneapropiadamente. El paquete de dependencia puede tener ciertos archivos que necesitan estar ensu lugar o puede ejecutar ciertos servicios que necesitan iniciarse antes de que el paquete que hade instalarse pueda funcionar. En cualquier caso, este proceso usualmente se ejecuta sinproblemas. Linux a menudo notificará al usuario si está instalando un paquete que tienedependencias para poder instalarlas también. Hay algunas veces cuando este proceso no procedecomo debiera y ocurren problemas. Usualmente el problema se relaciona con dependenciasinsatisfechas o conflictos entre paquetes. Esto es más probable que ocurra al instalar paquetes dediferentes fabricantes. Como administrador de sistemas, es importante comprender cómoreconocer estos errores y saber cómo resolverlos apropiadamente.

Hay varias razones por las cuales dependencias y conflictos pueden surgir en un sistema Linux conpaquetes RPM, Debian y tarball. Solamente los paquetes RPM y Debian tienen la capacidad paranotificar al usuario sobre problemas de dependencia, tarballs no tiene esta capacidad. Unos pocosejemplos de eventos que pueden ocasionar problemas de dependencia y conflictos se enumeran acontinuación.

Librerías o programas de soporte faltantesEste problema resulta ser uno de los tipos más comunes de problemas que son la causa de lamayoría de los problemas de dependencia. Las librerías son un tipo de código de soporte quepuede ser usado por muchos programas diferentes en un sistema Linux. Todos los diferentesprogramas pueden usar las librerías como si fueran parte del programa en sí. Cuando o si laslibrerías faltan, los programas instalados no funcionan. Los paquetes de soporte funcionan demanera muy similar a las librerías. Por ejemplo, todos los programas de KDE se basan en unprograma de soporte llamado Qt, que es un programa de soporte sobre el cual están construidostodos los programas de KDE. Si el paquete de soporte Qt no está instalado ningún paquete KDEpuede instalarse usando RPMs.

Librerías o programas de soporte incompatiblesEs importante comprender que hay diferentes versiones de las librerías y programas de soportedisponibles. Estas diferentes versiones corresponden a las versiones actual y pasadas deprogramas instalados. Si una librería o programa de soporte está instalado necesita ser la versiónactual que corresponde a los programas que se están ejecutando en el sistema Linux. Es posibletener varias versiones de librerías y programas de soporte instalados, para permitir el soporte paraprogramas con requisitos competentes. Por ejemplo, si un programa requiere Qt 2.2, pero laversión Qt 1.4 está instalada, entonces es necesario instalar la versión 2.2. Recuerde mantener laversión 1.4 para que otros programas instalados todavía puedan ejecutarse.

Archivos o funciones duplicadosA veces dos paquetes diferentes incluirán los mismos archivos exactamente o un paquete que estáa punto de ser instalado incluirá archivos o funciones que pueden ya estar instalados en el sistema.Cuando esto ocurre, puede causar ocasionalmente que los programas no funcionen correctamente.

Encontrar la causa exacta de un error de dependencia de un paquete puede ser difícil. Puedehaber un mensaje de error que se produce que puede ser útil al determinar qué paquete estáocasionando el problema y a qué categoría pertenece el problema. A veces estos problemas nocausarán ningún daño pero algunos pueden ser muy reales y serios. Tener librerías y programasde soporte faltantes puede hacer que varios programas fallen y hacer que el sistema no responda.Al instalar paquetes RPM o Debian, el proceso de encontrar la causa exacta para el problema de


34

dependencia del paquete puede ser un poco más fácil a causa del mensaje de error que seproduce.

Tarballs no produce ningún mensaje de error cuando se ha detectado un error de dependencia depaquete. El problema solamente se verá cuando el sistema intenta ejecutar el programa. Por estarazón, el problema puede manifestarse inmediatamente y producir un mensaje de que es incapazde localizar una librería o archivo específico. Pueden causar que los programas se caigan o norespondan. Por esta razón, al instalar paquetes tarball, lo mejor es usar la opción "mantener-archivos-antiguos" [keep-old-files] para que no se sobreescriban archivos existentes. Usar estaopción permitirá al paquete ser desinstalado y restaurar el sistema a su condición defuncionamiento original.

13.3.2 Soluciones a problemas de dependencia de paquetes

Ahora que los diversos errores que causan los problemas de dependencia de paquetes se hanidentificado, es el momento de tratar los pasos a dar para proporcionar soluciones a problemas dedependencia de paquetes. Hay varias formas de proporcionar una solución, no obstante la correctaa tomar dependerá de la situación. Repase todas las posibilidades antes de tomar una decisiónacerca de qué enfoque adoptar ya que algunas soluciones funcionan mejor que otras. Algunas delas soluciones posibles que se tratarán incluyen la instalación forzada, modificación del sistemapara que cumpla con la dependencia, reconstrucción del paquete del problema a partir del códigofuente, y encontrar una versión diferente del paquete problemático.

Instalación ForzadaTal solución para resolver problemas de dependencia de paquetes es simplemente ignorar el


35

mensaje de error e instalar el paquete por la fuerza de todos modos. Aunque puede ser arriesgado,hay casos en que hacerlo es apropiado. Si el error está en un paquete en el cual el usuario hacompilado manualmente el código fuente, puede forzarse la instalación. Para forzar la instalacióndel paquete e ignorar dependencias fallidas con paquetes RPM, use el parámetro – nodeps Paraforzar la instalación sobre otros errores, como conflictos con paquetes RPM existentes, use elparámetro –forcePor ejemplo, la sintaxis para estos parámetros se muestra en la Figura .

NOTA:

The xxxxxxxx.rpm representa a cualquier paquete rpm.

También es importante notar que estas opciones de parámetros serán levemente diferentes paralos paquetes Debian. Los paquetes Debian están identificados por dpkg en lugar de rpm. Al usarpaquetes Debian use los siguientes parámetros mostrados en la Figura para forzar la instalaciónde paquetes.

NOTA:

Donde paquete es el nombre del paquete

Modificación del SistemaEl método correcto y recomendado para proporcionar soluciones a problemas de dependencia esmodificar el sistema para que tenga las dependencias necesarias para ejecutarse apropiadamente.Por ejemplo, si el paquete que se está instalando requiere una librería o programa de soporteactualizado entonces la versión actualizada debe instalarse. Si Qt 1.44 está actualmente instaladoy el paquete requiere Qt 2.2 entonces la versión actualizada debe instalarse. Localice la versiónactualizada en los CDs de instalación de la distribución si es ahí donde el paquete se estáinstalando. El CD de instalación deberá tener librerías y programas de soporte actualizados que lospaquetes requieren para esa distribución. Todo lo que necesita hacerse es instalar las librerías yprogramas de soporte desde el CD.

Hay unas pocas precauciones a tener en cuenta al adoptar este enfoque. Preste particular atencióna qué paquetes y modificaciones se están haciendo y asegúrese de que cualquier paquete y/oactualización que esté instalado esté de hecho pensado para la versión de distribución particularque se está usando. Por ejemplo, programas que usan librerías y paquetes de soporte para RedHat 6 no necesariamente funcionarán con las librerías y paquetes de soporte de Red Hat 7. Unpaquete que contiene actualizaciones para librerías y paquetes de soporte y se instala para unadistribución en particular tendrá determinados requisitos que lo hacen compatible solamente conlos programas de esa distribución específica. Si la distribución A (Red Hat 6) está actualmente enejecución, pero se instala una actualización que fue construida para la distribución B (Red Hat 7),los programas producirán un mensaje de error enunciando los problemas de dependencia quetienen en términos de los archivos, librerías y paquetes de soporte de la distribución B, cuandorealmente se están ejecutando en la distribución A. Las actualizaciones de la versión apropiadapueden de hecho no estar disponibles para la distribución A, pero si la versión de la distribución Bde librerías y paquetes de soporte está instalada; puede haber conflictos con los otros paquetesque ya están instalados en la distribución A. En algunos casos si las actualizaciones apropiadas noestán instaladas para la versión de la distribución correcta, en un principio no habrá problemas. Noobstante, podría haber problemas en el futuro cuando se instalen otros programas o cuando ladistribución particular de Linux que se está usando se actualice. Cuando ése es el caso, laslibrerías y paquetes de soporte incorrectos que fueron actualizados ya no serán reconocidos y enalgunos casos ni siquiera se podrán actualizar a la versión de la nueva distribución.

Esto puede parecer un tanto confuso pero es realmente un concepto simple. En otras palabras, siel sistema va a ser modificado de cualquier manera, como que las librerías y paquetes de soporte


36

están siendo actualizados, entonces es necesario asegurarse de que las actualizaciones correctasestén instaladas. Esto significa que si Red Hat 6 se está usando, las actualizaciones para Red Hat6 son las que deberán usarse y no para otra versión de Red Hat, como Red Hat 7. En el caso deque las actualizaciones no estén disponibles para la distribución que se está usando, podría seruna mejor idea simplemente actualizar toda la versión de la distribución. Hacerlo aseguraría quelas actualizaciones necesarias estén instaladas.

Reconstrucción del Paquete Problemático a partir del Código FuenteEn algunos casos puede ser necesario reconstruir el paquete a partir del código fuente si aparecenmensajes de error de dependencia. No obstante, es importante comprender que las condiciones dedependencia que resultan de necesitar hacerlo en oposición a otras condiciones de dependenciaen las cuales no sería necesario reconstruir el paquete en sí. Por ejemplo, algunas dependenciasson el resultado de las librerías y paquetes de soporte que están actualmente instaladas en lacomputadora, y no de los requisitos de los otros paquetes y software del sistema. Esto a menudoresulta cuando el software de un sistema Linux se ha recompilado. Cuando el software serecompila, esto hará que las dependencias para diversos programas cambien. Por lo tanto, esmucho más fácil reconstruir el paquete a partir del código fuente para sobreponerse a este cambioque lo que sería intentar instalar por la fuerza nuevos paquetes o modificar el sistema de cualquierforma.

Es realmente un proceso bastante simple reconstruir un paquete RPM. Para reconstruir un RPMllame al rpm mediante el comando – rebuild. La sintaxis del comando usado para reconstruir unpaquete RPM es como sigue.

Es posible reconstruir tarballs a partir del código fuente, no obstante es un proceso mucho másdifícil. En lugar de tener que ejecutar un comando simple como arriba, alrededor de diez diferentescomandos tendrán que introducirse para configurar los scripts de compilación, el software tendráque recompilarse, y después el software puede instalarse. También habrá algunos archivos deconfiguración que tendrá que editarse manualmente. Por esta razón es mejor no intentar haceresto con los paquetes tarball. En cualquier caso lea la documentación del paquete que viene con elmismo para obtener más información acerca del paquete.

# rpm rebuild nombrepaquete-version.src.rpm

nombrepaquete-version.src.rpm es el nombre del RPM que es necesario reconstruir. Este comandoextrae el código fuente y ejecuta cualesquiera comandos sean necesarios para construir un nuevopaquete o a veces varios paquetes. Dependiendo de la velocidad de la computadora y del tamañodel paquete que se está reconstruyendo, el proceso para recompilar el paquete puede llevar deunos segundos a unas horas. Una vez que el proceso está completo, habrá varios RPMs en formabinaria ubicados en/usr/src/nombredist/RPMS/arch, donde nombredist es el código querepresenta la distribución del sistema, como RedHat o OpenLinux. arch representa la arquitecturade la CPU del sistema, como i386, i586, x86, o ppc. Una vez que estos archivos se han colocadoen/usr/src/nombredist/RPMS/arch, pueden moverse a cualquier ubicación y luego instalarsecomo cualquier otro paquete RPM.

Otra cosa que es bueno saber si un paquete va a recompilarse para reconstruirlo es que seránecesario un compilador apropiado para el software. Esto vale para cualquier tipo de paquete quese esté recompilando (RPM o Tarball). Usualmente el Compilador C de GNU (GCC) funcionarábien. Algunos programas también necesitarán tener instalados los archivos de encabezadoapropiados instalados, para que recompilen apropiadamente. Éste es usualmente el caso para lamayoría de los programas basados en X. Los archivos encabezado son archivos especiales que senecesitan al compilar un programa para que el programa use las librerías y paquetes de soportecorrectos. En algunos casos varias librerías pueden instalarse en un sistema Linux y el programanecesitará saber cuál se supone que use. Los paquetes de archivos encabezado pueden instalarsecomo cualquier otro paquete, no obstante, es necesario que los archivos encabezado que se


37

instalen coincidan con la librería que usa el programa compilado. Si las versiones del archivoencabezado no coinciden con las versiones de la librería entonces no compilará o no funcionaráuna vez compilado.

Reconstruir un programa o paquete a partir del código fuente no es el método más fácil y nosiempre funciona. Hay varias razones por las cuales el programa puede no funcionar una vezcompilado. Los archivos encabezado apropiados pueden faltar, o el compilador apropiado y otrasherramientas de desarrollo pueden ser los equivocados o faltar del todo. Otras veces el códigofuente se basa en funciones que no están presentes en las librerías que se instalan en el sistema.Si cualquiera de estos problemas se identifican, aparece un mensaje de error cuando el sistemaestá recompilando el paquete. Si esto ocurre la mejor idea es intentar por otro medio arreglar elproblema de dependencia.

Búsqueda de una Versión DiferenteLa forma más fácil de arreglar problemas de dependencia de los paquetes es ubicar una versióndiferente del paquete que está causando los problemas. Otra opción es buscar una versión másnueva del paquete. También es posible buscar una versión más antigua e incluso otra opción seríausar la misma versión del paquete pero una construida para la distribución Linux específica que seestá usando. Para buscar otros paquetes que pueden sustituirse por alternativos visite RPMFind(http://www.rpmfind.net) o el sitio de listado de paquetes de Debian en(http://www.debian.org/distrib/packages). Estos dos sitios web pueden ser de ayuda en localizarversiones alternativas de paquetes a usar. Otras ubicaciones a verificar están en los CDs deInstalación y en el sitio Web o FTP de la distribución particular.

Esta opción usualmente funciona bien y es más fácil que reconstruir el paquete recompilando elsoftware. No obstante, un problema es que a veces el único paquete aceptable es el que nofunciona. El paquete puede contener características especiales que es necesario instalar o puedeser un patch que tiene como objetivo arreglar bugs importantes del software, en cuyo caso seríacasi imposible hallar un reemplazo. Otras versiones podrían no estar disponibles, así que en estepunto puede ser mejor simplemente probar un software diferente.


38


39

13.3.3 Errores de backup y restauración

Otro tipo de error común que es importante poder reconocer y resolver eficazmente son los erroresde backup y restauración. Proporcionar una estrategia de backup confiable será una de las tareasmás importantes de cualquier administrador de sistemas. Sin un sistema de backup confiable, losdatos de la compañía podrían estar en riesgo de verse comprometidos en cualquier momento. Estono solamente incluye datos valiosos y a menudo irreemplazables y/o costoso tiempo de inactividaddel servidor o Internet, sino también robo o falla, e incluso error humano. Una cosa cierta es queestos problemas no son completamente evitables. No obstante, con un estrecho y confiableprograma de backup y restauración implementado, estos problemas no son permanentes. Otracosa desafortunada e inevitable sobre los backups es que no son inmunes a los errores en sí. Esimportante comprender cómo identificar estos errores así como las soluciones a errores de backupy restauración para que estén listos para usar en caso de que se necesiten los backups. Tambiénes importante notar que el peor momento para descubrir que el plan de backup y restauración tieneerrores es cuando necesitan usarse en una situación crítica. Por esta razón siempre es buena ideaprobar los procedimientos de backup y restauración antes de un caso real en el que sea necesariousarlos.

Existen diversos métodos y tipos de medios disponibles para los procedimientos de backup yrestauración. Los backups a cinta son el tipo más común encontrado en un sistema Linux y otrosgrandes entornos de servidores a causa de su facilidad de uso. Y pueden reutilizarse una cantidadde veces hasta que se estropean. Por esta razón la mayoría de los problemas y soluciones de estasección se aplican a backups de cinta. Hay varias otras formas de hacer backup y restaurar losdatos como CD-R, CD-RW, DVD-R, DVD-RW, así como diversas tecnologías RAID que hacenbackup de los datos directamente a otros discos rígidos. Otra razón por la cual los backups de cintase usan a veces es porque las tecnologías RAID tienden a ser bastante caras. Los backups a cintaproporcionan un medio confiable y costeable para proporcionar una solución de backup. La primeracuestión a comprender acerca de los backups a cinta es que ahorrarán mucho tiempo y ayudarán aevitar errores de backup y restauración y que los backups a cinta deberán reemplazarse despuésde haber sido usados 100 veces. Esto evitará que se vuelvan poco confiables.

Los errores de Backup y Restauración pueden ocurrir en diferentes puntos. Algunos erroresocurren cuando el sistema está realmente llevando a cabo el backup. Esto significa que el backupdel sistema puede ni siquiera funcionar. Otras veces los errores ocurren durante el proceso derestauración cuando el sistema está intentando recuperar los datos. Algunos de los tipos máscomunes de problemas se enumeran a continuación.

Problemas con los ControladoresComo cualquier otra pieza de hardware del sistema, los dispositivos de backup necesitan tener loscontroladores apropiados instalados. Sea cuidadoso acerca de los diversos problemas con loscontroladores que se han tratado en este curso con los sistemas Linux. Usualmente el dispositivode backup a cinta EIDE/ATAPI o SCSI requerirá soporte de un controlador o adaptador de host. Silos controladores están instalados como módulos entonces los controladores o el dispositivonecesitan cargarse en la memoria cuando se lleva a cabo el backup, de otro modo el sistema seráincapaz de hacer cualquier backup.

Errores de Acceso a la Unidad de CintaUn dispositivo de backup a cinta usualmente usará los archivos /dev/ht0 o /dev/nst0 paraproporcionar acceso a la unidad de cinta. Un usuario raíz deberá poder usar estos archivos paraacceder al dispositivo de backup a cinta tanto para lectura como para escritura. Si por alguna razónno puede accederse al dispositivo, probablemente haya un error en los archivos de dispositivousados o en los archivos de controladores que han sido cargados.


40

Errores de Acceso a los ArchivosLos permisos de acceso a los archivos pueden ser algo complicado y los backups no sondiferentes. El tipo de backup que alguien puede hacer en un sistema Linux dependerá de qué tipode acceso a los archivos tiene. Por ejemplo, cualquier usuario podrá hacer backups de sus propiosarchivos porque tendrá acceso tanto de lectura como de escritura a ellos. No obstante, para poderhacer un backup de todo el sistema de archivos en la computadora una persona necesita teneracceso de lectura completo a todos los archivos. Ésta es la razón por la cual la mayoría de losbackups se hacen como raíz. Un usuario no raíz que está haciendo un backup podrá hacerlo de lamayoría de los archivos del sistema, pero no de los archivos de otras personas y ciertamente no dearchivos protegidos como /etc/shadow. Esto funciona de igual forma con la restauración de unsistema. Para llevar a cabo una restauración de todo el sistema el usuario necesitará ser raíztambién porque necesitará tener acceso completo de lectura y escritura a todos los directorios quese están restaurando. Solamente la cuenta raíz tendrá tales derechos de acceso a los archivos enun sistema Linux.

Errores de los MediosUno de los peores tipos de errores de backup es cuando el medio real desarrolla errores. A vecesel backup a cinta, CD-R, DVD-R, o unidad de disco rígido secundaria reales se dañan y cualquierintento por restaurar los datos no funcionará. Hay varias cosas que pueden dañar un backup acinta, CD, o disco rígido. Muchas veces el medio de backup se dañará cuando ha estado enalmacenamiento mucho tiempo. Éste es especialmente el caso cuando las condicionesambientales del cuarto de almacenamiento no son las apropiadas para un almacenamiento demedios de backup apropiado. Una de las peores cosas para cualquier tipo de medio de backup esun cuarto de almacenamiento que no tiene la regulación de temperatura o circulación de aireapropiados para mantener el cuarto en una temperatura confortable. Otra idea a prueba de fallossería hacer un backup de los medios de backup, en caso de que un medio falle, habrá otro.

Errores de Archivos No Encontrados [Files not Found]Éste es otro tipo de error que puede a veces estar asociado con hacer backup y restauración dedatos en un sistema Linux. En sistemas Linux, al restaurar los datos de los backups usando lautilidad de línea de comandos tar, ésta a veces será incapaz de restaurar archivos específicos.Esto se debe a que la utilidad de línea de comandos tar almacena archivos sin la / al comienzo, loque significa que al restaurar archivos con tar la / al comienzo no deberá incluirse al restaurararchivos y directorios específicos. (Si se usa el parámetro -P (-rutas-absolutas) con tar, ésta haráun backup de los archivos e incluirá la / al comienzo). Por esta razón se recomienda que el usuariosiempre se encuentre en el directorio raíz (/) al restaurar cualesquiera datos. Si el archivo que esnecesario restaurar no puede encontrarse pero ha sido incluido en el backup y está en el medio debackup, entonces usar el parámetro -t (-list) con tar enumerará el contenido y permitirá unabúsqueda manual del archivo. Esto puede consumir mucho tiempo y si hay muchos archivos en elmedio de backup, llevará mucho tiempo hacer la búsqueda. Una alternativa sería usar unaherramienta de compresión y backup más sofisticada que tar que proporcione funcionesadicionales de búsqueda cuando un archivo necesite hallarse manualmente. Algunas de estasfunciones adicionales incluyen cosas como un índice de los archivos del medio de backup, juntocon otras funciones que permitirán restaurar solamente los archivos seleccionados, lo cual evitarácosas como tipear mal el nombre de archivo y luego tener que buscar manualmente a través de unbackup entero sin encontrar el archivo.

Hay diversos tipos de errores que pueden ocurrir al hacer backup y restaurar un sistemainformático Linux. Estos errores pueden estar asociados con el proceso de backup en sí, elhardware involucrado en el procedimiento de backup, o el medio de backup. Por esta razón esimportante que después de haber efectuado cualquier backup o restauración de datos el backup orestauración se verifiquen también. En un sistema Linux es posible usar una opción de verificacióndel tiempo de backup que llevará a cabo una verificación justo después de que los datos se hanllevado a backup. Es posible que durante esta verificación algunos archivos se devuelvan conerrores, pero pueden ser archivos que han cambiado legítimamente y por lo tanto el mensaje de


41

error puede ignorarse. Muchos dispositivos de backup incluyen una opción de verificación queverificará los datos inmediatamente después de haber sido reescritos. No obstante, aún esimportante correr una verificación completa después de haber realizado un backup de todos losdatos.

Otras técnicas de verificación incluyen comparar la información en la unidad o backup contracualquier información de resumen disponible. Por ejemplo, después de una restauración esimportante verificar que los mismos paquetes estén instalados como antes comparándolos con labase de datos RPM. (Recuerde de capítulos anteriores que algunos administradores de paquetescomo Red Hat y Debian tienen bases de datos que almacenan información acerca de los paquetesalmacenados o instalados en un sistema Linux). Para ello, use el comando rpm -Va. Tenga encuenta que podría haber variaciones legítimas debidas al hecho de que algunos cambios puedenhaberse efectuado.

13.3.4 Fallos de aplicaciones en servidores Linux

Entre las muchas organizaciones que desarrollan normas para redes de computadoras, el Institutode Ingenieros Eléctricos y Electrónicos (IEEE) ha estado muy activo en la definición de normaspara LANs. A través de sus grupos de trabajo "802", que comenzaron a reunirse en febrero (mes 2)de 1980 (el "80" de 802), el IEEE ha publicado normas para las LANs más ampliamenteimplementadas. Éstas incluyen Ethernet Ethernet (802.3), Token Ring (802.5), redes de fibra óptica(802.8), LANs inalámbricas (802.11), y otras. El IEEE también ha definido una norma paraproporcionar control de errores y control de flujo sobre diferentes tipos de LAN en su especificaciónpara el Control de Enlace Lógico (LLC, 802.2).


42

Las normas para LANs del IEEE son ahora centrales para las LANs usadas hoy. Dispositivos comolas placas de interfaz de red (NICs) que se conforman a las normas IEEE permiten que equiposconstruidos y vendidos por diferentes fabricantes interoperen en la misma LAN.


43

13.4 Detección y Resolución de Problemas de Red

13.4.1 Pérdida de conectividad

A pesar de los mejores esfuerzos preventivos, es inevitable que un administrador encuentreproblemas en la red. Éstos van desde ralentizamientos graduales que molestan a los usuarioshasta una completa pérdida de conectividad en toda la red que hace que el trabajo de miles deempleados se detenga.

Todos los productos que se han tratado pueden usarse para detectar y resolver problemas de red.Puesto que la mayoría de las redes modernas corren en TCP/IP, varias utilidades de detección yresolución de problemas están disponibles en cada sistema Linux. Pueden usarse sin la necesidadde adquirir, instalar y aprender un producto de administración de red complejo y costoso.

Esta sección trata algunos conceptos básicos de detección y resolución de problemas, cómo usarlos archivos log en la detección y resolución de problemas y las herramientas y utilidades TCP/IPincluidas en la mayoría de las distribuciones de Linux. Esta sección también trata el uso de estasherramientas en la detección y resolución de problemas de conectividad de red. Finalmente, seproporcionan directrices detalladas para detectar y resolver problemas en la red, que pueden serusadas por un administrador de red para rastrear y resolver problemas de conectividad ydesempeño de la red.

El problema más básico del networking es la incapacidad de una computadora de comunicarse conotra. La pérdida de conectividad puede estar relacionada con el hardware y/o software. La primeraregla de detectar y resolver problemas es verificar la conectividad física. Esta explicación simplenunca debería pasarse por alto. Más de un profesional del networking ha pasado horasreconfigurando protocolos, reinstalando software, e incluso reinstalando el sistema operativo,solamente para descubrir que la razón por la cual la computadora no podía comunicarse a travésde la red era que el cable había sido desconectado de la NIC. Por lo tanto, antes de embarcarse enuna compleja misión de detección de problemas, asegúrese de que los cables esténapropiadamente enchufados en ambos extremos, que el adaptador de red esté funcionandoverificando la luz de enlace de la NIC, que las luces de estado del hub estén encendidas, y que elproblema de comunicación no sea un simple mal funcionamiento del hardware.


44

13.4.2 Error del operador

Otra causa común de problemas en la red es el error del operador. Tal vez la razón por la cual laestación de trabajo no puede ver al resto de la red es que el usuario inició sesión en la máquinalocal y no se conectó a la red. Asegúrese de que los usuarios estén usando el nombre de usuario ycontraseña correctos y de que sus cuentas no estén restringidas en una forma que evite quepuedan conectarse a la red. Por ejemplo, los tiempos de inicio de sesión podrían estar limitados ahoras de negocios en días de la semana, o el usuario podría estar restringido para iniciar sesiónsolamente desde una estación de trabajo especificada.

NOTA:

Una de las razones más comunes por las cuales la contraseña de un usuario no funciona esdebido a la naturaleza sensible al uso de mayúsculas y minúsculas en la mayoría de los sistemasoperativos. Presionar accidentalmente la tecla Bloq Mayús antes de introducir la contraseña haráque se la rechace.

Los problemas de hardware son relativamente fáciles de tratar una vez descubiertos. Losproblemas de software pueden ser mucho más difíciles de rastrear y remediar. La malaconfiguración del software es un responsable común. Las configuraciones de software podríanhaber sido cambiadas por la rutina de instalación de un programa recientemente instalado, o elusuario podría haber estado experimentando con las configuraciones. Archivos faltantes ocorruptos pueden causar problemas de muchos tipos, incluyendo problemas de conectividad dered. Los usuarios accidentalmente o a propósito, borran archivos, y picos de energía o apagados


45

abruptos de la computadora pueden dañar los datos de los archivos. Los virus también puedendañar archivos del sistema o datos del usuario.

Cualquiera sea el origen sospechado del problema, seguir un conjunto de pasos para cada caso deresolución de problemas asegura que todas las bases queden cubiertas. Las siguientes secuenciasde pasos de detección de problemas se recomiendan para una resolución de problemas eficiente.Aunque los primeros cuatro pasos podrían parecer de sentido común, muchos profesionales de redsaltean el paso 5, y pueden también no proporcionar feedback al usuario. La secuencia de pasosde detección de problemas mostrados en la Sección 13.4.4 se recomiendan para una resolución deproblemas más eficiente. Una vez arreglado el problema, creen que el trabajo ha terminado. Noobstante, los últimos dos pasos son críticos en un entorno de networking.

Después de pasar dos días detectando un problema y finalmente resolviéndolo, olvidar los detallesparecería imposible. Pero la vida de un administrador de red es una vida ocupada, y es probableque cuando el mismo problema vuelva a ocurrir, tal vez un año después, lo único que cualquierarecordará es que ocurrió antes y que el problema se resolvió de alguna manera. Documentar lospasos de resolución del problema no sólo ahorrará tiempo en el futuro, sino que también evitarámucha frustración.

Proporcionar feedback a los usuarios también es importante. Los usuarios deberán ser educadoscada vez que sea posible. Éste es un elemento clave en la prevención de problemas. El usuariopuede no parecer preocuparse por lo que estaba mal, una vez que ha sido arreglado. No obstante,la mayoría de la gente aprecia la información, especialmente si esa información puede ayudar acambiar sus hábitos o permitirles comprender qué señales de problemas buscar e informar antesde que el problema empeore. El feedback al usuario siempre deberá proporcionarse en un lenguajeque sea apropiado para el conocimiento técnico del usuario.

NOTA:

El feedback siempre deberá incluir instrucciones para el usuario si el problema vuelve a ocurrir. Sies una cuestión simple y el usuario puede corregirla, deberán proporcionarse instrucciones paso apaso, preferentemente por escrito.


46

13.4.3 Uso de utilidades TCP/IP

En las siguientes secciones, se examinan varias categorías de utilidades TCP/IP. Hay aquéllas queprueban la conectividad, aquéllas usadas para configuración, y aquéllas que proporcionaninformación que puede ser útil en detectar problemas de red.

Utilidades para Probar la ConectividadEl primer paso en detectar problemas en una conexión perdida es determinar si en realidad estáperdida. Usuarios de red menos experimentados pueden suponer rápidamente que son incapacesde conectarse a un sitio Web en particular con sus navegadores, cuando el servidor del sitio en sípuede estar caído.

La herramienta TCP/IP más común hallada en sistemas Linux, UNIX y Windows que se usa paraprobar la conectividad a otra máquina es el comando ping.

ping y pathpingLa utilidad ping significa Buscador de Paquetes en Internetwork [Packet Internetwork Groper].Este comando es una utilidad simple que envía un mensaje llamado Solicitud de Eco a unacomputadora de destino designada usando el Protocolo de Control de Mensajes de Internet(ICMP). La computadora de destino responde enviando una Respuesta de Eco ICMP.

El primer paso para verificar un problema de conectividad sospechado es hacer ping al host. Si laconexión a Internet podría ser el problema, un host confiable en Internet, comohttp://www.yahoo.com, es un buen blanco para el ping. Si se recibe una respuesta, la conexiónfísica entre las dos computadoras está intacta y funcionando. La respuesta exitosa también

http://www.yahoo.com


47

significa que el sistema que llama puede llegar a Internet. La Figura muestra un ejemplo desolicitud y respuesta ping.

El orden preferido en el cual ejecutar el test en TCP/IP es el que sigue.

1. Nombre del host El primer paso en verificar un problema de conectividad sospechado eshacer ping al host. Esto imprime el nombre del servidor de red. Si se recibe unarespuesta, la conexión física entre las dos computadoras está intacta y funcionando.

2. ipconfig Imprime la configuración TCP/IP actual. Los sistemas Linux/UNIX usan elcomando ifconfig más que el ipconfig. Anote la dirección IP y máscara de subred delservidor de red para una futura referencia. Si la dirección IP del gateway por defecto semuestra, anótela también.

3. Ping 127.0.0.1 Haga ping a la dirección loopback para ver si TCP/IP está instaladocorrectamente. Si aparece cualquier mensaje de error, es hora de eliminar y reinstalar elprotocolo TCP/IP en el servidor de red.

4. Ping a la propia dirección IP Esto prueba que TCP/IP puede comunicarse con eladaptador de red del servidor de red. La dirección IP del servidor de red se muestra en lasalida del comando IPCONFIG.

5. Ping al gateway por defecto Esto prueba que el servidor de red puede comunicarsedesde la red a otro sistema de la red, en este caso el router. La dirección IP del gatewaypor defecto o router se muestra en la salida del comando ipconfig.

6. Ping al host remoto Un host remoto es una computadora del otro lado del gateway pordefecto o router. Esto prueba que el router está haciendo su trabajo y envía el paqueteTCP/IP a un sistema informático del otro lado del router.

7. Ping al propio nombre IP Esto prueba que el servidor de red puede resolver su propionombre IP.

8. Ping al nombre IP del host remoto Esto prueba que el servidor DNS está funcionando yresolviendo el nombre IP de host de una computadora remota.

El comando ping puede emitirse usando la dirección IP del nombre de host DNS de lacomputadora de destino. La dirección IP deberá usarse para probar la conectividad. Si un ping pordirección IP tiene éxito, pero un ping por nombre no lo tiene, esto indica un problema con elservidor o la configuración de resolución de nombres (DNS). Tal problema podría ocurrir cuando ala computadora del usuario se le asigna una dirección IP estática, en lugar de obtener unamediante DHCP, pero no tiene un servidor DNS definido en el archivo /etc/resolv.conf. Cuando laestación de trabajo es un cliente DHCP, el servidor DHCP usualmente asigna la dirección delservidor DNS.

El término tiempo de ping se refiere a la cantidad de tiempo que transcurre entre el envío de laSolicitud de Eco y la recepción de la Respuesta de Eco. Un tiempo de ping bajo indica unaconexión rápida.

ping también puede usarse para probar si la pila TCP/IP está apropiadamente instalada yfuncional en la computadora. Para llevar a cabo la prueba, haga ping a la dirección de loopback127.0.0.1, a la cual se da el nombre de host localhost en el archivo /etc/hosts. Si se recibe unarespuesta, la pila está funcionando.

Una versión de línea de comandos de ping se incluye con las pilas TCP/IP de todos los sistemasoperativos Windows y con las distribuciones UNIX y Linux. En un servidor NetWare, se incluyendos versiones, que se cargan como NLMs (Módulos Cargables de Netware) en la consola delservidor.


48

Pathping se incluye con Windows 2000, pero no con Windows 9x o NT. Combina las funcionesde ping con aquéllas de tracert y proporciona información adicional que no muestra ninguna deesas utilidades. Con pathping, es posible detectar qué routers están causando problemas en lared y medir cuántos paquetes se pierden en un router en particular.

Rastreo de Rutas de PaquetesLas utilidades de rastreo se usan para descubrir la ruta tomada por un paquete hasta llegar a sudestino. La forma usual de determinar el enrutamiento de paquetes en sistemas UNIX es elcomando traceroute. La Figura muestra salida común de traceroute en un sistema UNIX.

traceroute muestra todos los routers a través de los cuales el paquete pasa mientras viaja através de la red desde la computadora emisora hasta la computadora de destino. Esto puede serútil para determinar en qué punto la conectividad se pierde o ralentiza.

Utilidades de ConfiguraciónLos problemas de conectividad a menudo resultan ser problemas de configuración. Tal vez ladirección IP asignada a la computadora no se encuentre en el rango de subred correcto, o tal vezla máscara de subred, el gateway por defecto, la dirección DNS, u otras piezas de información deconfiguración se introdujeron incorrectamente. Si cualquiera de estas entradas está equivocada, ose la borra accidentalmente, la computadora no puede comunicarse apropiadamente en una redTCP/IP.

ifconfig/sbin/ifconfig, estándar en todos los sistemas UNIX más modernos, permite la visualización yel cambio de configuración de una interfaz de red, como una dirección IP, dirección de hardware,dirección de broadcast, y máscara de subred asociadas a un dispositivo ethernet determinado.

netstatLa utilidad netstat puede usarse para detectar problemas en la actividad de red mostrando lasconexiones que se han efectuado hacia y desde el servidor. Usar el comando netstat mostraráconexiones TCP activas, puertos en los cuales la computadora está escuchando, estadísticasEthernet, la tabla de enrutamiento IP, estadísticas IPv4 (para los protocolos IP, ICMP, TCP, yUDP), y estadísticas IPv6 (para los protocolos IPv6, ICMPv6, TCP sobre IPv6, y UDP sobre IPv6).Usada sin parámetros, netstat muestra todas las conexiones TCP activas. La página man denetstat enumera todos los parámetros que pueden usarse.

netconfigLinux incluye la utilidad /usr/sbin/netconfig que permite a un administrador seleccionar laconfiguración IP DHCP, o especificar una dirección IP estática junto con la máscara de red,gateway y servidor de nombres principal asociados.

lsofAunque no es estrictamente una utilidad de networking, lsof puede identificar recursos relativos alnetworking y qué procesos pueden estar bloqueándolos. lsof (LiSt Open Files) enumerainformación sobre archivos que son abiertos por procesos en ejecución. Un archivo abierto puedeser un archivo regular, un directorio, un archivo especial de bloque, un archivo especial de carácter,una referencia a texto en ejecución, una librería, un stream, o un archivo de red (socket de Internet,archivo NFS o socket de dominio Linux/UNIX).

Windows NT y Windows 2000 - ipconfigEl comando ipconfig se usa en Windows NT y Windows 2000 para mostrar la dirección IP,máscara de subred, y gateway por defecto para los cuales está configurado un adaptador de red.Ver Figura para información más detallada, se usa el switch/all. La Figura muestra losresultados del uso del comando ipconfig /all en un servidor Windows NT.


49

Si la computadora se configura como cliente DHCP, dos switches adicionales pueden usarse conipconfig. El primero es /renew. Éste ocasiona la renovación del préstamo de la dirección IP. Elsegundo es el switch /release, que hace que la dirección IP se libere para que el servidor DHCPpueda reasignarla.

Otras Utilidades TCP/IPProbar la conectividad y verificar la información de configuración son los usos más comunes deTCP/IP al detectar problemas de red. No obstante, los sistemas UNIX incluyen herramientasadicionales, mostradas en la Figura , que puede usarse para reunir información específica.


50


51


52

13.4.4 Directrices para resolver problemas

Detectar y resolver problemas en una red requiere habilidades para resolver problemas. El uso deun método estructurado para detectar, analizar y tratar cada problema a medida que se loencuentra incrementa la probabilidad de tener éxito. La detección de problemas deberá efectuarsesiempre paso a paso. Las buenas habilidades para resolver problemas no son específicas delnetworking de computadoras. Consideremos la forma en que un doctor encara un problema médicocomplejo o la forma en que un investigador resuelve un crimen. Independientemente del campo,los pasos son similares.

Reunir informaciónUn médico toma una historia clínica y pide al paciente que describa los síntomas. Un detective dela policía hace preguntas a víctimas y testigos. Ambos se basan en sus propias observaciones ypodrían tener que referirse a libros u otros expertos para investigar hechos específicosinvolucrados en el caso. Un detector de problemas de red deberá aprender a escuchar cuando losusuarios describen sus experiencias. Las buenas preguntas son una parte esencial de reunir lainformación necesaria para diagnosticar el problema.

Analizar la informaciónAquí es donde la experiencia y el conocimiento entran en juego. Las causas posibles más obviasdeberán eliminarse primero. Si un paciente se queja de un dolor de cabeza, el doctor no comienzallevando a cabo cirugía cerebral, sino que primero considera los factores más simples a partir delos cuales los síntomas pueden originarse. A medida que se eliminan posibilidades, la búsqueda seestrecha.


53

Formular e implementar un plan de "tratamiento"Cree un plan para rectificar el problema. Todo plan deberá incluir un plan de contingencia, en casode que el primer intento no funcione. Proceda con el plan organizadamente. Intente solamente unasolución por vez.

Probar para verificar los resultados del tratamientoEs esencial que el éxito de las acciones de resolución de problemas se confirme. Es tambiénimportante verificar que la "cura" no tuviera efectos colaterales que ocasionaran problemasadicionales o diferentes.

Documentarlo todoLos detalles del problema y los pasos dados para corregirlo deberán registrarse, idealmente conuna copia por escrito archivada. Esta documentación del proceso de ensayo y error podría ahorrara un futuro administrador mucho tiempo.

Objetivos y prioridades realistas son críticos durante el proceso de resolución de problemas yoptimización de la red. Un análisis de costo-beneficio puede ayudar a determinar qué problemasdeberán tener precedencia. Los costos no son siempre monetarios. Aunque las prioridades puedendepender de problemas incluyendo presupuestos, eficiencia, presiones de tiempo y fechas deentrega, incluso la política interna pueden ser factores de costo. Detectar y resolver problemas esuno de los trabajos más difíciles del administrador de red. Es también el área en la cual un buenadministrador prueba lo que vale y se gana tanto su salario como su título.

13.4.5 Herramientas de diagnóstico de Windows 2000


54

Las herramientas de diagnóstico de red de Microsoft Windows 2000 Server incluyen Ipconfig,Nbtstat, Netstat, Nslookup, Ping, y Tracert, que son similares a sus contrapartes deWindows NT. Windows 2000 Server también incluye los comandos Netdiag y Pathping, que noestaban disponibles en Windows NT Server.

NetdiagEl comando de Windows 2000 Server netdiag ejecuta un conjunto estándar de pruebas en la redy genera un informe de los resultados. El comando netdiag de Windows 2000 Server no es partede la instalación estándar de Windows 2000 Server. Debe instalarse desde el CD-ROM deWindows 2000 Server desde la carpeta Herramientas de Soporte. El comando netdiag deWindows 2000 tiene una característica muy buena, puede usarse sin ningún indicador en absolutoy llevará a cabo un conjunto completo de pruebas en la red. Un especialista en hardware deservidores tan sólo necesita analizar la salida del comando netdiag buscando la palabra "Falló"para encontrar posibles problemas de red. Incluso aunque el comando netdiag puede usarse sinningún indicador, varios están disponibles. Los indicadores que pueden usarse con el comandonetdiag de Windows 2000 Server son como sigue en la Figura .

pathpingEl comando pathping de Windows 2000 Server es una combinación del comando ping y delcomando tracert. Los indicadores que pueden usarse con el comando pathping de Windows2000 son como sigue en la Figura .


55


56

Resumen

Detectar y resolver problemas en cualquier sistema operativo puede a veces ser un proceso muydifícil y llevar mucho tiempo. Usualmente involucra dar muchos pasos y diferentes tareas paraencontrar el problema. El primer lugar donde comenzar es aislar como causa del problema una detres categorías. Estas categorías son relativas al hardware, relativas al software, o relativas alUsuario. El siguiente paso lógico sería hacer una serie de preguntas para descartar aún másopciones en la búsqueda de la causa del problema. ¿Hay algún componente específico que parececausar problemas? Después de descubrir cuáles son los síntomas, ¿cuál podría ser la causa delproblema con esos síntomas? Para responder a estas preguntas es importante tener unconocimiento extensivo acerca de cómo funcionan los diversos componentes, cómo estáninstalados, y cómo configurarlos apropiadamente para un sistema Linux. Responder a estaspreguntas también significa que es necesario conocer cómo funcionan los diversos componentesdel sistema cuando están funcionando apropiadamente así como inapropiadamente.

Este capítulo trata muchos de los problemas comunes e importantes que pueden surgir en unsistema Linux. También trata diversos temas acerca de cómo identificar, diagnosticar y arreglarestos problemas comunes e importantes. ALgunos de estos problemas que se tratan en estecapítulo son errores de arranque de LILO, problemas y procesos de inicio y apagado, y diversosotros fallos de software y aplicaciones. Los síntomas y soluciones de todos estos problemas setrataron eficazmente en este capítulo.

Este capítulo también describe las diversas herramientas y recursos que están disponibles paraayudar a diagnosticar y proporcionar soluciones que son importantes tener al detectar y resolverproblemas en un sistema Linux. Por ejemplo, en este capítulo se trataron las diversas formas dearrancar un sistema sin LILO. Además, los diversos comandos Linux que pueden ser útiles al hacerel debugging de un sistema se mencionaron en este capítulo. En todo este capítulo y en este cursoentero también, diversos lugares donde ir y encontrar ayuda para resolver estos problemas se hanmencionado cuando es posible. Es imposible pensar que cualquier administrador de sistemastendrá la respuesta para cada problema que surge o que será capaz de arreglar todos losproblemas por su cuenta. Saber dónde encontrar ayuda para los problemas que no puedenmanejarse individualmente es importante porque incluso el más conocedor administrador desistemas se encontrará con problemas que no puede arreglar.

Capitulo 13 IT Essentials 2 Sistemas Operativos de Red - Español

Documents

Transcript of Capitulo 13 IT Essentials 2 Sistemas Operativos de Red - Español