Archivo de la categoría: Utilidades GNU/Linux

Utilidades GNU/Linux

Monitorizando el consumo de red en nuestro equipo GNU/Linux (II)

En el anterior artículo vimos cómo usar iftop para monitorizar el consumo de ancho de banda en nuestro equipo GNU/Linux.

Hoy vamos a ver otro comando interesante: iptraf.

iptraf es una utilidad muy completa para monitorizar el consumo de ancho de banda actual en nuestras interfaces de red así como mostrar estadísticas de uso de las mismas.

Al arrancarlo sale una interfaz tipo curses, que permite seleccionar con los cursores del teclado la opción que queremos. Una opción que muestra bastante información es la de Detailed interface statistics, que muestra algo así:

Ejecución de iptraf

Ejecución de iptraf (*)

También es interesante la primera opción IP traffic monitor, que muestra las conexiones TCP junto con las estadísticas de paquetes y bytes enviados tanto en un sentido como en otro.

Espero que os resulte útil.

 

(*) Imagen descargada desde la web oficial de iptraf.

Monitorizando el consumo de red en nuestro equipo GNU/Linux (I)

Si nos interesa saber qué ancho de banda se está consumiendo en nuestro equipo Linux podemos hacerlo de forma muy sencilla usando la aplicación iftop.

iftop es una sencilla aplicación que funciona en modo texto y que, por tanto, podemos lanzar en cualquier sesión de terminal que tengamos abierta.

Está disponible para las distribuciones más importantes. Al arrancar la aplicación tiene este aspecto:

Ejecución de iftop (screenshot de la web oficial)

Ejecución de iftop (*)

Como vemos, nos muestra una lista de IPs origen e IPs destino que detecta nuestra tarjeta de red y qué cantidad de tráfico estamos enviando/recibiendo. Nos muestra 3 columnas a la derecha, en las cuáles nos informa el tráfico enviado/recibido en los últimos 2, 10 y 40 segundos.

Es algo parecido a lo que hace top con los recursos del sistema pero ésta aplicación lo hace con el consumo de ancho de banda.

En las dos últimas líneas nos muestra el tráfico acumulado (tanto recibido como enviado) desde que hemos arrancado la aplicación, los picos de tráfico y también el total de enviado y recibido en los últimos 2, 10 y 40 segundos.

Una vez que lo arrancamos tenemos varias opciones útiles, como por ejemplo:

t: Cambia el aspecto (sólo tráfico enviado, sólo recibido, ambos en una línea, ambos en 2 líneas)
p: Muestra los números de puerto
n: No resuelve los nombres de host (muestra las IPs)
T: muestra una columna adicional con los totales acumulados para ese tráfico
l: permite hacer filtros introduciendo la cadena por la cuál queremos filtrar
?: muestra la ayuda (todas las teclas y sus funciones)

Usad la opción «?» para ver todas porque hay muchas más opciones. Por ejemplo, también son útiles las que permiten ordenar el resultado por una u otra columna (con «<» y «>»).

Se puede arrancar ya la aplicación con unos parámetros. Por ejemplo, si sabemos que no queremos que resuelva los nombres podemos arrancarlo con la opción -n. Con el comando man podéis indagar más sobre todas las opciones disponibles.

Es muy útil para poder saber, en un momento en el que notáis que las descargas o la navegación web -por ejemplo- van más lentas de lo normal.

 

(*) Imagen descargada de la wikipedia.

Monitorizando vuestro equipo con «saidar»

En GNU/Linux existen muchas utilidades para monitorizar los distintos parámetros que miden la actividad y el estado del sistema, como consumo de CPU, de memoria, lectura/escritura en discos, uso de la red, etc.

Normalmente, cada una de estas utilidades monitoriza unos parámetros en concreto, por lo que si queremos ver otros tenemos usar otras utilidades. Esto no tiene por qué ser un problema, porque a uno le puede interesar consultar unos parámetros en un momento y otros en otro. Sin embargo, si queremos ver todos (*) podemos usar una herramienta como «saidar».

Saidar nos muestra en un formato de texto aunque fácilmente legible, consumo de CPU, de memoria, de red, uso de disco duro, entre otros. Para instalarlo, simplemente usar el gestor de paquetes de vuestra distro y lo tendréis. Si no os lo encuentra pensad en cambiar de distro ;-P. Ubuntu y OpenSuse, por ejemplo, lo tienen.

Al ejecutar el comando «saidar», aparecerá algo así:

