Archivos Mensuales: septiembre 2013

Un breve paseo por lo privativo …

Ayer me encontraba implementando un servidor de Microsoft SQL Server, ya que necesito replicar unas DB hacia un almacén en postgreSQL usando ETL, saliva e’ loro y muchas pegatinas; en fin, como tenía muchísimo tiempo sin hacer algo así, me tocó visitar muchas páginas para poder lograr algo ¿y luego se *quejan* de lo “difícil” del software libre?, no me …

  1. La noche comenzó intentando primero “decidir” cual de las diferentes versiones de sistema debes montar, Standard, Core, Enterprise, Workgroup, Workload, Enterprise Plus, Enterprise Plus ++, Datacenter, Developer Mainstream, “I’ll be back and you must die” y un sinfín de variedades, bueno, escogí una al azar y “descargando” …
  2. Luego, descargar la versión “express edition” de la DB no se quedó atrás, ¿2.2GB para una base de datos limitada y en versión *express*?, eso mide TODO mi sistema operativo (con escritorio y todo) para correr postgreSQL.
  3. Al finalizar ámbas cosas y montarlas en una VM, descubrí que la versión “express café edition” que bajé, no era para mi idioma, por allá decía “bueno, puedes instalar un *paquete de idioma* para poner tu sistema operativo en otro idioma, siempre y cuando tengas la versión Enterprise Plus ++ con sildenafil extendido”, ¡rayos!, ¿cómo es eso que tengo que “pagar” por un sistema operativo confinado al idioma en que me lo vendieron?
  4. Al tener ámbas cosas instaladas (y ni se imaginan la cantidad de horas que dura la **configuración del SQL Server “express”**) (y en inglés ¿para qué me voy a buscar más conflictos?) me tocó buscar el respaldo de la DB en producción.
  5. En un paseo entre gurús MVP (se lee “EM-BI-PI”) unos decían que “no puedes hacer un backup con sqlcmd hacia un recurso UNC” (porque no son capaces de decir “una puta carpeta compartida”), otros decían “claro que puedes” (pero no explican cómo) y otros más aberrados aún decían “claro que se puede, yo mismo acabo de hacerlo” (y tampoco aclaran como).
  6. Luego de girar por varias “redes sociales de desarrolladores privativos” (si!, y tienen muchas!) me encuentro con qué el uso de tecnologías “privativas” es una suerte de religión donde la gente le cree a los “EM-BI-PI” (y dicen para sus adentros con voz de squeezes “oooh, el ¡MVP! ese si que sabe!).
  7. El proceso de búsqueda de información de foros se convirtió en una guerra de “quien la tiene más grande” (la firma), con cosas como “Entrad en el registro de Windows” (es como el “abrid una cónsola de root” para ellos), pero bueno, eso de luchar con egos en listas y foros y de respuestas alienantes y sin sentido es del mundillo en general … ¿no creen?
  8. Aún recuerdo al “pobre hombre” que tenía un archivo “qué convertir” usando Word 2007 (no ha conocido el poder de “sed”, “egrep” y “awk”) o aquel que dijo que instaló Windows 8 Empresarial technical review full edition y deseaba recuperar unos datos *perdidos* durante el formateo y el MVP-Technet Engineer CTO Junior “Most pleasure for less” le indicó que “era algo absolutamente imposible e irreversible” (hasta testdisk que es libre hace eso) blip! *
  9. – Y ni hablar del pobre hombre que dijo que el “ícono” de la aplicación “itunes” -is gone- y le sugirieron (cual recuerdo de aquellas sugerencias de “¿su impresora no imprime?, ¿tiene papel?, ¿está conectada a la corriente eléctrica?, ¿tiene tinta?, ¿está encendida?, “si todas las respuestas son positivas, entonces no puedo ayudarlo”) que debía “ingresar a la tienda Windows, buscar *música*, descargar y reiniciar la PC”, eso de reiniciar siempre ha sido la solución para todo.
  10. Leyendo posts y artículos, encuentro frases como “eso lo resuelves modificando la línea de clave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL con valor hexadecimal “C0ch1n0NOCoM3JoBo”, uno sugirió que se debía a “una problemática de permisos a la red” y que debía modificar unas claves del registro, autorizar unos servicios y reiniciar el SQL ¡¡¿REINICIAR EL SQL EN PRODUCCIÓN DEL CLIENTE?!! ¿están borrachos o qué? …
  11. Al final, una luz me indicó “claro que funciona, prueba con la versión sqlcmd de la librería freetds para Linux”, a lo cual, presto, compilé la librería para SQL Server en el servidor Debian donde estaba mi Samba y ejecuté el comando sqlcmd ¡pum!, un error “mejor llame a su madre, de nivel 5, core 3, subsector de pila alcalina 48123×545477000 vete al carajo” …
  12. Un MVP muy amable de la India me indicó “no le pares pelotas a todo lo que va después, el error nivel 5 es un error de permisos” ahh!, coño!, no podían decir “access denied” los muy hijoerrrdiablo? …
  13. después de un chmod 0777 a la carpeta compartida del Samba (no quería sustos) el sqlcmd funcionó PERFECTAMENTE y trasladó 50GB de datos a un recurso compartido en mi servidor Samba.
  14. Luego, ajá, y ahora ¿se podrá automatizar esto en el servidor?, luego de ofrecerme varias herramientas costosísimas como “Mete-tu-SQL Backup Pro Platinum More powerful Edition”, me encuentro con otro Indú que afirma en su blog que encontró la manera perfecta de hacer backups “gratis” de tu servidor MS SQL.
  15. Usando “La Chel del Poder” (Powershell) hizo un *sencillo* script (según él, sin validaciones ni nada) con la friolera de 95 líneas de código (sin espacios ni comentarios), según fue muy felíz porque se sentía “poderoso” con *eso* (pobre no conoce “pg_dump -d database > archivo.sql”) xD
  16. Al final, terminé haciéndolo del lado del Samba, un lindo bash en cron con 10 líneas (incluyendo espacios, comentarios, respaldo incremental con fecha y si, tiene control de errores).

