sábado, 12 de noviembre de 2011

Resolución de problemas de DHCP en tarjetas de red.

En esta entrada, creada a partir de un problema cotidiano reciente, vamos a intentar solventar problemas relacionados con ordenadores clientes que no aceptan bien el protocolo DHCP sobre Windows y, por tanto, no navegan bien.

En primer lugar, explicaré el proceso APIPA, uno de los pilares básicos en las redes de Microsoft, creado para la simplificación de redes locales sin salida a Internet.

El proceso APIPA (Automatic Private IP Addresing) es un proceso por el cual una tarjeta de red, al conectarse a una red y detectar que no hay ningún servidor DHCP, se asigna a sí misma una dirección IP comprendida entre el rango 169.254.x.x, siendo X los valores que se asignará ella sola (sin colisionar con otros posibles ordenadores que estén conectados y con el mismo proceso) El proceso APIPA es ideal para cuando queremos tener una red sencilla entre dos ordenadores. No requiere de puerta de enlace ni servidores DNS y la conexión actúa entre dos nodos de red, así como la formación de redes locales sencillas.

El proceso APIPA se da en sistemas Windows 98 en adelante. Es un sistema sencillo, sin complicaciones, pero tiene algunos problemas de depuración. Es eficaz por una parte, pero ineficaz por otra. Sencillez y no complejidad, pero problemas para depurar errores presentes.

A veces, el proceso APIPA nos puede acarrear ciertos problemas, como por ejemplo que la tarjeta de red se ciña siempre a realizar el proceso APIPA aunque haya un servidor DHCP activo, por mero protocol de actuación. Ésto nos puede inducir a que pensemos que tenemos problemas con la interfaz o que nuestro ordenador está dando las últimas agonías. Pero no.

Pongamos un escenario no muy diferente de la realidad:

Tenemos un router ADSL y nuestro PC. EL router ADSL puede ser de cualquier marca o compañía, pero el ordenador tiene de Windows 98 en adelante (Para adaptarnos a los tiempos que corren, digamos por ejemplo un Windows 7). Conectamos el PC al router pero el proceso APIPA siempre interfiere y nos da fallo. La IP fija no funciona tampoco porque el proceso APIPA adquiere un fallo y se ciñe más al mismo que a la configuración que le intentamos poner.

Hay tres posibilidades:
  • APIPA se queda pillado y se ciñe siempre a ese protocolo.
  • El servicio de cliente DHCP está desactivado
  • La tarjeta de red tiene mal los drivers

Para solucionar el problema, debemos realizar dos sencillas operaciones:

En primer lugar, "tirar" el adaptador (Deshabilitar y volver a habilitar)
En segunda, interrumpir el proceso APIPA mediante la liberación de la IP y, después, renovar la dirección IP

Para realizar el primer paso, nos vamos a Conexiones de Red o Centro de Redes e Internet, varía según la versión de Windows que usemos. Una vez encontremos el adaptador, lo deshabilitamos y después lo volvemos a habilitar. Esto puede resultar un poco banal, porque, pensémoslo ¿Para qué reiniciar el adaptador si el proceso APIPA seguirá activo una vez lo activemos de nuevo? Por si acaso. En la informática, como en todo, nada es seguro y todo es probable.

Si el primer paso no solucionó el problema, podemos intentar el segundo.

Para ello, abrimos un Símbolo del sistema. En Windows XP y Vista es en Inicio > Ejecutar y escribimos cmd.

En Windows 7, en Inicio -> Todos los programas -> Accesorios -> Símbolo del sistema.

Una vez estemos ahí, introducimos el comando ipconfig /release para liberar la dirección IP del proceso APIPA. Una vez lo hagamos, el adaptador estará totalmente libre de direcciones IP y el proceso APIPA se cortará.

Dado que ahora la interfaz de red no tiene ninguna dirección de red, procedemos a pedir que consulte al servidor DHCP y que le dé un alquiler nuevo. Para ello, introduciremos el comando ipconfig /renew.

Si por algún motivo el adaptador siguiera sin renovar direcciones IP y se siguiera ciñendo a APIPA, podría ser que el servicio de Cliente DHCP de Windows esté desactivado. En este caso, en Ejecutar de nuevo, escribimos Services.msc para iniciar el programa gestor de servicios.

Si el servicio está desactivado, debe poner Detenido. Botón derecho sobre el servicio y Iniciar. Para establecerlo como automático, en Propiedades, y en modo de inicio, Automático.

Si el servicio DHCP está activado y aún así sigue dando problemas de éste estilo, podemos intentar reinstalar los controladores de la tarjeta de red. Para ello, en el Administrador de dispositivos.

