Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

martes, 28 de abril de 2015

Systemd, el init del presente en el mundo Linux

Durante muchos años System V ha sido el init dominante que ha sido usado en una gran número de distribuciones y todo el mundo se ha acostumbrado a usar todas las ventajas que ofrece este estupendo sistema que cómo todo tenía sus pros y contras. Durante los últimos años otro init llamado systemd ha ido ganando terreno hasta el punto de que la mayoría de las distribuciones han empezado a implantarlo por defecto, cosa que se ha ganado tantos seguidores como detractores. Cierto es que que systemd ha desatado una gran polémica que ha hecho que mucha gente haya incurrido en numerosísimos debates, desde el propio Linus Tovarlds en su momento hasta una gran cantidad de usuarios que consideran que a pesar de que ofrece numerosas ventajas, el hecho de que este init tome el control de una gran cantidad de servicios (cosa que va en contra de la filosofía Unix la cual dice que un programa tiene que hacer una cosa en concreto y hacerla bien) y que éste haya sido impuesto prácticamente en todas las distribuciones libres ha hecho que este sea con diferencia el init más polémico en la historia del software libre hasta el momento.

Antes de continuar muchos probablemente os preguntéis: ¿Qué es un init? Un init es el primer proceso que se inicia la arrancar el sistema operativo, y el último que se para dentro de dicho sistema. Su objetivo es iniciar, controlar y parar el resto de servicios mediante diferentes comandos y/o scripts y es un servicios que siempre está activo en todo momento ya que tiene que gestionar los distintos cambios que puede haber en un servicio. Hasta el momento había diferentes init dependiendo del tipo de distribución (siendo System V el más común), pero ahora la gran mayoría a decidido adoptar uno en común: systemd.

Dejando de lado la polémica que ha desatado este cambio. La verdad es que para el usuario final no hay ninguna diferencia y cualquier tipo de diferencia que pueda notar debería ser para mejor ya que una de las ventajas principales que posee systemd es la aceleración del proceso de arranque; Pero para cualquiera que desee administrar o gestionar el sistema, encontrará algunos cambios de lo más interesantes que serían convenientes tener en cuenta. El init ofrece una gran variedad de opciones, algunas de ellas bastante rebuscadas, con lo que me enfocaré en aquellas que pueden resultar más útiles o necesarias de aprender.

Unidades objetivo

Probablemente el cambio más notorio para alguien al que le guste indagar en el sistema, sea la implantación de un concepto llamado unidad objetivo, más conocido como target unit. A diferencia de en SystemV, los niveles de ejecución ya no son necesarios y la única razón por la que existen es por su compatibilidad con el anterior init. Aún así, el concepto es muy parecido con la diferencia de que las unidades objetivo pueden realizar más de una tarea al mismo tiempo y que no tienen una representación númerica cómo con los runlevel (0,1,2...)

Las definiciones de las unidades está en /lib/systemd/system y pueden consultarse mediante un simple ls /lib/systemd/system |grep ".target$" o mediante systemctl list-unit-files --type=target. Estas unidades también contienen enlaces simbólicos en la carpeta /etc/systemd/system. Si realizáis cualquier de esos comandos veréis que hay targets con el nombre runlevel , pero sólo están para tener compatibilidad con system V tal y cómo he comentado antes; Dichos targets tienen los mismos parámetros que los targets que realmente se usan, que tienen una nomenclatura distinta a la que estamos acostumbrados pero con una estructura equivalente a la de los runlevel, aquí abajo os muestro una tabla que muestra los distintos targets con sus equivalentes de SystemV:


Tabla de targets

Actualmente el target por defecto es el número 5, el graphical.target, con lo que veamos que es lo que muestra dicho target mediante el uso del comando cat:


Resultado de graphical.target

Para averiguar el target por defecto habría que escribir:

systemctl get-default

Si por el motivo que sea se desease cambiar el target por defecto solamente habría que escribir.

systemctl set-default ${NOMBRE_TARGET}


Systemctl

Anteriormente he mencionado el comando systemctl pero no os he explicado su utilidad. Systemctl es una herramienta desarrollada con el fin de gestionar las unidades controladas por systemd. Es una herramienta muy versátil con multitud de opciones, pero las más conocidas son:

Para mostrar todas las unidades activas sin ningún tipo de filtro ni especificación

  1. systemctl