Concuerdo que hay una sarta de trolles, enfermos de ego y demás fauna del lado del software libre, pero ¿cómo por la madre de Zeus pueden decir que es “mucho más fácil todo con software privativo”?, al final del lado “libre” fue:

  1. En en lado de mi servidor: aptitude install postgresql-9.1
  2. En el lado del usuario: su postgres
  3. createuser -sPL jesuslara
  4. pg_dump -H servidor_cliente -U jesuslara -W -c –format c basedatos | pg_restore -U jesuslara –clean –dbname basedatos
  5. UNA SOLA LINEA BACKUP Y RESTAURACION!
  6. Y para los mas “mainstream”, usé Apatar y luego Talend Data Integration para movilizar toda la integración de datos …

¿No y que en software privativo TODO es más fácil? …

La cadena de custodia: NSA y software libre

Han pasado dos noticias bastante interesantes en estos días, la primera, unas declaraciones de Kevin Mitnick, asegurando que la NSA había “Infiltrado” el código del PGP (Pretty-Good-Privacy), en la otra, que la NSA había “infiltrado” las decisiones para que el dispositivo generador de números aleatorios (/dev/random) del sistema Linux, dependiera del hardware, en este caso, de extensiones de hardware de CPUs Intel y AMD, comprometiendo la seguridad del núcleo …

¿Afectan estas noticias la credibilidad del software libre?, ¡al contrario!, veamos por qué.

Comprometidos con su seguridad …

Del PGP al GNU PG

PGP es un software “comercial” (y es “a ese software” al que hace referencia Mitnick), actualmente las patentes alrededor tanto de PGP como de los algoritmos de cifrado, están a cargo de Symantec, incluyendo el cifrado IDEA que hace uso PGP; en su lugar y gracias al uso de algoritmos libres (tanto de patentes, como limpios en sus especificaciones, como RSA-AES) se desarrolló GNU PG (GNU Privacy Guard) como una implementación de openPGP y que es la versión de PGP que utilizan TODAS las distribuciones de software libre a nivel mundial.

Hay que recordar de GNU PG dos historias claves, el caso del famoso bug detectado por la gente de Entrust de 2004, que causó la re-escritura de uno de los métodos de cifrado simétrico, el otro caso, en 2006, que fue detectado por la gente de seguridad de Gentoo Linux, y que (a diferencia de otros “bugs” de 10 años de duración en Windows), tardó en corregirse sólo 6 días.

Random Number Generator

Dilbert’s Random Number Generator

“/dev/random” es un pseudo-dispositivo de software, que existe en el núcleo Linux con el único propósito de proveer de una máquina generadora de números aleatorios, “/dev/random” hace uso de extensiones de hardware en los CPUs (Intel, AMD, Texas Instruments-ARM, etc) para poder generar números “pseudo-aleatorios” (se dice “pseudo”, porque al ser un computador un sistema determinista, hay una probabilidad remota de que los números no sean realmente aleatorios).

