Jose Armesto's Blog

Auto completado en zsh

Sat, 16 Jul 2016 17:49:15 +0000

Hace tiempo escribí un post sobre cómo sacarle el máximo rendimiento a tu terminal utilizando zsh, en el que introducía zsh y el framework oh-my-zsh para tener una experiencia más placentera usando el terminal.

Hoy veremos algunas funcionalidades extras que nos aporta esta herramienta y que nos puede ayudar a decidirnos a empezar a utilizarla.

Auto Completado

Una de las cosas que comentamos en el artículo original era que el auto completado de comandos era bastante potente, pero podemos mejorarlo aun más. Añadiendo esto a nuestra configuración

zstyle ':completion:*' verbose yes
zstyle ':completion:*' group-name ''

obtendremos la lista de posibles acciones agrupadas por tipo. Por ejemplo, escribiendo vi y dándole al tabulador

$ vi
 --- external command
 VirtualBox  vi          view        vim         vimdiffvisudo
 --- shell function
 vi_mode_prompt_info     virtualenv_prompt_info
 --- alias
 vim
 --- local directory
 videos/

Como podéis ver, en vez de salirme un listado enorme con todo, vemos las opciones agrupadas por tipo. Como dijimos anteriormente, no hace falta usar el tabulador para moverme por las opciones, si no que puedo utilizar los cursores del teclado para ir más rápido.

Y no solo vale con comandos, si no también con argumentos de los comandos:

$ ping -
 --- option
 -L  -- suppress loopback of multicast packets
 -Q  -- somewhat quiet
 -R  -- record route
 -a  -- audible for each packet
 -d  -- set SO_DEBUG on the socket
 -f  -- flood ping
 -n  -- numeric output only
 -q  -- quiet
 -r  -- bypass normal routing tables
 -v  -- verbose
 -I  -P  -S  -T  -c  -i  -l  -m  -p  -s  -t

O subcomandos:

$ git
 --- common commands
 add       -- add file contents to the index
 bisect    -- find by binary search the change that introduced
 branch    -- list, create, or delete branches
 checkout  -- checkout a branch or paths to the working tree
 clone     -- clone a repository into a new directory
 commit    -- record changes to the repository
 diff      -- show changes between
 fetch     -- download objects and refs from another repository
 grep      -- print lines matching a pattern
 init      -- create an empty Git repository
 log       -- show commit logs
 merge     -- join two or more development histories together
 mv        -- move or rename a file, a directory, or a symlink
 pull      -- fetch from and merge with another repository
 push      -- update remote refs along with associated objects
 rebase    -- forward-port commits to the updated upstream
 reset     -- reset current HEAD to the specified state
 rm        -- remove files from the working tree
 show      -- show various types of objects
 status    -- show the working tree status
 tag       -- create, list, delete or verify a tag object signed

Sugerencias

He visto muchas utilidades en Gthub que cuando escribimos un comando incorrectamente en la terminal, nos sugiere comandos válidos porque seguramente nos hemos equivocado en algún caracter. Esto que es bastante útil viene también con zsh. Podemos comprobar cómo funciona

$ vom
 zsh: correct 'vom' to 'vim' [nyae]? y

Cuando detecta que el comando es incorrecto, nos ofrece alguna sugerencia y nos da cuatro posibles respuestas:

n: no, quiero probar mi comando aunque no lo reconozca zsh
y: sí, quiero abrir la sugerencia de zsh
a: abortar, olvídate de mi comando y volvamos a la terminal
e, volver a la terminal para editar mi comando antes de ejecutarlo

Sugerencias en auto completado

Fíjate que incluso mezcla estas dos funcionalidades! Utilicemos el auto completado otra vez

$ cat tost
 corrections (errors: 1)
 test.jmx            test.json
 --- original
 tost

Al escribir cat tost y pulsar tabulador, me sugiere posibles correciones, ya que no hay ningún fichero que coincida con el nombre “tost”, pero sí con “test”.

Lo mismo con comandos

$ vom
 corrections (errors: 1)
 comptry                             vim
 compcall                            vimdiff
 composer                            homebrew/
 --- original
 vom

Conclusión

Como véis, hay muchos motivos para utilizar zsh y que estar en la terminal sea un placer. ¿Conocéis algún otro truco que no esté aquí?

