Acostumbrado a GnomeBaker, K3B, XcdRoast y similares hacía demasiado tiempo que no grababa un CD en consola pura. En Linux esta tarea corresponde habitualmente a cdrecord con su habitual longaniza, pero esta vez era una FreeBSD la toqueteada así que, al no tener soporte nativo de dicho programa, se hizo con burncd:

root@maistler isos > burncd -f /dev/acd0 -s 16 -e data debian-31r2-i386-netinst.iso fixate
next writeable LBA 0
writing from file debian-31r2-i386-netinst.iso size 111224 KB
written this track 111224 KB (100%) total 111224 KB
fixating CD, please wait..
root@maistler isos >

Lo del soporte nativo viene a ser que en releases anteriores de FreeBSD, el kernel GENERIC no traía soporte ATAPI/CAM, con lo que, para poder usar cdrecord, había que recompilar kernel con un añadido (device atapicam). Mucha gente optaba por ello, instalando posteriormente el programa para tener la misma herramienta que en Linux.

Como en su día me dijo Juanjo: BSD no es Linux, con lo que, siguiendo unas pequeñas normas, si tenemos una herramienta nativa que hace el trabajo, ¿para qué enrevesarlo todo?.

Cuando tratas de actualizar masivamente los paquetes de un servidor FreeBSD es porque basicamente has dejado pasar bastante tiempo desde la última actualización y probablemente encuentres sorpresas por el camino. La primera de ellas ha sido pear-PEAR, lo han cambiado de sitio y con los últimos ports no había Makefile disponible para compilación, con lo que... cual escopeta de feria.

Menos mal que tenemos un /usr/ports/UPDATING que en este caso nos ha ahorrado mucho tiempo:

20051213:
  AFFECTS: users of pear ports
  AUTHOR: ale@FreeBSD.org

  A few old pear ports have been removed from the tree in favour of a
  single devel/pear port.  If portupgrade complains about missing ports,
  you may safely remove pear-XML_RPC, pear-Console_Getopt, pear-Archive_Tar
  and php[45]-pear and then run:

  portupgrade -o devel/pear -f pear-PEAR

El siguiente susto ha sido actualizando courier-authlib-base y courier-authlib-mysql, aunque me decanto por el último sin saber muy bien lo ocurrido. Después justo de actualizar el paquete reinicio el authdaemond y a partir de ese momento IMAP ha dejado de funcionar, miro las configuraciones y veo que /usr/local/etc/authlib/authmysqlrc no es para nada lo que yo había configurado tiempo ha. Me sonaba más el contenido de authmysqlrc.bak.

Presupongo que alguno de esos dos paquetes ha sobreescrito mi configuración por la de casa, cosa que no me ha gustado demasiado. Mea culpa por otro lado, si en vez de ejecutar un portupgrade -a hubiera puesto -an la historia sería otra.

De todas formas no salgo de mi asombro al ver que con pkg_info todas mis suposiciones se van al traste:

# pkg_info -L courier-authlib-mysql-0.58
Information for courier-authlib-mysql-0.58:

Files:
/usr/local/etc/authlib/authmysqlrc.dist
/usr/local/lib/courier-authlib/libauthmysql.so
/usr/local/lib/courier-authlib/libauthmysql.so.0
/usr/local/share/doc/courier-authlib/README.authmysql.html
/usr/local/share/doc/courier-authlib/README.authmysql.myownquery

No sé si es un bug del port, si notificar un pr o que... En fin, llamaremos a Mulder & Scully que vengan a hacer de forenses.

Ahora que he organizado minimamente alguna tarea de esas que uno tiene siempre pendiente y necesita retocar... Una vez instalado, puesto en producción y comprobado el rendimiento de un servidor en FreeBSD, llegamos a la administración del mismo y los -siempre buenos- advisories de seguridad.

Oh! un advisory

Hace un par de días se puede leer en Security Advisories de FreeBSD un correo indicando un potencial rollback de ssl 2.0. ¿Qúe significa esto?, ni idea... por la descripción del correo parece ser que en un entorno ideal (SSL_OP_MSIE_SSLV2_RSA_PADDING activado en servidor), un atacante puede hacer que tanto cliente como servidor usen SSLv2 en vez de SSLv3 con los consiguientes riesgos.

Siguiendo con el montaje de Postfix+SASL2+MySQL y ya configurando el servidor Courier-IMAP (imap+pop) me encuentro un cambio, no sé si importante o no, pero al menos trascendental para ciertas configuraciones.

Los archivos de configuración de courier-imap antiguamente estaban en /usr/local/etc/courier-imap. En 5.4 siguen ahí, pero el demonio de autentificación de authdaemon (el que conecta con MySQL buscando usuarios virtuales) no verifica su configuración en ese directorio (como hacen courier-pop3 y courier-imap), ahora las configuraciones han de ubicarse en: /usr/local/etc/authlib (concretamente authdaemonrc).

Nota1: Al instalar Amavis (A Mail Virus Scanner) coloca los scripts de inicio en /etc/rc.d en vez de /usr/local/etc/rc.d como hacen todos los programas userland, mandar un pr ;).

Nota2: Si el Pear:DB no funciona, hay que editar php.ini y añadirle la siguiente linea: include_path=".:/usr/local/share/pear"

Nota3: Tener mucho cuidado con master.cf y main.cf porque si las versiones de Postfix varían un poco puede dar más de un quebradero de cabeza :P.

Hace unos días estoy intentando retomar mis conocimientos de BSD, centrados concretamente -en esta ocasión- en FreeBSD y considero que hay un par de consejos que conviene dejar escritos para futuras revisiones :D.

Cualquier sistema operativo tiene fallos de seguridad y FreeBSD no iba a ser una excepción. Quiero aclarar que cuando hablo del sistema operativo y centrándome de nuevo en este sabor de BSD me refiero al sistema base, como todos sabeis FreeBSD se compone de un sistema base y las aplicaciones (userland) instalables vía ports o packages.

Y yo me pregunto con toda la cara dura del mundo, ¡¡cómo coño va a funcionar un SMP en FreeBSD teniendo un micro quemado!! (extiéndase a cualquier sistema operativo que no sea capaz de hacer magia).

Necio de mí estaba de nuevo dándome golpes en la cabeza autoculpándome de haber dejado demasiado tiempo desde la última vez que toqué una FreeBSD. Necio de mí pensaba que el SMP quería reirse de otro desgraciado BOFH más. Necio de mí traté de verificar con un sistema operativo propietario. Bendito yo y mi conciencia, lo tranquilos que estamos ambos.

Me gustan las estadísticas, hasta cierto punto es bueno cuantificar algunos datos con el fin de conocer mejor algunos aspectos de tu sistema. Algo que se me ha escapado hasta ahora es el consumo instantáneo -en un momento dado- de ancho de banda. Varias alternativas asomaron cabeza sin ser demasiado convincentes, IPTraf, ntop... pero quería algo especial, sencillo y sin demasiadas dependencias, algo funcional e informativo, que con tan solo echar un pequeño vistazo pudiera hacerme la idea del porcentaje usado... ¿qué os parece ésto?: IFTop es justo la solución que buscaba, sencillo como top y tremendamente eficaz. Distintas opciones, métodos de ordenado, filtro y visualización hacen que se haya convertido, en menos de media hora, en una herramienta indispensable para cualquier BOFH.