No space left on device.

¿Cuántas veces habéis visto este mensaje en la consola? ¿Muchas verdad? Bueno, pues como lo que me ha pasado hoy se sale un poco de lo que digamos es usual para un administrador de sistemas (o al menos eso creo) he decidido ponerlo aquí.

Uno de los servidores que reviso, estaba dando problemas. Apache no arrancaba bien, y tampoco Qmail. Revisando en los logs, encontré que la partición estaba llena (no, no fuí yo el que montó ese horrible servidor) así que hice un df -h para ver Hard disk.realmente cuan llena estaba. Reviso la salida y me encuentro con que tiene exactamente 307M libres. ¿Entonces… cómo es posible que me diga que la partición está llena cuando la salida del df -h me dice que tengo espacio aún? La respuesta está en los inodos. Bueno, si revisáis bien, tenéis una opción para el df que es -i y muestra los inodos libres de la partición.

Pues bien, después de saber bien qué necesitaba, sabía qué hacer… y era ir directamente a la cola de Qmail, y con qmHandle borrar lo inservible, para recuperar inodos y así fue. Vuelvo a arrancar los servicios y todo va perfectamente (bueno, eso de perfecto en este servidor no existe claro está).

Espero que esto también le sirva a alguien más, si no es en la cola de Qmail puedes buscar en cualquier otra parte, donde haya una gran cantidad de archivos.

Actualización de OpenBSD 4.1 a 4.2 (OpenBSD update).

El otro día actualicé el servidor a la última versión stable de OpenBSD, por lo que creo que no estaría mal que compartiera eso con vosotros. En primer lugar, debéis tener cvsup instalado, bien desde ports o desde packages.

No voy a poner aquí cómo quedarían los ficheros para el cvsup, porque hay miles de documentos al respecto en internet. Sólo ve a Google y revísalos.

Una vez ya los tengas listos:

cvsup -gL2 ports-supfile

cvsup -gL2 stable-supfile

cvsup -gL2 xenocara-supfile

Recuerda que desde esta versión, viene con Xenocara. Una vez que tengas ya actualizado todo el árbol de ports, código y xenocara, nos toca lo siguiente:

cd /usr/src/sys/arch/i386/conf/

config GENERIC

cd ../compile/GENERIC/

make clean && make depend && make && make install

Esto recompilará el kernel. Una vez haya finalizado, debemos reiniciar. En cuando entremos de nuevo, veremos que el kernel ha sido actualizado, y ahora nos toca el userland:

rm -rf /usr/obj/*

cd /usr/src/

make obj

cd /usr/src/etc && env DESTDIR=/ make distrib-dirs

cd /usr/src

make build

Esto compilará el userland. Tardará un buen rato, dependiendo de qué tan rápida sea tu máquina.

Cuando termines, recuerda:

/usr/local/sbin/mergemaster

Ojo con la comparación de los ficheros que han cambiado de una versión a la otra, puedes hacer que no funcionen muchas cosas si no lo lees detenidamente. Reinicia de nuevo, y asegúrate de que todo estaba como antes, o que sólo necesitas algún ajuste. Os recuerdo que ahora no habrá port de expat ya que viene de base en xenocara. Tranquilo, ahora sólo tendrás que actualizar los paquetes, pero antes hay que compilar xenocara, para que los paquetes nuevos puedan funcionar, ya que no usarán el antiguo expat:

Recuerda que xenocara debe estar en /usr/src/xenocara, modifica tu cvsup-file si no es así.

cd /usr/src/xenocara

make bootstrap

make obj

make build

Y ahora, a esperar. Cuando termine, actualiza tus paquetes:

env PKG_PATH=”ftp://rt.fm/pub/OpenBSD/4.2/packages/i386/” pkg_add -ui -F update -F updatedepends

NOTA: Yo tengo aquí el mirror de rt.fm, tú puedes escoger el que más te guste o más te convenga.

Ahora verás cómo va actualizando paquete por paquete, y quizás te pregunte alguna cosa, que él no sabrá decidir por sí mismo. Una vez haya terminado y hayas verificado que ha ido bien, podrás eliminar expat:

pkg_delete expat

Recuerda que todos estos comandos, debes hacerlos como usuario root, y que para una mayor información, haz como hice yo, revisar la documentación del proyecto de OpenBSD que para algo está:

Actualización de 4.1 a 4.2

Compilar desde los fuentes.

Un saludo y espero errores, modificaciones, preguntas, etc en los comentarios.

La incompetencia de la Seguridad Social.

De verdad es que es la repera, vulgarmente dicho. ¿Cómo es posible que el servidor de la seguridad social, cuando nos envía un correo electrónico no permita el sender verify? Me encuentro con lo siguiente:

2007-10-22 15:43:33 [...] sender verify fail for <FileTransfer@seg-social.es>

Resumiendo y para los que no sepan qué es esto, se lo explicaré brevemente. Cuando alguien nos envía correo a nuestra dirección existe la posibilidad de que el servidor a donde llega el correo, verifique si realmente existe la dirección del remitente. Veámoslo de la siguiente manera:

nos envían una carta, desde la empresa MeLaInvento, el logotipo en el sobre, todo bien impreso, etc. Pero como resulta que hay personas que se hacen pasar por esta empresa, decidimos llamar a la empresa MeLaInvento para preguntarles si son ellos los que enviaron esta carta, para evitar fraudes. Lo que ocurre es que en vez de recibirnos, nos dan con la puerta en las narices, sin darnos una explicación. Resumidas cuentas, esto es lo que ocurre. Siendo para algo tan “para toda las opciones y configuraciones” deberían permitir este tipo de verificaciones, puesto que muchas personas estarán teniendo serios dolores de cabeza con esto. En este caso en concreto, el ejemplo es sacado de una máquina con CPanel instalado, con Exim. Aunque no me gusta ninguno de los dos, hay veces que uno tiene que adaptarse a todo, por lo que me adentré en la configuración, para sin quitar esta protección (que afectaría a los demás clientes si la quitamos, con una lluvia de SPAM considerable) habilitar la entrada de correos de la Seguridad Social sin verificación de remitente. Lo que hice fue lo siguiente:

Edité el fichero de configuración de CPanel, en mi caso /etc/exim.conf y buscamos esta parte:

domainlist relay_domains = lsearch;/etc/localdomains : \
lsearch;/etc/secondarymx :\
lsearch;/etc/whitelist.domains

La entrada que he metido es la última (OJO con el :\ del final de la anterior que indica que “hay más debajo”. El fichero tiene que existir evidentemente, y contendrá un dominio por línea, y es ahí donde tendremos que meter: seg-social.es (o el dominio que queramos meter en la lista blanca) para que lo deje entrar sin revisar el remitente.

Reiniciamos el Exim y listos.

OpenBSD: MaraDNS.

En este post intentaré explicar cómo montar un servidor de DNS con MaraDNS sobre OpenBSD.

Lo primero, instalar desde ports:

cd /usr/ports/net/maradns

make install clean

Una vez instalado, creamos el directorio /etc/maradns (este directorio puede tener el nombre que quieras, no necesariamente el que ves aquí, aunque me pareció el má apropiado).

mkdir /etc/maradns

Luego nos vamos a la configuración por defecto:

cd /usr/local/share/examples/maradns

En este directorio tienes buenos ejemplos de configuración para que los revises. Aquí pondré la configuración de la siguiente forma:

fichero /etc/maradns/mararc

ipv4_bind_addresses = “aquí_debes_poner_la_ip_donde_está_MaraDNS”
chroot_dir = “/etc/maradns”
verbose_level = 3
recursive_acl = “0.0.0.0/0″

csv2 = {}
csv2["dominio_uno.com."] = “db.dominio_uno.com”
csv2["dominio_dos.com."] = “db.dominio_dos.com”

Ahora, los archivos de zona de cada dominio: (este sería db.dominio_uno.com)

dominio_uno.com. NS ns1.dominio_uno.com.
dominio_uno.com. NS ns2.dominio_uno.com.

dominio_uno.com. A 64.85.161.4
www.dominio_uno.es. CNAME dominio_uno.com.

dominio_uno.com. MX 10 mail.dominio_uno.com.
Arrancar MaraDNS desde el inicio:

Editamos /etc/rc.local y añadimos lo siguiente:

if [ -x /usr/local/bin/duende ]; then
echo Starting maradns…; /usr/local/bin/duende /usr/local/sbin/maradns -f /etc/maradns/mararc
fi

NOTA: Recuerda que debe estar en una línea, a menos que lo dividas a propósito. Para guiarte mira los otros if que tienes.

Para arrancarlo en el momento, sólo tienes que usar el comando de más arriba, como root claro está.

Espero que le haya servido de ayuda a alguien y recordad que me puedo equivocar, los comentarios serán bienvenidos.

Más información sobre cómo configurara MaraDNS aquí.