o
  1. systemctl list-units

Este comando muestra todas las unidades ya estén activas o no

  1. systemctl --all
o
  1. systemctl list-unit-files

Aunque anteriormente ya he hecho mención a los siguientes dos comandos, creo que es conveniente mostrarlos aquí de nuevo para tenerlo todo mejor plasmado. Los siguientes dos comandos muestran las unidades objetivo. El primero muestra las unidades objetivo activas, mientras que el segundo muestra absolutamente todas

  1. systemctl list-units --type=target
  2. systemctl list-unit-files --type=target

Para controlar las unidades se hace de forma muy parecida a cuando se usa el comando service. En estos cuatro ejemplos se ve cómo se arranca, para, reinicia y se controla el estado de una unidad  (en este caso sshd) respectivamente.

  1. systemctl start sshd.service
  2. systemctl stop sshd.service
  3. systemctl reload sshd.service
  4. systemctl status sshd.service

Interfaz gráfica systemctl


Aquellos a los que no les guste la consola, pueden optar por una interfaz gráfica que te ofrece más vistosidad a la hora de mostrar las unidades; Permite realizar las tareas básicas de systemctl(cómo por ejemplo las mencionadas arriba), pero si uno desea entrar en opciones más profundas y/o complejas, probablemente no le quede más remedio que pasarse a la consola. Dicha interfaz gráfica no va instalada por defecto, sino que tiene que ser instalada manualmente. Para instalarla habría que hacer:


Debian: apt-get install systemd-ui
Fedora: yum install systemd-gtk

Aún con esos nombres de paquete, el nombre de la interfaz gráfica es systemd System Manager y tiene el siguiente aspecto:

systemd System Manager

Aunque la interfaz gráfica representa obviamente una ventaja, no siempre podemos contar con esta, ya que nos podemos encontrar en la situación de que no haya ningún entorno gráfico (cosa que ocurre en los servidores por ejemplo) con lo que conviene tener unas ideas generales del funcionamiento de este nuevo init y sus funcionalidades.

Espero que os sea útil.

Saludos.

martes, 21 de abril de 2015

Cómo tener una consola Unix sin tenerla instalada

¿Alguna vez os habéis hallado en la situación de querer probar un comando que habéis leido por ahí pero que por las circunstancias no lo podéis probar? En más de una ocasión uno quiere por ejemplo probar algo que ha leido por ahí pero carece tanto de un sistema operativo Linux ni tampoco ninguna maquina virtual; Por suerte, investigando un poco por ahí he encontrado este enlace de lo más interesante:

Se trata de un emulador de consola basado en Javascript que permite probar varios comandos cómo si uno se encontrase realmente en ésta. Evidentemente dicho emulador ofrece opciones muy limitadas y no permite instalar nada ni consultar muchos de los ficheros típicos que se hallan en /etc a excepción de fstab y poco más, pero para realizar unas pruebas rápidas de los comandos más comunes que uno se puede encontrar en Linux es más que suficiente y sólo requiere del uso de un navegador.

Cómo curiosidad, os informo que el creador de dicho emulador es Fabrice Bellard, un programador conocido responsable del proyecto QEMU. Con lo que la fiabilidad de dicho emulador está garantizada.

Saludos.

lunes, 20 de abril de 2015

Los metadatos

Hoy vengo a hablar de un concepto que cada vez es más sonado en el área informática, pero no tanto fuera de ésta. Se tratan de los metadatos. Los metadatos son, en palabras simples, la información generada por los usuarios a la hora de manipular o crear un fichero. Esta información es generada de forma automática, es decir, no es algo que uno elija generar, y pueden ofrecer una información muy valiosa sobre el documento en cuestión.



Dependiendo del sistema operativo que ha generado el archivo en cuestión, los datos que muestran los metadatos varían ligeramente, pero todos los sistemas tienen un estandar (la norma POSIX) que deben cumplimentar, con lo que independientemente del sistema que haya creado el fichero en cuestión, todos mostrarán la siguiente información:

-Tamaño
-Identificador del periférico que lo contiene
-Su propietario y grupo
-Sus permisos de acceso
-Su fecha de última modificación
-Su última fecha de acceso

Esa información puede ser obtenida mediante la consulta de sus propiedades y también se pueden usar herramientas especificas de terceros que pueden ofrecer información más detallada. Por ejemplo en Windows se puede usar una herramienta gratuita llamada Foca, que muestra la información en una interfaz gráfica bastante intuitiva. Para Linux en cambio se puede usar la herramienta stat que ya está integrada en Linux de por sí, pero que no muestra demasiada información, o en caso de necesitar información más detallada se puede optar por instalar la herramienta exiftool. Veamos la diferencia entre estas dos últimas herramientas.

La primera herramienta es muy simple ya que no requiere de ningún operando adicional,

stat "fichero" , el cual nos mostraría "solo" lo siguiente:



Cómo podéis ver esta herramienta solo muestra lo mínimo independientemente del fichero que se analice. En algunos casos la información que muestra es suficiente, pero en otras en cambio la cantidad de información mostrada es incompleta, requiriendo de herramientas más potentes.

Instalando y probando exiftool


Tal y cómo he comentado antes, exiftool no es una herramienta integrada en el sistema de por sí, pero por suerte, los repositorios oficiales de todas las distribuciones Linux lo tienen incluido con lo que no hace falta acceder a ningún sitio en particular, con tan sólo hacer:


apt-get install libimage-exiftool-perl


Al igual que la herramienta stat, carece de interfaz gráfica pero su carencia de visibilidad se ve compensada por su eficiencia y su detalle a la hora de mostrar los datos.



Dependiendo del tipo de fichero, se puede haber dejado una información mayor o menor. En este caso se ha analizado un fichero .odt, pero se pueden analizar imágenes jpg, videos o pdfs... Por ejemplo un vídeo mostraría mucha información adicional, tal que así:


La información adicional varía dependiendo del tipo de archivo y cómo podéis ver puede ofrecer multitud de detalles que a primera vista pueden parecer ocultos.

Una de las opciones más útiles que ofrece esta herramienta, es la posibilidad de eliminar los metadatos mediante el comando:

exiftool -all= "fichero"


Dicho comando tiene la capacidad de eliminar mucha información que, por las circunstancias, no se desean mostrar. Muchos de los datos no se pueden borrar, pero algunos elementos descriptivos tales cómo el creador del fichero o (en caso de tenerlos) la localización GPS o el sistema operativo en el que se creo el fichero, pueden ser eliminados. A continuación veréis el mismo fichero tras la "limpieza":



Cómo podéis observar, datos tales cómo el Handler Vendor ID. el Offset, o la información relacionada con Google, ha sido eliminada de los metadatos, dejando mucha menos información disponible. Alguno puede pensar que esa información no es importante, pero cómo podéis ver el esfuerzo para eliminar la información es muy bajo y nunca está de más eliminar todo rastro de aquello que se aloja en la web.

Saludos.

domingo, 12 de abril de 2015

Los niveles de ejecución

Los niveles de ejecución, más conocidos cómo runlevel, son los modos en los que se ejecutan los sistemas operativos basados en la tecnología Linux/Unix. Los niveles de ejecución son representados numéricamente y oscilan entre el nivel 0 y el nivel 6, representando diferentes modos dependiendo del nivel en cuestión. Cada nivel representaría lo siguiente:

     0.  Alto: El sistema operativo se cierra o se apaga.
    1.  Monousuario: En este modo no arrancan ni las tarjetas de red ni los servicios. Además no te permite conectar ningún otro usuario que no sea root. Este modo es habitualmente usado para depurar fallos. Se podría considerar este modo cómo el de aprueba de fallos
     2.  Multiusuario: Se trata del modo usado por defecto que te arranca el sistema de forma normal.
     3-5. Multiusuario: Exactamente igual que el runlevel 2.
     6. Reinicio del sistema: Eso significa que cuando el sistema operativo recibe la señal de reinicio, entra en el modo 6, ejecutando las acciones pertinentes a dicho modo.

El runlevel que se ejecuta por defecto al arrancar el sistema es establecido en el fichero /etc/inittab. Dicho valor queda representado en el fichero tal que así:


Lo más normal es mantener dicho valor tal y cómo está, aunque en caso de tener muchos problemas es recomendable cambiarlo al runlevel 1 para poder buscar cual puede ser la causa de éstos. Otra opción para saber en que runlevel nos encontramos es mediante los comandos who -r o runlevel. Ambos muestran el runlevel actual y pueden servir de ayuda para saber en qué modo se encuentra el sistema operativo en estos momentos.


