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

Spam como evento de calendario

He recibido una invitación a un evento de calendario por una oferta de rebajas que hace «alguien» por ahi, o sea un SPAM directo como un evento de calendario. Eso generó que todas las alarmas de calendario se activaran, pidiendo confirmación para aceptar o rechazar mi participación tal evento.

Me resulta una forma muy ocurrente y efectiva de hacer spam por el nivel de molestia que provoca. No es fácil ignorarla, pero la odisea no termina ahi.

El spam en cuestión invita a grupo importante de direcciones que comienzan todas con «rp», entre las que está la mía.

captura-de-pantalla-2016-11-25-a-las-10-40-34

Seguramente el spammer no sabe que yo he recibido su invitación, pero el sistema me obliga a aceptar o declinar la invitación, en cuyo caso notificará que estoy aquí y que he leído su spam, por lo que mi dirección es válida y buena para seguir enviando este tipo de «invitaciones».

captura-de-pantalla-2016-11-25-a-las-10-14-06

Así que de ninguna manera se debe aceptar o rechazar la invitación

Y como la opción borrar, no queda disponible el problema no es trivial de resolver.

Consultando distintos sitios, bases de conocimiento y lo que encontré, veo que la solución es crear un nuevo calendario, por ejemplo llamarlo SPAM, editar la invitación y moverla a dicho calendario.

captura-de-pantalla-2016-11-25-a-las-19-59-16

Al calendario SPAM lo desmarco para que no lo sincronice con mis dispositivos, pero también se puede borrar y de esa forma eliminan también los eventos que están en él.

Una molestia importante pero tiene solucion.

A mi me ha sucedido con el calendario de iCloud, pero hice pruebas y funciona equivalente en Google Calendar.

Humble Book Bundle Unix

The Humble Bundle es una iniciativa de venta donde uno paga lo que quiere (a voluntad) por un conjunto básico de items, e incluye otros conjuntos más que tienen un precio base (mínimo) que varía de acuerdo a las ofertas que se reciben. En el momento que uno confirma el pago puede elegir cómo repartir el monto de dinero entre autores, sito de venta y entidades de beneficio.

En este blog hablé en 2012 de Humble Bundle y también en otro artículo de 2014.

captura-de-pantalla-2016-11-23-a-las-19-41-31

Ahora han sacado Humble Book Bundle Unix que junta unos cuántos libros de la editorial O’Reilly sobre los temas que me interesan.

La verdad que estos muchachos se han lucido con esta oferta.

GNU/Linux Distribution Timeline

El proyecto GNU/Linux Distribution Timeline (GLDT) mantiene un diagrama de la evolución de las distribuciones de GNU/Linux desde 1992 a la fecha.

Se trata de un proyecto iniciado en 2006 y que actualmente mantiene unas 480 distribuciones activas.

Si desean acceder a esas distribuciones, uno de los mejores sitios es distrowatch.com.

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

El estilo con el que aprendemos

Muchas veces me ha pasado de tener diferencias en los procesos de aprendizaje con mis pares: algunos entienden más rapido que yo y otros son más lentos. Si pienso, recuerdo compañeros que hacían resúmenes, otros que subrayan los libros, algunos que repiten una y otra vez en voz alta, y los que con solo escuchar y leer un tema ya lo aprendían.

El profesor David Kolb analizó los estilos de aprendizaje y sintetizó cuatro estilos principales, basado en cómo solemos enfrentar los problemas, para definir cómo es que aprendemos. Así encontró que estamos en uno de estos cuatro grupos:

Adaptadores

Apenas han entendido los primeros conceptos básicos pasan a la acción y aprenden el resto con la experiencia, el ensayo y el error. No necesitan desarrollar o completar todo el proceso para ponerse manos a la obra y trabajan bien en entornos multidisciplinares resolviendo varios aspectos del problema a la vez.

Divergentes

Son capaces de trabajar varios conceptos a la vez de forma simultanea pero necesitan comprender la totalidad del proceso, la teoría subyacente, el por qué de las cosas.

Convergentes

Aprenden a través de la experiencia y la puesta en práctica de los conceptos pero prefieren un desarrollo lineal, ordenado de uno o pocos conceptos a la vez.

Asimiladores

Se centran en una sola idea por vez y están enfocados desde el punto de vista teórico, debiendo desarrollar una asimilación teórica de los conceptos para llegar a sentirse cómodos con su manejo. Es característico del entorno científico.

La Dra. Pilar Jericó creó este claro diagrama que resume los estilos de aprendizaje de Kolb y que resúmen las características del individuo en cada grupo:

1476119828_530014_1476120852_noticia_normal_recorte1

Entonces, ¿en qué estilo te encuentras?

Recuperar desde BackupPC por línea de comandos

BackupPC es una herramienta formidable para respaldar y guardar un registro histórico de respaldos en el storage del servidor. Pero está orientado al uso mediante interfaz web, y cuando queremos vincularos con el servidor por la línea de comandos, es algo complicado.

Recuperar el directorio /usr/local/sbin en forma automática se puede usar este comando, ejecutado en el servidor a recuperar.


cd /usr/local; \
ssh backuppc@server.backuppc \
/usr/share/backuppc/bin/BackupPC_tarCreate \
-h "$(hostname -f)" -n -1 -s "$(pwd)" "sbin" | tar xf -

Explicándolo:

cd /usr/local: es el directorio ‘source’ respaldado, registrado en $Conf{RsyncShareName}
ssh backuppc@server.backuppc: supone que tenemos acceso ssh al servidor backuppc y las credenciales como el usuario bakcuppc. Si se accede como root se puede ejecutar con sudo -u backuppc pues el comando BackupPC_tarCreate lo debe ejecutar el usuario backuppc obligatoriamente.
-h $(hostname -f): va a ser reemplazado con el nombre del host respaldado, desde el cual se ejecuta el comando. Si BackupPC lo conoce por la IP se puede poner directamente luego del -h.
-n -1: recupera el último backup realizado. Se puede colocar el numero de backup se se desea otro.
-s $(pwd): va a ser reemplazado con el directorio actual del host respaldado, desde el cual se ejecuta el comando ssh. Es el nombre registrado en $Conf{RsyncShareName}.
sbin: es la carpeta/archivo a recuperar. Se puede utilizar un punto "." si se desea recuperar todo el contenido.
tar xf –: el comando BackupPC_tarCreate que se ejecuta mediante ssh en el servidor BackupPC genera un archivo tar en stdout. Este tar xf - se ejecuta localmente en el host respaldado y extrae del tar los archivos en el disco local.

Se puede mejorar haciendo un gzip antes de pasar los datos por la red.

Si alguien conoce un método más óptimo, agradezco lo comparta y, si encuentro algo mejor, lo documentaré por aqui.

vagrant destroy no borra la máquina virtual

Hace tiempo que tengo una máquina virtual que no consigo borrar (destroy). El problema nació, según recuerdo, a partir instancia que intenté levantar con un provider en una nube externa que no estaba correctamente configurado y vagrant marcó la instalación como abortada.

En concreto la VM no existe más, la carpeta de Vagrantfile tampoco existe más y el comando vagrant global-status seguía mostrando allí la máquina:

$ vagrant global-status
id       name    provider   state   directory                           
------------------------------------------------------------------------
d0c7c28  default virtualbox aborted /Users/rodolfo/Vagrant/cloud    

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to

Antes de borrar el directorio con toda la información de vagrant ˜/.vagrant.d encontré que existe el modificador --prune para la opción vagrant-status:

$ vagrant global-status --help
Usage: vagrant global-status

        --prune                      Prune invalid entries.
    -h, --help                       Print this help

Y la ejecución limpió los datos de la máquina virtual inexistente:

$ vagrant global-status
id       name   provider state  directory                           
--------------------------------------------------------------------
There are no active Vagrant environments on this computer! Or,
you haven't destroyed and recreated Vagrant environments that were
started with an older version of Vagrant.

problema solucionado!

cal 9 1752

El comando cal de Unix es un comando estándar del sistema operativo (BSD, Linux, MacOS) que mostrará el mes actual en formato calendario cuando se ejecuta:

$ cal
   September 2016
Su Mo Tu We Th Fr Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

Si el comando cal se ejecuta seguido del año (2016) mostrará los 12 meses de dicho año; y si se ejecuta seguido de número del mes y año entonces mostrará ese mes en particular de dicho año.

De esta forma se pueden encontrar perlas o curiosidades que ha tenido nuestro calendario a lo largo de la historia:

$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

En setiembre de 1752 Gran Bretaña y sus colonias adoptaron oficialmente el calendario Gregoriano y se debió ajustar los días del anterior calendario Juliano. Referencia: Wikipedia Cal (Unix).

Este ajuste se corresponde con el que en octubre de 1582 hiciera el propio Papa Gregorio XIII para que la fiesta de Pascua coincidiera con la llegada de la primavera, y de esta forma al 4 de octubre le siguió el día 15 de octubre y asi, en el año 1583, el equinoccio primaveral (hemisferio norte) tuvo lugar el 21 de marzo.

Otros países se fueron uniendo de a poco: la Alemania Católica Romana, Belgia y los Países Bajos cambiaron a este nuevo calendario en 1584; Hungría en 1587; Dinamarca y la Alemania Protestante en 1704; Suecia en 1753; Japón en 1873; Egipto en 1875; Albania, Bulgaria, Estonia, Letonia, Lituania, Rumania y Turquía cambiaron entre 1912 y 1917; la URSS en 1918; Grecia en 1928 y finalmente China cambió luego de la revolución de 1949.

La adopción paulatina del calendario Gregoriano tiene algunas curiosidades, por ejemplo:

Segun Wikipedia, Miguel de Cervantes falleció el 22 de abril de 1616 a la edad de 68 años y William Shakespeare el 23 de abril del mismo año, pero Cervantes en España estaba bajo el calendario Gregoriano y Shakespeare en Gran Bretaña bajo el Juliano, por lo que la fecha Gregoriana de la muerte de Shakespeare fue el 3 de mayo de 1916.

La Revolución Bolchevique, que puso fin al zarismo en Rusia, se conoce como “Revolución de Octubre”, ya que tuvo lugar entre el 24 y 25 de octubre de 1917. Y el calendario gregoriano se adoptó en Rusia en 1918, al año siguiente. De haber adoptado el calendario gregoriano con anterioridad a la revolución la conoceríamos como la «Revolución de Noviembre».

Leer sobre el Calendario Gregoriano

Static Site Generators

Los Static Site Generators (SSG) son piezas de software que recopilan información, principalmente de archivos, y generan un sitio web de contenido estático. Los SSG se pueden ejecutar periódicamente haciendo que el sitio muestre el eventual contenido nuevo una vez generado.

Pensemos en este blog (dinámico):

Este contenido que lees, ha sido recuperando de una base de datos SQL y presentado en formato web mediante un conjunto de programas (PHP) que se ejecutaron cuando solicitaste la página, es decir, es un sitio dinámico; si tu lectura cambiara algo (por ejemplo, un contador de visitantes) esa nueva información será mostrada al siguiente visitante que acceda al sitio.

Pero los artículos que escribo tienen una periodicidad (digamos) semanal. Así que, si lees este artículo, posiblemente el sitio no tendrá cambios hasta dentro de unos días. Desde ese punto de vista, no requieriría procesar una generación para cada visitante y perfectamente podrias estar leyendo el sitio estático.

Es decir, este blog podría tener archivos en archivos de texto que editaría con mi editor preferido y un software que los recorra cada vez que redacto un nuevo artículo, generando todo un sitio estático en HTML que subiría al servidor cada vez que algo cambia.

Pensemos en el agregador agujerodelmate.org (estático):

Se trata de un software que periódicamente (una vez por hora) recorre varios sitios y recupera la información publicada, generando con ello un sitio estático en HTML. Si al revisar no encuentra contenido nuevo, deja el sitio publicado como está.

Ese mismo software podría guardar los datos en una base de datos y tener un código que se ejecuta cada vez que un visitante accede y generarle un sitio especial para él. Pero podemos coincidir que sería un uso excesivo de recursos informáticos.

Static Site Generators

Si bien en un tiempo se pensó que generar los sitios dinámicamente era una ventaja y una tendencia sin retorno, hoy día los sitios estáticos están ganando terreno mediante un sinceramiento entre las necesidades de presentación de contenido y los requisitos y oferta de recursos informáticos y de alojamiento. Pero también ha colaborado para esto, el avance de la web, ahora la presentación (CSS) está separada del contenido (HTML) y mucho del dinamismo lo realiza el navegador (JS y HTML5) del visitante.

Cuando me puse a buscar del tema encontré que existen muchas herramientas modernas para generación de contenido estático a partir de archivos, colecciones de fotos, recopilación de datos, etc. etc.

El sitio StaticGen presenta una lista bastante completa de los mejores SSG de código abierto. El propio sitio es generado en forma estática con una de esas herramientas y está alojado en el servicio Netlify, especialmente diseñado para contenido estático.

Para sitios estáticos hay alojamiento gratuito a través de sitios de gestión de desarrollo de software como Gitlab Pages o Github Pages.

Pero también se puede servir contenido estático en varios servicios que otorgan un alojamiento gratuito de archivos como Google Drive o Dropbox compartiendo el enlace al archivo HTML principal del sitio.

Y yo…

Por ahora estoy haciendo cosas con Tiddlywiki y Gitlab; pero también he hecho pruebas con Hugo para generar sitios a partir de archivos en formato markdown.