introducción:

El sistema de empaquetado de Redhat Packet Manager (RPM) es uno de los más famosos y es utilizado o soportado no solo por Red Hat hoy en día. Por ello es interesante prestarle atención a este… por eso y porque… vamos porque cae en el examen Sin más preámbulo vamos a ello:

RPM Overview

La función de los paquetes de RPM es la misma que los deb de Debian, básicamente automatizar la instalación de paquetes metiendo en un solo sitio el programa, la documentación, la configuración e indicando las dependencias. Para manipular estos paquetes usamos la orden rpm que mantiene una base de datos los paquetes instalados y los ficheros. Este sería al equivalente a dpkg en debian. Estos paquetes al igual que en Debian tienen una estructura, veamos como es esta:

• Nombre del paquete, sin espacios, normalmente se suelen usar los guiones en lugar de espacios.
• Version: indica la versión de cada paquete, las versiones suelen ser numéricas y la estructura: major.minor.patchlevel
• Revision, es una etiqueta que indica el número de revisión, solo se tiene en cuenta para controlar si una versión es más nueva que otra.
• Arquitectura, aquí se indica para que tipo de arquitectura esta compilado el paquete, no voy a entrar en detalles de las distintas arquitecturas.

Para el nombrado de paquetes todos estos elementos para formar el nombre, no obstante esto no es algo standard para el sistema RPM que recordemos no solo es usado para RedHat.

Running rpm
Como avanzaba antes el comando rpm es el equivalente a dpkg en debian que vimos ayer. Se usa para la gestión de paquetes. Con configuración entendemos instalación, desinstalación, configuración y comprobación de paquetes. RPM trabaja con distintos modos que se dedican a hacer cada uno este tipo de tareas, veamoslos uno por uno:

Install/upgrade mode: (-i)

Es usado para instalar nuevos paquetes. Dentro de este modo englobaríamos las variables -U para hacer una actualización, -F que sería equivalente al -U con la diferencia de que si actualiza paquetes con versiones antiguas si la versión instalada es más nueva o no esta instalado el paquete no hace nada. Pero hay que tener cuidado con la opción -F ya que no resuelve las dependencias. También son interesantes las siguientes posibilidades:

• –force fuerza la instalación de un paquete. Por ejemplo aunque haya un paquete más nuevo este será reemplazado por uno antiguo si lo forzamos.
• -h: mostrará 50 almohadillas a modo de barra de progreso.
• –nodeps: aun si existieran dependencias no las instalará
• –test simulará una ejecución, pero no hará nada, es usado para pruebas
• -v el modo ruidoso (verbose, no se me ocurre una buena traducción…)
• –v el modo super ruidoso (;))

Uninstall mode (-e)
Habéis adivinado este modo se usa para desintalar paquetes. Se usa típicamente en conjunción con las siguientes opciones:

• –nodeps desinstala sin comprobar dependencias. Esto tiene un problema y es que si desintalamos un paquete y este era dependencia de otros esos otros dejarán de funcionar, ojo con esta opción.
• –test para probar que pasaría, que más cosas se desinstalarían si desinstalamos ese paquete.

Query mode (-q)
En este modo preguntaremos información sobre los paquetes. Se usa normalmente con alguna de estas opciones:

• -a muestra una lista de todos los paquetes instalados en el sistema. Típica pregunta de examen es unir esto con un pipe y grep para comprobar la versión de un determinado paquete instalado.
• -f nombre_de_fichero : Muestra a que paquete pertenece un determinado fichero
• -p paquete : pide información de un determinado paquete

A partir de aquí estas opciones se usan en conjunción con las anteriores, digamos que para hilar más fino.

• -c Lista solo los ficheros de configuración
• -d lista solo los ficheros de documentación
• -i package : (ojo no confundir con el -i del modo de instalación) Muestra información de un paquete instalado. Es común usarlo en conjunción con el -p para “pedir” información de un determinado fichero.
• -l package muestra una lista de todos los ficheros contenidos dentro del paquete. También es común combinarlo con la opción -p
• -R Lista las dependencias del paquete.

Verify mode (-V)

Muestra información de los paquetes que pueden compararse con la configuración instalada actualmente.

Opciones típicamente usadas:

• –nofiles ignora los ficheros que falten
• –nomd5 ignora los errores de MD5
• –nopgp ignora los errores de PGP

Nota:

Se hace mucho hincapie con rpm en el examen y a veces caen preguntas de opciones raras y eso, os recomiendo darle un par de vueltas al comando probar cosas, leeros el man del comando y tratar de comprender y si tenéis tiempo de probar todo lo que aparece o al menos lo más importante.

YUM Overview

YUM son las siglas de Yellowdog Updater Modified, es el equivalente a apt-get en Debian. Lo normal cuando administramos actualizaciones y paquetes es hacerlo con esto y no con rpm y solo bajar al nivel de rpm para resolver situaciones concretas. Pero al igual que pasaba con Debian en el examen aquí también se tiene más en cuenta a rpm que a yum por lo que haremos más hincapie al primero aunque luego la frecuencia de uso sea al revés.

Al igual que apt-get tiene un sistema de repositorios y la configuración se encuentra en: /etc/yum.conf. Los típicos comandos con los que se usa yum son:

• install: para instalar un determinado paquete
• update: para actualizar uno o varios paquetes del
• erase: para borrar un paquete del sistema
• list: lista los paquetes instalados.
• search: busca paquetes según la cadena que le pongamos.
• info: muestra información en concreto de un determinado paquete.
• check-update nos informará de actualizaciones disponibles, pero no hará más.

Introducción:

Bien, tras el parón inesperado continuamos con el curso. Dejamos atrás ya los boot loaders y nos metemos de cabeza ya en la gestión de paquetes. Hoy estudiaremos como se gestionan los paquetes (programas) en Debian y mañana estudiaremos como se hace en RedHat. Como veréis ambos tienen un sistema de gestión de paquetes muy sencillo y potente que a mi en particular me hace que ame Linux de la forma que lo amé y lo amo. Pero antes de meternos en la gestión en general, entremos a mirarle las tripas a cada paquete:

Debian Package Management Overview

Los paquetes en Debian se llaman como tal ya que no solo contienen el programa en si, si no un paquete con más cosas, esto es el programa en si, los ficheros de configuración, la documentación y por último y muy importancia sus dependencias. Es importante comprender el concepto de dependencia. Esto es si queremos instalar el paquete frikipacket que sirve para procesar imágenes es posible que tenga dependencias. Es decir, que necesite otros paquetes sobre los que apoyarse y sobre los que funcionar correctamente, por ejemplo librerías.

Los nombres de los paquetes tienen la siguiente estructura:

• Nombre del paquete: El nombre es siempre corto y descriptivo, si el título esta formado por varias palabras suelen estar separadas por guiones.
• Número de versión: Esta versión va variando en cada revisión y aunque no esta fijado la estructura del versionado suele ser númerica siguiendo la siguiente metodología: major.minor.patchlevel.
• Extensión: Esta extensión es común para todos los paquetes en debian. Es siempre .deb

Managing Debian Packages

Bien, ya sabemos que son los paquetes en debian y que tienen dentro. Ahora vamos a ver como gestionarlos. Originalmente la herramienta para hacerlo es conocida como dpkg y se encarga de la gestión de paquetes de forma independiente, trata por tanto directamente con el paquete (el fichero .deb). Pero la gracia del sistema llega con sistemas como debian que tienen repositorios y satisfacen dependencias de manera automática, pero no nos adelantemos esto lo veremos en su correspondiente apartado dentro de unas pocas líneas. También trataremos otros dos comandos dselect (algo similar en parte a apt-get) y alien que nos permite instalar paquetes no debian en nuestro sistema.

