Este curso cubre administración de sistemas Linux modernos. Trata todos las tareas más importantes, incluyendo: controlar la inicialización del servicio y sistemas; manejar particiones de disco y sistemas de archivos; establecer una buena seguridad y prácticas de respaldo; monitoreo, solución de problemas y rescate del sistema ante una falla; instalación de software y actualizaciones. Las lecciones aprendidas son aplicadas a cada una de las tres familias de distribuciones de Linux (Red Hat, SUSE y Debian) con un foco principal en instalaciones Empresariales.

La meta es proveer a los administradores de sistemas de todas las herramientas y conceptos necesarios para instalar y manejar de forma eficiente una infraestructura de producción Linux. Los laboratorios prácticos de ejercicios presentarán una gran oportunidad para probar y aplicar esas lecciones.

Este curso está diseñado principalmente para administradores de sistema.

Estamos asumiendo que la mayoría de ustedes tienen tareas de configurar, ejecutar y resolver problemas en múltiples máquinas en lo que es llamado un ambiente Empresarial. Si bien es cierto que probablemente tenga experiencia significante con otros sistemas operativos, deseamos que usted aprenda cómo hacer las cosas de forma correcta y nativa en Linux, mientras que se basa en el conocimiento previo que posee.

También es probable que ya esté utilizando Linux, pero que aún no haya estudiado de forma seria tópicos más complejos que mantener su sistema personal funcionando apropiadamente y de forma segura.

Este curso no está diseñado principalmente para:

• Usuarios nuevos sin mucha experiencia previa con cualquier sistema operativo.
  A los usuarios de Linux relativamente nuevos se les recomienda tomar este curso solamente después de haber tomado un curso introductorio como el LFS101x.2 de Linux Foundation.
• Desarrolladores (a nivel del kernel o de aplicaciones).
  La mayoría de los desarrolladores encontrarán interesante este material y entre más sepa alguien de teoría de sistemas operativos, funcionamiento interno del kernel, aplicaciones, etc., más también querrá salirse de este curso. También hay muchos usuarios avanzados quien realizan ambas cosas, administración de sistemas y desarrollo.
• Administradores experimentados que se concentran en la optimización del rendimiento.
  Vamos a discutir algunos problemas de ajuste de rendimiento debido a que la administración y el rendimiento están claramente asociados. Sin embargo, no vamos a entrar en detalles, ya que este tema se trata en un curso más dedicado y avanzado como es el LFS426 de Linux Foundation.

Estamos asumiendo que usted ha tomado el curso gratuito Introducción a Linux (2da Ed.) de Linux Foundation en edX. Este MOOC (Massive Open Online Course) puede ser encontrado haciendo click aquí, o buscando "Linux" en edx.org. O por otro lado, que usted tiene conocimiento equivalente o incluso mejor que lo que podría haber obtenido al tomar ese curso.

LFS101x.2 es gratuito e incluso si usted siente que no tiene que tomar ese curso, recomendamos que se inscriba en él; al menos puede echar un vistazo rápido del material. Algunos de los temas contenidos en LFS101x.2 están cubiertos en este curso, generalmente en un nivel más detallado acorde con nuestra audiencia. El tema de gestión de paquetes es un ejemplo claro de ello. En lugar de repetirnos, instamos a que usted se refiera el curso introductorio para temas básicos no cubiertos aquí.

Existen otros temas que los administradores de sistemas deben saber, que no cubriremos en este curso. En particular:

• Editores de texto (vi, emacs, nano, gedit, etc.)
• Encontrar documentación de Linux
• Manipulación de texto (sed, grep, awk, cut, paste, tail, head, etc.)
• Utilidades de archivo (find, locate, file, etc.)
• Impresión (configurar impresoras, manejo de trabajos de impresión)
• Interfaces gráficas y su administración
• Programas en el shell bash
• Instalación de sistemas.

Antes de tomar este curso, le recomendamos que por lo menos eche un vistazo a LFS101x.2. Si no se siente cómodo o totalmente familiar con algunas herramientas básicas y los procedimientos que usaremos en este curso, usted probablemente los encontrará ahí, ya que este curso pretende tenerlo como complemento.

La Linux Foundation ofrece un Programa de Certificación de dos niveles:

• LFCS (Linux Foundation Certified Sysadmin)
• LFCE (Linux Foundation Certified Engineer).

Todos los detalles acerca de este programa se pueden encontrar en http://training.linuxfoundation.org/certification. Esta información incluye una descripción detallada de los Dominios y Competencias cubiertas por cada examen.

Los asistentes a este curso (y al curso de introductorio de prerrequisito) habrán cubierto todas las áreas descritas como necesarias para la certificación LFCS. Además de este curso, la Linux Foundation ofrece otros recursos para ayudar en la preparación de exámenes.

Con el fin de que sea más fácil distinguir los distintos tipos de contenido en el curso, utilizamos la codificación de colores y formatos que se muestran a continuación:

• Negrita: nombres de programas o servicios (o utilizado para enfatizar)
• Azul oscuro: texto en la línea de comandos
• Verde: salida del sistema en la línea de comandos
• Café: nombres de archivos y contenido de archivos

Para ver los gráficos incluidos en este curso en un formato más grande, simplemente haga clic en el gráfico y automáticamente se mostrará en una ventana emergente.

De vez en cuando, vamos a discutir cómo elaborar un comando utilizando un programa de utilidad de Linux, pero sólo mostraremos uno o unos pocos ejemplos de selección de opciones, argumentos, etc. Además no consideraremosa los modos menos comunes de uso; muchos programas son increíblemente versátiles y tienen muchas características raramente utilizadas.

Mientras que a menudo le diremos explícitamente "lea la página Man para obtener más detalles", usted debe asumir que lo estamos diciendo implícitamente todo el tiempo. Usted debe desarrollar el hábito de la lectura de la documentación de fácil acceso en su distribución de Linux sin preguntar, para la mayoría de las utilidades.

Además de las páginas man, la mayoría de los programas tienen dentro de sí una ayuda como también información acerca de su uso. Generalmente esto se accede mediante el uso de la opción --help, como en df --help.

Si tratamos de incluir toda esa información en el material del curso, sería una duplicación inútil y de hecho el contenido se diluiría de una mala manera.

Este curso está diseñado para trabajar en plataformas basadas en x86, ya sea en hardware nativo o como una máquina virtual (VM) bajo un hypervisor, como KVM, VMWare u Oracle Virtual Box.

Casi todo en este curso es completamente relevante para otras arquitecturas, pero x86 real o virtual cubre la mayoría de las implementaciones.

No consideraremos 32-bit y asumiremos 64-bit a lo largo del curso. Sin embargo, si usted está ejecutando un x86 de 32-bit por alguna razón, casi todo lo que estamos haciendo seguirá siendo válido, aunque no lo hemos probado.

Tampoco estamos apuntando a plataformas de Linux embebido, donde a pesar de que las implementaciones se basan en el mismo kernel Linux y utilizan muchos de los mismos ingredientes del espacio de usuario, uno no suele hablar de la administración del sistema para los dispositivos que se utilizan como soluciones especializadas (appliances).

Existen importantes ingredientes básicos que son muy diferentes, como el uso de diferentes programas del gestor de arranque y sistemas de archivos. Además, los recursos tales como memoria, capacidad de almacenamiento y del procesador pueden diferir grandemente.

Las mismas consideraciones se aplican a Android (una forma particular de Linux embebido), en donde si bien es cierto que el kernel es Linux, el sistema de archivos y el espacio de aplicaciones son muy diferentes a lo que se encuentra en un sistema Linux estándar.

Muchas de las tareas administrativas pueden ser realizadas desde la línea de comandos o desde una aplicación gráfica. Casi siempre hay más flexibilidad y capacidades adicionales en el enfoque de la línea de comandos, ya que la capa de abstracción se ha eliminado. El inconveniente de la línea de comandos, sin embargo, es que el administrador puede tener que recordar más o buscar información cuando tiene que completar una tarea.

Hay una gran variedad de entornos de escritorio gráficos utilizados en Linux, los dos más comunes son GNOME y KDE. Cada uno de ellos viene en múltiples versiones, o generaciones.

En este curso no queremos involucrarnos en interfaces gráficas, debido a que varían mucho entre las versiones y familias de distribuciones de Linux. Además, muchos servidores no tienen una interfaz gráfica instalada.

Si ya ha tomado el curso LFS101x.2, entonces estará familiarizado con los temas.

El beneficio es que habrá muy poca diferencia entre las distribuciones para lo que estamos haciendo, y aparte de las tareas sencillas que implican la gestión de paquetes, no tendremos que explicar las cosas por separado para cada distribución muy a menudo.

Para este curso, usted puede trabajar desde la línea de comandos en el equipo local, usando una consola o un emulador de terminal como gnome-terminal corriendo en un escritorio gráfico. O puede trabajar remotamente mediante una sesión ssh o vpn. Casi todo lo que estamos haciendo se aplicará igualmente bien en el caso de sesión remota. Las excepciones surgirán sólo cuando se necesita acceso físico a la máquina, tales como cuando se intenta iniciar en un entorno de rescate.

Hay una lista casi infinita de distribuciones de Linux; simplemente hojee la lista en http://lwn.net/Distributions.

Sin embargo, nos estamos concentrando en este curso en las distribuciones Empresariales de Linux. La gran mayoría de estos sistemas utilizan:

1. Red Hat Enterprise Linux: Generalmente lo abreviaremos como RHEL o con la versión como en RHEL 6 o RHEL 7, lanzada en 2014.
   Bajo el paraguas de RHEL incluiremos distribuciones derivadas como CentOS y Scientific OS; para los efectos de este curso deben ser idénticas, así como su libre disposición sin cargo. Hay algunas diferencias en la actualización de paquetes para los sistemas oficiales de RHEL, pero no vamos a investigar lo suficiente como para verlos aquí. Para nuestros propósitos Oracle Linux es realmente una copia casi idéntica a RHEL y no merece ninguna discusión distinta aquí.
   Fedora está en la familia Red Hat y en realidad puede ser visto como la versión hacia donde RHEL se dirige. Las versiones actuales son bastante similares a RHEL 7. Sin embargo, es raro que Fedora se utilice en implementaciones Empresariales debido a que es de vanguardia y cambia características importantes (la versión del kernel, por ejemplo) muy a menudo y por comodidad, donde más bien la estabilidad es clave.
2. SUSE es una distribución Empresarial completa con una cuota de mercado significativa. Se relaciona estrechamente con openSUSE, el cual es a SUSE como Fedora a RHEL. Debido a que no hay ningún clon de SUSE como lo hay con CentOS y RHEL, nos basaremos en openSUSE como un sistema de trabajo; las diferencias deben ser pequeñas y en el peor caso los estudiantes se mantendrán cercanos a desarrollos futuros.
3. Debian (y Ubuntu que es un derivado de Debian) también se utiliza en entornos empresariales. En su mayor parte cuando hablamos de sistemas Debian o Ubuntu, vamos a utilizar la versión de Ubuntu LTS 14.04. Otras distribuciones derivadas de Debian como Linux Mint no serán muy diferentes.

Todo en este curso se trabajará en las tres principales familias de distribución mencionadas anteriormente, y cuando sea necesario explicaremos las diferencias que surjan; estas a menudo surgen sólo en cómo se empaqueta el software y no en la forma en que se utiliza.

En ningún caso criticamos a alguien que utilice distribuciones menos difundidas aunque también ampliamente respetadas, como Arch Linux y Gentoo, las cuales se usan en implementaciones Empresariales. Debido a que ambas son distribuciones de liberación continua de software (no tienen versiones específicas de lanzamiento, sino que se actualizan constantemente) son las más utilizadas por administradores muy expertos en entornos Empresariales.

Le invitamos a utilizar su propia instalación local favorita de Linux, usando cualquier distribución con la que se sienta cómodo. De vez en cuando es posible que usted necesite instalar un programa o paquete que usamos en este curso y tendrá que ir a buscarlo e instalarlo, utilizando los métodos habituales de su distribución Linux.

Debido a que no estamos usando un entorno gráfico, usted debe ser capaz de hacer el trabajo del curso en una máquina en la que inicie sesión de forma remota.

Puede utilizar una máquina física, o una máquina virtual en ejecución bajo un hipervisor como VMware, Oracle Virtual Box o KVM. En parte porque no nos estamos concentrando en optimización de rendimiento, una máquina virtual debe funcionar tan bien como una máquina física; por una parte el rendimiento menor no será un problema, y por otra, usted puede hacer mucho menos daño.

La Linux Foundation preparó un documento sobre los temas involucrados al realizar una instalación para LFS101x, el cual es completamente relevante para este curso. Puede descargarlo haciendo click aquí. Entre otras cosas le dará información sobre las distintas opciones para hipervisores.

Otros recursos últiles: documento de bienvenida, Ready-For LF Course (ready-for.sh).

Este curso es completamente autodidacta; no hay ningún horario fijo para ir a través del material. Puede revisar el curso a su propio ritmo y siempre será devuelto a exactamente donde lo dejó cuando vuelva a iniciar una nueva sesión. Sin embargo, de todas formas sugerimos evitar pausas largas entre períodos de trabajo, para que el aprendizaje sea más rápido y la retención del contenido sea mejor.

Usted tiene acceso ilimitado a este curso por 12 meses desde la fecha en la cual se registró, incluso después de haber completado el curso.

Los capítulos en el curso han sido diseñados para construirse uno sobre el otro. Probablemente lo mejor para trabajar a través de ellos es de forma secuencial; si se salta o pasa por algunos capítulos rápidamente, puede encontrar que hay temas en discusión a los que no ha estado expuesto todavía. Pero todo esto es a su propio ritmo y siempre se puede volver atrás, por lo que puede hacer su propio camino a través del material.

En todos los cursos de Linux Foundation (en cualquier formato) ponemos un fuerte énfasis en el aprendizaje mediante la práctica. En las clases presenciales, dirigidas por un instructor, casi siempre buscamos un equilibrio 50/50 entre la conferencia y debate. También en trabajar en ejercicios de laboratorio o en tareas, las que llevan a cabo el trabajo descrito en la clase, o probar con variaciones más ambiciosas. Los instructores ayudan durante estas sesiones de laboratorio a los estudiantes a descubrir cómo hacer las cosas, depurar su código y scripts, etc. Al ser este un curso autodidacta, sin un instructor presencial, estará en sus manos el controlar su presupuesto de tiempo y asegúrese de tomar suficiente tiempo para hacer los laboratorios.

Para cada ejercicio presentamos la descripción de un archivo que puede descargar. En muchos casos, también hay un archivo asociado a la solución (en unos pocos casos también hay un archivo que contiene scripts necesarios para completar el laboratorio). Tenga en cuenta que en muchos casos las soluciones no son únicas, así que considere estas respuestas como un método representativo para resolver el problema; ¡usted puede tener una mejor!

Para mayor comodidad, también puede descargar en un archivo todos los ejercicios de laboratorio y soluciones.

Usted también encontrará una serie de preguntas de verificación de conocimientos al final de cada capítulo. Estas preguntas, al igual que los laboratorios, fueron diseñados con un objetivo principal en mente: ayudarle a comprender mejor el contenido del curso y reforzar lo que ha aprendido. Es importante destacar que los laboratorios y preguntas de verificación de conocimientos no se califican. Nos gustaría hacer hincapié en que no se le exigirá tomar un examen final para completar este curso.

Tres piezas importantes de contexto:

1. Las cosas cambian en Linux. No importa lo duro que hemos trabajado para estar al día, Linux está en constante evolución, tanto a nivel técnico (incluyendo características del kernel) y al nivel de distribución y la interfaz. Por favor, tenga en mente que hemos tratado de estar lo más actualizados posible al momento en que este curso fue publicado, pero habrá cambios y novedades que no hemos discutido, es inevitable.
2. Hemos repetido unas pocas cosas en el material del curso. Es casi imposible en un curso de este amplitud no revisar temas que han sido cubiertos previamente. Los comentarios cortos son útiles, así que no tendrá que ir recorriendo a través de las secciones anteriores para refrescar su memoria. Sabemos que hemos hecho esto, y por lo menos en la mayoría de los casos es por diseño, no por accidente.
3. Hemos intentado evitar guerras santas. Hay muchas áreas donde hay fuertes desacuerdos de preferencias en la comunidad Linux (y de forma más amplia en el código abierto). Los ejemplos incluyen el mejor editor: emacs vs vi; el mejor escritorio gráfico: GNOME vs KDE, etc. Generalmente hemos elegido (cuando sea necesario) una alternativa particular tan sólo para mantener las cosas claras; por ejemplo podemos hablar más acerca de GNOME que KDE simplemente porque tiene una base de usuarios más grande, no porque estamos tomando una posición en cuanto a que es superior.

La Linux Foundation es el consorcio sin fines de lucro dedicado a fomentar el crecimiento de Linux. Patrocina el trabajo del creador de Linux, Linus Torvalds, y es apoyado por las principales empresas de tecnología y desarrolladores alrededor del mundo.

La Linux Foundation promueve, protege y hace que Linux avance a través de los recursos proveídos por sus miembros y la comunidad de desarrollo de código abierto para asegurar que Linux siga siendo libre y avanzado técnicamente.

La Linux Foundation:

• Sirve como portavoz neutral de Linux.
• Patrocina al creador de Linux - Linus Torvalds - y a otros desarrolladores clave del kernel para que puedan trabajar a tiempo completo en la mejora de Linux. Es de vital importancia que ellos sigan siendo independientes.
• Genera una investigación original y contenido que promueve la comprensión de la plataforma Linux.
• Llega a millones de personas a través de sus sitios web, incluyendo http://www.linux.com.
• Fomenta la innovación mediante la organización de grandes eventos de colaboración (incluyendo LinuxCon) e iniciativas de la industria.
• Gestiona la marca Linux, ofrece protección legal de propiedad intelectual a los desarrolladores y un fondo de defensa legal. Coordina la colaboración jurídica y educativa entre la industria y la comunidad, incluyendo trabajo importante para defender Linux de a amenazas legales.
• Ofrece servicios de estandarización y soporte para desarrolladores de aplicaciones, incluyendo el Linux Standard Base.
• Desarrolla y ofrece programas de capacitación.

• LinuxCon América del Norte, Europa y Japón
• Linux Kernel Summit
• CloudOpen América del Norte y Japón
• Collaboration Summit
• Embedded Linux Conference América del Norte y Europa
• Enterprise End User Summit
• Android Builders Summit
• Tizen Developer Conference
• Automotive Linux Summit
• ApacheCon
• CloudStack
• Foro KVM
• Linux Storage Filesystem & MM Summit

La Linux Foundation alberga un número creciente de eventos cada año, incluyendo:

LFS201: Fundamentos de Administración de Sistemas Linux

La Linux Foundation ofrece varios de tipos de capacitación:

• Sala de clases
• En línea
• En su sitio de trabajo
• En eventos.

Vea los siguientes enlaces para obtener más información sobre cursos específicos ofrecidos por la Linux Foundation:

• Entrenamiento en Programación y Desarrollo en Linux: http://training.linuxfoundation.org/linux-courses/development-training
• Cursos de IT Empresarial y Administración de Sistemas Linux: http://training.linuxfoundation.org/linux-courses/system-administration-training
• Cursos de Cumplimiento de Normas de Código Abierto: http://training.linuxfoundation.org/linux-courses/open-source-compliance-courses

Para información adicional, incluyendo requisitos técnicos y otros aspectos logísticos, consulte http://training.linuxfoundation.org.

• Laboratorio 1.1

Es importante delinear los pasos básicos de la secuencia de inicio y comprender el papel de la BIOS y del UEFI, y de los principales tipos de cargadores de inicio. Los archivos de configuración en /etc controlan el comportamiento del inicio, particularmente los de /etc/sysconfig y /etc/default. El apagado y reinicio del sistema se puede realizar de diferentes maneras.

Al final de este capítulo, usted debería ser capaz de:

• Explicar el proceso de arranque.
• Identificar varios tipos de cargadores de arranque.
• Describir lo que hace la BIOS.
• Identificar los archivos de configuración importantes.
• Describir cómo el sistema se apaga y reinicia.

La Secuencia de Inicio

Los pasos básicos en el proceso de inicio son:

1. La BIOS/UEFI localiza y ejecuta el gestor de arranque, o cargador de inicio.
2. El gestor de arranque carga el kernel.
3. El núcleo inicia el proceso init (pid=1).
4. init gestiona la inicialización del sistema, utilizando scripts de inicio SysVinit convencionales, o usando Upstart o systemd.

Los equipos más nuevos están cambiando a UEFI, un reemplazo para la BIOS, que realiza muchas de las mismas funciones.

En la arquitectura x86, la BIOS contiene todo el código requerido para obtener acceso inicial al teclado, pantalla, unidades de disco, de comunicaciones en serie y un número de funciones variadas. Una vez que el sistema completo está en marcha, la mayoría de estos dispositivos habrán mejorado sus capacidades cuando los controladores de dispositivos especializados y completos se cargan y asumen el control.

La BIOS se coloca típicamente en un chip ROM que viene con el equipo (el que a menudo se llama BIOS ROM). Esto asegura que la BIOS estará siempre disponible y no será dañada por fallas en el disco. Esto también hace que sea posible que un equipo arranque.

Durante el proceso de arranque, la BIOS carga el gestor de arranque desde el MBR.

Existen diferentes gestores de arranque utilizados en Linux, incluyendo:

• GRUB
• LILO
• efilinux
• Das U-Boot.

Prácticamente todas las distribuciones modernas de Linux (no-embebidas) usan GRUB (GRand Unified Boot Loader). Las características de GRUB incluyen la capacidad de arrancar varios sistemas operativos, tanto en una interfaz gráfica y en otra basada en texto que permite ser usado a través de un cable serial, una potente interfaz de línea de comandos para la configuración interactiva, iniciando desde la red sin disco de arranque y otras características avanzadas.

El cargador de Linux (LILO) es viejo y obsoleto.

efilinux es un gestor de arranque alternativo diseñado específicamente para el mecanismo de UEFI.

Das U-Boot es el cargador más popular para sistemas Linux embebidos; hay algunos otros, entre ellos bareboot. Sin embargo, en realidad no estamos considerando el espacio embebido en este curso.

Más adelante vamos a discutir acerca de donde las distribuciones de Linux cooperan para colocar ciertos tipos de archivos en lugares estándar en el sistema. En particular, los archivos de configuración de todo el sistema se colocan generalmente en /etc y sus subdirectorios, mientras que los específicos del usuario se colocan a menudo en sus directorios personales.

Las distribuciones desarrollaron sus propias reglas sobre exactamente dónde colocar información en /etc. Por ejemplo, todos los sistemas derivados de Red Hat hacen uso extensivo de /etc/sysconfig, mientras que los sistemas basados en Debian han utilizado /etc/default. Curiosamente, RHEL 7 y SUSE usan ambos.

En un sistema RHEL 6:

$ ls -F /etc/sysconfig

atd              grub                     modules          samba
auditd           htcacheclean             netconsole       sandbox
authconfig       httpd                    network          saslauthd
autofs           i18n                     networking       selinux
cbq              init                     network-scripts  sendmail
cgconfig         ip6tables-config         nfs              smartmontools
cgred.conf       ip6tables-config.rpmnew  ntpd             snmpd
clock            iptables-config          ntpdate          snmptrapd
collectl         iptables-config.rpmnew   pluto            sshd
console          irqbalance               prelink          sysstat
cpuspeed         kdump                    quota_nld        sysstat.ioconf
crond            kernel                   radvd            system-config-firewall
dhcpd            keyboard                 raid-check       system-config-users
dhcpd6           ksm                      readahead        udev
dhcrelay         libvirtd                 readonly-root    vncservers
dhcrelay6        libvirt-guests           rhn              wpa_supplicant
ebtables-config  lm_sensors               rngd             xinetd
firstboot        mcelogd                  rsyslog

Para ver el contenido de un archivo:

$ cat /etc/sysconfig/network

NETWORKING=yes
HOSTNAME=quad64
GATEWAY=192.168.1.1

lo cual configura algunas variables ambientales usadas por varios scripts de inicio.

Los archivos en este directorio son usados a menudo por el script que controla el servicio asociado en /etc/init.d; por ejemplo, el script /etc/init.d/network incluye la línea con el siguiente archivo:

. /etc/sysconfig/network

el que define estas variables cuando la red se inicia.

En un sistema Ubuntu 14.04:

$ ls -F /etc/default

acpid         console-setup  grub.ucf-dist  locale      rsyslog
acpi-support  crda           halt           nfs-common  saned
alsa          cron           im-config      nss         speech-dispatcher
anacron       cups           irqbalance     ntfs-3g     sysstat
apport        dbus           kdump-tools    ntpdate     ufw
avahi-daemon  devpts         kerneloops     pulseaudio  useradd
bridge-utils  grub           kexec          qemu-kvm    whoopsie
brltty        grub~          keyboard       rcS
bsdmainutils  grub.d/        libvirt-bin    rsync

El uso de este directorio es similar al /etc/sysconfig de Red Hat:

• Los archivos son utilizados para proveer opciones adicionales al iniciar un servicio.
• Normalmente contienen código para configurar variables de entorno.

Por ejemplo, el archivo /etc/default/useradd establece los valores predeterminados que se utilizan cuando se crean nuevas cuentas de usuario.

shutdown se utiliza para apagar el sistema de forma segura, notificando a todos los usuarios que el sistema va a apagarse y luego lo detiene de manera elegante y no destructiva. Después de que está apagado, el sistema es detenido o reiniciado.

Sin opciones (por ejemplo, shutdown now) el comportamiento por defecto es apagar por completo el sistema. Algunas distribuciones, como Ubuntu, violan esto y van a modo monosuario en vez de apagarse.

Un error común es no especificar un argumento de tiempo (tal como now o algún tiempo real). Esto es requerido.

También existen los comandos heredados reboot, halt y poweroff, los que muchos usuarios veteranos utilizan con frecuencia.

Organice los pasos básicos de la secuencia de inicio en el orden correcto.

El cargador de arranque es ejecutado.

El kernel Linux y la imagen initrd o initramfs son cargadas en memoria y el núcleo se ejecuta.

El proceso init se inicia.

Módulos adicionales del kernel (incluyendo controladores de dispositivo) se cargan y se inician los servicios del sistema.

• Laboratorio 2.1

Usted debería ser capaz de:

• Explicar el proceso de arranque.
• Identificar varios tipos de cargadores de arranque.
• Describir qué hace la BIOS.
• Identificar los archivos de configuración correspondientes.
• Describir cómo el sistema se apaga y reinicia.

Un sistema que no puede iniciar es bastante inútil. Los sistemas Linux tienen mucha flexibilidad en la forma de arrancar. Es posible elegir versiones diferentes del kernel u opciones, o incluso diferentes sistemas operativos en escenarios de inicio múltiple. La mayoría de los sistemas no embebidos utiliza el Grand Unified Boot Loader para realizar los primeros pasos de una inicialización exitosa del sistema. GRUB también tiene capacidades interactivas, así como una utilidad de contraseñas seguras.

Al final de este capítulo usted debería ser capaz de:

• Explicar cuál es el rol de GRUB.
• Comprender las diferencias entre las versiones GRUB 1 y GRUB 2.
• Estar familiarizado con las selecciones interactivas que se pueden realizar en el arranque.
• Saber cómo instalar GRUB.
• Explicar cómo se usan y modifican los archivos de configuración que GRUB necesita.

Para cualquier versión, el archivo de configuración principal contiene algunos parámetros globales y luego una sección para cada sistema operativo o núcleo configurado.

Prácticamente todos sistemas basados en x86 de Linux (dejando de lado la esfera de los sistemas embebidos) usan GRUB actualmente (GRand Unified Bootloader) para manejar las primeras fases de arranque del sistema. Otras plataformas pueden tener otros equivalentes, como ELILO, utilizado en sistemas EFI como IA64 (Itanium) y Das U-BOOT utilizado en muchas configuraciones de sistemas embebidos.

Algunas características importantes de GRUB son:

• Sistemas operativos alternativos pueden ser elegidos en el momento del arranque.
• Los kernels alternativos o ramdisk inicial pueden ser elegidos durante el arranque para un determinado sistema operativo.
• Los parámetros de arranque pueden cambiarse fácilmente al arrancar sin tener que editar archivos de configuración, etc. de antemano.

Las distribuciones de Linux más antiguas (por ejemplo, RHEL 6) usan versiones antiguas de GRUB, 1.0 o menor, mientras que las más recientes se basan en GRUB 2. Mientras que los detalles son diferentes entre las versiones, la filosofía básica es la misma.

Al arranque del sistema, después de las etapas iniciales del POST y BIOS, GRUB se ejecutará y mostrará un menú.

Este puede o no tener gráficos en él (al menos para el fondo de pantalla de splash). El menú contiene una lista de imágenes de arranque de uno o más sistemas operativos o distribuciones de Linux. En GRUB 2 (o, si usas 'chainloading' para conectar múltiples instalaciones de GRUB en el mismo disco, un tema complicado que no trataremos aquí) también pueden haber submenús con aún más opciones.

Usando las flechas arriba y abajo y la tecla Enter, usted puede seleccionar la opción de arranque correcta, o puede esperar durante un periodo de tiempo configurable antes de entrar en la opción predeterminada.

Sin embargo, es posible hacer mucho más. Después de seleccionar una entrada, puede escribir e para editar y luego entrar en una shell interactiva. En esta shell, puede modificar la sección en el archivo de configuración que describe esa opción de arranque particular. Por lo general, esto se hace para modificar la línea de comandos del kernel; por ejemplo, agregando la palabra single al final de la línea de comando hará que el sistema arranque en el modo monousuario con el fin de tomar acciones correctivas. Una vez que el cambio deseado se ha realizado, usted puede presionar la tecla adecuada para iniciar el sistema.

En la parte inferior de la pantalla verá que aparece información sobre las combinaciones de teclas exactas, así que no es necesario memorizarlas.

Tenga en cuenta que cualquier cambio que realice en la configuración no es persistente y se perderá en el próximo inicio. Para realizar cambios permanentes, es necesario modificar los archivos en el sistema, usando las utilidades adecuadas.

También es posible introducir una shell pura, en lugar de editar una sección en particular. Puede ejecutar una serie de comandos diferentes e incluso tratar de reinstalar o reparar GRUB. Si hay problemas serios, como no encontrar un archivo de configuración, GRUB vuelve al modo de línea de comandos y usted podría rescatar el sistema sin tener que recurrir a los medios físicos (DVDs).

La palabra instalación puede tener significados diversos en relación a GRUB:

1. Instalar el programa grub y sus herramientas asociadas en sus lugares respectivos. En GRUB 1 hay un solo programa llamado grub, pero en GRUB 2 hay un montón de utilidades con nombres como grub2-* o grub-*; el cómo están empaquetados depende bastante de la distribución.
2. Instalar los archivos que GRUB necesita para operar en el momento de arranque, ya sea en /boot/grub o /boot/grub2. Esto es independiente de los archivos que el kernel Linux necesita (vmlinuz-*, initramfs_*), los cuales deberán estar en el directorio /boot también.
3. Instalar GRUB como el gestor de arranque en el sistema; generalmente esto se hace en el comienzo de todo el disco duro, pero también puede ser realizado en una partición y acceder a él través de 'chainloading', es decir de un GRUB a otro.

Si no instala GRUB durante la instalación o si necesita volver a instalarlo en algún momento más adelante, el procedimiento exacto para hacerlo depende de la versión de GRUB.

En ambas versiones de GRUB, el primer y segundo disco duro es denominado como hd0, el segundo como hd1, etc. Sin embargo, en la versión 1 las particiones comienzan contando desde 0 y en la versión 2 desde 1:

• sda1 es (hd0,1) en GRUB 2, pero (hd0,0) en GRUB 1.
• sdc4 es (hd2,4) en GRUB 2, pero (hd2,3) en GRUB 1.

No hay necesidad de enfatizar que confundirse acerca de esto puede ser muy destructivo. Ambas versiones de GRUB a veces usan la notación de sda# y a veces usan (hd0,#), así que puede ser aún más confuso.

Dentro del archivo de configuración, cada sección tiene que especificar cuál es la partición raíz; esto no es lo mismo que lo que queremos decir cuando hablamos del directorio raíz del sistema. En este contexto significa la partición que contiene el kernel (en el directorio /boot). Por ejemplo, es muy común tener /boot en su partición propia, digamos /dev/sda1. Luego, en GRUB 1 podrá encontrar una sección simple como la siguiente:

title 3.17.3
        root (hd0,0)
        kernel vmlinuz-3.17.3 ro root=/dev/sda2 quiet
        initrd initramfs-3.17.3.img

Sin embargo, si /boot no tiene su propia partición, se vería como lo siguiente:

title 3.17.3
        root (hd0,0)
        kernel /boot/vmlinuz-3.17.3 ro root=/dev/sda1 quiet
        initrd /boot/initramfs-3.17.3.img

También es posible especificar kernel (hd0,0)/vmlinuz .... , y dejar de lado la línea root.

En GRUB 2 la sintaxis es diferente pero obvia; una mirada rápida a /boot/grub2/grub.cfg lo dejará claro.

Nos vamos a concentrar en GRUB 2 porque las versiones anteriores se están volviendo obsoletas rápidamente. Además es esencialmente el mismo en las diversas distribuciones de Linux.

Recuerde que no debería editar grub.cfg directamente. Hay dos lugares en el directorio /etc que deberían requerir atención y se utilizan para reconstruir grub.cfg cuando el sistema se ve alterado con la instalación de kernel nuevos, o cuando se ejecuta de forma manual un programa de actualización (como update-grub).

El primero es /etc/default/grub. En un sistema RHEL 7 luce de la siguiente forma:

$ cat /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="vconsole.keymap=us crashkernel=auto  vconsole.font=latarcyrheb-sun16 rhgb quiet" GRUB_DISABLE_RECOVERY="true"

Red Hat ha abreviado bastante este archivo en comparación con otras distribuciones. Por ejemplo, en un sistema Ubuntu 14.4 se ve de la siguiente forma:

$ cat /etc/default/grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#  info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR='lsb_release -i -s 2> /dev/null || echo Debian'
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US"
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

El otro directorio que importa es /etc/grub.d:

$ ls -l /etc/grub.d

total 76
-rwxr-xr-x 1 root root   9424 Sep    8 17:35 00_header
-rwxr-xr-x 1 root root   6058 Sep    8 17:35 05_debian_theme
-rwxr-xr-x 1 root root  11608 Sep    8 17:35 10_linux
-rwxr-xr-x 1 root root  10412 Sep    8 17:35 20_linux_xen
-rwxr-xr-x 1 root root   1992 Sep    8 17:35 20_linux_xen
-rwxr-xr-x 1 root root  11692 Sep    8 17:35 30_os-prober
-rwxr-xr-x 1 root root   1416 Sep    8 17:35 30_uefi-firmware
-rwxr-xr-x 1 root root    214 Sep    8 17:35 40_custom
-rwxr-xr-x 1 root root    216 Sep    8 17:35 41_custom
-rw-r--r-- 1 root root    483 Sep    8 17:35 README

donde una vez más estamos mostrando Ubuntu 14.04. Cada uno de estos archivos se ejecutan en orden ascendente cuando se actualiza el archivo de configuración. No los discutiremos aquí debido a que están bien autodocumentados y recomendamos que les eche un vistazo.

Para GRUB 1 cada distribución puede tener algunas peculiaridades, pero básicamente se edita grub.conf directamente o a través de un script como grubby.

¿Cuáles de las siguientes afirmaciones son ciertas?

• Un cargador de arranque como GRUB es necesario para Linux solamente. Otros sistemas operativos, particularmente los propietarios, no necesitan un cargador de arranque para iniciarse.
• GRUB es capaz de iniciar múltiples sistemas operativos como Linux, FreeBSD y Microsoft Windows.
• No es posible utilizar GRUB en modo interactivo cuando el sistema inicia.
• Según cómo está configurado el gestor de arranque puede tener un impacto importante en la seguridad del sistema.
• GRUB puede soportar solamente una configuración para cada sistema operativo. Por lo tanto, no es posible utilizarlo para seleccionar entre los diferentes kernels, opciones del kernel o sistemas de archivos raíz para una sola instalación de Linux.
• El archivo de configuración principal de GRUB 2, grub.cfg, debe ser editado directamente.

• Laboratorio 3.1

Usted debería ser capaz de:

• Explicar cuál es el rol de GRUB.
• Comprender las diferencias entre GRUB 1 y GRUB 2.
• Estar familiarizado con las selecciones interactivas que puede hacer en el arranque.
• Saber cómo instalar GRUB.
• Explicar cómo se usan y modifican los archivos de configuración que GRUB necesita.

Cuando un sistema Linux se inicia, muchas tareas deben llevarse a cabo de manera cooperativa. Los dispositivos tienen que ser reconocidos e inicializados, los servicios del sistema tienen que ser lanzados, los sistemas de archivos tienen que estar disponibles, procesos de gestión importantes tienen que iniciarse y el sistema debe estar disponible a los usuarios para iniciar sesión. Todo esto debe hacerse en la secuencia correcta y lo más rápidamente posible.

Al final de este capítulo usted debería estar capacitado para:

• Entender la importancia del proceso init.
• Explicar cómo funciona el método tradicional de SysVinit, cómo incorpora los niveles de ejecución y qué sucede en cada uno.
• Saber usar chkconfig y service (y utilidades alternativas) para iniciar y detener servicios o hacerlos persistentes luego del reinicio del sistema.
• Entender por qué surgieron los métodos alternativos Upstart y systemd y cómo funcionan.
• Usar systemctl para configurar y controlar systemd.

/sbin/init (normalmente llamado init) es el primer proceso (o tarea) a nivel de usuario que se ejecuta en el sistema y continúa funcionando hasta que el sistema se apaga. Tradicionalmente ha sido considerado el padre de todos los procesos del usuario, aunque técnicamente eso no es cierto ya que algunos procesos son iniciados directamente por el kernel.

init coordina las etapas posteriores del proceso de arranque, configura todos los aspectos del ambiente e inicia los procesos necesarios para entrar/autenticarse en el sistema. init también trabaja estrechamente con el kernel para limpiar lo necesario a medida en que los procesos terminan.

Tradicionalmente casi todas las distribuciones basan el proceso init en el venerable SysVinit de UNIX. Sin embargo, este esquema fue desarrollado décadas atrás en circunstancias muy diferentes:

• El objetivo eran sistemas multiusuario de tipo mainframe (y no ordenadores personales, portátiles y otros dispositivos).
• El objetivo era un sistema de procesador único.
• El tiempo de inicio (y apagado) no era un asunto importante; era mucho más importante hacer que las cosas funcionaran bien.

El inicio fue visto como un proceso serial, dividido en una serie de etapas secuenciales. Cada etapa requería ser finalizada antes de que la próxima pudiera iniciar. Por lo tanto, el arranque no aprovechó el procesamiento en paralelo que podría hacerse en múltiples procesadores.

En segundo lugar, el apagado/reinicio fue visto como un acontecimiento relativamente raro y exactamente cuánto demoraban no era considerado importante.

Para lidiar con estas limitaciones intrínsecas en SysVinit, se han desarrollado nuevos métodos para controlar el arranque del sistema. Si bien es cierto que existen otros, dos esquemas principales fueron adoptados por distribuidores Empresariales:

1. Upstart fue desarrollado por Ubuntu y fue incluido por primera vez en el lanzamiento de la versión 6.10 en el 2006 y pasó a ser utilizado por defecto en el lanzamiento de la versión 9.10, el 2009. También fue adoptado en Fedora 9 (en el 2008) y en RHEL 6 y sus clones, tales como CentOS, Scientific Linux y Oracle Linux. En openSUSE fue ofrecido como una opción desde la versión 11.3. También se ha utilizado en varios dispositivos embebidos y móviles.
2. systemd es más reciente y Fedora fue la primera distribución de las principales en adoptarlo en el 2011.

RHEL 7 se basa en systemd y cada distribución principal de Linux lo ha adoptado y usado por defecto, o ha anunciado planes para hacerlo. Los desarrolladores principales de systemd están estrechamente vinculados a la comunidad del kernel de Linux. Incluso Ubuntu ha programado el retiro de Upstart en su favor.

La migración a los nuevos esquemas puede ser complicada debido a que los errores de software y funciones faltantes pueden ser muy incapacitantes, de hecho han habido capas que requieren compatibilidad esencial. Por lo tanto, los métodos y utilidades SysVinit persistirán por mucho tiempo aunque bajo el capó, las cosas son muy diferentes.

La historia de las controversias y todo eso es muy complicado, y personalidades interesantes han asegurado no que toda la discusión es de carácter técnico. En nuestro contexto no veremos a través de esta lente.

En adelante vamos a concentrarnos en SysVinit y systemd con una breve sección sobre Upstart (aunque RHEL 6 y algunas otras distribuciones han estado usando Upstart, éste ha sido completamente oculto detrás de una capa de compatibilidad usando las utilidades SysVinit normales).

Un sistema SysVinit inicia a través de una secuencia de 'runlevels' (niveles de ejecución) que definen diferentes estados del sistema; están numerados del 0 al 6.

El runlevel 0 está reservado para el apagado del sistema, runlevel 1 para el modo monousuario y runlevel 6 para reiniciar el sistema. Los otros runlevels se usan para definir qué servicios están ejecutándose en un sistema normal; según el caso, las distribuciones definen algo de forma diferente. Por ejemplo, en sistemas basados en Red Hat, runlevel 2 se define como un sistema en funcionamiento sin red o X, runlevel 3 incluye soporte de red, y runlevel 5 incluye red y X.

El runlevel actual pueden ser desplegado simplemente con el comando runlevel, como se muestra aquí:

$ runlevel

N 5

donde el primer caracter es el nivel previo; N significa desconocido.

telinit puede ser usado para cambiar el nivel de ejecución del sistema. Por ejemplo, para ir desde runlevel 3 a runlevel 5, ejecute lo siguiente:

$ sudo /sbin/telinit 5

Cuando el proceso init es iniciado, lo primero que hace es leer /etc/inittab. Históricamente, este archivo ha instruido a init acerca de los scripts que debe ejecutar para llevar al sistema a cada runlevel. Y se ha hecho con una serie de líneas, una para cada runlevel:

id:runlevel(s):action:process

donde:

• id: un identificador único de 1 a 4 caracteres para la entrada.
• runlevel(s): cero o más caracteres individuales o identificadores de dígitos, el que indica en qué nivel de ejecución se realizará la acción.
• action: describe la acción a ser realizada.
• process: especifica el proceso a ser ejecutado.

Sin embargo, en sistemas más recientes como RHEL 6 que enmascaran upstart detrás de una capa de compatibilidad, la única línea descomentada y lo único que se encuentra en este archivo es el runlevel predeterminado con la línea:

id:5:initdefault

Este es el runlevel al cual llegará el sistema una vez que haya terminado de iniciar. Sin embargo, si se especifica otro valor en la línea de comandos del núcleo, init ignora el valor por defecto (esto se hace añadiendo el dígito entero a la línea de comandos del núcleo). El runlevel por defecto es generalmente 5 para un sistema completo, lo cual considera soporte multiusuario, sistema gráfico en red o 3 para un servidor sin una interfaz gráfica.

El método tradicional es que primero se ejecute el script rc.sysinit, el cual realiza numerosas funciones, como iniciar LVM, montar sistemas de archivos, etc. Este script reside en el directorio /etc, pero probablemente lo encontrará en /etc/rc.d con un enlace simbólico a /etc.

A continuación, se ejecuta el script rc (en el mismo directorio) con el runlevel deseado como argumento. Esto hace que el sistema vaya al directorio rc.d/rc[0-6].d y ejecute todos los scripts que están ahí:

$ ls -lF /etc/rc.d/rc5.d

total 0
lrwxrwxrwx. 1 root root 14 Sep 3 10:05 K05pmcd -> ../init.d/pmcd*
lrwxrwxrwx. 1 root root 14 Sep 3 10:05 K05pmie -> ../init.d/pmie*
lrwxrwxrwx. 1 root root 18 Sep 3 10:05 K05pmlogger -> ../init.d/pmlogger*
lrwxrwxrwx. 1 root root 15 Sep 3 10:05 K05pmmgr -> ../init.d/pmmgr*
lrwxrwxrwx. 1 root root 17 Sep 3 10:05 K05pmproxy -> ../init.d/pmproxy*
lrwxrwxrwx. 1 root root 16 Sep 3 10:05 K05pmwebd -> ../init.d/pmwebd*
lrwxrwxrwx  1 root root 37 Sep 6 08:50 K08vmware-USBArbitrator -> /etc/rc.d/init.d/vmware-USBArbitrator*
lrwxrwxrwx. 1 root root 20 Sep 3 03:57 K50netconsole -> ../init.d/netconsole*
lrwxrwxrwx. 1 root root 17 Sep 3 09:39 S10network -> ../init.d/network*
lrwxrwxrwx  1 root root 16 Sep 6 08:50 S19vmware -> ../init.d/vmware*
lrwxrwxrwx. 1 root root 17 Sep 3 04:04 S20iprinit -> ../init.d/iprinit*
lrwxrwxrwx. 1 root root 19 Sep 3 04:04 S20iprupdate -> ../init.d/iprupdate*
lrwxrwxrwx. 1 root root 17 Sep 3 10:05 S21iprdump -> ../init.d/iprdump*
lrwxrwxrwx  1 root root 17 Sep 6 08:51 S25vmamqpd -> ../init.d/vmamqpd*
lrwxrwxrwx  1 root root 37 Sep 6 08:50 S50vmware-USBArbitrator -> /etc/rc.d/init.d/vmware-USBArbitrator*
lrwxrwxrwx. 1 root root 15 Sep 3 03:59 S97rhnsd -> ../init.d/rhnsd*

El script rc.local puede ser usado para iniciar aplicaciones específicas del sistema.

Note lo siguiente:

• Todos los scripts reales están en /etc/init.d: cada directorio de nivel de ejecución solo enlaza a ellos.
• Los nombres de los scripts de inicio comienzan con s.
• Los nombres de los scripts de detención comienzan con k.

La existencia (o falta) de un vínculo simbólico de un script en un directorio de runlevel determina si el script se ejecuta en ese runlevel o no.

El número que le sigue a la K o S en cada nombre de script determina el orden en el cual los scripts son invocados. El nombre del script corresponde también al nombre del servicio.

Controlar qué scripts de inicialización se ejecutan al entrar a cada runlevel consiste en gestionar los enlaces simbólicos. Mientras que es posible administrar estos vínculos de forma manualmente, hay utilidades como chkconfig que están diseñadas para hacer esto de manera consiste y simple.

chkconfig se utiliza para consultar y configurar en qué runlevels van a correr los diferentes servicios del sistema.

No es difícil añadir sus propios servicios y escribir scripts de inicio. Solamente hay que poner el script en /etc/init.d, el cual debe tener ciertas características (¡sólo algunas líneas en el comienzo del archivo!) y luego usar chkconfig --add para habilitarlo o chkconfig --del para desactivar el uso de las instrucciones on y off.

Cada sistema operativo tiene servicios que generalmente arrancan en la inicialización del sistema y a menudo permanecen funcionando hasta el apagado. Tales servicios pueden ser iniciados, detenidos o reiniciados en cualquier momento, lo que generalmente requiere privilegios de root. En un sistema Linux usando o emulando SysVinit, los servicios están en el directorio /etc/init.d.

service tiene diversas opciones, las que varían según el servicio en particular; por ejemplo:

$ sudo service network

Usage: /etc/init.d/network {start|stop|restart|reload|status}

$ sudo service iptables

Usage: /etc/init.d/iptables {start|stop|restart|condrestart|status|panic|save}

Todo servicio se dirige al directorio /etc/init.d y ejecuta el script apropiado en ese directorio con las opciones suministradas.

El iniciar y detener servicios con service es efectivo sólo durante la operación actual del sistema; todos los cambios se pierden al reiniciar. Para configurar que un servicio en particular se active o no durante la inicialización del sistema - en sistemas basados en Red Hat - se utiliza chkconfig como se describió anteriormente.

En sistemas basados en Debian, incluyendo Ubuntu, las utilidades anteriores funcionarán solamente si se han instalado los paquetes sysvinit-utils y chkconfig, como se muestra aquí:

$ sudo apt-get install sysvinit-utils chkconfig

Sin embargo, las versiones recientes de Ubuntu ya no tienen el paquete chkconfig; tendrá que utilizar la utilidad update-rc.d que se describe más abajo.

Como alternativa, puede utilizar los comandos nativos en estos sistemas. Por ejemplo, el equivalente de la utilidad service es:

$ sudo invoke-rc.d cups [ status | start | stop ]
$ sudo status cups

para visualizar o cambiar el estado de cups. El comando status es más reciente y es preferido sobre invoke-rc.d.

Del mismo modo el equivalente de chkconfig sería:

$ sudo update-rc.d cups [ defaults | purge ]
$ sudo sysv-rc-conf cups [ on | off ]

Usted deberá consultar las páginas man para acceder a la documentación completa.

Upstart es manejado por eventos, en lugar de ser un conjunto de procedimientos en forma serial. Las notificaciones de eventos son enviadas al proceso init para ejecutar ciertos comandos en el momento justo después de que han cumplido los requisitos previos. Debido a que Upstart está siendo reemplazado por systemd, no invertiremos mucho tiempo en él ni hacemos ejercicios al respecto.

Cuando el kernel inicia el proceso init, éste ejecuta el script rcS.conf. Esto a su vez, hace que rc-sysinit.conf se ejecute.

rc-sysinit.conf realizará una serie de tareas, incluyendo iniciar LVM, montar sistemas de archivos y luego ejecuta todos los scripts para el runlevel por defecto especificado en /etc/inittab.

Esto se logra mediante la ejecución de rc.conf y pasando al runlevel. Los scripts del runlevel levantan los servicios en el sistema.

Finalmente, scripts adicionales como prefdm.conf son ejecutados (para el runlevel 5 solamente).

Como se mencionó anteriormente, /etc/inittab está obsoleto y ahora sólo se utiliza para configurar el runlevel predeterminado mediante la línea initdefault. Otra configuración se realiza mediante Upstart en el directorio /etc/init. En general, Upstart se encontrará en el directorio /etc/event.d.

Por ejemplo, el número de consolas tty activas ahora se establece mediante la variable ACTIVE_CONSOLES en /etc/sysconfig/init, la que es leída por /etc/init/start-ttys.conf. El valor predeterminado es ACTIVE_CONSOLES=/dev/tty [1-6], el cual inicia un proceso getty desde tty1 hasta tty6.

Usando initctl usted puede ver, iniciar y detener procesos casi del mismo modo que lo hace service. La sintaxis es como sigue:

$ initctl options command

donde options puede tener los siguientes valores:

• start: Inicia un proceso
• stop: Detiene un proceso
• restart Reinicia un proceso
• reload Envía la señal HUP a un proceso
• status Consulta el estado de un proceso
• list: Lista los procesos conocidos
• emit Emite un evento.

Es posible encontrar un buen resumen de cómo utilizar initctl y muchas otras características de upstart en http://upstart.ubuntu.com/cookbook.

El sistema de administración central systemd y manejador de sesión para Linux está tomando lugar rápidamente en todas las distribuciones importantes.

systemd es compatible con SysVinit y el concepto de runlevels está soportado a través de 'targets' de nivel de ejecución. El programa telinit es emulado para trabajar con runlevels.

En vez de utilizar scripts bash, systemd usa archivos .service. Adicionalmente, systemd clasifica todos los demonios en su propio cgroups del núcleo Linux (grupos de control).

Aunque systemd prefiere utilizar un conjunto de archivos de configuración correspondientes a un estándar nuevo, también puede utilizar archivos de configuración heredados dependiente de cada distribución.

Un ejemplo de un archivo de configuración nuevo sería /etc/hostname, el cual reemplazaría a /etc/sysconfig/network en Red Hat, /etc/HOSTNAME en SUSE y a /etc/hostname (adoptado como estándar) en Debian.

Otros archivos pueden incluir:

• /etc/vconsole.conf: mapa de teclado por defecto y fuente de consola.
• /etc/sysctl.d/*.conf: directorio para los parámetros sysctl del kernel.
• /etc/os-release: archivo de ID de la distribución.

systemctl es la utilidad principal para manejar servicios. La sintaxis básica es la siguiente:

$ systemctl [options] command [name]

Para ver un excelente resumen de cómo pasar desde SysVinit a systemd, consulte la documentación SysVinit to Systemd Cheatsheet en https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet.

Hasta hace poco tiempo atrás, casi todas las distribuciones estaban basadas en SysVinit. Sin embargo hubo problemas que motivaron el desarrollo de systemd. ¿Cuál de las siguientes afirmaciones es correcta?

SysVinit fue diseñado para mainframes, los que tienen requerimientos diferentes a computadores de escritorio, sistemas embebidos y plataformas para dispositivos móviles.

SysVinit fue diseñado para sistemas de núcleos múltiples.

Los tiempos de inicio y apagado no son importantes actualmente.

SysVinit no es confiable.

systemd se orienta a tener un diseño modular y a tener compatibilidad con el SO, objetivos que no se alcanzan con SysVinit.

¿Qué runlevel corresponde a cada ítem de los que se enumeran a continuación?

• Apagado del sistema
• Reinicio
• Modo monousuario
• Modo normal de sólo texto
• Modo normal gráfico

• Laboratorio 4.1 (código fuente: fake_service)
• Laboratorio 4.2

Usted debería ser capaz de:

• Comprender la importancia del proceso init.
• Explicar cómo funciona el método tradicional de SysVinit, cómo incorpora los runlevels y lo que sucede en cada uno de ellos.
• Saber cómo usar chkconfig y service (y utilidades alternativas) para iniciar y detener servicios, o hacerlos persistentes entre reinicios del sistema.
• Entender por qué surgieron los métodos alternativos Upstart y systemd y cómo funcionan.
• Usar systemctl para configurar y controlar systemd.

Hay muchos tipos de archivos presentes en un sistema Linux. Se diferencian por su propósito, tamaño, dueño, permisos para ser compartidos. Así mismo, por su permanencia temporal o definitiva en el sistema. Debido a lo anterior, la organización coherente de todo el árbol del sistema de archivos es muy importante, como también su estandarización entre las distribuciones de Linux (en tanto sea posible).

Al final de este capítulo usted debería estar capacitado para:

• Explicar por qué Linux requiere la organización de un gran árbol de sistemas de archivos, y cuáles son las principales consideraciones de cómo hacerlo.
• Conocer el rol desempeñado por el Estándar de Jerarquía del Sistema de Archivos (Filesystem Hierarchy Standard o FHS).
• Describir qué debe estar disponible en el arranque en el directorio raíz (/), y lo que debe estar disponible una vez que el sistema ha iniciado.
• Explicar cada uno de los subdirectorios principales del árbol en términos de propósito y contenido.

Linux, como todos los sistemas operativos basados en UNIX, consiste en un árbol grande de sistemas de archivos. Generalmente es diagramado como un árbol invertido con el directorio raíz / en la parte superior del árbol.

Dentro de este tremendo sistema de archivos lógico pueden haber varios, incluso muchos sistemas de archivos distintos, montados en puntos que corresponden a los subdirectorios. Estos distintos sistemas de archivos suelen estar en particiones diferentes, en diversas cantidades y tipos de dispositivos, incluyendo aquellos que se encuentran en red.

De forma independiente de cómo exactamente las cosas están unidas entre sí, todo se ve como un gran sistema de archivos; las aplicaciones no se preocupan en absoluto de los dispositivos físicos en los cuales residen los archivos.

En el pasado los diferentes sistemas operativos tipo UNIX organizaron este gran árbol de diversas maneras; incluso entre las distribuciones de Linux había muchas diferencias. Esto hizo que tanto el desarrollo de aplicaciones como llevar a cabo tareas de administración en más de un tipo de sistema fuera difícil y a menudo frustrante.

Como consecuencia de lo anterior, el ecosistema Linux ha trabajado arduamente para establecer procedimientos estandarizados para minimizar esos inconvenientes.

Cuando se habla de cómo se organizan los archivos y datos en el gran árbol de directorios, es importante conocer la taxonomía en cuánto a qué tipo de información tiene que ser leída y cuál escrita. En particular, hay dos tipos de diferencias:

1. Compartidos vs no-compartidos
   Los datos compartibles corresponden a los que se pueden compartir entre diferentes máquinas. Los datos no compartibles son aquellos que son específicos para un determinado host. Por ejemplo, los directorios personales de los usuarios pueden ser compartibles, mientras que los archivos de bloqueo de dispositivos no lo son.
2. Variable vs. estático
   Los archivos estáticos incluyen binarios, bibliotecas, documentación y todo lo que no cambia sin ayuda del administrador de sistemas. Los archivos variables son cualquier cosa que puede cambiar, incluso sin ayuda del administrador de sistemas.

A menudo estas distinciones lógicas están incorporadas como distintos tipos de información que residen en varios directorios, o incluso en particiones y sistemas de archivos.

El Estándar de Jerarquía del Sistema de Archivos (FHS, de Filesystem Hierarchy Standard), administrado inicialmente por el Free Standards Group y ahora por la Linux Foundation, especifica los directorios principales que deben estar presentes y describe sus propósitos. Se puede descargar desde http://www.pathname.com/fhs/.

Al especificar un diseño estándar, el FHS simplifica el tema de la localización de los archivos. Aunque la mayoría de las distribuciones de Linux respetan el FHS, probablemente ninguno de ellos lo sigue exactamente. Por otro lado, la última versión oficial no tiene en cuenta algunos desarrollos nuevos.

A las distribuciones les gusta probar diferentes cosas y eventualmente algunos de los experimentos terminan siendo ampliamente aceptados.

Los distribuidores de Linux pasan mucho tiempo asegurándose de que el diseño de su sistema de archivos es coherente y que evoluciona correctamente en el tiempo.

Es posible que haya directorios adicionales en el directorio raíz, específicos a cada distribución. Estos podrían incluir /misc, que se puede utilizar para información de diverso tipo y /tftpboot, que se utiliza para el inicio a través de tftp. En caso de haber archivos en ese directorio, están relacionados con el inicio del sistema sin utilizar un disco duro. Note que no viola la FHS el tener otros directorios; sin embargo, la norma es violada cuando se tienen componentes en directorios distintos a los dictados por el estándar.

Mientras que todo el sistema de archivos puede ser visto como un gran árbol, como hemos señalado, pueden haber varias particiones y sistemas de archivos trabajando de forma unida.

La partición y sistema de archivos en el cual el directorio raíz está contenido es bastante especial y a menudo está en una partición dedicada, con otros componentes con directorios como /home, /var, /opt , etc, los cuales son montados posteriormente.

La partición raíz debe contener todos los archivos esenciales necesarios para iniciar el sistema y luego montar el resto de los sistemas de archivos. Por lo tanto necesita utilidades, archivos de configuración, información del cargador de arranque y otros datos esenciales del inicio. Debe estar habilitado para:

• Iniciar el sistema.
• Restaurar el sistema desde copias de seguridad de medios externos, tales como cintas y otros medios extraíbles, o NAS, etc.
• Recuperar y/o reparar el sistema; un administrador experimentado debe tener las herramientas para diagnosticar y reconstruir un sistema dañado.

De acuerdo con el FHS, ninguna aplicación o paquete debería crear nuevos subdirectorios en el directorio raíz.

El directorio /bin es muy importante y éste:

• Contiene programas y scripts ejecutables necesitados tanto por administradores de sistemas y usuarios sin privilegios, que son necesarios cuando todavía no se ha montado ningún otro sistema de archivos, por ejemplo, al iniciar en modo monousuario o en modo de recuperación.
• También puede contener ejecutables que son utilizados indirectamente por scripts.
• No debe contener ningún subdirectorio.

Los comandos binarios que no son considerados esenciales lo suficiente para ir en /bin van en /usr/bin. Solamente los programas requeridos por los usuarios que no son root se colocan en esta categoría.

Nota: Algunas distribuciones muy recientes están abandonando la estrategia de la separación /bin y /usr/bin (como también /sbin y /usr/sbin) y solo tienen un directorio con enlaces simbólicos, preservando así una visión de dos directorios. Consideran como obsoleto el concepto tradicional de permitir la posibilidad de colocar /usr en una partición separada para ser montada después del inicio.

Los archivos esenciales para iniciar el sistema deben estar en el directorio /boot y sus subdirectorios. Los dos archivos absolutamente esenciales son:

• vmlinuz: El kernel Linux comprimido.
• initramfs: El sistema de archivos de RAM inicial, el cual se monta antes de que el sistema real de archivos raíz esté disponible.

Estos archivos tienen nombres largos que dependen de la versión del núcleo, en donde el nombre exacto está en función de la distribución de Linux. Además, en lugar de initramfs, el archivo puede ser llamado initrd, siglas de disco RAM inicial, el cual si bien es cierto corresponde al método antiguo, el nombre se usa en algunas distribuciones todavía.

El contenido exacto de /boot variará según la distribución y el tiempo; en un sistema RHEL 7 tenemos:

$ ls -lF /boot

total 135336
-rw-r--r--  1 root root   122094 Nov  4 09:20 config-3.10.0-123.13.1.el7.x86_64
-rw-r--r--  1 root root    81386 Dec  7 12:03 config-3.17.5
-rw-r--r--  1 root root    81896 Dec 15 07:28 config-3.18.0
-rw-r--r--  1 root root    81896 Dec 16 15:56 config-3.18.1
drwxr-xr-x. 6 root root     4096 Dec 16 15:57 grub2
-rw-r--r--. 1 root root 40732911 Sep  3 04:07 initramfs-0-rescue-3a0cc7a6d7bb4525815f4d2b4298e611.img
-rw-r--r--  1 root root 16406996 Dec 10 07:25 initramfs-3.10.0-123.13.1.el7.x86_64.img
-rw-r--r--  1 root root 13967066 Dec  7 12:03 initramfs-3.17.5.img
-rw-r--r--  1 root root 13914297 Dec 15 07:28 initramfs-3.18.0.img
-rw-r--r--  1 root root 13915331 Dec 16 15:56 initramfs-3.18.1.img
-rw-r--r--. 1 root root   865512 Sep  3 04:06 initrd-plymouth.img
-rw-r--r--  1 root root   228603 Nov  4 09:23 symvers-3.10.0-123.13.1.el7.x86_64.gz
lrwxrwxrwx  1 root root       24 Sep 28 10:18 System.map -> /boot/System.map-3.15.0+
-rw-------  1 root root  2841409 Nov  4 09:20 System.map-3.10.0-123.13.1.el7.x86_64
-rw-r--r--  1 root root  2875608 Dec  7 12:03 System.map-3.17.5
-rw-r--r--  1 root root  2891484 Dec 15 07:28 System.map-3.18.0
-rw-r--r--  1 root root  2891509 Dec 16 15:56 System.map-3.18.1
lrwxrwxrwx  1 root root       21 Sep 28 10:18 vmlinuz -> /boot/vmlinuz-3.15.0+
-rwxr-xr-x. 1 root root  4902000 Sep  3 04:07 vmlinuz-0-rescue-3a0cc7a6d7bb4525815f4d2b4298e611
-rwxr-xr-x  1 root root  4904592 Nov  4 09:20 vmlinuz-3.10.0-123.13.1.el7.x86_64
-rw-r--r--  1 root root  5363200 Dec  7 12:03 vmlinuz-3.17.5
-rw-r--r--  1 root root  5404992 Dec 15 07:28 vmlinuz-3.18.0
-rw-r--r--  1 root root  5405440 Dec 16 15:56 vmlinuz-3.18.1

Hace mucho tiempo estos archivos esenciales se solían poner directamente en /, en vez de usar un directorio /boot por separado, siguiendo las prácticas tradicionales de UNIX. Hoy en día esto se considera obsoleto.

Usted puede haber notado que existen varias versiones del núcleo en /boot, y para cada uno hay cuatro archivos disponibles (la posibilidad de elegir entre los núcleos se hace mediante GRUB en el inicio).

Los otros dos archivos además de vmlinuz y initramfs son:

• config: Es el archivo de configuración utilizado al compilar el kernel. Está presente sólo para referencia y porque puede ser de utilidad al depurar programas.
• System.map: La tabla de símbolos del kernel, la cual es muy útil en la depuración de programas. Entrega las direcciones hexadecimales de todos los símbolos del kernel.

Ninguno de estos archivos es requerido para iniciar o ejecutar el sistema.

Las distribuciones pueden poner otros archivos y directorios en /boot, tales como los sectores de arranque maestros guardados y otros datos no editados a mano.

Este directorio contiene archivos de dispositivos especiales (también conocidos como nodos de dispositivo) los cuales representan los dispositivos incorporados o conectados al sistema. Estos archivos especiales son esenciales para que el sistema funcione correctamente.

Dichos archivos de dispositivo representan caracteres (una trama de bytes) y dispositivos de bloque E/S. Los dispositivos de red no tienen nodos de dispositivo en Linux y en cambio son referenciados por su nombre, como eth1 o wlan0.

Todas las distribuciones modernas de Linux (no embebidas) utilizan el sistema udev, el cual crea nodos en /dev sólo a medida en que se necesita, lo que sucede cuando se encuentran dispositivos, ya sea al inicio o al conectarlos al sistema (discutiremos udev en una sección posterior).

Si usted fuera a echar un vistazo en el directorio /dev en un sistema de archivos sin montar, lo encontraría vacío; en el inicio se crea y monta un sistema de archivos virtual en /dev, el que luego es populado con nodos de dispositivos, como lo requiere udev. Los sistemas Linux embebidos pueden fijar los nodos de dispositivos y no utilizar udev o alguna alternativa como mdev.

Este directorio contiene los archivos de configuración de la máquina local y algunos scripts de inicio; aquí no debería haber ningún programa ejecutable binario.

Las distribuciones a menudo agregan archivos de configuración y directorios a /etc. Por ejemplo, Red Hat añade un número de directorios adicionales incluyendo /etc/sysconfig, donde se alojan archivos y directorios de configuración del sistema.

Otros subdirectorios importantes incluyen /etc/skel, que contiene archivos de plantilla usados para popular directorios de usuario recién creados. También /etc/init.d, que contiene scripts de inicio y detención cuando se utiliza la inicialización de System V.

En los sistemas Linux los directorios de usuarios están en /home, como /home/coop, /home/alumno, etc. Toda la configuración personal, datos y programas ejecutables se ponen en esta jerarquía de directorios. /home también puede contener subdirectorios para varios grupos o asociaciones de usuarios, como /home/estudiantes, /home/staff, /home/aliens, etc.

En otros sistemas operativos tipo UNIX, existe el concepto del árbol de directorios /home, pero puede ser sutilmente diferente. Por ejemplo, en Solaris los directorios de usuarios se crean en /export/home y luego la utilidad automount los montará en /home. Esto se debe a la situación habitual en que el directorio de los usuarios puede estar en cualquier lugar en una red corporativa, probablemente en un servidor NFS, en donde el directorio de cada usuario se montará automáticamente cuando esté en uso.

Linux también tiene la utilidad automount, pero muchos usuarios no están conscientes de ellos, y en sistemas personales probablemente el concepto de puntos de montaje NFS no aplicará.

Un usuario siempre puede sustituir la variable de ambiente $HOME para su directorio raíz, o la abreviación ~; es decir, los siguientes usos son equivalentes:

$ ls -l $HOME/public_html
$ ls -l ~/public_html

Hay una excepción: el directorio home del usuario root en los sistemas Linux siempre se encuentra en /root. Algunos sistemas UNIX antiguos pueden usar / en cambio, lo que puede causar algún desorden.

Este directorio debe contener sólo las bibliotecas necesarias para ejecutar los binarios en /bin y /sbin. Estas bibliotecas son particularmente importantes para iniciar el sistema y ejecutar comandos en el sistema de archivos raíz.

Los módulos del kernel (a menudo controladores de dispositivo o sistemas de archivos) se encuentran bajo /lib/modules/<kernel-versión-número>.

Los archivos de PAM (Pluggable Authentication Modules) se almacenan en el directorio /lib/security.

Los sistemas que soportan tanto binarios de 32 bits y 64 bits deben mantener ambos tipos de bibliotecas en el sistema. En los sistemas basados en Red Hat hay directorios separados para las bibliotecas de 32 bits (/lib) y 64 bits (/lib64).

Este directorio se usa normalmente para montar sistemas de archivos en medios extraíbles. Estos incluyen CDs, DVDs, unidades USB y disquetes del paleolítico.

Los sistemas Linux modernos montan estos medios de forma dinámica durante la inserción, momento en el cual udev crea directorios bajo /media y luego monta los sistemas de archivos extraíbles allí, con los nombres que se establecen a través de las reglas de udev especificadas en los archivos de configuración. Al desmontar y extraer los medios, los directorios que fueron usados como puntos de montaje en /media desaparecerán.

Si el medio extraíble tiene más de una partición y sistema de archivos, aparecerá más de una entrada en /media. En muchas distribuciones de Linux el administrador de archivos (como Nautilus) se abrirá cuando el medio es montado.

Nota: En algunas distribuciones más recientes (incluyendo SUSE y RHEL 7) los medios extraíbles se montarán en /run/media/[nombre de usuario]/... Vamos a tratar /run al final de este capítulo.

Se dispone de este directorio para que el administrador del sistema pueda montar temporalmente un sistema de archivos en caso de necesitarlo. Se usa comúnmente para sistemas de archivos en red, incluyendo:

• NFS
• Samba
• CIFS
• AFS

Históricamente, /mnt también fue usado para los tipos de archivos que se montan actualmente en /media (o /run/media) en los sistemas modernos.

En términos generales, este directorio no debe ser utilizado por programas de instalación. Una mejor alternativa es otro directorio temporal que no esté siendo usado.

Este directorio está diseñado para paquetes de software que desean mantener la totalidad o gran parte de sus archivos en un lugar aislado en vez de dispersarse por todo el sistema en los directorios compartidos con otros programas.

Por ejemplo, si dolphy_app fuera el nombre de un paquete en /opt, todos sus archivos deben residir en directorios bajo /opt/dolphy_app, incluyendo /opt/dolphy_app/bin para binarios y /opt/dolphy_app/man para las páginas man.

Esto puede hacer que tanto la instalación y desinstalación de software sean relativamente fácil, ya que todo está aislado de forma conveniente en una ubicación predecible y estructurada. También hace que sea más fácil para los administradores de sistemas el determinar la naturaleza de cada archivo asociado a un paquete.

Note, sin embargo, que si uno utiliza sistemas de empaquetamiento como RPM y APT, como veremos más adelante, también es fácil de instalar y desinstalar conservando un claro sentido de las ubicaciones de archivos, sin exhibir tal conducta antisocial con la distribución.

En Linux, el directorio /opt es utilizado a menudo por proveedores de aplicaciones, ya sea con software propietario o aquellos que desean evitar las complicaciones asociadas a los cambios entre distribuciones. Por ejemplo, en RHEL 7 los únicos paquetes se encuentran en esta categoría están en /opt/skype y /opt/google, en donde este último tiene subdirectorios para chrome, earth y talkplugin.

Los directorios /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib y /opt/man están reservados para uso del administrador del sistema local. Los paquetes pueden proporcionar archivos que estén vinculados o copiados en estos directorios reservados, pero también deben ser capaces de funcionar sin los programas que están en estos directorios especiales.

Este directorio es el punto de montaje para un seudosistema de archivos, donde toda la información reside sólo en memoria, no en disco. Tal como /dev, el directorio /proc está vacío en un sistema que no está corriendo.

El kernel muestra algunas estructuras de datos importantes a través de las entradas disponibles en /proc. Además, cada proceso activo en el sistema tiene su propio subdirectorio, el que ofrece información detallada sobre el estado del proceso, los recursos que está utilizando y su historia.

Las entradas en /proc a menudo se denominan archivos virtuales y tienen cualidades interesantes. Mientras que la mayoría tienen cero bytes de tamaño, cuando se visualiza su contenido es posible comprobar que pueden tener una gran cantidad de información.

Adicionalmente, la mayoría de los ajustes de hora y fecha en los archivos reflejan la hora y fecha actuales, indicativo del hecho de que están en constante cambio. De hecho, la información de estos archivos se obtiene sólo cuando son visualuzados, no se están actualizando constantemente o periódicamente.

Importantes pseudoarchivos, incluyendo /proc/interrupts, /proc/meminfo, /proc/mounts y /proc/partitions, proporcionan un vistazo del estado actual del hardware del sistema.

Otros archivos como /proc/filesystems y el directorio /proc/sys/, proveen información de configuración del sistema y de las interfaces.

Para propósitos de organización, los archivos que contienen información sobre un tema similar se agrupan en directorios virtuales y subdirectorios. Por ejemplo, /proc/scsi/ contiene información de todos los dispositivos SCSI físicos. De la misma forma, los directorios de procesos contienen información acerca de cada proceso corriendo en el sistema.

A lo largo de este curso examinaremos ampliamente las entradas en /proc, y echaremos un vistazo más detallado en los capítulos siguientes acerca de la configuración del kernel y monitoreo del sistema.

Este directorio es el punto de montaje para el seudosistema de archivos sysfs, donde toda la información reside sólo en memoria, no en disco. Al igual que /dev y /proc, el directorio /sys está vacío en un sistema detenido.

sysfs se utiliza tanto para recopilar información sobre el sistema, como también modificar su comportamiento mientras se ejecuta. En ese sentido se parece a /proc, pero es más nuevo y se ha adherido a normas estrictas acerca de qué tipo de entradas que puede contener. Por ejemplo, casi todos los seudoarchivos en /sys contienen sólo una línea o valor; no existe ninguna de las entradas largas que se pueden encontrar en /proc.

Al igual que con /proc, examinaremos entradas en /sys a lo largo de este curso, lo que será relevante en los próximos capítulos acerca de la configuración del kernel y monitoreo del sistema.

Este directorio (pronunciado "slash-root") es el directorio de inicio para el usuario root.

La cuenta de root que es dueña de este directorio se debe utilizar solamente para las acciones que requieren privilegios de superusuario. Para aquellas acciones que pueden realizarse como un usuario sin privilegios, utilice otra cuenta.

Este directorio contiene los archivos binarios esenciales para arrancar, restaurar, recuperar y/o reparar los binarios en el directorio /bin. También debe tener lo necesario para montar otros sistemas de archivos en /usr, /home y otros lugares de ser necesario, una vez que el sistema de archivos raíz esté en buenas condiciones en el arranque.

Los siguientes programas deberían estar incluidos en este directorio (siempre y cuando sus subsistemas estén instalados):

fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.

Nota: como se mencionó anteriormente, algunas distribuciones nuevas están abandonando la estrategia de separar /sbin y /usr/sbin (como también /bin y /usr/bin), y sólo tienen un directorio con enlaces simbólicos, preservando una vista de dos directorios.

Este directorio se utiliza para almacenar archivos temporales, y puede ser accedido por cualquier usuario o aplicación. Sin embargo, no se puede esperar que los archivos en /tmp estén ahí por largo tiempo:

• Algunas distribuciones corren trabajos de cron automatizados, los que generalmente eliminan los archivos de más 10 días, a menos que los scripts de purga hayan sido modificado para excluirlos. Esta es la política de RHEL 6.
• Algunas distribuciones eliminan el contenido de /tmp con cada reinicio del sistema. Esta ha sido la política de Ubuntu.
• Algunas distribuciones modernas utilizan un sistema de archivos virtual, usando el directorio /tmp sólo como un punto de montaje para un disco ram utilizando el sistema de archivos tmpfs. Esta es la política por defecto de los sistemas Fedora recientes. Cuando el sistema se reinicia, toda la información se pierde; ¡/tmp es de hecho temporal!

En este último caso, hay que evitar la creación de archivos de gran tamaño en /tmp, debido a que en realidad va a ocupar espacio en memoria en vez de disco, y es fácil dañar o bloquear el sistema a través del agotamiento de la memoria. Si bien es cierto que la guía para las aplicaciones es evitar poner archivos de gran tamaño en /tmp, hay un gran número de aplicaciones que violan esta política. Incluso si fuera posible ponerlos en otro lugar (tal vez mediante la especificación de una variable de entorno), muchos usuarios no saben cómo configurarlo, y por otro lado, todos los usuarios tienen acceso a /tmp.

Esta política puede ser cancelada en los sistemas utilizando systemd, como en Fedora, a través del siguiente comando:

$ systemctl mask tmp.mount

Luego de lo cual es necesario reiniciar el sistema.

El directorio /usr puede ser visto como una jerarquía secundaria. Se utiliza para los archivos que no son necesarios para el inicio del sistema. De hecho, /usr no necesita estar localizado en la misma partición que el directorio raíz y se puede compartir entre los hosts que utilizan la misma arquitectura de sistema a través de la red.

Los paquetes de software no deberían crear subdirectorios directamente bajo /usr. Podrían existir algunos enlaces simbólicos a otros lugares por razones de compatibilidad.

Este directorio tiene usualmente datos de sólo lectura. Contiene binarios que no son necesarios en modo monousuario. Contiene el directorio /usr/local, donde es posible almacenar binarios locales. Las páginas man se encuentran en /usr/share/man.

Este directorio contiene archivos de datos variables (o volátiles) que cambian frecuentemente durante el funcionamiento del sistema. Estos incluyen:

• Archivos de registro.
• Directorios y archivos de spool para imprimir, colas de correo, etc.
• Archivos de datos administrativos.
• Archivos transitorios y temporales, como contenido del caché.

Obviamente, /var no puede ser montado como un sistema de archivos de sólo lectura.

Por razones de seguridad, a menudo se considera una buena idea montar /var como un sistema de archivos por separado. Además, si el directorio se llena, no debería producir un bloqueo del sistema.

/var/log es donde se encuentran la mayoría de los archivos del registro del sistema. El directorio /var/spool es donde se almacenan los archivos locales para procesos como correo, impresión y trabajos de cron a la espera de ser liberados de la cola.

Un nuevo árbol de directorio montado en /run ha estado en uso desde hace varios años por las principales distribuciones de Linux, y pese a que ha sido propuesto para el FHS, no ha sido aceptado formalmente. Sin embargo es bueno saber acerca de su existencia, ya que muy probablemente se encontrará con él.

El propósito de /run es almacenar archivos transitorios: aquellos que contienen información del tiempo de ejecución (runtime), los cuales probablemente sean escritos tempranamente en el inicio del sistema, y que no requieren ser preservados al reiniciar.

Generalmente /run se implementa como un punto de montaje vacío, con un disco ram tmpfs (tal como /dev/shm) montado en tiempo de ejecución. Por lo tanto, este es un seudosistema de archivos existente sólo en memoria.

Algunos directorios existentes, tal como /var/run y /var/lock, serán enlaces simbólicos a los directorios bajo /run. Otros, dependiendo de cada distribución, pueden apuntar a directorios bajo /run.

Según el Filesystem Hierarchy Standard (FHS), qué directorio de alto nivel (bajo /, como /tmp y no como /tmp/otros) son los más apropiados para:

• archivos de configuración.
• archivos personales.
• archivos del registro del sistemas, como los registro del servidor.
• archivos que son utilizados sólo en el inicio, tales como el kernel e initrd.
• módulos del kernel Linux, los que son extensiones cargables del kernel.

Hay algunos directorios que contienen entradas especiales, las cuales resumen las propiedades del sistema, en vez de mostrar otro tipo de datos almacenados en el disco. Esos pseudo-sistemas de archivos son muy importantes para que el sistema funcione adecuadamente. ¿Cuáles de los siguientes directorios contienen este tipo de datos? Seleccione todos los que apliquen:

/boot
/dev
/etc
/lib
/mnt
/opt
/proc
/sys
/srv

• Laboratorio 5.1
• Laboratorio 5.2

Usted debería ser capaz de:

• Explicar porqué Linux requiere que su árbol de sistemas de archivos esté organizado, y cuáles son las consideraciones más importantes en relación a cómo hacerlo.
• Saber cuál es el rol que juega el Estándar de jerarquía del sistema de archivos (FHS).
• Describir qué debe estar disponible durante el inicio en el directorio raíz (/) , y qué debe estar disponible una vez que el sistema ya se haya iniciado.
• Explicar cada uno de los principales subdirectorios del árbol en términos de propósito y contenido.

El kernel del sistema operativo se encuentra en el corazón de todos los sistemas Linux, desde el dispositivo embebido o móvil más pequeño, a la supercomputadora más poderosa. Cabe destacar que el kernel tiene las mismas tareas esenciales en este amplio espectro. Controla el acceso al hardware, la competencia por los recursos entre diferentes aplicaciones y otras tareas, maneja la actividad de E/S, los archivos y almacenamiento de datos, seguridad, redes, etc. Al seleccionar los parámetros de línea de comandos del kernel en el inicio, el sistema puede comportarse de diferentes formas.

Al final de este capítulo usted debería ser capaz de:

• Conocer las principales responsabilidades que el kernel debe cumplir y saber cómo lo hace.
• Explicar qué parámetros pueden ser configurados en la línea de comandos del kernel y cómo hacerlos efectivos, ya sea para un sólo inicio del sistema o de forma persistente.
• Saber en donde encontrar documentación detallada acerca de estos parámetros.
• Saber cómo usar sysctl para configurar parámetros del kernel ya sea una vez que el sistema ha iniciado, o de forma persistente luego del reinicio del sistema.

En rigor, Linux es sólo el kernel del sistema operativo. Este último incluye muchos otros componentes, como bibliotecas y aplicaciones que interactúan con el kernel.

El kernel es el componente central esencial que conecta el hardware al software y maneja recursos del sistema, como memoria y asignación de tiempo de CPU a las aplicaciones y servicios que compiten por ellos. Se ocupa de todos los dispositivos conectados utilizando los controladores de dispositivos, y hace que estén disponibles para el uso del sistema operativo.

Un sistema que ejecuta solamente el kernel tiene una funcionalidad bastante limitada. Esto se encuentra sólo en dispositivos dedicados y enfocados a los sistemas embebidos.

Las principales responsabilidades del kernel incluyen:

• Inicialización del Sistema y booteo.
• Planificación de procesos.
• Gestión de Memoria.
• Controlar acceso al hardware.
• E/S (Entrada/Salida) entre aplicaciones y dispositivos de almacenamiento.
• Implementación de sistemas de archivos locales y de red.
• Control de seguridad, tanto a nivel local (como los permisos del sistema de archivos) y en red.
• Control de la red.

Varios parámetros son pasados al sistema durante el inicio a través de la línea de comandos del kernel. Normalmente están en la línea del kernel (o linux16) en el archivo de configuración de GRUB, pero pueden ser modificados en el inicio.

En los ejemplos anteriores las filas largas fueron divididas para su visualización, pero cada una de ellas corresponden a una línea larga. Recuerde que discutimos cómo configurar las dos versiones de GRUB, y que la versión 2 no debe editarse directamente, sino modificar los archivos correspondientes en /etc.

Basta hacer lo siguiente para ver con qué línea de comandos inició un sistema:

$ cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-3.18.1 root=UUID=9d6b5801-9c7e-4c17-9068-49923952338e ro rhgb quiet loop.max_loop=256 LANG=en_US.UTF-8

Hay una lista sorprendentemente larga de los parámetros disponibles del kernel. Documentación detallada al respecto se puede encontrar aquí:

• En las fuentes del kernel, en el archivo Documentation/kernel-parameters.txt.
• En línea, en http://kernel.org/doc/Documentation/kernel-parameters.txt.
• En el paquete de documentación del kernel proveído por la mayoría de las distribuciones, con un nombre similar a kernel-doc o linux-doc.
• Ejecutando el comando man bootparam.

Los parámetros pueden ser especificados simplemente como un valor dado como argumento, o de la forma param=valor, donde el valor dado puede ser un string, entero, arreglo de enteros, etc, tal como se explica en el archivo de documentación.

Por convención, no debería haber parámetros intencionalmente escondidos o secretos, todos ellos deberían estar explicados en la documentación. Los parches a las fuentes del kernel con parámetros nuevos deben incluir modificaciones en el archivo de documentación.

La interfaz sysctl puede ser utilizada para leer y ajustar los parámetros del kernel en tiempo de ejecución. Los valores actuales se pueden visualizar con el siguiente comando:

$ sysctl -a

....
kernel.pid_max = 32768
...
kernel.threads-max = 63707
 ....
net.ipv4.ip_default_ttl = 64
....
net.ipv4.ip_forward = 0
....
vm.nr_hugepages = 16
vm.swappiness = 10
....

Cada valor corresponde a un seudoarchivo en particular bajo /proc/sys, en donde las diagonales son reemplazadas por puntos. Por ejemplo, las dos siguientes sentencias son equivalentes:

$ sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
$ sudo sysctl net.ipv4.ip_forward=1

donde la segunda forma se usa para establecer un valor con la interfaz de línea de comando sysctl. No se puede dejar espacios alrededor del signo = en este comando. Note que en la primera forma, no es posible utilizar sudo con echo; el comando debe hacerse en la forma en que se muestra, o ejecutándolo como root.

Si va a través de los seudoarchivos en /proc/sys va a obtener la misma información que provee sysctl -a. Puede obtener todos los detalles sobre cómo utilizar sysctl con man 8 sysctl. Para obtener información acerca de cómo se usa la función sysctl() desde un programa para realizar las mismas operaciones, ejecute man 2 sysctl.

Si la configuración está en /etc/sysctl.conf (ver man sysctl.conf para más detalles), es posible realizar ajustes en el inicio del sistema.

Note que el comando:

$ sudo sysctl -p

lleva a cabo de forma inmediata lo que se encuentra en el archivo de configuración, ajustando todos los parámetros según se haya especificado; esto también es parte del proceso de inicio.

En algunas distribuciones recientes basadas en systemd (como en RHEL 7), el archivo de configuración es ahora /usr/lib/sysctl.d/00-system, pero el archivo original está soportado todavía, ya que está autodocumentado en ese archivo.

En este capítulo se describen dos formas de realizar ajustes al kernel. La línea de comandos del kernel permite especificar opciones al inicio, mientras que el uso de sysctl permite la especificación de opciones de tiempo de ejecución. Seleccione cuál de las siguientes opciones corresponden a ajustes en tiempo de ejecución:

Habilitar IP forwarding

Montar el sistema de archivos raíz en modo sólo lectura

Activar el sistema de archivos raíz en el volumen lógico especificado

Número máximo PID

Deshabilitar la detección de DM RAID

Seleccionar el lenguaje del sistema

Ingresar en modo monousuario

• Laboratorio 6.1
• Laboratorio 6.2

Usted debería ser capaz de:

• Conocer las principales responsabilidades que el kernel debe cumplir y saber cómo lo hace.
• Explicar qué parámetros pueden ser configurados en la línea de comandos del kernel y cómo hacerlos efectivos, ya sea para un sólo inicio del sistema o de forma persistente.
• Saber en donde encontrar documentación detallada acerca de estos parámetros.
• Saber cómo usar sysctl para configurar parámetros del kernel ya sea una vez que el sistema ha iniciado, o de forma persistente luego del reinicio del sistema.

El kernel Linux hace un uso extensivo de módulos, los cuales contienen software importante que puede ser cargado y descargado según se necesite después que el sistema ha iniciado. Muchos módulos incorporan controladores de dispositivos para el control de hardware, ya sea como parte del sistema o periféricos. Otros módulos pueden controlar protocolos de red, proveer soporte a diferentes tipos de sistemas de archivos y muchos otros propósitos. Los parámetros pueden ser especificados al cargar los módulos con el fin de controlar su comportamiento. El resultado final es una gran flexibilidad y agilidad en la respuesta a las condiciones y necesidades cambiantes.

Al final de este capítulo usted debería ser capaz de:

• Enumerar las ventajas en la utilización de módulos del kernel.
• Utilizar insmod, rmmod y modprobe para cargar y descargar módulos del kernel.
• Saber cómo usar modinfo para encontrar información acerca de los módulos del kernel.

Muchas piezas de soporte en el kernel Linux están diseñadas como parte integral del kernel cuando éste se carga inicialmente, o para ser agregadas (o removidas) más tarde en forma de módulos según sea necesario. De hecho, la mayoría de los componentes del kernel se integran como módulos, con excepción de los elementos centrales.

Tales módulos pueden o no ser controladores de dispositivos. Por ejemplo, pueden implementar un cierto protocolo de red o sistema de archivos que maneja un dispositivo de hardware o software. Incluso en los casos en que prácticamente siempre se necesitará la funcionalidad, la incorporación de la capacidad de carga y descarga como módulo facilita el desarrollo de software, ya que no hacen falta reinicios del kernel para probar los cambios realizados.

Incluso con el uso generalizado de los módulos del kernel, Linux conserva una arquitectura de kernel monolítico en vez de un microkernel. Esto es porque cuando se carga un módulo se convierte en una parte completamente funcional del kernel, con pocas restricciones. Estos se comunican con todos los subsistemas del kernel principalmente a través de recursos compartidos, como memoria y archivos de bloqueo, más que a través de pasar mensajes como puede ocurrir en un microkernel.

Linux no es el único sistema operativo que utiliza módulos; Solaris lo hace y también AIX, quienes las llaman extensiones del kernel. Sin embargo, Linux las utiliza de manera particularmente robusta.

Hay una serie de herramientas que se utilizan con los módulos del kernel:

• lsmod: Lista los módulos cargados.
• insmod: Carga módulos directamente.
• rmmod: Remueve módulos directamente.
• modprobe: Carga o descarga módulos, utilizando una base de datos preconstruida de los módulos con información de sus dependencias.
• depmod: Reconstruye la base de datos de dependencia de módulos; es requerida por modprobe y modinfo.
• modinfo: Proporciona información acerca de un módulo.

La carga y descarga del módulo se debe realizar como usuario root. Si se conoce la ruta completa, el módulo se puede cargar directamente de la siguiente forma:

$ sudo /sbin/insmod <pathto>/module_name.ko

La ubicación normal de los módulos del kernel está bajo el árbol de directorios /lib/modules/<kernel-version>. Un módulo del kernel siempre tiene una extensión .ko, como e1000e.ko, ext4.ko, o usbserial.ko.

Los módulos del kernel están asociados a la versión específica del kernel y deben coincidir con el kernel en ejecución o no pueden ser cargados. Deben ser compilados ya sea cuando el propio kernel es compilado, o posteriormente en un sistema que contiene las fuentes del kernel y la configuración de compilación para realizarlo de forma apropiada.

Mientras el módulo es cargado es posible ver su estado con lsmod:

$ lsmod

Module Size   Used by
...
usb_storage               50309   0
vmnet                     38408   13
fuse                      74097   5
....
snd_hda_codec_analog       9813   1
snd_hda_codec_generic     47551   1 snd_hda_codec_analog
snd_hda_intel             19279   4
snd_usb_audio            140055   3
....
soundcore                  5891   2 snd,snd_hda_codec
nouveau                  911957   4
ahci                      23547   8
libahci                   21534   1 ahci
skge                      29924   0
.....

El módulo se puede remover directamente como sigue:

$ sudo /sbin/rmmod module_name

Note que al remover un módulo no es necesario proveer ya sea la ruta completa del archivo o la extensión .ko.

En la mayoría de los casos los módulos no son cargados ni descargados con insmod y rmmod. En vez de eso, se usa modprobe, de la forma que se muestra en continuación:

$ sudo /sbin/modprobe module_name
$ sudo /sbin/modprobe -r module_name

en donde la segunda forma es usada para remover el módulo. Para que modprobe funcione, los módulos tienen que estar instalados en el lugar correcto, generalmente bajo /lib/modules/$(uname -r), donde $(uname -r) entrega la versión actual del kernel, por ejemplo 3.18.3.

Hay algunas cosas importantes para mantener en mente al cargar y descargar módulos:

• No es posible descargar un módulo que está siendo usado por uno u otros módulos, lo cual se puede determinar a partir de la lista que provee lsmod.
• No es posible descargar un módulo que está siendo usado por uno o más procesos, lo cual también puede ser visto en la salida de lsmod. Sin embargo, hay módulos que no llevan un registro de este tipo de referencias, como los módulos de los controladores de dispositivos de red, ya que sería muy difícil reemplazar temporalmente un módulo sin apagar y reiniciar gran parte de la pila de red.
• Cuando un módulo es cargado con modprobe, el sistema automáticamente carga todos los módulos de los cuales depende, los cuales necesitan ser cargados primero.
• Cuando un módulo es descargado con modprobe -r, el sistema descargará automáticamente cualquier otro módulo que esté siendo utilizado por éste, siempre y cuando no estén siendo usados de forma simultánea por otros módulos cargados.

modinfo puede ser usado para encontrar información acerca de los módulos del kernel (tanto si están actualmente cargados o no), como se muestra a continuación:

$ /sbin/modinfo my_module
$ /sbin/modinfo <pathto>/my_module.ko

Por ejemplo:

$ modinfo e1000

filename: /lib/modules/3.1.0/kernel/drivers/net/e1000/e1000.ko
version: 7.3.21-k8-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: E005D763BC7910379BDD09A
alias: pci:v00008086d00002E6Esv*sd*bc*sc*i*
alias: pci:v00008086d000010B5sv*sd*bc*sc*i*
alias: pci:v00008086d00001099sv*sd*bc*sc*i*
....
alias: pci:v00008086d00001000sv*sd*bc*sc*i*
depends: vermagic: 3.1.0 SMP preempt mod_unload
parm: TxDescriptors:Number of transmit descriptors (array of int)
parm: RxDescriptors:Number of receive descriptors (array of int)
parm: Speed:Speed setting (array of int)
parm: Duplex:Duplex setting (array of int)
parm: AutoNeg:Advertised auto-negotiation setting (array of int)
parm: FlowControl:Flow Control setting (array of int)
parm: XsumRX:Disable or enable Receive Checksum offload (array of int)
parm: TxIntDelay:Transmit Interrupt Delay (array of int)
parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm: RxIntDelay:Receive Interrupt Delay (array of int)
parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm: debug:Debug level (0=none,...,16=all) (int)

lo cual despliega información acerca de la versión, nombre de archivo, qué dispositivos de hardware puede manejar el controlador y qué parámetros pueden ser suministrados durante la carga.

Mucha de la información acerca de los módulos puede ser visualizada también en el árbol de directorios del seudosistema de archivos /sys; en el ejemplo anterior se podría mirar bajo /sys/module/e1000, y algunos - si es que no todos los parámetros - se pueden leer y/o escribir bajo /sys/module/e1000/parameters. Le mostraremos cómo configurarlos en el ítem siguiente.

En muchos casos es posible especificar valores de los parámetros al cargar el módulo, como se muestra aquí:

$ sudo /sbin/insmod <pathto>/e1000e.ko debug=2 copybreak=256

o de forma más fácil para un módulo que está presente en la ubicación adecuada del sistema:

$ sudo /sbin/modprobe e1000e debug=2 copybreak=256

Los archivos en el directorio /etc/modprobe.d controlan algunos parámetros que entran en juego cuando la carga se realiza con modprobe. Estos parámetros incluyen alias de nombre de módulo y opciones proveídas automáticamente. También es posible poner módulos específicos en una lista negra para evitar que sean cargados.

Los ajustes se aplican tanto a módulos que están cargados y descargados, y la configuración puede ser modificada a medida en que las necesidades cambian.

El formato de los archivos en /etc/modprobe.d es simple: un comando por línea, con líneas en blanco y otras con #, en las cuales se ignora el contenido (lo cual es útil para agregar comentarios). Una diagonal inversa al final de una línea causa que ésta continúe en la siguiente, lo cual le brinda un mayor orden al archivo.

¿Qué utilidad coincide con la descripción?

• Lista los módulos cargados.
• Carga o descarga módulos usando una base de datos de módulos preconstruídos.
• Descarga un módulo directamente.
• Reconstruye la base de datos de dependencia de módulos.
• Provee información acerca de un módulo.

• Laboratorio 7.1

Usted debería ser capaz de:

• Enumerar las ventajas de utilizar módulos del kernel.
• Usar insmod, rmmod y modprobe para cargar y descargar módulos del kernel.
• Saber cómo usar modinfo para encontrar encontrar información acerca de módulos del kernel.

Linux usa udev, una pieza de software inteligente para descubrir hardware y dispositivos periféricos tanto durante el inicio como después, una vez que son conectados al sistema. Los nodos de dispositivo son creados automáticamente, para luego utilizados por las aplicaciones y subsistemas del sistema operativo para comunicarse y transferir datos desde y hacia los dispositivos. Los administradores del sistema pueden controlar cómo opera udev a través de la creación de reglas especiales para asegurar que los resultados corresponden al comportamiento deseado.

Al final de este capítulo usted debería ser capaz de:

• Explicar el rol de los nodos de dispositivo y cómo se usan los números mayor y menor.
• Comprender la necesidad de usar udev y enumerar sus componentes principales.
• Describir cómo funciona el administrador de dispositivos udev.
• Identificar archivos de reglas de udev y aprender a crear reglas personalizadas.

Los dispositivos orientados a caracteres y bloques tienen entradas de sistemas de archivos asociados a ellos; por otro lado, los dispositivos de red en Linux no los poseen. Estos nodos de dispositivo pueden ser usados por programas para comunicarse con los dispositivos, usando llamadas al sistema E/S normal como open(), close(), read() y write(). Por otra parte, los dispositivos de red funcionan a través de la transmisión y recepción de paquetes, los cuales deben construirse a partir de la decodificación de flujos de datos, o ser reensamblados cuando son recibidos.

Un controlador de dispositivo puede administrar múltiples nodos de dispositivo, los cuales están localizados normalmente en el directorio /dev:

$ ls -l /dev

total 0
crw------- 1 coop audio 14, 4 Jul 9 01:54 audio
crw------- 1 root root 10, 62 Jul 9 01:54 autofs
lrwxrwxrwx 1 root root 4 Jul 9 01:54 cdrom -> scd0
lrwxrwxrwx 1 root root 4 Jul 9 01:54 cdrw -> scd0
crw------- 1 coop root 5, 1 Jul 9 06:54 console
....
lrwxrwxrwx 1 root root 4 Jul 9 01:54 dvd -> scd0
lrwxrwxrwx 1 root root 4 Jul 9 01:54 dvdwriter -> scd0
crw------- 1 root root 10, 228 Jul 9 01:54 hpet
crw-r----- 1 root kmem 1, 2 Jul 9 01:54 kmem
crw------- 1 root root 1, 11 Jul 9 01:54 kmsg
crw-r----- 1 root kmem 1, 1 Jul 9 01:54 mem
crwxrwxrwx 1 root root 1, 3 Jul 9 01:54 null
crw-rw---- 1 root root 10, 144 Jul 9 01:54 nvram
brw------- 1 coop disk 11, 0 Jul 9 01:54 scd0
....
brw-r----- 1 root disk 8, 0 Jul 9 01:53 sda
brw-r----- 1 root disk 8, 1 Jul 9 01:53 sda1
brw-r----- 1 root disk 8, 2 Jul 9 06:54 sda2
....
brw-r----- 1 root disk 8, 16 Jul 9 01:53 sdb
brw-r----- 1 root disk 8, 17 Jul 9 01:53 sdb1
brw-r----- 1 root disk 8, 18 Jul 9 01:53 sdb2
....
crw------- 1 coop audio 14, 1 Jul 9 01:54 sequencer
crw------- 1 coop audio 14, 8 Jul 9 01:54 sequencer2
crw-rw-rw- 1 root tty 5, 0 Jul 9 01:54 tty
crw-rw---- 1 root root 4, 0 Jul 9 14:54 tty0
crw------- 1 root root 4, 1 Jul 9 06:54 tty1
cr--r--r-- 1 root root 1, 9 Jul 9 01:53 urandom
....
crw-rw-rw- 1 root root 1, 5 Jul 9 01:54 zero

Los nodos de dispositivo pueden ser creados de la siguiente forma:

$ sudo mknod [-m mode] /dev/name <type> <major> <minor>
e.g., mknod -m 666 /dev/mycdrv c 254 1

Los números mayor y menor identifican el controlador asociado al dispositivo. En este esquema el controlador reserva de forma única un grupo de números. En la mayoría de los casos (con excepciones) los nodos de dispositivo del mismo tipo (de bloque o caracter) que tienen el mismo número mayor, usan el mismo controlador.

Al listar algunos nodos de dispositivo de la forma en que se muestra, se obtiene lo siguiente:

$ ls -l /dev/sda*

brw-rw---- 1 root disk 8,  0 Dec 29 06:40 /dev/sda
brw-rw---- 1 root disk 8,  1 Dec 29 06:40 /dev/sda1
brw-rw---- 1 root disk 8,  2 Dec 29 06:40 /dev/sda2
.......
Los números mayor y menor se muestran en el mismo lugar que el tamaño de archivo al visualizar archivos normales; en el ejemplo de arriba sería 8, 0, etc. Mientras que los usuarios finales probablemente no necesitarán referirse explícitamente a los números mayor y menor (ya que lo harán por nombre), los administradores de sistema podrían requerir hacerlo de vez e cuando, en caso que el sistema se confunda acerca de los dispositivos, o si se ha agregado hardware en tiempo de ejecución.

El número menor es usado sólo por el controlador de dispositivo para diferenciar entre los diferentes dispositivos que este puede controlar, o cómo son usados. Estos pueden corresponder a instancias diferentes de un mismo tipo de dispositivo (como la primera y segunda tarjeta de sonido o partición de disco duro), o diferentes modos de operación de un determinado dispositivo (como diferentes densidades en una unidad de disquete).

Los números de dispositivo tienen sentido en el espacio de usuario también. Las llamadas al sistema mknod() y stat() entregan información acerca de los números mayor y menor.

Los métodos de gestión de nodos de dispositivo se tornaron torpes y difíciles a medida en que Linux evolucionó. El número de nodos de dispositivo en /dev y sus subdirectorios alcanzó una cantidad entre 15.000 a 20.000 en la mayoría de las instalaciones durante la serie del kernel 2.4. Nodos para todo tipo de dispositivos - los que nunca van a ser utilizados en la mayoría de las instalaciones - todavía son creados de forma predeterminada, ya que los distribuidores no tienen la certeza de qué hardware estará presente en un sistema.

Por supuesto, muchos desarrolladores y administradores de sistema recortaron la lista a lo que realmente se necesita, lo cual es especialmente útil en sistemas embebidos, pero esto correspondió a una tarea esencialmente manual y propensa a generar errores.

Note que mientras los nodos de dispositivo no son archivos normales y no ocupan mucho espacio en el sistema de archivos, el tener directorios muy grandes disminuye la velocidad de acceso a los nodos de dispositivo, especialmente en el primer uso. Por otro lado, el agotamiento de los números mayor y menor disponibles requiere un enfoque más moderno y dinámico en cuanto a la creación y el mantenimiento de los nodos de dispositivo.

Lo ideal sería registrar dispositivos por nombre. Sin embargo, no es posible librarse de los números mayor y menor del todo, debido a que el estándar POSIX los exige (POSIX es un acrónimo de Interfaz de sistema operativo portable, una familia de estándares diseñados para asegurar la compatibilidad entre diferentes sistemas operativos).

El método udev crea nodos de dispositivo al vuelo, a medida en que son requeridos. No hay necesidad de mantener un gran cantidad de nodos de dispositivo que no van a ser usados nunca. La u en udev viene de usuario e indica que la mayoría del trabajo de creación, eliminación y modificación de nodos de dispositivo se realiza en el espacio de usuario.

udev maneja la generación dinámica de nodos de dispositivo y evolucionó de tal forma que reemplazó mecanismos como devfs y hotplug. Una característica interesante es el soporte de nombres persistentes para los dispositivos; los nombres no necesitan depender del orden en el cual los dispositivos son conectados. Tal comportamiento es controlado en las especificaciones de las reglas de udev.

udev se ejecuta como demonio (ya sea udevd o systemd-udevd) y monitorea un netlink socket. Cuando dispositivos nuevos son inicializados o removidos, el utilitario uevent del kernel envía un mensage a través del socket, el que es recibido por udev, el cual realiza la acción apropiada para crear o remover entradas de los nodos de dispositivo de acuerdo a las reglas.

Los tres componentes de udev son:

1. La biblioteca libudev, la cual permite el acceso a la información de los dispositivos.
2. El demonio udevd, el cual gestiona el directorio /dev .
3. La utilidad udevadm para el control y diagnóstico.

La manera más apropiada de utilizar udev es tener un sistema original; el directorio /dev está vacío en el arranque del kernel y luego se puebla con nodos de dispositivo a medida en que se necesitan. Cuando se usa de esta forma, es necesario iniciar usando una imagen initramfs, la cual puede contener un conjunto de nodos de dispositivos preliminares, como también la infraestructura de udev.

A medida en que se agregan o remueven dispositivos desde el sistema - en este caso al trabajar con el subsistema hotplug - udev actúa ante la notificación de eventos para crear y remover nodos de dispositivo. La información necesaria para crearlos con los nombres adecuados, números mayor y menor, permisos, etc., es obtenida a través del registro existente en el seudosistema de archivos sysfs (montado en /sys) y un conjunto de archivos de configuración.

El archivo principal de configuración es /etc/udev/udev.conf. Este contiene información de dónde poner los nodos de dispositivo, permisos por defecto, dueños, etc. Por defecto, las reglas para los nombres de los dispositivos están ubicadas en el directorio /etc/udev/rules.d. A través de la lectura de la página man de udev es posible obtener una gran cantidad de información específica acerca de cómo configurar reglas para situaciones comunes.

Cuando udev recibe un mensaje desde el kernel acerca de dispositivos que están siendo añadidos o removidos, analiza los archivos de configuración en /etc/udev/rules.d/*.rules para determinar si hay reglas que apliquen al dispositivo en cuestión.

Entonces udev toma las acciones apropiadas, incluyendo:

• Asignación de nombre a los nodos de dispositivo.
• Creación de nodos de dispositivo y links simbólicos.
• Ajuste de permisos de archivo y dueño para los nodos de dispositivo.
• Realizar otras acciones para inicializar el dispositivo y ponerlo disponible.

Estas reglas son completamente personalizables.

Los archivos de las reglas de udev están localizados bajo /etc/udev/rules.d/<rulename>.rules , con nombres como los siguientes:

• 30-usb.rules
• 90-mycustom.rules

Por defecto, cuando udev lee los archivos de reglas busca archivos con el sufijo .rules. Si encuentra más de un archivo, los lee uno por uno, de manera lexicográfica, es decir, en orden alfabético ascendente. El nombre estándar de un archivo de reglas corresponde generalmente a un número de dos dígitos seguido por un nombre descriptivo de la regla en cuestión, para finalizar con el sufijo .rules.

El formato para una regla udev es simple:

<match><op>value [, ...] <assignment><op>value [, ... ]

Hay dos partes separadas que están definidas en una misma línea:

• La primera parte consiste en uno o más pares indicados por == . Estos tratan de coincidir con los atributos y/o características de un dispositivo a algún valor.
• La segunda parte consiste en una o más asignaciones clave-valor, las que asignan un valor a un nombre, tal como un nombre de archivo, pertenencia a un grupo, incluso permisos de archivo, etc.

Si no se encuentra una regla que coincida, se usa el nombre de nodo de dispositivo y otros atributos por defecto.

Aquí hay un ejemplo de un archivo de reglas para un dispositivo Fitbit:

$ cat /etc/udev/conf.d/rules.d/99-fitbit.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="2687", ATTR{idProduct}=="fb01", SYMLINK+="fitbit", MODE="0666"

$ cat /etc/udev/conf.d/rules.d/98-kexec.rules

SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try-restart kdump.service" SUBSYSTEM=="cpu", ACTION=="offline", PROGRAM="/bin/systemctl try-restart kdump.service" SUBSYSTEM=="memory", ACTION=="add", PROGRAM="/bin/systemctl try-restart kdump.service" SUBSYSTEM=="memory", ACTION=="remove", PROGRAM="/bin/systemctl try-restart kdump.service"

$ cat 80-kvm.rules

KERNEL=="kvm", GROUP="kvm", MODE="0666"

$ cat 99-fuse.rules

KERNEL=="fuse", MODE="0666",OWNER="root",GROUP="root"

¿Qué dispositivos de hardware se listan bajo /dev como archivos especiales? Seleccione todos los que apliquen:

Mouse

Adaptador de vídeo

Adaptador de red

Cámara web

Disco duro

Dispositivo USB

• Laboratorio 8.1

Usted debería ser capaz de:

• Explicar el rol de los nodos de dispositivo y cómo se usan los números mayor y menor.
• Comprender la necesidad del método udev y enumerar sus componentes principales.
• Describir cómo funciona el administrador de dispositivos udev.
• Identificar archivos de reglas de udev y saber crear archivos de reglas personalizadas.

El particionado y formateo de los discos duros disponibles es una parte crítica en la instalación del sistema. Es posible escoger diferentes esquemas en función del tamaño del sistema, el número de usuarios y sus necesidades. Otros ítems a tomar en cuenta es el tipo de hardware del que se dispone, particularmente el tipo de bus de datos al cual el sistema de almacenamiento está conectado.

Se debe tener mucho cuidado al configurar o modificar las tablas de particiones, ya que los errores de este tipo pueden ser muy destructivos.

Al final del capítulo usted debería ser capaz de:

• Describir y contrastar los tipos de discos duros y buses de datos más comunes.
• Explicar cómo es la geometría de un disco y otros conceptos de particionamiento.
• Comprender cómo los dispositivos de disco son nombrados y cómo identificar sus nodos de dispositivo asociados.
• Distinguir las distintas estrategias de particionamiento y saber seleccionarlas correctamente.
• Usar las utilidades blkid y fdisk.
• Respaldar y restaurar tablas de partición.

Existe una gran variedad de tipos de discos duros; cada uno está caracterizado por el tipo de bus de datos a través del cual se conecta, como también otros factores como velocidad, capacidad y cuán bien operan múltiples unidades de forma simultánea.

• IDE y EIDE (Entorno de desarrollo integrado e IDE mejorado)
  Estos fueron el estándar en notebooks y PCs de escritorio por años. Sin embargo, son pequeños y lentos en comparación a hardware más moderno, por lo cual actualmente están obsoletos; de hecho, los controladores no están disponibles en máquinas actualizadas.
• SATA (Serial ATA)
  Este tipo fue diseñado para reemplazar a Parallel ATA (PATA) (el cual fue conocido originalmente como IDE). Tenían una mayor transferencia de datos, cables más pequeños y eran detectados como dispositivos SCSI por el sistema operativo, lo cual simplificó el tema de escribir controladores de software (entre otras cosas), aún siendo que el hardware no es realmente SCSI.
  En comparación a PATA, SATA ofrece un cable de tamaño menor (7 pines), sustitución en caliente (hot swapping) y una transferencia de datos más rápida y eficiente. Los controladores más nuevos pueden manejar 16 GB/s, pero 3 GB/s y 6 GB/s son los valores más comunes en dispositivos del segmento usuario normal.
• SCSI (Interfaz de Sistema para Pequeñas Computadoras)
  Estos han sido el pilar de los servidores empresariales por décadas. Mientras que pueden tener una capacidad menor que los discos SATA, tienen a ser mucho más rápidos y a trabajar en paralelo mucho mejor, de la forma en la que se requiere para algunas configuraciones en RAID.
  Hay varias versiones de SCSI: Fast, Wide, Ultra y UltraWide, lo cual torna un poco confusas las cosas. Además, hay muchos controladores de dispositivo diferentes, dependiendo del hardware específico. Eso no sucede en SATA, ya que en ese caso existen controladores estandarizados que pueden adaptarse a una gran variedad de hardware.
  Los discos SCSI van desde un rango pequeño (bus de 8 bits) a uno amplio (bus de 16 bits), con una tasa de transferencia desde 5MB por segundo (un valor bajo, correspondiente a dispositivos SCSI estándar) a cerca de 160MB por segundos (Ultra-Wide SCSI-3).
  La mayoría de los PCs usan unidades SCSI de un solo extremo o diferenciales. Desafortunadamente, los dos tipos no son compatibles entre sí. De todas formas, ambos tipos pueden coexistir en el mismo controlador.
  Los controladores de una sola terminación soportan hasta 7 dispositivos, con una longitud de cable de cerca de 6 metros. Los controladores diferenciales soportan hasta 15 dispositivos, con una longitud máxima del cable de unos 12 metros.
• SAS
  El Serial Attached SCSI es un protocolo serial punto a punto nuevo, que viene a reemplazar a la interfaz SCSI. Las tasas de transferencia son similar a SATA, pero el rendimiento general es mejor.
• USB
  Los dispositivos de Bus Universal en Serie incluyen memorias y discos duros externos USB. El sistema operativo los ve como dispositivos SCSI.
  En la misma categoría están las unidades SSD modernas (dispositivos de estado sólido), las cuales han bajado de precio, no tienen partes movibles, usan menos energía que las unidades de disco giratorio y tienen velocidades de transferencia más rápidas. Los SSD internos son instalados de forma similar y en los mismos encapsulados que los discos convencionales.
  Los SSD todavía cuestan un poco más pero el precio está bajando. Es algo común tener discos SSD y convencionales en una misma máquina, en donde las operaciones de rendimiento crítico y de alto tráfico de datos son llevadas a cabo en las unidades SSD.

La geometría del disco es un concepto con una historia larga para dispositivos giratorios; se habla de cabezales, cilindros, pistas y sectores.

Los discos giratorios se componen de uno o más platos, cada uno de los cuales es leído por uno o más cabezales. Los cabezales leen una pista del plato a medida en que el disco gira.

Estas pistas circulares están divididas en bloques de datos llamados sectores, generalmente de 512 bytes de tamaño. Un cilindro es un grupo que está formado por una misma pista en todos los platos.

A medida en que el tiempo pasa la figura de la estructura física ha sido cada vez menos relevante, debido a que se conoce poco de la electrónica interna de la unidad. Además, los SSD no tienen partes móviles ni ninguna de las partes descritas anteriormente.

Actualmente los discos están siendo fabricados con sectores más grandes que 512 bytes; están disponibles en 4 KB. Mientras que sectores de tamaño más grandes pueden conducir a velocidades de transferencia mayores, el soporte del sistema operativo no está listo todavía para lidiar con tamaños grandes.

Los discos se dividen en particiones. En términos geométricos, estos consisten en grupos físicamente contiguos de sectores o cilindros.

Una de las particiones primarias puede ser designada como una partición extendida, la cual puede ser subdividida en particiones lógicas.

SCSI y estándares relacionados como SATA, suportan hasta 15 particiones en el disco. Las particiones 1-4 son primarias o extendidas; las particiones 5-15 son lógicas. Sólo puede haber una partición extendida, pero esta puede ser dividida en cuántas particiones lógicas se necesiten, hasta que se alcance el número máximo de particiones permitidas.

Por ejemplo, la primera unidad SCSI o SATA se denomina sda, la segunda sdb y así sucesivamente. En la primera unidad, /dev/sda1 es la primera partición primaria, /dev/sda2 es la segunda, etc.

Si creamos una partición extendida como /dev/sda3, esta podría ser dividida en particiones lógicas, con designaciones numéricas como /dev/sda5, /dev/sda6, etc.

Nota: Linux no requiere que las particiones comiencen o terminen en los límites de los cilindros, pero otros sistemas operativos podrían presentar problemas ante la misma situación. Por esta razón, las herramientas de particionamiento de Linux tratan de terminar en los límites, con el fin de integrarse bien con otros sistemas. Obviamente, las particiones tampoco deberían traslaparse.

Hay diversas razones que justifican didivir los datos del sistema en múltiples particiones, incluyendo:

• Separación
  Es deseable aislar los datos de usuario y aplicaciones de los archivos del sistema operativo, la mayoría de los cuales son de lectura solamente, excepto durante la instalación y actualizaciones del sistema. Por ejemplo, /home, que contiene archivos específicos de los usuarios se suele poner en una partición por separado.
• Datos compartidos
  Múltiples sistemas operativos o máquinas pueden usar los mismos sistemas de archivos. Por ejemplo, /home podría estar montado como un directorio compartido en una red, a través de NFS. O alguien podría tener un sistema de inicio múltiple, incluso varias versiones de Linux, entre las cuales usted podría desear compartir /usr/local o /home, por dar un par de ejemplos.
• Seguridad
  Puede ser deseable imponer diferentes cuotas (espacio en disco), permisos y ajustes para diferentes partes del sistema.
• Tamaño
  Algunos datos son más bien constantes y otros variables o volátiles, y a menudo pueden incrementar su tamaño un poco. Por ejemplo, tales datos variables son almacenados generalmente en una partición montada en /var. Si la partición se queda sin espacio disponible, en el caso de estar en una partición por separado de /, será menos probable que el sistema se bloquee.
• Rendimiento
  Los datos que tienen que ser leídos con mayor frecuencia, en grandes trozos de información, serán accedidos más rápidamente si están en un disco rápido (como los SSD), o en términos anticuados, cercanos al centro del disco, en donde los tiempos de búsqueda son más cortos.
• Intercambio (swap)
  En los sistemas Linux es preferible tener un espacio de intercambio (conocido como swap) en una partición por separado, en lugar de un archivo en alguna partición que esté siendo utilizada con otro propósito. Esto tiene una ventaja secundaria, ya que los esquemas de hibernación utilizan el espacio en la partición de intercambio.

Un esquema común de particionamiento contiene una partición /boot, una para el sistema raíz /, una partición de intercambio y otra para el directorio /home.

Tenga en cuenta que es más difícil redimensionar una partición después de su creación e instalación del sistema. Recomendamos que haga un plan inteligente al respecto.

Discutiremos acerca de diseños de sistemas de archivos y el impacto de las particiones en ellos más adelante.

La tabla de partición del disco está contenida en el Registro de arranque principal (MBR), la cual es de 512 bytes de longitud y cuya estructura está definida por una convención que es independiente del sistema operativo.

La tabla de partición tiene 64 bytes de largo y está ubicada después del byte 446 del registro de arranque. Nota para los curiosos: hay 2 bytes más al final del MBR, lo cual se conoce como el número mágico, firma del MBR, o marca de final de sector, que tiene siempre el valor 0x55AA.

Los primeros 446 bytes están reservados para código máquina. Por lo general, forman parte de un programa de cargador de arranque como GRUB.

Sólo una partición en un disco específico puede ser marcada como activa. Cuando el sistema inicia, el cargador de booteo maestro busca ítems para cargar en esa partición.

Cada entrada en la tabla de partición tiene 16 bytes de largo y describe una de las cuatro posibles particiones primarias. La información que tiene cada una es la siguiente:

• Bit activo
• Dirección de inicio en formato cilindro/cabezal/sectores (CHS), lo cual es ignorado por Linux de todas formas
• Código del tipo de partición, indicando: xfs, LVM, ntfs, ext4, swap, etc
• Dirección final en CHS (también ignorado por Linux)
• Sector the inicio, contando linealmente desde 0
• Número de sectores en la partición.

Linux usa sólo los últimos dos campos para direccionamiento, utilizando el método de direccionamiento de bloque lógico (LBA).

El kernel Linux interactúa a bajo nivel con los discos a través de nodos de dispositivos que normalmente se encuentran en el directorio /dev. Generalmente los nodos de dispositivos son accedidos sólo a través de la infraestructura del sistema de archivos virtual del kernel; si se accede de cualquier otra forma a los nodos de dispositivo, es posible destruir un sistema de archivos completo. Eso es justamente lo que se hace al formatear una partición, como en el siguiente comando:

$ sudo mkfs.ext4 /dev/sda9

Los nodos de dispositivo para discos SCSI y SATA siguien una convención de nombres simple:

• El primer disco duro es /dev/sda.
• El segundo disco duro es /dev/sdb.
• etc.

Las particiones son enumeradas como sigue:

• /dev/sdb1 es la primera partición del segundo disco.
• /dev/sdc4 es la cuarta partición del tercer disco.

En las sentencias de arriba, sd puede ser un disco SCSI o SATA. Cuando aún se encontraban discos IDE, eran llamados /dev/hda3, /dev/hdb , etc.

El comando ls -l /dev mostrará los nodos de dispositivo disponibles.

Para dispositivos SCSI necesitamos elaborar un poco más en lo que se entiende por primer disco duro, segundo, etc. Estos están determinados por la combinación del número ID/número del controlador.

La designación de la unidad (a, b, c, etc.) está basada principalmente en el número de ID del dispositivo SCSI en vez de su posición en el bus mismo.

Por ejemplo, si tuviéramos dos controladoras SCSI, uno con ID 1 y otro con ID 3 en la controladora 0; uno con ID 2 y otro con ID 5 en la controladora 1 (note que el ID 2 está en la última unidad):

• ID 1 sería /dev/sda
• ID 3 sería /dev/sdb
• ID 2 (en la controladora 1) sería /dev/sdc
• ID 5 sería /dev/sdd

blkid es una utilidad para localizar dispositivos de bloque y entregar información acerca de sus atributos. Funciona con la biblioteca libblkid. Puede tomar como argumento un dispositivo en particular o una lista.

blkid funcionará solamente en dispositivos que contienen datos, es decir, una partición vacía no generará un identificador de bloque UUID.

blkid tiene dos formas principales de operación: ya sea buscando un dispositivo con un par específico NOMBRE=valor, o desplegando pares de NOMBRE=valor para uno o más dispositivos.

Si no se especifican argumentos, se listarán todos los dispositivos. Existe un buen número de opciones que indican cómo especificar qué atributos se desean listar.

Una herramienta relacionada es lsblk, la cual presenta los resultados en un formato de árbol, como se muestra abajo.

Los sistemas Linux deberían tener un mínimo de dos particiones:

• /(root): utilizado para todo el sistema de archivos lógico
  - En la práctica la mayoría de las instalaciones tendrán más de un sistema de archivos y más de una partición, las cuales trabajan unidas a través de los puntos de montaje.
  - Con la mayoría de los tipos de sistemas de archivos es difícil redimensionar la partición raíz; usando LVM, lo cual discutiremos más adelante, podemos facilitar esta tarea.

Aunque si bien es cierto es posible correr Linux con sólo la partición raíz, la mayoría de los sistemas usan más particiones para realizar respaldos de forma más fácil, usar de forma más eficiente las unidades de disco e implementar una mejor seguridad.

• Intercambio: se usa como una extensión de la memoria física; páginas de memoria que no tienen un respaldo en archivo físico, pueden ser movidas al disco hasta que se necesiten nuevamente.
  - La recomendación usual es que el tamaño del área de intercambio debería ser igual al de la memoria física, aunque a veces se recomienda usar el doble. Sin embargo, la opción adecuada depende de los escenarios de usos del sistema, como también de las capacidades de hardware. Ejemplos de este tema pueden ser encontrados en https://help.ubuntu.com/community/SwapFaq y en http://www.novell.com/support/kb/doc.php?id=7010157.
  - El sistema puede tener múltiples particiones o archivos de intercambio.
  - En un sistema de un sólo disco, trate de ubicar la partición de intercambio al centro del mismo; en sistemas de discos múltiples, trate de repartir áreas de intercambio en los discos.
  - Agregar más y más áreas de intercambio no ayudará necesariamente, ya que a partir de cierto punto se vuelve inútil. En los casos en que aparentemente falte memoria, es necesario agregar más memoria física o reevaluar la configuración del sistema.

El área de intercambio es usado como memoria virtual; cuando las páginas de procesos son movidas fuera de la memoria física, generalmente son almacenadas en el área de intercambio.

Particionar y reparticionar discos son operaciones peligrosas. Para tener la posibilidad de volver a la situación original si algo sale mal, es necesario saber cómo realizar respaldos y restaurar tablas de particiones.

Es bastante simple realizar una copia de seguridad con dd, como sigue:

$ sudo dd if=/dev/sda of=mbrbackup bs=512 count=1

lo cual respaldará el MBR en el primer disco, incluyendo la tabla de particiones de 64 bits, la cual es parte de ella.

El MBR puede ser restaurado de ser necesario, de la siguiente forma:

$ sudo dd if=mbrbackup of=/dev/sda bs=512 count=1

Note que los comandos mencionados copiarán solamente la tabla de partición primaria; no se harán cargo de cualquier tabla de partición que esté almacenada en otras partitiones (como particiones extendidas, por ejemplo).

Nota: usted debería asumir que modificar la tabla de partición del disco podría eliminar toda la información de todos los sistemas de archivos en el disco (no debería, pero es mejor ser precavido). Por lo tanto, siempre es prudente realizar una copia de seguridad de toda la información antes de realizar cualquier trabajo de este tipo.

En particular, es necesario ser cuidadoso al usar dd: un error simple de tipeo o una opción usada erróneamente podría destruir la información completa del disco, ¡en cualquier caso lo mejor es hacer respaldos!

Hay una serie de utilidades que pueden ser usadas para modificar las tablas de partición:

• fdisk Es un editor de tabla de particiones que tiene un menú. Es el más estándar y uno de los editores más flexibles. Esta es la única herramienta de este tipo que discutiremos.
• sfdisk es un programa de edición de particiones no interactivo, el cual es útil para hacer scripts. ¡Use esta herramienta con mucho cuidado!
• parted es el programa de manipulación de particiones del proyecto GNU. Puede crear, eliminar, redimensionar y mover particiones (incluyendo ciertos sistemas de archivos).
• gparted es una interfaz gráfica de parted, la cual es utilizada ampliamente.

Muchas distribuciones Linux tienen una versión Live CD que se puede ejecutar ya sea desde un CDROM o un dispositivo USB. Esos medios suelen incluir una copia de gparted, por lo cual puede ser usado fácilmente como una herramienta gráfica de particionamiento en discos que no están siendo utilizados.

Note que gparted puede realizar muchas operaciones más que sólo agregar y eliminar particiones (y las demás operaciones que realiza fdisk), como asignar el tipo de partición. Es posible mover, redimensionar y formatear particiones, lo cual implica entender los detalles de diversos tipos de sistemas de archivos. Lo anterior va mucho más lejos de las funciones esenciales de un editor de particiones.

Si bien es cierto que esto es muy útil, es difícil hacerlo bien y los errores pueden tener consecuencias serias. Por lo anterior, se recomienda ir a la línea de comandos y realizar cada una de estas operaciones por separado, con herramientas de bajo nivel (como fdisk). De hecho Red Hat Enterprise Linux ya no soporta gparted.

fdisk estará incluido siempre en toda instalación de Linux, por lo cual es buena idea aprender a usarlo. Usted debe ser root para ejecutar fdisk. Puede ser algo complejo de usar y se recomienda hacerlo con precaución.

La interfaz de fdisk es simple y posee un menú de texto. Se inicia en un disco en particular de la siguiente forma:

$ sudo fdisk /dev/sdb

los principales comandos (de una letra) son:

• m: Despliega el menú.
• p: Lista la tabla de particiones.
• n: Crea una partición nueva.
• d: Elimina una partición.
• t: Cambia el tipo de partición.
• w: Escribe la información nueva de la tabla de particiones y sale.
• q: Sale sin realizar cambios.

Afortunadamente no se realizan cambios hasta que la tabla de particiones es escrita en el disco, presionando w. Por lo tanto, es importante revisar que la tabla de partitiones es correcta (con la tecla p), antes de escribir a disco con w. Si algo está mal, usted puede salir de forma segura con la tecla q (a menos que ya haya guardado los cambios).

El sistema no utilizará la nueva tabla de partición hasta el próximo reinicio. Sin embargo, es posible usar el siguiente comando:

$ sudo partprobe -s

para tratar de leer la tabla de partición modificada. Sin embargo, esto no siempre funciona de manera confiable y lo mejor es reiniciar antes de formatear particiones nuevas y realizar otras operaciones, ya que mezclar particiones o sobreponer una en otra puede ser catastrófico.

En cualquier momento es posible ejecutar el siguiente comando:

$ cat /proc/partitions

con el fin de visualizar qué particiones reconoce el sistema operativo.

Al agregar un disco interno nuevo a un servidor existente, ¿cuál sería el mejor orden lógico para ejecutar los siguientes pasos con el fin de montar el disco de forma persistente (luego de reiniciar el sistema)?

Crear una partición nueva.

Formatearla con un sistema de archivos.

Editar /etc/fstab.

Reiniciar el sistema.

Los nombres tradicionales para dispositivos de almacenamiento tales como /dev/sda no son confiables para la identificación de un disco, ya que al cambiar el puerto en el cual está conectado el disco, o al conectar el disco a otro servidor puede resultar en un nombre diferente.

Linux permite el uso de etiquetas y UUIDs para asignar nombres a los dispositivos de almacenamiento. ¿Cómo se llama la herramienta que despliega los UUIDs de los dispositivos de bloque que están conectados actualmente al sistema?

• Laboratorio 9.1
• Laboratorio 9.2
• Laboratorio 9.3
• Laboratorio 9.4

Usted debería ser capaz de:

• Describir y contrastar los tipos más comunes de discos duros y buses de datos.
• Explicar cómo es la geometría de un disco y otros conceptos de particionamiento.
• Comprender cómo se les asigna el nombre a los dispositivos de disco y cómo identificar los nodos de dispositivo asociados.
• Distinguir y seleccionar entre diferentes estrategias de particionamiento.
• Use utilities such as blkid and fdisk.
• Respaldar y restaurar tablas de partición.

Los sistemas de archivos pueden ser cifrados para proteger la información de accesos no autorizados y de intentos de corromper los datos que contienen. El cifrado puede ser elegida en la instalación o ser incorporada más tarde. Las distribuciones de Linux usan a menudo el método LUKS y llevan a cabo tareas de cifrado usando la herramienta cryptsetup.

Al final del capítulo usted debería ser capaz de:

• Proveer buenas razones para el uso de cifrado y saber cuándo se requiere.
• Ententer cómo opera LUKS a través del uso de cryptsetup.
• Ser capaz de configurar y usar particiones y sistemas de archivos cifrados.
• Saber cómo configurar el sistema para montar particiones cifradas en el arranque.

El cifrado de datos debería ser usado en cualquier lugar en donde hay información sensible que está siendo almacenada y transmitida. La configuración y el uso de cifrado a nivel de dispositivo de bloque es una de las protecciones más robustas contra los daños producidos por pérdida o compromiso de información contenida en discos duros y otros medios.

Las distribuciones de Linux modernas ofrecen la alternativa de cifrar todas o algunas de las particiones durante la instalación. También es fácil crear y formatear particiones cifradas posteriormente, pero no es posible cifrar una partición existente sin tener que copiar los datos a ella.

Las distributiones de Linux modernas proveen un cifrado a nivel de dispositivo de bloque principalmente a través de LUKS (Linux Unified Key Setup). Usar este tipo de cifrado es altamente recomendable para sistemas portátiles como laptops, tabletas y teléfonos inteligentes.

LUKS está basado en cryptsetup, una herramienta potente que también puede usar otros métodos como volúmenes dm-crypt (planos), loop-AES y formato compatible con TrueCrypt. No vamos a discutir esas alternativas, ya que LUKS es el método estándar y usado más a menudo en Linux (fue diseñado originalmente para Linux, pero también ha sido exportado a otros sistemas operativos).

El módulo del kernel dm-crypt usa la infraestructura de device mapper del kernel, la cual es usada también de forma importante en LVM, lo cual veremos más adelante.

Debido a que LUKS almacena toda la información necesaria en la cabecera de la partición, es simple migrar particiones a otros discos o sistemas.

LUKS también puede ser usado para cifrar particiones de intercambio de forma transparente.

Básicamente, todo se realiza con el programa cryptsetup. Una vez que los volúmenes han sido cifrados, pueden ser montados y desmontados con las utilidades normales.

La sintaxis común de un comando es la siguiente:

cryptsetup [OPTION...] <action> <action-specific>

y una lista con todas las opciones puede ser generada con:

$ cryptsetup --help

Asumiendo que la partición LVM /dev/VG/MYSECRET ya existe, los siguientes comandos configurarán el cifrado, la pondrán a disposición de LUKS, le darán formato, la usarán y desmontarán.

Lo primero que se debe realizar es darle formato LUKS a la partición:

$ sudo cryptsetup luksFormat /dev/VG/MYSECRET

Se le pedirá ingresar una contraseña, la cual tendrá que usar para abrir el volumen cifrado más tarde. Note que tendrá que hacer esto una vez solamente, durante la configuración del cifrado.

Usted podría enfrentar ciertas dificultades si el kernel del sistema no soporta el método de cifrado que usa cryptsetup por defecto. En ese caso usted puede examinar /proc/crypto para ver los métodos que soporta el sistema, y luego especificar uno, como se muestra a continuación:

$ sudo cryptsetup luksFormat --cipher aes /dev/VG/MYSECRET

Usted puede abrir el volumen en cualquier momento, con el siguiente comando:

$ sudo cryptsetup --verbose luksOpen /dev/VG/MYSECRET SECRET

tras lo cual se le pedirá ingresar la contraseña. Luego de eso es posible formatear el sistema de archivos:

$ sudo mkfs.ext4 /dev/mapper/SECRET

Y montarlo:

$ sudo mount /dev/mapper/SECRET /mnt

A partir de este momento usted dispone de una partición sin cifrar montada en /mnt, con la cual puede trabajar a su gusto. Cuando haya terminado de realizar las tareas en cuestión, la puede desmontar de la siguiente forma:

$ sudo umount /mnt

luego remueva la asociación mapper por el momento (siempre podrá usar la partición nuevamente):

$ sudo cryptsetup --verbose luksClose SECRET

Para montar una partición cifrada en el arranque hay que satisfacer dos condiciones:

1. Agregar una línea apropiada en /etc/fstab. No hay nada de especial en esta línea y no se refiere al cifrado en ningún sentido.
2. Agregar una entrada a /etc/crypttab. Puede ser tan simple como esto:
   SECRET /dev/mapper/MYSECRET
   Usted puede hacer otras cosas en este archivo, como especificar la contraseña si no desea ingresarla en el arranque (lo cual sería contraproducente para la seguridad del sistema). Haga man crypttab para ver todo lo que puede hacer con este archivo.

Gracias a LUKS, crear particiones cifradas en distribuciones Linux modernas es muy fácil. Organice los siguientes pasos para preparar y montar una partición cifrada en el mejor orden lógico:

Crear una partición para el dispositivo de bloque cifrado.

Darle formato con cryptsetup.

Crear la contraseña para descifrar el dispositivo.

Darle formato con un sistema de archivos estándar, como ext4.

Montar el sistema de archivos en el dispositivo de bloque.

• Laboratorio 10.1
• Laboratorio 10.2

Usted debería ser capaz de:

• Proveer buenas razones para el uso de cifrado y saber cuándo se requiere.
• Ententer cómo opera LUKS a través del uso de cryptsetup.
• Ser capaz de configurar y usar particiones y sistemas de archivos cifrados.
• Saber cómo configurar el sistema para montar particiones cifradas en el arranque.

Los sistemas Linux son capaces de usar una amplia variedad de sistemas de archivos. Esta versatilidad se consigue a través de la capa de abstracción del Sistema de Archivos Virtual (VFS), la cual se sitúa entre el software y el sistema de archivos en el disco. Los sistemas de archivos transaccionales avanzados se han convertido en el estándar en las distribuciones empresariales.

Al final del capítulo usted debería ser capaz de:

• Explicar la organización básica de un sistema de archivos.
• Comprender el rol del VFS.
• Conocer qué sistemas de archivos están disponibles en Linux y cuáles son los que pueden ser usados en su sistema actual.
• Comprender porqué los sistemas de archivos con journaling representan avances importantes.
• Discutir el uso de sistemas de archivos especiales en Linux.

Los programas necesitan leer y escribir archivos, en vez de tener que lidiar con los lugares físicos en el hardware en el cual los archivos están almacenados.

Los archivos y sus nombres son una abstracción de la capa física de E/S. Escribir en el disco de forma directa (ignorando la capa del sistema de archivos) es muy peligroso y se realiza sólo por programas de bajo nivel del sistema operativo, nunca por una aplicación de usuario.

Los sistemas de archivos locales generalmente residen en una partición de disco, la cual puede ser una partición física en un disco o una partición lógica controlada por un Logical Volume Manager (LVM). Los sistemas de archivos también pueden estar en la red, de tal forma que el encapsulado físico queda totalmente oculto al sistema local.

Todos los sistemas Linux usan una jerarquía de árbol invertido del directorio raíz (/). Mientras que todo el árbol puede estar contenido en un sistema de archivos local en una partición, usualmente hay varias particiones (o sistemas de archivos de red) trabajando de forma unida en los puntos de montaje. Estos también pueden incluir medios extraíbles como dispositivos USB, discos ópticos, etc.

Adicionalmente, algunos sistemas de archivos seudovirtuales (abstracciones útiles que existen en memoria solamente) serán montadas en el árbol; estos incluyen /proc, /sys, /dev y tal vez /tmp, como también /run.

Cada uno de los elementos montados en el árbol puede tener su propio tipo de sistema de archivos. Pero ante las aplicaciones y el sistema operativo se muestra como una una sola estructura de árbol unificado.

Linux implementa un Virtual File Sistem (VFS), sistema de archivos virtual, como lo hacen todos los sistemas operativos modernos. Cuando una aplicación necesita acceder a un archivo, ésta interactúa con la capa de abstracción del VFS, el cual traduce todas las llamadas E/S (operaciones de lectura/escritura, etc) en código específico relacionado con el sistema de archivos real en particular.

De esta forma, tanto el sistema de archivos real como el medio físico y hardware sobre el cual reside, no necesitan ser considerados por las aplicaciones. Por otro lado, los sistemas de archivos de red (como NFS) pueden ser manejados de forma transparente.

Esto permite a Linux trabajar con una variedad de sistemas de archivos mayor que cualquier otro sistema operativo. Este atributo ha sido un factor importante en su éxito.

La mayoría de los sistemas de archivos tienen acceso de lectura y escritura completo, mientras que otros sólo tienen acceso a lectura y tal vez de escritura de tipo experimental. Algunos tipos de sistemas de archivos - especialmente aquellos que no están basados en UNIX - pueden requerir mayor manipulación para ser representados en el VFS.

Variantes como vfat no diferencias permisos de lectura/escritura/ejecución para los campos dueño/grupo/todos; el VFS tiene que suponer cómo especificar diferentes permisos para los tres tipos de usuarios, y tal asunto puede tener influencia en las operaciones de montaje. Existen implementaciones que no basan su soporte en el sistema de archivos del kernel, como el de lectura/escritura ntfs-3g (http://www.tuxera.com/community/ntfs-3g-download), el cual si bien es cierto es confiable, tiene un rendimiento menor que aquellos sistemas de archivos con soporte en el kernel.

Una serie de nuevos sistemas de archivos de alto rendimiento incluyen la capacidad de journaling completo.

Los sistemas de archivos con journaling se recuperan muy rápidamente de crashes/congeladas o caídas con poco o nada de corrupción. Si bien esto tiene el costo de tener que realizar más operaciones, las mejoras adicionales pueden compensar el costo con creces.

En un sistema de archivos con journaling las operaciones se agrupan en transacciones. Una transacción debe ser llevada a cabo sin errores, de forma completa, ya que de otra manera el sistema de archivos no es modificado. Se mantiene un archivo de registro para las transacciones. Cuando ocurre un error, por lo general sólo la última transacción necesita ser examinada.

Los siguientes sistemas de archivos con journaling están disponibles de forma libre en Linux:

• ext3 fue una extensión del sistema de archivos anterior ext2, el cual no tenía journaling.
• ext4 es un avance significativo derivado de ext3. Las características incluyen extents, bloques de 48 bits y de hasta 16 TB de tamaño. La mayoría de las distribuciones de Linux han usado ext4 como el sistema de archivos por defecto por varios años a la fecha.
• reiserfs fue la primera implementación de journaling usada en Linux, pero perdió su liderazgo y su desarrollo fue abandonado.
• JFS fue originalmente un producto de IBM y fue portado desde el sistema operativo AIX.
• XFS originalmente fue un producto de SGI y se portó desde el sistema operativo IRIX. RHEL 7 adoptó a XFS como su sistema de archivos por defecto.
• btrfs es el sistema de archivos con journaling más nuevo y todavía está bajo un desarrollo fuerte y rápido.

Usted puede ver una lista de los tipos de sistemas de archivos soportados por el kernel Linux en ejecución con el siguiente comando:

$ cat /proc/filesystems

nodev sysfs
nodev rootfs
nodev ramfs
nodev bdev
nodev proc
nodev cgroup
nodev cpuset
nodev tmpfs
nodev devtmpfs
nodev binfmt_misc
nodev debugfs
nodev sockfs
nodev pipefs
nodev devpts
               squashfs
nodev hugetlbfs
               iso9660
nodev mqueue
               ext3
               ext2
               ext4
               fuseblk
nodev fuse
nodev fusectl
nodev autofs
nodev rpc_pipefs
nodev nfsd

Note que para algunos tipos de sistemas de archivos adicionales, el código de soporte puede ser cargado sólo cuando el sistema trata de acceder a la partición que los contiene.

Linux hace un uso amplio de sistemas de archivos especiales para ciertas tareas. Estos son particularmente útiles para acceder varias estructuras de datos y ajustes de rendimiento del kernel, o para implementar funciones específicas.

Note que algunos de esos sistemas de archivos especiales no tienen punto de montaje; esto significa que las aplicaciones de usuario no interactúan con ellos, pero el kernel lo hace, tomando ventaja de las capas y el código del VFS.

El archivo especial _______________________ contiene una lista de todos los sistemas de archivos soportados por el sistema operativo.

¿Cuáles son las ventajas de tmpfs sobre un disco RAM? Seleccione todas las respuestas que apliquen:

No es necesario formatearlas antes de usar.

Utiliza la memoria de una forma eficiente.

El tamaño máximo del sistema de archivos es 4GB.

Puede usar tanto RAM como área de intercambio.

• Laboratorio 11.1

Actualmente usted debería ser capaz de:

• Explicar la organización básica de un sistema de archivos.
• Comprender el rol del VFS.
• Conocer qué sistemas de archivos están disponibles en Linux y cuáles son los que pueden ser usados en su sistema actual.
• Comprender porqué los sistemas de archivos con journaling representan avances importantes.
• Discutir el uso de sistemas de archivos especiales en Linux.

Las características importantes de los sistemas de archivos incluyen inodos, archivos de directorio y tanto enlaces simbólicos (soft) como duros (hard). Los atributos extendidos amplían los permisos de archivos tradicionales de UNIX. Existen utilidades específicas asociadas a los sistems de archivos que realizan tareas como crearlos y darles formato, comprobar si hay errores y repararlos. También montar y desmontar los sistemas de archivos durante el arranque o en un momento posterior.

Al final del capítulo usted debería ser capaz de:

• Estar familiarizado con conceptos tales como inodos, archivos de directorios y atributos extendidos.
• Crear y formatear sistemas de archivos.
• Verificar y reparar errores en sistemas de archivos.
• Montar y desmontar sistemas de archivos.

Un inodo es una estructura de datos en el disco que describe y almacena los atributos del archivo, incluyendo su localización. Cada archivo está asociado con su propio inodo. La información almacenada en el inodo incluye lo siguiente:

• Permisos
• Usuario y grupo propietario
• Tamaño
• Registros de tiempo (al nanosegundo)
  - Momento en el cual se realizó el último acceso
  - Momento en el cual se realizó la última modificación del contenido
  - Momento en el cual se realizó la última modificación del inodo.

Nota: los nombres de los archivos no se almacenan en el inodo asociado al archivo, sino que lo hacen en el archivo de directorio.

Toda la actividad E/S concerniente a un archivo usualmente involucra el inodo del archivo como información que debe ser actualizada.

Un archivo de directorio es un tipo de archivo en particular, el cual es usado para asociar nombres de archivo a inodos. Hay dos formar de asociar (o enlazar) un nombre de archivo con un inodo:

• Con enlaces duros, que apuntan a un inodo.
• Con enlaces simbólicos, los cuales apuntan a un nombre de archivo el cual tiene un inodo asociado.

Cada asociación de un contenido de los archivos de directorio y un inodo es conocido como un enlace. Enlaces adicionales pueden ser creados usando el comando ln.

Debido a que es posible (y muy común) que dos o más entradas de directorio apunten al mismo inodo (enlaces duros), un archivo puede ser conocido por múltiples nombres, en los que cada uno de ellos tiene su propio lugar en la estructura de directorios. Sin embargo, puede tener un inodo solamente, sin importar qué nombre está siendo usado.

Cuando un proceso se refiere a un nombre de ruta, el kernel busca directorios para encontrar el número de inodo correspondiente. Luego de que el nombre ha sido convertido a un número de inodo, el inodo se carga en memoria y es usado en solicitudes posteriores.

Los atributos extendidos asociados a los metadatos no son interpretados directamente por el sistema de archivos. Existen cuatro espacios de nombres (namespaces): usuario, de confianza, seguridad y sistema. Más adelante veremos que el espacio de nombres sistema es usado por las listas de control de acceso (ACLs) y el espacio de nombres seguridad es usado por SELinux.

Los valores de los atributos son almacenados en el inodo de archivo y pueden ser modificados y configurados sólo por el usuario root. Se visualizan con lsattr y configuran con chattr.

Note que hay otros atributos que se pueden configurar: al ejecutar man chattr se mostrará la lista completa. El formato para chattr es el siguiente:

$ chattr [+|-|=mode] filename

lsattr se usa para desplegar los atributos de un archivo:

$ lsattr filename

Cada tipo de sistema de archivos tiene una herramienta para formatear un sistema de archivos en una partición. El nombre genérico para esas utilidades es mkfs. Sin embargo es sólo una interfaz para los programas del sistema de archivos específico:

$ ls -lh /sbin/mkfs*

-rwxr-xr-x 1 root root  11K Apr 10 03:50 /sbin/mkfs
-rwxr-xr-x 1 root root 181K Oct 15  2012 /sbin/mkfs.btrfs
-rwxr-xr-x 1 root root  26K Apr 10 03:50 /sbin/mkfs.cramfs
-rwxr-xr-x 5 root root  68K Jul 16 15:31 /sbin/mkfs.ext2
-rwxr-xr-x 5 root root  68K Jul 16 15:31 /sbin/mkfs.ext3
-rwxr-xr-x 5 root root  68K Jul 16 15:31 /sbin/mkfs.ext4
-rwxr-xr-x 5 root root  68K Jul 16 15:31 /sbin/mkfs.ext4dev
lrwxrwxrwx 1 root root    7 Dec  6  2011 /sbin/mkfs.msdos -> mkdosfs
lrwxrwxrwx 1 root root   12 Sep 28  2011 /sbin/mkfs.ntfs -> /sbin/mkntfs
lrwxrwxrwx 1 root root    7 Dec  6  2011 /sbin/mkfs.vfat -> mkdosfs

Por tanto, los dos comandos de a continuación son completamente equivalentes:

$ sudo mkfs -t ext4 /dev/sda10
$ sudo mkfs.ext4 /dev/sda10

El formato general para mkfs es el siguiente:

mkfs [-t fstype] [options] [device-file]

donde [device-file] es generalmente un nombre de dispositivo como /dev/sda3 o /dev/vg/lvm1.

Cada tipo de sistema de archivos tiene sus propias opciones que pueden ser configuradas en el proceso de formateo. Por ejemplo, cuando se crea un sistema de archivos ext4, un asunto para considerar es la configuración del journaling. Estos incluyen el tamaño de archivo del journal y si se utilizará o no un archivo de journal externo.

Es necesario revisar la página man de cada uno de los programas mkfs.* para ver los detalles.

Cada tipo de sistema de archivos tiene una utilidad diseñada para verificar errores (y en lo posible repararlos, en caso que se encuentren). El nombre genérico para esas herramientas es fsck. Sin embargo esto es sólo una interfaz para los programas específicos de cada sistema de archivos:

$ ls -l /sbin/fsck*

-rwxr-xr-x 1 root root  34680  Apr 10 03:50 /sbin/fsck
-rwxr-xr-x 1 root root  15976  Apr 10 03:50 /sbin/fsck.cramfs
-rwxr-xr-x 5 root root 197352  Jul 16 15:31 /sbin/fsck.ext2
-rwxr-xr-x 5 root root 197352  Jul 16 15:31 /sbin/fsck.ext3
-rwxr-xr-x 5 root root 197352  Jul 16 15:31 /sbin/fsck.ext4
-rwxr-xr-x 5 root root 197352  Jul 16 15:31 /sbin/fsck.ext4dev
lrwxrwxrwx 1 root root      7  Dec  6  2011 /sbin/fsck.msdos -> dosfsck
lrwxrwxrwx 1 root root     13  Sep 28  2011 /sbin/fsck.ntfs -> ../bin/ntfsck
lrwxrwxrwx 1 root root      7  Dec  6  2011 /sbin/fsck.vfat -> dosfsck

Por tanto, los dos comandos de a continuación son completamente equivalentes:

$ sudo fsck -t ext4 /dev/sda10
$ sudo fsck.ext4 /dev/sda10

fsck se ejecuta automáticamente luego de un número de montajes o un intervalo desde la última vez que fue ejecutado, o luego de un apagado anormal. Debería ser ejecutado en sistemas de archivos sin montar.

Usted puede forzar una verificación de todos los sistemas montados en el próximo arranque con los siguientes comandos:

$ sudo touch /forcefsck
$ sudo reboot

El archivo /forcefsck desaparecerá luego de que la verificación sea exitosa. Esta forma de verificación es muy útil, ya que permite ejecutar fsck en el sistema de archivos root, lo cual es muy difícil de realizar en un sistema que está corriendo.

El formato general de fsck es el siguiente:

fsck [-t fstype] [options] [device-file]

donde [device-file] es generalmente un nombre de dispositivo como /dev/sda3 o /dev/vg/lvm1. Usualmente no es necesario especificar el tipo de sistema de archivo, ya que fsck puede detectarlo a través de examinar los superbloques al comienzo de la partición.

Es posible controlar si los errores encontrados deben repararse uno a uno manualmente con la opción -r, o automáticamente de la mejor forma posible usando la opción -a. Adicionalmente, cada tipo de sistema de archivo puede tener sus propias opciones particulares que pueden ser configuradas al momento de la verificación.

Note que los sistemas de archivos con journaling son mucho más rápidos para verificar que los sistemas de archivos de generaciones anteriores por dos razones:

• Raramente es necesario escanear la partición completa para buscar errores, ya que todo - con excepción de la última transacción - ha sido registrado y confirmado, por lo cual se requiere muy poco tiempo para verificar.
• Incluso si uno verifica el estado del sistema de archivos completo, los sistemas de archivos nuevos han sido diseñados con fsck rápido; de hecho los sistemas de archivos antiguos no consideraron este tema cuando fueron diseñados, debido a que los tamaños eran mucho más pequeños.

Para ver los detalles de los programas fsck.* vea la página man de cada uno.

Todos los archivos accesibles en Linux están organizados en una gran estructura de árbol jerárquica con la parte superior del mismo en el directorio root ( / ). Sin embargo, es común tener más de una partición (cada una de las cuales puede tener su propio tipo de sistema de archivos), las que trabajan juntas en el mismo árbol de sistema de archivos. Estas particiones pueden estar en diferentes dispositivos físicos, o incluso localizadas en una red.

El programa mount permite montar un sistema de archivos en cualquier punto de la estructura de árbol; por el contrario, umount permite desmontarlo.

El punto de montaje corresponde al directorio donde el sistema de archivos está montado. Este debe existir con anterioridad a que mount pueda usarlo; el comando mkdir puede ser usado para crear un directorio vacío. Si un directorio preexistente es usado para tal efecto y contiene archivos previamente al ser usado como punto de montaje, los archivos se ocultarán al momento del montaje. Estos archivos no son borrados y estarán visibles nuevamente cuando el sistema de archivos es desmontado.

Sólo el superusuario puede montar y desmontar sistemas de archivos.

Cada sistema de archivos es montado bajo un directorio específico, como en el caso que se muestra a continuación:

$ sudo mount -t ext4 /dev/sdb4 /home

• Monta un sistema de archivos ext4.
• El sistema de archivos está localizado en una partición específica del disco duro (/dev/sdb4).
• El sistema de archivos está montado en la posición /home en el árbol de directorios actual.
• Cualquier archivo que esté en el directorio original /home estará oculto hasta que la partición se desmonte.

Note que en este ejemplo el sistema de archivos es montado utilizando el nodo de dispositivo sobre el que reside. Sin embargo, también es posible montarlo usando una etiqueta o un UUID. Por lo tanto, los siguientes comandos son todos equivalentes:

$ sudo mount /dev/sda2 /home
$ sudo mount LABEL=home /home
$ sudo mount -L home /home
$ sudo mount UUID=26d58ee2-9d20-4dc7-b6ab-aa87c3cfb69a /home
$ sudo mount -U 26d58ee2-9d20-4dc7-b6ab-aa87c3cfb69a /home

Las etiquetas son asignadas por utilidades específicas de cada tipo de sistema de archivos, tal como e2label. Los UUIDs se asignan cuando las particiones son creadas como contenedores para el sistema de archivos.

Mientras cualquiera de estos tres métodos para especificar el dispositivo puede ser usado, los sistemas modernos desestiman el uso del nodo de dispositivo debido a que los nombres pueden cambiar de acuerdo a cómo el sistema arranca, qué discos duros son encontrados primero, etc. Las etiquetas son una mejora, pero en raras ocasiones se podría tener dos particiones que se muestran con la misma etiqueta. Los UUIDs, sin embargo, siempre deberían ser únicos y son creados cuando las particiones se crean.

mount tiene muchas opciones, algunas genéricas como -a (lo cual monta todos los sistemas de archivos mencionados en /etc/fstab) y muchas que son específicas al sistema de archivos; de hecho, mount tiene una página man muy larga. Un ejemplo común sería el siguiente:

$ sudo mount -o remount,ro /myfs

lo cual montaría nuevamente un sistema de archivos con un atributo de sólo lectura.

Los sistemas de archivos pueden ser desmontados de la siguiente forma:

$ umount [device-file | mount-point]

Tal como mount, umount tiene muchas opciones, muchas de las cuales son específicas al tipo de sistema de archivos. Nuevamente, las páginas man son la mejor fuente para obtener las opciones específicas.

El error más común que se encuentra al desmontar un sistema de archivos es tratar de hacerlo en un sistema de archivos que está en uso actualmente; es decir, hay aplicaciones usando archivos u otras entradas en el sistema de archivos.

Esto puede ser tan simple como tener una terminal abierta en un directorio en el sistema de archivos montado. Tan solo haciendo cd en esa ventana o cerrándola, solucionará el error del dispositivo que está en uso y se permitirá desmontardo.

Sin embargo, si hay otros procesos induciendo ese error, deberá cerrarlos antes de poder desmontar el sistema de archivos. Usted puede usar fuser para encontrar qué usuarios están usando el sistema de archivos y detener sus procesos (sea cuidadoso con esto, tal vez sea buena idea informar a los usuarios antes de hacerlo). También se puede usar lsof ("lista de archivos abiertos") para ver qué archivos están siendo utilizados y que están bloqueando el desmontado.

Durante el arranque del sistema se ejecuta el comando mount -a. Esto monta todos los sistemas de archivos listados en el archivo de configuración /etc/fstab. Las entradas pueden referirse a sistemas de archivos locales o remotos, montados a través de la red.

Las herramientas mount y umount pueden usar la información que se encuentra en /etc/fstab; en este caso podríamos hacer lo siguiente (usando la información del ejemplo anterior)

$ sudo mount /usr/src

en vez de

$ sudo mount LABEL=src /usr/src

La lista de sistemas de archivos montados actualmente puede ser vista ejecutando el siguiente comando:

$ mount

/dev/sda5 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda6 on /RHEL6-32 type ext4 (rw)
/dev/sda2 on /boot_master type ext4 (rw)
/dev/mapper/VG-tmp on /tmp type ext4 (rw)
/dev/mapper/VG-local on /usr/local type ext4 (rw)
/dev/mapper/VG-src on /usr/src type ext4 (rw)
/dev/mapper/VG-audio on /AUDIO type ext4 (rw)
/dev/mapper/VG-pictures on /PICTURES type ext4 (rw)
/dev/mapper/VG-dead on /DEAD type ext4 (rw)
/dev/mapper/VG-virtual on /VIRTUAL type ext4 (rw)
/dev/mapper/VG-virtual2 on /VIRTUAL2 type ext4 (rw)
/dev/mapper/VG-virtual3 on /VIRTUAL3 type ext4 (rw)
/dev/mapper/VG-iso_images on /ISO_IMAGES type ext4 (rw)
/usr/local/FTP on /var/ftp/pub type none (rw,bind)
/usr/src/KERNELS.sqfs on /usr/src/KERNELS type squashfs (rw,loop=/dev/loop0)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
vmware-vmblock on /var/run/vmblock-fuse type fuse.vmware-vmblock (rw, nosuid, nodev, default_permissions, allow_other)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

¿Qué información no se almacena en el inodo?

Permisos

Usuario y grupo propietario

Nombre de archivo

Marcas de tiempo

Tamaño

Identifique las herramientas que se describen a continuación:

• es la herramienta general para formatear sistemas de archivos.
• es la herramienta general para verificar y reparar sistemas de archivos.
• es una herramienta para listar los atributos extendidos de un archivo.
• es una herramienta para cambiar los atributos extendidos de un archivo.
• es una herramienta para listar los archivos en uso.

• Laboratorio 12.1
• Laboratorio 12.2

Actualmente usted debería ser capaz de:

• Estar familiarizado con conceptos tales como inodos, archivos de directorios y atributos extendidos.
• Crear y formatear sistemas de archivos.
• Verificar y reparar errores en sistemas de archivos.
• Montar y desmontar sistemas de archivos.

Linux usa una implementación de espacio de intercambio robusto, a través de la cual el sistema de memoria virtual permite el uso aparente de más memoria que la disponible en forma física. Las cuotas del sistema de archivos pueden ser usadas para administrar el uso del espacio en disco de las cuentas de usuario. Las herramientas df y du son útiles para monitorear de forma simple el uso y capacidad del sistema de archivos.

Al final de este capítulo usted debería ser capaz de:

• Explicar los conceptos de área de intercambio y cuotas.
• Usar las herramientas que ayudan a administrar las cuotas: quotacheck, quotaon, quotaoff, edquota y quota.
• Usar las herramientas df y du.

Linux emplea un sistema de memoria virtual en el cual el sistema operativo funciona como si tuviera más memoria de la que realmente tiene. Este tipo de memoria funciona de dos maneras:

• Muchos programas no usan toda la memoria que tienen permitido usar. A veces esto se debe a que los procesos hijos heredan una copia de las regiones de memoria de los padres, que utilizan la técnica COW (Copy On Write), en la cual el hijo obtiene solamente una copia única (de a una página) cuando hay un cambio.
• Cuando la presión de memoria se vuelve importante, regiones de memoria menos activa pueden ser escritas al área de intercambio, para ser llamadas sólo cuando se requieren nuevamente.

Tal movimiento en el área de intercambio sea realiza usualmente a una o más particiones o archivos; Linux permite múltiples áreas de intercambio, por lo cual las necesidades pueden ser ajustadas dinámicamente. Cada área tiene una prioridad asociada; las de prioridad baja no son utilizadas hasta que otras de prioridad mayor están llenas.

En la mayoría de los casos el tamaño recomendado de intercambio es el total de RAM en el sistema. Es posible ver lo que el sistema está usando actualmente en las áreas de intercambio de la siguiente forma:

$ cat /proc/swaps

Filename             Type Size             Used         Priority
/dev/sda9            partition             4193776          0            -1
/dev/sdb6            partition             4642052          0            -2

y el uso actual de memoria con:

$ free -o

                  total      used     free   shared   buffers   cached
Mem:      4047236   3195080    852156        0    818480  1430940
Swap:     8835828         0   8835828

Los únicos comandos que implican el área de intercambio son los siguientes:

• mkswap: formatea una partición o archivo de intercambio
• swapon: activa una partición o archivo de intercambio
• swapoff: desactiva una partición o archivo de intercambio

En algún momento la mayoría de la memoria está en uso para almacenar en caché contenidos de archivo para prevenir ir a leer al disco más de lo necesario, o en un orden o tiempo que podría estar debajo de lo óptimo. Este tipo de página en memoria no se escribe en el área de intercambio, ya que están respaldadas en los archivos en sí, por lo cual hacerlo no tendría sentido; en cambio, las páginas que han sido modificadas y que no tienen respaldo físico - conocidas como dirty pages en inglés - son movidas al disco.

Vale la pena señalar que en Linux la memoria que usa el kernel, de forma opuesta a la memoria de aplicaciones y a diferencias de otros sistemas operativos, nunca se traslada al área de intercambio.

Linux puede usar y aplicar cuotas en sistemas de archivos. Las cuotas de disco les permite a los administradores controlar el espacio máximo que usuarios o grupos en particular tienen habilitados para su uso. Se permite una flexibilidad considerable y las cuotas pueden ser asignadas en base a cada sistema de archivos. Se provee de protección para que los usuarios no agoten los recursos colectivos.

Las siguientes herramientas permiten controlar las cuotas:

• quotacheck: genera y actualiza los archivos que llevan la cuenta de las cuotas
• quotaon: habilita el sistema de cuotas
• quotaoff: deshabilita el sistema de cuotas
• edquota: se usa para editar cuotas de usuarios o grupos
• quota: informa acerca del uso y límites de las cuotas.

Las operaciones de cuota requieren la existencia de los archivos aquota.user y aquota.group en el directorio raíz del sistema de archivos que está usando cuotas.

Las cuotas pueden estar habilitadas o deshabilitadas en función de cada sistema de archivos. Adicionalmente, Linux soporta el uso de cuotas basadas en el id de usuario y grupo.

Los diferentes sistemas de archivos pueden tener utilidades adicionales relacionadas a las cuotas, tales como xfs_quota.

Para crear una cuota de sistema de archivos hay que asegurarse de haber montado el sistema de archivos con las opciones de cuotas de usuario y/o grupo. Sin eso nada funcionará. Los pasos básicos son los siguientes:

• Montar el sistema de archivos con las opciones de cuota de usuario y/o grupo:
  - Agregar las opciones usrquota y/o grpquota a la entrada del sistema de archivos en /etc/fstab
  - Remontar el sistema de archivos (o montarlo si es nuevo).
• Ejecutar quotacheck en el sistema de archivos para configurar las cuotas.
• Habilitar las cuotas en el sistema de archivos.
• Configurar las cuotas con el programa edquota.

Por lo tanto, para crear una cuota de sistema de archivos primero hay que asegurarse de haber montado el sistema de archivos con las opciones de cuota para usuarios y/o grupos. Recuerde que sin ellos no va a funcionar.

Primero es necesario agregar las opciones correctas en el archivo /etc/fstab, como se muestra a continuación:

/dev/sda5 /home ext4 defaults,usrquota 1 1

donde hemos asumido que /home está en una partición dedicada.

Luego realice un test con los siguientes comandos:

$ sudo mount -o remount /home
$ sudo quotacheck -vu /home
$ sudo quotaon -vu /home
$ sudo edquota someusername

Usted también podría querer configurar períodos de gracia con edquota. Las opciones de montaje que deberían ser usadas en el archivo /etc/fstab son usrquota para cuotas de usuario y grpquota para cuotas de grupo.

La herramienta quotacheck crea y actualiza los archivos que llevan la cuenta de las cuotas (aquota.user y aquota.group) en el sistema de archivos.

Para actualizar los archivos de usuarios para todos los sistemas de archivos en /etc/fstab con opciones de cuota de usuario, haga lo siguiente:

$ sudo quotacheck -ua

Para actualizar los archivos de grupo para todos los sistemas de archivos en /etc/fstab con opciones de cuota de grupo, haga lo siguiente:

$ sudo quotacheck -ga

Para actualizar el archivo de usuario de un sistema de archivos en particular, haga lo siguiente:

$ sudo quotacheck -u [somefilesystem]

Para actualizar el archivo de grupo de un sistema de archivos en particular, haga lo siguiente:

$ sudo quotacheck -g [somefilesystem]

Use la opción -v para obtener una salida más detallada.

quotacheck es ejecutado generalmente sólo cuando las cuotas son habilitadas inicialmente (o cuando necesitan ser actualizadas). El programa también podría ser ejecutado cuando fsck reporta errores en el sistema de archivos durante el arranque del sistema.

quotaon se usa para habilitar las cuotas en el sistema de archivos; quotaoff se usa para deshabilitarlas. Los comandos anteriores se usan de la siguiente forma:

$ sudo quotaon [flags] [filesystem]
$ sudo quotaoff [flags] [filesystem]

en donde los parámetros (flags) pueden ser:

-a, --all turn quotas off for all filesystems
-f, --off turn quotas off
-u, --user operate on user quotas
-g, --group operate on group quotas
-p, --print-state print whether quotas are on or off
-x, --xfs-command=cmd perform XFS quota command
-F, --format=formatname operate on specific quota format
-v, --verbose print more messages
-h, --help display this help text and exit
-V, --version display version information and exit

Note que estos dos programas son realmente uno y funcionan de acuerdo al nombre con el cual son invocados.

Por ejemplo:

$ sudo quotaon -av

/dev/sda6 [/]: group quotas turned on
/dev/sda5 [/home]: user quotas turned on

$ sudo quotaoff -av

/dev/sda6 [/]: group quotas turned off
/dev/sda5 [/home]: user quotas turned off

$ sudo quotaon -avu

/dev/sda5 [/home]: user quotas turned on

$ sudo quotaoff -avu

/dev/sda5 [/home]: user quotas turned off

$ sudo quotaon -avg

/dev/sda6 [/]: group quotas turned on

$ sudo quotaoff -avg

/dev/sda6 [/]: group quotas turned off

Tenga en cuenta que las operaciones de cuota fallarán si los archivos aquota.user o aquota.group no existen.

La herramienta quota se usa para generar reportes de cuotas:

• quota (o quota -u) informa su cuota actual de usuario.
• quota -g informa su cuota actual de grupo.
• El superusuario puede ver las cuotas de cualquier usuario u grupo al especificar un nombre de usuario o grupo.

Por ejemplo:

$ sudo quota george

Disk quotas for user george (uid 1000):
   Filesystem   blocks quota limit grace files quota limit grace
      /dev/sda5 837572   500  1000        5804     0     0

$ sudo quota gracie

Disk quotas for user gracie (uid 1001):
  Filesystem     blocks quota limit grace files quota limit grace
    /dev/sda5     83757  5000 10000        5804     0     0

El comando edquota ejecuta el editor de cuotas. Para el usuario o grupo especificado se crea un archivo temporal con una representación de texto de las cuotas de disco actuales para ese usuario o grupo.

Entonces un editor es invocado con el fin de modificar las cuotas en el archivo mencionado. Una vez que el editor se cierra, el archivo temporal se lee y los archivos binarios de cuota llevan a cabo los cambios.

Los únicos campos que pueden ser editados en la cuota son los límites soft y hard. Los otros campos son informativos solamente.

Las cuotas para usuarios y grupos pueden estar configuradas para bloques de discos y/o inodos. Adicionalmente, los límites soft y hard pueden ser configurados como períodos de gracia: el límite soft puede ser excedido por un período de gracia, sin embargo, el límite hard no puede ser excedido en ningún caso.

El período de gracia se configura en función de cada sistema de archivos.

$ sudo edquota gracie
$ sudo edquota -t

La herramienta df (disk free) muestra el uso y la capacidad disponible del sistema de archivos. Por ejemplo:

$ df -hT

Filesystem           Type      Size  Used Avail Use% Mounted on
/dev/sda5            ext4      9.8G  8.1G  1.3G  87% /
tmpfs                tmpfs     3.9G  2.3M  3.9G   1% /dev/shm
/dev/sda6            ext4      9.8G  5.0G  4.3G  54% /RHEL6-32
/dev/sda2            ext4      380M  3.2M  353M   1% /boot_master
/dev/mapper/VG-local ext4       24G   16G  7.2G  68% /usr/local
/dev/mapper/VG-src   ext4       16G  6.4G  8.6G  43% /usr/src
/dev/mapper/VG-pictures
                     ext4       12G  8.9G  2.3G  80% /PICTURES
/dev/mapper/VG-dead  ext4       59G   35G   22G  62% /DEAD
/dev/mapper/VG-virtual
                     ext4      222G  162G   49G  77% /VIRTUAL
/dev/mapper/VG-iso_images
                     ext4       59G   35G   21G  63% /ISO_IMAGES
/usr/src/KERNELS.sqfs
                     squashfs  3.8G  3.8G     0 100% /usr/src/KERNELS

en donde la opción -h significa "legible para humanos", es decir en KB, MB, GB y no en bytes. La opción -T muestra el tipo de sistema de archivos. La opción -i muestra la información del inodo en vez de bytes.

du (disk usage, o uso del disco) se usa para evaluar cuánto espacio está usando un directorio (y sus subdirectorios) en un sistema de archivos.

Para desplegar el uso del disco del directorio actual: $ du

Para desplegar todos los archivos, no sólo los directorios: $ du -a

Para listar en formato "legible por humanos": $ du -h

Para desplegar el uso del disco para un directorio específico: $ du -h somedir

Para desplegar los totales solamente, suprimiendo la salida de los subdirectorios: $ du -s

Por ejemplo:

$ du -ch /teaching/CRASH

16K      /teaching/CRASH/crash-7.0.3/memory_driver
136K     /teaching/CRASH/crash-7.0.3/extensions
35M      /teaching/CRASH/crash-7.0.3
101M     /teaching/CRASH
101M     total

Provea la opción correcta para el programa df, con el fin de:

• Listar en formato "legible por humanos".
• Listar la información del inodo en vez del uso de bloques.

Organice los pasos de a continuación en el mejor orden lógico para habilitar las cuotas en un sistemas de archivos existente:

Editar /etc/fstab para agregar la opción de montaje usrquota.

Montar de nuevo el sistema de archivos.

Ejecutar quotaon para habilitar el sistema de cuotas.

Editar de forma individual las cuotas de usuario o grupo con edquota.

En esta sección se presentaron las herramientas básicas para administrar particiones de intercambio. Las preguntas de a continuación son en relación a las tres herramientas básicas para tal efecto:

se usa para formatear una partición de intercambio.

se usa para habilitar una partición de intercambio.

se usa para deshabilitar una partición de intercambio.

• Laboratorio 13.1
• Laboratorio 13.2

Actualmente usted debería ser capaz de:

• Explicar los conceptos de área de intercambio y cuotas.
• Usar las herramientas que ayudan a administrar las cuotas: quotacheck, quotaon, quotaoff, edquota y quota.
• Usar las herramientas df y du.

La familia de sistemas de archivos ext han sido nativos de Linux desde sus primeros días, y los más ampliamente usados de todas las alternativas disponibles. Hasta muy recientemente, ext4 ha sido la alternativa por defecto más frecuente de distribuciones Linux, debido a su excelente combinación de rendimiento, integridad y estabilidad.

Al final de este capítulo usted debería ser capaz de::

• Describir las características principales del sistemas de archivos ext4 y la forma en la que ocupa el disco.
• Explicar los conceptos de grupos de bloques, superbloque, bloques de datos e inodos.
• Usar las herramientas dumpe2fs y tune2fs.
• Enumerar las mejoras del sistema de archivos ext4.

El sistema de archivos ext2 fue una variedad nativa de Linux y está disponible en todos los sistemas Linux, pero rara vez se utiliza hoy en día.

El sistema de archivos ext3 fue la primera extensión de ext2 que incluyó journaling. Tenía el mismo diseño en disco que ext2, excepto por la existencia de un archivo de journal.

El sistema de archivos ext4 se incluyó por primera vez en la versión 2.6.19 del kernel, y su designación como experimental fue quitada en la versión 2.6.28. Incluyó mejoras significativas como el uso de extents para archivos largos, en vez de listas de bloques de archivos.

Un extent es simplemente un grupo de bloques continuos. Su uso puede mejorar el rendimiento de archivos de gran tamaño y reducir la fragmentación.

ext4 es el sistema de archivos por defecto en la mayoría de las distribuciones empresariales de Linux, aunque RHEL 7 adoptó recientemente XFS de forma predeterminada.

Existe una correspondencia cercana de características entre el VFS y los sistemas de archivos ext2/3/4, debido a que cada uno ha sido diseñado sobre la base del otro.

El tamaño del bloque se selecciona cuando el sistema de archivos se construye; puede ser de 512, 1024, 2048, o 4096 bytes. Por defecto, 4096 es usado con frecuencia para discos duros, a menos que la partición sea muy pequeña. A menos de que haya muchos archivos pequeños, los tamaños grandes de bloque pueden ser más eficientes en términos de minimizar accesos al disco duro.

El sistema de gestión de memoria del kernel Linux requiere que solamente un número entero de bloques quepa en una página de memoria; por lo tanto no es posible tener bloques de 8 KB en una plataforma x86 en donde las páginas de memoria son de 4KB de tamaño.

El número de inodos en el sistema de archivos también puede ser ajustado, lo cual podría ahorrar espacio en disco.

Una característica llamada reservación de inodos consiste en reservar un número considerable de inodos cuando un directorio se crea, con la idea de ser usados en el futuro. Esto mejora el rendimiento debido a que cuando se crean nuevos archivos en el directorio, éste tiene ya inodos asignados.

Si la ruta de un enlace simbólico es menor que 60 caracteres, se crea un enlace simbólico rápido, el cual se almacena directamente en el inodo, obviando la necesidad de leer un bloque de datos.

Todos los campos son escritos a disco en orden little-endian, con excepción del journal.

Los bloques de disco se dividen en grupos de bloques, cada uno de los cuales contiene inodos y bloques de dato almacenados de forma adyacente, con lo que se reduce el tiempo de acceso.

El diseño de un grupo de bloques estándar es simple. Para el grupo de bloques 0, los primeros 1024 bytes no se usan (le ceden el espacio a sectores de booteo, etc). El superbloque comenzará en el primer bloque, con excepción del grupo de bloque 0. Luego siguen los descriptores de grupo y un número de bloques GDT (Group Descriptor Table). Estos son seguidos por el mapa de bits de bloques de datos, el mapa de bits de inodos, la tabla de inodos y los bloques de datos.

Los bloques de datos son preasignados a archivos antes de que sean usados. Así cuando el tamaño de un archivo se incrementa, se hace uso de espacio adyacente que ha sido previamente reservado, por lo cual la fragmentación se reduce.

El superbloque del sistema de archivos contiene campos de bit, los cuales son usados para determinar si el sistema de archivos requiere o no verificación cuando se monta por primera vez durante la inicialización del sistema. El estado puede ser:

• clean: el sistema de archivos se desmontó de forma limpia previamente
• dirty: generalmente significa que está montado
• unknown: no se desmontó de forma limpia, como cuando hay un bloqueo o caída del sistema.

En los últimos dos casos fsck será ejecutado para verificar el sistema de archivos y resolver cualquier problema antes de que sea montado.

Otros campos en el superbloque contienen información acerca de la última verificación del sistema de archivos, tanto la fecha como el número de montajes. Una verificación automática es lanzada cuando los límites ajustables exceden esos valores.

El primer bloque en el sistema de archivos es llamado bloque de arranque y está reservado para el sector de arranque de la partición.

Después del bloque de arranque hay una serie de grupos de bloques, en donde cada uno de ellos tiene el mismo tamaño. El diseño de cada grupo de bloques se muestra en la figura siguiente:

Figura 14.1: Diseño de los sistemas de archivos ext2/3/4

El primer y segundo bloque son los mismos para cada grupo de bloques y comprenden el Superbloque y los Descriptores de Grupo. Bajo circunstancias normales, sólo los bloques que están en el primer grupo son utilizados por el kernel; las copias duplicadas son referenciadas solamente cuando el sistema de archivo está siendo verificado. Si todo está bien, el kernel los copia desde el primer grupo de bloques. Si hay algún problema con las copias maestras, va al siguiente y así sucesivamente hasta que se encuentra uno en buen estado y la estructura del sistema de archivos se reconstruye. Esta redundancia hace que sea muy difícil que un sistema de archivos ext2/3/4 se estropee, siempre y cuando las verificaciones del sistema de archivos se ejecuten de forma periódica.

En las versiones tempranas de la familia ext, cada grupo de bloques contenía los descriptores de grupos de cada uno de ellos, como también una copia del superbloque. Debido a las optimizaciones actuales, no todos los grupos de bloques tienen una copia del superbloque y de los descriptores de grupos. Para ver la situación en el sistema usted podría hacer lo siguiente:

$ sudo dumpe2fs /dev/sda1 | grep superblock

dumpe2fs 1.42.9 (28-Dec-2013)
    Primary superblock at 0, Group descriptors at 1-4
    Backup superblock at 32768, Group descriptors at 32769-32772
    Backup superblock at 98304, Group descriptors at 98305-98308
    Backup superblock at 163840, Group descriptors at 163841-163844
    Backup superblock at 229376, Group descriptors at 229377-229380
    Backup superblock at 294912, Group descriptors at 294913-294916
    Backup superblock at 819200, Group descriptors at 819201-819204
    Backup superblock at 884736, Group descriptors at 884737-884740
    Backup superblock at 1605632, Group descriptors at 1605633-1605636
    Backup superblock at 2654208, Group descriptors at 2654209-2654212
    Backup superblock at 4096000, Group descriptors at 4096001-4096004

provea un nodo de dispositivo apropiado para que pueda ver las ubicaciones precisas. Esto sucede cuando el sistema de archivos se crea con la opción sparse_super, que es el valor por defecto.

El número de grupos de bloques está limitado debido al hecho que el mapa de bits de bloque - el cual identifica bloques usados y disponibles en el grupo - tiene que caber en un bloque único. Por lo tanto, si un bloque tiene un tamaño de 4096 bytes, un grupo de bloques no puede contener más de 32 K bloques, o 128 MB. Si tomamos el mayor tamaño posible de un grupo de bloques, una partición de 10 GB tendría que tener al menos 80 grupos de bloques.

El asignador de bloques trata de mantener los bloques de cada archivo en el mismo grupo de bloques para disminuir los tiempos de búsqueda.

Como se ha demostrado, es posible usar la herramienta dumpe2fs para obtener información del sistema de archivos; poniendo esto en práctica sobre una partición obtenemos lo siguiente:

$ sudo dumpe2fs /dev/sda1

Filesystem volume name:  RHEL7
Last mounted on:         /
Filesystem UUID:         9d6b5801-9c7e-4c17-9068-49923952338e
Filesystem magic number: 0xEF53
Filesystem revision #:   1 (dynamic)
Filesystem features:     has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super
Filesystem flags:        signed_directory_hash
Default mount options:   user_xattr acl
Filesystem state:        clean
Errors behavior:         Continue
Filesystem OS type:      Linux
Inode count:             1908736
Block count:             7630592
Reserved block count:    381529
Free blocks:             5353383
Free inodes:             1682479
First block:             0
Block size:              4096
Fragment size:           4096
Group descriptor size:   64
Reserved GDT blocks:     1024
Blocks per group:        32768
Fragments per group:     32768
Inodes per group:        8192
Inode blocks per group:  512
Flex block group size:   16
Filesystem created:      Wed Sep 3 03:52:55 2014
Last mount time:         Fri Oct 24 09:18:58 2014
Last write time:         Fri Oct 24 09:18:58 2014
Mount count:             89
Maximum mount count:     -1
Last checked:            Wed Sep 3 03:52:55 2014
Check interval:          0 (<none>)
Lifetime writes:         103 GB
Reserved blocks uid:     0 (user root)
Reserved blocks gid:     0 (group root)
First inode:             11
Inode size:              256
Required extra isize:    28
Desired extra isize:     28
Journal inode:           8
First orphan inode:      396118
Default directory hash:  half_md4
Directory Hash Seed:     e488c43e-241c-4014-91d8-6a9d3d6c7784
Journal backup:          inode blocks
Journal features:        journal_incompat_revoke journal_64bit
Journal size:            128M
Journal length:          32768
Journal sequence:        0x00023592
Journal start:           16394
Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
    Checksum 0x2921, unused inodes 7738
    Primary superblock at 0, Group descriptors at 1-4
    Reserved GDT blocks at 5-1028
    Block bitmap at 1029 (+1029), Inode bitmap at 1045 (+1045)
    Inode table at 1061-1572 (+1061)
    22880 free blocks, 8174 free inodes, 2 directories, 7738 unused inodes
    Free blocks: 9381-9672, 10180-32767
    Free inodes: 19-8192
Group 1: (Blocks 32768-65535) [INODE_UNINIT, ITABLE_ZEROED]
    Checksum 0x473e, unused inodes 8192
    Backup superblock at 32768, Group descriptors at 32769-32772
    Reserved GDT blocks at 32773-33796
    Block bitmap at 1030 (bg #0 + 1030), Inode bitmap at 1046 (bg #0 + 1046)
    Inode table at 1573-2084 (bg #0 + 1573)
    14918 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
    Free blocks: 33797, 33800-33919, 34108-34511, 34521-34559, 34784-34815, 37053-38015, 38039- 38040, 38080-38527, 38529-38911, Free inodes: 8193-16384
.....
Group 196: (Blocks 6422528-6455295) [INODE_UNINIT, ITABLE_ZEROED]
    Checksum 0x946d, unused inodes 8192
    Block bitmap at 6291460 (bg #192 + 4), Inode bitmap at 6291476 (bg #192 + 20)
    Inode table at 6293536-6294047 (bg #192 + 2080)
    32768 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
    Free blocks: 6422528-6455295
    Free inodes: 1605633-1613824
    ....
Group 232: (Blocks 7602176-7630591) [INODE_UNINIT, ITABLE_ZEROED]
    Checksum 0xa174, unused inodes 8192
    Block bitmap at 7340040 (bg #224 + 8), Inode bitmap at 7340056 (bg #224 + 24)
    Inode table at 7344160-7344671 (bg #224 + 4128)
    28416 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
    Free blocks: 7602176-7630591
    Free inodes: 1900545-1908736

tune2fs puede ser usado para cambiar parámetros del sistema de archivos.

Para cambiar el número máximo de montajes entre verificaciones del sistema de archivos (max-mount-count):

$ sudo tune2fs -c 25 /dev/sda1

Para cambiar el intervalo de tiempo entre verificaciones (interval-between-checks):

$ sudo tune2fs -i 10 /dev/sda1

Para listar el contenido del superbloque incluyendo los valores actuales de los parámetros que pueden ser modificados:

$ sudo tune2fs -l /dev/sda1

El superbloque contiene información global acerca del sistema de archivos, incluyendo:

• Mount count (cuenta de montaje) y maximum mount count (cuenta máxima de montaje). El parámetro mount count se incrementa cada vez que el disco es montado satisfactoriamente y el valor corresponde al número de veces que esa operación se ha realizado desde el último fsck. También es posible forzar la verificación del sistema de archivos luego de 180 días (por defecto), u otro período de tiempo que puede ser configurado con la herramienta tune2fs.
• Tamaño del bloque, el cual no puede ser mayor a una página de memoria. Se configura a través de mkfs.
• Bloques por grupo.
• Cuenta de bloques disponibles.
• Cuenta de inodos disponibles.
• ID del sistema operativo.

Como se comentó anteriormente, el superbloque se almacena de forma redundante en varios grupos de bloques.

El bloque de datos y el mapa de bits de inodos son bloques cuyos bits contienen 0 para cada bloque o inodo libre y 1 para cada uno que está usado. Hay uno de cada uno de estos mapas de bits por grupo de bloques.

La tabla de inodos contiene tantos bloques consecutivos como sea necesario para cubrir el número de inodos en el grupo de bloques. Cada inodo requiere 128 bytes; por lo tanto, un bloque de 4 KB puede contener 32 inodos.

Note que hay espacio reservado para cierta cantidad de información dependiente del sistema operativo; diferentes SOs podrían montar un sistema de archivos ext2/3/4, tal como Linux puede montar muchos sistemas de archivos no nativos.

Tenga en cuenta que el número de inodo no se almacena en esta estructura en el disco; su valor puede ser calculado rápidamente desde el número de grupo de bloque y el offset de la tabla de inodo.

Los sistemas de archivos ext2 y ext3 no han incorporado aún el uso de extents para organizar archivos grandes. En vez de eso, el arreglo de punteros a bloques de datos i_block[], de largo EXT2_N_BLOCKS=15, es descrito por el inodo. La forma en que esto se maneja es algo compleja:

• Los primeros 12 elementos en este arreglo apuntan a los primeros 12 bloques de datos en el archivo.
• El elemento 13avo apunta a un bloque que representa un arreglo de segundo orden de números de bloque; el 14avo a un arreglo de tercen orden y el 15avo a un arreglo de cuarto orden.

Este algoritmo hace que el abordar archivos pequeños sea más rápido, como es de esperar. Por ejemplo, con un tamaño de bloque de 4 KB, un archivo de 48 KB puede ser abordado directamente. Un archivo de 2 MB requiere un proceso de segundo orden, uno de 1 GB uno de tercer orden, uno de 4 GB uno de cuarto orden.

El sistema de archivos ext4:

• Es compatible con ext3 y ext2.
• Incrementa el tamaño máximo del sistema de archivos a 1 EB (desde 16 TB) y el tamaño máximo de un archivo a 16 TB (desde 2 TB). Estos límites aparecen cuando se usa un direccionamiento de 48 bit; direccionamiento completo de 64 bit podría usarse en el futuro, pero hasta la fecha no hay una necesidad real de ello.
• Incrementa de forma ilimitada el número máximo de subdirectorios, el cual estuvo limitado a 32 K en ext3.
• Divide archivos grandes en extents de la máxima longitud en vez de usar mapeo de bloques indirecto. Esto puede mejorar el rendimiento de archivos grandes y reducir la fragmentación.
• Utiliza asignación multibloque, la cual puede asignar todo el espacio de una vez, en vez de hacerlo de a un bloque. Adicionalmente, la asignación demorada puede incrementar el rendimiento también.
• Puede preasignar espacio de disco para un archivo. El espaco asignado está generalmente garantizado y es contiguo.
• Usa allocate-on-flush, una técnica de rendimiento la cual retrasa la asignación de bloques hasta que los datos son escritos en el disco.
• Usa fsck rápido, el cual puede aumentar la velocidad de verificación de un sistema de archivos en un orden de magnitud o más.
• Usa checksums para el journal, lo cual mejora la confiabilidad. Esto también puede evitar esperas de E/S durante el journaling, resultando en una lijera mejora del rendimiento.
• Usa timestamps mejoradas, medidas en nanosegundos.
• Incluye soporte de snapshots.

¿Qué comando puede usarse para ajustar el intervalo de tiempo entre verificaciones del sistema de archivo a 180 días, en un sistema de archivos ext3 o ext4 en /dev/sda1?

• Laboratorio 14.1
• Laboratorio 14.2

Actualmente usted debería ser capaz de:

• Describir las características principales del sistemas de archivos ext4 y la forma en la que ocupa el disco.
• Explicar los conceptos de grupos de bloques, superbloque, bloques de datos e inodos.
• Usar las herramientas dumpe2fs y tune2fs.
• Enumerar las mejoras del sistema de archivos ext4.

Los sistemas de archivos XFS y btrfs han surgido como desafíos importantes a la dominación de ext4 en las distribuciones empresariales de Linux. Estos sistemas de archivos de nueva generación tienen capacidades robustas en relación a manejar tamaños grandes, abarcan múltiples volúmenes físicos y lógicos, como también métricas de rendimiento.

Al final de este capítulo usted debería ser capaz de:

• Describir el sistema de archivos XFS.
• Mantener el sistema de archivos XFS.
• Describir el sistema de archivos btrfs.

XFS fue creado y diseñado originalmente por SGI y usado en el sistema operativo IRIX, y luego portado a Linux. Fue diseñado explícitamente para lidiar con conjuntos de datos grandes como también para manejar tareas en paralelo de E/S muy eficientemente.

Este puede manejar:

• Hasta 16 EB (exabytes) para el total del sistema de archivos
• Hasta 8 EB para un archivo individual.

El alto rendimiento es uno de los elementos clave del diseño de XFS, el cual implementa métodos para:

• Usar E/S de DMA (Direct Memory Access)
• Garantizar una tasa de E/S
• Ajustar tamaño de banda para igualar los dispositivos RAID o LVM subyacentes.

En contraste a los sistemas de archivos tradicionales, XFS puede manejar la información de las cuotas con journaling. Esto conduce a una reducción del tiempo de recuperación cuando un sistema de archivos que tiene cuotas se desmonta de forma fallida. Además, el journal puede estar en un dispositivo externo.

Al igual que otros sistemas de archivos de UNIX y Linux, XFS soporta atributos extendidos.

El realizar mantenimiento a un sistema de archivos XFS se facilita por el hecho de que la mayor parte de este tipo de tareas puede ser llevada a cabo en línea, es decir, con el sistema de archivos montado. Estas incluyen:

• Defragmentar
• Ampliar
• Realizar respaldo/Restaurar.

Para crear respaldos y restaurar se usan las siguientes herramientas nativas de XFS:

• xfsdump
• xfsrestore

los cuales pueden ser pausados de forma conveniente y retomados luego. Debido a que estos programas son multihebra, los respaldos y restauraciones de XFS pueden ser llevadas a cabo muy rápidamente.

Mientras que XFS no soporta directamente snapshots de hardware o software, la herramienta xfs-freeze puede ser usada para poner el sistema de archivos en reposo, permitiendo a algún programa de snapshot trabajar en el dispositivo subyacente. Las herramientas LVM de Linux usan xfs-freeze automáticamente para detener la actividad del sistema de archivos para tomar snapshots.

XFS soporta cuotas y los comandos tradicionales de cuota pueden usarse para manipular las cuotas por sistema de archivos en un volumen XFS. Sin embargo, si usa el comando xfs-quota puede hacer uso de las cuotas por directorio que XFS soporta.

Tanto desarrolladores como usuarios de Linux con sistemas de alto rendimiento y alta capacidad o necesidades específicas, están siguiendo el desarrollo e implementación gradual del sistema de archivos btrfs, el cual fue creado por Chris Mason. El nombre viene de sistema de archivos B-tree. La documentación completa puede ser encontrada en http://btrfs.wiki.kernel.org/index.php/Main_Page .

btrfs apunta a resolver la falta de pooling, snapshots, checksums e integral multi-device spanning en otros sistemas de archivos tales como ext4. Esas características pueden ser cruciales para que Linux escale a configuraciones de almacenamiento más grande de tipo empresarial.

Mientras que btrfs ha estado en el mainline kernel (versión de mantenimiento) desde 2.6.29, ha sido considerado como experimental, aunque unos pocos vendedores lo han usado en productos nuevos.

Una de las características principales es la habilidad de tomar snapshots frecuentes de sistemas de archivos completos, o de subvolúmenes de sistemas de archivos en muy poco tiempo. Debido a que btrfs hace amplio uso de la técnica COW (Copy on Write), un snapshot no involucra mucho espacio inicial para bloques de datos o cualquier otra actividad E/S, con la excepción de algunos metadatos que requieren ser actualizados.

Es posible revertir el sistema a un estado descrito por snapshots anteriores e incluso hacer que el kernel arranque una snapshot anterior del sistema de archivos raíz .

btrfs mantiene su propio framework interno para agregar o remover particiones nuevas y/o medios físicos a sistemas de archivos existentes, de forma similar a como lo hace LVM (Logical Volume Management).

Algunas tareas deben ser terminadas antes de que btrfs esté listo para el trabajo diario en sistemas de archivos críticos. Para revisar la historia de desarrollo de btrfs y la evolución que se espera revise http://lwn.net/Articles/575841.

¿Cuáles son las herramientas por defecto del sistema de archivos XFS para las siguientes operaciones?

• Realizar un respaldo
• Restaurar

• Laboratorio 15.1
• Laboratorio 15.2

Actualmente usted debería ser capaz de:

• Describir el sistema de archivos XFS.
• Mantener el sistema de archivos XFS.
• Describir el sistema de archivos btrfs.

LVM permite tener un sistema de archivos lógico sobre múltiples volúmenes físicos y particiones, la cual al usarla se presenta como una sola partición. Cuando se usa LVM es muy fácil contraer y expandir los sistemas de archivos según se necesite; sin embargo, tales operaciones son difíciles de realizar en particiones físicas fijas.

Al final de este capítulo usted debería ser capaz de:

• Explicar los conceptos detrás de LVM.
• Crear volúmenes lógicos.
• Visualizar volúmenes lógicos.
• Redimensionar volúmenes lógicos.
• Usar snapshots de LVM.

LVM (Logical Volume Manager) separa una partición virtual en varias partes, cada de una de las cuales puede estar en distintas particiones y/o discos.

Hay muchas ventajas al usar LVM; en particular, se torna bastante fácil el modificar el tamaño de las particiones lógicas y sistemas de archivos, agregar más espacio de almacenamiento y reorganizarlo.

Uno o más volúmenes físicos (particiones de disco) están agrupadas en un grupo de volúmenes. Luego el grupo de volumen es subdividido en volúmenes lógicos, lo cual imita particiones de disco físicas y pueden ser formateadas para contener sistemas de archivos.

Hay una variedad de herramientas de línea de comandos para crear, eliminar, redimensionar, etc., volúmenes físicos y lógicos. La herramienta gráfica system-config-lvm se usa en la mayoría de distribuciones de Linux. Sin embargo, en RHEL 7 ya no está soportada y no hay ninguna herramienta gráfica que sea confiable con los cambios más recientes de los sistemas de archivos. Afortunadamente, las herramientas de la línea de comandos no son difíciles de usar y son más flexibles.

LVM tiene un impacto en el rendimiento. Hay un costo adicional definido que proviene de la sobrecarga de la capa de LVM. Sin embargo, aún en sistemas sin RAID, si se usa striping (dividir los datos en más de un disco) es posible lograr algunas mejoras de paralelización.

Al igual que RAID (lo cual discutiremos en el próximo capítulo), el uso de volúmenes lógicos es un mecanismo para crear sistemas de archivos que pueden abarcar más de un disco físico.

Para crear volúmenes lógicos primero se ponen todos los dispositivos en un pool grande de espacio de disco (el grupo de volúmenes). Luego de eso, se asigna espacio desde el pool con el cual se crea un volumen lógico.

Los volúmenes lógicos tienen características similares a los dispositivos de RAID. De hecho pueden estar construidos sobre un dispositivo RAID. Esto le daría al volumen lógico la redundancia de un dispositivo RAID con la escalabilidad de LVM.

LVM tiene mejor escalabilidad que RAID: los volúmenes lógicos pueden ser fácilmente redimensionados, tanto para agrandarlos como reducirlos. Si se requiere más espacio, es posible agregar dispositivos adicionales en cualquier momento.

Las particiones son convertidas a volúmenes físicos y múltiples volúmenes físicos se agrupan en grupos de volúmenes; puede haber más de un grupo de volúmenes en el sistema.

El espacio en el grupo de volúmenes se divida en extents, los cuales son por defecto de 4 MB de tamaño, pero puede ser modificado en el momento de la asignación.

Hay una serie de herramientas de línea de comandos que se usan para crear y manipular grupos de volúmenes, cuyos nombres comienzan siempre con vg. Algunas de estas utilidades son:

• vgcreate: Crea grupos de volúmenes.
• vgextend: Agrega volúmenes físicos a un grupo de volúmenes.
• vgreduce: Reduce un grupo de volúmenes.

Las herramientas que agregan o quitan particiones físicas de un grupo de volúmenes comienzan con pv e incluyen:

• pvcreate: Convierte una partición en un volumen físico.
• pvdisplay: Muestra los volúmenes físicos en uso.
• pvmove: Mueve los datos desde un volumen físico a otro, dentro del mismo grupo de volúmenes; esto puede ser requerido si un disco o una partición va a ser eliminada por alguna razón. A continuación podría ejecutarse:
• pvremove: Elimina una partición desde un volumen físico.

Para obtener una lista completa de las herramientas LVM ejecute man lvm.

Hay una serie de herramientas que manipulan volúmenes lógicos. Como era de esperar, todos comienzan con lv. Revisaremos los más utilizados, pero una lista corta puede ser obtenida con:

$ ls -lF /sbin/lv*

lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvchange -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvconvert -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvcreate -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvdisplay -> lvm*
lrwxrwxrwx. 1 root root              3 Sep  3 03:58 /usr/sbin/lvextend -> lvm*
-r-xr-xr-x. 1 root root 1196016 Mar 26  2014 /usr/sbin/lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvmchange -> lvm*
-r-xr-xr-x. 1 root root    7230 Mar 26  2014 /usr/sbin/lvmconf*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvmdiskscan -> lvm*
-r-xr-xr-x. 1 root root    7412 Mar 26  2014 /usr/sbin/lvmdump*
-r-xr-xr-x. 1 root root   48728 Mar 26  2014 /usr/sbin/lvmetad*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvmsadc -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvmsar -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvreduce -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvremove -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvrename -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvresize -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvs -> lvm*
lrwxrwxrwx. 1 root root       3 Sep  3 03:58 /usr/sbin/lvscan -> lvm*

Nota:

• Estas herramientas están en /sbin y no en /usr/sbin , ya que pueden ser necesitados para arrancar o reparar y recuperar un sistema.
• La mayoría de ellas están enlazadas simbólicamente a lvm, un programa al estilo navaja suiza que realiza todo el trabajo y que sabe qué debe hacer basado en el nombre por el cual es invocado. Esto también es válido para la mayoría de las herramientas pv* y vg*, lo cual se puede comprobar fácilmente.

lvcreate asigna volúmenes lógicos desde los grupos de volúmenes. El tamaño puede especificarse ya sea en bytes o número de extents (recuerde que son de 4 MB por defecto). Los nombres son a elección.

lvdisplay informa acerca de los volúmenes lógicos disponibles.

Los sistemas de archivos se localizan en los volúmenes lógicos y se formatean como de costumbre, con mkfs.

Si se comienza con un grupo de volúmenes nuevo, los pasos asociados a la configuración y uso de un volumen lógico nuevo son los siguientes:

1. Crear particiones en las unidades de disco (escriba 8e en fdisk) .
2. Crear volúmenes físicos desde las particiones.
3. Crear el grupo de volúmenes.
4. Asignar volúmenes lógicos desde el grupo de volúmenes.
5. Montar los volúmenes lógicos (y actualizar /etc/fstab según sea necesario).

Los siguientes programas de línea de comandos están disponibles para desplegar información acerca de LVM:

• pvdisplay muestra los volúmenes físicos

$ sudo pvdisplay
$ sudo pvdisplay /dev/sda5

• vgdisplay muestra los grupos de volúmenes

$ sudo vgdisplay
$ sudo vgdisplay /dev/vg0

• lvdisplay muestra los volúmenes lógicos

$ sudo lvdisplay
$ sudo lvdisplay /dev/vg0/lvm1

Si no se proveen argumentos, estas herramientas desplegarán todos los volúmenes físicos, grupos de volúmenes o volúmenes lógicos, según corresponda.

Una de las grandes ventajas de usar LVM es que es fácil y rápido cambiar el tamaño de un volumen lógico, especialmente cuando se intenta hacer lo mismo con una partición física que ya contiene un sistema de archivos.

Cuando se hace esto, los extents pueden agregarse o substraerse desde el volumen lógico, y pueden provenir desde cualquier parte en el grupo de volúmenes; de hecho no necesitan ser de regiones físicas contiguas del disco.

Si el volumen contiene un sistema de archivos, expandirlo o contraerlo es una operación completamente diferente que cambiar el tamaño del volumen:

• Cuando se expande un volumen lógico que tiene un sistema de archivos, se debe expandir primero el volumen y luego el sistema de archivos.
• Cuando se contrae un volumen lógico que contiene un sistema de archivos, primero se debe contraer el sistema de archivos y luego el volumen.

El sistema de archivos no puede estar montado mientras se reduce el tamaño del mismo. Sin embargo, algunos sistemas de archivos permiten ser expandidos mientras están montados.

Obviamente, las herramientas para modificar el tamaño del sistema de archivos dependen del tipo del mismo; para ext4 el programa es resize2fs.

Para extender un volumen lógico con un sistema de archivos ext4:

$ sudo lvextend -L +500M /dev/vg/mylvm
$ sudo resize2fs /dev/vg/mylvm

donde el signo más indica que se está agregando espacio.

Para reducir el sistema de archivos:

$ sudo umount /mylvm
$ sudo fsck -f /dev/vg/mylvm
$ sudo resize2fs /dev/vg/mylvm 200M
$ sudo lvreduce -L 200M /dev/vg/mylvm
$ sudo mount /dev/vg/mylvm

Si usted tiene una versión reciente de las herramientas lvm, puede realizar estas operaciones en un paso en vez de dos, usando la opción -r, como se muestra a continuación:

$ sudo
$ sudo lvextend -r -L +100M /dev/vg/mylvm
$ sudo lvreduce -r -L -100M /dev/vg/mylvm

en donde las cantidades usan el signo más o menos para indicar el cambio requerido. Esto usa la herramienta subyacente fsadm, la cual puede redimensionar cualquier tipo de sistema de archivos para cual cual el sistema operativo tenga soporte. Le recomendamos leer la página man de fsadm.

Es posible reducir un grupo de volúmenes de la siguiente forma:

$ sudo pvmove /dev/sdc1
$ sudo vgreduce vg /dev/sdc1

Las snapshots LVM crean una copia exacta de un volumen lógico.

Son muy útiles para realizar respaldos, probar aplicaciones e implementar VMs (máquinas virtuales). El estado original de la snapshot se mantiene, como por ejemplo el mapa de bloques.

Los snapshots usan espacio para almacenar las diferencias (conocidas como deltas):

• Cuando el volumen lógico original cambia, los bloques de datos originales son copiados a la snapshot.
• Si la información se agrega directamente al snapshot, se almacena ahí solamente.

Para crear una snapshot de un volumen lógico existente:

$ sudo lvcreate -l 128 -s -n mysnap /dev/vg/mylvm

Para crear un punto de montaje y montar la snapshot:

$ mkdir /mysnap
$ mount -o ro /dev/vg/mysnap /mysnap

Para desmontar/usar la snapshot y luego removerla:

$ sudo umount /mysnap
$ sudo lvremove /dev/vg/mysnap

Asegúrese siempre de remover la snapshot cuando va a trabajar con ella. Si no remueve la snapshot y esta se llena a causa de los cambios, será deshabilitada automáticamente. Una snapshot con el tamaño del original nunca se desbordará.

Seleccione la sentencia correcta de las listadas a continuación:

Los PVs están agrupados en VGs. Los VGs se dividen en LVs.

Los VGs están agrupados en PVs. Los PVs se dividen en LVs.

Los LVs están agrupados en VGs. Los VGs se dividen en PVs.

¿Cuál es el mejor orden lógico de acciones necesarias para crear un disco nuevo y hacerlo disponible usando LVM?

Particionar el disco.

Crear un volumen físico.

Crear un grupo de volúmenes.

Asignar un volumen lógico.

Formatear el volumen lógico.

Montar el volumen lógico.

• Laboratorio 16.1

Actualmente usted debería ser capaz de:

• Explicar los conceptos detrás de LVM.
• Crear volúmenes lógicos.
• Visualizar volúmenes lógicos.
• Redimensionar volúmenes lógicos.
• Usar snapshots de LVM.

Al usar RAID se reparte la actividad de E/S en múltiples discos físicos en vez de sólo uno. El propósito de esto es mejorar la integridad y capacidad de recuperación en caso de falla, como también aumentar el rendimiento cuando es usado con dispositivos modernos de almacenamiento. Hay diversos niveles de RAID, los cuales varían en sus fortalezas relativas de seguridad, rendimiento, complejidad y costo.

Al final de este capítulo usted debería ser capaz de:

• Explicar el concepto de RAID.
• Proveer un resumen de los niveles de RAID.
• Configurar un dispositivo RAID usando los pasos esenciales entregados.
• Monitorear dispositivos RAID de múltiples maneras.
• Usar discos de reserva (hot spares).

RAID (Redundant Array of Independent Disks) reparte la carga de E/S en múltiples discos. Esto realmente puede incrementar el rendimiento en interfaces de controladoras de disco modernas, tales como SCSI, las cuales pueden realizar el trabajo en paralelo, de forma eficiente.

RAID puede ser implementado ya sea en software (es una parte madura del kernel Linux) o en hardware. Si su hardware de RAID es conocido por tener una buena calidad, podría ser más eficiente que usar RAID de software. En una implementación de hardware, el sistema operativo no está consciente de que está usando RAID, esto es transparente. Por ejemplo, tres discos duros de 512 GB (dos para datos, uno para paridad) configurados con RAID-5, se verán como un disco único de 1 TB.

Por otro lado, una desventaja de usar RAID de hardware es que si la controladora del disco falla, debe ser reemplazado por una compatible, la cual puede no ser fácil de obtener en todos los casos. Cuando se usa RAID de software, los mismos discos pueden conectarse y funcionar con cualquiera controladora de disco. Tales consideraciones pueden ser relevantes para hardware de gama media y baja.

Tres características esenciales de RAID son:

• mirroring (espejamiento): escribe los mismos datos en más de un disco.
• striping (división): divide o reparte los datos en más de un disco.
• parity (paridad): datos extra son almacenados para permitir la detección y reparación de problemas, proveyendo tolerancia a fallos.

Por lo tanto el uso de RAID puede mejorar tanto el rendimiento y fiabilidad.

Uno de los principales propósitos de RAID es crear un sistema de archivos el cual se reparte en más de un disco. Esto nos permite crear sistemas de archivos que son más grandes que cualquier dispositivo único. Los dispositivos RAID son creados generalmente combinando particiones de diferentes discos juntos.

Otra ventaja de los dispositivos RAID es la habilidad de proveer mejor rendimiento, redundancia o ambos. Striping provee mejor rendimiento al repartir la información sobre múltiples dispositivos, de tal forma que la escritura simultánea es posible. Mirroring o espejamiento escribe la misma información en múltiples discos proveyendo una mejor redundancia.

mdadm se usa para crear y administrar dispositivos RAID.

Una vez creado, el nombre del arreglo /dev/mdX puede ser usado como cualquier otro dispositivo, tal como /dev/sda1.

Existe una serie de especificaciones de RAID de complejidad y uso creciente. Los más comúnmente conocidos son los niveles 0, 1 y 5.

• RAID 0 usa striping solamente. Los datos se reparten a través de discos múltiples. Sin embargo, a pesar del nombre, no hay redundancia y no hay estabilidad o capacidades de recuperación. De hecho, si cualquier disco falla la información se perderá. Pero el rendimiento puede ser mejorada significativamente debido a la paralelización de tareas de E/S.
• RAID 1 usa mirroring solamente; cada disco tiene un duplicado, lo cual es bueno para la recuperación de los datos. Se requieren al menos dos discos.
• RAID 5 usa una banda de paridad de rotación; si una unidad de disco falla, no se producirá una pérdida de datos, solamente se reducirá el rendimiento. Tienen que haber al menos 3 discos.
• RAID 6 tiene discos con stripping y paridad dual; puede soportar la pérdida de dos discos y requiere al menos 4. Debido a que RAID 5 puede imponer un estrés significante sobre los discos, lo cual puede conducir a fallas durante el proceso de recuperación, RAID 6 se ha vuelto más importante.
• RAID 10 es un set de datos con mirroring y striping. Se necesitan al menos 4 discos.

Como regla general, el agregar más discos mejora el rendimiento.

Los pasos esenciales para configurar un dispositivo de RAID de software son:

• Crear las particiones en cada disco (teclee fd en fdisk).
• Crear el dispositivo RAID con mdadm.
• Formatear el dispositivo RAID.
• Agregar el dispositivo a /etc/fstab
• Montar el dispositivo RAID.
• Capturar detalles del RAID para asegurar la persistencia.

El comando:

$ sudo mdadm -S

se usa para detener/desactivar el RAID.

Por ejemplo:

Crear primero dos particiones de tipo fd en los discos sdb and sdc (digamos /dev/sdbX y /dev/sdcX) usando fdisk en cada una de ellas:

$ sudo fdisk /dev/sdb
$ sudo fdisk /dev/sdc

Entonces configure el arreglo, dele formato, agréguelo a la configuración y móntelo:

$ sudo mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/sdbX /dev/sdcX
$ sudo mkfs.ext4 /dev/md0
$ sudo bash -c "mdadm --detail --scan >> /etc/mdadm.conf"
$ sudo mkdir /myraid
$ sudo mount /dev/md0 /myraid

Asegúrese de agregar una línea en /etc/fstab para el punto de montaje.

/dev/md0 /myraid ext4 defaults 0 2

Puede examinar /proc/mdstat para ver el estado del RAID, tal como se muestra aquí:

$ cat /proc/mdstat

Personalities : [raid1]
md0 : active raid1 sdb8[1] sdc7[0]
---------- 521984 blocks [2/2]
unused devices: <none>

Use lo siguiente para detener el dispositivo RAID:

$ sudo mdadm -S /dev/md0

Usted puede monitorear dispositivos RAID de diversas formas:

$ sudo mdadm --detail /dev/md0
$ cat /proc/mdstat

También es posible usar mdmonitor, el cual requiere configurar /etc/mdadm.conf. El siguiente comando mostrará el estado actual del dispositivo RAID /dev/mdX:

$ sudo mdadm --detail /dev/mdX

Otra forma de hacerlo es examinar el sistema de archivos /proc:

$ cat /proc/mdstat

mostrará el estado de todos los dispositivos RAID en el sistema.

También puede darle el siguiente uso al servicio mdmonitor, editando /etc/mdadm.conf y agregando una línea como la siguiente:

MAILADDR eddie@haskell.com

lo anterior le enviará un email a eddie@haskell.com cuando un dispositivo RAID esté experimentando algún problema, tal como un arreglo que falla al iniciar o que cae en un estado degradado de funcionamiento. Lo puede habilitar con:

$ sudo service mdmonitor start

y asegúrese que va a iniciar en el arranque con:

$ sudo chkconfig mdmonitor on

Nota: En sistemas Ubuntu el servicio se llama mdadm en vez de mdmonitor.

Una de las cosas importantes que provee RAID es redundancia. Para asegurar que cualquier reducción en esa redundancia es resuelta lo antes posible, se usa un disco de reserva.

Para crear un disco de reserva cuando se está creando el arreglo RAID:

$ sudo mdadm --create /dev/md0 -l 5 -n3 -x 1 /dev/sda8 /dev/sda9 /dev/sda10 /dev/sda11

La opción -x 1 le indica a mdadm que use un dispositivo de reserva. Tenga en cuenta que un disco de reserva también puede ser agregado más tarde.

El comando:

$ sudo mdadm --fail /dev/md0 /dev/sdb2

probará la redundancia y el disco de de reserva de su arreglo.

Para restaurar la unidad probada o un disco nuevo en caso de una falla legítima, primero remueva el miembro defectuoso y luego agregue el miembro nuevo, como se muestra a continuación:

$ sudo mdadm --remove /dev/md0 /dev/sdb2
$ sudo mdadm --add /dev/md0 /dev/sde2

Supongamos que usted agregó dos discos nuevos a un servidor. ¿En qué orden debería usar los siguientes comandos para crear un dispositivo RAID con /dev/sdb1 y /dev/sdc1, y luego habilitar el RAID usando un sistema de archivos ext4?

fdisk /dev/sdb; fdisk /dev/sdc
mdadm --create /dev/md0 ... /dev/sdb1 /dev/sdc1
mkfs.ext4 /dev/md0
mdadm --detail --scan >> /etc/mdadm.conf
reboot

¿Cuál es el único nivel de RAID que no ofrece redundancia?

RAID 10

RAID 1

RAID 6

RAID 0

RAID 5

• Laboratorio 17.1

Actualmente usted debería ser capaz de:

• Explicar el concepto de RAID.
• Proveer un resumen de los niveles de RAID.
• Configurar un dispositivo RAID usando los pasos esenciales entregados.
• Monitorear dispositivos RAID de múltiples maneras.
• Usar discos de reserva (hot spares).

Una tarea esencial de cualquier administrador de sistemas es asegurar el o los sistemas contra amenazas tanto internas como externas. El trabajo comienza con el diseño de una política de seguridad apropiada, creada para defenderse contra amenazas esperadas e inesperadas. Adicionalmente se requiere mantener los sistemas en un punto saludable; se necesita realizarles mantención y actualizarlos de forma oportuna, como también protegerlos físicamente de robos. Además, políticas sensatas tienen que garantizar que solo los usuarios apropiados tienen privilegios potencialmente peligrosos, y solo aquellos que son absolutamente necesarios.

Al final de este capítulo usted debería ser capaz de:

• Evaluar los riesgos de seguridad del sistema.
• Implementar políticas y procedimientos de seguridad informática.
• Proteger de forma eficiente la BIOS y el cargador de arranque con contraseñas de acceso.
• Usar de forma apropiada las opciones setuid y setgid del comando mount, para mejorar la seguridad.

Los computadores son inherentemente inseguros y necesitan ser protegidos de la gente que podría inmiscuirse en ellos o atacarlos. Los atacantes suelen hacer esto con el fin de dañar el sistema, denegar servicios o robar información.

Ningún computador puede ser absolutamente seguro. Todo lo que podemos hacer es ralentizar y desalentar a los intrusos con el fin de que abandonen el ataque, para buscar blancos más fáciles, o para atraparlos en el acto y tomar las acciones apropiadas.

La seguridad puede ser definida en términos de la habilidad del sistema para hacer con regularidad lo que se supone que tiene que hacer, su integridad y exactitud, como también en la garantía de que el sistema está disponible solamente para quienes están autorizados a usarlo.

El mayor problema es encontrar la mezcla apropiada entre seguridad y productividad; si las restricciones de seguridad presionan mucho al usuario, son difíciles, no están totalmente claras y básicamente son medidas ineficaces, los usuarios eludirán los procedimientos.

Las cuatro áreas que necesitamos proteger incluyen la física, local, remota y el personal. En esta sección no nos concentraremos en la seguridad de la red, sino más bien en los factores locales.

Es importante crear y dar a conocer en la organización una política de seguridad clara. Esta debería:

• Ser simple y fácil de comprender.
• Ser actualizada constantemente.
• Estar por escrito en un documento, como también en línea de ser necesario.
• Describir tanto políticas como procedimientos.
• Especificar las acciones coercitivas.
• Especificar las accionar a tomar en respuesta a una brecha de seguridad.

Las políticas deben ser genéricas y fáciles de entender, ya que eso las hace más fáciles de seguir. Deben salvaguardar la información que necesita ser protegida, denegar acceso a los servicios asociados y proteger la privacidad de los usuarios.

Estas políticas deberían ser actualizadas regularmente; de hecho las políticas necesitan cambiar en la medida en que los requerimientos lo hacen. Tener una política desactualizada puede ser peor que no tener una.

Una política de seguridad debe incluir métodos de protección de la información, para evitar sea leída o copiada por personal no autorizado. También debería debería incluir protección para que la información no sea alterada o eliminada sin el permiso del dueño. Todos los servicios deberían estar protegidos para que estén disponibles y no degradados de alguna forma sin autorización.

Aspectos esenciales:

• Confidencialidad
• Integridad de los datos
• Disponibilidad
• Consistencia
• Control
• Auditoría.

Debe asegurarse que la información es la correcta y que el sistema se comporta como se espera. En efecto, debería haber procesos para determinar quien está consiguiendo acceso a su sistema. El factor humano es el enlace más débil en la cadena de seguridad; esto requiere la mayor atención a través de una auditoría constante.

El análisis de riesgo está basado en las siguientes tres preguntas:

• ¿Qué quiero proteger?
• ¿Contra quién lo estoy protegiendo?
• ¿Cuánto tiempo, personal y dinero se necesita para brindar la protección adecuada?

Este es el primer paso a tomar para construir una política de seguridad informática. Es un prerrequisito para planear y luego aplicar políticas y procedimientos para proteger sus sistemas.

Existen dos filosofías básicas que se pueden encontrar en la mayoría de ambientes computacionales:

• Cualquier cosa no expresamente permitida es denegada.
• Cualquier cosa que no está expresamente prohibida es permitida.

Usted debe decidir cuál filosofía es la mejor para su organización.

La primera opción es más estricta: un usuario está habilitado para hacer solo lo que está clara y explícitamente especificado como permisible sin privilegios. Esta es la filosofía usada más comúnmente.

La segunda alternativa constituye un ambiente más liberal en donde a los usuarios se les permite hacer todo excepto lo que está expresamente prohibido. Esto implica un alto grado de confianza y se utiliza con menos frecuencia por razones obvias.

A continuación algunas guías generales a recordar durante la implementación de filosofías de seguridad:

1. El factor humano es el eslabón más débil.
   Debe educar a sus usuarios y mantenerlos contentos. El mayor porcentaje de vulneraciones de seguridad son internos y a menudo no son maliciosos.
2. No existe un ambiente informático invulnerable.
   El único sistema totalmente seguro es el que no está conectado a nada, guardado en una habitación segura y apagado.
3. La paranoia es buena.
   Sospeche, esté atento y sea perseverante al asegurar un sistema informático. Es un proceso continuo al que se le debe prestar atención constantemente. Verifique los procesos, usuarios y fíjese en cualquier cosa que parezca estar fuera de lo normal.

Los usuarios nunca deberían poner el directorio actual en el path. Es decir, no ponga algo como lo siguiente en su archivo ~/.bashrc:
PATH=./:$PATH

Esto tiene un riesgo de seguridad importante; una persona maliciosa podría reemplazar un programa con otro del mismo nombre, el cual podría hacer cosas perjudiciales. Piense en un script llamado ls que contenga solo la siguiente línea:

/bin/rm -rf $HOME

Si usted fuera al directorio que contiene ese archivo y ejecutara ls, borraría todo su directorio de usuario.

Es crítico prestar atención a las actualizaciones de su distribuidor de Linux y aplicarlas tan pronto sea posible.

La mayoría de los ataques explotan agujeros de seguridad conocidos en el período de tiempo entre la revelación del problema y la aplicación de parches. Los ataques de día cero son mucho más raros; en este caso un atacante usa un agujero de seguridad que no ha sido descubierto o para el cual no se ha liberado un parche.

Los administradores de sistemas son reacios a aplicar tales parches inmediatamente después de que han sido liberados, más que nada basados en experiencias negativas con compañías de software privativo, las que pueden causar más problemas que soluciones con los parches que incluyen. Sin embargo, esas regresiones son extremadamente raras en Linux, y probablemente el peligro de retrasar la aplicación de un parche de seguridad no es justificable.

En cualquier momento el hardware que está accesible físicamente puede ser comprometido por:

• Key logging: Almacenar la actividad en tiempo real de un usuario de computador (con un software de tipo keylogger), incluyendo las teclas que presiona. La información capturada puede ser almacenada localmente o transmitida a máquinas remotas.
• Analizador de paquetes de red: Captura y visualización de los datos a nivel de paquetes de red.
• Arrancar con un live CD/DVD o de rescate.
• Montar nuevamente el disco y modificar su contenido.

El acceso físico a un sistema permite a los atacantes aprovechar fácilmente diferentes vectores de ataque, lo cual torna en irrelevantes todas las recomendaciones a nivel de sistema operativo.

Por lo anterior, la política de seguridad debe partir con requerimientos acerca de cómo asegurar apropiadamente el acceso físico a los servidores y estaciones de trabajo.

Los pasos necesarios incluyen:

• Asegurar las estaciones de trabajo y servidores.
• Proteger el acceso a los enlaces de red de personas en las cuales no confía.
• Proteger los teclados en donde las contraseñas son ingresadas para asegurar que no puedan ser alterados.
• Configure protección por contraseña en la BIOS de tal forma que el sistema no pueda ser arrancado con un live CD/DVD, de rescate o un dispositivo USB.

Para computadores de usuario y aquellos en un ambiente del hogar, algunas de las características mencionadas (como prevenir el arranque de medios removibles) pueden ser excesivas y usted podría evitar su uso. Sin embargo, si en su sistema hay información sensitiva que requiere protección, entonces no debe estar ahí, o debería estar mejor protegida utilizando los lineamientos mencionados anteriormente.

La BIOS es el nivel más bajo de software que configura o manipula su sistema. El cargador de arranque accede a la BIOS para determinar cómo arrancar la máquina. La BIOS:

• Es el nivel más bajo de seguridad.
• Debe ser protegido por el uso de una contraseña.
• Debe estar actualizada.

Configurar una contraseña en la BIOS protege de que personas sin autorización cambien las opciones de arranque para ganar acceso al sistema. Sin embargo, solo importa si alguien puede conseguir acceso físico a la máquina, ya que esto requiere de presencia local.

También se recomienda generalmente que la BIOS se mantenga al día con la última versión del firmware. Sin embargo, la mayoría de las actualizaciones de las BIOS no tienen relación con el tema de seguridad y los administradores de sistemas suelen instalar esos parches con mucho cuidado, ya que una pieza de código incompetente en actualizaciones innecesarias podría inutilizar un sistema.

Usted puede asegurar el proceso de arranque con una contraseña segura para prevenir que alguien evite el paso de autenticación de usuario. Esto puede funcionar en conjunto con una protección por contraseña de la BIOS.

Tenga en cuenta que al usar una contraseña en el cargador de arranque va a prevenir que un usuario edite la configuración del mismo durante el proceso de arranque, sim embargo no prevendrá que un usuario arranque desde un medio alternativo, tales como CDs/DVDs o dispositivos USB. Por lo anterior, esto debería ir acompañado con una contraseña en la BIOS para tener una protección total en esta etapa.

Para sistemas que usan GRUB:

• Para la versión 1 de GRUB (la antigua), ejecute grub-md5-crypt. Esta herramienta le pedirá una contraseña, la cual cifrará y desplegará.
  Luego de eso edite /boot/grub/grub.conf y agregue la línea siguiente debajo de la línea que contiene la entrada timeout:
  password --md5 $1$Wnvo.1$qz781HRVG4jUnJXmdSCZ30
  en donde debe ingresar la contraseña cifrada que desplegó la salida de grub-md5-crypt. Note que es posible forzar el uso de la contraseña solamente para algunas opciones de arranque, en vez de todas.
• Para la versión 2 de GRUB (la actual) las cosas son más complicadas. Sin embargo, existe una mayor flexibilidad y es posible hacer cosas como configurar contraseñas individuales de usuario, las cuales incluso pueden ser las del inicio de sesión.

Como es usual en la versión 2, nunca edite el archivo de configuración directamente (/boot/grub/grub.cfg). En vez de eso, edite los archivos de configuración en /etc/grub.d y luego ejecute update-grub. Una explicación de esto puede encontrarse aquí: https://help.ubuntu.com/community/Grub2/Passwords.

Cuando un sistema de archivos se monta, ya sea desde la consola con un comando mount, o automáticamente a través de /etc/fstab, hay varias opciones que se pueden especificar para incrementar la seguridad:

• nodev
  No interprete caracteres o dispositivos especiales de bloque en el sistema de archivos.
• nosuid
  Los bits set-user-identifier y set-group-identifier no tienen efecto. Vamos a discutir en breve setuid y setgid.
• noexec

Restringe la ejecución directa de cualquier binario en el sistema de archivos montado.

• ro

Monta el sistema de archivos en modo de solo lectura, como se muestra a continuación:

$ mount -o ro,noexec,nodev /dev/sda2 /mymountpt

o en /etc/fstab:

/dev/sda2 /mymountpt ext4 ro,noexec,nodev 0 0

Normalmente un programa corre con los privilegios del usuario que lo ejecutó. Esto significa que sin importar quien es el dueño del binario que está corriendo, el proceso de todas formas tiene privilegios restringidos.

Ocasionalmente puede tener sentido que haya usuarios con capacidades extendidas que no tienen generalmente, tales como la habilidad para iniciar o detener una interfaz de red, o editar un archivo del cual el superusuario es dueño.

Al configurar el bit setuid (set user ID) en un archivo ejecutable, se modifica el comportamiento normal y se otorgan derechos de acceso del dueño en vez del usuario que ejecuta el programa.

Además es posible configurar el bit setgid, de tal forma que el proceso se ejecute con los privilegios del grupo que es dueño del binario, en vez del de quien lo está corriendo.

Quisiéramos enfatizar que esto es generalmente una mala idea y que es recomendable evitarlo en la mayoría de las circunstancias. A menudo es mejor escribir un programa demonio con menos privilegios para este tipo de uso. Algunas distribuciones recientes han deshabilitado completamente esta característica.

Esto se realiza de forma simple con:

$ chmod u+s somefile
$ chmod g+s somefile

en donde el primer ejemplo realiza la operación de setuid y el segundo la de setgid.

En el caso de los directorios, configurar el bit de grupo tiene un efecto diferente; se utiliza para crear un directorio compartido, como se muestra aquí:

$ chmod g+s somedir

Los archivos creados en este directorio pertenecen al grupo del dueño del directorio (y no al grupo del usuario que lo crea).

Tenga en cuenta que efectivamente no puede cambiar el setuid de un script shell; de hecho, no sucederá nada a menos que usted cambie el bit setuid en la consola, lo cual podría ser un tremendo agujero de seguridad. Solo se puede hacer en binarios ejecutables.

El uso de contraseñas para cuentas de usuario es común y es la herramienta básica para seguridad y privacidad. Sin embargo, hay dos contraseñas adicionales que se pueden configurar para incrementar de forma importante la seguridad del sistema. ¿Cuáles son las dos contraseñas adicionales que pueden ser configuradas para evitar que se carguen sistemas operativos desde dispositivos externos tales como un disco USB?

Cifrar el directorio / con LUKS.

Cifrar el directorio /boot con LUKS.

Configurar una contraseña para la BIOS.

Configurar una contraseña para el cargador de arranque.

• Laboratorio 18.1
• Laboratorio 18.2 (código fuente: writeit.c)

Actualmente usted debería ser capaz de:

• Evaluar los riesgos de seguridad del sistema.
• Implementar políticas y procedimientos de seguridad informática.
• Proteger de forma eficiente la BIOS y el cargador de arranque con contraseñas de acceso.
• Usar de forma apropiada las opciones setuid y setgid del comando mount, para mejorar la seguridad.

Un sistema computacional moderno tiene que ser seguro, pero las necesidades varían de acuerdo a la sensibilidad de la información, número de cuentas de usuario, exposición a redes externas, requerimientos legales y otros factores. La responsabilidad de habilitar buenos controles de seguridad recae tanto en los diseñadores de las aplicaciones, desarrolladores y mantenedores del kernel Linux. Por supuesto, los usuarios también deben seguir los buenos procedimientos establecidos, pero en un sistema gestionado adecuadamente, los usuarios no privilegiados deberían tener una capacidad muy limitada para exponer el sistema a violaciones de seguridad.

En esta sección nos ocuparemos de cómo el kernel Linux mejora la seguridad a través del uso de Módulos de Seguridad de Linux (LSM), particularmente con la implementación de SELinux.

Al final de este capítulo usted debería ser capaz de:

• Comprender cómo funciona y se implementa la infraestructura de los Módulos de Seguridad de Linux.
• Listar las diversas implementaciones disponibles de LSM.
• Describir las principales características de SELinux.
• Explicar los diversos modos y políticas disponibles.
• Comprender la importancia de los contextos, cómo obtenerlos y configurarlos.
• Saber cómo usar las herramientas importantes de SELinux.

Ha habido una serie de ideas acerca de cómo incorporar un módulo de seguridad informática en Linux. La idea es implementar controles de acceso obligatorios sobre una variedad de peticiones realizadas al kernel, de una forma en la que:

1. Se minimicen los cambios al kernel.
2. Se minimice la sobrecarga sobre el kernel.
3. Permita flexibilidad y se pueda elegir entre diferentes implementaciones, cada una de las cuales se presenta como un LSM autónomo (Linux Security Module).

La idea básica es interceptar las llamadas al sistema; insertar código cada vez que una aplicación solicita una transición a modo kernel con el fin de realizar la tarea que requiere habilidades extendidas. Este código se asegura de que los permisos son válidos y que exista protección contra intentos malintencionados. Esto se lleva a cabo al invocar pasos de seguridad funcionales antes y/o después de que una llamada al sistema es satisfecha por el kernel.

Por un largo tiempo el único modelo de seguridad extendida que se implementaba fue SELinux. Cuando el proyecto fue sugerido por primera vez para ser incluido directamente en el kernel, en el 2001, hubo objeciones acerca de usar un solo enfoque a la seguridad extendida.

Como resultado de lo anterior, el método LSM fue adoptado con el fin de que módulos alternativos a SELinux podrían ser usados a medida en que fueran desarrollados. Se incorporó al kernel Linux en 2003.

Las implementaciones actuales de LSM son:

• SELinux: http://selinuxproject.org/page/Main_Page
• AppArmor: http://apparmor.net
• Smack: http://schaufler-ca.com
• TOMOYO: http://tomoyo.sourceforge.jp

Solo un LSM puede ser usado a la vez, ya que potencialmente modifican las mismas partes del kernel Linux.

Nos concentraremos principalmente en SELinux y de forma secundaria en AppArmor, en orden de volumen de uso.

SELinux fue desarrollado originalmente por la NSA de Estados Unidos (National Security Administration) y ha sido parte integral de RHEL por mucho tiempo, lo cual ha traído consigo una gran base de usuarios.

Operacionalmente, SELinux es un conjunto de reglas de seguridad que se usan para determinar qué procesos pueden acceder a cuáles archivos, puertos y otros ítems en el sistema.

Funciona con estas tres cantidades conceptuales:

1. Contextos: Son etiquetas a archivos, procesos y puertos. Ejemplos de contextos son usuarios de SELinux, rol y tipo.
2. Reglas: Describe el control de acceso en términos de contextos, procesos, archivos, puertos, usuarios, etc.
3. Políticas: Son un conjunto de reglas que describen las decisiones de control de acceso aplicables a todo el sistema, las que deberían ser aplicadas por SELinux.

Un contexto de SELinux es un nombre usado por una regla para definir cómo los usuarios, procesos y puertos interactúan entre ellos. Como la política por defecto es denegar cualquier acceso, las reglas se usan para describir las acciones permitidas en el sistema.

SELinux puede correr en uno de los tres modos siguientes:

• Enforcing: Todo el código SELinux está operativo y el acceso está denegado de acuerdo a la política. Todas las violaciones a la misma son auditadas y registradas.
• Permissive: Habilita el código SELinux pero solo audita y advierte acerca de las operaciones que serían denegadas en modo enforcing.
• Disabled: Deshabilita completamente el código para aplicaciones y kernel de SELinux y deja el sistema sin ninguna de estas protecciones.

Estos modos se seleccionan (y explican) en un archivo (generalmente /etc/selinux/config), cuya ubicación varía según la distribución (a menudo se encuentra en /etc/sysconfig/selinux o enlazado desde aquí). El archivo está bien autodocumentado. La herramienta sestatus despliega el modo y política actual.

Para examinar o configurar el modo actual se puede usar getenforce y setenforce:

$ getenforce

Disabled

$ sudo setenforce Permissive
$ getenforce

Permissive

setenforce se usa para cambiar entre modo enforcing y permissive al vuelo, mientras el sistema está en operación. Sin embargo, no se puede habilitar o deshabilitar el modo disabled de esta forma. Mientras que setenforce permite cambiar entre los modos Permissive y Enforcing, no permite deshabilitar SELinux completamente. Hay al menos dos formas diferentes de deshabilitar SELinux:

• Archivo de configuración: edite el archivo de configuración (generalmente /etc/selinux/config) y configure SELINUX=disabled. Este es el método por defecto y debería usarse para deshabilitar SELINUX permanentemente.
• Parámetro del kernel: Agregue selinux=0 a la lista de parámetros del kernel cuando reinicie.

Sin embargo es importante notar que no se recomienda deshabilitar SELinux en sistemas en los cuales va a ser habilitado nuevamente. Es preferible usar el modo Permissive en vez de deshabilitar SELinux, para evitar que el sistema de archivos sea reetiquetado completamente, lo cual podría consumir bastante tiempo.

El mismo archivo de configuración, generalmente /etc/sysconfig/selinux, también configura la política de SELinux. Se permiten múltiples políticas, pero solo una puede estar activa a la vez. Cambiar la política puede requerir un reinicio del sistema y un reetiquetado del contenido del sistema de archivos, lo cual puede ser lento. Cada política tiene archivos que deben ser instalados bajo /etc/selinux/[SELINUXTYPE].

Las políticas más comunes son:

• targeted: La política por defecto en la cual SELinux es más restringida a procesos específicos. Los procesos de usuario e init no están dentro de los objetivos. SELinux impone restricciones de memoria para todos los procesos, lo cual reduce la vulnerabilidad ante ataques de desbordamiento de búfer (buffer overflow).
• minimum: Una modificación sobre la política targeted en donde solo los procesos seleccionados están protegidos.
• MLS: La política de seguridad de múltiples niveles es mucho más restrictiva; todos los procesos se ponen en dominios de seguridad específicos con políticas particulares.

Como se mencionó anteriormente, los contextos son etiquetas que se aplican a archivos, directorios, puertos y procesos. Estas etiquetas se usan para describir reglas de acceso. Existen cuatro contextos de SELinux:

• User (usuario)
• Role (rol)
• Type (tipo)
• Level (nivel).

Sin embargo, nos focalizaremos en type (tipo), el cual es el contexto más usado comúnmente. La convención de nombres de etiquetas determina que las etiquetas de contexto type deben terminar con _t, como en kernel_t.

Muchos comandos estándar de la línea de comandos, como ls y ps, fueron extendidos para soportar SELinux y las secciones correspondientes fueron agregadas a las páginas man, explicando los detalles. A menudo el parámetro Z se pasa a las herramientas estándar de línea de comandos, como en:

$ ps axZ

LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t:s0 1 ? Ss 0:04 /usr/lib/systemd/systemd --switched-root ...
system_u:system_r:kernel_t:s0 2 ? S 0:00 [kthreadd]
...
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2305 ? D 0:00 sshd: peter@pts/0
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2306 pts/0 Ss 0:00 -bash
...
system_u:system_r:httpd_t:s0 7490 ? Ss 0:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0 7491 ? S 0:00 /usr/sbin/httpd -DFOREGROUND
...

$ ls -Z /home/ /tmp/

/home/:
drwx------. peter peter unconfined_u:object_r:user_home_dir_t:s0 peter
/tmp/:
-rwx------. root root system_u:object_r:initrc_tmp_t:s0 ks-script-c4ENhg
drwx------. root root system_u:object_r:tmp_t:s0 systemd-private-0ofSvO
-rw-------. root root system_u:object_r:initrc_tmp_t:s0 yum.log

Otras herramientas que fueron extendidas para soportar SELinux incluyen cp, mv y mkdir.

Tenga en cuenta que si SELinux está deshabilitado, no se mostrará información relevante en los campos asociados a esas herramientas.

Los archivos nuevos heredan el contexto del directorio padre, pero al mover o copiar archivos, el contexto del directorio fuente es el cual debe ser preservado, lo cual puede causar problemas.

Continuando con el ejemplo anterior, vemos que el contexto de tmpfile no ha cambiado al mover el archivo desde /tmp a /home/peter:

$ cd /tmp/
$ touch tmpfile
$ ls -Z tmpfile

-rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 tmpfile

$ cd
$ touch homefile
$ ls -Z homefile

-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile

$ mv /tmp/tmpfile .
$ ls -Z

-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile
-rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 tmpfile

El ejemplo clásico en el cual se crea un problema en SELinux al mover archivos es cuando son movidos al directorio DocumentRoot del servidor httpd. En sistemas que tienen habilitado SELinux, el servidor web solo puede acceder a archivos con las etiquetas de contexto adecuadas. Si se crea un archivo en /tmp y luego se mueve al directorio DocumentRoot, estará inaccesible para el servidor httpd hasta que el contexto SELinux del archivo se modifique.

La herramienta restorecon restablece los contextos de un archivo, basado en la configuración del directorio padre. En el siguiente ejemplo, restorecon restablece la etiqueta por defecto recursivamente para todos los archivos en el directorio home.

$ ls -Z

-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile
-rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 tmpfile

$ restorecon -Rv /home/peter

restorecon reset /home/peter/tmpfile context \
unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:user_home_t:s0

$ ls -Z

-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile
-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 tmpfile

Note que el contexto de tmpfile fue reconfigurado al contexto por defecto para archivos creados en el directorio home. El tipo fue cambiado desde user_tmp_t a user_home_t.

Otro problema es cómo configurar el contexto por defecto para un directorio nuevo. La herramienta semanage fcontext (proveída por el paquete policycoreutils-python) despliega y cambia el contexto por defecto de archivos y directorios. Tenga en cuenta que semanage fcontext cambia la configuración por defecto solamente y no se aplica a objetos existentes. Esto requiere ejecutar restorecon luego. Por ejemplo:

[root@rhel7 /]# mkdir /virtualHosts
[root@rhel7 /]# ls -Z

...
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 virtualHosts

[root@rhel7 /]# semanage fcontext -a -t httpd_sys_content_t /virtualHosts
[root@rhel7 /]# ls -Z

...
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 virtualHosts

[root@rhel7 /]# restorecon -RFv /virtualHosts

restorecon reset /virtualHosts context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0

[root@rhel7 /]# ls -Z

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 virtualHosts

Por lo tanto, el cambio del contexto desde default_t a httpd_sys_content_t se lleva a cabo solamente después de haber ejecutado restorecon.

El comportamiento de la política de SELinux puede ser configurada en tiempo de ejecución sin necesidad de reescribir la política. Esto se consigue configurando los Booleanos de SELinux, los cuales son parámetros de políticas que pueden ser habilidados y deshabilitados.

Para listar todos los booleanos de la política actual, incluyendo el estado actual y una descripción corta, haga lo siguiente:

$ sudo semanage boolean -l

SELinux boolean             State   Default   Description
ftp_home_dir                  (off , off)      Allow ftp to home dir
smartmon_3ware                (off , off)      Allow smartmon to 3ware
mpd_enable_homedirs           (off , off)      Allow mpd to enable homedirs
xdm_sysadm_login              (off , off)      Allow xdm to sysadm login
xen_use_nfs                   (off , off)      Allow xen to use nfs
mozilla_read_content          (off , off)      Allow mozilla to read content
...
nfs_export_all_rw              (on , on)       Allow nfs to export all rw
pcp_bind_all_unreserved_ports (off , off)      Allow pcp to bind all unreserved ports
postgresql_selinux_transmit_client_label (off , off) Allow postgresql to selinux transmit client label
collectd_tcp_network_connect  (off , off)      Allow collectd to tcp network connect
cobbler_use_cifs              (off , off)      Allow cobbler to use cifs
mcelog_server                 (off , off)      Allow mcelog to server
httpd_setrlimit               (off , off)      Allow httpd to setrlimit
squid_connect_any              (on , on)       Allow squid to connect any
ssh_sysadm_login              (off , off)      Allow ssh to sysadm login
domain_fd_use                  (on , on)       Allow domain to fd use
virt_use_samba                (off , off)      Allow virt to use samba
cluster_use_execmem           (off , off)      Allow cluster to use execmem
nfs_export_all_ro              (on , on)       Allow nfs to export all ro
cron_can_relabel              (off , off)      Allow cron to can relabel
sftpd_anon_write              (off , off)      Allow sftpd to anon write

Una alternativa para desplegar la información booleana que produce una salida más simple, es getsebool -a, la cual imprime solo el nombre booleano y su estado actual.

setsebool se usa para cambiar el estado booleano. El comportamiento por defecto es aplicar los cambios inmediatamente y no son persistentes luego del reinicio. Sin embargo, el parámetro -P puede ser proveído para hacer que los cambios sean persistentes.

SELinux viene con un conjunto de herramientas que recopilan información acerca de problemas en tiempo de ejecución; registran esos problemas y proponen soluciones para prevenir que esos problemas ocurran de nuevo. Estas herramientas son proveídas por el paquete setroubleshoot-server. Aquí hay un ejemplo de su uso:

[root@rhel7 ~]# echo 'File created at /root' > rootfile
[root@rhel7 ~]# mv rootfile /var/www/html/
[root@rhel7 ~]# wget -O - localhost/rootfile

--2014-11-21 13:42:04--  http://localhost/rootfile
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2014-11-21 13:42:04 ERROR 403: Forbidden.

[root@rhel7 ~]# tail /var/log/messages

Nov 21 13:42:04 rhel7 setroubleshoot: Plugin Exception restorecon
Nov 21 13:42:04 rhel7 setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file .
For complete SELinux messages. run sealert -l d51d34f9-91d5-4219-ad1e-5531e61a2dc3
Nov 21 13:42:04 rhel7 python: SELinux is preventing /usr/sbin/httpd from getattr access on the file .
*****  Plugin catchall (100. confidence) suggests  **************************
If you believe that httpd should be allowed getattr access on the  file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

[root@rhel7 ~]# sealert -l d51d34f9-91d5-4219-ad1e-5531e61a2dc3

SELinux is preventing /usr/sbin/httpd from getattr access on the file .
*****  Plugin catchall (100. confidence) suggests  **************************
If you believe that httpd should be allowed getattr access on the  file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context unconfined_u:object_r:admin_home_t:s0
Target Objects [ file ]
Source httpd
Source Path /usr/sbin/httpd
Port <Unknown>
Host rhel7
Source RPM Packages httpd-2.4.6-18.el7_0.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.12.1-153.el7_0.11.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name rhel7
Platform Linux rhel7 3.10.0-123.9.3.el7.x86_64 #1 SMP Thu
Oct 30 00:16:40 EDT 2014 x86_64 x86_64
Alert Count 2
First Seen 2014-11-21 12:34:13 CET
Last Seen 2014-11-21 13:42:04 CET
Local ID d51d34f9-91d5-4219-ad1e-5531e61a2dc3
Raw Audit Messages
type=AVC msg=audit(1416573724.395:1598): avc: denied { getattr } for pid=20180 comm="httpd"
path="/var/www/html/rootfile" dev="dm-0" ino=70624441 scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=SYSCALL msg=audit(1416573724.395:1598): arch=x86_64 syscall=lstat success=no exit=EACCES
a0=7f2896ed0578 a1=7fffcc64fb30 a2=7fffcc64fb30 a3=0 items=0 ppid=20178 pid=20180
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)
Hash: httpd,httpd_t,admin_home_t,file,getattr

Tenga en cuenta que en RHEL 7 se sugiere ejecutar lo siguiente:

$ grep httpd /var/log/audit/audit.log | audit2allow -M mypol

audit2allow es una herramienta que genera reglas de políticas de SELinux desde registros de operaciones denegadas. Una herramienta similar es audit2why, la cual traduce los mensajes de auditoría de SELinux en descripciones de porqué el acceso fue denegado.

El ejemplo siguiente muestra cómo resolver este problema usando la herramienta restorecon, la cual fue descrita anteriormente. Siéntase libre de intentar ambas aproximaciones para resolver el problema encontrado en SELinux.

[root@rhel7 ~]# restorecon -Rv /var/www/html/

restorecon reset rootfile context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0

[root@rhel7 ~]# wget -q -O - localhost/rootfile

File created at /root

En esta sección hemos cubierto las tareas de administración de sistemas básicas y más comunes relacionadas a SELinux. Existen recursos gratuitos que están disponibles en línea para ítems avanzados de SELinux, los cuales incluyen (documentación disponible en inglés):

• Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide (https://access.redhat.com/ documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/)
• Red Hat Enterprise Linux 6 Security-Enhanced Linux (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/)

AppArmor es una alternativa LSM a SELinux. El soporte para ésta fue incorporado en el kernel Linux desde 2006. Ha sido usado por SUSE, Ubuntu y otras distribuciones.

AppArmor:

• Provee Control de Acceso Obligatorio (MAC).
• Habilita a administradores a asociar un perfil de seguridad a un programa, lo cual restringe sus capacidades.
• Es considerado más fácil de usar (por algunos, pero no todos) que SELinux.
• Se considera como neutral al sistema de archivos (no requiere etiquetas de seguridad).

AppArmor complementa el modelo tradicional de Control de Acceso Discrecional de UNIX (DAC) al proveer Control de Acceso Obligatorio (MAC).

De forma adicional a la capacidad de especificar perfiles de forma manual, AppArmor incluye un modo de aprendizaje, en el cual las violaciones al perfil son registradas, pero no prevenidas. Este registro puede ser convertido en un perfil, basado en el comportamiento típico del programa.

¿Cuál de las sentencias de a continuación describe mejor las diferencias entre los modos Permissive y Enforcing de SELinux?

El modo Enforcing de SELinux restringe qué procesos pueden ser accedidos, pero no tiene efectos en los puertos de red.

El modo Enforcing de SELinux deniega acceso a todo pero lo permite a aquello que se ha habilitado de forma explícita.

Los modos Enforcing y Permissive de SELinux son similares, pero el modo Permissive registra los errores.

El modo Permissive de SELinux deniega acceso a todo pero lo permite a aquello que se ha habilitado de forma explícita.

¿Qué herramienta de SELinux se usa para restablecer el contexto de un archivo para que coincida con el contexto del directorio actual?

• Laboratorio 19.1

Actualmente usted debería ser capaz de:

• Comprender cómo funciona y se implementa la infraestructura de los Módulos de Seguridad de Linux.
• Listar las diversas implementaciones disponibles de LSM.
• Describir las principales características de SELinux.
• Explicar los diversos modos y políticas disponibles.
• Comprender la importancia de los contextos, cómo obtenerlos y configurarlos.
• Cómo usar las herramientas importantes de SELinux.

Un proceso es la encarnación de una aplicación en ejecución que puede o no consistir de varias hebras. Los procesos tienen atributos y permisos bien definidos. Tienen que estar en uno de un número de procesos enumerados; los más comunes son running (corriendo) o sleeping (durmiendo). Es importante saber cuándo un proceso está corriendo en modo usuario con privilegios limitados o en modo kernel, con privilegios extendidos, incluyendo un acceso más directo al hardware. Hay diversas formas de crear un proceso hijo y tanto configurar como modificar sus prioridades.

Al final de este capítulo usted debería ser capaz de:

• Describir un proceso y los recursos asociados a él.
• Distinguir entre procesos, programas y hebras.
• Comprender los atributos de procesos, permisos y estados.
• Saber la diferencia entre la ejecución de un programa en modo usuario y kernel.
• Describir los procesos demonio (daemon).
• Comprender cómo se crean los procesos nuevos.
• Usar nice y renice para configurar y modificar las prioridades.

Un proceso es un programa en ejecución y los recursos asociados, incluyendo el ambiente, archivos abiertos, manejadores de señales, etc. El mismo programa puede ser ejecutado más de una vez en forma simultánea y por lo tanto es responsable de múltiples procesos.

Al mismo tiempo, dos o más tareas, o hebras de ejecución, pueden compartir diversos recursos, como los espacios completos de memoria (o solo áreas de memoria en particular), archivos abiertos. etc. Cuando hay cualquier circunstancia en la cual se comparten recursos, hablamos de un proceso multihebra.

En otros sistemas operativos puede haber una gran diferencia entre procesos pesados y ligeros (full heavy weight processes/light weight); en forma estricta, los procesos pesados pueden incluir procesos livianos, o solo uno de ellos.

En Linux la situación es bastante diferente. Cada hebra de ejecución se considera individualmente, la diferencia entre un proceso pesado y ligero tiene relación solamente con el uso de recursos compartidos y con la velocidad algo más rápida en la conmutación de contextos entre hebras en ejecución.

A diferencia de otros sistemas operativos, Linux siempre ha hecho un trabajo excepcionalmente rápido al crear, destruir y conmutar entre procesos. Por lo tanto el modelo adoptado para aplicaciones de multihebra se asemeja a procesos múltiples; cada hebra se programa individualmente, como si fuera un proceso independiente normal. Esto se realiza en vez de involucrar más niveles de complejidad como tener un método por separado para la programación de las hebras de un proceso, como también tener método de programación entre diferentes procesos.

Al mismo tiempo, Linux respeta el POSIX y otros estándares de multihebra; por ejemplo, cada hebra devuelve el mismo ID de proceso (llamado internamente como ID de grupo de hebra), mientras que devuelve un ID de hebra distinta (llamado internamente como el ID de proceso). Esto puede conducir a los desarrolladores a una confusión, pero debería ser transparente a los administradores.

El primer proceso de usuario en el sistema es init, el cual tiene ID = 1. Este se inicia tan pronto como el kernel ha sido inicializado y se montado el sistema de archivos raíz.

init se ejecutará hasta que el sistema se apague; este será el último proceso de usuario que será terminado en ese punto. Este sirve como el padre ancestral de todos los demás procesos de usuario, tanto directa como indirectamente.

Un proceso es una instancia de un programa en ejecución. Puede estar en diversos estados, tales como running (en ejecución) o sleeping (durmiendo). Cada proceso tiene un pid (Process ID), un ppid (Parent Process ID) y un pgid (Process Group ID). Adicionalmente, cada proceso tiene un código de programa, datos, variables, descriptores de archivos y un ambiente.

init es generalmente el primer proceso de usuario que se ejecuta en el sistema, y por lo tanto es el antecesor de todos los procesos subsecuentes, con la excepción de aquellos que han sido iniciados directamente por el kernel (los cuales se muestran con [] alrededor del nombre en un listado de ps).

Si el proceso padre muere antes que el hijo, el ppid del hijo se configura en 1; es decir, el proceso es adoptado por init. Nota: en sistemas Linux recientes que usan systemd, el ppid será configurado en 2, lo cual corresponde a una hebra interna del kernel conocida como kthreadd, el que ha asumido de init el rol de adopción de los hijos huérfanos.

Un proceso hijo que termina su ejecución (ya sea normal o anormalente) antes que su padre, el cual no esperó por este ni examinó su código de salida, se conoce como un proceso zombie (o difunto). Los procesos zombies liberan prácticamente todos los recursos y se mantienen en ese estado solo para transmitir su estado de salida. Una función del proceso init consiste en verificar los hijos adoptivos y dejar que mueran de forma adecuada aquellos que ya han terminado. Por lo anterior, a veces se le denomina el asesino de zombies, o de forma más sombría, el segador de niños.

Los procesos son controlados por la programación de los mismos, lo cual es completamente preferente. Solo el kernel tiene el derecho de preferencia sobre un proceso, algo que el resto de los procesos no pueden hacerse entre ellos.

Por razones históricas, el PID más grande ha sido limitado a un número de 16 bit, el cual corresponde a 32768. Es posible modificar este valor cambiando /proc/sys/kernel/pid_max, ya que el valor por defecto puede ser inadecuado para servidores más grandes. A medida en la que los procesos son creados, eventualmente alcanzarán el pid_max, punto en el cual comenzarán de nuevo en PID = 300.

Todos los procesos tienen ciertos atributos:

• El programa que está siendo ejecutado
• Contexto (estado)
• Permisos
• Recursos asociados.

Cada proceso ejecuta algún programa. En cualquier momento el proceso puede tomar una snapshot de sí mismo a través de la captura del estado de los registros de la CPU, dónde se está ejecutando, qué hay en la memoria del proceso y alguna otra información. Esto es el contexto del proceso.

Ya que los procesos pueden ser agendados para entrar y salir del tiempo compartido de CPU con otros (o a veces tienen que ser puestos a dormir mientras esperan que alguna condición se cumpla, tal como una petición de usuario o datos que están por llegar), es posible almacenar el contexto completo cuando cambia la condición del proceso y se restablece su ejecución. Lo anterior es crítico para que el kernel sea capaz de cambiar al contexto que se requiera en un instante determinado.

ulimit está construido sobre la base de un comando bash, el cual despliega o restablece una serie de límites de recursos asociados con procesos corriendo bajo una shell. Si se ejecuta con el argumento -a muestra lo siguiente:

$ ulimit -a

core file size             (blocks, -c) 0
data seg size              (kbytes, -d) unlimited
scheduling priority                (-e) 0
file size                  (blocks, -f) unlimited
pending signals                    (-i) 31843
max locked memory          (kbytes, -l) 64
max memory size            (kbytes, -m) unlimited
open files                         (-n) 1024
pipe size               (512 bytes, -p) 8
POSIX message queues        (bytes, -q) 819200
real-time priority                 (-r) 0
stack size                (kbytes,  -s) 8192
cpu time                  (seconds, -t) unlimited
max user processes                 (-u) 4096
virtual memory             (kbytes, -v) unlimited
file locks                         (-x) unlimited

Un administrador de sistemas podría necesitar cambiar alguno de estos valores en una u otra dirección:

• Para restringir las capacidades de tal forma que un usuario y/o proceso no pueda acaparar los recursos del sistema, tales como memoria, tiempo de cpu o el número máximo de procesos en el sistema.
• Para ampliar las capacidades de tal forma que un proceso no esté limitado en sus recursos; por ejemplo, para un servidor que maneja muchos clientes el valor por defecto de 1024 archivos abiertos podría hacer que su trabajo sea imposible de realizar.

Hay dos tipos de límites:

• Hard: El valor máximo, que solo el usuario root puede configurar, al que un usuario puede elevar el límite de recursos.
• Soft: El valor del límite actual, el cual un usuario puede modificar, pero que no puede exceder el límite hard.

Es posible configurar cualquier límite en particular haciendo lo siguiente:

$ ulimit [options] [limit]

como en

$ ulimit -n 1600

lo cual aumentaría el número máximo de descriptores de archivos a 1600.

Tenga en cuenta que los cambios afectarán solamente a la shell actual. Para que los cambios sean efectivos para todos los usuarios logueados, es necesario modificar /etc/security/limits.conf, un archivo muy bien autodocumentado, y luego reiniciar.

Cada proceso tiene permisos basados en el usuario específico que lo invocó. Adicionalmente, puede tener permisos basados en el usuario dueño del archivo del programa.

Tal como se comentó en la sección de seguridad local, los programas que están marcados con una s en el bit de ejecución tienen un user id efectivo diferente al de su usuario real. Estos se conocen como programas setuid. Se ejecutan con el user id del usuario que es dueño del programa; los programas que no tienen setuid definidos se ejecutan con los permisos del usuario que los corre. Los programas setuid de los cuales root es dueño tienen el potencial de ser un problema de seguridad conocido.

La herramienta passwd es un ejemplo de un programa setuid. Cualquier usuario puede ejecutarlo. Cuando un usuario ejecuta este programa, el proceso debe correr con permisos de root para poder actualizar los archivos restringidos de escritura /etc/passwd y /etc/shadow, en donde se mantienen las contraseñas de usuario.

Los procesos pueden estar en uno de varios estados posibles. Los principales son los siguientes:

• En ejecución:
  El proceso está siendo ejecutado actualmente ya sea en una CPU, o núcleo de CPU o en la cola de ejecución, esperando una nueva tajada de tiempo. Se reanudará cuando el planificador decide que merece utilizar la CPU, o cuando otra CPU queda libre y el planificador migra el proceso a esa CPU.
• Durmiendo (es decir, esperando):
  El proceso está esperando una solicitud (generalmente E/S) que se realizó y que no puede continuar hasta que se complete. Cuando la petición se ha completado, el kernel despertará el proceso y lo pondrá de vuelta en la cola de ejecución, y se le otorgará una tajada de tiempo en una CPU cuando el planificador decida hacerlo.
• Detenido:
  El proceso ha sido suspendido. Este estado se experimenta comúnmente cuando un programador quiere examinar la memoria del programa en ejecución, los registros de la CPU, banderas u otros atributos. Una vez que esto se ha realizado el proceso podría ser reanudado. Esto generalmente se realiza cuando el proceso está siendo ejecutado desde un depurador o el usuario teclea Ctrl-Z.
• Zombie:
  El proceso entra en este estado cuando termina su ejecución y ningún otro proceso (generalmente el padre) ha inquirido acerca de su estado de salida. Tales procesos también se denominan difuntos. Un proceso zombie ha liberado todos sus recursos con excepción de su estado de salida y su entrada en la tabla de procesos. Si el padre de cualquier proceso muere, el proceso es adoptado por init (PID=1) o kthreadd (PID=2).

En un momento dado un proceso (o cualquier hilo en particular de un proceso multihebra) puede ser ejecutado ya sea en modo usuario o modo sistema, el cual es llamado generalmente modo kernel por los desarrolladores del kernel.

Las instrucciones que pueden ser ejecutadas dependen del modo, el cual se aplica a nivel de hardware, no de software.

El modo no es un estado del sistema; es un estado del procesador en un sistema multinúcleo o multi-CPU, en donde cada unidad puede estar en su estado individual.

En la jerga de Intel, el modo usuario se denomina Ring 3, y el modo de sistema, Ring 0.

Con la excepción de cuando se ejecuta una llamada al sistema (lo cual se describirá en la sección siguiente), los procesos se ejecutan en modo usuario, donde tienen menos privilegios que en modo kernel.

Cuando un proceso se inicia, es aislado en su propio espacio de usuario para protegerlo de otros procesos. Esto promueve la seguridad y crea una estabilidad mayor. A veces esto se denomina aislación de recursos del proceso.

Cada proceso que se ejecuta en modo usuario tiene su propio espacio de memoria, partes del cual pueden ser compartidos con otros procesos; excepto para los segmentos de memoria compartida, un proceso de usuario no puede leer desde o escribir hacia el espacio de memoria de cualquier otro proceso.

Incluso un proceso ejecutado por el usuario root o un programa con setuid se ejecuta en modo usuario, excepto cuando realiza una llamada al sistema, caso en el cual tiene una capacidad limitada para acceder al hardware.

En modo kernel (de sistema) la CPU tiene acceso completo a todo el hardware en el sistema, incluyendo periféricos, memoria, discos, etc. Si una aplicación necesita acceso a estos recursos debe realizar una llamada al sistema, lo cual causa un cambio de contexto desde modo usuario a modo kernel. Este procedimiento se debe realizar cuando se lee y escribe archivos, se crean procesos nuevos, etc.

El código de las aplicaciones nunca se ejecuta en modo kernel, solo las llamadas al sistema en sí, lo cual corresponde a código del kernel. Cuando la llamada al sistema está completa, se devuelve un valor y el proceso vuelve a modo usuario con un cambio de contexto en el sentido contrario.

Hay oportunidades en las que el sistema está en modo kernel y no tiene relación con los procesos, tales como manejo de interrupciones de hardware, ejecutar las rutinas del planificador y otras tareas administrativas del sistema.

Un demonio es un proceso que se ejecuta en segundo plano, cuyo único propósito es proveer algún servicio específico a los usuarios del sistema. Los demonios:

• Pueden ser muy eficientes debido a que funcionan solo cuando es necesario.
• Muchos de ellos se inician en el arranque.
• Sus nombres a menudo (aunque no en todos los casos) terminan con d.
• Algunos ejemplos incluyen httpd y udevd.
• Los demonios pueden responder a eventos externos (udevd) o a tiempo transcurrido (crond).
• Generalmente no tienen una terminal de control ni dispositivos estándar de entrada/salida.
• A veces proporcionan un mejor control de la seguridad.

Cuando se usa SysVinit, los scripts en el directorio /etc/init.d inician varios demonios del sistema. Estos scripts invocan comandos como argumentos de una función de shell llamada daemon, definida en el archivo /etc/init.d/functions.

Para ver un ejemplo de cómo se hace esto, mire el script del servicio httpd en el directorio /etc/init.d.

Los sistemas que usan systemd utilizan métodos similares para los demonios.

No todos los procesos son creados (o forked) a raíz de los procesos padre del usuario. El kernel Linux crea directamente dos tipos de procesos por iniciativa propia. Estos son:

• Procesos internos del kernel:
  Estos se ocupan de tareas de mantención, tales como asegurar que los buffers fluyen hacia los discos, que la carga se equilibra de manera uniforme en las diferentes CPUs, que los controladores de dispositivos se hacen cargo del trabajo que ha sido encolado para ellos, etc. Estos procesos a se ejecutan mientras el sistema está corriendo y generalmente están durmiendo, a menos de que tengan algo específico que realizar.
• Procesos externos de usuario:
  Estos son procesos que corren en espacio como las aplicaciones normales, pero que son iniciados por el kernel. Hay muy pocos procesos de este tipo y generalmente tienen una vida corta.

Es fácil ver los procesos de este tipo; cuando se ejecuta el siguiente comando

$ ps -elf

se listan todos los procesos en el sistema y se muestran los IDs de los procesos padres; todos los que tienen PPID = 2 se refieren a kthreadd, el hilo del kernel, cuyo trabajo es crear tales procesos. Los nombres de estos procesos estarán encapsulados en paréntesis cuadrados, como [ksoftirqd/0], por ejemplo.

Un sistema Linux promedio está constantemente creando procesos nuevos. A menudo esto se denomina forking; el proceso original padre continúa ejecutándose mientras que el proceso hijo recién creado se inicia.

Cuando la mayoría de los computadores tenían procesadores individuales solamente, generalmente eran configurados para que el padre realizara una pausa inicial mientras que el hijo se iniciaba; hay una expresión de UNIX que dice "Los niños son lo primero". Sin embargo, con sistemas modernos multi CPU ambos correrán simultáneamente en diferentes CPUs.

A menudo, en vez de un fork, se sigue con un exec, en donde el proceso padre termina y el proceso hijo hereda el ID del proceso padre. Los términos fork y exec se usan tan a menudo que la gente piensa que son la misma palabra.

Los sistemas UNIX antiguos a menudo usan un programa llamado spawn, el cual es similar en diversas formas a fork y exec, pero difiere en algunos detalles. No es parte del estándard POSIX ni de Linux.

Para tener una idea de cómo un proceso podría iniciarse, considera un servidor web que maneja muchos clientes. El servidor web puede lanzar un proceso nuevo cada vez que una conexión nueva se hace a través de un cliente. Por otro lado, podría iniciar simplemente un nuevo hilo como parte del mismo proceso; en Linux realmente no existe mucha diferencia en el aspecto técnico entre crear un proceso completo o solo un hilo nuevo, ya que cada mecanismo toma aproximadamente el mismo tiempo y usa una cantidad similar de recursos.

Otro ejemplo es el demonio sshd: este es iniciado cuando el proceso init ejecuta el script de inicio sshd, el que a su vez es responsable de iniciar el demonio sshd. Este proceso demonio escucha solicitudes ssh de usuarios remotos.

Cuando se recibe una solicitud, sshd crea una copia nueva de sí mismo para atender el requerimiento de servicio. Cada usuario remoto obtiene su propia copia del demonio sshd que está en ejecución, para atender su conexión remota. El proceso sshd inciará el programa login para validar el usuario remoto. Si la autenticación es exitosa, el proceso login hará un fork de shell (por ejemplo, bash) para interpretar los comandos de usuario, y así sucesivamente.

¿Qué sucede cuando un usuario ejecuta un comando en un intérprete de shell, tal como bash?

• Un proceso nuevo se crea, como un fork desde la shell de inicio de sesión del usuario.
• Una llamada al sistema de espera pone a dormir el proceso de la shell padre.
• El comando se carga en el espacio del proceso hijo a través de la llamada al sistema exec. En otras palabras, el código del comando reemplaza el programa bash en el espacio de memoria del proceso hijo.
• El comando completa su ejecución y el proceso hijo muere a través de la llamada al sistema de salida.
• La shell padre se despierta nuevamente por la muerte del proceso hijo y procede a crear un nuevo intérprete de comandos. Entonces la shell padre espera por la próxima solicitud de comando desde el usuario, momento en el cual el ciclo se repetirá.

Si un comando se ejecuta en segundo plano (agregando un signo & al final de la línea de comandos), la shell padre se salta la solicitud de espera y queda libre para crear una nueva shell inmediatamente, permitiendo que el proceso en segundo plano se ejecute en paralelo. Por otro lado, para las solicitudes de primer plano la shell espera hasta que el proceso hijo se ha completado o es detenido a través de una señal.

Algunos comandos de shell (tales como echo y kill) están construidos en la shell misma y no implican la carga de archivos de programa. Para la ejecución de esos comandos no se utiliza fork ni exec.

La prioridad de los procesos puede ser controlada a través de los comandos nice y renice. Desde los primeros días de UNIX la idea ha sido que el proceso nice disminuya su prioridad para cedérsela de los demás. Por lo tanto, a medida en que nice es mayor, la prioridad es menor.

El rango de nice va desde -20 (la prioridad más alta) a +19 (la prioridad más baja). La forma normal de ejecutar nice es la siguiente:

$ nice -n 5 command [ARGS]

lo cual aumentaría nice en 5. Esto es equivalente a hacer lo siguiente:

$ nice -5 command [ARGS]

Si usted no provee un valor para nice, se utilizará el predeterminado, el cual consiste en incrementarlo en 10. Si no da ningún argumento se informará del valor actual. Por ejemplo:

$ nice

0

$ nice cat &

[1] 24908

$ ps -l

F S UID   PID  PPID C PRI NI ADDR SZ WCHAN  TTY          TIME CMD
0 S 500  4670  4603 0 80   0 - 16618 wait   pts/0    00:00:00 bash
0 S 500 24855  4670 0 80   0 - 16560 wait   pts/0    00:00:00 bash
0 T 500 24908 24855 0 90  10 - 14738 signal pts/0    00:00:00 cat
0 R 500 24909 24855 0 80   0 - 15887 -      pts/0    00:00:00 ps

Tenga en cuenta que al aumentar el valor de nice de un proceso no significa que este no se ejecutará; incluso podría obtener todo el tiempo de la CPU si no hay nada con lo cual competir.

Si usted provee un gran incremento o decremento que sale del rango -20 a 19, el valor de incremento será truncado.

Por defecto solo un superusuario puede disminuir el valor de nice, es decir, incrementar la prioridad. Sin embargo es posible darle a los usuarios normales la habilidad de disminuir el valor de nice para sus procesos, en un rango predeterminado, lo cual se realiza editando el archivo /etc/security/limits.conf.

Para cambiar el valor de nice de un proceso que está en ejecución, usamos el comando renice, así:

$ renice +3 13848

lo cual incrementará en valor de nice en 3, del proceso con pid = 13848. Puede hacerlo con más de un proceso a la vez y hay algunas otras opciones interesantes que puede ver con man renice.

Los programas están construidos usando bibliotecas de código, desarrolladas con múltiples propósitos, las cuales son reutilizadas en diversos contextos.

Hay dos tipos de bibliotecas:

• Estáticas
  El código para las funciones de la biblioteca se inserta en el programa en el momento de la compilación, de tal forma que no cambia después de eso, incluso si la biblioteca es actualizada.
• Compartidas
  El código para las funciones de la biblioteca se carga en el programa en tiempo de ejecución, y si la biblioteca se cambia en un momento posterior, el programa en ejecución corre con las modificaciones que se han hecho a la biblioteca.

El uso de bibliotecas compartidas es más eficiente porque pueden ser utilizadas por muchas aplicaciones a la vez. El uso de la memoria, el tamaño de los ejecutables y el tiempo de carga de la aplicación se reducen.

Las bibliotecas compartidas también se denominan DLLs (Dynamic Link Library).

Las bibliotecas compartidas necesitan ser versionadas cuidadosamente. Si hay un cambio importante en la biblioteca y un programa no está equipado para manejarlo, es posible esperar que ocurran problemas serios. Esto se suele conocer como Infierno de las DLL.

Por lo tanto, los programas pueden solicitar una versión específica de la biblioteca, en vez de la última disponible en el sistema. Sin embargo, generalmente el programa usará la versión menor en su última actualización disponible.

Algunos proveedores de aplicaciones usan bibliotecas estáticas embebidas en el programa para evitar estos problemas. Sin embargo, si hay mejoras, bugs y agujeros de seguridad que han sido resueltos en las bibliotecas, no van a estar disponibles en las aplicaciones en un tiempo adecuado.

Shared libraries have the extension .so. Typically the full name is something like libc.so.N where N is a major version number.Algunas librerías tienen la extensión .so. Generalmente el nombre completo es algo como libc.so.N, en donde N es un número de una versión principal.

En Linux las bibliotecas compartidas están versionadas cuidadosamente. Por ejemplo:

c7:/usr/lib64>ls -lF libgdbm.so*

lrwxrwxrwx 1 root root 16 Apr 9 2015 libgdbm.so -> libgdbm.so.4.0.0*
lrwxrwxrwx 1 root root 16 Apr 9 2015 libgdbm.so.4 -> libgdbm.so.4.0.0*
-rwxr-xr-x 1 root root 36720 Jan 24 2014 libgdbm.so.4.0.0*

c7:/usr/lib64>

por lo que un programa que solicita libgdm obtiene libgdm.so y las que se especifican como versiones principales y menores.

Un programa que usa bibliotecas compartidas debe ser capaz de encontrarlas en tiempo de ejecución.

ldd puede usarse para determinar qué bibliotecas compartidas requiere un ejecutable. Muestra el nombre de la biblioteca y a qué archivo apunta:

$ ldd /usr/bin/vi

                linux-vdso.so.1 => (0x00007fffe55dc000)
                libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f0202cc0000)
                libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f0202a96000)
                libacl.so.1 => /lib64/libacl.so.1 (0x00007f020288c000)
                libc.so.6 => /lib64/libc.so.6 (0x00007f02024cb000)
                libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f020226a000)
                liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f0202044000)
                libdl.so.2 => /lib64/libdl.so.2 (0x00007f0201e40000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f0202f01000)
                libattr.so.1 => /lib64/libattr.so.1 (0x00007f0201c3b000)
                libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0201a1e000)

ldconfig se ejecuta generalmente en el arranque del sistema (aunque puede ser ejecutado en cualquier momento), y usa el archivo /etc/ld.so.conf, el cual lista los directorios en los que se buscarán bibliotecas compartidas. ldconfig debe ejecutarse como root y las bibliotecas compartidas deberían ser almacenadas solamente en directorios del sistema, en donde están seguras y son útiles.

Además de buscar la base de datos construida por ldconfig, el enlazador buscará primero cualquier directorio especificado en la variable de ambiente LD_LIBRARY_PATH, una lista de directorios separados por dos puntos, en la variable PATH. Así es que es posible hacer:

$ LD_LIBRARY_PATH=$HOME/foo/lib
$ foo [args]

o

$ LD_LIBRARY_PATH=$HOME/foo/lib foo [args]

es el proceso con PID =1 y es iniciado por el kernel

durante el .

¿Cuál es el comando para cambiar el número máximo permitido de archivos abiertos?

• Laboratorio 20.1
• Laboratorio 20.2

Actualmente usted debería ser capaz de:

• Describir un proceso y los recursos asociados a él.
• Distinguir entre procesos, programas y hebras.
• Comprender los atributos de procesos, permisos y estados.
• Saber la diferencia entre la ejecución de un programa en modo usuario y kernel.
• Describir los procesos demonio (daemon).
• Comprender cómo se crean los procesos nuevos.
• Usar nice y renice para configurar y modificar las prioridades.

Las señales se usan para emitir notificaciones para que los procesos tomen acción en respuesta a eventos que generalmente son impredecibles. Estos pueden ser generados desde dentro de un proceso, o desde eventos externos y otros procesos. Muchas señales son fatales y resultan en el término del proceso. Sin embargo, la muerte de los procesos se puede evitar si los desarrolladores del programa deciden manejar ciertas señales de finalización.

Por otro lado, muchas señales son más benignas y son informativas solamente o solicitan otro tipo de acciones. Es posible enviar señales (incluyendo aquellas que inducen a la finalización de un proceso) desde la línea de comandos usando kill, killall y pkill.

Al final de este capítulo usted debería ser capaz de:

• Explicar qué son las señales y cómo se usan.
• Conocer los diferentes tipos de señales que están disponible en Linux.
• Usar kill, killall and pkill para enviar señales desde la línea de comandos.

Las señales son uno de los métodos más antiguos de Comunicación Inter-Procesos (IPC) y se usan para notificar procesos acerca de eventos asincrónicos (o excepciones).

Por asincrónico entendemos que el proceso receptor de la señal puede:

• No esperar que ocurra el evento.
• Esperar el evento, pero no saber en qué momento va a ocurrir.

Por ejemplo, si un usuario decide terminar un programa en ejecución, podría enviar una señal al proceso a través del kernel para interrumpir y finalizar el proceso.

Hay dos vías a través de las cuales se envían señales a los procesos:

• Desde el kernel a un proceso de usuario como resultado de una excepción o de un error de programación.
• Desde un proceso de usuario (usando una llamada al sistema) al kernel, el cual la enviará a un proceso de usuario. El proceso que envía la señal puede ser el mismo que la reciba de vuelta.

Las señales solamente pueden enviarse entre procesos de propiedad del mismo usuario, o desde un proceso del superusuario a cualquier proceso.

Cuando un proceso recibe una señal, lo que hará a continuación depende de la forma en la cual el programa está escrito. Puede tomar acciones específicas, codificadas en el programa para manipular la señal, o solo responder de acuerdo a los valores por defecto en el sistema. Dos señales (SIGKILL y SIGSTOP, que se mencionarán en seguida) no pueden ser manipuladas y siempre finalizarán el programa.

Hay una variedad de tipos de señales, y la señal en particular que es enviada indica el tipo de evento (o excepción) ocurrida. Generalmente las señales se usan para manejar dos cosas:

1. Excepciones detectadas por el hardware (tal como una referencia ilegal a memoria).
2. Excepciones generadas por el ambiente (tal como la finalización prematura de un proceso desde la terminal del usuario).

Para ver una lista de las señales en Linux, junto con los números correspondientes, haga lo siguiente:

$ kill -l

  1) SIGHUP       2) SIGINT        3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS        8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2      13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD      18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU      23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF      28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN     35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5   40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10  45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15  50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10  55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5   60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

Las señales de SIGRTMIN se denominan como de tiempo real y son una adición relativamente reciente. No tienen un propósito predefinido y difieren de forma importante en algunos aspectos con relación a las señales normales; pueden ser encoladas y son manejadas en orden FIFO (First In First Out).

El significado implícito en el tipo de señal indica qué evento causó que fuera enviada. Mientras los usuarios pueden explícitamente enviar cualquier tipo de señal a uno de sus procesos, el significado implícito podría no estar relacionado al número o tipo de la señal, y puede usarse en cualquier forma que el proceso desea.

man 7 signal le dará mayor información al respecto.

Un proceso no puede enviar una señal directamente a otro proceso; este debe pedirle al kernel que envíe la señal mediante la ejecución de una llamada al sistema. Los usuarios (incluyendo el superusuario) pueden enviar señales a otros procesos desde la línea de comandos o scripts usando kill, tal como se muestra a continuación:

$ kill 1991
$ kill -9 1991
$ kill -SIGKILL 1991

en el comando anterior enviamos una señal al proceso con PID = 1991. Si no se provee un número de señal (como en el primer ejemplo), el valor por defecto a enviar es SIGTERM (15), una señal de finalización que puede ser manipulada; el programa puede tomar una acción evasiva o limpiarse a sí mismo en vez de finalizar inmediatamente. Si esta señal es ignorada, el usuario puede enviar una SIGKILL (9), la cual no puede ser ignorada.

El nombre kill es un nombre realmente malo, el cual sobrevive por razones históricas. Aunque a menudo se utiliza para matar (terminar) procesos, la función real del comando es enviar cualquier y todas las señales a los procesos, incluso a los que son benignos y totalmente informativos.

killall termina todos los procesos con un nombre dado, en el caso que el usuario tenga los permisos necesarios. Usa un nombre de comando en vez de un ID de proceso y puede ser ejecutado así:

$ killall bash
$ killall -9 bash
$ killall -SIGKILL bash

pkill envía una señal a un proceso utilizando un criterio de selección:

$ pkill [-signal] [options] [pattern]

Por ejemplo:

$ pkill -u libby foobar

terminará todos los procesos de libby que se llamen foobar.

Otro ejemplo:

$ pkill -HUP rsyslogd

hace que rsyslog relea su archivo de configuración.

¿Cuáles de las siguientes afirmaciones son ciertas?

• kill, killall y pkill aceptan un nombre de proceso como parámetro.
• Pasar -9 o -SIGKILL como parámetro a kill tiene el mismo efecto en el proceso objetivo.
• Si no se especifica, kill enviará la señal por defecto SIGTERM.
• Presionar Ctrl+Z o usar kill -SIGTSTP sobre un proceso en ejecución en una terminal tiene el mismo efecto.

• Laboratorio 21.1 (código fuente: signals.c)

Actualmente usted debería ser capaz de:

• Explicar qué son las señales y cómo se usan.
• Conocer los diferentes tipos de señales que están disponibles en Linux.
• Usar kill, killall and pkill para enviar señales desde la línea de comandos.

Linux tiene una amplia variedad disponible de herramientas de monitoreo del sistema, incluyendo top, ps y sar. La mayoría de estas herramientas hacen un uso extensivo de los pseudosistemas de archivos montados en /proc y /sys. Si bien es cierto que hay interfaces gráficas (dependientes de la distribución), nos concentraremos en los métodos de la línea de comandos.

Al final de este capítulo usted debería ser capaz de:

• Reconocer y usar las herramientas disponibles de monitoreo del sistema.
• Usar los pseudosistemas de archivos /proc y /sys.
• Usar sar para obtener información de la actividad y rendimiento del sistema, para crear reportes en forma cómoda para su análisis.

Las distribuciones Linux vienen con diversas herramientas estándar instaladas por defecto para medir el rendimiento y visualizar el estado del sistema. Muchas de ellas provienen de otros sistemas operativos tipo UNIX, mientras que otras fueron desarrolladas específicamente para Linux.

La mayoría de estas herramientas hacen uso de pseudosistemas de archivos montados, especialmente /proc, y /sys de forma secundaria (los cuales discutimos anteriormente cuando tratamos los sistemas de archivos y configuración del kernel). En este capítulo trabajaremos con ambos.

Aunque existe una serie de monitores gráficos del sistema, los cuales esconden muchos detalles, en este curso consideraremos solamente las herramientas de la línea de comandos.

Antes de considerar algunas de las herramientas principales veremos un resumen clasificado por tipo; tenga en cuenta que algunas de las herramientas tienen dominios superpuestos de cobertura.

Los pseudosistemas de archivos /proc y /sys contienen bastante información acerca del sistema. Por otro lado, muchas de las entradas en estos árboles de directorios son escribibles y pueden usarse para cambiar el comportamiento del sistema; en la mayoría de los casos esto requiere del usuario root.

Estos son pseudosistemas de archivos porque existen totalmente en memoria; si usted revisa la partición del disco cuando el sistema no está en ejecución, se dará cuenta que solo hay un directorio vacío, el cual se usa como punto de montaje.

Por otra parte, la información que se despliega es obtenida solamente cuando se lee; no hay un sondeo constante o periódico para actualizar las entradas.

El pseudosistema de archivos /proc tiene una historia larga; tiene su origen en otras variantes de sistemas operativos tipo UNIX y en un comienzo fue desarrollado para desplegar información acerca de los procesos en el sistema, cada uno de los cuales tiene su propio directorio en /proc, con todas las características importantes de los procesos.

A través del tiempo creció para contener mucha información acerca de las propiedades del sistema, tales como interrupciones, memoria, red, etc, en una forma un tanto anárquica. Todavía es usado de forma extensiva y a menudo nos referiremos a él.

Echemos un vistazo a lo que hay en el pseudosistema de archivos /proc:

$ ls -F /proc

1/      11214/ 15887/ 19/    26/    3706/ 509/  614/ 7402/ asound/       modules
10/     12/ 15891/ 1929/  260/   3707/ 510/  619/ 741/  buddyinfo     mounts@
1017/   1284/  15896/ 1934/  26218/ 3708/ 511/  620/ 742/  bus/          mtrr
1018/   1290/  15899/ 1959/  264/   3709/ 512/  622/ 743/  cgroups       net@
1023/   13/    15905/ 19950/ 265/   3713/ 513/  623/ 744/  cmdline       pagetypeinfo
1031/   1301/  15909/ 2/     267/   3714/ 514/  625/ 761/  config.gz     partitions
10544/  14/    15912/ 2008/  268/   375/  515/  626/ 763/  consoles      sched_debug
10545/  1400/  15919/ 2079/  27/    396/  517/  641/ 7699/ cpuinfo       schedstat
1061/   1444/  15928/ 21/    28/    398/  519/  642/ 8/    crypto        scsi/
10671/  1452/  15938/ 22/    280/   414/  521/  644/ 8036/ devices       self@
10802/  1465/  15941/ 2298/  281/   42/   5302/ 645/ 8226/ diskstats     slabinfo
10803/  1484/  15944/ 23/    29/    43/   537/  648/ 824/  dma           softirqs
10911/  1490/  15957/ 237/   3/     4555/ 5376/ 649/ 8323/ driver/       stat
11/     1503/  15963/ 238/   30/    460/  538/  651/ 8435/ execdomains   swaps
11087/  15466/ 15966/ 239/   30170/ 480/  5503/ 652/ 8443/ fb            sys/
11089/  15471/ 15982/ 24/    31/    481/  5506/ 66/  8444/ filesystems   sysrq-trigger
11090/  15616/ 16/    240/   32/    482/  5515/ 67/  845/  fs/           sysvipc/
11103/  1563/  16016/ 241/   33/    484/  5516/ 68/  8479/ interrupts    timer_list
11104/  15632/ 16030/ 242/   34/    485/  5524/ 684/ 8594/ iomem         timer_stats
11105/  15642/ 16037/ 243/   35/    486/  5525/ 690/ 8633/ ioports       tty/
11123/  15650/ 16039/ 244/   3557/  489/  5530/ 697/ 8643/ irq/          uptime
11124/  15651/ 16065/ 245/   3558/  491/  5531/ 698/ 8644/ kallsyms      version
11125/  1570/  16066/ 246/   3560/  494/  5536/ 699/ 8726/ kcore         vmallocinfo
11126/  1571/  16071/ 247/   36/    496/  559/  7/   8903/ keys          vmnet/
11163/  15719/ 16073/ 248/   3687/  498/  560/  701/ 9/    key-users     vmstat
11165/  15723/ 16089/ 24819/ 3697/  5/    5645/ 709/ 9277/ kmsg          zoneinfo
11166/  15791/ 16112/ 24822/ 3698/  500/  5665/ 712/ 9284/ kpagecount
11187/  1582/  1621/  24823/ 3699/  501/  5678/ 714/ 9816/ kpageflags
11194/  15837/ 16477/ 24879/ 37/    502/  583/  715/ 9853/ latency_stats
11196/  15840/ 16515/ 257/   3702/  503/  584/  717/ 9871/ loadavg
11197/  15844/ 1654/  258/   3703/  504/  599/  718/ 988/  locks
11199/  15847/ 17/    259/   3704/  505/  600/  723/ 9885/ meminfo
11206/  15871/ 18/    2591/  3705/  507/  613/  727/ acpi/ misc

Primero vemos que hay un subdirectorio por cada proceso en el sistema, ya sea si están durmiendo, en ejecución o programados. Revisando uno al azar:

$ ls -lF /proc/16477

total 0
-r-------- 1 coop coop 0 Sep 10 18:11 auxv
-r--r--r-- 1 coop coop 0 Sep 10 12:28 cgroup
--w------- 1 coop coop 0 Sep 10 18:11 clear_refs
-r--r--r-- 1 coop coop 0 Sep 10 08:30 cmdline
-rw-r--r-- 1 coop coop 0 Sep 10 12:28 comm
-rw-r--r-- 1 coop coop 0 Sep 10 18:11 coredump_filter
-r--r--r-- 1 coop coop 0 Sep 10 18:11 cpuset
lrwxrwxrwx 1 coop coop 0 Sep 10 18:11 cwd -> /usr/local/coop7/
-r-------- 1 coop coop 0 Sep 10 18:11 environ
lrwxrwxrwx 1 coop coop 0 Sep 10 08:30 exe -> /usr/lib64/thunderbird/thunderbird*
dr-x------ 2 coop coop 0 Sep 10 08:30 fd/
dr-x------ 2 coop coop 0 Sep 10 18:11 fdinfo/
-rw-r--r-- 1 coop coop 0 Sep 10 18:11 gid_map
-r-------- 1 coop coop 0 Sep 10 18:11 io
-r--r--r-- 1 coop coop 0 Sep 10 18:11 latency
-r--r--r-- 1 coop coop 0 Sep 10 18:11 limits
-r--r--r-- 1 coop coop 0 Sep 10 08:30 maps
-rw------- 1 coop coop 0 Sep 10 18:11 mem
-r--r--r-- 1 coop coop 0 Sep 10 08:30 mountinfo
-r--r--r-- 1 coop coop 0 Sep 10 18:11 mounts
-r-------- 1 coop coop 0 Sep 10 18:11 mountstats
dr-xr-xr-x 4 coop coop 0 Sep 10 18:11 net/
dr-x--x--x 2 coop coop 0 Sep 10 18:11 ns/
-rw-r--r-- 1 coop coop 0 Sep 10 18:11 oom_adj
-r--r--r-- 1 coop coop 0 Sep 10 18:11 oom_score
-rw-r--r-- 1 coop coop 0 Sep 10 18:11 oom_score_adj
-r-------- 1 coop coop 0 Sep 10 18:11 pagemap
-r-------- 1 coop coop 0 Sep 10 18:11 personality
-rw-r--r-- 1 coop coop 0 Sep 10 18:11 projid_map
lrwxrwxrwx 1 coop coop 0 Sep 10 18:11 root -> //
-rw-r--r-- 1 coop coop 0 Sep 10 18:11 sched
-r--r--r-- 1 coop coop 0 Sep 10 18:11 schedstat
-r--r--r-- 1 coop coop 0 Sep 10 18:11 smaps
-r-------- 1 coop coop 0 Sep 10 18:11 stack
-r--r--r-- 1 coop coop 0 Sep 10 08:35 stat
-r--r--r-- 1 coop coop 0 Sep 10 16:59 statm
-r--r--r-- 1 coop coop 0 Sep 10 08:31 status
-r-------- 1 coop coop 0 Sep 10 18:11 syscall
dr-xr-xr-x 35 coop coop 0 Sep 10 10:10 task/
-rw-r--r-- 1 coop coop 0 Sep 10 18:11 uid_map
-r--r--r-- 1 coop coop 0 Sep 10 18:11 wchan

vemos que este corresponde al cliente de correo electrónico thunderbird. Este directorio está lleno de información, tanto acerca del estado y de los recursos que el proceso está usando. Por ejemplo:

$ cat /proc/16477/status

Name: thunderbird
State: S (sleeping)
Tgid: 16477
Ngid: 0
Pid: 16477
PPid: 15912
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
FDSize: 256
Groups: 500
VmPeak: 1262996 kB
VmSize: 1139452 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 241644 kB
VmRSS: 201404 kB
VmData: 435360 kB
VmStk: 224 kB
VmExe: 88 kB
VmLib: 89756 kB
VmPTE: 1488 kB
VmSwap: 0 kB
Threads: 33
SigQ: 1/31853
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000f800144ef
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 590633
nonvoluntary_ctxt_switches: 5881

Otras entradas proveen información de todo el sistema. Por ejemplo, las estadísticas de interrupciones se muestran aquí:

$ cat /proc/interrupts

                     CPU0        CPU1         CPU2        CPU3
  0:     127                0       0       0 IO-APIC-edge    timer
  1:   22610   26632   22019   24652 IO-APIC-edge    i8042
  8:       0       0       1       0 IO-APIC-edge    rtc0
  9:       0       0       0       0 IO-APIC-fasteoi acpi
 16:      10      13      13      11 IO-APIC-fasteoi uhci_hcd:usb3
 18:   81801   33810  269011   97396 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8,enp4s2
 19:       0       0       0       0 IO-APIC-fasteoi uhci_hcd:usb7
 21:       0       0       0       0 IO-APIC-fasteoi uhci_hcd:usb4
 23:  459503  414973 2294258 1886762 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6
 43: 7839477      12      17      14 PCI-MSI-edge    enp2s0
 44:   90833   73862  431567  197408 PCI-MSI-edge    ahci
 45: 2308942 2324143 2037740 2226651 PCI-MSI-edge    nouveau
 46:    1706    1853    1806    1740 PCI-MSI-edge    snd_hda_intel
NMI:    4021    3150    3201    3076 Non-maskable interrupts
LOC: 8186969 8028365 8257507 7848638 Local timer interrupts
SPU:       0       0       0       0 Spurious interrupts
PMI:    4021    3150    3201    3076 Performance monitoring interrupts
IWI:  455847  423644  402570  390176 IRQ work interrupts
RTR:       0       0       0       0 APIC ICR read retries
RES: 6489645 6430364 6430834 6271845 Rescheduling interrupts
CAL: 4816017 4550737 4171364 4829737 Function call interrupts
TLB:  909001 1140883  879189 1152043 TLB shootdowns
TRM:       0       0       0       0 Thermal event interrupts
THR:       0       0       0       0 Threshold APIC interrupts
MCE:       0       0       0       0 Machine check exceptions
MCP:     133     133     133     133 Machine check polls
ERR:       0
MIS:       0

Para cada interrupción vemos su tipo, cuántas veces ha sido manipulada en cada CPU y qué dispositivos están registrados para responder a ella. También obtenemos estadísticas globales.

La mayoría de los parámetros ajustables del sistema pueden encontrarse en el árbol de subdirectorios /proc/sys:

$ ls -F /proc/sys

total 0
dr-xr-xr-x 1 root root 0 Sep 10 18:17 abi/
dr-xr-xr-x 1 root root 0 Sep 10 18:17 debug/
dr-xr-xr-x 1 root root 0 Sep 10 15:53 dev/
dr-xr-xr-x 1 root root 0 Sep 10 02:14 fs/
dr-xr-xr-x 1 root root 0 Sep 10 02:14 kernel/
dr-xr-xr-x 1 root root 0 Sep 10 18:17 net/
dr-xr-xr-x 1 root root 0 Sep 10 16:10 vm/

Cada uno de estos subdirectorios contiene información como también controles que pueden ser ajustados (con cuidado):

• abi/
  Contiene archivos con información binaria de aplicaciones; raramente se usa.
• debug/
  Parámetros de depuración; por ahora solo un control de reportes de excepción.
• dev/
  Parámetros de dispositivo incluyendo subdirectorios para cdrom, scsi, raid y parport.
• fs/
  Parámetros de sistemas de archivos, incluyendo cuota, identificadores de archivos usados y máximos, información de inodos y directorios, etc.
• kernel/
  Parámetros del kernel. Hay muchas entradas importantes aquí.
• net/
  Parámetros de red. Hay subdirectorios para ipv4, netfilter, etc.
• vm/
  Parámetros de memoria virtual. Hay muchas entradas importantes aquí.

Ver y cambiar los parámetros puede ser realizarse con comandos simples. Por ejemplo, el número máximo de hilos permitidos en el sistema puede verse así:

$ ls -l /proc/sys/kernel/threads-max
$ cat /proc/sys/kernel/threads-max
129498

Entonces podemos modificar el valor y verificar que el cambio tuvo efecto:

$ sudo bash -c 'echo 100000 > /proc/sys/kernel/threads-max'
$ cat /proc/sys/kernel/threads-max
100000

Recuerde de la discusión acerca de sysctl que lo mismo se consigue con:

$ sudo sysctl kernel.threads-max=100000

Los usuarios normales pueden visualizar los valores, sin embargo para modificarlos se requiere de privilegios de superusuario.

El pseudosistema de archivos /sys es una parte integral de lo que se llama el Modelo Unificado de Dispositivos (Unified Device Model). Conceptualmente está basado en un árbol de dispositivos a través del cual se puede ir y ver los buses, dispositivos, controladores, etc. También contiene información que puede o no estar relacionada estrictamente a los dispositivos, tales como los módulos del kernel.

Tiene una estructura más definida que /proc. La mayoría de las entradas contienen solo una línea de texto, aunque existen excepciones, no llega a ser como su precedesor (/proc), el cual tiene entradas de múltiples líneas cuyo contenido exacto ha ido cambiando entre versiones del kernel. Por lo tanto, la interfaz de /sys es más estable hasta el momento.

Hay propiedades del sistema que tienen entradas tanto en /proc como en /sys; los ítems antiguos se están eliminando gradualmente con el fin de mantener una compatibilidad entre las utilidades de sistema usadas ampliamente.

El soporte para el sistema de archivos virtual sysfs está construido en todos los kernel modernos, y debería montarse bajo /sys. Sin embargo, el modelo unificado de dispositivos no requiere que sysfs sea montado para entrar en operación.

Echemos un vistazo a lo que podemos encontrar usando el kernel 3.18; advertimos que el diseño exacto de este sistema de archivos tiene una tendencia a cambiar. Al visualizar los directorios de nivel superior encontramos:

$ ls -F /sys

block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/

lo cual despliega la jerarquía básica de dispositivos. La implementación del modelos de dispositivos sysfs también incluye información que no está estrictamente relacionada a hardware.

Los dispositivos de red pueden examinarse con:

$ ls -lF /sys/class/net

total 0lrwxrwxrwx 1 root root 0 Apr 30 11:38 eth0 -> \
                                                                                                                   ../../devices/pci0000:00/0000:00:1c.5/0000:02:00.0/net/eth0/
lrwxrwxrwx 1 root root 0 Apr 30 11:38 eth1 -> \
                                                                           ../../devices/pci0000:00/0000:00:1e.0/0000:04:02.0/net/eth1/
lrwxrwxrwx 1 root root 0 Apr 30 06:38 lo -> \
 ../../devices/virtual/net/lo/

al mirar la primera tarjeta Ethernet obtenemos:

$ ls -l /sys/class/net/eth0/

total 0
-r--r--r-- 1 root root 4096 Apr 30 13:43 addr_assign_type
-r--r--r-- 1 root root 4096 Apr 30 11:38 address
-r--r--r-- 1 root root 4096 Apr 30 11:38 addr_len
-r--r--r-- 1 root root 4096 Apr 30 13:43 broadcast
-r--r--r-- 1 root root 4096 Apr 30 13:43 carrier
lrwxrwxrwx 1 root root    0 Apr 30 11:38 device -> ../../../0000:02:00.0
-r--r--r-- 1 root root 4096 Apr 30 13:43 dev_id
-r--r--r-- 1 root root 4096 Apr 30 13:43 dormant
-r--r--r-- 1 root root 4096 Apr 30 13:43 duplex
-rw-r--r-- 1 root root 4096 Apr 30 11:38 flags
-rw-r--r-- 1 root root 4096 Apr 30 13:43 ifalias
-r--r--r-- 1 root root 4096 Apr 30 11:38 ifindex
-r--r--r-- 1 root root 4096 Apr 30 13:43 iflink
-r--r--r-- 1 root root 4096 Apr 30 13:43 link_mode
-rw-r--r-- 1 root root 4096 Apr 30 13:43 mtu
-rw-r--r-- 1 root root 4096 Apr 30 13:43 netdev_group
-r--r--r-- 1 root root 4096 Apr 30 13:43 operstate
drwxr-xr-x 2 root root    0 Apr 30 13:43 power
drwxr-xr-x 4 root root    0 Apr 30 11:38 queues
-r--r--r-- 1 root root 4096 Apr 30 13:43 speed
drwxr-xr-x 2 root root    0 Apr 30 13:43 statistics
lrwxrwxrwx 1 root root    0 Apr 30 11:38 subsystem -> ../../../../../../class/net
-rw-r--r-- 1 root root 4096 Apr 30 13:43 tx_queue_len
-r--r--r-- 1 root root 4096 Apr 30 11:38 type
-rw-r--r-- 1 root root 4096 Apr 30 11:38 uevent

$ cat /sys/class/net/eth0/mtu

1500

La intención de sysfs es tener un valor de texto por línea, aunque no se espera que esto se aplique rigurosamente.

El dispositivo y controlador subyacente para la primera interfaz de red pueden encontrarse a través de device y de los enlaces simbólicos de driver (lo cual vamos a revisar pronto). Si vemos el directorio correspondiente a la primera tarjeta Ethernet veremos lo siguiente:

$ ls -l /sys/class/net/eth0/device/

total 0
-rw-r--r-- 1 root root   4096 Apr 30 13:47 broken_parity_status
-r--r--r-- 1 root root   4096 Apr 30 06:38 class
-rw-r--r-- 1 root root   4096 Apr 30 11:38 config
-r--r--r-- 1 root root   4096 Apr 30 13:47 consistent_dma_mask_bits
-r--r--r-- 1 root root   4096 Apr 30 11:38 device
-r--r--r-- 1 root root   4096 Apr 30 13:47 dma_mask_bits
lrwxrwxrwx 1 root root      0 Apr 30 11:38 driver -> ../../../../bus/pci/drivers/sky2/
-rw------- 1 root root   4096 Apr 30 13:47 enable
-r--r--r-- 1 root root   4096 Apr 30 11:38 irq
-r--r--r-- 1 root root   4096 Apr 30 13:47 local_cpulist
-r--r--r-- 1 root root   4096 Apr 30 11:38 local_cpus
-r--r--r-- 1 root root   4096 Apr 30 13:47 modalias
-rw-r--r-- 1 root root   4096 Apr 30 13:47 msi_bus
drwxr-xr-x 3 root root      0 Apr 30 13:47 msi_irqs/
drwxr-xr-x 3 root root      0 Apr 30 11:38 net/
drwxr-xr-x 2 root root      0 Apr 30 13:47 power/
--w--w---- 1 root root   4096 Apr 30 13:47 remove
--w--w---- 1 root root   4096 Apr 30 13:47 rescan
--w------- 1 root root   4096 Apr 30 13:47 reset
-r--r--r-- 1 root root   4096 Apr 30 13:45 resource
-rw------- 1 root root  16384 Apr 30 13:47 resource0
-rw------- 1 root root    256 Apr 30 13:47 resource2
-rw------- 1 root root 131072 Apr 30 13:47 rom
lrwxrwxrwx 1 root root      0 Apr 30 11:38 subsystem -> ../../../../bus/pci/
-r--r--r-- 1 root root   4096 Apr 30 11:38 subsystem_device
-r--r--r-- 1 root root   4096 Apr 30 11:38 subsystem_vendor
-rw-r--r-- 1 root root   4096 Apr 30 06:38 uevent
-r--r--r-- 1 root root   4096 Apr 30 11:38 vendor
-rw------- 1 root root  32768 Apr 30 13:47 vpd