Categoría: General

Tamaño máximo de adjuntos en correos

Publicada el | por pilasguru | Dejar un comentario en Tamaño máximo de adjuntos en correos

El tamaño máximo de adjuntos en un correo varía de servicio en servicio.

Esto nos afecta, pues nuestro servicio puede tener un tamaño establecido que es mayor que el tamaño del servicio de destino y, si mis ajuntos son mayores, el correo no será ni acpetado ni entregado al destinatario. Mientras que correos que envío a cuentas en mi mismo servicio son entregados sin problema.

Por supuesto, es posible configurar un servidor de correo para soportar tamaños mayores a los indicados, pero hay que tener en cuenta que cuando se envíe un correo será el servicio de destino el que aplicará sus límites, antes de aceptar el correo, para entregar en la casilla del destinatario.

Esta es una lista de los tamaños de ajuntos soportado por distintos servicios:

Servicios internacionales:

Servicios nacionales (Uruguay):

Otros límites a un correo:

Hay que recordar también que los distintos servicios tienen límites aplicados a otras características de los correos electrónicos, que también puden afectar si mi correo llegará a destino.

  • Número máximo de direcciones de destinto (To:)
  • Tamaño máximo de mensaje (adjunto + cuerpo + cabezales)
  • Espacio máximo de casilla destino (esto puede afectar si el destinatario no vacía su casilla para alojar el correo que recibe)
  • Cantidad de correos que se aceptan recibir de un mismo dominio (por día)

Estos límites han creado un «estándar» que se observa desde hace muchos años y al que todos más o menos nos adaptamos, pero cada tanto alguien tiene requisitos por sobre estos límites y se encontrará que su correo no llega a destino.

Cuando su correo no llegue a destino por tamaño del adjunto, debe buscar la ayuda de otros servicio, como ser file.io, donde el adjunto viaja por un medio y el correo, con un enlace para recuperar el adjunto, llega al destinatario de manera normal.

Les Luthiers

Publicada el | por pilasguru | Dejar un comentario en Les Luthiers

Recuerdo de mi más tierna adolecencia es ir al centro de Montevideo hasta la casa de venta de discos Palacio de la Música (en la misma esquina de Av. 18 de Julio y la calle Paraguay) con algun amigo para encerrarme en alguna de las cabinas con toca-discos (de pasta) a escuchar Les Luthiers, con el pretexto de decidir si los compraba, cosa que nunca hice ….

Ya de más grande supe tener un par de CDs de ellos y la oportunidad de irlos a ver actuar en el Teatro El Galpón. Y en mi biblioteca está su libro «Les Luthiers de la L a la S»

Hemos sido muchos los que descubrimos, nos fascinamos y reimos con ese humor inteligente y ocurrente que apelaba a la excelencia para transportarnos al punto donde conviven las lágrimas y la risa.

Aquí una breve colección de sus frases:

  • Todo es relativo. El tiempo que dura un minuto depende del lado de la puerta del baño que te encuentres.
  • Evite accidentes. Hágalo a propósito.
  • Tener la conciencia limpia es síntoma de mala memoria.
  • Evite accidentes. Hágalo a propósito.
  • La confianza mata al hombre…y embaraza a la mujer.
  • El que nace pobre y feo tiene grandes posibilidades de que al crecer se le desarrollen ambas condiciones.
  • Digamos, ha estado usted razonando… fuera del recipiente.
  • Pez que lucha contra la corriente muere electrocutado.
  • Lo importante no es ganar, sino hacer perder al otro.
  • Lo importante es el dinero, la salud va y viene.
  • Los honestos son inadaptados sociales.
  • Dime con quién andas y te diré si voy contigo.
  • Toda cuestión tiene dos puntos de vista: el equivocado y el nuestro.
  • La verdad no es lo que importa, sino tener razón.
  • El dinero no hace la felicidad, la compra hecha.
  • Errar es humano, pero echarle la culpa a otro es más humano todavía.
  • La pereza es la madre de todos los vicios, y como madre hay que respetarla.
  • Hay dos palabras que te abrirán muchas puertas: tire y empuje.
  • Si no puedes convencerlos, confúndelos.
  • No te metas en el mundo de las drogas. Ya somos muchos y hay muy poca.
  • Todo tiempo pasado fue anterior.
  • Yo tengo muchos libros escritos… yo ya los compro escritos porque si no, es como si no me dijeran nada.

Referencias:

FIX AWS cli «An error occurred (AuthFailure)»

Publicada el | por pilasguru | Dejar un comentario en FIX AWS cli «An error occurred (AuthFailure)»

Uno de los deployments que estoy automatizando con aws-cli funcionaba perfectamente cuando utilizaba recursos RDS, por ejemplo:

$ aws rds describe-db-snapshots --db-instance-identifier production
{
    "DBSnapshots": []
}

lo que significa que estaban correctamente configuradas las credenciales y los permisos dentro de IAM.

Pero al ejecutar comandos sobre EC2 obtenía un error, en algo tan sencillo como listar las instancias

