Normalmente tenemos en ejecución decenas de servicios, y todos deben estar en ejecución en todo momento. Puede que si somos usuarios de escritorio y tenemos un problema, lo detectemos al momento y reiniciemos el ordenador, o incluso investiguemos qué se ha detenido, lo reiniciamos y continuamos trabajando.

Aunque, si tenemos un VPS, una Raspberry PI o un NAS con un pequeño servidor, o cualquier sistema que tenga que estar todo el día encendido de forma independiente ejecutando un sistema GNU/Linux tenemos que tener en mente que los servicios fallan en algún momento. Ya sea por ejecutar una versión experimental, descubrir un bug, o simplemente quedarte sin memoria o disco. La clave es tener previsto que esos servicios pueden sufrir un problema. En el caso de tener un VPS con una web o un blog, significaría dejar a los usuarios sin poder acceder si por ejemplo se cae el servidor web o el servidor de aplicación. O en el caso de una Raspberry implicaría conectarnos o conectar monitor y teclado para reiniciar el servicio a mano, cuando debería ser algo que funcione de manera independiente.

Y como actualmente muchas distribuciones incluyen Systemd, vamos a hacerlo utilizando este sistema.

NOTA: En este tutorial, estoy utilizando sudo para ejecutar acciones con privilegios de root, pero puede que tu sistema no tenga sudo configurado. Así que tendrás que alcanzar el usuario root para ejecutar los comandos.

Listar nuestros servicios

Para ello, tenemos que tener claro cómo se llama el servicio. En Systemd todos acaban con ".service", algunos ejemplos de servicios pueden ser: apache, nginx (servidores web), sshd (servidor ssh), ufw (firewall), etc.

Podemos obtener un listado de los servicios de nuestro sistema así

sudo systemctl list-units --type=service

Vamos a probar, por ejemplo con el servicio apache2.service, es un servidor web y será muy fácil hacer pruebas con él.

Simulando fallos en el servicio

Es posible que este servicio falle. Y es algo que pasa en servidores del mundo real. Puede ser por algún fallo que se haya descubierto y haya sido explotado por un atacante, falta de recursos en el servidor, o incluso un fallo en un módulo, pero no podemos renunciar a ofrecer el servicio a nuestros usuarios. Así que, vamos a matar el proceso, para que éste finalice repentinamente sin contar con systemd:

sudo killall -9 apache2

Lo ejecutamos varias veces, hasta que nos aseguremos de que el proceso está realmente muerto. Si queremos, podemos intentar acceder al servidor web, y asegurarnos de que no responde.

Editando el servicio

Ahora, vamos a editar el archivo de descripción del servicio. Lo bueno de systemd es que no tenemos que editar el archivo original que describe el servicio, en mi caso /lib/systemd/system/apache2.service. Editar el archivo original implica que si actualizamos el sistema, una actualización puede deshacer nuestros cambios y nos obligaría a revisarlos cada vez que actualicemos. En su lugar podemos editar el archivo /etc/systemd/system/apache2.service o, en versiones más modernas de systemd, podemos ejecutar:

sudo systemctl edit apache2.service
 

Esto directamente nos mostrará un editor de texto (vi, nano, etc) con un fichero en blanco desde el que podemos introducir modificaciones al fichero original. Los cambios introducidos aquí se sumarán al fichero original y systemd lo interpretará como un archivo que contiene todas las directivas conjuntas. El comando, crea un directorio llamado /etc/systemd/system/apache2.service.d/ y dentro de ese directorio creará el archivo override.conf.

En dicho editor introduciremos lo siguiente:

 
[Service]
Restart=always
 

Con esto indicaremos a systemd que debe reiniciar el servicio siempre que se pare. Guardamos el fichero y ejecutaremos ahora:

sudo systemctl daemon-reload
sudo systemctl daemon-reload

Con este comando indicaremos a systemd que debe leer de nuevo todos los ficheros de configuración de los servicios. Ya podemos reiniciar el servicio (porque lo dejamos parado antes):

sudo systemctl restart apache2.service

o

sudo service apache2 restart

Este segundo es el antiguo método, aunque systemd lo mantiene. Para comprobar que realmente funciona este método, podemos esperarnos un minuto y pedir el estado del proceso apache2, para ello ejecutamos:

sudo systemctl status apache2.service

Y veremos algo parecido a esto:

● apache2.service - The Apache HTTP Server
 Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: ena
 Drop-In: /lib/systemd/system/apache2.service.d
 └─apache2-systemd.conf
 /etc/systemd/system/apache2.service.d
 └─override.conf
 Active: active (running) since Sun 2018-11-18 14:15:51 CET; 1min 19s ago
 Process: 13229 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS
 Main PID: 13245 (apache2)
 Tasks: 55 (limit: 4915)
 CGroup: /system.slice/apache2.service
 ├─13245 /usr/sbin/apache2 -k start
 ├─13248 /usr/sbin/apache2 -k start
 └─13249 /usr/sbin/apache2 -k start