Salida del comando saidar

Salida del comando saidar

Como vemos, con esta utilidad podemos observar, de un vistazo, algunos de los parámetros más importantes que muestran el estado de nuestro equipo.

Un aspecto a tener en cuenta respecto a la información suministrada sobre la memoria usada/libre: la información es correcta, por supuesto, pero hay que tener en cuenta que Linux usa memoria libre para optimizar procesos del sistema como vimos en el anterior artículo.

El comando se puede dejar lanzado en una terminal y va actualizando cada 2 segundos.

 

(*) Realmente no son todos los parámetros del sistema, sino algunos de los parámetros más significativos.

Consultar memoria usada/libre en GNU/Linux con comandos

Existe una forma sencilla de consultar la memoria ocupada/libre de nuestro sistema GNU/Linux desde la línea de comandos. Para ello tenemos el comando free.

Si lo ejecutamos nos mostrará la cantidad de memoria ocupada/libre que hay en el sistema, pero lo hará en bytes, lo cuál es difícil de leer. Para solucionar esto usaremos el parámetro -m. De esta forma (con «free -m») lo vemos en MB. Ejemplo:

Salida del comando free

Salida del comando free

Si nos fimajos en la segunda fila (-/+ buffers/cache) tenemos 1137 MB de memoria en uso y libres 2818 MB. De estos 2818 MB, 845 se están usando para caché de procesos, 72 MB para buffers de I/O y 1900 MB están libres (el sistema no los está usando para nada). Los 72 MB de «buffers» y los 845 MB de «cached» se pueden usar cuando se necesite memoria para algún programa, por lo que se pueden considerar como libres, sumándolos a los otros 1900 MB (lo que nos dán los 2818 MB que nos indica dicha línea (*)).

GNU/Linux usa toda la memoria para cachear procesos y datos de forma que se le saque partido a la misma. De esta forma se aceleran el uso del sistema y la memoria se considera libre al mismo tiempo, pasando a disposición de cualquier proceso que la necesite.

 

(*) La columna «shared», según se indica en la página del manual, es una información obsoleta y se puede obviar.

Ejecutando comandos como root dentro de un script

A veces, dentro de un script, se necesita ejecutar un comando como superusuario. Una posibilidad es usando el comando sudo, por ejemplo:

sudo ls /root

Si lo ejecutáis sin el sudo (es decir, como vuestro usuario normal del sistema) no os va a dejar porque no tenéis permiso para ver el contenido del directorio /root. Si lo ejecutáis con sudo sí que podréis. Eso sí, os pide vuestro password -para comprobar que no es cualquiera que se ha sentado un momento en vuestro PC y os quiere fastidiar el equipo-.

Para que esto funcione, vuestro usuario tiene que tener permisos de sudo. Esto se hace automáticamente para el usuario que se define en la instalación de sistemas operativos como Ubuntu y derivados.

En cualquier caso, aquí tenéis más información sobre sudo y cómo configurarlo para un usuario.

Así, si en un script necesitáis ejecutar algo con permisos de root podéis usar sudo. Ahora bien, tended en cuenta que os va a pedir el password, por lo que no podéis lanzarlo y marcharos, ya que se quedará esperando que pongáis el password de vuestro usuario. Imaginad que lanzáis un script que hace mogollón de cosas -en las que tarda un tiempo- y luego, al rato, en uno de los comandos que hay en el script, usa sudo para ejecutarse como root. Tendréis que estar sentados todo el rato hasta que os la pida.

Para salvar esto podéis usar la opción -S, que permite que se le pase el password en la línea de comandos. Se usaría así:

echo PASSWORD | sudo -S ls /root

Evidentemente, el comando que ejecutaréis en el sudo, normalmente será algo más complicado que éste ;-P (y más útil).

Por tanto, con sudo -S podemos, bien pedir el password al principio del script (con read) o bien cogerlo de algún sitio. En este último caso hay que tener presente que el password estaría almacenado en claro en ese «sitio», por lo que conviene que tenga permisos de lectura sólo para el propio usuairo (algo como «chmod 600 fichero«, por ejemplo).

Espero que os resulte útil.

Ventajas de usar Dropbox

Existen muchas empresas que ofrecen almacenamiento en la nube, como Dropbox, Google (Google Drive), Microsoft (Skydrive) y otras más. Además, para los más celosos de su intimidad, existen soluciones que cifran todo en el cliente como spideroak e incluso soluciones de tipo «móntatelo tú mismo» como ownclowd.

Yo uso Dropbox desde hace ya varios años (bastantes). No tengo mucho espacio (unos 6 GB aprox.), pero no necesito más. Allí tengo todos los archivos de configuración, documentos, plantillas, etc., que uso en mi día a día. Lo tengo configurado en todos mis equipos, de forma que si actualizo un archivo en uno de ellos (con la comodidad de hacerlo directamente desde el propio sistema operativo, sin necesidad de hacerlo obligatoriamente desde la web), lo tengo actualizado en todos.

Os recomiendo este sistema por 5 razones fundamentalmente:

1.- Existe un cliente para casi cualquier plataforma. En particular, en windows funciona, en linux también (yo sólo uso éste), en Android también… (aunque aquí no se sincroniza sino que se descargan los archivos conforme los necesitamos por ahorrar ancho de banda -pero es más que suficiente-).

2.- Funciona perfectamente. No da problemas. Lo instalas, se sincroniza y a correr.

3.- Es una copia de seguridad en sí misma (la tienes en varios PCs y la nube).

4.- Si borras un archivo puedes recuperarlo. Hay como una «papelera» interna que desde la web podéis usar para recuperar archivos. Yo la he usado en un par de ocasiones y me ha salvado la vida.

5.- Tiene un control de todas las versiones de un archivo, es decir, creas un archivo dentro de tu directorio de dropbox, luego editas y grabas, luego vuelves a editar y grabas de nuevo, vuelves a editarlo y vuelves a guardar… si en la última edición, por ejemplo, te has cargado el contenido, puedes recuperar todas y cada una de las versiones anteriores. A mí esto me ha salvado también hace poco de una bastante gorda. De hecho, no concibo editar archivos fuera de Dropbox. Así es prácticamente imposible que se pierdan, no sólo los archivos totalmente sino los cambios entre versiones. Es, simplemente, fantástico.

La pega que tiene es que, como cualquier servicio de almacenamiento en la nube, los datos están en servidores de empresas privadas. Así que si no os gusta que otras empresas «husmeen» en vuestros archivos, no lo uséis. En este caso, mejor usad cosas como spideroak, ownclowd o, mejor aún, no uséis servicios en la nube. Mejor incluso, no uséis internet (¡toda precaución es poca!). En mi caso, prefiero disfrutar de los servicios gratuitos y de calidad que me ofrecen sabiendo que la publicidad que me aparece va en función de mis gustos personales, los cuáles Google ha obtenido gracias a husmear en mis cosas, pero vamos, puedo vivir con ello, oye.

Hacer copias de seguridad usando gmail II

En el anterior artículo vimos que podemos exprimir un poco más nuestra cuenta de correo en la nube (gmail en este caso) y aprovechar los muchos megas que nos ofrecen gratis para salvaguardar no sólo mails sino también archivos.

Ahora vamos un paso más allá para agilizar este proceso. Con lo visto hasta ahora, si queremos hacer un backup de un archivo usando gmail tenenos que abrir gmail en el navegador, darle a «Redactar», crear el mensaje, rellenarlo, incluir el adjunto y enviar… Esto es sencillo pero lo cierto es que nos quita tiempo, ese recurso tan importante y escaso. Podemos hacerlo más rápido con un script. Veamos cómo.

En un artículo anterior vimos cómo enviar mails desde nuestra cuenta de gmail usando la línea de comandos. Vamos a hacer uso de esto para agilizar la copia de seguridad de archivos. Os muestro un ejemplo de script que realizaría esta tarea:

#!/bin/bash

echo -n "Subject: "
read SUBJECT
SUBJECT="-backup- $SUBJECT"

echo -n "Body: "
read BODY

echo -n "Enviando mail..."
echo $SUBJECT > /tmp/subject
echo $BODY > /tmp/body
/usr/local/bin/send_gmail /tmp/subject /tmp/body $1
echo "OK"

Este script hace uso del script que vimos en dicho artículo (send_gmai), script que hemos dejado en /usr/local/bin para poder ejecutarlo desde la línea de comandos de forma habitual sin necesidad de incluir la ruta (aunque en el script de arriba sí que lo hacemos para asegurarnos de que funciona siempre independientemente del valor de la variable de entorno PATH).