dpkg
Como veíamos antes este comando nos permite interactuar directamente con el paquete. Normalmente a no ser que queramos cacharrear no tocaremos en exceso esta herramienta y por mi experiencia siempre que podais es mejor usar apt-get. Pero hay en ocasiones en la que no nos queda otra. Por ejemplo: instalar paquetes con distinta versión a lo que tenemos en el repositorio, forzar instalaciones, instalar paquetes fuera de repositorios o arreglar dependencias rotas y es que si, a veces apt-get se rompe y cuando lo hace da muchos quebraderos de cabeza. También se usa típicamente para listar paquetes instalados. Pero la principal razón por la que le prestaremos especial atención a esto es porque en el examen lo hacen! Y es que dpkg es de lo que más cae de esta lección en el examen muy por encima de apt-get y los otros comandos.

Vamos a ver el funcionamiento y sus opciones más usadas:

• -i la más típica, sirve para instalar el paquete que se le pasa como segundo parámetro.
• -r o –purge para eliminar el paquete que se indica a continuación.
• -S para buscar un paquete que contenga la cadena que le indicamos a continuación. Si en lugar de un paquete le pasamos un fichero nos indicará a que paquete corresponde dicho fichero.
• -s nos muestra información sobre un determinado paquete que le indicamos a continuación. Si esta instalado, tamaño y demás información.
• -l Nos muestra una lista de los paquetes instalados en el sistema. Si le indicamos una cadena después nos muestra los paquetes instalados que además tienen esa cadena. Aquí se nos muestra que versión esta instalada y tal. Esta opción sale muchisisisimo en los examenes.
• -L Nos muestra una lista de los ficheros que usa el paquete cuyo nombre indicamos a continuación.
• –configure ejecuta los scripts de configuración del paquete que indiquemos a continuación.
• –unpack desempaquetará el paquete pero no lo instalará en el sistema.

apt-get

Como adelantaba apt-get es un programa que sirve para automatizar la gestión de paquetes. Recuerdo en mis primeros tiempos en linux con una vieja Slackware cuando querías instalar algo el resultado solía ser, para instalar eso necesitas esos 3 paquetes y al ir a instalar esos paquetes estos te pedían otras 3 dependencias y la cosa llegaba a volverse una auténtica locura. Locura total ya si hablamos de dependencias cruzadas, pero no hablemos de batallitas…

Una de las ventajas de apt-get es que te resuelve el mismo las dependencias y si quieres instalar un paquete y este tiene dependencias y estos a su vez otras y al final resultase que tienes que instalar 28 paquetes te informará de ello y te dirá que si los quieres instalar todos y tu lo lo habrás resuelto tan solo confirmándolo.

Para esto en lugar de trabajar directamente con los paquetes lo hace con repositorios. Estos repositorios pueden estar en un cd aunque lo más habitual hoy en día es que estos repositorios sean online y que sean mantenidos y actualizados diariamente. De esta forma otra de las ventajas añadida, diría yo LA ventaja, es que con un solo comando podemos actualizar todos los paquetes de un golpe y plumazo. La configuración de estos repositorios se encuentra en: /etc/apt/sources.list

Veamos sus opciones de uso más típicas:

• install: instala el paquete que le indicamos a continuación.
• remove: borra el paquete que le indicamos a continuación.
• update: Actualiza la lista de paquetes y de versiones disponibles desde el repositorio.
• upgrade: actualiza todos los paquetes de los cuales haya nuevas versiones disponibles.
• dist-upgrade: Actualiza a una nueva versión de Debian (previamente debemos haber modificado el fichero del repositorio)
• -d para que solo descargue el paquete pero no quieras instalarlo.
• -s simula la orden pero no la realiza, sirve para ver que implicaría un upgrade por ejemplo.
• -y le contesta si a todo, ojito con esta opción que nos la puede liar!

Si vais a administrar máquinas con debian eventualmente os daréis cuenta de que estas opciones de apt-get se quedan un poco cortas por lo que os recomiendo echarle un ojo a su página de man, pero parece ser que para el examen con esto vas que chutas

dselect

dselect es poco más que una interfaz amigable y bonita para dpkg. En el libro de O’Reilly no habla mucho más de la herramienta y la verdad no le encuentro mucho sentido, no la he encontrado mucho en preguntas de examen y solo recuerdo que me salía hace años al final de la instalación de debian hoy en día ya no y llevo años sin usarla. Para mi que en la siguiente revisión de la LPI es posible que esto se vaya a tomar viento fresco…

alien

Este comando como adelantaba lo que hace es permitir instalar paquetes que no son de debian si no de redhat (rpm), stampede (slp), de Slackware o genéricos. Lo que hace Debian es generar una salida lo más parecida a Debian. Sinceramente nunca he usado la herramienta y siempre que he querido instalar algo que no estaba en los repositorios de Debian lo he instalado a mano, pero parece que ese tipo de instalaciones no se tocan en la certificación o al menos no en este examen.

Los comandos típicos parecen ser:

• -i para instalar
• -r para convertir el paquete a formato RPM (redhat)
• -t para convertirlo a formato tar

Lo cierto es que no tengo del todo claro que esto aparezca demasiado en el examen, pero echadle un ojo que no esta de más.

Introducción

Durante este tema hablaré del termino librerías compartidas no obstante es vital saber su nombre en inglés: “shared libraries” ya que es así como nos lo encontraremos en infinidad de sitios, como en la certificación en caso de hacerla en inglés. Una vez aclarado el asunto vayamos al lio:

En realidad el concepto de librerías compartidas es un concepto de bajo nivel que no se nos pide comprender del todo. Hagámonos pues una idea aproximada. Al programar una aplicación si usamos una función del sistema el codigo lo buscará entre las librerías que ya tiene el sistema. Una posibilidad y es que se haga un enlazado estático (copiandola). Esto es usar el código ya ejecutable de aquello que queremos usar. Esto lo hace muy rápido y cómodo pero básicamente muy poco eficiente. Para solucionar esto se usa lo que se conoce como linkado dinámico. Esto es que en lugar de copiar esa rutina ejecutable la usa y la comparte con otros programas que también la necesiten. Esto lo hace más eficiente. Esta es a mi entender una idea muy muy por encima del tema y la verdad es que yo me quedo también en la superficie y no se si he llegado a comprenderla bien pero en la documentación de Oreilly es lo que dice y por lo que he visto en examenes con saber esto vamos que chutamos

Dependencias de las librerías compartidas

cualquier programa que es linkado dinámicamenterequiere al menos unas pocas librerías compartidas. Si estas no existen o no pueden ser encontradas el programa fallará al ejecutarse. Lo que deberemos hacer por tanto es instalar las librerías adecuadas. El problema es a veces saber cuales son estas librerías, pero para esto existe la utilidad ldd. El uso de este comando no puede ser más sencillo ldd seguido del comando del cual queremos saber sus dependencias y como resultado nos dirá estas. En caso de que no tuvieramos alguna de ellas procederemos a instalarla y ya nos funcionará.

Enlazando librerías compartidas

El programa ld.so busca dependencias en los ejecutables que estan siendo cargados e intenta satisfacer sus enlaces no resueltos con librerías del sistema. Si no puede encontrar una adecuada fallará. Para buscar nuevas librerias ld.so debe buscar en /usr/local/lib y para que lo haga podríamos modificar la variable del sistema LD_LIBRARY_PATH pero lo suyo es configurarlo en ld.so para ello modificaremos el fichero /etc/ld.so.confy y añadiremos la ruta. Tras esto ejecutando el comando ldconfig recargaremos los nuevos links de librerias. Esta misma orden con la opción -p nos muestras los actuales links de las librerías.

