grub loading gufete...
http://gufete.net/index.php
Han pasado 2000 años y no hemos aprendido todavía..
http://gufete.net/index.php?entry=entry100205-100157
"El presupuesto tendrá que estar equilibrado, el tesoro tendrá que volver a
llenarse, la deuda pública se tendrá que reducir, la arrogancia de la
burocracia tendrá que ser atemperada y controlada y la ayuda a las tierras
extranjeras tendrá que eliminarse para que Roma no entre en la bancarrota. El pueblo debe otra vez aprender a trabajar en vez de vivir de la asistencia
pública"
Cicerón, 55 AC
]]>Rumor: RHEL 6 NO soportará la arquitectura Itanium (ia64)
http://gufete.net/index.php?entry=entry091227-213746
Por si no lo he dejado claro al principio: es un RUMOR. Red Hat (que yo sepa) aún no ha dado una respuesta oficial. Pero hay ciertas cosas que le hacen a uno pensar que en este rumor haya parte de verdad.
No voy a entrar a valorar la validez o no de la arquitectura ia64, pero si puedo decir que es una arquitectura "rara" de encontrar en los CPD, donde hay sobre todo x64 (muchísimo), y algún Sparc/Power/ia64 para tareas de "back-end" Oracle/SAP . En sitios grandes / muy grandes se ve también algún Mainframe (99,99%, IBM)
Como cliente de Red Hat, les he mandado una pregunta comercial acerca de RHEL6 e Itanium. A ver qué responden.
En cuanto sepa la respuesta de Red Hat, lo comentaré en este blog
ACTUALIZADO 12 de enero 2010 Red Hat confirma que RHEL 6 no soportará Itanium. RHEL 5 seguirá soportándolo hasta 2014, pero esto se ha convertido en una via muerta.
]]>Clariion y Red Hat Enterprise Linux 5.4
http://gufete.net/index.php?entry=entry090908-091510
La semana pasada se publicó la Red Hat Enterprise Linux 5.4. Repasando las notas de lanzamiento me encuentro con una nueva funcionalidad muy interesante para aquellos que tengan RHEL 5.4 conectadas a SAN EMC Clariion.
Primero vamos a explicar un poco de teoría. Los sistemas Clariion son la gama media de almacenamiento de EMC, siendo Simmetrix la gama alta. La gama Clariion cuenta con controladoras que pueden funcionar en modo "activo-activo" por lo que una LUN dada solo está accesible desde una controladora, si bien las controladoras se intercambian información para que en el caso de que una falle la transacción no se pierda.
En topologías complejas de almacenamiento (con directores, varios niveles de conmutadores de fibra, etc) nos podemos encontrar que hay caminos "más óptimos" que otros, por el mero hecho de que pasa menos tráfico por uno que por otros.
En versiones anteriores de Red Hat Enterprise Linux 5 se podía definir un camino "preferido" a una LUN, de forma implícita, es decir, que el administrador del sistema Linux le preguntaba al administrador de almacenamiento cual es el camino "óptimo" para llegar a tal LUN y así se configuraba en el sistema Red Hat
Esto no es demasiado flexible. Si el administrador de almacenamiento decide reorganizar la asignación de LUNes a las controladoras, se tiene que poner de acuerdo de nuevo con los administradores de los hosts. Si tenemos varias decenas de hosts y/o LUNes la cosa se vuelve muy tediosa.
Pues bien, Red Hat Enterprise Linux 5.4 añade una nueva funcionalidad a device mapper multipath que se denomina explicit AULA, que consiste en ni más ni menos que el host Red Hat Enterprise Linux negocia con el almacenamiento cuál es el camino óptimo para llegar al almacenamiento, liberando a los administradores de esta tarea.
Para habilitar esta funcionalidad hay que cargar el módulo de kernel scsi_dh_alua . También es necesario especificar "1 aula" como hardware_handler en el fichero multipah.conf (ver Bugzilla )
Ojo que para sistemas EMC Clariion sólo se puede cargar el módulo scsi_dh_alua o bien el de toda la vida, el dm-emc, no está soportado cargar los dos a la vez.
Hay administradores que no usan device mapper multipath sino el producto EMC PowerPath que desconozco si tiene también esta funcionalidad. ¿Algún lector que arroje un poco de luz?
Gufete
Nota post post: Gracias a Juan José Palacios de Optima Technologies por aclararme mi empanada mental acerca de las Clariion.
]]>ETA, Déjanos en PAZ
http://gufete.net/index.php?entry=entry090801-145608
Presto: como ahorrar ancho de banda en las actualizaciones de seguridad
http://gufete.net/index.php?entry=entry090622-221957
Ya soy feliz usuario de la Fedora 11 x64. No me voy a poner a contar el mogollón de mejoras que trae respecto a Fedora 10 (para el que quiera los detalles, aquí los tiene ). Lo que todo el mundo destaca es que arranca muy rápido, dicen que en 20 segundos (pues a mi me tarda 36, que es menos de la mitad de lo que me tardaba antes), pero hay algo que se llama Presto y no veo que se le haya dado mucho bombo.
Pues para eso está este blog :P
En versiones anteriores de Fedora (y también de RHEL, todo hay que decirlo) alguna vez nos habrá pasado que ha tocado actualizar un paquete "pesado", del tipo OpenOffice.org, kdelibs o tetext. Pues nada, a bajar unas pocas decenas/centenas de megabytes cuando a la hora de la verdad lo que se ha actualizado son unos pocos cientos de kilobytes / algunos megabytes.
Pues es aquí donde entra en acción Presto.. A grosso modo, y simplificando mucho, lo que hace es bajarse únicamente las diferencias ('delta' ) entre los binarios que tenemos instalados y los que están disponibles en el servidor de actualizaciones.
Por defecto no viene activado en Fedora 11, para activarlo hay que instalar el paquete yum-presto. Para ello ejecutamos el comando:
yum -y install yum-presto
Y voilá!. Ya tenemos activado el plugin, por lo que a partir de ahora las actualizaciones de seguridad ya no serán tan "dolorosas" en ancho de banda.
Ojalá otros fabricantes (y no sólo de distribuciones de Linux) les de por emplear una tecnología similar. El otro día me bajé 150 megas de parches para MacosX por una actualización de Java. En Solaris 10 idem. Y de Microsoft Windows ni os cuento lo que me tardó una actualización de .NET de 350 megabytes...
Nota: para el que se pregunte qué hago yo con un Windows le diré 4 cosas:
A) Aparte de la cerveza me gusta el tinto. Pero me gusta más la cerveza.
B) El que no conoce la historia está condenado a repetirla.
C) Conoce a tu enemigo
D) Las herramientas de gestión de entornos virtuales (Vmware vSphere / Citrix Xen Server) sólo las hay en Windows. No las hay ni en OSX ni en Fedora / Ubuntu / Gentoo / OpenBSD.
A ver si hay suerte y la tecnología Presto la vemos en Red Hat Enterprise Linux 6 el año que viene...
Gufete
]]>Appliances y seguridad
http://gufete.net/index.php?entry=entry090515-234453
En mi nueva vida laboral me toca ahora "estar al otro lado". He dejado de ser proveedor y he pasado a ser cliente, y la verdad que es una experiencia de lo más curiosa.
Hoy escribo para hablar de los dichosos "appliances". A fin de cuentas, un trasto de estos se supone que es la unión de un hardware específico con un sistema operativo "empotrado y optimizado" para ese hardware. Esta unión hace que ese cacharro sea (se supone) muy bueno para una tarea específica.
Appliances hay a patadas: cortafuegos, proxys, front-ends de correo, NAS, ldap, dns, ntp, buscadores web, antivirus, antispam... la gran mayoría son de servicios de infraestructura, aunque alguno he visto con cosas tipo ERP y CRM (flipa)
A mi una cosa que me hace una jartá de gracia es eso de que "este appliance se basa en una versión endurecida (o optimizada) de Linux (o de FreeBSD)". Entonces me salta la alarma.
Me salta la alarma porque pienso... "¿cómo que estos señores han mejorado la seguridad o el rendimiento de algo tan usado como un Linux o un FreeBSD cuando hay tanta gente metida en esto? ¿Habrán compartido esas mejoras con la comunidad?
A lo mejor le pides un appliance de pruebas a tu proveedor, y encantado, esperando negocio, te lo presta. Tu ves su fantástico interfaz web de administración y piensas: "me aburro; voy a verle las tripas al cacharro este"
Se va uno a la web del fabricante del appliance (donde muchas veces sale gente embelesada mirando al cielo como si lloviesen billetes de 500 €) y te bajas el manual. Te pones a leerte el manual que básicamente lo que hace es explicarte para que vale cada uno de los botones del interfaz web, hasta que llegas a la parte de "habilitar una consola". Premio.
Habilito la consola, entras (¿aún hay gente que usa telnet? joder...) y se te caen los palos del sombrajo. Literalmente.
Ante ti aparece una distribución de Linux de hace unos años, donde le han cambiado 4 paquetes y le han puesto un interfaz web. A lo mejor (si tienes suerte) tienen un kernel propio, casi siempre de hace más de dos años. Si es un *BSD igual, te encuentras un cacharro "casi por defecto".
¿Y no decían en su publicidad que esto era un cacharro "tuneado, optimizado y blindado" . Pues llega uno, mira las tripas, y se encuentra librerías openssl del año catapún, servidores viejecitos (postfix, squid, bind, apache...) con sus buenos 2-3 añitos, usuarios y grupos en la máquina por defecto, permisos de lo más laxos, un desastre, vamos. Pues si, está esto currao, si...
Querido lector, cuando vayas a mirar para comprar uno de estos appliances, te recomiendo los siguientes pasos:
Paso 1: pregúntale al vendedor: "¿En qué está basado esto"?.
Paso 2: Te vas a la web del fabricante y miras hace cuánto liberaron su último update/service_pack/parche/nuevo_firmware.
Paso 3: le haces un par de telnets a los puertos que presta servicio el cacharro (sea el 80/tcp, el ssh, smtp, el que sea, según el cacharro). Te apuntas las versiones de software que te dice que tiene
Paso 4: entras en el cacharro y miras las versiones de software, o a las malas, a base de "strings o hexdumps".
Paso 5: Te vas a la web de Security Focus y miras para tal versión de librería o demonio cuál es la última versión. Échale un rato y mira los agujeros de seguridad que tenían versiones anteriores.
Paso 6 y último: comparas tu búsqueda en SecurityFocus con lo que has encontrado en el paso 4 de esta guía y con lo que hay en la web del fabricante en el paso 2.
Muchos fabricantes de appliances montan software "por defecto" en sus cacharros, y lo actualizan muy de vez en cuando. ¿Es esto lo que queremos para dar servicio? ¿Nos estamos casando con estos señores (porque la plataforma es suya y sólo suya) para esto?
Por supuesto, no se puede generalizar. Hay fabricantes de appliances muy profesionales. Pero con el tiempo que llevo en esto os puedo decir que hay más paja que trigo
Última hora: ya no sólo hay appliances, también hay "virtual appliances". Ojito con lo que montáis...
]]>¿Cisco compraría a Sun?
http://gufete.net/index.php?entry=entry090322-223119
Voy a dejarlo claro desde el principio: ESTA ENTRADA ES PURA ESPECULACIÓN. No me baso en ningún hecho, no tengo ningún contacto ni con Sun ni con Cisco ni con IBM. Tan sólo leo ciertas cosas en Internet y veo que hay gente que piensa como yo
En estos días se habla mucho de los rumores de compras de Sun por parte de IBM. En mi modesta y desinformada opinión, creo que IBM tendría interés en Sun para quitarsela a otro comprador: Cisco
¿Y qué razones doy? Pues varias: primero, las líneas de negocio de IBM y Sun se parecen en muchas cosas: servidores Unix, storage, backup, servidores x86/64, servidores de aplicaciones, Java... IBM es más fuerte que Sun en servicios profesionales y IBM también tiene la línea de Mainframes.
Pienso que la compra de IBM a Sun sería contranatura. Se pisan en demasiadas cosas, y no se hasta que punto las autoridades de EEUU permitirían que se hiciese realidad la compra, porque hay riesgo de monopolio.
¿Que pasaría con Solaris? ¿Y con AIX? ¿Lo mismo que con Tru64 Unix y HP-UX tras la compra de Digital por parte de Compaq y ésta a su vez por HP? ¿Y las líneas de almacenamiento StorageTek de Sun versus DS de IBM? ¿Que pasaría con Java? ¿Se mantendría la gama de procesadores Sparc? ¿Y la línea de procesadores Power? No se. No lo veo, la verdad. Y menos con el riesgo de monopolio.
Además, en estos tiempos de crisis no creo que estuviera bien visto que se IBM se gastase tantos millones de dolares en Sun para a los pocos meses echar a muchos trabajadores porque las líneas de negocios se solapan.
En cambio, por otro lado, tenemos a Cisco. Un gigante de las comunicaciones, con presencia en prácticamente cualquier empresa de más de 200 usuarios.
Hay rumores de compra de Vmware por parte de Intel. También se habló de Cisco como posible comprador.
Cisco no tiene línea de servidores Unix. Su línea de almacenamiento se centra en el fabric (switches, routers) más que en cabinas de almacenamiento. No tiene línea de backup. No tiene procesadores propios. Recientemente ha entrado en el mundo de los servidores x86-x86/64 de la mano de la virtualización en su línea Unified Computing System
¿Qué visión tiene Cisco? La de centros de datos unificados, de crear "nubes", de que la tecnología sea esencialmente centralizada (en vez de distribuida).
¿Paranoias mías?
Actualización: me equivoqué. Al final fue Oracle
]]>Compresión extrema
http://gufete.net/index.php?entry=entry090119-212757
Para un cliente tuve que usar una lista de claves típicas para probar la "dureza" de unas contraseñas. Hay muchas herramientas que pueden hacer ataques de diccionario, como el inefable John The Ripper .
Pues nada. A buscar por Internet un fichero con claves típicas, en varios idiomas, y con permutaciones. Y lo encontré.
El fichero de claves que encontré ocupa casi 1,9 gigabytes. Una barbaridad de fichero. Inmenso. Gigantesco. Monstruoso. Titánico.
Por estas _malignas_ casualidades del destino, tenía que mandarle por correo electrónico a una persona este fichero de claves. Pues nada, a comprimir. Se lo pasé en varios correos, como es lógico, en uno sólo no cabía, el límite máximo de cada mensaje era de 10 megabytes.
Hace dos fines de semana no tenía Internet en casa, (des)cortesía de mi proveedor. Y el domingo por la tarde, diluviaba. El aburrimiento es mal compañero. Así que me puse a leer de compresión de datos, me vino a la cabeza el megafichero este de 1,9 gigabytes de texto. Lo que quería era compresión extrema, independientemente del tiempo que tarde.
Primer recurso: Maximum Compression. Leer. Leer mucho. Que interesante está esto, la verdad.
Segundo: Wikipedia. Leer. Leer mucho. Leer los enlaces a los que apunta la wikipedia. Dormir menos entre semana para leer. Más interesante aún
Me puse a probar. Cogí el megafichero de claves y probé varios compresores, desde los más típicos ( gzip, bzip2 y rar ) a otros más "exóticos" como 7zip o Paq8p.
Repito: lo que yo buscaba era compresión extrema, independientemente del tiempo que tarde en comprimir. Estos son los resultados:
Fichero sin comprimir: 1,9 gigabytes (2.011.399.369 bytes).
Zip y Gzip: 184 megabytes. Aproximadamente 7 minutos. bzip2: 169 megabyes. Aproximadamente 9 minutos. RAR: 153 megabytes. Aproximadamente 8 minutos. 7zip: 75 megabytes. Aproximadamente 11 minutos. Paq8p: 17 megabytes. Casi 3 días.
A la vista de estos resultados, el ganador es paq8p con una gran ventaja sobre el segundo clasificado, 7zip. Pero esta ventaja la consigue a costa de tardar una barbaridad más.
Hay varias cosas que me sorprenden. Lo primero, que casi ningún compresor es capaz de aprovechar más de un procesador, a excepción de RAR y de una versión especializada de bzip2 ( pbzip2 ), ninguno de los compresores que he probado aprovechan que haya múltiples procesadores o cores.
Se muy poco de compresión de datos. Muy, muy poco. Por lo poquito que se, y simplificando, un compresor trabaja cogiendo un bloque de datos e intentando reducir su tamaño empleando diversas técnicas. A priori, no se me ocurre la razón por la que un compresor no debería ser fácilmente paralelizable. Seguro que hay algo que se me escapa.
Es una pena que algunos de los compresores anteriores no soporten sistemas con más de un procesador/core. Es bastante común encontrarse hoy en día con máquinas con 4, 8 o más cores, por lo que el tiempo de compresión se podría reducir bastante.
Respecto al compresor Paq8p, sus resultados son impresionantes. Pero tiene bastantes pegas: la primera es que tarda una barbaridad en comprimir. La segunda es que usa la friolera de 1.600 megabytes de ram (si, si, está bien escrito) para comprimir a máxima potencia y por último, que tarda casi lo mismo en comprimir que en descomprimir. Una pasada, vamos.
Por tanto, si uno va a usar un compresor para hacer backups de tus propias cosas, le recomiendo que use 7zip. Si lo que quiere es intercambiar datos con otras personas, lo más cómodo es zip. En ambientes UNIX/Linux, bzip2. Y si uno es un "agonía", pues nada, paq8p y mucha paciencia.
Paq8p no deja de ser una prueba de concepto académica. No se me ocurre ninguna aplicación práctica de uso de este compresor. El tiempo que tarda es demasiado alto, consume mucha memoria y lo que es peor, el tiempo de descompresión es muy alto también.
Si alguien quiere detalles de la máquina empleada para hacer las pruebas los tiene aquí. Las opciones de compresión usadas en los compresores están en este enlace.
Por último, si alguien tiene interés en el megafichero de claves, pues lo tiene aquí en diversos formatos de compresión.
Oh what fun it is to slip our release for a month!
Oh What Fun It Is To Slip Our Release For A Monnnnnnnnnnnnnnnnth!!!
Fuente: Jesse Keating, hacker de Fedora y trabajador de Red Hat]]>Ya soy Red Hat Academy Examiner
http://gufete.net/index.php?entry=entry080907-233730
Pues si, al final me saqué la certificación de Red Hat Academy Examiner. Estuve el 27 y 28 de agosto en Farnborough en la sede de Red Hat Reino Unido y aprobé los exámenes, 97/100 .
¿Y esto para qué vale? Pues ya puedo impartir los cursos oficiales (y exámenes) de RHCE y RHCT , por lo que en un futuro muy cercano (cuando tengamos montada el aula, vamos), ya no será necesario irse a Madrid o a Barcelona para recibir esta formación, sino que podrá darse aquí en Sevilla.
La "pega" es que esta formación la imparto yo, que soy un petardo. :P
Últimamente me está dando por colaborar con la gente de Clamav y con la venia de algún cliente estamos localizando ficheros sospechosos que no detecta Clamav en servidores de correo.
En la configuración de Clamav hemos activado la opción "MailFollowURLs yes", de esta forma no se analiza sólo el mensaje de correo, sino también los enlaces que contengan (ojo que hay que tener cuidado con los DoS)
El truco está en decirle al clamav que use un proxy para conectarse a Internet (en mi caso, squid ) y parseando los logs del proxy podemos ver que enlaces contienen los correos. Con un par de grep te puedes quedar con los enlaces que contengan ".exe", ".pif" y demás ficheros ejecutables en esa plataforma tan conocida.
Gracias a la gente de Virus Total (sois los mejores, Hispasec!) uno puede subir ficheros sospechosos y que lo analicen más de 30 antivirus distintos.
En la semana que llevamos haciendo esto hemos detectado más de 13 virus/adware/malware que Clamav no detectaba. Y algún otro que Clamav si detectada pero otros antivirus no. La propia gente de Virus Total se encarga de repartir las muestras entre las casas antivirus, por lo que todos quedamos beneficiados.
Ahora viene la parte interesante. Mirando los logs del proxy vemos que las webs que mantienen los ficheros .exe la mayoría nada tienen que ver con los virus/underground, sino que han sido comprometidas y están alojando malware sin saberlo.
Hemos probado en ir avisando a las webs españolas que están infectadas, pero si ve que la gente no lee las cuentas de correo webmaster@dominio_infectado.es
He estado leyendo por Internet, pero aparte del CERT-Es no encuentro ningún sitio para avisar de que hay direcciones infectadas. ¿Alguien conoce algún sitio?
Gufete
]]>Más maquero que ayer....
http://gufete.net/index.php?entry=entry080312-204407
...pero menos que mañana :P
Última adquisición 8)
Estoy feliz como un perrillo chico, pedazo iMac de 24 pulgadas y 4 gigabytes de ram, pero ahora me cuesta desprenderme de mi eMac G4 que ha dado tan buen servicio. Cosa rara ésta la de cogerle cariño a las máquinas...
Se ve que no soy el único maquero feliz
]]>Acabo de recorrer mis primeros 2.000 kilómetros..
http://gufete.net/index.php?entry=entry080113-210133
...con el nuevo coche, un Skoda Fabia Combi 1.9 TDi de 101 CV. Hasta que no he hecho 2.000 kilómetros no quería dar una opinión, y el veredicto es SOBRESALIENTE.
Este coche no tiene absolutamente nada que ver con el que conducía antes... su predecesor era un Seat Toledo 1.8 Class gasolina con 14 años a cuestas, y claro, el pobre no daba más de si.
El Skoda lo supera absolutamente en todo: facilidad de conducción, potencia, agarre, consumo, rendimiento, estabilidad, seguridad, comodidad... si, parezco un niño con zapatos nuevos, pero es que el cambio ha sido enorme.
Por si alguien tiene interés en conocer más datos técnicos del coche, en éste enlace puede ver un buen resumen. Yo tuve la gran suerte de coger una promoción y me salió por 15.000 € iva incluido, que es una GANGA con mayúsculas.
A destacar de este coche: la mecánica, que es impresionante (la misma que el Volkswagen Golf), el espacio interior (engaña para ser un Fabia) y el precio. El coche viene de serie con ordenador de a bordo, climatizador, ABS, airbargs frontales y laterales, cierre centralizado, faros antiniebla, control de estabilidad y pintura metalizada.
La única "pega" que le encuentro es que es algo sobrio por dentro, no tiene demasiadas pijerias y que la radio integrada no tiene reproductor de MP3... menos mal que tengo un iPhone. :P
Aquí dejo una foto del coche aparcado delante de la puerta de casa.
]]>Un nuevo trasto a base de electrones...
http://gufete.net/index.php?entry=entry080113-205012
Pues si, mi querida y amada nena tuvo a bien regalarme estos reyes un iPhone de 8 gigas. Y la verdad que el cacharro es una pasada...
Aún no he sido capaz de hacerlo funcionar como teléfono (traía el firmware 1.1.2 de fábrica con el puñetero baseband 04.02.13_G) pero si he sido capaz de activarlo y usarlo como iPod Touch (con 1.1.2 y jailbreak).
Ya tiene su servidor de openssh, su cliente de terminal vt100 y su detector de redes wifi. Aún no es teléfono, pero no creo que tarde más de dos o tres semanas en conseguirlo.
Me ha sorprendido mucho la calidad de la pantalla y lo sencillo que es de manejar. Le doy un 8,5 o 9 de 10 puntos, porque lo hace casi todo bien.
En fin, un paso menos para dominar el mundo :)
]]>Linux avanza "por pura suerte" versus Ingeniería del Software
http://gufete.net/index.php?entry=entry080101-222727
Fuente original
¿Sabes cual es la obra de ingeniería más compleja en el sistema solar conocida hasta el momento?
Adivina - no es Linux, no es Solaris, y no es tu automóvil ni el Airbus 380.
Eres tu. Y yo también.
Piensa como tu y yo aparecimos - no fue por ningún diseño complejo.
Correcto. "pura suerte".
Bien, pura suerte, Y:
- libre disponibilidad y _polinización cruzada_ a través de compartir el "código fuente", aunque los biólogos le llaman ADN.
- un ambiente de usuario bastante implacable que felizmente reemplaza versiones malas de nosotros con versiones funcionales mejores y así controla la manada (los biólogos llaman a éso "supervivencia del más apto" )
- desarrollo masivo y no dirigido, realizado en paralelo ("prueba y error" )
Estoy hablando muy en serio: nosotros los humanos _nunca_ hemos podido replicar algo más complicado que nosotros mismos, aunque la selección natural lo ha hecho sin siquiera pensarlo.
No subestimes el poder de la supervivencia del más apto.
Y jamás cometas el error de creer que puedes diseñar algo mejor que lo que obtienes de hacer prueba-y-error en paralelo despiadada y masivamente con un ciclo de retroalimentación.
Eso es dar a tu inteligencia demasiado crédito.
Francamente, Sun, está condenado. Y no tiene nada que ver con sus prácticas de ingeniería o su estilo de código.
Linus
]]>Las Brand Zones de OpenSolaris no valen solo para correr Linux...
http://gufete.net/index.php?entry=entry071103-200524
Aunque muchos me conocéis por mi trabajo en plataformas GNU/Linux (especialmente Red Hat ) uno en su tiempo libre se dedica a hacer el ganso con otras cosas. Y si lleváis tiempo viendo mi blog, veréis que desde hace más de un año soy un enamorado de OpenSolaris
Si tú, querido lector/a (no me gusta usar la @) no tienes ni idea de que es OpenSolaris, empieza por esta entrada de mi blog y luego vete ipso-facto a la comunidad OpenSolaris en español.
Vamos a empezar desde el principio. ¿Qué es un contenedor en Solaris10? Pues es una técnica de virtualización para poder correr más de una instancia de Solaris10 en el mismo hardware. Algunos lo ven como un chroot() a lo bestia, pero la verdad que es es bastante más complejo y pontente que eso.
Este post no se va a poner a comparar las zonas de Solaris con otras tecnologías como Xen, Virtuozzo o VMware (esto para otro post) pero sí os diré que las tecnología de zonas de Solaris se han expandido para ser más que un contenedor de Solaris 10 sobre Solaris 10.
El primer intento serio fueron las Brandz.
Consistía básicamente en ejecutar un sistema operativo que no fuese Solaris 10 dentro de una zona. El primer éxito fue con GNU/Linux. La llamada "lx brand" es capaz de ejecutar Linux x86 sobre una plataforma OpenSolaris x86/x86-64.
Los clientes de Sun MicroSystems vieron esto con cierta curiosidad. Algunos (los menos) sí se lanzaron a probarlo en sus plataformas Solaris/x86, pero los clientes del "big iron" seguían viendo las zonas Brandz de OpenSolaris como un demostrador tecnológico más que como algo que se pudiera emplear en su día a día a la hora de explotar sistemas.
Pues bien, me ha llamado mucho la atención el proyecto Etude , que es ni más ni menos que ejecutar Solaris 8 en un contenedor dentro de Solaris 10. Y con soporte de Sun, y sí, estamos hablando de Solaris 8 Sparc y Solaris 10 Sparc.
Si esto por si solo ya es la mar de interesante, el hecho de que estén desarrollando una herramienta de P2V (physical to virtual) es ya demoledor. Más de una vez me he encontrado un sistema Sun/Sparc corriendo Solaris 8 & Oracle 8i y que el jefe de informática no quiere migrar porque "just works", a pesar de que el hardware de la época flojea para los tiempos actuales. Pues ahora tiene un plan de migración creíble para ejecutar en su nuevo hardware Sparc.
Me voy a quitar un poco la gorra técnica para ponerme el sombrero de comercial: el proyecto Etude puede ser un paso de gigante para Sun, se pueden hinchar de vender hardware para consolidar los viejos servidores basados en Solaris8. A la gente de IBM le va de perlas esto de mantener la compatibilidad hacia atrás...
P.D: Mora, mientras escribía esta entrada me acordaba constantemente de ti, y de tu "fork" Marcos.
