Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

Candyman (7)

Candyman
  (email no mostrado públicam.)

Down Kill Up Publicidad

Jueves, 25 de Noviembre 2010

Samsung Galaxy S con Froyo + OCLF: como nuevo

01:51h.
Android
Ayer actualicé mi Galaxy S a Android 2.2 "Froyo", y le puse otra vez el LagFix de RyanZA. El resultado es como un móvil nuevo.

Según los benchmarks sintéticos duplica la velocidad del mismo teléfono sacado de la caja (la ilustraci'on del artículo enlazado es totalmente cierta). En realidad sé que ese número no vale para nada, pero satisface mucho. Lo que es cierto es que antes se bloqueaba durante decenas de segundos, y ahora va todo fluido. Incluso me da la sensación de que o los de Google o quien haya preparado el instalador ha corregido otras cosas como el perfil de color de la pantalla, dado que los blancos están más equilibrados, sin el tinte azul que tenía antes. En general, todo va mejor.

Sobre el Lag Fix: El Galaxy S es una máquina estupenda, pero lastrada por un tremendo error de los ingenieros de Samsung, que montaron un sistema de ficheros de juguete que crea unos problemas de retardo de i/o apabullantes: "RFS is simply a FAT16 (maybe 32 too, in my movinand.bin is 16) with a transaction log for journaling (file $rfs_log.lo$) in root and a partition mark of 0x83 (linux)"

El One Click Lag Fix de RyanZA es elegante en su simpleza. Consiste en montar en modo loopback una partición EXT2 sobre un fichero muy grande dentro de esa partición RFS, y usar la partición EXT2, que no tiene los problemas de retardo de lectura/escritura. Además es una aplicación instalable desde el Market, o mejor dicho dos: una gratuita y otra de pago. Las dos contienen el mismo código, sólo que con una le puedes dar una donación como muestra de tu agradecimiento. La verdad, que te dejen el teléfono como nuevo por menos de dos euros vale la pena.
Jueves, 04 de Noviembre 2010

Recuperación de la cuenta @barrapunto en Twitter

12:22h.
Bitácoras
Ayer le escribí a quien lleva la cuenta @barrapunto en Twitter pidiéndole que por favor me de la contraseña, y alguien (que supongo es la misma persona) ha puesto una encuesta preguntando al respetable qué cree que se debería hacer.

Por si queréis dar vuestra opinión.
Martes, 02 de Noviembre 2010

Actualizada máquina con base de datos a Lenny

02:13h.
Barrapunto
Acabo de actualizar la máquina que ejecuta la base de datos de barrapunto a Debian Lenny. Por ahora parece que no ha explotado nada. Cruzando los dedos.

La máquina que lleva el servidor web es algo más preocupante. Todavía va con Sarge sobre 32 bits. Un día de estos vamos a tener que sacarla del centro de datos y darle un repaso.
Domingo, 31 de Octubre 2010

Corte de servicio ayer sábado por intrusión via phpmyadmin

11:35h.
Barrapunto
Somos unos pupas. Poco más de una semana después de la corrupción del disco con la partición /var, ayer tuvimos un parón de unas 14 horas debido a una intrusión. Este es el resumen de lo ocurrido.

- Hace dos días instalé phpmyadmin para controlar la base de datos de barrapunto.
- Unas 12 horas más tarde, un script automático escaneó y explotó la instalación de phpmyadmin e instaló un cliente de botnet.
- El exploit sólo afectó al usuario www-data, y estamos razonablemente seguros de que no fueron afectados ni root ni otros usuarios con más permisos.
- Sin embargo, fuera por un bug o porque el propósito del bot era hacer DDoS externo, el caso es que hacia las 2 AM de la mañana del sábado la máquina de la base de datos empezó a saturar la conexión ethernet, hasta el punto de dejar las dos máquinas totalmente inaccesibles desde el exterior.
- Al principio creía que era un problema de red, pero los técnicos de Nova vieron lo que pasaba, y quitaron el gateway para dejar las máquinas de barrapunto en cuarentena.
- Cuando me comuniqué con ellos, me abrieron acceso por VPN, con lo que pude comprobar que la máquina que hace de servidor web estaba bien, y la máquina afectada era la que sirve de base de datos.
- El diagnóstico del bot fue vía htop. Aunque al principio me asusté mucho pensando que era un juanquer humano y que había llegado a root, pronto estuvo claro que esto era un ataque automatizado y que sólo estaba en www-data. Tenía cuatro o cinco procesos muy evidentes, ejecutando un sshd y un programa llamado std desde el directorio /tmp/-/...
- La limpieza del bot fue manual: parar los apaches, borrar el directorio /tmp/-/... donde estaban los scripts, y comprobar que no había más perlas envenenadas en los crontabs.
- De paso aproveché para desinstalar servicios que no se usan, además de phpmyadmin, por supuesto.
- Hacia las 16h ya había terminado y mandado mensaje a Nova de que volvieran a conectar las máquinas. Lo hicieron podo después.

No lo sé con precisión, entre otras cosas porque estoy en Australia y porque entre medias coincidió con el cambio de hora en España, pero calculo que la máquina estuvo fuera de servicio unas 14 horas.

Las lecciones aprendidas son:

- No echarle la culpa a la red cuando puede ser que sea tu propia máquina la que esté causando el problema de red.
- Las guarradas en php son guarradas aunque las empaquete Debian.
- En particular, phpmyadmin es una leprosería.
- Voy a montar phpmyadmin restringiéndolo sólo a localhost, y lo miraré con un túnel ssh. Por el mismo precio, consigo también un proxy desde el que ver qué anuncios servimos desde España.
- Las cosas no son tan malas como las ves a las 2 de la madrugada: a las 4 de la madrugada ya había resuelto el entuerto.
- A las horas que eran, no se me ocurrió guardar los malwares para mandárselos a los laboratorios a analizar. La próxima vez no seré tan rápido con el borrado.

Gracias a los barrapunteros varios que me echaron una mano, primero para serenarme, y luego para resolver el problema. Muchas gracias también al equipo técnico de Nova, no sé lo que haría sin ellos.
Jueves, 21 de Octubre 2010

Fallo en el servicio de Barrapunto

02:49h.
Barrapunto
En algún momento del día de ayer se corrompió la partición /var de gamma.barrapunto.com, la máquina que nos sirve la base de datos. Dado que la base de datos está en /var/lib/mysql, esto era una avería muy seria, que algunos de vosotros nos señalásteis por correo, dado que no podíais hacer login en el sitio.

Con la inestimable ayuda de algunos amigos conseguí recuperar el control de la máquina y reparar la partición de /var. Sin embargo, algunas de las tablas de la base de datos se quedaron corruptas, y el daemon slash dejó de actualizar las noticias de portada y otros sistemas de barrapunto. Por desgracia usamos tecnología del siglo pasado, con almacenamiento ISAM, así que hubo que rehacer los índices a mano y con la base de datos parada y el sitio fuera de línea.

El funcionamiento normal del sitio quedó restablecido a las 9h de hoy, hora española. Calculo que estuvo descabalado (mostrando noticias atrasadas pero sin permitir acceso a usuarios registrados) unas 7 horas, y otras dos más totalmente fuera de servicio.

Menos mal que había hecho un backup remoto hace sólo tres días, porque he tenido unas horas de mucho susto, y sin una copia de seguridad la tensión habría sido aún mayor.

En el corto-medio plazo, la base de datos tendrá una réplica automática en otra máquina en el mismo centro. La réplica se usará para las copias de seguridad, los cálculos del demonio slash, y para tener un "remplazo caliente" en caso de que tengamos un accidente irreparable.

Gracias a todos los que habéis escrito informando del fallo, y sobre todo a los amigos (y amigas) que habéis prestado tiempo y talento en ayudarme a la recuperación.
Sábado, 16 de Octubre 2010

Anuncio: backups remotos en la madrugada de mañana domingo

01:49h.
Barrapunto
Actualización:Voy a empezar haciendo un backup remoto semanal con rsync (alias ñapa) mientras evaluo dirvish vs rdiff-backup vs rsnapshot vs duplicity. Si tenéis pros y contras de cada sistema, los agradezco. Ah, y ya se han encargado de martillearme en la cabeza que "version control is not backup". Gracias también por eso.

La semana pasada se llenó /var de una de las máquinas, y hubo un pequeño paroncillo en barrapunto. No os daríais ni cuenta porque fue de madrugada en España, y también porque me pilló editando, con lo que me dí cuenta en seguida y lo resolví inmediatamente. Esto me sirvió también para darme cuenta de que la situación de backups de barrapunto es mejorable, así que vamos a mejorarla.

Mañana domingo durante las 00h y las 10 o así de España estaré organizando los backups remotos de barrapunto. Como habrá que hacer un par de transferencias tochas y además estaré trasteando en las máquinas, es posible que el servicio se resienta. Pido disculpas adelantadas si esto es así, aunque intentaré que el trastorno sea mínimo.

Por cierto, que si alguien quiere opinar, todavía está a tiempo de darme un consejo. Voy a organizar los backups así:
- Locales: backup diario de la máquina A a la B, y vice-versa, usando rsync para los directorios de slash (dado que crea un fichero shtml nuevo por noticia, hay que hacer backup diario del directorio raíz) y un dump de la base de datos copiado encima del anterior, sin versionear.
- Remotos: sobre los backups locales, dirvish hará una copia remota diaria en un VPS sólo para la ocasión, donde se mantendrán 30 días de rotación. De esta copia me haría yo una copia más en mi casa con periodicidad semanal.

La idea es que si casca un disco duro o hay una corrupción local, es más fácil hacer la transferencia con el backup del día anterior que estará situado en una máquina en el mismo rack. Si pasa algo más gordo en plan "se quema el centro de datos" o "nos rootean y hay que mirarlo todo con lupa", pues tenemos el último mes de backups en un sitio remoto.

Ahora mismo los backups son sólo locales con rsync de una máquina a otra y sin versiones. No puedo versionar mucho porque los discos empiezan a andar algo cortos, y aunque dirvish hace sólo copias nuevas de los cambios (y el resto lo enlaza con hardlinks), prefiero no tener que jugar al whack-a-mole con el espacio de disco como he estado haciendo la semana pasada.

Si tenéis opiniones o consejos, no voy a empezar a currar hasta dentro de 20 horas, así que todavía puedo cambiar los planes.
Miércoles, 28 de Julio 2010

Si heredas listas de correo sobre Mailman

06:53h.
Correo electrónico
Esta es otra de esas notas para mí mismo.

Si en el futuro vuelves a heredar un servicio de listas de correo electrónico sobre Mailman (doy por hecho que es un sistema debibuntu, porque el único que va a leer esta nota en el futuro serás yo mismo), estos son los sitios donde tienes que mirar : /etc/mailman/ /usr/lib/mailman/bin/ /usr/lib/cgi-bin/mailman/

Primero cambia la contraseña maestra de mailman con /usr/lib/mailman/bin/mmsitepass

Si la interfaz web funciona, puede que no necesites hacer nada más. Pero si el dominio en el que respondía dicha interfaz web se ha dejado caducar, lo mismo tienes que:

Retocar en /etc/apache2/sites-enabled/$vhost para apañar configuración de la interfaz web. Si no existe, ya sabes por qué no te funcionaba la interfaz web.

Darle un repaso también a /etc/mailman/mm_cfg.py para sincronizar la configuración con la que hayas puesto en el fichero de vhosts de apache.

En este momento puedes reiniciar Mailman. Yo lo hago con /usr/lib/mailman/bin/mailmanctl stop y /usr/lib/mailman/bin/mailmanctl start. Es pura superstición no usar restart, pero quieres estar seguro de que te vuelve a leer mm_cfg.py, porque...

Lo siguiente que vas a hacer es decirle a las listas existentes que usen la nueva configuración para la interfaz web con /usr/lib/mailman/bin/withlist -l -r fix_url $nombredelista...

Y ya está. Para bitácoras de barrapunto, desde 2010, Hari Seldon.
Jueves, 14 de Enero 2010

Mi primera contribución a un proyecto de software libre

07:35h.
Python
Ayer Sean B Palmer, autor del bot de irc phenny, aceptó mi parche para la gestión de contraseñas de servidor. Es una pavada de unas diez líneas distribuídas entre tres ficheros de python, pero añade una funcionalidad que alguien ha considerado útil (además de yo mismo).

Todos los viajes comienzan con un primer paso: éste es el mío.
Jueves, 13 de Noviembre 2008

Mutex en Bash

04:04h.
Unix
Sólo un par de notas para mí mismo:

Mutex en Bash

Señales en Unix

Y un truco que incluye Bash que me ha comentado Heimy, y que no creo que use esta semana:

Smashing the Stack for Fun and Profit
Miércoles, 29 de Octubre 2008

"Fork off and Die" (con perdón) en Bash

01:32h.
Unix
Espero que al siguiente que meta "fork off and die bash" en un buscador le salga algo más útil que a mí, y es posible que hasta le sirvan estas dos recetas (una buena y una mala) a las que he llegado hoy.

Básicamente el encargo que tenía era el de "daemonizar" un programa en bash. La plataforma es CentOS, que tiene su propia librería de apoyo al proceso de init en /etc/init.d/functions, con lo que realmente no tengo que preocuparme de manejar los comandos de start y stop, porque puedo modificar uno de los scripts existentes, ni tampoco ocuparme del seguimiento de pids y locks. Todo esto lo hace por mí la infraestructura, que para eso está (CentOS todavía no la lleva el Partido Republicano de los EEUU, si no se empeñaría en que cada daemon se ocupara de lo suyo, y que lo demás es ¡socialismo!).

Pero los demonios en sí, los programas que hacen el trabajo, tienen que saber hacer un hijo y morirse para que el hijo sea adoptado por init. Es lo que tradicionalmente se llama "fork off and die". Con una riqueza léxica e idiomática como esta, no es de extrañar que Unix siga pujante tantos años más tarde.

Alguna gente a la que he consultado me sugería que hiciera algo así como esto:

!#/bin/bash
# /etc/init.d/blargh
# this is the part that starts the daemon
(/usr/local/bin/blarghd -options) &

Pero el problema es que el código que hace el fork tiene que estar en /usr/local/bin/blarghd, no en /etc/init.d/blargh. La razón es que las funciones de apoyo de CentOS esperan que el programa que se lance desde /etc/init.d/blargh start (nuestro blarghd, en este ejemplo) devuelva un 0, como corresponde a los buenos ciudadanos de Unix, para comunicar que ha hecho un proceso hijo y se ha suicidado (para que el hijo sea adoptado por init). Sin ese 0, las funciones de apoyo no van bien.

Tras leer un par de ejemplos de "fork off and die" en perl y en C, hablar con la gente de #bash y sobre todo dar la lata a mis colegas de #rowr (gracias seti y jillzilla), esta fue la solución a la que llegué:

!#/bin/bash
# /usr/local/bin/blarghd
# this is a hack because bash's "&" is "fork and exec",
# there is no explicit fork() in bash!
if [ "$1" != "-d" ]; # invoked without the "-d", we are the parent
        then # so
        codec -d & # we fork off
        exit 0 # and die!
fi
# main code here

Sin embargo, en cuanto se lo enseñé a los ciudadanos de #bash en freenode, me dijeron que lo que yo quería se podía hacer mucho mejor así:

!#/bin/bash
# /usr/local/bin/blargh
{ #main code here } &

Ni siquiera hace falta ponerle un exit 0 explícito, porque el script sale y devuelve un "success" por defecto.

Resulta que esta solución me la habían ya sugerido varias personas, entre ellas los propios seti, jillzilla, y también varios de los dudes debianeros con los que me junto. Pero todos parecían entender que yo quería ponerlo en el script de /etc/init.d/blargh que lanza el demonio, no en el demonio en sí. Incluso me decían "pero no lo hagas en el script de /etc/init.d/, hazlo fuera", cuando fuera es donde yo quería hacerlo.

De este ejercicio saco cuatro aprendizajes:
  1. Lo fácil que es "fork off and die" en bash. Como dicen seti y jill, bash es una herramienta de hacer forks.
  2. Lo difícil que es hacerse entender en IRC, especialmente bajo stress, y también cuando las personas con las que te comunicas no se fían de que lo que dices que quieres hacer es lo que necesitas hacer, exactamente.
  3. Lo fácil que es "escribir fortran en cualquier lenguaje": mi hack es una traducción forzada, un calco de la expresión idiomática en perl o en C. El código necesario consistía exactamente en tres caracteres.
  4. La capacidad expresiva del código como herramienta de comunicación entre humanos. Lo que he tardado una hora en explicar, discutiendo y debatiendo, antes de llegar a mi primer ejemplo con la ayuda de seti y jill, lo han entendido en #bash con sólo leer el código, en apenas segundos. En este sentido la primera solución ha sido todo un éxito, porque si bien no es la forma óptima de plantearle el problema al ordenador, sí que ha sido una forma excelente de plantearles mi necesidad a expertos humanos.

Ahora, otra duda:

Como /etc/init.d/blargh necesita recibir el 0 de blarghd, no puede lanzar blarghd así:

blarghd > /dev/null 2> /dev/null < /dev/null

El código que cierra stdout, stderr y stdin tiene que estar dentro de los corchetes estos de { ... } &, dentro de blarghd. Aquí es ya muy tarde y me tengo que acostar. Pero seguro que para cuando me levante alguien me habrá contestado, además de decirme en qué me he equivocado con esta historia.