Y esto es todo uno de los episodios que se tocan más de refilón del temario y a mi entender mal explicado en el libro de Oreilly. Si según sigo estudiando cosas aprendo nuevos conceptos que considere utiles para esto los iré añadiendo. No obstante como decía poco de esto cae en el examen yo creo que con comprender medianamente lo que es una shared librarie y saber que es, que hace y como funciona ldd y ldconfig la cosa va que chuta.

Introducción:

Cuando arrancamos linux desde el disco duro lo primero que ocurre es que la BIOS indica en que disco y en que partición esta el sistema desde donde arrancará. Después una vez ya en el disco existen dos fases: Cuando arranca el boot loader, que no es más que un programita en donde elegimos que kernel queremos arrancar y con que opciones de arranque y una vez seleccionado ya lanzará el kernel seleccionado y arrancará los procesos. Cuando comienza este punto el trabajo del boot loader habrá terminado, por tanto, lo que estudiaremos en esta lección será el primer punto del arranque, el que es responsabilidad del boot loader.

Todos los sistemas linux necesitan algún tipo de boot loader los más conocidos son LILO y GRUB que son los dos que estudiaremos a continuación:

LILO

Lilo es un boot loader que gozó de una grandísima popularidad hace unos años teniendo prácticamente el monopolio en los boot loaders. No obstante hoy en día practicamente ha desaparecido dejando paso a GRUB que estudiaremos después de este. No obstante sobre todo en sistemas antiguos aun nos lo encontramos por lo que es necesario conocer su funcionamiento. Y bueno en el examen normalmente suele caer al menos alguna pregunta de LILO así que razón más que de sobra para estudiarlo no?

The boot loader

El boot loader en si consta de dos partes por un lado en el sector de arranque se aloja una llamada al programa en si, ya que dicho sector es demasiado pequeño para alojar todo el programa en si. Es en esta segunda etapa cuando de una forma interactiva se lanza el LILO propiamente dicho que esta alojado en el disco duro. En este punto se nos ofrece un prompt que nos permite elegir la imagen del kernel que queremos iniciar así como pasarle opciones al kernel en boot time.

El prompt que se nos muestra aquí es:

LILO:

y en el podremos indicarle el kernel del que queremos arrancar así como los parametros mediante la tecla de tab podremos ir moviéndonos entre los kernels que tenemos instalados. El kernel por defecto tendrá al lado un asterisco, indicando precisamente eso que es el kernel que se iniciará por defecto.

Normalmente no es necesario elegir ningún kernel, ya que el arranque normal es hacerlo desde el kernel marcado por defecto. Pero en caso de querer usar cualquier otro kernel por cualquier razón puede cambiarse aquí para arrancar el que tu quieras.

The LILO command:

Es conocido también como map installer y es el comando que se usa para instalar y configurar LILO boot loader. El comando lee la configuración de un fichero y en el se indica donde estan las imagenes del kernel, la configuración del vídeo, el arranque por defecto y demás. Esto es por tanto un comando de nuestro sistema linux y como tal tiene su entrada en el man. Parametros interesantes son:

• -C confg_file carga una nueva configuración desde el fichero que se le indica.
• -m map_file crea un nuevo map_file donde se le indica
• -q muestra la configuración actual.
• -v el clásico verbose mode.

El fichero de configuración tiene esta pinta:

boot = ruta del dispositivo de donde de boot
timeout = tiempo que pasa hasta que arranca ese kernel
prompt si existe esta línea muestra el prompt al usuario
read-only el filesystem de root se monta en modo lectura en el arranque posteriormente puede montarse como se quiera
map = ruta del map_file
install = ruta del boot

image = ruta del kernel
label = nombre del kernel que se mostrará en lilo
root= ruta de la partición de arranque

La localización de LILO

Al instalar lilo puede se puede elegir si situar el kernel en el boot sector o en la partición de root. Si el sistema es solo para linux esta decisión es irrelevante si vas a correr más sistemas debes situarlo en el boot sector. No obstante para esta certificación se consideran instalaciones de linux sin convivir con otros sistemas operativos.

GRUB

GRUB es en la actualidad prácticamente un standard de facto y presenta la principal ventaja frente a lilo de ser mucho más flexible y tener un soporte mucho más completo a kernels y configuraciones más inusuales. Otra ventaja es que los cambios que realizamos tienen efecto inmediato, no siendo necesario andar ejecutando el comando para que tengan efecto.

Grub device naming

Una peculiaridad de grub es que cambia el nombre de los dispositivos lo cual si me preguntais a mi me parece un jaleo bastante interesante, pero seguro que tendrá s razón de ser. Grub se refiere a los dispositivos de la siguiente forma :

(xdn[,m])

la x varía en caso de ser disco duro (hd) o diskete (fd) y la n se refiere al número de disco según lo veo la BIOS, comenzando desde cero. La m de ,m se refiere a la partición dentro del disco de nuevo empezando desde cero. El uso de esto último es opcional y se usará solo cuando nos refiramos a particiones. Así pues (hd0) es el primer disco duro instalado y (hd0,1) es la segunda partición dentro del primer disco duro.

Installing grub

Para instalar grub lo más sencillo es ejecutar el script grub-install que irá seguido del disco donde queremos instalarlo. Lo que hace dicho script es mirar el map fil (/boot/grub/device.map por defecto) y lo mapea desde la bios por lo que arranca directamente desde ese fichero. Para editar la configuración modificaremos /boot/grub/device.map y ejecutaremos de nuevo grub-install. Pero esto solo en caso de querer remapear el map file con la bios. El map file tiene este formato:

(disk) /dev/device

Esta es la forma más comoda de instalarlo pero también se podría hacer a mano con el comando grub. Para ellos ejecutamos el comando grub y optendremos un prompt donde pondríamos por ejemplo:

root (hd0,0)
setup (hd0)

Esto hará que el arranque sea desde el primer disco y concretamente arranque la primera partición.

Booting grub

Si no hay fichero de configuración lo que obtendremos será simplemente un prompt. Para arrancarlo a mano tendriamos que hacer lo siguiente:

1. root device
2. kernel ruta_del_kernel [opciones]
3. initrd fichero (esto es opcional solo si es necesario un ramdisk)
4. boot

The grub configuration file

Aunque podemos hacer el arranque manual lo normal y lo conveniente es tener un fichero de configuración con el arranque ya precargado. Para ello editaremos el fichero /boot/grub/menu.lst o /boot/grub/grub.conf (redhat). Aunque esto último puede variar en función de tu distribución en mi debian esta en: /boot/grub/grub.cfg

El fichero de configuración tiene varias cosas, pero la parte importante del arranque es la siguiente:

default=0
timeout=3
title Linux
root (hd0,0)
kernel /vmlinuz-2.4…. root=/dev/hda2
initrd /initrd-2.4…img

Esta es una pequeña parte de las opciones en realidad todo lo que se puede hacer con GRUB es realmente abrumador. Estas opciones básicas son en realidad muy parecidas a las de LILO y creo que podréis imaginaroslas. Lo que quizá pueda parece más complejo es el tema de vmlinuz y de initrd, pero de momento por lo que he visto no es algo que exijan en esta certificación de LPIC. Si os interesa yo os recomiendo que busquéis manuales de como compilar el kernel compileis un par de kernels los configureis en GRUB para arrancar desde ahí y trastéis un poco. De esta forma es como yo en mis tiempos mozos aprendi todas estas cosas, todo sea dicho de paso a costa de cargarme mi máquinas unas cuantas veces (y no fueron ni dos ni tres esas veces )