Problemas desplegando código si usas Apache, symlinks y opcache

Fri, 01 May 2015 12:14:32 +0000

Muchas de las soluciones disponibles en el mercado para desplegar aplicaciones se basan en el uso de enlaces simbólicos (o symlinks) para activar la última versión de código en el servidor.

Simplificando mucho, podríamos decir que un flujo habitual a la hora de desplegar sería el siguiente:

Ejecutamos comando para iniciar el proceso de despliegue de código nuevo.
Se descarga el código del repositorio y se construye la aplicación. Esto suele significar instalar dependencias, generar ficheros, etc.
Se mueve el resultado del paso anterior al servidor y se pone en una carpeta nueva.
La carpeta a la que apunta el document root de nuestro servidor web es en realidad un enlace simbólico a otra carpeta que contiene código en la versión anterior. Por tanto solo nos queda cambiar ese enlace simbólico para que apunte a la nueva que acabamos de crear.

Como el cambio de enlace simbólico es practicamente instantáneo, conseguimos reducir la ventana de tiempo en la que el servidor está en un estado inconsistente, por ejemplo, porque todavía no se hayan terminado de copiar ficheros. Mientras se están subiendo la versión nueva, seguimos sirviendo la versión vieja, sin dejar de dar servicio. Y solo cuando la nueva está lista, hacemos el cambio de forma casi instantánea.

Problemas con este enfoque

Esta manera de desplegar, que parece sencilla y perfecta, tiene algunas complicaciones. Con la que la gente más suele pelearse es con el hecho de que a pesar de haber desplegado una versión nueva en el servidor, a veces siguen viendo la versión vieja, debido a la extensión Opcache (antiguo APC) que guarda la compilación del código PHP interpretado en memoria. Por tanto, aunque la versión nueva ya está activa, PHP sigue tirando de esta caché para no tener que leer del disco y volver a compilar código PHP, así que se sirve el código de la versión vieja hasta que caduque esta caché (si es que lo tenemos configurado para que caduque), o hasta que reiniciemos el servidor dejando de dar servicio mientras dure el reinicio del servidor.

Antes de ver cómo solventarlo, vamos a ver un par de detalles interesantes.

Te presento a tu nueva amiga realpath_cache

Cada vez que utilizas una ruta del sistema de archivos, por ejemplo porque vas a hacer un require/include de ese archivo, o porque vas lees/escribir en esa ruta, el sistema tiene que resolver esa ruta: saber donde es exactamente, si es un directorio o un archivo, etc.

Para mejorar su rendimiento y minimizar lecturas de disco, PHP utiliza una caché interna donde guarda información sobre el sistema de archivos. No estoy hablando de Opcache, sino de otra caché llamada realpath_cache. Si intentas resolver la misma ruta dos veces seguidas, solo en la primera PHP le pedirá información al lentísimo sistema de archivos: la segunda se leerá directamente de la caché, mejorando mucho el rendimiento.

Esto es bueno, ¿no?

Sí, claro. El tema es que, como con todas las cachés del mundo, el problema viene a la hora de invalidar la caché y decirle que queremos utilizar contenido nuevo.

There are only two hard things in Computer Science: cache invalidation and naming things.

Cuando desplegamos código nuevo, el contenido de la ruta de nuestro Document Root cambia. Aunque en nuestro código siempre usemos la misma ruta para hacer algo, piensa por ejemplo la ruta relativa que usas para incluir el autoload, despues de cada deploy, esa ruta se resuelve a un lugar distinto en el disco, porque el enlace simbólico apunta a otro sitio. Esto evitará que veamos la versión nueva del código desplegado, hasta que esta caché no caduque o hagamos algo al respecto.

Cómo funciona Apache

A diferencia de Opcache, que se guarda en memoria compartida por todos los procesos, la realpath_cache es local para cada proceso del sistema. Este detalle es importante porque si utilizas Apache prefork para servir tu aplicación, cuando inicias Apache, este crea varios procesos hijos, tantos como le hayas configurado. Cada proceso hijo creado servirá X número de peticiones en su vida (esto también es configurable), y una vez que ha cumplido su deber, Apache lo matará y lo reemplazará con otro proceso hijo, poco a poco renovando todos los procesos que sirven páginas.

Es decir, no podemos preveer exactamente cuando los procesos dejarán de existir. Sumado a que la realpath_cache es local a cada proceso, la nueva versión que acabamos de desplegar se irá sirviendo aleatoriamente, dependiendo de qué proceso de Apache te haya asignado el servidor.

Como dijimos antes, podríamos solventarlo haciendo un reinicio de Apache despues de cada despliegue, pero dejaríamos de servir páginas el tiempo que tardase en reiniciar.

Mal, mal, mal, verdadera mal, por no deci borchenoso

Reiniciando elegantemente

Pero tranquilo, no sufras, hay solución. Apache nos ofrece una variante al reinicio, llamada graceful restart. Esta variante, en vez de matar al proceso de Apache y todos sus hijos para reiniciarlo, lo que hace es que el proceso padre revisa a los procesos hijos de forma que:

Si no están haciendo nada, los sustituye por un proceso nuevo.
Si está sirviendo una petición en este momento, cuando termine lo sustituye por un proceso nuevo.

Como dijimos que realpath_cache era local a cada proceso, cuando Apache levanta un nuevo proceso hijo la realpath_cache está vacía para ese proceso y las rutas se resolverán al código nuevo que acabamos de desplegar. Todo esto sin dejar de dar servicio, porque siempre hay procesos sirviendo páginas.

Pesao. Que yo venía aquí a solventar el problema de Opcache

Cierto. Opcache no es más que un diccionario (piensa en un array PHP), en el que cada key es la ruta del fichero compilado, y el value es el resultado de esa compilación. Cuando se va a ejecutar un fichero PHP, se ve si la ruta de ese archivo ya es una de las _keys_ en el diccionario, si ya lo está significa que ya lo hemos compilado antes, y se utiliza directamente el value. Si no, se compila y se guarda en el diccionario.

El ‘final plot twist’ de todo esto es que Opcache utiliza realpath_cache internamente para resolver la ruta de los ficheros. Por tanto, si hacemos un graceful restart después de cada despliegue, la ruta del archivo habrá cambiado, resuelve a una carpeta distinta, así que será como un fichero totalmente nuevo para Opcache y volverá a compilarlo, haciendo que sirvamos la versión nueva.

Conclusión

Lo que hemos visto hoy es tan solo uno de los posibles problemas a la hora de desplegar código. Otro problema, por ejemplo, sería el que se produce cuando iniciamos un despliegue, un visitante entra en la web, justo después se cambia el enlace simbólico y estamos sirviendo archivos estáticos como javascript o css. Es posible que algunos archivos hayan sido de la versión vieja, y otros de la versión nueva, llevando a posibles inconsistencias. Hay módulos de apache que intentan solventar este tipo de problemas.

El despliegue de código es un tema complicado y muy interesante. Últimamente está avanzando mucho con conceptos como servidores inmutables y los contenedores, pero eso ya es tema de otro post.

Utilizando Puphpet también en producción

Sat, 19 Apr 2014 09:00:56 +0000

Ya hablé en el pasado sobre Puphpet, una herramienta web que genera manifiestos de Puppet y de Vagrant de forma rápida y sencilla.

Llevo tiempo utilizándolo para configurar mis máquinas virtuales de desarrollo junto a Vagrant, pero siempre estaba un poco con la mosca detrás de la oreja por el hecho de no poder utilizarlo también en producción.

Así que el otro día me decidí a echar un ojo al código fuente de Puphpet y ver si podía utilizar solo la parte generada de Puppet, y olvidarme de la parte de Vagrant.

Resulta que para hacer su magia, Puphpet tan solo le dice a Vagrant que ejecute unos scripts de bash. Así que pensé, ¿qué pasa si los ejecuto yo manualmente en producción? Los scripts solo se encargaban de instalar puppet, curl y alguna librería más, así que no debía de haber mucho problema. Después de hacer esto, tan solo le diría a puppet que leyese el manifiesto generado por Puphpet y listo. Mi plan sonaba bien, así que me propuse a intentarlo.

Para asegurarme de que nada fallaba, coloqué los archivos generados por Puphpet en el mismo sitio que cuando Vagrant los utiliza, es decir /vagrant. Entré en mi servidor de producción y subí los archivos de forma que quedaron así:

Una vez que tenía todo en su sitio, tan solo me quedaba ejecutar los scripts en el mismo orden que Vagrant lo hace. Acordaos de dar permisos de ejecución a esos ficheros. El orden es el siguiente:

chmod +x /vagrant/puphpet/shell/*.sh
sudo ./vagrant/puphpet/shell/initial-setup.sh /vagrant/puphpet
sudo ./vagrant/puphpet/shell/update-puppet.sh
sudo ./vagrant/puphpet/shell/r10k.sh

Esto instalará todas las dependencias necesarias para que podamos empezar a utilizar puppet en producción. Así que una vez finalizado, solo queda decirle a puppet que aplique los cambios del manifiesto.

sudo puppet apply --debug --verbose --hiera_config /vagrant/puphpet/puppet/hiera.yaml --parser future /vagrant/puphpet/puppet/manifest.pp

Este comando hará todo lo que hemos pedido en el manifiesto. Para asegurarnos de que todo sigue en orden en el servidor, podemos crear un cron que lo ejecute cada cierto tiempo, o tan solo ejecutarlo manualmente cuando añadimos o borramos algo al manifiesto.

Así que con esto tengo la misma configuración en mi máquina virtual de desarrollo que en mi máquina de producción. Y es una configuración que he ido seleccionando a través de una cómoda interfaz web gracias a Puphpet. Épico.

Sácale el máximo partido a tu terminal con zsh

Sat, 12 Apr 2014 13:42:17 +0000

No quiero tirar de términos de moda y hablar de DevOps, pero sí es cierto que, yo por lo menos, paso cada vez más tiempo delante de una terminal de UNIX. Estoy empezando a sentirme como en casa en algo que hace unos años me asustaba bastante.

Hoy vengo a hablaros de zshell, una alternativa a bash, el intérprete que viene por defecto en la mayoría de distribuciones. Algunos pensaréis… “¿Cambiar el intérprete? ¡Eso suena muy difícil!“, pero nada más lejos de la realidad! Otros diréis… “¿Para qué iba yo a querer uno distinto? ¿Cual es el problema con bash?” Problema ninguno! Pero con este post espero enseñaros todo lo que os estáis perdiendo por no utilizar zshell. Además, lo más importante es que no hay que aprender ningún comando nuevo: practicamente todo lo que usas en bash funcionará en zsh.

Instalación de zshell

Instalarlo es muy simple en la mayoría de distribuciones, ya que hay un paquete ya listo para nosotros. No os preocupéis que por el hecho de instalarlo, no lo estamos activando todavía. Por ejemplo, en Ubuntu:

sudo apt-get install zsh

Una vez instalado tenemos que configurarlo. Una de las ventajas de zshell, es que está pensado para que puedas configurarlo de forma modular a través de plugins y templates. Para ayudarnos a gestionar la configuración, vamos a instalar otra cosa rápidamente: oh-my-zsh. Es un framework hecho por la comunidad con un montón de plugins que además de aportarnos funcionalidad extra, hará que sea fácil configurar zsh a nuestro antojo. Tranquilos, instalar esto tampoco activará zsh. Para instalar oh-my-zsh automáticamente solo ejecutamos:

curl -L http://install.ohmyz.sh | sh

Para los indecisos (espero que no quede ninguno al finalizar el post), podéis probar este intérprete sin ponerlo por defecto, y solo hacer el cambio cuando estéis 100% seguros. Para probarlo y ver de qué va esto, ejecutad en la consola:

zsh

Veréis que de repente vuestro prompt ha cambiado. Tranquilos, es normal: zsh tiene configurado un prompt distinto al que bash tiene. Vamos a ver algunas de las ventajas más obvias de zsh. Recordad que siempre podéis volver a dejarlo todo como estaba escribiendo:

bash

Ventajas de zsh

Prompt

Una de las cosas que más nos gusta a los frikis de la consola es configurar nuestro prompt para que aparezca información relevante más allá del _path_ actual en el que estamos. El que zsh trae por defecto ya es bastante bueno, indicando información de la rama actual de git en la que estamos. Esto ya es configurable con bash, pero al haber instalado oh-my-zsh tenemos acceso a todos los themes de la comunidad donde podremos elegir verdaderas maravillas. Para activar un theme, tan solo tenemos que modificar el archivo de configuración en ~/.zshrc y cambiar el que viene por defecto, por uno del listado. La línea a modificar es:

ZSH_THEME="robbyrussell"

Si queremos hacerlo nosotros mismos, podemos configurar no solo el prompt normal, sino que nos permite configurar texto a la derecha del prompt. Para que os hagáis una idea, el que yo utilizo actualmente muestra, además de lo habitual, la rama actual de git, si hay cambios por comittear pendientes, el load de la máquina y la hora actual, estos dos últimos en la parte derecha del prompt. Luce así:

Navegación entre directorios

Probad a escribir ‘cd ‘ y darle a tabulador para que os sugiera los posibles directorios. Dadle varias veces a tabulador y podréis ir eligiendo uno a uno. ¿Que no queréis ir uno a uno? ¡Sin problema! Utilizad las flechas del teclado para navegar entre las sugerencias.

Elegid uno de los directorios para entrar en él. Ahora probad a escribir ‘..’. Con eso iréis al directorio padre. Y si ponéis ‘…’ al superior. Y así sucesivamente. Útil, ¿no?

A veces es un poco engorroso recordar exactamente el nombre del directorio al que queremos acceder. Tranquilos, zsh es muy listo y si intentáis entrar en un directorio pero poniendo solo parte de su nombre, zsh intentará averiguar a cual te refieres y, si lo consigue, entrará en él. Incluso aunque lo que hayas escrito no sea el principio del nombre del directorio.

Además, escribir “cd” para movernos es poco eficiente. Si probáis a escribir tan solo el nombre de la carpeta, sin ponerle el “cd” delante, también entrará en el directorio.

Si llegados a esto todavía no os parece canela en rama, tranquilos, que hay más.

Mejor historial

En la consola acabamos repitiendo los mismos comandos varias veces. Hasta ahora, yo utilizaba control+R para buscar en el historial, o si era un comando reciente, le daba a la flecha hacia arriba del cursor para ir hacia atrás en el historial. Esto está bien, pero zsh lo mejora haciendo que solo vaya recorriendo aquellos comandos que coinciden con lo que tienes actualmente escrito. Es decir, si yo escribo “vim” y voy dándole hacia arriba, solo irá navegando por el historial de comandos que empezaban con “vim”.

Además, siempre podemos conseguir que zsh sea más eficiente, viendo qué comandos son los que más utilizamos y creando alias para ellos. Igual que en bash, con la diferencia de que zsh nos proporciona un comando con información detallada sobre lo que más utilizamos:

Plugins

Todo esto es lo que nos ofrece zsh por defecto, pero lo bueno de oh-my-zsh es que nos ofrece un montón de plugins que añaden alias a acciones de nuestro día a día para que la shell sea todavía más cómoda. Para añadir o quitar plugins, tan solo tenemos que editar el archivo de configuración de zsh situado en ~/.zshrc y modificar la línea de los plugins. Actualmente la mía está así:

plugins=(git autojump colored-man colorize extract zsh-syntax-highlighting)

Con estos plugins obtengo desde archivos del manual con texto coloreado, hasta un comando nuevo llamado extract que puedo utilizar para descomprimir cualquier tipo de archivo comprimido sin preocuparme de cómo se descomprime: él decidirá qué es lo que debe utilizar: zip, gz, etc. Además, como habréis notado en los pantallazos anteriores, cuando estoy escribiendo un comando en la terminal, está coloreado en verde si la shell lo reconoce. Si estoy escribiendo un comando que no existe, zsh lo escribe en rojo.

AutoJump

Quiero hacer mención especial a uno de los plugins que tengo activados: autojump. Si la navegación entre directorio ya es la más cómoda del mundo con zsh, autojump va todavía más allá y va guardando tus directorios más utilizados en tu día a día. De tal forma que tan solo tienes que escribir “j” seguido de una cadena que él intentará matchear contra tu historial de directorios, y entrará en aquel que más hayas visitado. Esta cadena puede ser desde una letra, hasta el nombre entero de la carpeta. En este ejemplo, escribiendo “j w”, él ya sabía que me estaba refiriendo a /var/www.

Para instalarlo tan solo ejecuta:

sudo apt-get install autojump

Dejando zsh por defecto en vez de bash

Si finalmente os he convencido, solo queda activar zsh para que sea siempre vuestra shell, en vez de bash. Para hacer esto, solo tenéis que ejecutar:

chsh -s $(which zsh)

Si por algún motivo que se me escapa quisierais volver a utilizar bash, solo tenéis que ejecutar:

chsh -s $(which bash)

Conclusión

Hay muchísimas más cosas que me dejo en el tintero. Como véis, zsh aporta un montón de comodidades extras a bash. Realmente, no hay nada que no podamos hacer a mano en bash, configurando alias y creando scripts, pero es mucho mejor apoyarnos en la sabiduría de toda una comunidad dedicada a esto.

¿Alguno no se ha convencido de cambiarse?

Enlaces de interés

Problema con ciertos prompts que duplican el comando. Asegúrate de que tu fichero .zshrc tiene estas dos líneas:

export LANG=en_US.utf8
export LC_ALL=en_US.utf8

Limitar memoria máxima de Redis

Thu, 21 Nov 2013 17:59:32 +0000

Haciendo pruebas en uno de los proyectos que tengo, utilicé Redis como sistema de caché, en vez de utilizar Memcached que es el que normalmente uso. Por defecto, Memcached va llenando su memoria hasta que esta se llena, y es entonces cuando empieza a borrar valores existentes para hacer sitio a las nuevas. La estrategia elegida para borrar es eliminar aquellas keys de la cache que han sido menos utilizadas.

Cuando activé Redis para mi proyecto, el proceso _daemon_ del servidor empezó a ocupar más y más memoria hasta que ocupaba casi la totalidad de la RAM del servidor. Poco después, el propio sistema operativo decidió matar el proceso de redis para no morir en el intento.

Si no quería tener que conectarme todos los días a levantar manualmente el daemon de Redis debía encontrar una manera de que esto no ocurriese. Así que decidí que Redis se comportase igual que Memcached: decidir una memoria límite, y que cuando esté llena, empiece a descartar las claves menos utilizadas. Para ello abrí el archivo de configuración de Redis (en mi caso se encontraba bajo /etc/redis/redis.conf), y me llevé una grata sorpresa ya que parecía casi un manual. Todas las opciones estaban muy bien explicadas, incluso con ejemplos.

Buscando la opción maxmemory, me encontré con lo siguiente en el propio archivo de configuración

# Don't use more memory than the specified amount of bytes.
# When the memory limit is reached Redis will try to remove keys with an
# EXPIRE set. It will try to start freeing keys that are going to expire
# in little time and preserve keys with a longer time to live.
# Redis will also try to remove objects from free lists if possible.
#
# If all this fails, Redis will start to reply with errors to commands
# that will use more memory, like SET, LPUSH, and so on, and will continue
# to reply to most read-only commands like GET.
#
# WARNING: maxmemory can be a good idea mainly if you want to use Redis as a
# 'state' server or cache, not as a real DB. When Redis is used as a real
# database the memory usage will grow over the weeks, it will be obvious if
# it is going to use too much memory in the long run, and you'll have the time
# to upgrade. With maxmemory after the limit is reached you'll start to get
# errors for write operations, and this may even lead to DB inconsistency.
#
# maxmemory <bytes>

Así que solo tenía que decidir cuanta memoria quería designar como máximo para Redis. Como lo estaba utilizando de caché, y no como base de datos, no hacía falta que fuese demasiado. Así que decidí poner 256Mb

maxmemory 268435456

Lo siguiente, era decidir qué estrategia debía seguir Redis para descartar claves guardadas en memoria. Una línea más abajo de donde estaba en el fichero de configuración me encuentro esto

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached? You can select among five behavior:
# 
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key accordingly to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys->random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# noeviction -> don't expire at all, just return an error on write operations
# 
# Note: with all the kind of policies, Redis will return an error on write
# operations, when there are not suitable keys for eviction.
#
# At the date of writing this commands are: set setnx setex append
# incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
# sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
# zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
# getset mset msetnx exec sort
#
# The default is:
#
# maxmemory-policy volatile-lru

Así que cualquiera de las 2 primeras estrategias podía valerme para lo que yo quería conseguir. Añadí la siguiente línea

maxmemory-policy volatile-lru

Y listo. Ahora Redis tenía un ímite de memoria, y cuando se llenase, iría borrando valores que hubiesen sido menos utilizados recientemente. Podemos comprobar que funciona correctamente, controlando cuánta memoria está utilizando Redis en un momento determinado. Para ello, tan solo tenemos que utilizar el siguiente comando

redis-cli info | grep memory

Y debería mostrarnos algo parecido a esto

used_memory:268227192
used_memory_human:255.80M
used_memory_rss:293154816

Ahí podemos ver que la memoria no supera el límite que elegimos. El sistema operativo ya no tendrá que volver a preocuparse.

¿Donde pongo mis scripts?

Fri, 27 Sep 2013 18:00:27 +0000

Vale, te has creado un _script_ en Unix para automatizar una tarea, pero después de programar durante horas, ahora viene lo más difícil de todo… donde lo pones?

Podrías ponerlo en la carpeta /bin… o en /usr/bin… incluso en /home/../bin. Para qué tantas carpetas de binarios?

Vamos a intentar explicar para qué sirve cada una.

Jerarquía

Los directorios en Unix siguen una jerarquía que, aunque no lo parezca, intenta tener un sentido. Los más importantes son:

/boot: Cosas necesarias para el arranque.
/lib: Librerías del sistema.
/etc: Configuraciones del sistema.
/proc: Información sobre los procesos que están ejecutándose.
/dev: Aquí encontramos archivos representando dispositivos conectados, como los discos duros o dispositivos usb.
/var: Archivos variables, como los logs.
/tmp: Directorio temporal. La información que hay aquí se perderá cuando reiniciemos.
/bin: Ejecutables indispensables que se usan antes de que se monte la carpeta /usr, o cuando se inicia en modo “_single-user_“. Aquí hay programas como _cat_ o ls.
/sbin: Lo mismo que antes, pero con ejecutables para administradores del sistema. Un usuario normal no tiene permisos para ejecutar estos binarios.
/usr: Contiene ejecutables (bin), librerías (lib) o documentación (doc).
- /usr/bin: Lo mismo que /bin, pero para ejecutables de propósito general.
- /usr/sbin: Igual que /usr/bin, pero para administradores del sistema.
- /usr/local: Contiene programas que no son administrados por paquetes del sistema o el gestor de paquetes
/home: Todo lo relacionado con los usuarios que utilizarán el sistema
- /home/bin: Ejecutables creados por el usuario, para tareas que no son del sistema

Cuando crees un programa propio para _parsear un csv con información, ponlo en tu /home, y cuando instales algún programa, ponlo en /usr/local/bin. Recuerda también que tanto /bin, como /usr/bin y /usr/local/bin están incluídos en el **$PATH del sistema, así que cuando quieras ejecutarlos no hace falta que pongas su ruta completa. Esto no es así para tu /home**, que deberás o bien añadirlo al $PATH_, o crear un _symlink_ de tu programa a /usr/local/bin por ejemplo.

# ln -s /home/fiunchinho/my_program /usr/local/bin/

Evitar borrar todo tu disco con rm -rf

Fri, 20 Sep 2013 18:01:09 +0000

A quién no le ha pasado, verdad? Quieres borrar el contenido de una carpeta con el comando rm, pero sin querer pones el asterisco donde no debías y ZASCA! : todo tu disco duro se ha borrado por completo.

A veces no es tan dramático. A veces solo te equivocas en el directorio que querías borrar. Estabas un nivel más arriba o más abajo del que pensabas y adiós proyecto en el que llevabas toda la tarde trabajando y del que todavía no habías hecho commit.

Posible solución

Una posible solución sería utilizar la opción _-i del comando rm, creando un alias en tu /.bashrc_ para que siempre que ejecutemos _rm_ sea con ese _flag_ activado. Esto hace que nos pida confirmación siempre que lo usamos, para tener un “_double check_” antes de liarla parda.

alias rm='rm -i'

El problema que le veo a esto, es que muchas veces estamos borrando solo un fichero, y es un poco incómodo tener que andar confirmando siempre.

Además, da una falsa sensación de seguridad. Cuando te pida confirmación, tanto tú como yo sabemos que en ese momento no te vas a dar cuenta del error que estás a punto de cometer.

Mejor todavía

Hay una solución mejor. Otro _flag que trae este comando es el -I_. Como su definición indica, nos pedirá confirmación solo cuando estemos a punto de borrar más de 3 ficheros. Si borramos menos de eso, no nos pedirá confirmación.

alias rm='rm -I'

Está claro que tarde o temprano acabaremos liándola, pero con esta opción quizá podamos retrasar ese día unos añitos más.