Otro factor importante del nivel de ejecución es el control de los servicios que se arrancan dependiendo del nivel en cuestión. Estas decisiones se toman en ficheros denominados rc, y van seguidos de un número que indica en nivel (rc0,rc1,rc2...).

Para incluir dichos servicios en los diferentes niveles, se requiere el uso de update-rc.d o insserv. Para el uso de insserv se requiere el script de arranque alojado en /etc/init.d/ contenga el standard LSB explicado aquí. Con el LSB bien cumplimentado sólo habría que escribir insserv ${servicio}. Con update-rc.d en cambio habría que hacer:


  1. update-rc.d ${servicio} start ${orden_arranque} 2 3 4 5 . stop ${orden_parada} 0 1 6 .


miércoles, 8 de abril de 2015

Los canales estándar en Linux

En esta ocasión voy a hablar de un tema un poco menos conocido en Linux: Los canales. Un canal es lo equivalente un fichero con una descripción pre-establecida por defecto que, cómo un fichero normal, puede ser leído y escrito.

Estos canales son usados involuntariamente por todos los usuarios de Linux y todo aquel que ha escrito un script suele encontrarse con uno de estos canales, especialmente con el último.
  • El canal de entrada se llama stdin y lleva un descriptor numérico llamado 0.
  • El canal de salida se llama stdout y lleva un descriptor numérico llamado 1.
  • El canal de error se llama stderr y lleva un descriptor numérico llamado 2. Este canal puede ser redirigido a otro, ya sea el canal 0 o el 1.

Los canales reciben automáticamente estos contenidos y éstos pueden ser redirigidos a un fichero. Por ejemplo, imaginemos que queremos eliminar un fichero llamado test.txt y este no existe. Evidentemente el comando no se ejecutará y dará un error:


Cómo acabamos de ver, el canal de error posee el descriptor numérico 2. Con lo que sólo habría que redirigir la salida del canal de error a un fichero mediante el 2>${fichero}. Así que si queremos que la salida de error del comando rm test.txt vaya a un fichero, sólo habría que hacer lo siguiente:

rm test.txt 2>/tmp/errores.log

Otra opción es redirigir un canal a otro, para luego redirigir el contenido de ambos a un fichero con por ejemplo:

rm test.txt >/tmp/errores.log 2>&1 

Esta redirección es más común cuando se quiere ejecutar un script de forma automática y no se quiere importunar al usuario que esté conectado por consola con mensajes de error o de salida que pueda dar este script, pero se desea tener un registro de lo que pueda generar dicho script por si hay cualquier problema. Un buen ejemplo de este tipo de redirecciones es el fichero crontab (tareas programadas en Linux) que ejecuta un script o comando de forma automática a una hora determinada y no nos interesa que nos muestre notificación o error alguno.

Muchos dirán que aunque ven útil el hecho de no ser importunados por mensajes, no quieren tener un fichero de log que vaya incrementándose poco a poco y ocupando espacio innecesario en el disco duro. Por fortuna, esto se puede arreglar haciendo que los canales vayan redirigidos a la nada. Así, evitamos tanto ser importunados cómo llenar espacio innecesario en el disco. Para redirigir a la "nada", aplicando el ejemplo anterior escribiríamos:

rm rest.txt >/dev/null 2>&1

Esta última redirección es la que se ve más a menudo en el fichero crontab.

En conclusión, los canales pueden parecer algo abstracto o incluso, para algunos, aburrido, pero la verdad es que para aquellos que jueguen con crontab o quieran ejecutar algunos scripts, tienen un valor incalculable.

Saludos.

miércoles, 1 de abril de 2015

Métrica tarjetas de red Linux

En más de una ocasión uno puede tener instaladas dos tarjetas de red con ip estática configurada en un equipo con Linux instalado y desea que en caso de que una puerta de enlace falle, se pueda ir por una secundaria configurada para la otra tarjeta de red. Eso parece fácil así dicho, pero si se ponen dos puertas de enlace sin configuración especial alguna, el equipo se ve incapaz de decidir por qué puerta de enlace salir, y con iptables se puede hacer para salir por ambas puertas indistintamente, pero no se desea eso tampoco y en algunos entornos puede resultar algo ineficiente.