$ aws ec2 describe-instances

An error occurred (AuthFailure) when calling the DescribeInstances operation: 
AWS was not able to validate the provided access credentials

y es un poco desconcertante, porque algunos comandos/servicios funcionan y otros no.

Una prueba que hice fue dar de alta las variables

export AWS_ACCESS_KEY_ID="AKIAIW......A"
export AWS_SECRET_ACCESS_KEY="GOvDvOPvjBW0n.........."

pero el error continúaba.

El problema es que la máquina local necesita tener una hora correctamente configurada:

$ date
Sat Sep 15 16:12:01 UTC 2018

$ sudo apt install -y ntp

$ date
Sat Sep 15 16:23:57 UTC 2018

Esos 9 minutos de retraso que tenía mi máquina local evitaba el uso de EC2.

Hay muchas formas de ajustar la hora, el servicio NTP no es la única solución y puede no ser la mejor. Tal vez un simple

$ sudo date 091516232018

hubiera sido una solución más adecuada; pero la idea es la misma, poner el host local en hora

246 días y renace

Publicada el | por pilasguru | Dejar un comentario en 246 días y renace

Si, fueron 246 días off-line. Más concretamente 5907 horas, 51 minutos y 5 segundos en que este blog ha estado off-line, según mi sistema de monitoreo.

La baja del blog se debió al cierre de la capa gratuita del servicio RedHat OpenShift en octubre, cuando procesaron un cambio de versión (tengo entendido que la capa gratuita se ha restaurado, pero no estoy seguro).

Aprovechando este «apagón» decidí migrar toda la plataforma a una infraestructura de docker y entre los tiempos que puede dedicar, las pruebas, los armados, que ahora dedico tiempo al podcast deployando.me y si …. pasó mucho tiempo.

Primero levanté el wiki pi.lastr.us, luego el sistema de certificados Let’s Encrypt y por último este blog. Pero lo que más pruebas me llevó fue armar un sistema de respaldos coherente para todo lo que voy levantando.

La estructura armada es de la siguiente forma:

En el host se levantan un conjunto de contenedores docker:

Las dos aplicaciones

que están detrás de un proxy reverso que atiende las conexiones de los navegantes

que recibe los certificados y configuración SSL gestionada por

el blog que guarda datos en un volumen definido en una carpeta del host y en una base de datos

que se respalda a un espacio de disco diariamente mediante un contenedor

que es invocado desde una tarea diaria en el crontab.

Estoy muy conforme con el resultado, pues es un sistema coherente para mantener y respaldar y escalable para agregar eventualmente más aplicaciones.

Volver a ver mi blog online fue la culminación de un proyecto personal bastante lindo para mi.

LXC en Debian con Ansible

Publicada el | por pilasguru | Dejar un comentario en LXC en Debian con Ansible

Desde antes del 2013 vengo insitiendo con las ventajas de los containers en Linux, ya que permiten un rápido despliegue de muchos sistemas Linux corriendo en forma independiente.

En 2014 había hecho experiencias para tener con una máquina virtual de DigitalOcean muchos contenedores Linux instalados y prestando servicios y en 2016 tuve la oportunidad de compartir en forma práctica con la comunidad de Paysandú un ejemplo de uso de contenedores.

Hace unos meses atrás armé un perfil de vagrant (Vagrantfile) que permite levantar una máquina virtual con Debian e instalar (aprovisionar) un servidor de contenedores LXC, y un primer contenedor de pruebas.

Este artículo tiene por objetivo, compartir esa configuración, para que la pueda usar quién desee.

Repositorio: debian-lxc-ansible

El aprovisionamiento se realiza mediante Ansible, por lo que es fácil de parametrizar y adaptar.

Una vez levantado el primer contenedor (que ya queda en el aprovisionamiento inicial, luego de correr vagrant up) es muy fácil levantar más contenedores con los comandos normales.

También, en el directorio /vagrant/utils se entregan scripts (requieren revisión y adaptación a la instalación particular) que sirven cómo muestra de cómo levantar containers para producción:

a) Levantar un container con sitio web funcional

/vagrant/utils/create-container.sh name

b) Borrar el container creado con el script anterior

/vagrant/utils/destroy-container.sh name

c) Crear una página web para ver el status de los containers a través de web en el servidor lxc

/vagrant/utils/status.sh

Toda esta instalación, obviamente puede ser modificada y mejorada. Si desean compartir sus mejoras conmigo lo pueden hacer a través de Merge Request.

Carguemos las pilas

Publicada el | por pilasguru | Dejar un comentario en Carguemos las pilas

Creo que he llegado a una nueva marca sin publicaciones en el blog desde abril pasado.

Una de las razónes es Deployando.Me el podcast de tecnología para sysadmin y devops que trato de mantener en forma períodica ¿ya lo escucharon?

Otra de las razones son nuevos proyectos laborales, viajes al exterior para distintas tareas profesionales y un montón de etcéteras que puedo encontrar, pues razones hay muchas pero…

el que no publica soy yo, y no es porque falte material o falte qué compartir.

Entonces, va este artículo como auto-compromiso de seguir publicando.

Actualización y los 4 millones de archivos

Publicada el | por pilasguru | Dejar un comentario en Actualización y los 4 millones de archivos

Un tiempo atrás actualicé un sistema Debian en forma rutinaria y hace un par de días comenzó a producir problemas extraños en las aplicaciones: desde pérdida de sesión al editar páginas web, errores para escribir en las bases de datos, hasta problemas de permisos en los archivos temporales.

El problema resultó ser la temida y oscura: tabla de inodos llena.

# df -i
Filesystem      Inodes    IUsed           IFree IUse% Mounted on
/dev/sda1       5120000 5120000     0        100%   /

Entonces, a salir a buscar dónde estaban los millones de archivos que ocupaban todos los inodos:

# find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
...
3945231  /var/lib/php5/

y resulta que en ese directorio se mantenían unos casi cuatro millones de archivos llamados como sess_dn5m6oc4fcpfo0c95pq1se4rp0.

Aparte de iniciar un proceso de borrado masivo:

# cd /var/lib/php5
# find . -name "sess_*" -print | xargs rm -v

Inicié la búsqueda de las causas de fondo para evitar que el problema se vuelva a repetir en el futuro.

En Debian/Ubuntu el encargado de mantener los archivos de sesiones que se generan en /var/lib/php5 es el script

# cat /etc/cron.d/php5
# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)

que como se puede ver, utiliza la salida de la ejecución de /usr/lib/php5/maxlifetime para determinar el tiempo de mantenimiento de los archivos de sesión de php.

El problema se generó en la ejecución de /usr/lib/php5/maxlifetime que producía el error de al ejecutar por la presencia de la directiva safe_mode en el archivo php.ini:

#  grep safe_mode /etc/php5/apache2/php.ini
safe_mode = On

en razón de que:

42 | WARNING | INI directive ‘safe_mode’ is deprecated from PHP 5.3 and forbidden from PHP 5.4.

Así la actualización a PHP 5.4 hizo que el archivo /usr/lib/php5/maxlifetime dejara de devolver un valor para devolver un error. Entonces el proceso de limpieza, dejó de limpiar y se juntaron cuatro millones de archivos que llenaron la tabla de inodos.

Solución permanente: comentar safe_mode = On en el archivo php.ini.

Listar permisos rwx en octal

Publicada el | por pilasguru | Dejar un comentario en Listar permisos rwx en octal

Estamos acostumbrados a ver los permisos de los archivos con el comando ls -l con la típica representación de rw-r–r– y generalmente hago la traducción a octal 644 en forma mental.

Pero si necesitamos desplegarlos en octal, tenemos a nuestra disposición el comando stat que soporta dar formato a la salida para ver sobre el estado de nuestro sistema de archivos:

En GNU/Linux que utilizamos stat de GNU Coreutils:

stat -c «%n %a» *
config.cf 644
containers.txt 644
libs 755

En MacOS que utilizamos stat de BSD:

stat -f «%N %Lp» *
config.cf 644
containers.txt 644
libs 755

Felicidades y happy hacking en 2017

podcast: deployando.me

Publicada el | por pilasguru | 1 comentario en podcast: deployando.me

deployandome300x300 Comienzo una nueva etapa, un nuevo emprendimiento: el podcasting. Ayer publiqué el episodio Nro. 1 de deployando.me, el podcast para sysadmins y devops.

Ha sido un camino muy interesante hasta ahora. He escuchado algunos podcast de como hacer podcast (¿metapodcast?) y ha sido Podcast Pro una de mis referencias principales. También, he leido unos cuantos sitios con tutoriales y sugerencias para podcasters, como este, este y este otro artículo. Por supuesto, escucho y analizo otros podcast y podcasters de diferentes temáticas.

Me entusiasma el hecho de que el podcasting es algo evolutivo, que se sabe cómo empieza, pero no se tiene claro cómo o cuándo termina; confieso que no tengo planes más allá de un par de episodios por adelantado, ni aspiraciones más que las de satisfacer el autodesafío del podcasting.

Por eso, me entusiasma ese desafío y compromiso implicito del podcast. Un podcast que termina en unos pocos capítulos o un podcast de una periodicidad incierta tendrá una baja incidencia; pero un podcast regular que acumula una tradición de ediciones se vuelve un referente. Los ejemplos de esto sobran en cualquier catálogo de podcast.

Y así nace: deployando.me

Los invito a escuchar la edición Nro. 1 de deployando.me sobre Let’s Encrypt.

A suscribirse a los canales de podcast de iTunes, de iVoox, o directamente a sindicar el RSS en su programa de podcast favorito.

Por supuesto, si tienen cualquier comentario, sugerencia o crítica constructiva me pueden contactar o dejar comentarios del podcast.

Nota: este artículo me recuerda al primer artículo que iniciaba este blog en el 2004: En el ir y venir aquí estamos