PaLo/ASoFt - V5.0

Quiero deshacerme de mi workstation Sun Blade 150, pero como no podría sacar mucho dinero por ella vendiendola en el mercado de segunda mano, he decidido cambiarsela a alguien por algún PC, asique si alguien quiere hacerme alguna oferta que me mande un correo a palo@akinosoft.org

El cacharro este esta bien para usarlo de servidor casero con Solaris o para trastear con el sistema operativo.

Me he hecho con un portatil ACER Aspire 5050 y por fin he probado algo que llevaba tiempo queriendo probar. Este portatil lleva un procesador AMD Turion 64 MK-36 con las extensiones de AMD para virtualización hardware (svm en AMD y vmx en Intel). He instalado Ubuntu 6.10 Edgy para x86_64 y funciona perfectamente todo el hardware (excepto la webcam, cosa que no me importa demasiado …). Por la parte software, me he encontrado problemas con plugins para el navegador (flash, pdf, java …), que no existía soporte para la plataforma x86_64. Tampoco es gran problema, porque se puede hacer un chroot de 32-bits y ejectuar bajo el todas las aplicaciones que solo corran en plataformas x86. En los foros de ubuntu se explica muy bien como hacer esto.

Para la virtualización, primero intenté probar con Xen, pero los paquetes para Ubuntu no funcionan muy bien, y no me apetecía compilarme los fuentes, el kernel y todos los modulos que necesito, asique busqué otras alternativas, y que funcionaran bajo x86_64, la única que encontré fue KVM (Kernel based Virtual Machine). Es muy sencillo, compilas el modulo y lo cargas en el kernel, cualquiera que tengas, y la aplicación es un qemu modificado para aprovechar, haciendo uso del módulo del kernel kvm, las funcionalidades de aceleración por hardware.

He instalado Windows XP en el qemu y funciona bastante bien, practicamente a velocidad “nativa”. El mayor inconveniente es el rendimiento gráfico, que no hay aceleración 3D. También tengo otro problema, la pantalla del portatil es del formato 16:10 (1280×800) y la VGA emulada no soporta esta resolución. Como máximo puedo poner 1024×768, y al ser alargada la pantalla se ve bastante mal.

Aqui pongo una captura de pantalla ejecutandose Windows XP:

Hace algún tiempo ando dandole vueltas a comprarme un iMac de 20″, con procesador Intel Core 2 Duo a 2,33Ghz y 1Gb de RAM. Menudo cacharro esta hecho!!! jajaja. Además de lo bonito que es y lo molón que queda, al fin voy a poder usar MacOS X !!! De momento, para ir habituandome al sistema operativo y conociendolo, he visto que anda rulando en el eMule una imagen del MacOS X parcheada para botar desde cualquier PC Intel normal y corriente, asique voy a instalarla en mi PC para ir probando a ver que tal … Todavia voy a tardar en comprarlo, porque sale a 1800€ (casi ná) y me queda un poco por ahorrar, asique mientras tanto voy aprendiendo. Lo bueno que el MacOS X es un BSD, asique muchas cosas me van a ser muy familiares. Ya contaré cuando lo tenga instalado en el PC cómo lo he hecho, por si alguno se anima a probarlo tambien. Creo que para que funcione bien hace falta un procesador con SSE3 (AMD Athlon64, AMD Turion64, Intel Pentium 4 Prescott, Intel Pentium D, Intel Core-Duo …). Mi procesador es Pentium 4 de los normalitos, asique espero que funcione, aunque no de muy buen rendimiento, al menos que arranque y pueda trapichear un poco.