Por suerte, a la hora de configurar una puerta de enlace en /etc/network/interfaces, existe la opción de asignarles una métrica a las puertas de enlace, conocidas en Linux cómo gateways. La métrica establece la prioridad que tiene una puerta de enlace sobre la otra y cuanta más baja sea, mayor prioridad tendrá sobre el resto de puertas de enlace, así aquella que posea una métrica de 0 tendrá más prioridad que la 1 y así sucesivamente. Aún así, le métrica que se establece siempre por defecto es 0 para todos los gateways, con lo que por defecto, al poner dos gateways, ambos tendrán la misma métrica y no sabría por donde salir.

Para solucionar dicho problema existe un método muy sencillo que nos permite establecer un métrica diferente a cada puerta de enlace. Supongamos que tenemos dos interfaces configuradas con ip estática. Dichas dos interfaces ya están configuradas pero no se puede salir a internet debido a que las dos tienen una puerta de enlace y el sistema no sabe por cual salir. Este sería un fichero de configuración de ejemplo:

  1. # Loopback
  2. auto lo
  3. iface lo inet loopback
  4. # Interfaz primaria
  5. auto eth0
  6. allow-hotplug eth0
  7. iface eth0 inet static
  8.         address 192.168.1.10
  9.         netmask 255.255.255.0
  10.         network 192.168.1.0
  11.         broadcast 192.168.1.255
  12.         gateway 192.168.1.1
  13. # Interfaz secundaria
  14. auto eth1
  15. allow-hotplug eth1
  16. iface eth1 inet static
  17.         address 192.168.2.10
  18.         netmask 255.255.255.0
  19.         network 192.168.2.0
  20.         broadcast 192.168.2.255
  21.         gateway 192.168.2.1

Así tal y cómo está nunca podría funcionar, pero con unas ligeras modificaciones se podría solucionar el problema. Dichas modificaciones consisten en quitar los gateway tal y cómo están puestos y hacer para que tras activar las interfaces de red (ya sea eth0 o eth1) el sistema añada automáticamente el gateway con una métrica definida por nosotros y que al desactivarlas, borre dichos gateways. Para dicho propósito se borran las líneas de los gateways y se añaden dos líneas, que consisten en post-up y pre-down. Post-up incluye una acción tras activar la interfaz de red en cuestión mientras que pre-down incluye una acción justo antes de desactivar dicha interfaz. En este caso lo que se desea en concreto es que se añada un gateway con métrica justo después de activar la interfaz y que se elimine dicho gateway cuando la desactivemos, con lo que hablando de forma global sería algo como:

post-up route add default gateway ${IP} metric ${NÚMERO}
pre-down route del default gateway ${IP}

Eso aplicado al ejemplo que he mostrado antes quedaría así:

  1. # Loopback
  2. auto lo
  3. iface lo inet loopback
  4. # Interfaz primaria
  5. auto eth0
  6. allow-hotplug eth0
  7. iface eth0 inet static
  8.         address 192.168.1.10
  9.         netmask 255.255.255.0
  10.         network 192.168.1.0
  11.         broadcast 192.168.1.255
  12.         post-up route add default gateway 192.168.1.1 metric 1 
  13.         pre-down route del default gateway 192.168.1.1
  14. # Interfaz secundaria
  15. auto eth1
  16. allow-hotplug eth1
  17. iface eth1 inet static
  18.         address 192.168.2.10
  19.         netmask 255.255.255.0
  20.         network 192.168.2.0
  21.         broadcast 192.168.2.255
  22.         post-up route add default gateway 192.168.2.1 metric 2

  23.   pre-down route del default gateway 192.168.2.1

Por último quedaría revisar si efectivamente se han puesto las métricas cómo nosotros deseamos. Para ello sólo habría que escribir route, y tendría que mostrar algo parecido a ésto:

Destination     Gateway     Genmask Flags Metric Ref Use Iface

default          192.168.1.1    0.0.0.0       UG         1    0     0    eth0
default          192.168.2.1    0.0.0.0       UG         2    0     0    eth1

Con ésto ya tendríamos dos puertas de enlace que no colisionan entre sí y que en caso de que no se pudiese salir por la primera, se tuviese la opción de salir por la segunda automáticamente.

Saludos.