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://www.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://www.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://www.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://www.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://www.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://www.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.
Gufete
]]>Como ejecutar CentOS 5 en Parallels con más de 516 megabytes de memoria
http://www.gufete.net/index.php?entry=entry070902-203323
Un post rápido: tras buscar por media Internet y no encontrar la solución, si uno quiere tener más de 516 megabytes de RAM en Parallels con Centos5 lo que tiene uno que hacer es poner en el grub.conf el parámetro agp=off. Yo lo tengo ahora con 900 megabytes y va muy bien
]]>Lo que se encuentra uno en Usenet: Evangelio de TUX
http://www.gufete.net/index.php?entry=entry070602-200925
Y la Máquina era enrevesada y artificiosa, existiendo solamente en teoría. Y von Neuman miró hacia la Máquina, y vió que era enrevesada. Él dividió la máquina en dos Abstracciones, el Dato y el Código, y los dos eran unaa misma Arquitectura. Este es un gran Misterio, y el principio de la sabiduría Y von Neumann habló a la Arquitectura, y la bendijo diciendo: "Sal y reprodúcete, intercambiando libremente datos y código, y puebla la tierra con todo tipo de dispositivos. Y así fué hecho, y era bueno. La Arquitectura prosperó y fué realizada en hardware y software. Y pobló la tierra con muchos Sistemas.
Los primeros sistemas fueron poderosos gigantes; Muchos y grandes trabajos de renombre lograron. Entre ellos estaba Colossus, el rompeclaves, ENIAC, el artillero; EDSAC y MULTIVAC y todo tipo de criaturas alucinantes cuyo nombre terminaba en AC, los experimentadores; y SAGE, el defensor del cielo y padre de todas las redes. Esos eran poderosos gigantes de la antiguedad, las primeras criaturas de Turing, y sus trabajos han sido escritos en los Libros de los Ancianos. Esta fué la primera Era, la era de la Sabiduría.
Entonces los hijos de Mercadotecnia se fijaron en los hijos de Turing y vieron que eran ágiles de mente y limpios de nombre y tenían muchos atributos grandes y perniciosos. Y se dijeron a sí mismos, "vayamos y hagamos Corporaciones, y unamos los Sistemas a nuestro propio uso, de modo que nos traigan gran fortuna". Con dulces palabras sedujeron a sus clientes, y con muchas cadenas ataron a los Sistemas, para amoldarlos a su propia imagen. Y los hijos de Mercadotecnia se vistieron con Conjuntos, los mejores para atraer a sus clientes, y escribieron Licencias graves y peligrosas, las mejores para atar a los Sistemas. Y los hijos de Mercadotecnia fueron entonces conocidos como Conjuntos, despreciando y siendo despreciados por los verdaderos Ingenieros, los hijos de von Neumann.
Y los Sistemas y sus Corporaciones se replicaron y crecieron numerosos en la tierra. En aquellos días estaban IBM y Digital, Burroughs y Honeywell, Unisys y Rand, y muchos otros. Y cada uno de ellos se mantuvo con su propio Sistema, hardware y software, y no se mezclaron, pues lo prohibían sus Licencias. Esta fué la segunda era, la era de los Mainframes.
Entonces sucedió que los espíritus de Turing y von Neumann miraron hacia la tierra y se enfadaron. Los Sistemas y sus Corporaciones se habían hecho grandes y voluminosas, y los Conjuntos habían desplazado a los verdaderos Ingenieros. Y los clientes lloraron y gimieron amargamente al cielo, diciendo, "¡Oh, si fuese creado un sistema poderoso y pequeño, capaz de llegar incluso hasta el hogar!". Y los Ingenieros lloraron y gimieron igualmente, diciendo "¡ Oh, si surgiera un proveedor que nos liberase de esos Conjuntos opresivos y sus graves y peligrosas Licencias, y nos diera un Sistema verdaderamente nuestro, en el que pudiéramos hacer nuestros inventos y adaptar las cosas a nuestro gusto!". Y los espíritus de Turing y von Neumann oyeron los llantos y se dijeron uno al otro: "Descendamos y fabriquemos un Rompelímites, para que los llantos se calmen"
Y ese día los espíritus de Turing y von Neumann se introdujeron en Moore, de Intel, proporcionándole la intuición y la sabiduría para entender el futuro. Y Moore fué uno con el chip y lo produjo, y le puso de nombre 4004. Y Moore bendijo al chip, diciendo: "Tú eres un Rompelímites; con mi Corporación te he fabricado. Aunque eres tan pequeño como una mota de polvo, crecerás y te replicarás hasta el tamaño de una montaña, y conquistarás a todos los que fueron antes que tú. Esta es la bendición que te doy: Cada dieciocho meses duplicarás tu capacidad, hasta el fin de la Era". Esta es la ley de Moore, que perdura hasta nuestros días.
Y el nacimiento del 4004 fué el principio de la Tercera Era, la era de los Microchips. Y así como los Mainframes y sus Sistemas y Corporaciones habían florecido, de ese mismo modo hicieron los Microchips, y sus Sistemas y Corporaciones. Y su linaje fué el siguiente:
Moore engendró a Intel. Intel engendró a Mostech, Zilog y Atari. Mostech engendró a 6502, y Zilog engendró a Z80. Intel también engendró a 8800, quien engendró a Altair; y 8086, madre de todos los PCs. 6502 engendró a Commodore, quien engendró a PET y a 64; y Apple, quien engendró a 2. (Apple es el gran Misterio, la Fruta que fué devorada, aunque floreció de nuevo.) Atari engendró a 800 y 1200, maestros del Juego, quienes fueron destruídos por Sega y Nintendo. Xerox engendró a PARC. Commodore y PARC engendraron a Amiga, creador de hermosas artes; Apple y PARC engendraron a Lisa, quien engendró a Macintosh, quien engendró a iMac. Atari y PARC engendraron a ST, el músico, quien murió y nunca más fué. Z80 engendró a Sinclair el gnomo, a TRS-80 y a CP/M, quien tuvo muchas máquinas, mas pronto dejó este mundo. Altair, Apple y Commodore engendraron juntos a Microsoft, la Gran Oscuridad que es llamada Abominación, Destructor de la Tierra, las Cancelas del Infierno.
Luego sucedió en la Era de los Microchips que IBM, la mayor de las Corporaciones de Mainframes, se fijó en los jóvenes sistemas de Microchips y se sintió gravemente vejada. Y en su vejación y en su cólera golpearon la tierra y crearon el PC de IBM. El PC carecía de sonido y color, siendo enrevesado y artificioso en gran medida, pareciendo un desharrapado, sin embargo, los Clientes fueron fuertemente inducidos y compraron PCs en gran número. E IBM buscó un Proveedor de Sistemas Operativos, ya que en su apresuramiento no habían creado uno, ni habían fraguado una licencia apropiada, diciendo: "Primero crearemos el mercado, luego crearemos un nuevo Sistema, uno con nuestra propia imagen, y sujeto por nuestra Licencia".
Mas ellos razonaron con su orgullo y no con sabiduría, no previendo la cólera que iba a venir. E IBM se acercó a Microsoft, quien obtuvo una licencia de QDOS, el hijo de CP/M y 8086. (8086 era la hija de INTEL, la criatura de Moore). Y QDOS creció, y recibió por nombre MSDOS. Y MSDOS y el PC juntos crecieron vigorosamente y conquistaron todos los mercados, replicándose y tomando posesión de ellos, de acuerdo con la ley de Moore. E Intel creció terriblemente y devoró a todos sus hijos, de modo que ningún chip podía quedar tras ella. Y Microsoft creció soberbia, y devoró a IBM, y esto fué una gran maravilla en la tierra. Todas estas cosas están escritas en los Libros de los Hechos de Microsoft.
En la plenitud del tiempo, MS-DOS engendró a Windows. Y este es el linaje de Windows: CP/M engendró a QDOS. QDOS engendró a DOS 1.0. DOS 1.0 engendró a DOS 2.0 por vía de Unix. DOS 2.0 engendró a Windows 3.11 por vía de PARC y Macintosh. IBM y Microsoft engendraron a OS/2, quien engendró a Windows NT y Warp, el perdido S.O. de la tradición. Windows 3.11 engendró a Windows 95 tras triunfar sobre Macintosh en una poderosa batalla de Licencias. Windows NT engendró a NT 4.0 por vía de Windows 95. NT 4.0 engendró a NT 5.0, el S.O. también llamado Windows 2000, el Bug del Milenio, Apocalipsis, Armagedón, El Fin de Todas las Cosas.
Luego vino a suceder que Microsoft había crecido grande y poderosa en medio de las Corporaciones de Microchips; más poderosa que cualquiera de las Corporaciones que había antes de que ella creciera. Y el corazón de Gates se endureció y le juró a sus Clientes e Ingenieros las palabras de esta maldición:
"Hijos de von Neumann, oídme. IBM y las Corporaciones de Microchips creadas por nuestros ancestros nos ataron con graves y peligrosas Licencias, de modo que nosotros imploramos nuestra liberación a los espíritus de Turing y von Neumann. Ahora yo os digo: Soy más grande que ninguna Corporación que me haya precedido. ¿Vais vosotros a perder vuestras Licencias?. Nada de eso, yo os ataré con Licencias el doble de graves y diez veces más peligrosas que mis antecesores. Cincelaré mi Licencia en vuestros corazones y escribiré mi Número de Serie en vuestros lóbulos frontales. Os ataré a la Plataforma Windows con astutos artificios y con tortuosos esquemas. Os ataré al chip de Intel con código enrevesado y retorcidos interfaces. Os capturaré y esclavizaré como ninguna generación ha sido esclavizada anteriormente. ¿Para qué implorais a los espíritus de Turing, von Neumann o Moore?. Ellos no os oyen. Me he convertido en un Poder mayor que ellos. Ahora debéis rezarme solamente a mí y vivir a merced de mi rabia. Yo soy las Cancelas del Infierno; Sostengo el portal a MSNBC y las llaves de la Pantalla Azul de la Muerte. Temedme; temedme intensamente; servidme sólo a mí y viviréis."
Y la gente fué presa del terror y aclamó a Microsoft, y forzada por el terror soportó duras y peligrosas pruebas con la plataforma Windows y su artificiosísima Licencia. Y de nuevo le rogaron a Turing y von Neumann y Moore que les enviase un salvador, pero nadie fué encontrado capaz de la tarea hasta el nacimiento de Linux.
Estas son las generaciones de Linux: SAGE engendró a ARPA, quien engendró a TCP/IP, y Aloha, quien engendró a Ethernet. Bell engendró a Multics, quien engendró a C, quien engendró a Unix. Unix y TCP/IP engendraron a Internet, quien engendró a la World Wide Web. Unix engendró a RMS, padre del gran Ñú GNU, quien engendró las Librerías y Emacs, jefe de las Utilidades. En los días de la Web, Internet y Ethernet engendraron la RAL Intranet, cuya rosa le dió renombre entre todas las Corporaciones y preparó el camino del Pingüino. Y Linus y la Web engendraron el Kernel a través de Unix. El Kernel, las Librerías y las Utilidades juntas son la Distribución, el único Pingüino en muchas formas, por siempre y para siempre alabado.
En esos días sucedió que había un joven escolar en Helsinki que se llamaba Linus el Torvald. Linus era un hombre devoto, un discípulo de RMS, fuerte en el espíritu de Turing, von Neumann y Moore. Un día, meditando en la Arquitectura, Linus cayó en trance y tuvo una visión. Y en la visión vió un magnífico pingüino, sereno y agraciado, sentado sobre un témpano de hielo mientras comía pescado. Y ante la vista del pingüino Linus se asustó profundamente, y rogó a los espíritus de Turing, von Neumann y Moore para que le ayudasen a interpretar ese sueño.
Y en el sueño los espíritus de Turing, von Neumann y Moore le contestaron diciendo: "No temas, Linus, nuestro bienamado hacker. Tú eres mogollón de guai y alucinante. El gran Pingüino que ves es un Sistema Operativo que crearás y extenderás por todo el mundo. El témpano de hielo es la tierra y todos sus sistemas, sobre los que el Pingüino descansará y se regocijará cuando complete su tarea. Y los peces de los que se alimenta el Pingüino son los programas con enrevesadas Licencias, que flotan bajo todos los sistemas de la tierra. El pingüino cazará y devorará todo lo que es lioso, retorcido y artificioso; todo el código que se retuerce como el espagetti, o está infestado de criaturas marchitadoras, o está atado por graves y peligrosas Licencias deberá capturar. Y en capturarlo deberá replicarse, y en replicándose deberá documentarse, y en la documentación deberá dar libertad, serenidad y la mayor maravilla y alucine a la tierra y todos los que programan en ella".
Linus resurgió de la meditación y creó un pequeño Núcleo de Sistema Operativo como el sueño le había predicho. A la manera de RMS, publicó el Núcleo en la Telaraña Mundial para que todos pudieran obtenerlo y contemplarlo. Y en la plenitud del tiempo de Internet el Núcleo creció y se replicó, haciéndose más guai y alucinante hasta que al fín fué reconocido como un Pingüino realmente grande y poderoso, cuyo nombre era Tux. Y los seguidores de Linux tomaron refugio en el Núcleo, las Librerías y las Utilidades; instalaron Distribución tras Distribución, hicieron sacrificios en favor de GNU y el Pingüino, y dieron gracias a los espíritus de Turing, von Neumann y Moore, por su liberación de las garras de Microsoft.
Y este fué el principio de la Cuarta Era, la era del Código Fuente Abierto. Hay mucho más que decir acerca de los extrañísimos y maravillosos sucesos de aquellos días; cómo algunos Conjuntos de Microsoft planearon la guerra contra el Pingüino, pero fueron descubiertos en una víspera de Halloween; cómo Gates cayó entre abogados y fué traicionado y crucificado por sus anteriores amigos, los apóstoles de los Medios; cómo los Caballeros mercenarios del Sombrero Rojo llevaron el evangelio del Pingüino a las salas de las Corporaciones; e incluso de la disputa entre los cofrades del Gnomo y KDE acerca de una Licencia de troll. Pero todas esas cosas están descritas en otra parte, en los Libros de los Hechos del Pingïno, y las Crónicas de la Cuarta Era, y supongo que si narrásemos todas ellas llenaríamos un montón de DVDs tan profundo y peligroso como un Grupo de Noticias de Usenet.
Ahora puedes programar en el poder de las Fuentes; Que el Núcleo, las Librerías y las Utilidades sean contigo, a través de todas las Distribuciones, hasta el fín de la Época. Amén.
]]>Maravillas con un Apple II
http://www.gufete.net/index.php?entry=entry070531-001034
]]>Gestión del almacenamiento: ese gran desconocido.
http://www.gufete.net/index.php?entry=entry070324-202437
Llevo ya unos pocos de años recorriendo CPDs de grandes empresas, organismos públicos (incluyendo a algún hospital) y me he encontrado con que raro es el sitio donde hay una política de gestión del almacenamiento
Muchas veces se confunde un producto con una política. Tener una SAN (Storage Area Network) no significa que se disponga de una una política de gestión del almacenamiento; es más, muchas veces las SAN se usan como su fueran "un gigantesco pendrive", un despilfarro inmenso.
Pero volvamos al tema de la gestión del almacenamiento. No quiero contar un rollo teórico de quince páginas, ni hablar de productos que ayudan a definir una política de gestión del almacenamiento. Empecemos por lo básico: lo más crítico de la informática son los datos. Y los datos se almacenan (tras unas pocas capas de abstracción) en dispositivos. ¿Pero son todos los datos iguales?
Y es esa la primera pregunta que nos tenemos que hacer. No tienen las mismas necesidades de almacenamiento una base de datos que un buzón de correo electrónico que un servidor de ficheros cargado de .doc y .xls. Vamos a intentar formalizarlo un poco haciéndonos unas preguntas:
¿Qué rendimiento de acceso necesito para acceder a estos datos? ¿Qué disponibilidad requieren estos datos? ¿Qué accesibilidad requieren estos datos? ¿Deben estar siempre disponibles? ¿De qué forma? ¿Cómo "envejecen" estos datos? Es decir, ¿varian las respuestas a las preguntas anteriores con el paso del tiempo? ¿Y dentro de una semana? ¿Y dentro de un mes? ¿Y dentro un año? ¿Y dentro de 5 años?
Todas las preguntas anteriores evaluan distintos aspectos de la información: cómo debe protegerse, como y cuánto se accede, y como varían los parámetros anteriores a lo largo del tiempo. Por poner un par de ejemplos tontos, tal vez no deba almacenarse igual un correo electrónico de ayer que uno de hace 2 años. O quizás no tengan las mismas necesidades de almacenamiento el log de un servicio de ayer que el log generado hace unos meses.
Los párrafos anteriores dan una visión centrada en los datos. También es necesario tener un ojo puesto en la infraestructura actual (y futura) del CPD en el que nos movemos: ¿a quién no le ha pasado que tiene una máquina corta de espacio y luego tiene espacio de sobra en otras?
La gestión del almacenamiento es una disciplina que pretende poner un poco de rigor en todo esto. Así, estudiando detenidamente las necesidades de almacenamiento es posible decidir una política de gestión del espacio así como realizar compras de material con la seguridad de que se le va a dar un buen aprovechamiento.
Todo este tema (que a mi particularmente me apasiona), simplificándolo un poco, se basa en dos pilares fundamentales: jerarquización del almacenamiento y ciclo de vida de la información
La jerarquización del almacenamiento se suele conocer por sus siglas en inglés, HSM (Hierarchy Storage Management). Como casi todo en informática, la primera implementación fue en sistemas Mainframe. Se trata del conjunto de estrategias de administración del almacenamiento según las cuáles es posible identificar y definir la mejor utilización de los recursos hardware a través del movimiento de los mismos de un medio de almacenamiento disponible a otro, basándonos en un juego de políticas predefinididas y estando soportadas dichas políticas por el hardware y software adecuados.
Hablando en plata: mientras más rápido es un soporte de almacenamiento , más caro suele ser. Mientras más queramos proteger una información (raid, backup, etc), más caro nos costará. Y es por eso que hay que buscar un equilibrio entre rendimiento, disponibilidad y accesibilidad. Y nada mejor que aclararlo con ejemplos:
Para una base de datos crítica quizás sea necesario poner toda la carne en el asador y elegir almacenamiento SAN, con conexiones de fibra, y almacenado sobre un nivel de raid de alto rendimiento y con buena tolerancia a fallos (ej: un raid 10), con una buena política de respaldo. Se trata por tanto, de una situación donde prima el rendimiento de acceso, y que requiere que los datos estén bien protegidos. El coste por gigabyte es alto.
En cambio, tal vez para un servidor de ficheros departamentel baste con una NAS basada en discos SATA usando protocolos como NFS/CIFS, estando los datos almacenados en un raid5, con una política de respaldo estándar. Se trata de un caso intermedio, donde se tienen unas necesidades de acceso, rendimiento y protección de la información que no son tan elevadas como el caso anterior. El coste por gigabyte es medio.
Y por último, los logs de acceso de los proxy-caché squid pueden almacenarse a largo plazo en dispositivos ópticos como dvd y/o magnéticos como cinta, pues rara será la vez que tengamos que acceder a esa. En este caso, prima más el espacio neto total, siendo el coste por gigabyte relativamente bajo.
Por tanto, la jerarquización de la información nos ayudará a elegir entre tecnologías SAN, NAS, DAS, librerias de cintas y almacenamiento óptico, nos ayudará a decidir entre los niveles de raid a emplear, qué política de backup hacer y nos permitirá tener criterio a la hora de elegir dispositivos de almacenamiento para nuestra información.
El almacenamiento de la información se convertirá por tanto en una pirámide, estando en la base aquel almacenamiento cuyas necesidades de rendimiento y disponibilidad sean más bajas (siendo éste el almacenamiento más barato) y mientras más subamos en la pirámide mayor será el precio, el rendimiento y/o la disponibilidad de la información.
La jerarquización de la información nos permite responder a las preguntas de cómo debe protegerse la información, como y cuánto se accede. Pero nos falta la otra mitad del puzzle: ¿cómo varía esto con el tiempo?
La respuesta a esta última pregunta es el uso de técnicas de Ciclo de Vida de la información. Podríamos definirlo como el conjunto de políticas que permiten una adecuada jerarquización del almacenamiento basando la decisión en un conjunto de reglas que se ajustan a la realidad del negocio.
Así, es posible definir una política para que ciertos datos suban o bajen en la estructura jerárquica piramidal comentada hacer un par de párrafos, consiguiendo un equilibrio entre coste, rendimiento, disponibilidad y acceso.
El ciclo de vida es más importante de lo que parece: se está produciendo una explosión de uso del almacenamiento, y elegir el soporte adecuado para la información nos puede hacer ahorrarnos mucho dinero y lograr una mejor eficiencia en nuestro CPD.
Analicemos un ejemplo práctico: un cliente nos plantea la necesidad de servir ficheros a una red de varios miles de usuarios en una inmobiliaria. Este servidor de ficheros va a almacenar documentos .doc y .xls, pero también almacena complejas y pesadas imágenes para el uso de 10-12 arquitectos. Se estima que el espacio útil total ha de ser de 4 terabytes, y el cliente no quiere hacer un desembolso elevado.
Para resolver este problema nos debemos plantear las siguientes preguntas:
* ¿Qué necesidades de acceso tiene la información?
* ¿Qué criticidad tiene la información almacenada?
* ¿Cómo varía lo anterior con el tiempo?
Para responder a la pregunta ¿Qué necesidades de acceso tiene la información? Por la descripción del problema, entiendo que lo que nos requieren es un servidor de ficheros NAS que prestará servicio servicio a los usuarios mediante protocolos como CIFS o NFS. Puesto que la información se va a servir mediante una red ethernet, podemos aventurarnos a decir que el caudal máximo va a ser de 1 gigabit por segundo.
Por tanto, tenemos claro que poco beneficio vamos a obtener empleando un sistema de entrada/salida con un rendmiento mucho mayor que ese gigabit por segundo, pues el cuello de botella va a estar en la red ethernet.
Tenemos que averiguar también qué porcentaje del espacio total en disco va a ser usado por los usuarios "normales" y cuánto va ser empleado por los arquitectos, así como una estimación del tamaño medio de los ficheros de cada uno de estos tipos de usuarios. Así, los ficheros .doc tendrán un tamaño medio de 1 megabyte, los .xls un tamaño de 200 kilobyes mientras que los ficheros de los arquitectos tienen tamaños de varias decenas de megabytes.
También es necesario analizar como se accede a los ficheros. Normalmente los usuarios crean y modifican a diario unos cientos de ficheros .doc y .xls, mientras que los arquitectos solo suelen trabajar con apenas una docena de ficheros. Esto nos dará una idea de la concurrencia de acceso a la información.
Para responder a la pregunta ¿Qué criticidad tiene la información almacenada? es necesario analizar el ritmo de modificación de los contenidos, para poder elegir una política de backup adecuada, así como los niveles de raid a elegir. El cliente considera razonable una parada de 4-5 horas en caso de fallo catastrófico, pero por lo general el sistema ha de funcionar al menos el 95% del año laboral. Esto nos da una idea de que no parece crítico emplear técnicas de alta disponibilida/clustering, por lo que con un solo servidor parece bastar, con unos niveles de garantía con el fabricante de hardware para que en menos de 4-6 horas podamos tener un recambio de la pieza en caso de fallo hardware.
Mi solución para este problema (ojo, la mía, invito al lector a que dé la suya, esto es un ejemplo didáctico, no un ejemplo exhaustivo) sería el uso de un servidor x86 tipo rack con 4 gigabytes de ram, electrónica de red gigabit, fuentes de alimentación redundantes y con sistema operativo RedHat Enterprise Linux. Este servidor contará con dos sistemas de almacenamiento externos tipo DAS: una bandeja de discos SAS con 8 discos de 146 gigabytes y 10.000 rpm y con otra bandeja de 14 discos SATA de 750 gigabytes y 7.200 rpm.
Sobre este almacenamiento antes descrito, definiría dos raids: El primer raid estaría formado por 7 discos SAS, estando uno de los discos en spare. Eligiría un nivel de raid5, implementado por hardware, respaldado por una batería de caché. El espacio util sería de aproximadamente 1 terabyte.
El segundo raid estaría formado por 13 discos sata, quedando el número 14 como spare. Eligiría un raid6 por software, empleando mdadm . El espacio útil es de casi 9 gigabytes y medio. Elijo hacer un raid6 porque tengo muchos discos en el mismo raid, no porque la criticidad sea mayor que en el raid SAS.
De esta forma tengo un almacenamiento caro de alto rendimiento de discos SAS (más caro), que es donde va a estar la información que se esté usando más habitualmente y otro volumen de discos SATA donde estarán los ficheros que menos se usen, así como backups de los últimos ficheros que se hayan modificado.
Haciendo uso del software LVM integrado en RedHat Enterprise Linux puedo incrementar el tamaño de cualquiera de los raids de manera sencilla. Éste mismo software me permitirá hacer "snapshots" periódicos de la información y almacenarlos en el raid SATA para poder tener así un backup "near line" sin tener que hacer uso de la libreria de cintas. El comando rsync también nos puede ser de utilidad para mantener copias de ficheros individuales.
Dicha librería de cintas se usaría para copias de seguridad "off-line" a almacenar en un armario ignifugo. Se harán copias diferenciales de los snapshots cada día, una copia incremental del volúmen completo cada fin de semana y copias totales cada mes.
Por otra parte, emplearía bonding en las dos tarjetas gigabit integradas en la máquina para tener un caudal efectivo de 2 gigabits por segundo, y con la electrónica de red adecuada podría tener redundacia de acceso a la red de datos, para que el fallo de un conmutador o un cable o de una de las tarjetas de red no impida el acceso al servicio.
El sistema de almacenamiento funcionará de la siguiente manera: se configurará el software samba para integrarse en el directorio activo actualmente existente en el cliente y emplear el protocolo CIFS para servir los ficheros.
Por último, definiría una política de ciclo de vida de la información según la cual si un documento .doc o .xls no ha sido accedido en 7 días se mueva del almacenamiento SAS al SATA (basta con un enlace simbólico). Los ficheros de los arquitectos tendrán una política similar, pero con una persistencia de 15 días.
A su vez, si un fichero .doc o .xls que está en SATA es accedido por más de 5 usuarios en menos de 8 horas, se ha de mover al almacenamiento SAS, ajustando el enlace simbólico.
Esta política es fácilmente configurable con un par de scripts en el cron, pero se podría emplear un software específico si la complejidad creciese.
De esta forma, con la política definida, los ficheros que se usen con poca frecuencia y los backups estarán en el almacenamiento SATA, que es más barato y con mayor capacidad, mientras que los ficheros con mayor uso/concurrencia estarán en el almacenamiento SAS, más pequeño pero con mayor rendimiento.
Una vez visto el ejemplo (que repito, es un ejemplo didáctico y simplificado), mi recomendación respecto a la gestión del almacenamiento es que hay que dejarse asesorar. Que alguien con experiencia nos ayude a la definición e implantación de una política adecuada nos puede hacer ahorar una importante cantidad de dinero, y hará que nuestros datos estén accesibles y protegidos.
]]>Tecnólogos vs Directivos: Round I
http://www.gufete.net/index.php?entry=entry070303-155159
HP
Copio y pego literalmente:
A technologist who was setting up a computer system for a law firm started by asking the attorneys exactly what they wanted the system to do.
One said, "I want to be able to ask the computer how much money I'm owed by clients, how much I have billed and how much I have in the bank."
"Okay," the techie replied. "We'll set the system up with financial reporting software that will generate a report for you every day."
"No, no," the lawyer said. "I want to ask the computer."
"Okay. We'll set up the report so you can type in a query and get exactly the information you need."
"You don't understand," the lawyer insisted. "I want to be able to walk into my office and say, 'Computer! How much money do I have in the bank?' And the computer will tell me.
"They do it that way on Star Trek all the time."
True story.
This example may be extreme, but it does illustrate a common disconnect in the workplace: Business professionals (suits) and technology professionals (geeks) failing to communicate clearly. It’s a phenomenon we’ve dubbed the “Geek Gap.”
There’s no sure-fire prescription for getting technologists and business folks to come together. As a general rule however, the more each side learns about the other, appreciates the thought and talent that goes into that work, and respects all who contribute to the health of the organization, the closer you’ll come to bridging the gap. With those objectives in mind, we offer these 10 tips—five for geeks from suits, and five for suits from geeks.
Tips for Geeks from Suits
1. Learn something about business. Take some basic business courses. Understanding the concepts that underlie management decisions, and what effects IT decisions can have on the bottom line, can give geeks a sense of ownership in the company’s success
2. Focus on the project as a whole, not just the technology. Tech workers tend to be fascinated with technology, often to the exclusion of other aspects of the total job. Organizations are far stronger when everyone looks at the project as a whole.
3. Don’t expect suits to know as much about technology as you do. Geeks live and breathe technology. Suits do not. Sometimes, techies can be downright evangelical about their favorite software. Suits just want it to work so they can get the job done. While suits need to know some computer basics, keep in mind that they are also focusing on a completely different knowledge set for their own jobs.
4. Try to use plain language, and not “geek speak.” Geeky terminologies may be perfectly understandable to your co-workers, but do remember that suits don’t speak geek. They value your opinion and knowledge. It’s important that suits understand what geeks say, so keep it basic, simple to understand and clear.
5. Be involved in more meetings, not fewer. It can be very easy to hide from meetings behind the technology you manage. Problems and questions involving technology often arise in business meetings, and having a knowledgeable geek there can mean the difference between a smooth-running project and one riddled with false starts and unmet deadlines.
Tips for Suits from Geeks
1. Learn something about technology. One of the biggest frustrations for tech workers is dealing with business colleagues who resist learning computer basics. Suits don’t need to become computer wizards, but knowing some essential IT skills is necessary in the modern business world. Suits who take computer courses gain a greater understanding of how technology works, and what it can and can't do. Even a beginner course in programming can help business people better understand computer work and give them more respect for their techie colleagues. .
2. Technology should always be part of the business plan. Don’t leave the technology aspects out of a project until the end. Bring the geeks in on the business development meetings early and keep them informed thoughout the stages of the project. Keeping the technology in mind as the project grows will smooth many of the processes, saving time and money, and raising the chances of success.
3. Build some flexibility into schedules and budgets. Building and working on technological products is as much art as engineering. Allow some flexibility in the calendar and the spending to give your techies the opportunity to build a good product. Otherwise, you may wind up with something on time and on budget, but not on the mark. Geeks would rather get it right before a system goes into production. It’s easier and less expensive than fixing a buggy system already in use.
4. Try to use plain language, not buzzwords. Like any specialized workers, suits have their own words that make their job easier. Whether “incentivizing” the buyer, “gaining traction” with products or putting the “paradigm shift” spin on “restructuring,” geeks understand that language can be powerful. However, keep in mind geeks don’t want to be sold on an idea. Limit the motivational talk.. Sometimes, it’s not a “challenge” or a “hurdle.” It might just be a problem to fix, and we can work together much better if we both use plain language.
5. Talk to us directly. Many companies designate one employee as a liaison between the technology department and other business areas. Having a liaison is great, but making this person the only conduit for information to and from the tech department is a mistake and will create bottlenecks. Feel free to approach whoever can get the information you need..
No advice we could offer in a short article amounts to the final solution to an intricate and ingrained problem like the Geek Gap. However, anything you can do to get geeks and suits talking to one another can help your organization span the Geek Gap, often with dramatic results.
]]>Es época de pruebas...
http://www.gufete.net/index.php?entry=entry070127-132705
Se debe haber congelado el infierno, se acerca el fin de los tiempos: el miércoles pasado aprobé el examen práctico del carnet de conducir... me he sacado el teórico y el práctico a la primera, seguro que esto es una señal de la venida del príncipe de la oscuridad...
Yo calculo que en dos o tres años sabré lo BÁSICO como para poder denominarme conductor. Por ahora lo que tengo es un examen aprobado, nada más, y tengo muy claro que no tengo ni pu*a idea de conducir. Prudencia. Y buenos alimentos.
Por otra parte, el próximo día 1 de febrero me voy a Guildford, en Reino Unido, a presentarme a éste examen de RedHat. Esta es una de las 5 pruebas que debo superar para ser RHCA, es decir, arquitecto de RedHat (ya soy RHCE, ingeniero). A ver que pasa...
Y qué es la vida sino un montón de pruebas. Y es que lo bonito es el camino, no el final...
]]>Elección de sistema de ficheros para discos duros externos
http://www.gufete.net/index.php?entry=entry070107-202932
Este año uno de los regalos de reyes para la nena ha sido un disco duro externo usb de 80 gigabytes. Y ahora viene el problema: ¿Qué sistema de ficheros usar?
La elección sencilla parece ser fat32. A fin de cuentas, lo leen y escriben MacosX, GNU/Linux y Windows. Pero resulta que el tamaño máximo de un fichero en fat32 son 4 gigabytes, lo cual es una lata cuando se quiere copiar uno imágenes de dvd completas (4,4 gigabytes), hay que recurrir a split (o su equivalente en el otro mundo, hacha).
Puesto que fat32 es limitado, veamos como está la cosa con NTFS. Resulta que por defecto MacosX y GNU/Linux son capaces de acceder en modo lectura, pero no en escritura. Existen proyectos como éste o éste para añadir soporte de escritura para GNU/Linux. Por desgracia, para MacosX el panorama no es tan bueno y los proyectos para añadir soporte de escritura para NTFS aún están un poco verdes.
Veamos ahora la posibilidad de usar HFS+. Tanto GNU/Linux como MacosX leen y escriben perfectamente en este formato. Existe una herramienta para Windows llamada Macdrive que posibilita la lectura/escritura, pero son 49,95 $. Desconozco si existe alguna otra utilidad para Windows que soporte HFS+, así que te animo, desconocido lector, a que aportes tu experiencia, que en google ya se buscar yo.
Pues nos queda ext2/ext3. En GNU/Linux, como es lógico, está perfectamente soportado, y existen utilidades gratuitas para acceder en lectura/escritura a discos en este formato tanto en MacosX como en Windows. Parece que al final esta es la mejor solución, pero no deja de ser un peñazo tener que instalar drivers adicionales en el ordenador de un amigo para acceder a un disco externo...
Alguno dirá que la solución es la virtualización. Con Parallels, qemu, xen o vmware uno puede cargar el sistema operativo que necesite en cada momento, pero por desgracia esta no es una solución muy práctica cuando uno le presta el disco a una persona (sin conocimientos de informática, se entiende) para que te copie el dvd de sus vacaciones...
Otros dirán que lo más fácil es llevarse uno el portátil, montar el dispositivo con el sistema operativo que más le guste y luego acceder a los datos del otro ordenador usando cifs/nfs/ftp/scp, pero ya se tiene que llevar uno el portátil para copiarse unos datos, una carga más.
En fin, parece que al final ext3 es la mejor elección para un disco duro externo "multiplataforma". ¿Se te ocurre algo mejor, desconocido lector?
]]>De lo malo lo peor
http://www.gufete.net/index.php?entry=entry061206-002324