Introducción:

Comenzamos la semana y con esto la segunda lección a mi entender una lección que sería mejor que viniera la primera antes de la anterior ya que aprenderemos como instalar el sistema desde cero y como gestionar los distintos paquetes instalados. No obstante entiendo el razonamiento del orden de estudio de la LPI ya que en la primera lección dabamos cuestiones de hardware que son al fin y al cabo las de más bajo nivel.

Y dicho esto comencemos con la lección propiamente dicha. De nuevo se hace hincapie en que vamos a estudiar instalaciones a nivel de linux en general no se trata de guías de instalación de ninguna distribución en concreto, se trataran temas generales. En cuanto la gestión de paquetería nos centraremos en la gestión de paquetes en Debian (lección 4) y la gestión de paquetes en RedHat (lección 5). No nos olvidamos del boot manager (lección 2) ni de las librerías (lección 3). Vamos pues con el tema de hoy en el que hablaremos del diseño del layout del disco duro.

Al instalar un sistema Linux más allá de la decisión del idioma del instalador alguna otra pregunta lo primero a lo que nos enfrentaremos será al particionado del disco duro. Que estructura queremos que tenga esto. El particionado del sistema no es una cuestión meramente organizativa si no que dependiendo del sistema que queramos montar será conveniente hacerlo de una determinada forma o de otra. Y es precisamente lo que estudiaremos hoy. Comencemos:

System considerations

Existen varias variables que haran que elijamos una estructura en nuestro disco duro u otra esas son: tamaño del disco, lo que ocupa el sistema, para que será usado el sistema y como se realizarán los backups.

Limited disk space

El primer escenario en el que nos encontramos es uno con espacio en disco limitado. Normalmente se tiende a tratar de conseguir dejar la mayor cantidad de espacio disponible en la parte del usuario, para que este pueda trabajar con mayor holgura. No obstante he de añadir yo que esto puede variar dependiendo de la función del sistema, en determinados sistemas es posible que el espacio reservado para usuarios prácticamente no se utilice. Cada administrador de sistemas debe valorar el uso de su sistema y tratar de elegir la opción más correcta. Pero algo en común de las instalaciones en discos con espacio limitado es el reducir al mínimo el número de particiones. Podríamos decir que el número mínimo para una buena instalación de linux es:

• /boot Es suficiente con una pequeña cantidad de megas, es necesario tener en cuenta que debe ser la primera de las particiones. Normalmente con un centenar de megas es más que suficiente y puede reducirse hasta 50mb.
• / el directorio raíz es donde se instala el sistema. Aquí depende mucho del sistema que queráis montar. Dado que los sistemas avanzan cada poco tiempo no creo que hagan preguntas en el examen en terminos absolutos. No obstante en la documentación nos dicen la cifra de 850mb. Pero yo ahora mismo tengo una debian base sin entorno gráfico con servidor LAMP y con poco más ya que no hay mucha tontería y sube ligeramente del 1gb de ocupación en disco. Esta partición es donde se guardará todo lo que no este en /boot
• swap Es un tipo de partición especial. En el libro de oreilly nos hablan de que si solo contamos con 1gb para la instalación dejaremos 100mb para la swap esto me parece totalmente obsoleto. Usualmente no suele dejarse una swap menor que el tamaño de la memoria RAM instalada.

Larger systems:

En estos sistemas ya tendremos discos más grandes y podremos planear estrategias de backup así como el fragmentar más la partición. En el libro de oreilly nos dan estos valores para un disco de 100gb:

• /boot 100mb
• swap 1gb
• / minimo 500mb
• /usr 4gb ya que aqui se guardan los ejecutables
• /var 2gb ya que aqui se guardan los logs de las distintas aplicaciones. Si se llenase la partición podría afectar a la estabilidad del sistema así que es mejor ir sobrados de espacio aquí.
• /tmp 500mb aquí se guardan los ficheros temporales. Conviene de nuevo que este separada y que sea grande ya que si el sistema no puede escribir en /tmp podríamos decir que afecta a la estabilidad del sistema, aunque es quedarse cortos ya que lo que suele ocurrir es que se bloquea la máquina.
• /home aquí iría el resto del espacio para los usuario, es decir 90gb

Muchas veces estos discos están replicados o estan montados en remoto y demás.

Nota propia: Encuentro que en este capítulo el libro de oreilly esta terriblemente obsoleto (a pesar de estar revisado en el 2009) y no termino de ver el sentido real de estudiar tamaños absolutos del disco. Personalmente me quedaría con los conceptos más que con las cifras, las particiones que es comveniente crear y y que particiones es conveniente que sean más grandes. Repito que dependiendo del sistema es muy posible que no necesitemos carpetas de home tan grandes, por ejemplo en un servidor web las carpetas de home a penas se utilizan. Entiendo que este layout esta pensado para servidores a los que accederán multiples (bastantes) usuarios. Una vez hecha la aclaración prosigamos.

Mount points

Los mount points son conocidos en español como los puntos de montaje. Para poder acceder a una partición es necesario que estos esten montados en un directorio y a esto se le conoce como mount point. Para poder montar una partición en un directorio primero tendrás que crearla y ya una vez creada montarla con el comando mount. Si no quieres montar la partición de forma manual será necesario que las incluyas en el fichero /etc/fstab con la sintaxis adecuada. Lo que haya aquí se montará en el arranque del sistema.

Superblock

El superbloque es un bloque que tiene cada filesystem que contiene la información metadata con la estructura de ese filesystem. La iformación que se incluye aquí es el tipo, el tamaño y el estado del filsystem montado. Dado que esta información es importante esta información se encuentra replicada y puede ser restaurada desde una de las copias en caso de que el superbloque se

MBR:

Son las siglas para master boot record, se trat ade un pequeño programa que contiene la información con las particiones del disco y la carga del sistema operativo. El MBR esta situado siempre en los primero 512 bytes del disco. En caso de dañarse el MBR será imposible arrancar, por lo que es más que conveniente guardar un backup de esto. Para ello podremos hacer uso del comando dd y clonar solo los primeros 512 bytes gracias a las variables count = 1 bs=512. La restauración del MBR se podrá hacer por tanto haciendo uso del mismo comando pero alterando el orden de los comandos.

Booting from a USB device:

Al igual que se puede arrancar desde un cd es posible arrancar linux desde un usb. Pero hay que tener en cuenta que los discos usb pueden ser modificados. Esto es muy util para tener un sistema portable que llevarte a donde quieras y además al arrancar desde aquí podemos montar los discos del ordenador dentro desde nuestro sistema arrancado desde el usb y usarlo para hacer troubleshooting.

Para poder arrancar desde el usb necesitamos hacer arrancable el usb para lo cual una partición debe tener el flag de bootable activado, así como activar el arranque desde este dispositivo en la BIOS.

System role

Como adelantaba anteriormente dependiendo de la funcionalidad que se le vaya a dar al sistema el layout que se elija para diseñar el sistema cambiará. Lo cierto es que hoy en día el almacenamiento se ha abaratado enormemente y no es el quebradero de cabeza que era antes. Personalmente mi consejo es mejor que sobre a que falte Además en la actualidad es muy viable tener datos cargados externamente por red por medio de sistemas NFS.

Backup