Voy a contar como he instalado OpenWrt en un router Linksys WRT54G V3.1 (aqui podemos saber cual es nuestra versión). Entre el V3.1 y el V2 no hay ninguna diferencia en el hardware a parte que el V3.1 tiene un boton luminoso en el frontal. Lo primero que he hecho ha sido activar el boot_wait por si me encontraba con problemas. Al activar boot_wait, el router lo que hace es que en el arranque, espera a ver si hay alguna peticion via TFTP para actualizar el firmware, y en caso de que exista, lo actualiza. De esta forma podemos recuperar nuestro router en caso de desastre. El método que he encontrado para activar el boot_wait no funciona con la version del firmware que viene en el V3.1 (en el mio venía la v4.01.1). Dado que el WRT54G V3.1 es igual que el V2, lo que vamos a hacer es “downgradear” el firmware a la v3.01.3 que es la que viene con el V2, y en esta versión si que funciona el método para activar el boot_wait. Como el firmware que vamos a meter es original de linksys, consideramos que el riesgo de esta operación es bajo. Aquí podemos descargar el firmware de linksys:

El de la V2: WRT54GV2_3.01.3_US_code.zip

El de la V3.1, por si algún dia queremos volver al original: WRT54GV3.1_4.00.7_US_code.zip

Realizamos la actualización del firmware via web en “Administration -> Firmware Upgrade”. La única diferencia que notaremos al poner este firmware es que deja de funcionar el botón de la parte frontal. Ahora procedemos a activar el boot_wait siguiendo el siguiente procedimiento:

- Configuramos lo siguiente:

MENU: Setup

OPCION: Basic Setup

Internet Connection Type: Static IP

Internet IP Address: 10.0.0.1

Subnet Mask: 255.0.0.0

Gateway: 10.0.0.2

- Vamos a la página del ping (http://192.168.1.1/Ping.asp) y en la caja de texto donde hay que poner la dirección del ping, ponemos:

;cp${IFS}*/*/nvram${IFS}/tmp/n

- Ejecutamos el ping. Da igual la respuesta que salga. Depués repetimos el ping poniendo:

;*/n${IFS}set${IFS}boot_wait=on

- Y después:

;*/n${IFS}commit

- Y para comprobar que ha funcionado:

;*/n${IFS}show>tmp/ping.log

- Debería haber salido una lista con un montón de propiedades, y entre ellas: boot_wait=on

Ahora, una vez tenemos activado el boot_wait, ya podemos instalar de una forma segura el OpenWrt siguiendo el manual. En mi caso, he instalado OpenWrt Whiterussian.

En mi sistema Linux (CentOS 4.3), el mismo que sirve esta web y que tambien lo utilizo para otras historias (correo, dns, ftp …) venía haciendo uso, hasta hace unos días, de OpenLDAP para la autentificación de usuarios, tanto para el sistema, como para lo demás. Desde hace algun tiempo vengo experimentando problemas de corrupción en la base de datos. Como backend para OpenLDAP usaba Berkeley DB, es la opción por defecto, aunque soporta otros backends. Cada vez que el sistema sufria una caida brusca, que ultimamente eran bastante frecuentes o bien por problemas con un modulo del kernel (el rt2500 para la tarjeta wireles) o bien por caidas de tensión, al levantar el sistema la base de datos de OpenLDAP estaba corrupta y me tocaba ejecutar a mano un db_recover para restaurarla. Entonces empezé a buscar una alternativa a OpenLDAP. Conocía de hace bastante tiempo lo que era el Netscape Directory Server, que luego pasó a llamarse iPlanet Directory Server, y que después adquirió SUN Microsystems y lo llamó SunONE Directory Server, y luego lo llamó Sun Java Directory Server … (creo que asi fue la evolución, jeje), lo que no sabía era que los de RedHat habían adquirido hace poco el mismo producto y ahora lo han liberado bajo licencia GPL con el nombre de Fedora Directory Server (a.k.a. FDS).  Ya conocía bastante bien el producto, pero no habia querido utilizarlo debido al tipo de licencia que tenía antes. El caso es que me he decidido ha migrar de OpenLDAP a FDS, y el resultado es, hasta ahora, bastante satisfactorio. El unico inconveniente que veo es el mayor consumo de memoria que tiene el FDS frente al OpenLDAP, pero bueno, es un gasto que estoy dispuesto a asumir.