sistemas (Página 30) - Userlinux.net

Las tareas programadas en cron por defecto reportan un correo electrónico con la salida del comando a la cuenta local del propietario de la tarea. Si por alguna razón no queremos que ese correo se envíe tenemos varias alternativas que podemos encadenar para garantizarlo.

Por un lado podemos intentar eliminar la salida de errores en las tareas que hemos programado, bien en la propia tarea o bien haciendo uso de /dev/null/. Y por otro lado está el uso de la variable MAILTO en el cron del usuario, vamos a describir un poco más cada una de estas opciones.

Cuando trabajamos con servidores de versiones seguro que hay muchas razones de peso de por medio, una de ellas -la que veremos- puede ser la replicación de código en diversas máquinas.

Supongamos un montón de máquinas que comparten el mismo código de repositorio, el orden de propagación de un cambio en todas esas máquinas es sencillo:

1. Programamos dicho cambio en nuestro servidor de desarrollo (devel).
2. Hacemos un commit local (en sistemas de versionado distribuido -como Mercurial- cada repositorio también es servidor).
3. Lo siguiente es un push al servidor donde almacenamos el código (repo código).
4. Ahora tocaría entrar en cada una de esas máquinas en las que queremos propagar el código y ejecutar un hg pull ; hg update.

Necesitaba instalar Mercurial en varias máquinas totalmente desactualizadas, concretamente una Fedora Core release 4 (Stentz) y una CentOS release 5 (final), pensé que iba a ser un lío de dependencias pero al final ha resultado inexplicablemente más sencillo de lo esperado:

No todos tenemos un router super configurable, ni un dd-wrt, ni un NSLU2 ni nada parecido (se aceptan donaciones), algunos nos conformamos con el cable-modem que nos ofrece nuestro proveedor de servicios y como tal estamos limitados a ciertas acciones.

Los que -además- somos cutres y no deseamos pagar un plus por obtener una IP fija no tenemos otra opción que tirar de fantásticos servicios como DynDNS, encargados de redirigir cada cambio de IP a un nombre que nosotros elijamos dentro de las posibilidades.

Todas las veces suele ocurrir de forma similar, estás probando algo que -de repente- tarda demasiado en ejecutarse y es entonces cuando empieza a subir una especie de sentimiento calórico desde el estómago a la cabeza según te vas dando cuenta de lo que puede estar pasando de fondo.

El resultado puede ser distinto según la ocasión, un servidor caído, una base de datos eliminada, datos redundantes, inconsistencia en un sistema de ficheros... pero el susto y la situación son similares.

En este caso ha sido a través de un script de migración, ¡que mejor prueba que ésta web para el nuevo rCMS!, así que mientras $link_viejo y $link_nuevo se hacían la picha un lío en los mysql_connect(), mi cabeza ardía pensando en la fecha del último backup: 17 de febrero.

Resultado: Se han perdido los comentarios de los últimos 10 posts y varios updates del error 8001050f. El estropicio no ha sido nada comparado con lo que se me ha calentado eso que sale del cuello y suelen llamar cabeza.

Entre que llevamos toda la tarde con cortes en la conexión -por cierto, últimamente se están acentuando bastante, punto negativo para R- y que ha dejado archivos a medio guardar solo faltaba el maldito Plesk.

Nota mental, si tienes pensado reiniciar -el maldito Plesk- y tienes entradas Bind agregadas de forma manual acuérdate de reponerlas antes de nada, te ahorrarás un cabreo.

En serio -y vuelvo a repetir por enésima vez- cuanto menos conozca de estos mamotretos más años viviré. ¡AWS ya!.

Lo tenía pendiente desde que cambié de Subversion a Mercurial, sabía que se podía y que era algo trivial pero lo vas dejando y bueno, just happens. El caso es que cuando haces un push al servidor lo normal es hacer un update de su lado, así que el hook que lo automatiza es el correspondiente:

[server]$ cat /path/del/repo/.hg/hgrc
[hooks]
changegroup = hg update

Y fuera preocupaciones. La obligada referencia a Tao of Mac, desde donde me vino la inspiración mientras intentaba poner el Macbook a punto.

He visto este gráfico en el blog de David Anguita y me ha parecido curioso e interesante. Por eso quiero compartirlo con vosotros, linuxeros de pro: No sabéis lo que me alegro de haber hecho los primeros pinitos como pingüino con Slackware, aunque hace tiempo que la tengo olvidada me siento uno más de la Subgenius Church... simplicity is divine!.

Todos sufrimos con más frecuencia de lo deseado intentos de ataques por fuerza bruta en los servicios que ofrecen nuestras máquinas, es inevitable. Pero con herramientas como DenyHosts podremos controlar mucho mejor estos intentos de violación. Su instalación y posterior configuración son triviales, tan solo debemos comprobar que tenemos python instalado en el sistema y poco más:

# dpkg --list | grep python2
ii  python2.5...
# python -V
Python 2.5.2
# apt-get install denyhosts

Una vez instalado pasamos a configurar el archivo /etc/denyhosts.conf, que es el que tiene toda la chicha:

Después del owned con el que hemos puesto fin al 2009 ha llegado un nuevo servidor de desarrollo y con ello su consecuente migración (y problemas varios).

Ha llegado despiezado así que nos hemos puesto manos a la obra para restaurar el servicio cuanto antes, primero el hardware y luego -wiki en mano- los servicios correspondientes. El primer problema -que en principio no ha trascendido demasiado- ha sido la migración de los repositorios Subversion a la nueva máquina. Digo problema porque nunca había migrado un SVN, pero todavía sigue quedando gente que documenta estas operaciones para hacer la vida más sencilla a los demás.