Es un hecho el que debemos implementar una política de backup en nuestros sistemas. Debemos ser capaces de poder recuperar el sistema en caso de que ocurra un desastre. El mejor backup sería aquel que cuenta que cuenta con todos los datos en todo momento y se pueden recuperar instantaneamente. No obstante este backup ideal no existe y siempre hay algún inconveniente.

Una posibilidad de hacer backup sería el uso del comando dd que ya hemos comentado anteriormente. Este comando hace un backup bit a bit de los datos de un disco/partición mediante us uso podemos clonar discos duros completos. También es posible hacer un backup de la estructura de las particiones mediante el comando “sfdisk -d /dev/disco_duro > particiones_bk.txt” . Para recuperarlas haríamos algo parecido pero en sentido contrario “sfdisk /dev/disco_duro < particiones_bk.txt"

Swap space:

Al instalar linux tendrás que instalar una partición de swap, esto es una partición para la memoria virtual. Para que nos entendamos esto es una memoria ram que se almacena en el disco duro, normalmente esto sucede cuando la memoria ram se agota. Historicamente la regla no escrita en linux era la de hacer una partición que fuera el doble de la cantidad de ram, sucede que con el aumento de la cantidad de ram en la actualidad muchas veces la swap se deja en el mismo tamaño que la ram o incluso en una cantidad fija que es a veces menor que la cantidad de ram. En sistemas de escritorio con grandes cantidades de ram se opta incluso por la desactivación de la ram, pero digamos que esto es algo muy extremo.

General guidelines

Ahora mi parte preferida unos consejos generales sobre este tema:

• Mantener el filesystem de root (/) lo más sencillo posible dividiendo fragmentando el resto tanto como sea posible.
• Hacer una partición a parte para la partición de /boot en bios y kernels antiguos es nesario que esta este por debajo del cilindro 1024
• Separar /var y así asegurarnos de que tenemos suficiente espacio para gestionar los logs, spools y los mails. Es conveniente ir rotando aquí los ficheros haciendo una copia de los más antiguos ficheros y borrandolos.
• Separar /tmp y así no correr el riesgo de bloquear el sistema porque tmp crezca desmesuradamente
• Separar /usr y asegurarse de que va bien de espacio ya que aquí estan los ejecutables y también entre otras cosas el kernel del sistema.
• Separar el /home así aunque tengamos varios usuarios podrán usar el sistema y aunque cambiemos de máquina o hagmaos un upgrade podremos consevar estos datos. Además así un usuario que crezca demasiado no nos bloqueará el sistema.
• El tamaño de la swap se recomienda que sea de 2 veces el tamaño de la memoria ram o si no al menos de igual tamaño que esta.

Conclusión:

Este libro de oreilly que estamos utilizando para seguir el curso es parte del grupo de los “in a nutshell” estos libros nos dan una visión global y no entran en los temas en profundidad. Esto tenemos que tenerlo en cuenta para ampliar los conocimientos en cada momento y no quedarnos en lo que dice el libro en todo capítulo. No obstante en este capítulo en especial me parece que esto esta bastante poco documentado y lo que hay es bastante antiguo. Personalmente os recomiendo leer un poco más sobre el tema y hacer varias instalaciones de linux para familiarizaros con esto. Os dejo a modo de lista unos cuantos caminos y rutas que deberías dominar para llevar bien este punto:

• fdisk
• /usr/local
• /opt
• /mnt
• /media
• gnu parted
• ext3, ext4, reiserfs, JFS, XFS, FAT, HFS, HFS+, UDF, NTFS
• mkfs -t

En realidad algunos de estos comandos, especialmente los últimos son utilizados y estudiados para lo que estudiaremos en el tema 4 por lo que podría parecer lejano, pero esta muy relacionado con esto y en mi opinión viene bien ir echándoles un ojo desde ya. Aunque ahora mismo este tema solo tenga como objetivos comprender la configuración de arranque creo que no viene mal ir ampliando un poquito.

El primero de los exámenes para la certificación junior de la LPI tiene un coste aproximado de 150 euros, lo cierto es que para el precio del mercado actual de las certificaciones no es un precio para nada elevado y es asequible para un profesional de Linux. El problema es si como yo te encuentras en ese momento desempleado que estas lo que se dice a dos velas.

Una opción de financiarlo sería currarme unas guías de estudio y cobrar por su suscripción, pero a mi personalmente no me parecen la forma y he optado por una financiación por donaciones. En la barra de la derecha veréis que ha aparecido un botón en naranja (naranja paypal) en el que dice “Donar”. Si pinchais en el os llevará a la web de paypal y con vuestro usuario y poniendo la cantidad que me donéis me llegará a mi. Cada vez que reciba una donación actualizaré una barra de progreso para que sepáis cuan cerca estoy de poder examinarme

No os pido grandes sacrificios económicos ni mucho menos, se que la situación no es boyante ahora mismo para ninguno. si el curso que estoy siguiendo a través de mi blog te ha sirve de ayuda trata si puedes de donar aunque sea 1 euro. Puede parecer una ridiculez pero con tan solo 150 personas haciendo esa ridiculez yo podría examinarme de esto. También podéis donarme 10 y acabamos antes eh Si queréis aparecer en agradecimientos indicadmelo en los comentarios indicandome al nombre, la web o la compañía a la que pondré en agradecimientos.

A que me comprometo yo con este curso? Lo primero a terminarlo, lo segundo a revisarlo, se que actualmente hay algunos fallos en alguna cifra o letra que me puede haber bailado y errores de formato y ortográficos que espero corregir cuanto antes. También a publicar todo bien maquetado y bonito gracias a mi amigo David en un pdf que espero que os sirva. Y por último no tengais duda que si me examino de este examen lo siguiente es el segundo. Así que si estáis deseando que empiece ya con ese, ya sabéis: “Show me the money!” Hahaha.

Espero que a nadie le moleste esto de las donaciones, recuerda que si no tienes interes en participar en ellas puedes ignorar esto y seguir con el curso sin ningún problema aun con todo tendrás los cursos, las correcciones, los pdf’s y todo

Por cierto la barra de progreso la podréis ver en la página de donaciones De momento la página esta a cero, pero os dejo una captura de como espero que se vea dentro de bien poco:

Introducción:

Esta lección particularmente me parece muy interesante porque aprendemos como funcionan los distintos runlevels (niveles de ejecución) en linux, para que sirven cada uno y como los podemos usar de una manera óptima. La cuestión de los runlevels es algo heredado de unix como tantas otras cosas de linux. Los runlevels indican que cosas se ejecutan en cada momento. Podríamos tener un runlevel en el que la máquina se comportase como servidor web y otro solo para administración. Los runlevels pueden modificarse a gusto del consumidor y son 7 desde el 0 hasta el 6. Veremos los usos por defecto que dan tanto la distribución de Debian como la de RedHat a estos runlevels:

Debian

• 0: Se trata de un runlevel especial, ya que es secuencial y se usa para parar el sistema (shutdown). Una vez termina de pararse el sistema se apaga de ahí que sea un estado secuencial.
• 1,s,S: Son distintos nombre para indicar lo mismo, que es el conocido como single-user mode también como conocido como de mantenimiento. Con este init tendremos un número de servicios mínimo levantado, no tendremos dispositivos de red, no se permitirá que se conecten usuarios que no sean root, etc. Este método se usa para hacer labores de mantenimiento en la máquina que requieran que esta permanezca lo más invariable posible durante este periodo.
• 2: Modo multiuser. Es el modo por defecto en Debian
• 3,4,5: Estos modos no son usados por defecto
• 6: De nuevo un estado transicional en este caso para reiniciar la máquina.

Redhat:

• 0: Igualito que Debian, modo shutdown.
• 1,s,S: Igualito que Debian, single-user mode.
• 2: Al igual que en Debian es el modo multiuser, pero no es el modo por defecto ya que no tiene activado ni compartición por NFS ni el modo gráfico.
• 3: Aquí si que se usa, es el sistema completo con todo funcionando salvo las X. Este es el sistema pordefecto de Redhat. (*ver nota).
• 4: Este runlevel no se usa por defecto.
• 5: Igual que el rulevel 3 (con todo corriendo) con la diferencia de que aquí se arrancan las X por defecto.
• 6: Igualito que Debian, modo reboot.

* Nota: En el libro de O’Reilly con el que me estoy documentando así lo indica, pero revisando la configuración de RedHat indica que la configuración por defecto es que arranque con init 5, es decir con X, pero no lo afirma categóricamente. De cualquier forma es configurable el runlevel por defecto como veremos más adelante. Por twitter el bueno de rhoml me chiva que esto en realidad depende del tipo de instalación que hagas, si haces una en modo gráfico te iniciará en runlevel 5 y si es en terminal te iniciará en runlevel 3, tiene mucho sentido la verdad

single-user mode

Merece la pena dedicarle un apartado en concreto a este runlevel por lo particular de este. Tenemos practicamente todo desactivado y por tanto como adelantaba en la introducción podemos hacer tareas que requieran no tener en el momento acticidad de usuarios. Algo típico de este modo es corregir problemas de corrupción de filesystems.

Para arrancar en modo single user mode podemos hacerlo de dos formas. Por un lado indicarselo al arranque mediante el paso de comandos en el boot como vimos en la lección de ayer, para ello tan solo tendremos que añadir a la línea de arranque por defecto de nuestro sistema el numero 1 o la palabra single detras. Otra opción es desde un sistema ya arrancado usar el comando init con el parámetro 1 detrás, es decir init 1. No es la mejor forma esta porque pasa automáticamente a este modo por lo que echa de golpe a todos los usuarios sin aviso previo, lo cual no es la mejor idea. No obstante la posibilidad existe y si queremos usar este modo sin necesidad de reinicio podemos usarlo, teniendo en cuenta que deberemos encargarnos antes de los usuarios.

Vistazo a la estructura del directorio /etc y al proceso init

Los runlevels explicados en la introducción son los conceptos, la organización pero no la configuración real de cada runlevel. Para ver esta configuración tendremos que ver varios ficheros que estan en el directorio /etc Lo malo aquí es que estos ficheros dependerán de cada distribución, aquí comentaré los mismos que el libro de O’Reilly los de ya que es cumple los “Linux standards Base (LSB)” que es lo que se estudia para esta certificación.

/etc/rc.sysinit o /etc/init.d/rcS
rc.sysinit es un script de inicialización monolítica. en Debian varia un poco ya que rcS corre varios pequeños scripts que estan en dos directorios. En ambos casos se lanzan en boot time. Estos son unos scripts que se encargan de cargar digamos las funciones básicas antes de que se levanten los demonios por ejemplo se encarga de montar los filesystems.

Veamos el funcionamiento práctico de Debian en esto con unas pruebas que he estado haciendo. Por cierto os recomiendo que hagáis vosotros pruebas de estas, que entréis en vuestras máquinas del laboratorio y os miréis los directorios /etc/rc* ya que hay cosas muy interesante y en general estan documentadas dentro de los mismos ficheros de configuración.

Básicamente /etc/init.d/rcS nos dice que cargara “/etc/rcS.d/” de forma númérica/alfabética. Si entramos en el directorio veremos los scripts que cargarán los servicios y un README explicándonos como activar o desactivar servicios. En serio echad un vistazo a estos directorios/ficheros es básico para el aprendizaje el hacerlo. Y dedicarle el tiempo que haga falta a esto, considero fundamental para corregir problemas y configurar el sistema apropiadamente comprender de una manera correcta la forma de arranque del sistema.

/etc/rc.local
No se usa en sistemas Debian, en RedHat si. Cuando ya estan todos los scripts y ya con todos los demonios por defecto inicializados se lanza. Contiene las personalizaciones locales que modifican los servicios ya lanzados. El sentido de esto es hacer las modificaciones aquí en lugar del rc.sysinit la razón de hacerlo así es que en los upgrades del sistema el rc.sysinit se sobre-escribe perdiendo estos cambios pero el rc.local se conserva.

/etc/rc
Este script que no existe en Debian se usa para cambiar entre distintos runlevels.

/etc/init.d
En este directorio se encuentran los scripts encargados de inicializar (start), reinicializar (reboot) y parar (stop) los demonios, entre otros. desde la carga de los distintos runlevels se llama a estos scripts pero tambien podemos invocarlos manualmente. Por ejemplo si queremos inicializar a mano el servidor de apache en Redhat usaremos: “/etc/init.d/httpd start”. También podemos tener los parametros de status y de reload en los scripts, es recomendable ver la documentación de cada demonio para entender que hace cada opción en concreto para cada demonio.

En la gran mayoría de los casos al instalar un paquete automáticamente se nos crean estos scripts. En cualquier caso podríamos añadirlos nosotros manualmente o realizar modificaciones en rc.local (recordemos que en en tan solo el caso de RH esto último).

/etc/rc0.d – /etc/rc6.d
Ya tratados por encima anteriormente, estos directorios en realidad no contienen ficheros si no enlaces simbólicos a los scripts de inicialización de /etc/init.d . De esta forma en caso de querer cambiar algo en el script de arranque de apache y este estar presente en los init 2, 3 y 5 en lugar de modificarlos en cada uno tan solo lo haremos en /etc/init.d . Cuando se carga un runlevel se cargan todos los scripts que esten dentro de esta carpeta pero con cierta restricción y es que los nombres de los enlaces simbólicos tienen una metodología especial. En caso de empezar por S se cargaran, pero si empiezan por K (kill) se matan. Si realizamos modificaciones y queremos cargar de nuevo el init con los cambios deberemos ejecutar el script: “update-rc.d “. También como parte de la política de nombres después de la S o la K irá un número secuencial, este indicará el orden en el que se ejecutarán el inicio o parada de los servicios. Este número puede repetirse y significará que esos demonios se pararán o inicializarán a la vez y una vez esten arrancados pasarán al siguiente número. Si renombramos esto podremos por tanto cambiar el orden de parada o de arranque.

Os recomiendo que veais la diferencia entre el directorio: “etc/rc2.d” y el “etc/rc6.d”. Vemos que en el 2 lo que se hace es inicializar los servicios y en el 6 como es para reiniciar vamos matando los procesos.

Configurando el runlevel por defecto

Bien, creo que ya tenemos todos claro que es un runlevel, como se utiliza y como se modifica. Nos falta por tanto saber como podemos cambiar el runlevel por defecto. Imaginemos que tenemos una RedHat que arranca en runlevel 5 lanzando por tanto el modo gráfico pero al ser un servidor nosotros no queremos ocupar estos servicios y preferimos por tanto arrancar en runlevel 3. Bien este cambio es realmente trivial, para ello tendremos que mirar el fichero “/etc/inittab”. Este fichero tiene bastantes cosas pero lo que nos interesa es lo siguiente”

# The default runlevel.
id:2:initdefault:

En este caso, al tratarse de una debian el runlevel por defecto es 1, si quisieramos cambiarlo a 1 (single user) sería tan sencillo como cambiar el 2 por un 1 y guardar el fichero. En el próximo reinicio arrancará en runlevel 1. En el ejemplo que planteabamos antes de cambiar un arranque gráfico a uno en modo texto en Redhat deberíamos cambiar la línea:

id:5:initdefault:

Por esta otra:

id:3:initdefault:

Conocer y cambiar el runlevel actual del sistema

Podría darse el caso en el que queramos saber en que runlevel se encuentra nuestro sistema, por ejemplo para comprobar si efectivamente nuestra máquina arrancó en single user-mode para así poder comenzar con la intervención que teníamos planeada. Para ello nada más sencillo, tan solo deberemos usar el comando “runlevel” sin parámetros. Este comando nos dará como salida dos valores, el runlevel anterior y el runlevel actual. En caso de que el anterior sea una N quiere decir que no ha habido cambio de runlevel. Supongamos que cambiamos como queríamos antes manualmente el runlevel en nuestra redhat de 5 a 3 para prescindir de esta forma del entorno gráfico, si ejecutásemos runlevel obtendríamos el siguiente resultado:

runlevel
3 5

No obstante con esto solo conocemos el runlevel actual nunca lo modificaremos, en caso de querer modificarlo tendremos que usar o bien el comando init o el comando telinit. Estos comandos son muy sencillos y son el mismo comando (en realidad telinit es un alias de init) y tan solo tendremos que pasarle como parametro el init al que queremos que pase el sistema. Por ejemplo si estamos en runlevel 5 y queremos pasar al 3 ejecutaremos “init 3″, si quisieramos apagar podríamos usar “init 0″ o “init 6″ para reiniciar.

Shutdown

Aunque podemos apagar y reiniciar la máquina mediante init o su alias telinit es más conveniente hacerlo mediante el comando shutdown. Son varias las razones de esto, la primera es porque shutdown avisa a los usuarios. Indicará a los usuarios que se va a reiniciar o apagar la máquina con un mensaje que es personalizable. En segundo lugar podemos fijar un tiempo de espera, podemos decir que la máquina se apague a una hora en concreto o pasado un tiempo, de esta forma podríamos hacer que nuestro ordenador deje de funcionar después de las 12 que ya no le necesitaremos o tras 10 minutos y así alertar a usuarios conectados y tengan tiempo así a guardar sus trabajos. Shutdown tiene una serie de opciones con las que ejecutarse que resultan interesantes, estan son:

• -f arranque rápido, en el siguiente arranque no comprobará los filesystems.
• -h después de parar todos los servicios la máquina se apagará.
• -k en realidad no se apaga pero manda el mensaje de apagado, esta opción es realmente una opción trollface O un poco BOFH si me permitis
• -r tras parar los servicios se reiniciará.
• -F es el contrario de F en el siguiente arranque le toque o no se forzará a una comprobación de los filesystems.

Para indicar el tiempo podemos usar lo siguiente:
+(número) número será el número de minutos tras lo cual se hará shutdown de la máquina
now: la máquina hará un shutdown en ese mismo instante
hh:mm la máquina hará shutdown a la hora indicada (con formato 24h)

Sobre runlevels en debian os recomiendo leer debianadmin. Sobre todo la parte final con el uso de “update-rc.d” que no se habla mucho en la documentación de esta certificación y lo considero interesante.

Y con esto terminamos el tema 1 donde hemos hablado de sistema y del arranque, la semana que viene tiraremos con el tema 2 que como bien podéis ver el índice trata sobre la instalación y mantenimiento de paquetes en Linux. Estoy tratando de tomarme en la medida de lo posible lo más en serio que puedo esto y por lo tanto he hecho un calendario para el tema 2 que podéis consulta aquí.

Por aportarle seriedad a esto y tratar de organizarme eficientemente y obligarme a mantener la regularidad comparto con vosotros el calendario planificado de las lecciones del tema 2 de la LPIC así podéis saber antes cuando tendréis las nuevas lecciones.

Tema 2: Linux installation and package management

• Lunes 22: Design hard disk layout (2)
• Martes 23: Install a boot manager (2)
• Miércoles 24: Manage shared libraries (1)
• Jueves 25: Use Debian package management (3)
• Viernes 26: Use RPM and YUM package management (3)

Así pues tenéis hasta el lunes 3 días en total para repasar el tema 1. Trataré de seguir esta tónica y dejar entre lección y lección al menos 3 días libres para que podáis repasar y para que os podáis reenganchar los que no estabais al día y así poder ir todos al mismo ritmo

Introducción:

Hoy a diferencia de ayer la entrada será bastante cortita por lo que será un día de estudio bastante light que os recomiendo que uséis para probar más cosas y repasar conceptos de ayer que el día estaba bastante cargadito. Hoy vamos a recorrer el sistema de arranque y aprenderemos a guiar al sistema durante este proceso en caso de que surgiera algún problema. Este tema guarda mucha relación con lo que estudiaremos mañana donde estudiaremos los runlevels que es a mi parecer donde esta la verdadera chicha del arranque. No obstante hoy tocaremos también temas interesantes así que no os perdáis ningún detalle.

Peso:

Este apartado tiene un peso de 3 sobre 4.

Comandos y directorios relacionados

• /var/log/messages
• dmesg
• init

Parámetros del kernel en boot-time

Por defecto los parametros con los que arranca el kernel estan configurados en el boot loader. En el caso de LILO en /etc/lilo.conf y en el caso de GRUB en /boot/grub/menu.lst o /boot/grub/grub.conf. Pero lo más interesante de esto es que también podemos mandar información mediante la línea de comando. De esta forma podremos indicar que arranque desde una participación distinta a la configurada por defecto.

Es importante dedicarle un tiempo aquí a estudiar los parámetros que podemos pasarle al kernel desde LILO y desde GRUB

Introducción a la configuración de módulos del kernel

Recuerdos de mis tiempos universitarios en el club de linux lo mucho que me gustaba compilar el kernel cada dos por tres para tener las últimas funcionalidades y todo lo más ajustado posible para que su rendimiento fuera el mayor posible. Hoy en día vamos sobrados de recursos y ya no suele ser necesario o no sale a cuenta andar recompilando el kernel en situaciones normales. Una cosa importante que aprendí es el uso de los modulos que hoy en día tanto se usan. Los modulos son partes del kernel que digamos que se cargan bajo demanda y se pueden usar o no en función de necesitarse o no. El soporte al sistema fat es por ejemplo un módulo y podremos “montarlo” en función de que vayamos a usarlo o no. Existe un fichero /etc/modules o /etc/modules.conf (dependiendo de la configuración) donde podremos poner los módulos que queremos que se carguen por defecto en el inicio.

Kernel boot-time messages:
Durante el arranque el kernel nos “escupe” muchos mensajes relacionados entre otras cosas con la carga de modulos. esta información en algunas ocasiones es muy interesante pero claro no siempre estamos delante para ver lo que pone o puede que pase muy rápido y no nos de tiempo a leerlo. Pero no os preocupéis como casi todo en linux esto queda “logueado”. Para ello tan solo tendremos que usar el comando dmesg esto nos escupirá toda la información de golpe para poder verla de forma paginada podremos usar dmesg | less o mandarla a un fichero y leerla desde ahí mediante el comando dmesg > fichero.txt. Si tenemos problemas con algún arranque el dmesg será uno de los primeros sitios donde miraremos a ver si “se quejó” de algo mientras arrancaba.