En la línea que comienza por Active, veremos cuánto tiempo lleva el proceso arrancado, en este caso 1 minuto y 19 segundos. Ahora, si matamos el proceso apache2 y pedimos el estado del proceso de nuevo, ahora veremos que el proceso sigue activo, pero se habrá iniciado hace unos segundos nada más. También veremos que los PID de los procesos son diferentes, y veremos una líneas indicando este reinicio.

Ver el log del proceso

Si queremos ver el log del proceso para saber el momento en el que se ha reiniciado, o ver directamente si se ha producido este reinicio y diagnosticarlo, porque lo ideal es que esto nunca suceda, podemos ejecutar:

sudo journalctl -u apache2.service

Ganando algo más de control

Ya hemos conseguido que los procesos se reinicien automáticamente, ahora vamos a afinar un poco esta configuración. Puede que nuestro servicio necesite unos segundos antes de levantarse, para lo que podremos editar el archivo de descripción del servicio e introducir:

RestartSec=2s

Y así esperaremos 2 segundos antes de reiniciarlo.

Incluso podemos limitar el número de veces que se reiniciará dentro de un intervalo de tiempo, por ejemplo, le podemos decir que si en un intervalo de 10 segundos, el servicio se reinicia 3 veces, no intentemos reiniciarlo más. Imaginemos que el equipo se queda sin disco, y vamos a tener a systemd reiniciando constantemente un servicio, ocupando CPU y memoria y puede que impidiendo la administración remota. Lo podemos hacer introduciendo estas líneas en la descripción del servicio:

StartLimitBurst=3
StartLimitIntervalSec=10

Y por supuesto, podemos probarlo matando el servicio varias veces. Incluso systemd nos indicará en el estado que ha superado el límite de reinicios y por eso el servicio se ha detenido.

Otra buena idea es, por ejemplo, enviar un correo electrónico al administrador en caso de reinicio de determinados servicios. Para ello, en esta misma descripción podemos incluir:

ExecStartPre=/usr/local/bin/correo_error_admin.pl

Luego, podemos crear el script que envía el correo, por ejemplo en Perl, introduciendo lo siguiente en el script /usr/local/bin/correo_error_admin.pl :

#!/usr/bin/perl
use strict;
use warnings;
# first, create your message
use Email::MIME;
my $message = Email::MIME->create(  
  header_str => [
    From    => <a href="mailto:Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.'">Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.'</a>,
    To      => <a href="mailto:Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.'">Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.'</a>,
    Subject => 'Error en tu servidor',
  ],
  attributes => {
    encoding => 'quoted-printable',
    charset  => 'ISO-8859-1',
  },
  body_str => "Lo siento, tu servidor se ha reiniciado\n",
);
# send the message
use Email::Sender::Simple qw(sendmail);
sendmail($message);

En este script podemos incluir cualquier acción que nos interese automatizar cuando se inicie el servicio. Incluso podemos utilizar ExecStartPost= para ejecutar una acción cuando el servicio se haya iniciado y de la misma manera ExecStopPre= y ExecStopPost= para ejecutar acciones cuando paremos el servicio (pero no cuando el servicio se detenga o muera).

¡Espero que les haya sido útil!

Foto: unsplash-logoAles Nesetril

Buenas a todos de nuevo. En este nuevo capítulo de “Cómo instalar Linux en Macintosh” nos centraremos en la instalación de Linux bajo el sistema EFI que hay disponible en los Macs con procesador Intel. Como ya se comentó en capítulos anteriores de este “macrotutorial”, la implementación de EFI es bastante difusa con respecto a los sistemas EFI normalizados de la gran mayoría de las placas base de hoy en día. Además, también hay que tener en cuenta que, en un principio (y tal como he comentado anteriormente), Apple restringe el arranque vía EFI del ordenador a su sistema propietario Mac OS. De ahí que haya que tener en cuenta que, si quieres tener la experiencia más “nativa” posible de Linux en tu Mac, habrá que entrar en modificaciones serias, por lo que, antes de intentar realizar los puntos de esta parte del tutorial, recomiendo encarecidamente la realización de una copia de seguridad de los datos de las particiones y los programas que dispongas en Mac OS y en cualquiera de los sistemas operativos alternativos que se dispongan en el ordenador en ese momento. No importa el programa que uses (Time Machine, programas de clonado de particiones, etc), pero hazlo. Si en alguno de los pasos de los que se van a describir a continuación sucede algún problema, siempre podrás restaurar los datos sin tener complicación, y con el “peace of mind” que dicen los ingleses ;) .