Al igual que con PGP, en Linux existe además “/dev/urandom”, la diferencia entre ellos es clave, el primero, basado en “entropía de hardware”, puede llegar a quedarse “exhausto” de bytes, por ende, esperará a llenar el pool de entropía para entregarte “más números aleatorios”, esto hace que “/dev/random” sea en consecuencia, más lento que “/dev/urandom”, que simplemente reutiliza la fuente de entropía una y otra vez para obtener más números aleatorios por software (es por esta razón que lleva la “U” adelante, de “unblock”, es decir, no se bloquea como /dev/random).

Entonces, ¿la decisión de Torvalds compromete la seguridad de algo?, ciertamente de las distribuciones de GNU/Linux en las que “/dev/random” utilice exclusivamente la entropía del CPU (que al sol de hoy y luego de los trabajos de Gutterman y Reinman en 2006, creo que ninguna); hay parches en Debian GNU/Linux (no aprobados en la LKML -Linux Kernel Mailing List-) que modifican /dev/random para hacer uso de más entropía como ioctl (movimiento del mouse, ruido del flujo de video, ruido del tráfico de la red, etc), dichos parches se aplican desde el 2006 por requerimiento de aplicaciones “precisamente” como GNU PG y GNU TLS.

Creo que incluso, después de “descubierto” el compromiso de las extensiones de CPU Intel por parte de la NSA, un simple “parche” será cosa de algunos días.

¿no creen?

Coneheads y la NSA llegó a mi casa …

Una vez alguien me escribió que iba a “desactivar SELINUX porque era un producto maléfico de la NSA”, además del hecho de existir varios miles de ojos dentro del código de SELinux (admitir que hay código malicioso dentro del núcleo Linux es contradecir expresamente lo que se defiende acerca de las 4 libertades que la FSF defiende a ultranza), es más que claro con el hecho de arriba (/dev/random no está comprometido, sino una de sus tantas fuentes de aleatoriedad, como lo son los CPU de Intel/AMD) que el software libre ha probado, una vez más, que se deben comprometer cosas “más oscuras” que el código, para empañar la seguridad del núcleo Linux (o de freeBSD,  por ejemplo).

De Intel se cree todo, por allá por la guerra del golfo, se distribuyó por la “conspironoosfera”, una *noticia* que indicó que todos los CPU Intel “chiflaron y se quemaron” dejando inútiles miles de computadoras en Bagdad, minutos antes de iniciar la invasión a Irak ¿posible?, 100%, ¿creible?, muy creíble … de la NSA espero todo.

Pero como indicara alguien en las listas de Fedora (precisamente a la respuesta de SELINUX y su relación con la NSA), cualquier relación con “desactivar SELinux porque lo hizo la NSA y fabricar conos de papel aluminio para “librarse de lectores mentales”, es pura coincidencia … “Los conos de papel aluminio se deben hacer de 2 caras, una cara reflectante hacia afuera, para evitar que “entren” cosas enviadas con rayos mentales por la NSA, pero también con papel reflectante “hacia adentro”, para evitar que la NSA use rayos mentales para leernos la mente, ah!, hay que evitar que haya un “corto-circuito” entre ámbas capas, para no quedar comprometido”.

Es decir, si el CPU (harware) es comprometido por alguna “instrucción maléfica”, no importa el sistema operativo que tengas encima, ¿no creen? …

Claro, ahí si caemos en la retórica de la “eterna conspiración”, podríamos indicar “ahh!, pero Selinux podría *restaurar* sus *troyanos* a través del compilador”, entonces les recuerdas al compilador libre GCC (GNU C), “Ahh!, pero segurito GCC usa extensiones de CPU y si te comprometen el CPU?”, bueno, ármate tu propia máquina! (empezando por el CPU) ¿para eso hay movimientos de hardware libre?, ¿no?; de llegar a pensar así (en esa eterna cadena conspiranóica), tendrías que ponerte como algunos conspiranóicos que hablan de IPv8 (¿no sale más fácil esto si quieres privacidad?) tendremos que vivir en cuevas, con nuestro propio hardware de computadora, nuestras propias redes, fabricando hasta nuestro propio cable (inmune a las ondas electromagnéticas que USA lanza regularmente antes de cualquier invasión), rodeando nuestras cabezas con conos de papel aluminio (bien diseñados, ¡por favor!) y evitando cualquier contacto con otro ser humano “sospechoso”.

Vivimos esta realidad, hay que enfrentarla … no tratar de volver a las cuevas y el oscurantismo …

A %d blogueros les gusta esto: