En los regalos hay dos tipos de personas, las que leen el manual de instrucciones del juguete y las que directamente se ponen a probar todos los botones. Yo casi siempre me he quedado en el segundo grupo.

Sin embargo con el tiempo me estoy dando cuenta de la importancia que tiene leer y escribir -y no estoy de coña- manuales y/o guiones para aprender/planificar según qué tareas.

Esta tarde hemos tenido que llevar a cabo una actualización bastante curiosa (no llegaba a ser crítica pero toda actualización debe ser tomada en consideración) en BidoBido y lejos de utilizar la metodología de prueba/error, intentamos hacer un pequeño esquema sobre cómo actuar.

Una de las tantas actualizaciones del módulo php5 (5.2.6.dfsg.1-1+lenny3) para Apache2 en Debian Lenny (5.0 stable) nos indica que se cambiarán los límites de máximo de archivos upload por petición a 50 -como ya se está haciendo por defecto en php-5.3.1-, para prevenir ataques de denegación de servicio.

En principio no debería afectar demasiado a cualquier sistema, pero por si las moscas en la actualización nos avisan convenientemente para no tener ningún tipo de inconveniencia o incompatibilidad con vuestros scripts:

Apticron es una de esas herramientas que agradecemos los sysadmins que tenemos máquinas Debian.

Se trata de un pequeño script que comprueba las novedades en cuanto a actualizaciones de software instalado se refiere y envía un correo/informe con la lista de updates.

Instalarlo es tan simple como hacer un apt-get install apticron, configurar la cuenta de correo a la que van a llegar los informes también es trivial:

$ nano -w /etc/apticron/apticton.conf
EMAIL="tu@correo.com"

Entre ocio y auto-obligación estoy pasando el código de rCMS a CakePHP -motivo de las últimas entradas etiquetadas con este tag-.

Hablar del framework en sí podría llenar ríos de tinta tanto positiva como negativamente (bestial automagia y rapidez de desarrollo vs caos documental y organizativo).

Una de las últimas tareas ha sido actualizar el core a la última versión con luz: 1.2-beta. Para ello me he encontrado estos 4 tips, por si pudieran ayudar:

Después del evento Apple de esta tarde imaginé que habría algunas actualizaciones de software disponibles con lo que al llegar a casa -aburridísimo por el pésimo partido de Copa- me pongo a ello.

Preferencias del Sistema, Búsquedas Programadas, Buscar Ahora... Efectivamente, iTunes, Quicktime, FrontRow y algunas otras actualizaciones de seguridad.

Poco después de introducir la contraseña y aceptar los típicos contratos de licencia se dispone a descargar dichas actualizaciones. Hasta aquí todo bien.

Increible, o como diría Andrés Montes: "dos de dos!... jugón!". Segunda actualización fuerte en la misma máquina y de nuevo falla el mismo paquete: courier-authlib.

Aunque esta vez he leido y repasado el /usr/ports/UPDATING creo que a alguien se le ha ido la mano con el principal fichero de configuración. Ahora la actualización machaca tus configuraciones y coloca unas por defecto. Cierto es que antes genera una copia de seguridad pero solo faltaría que se quedara tan ancho.

# ls -flash /usr/local/etc/authlib/authmy*
10 -rw-------   1 courier  courier   8.3K Oct  3 16:45 authmysqlrc
 2 -rw-------   1 courier  courier   521B Nov 17  2006 authmysqlrc.bak

Nada que cp/mv no arreglen pero aún así resulta molesto perder el control de esta forma. Tirón de orejas para oliver@freebsd.org ;).

Muchos de los usuarios de Ubuntu intentaremos pasar (actualizar) de Dapper Drake a Edgy Eft sin instalar el sistema desde cero, nada más sencillo que tres simples pasos (método consola):

# sed -e ’s/sdapper/ edgy/g’ -i /etc/apt/sources.list
# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Una vez hecho esto, miramos si realmente todo ha acabado como debe y reiniciamos la máquina:

# apt-get -f install
# dpkg --configure -a
# reboot

Nota: Con una conexión normal de 4mbps y en un K7-1000Mhz el tiempo empleado para dicha actualización ha sido el siguiente:

real    62m30.258s
user    13m10.241s
sys     3m2.967s

Nota2: Peta bastante este método (el método es correcto, lo que petan son los repositorios), una vez cascado el sistema optaré por una instalación limpia, desde cero.

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.

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.