Revisando los logs:
Administrando un sistema linux una cosa que harás recurrentemente será comprobar los ficheros de logs. En estos ficheros se va almacenando con distinto nivel de detalle lo que ha ido sucediendo en el sistema guardando especial atención a los eventos relevantes como lo son por ejemplo los errores. Es por tanto muy útil a la hora de revisar problemas mirar los logs. En linux los logs se encuentran por ejemplo en /var/log/messages . Mucha de esta información no es mostrada por pantalla por lo tanto es posible encontrar problemas en el arranque que no se muestren en el dmesg. Más adelante estudiaremos más sobre estos ficheros de log.

Empezamos ya con la primera de las lecciones del estudio de la LPIC. Si bien no quisiera empezar sin hacer un pequeño disclaimer y es que no soy un formador ni ningún experto si no que soy un estudiante más que tiene la intención de ir escribiendo aquí lo aprendido, por tanto si véis errores os animo a reportármelos para así poder corregirlos y que todo el mundo aprender sin problemas. Y dicho esto comencemos a estudiar siguiendo el guión del libro que estoy siguiendo el de o’reilly

Peso:

Este apartado tiene un peso de 2 sobre 4.

Comandos y ficheros útiles

• lsmod
• lsdev
• lspci
• lsusb
• insmod
• rmmod
• modinfo
• modprobe
• /proc

Básicamente tenemos 2 grupos de comandos, en un primer lugar los ls* que lo que hacen es listar los dispositivos y el resto que sirven para modificar la configuración de estos. Lo mejor es que le echéis una ojeada a las páginas man (enlazadas más arriba) y que trasteeis los comandos en vuestras máquinas del laboratorio.

Introducción:

Hoy vamos a estudiar la parte del hardware que en muchos casos es la gran olvidada. Le pinchamos algo nuevo a nuestro servidor y que ocurre. En sistemas de escritorio estamos acostumbrados a cargar unos drivers en el caso de Windows o no hacer nada en MacOS. Linux ha avanzado una barbaridad en esto y en muchos casos funciona todo sin problemas. Si bien siendo administradores de un sistema linux debemos ser capaces de podemos detectar y configurar hardware de forma manual y es lo que aprenderemos a hacer hoy.

BIOS:

Comenzamos desde lo más bajo la BIOS. Esto no esta directamente relacionado con el sistema operativo ya que depende del hardware y por tanto dependerá de cada ordenador y cada fabricante, pero para este curso se requieren unos conocimientos generales básicos:

Fecha y hora:
Una de las labores de la bios es controlar la fecha y la hora y gracias a una pila en la placa mantener esta hora y fecha al día gracias a una pila. Esta parte se relaciona con el sistema operativo ya que este último es capaz de cambiar la hora y la fecha de dicha BIOS. Más adelante estudiaremos como mantener esta fecha al día gracias al servicio NTPD.

Discos y sistemas de arranque:
Otra de las cosas que podemos hacer en la BIOS es elegir el orden en el que buscará dispositivos de arranque el ordenador. Es decir que busque algo de lo que arrancar primero desde el ordenador, desde el disco duro o desde un USB. Esto guarda cierta relación los boot loaders que estudiaremos más adelante (LILO y GRUB) y también conviene que si no sabéis lo que es es el MBR (Master Boot Record). También conviene conocer las posibilidades de arranque desde red de ciertas placas base.

Usando el filesystem /proc:

En el directorio proc tendremos de forma estructurada todo el hardware que hemos ido instalando así como su configuración. Podremos usarlo por tanto para detectar problemas de configuración de hardware. Es recomendable que os perdais un rato en el directorio que contine información tan interesante a nivel de hw como un listado de las interrupciones, los filesystems, el dma, el estado de la cpu y un largo etcétera.

USB:

En los últimos tiempos el USB se va ha convertido en un dispositivo omnipresente en casi cualquier ordenador. Si bien es cierto que en entornos de servidor no son tan utilizados en entornos de escritorio nos las veremos tarde o temprano con alguno de estos dispositivos. Veamos como podemos gestionarlos en linux.

USB Topology
La topología USB se organiza por agrupadores (hub) desde los cuales cuelgan dispositivos. Para listar los dispositivos USB conectados usaremos el comando lsusb. Si nos interesa ver una visión más gráfica de como cuelga cada dispositivo de cada concentrador lsusb -t nos será de gran utilidad.

Controladores USB:
Más a nivel de hw los controladores se agrupan en tres tipos que son:

• Open Host Controller Interface (OHCI) -> USB 1.1 (12Mbps.)
• Universal Host Controller Interface (UHCI) -> USB 1.1 (12Mbps.)
• Enhanced Host Controller Interface (EHCI) -> USB 2.0 (480Mbps.)

Para poder usar la velocidad de los dispositivos USB 2.0 es necesario que nuestra controladora sea USB 2.0, si bien cualquier ordenador actual la tiene y es lo que se viene usando hoy en día. La documentación no esta actualizada aún a los nuevos estadares de USB 3.0.

Dispositivos USB:
Hay distintos tipos de dispositivos USB, en realidad nada que no conozcamos hasta ahora, que si teclados, ratones, micrófonos, discos duros, tarjetas de sonido, impresoras… No explican mucha novedad al respecto.

Drivers USB:
A partir de la rama 2.3.x del kernel el usb fue soportado y a posteriore se añadió en las versiones 2.2.x a partir de la versión 2.2.18. Los drivers son de tres categorías:

• Drivers de controlador host

Class drivers: Los dispositivos USB en si hid.0, usb-storage.o (para los discos duros), acm.o (para dispositivos de comunicación), printer.o y audio.o

• Drivers de otros dispositivos: resto de dispositivos más concretos, que si una webcam de un fabricante o lo que sea. De esto cada fabricante saca sus propios drivers ya que no son standar.

Como punto interesante decir que el soporte usb en linux funciona por capas, desde las capas más standar (usbcore.o) sobre lo que se van añadiendo. Podremos ver los modulos que tenemos cargados en /proc/modules o haciendo un lsmod

USB Hotplug
Por supuesto que el hotplug también existe en linux. Para cargar drivers genéricos en linux se usa /sbin/hotplug si bien deberemos activar su soporte en el kernel (hoy en día viene activado por defecto en todos los kernels actuales)
.

Conociendo el hw instalado:

Para conocer este hardware son útiles estos comandos: lsmod, lsdev, lspci y lsusb. En realidad os recomiendo que vayais a las páginas man a aprender para que sirven y como funcionan estos comandos. Una nota importante es que en debian para tener lsdev deberéis instalar el paquete “procinfo”. Tanto para lspci y lsusb es interesante la opción -t para mostrarnos en forma de arbol viendo de que controlador depende cada dispositivo.

Manipulando los módulos:

Los modulos en linux se enlazan dinámicamente, normalmente esta gestión la hará el kernel el solito, pero cuando falle nos tocará pelearnos con el tema y aquí es cuando nos tocará pelearnos con esto. Podremos insertar modulos manualmente con insmod, rmmod es lo contrario, descarga un modulo manualmente. Por último modinfo nos da información de un módulo (que esperábais? ) Modprobe es interesante, nos permite cargar modulos con funcionalidades complementarias que insmod no tiene. Al ser un comando algo más completo os invito a mirar su página de ayuda y a pelearos un rato con el ya que es un comando que se usa bastante a menudo.

Device Management Definitions

Y para terminar la lección de hoy este apartado que al menos en el libro de o’reilly se toca muy de refilón. nos habla de sysfs y de /sys de udev, de messagebus, /et/udev o D-Bus pero poco nos cuenta en realidad más bien solo lo nombra de pasado. Dejo como tarea personal investigar el tema más allá de lo que cuenta el libro ya que lo encuentro incompleto.