viernes, febrero 5, 2010, 10:01 AM - Opinión
"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
[ 4 comentarios ] ( 691 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 211 )domingo, diciembre 27, 2009, 09:37 PM - GNU/Linux, Opinión
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.
Son múltiples las fuentes que apoyan a este rumor. Desde los "visionarios encorbatados" de IDC a los pitonisos de PCWorld pasando por los "buitres" de The Register.
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.
[ 2 comentarios ] ( 391 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 291 )martes, septiembre 8, 2009, 09:15 AM - GNU/Linux, Tecnología
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.
[ añadir comentario ] ( 76 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 419 )sábado, agosto 1, 2009, 02:56 PM
[ añadir comentario ] ( 82 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 457 )lunes, junio 22, 2009, 10:19 PM - GNU/Linux, Tecnología
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
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
[ 3 comentarios ] ( 737 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 477 )viernes, mayo 15, 2009, 11:44 PM - Tecnología, Yo mismo, Opinión
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...
[ 2 comentarios ] ( 1463 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 488 )domingo, marzo 22, 2009, 10:31 PM - Tecnología, Opinión
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
[ 5 comentarios ] ( 691 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 523 )lunes, enero 19, 2009, 09:27 PM - Tecnología
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.
[ 1 comentario ] ( 831 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 582 )
