Archive
You are currently browsing the archives for the Networking category.
By Jose Antonio Cely Saidiza
Fail2ban ( http://www.fail2ban.org/ ) es una aplicaci?n que se usa para bloquear conexiones remotas despu?s de una cantidad de intentos fallidos. El funcionamiento de Fail2ban es muy simple, comprueba archivos de log y si detecta registros de intentos fallidos, ejecuta autom?ticamente los comandos de IPTables para bloquear al host que esta intentando realizar la conexi?n. Fail2ban soporta muchos servicios como lo son ftp, apache, imap, pop, etc; incluso tambi?n aplicaciones web.
Para este caso documentar? el t?pico escenario, donde tenemos un servidor Linux conectado a internet permanente y por cuestiones administrativas tenemos el servicio SSH abierto a cualquier IP (!!!). Un servidor de este tipo es muy atacado por robots o creckers con t?cnicas de fuerza bruta, usando sencillamente un script que mediante un diccionario de claves o generador de palabras intenta frecuentemente autenticarse como usuario root.
Por ejemplo viendo los logs de un servidor personal que mont? hace poco, v? como tengo miles de intentos de login remoto. Por ejemplo viendo los ?ltimos intentos de login mediante el comando:
# tail /var/log/auth.log
Veo como un hijo de puta con la direcci?n IP 116.31.116.28 se est? intentando conectar como root. Por los tiempos de diferencia entre cada conexi?n de pocos segundos seguramente es un robot. As? pues, a instalar fail2ban!.
Instalaci?n y configuraci?n
Los siguiente comando se ejecutan como usuario root en el servidor. Si usa sudo antepongalo a los comandos.
Instalamos el paquete est?ndar de Debian Jessie estable:
# apt-get install fail2ban
Una vez instalado copiamos el archivo de configuraci?n para crear una configuraci?n local:
# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Ahora editamos el archivo recientemente copiado /etc/fail2ban/jail.local, el archivo es extenso y viene casi listo y documentado. Un par?metro t?pico por ejemplo para cambiar es ?bantime?, que es el tiempo que el host remoto tardar? bloqueado hasta que nuevamente fail2ban permita el intento de conexi?n, en mi caso lo edit? para 1200 segundos, es decir, 20 minutos:
bantime = 1200
Por otro lado, confirm? que el servicio SSH este activado y en el caso de esta versi?n de Jessie viene activado por default la supervisi?n:
[ssh]
enabled = true
Si hicimos alg?n cambio, se puede reiniciar fail2ban mediante el comando:
# service fail2ban restart
Esto es todo, failban inciar? a supervisar y bloquear los servicios que hemos definido. Por ejemplo en la siguiente captura realic? tres intentos intencionalmente fallidos al servidor y vemos como en el tercer intento me bloquea:
Ante este caso solo queda esperar el ?bantime? para poder volver intentar a conectarme. Como vemos muy facilmente se puede aumentar la seguridad de nuestros servidores.
??
?Dudas, comentarios, sugerencias?
Sigueme en twitter?@josecely
By Jose Antonio Cely Saidiza
A la fecha Dropbox no tiene cliente para *BSD, aunque muy solicitado, no hay fechas de RELEASE.
Buscando alternativas en las que no perdiera la sensación de tiempo real con Dropbox en mi Gnome en FreeBSD 9.1, y pensando en no tener que ejecutar comandos constantes para sincronizar, e inspirado en algunas búsquedas; encontré una técnica para que funcione de la manera más transparente Dropbpx en mi Gnome. Supongo con un par de cambios aplica a OpenBSD.
La técnica guerrillera consiste en instalar una máquina virtual (con VirtualBOX, KVM, etc) o usar un computador viejo, y en este montar un Linux y Dropbox, a este combo lo llamaré «servidor Dropbox» (Para Linux si hay daemon oficial para Dropbox). Entonces en FreeBSD solo es montar la partición remota.
Si eres usuario avanzado BSD y lees esto, tal vez te sientas engañado el título del artículo, mis disculpas :)
Hay varias formas de montar la partición remota (NFS, SMB, FUSE, etc); en este caso opté por usar SSHFS (fuse), pues es la más «limpia», por decirlo así, de configurar el pequeño «servidor» Dropbox, solo se instala el sistema base, el servicio ssh y el sistema Dropbox en modo daemon, lo cual es muy «light». Además se puede montar como usuario, nada de editar el fstab o cosas similares.
En mi caso el servidor virtualizado es un i386, con 128Mb RAM, y Debian wheezy y corre como perfectamente bien.
Entonces, primero explicaré como instalar el servidor Dropbox, y luego como configurar FreeBSD para que monte la partición.
Instalando Dropbox en un servidor Linux sin entorno gráfico:
Para el servidor, sirve cualquier Debian básico, entorno mínimo, con sshd. Con el sistema básico, solo hay que seguir las instrucciones para la instalación en la página oficial de www.dropbox.com, con unos pequeños ajustes.
TODOS estos pasos se ejecutan como usuario (en mi caso josecely), ajustenlo a su usuario y por favor… no usen el root para estos menesteres!
Descargamos el instalador de Dropbox de https://www.dropbox.com/install2.
En mi caso para el «servidor Dropbox» virtualicé una máquina de 32 bit, por lo tanto descargue
$cd ~ && wget -O – «https://www.dropbox.com/download?plat=lnx.x86» > dropbox.tar
Descomprimo el instalador:
$tar xf dropbox.tar
Eso es todo, al descomprimir crea una carpeta oculta llamada
~/.dropbox-dist/
En esta carpeta esta el ejecutable y archivos de configuración, no hay que compilar, en hora buena!
Ahora a configurar con su cuenta de Dropbox,. Para esto ejecuto el demonio Dropbox por primera vez manualmente, para que me cree el vínculo temporal de configuración y autorización del servdor.
$~/.dropbox-dist/dropboxd
El comando me informa:
Este cliente no está vinculado a una cuenta…
Visita https://www.dropbox.com/cli_link?host_id=xxxxxxxxxxxxxxxxxxxxxxxxxxe para vincular este equipo.
Tal cual como lo dice, copie y pegué el vínculo en un navegador, ingresé la contraseña de mi cuenta en Dropbox
De esta manera se autorizó la cuenta para el sevidor «El cliente se vinculó correctamente. Te damos la bienvenida, Jose Antonio.»
Ahora descargo el script CLI oficial de Dropbox, una herramienta muy útil para administrar Dropbox desde el shell.
$wget https://www.dropbox.com/download?dl=packages/dropbox.py
Le asigno permisos de ejecución:
$chmod +x dropbox.py
Lo ejecuto para confirmar que funciona correctamente:
$./dropbox.py
Dropbox command-line interface
commands:
Note: use dropbox help <command> to view usage for a specific command.
status get current status of the dropboxd
help provide help
puburl get public url of a file in your dropbox
stop stop dropboxd
running return whether dropbox is running
start start dropboxd
filestatus get current sync status of one or more files
ls list directory contents with current sync status
autostart automatically start dropbox at login
exclude ignores/excludes a directory from syncing
lansync enables or disables LAN sync
Por ejemplo para arrancarlo ejecuto:
$~/dropbox.py start
Starting Dropbox…Done!
Como ya esta autorizada la máquina y tenemos un útil scrip CLI, lo siguiente es configurar el «servidor» para que arranque siempre Dropbox como el usuario. (No olvidar ajustarlo a su usuario). De las cincuenta mil formas de hacerlo, lo agregaremos al arranque CRON:
$crontab -e -u josecely
Agregamos la linea
@reboot ~/dropbox.py start
Reiniciamos el servidor, y comprobamos que arrancó el demonio Dropbox bajo el respectivo usuario, esto lo podemos comprobar con:
$ps aux | grep dropbox
josecely 2900 37.0 15.4 267652 56948 ? Ssl 01:27 1:18 /home/josecely/.dropbox-dist/dropbox
Montando la carpeta remota Dropbox en FreeBSD
Secure SHell FileSystem (SSHFS) es un sistema de archivos para FreeBSD, Linux y otros. Permite montar de modo seguro (sobre ssh) un directorio remoto, como si fuera local, además del lado del servidor, no necesita instalar ni configurar nada especial, el módulo FUSE solo se necesita en el cliente que va a montar el directorio remoto. El servidor remoto solo necesita tener el servicio sshd corriendo.
Los siguientes comandos y configuraciones se probaron en FreeBSD 9.1.
Como usuario root, en la máquina FreeBSD agregamos el package sshfs:
#pkg_add -r fusefs-sshfs
Editamos el archivo /etc/sysctl.conf, agredando la línea:
vfs.usermount=1
Editamos el archivo /etc/rc.conf, agredando la línea:
fusefs_enable=»YES»
Ahora agregamos el usuario que montará la partición al grupo operator, para que quede habilitado para montar y desmontar (No olvidar ajustarlo a su usuario):
#pw usermod josecely -G operator,wheel
Sería prudente, un reinicio:
# reboot
Una vez reiniciado, como usuario en la máquina FreeBSD, creamos el directorio para montar la carpeta Dropbox:
$ cd ~
$mkdir Dropbox
Y viene la magia!, montamos la carpeta remota del «servidor» Dropbox.
$ sshfs -o idmap=user josecely@10.0.0.4:/home/josecely/Dropbox Dropbox
Nótese el «-o idmap=user», es necesario para evitar errores del tipo «Bad file descriptor».
Ingresamos la contraseña del usuario remoto, y listo, la carpeta remota se ve como local, y es transparente para nuestro sistema operativo!
Podemos automatizar aun más, por ejemplo creando un par de llaves para que no pida contraseña, y pegando el comando de montaje al arranque de Gnome.
Dudas, comentarios, sugerencias?
Sigueme en twitter @josecely
——
Links
http://www.freebsd.org/
http://forums.freebsd.org/showthread.php?t=36449
By Jose Antonio Cely Saidiza
< offtopic> Retomando este abandonado Weblog, regreso con un artículo de algo poco documentado, para la élite :D, espero no haber perdido el tono a veces ácido y sarcástico de antiguos tutoriales, claro que es con el fin que no sean aburridos ñ_ñ
Tal vez deje de documentar Linux, pues ya es muy usado en la industria, y Ubuntu facilitó las cosas para el escritorio (cosas que me hacen sentir muy bien), pero… quiero ser siempre el chico raro, el de la minoría ;), y linux ya no lo es!. No solo eso, algunos clientes nos piden soluciones sobre este sistema (OpenBSD), dada su seguridad de facto cuando se maneja información sensible (Ej. grandes ISP, la industria del petróleo, etc.).</offtopic>
OpenBSD
OpenBSD es una leyenda en cuanto a seguridad informática nativa en el sistema operativo, y que mejor descripción como lo dice el primer parrafo en su página (http://www.openbsd.org/):
Pufffy, la mascota de OpenBSD
«El proyecto OpenBSD produce un sistema operativo LIBRE de tipo Unix, multiplataforma y basado en 4.4BSD. Nuestros esfuerzos se concentran en la portabilidad, estandarización, corrección, seguridad proactiva y criptografía integrada«.
Estas dos últimas palabras «criptografía integrada«, no consiste solo en encriptar fuertemente contraseñas y otras yerbas!… consiste en toda una serie de sistemas y subsistemas (OpenSSH, PRNG, hash functions, Componentes criptográficos por hardware, etc) que funcionan orquestadamente.
En la documentación aparece la pregunta, ¿Por qué incluimos criptografía?, con su merecida y modesta respuesta «because we can.».
Estados Unidos y otros paises (China, Rusia, Irán, Irak, Myanmar, etc.) tienen políticas «raras» en cuanto a la exportación/importación de software que maneje algún tipo de criptografía, Incluso en Estados Unidos se específica un límite en la cantidad de bits para RSA!, pero mejor este tema interesante y político podría ser asunto de otro artículo.
Afortudamente el proyecto Open BSD es Canadiense, y esas políticas raras no aplican.
http://www.efc.ca/pages/doc/crypto-export.html
Para finalizar la introducción no sobra decir que el equipo de OpenBSD, también es el autor de SSH, con su legendario proyecto OpenSSH, que esta en todas la versiones de Linux, *nix.
http://www.openssh.com/
Gracias señores, SSH es mi pan de cada día, no concibo el trabajo sin él.
¿ Por que servidor web verdaderamente seguro ?
Así como en la industria al combo Linux, Apache, MySQL y PHP se le conoce como LAMP, podemos llamar a este combo OAMP.
- OpenBSD: Sistema operativo descrito anteriormente como seguro. Configuraciones por defecto seguras (Ej. ssh no permte root remoto). entre otros.
- Apache: Instalado en modo chroot jail (más detalles abajo), entre otros.
- MySQL: Configurado en modo secure
- PHP: El mismo de siempre ¬¬
Así pues tenemos un gran márgen de seguridad al inicio. Sin embargo a veces no es suficiente, todo depende de una buena admnistración.
Instalando OpenBSD
Esto es de las cosas que me gustan de OpenBSD y FreeBSD, es la documentación de calidad y que esta unificada en el sitio oficial. Nada de rebotar en miles de páginas como pasa en Linux, algunas veces contradiciendose entre ellas por apoyar su distro de turno O.o!
La documentación sobre instalación esta en (No profundizaré mucho en el tema de instalación):
http://www.openbsd.org/faq/faq4.html.
Para este tutorial usé la imágen de CDROM de :
http://mirror.esc7.net/pub/OpenBSD/5.2/i386/install52.iso
Pueden descargarla y quemarla en un CDROM como acostumbren hacerlo para estos menesteres ;).
Una vez con el CDROM en el servidor a instalar, solo es arrancar la máquina y tenemos un bonito y espartano arranque Unix!
Inicio instalador
Si señores, solo hay que leer y seguir los pasos, en mi caso, detectó todo como debía ser, tarjeta de red, dhcp, disco duro, etc. casi que el 95% de las opciones por default funcionaron!
OpenBSD instalando paquetes
Una vez instalado, hay que reiniciar el sistema con el clásico comando:
# reboot
Reboot final en la instlación de OpenBSD
Y listo, una vez reiniciado tenemos un bonito BSD, con el clásico XDM… a que mola!
XDM en OpenBSD
En realidad no necesitamos el entorno gráfico para el servidor web verdaderamente seguro, solo lo instalé por impresionar a las chicas.
Paquetes
Los paquetes son los binarios pre-compilados por terceros de algunos de los programas más utilizados (http://www.openbsd.org/faq/faq15.html).
Cada paquete es un archivo con extensión .tgz que incluye información de dependencias y scripts para instalar y desinstalar, para manejarlos se emplean los programas pkg_add, pkg_delete, pkg_info y pkg_create.
El programa pkg_add instala un paquete y todos los que este requiera. Los descargarga de lo(s) repositorio(s) especificada(s) en la variable de entorno PKG_PATH, y en las rutas especificadas en el archivo /etc/pkg.conf
Instalando los paquetes para el servidor Web
En este caso usarmos los repositorios oficiales de BSD.
Para esto ejecutamos como root en el servidor:
# echo installpath=ftp://ftp5.usa.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(uname -m) | sudo tee /etc/pkg.conf
Una vez agregdo el repositorio, ya podemos empezar a instalar paquetes
1. Apache
Ejecutamos:
# pkg_add apache-httpd
2. PHP-MySql
Ejecutamos:
# pkg_add php-mysql
El cual nos pregunta:
# pkg_add php-mysql
Ambiguous: choose package for php-mysql
a 0:
1: php-mysql-5.2.17p6
2: php-mysql-5.3.14p0
Your choice: 2
Seleccionamos la opción 2.
Cuando termine de descargar e instalar, ejecutamos los siguientes comandos
# cp /var/www/conf/modules.sample/php-5.3.conf /var/www/conf/modules/php.conf
# cp /etc/php-5.3.sample/mysql.ini /etc/php-5.3/mysql.ini
3. MySql Server
Ejecutamos:
# pkg_add mysql-server
Cuando termine de descargar e instalar, ejecutamos los siguientes comandos
# /usr/local/bin/mysql_install_db
# /usr/local/share/mysql/mysql.server start
# /usr/local/bin/mysqladmin -u root password ‘your-password’
Obviamente se debe cambiar your-password por algo más seguro!
4. Aseguramos MySql
Ejecutamos:
# /usr/local/bin/mysql_secure_installation
El anterior script, hace los cambios pertinentes que todo servidor de producción debe tener respondiendo a las siguientes preguntas:
Remove anonymous users? [Y/n]
Disallow root login remotely? [Y/n]
Remove test database and access to it? [Y/n]
Reload privilege tables now? [Y/n]
Recomendaría SI (Y) a todo.
5. PhpMyAdmin
Ejecutamos:
#pkg_add phpMyAdmin
Cuando termine de descargar e instalar, ejecutamos los siguientes comandos
# cp /etc/php-5.3.sample/gd.ini /etc/php-5.3/gd.ini
# cp /etc/php-5.3.sample/mcrypt.ini /etc/php-5.3/mcrypt.ini
# cd /var/www/htdocs
# ln -s ../phpMyAdmin /var/www/htdocs/phpMyAdmin
Comunicando Apache con MySQL
Apache esta enjaulado por defecto (chroot jail), que bonito!, otra muestra más de la seguridad, esto quiere decir que Apache NO puede ver directorios fuera de su entorno de usuario, y mucho menos comunicarse con MySQL (Que obviamente también esta enjaulada), es imposible que los dos se comuniquen.
Entonces es necesario mover el archivo de la comunicación de MySQL /var/run/mysql/mysql.sock :
Para esto, creamos los directorios:
# mkdir /var/www/var/
# mkdir /var/www/var/run/
# mkdir /var/www/var/run/mysql/
Y editamos el archivo /etc/rc.local
# vi /etc/rc.local
Agregando las siguientes líneas
if [ -x /usr/local/bin/mysqld_safe ]; then
echo -n » mysqld»
/usr/local/bin/mysqld_safe –user=_mysql –log=/var/log/mysqld
sleep 4
rm -f /var/www/var/run/mysql/mysql.sock
ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock
fi
Iniciando el servidor OAMP automáticamente
Editamos el archivo /etc/rc.conf.local:
# vi /etc/rc.conf.local
Agregando las siguientes líneas
mysqld_flags=»»
httpd_flags=»»
pkg_scripts=»mysqld»
Sería prudente, un reinicio:
# reboot
Probando el servidor
La ruta por defecto para el contenido del servidor web es /var/www/htdocs/
Podemos crear un script de prueba, con el comando.
# echo «< ?php phpinfo(); ?>» | sudo tee /var/www/htdocs/phpinfo.php
El cual debe responder desde un navegdor a la dirección http://sudirecionip/phpinfo.php
En mi caso la dirección de mi intranet http://10.0.0.228/
Phpinfo en OpenBSD
Lo mismo para PhpMyAdmin, a la dirección http://sudirecionip/phpMyAdmin/index.php
En mi caso http://10.0.0.228/phpMyAdmin/index.php
PhpMyAdmin en OpenBSD
——
Dudas, comentarios, sugerencias?
PD.
El servidor web verdaderamente seguro, es para cosas verdaderamente serias. Ej. no pretendas instalar Joomla y catapum! Joomla se volvio seguro XD! Una cosa es la seguridad del servidor, otra cosa una aplicación web vulnerable, y que mejor ejemplo que Joomla para aplicación web vulnerable!. Lo mismo sucede con las contraseñas, puedes tener el mejor BSD, con los últimos guariches, pero si tu contraseña es 123456… mejor ni hablemos….
Sigueme en twitter @josecely
——
Links
http://www.openbsd.org/
http://www.asep.us/2013/01/27/openbsd-5-2-web-server-apache-mysql-php/
http://www.serverschool.com/dedicated-servers/what-is-a-chroot-jail/
By Jose Antonio Cely Saidiza
El siguiente chicharrón me sucedió con un sistema webmail que vendí a un cliente, todo funcionó sin problemas durante meses, pero de un día para otro me comentaron «Los correos a veces no salen», y peor aun «donde esta la carpeta de correos Enviados? en algunas cuentas no aparece!».
Entorno del chicharron:
1 servidor Debian Lenny, con exim4 instalado, vexim como administrador de cuentas de correo, courier para extensiones IMAP y POP3, y una aplicación web que como módulo de correo usa una versión modificada de Telaen webmail.
Conexión a internet corporativa con mediacommerce.
Problema:
* Correos que misteriosamente no son enviados
* Algunas cuentas de correo no cuentan con las carpetas estándar del sistema
Las palabras «misteriosamente» y «algunas», son palabras enmarcan esto como un chicharron!
Troubleshooting:
– Telnet a el servidor a los puertos 110 y 143 – todo OK
– Revisar el código fuente de Telaen – horas perdidas, pero todo OK, sin embargo se detectaron algunas falencias
– Revisar /var/log/exim4/mainlog – Gracias a esto identifique el problema «(-52): Retry time not yet reached»
– Revisar los Maildir de los usuarios que en el webmail no figuran con la carpetas de sistema (Enviados, Borrador, Papelera) y efectivamente no existen.
Solución:
Para los correos que aleatoriamente no salen, gracias a:
http://www.exim.org/exim-html-3.20/doc/html/spec_33.html
(donde dice «timeout_DNS: DNS lookup timed out «)
Bingo! ingrese al servidor por ssh y comprobé que el servidor no resolvía nombres (ping www.google.com , host not found), la IP que tenia configurada como servidor de nombres «200.24.7.20» no funciona, esta muerto ese servidor DNS!, entonces solo fue agregar un par de DNS, comprobar que el servidor resuelve nombres y volá! todos los correos salen como magia!
Para las carpetas del sistema que no funcionan, se ingreso con otro webmail (squirrelmail) y en este si aparecían, luego se volvió a ingresar con Telaen y si aparecieron, conclusión, Telaen NO crea las carpetas imap estándar cuando no las detecta, tampoco lo hace el administrador web vexim. Por lo tanto se debe usar otro webmail. O también se pueden crear con comandos en el servidor, con el comando maildirmake dentro de la carpeta Maildir del usuario, ej:
# maildirmake .Sent
# chown -R vexim:vexim .Sent/
Recomendaciones:
– Siempre iniciar leyendo los logs del sistema! si lo hubiese hecho así en lugar de ir apresuradamente a ver codigo fuente, me hubiese ahorrado por lo menos una hora :(
– Comprobar que el servidor resuelve nombres :S
– Migrar a otro webmail o actualizar Telaen webmail
By Jose Antonio Cely Saidiza
El presente tutorial explica como configurar en servidor de correo por default en Debian (exim), par a que envíe correos a través de una cuenta de gmail. (smarthost on email Google servers).
No es necesario tener IP publica, solo tu cuenta de Gmail!, y un sistema operativo decente (Debian Lenny).
Entre las utilidades, podemos citar la creación de scripts que nos envien información del estado de la máquina. También se podría aprovechar para que nuestros scripts en php envíen email, o aplicaciones que hacen uso intensivo de correo (Ej. Nagios, Asterisk, Gforge, etc).
Además, tienes el registro de email enviados, bien sea con los logs, o en los correos enviados de tu cuenta de Gmail ;) .
INSTALACION Y CONFIGURACION
Ejecutamos:
dpkg-reconfigure exim4-config
(Si no esta instalado, lo sintalamos con apt-get install exim4)
En la reconfiguración/instalación seleccionamos:
* El correo se envía mediante un «smarthost»; se recibe a través de SMTP
* Nombre del sistema de correo: tudominio.xxx
* Direcciones IP en las que recibir conexiones SMTP entrantes: 127.0.0.1
* Otros dominios para los que se acepta el correo: en blanco
* Máquinas para las cuales reenviar correo: en blanco
* Direccion IP o nombre del equipo (smarthost) saliente: smtp.gmail.com::587
* Desea ocultar el nombre de correo local en los mensajes salientes? NO
* Limitar el numero de consultas DNS (Marcación bajo demanda)? NO
* Dividir la configuración en pequeños ficheros? Sí
Ahora editamos el archivo /etc/exim4/passwd.client
vi /etc/exim4/passwd.client
# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:login:password
gmail-smtp.l.google.com:yourAccountName@gmail.com:y0uRpaSsw0RD
*.google.com:yourAccountName@gmail.com:y0uRpaSsw0RD
smtp.gmail.com:yourAccountName@gmail.com:y0uRpaSsw0RD
Cambiamos permisos del archivo
chown root:Debian-exim /etc/exim4/passwd.client
Reiniciamos el servidor de correo
/etc/init.d/exim4 restart
Con esto hemos finalizado la configuración, ahora nuestro sistema tendrá la capacidad de enviar email!
EJEMPLO DE USO
* No hay nada mas elegante que enviar un email a traves del shell XD, con el comando mail:
mail jose.cely@xxxx.xxx
Subject: Hola, email enviado desde el Shell
Esto es el cuerpo del mensaje. Es una prueba de mailx.
Un mensaje se acaba con un punto (.) al principio de línea.
.
Cc:
Se podrían hacer scripts para que nos envíen información automática y periódica del estado del estado de la máquina donde corre el servidor!
Para depurar errores en configuraciones, o ver en más detalle que esta pasando, no existe mejor alternativa que ver los logs!
tail /var/log/exim4/mainlog
Dudas, comentarios, sugerencias?
Consultor, unixero, desarrollador.