Lo que hace es pedirnos el subject y meterle luego la cadena -backup- para que no tengamos de preocuparnos de meterla nosotros manualmente. Esta palabra es la que, como dijimos en el artículo anterior, usamos para hacer el filtro. Podríamos crearnos distintos scripts para distintos tipos de backups si quisiéramos y cambiar aquí -backup- por otra cosa en cada uno. Posibilidades hay mil.

También nos pide el cuerpo del mensaje. Si no lo necesitáis podéis obviar esto y meter siempre algo como «backup» y váis más rápidos.

Para finalizar, llama al script send_gmail, el cuál envía el correo electrónico con el adjunto que pasamos como único parámetro al script en cuestión, el cuál llamaremos, por ejemplo, backup_file. Así pues, suponiendo que queremos hacer un backup de un archivo llamado proyecto.odt que tenemos en el directorio actual, lo llamaríamos así:

backup_file proyecto.odt

Como digo, las posibilidades son muchas. Podéis automatizar el backup de un directorio entero, por ejemplo. Podéis añadir también automáticamente la fecha en el subject o el cuerpo del mensaje para tenerlo mejor clasificado (aunque esto ya se ve en la fecha y hora del propio mail). Podéis quitar los read y meter algo estático y luego meter el script en el crontab para que haga backup de cierto archivo o directorio cada hora, por ejemplo…

Alguien dirá que para esto ya está Dropbox, Google Drive, etc. Sí, pero a mí me gusta usar este método también porque estos archivos de backup son versiones de un fichero y, una vez finalizado, ya no las necesitaré aunque no viene de más tenerlas en una especie de cajón desastre que puedo consultar el día de mañana. Digamos que no quiero ver esos ficheros «temporales» en mis directorios de Dropbox ni GDrive, sino que prefiero almacenarlos en algún lugar que, aunque seguro, es menos accesible (*), porque además, el hecho de tener muchas versiones de un archivo en un directorio y no tener un control luego puede ser un caos.

(*) Lo cuál es cómodo desde un punto de vista organizativo.

Hacer copias de seguridad usando gmail I

Existen muchos mecanismos para hacer copias de seguridad (backups), como pendrives, cd-roms, dvds, almacenamiento en la nube (dropbox, google drive…), pero existe uno muy sencillo que podéis usar en cualquier momento para salvaguardar datos que queréis tener replicados (es decir, queréis tener alguna que otra copia de respaldo por si se pierde/estropea la original) y es usando vuestro correo electrónico.

Evidentemente, me estoy refiriendo a mail en la nube, esto es, gmail, hotmail, o cualquier otro que tengáis con un proveedor y que consultéis y almacenéis en la red. Si lo descargáis con pop3 no os va a servir. Yo voy dar unas ideas basándome en gmail, que es el que uso, pero podéis aplicarlo al que queráis (siempre que tengáis los datos de configuración del servidor de salida -smtp-).

En Gmail podéis crear «etiquetas», que vendría ser algo parecido o que da un resultado similar a «carpetas». En definitiva, no es más que una forma de clasificar vuestro correo. Si además usáis los filtros para que los mails vayan a las etiquetas correspondientes automáticamente, pues ya tenéis un sistema de correo más ordenadito y limpio, que es lo suyo (*).

Una forma obvia es enviar un mail desde vuestra cuenta a vuestra misma cuenta y guardar manualmente el mail en su etiqueta correspondiente. Si ponéis el filtro esto se hará automáticamente, moviendo el mail a una etiqueta llamada, por ejemplo, backup. Para poner el filtro, podéis hacerlo en función del asunto del mail, que podría contener la palabra «backup». Así, «le estáis diciendo» que los mails con origen «mi propia dirección» y cuyo asunto contenga la palabra «backup» que los envíe directamente a la etiqueta «backup». Yo lo tengo así. De hecho, como esa etiqueta la tengo «simplemente» para almacenamiento y no la consulto prácticamente nunca, la pongo al final de todas, ¿cómo? -fácil: nombrándola así «z__backup».

A veces hay archivos e incluso los propios mails que recibimos que queremos tenerlos guardados en algún sitio por si algún día nos hicieran falta. Yo, en estos casos, no creo etiquetas para cada tipo de mail a guardar o para cada tipo de archivo, lo que uso es una etiqueta llamada «0__mi_papelera» en la que meto todos estos mails que puede que un día me puedan hacer falta, donde envío los archivos de copias de seguridad que no creo que necesite pero nunca se sabe…