La primera parte de este tutorial, es exactamente igual a la que se ha descrito anteriormente. No voy a extenderme más en este aspecto, ya que la elección de la distro, la arquitectura, y la creación de los medios de instalación son exactamente iguales a los ya comentados (eso sí, el disco de arranque puede ser, o un DVD, o un USB especialmente preparado para el arranque bajo EFI; ojo con esto). Sin embargo, aquí es dónde va a empezar a diferir el procedimiento ya que, a la hora del particionado de los discos duros, es necesario realizar este proceso de forma manual en la Utilidad de Discos de Mac OS, el cual, te aparecerá tal que así (al menos, es como lo dispongo en mi caso, con macOS High Sierra 10.13.4):

Si tienes una unidad de disco duro o SSD formateada en HFS+, estás de suerte. Simplemente le das a Crear Partición, le das el tamaño que prefieras, le das el formato FAT32 (importante), y, como diría cierto personaje de la televisión, “ala, aparcao”. Sin embargo, con el nuevo sistema de archivos introducido en macOS High Sierra (APFS), las unidades de disco duro se agrupan en “volúmenes lógicos”, por lo que te saldrá este aviso si intentas crear una partición en un disco de este estilo:

Dado que APFS es un formato de sistema de archivos que está en su infancia (al menos, en Macintosh), y ha dado bastantes problemas en este tipo de temas, yo, en mi humilde opinión, no me atrevería personalmente a reparticionar nada usando la Utilidad de Discos. En su lugar (y lo voy a realizar paso a paso), voy a realizar estos pasos:

-Teclear en la Terminal:

diskutil list disk0

¿Por qué pongo esto? Por lo siguiente:

Porque “disk0” es la unidad de disco física en la que está instalado el 
sistema operativo, en el formato de sistema de archivos APFS. De ahí que
 sea la unidad que se vaya a utilizar para particionarla a fin de 
instalar Linux como los cánones mandan. Me quedaré con esto:

Especialmente en la que contiene el identificador “disk0”, ya que será 
la unidad de la cual haremos la correspondiente partición.

-Teclearé ahora en la Terminal el siguiente comando:

sudo  diskutil  apfs  resizeContainer  disk0s2  (Tamaño de disk0s2-Tamaño de la partición Linux; en gigabytes; sin los paréntesis)  FAT32  (Nombre de la partición Linux; sin los paréntesis)  (Tamaño de la partición Linux en gigabytes; sin los paréntesis)

Esto creará una nueva partición para nuestra distro Linux con el menor 
riesgo posible. Podrás ver los cambios en la Utilidad de Discos 
posteriormente.



A partir de aquí ya tendremos el espacio preparado para la instalación 
de Linux. Pero todavía queda una parte más para solucionar el puzzle: el
 gestor de arranque. Para esta parte, utilizaremos el gestor de arranque
 alternativo rEFInd (
	www.rodsbooks.com/refind/index.html
). Ve a este enlace: 
	sourceforge.net/projects/refind/
  y descarga la última versión de este gestor (según el desarrollador de
 esta aplicación, siempre estará en beta, por lo que no te asustes a la 
hora de descargarlo ;) ). 



Cuando hayas descargado rEFInd, en función de la versión de Macintosh 
que tengas, es posible que tengas que desactivar cosas antes de 
instalarlo. Desde macOS El Capitan (versión 10.11 en adelante) existe un
 pequeño obstáculo llamado System Integrity Protection, el cual 
interferirá en la instalación de este elemento que hemos descargado. Si 
no tienes 10.11+, sáltate estos pasos que voy a indicar a continuación. 
Pero, si lo tienes, síguelos:

-Ve a Terminal y ejecuta

csrutil disable

, y pulsa Intro
-Reinicia el ordenador (tardará un poquito debido a la aplicación de esta operación)
Una vez hayas hecho esto, estarás listo para instalar rEFInd. Tendrás una carpeta refind-bin-0.11.2.zip (el número de versión puede variar, a fecha de hoy es la que se ha indicado). Descomprímela, abre una ventana de Terminal, y, en la carpeta de refind-bin-0.11.2, arrastra el archivo llamado refind-install a la ventana del terminal. Dale al botón de Intro las veces necesarias hasta que se instale. Cuando termine, cierra la ventana de Terminal. Como paso adicional para los que lleven el System Integrity Protection activado, volved a abrir ventana de terminal, ejecutad

csrutil enable

[ -d /efi/refind ]] && sudo rm -R -f /efi/refind
[[ -d /EFI/refind ]] && sudo rm -R -f /EFI/refind
efivol=$(diskutil list | grep " EFI " | grep -o 'disk.*' | head -n 1)
sudo mount -t msdos /dev/${efivol} /Volumes/ESP
[[ $? != 0 ]] && sudo mount -t hfs /dev/${efivol} /Volumes/ESP
[[ -d /Volumes/ESP/EFI/refind ]] && sudo rm -R -f /Volumes/ESP/EFI/refind
sudo umount /Volumes/ESP
sudo bless --setBoot --mount /