Windows XP: Panel de control, Herramientas administrativas, Administrador de dispositivos
Windows Vista y 7: Panel de control, Hardware, Administrador de dispositivos

Seleccionamos nuestra tarjeta de red, y en propiedades, Actualizar controlador. Si sigue sin funcionar, Consultamos al fabricante los controladores o tiramos de Google para buscarlos y reinstalarlos. Para ello, en el Administrador de dispositivos, desinstalamos el controlador antes de instalar otro de nuevo, de lo contrario no lo realizaría.

Si sigue fallando aún realizando todo lo anterior, podría ser un problema de hardware. Consulta al vendedor para más información.

Fuente:
Experiencia realizada en clase
Algunos problemas cotidianos.

Nota: En unos días procedere a actualizar ésta entrada para hacer una edición más resuelta.

martes, 8 de noviembre de 2011

Recuperar la contraseña de superusuario (root) [Sólo emergencias]

 Las distribuciones basadas en UNIX tienen como particularidad que todas ellas comparten un usuario único y que tiene una total administración de los ficheros y de todas las configuraciones del sistema.
Dicho usuario es el llamado superusuario, superuser o comúnmente llamado root.
Cuando intentamos instalar algo nuevo en el sistema, sea cual sea, siempre hay que usar la clave de root para acceder, o que el usuario en el que estamos trabajando tiene acceso siempre que esté en el fichero /etc/sudoers. Aun así, siempre prevalecerá mucho más el superusuario root.

Aunque root sea un usuario especial, en ocasiones puede existir la posibilidad de que queramos acceder al superusuario y no recordemos la contraseña, bien sea porque hacía tiempo que no iniciábamos el sistema o bien para otros usos.

Por ello, existe un método para quitar la contraseña de root. Al iniciar el login de root, no pedirá la contraseña y será totalmente accesible al ordenador



Por defecto, al instalar un nuevo sistema operativo bajo Linux, el sistema operativo tiene deshabilitada la cuenta de root como tal. Sí se puede entrar como superusuario con el comando sudo bash, pero para entrar como usuario root se le debe asignar antes una contraseña con el comando passwd.

Importante: El método aquí explicado es para recuperar la contraseña. Cualquier uso del presente artículo de forma maliciosa es bajo su responsabilidad total. Cada cual es libre de usarlo como quiera, bajo su propio riesgo.

Pasemos a explicar cómo recuperar la contraseña.