La llamo «0__mi_papelera» para que aparezca la primera. Así, cuando recibo un mail que quiero enviar a dicha etiqueta, al pulsa en el botón «Mover» de gmail, me aparece la primera y es mucho más rápido.

Hasta aquí, lo que he dicho no tiene mucho misterio, simplemente son formas de sacarle un poco más de partido a gmail. En el siguiente artículo os cuento una forma muy cómoda de enviar archivos que queréis guardar como copia de seguridad.
(*) Yo creo «es lo suyo» pero está claro que es sólo mi opinión. Para mí lo es, porque prefiero tener la bandeja de entrada limpia y los mails almacenados en su lugar correspondiente una vez «procesados». Esto no se aplica a la gente que prefiere tener 2430 emails en la bandeja de entrada (donde intentan convivir correos del banco, de la novia, etc., con otros cientos de mails de publicidad). Es lo bueno del correo electrónico: cada uno tiene una cuenta personal y hace con ella lo que quiere. Es como el que tiene el escritorio de su sistema operativo repleto de iconos en una pantalla de 24 pulgadas de alta definición (o sea, con una densidad de 5 iconos por centímetro ;-P). Estas cosas molan, supongo, porque es como jugar a «dónde está Wally» cada vez que tienes que buscar un documento o acceso directo. Supongo que eso mola (a veces soy un aburrido).

 

Enviando un mail de gmail desde la línea de comandos

Enviar mails desde la línea de comandos de Linux es bastante sencillo. Hay un comando llamado «mail» que hace esto sin problemas. Si nos instalamos un servidor de correo SMTP como postfix, ya lo tendremos.

El problema es que estaremos enviando mails desde un servidor de correo cuyo dominio (el que hayamos puesto nosotros, algo como «micasa.com») o bien no existe o si lo hace no está a nuestro nombre. Si enviáis unos pocos e-mails al día puede que todo vaya bien pero, si enviáis más correos, esto puede ocasionar problemas (por ejemplo, vuestro proveedor de servicio a Internet os pegaría un toque por posible SPAM).

Lo mejor es hacer las cosas bien hechas para evitar problemas (*); en este caso, lo suyo es enviar correos legítimos, desde una cuenta «oficial», de un dominio «oficial» (registrado, vamos). Vamos, que si enviamos un correo desde loquesea@gmail.com, ese correo debería partir del servidor gmail.com, es decir, el servidor de correo de Google.

Para hacer esto desde línea de comandos os recomiendo el comando «mailx», que además nos permite enviar adjuntos.

Vamos a ver cómo usarlo para enviar un mail desde nuestra cuenta de gmail. Lo que vamos a ver es cómo usar mailx para enviar correos desde la línea de comandos usando nuestra cuenta de gmail (a través, por supuesto, de los servidores de Google).

Lo que tenemos que hacer es especificar los distintos parámetros (servidor, puerto, usuario, password…) con la opción -S. Nos quedaría algo así:

mailx -v -s "ASUNTO" -S smtp=smtp.gmail.com:587 -S smtp-auth-user=VUESTRO_USUARIO_DE_GOOGLE@gmail.com -S smtp-use-starttls -S smtp-auth-password=VUESTRO_PASSWORD -S from=VUESTRO_USUARIO_DE_GOOGLE@gmail.com MAIL_DESTINO

Al ejecutar esto os dejará escribir el cuerpo del mensaje. Para finalizar el mail, dar un par de veces a Intro, escribid un punto y darle de nuevo a Intro (es la forma de decirle a mailx que habéis terminado de redactar el mail).

Si queréis hacerlo menos interactivo podéis pasarle el cuerpo del mensaje así:

echo «CUERPO DEL MENSAJE…» | mailx -v -s «ASUNTO»…

Si queréis un cuerpo más completo, con intros y demás, podéis pasarle un archivo (tanto como cuerpo de mensaje como de asunto). También podéis registrar los logs de salida y error por si algo fallara poder estudiar cuál ha sido el problema. Un script que contemple ambas cosas podría quedar así:

DATE=`date +%Y-%m-%d--%H-%M`
if [ $# = '0' ]; then
     echo send_gmail FILE_SUBJECT FILE_BODY \[ FILE_ATTACH \]
elif [ $# > '1' ]; then
     SUBJECT=`cat $1`
     if [ $2 ]; then
        BODY=`cat $2`
     else
        BODY="."
     fi
     ATTACH=$3
     if [ $ATTACH ]; then
        echo $BODY | mailx -v -s $SUBJECT -a $ATTACH -S smtp=smtp.gmail.com:587 -S smtp-auth-user=VUESTRO_USUARIO_DE_GOOGLE@gmail.com -S smtp-use-starttls -S smtp-auth-password=VUESTRO_PASSWORD -S from=VUESTRO_USUARIO_DE_GOOGLE@gmail.com MAIL_DESTINO >/tmp/mail_$DATE.log 2>/tmp/mail_$DATE.err
     else
        echo $BODY | mailx -v -s $SUBJECT -S smtp=smtp.gmail.com:587 -S smtp-auth-user=VUESTRO_USUARIO_DE_GOOGLE@gmail.com -S smtp-use-starttls -S smtp-auth-password=VUESTRO_PASSWORD -S from=VUESTRO_USUARIO_DE_GOOGLE@gmail.com MAIL_DESTINO >/tmp/mail_$DATE.log 2>/tmp/mail_$DATE.err
     fi
fi

Lo he hecho rápidamente, así que se puede mejorar mucho a la hora de tratar los parámetros. De todas formas, así es perfectamente válido (doy fe ;-). A continuación explico cómo funciona.

Lo que hace el script es coger la fecha del sistema (en la variable DATE) para que nuestros archivos de log la tengan incorporada en el nombre de archivo (así es más fácil identificar de cuándo son).

Después, si el número de parámetros es 0 muestro un mensaje de uso correcto del script (cuyo nombre es «send_gmail» en este ejemplo), que básicamente es, el nombre del script, el fichero que lleva el subject del mensaje, el fichero que lleva el cuerpo del mensaje y, opcionalmente, el archivo que queremos adjuntar.

Si el número de parámetros es mayor que 1 (**) el asunto del mensaje (SUBJECT) es el contenido del primer argumento. Si existe un segundo parámetro sería el fichero que contendría el cuerpo del mensaje. Si no existe segundo parámetro se pone un «.» (podemos poner un espacio o una palabra por defecto) porque si no ponemos nada fallará el script.

Si hay un tercer argumento ejecutaremos el comando que hemos visto antes con la opción «-a $ATTACH», que incluirá dicho archivo como adjunto.

Esto os puede venir de perlas para cosas como enviar mails al iniciar el equipo para indicar que está operativo (como vimos en el artículo anterior «Ejecutar scripts al inicio de Linux»), para enviar mails de notificación desde nagios o, como veremos en un artículo posterior, para hacer backups de archivos rápida y cómodamente.

(*) Esto se debería aplicar a todos los aspectos de la vida. Si todo el mundo lo hiciera… irían mejor las cosas, nor?
(**) como mínimo hemos introducido subject y body; si introducimos 3, el tercero es el fichero a adjuntar; a partir del tercer parámetro se ignoran si los hubiera.

Ejecutar scripts al inicio de Linux

A veces es interesante que al arrancar nuestro equipo se ejecuten ciertos scripts.

Si tenemos una distro Ubuntu o basada en ella, podemos usar /etc/rc.local, es decir, meter la llamada a dicho script dentro de este fichero (antes del «exit 0», lógicamente).

Sin embargo, desde que Ubuntu usa Upstart como sistema de arranque no tengo claro que sea una buena forma de iniciar los scripts ya que es posible que no se ejecute correctamente si depende de otros servicios, como podría ser el de red. En otras palabras, que puede que metas un script que haga algo como enviar un mail (en otro artículo veremos este caso) pero que no esté iniciado el servicio de red y no se ejecute. A mí me ha pasado.

Por eso, para estos casos recomiendo que metáis el script dentro de /etc/network/if-up.d. Los scripts que se encuentren en dicho directorio se ejecutarán sí o sí cuando el servicio de red esté operativo.

En openSUSE el directorio es /etc/sysconfig/network/if-up.d.

OJO: los scripts deben ser ejecutables (algo lógico) y no pueden tener extensión, es decir, si tenéis algo como enviar_mail.sh cambiadlo a enviar_mail (me costó un rato de «googleo» para descubrirlo).

En otro artículo veremos cómo enviar precisamente un mail desde un script (usando nuestra cuenta de gmail) para notificarnos cualquier cosa.

Yo, en particular, tengo un script que me envía un mail cada vez que enciendo el PC de casa para saber que está encendido. ¿Para qué me puede servir? Por ejemplo: para saber que el PC está ya operativo tras haberlo encendido remotamente (más info aquí) 😉