La primera vez que usé Docker no me convenció demasiado, porque me parecía que las imágenes a partir de las cuales se crean los contenedores eran muy pesadas. Por ejemplo, mysql pesa 603 MB, nginx 192 MB y openvpn 708 MB. Por eso lo veía como un desperdicio de espacio en disco y de recursos. Sin embargo, a medida que fui profundizando y creando mis propias imágenes, me di cuenta de que pueden pesar muchísimo menos si se optimizan correctamente.
Ese descubrimiento me convirtió en un fanático: hoy prácticamente no hay un solo servicio en mi servidor que no corra dentro de un contenedor. Docker ofrece comodidad y seguridad, algo que para mí es esencial. Combinarlo con un firewall que cierre todos los puertos de los contenedores y deje pasar únicamente los necesarios me parece una de las formas más eficientes de gestionar un servidor web. Además, si las imágenes están lo suficientemente optimizadas, todo funciona muy rápido y se siente ligero.
Instalar docker resulta muy fácil usando alguno de los gestores de paquetes disponibles en internet. Luego de instalar hay que hacer una serie de pasos para que quede completamente listo.
sudo groupadd docker
sudo usermod -aG docker $USERSe puede verificar si los cambios se aplicaron correctamente corriendo el container de docker hello-world
docker run hello-worldsudo chown "$USER":"$USER" /home/"$USER"/.docker -R
sudo chmod g+rwx "$HOME/.docker" -RLa documentación de docker tiene una página en su documentación dedicada a la postinstalación.
A continuación se muestran algunos de los comandos qu me parece útil guardar para posterior uso.
Los contenedores permiten entrar a sus respectivas terminales, lo cual puede ser muy útil para realizar modificaciones internas en el sistema.
docker exec -it contenedor shEjecutar un comando dentro de una imagen puede resultar muy útil. En mi caso particular, me ha servido para inspeccionar distintas partes de la imagen de Alpine y, así, contar con una base sólida que oriente la creación de imágenes derivadas y contenedores.
docker run --rm <imagen> <comando>El soporte multiusuario es una de las características más interesantes de Linux y, a la vez, una de las que más suele pasarse por alto. Hasta ahora me he limitado a mi usuario personal y al superusuario, sin reparar en lo que aporta crear usuarios adicionales y afinar la gestión de permisos. Pero a medida que administro mi servidor web, voy entendiendo por qué conviene aislar y separar determinados elementos por motivos de seguridad, orden y control interno. Me interesa, sobre todo, añadir capas de protección que impidan eliminar o modificar archivos que pertenecen a servicios concretos.
A. Hay cuatro conceptos fundamentales:
B. Los usuarios y grupos del sistema están vinculados a un número que los identifica (identificador):
C. En cuanto a los permisos:
D. Detalles importantes:
Los comandos relacionados a la administración de usuarios/grupos/permisos provienen de diferentes proyectos GNU. A continuación un listado con los más comunes mencionando de qué proyecto provienen.
Si bien el Linux Standard Base es un proyecto que no se sigue actualizando, algunas de sus definiciones siguen teniendo relevancia. En el documento se definen que rangos de GUID y UID deberían usar para cada caso. Aunque estos rangos ya no son usados, sino que se alinearon con Debian/Ubuntu. Sin embargo encuentro importante mencionar el LSB porque fue un intento de estandarizar las diferentes distros.
0-99 -----------> Reservado para el Sistema Base (kernel, init, etc)
100-999 -------> Aplicaciones y Servicios (mail, www-data, docker...)
1000+ ---------> Usuarios HumanosRecuerdo que, cuando empecé a usar GNU/Linux de niño, estaba convencido de que lo mejor era ponerle 777 a todo. ¿Qué mejor que el número de la suerte del casino para los permisos de mis archivos? Además, me parecía la forma perfecta de simplificar de golpe todo aquel enredo de los permisos.
Ahora que tengo un servidor con varios servicios corriendo, lo veo de otra manera. Para separar los privilegios de cada servicio y protegerme tanto de mis propios errores como de posibles problemas de seguridad, me parece buena práctica usar 750 en las carpetas y 640 en los archivos. Así, el usuario del servicio puede leer y editar, mientras que mi usuario personal solo puede leer, pero no modificar. De este modo evito que un script mal escrito o un comando equivocado, lanzados desde mi cuenta personal, acaben provocando un desastre.
Me parece importante hacer un listado con comandos que voy usando y que son importantes de recordar.
chmod y chown permiten cambiar los permisos en todos los subdirectorios usando -R
chown -R terryDavid:terryDavis ./
chmod -R 777 ./Para listar usuarios y grupos es necesario imprimir en pantalla dos archivos.
cat /etc/passwd # Usuarios
cat /etc/group # GruposMe parece que Markdown es uno de los formatos más inteligentes que se han inventado. Formatos como docx o pdf son excelentes para seguir formalidades o mostrar información de manera más tradicional. Sin embargo, para crear los esqueletos, los primeros borradores o tomar notas no me parece que sea tan inteligentes. Tener demasiadas opciones desvía los pensamientos de lo que es realmente importante tal como lo es el contenido y la jerarquía de las ideas. Si bien en herramientas word se puede jerarquizar y a través de (decir cómo jerarquizar), se pierde demasiado tiempo en cosas que no son importantes.
Lo mismo ocurre con las presentaciones en PowerPoint. Se pierde mucho foco y claridad en ver los estilos del titulo de los subtitulos etc. También moviendo los elementos, y crear diferentes estilos de los cuales unos apliquen para unas diapositivas y otros para otras resulta contraintuitivo y poco cómodo.
Marp (Markdown Presentation Ecosystem), un ecosistema completo para crear presentaciones a partir de Markdown, escrito en Typescript/Javascript, que se forma de las siguientes capas:
La herramienta está disponible en brew, por lo cual se puede instalar con:
brew install marp-cliMarp convierte los MD/CSS a HTML/CSS primero usando la implmentación de Marp Core, que renderiza cada diapositiva como un svg separado un o de otro y le agrega un visualizador de disapositivas en javascript. Convertir a HTML se hace usando:
marp input.md output.htmlLos formatos otros disponibles son:
--pdf
--pptx
--pptx-editableCuanto se exporta en pptx solo incrusta las imagenes de la composición completa en vez de separar los diferentes elementos. Sin embargo, hay una forma experimental de exportar a PPTX editable usando el motor de libreoffice.
Teniendo en cuenta que la exportación a PPTX aún es poco fiable, el flujo que estoy usando actualmente para convertir de marp a PPTX es el siguiente:
markdown -> marp -> html \ markdown -> claude -> python-script -> pptx
Parece ser que el editor de texto más famoso hoy en dia es Visual Code Studio. Personalmente no me gusta, me parece que se siente innecesariamente pesado. Creo que no fue una buena decisión por parte de los desarrolladores el usar electron, no se si se necesite todo un navegador para un editor de texto. Existen otras alternativas, una de la que más me gusta es Sublime Text, pero es de pago. De las Open Source, no veo ninguna que me parezca suficientemente satisfactoria.
Vim tiene como ventaja que se puede usar directamente desde la terminal, por lo que se puede usar directamente desde servidores remotos de manera muy fácil, es minimalista, tiene muchísimos plugins y es ligero. Por eso elijo el editor de Bram Moolenaar sobre cualquier otra alternativa. Además es interesante su licencia de charityware
Vim es un editor de texto que tradicionalmente se utiliza dentro de una termina. Sin embargo, existen alternativas que permiten ejecutarlo como una aplicación independiente, con su propia ventana gráfica, sin necesidad de abrir antes una terminal. MacVim es una de las más populares en macOS: conserva intacto el motor y el comportamiento de Vim, pero lo envuelve en una interfaz nativa del sistema.
Me gusta MacVim precisamente por esa integración con el entorno gráfico. Puedo abrir archivos directamente desde el Finder haciendo doble clic o arrastrándolos sobre el icono de la aplicación, asociar ciertos tipos de archivo para que se abran con él por defecto, y aprovechar comodidades propias del sistema, como los menús, el portapapeles compartido o el desplazamiento con el ratón, sin renunciar a los atajos y modos de edición que hacen a Vim tan eficiente.
Es cierto que también podría conseguir un comportamiento parecido desde la terminal mediante un pequeño script que lanzara Vim con el archivo deseado. Aun así, prefiero tener las aplicaciones bien separadas: la terminal para sus tareas y el editor en su propia ventana. Esta separación me aporta más orden, hace el flujo de trabajo más claro y me permite tratar cada herramienta según su propósito, sin mezclar contextos.
En Vim, los temas se aplican mediante el comando colorscheme. Un colorscheme es un conjunto de definiciones que establece los colores del texto, el fondo y el resaltado sintáctico de los distintos elementos. Para listar los esquemas disponibles actualmente en Vim, escribe lo siguiente en el modo de línea de comandos:
:echo globpath(&rtp, "colors/*.vim")Para instalar un tema, basta con copiar su archivo en la carpeta .vim/colors. Cada tema es un archivo de texto con extensión .vim. En este momento estoy usando el tema paper, que obtuve de este repositorio.
Una vez copiado el archivo, puedes activar el tema de forma temporal con:
:colorscheme paperPara que el cambio sea permanente, añade ese mismo comando a tu archivo .vimrc.
Vim carga los plugins basándose en una variable llamada runtimepath (abreviada rtp), que no es más que una lista de directorios donde el editor busca scripts de configuración, plugins, documentación, sintaxis y demás. Al arrancar, Vim recorre cada uno de esos directorios y carga automáticamente ciertos archivos según una estructura de carpetas estándar dentro de ~/.vim/:
~/.vim/
├── plugin/ ← scripts que se cargan siempre al inicio
├── autoload/ ← funciones que se cargan solo cuando se invocan
├── ftplugin/ ← scripts según el tipo de archivo (filetype)
├── syntax/ ← reglas de resaltado de sintaxis
├── doc/ ← documentación de ayuda
└── colors/ ← esquemas de colorCualquier archivo .vim que se coloque en ~/.vim/plugin/, por ejemplo, se ejecutará automáticamente cada vez que se abra el editor. Ese es el mecanismo base, y es el mismo que hace funcionar a los temas descritos en la sección anterior.
Para instalar un plugin de forma manual hay que copiar los archivos en las carpetas correspondientes dentro de ~/.vim/. Si un plugin trae un archivo en plugin/, otro en autoload/ y otro en doc/, hay que poner cada parte en su carpeta. Esto produce que con muchos plugins instalados, archivos de diferentes plugins se mezclan en los mismos directorios, provocande que actualizar o desinstalar sea una tarea tediosa.
Desde Vim 8 existe un sistema nativo de paquetes que ya no necesita ningún gestor externo. Funciona con esta estructura:
~/.vim/pack/cualquier-nombre/
├── start/ ← plugins que se cargan automáticamente al inicio
│ ├── nerdtree/
│ └── vim-fugitive/
└── opt/ ← plugins que se cargan bajo demanda con :packadd
└── algun-plugin/Aquí cada plugin vive en su propia carpeta, normalmente clonada con git, lo que resuelve el problema de los archivos mezclados. Instalar un plugin es tan sencillo como clonarlo dentro de start:
cd ~/.vim/pack/mis-plugins/start
git clone https://github.com/preservim/nerdtreeDesinstalarlo es solo borrar esa carpeta, y para actualizarlo basta con hacer git pull dentro de ella.
vim-plug es uno de los gestores más populares, es un único archivo de script (plug.vim), muy ligero, que instala los plugins en paralelo y permite cargarlos de forma perezosa solo cuando se necesitan, mejorando el tiempo de arranque.
Con vim-plug, los plugins se declaran en el archivo .vimrc dentro de un bloque, en lugar de gestionarlos a mano:
call plug#begin('~/.vim/plugged')
Plug 'tpope/vim-fugitive'
Plug 'preservim/nerdtree'
call plug#end()Lo que hace call plug#end() es registrar cada plugin y añadir su carpeta al runtimepath, de modo que Vim sepa que existen; no los descarga, pues para ello hay que ejecutar :PlugInstall y que los archivos estén ya en ~/.vim/plugged/. Tal como está escrito, todos los plugins se registran durante el arranque, sin carga perezosa.
La directiva Plug admite, sin embargo, varias maneras de controlar cuándo se carga cada plugin. En su forma más simple solo recibe el repositorio, pero acepta opciones adicionales entre llaves:
" Forma básica: se registra al iniciar Vim
Plug 'tpope/vim-fugitive'
" Carga diferida hasta usar un comando concreto
Plug 'preservim/nerdtree', { 'on': 'NERDTreeToggle' }
" Carga diferida hasta abrir cierto tipo de archivo
Plug 'fatih/vim-go', { 'for': 'go' }
" Fijar una rama, etiqueta o commit del repositorio
Plug 'nsf/gocode', { 'branch': 'master' }
Plug 'fatih/vim-go', { 'tag': '*' }También es posible apuntar a un directorio local en lugar de a un repositorio remoto:
" Instalar desde un directorio local en lugar de un repositorio remoto
Plug '~/mis-plugins/plugin-propio'Este último caso merece una aclaración, cuando se pasa una ruta local a Plug, el plugin no se copia ni se clona en ningún sitio: vim-plug se limita a añadir ese directorio tal cual al runtimepath, de modo que el plugin se usa directamente desde la carpeta donde ya está. Por eso :PlugInstall y :PlugUpdate lo ignoran, pues no hay nada que descargar ni actualizar desde un repositorio remoto. Esta forma resulta especialmente útil al desarrollar un plugin propio: basta con editar los archivos en el directorio de trabajo y reiniciar Vim para probar los cambios, sin pasos intermedios de instalación. Conviene distinguirla de la forma habitual Plug 'usuario/repo', donde el repositorio remoto sí se clona dentro de ~/.vim/plugged/ como una copia que gestiona vim-plug, mientras que la ruta local deja intacta la carpeta original.
Además, desde el modo de linea de comandos de Vim, se tienen las siguientes instrucciones:
:PlugInstall instala los plugins de la lista:PlugUpdate los actualiza todos a la vez:PlugClean elimina los que ya no figuran en la lista:PlugStatus muestra su estado
En resumen, sin gestor uno mismo hace el trabajo de git y de ordenar las carpetas; con vim-plug basta con declarar la lista de plugins en la configuración y el gestor se ocupa de lo demás. Es un buen ejemplo del espíritu de Vim: una base minimalista que se puede usar tal cual o ampliar tanto como uno quiera.A continuación una tabla con los plugins que uso
| Plugin | Descripción | Link Repositorio |
|---|---|---|
| preservim/nerdtree | Explorador de archivos | Link |
| KabbAmine/vCoolor.vim | Selector de Colores | Link |
Me parece una excelente práctica tener todos mis proyectos y trabajos respaldados en un servidor remoto. Para mis proyectos personales generalmente uso GitHub, dejando los repositorios abiertos a la comunidad. Sin embargo, no quiero mezclar mis proyectos personales y Open Source con aquellos que corresponden a servicios que ofrezco a otros. Para este segundo caso, la mejor solución es usar mi propio servidor como servidor Git, haciendo los push directamente allí. Las ventajas que esto me ofrece son: una mayor autoridad sobre mis propios datos, un control de acceso personalizado por si en el futuro quiero colaborar, y una mayor personalización.
Primero es importante tener en cuenta que Git permite conectarse sin credenciales usando el protocolo git://, que usa el puerto 9418 por defecto. De esta manera cualquier usuario podría clonar los repositorios sin restricciones. Para el uso que yo le voy a dar no usaré nunca el protocolo git://, sino que en cambio usaré Git sobre ssh, que viene habilitado por defecto. Usando ssh no se necesita tener ningún daemon ejecutándose en segundo plano, ya que los comandos se ejecutan en el servidor vía ssh usando git-shell como intérprete, que es mucho más seguro que bash. Git también permite escuchar a través del protocolo https:// con credenciales, pero usar ssh resulta mucho más sencillo, por lo cual descartaré esa opción.
Crear el usuario dedicado para Git. El hecho de que sea un usuario dedicado lo hace mucho más seguro. Además, al usar git-shell como intérprete en lugar de bash, no puede usarse para administrar el servidor remotamente.
sudo useradd -m -s /usr/bin/git-shell gitCrear la carpeta para las claves SSH y el archivo authorized_keys. Es importante que authorized_keys exista como archivo antes de añadir claves, de lo contrario algunos sistemas lo crearán como directorio y la autenticación no funcionará.
mkdir /home/git/.ssh
chmod 700 /home/git/.ssh
touch /home/git/.ssh/authorized_keys
chmod 600 /home/git/.ssh/authorized_keysCambiar el propietario de /home/git/ para añadir una capa extra de seguridad, y crear la carpeta repos.
sudo chown root:root /home/git
sudo chmod 711 /home/git
sudo mkdir /home/git/repos
sudo chown git:git /home/git/reposDeshabilitar la autenticación por contraseña y habilitar la autenticación por clave pública editando /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yesY reiniciar el servicio:
sudo systemctl restart sshdAñadir las claves públicas de los usuarios autorizados al archivo authorized_keys:
cat ~/.ssh/id_ed25519.pub >> /home/git/.ssh/authorized_keysA partir de aquí ya es posible crear repositorios bare y hacer push directamente al servidor:
git init --bare /home/git/repos/mi-proyecto.gitY desde el cliente:
git remote add origin ssh://git@mi-servidor/home/git/repos/mi-proyecto.git
git push -u origin mainLos git-shell-commands son scripts ejecutables que extienden las capacidades de git-shell. Cuando un usuario se conecta vía SSH al servidor, git-shell actúa como intérprete restringido — solo permite operaciones git y los comandos personalizados que se hayan definido.
Por defecto git-shell únicamente permite las operaciones básicas de git: clonar, hacer push y pull. Cualquier intento de ejecutar otros comandos es rechazado. Esto lo hace ideal para un servidor git dedicado, ya que el usuario no puede usar la conexión SSH para administrar el servidor.
Se pueden crear comandos personalizados, creando scritps en el directorio ~/git-shell-commands/ del usuario git. Cada script se convierte en un comando disponible vía SSH:
ssh git@servidor nuevo-comandoLos scripts pueden estar escritos en cualquier lenguaje disponible en el servidor, aunque lo más habitual es usar bash o sh. Por ejemplo, el comando new que crea un repositorio bare:
#!/bin/sh
if [ -z "$1" ]; then
echo "Usage: new <repo-name>"
exit 1
fi
git init --bare /home/git/repos/$1.git
echo "Repo $1 created."Prefiero alojar el servidor Git dentro de un contenedor Docker, tanto por seguridad como por portabilidad. Para eso creé una imagen personalizada basada en Alpine Linux junto con un docker-compose que gestiona su configuración. La imagen incluye comandos de gestión de repositorios accesibles vía ssh (new, list, delete, etc.), datos persistentes mediante bind mounts, soporte para agregar claves ssh sin reiniciar el contenedor, y arranque automático con el sistema.
Está disponible en el siguiente repositorio:
https://github.com/maagenta/git-server-docker/tree/main
Como desarrollador me parece importante tener el control de mi servicio de correo y no depender de terceros. Además de ahorrar dinero (usar servicio de correo con un dominio personalizado siempre tiene un costo), me permite simplificar los backups y mejorar la privacidad de mis comunicaciones. Al alojar mi propio servidor de correo, tengo visibilidad total sobre quién accede a mis datos, cómo se almacenan y cuánto tiempo se retienen, sin estar sujeto a los términos de servicio de un proveedor externo que pueden cambiar en cualquier momento.
No necesito un servicio de correo demasiado complejo, necesito algo básico, por lo que no es necesario abrir puertos para IMAP y POP. Además, puedo mantener el puerto 25 de salida siempre cerrado, y que se abra dinámicamente solo cuando vaya a enviar un correo (que creo que va a ser muy ocasional). De esta manera simplifico la seguridad y la infraestructura de mi correo. También lo pienso porque a largo plazo quiero montar una empresa o fundación y quiero demostrar que es posible ahorrar mucho si se simplifican las cosas. Las grandes corporaciones tienen problemas de ineficiencia y de sobregasto porque sobrecomplican la infraestructura en la que se sostienen. Una infraestructura pequeña, programas que actúen de manera primitiva y eficiente, sin ocupar mucha memoria, sin necesitar demasiados casos a los cuales acudir, sin duda es una gran respuesta para mostrar que existe un camino que prioriza un modo de eficiencia distinto, donde no se necesita un sistema de colaboración jerarquizado y atomizado en cargos.
Cuando se habla de correos electrónicos se habla de SMTP, que es el estandar de mensajería por correo. SMTP fue creada en el año https://www.rfc-editor.org/rfc/rfc5321
Cualquier computadora con el puerto 25 abierto puede enviar correo usando SMTP. El problema es que las grandes compañías no aceptan correos de cualquier IP por seguridad y para evitar el spam. Por eso mismo, muchos proveedores cloud y VPS no permiten abrir el puerto 25 saliente para enviar correo, pues si sus usuarios empezaran a usar sus direcciones IP para enviar spam, estas perderían reputación ante los grandes servicios de correo. Por otro lado, las direcciones IP domésticas tampoco gozan de buena reputación para enviar correo y serán directamente rechazadas.
La reputación aplica para enviar correos, no para recibirlos. Por eso los proovedores cloud tienen el puerto 25 abierto para recibir correo y también se podría usar la IP de una red doméstica para recibir correo sin problemas.
Acabo de descubrir que, con SMTP puro, cualquier dirección IP puede hacerse pasar por cualquier dominio y usuario sin ningún tipo de restricción. Por eso, con el tiempo se han ido incorporando medidas que no forman parte del protocolo original y que buscan corregir, al menos en parte, estas vulnerabilidades. Casi todas dependen de un tipo de registro DNS llamado TXT, que, como su nombre indica, devuelve texto cuando se le hace una consulta.
Funciona así: cuando un servicio de correo recibe un mensaje, realiza varias consultas DNS que devuelven texto, y ese texto le permite verificar si el emisor proviene de un servidor legítimo o no. Las consultas son las siguientes:
SPF (Sender Policy Framework): el servicio receptor consulta el registro TXT del dominio del remitente y obtiene una lista de IPs autorizadas para enviar correo en su nombre. Si la IP del servidor emisor no está en esa lista, el correo es sospechoso.
DKIM (DomainKeys Identified Mail): el servidor emisor firma criptográficamente cada mensaje con una clave privada. El servicio receptor consulta el registro TXT del dominio para obtener la clave pública y verifica que la firma es válida. Si alguien modificó el mensaje en tránsito, la firma no coincide.
DMARC (Domain-based Message Authentication, Reporting and Conformance): el servicio receptor consulta el registro TXT _dmarc.dominio.com y obtiene la política del dominio: qué hacer si SPF o DKIM fallan. Las opciones son none (solo reportar), quarantine (mandar a spam) o reject (rechazar directamente).
El problema para mi caso es que no tenía ninguna de estos tres registros configurados en mi DNS, lo cual hace mucho más fácil para los hackers usar mi dominio para enviar spam. Por eso, decidí usar SPF y DMARC para decirle a los servicios de correo que bloqueen cualquier recepción de correo desde mi dominio y así mantenerlo límpio y con una buena reputación.
A continuación muestro en una tabla los registros que agregué:
| Type | Name | Content |
|---|---|---|
| TXT | * | "v=spf1 -all" |
| TXT | _dmarc | "v=DMARC1; p=reject; rua..." |
| TXT | @ | "v=spf1 -all" |
Se podría pensar que lo más lógico para manejar los correos que me llegan al servidor desde mis dispositivos sería usar IMAP y conectarlo a algún cliente de correo. Sin embargo, esto me parece que trae muchas complicaciones innecesarias. Por ahora el correo lo usaré muy poco: solo necesito tener un buzón desde donde recibir códigos de seguridad y poder crear cuentas en diferentes plataformas usando mi dominio. Para eso me basta con leer directamente el formato Maildir con un lector de correos básico en mi servidor o bien leer los archivos en texto plano. No necesito más. Si en un futuro necesitase ver mi correo más frecuentemente, podría crear una pequeña aplicación que leyera los correos en tiempo real usando TCP básico con cifrado asimétrico; sería súper seguro y simple. Y bueno, si el correo empezara a necesitar muchas más cosas, contrataría un servicio de terceros que garantice cierta privacidad, como lo puede ser Proton.
Existen dos estándares para guardar el buzón de correo en la computadora: Mailbox y Maildir.
Mbox es el formato más antiguo de los dos. Se trata de un archivo de texto en donde los correos se concatenan uno tras otro. Cada mensaje se separa con el una línea que empieza con From para separar cada mensaje.
Maildir crea un directorio Maildir en donde cada correo se recibe como un archivo diferente independiente dentro de una estructura de carpeta. El buzón de Maildir se organiza en tres subdirectorios:
tmp/: donde se escribe el mensaje mientras llega, antes de confirmarse.new/: mensajes recibidos pero que aún no se han leído.cur/: mensajes leídos.Entre las dos opciones elijo Maildir: al guardar cada correo en un archivo separado, un fallo afecta solo a un mensaje y nunca al buzón completo. Además evita bloqueos, agiliza el borrado y simplifica los respaldos.
Creo que OpenSMTP es la mejor opción para mí porque es muy liviano y sencillo de usar. Mostraré como lo instalé y configuré en mi servidor Ubuntu.
sudo apt install opensmtpd/etc/smtpd.conf. Yo lo dejé así:# $OpenBSD: smtpd.conf,v 1.10 2018/05/24 11:40:17 gilles Exp $
# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.
#table aliases file:/etc/aliases
# Users Table
table accounts file:/etc/mail/accounts
# Domains Table
table domains file:/etc/mail/domains
# To also accept external mail over IPv4 or IPv6,
# respectively replace "listen on localhost" with:
#
# listen on 0.0.0.0
# listen on ::
listen on localhost
listen on 1.1.1.1
action "receive" maildir "/var/mail/%{dest.domain}/%{dest.user}/Maildir" virtual <accounts>
action "send" relay
# Rules
match for local action "receive"
match from any for domain <domains> action "receive"
#match from local for any action "send"Creo que todo es bastante entendible salvo las tablas. Las tablas permiten añadir listas de datos para controlar el comportamiento de SMTP.
En el caso de la tabla domains, la uso para definir sobre qué dominios se recibe correo. Si un mensaje no pertenece a alguno de los dominios de la lista, el servidor simplemente lo rechaza.
La segunda tabla se llama virtual. Por defecto, el servidor de correo asocia cada destinatario con un usuario del sistema y le entrega el correo directamente. Como este enfoque resulta algo arcaico, no lo usaré. En su lugar empleo virtual, que permite vincular el nombre de cada destinatario a cualquier usuario del sistema. En este caso, todas las direcciones de destino apuntan al usuario mail, que ya viene incluido en Linux.
Muestro un ejemplo de como podría ser la tabla /etc/mail/accounts:
# Accounts
caballo@equitacion.com mail
koala@perezita.net mail
leon@selva.org mailLa tabla de dominios contiene un único valor; en realidad funciona más como una lista.
Muestro un ejemplo de cómo podría ser la tabla /etc/mail/domains:
# Domains
equitacion.com
perezita.net
selva.orgCon esto todo esta más o menos configurado.
smtpd -n.sudo systemctl restart opensmtpdMutt es un cliente de correo de texto que es bastante simple de usar y sobretodo me gusta porque permite leer el correo en directorios personalizados.
Por defecto mutt busca el correo en los directorios /home/user/Mail o bien en /var/user/Mail. Para cambiar a una carpeta personalizada se debe usar:
mutt -f ./directorioAl iniciarse, mutt busca el correo en los directorios mencionados anteriormente, incluso cuando se ha seleccionado un directorio personalizado. Si esos directorios no existen, muestra una advertencia indicando que la carpeta no se encuentra y pregunta si se desea crearla.
Para eliminar esta advertencia en todos los usuarios del sistema, basta con modificar el archivo /etc/Muttrc y fijar la carpeta en /dev/null.
# Disable message warning that the user folder doesn't exist
set folder=/dev/nullmailPor defecto, al ejecutar mutt el programa se inicia con el usuario de la sesión actual. Si se necesita que se ejecute como el usuario mail, se puede forzar mediante sudo:
sudo -u mail mutt -f .Cambiar de usuario requiere privilegios de root, por lo que el comando anterior solicitará una contraseña cada vez que se ejecute. Para evitarlo, se puede crear un archivo de configuración dentro de /etc/sudoers.d, siguiendo la convención de nombre usuario-comando. En este caso se llamará usuario-mutt:
usuario ALL=(mail) NOPASSWD: /usr/bin/muttCon esta regla, al ejecutar sudo -u mail mutt ... el sistema ya no pedirá ninguna contraseña.
Como último paso, se puede un alias para no tener que anteponer sudo -u mail manualmente en cada ejecución:
alias mutt="sudo -u mail mutt"A partir de ahora, basta con escribir mutt para que el programa se ejecute como el usuario mail.