(Pruebas realizadas sobre sistemas Ubuntu y CentOS. Trataré de verificar resto de 
sistemas)

  •  Con un Live CD: Los Live CD de ubuntu permiten al ordenador la capacidad de usar Linux sin modificar ni cargarse parte de espacio del disco duro. Asímismo, el disco Live permite también acceder al sistema de ficheros del disco duro, lo que nos lleva a que podemos modificar cualquier archivo del mismo sistema como si de root se tratara.

    Para eliminar la contraseña, debemos acceder a la carpeta /etc y buscar el archivo shadow. Dicho archivo guarda las contraseñas encriptadas de todos los usuarios del sistema. Generalmente, la contraseña aparece con encriptación, y, eventualmente, el usuario root será el primero. Ejemplo:
    root:$1$N9L1HjIf$.YbfoPCCZmrqemk4zwYUb4:13918:0:::::0
    
    - root: nombre de usuario
    - $1$N9L1HjIf$.YbfoPCCZmrqemk4zwYUb4: contraseña encriptada
    - resto de campos: algunos permisos sobre la contraseña (Hace cuantos días
    se cambió, cuántos faltan para cambiarla.
    Para restablecer la contraseña, hay que borrar el campo de la misma. Con Vim, Nano o
    cualquier otro editor, lo borramos. Debe quedar algo así:
    
    
    root::13918:0:::::0
     
    Guardamos el fichero y reiniciamos el ordenador. Ahora, cada vez que iniciemos el usuario
    root, se iniciará sin pedir contraseña. En el caso de pedirla, basta con pulsar la tecla
    Enter y entrar.
     
  • Entrando en el sistema en el runlevel 1 o single: El runlevel 1 o single es un nivel especial del sistema que permite realizar cambios como si de un un superusuario root se tratara. Para hacerlo más efectivo, se puede recurrir al mismo método que el que usamos para el Live CD, pero también podemos usar el comando passwd root y cambiársela. Para gustos los colores.

    Para entrar en el Runlevel 1 hay varios métodos. En artículos anteriores expliqué como realizarlo en CentOS.

    Para entrar en el Runlevel 1 en Ubuntu habrá que hacerlo a través del GRUB. Hacer el montaje de la unidad de sistema como rw y no como ro, y especificar al final de la misma línea el comando init=/bin/bash
Fuente:

Foros varios sobre Linux.
Experiencia de clase.
Trasteos con el sistema.

martes, 1 de noviembre de 2011

Niveles de ejecución en núcleos UNIX (Init)

En la mayoría de distribuciones basadas en el núcleo UNIX, así como los distintos sistemas operativos derivados, comparten entre sí la complicidad de ser sistemas multiusuario y multitarea. Dicha función también radica en que tienen el mismo proceso de carga de núcleo y sistema.

Dicho sistema de arranque puede ser alterable.

Los sistemas UNIX ofrecen varios niveles de ejecución de Kernel o INIT. Éstos niveles, también llamados Runlevel, ayudan a que un usuario elija qué nivel quiere iniciar: Si solo quiere interfaz gráfica, o línea de comandos, o quiere iniciar la línea de comandos con unos determinados servicios, o la interfaz gráfica con todo completo.

Los niveles básicos de ejecución (y los más extendidos) de un kernel Linux/UNIX son:

  • 0 : Nivel HALT. Es el nivel de apagado del sistema
  • 1 : Nivel monousuario. Se realiza para tareas de mantenimiento del ordenador.
  • 2 : Nivel multiusuario sin soporte de red, por línea de comandos.
  • 3 : Nivel multiusuario con soporte de red, por línea de comandos.
  • 4 : Nivel no ocupado. 
  • 5 : Multiusuario gráfico con soporte de red. Es el nivel 3 añadiéndole el Display o X-Server.
  • 6 : Nivel REBOOT. Reinicio del sistema.

    PD: Estos niveles pueden ser diferentes dependiendo de la distribución que se use. Éstos, por ejemplo, son los más extendidos en Red Hat, CentOS, Fedora, Ubuntu.
Los niveles de ejecución albergan también los servicios que ejecuta cada determinado INIT. Es posible que en el nivel 5 tengamos un servicio que no se ejecute en el nivel 3. Todo ello es configurable con el comando chkconfig. Con este método, podemos hacer un uso más selectivo de la memoria dependiendo del runlevel.

Existen dos métodos posibles para iniciar un runlevel en un sistema UNIX: Antes de la ejecución del Kernel o después.

(Probado en CentOS las siguientes variables. Confirmaré cuando tenga datos de otros sistemas operativos y sus variables)

  •  Antes del inicio del Kernel: Se modifica la línea de Grub del Kernel. Si por ejemplo la línea del Grub correspondiente al Kernel es tal como:

    Grub > Kernel (Línea de iniciación del Kernel) Número de init a iniciar

    Ejemplo
    para iniciar el nivel 3

    Grub > Kernel (Línea de iniciación del Kernel) 3

    Éste método viene mejor para el nivel 1. Así, por ejemplo, si perdiéramos la contraseña del sistema, cambiado el nivel de ejecución podríamos asignarle una nueva sin pérdida de datos

  •  Después del inicio del Kernel: Una vez iniciado el sistema, sea en cual sea el tipo de inicio que se le haya transmitido, en una línea de comandos escribimos como superuser

    # init (nivel de ejecución)
Hemos aprendido a hacer que un runlevel nos funcione en el sistema de una forma fácil e intuitiva, pero con una pequeña pega: Los anteriores ejemplos solo sirven para ése inicio, con lo que el cambio de init es solo temporal. Una vez el ordenador reinicie seguirá ejecutándose en el predeterminado del sistema. Para cambiar este parámetro y, por ejemplo, ejecutar siempre la línea de comandos o cualquier otro nivel:

(Sistemas CentOS)
  • Entramos como superuser en el sistema
  • En la carpeta /etc, buscamos el archivo Inittab
  • Con Vim, Nano o cualquier otro editor de texto, Modificamos la línea por defecto.
    # Default runlevel.
    id:X:initdefault:

    Donde X es el número de init a arrancar.
  • Guardamos. Una vez reiniciemos el sistema, arrancará en el INIT que hayamos pedido como predeterminado.
(Sistemas Ubuntu)

  • Entramos como superuser en el sistema
  • En la caperta /etc/init, buscamos el archivo gdm.conf
  • Con Vim, Nano o cualquier editor de texto, Añadimos después de la línea "start on", en los paréntesis, runlevel [3], debiendo quedar algo tal como

    start on (runlevel [3] ...).

    Si queremos deshabilitar por completo el entorno, en vez del anterior, agregamos el siguiente

    start on (runlevel [ ] ... )
  • Guardamos y reiniciamos el ordenador. 
Nota: Antes de modificar cualquier fichero de éste tipo, debemos hacer previa copia de seguridad, para por si acaso fallase y podamos tener un fichero de restauración del sistema.
    Fuente:
    Experiencia realizada en clase.
    Wikipedia y su sabiduría