Sysnotas - System Administration

Nubes Privadas para dummies

2011-10-03T13:51:00.000-07:00

Esteartículo comenzó igual que la mayoría de los problemasinteresantes, con una simple pregunta

¿Porqué iniciarse en infraestructuras de cloud privada?.

Desdeel punto de vista del especialista en infraestructura, solo puedellamar a una respuesta "Qué? Todavía no comenzaste aimplementar una private cloud?"

Sí,es así de necesario.

En elfondo es bueno

Lacuestión de fondo es que las private clouds son una solución adiversos problemas de infraestructura que han estado dando vueltas enlos datacenters desde poco tiempo después de que se hizo el avance -o retroceso, es cuestión de opiniones - tecnológico de grandesmainframes propietarios a "pequeños" servers (primero elhard propietario de Digital, Sun, etc. y luego a Intel, AMD, ahorainclusive yendo a ARM).

Sitodavía tienes pocos servers en tu datacenter, este es el momento deempezar a ganar insight en infraestructura de private clouds. De esemodo tendrás listo el skillset y el expertise para el momento en quellegues a los problemas que se desprenden de usar serversindividuales, luego sumarles storage externo (SANs y similares),luego empezar a virtualizar servers físicos en hipervisores y luegoempezar a utilizar manejadores de hipevisores.

Unacloud privada es justo el tipo de software que puedes utilizar juntocon los manejadores de hipervisores o para reemplazarlos por completo(depende de la solución y del producto) y resolver los problemas quetodavía no mencioné (de hecho).

¿Quéganamos con más trabajo?

Pareceríaobvia la respuesta, pero vamos a los sucios detalles.

Laganancia de utilizar private clouds son muchas, en principio puedoreferenciar las listas de problemas de las páginas de datasheets delos varios vendors de soluciones de virtualización, que es donde vasa encontrar el 100% de los problemas que resuelve una infraestructuravirtualizada.

Luegode eso, para qué querrías complicarte la vida con el montaje de unaprivate cloud? La respuesta es simple: no es complicarte, si yallegaste al último paso y estás usando manejadores de hipervisoresen tu día de oficina típico como sysadmin, ya estás a las puertasde:

-Necesitar manos extra ($$$ en más sysadmins), y/o

-Necesitar más tiempo de trabajo propio ($$$ y !#$% a granel,compitiendo simultáneamente por tu valiosa atención)

- Enlo técnico, tus máquinas virtuales van a empezar a necesitar untrabajo semi-artesanal de babysitting muy similar a las viejas épocasdonde se parcheaba y compilaba manualmente código fuente de Apachepara varias decenas de servers. No, no hablemos de kernels, algunossysadmins ganan un rápido estado de agitación de solo recordar losdías de administración manual de kernels Linux :-D

Lo queno anda nos encontró (y no queríamos)

Endefinitiva, las nuevas capacidades de la infraestructura virtual (ytodo lo que hay "abajo"), han creado un monstruo: lafacilidad para crear nuevos servidores tan rápido como puedaclickear "aceptar" el sysadmin.

Eso noes bueno, definitivamente, es bueno para el negocio, es bueno para lainfraestructura, es bueno para los developers, etc. pero no es buenopara el sysadmin.

Haydecenas de componentes anidados en una infraestructura virtual, queincluso si fue muy bien diseñada (las chances van al contrario),pueden fallar. Ahora ¿por qué digo que "tu"infraestructura virtual está mal diseñada? No lo dije (lee devuelta), sino que la mayoría de las "infras" van aterminar virtualizadas "por las malas", esto es tambiénconocido como "implementación paulatina", con muchos SPOF(Single Point of Failure), acechando detrás de cada esquina deldatacenter.

No seañade a esa sopa de SPOFs un capa más de administración demáquinas virtuales promiscuamente generadas a golpe de llamadastelefónicas de management, un rápido capacity planning (y un feliz"sí jefe, se puede"), y un par de clicks casi no muymeditados.

Esainfraestructura virtual va a requerir - más - tiempo deadministración, que no va a estar disponible si estás ocupadocreando y borrando máquinas virtuales.

Lasolución es una private cloud.

Metiendolas manos en el barro

Laidea central de la private cloud es ocuparse de crear una interfazentre los usuarios de la infraestructura virtual, "clientes"a partir de ahora y los recursos de la infraestructura (virtual),"servicios" desde ahora.

Cualquierprivate cloud software que se precie de llamarse así brinda unainterfaz lo suficientemente gráfica para que un "cliente"pueda conectarse a ella, elegir de un menu (ahí hay trabajo deconfiguración para el sysadmin!), y luego crearse para sí mismo unareluciente y nueva máquina virtual, con toda clase decaracterísticas técnicas muy interesantes, pero con característicasno técnicas aún más interesantes:

Elservicio del software de private cloud incorpora al autoservicio decreación de máquinas virtuales no solo la extracción quirúrgicade la necesidad de comunicaciones telefónicas y de correos y lacorrespondiente lluvia de chequeos y autorizaciones, sino tambiénincorpora a la administración automática (configurables por elsysadmin), diversas políticas muy útiles, por ejemplo:

-Cuanto tiempo de vigencia tiene la máquina virtual antes de serautomáticamente borrada

- Seráborrada de inmediato? o solo apagada y dejada en reserva, por cuantotiempo?

- Elpersonal de helpdesk puede crear nuevos servers o clientes virtualesde prueba para software de oficina, con tremendas restricciones anivel de comunicaciones de red con el resto de la infraestructurainterna.

- Elpersonal de sysadmin (esos somos nosotros), podrá crear la cantidadde máquinas virtuales que necesite (quiera), sin importar que seseleccione la cantidad total de RAM disponible en el hipervisor (esbroma :-).

- Elpersonal de desarrollo tendrá determinados privilegios extendidos,para crear y guardar determinada cantidad de servidores virtuales (demodo de poder ir probando diversos baseline de configuración parauna aplicación).

- etc.etc.

Laidea de mostrar un par de políticas no es abarcar todas lascapacidades del software de private clouds, sino que se vea qué tipode trabajo administrativo se está automatizando - esta palabra esadorada por RR.HH. y jefes hoy en día - y mejorando sustancialmente("si es automático, no puede haber error humano", ya sé,ya sé...está muy sobrevalorada la idea).

Veamos un par de detalles técnicos; hoy disponemos de OpenNebula y OpenStack, softwareopensource (licencia Apache ambos), que a diferencia de la mayoríadel software de clouding privativo permite administrar varios/muchos tiposde hipervisores, incorporando nuevos tipos con regular frecuencia. Traducción al español: desde tu soft de cloudprivada puedes usar al mismo tiempo máquinas virtuales(hipervisores) KVM, Vmware, Hyper-V, Xen, Virtualbox y probablementenuevos tipos (y versiones no retrocompatibles con viejos hipervisoresdel mismo tipo!!! alguien dijo escalabilidad horizontal?), dehipervisores que vayan apareciendo.

Lasposibilidades en lo técnico se amplían al poder utilizar cloudshíbridas: múltiples tipos de máquinas virtuales, locales yremotas, que incluye las de proveedores públicos de clouding comoAmazon y probables futuros proveedores de clouding basados enestándares (impuestos por los productos opensource como OpenNebula yOpenStack).

Conclusiones

Estoes básicamente una explicación a vuelo de pájaro, así que no haytanto material para sacar conclusiones.

Lobásico es que si no usas private clouds, lo harás porque:

- tepedirán que lo hagas,

-eventualmente lo vas a necesitar,

- dehecho puede que no lo llegues a necesitar (o que nadie se haya dadocuenta que hace falta :-), y en realidad verás que te solucionasuficientes problemas para que querer usarlas.

- yclaro, es innegable, son tremendos powertoys para el sysadmin con unpoco de sangre caliente en las venas.

-pensandolo mejor, sí las vas necesitar, es mejor que empieces ahora.

El reloj corre para el software propietario complejo

2011-09-30T05:39:00.000-07:00

"El reloj está corriendo" dice Marc Andreessen y habla de un hecho conocido en el ambiente de infraestructura, en realidad es más bien como una sensación, como el viento frío que pone la piel de gallina.

Se termina un modelo de negocios, comienza otro
La sensación es que se va acabando el modelo de negocios basado en soluciones de software propietarias complejas; el ejemplo de Marc es Oracle. Lo da como ejemplo, sin embargo se puede encontrar un largo listado de software propietario complejo que va siendo lentamente desplazado por otras opciones.

El ejemplo de Oracle es obvio y el escenario se repitió ya varias veces. Google, Facebook, Yahoo, Linkedin, Twitter, FourSquare, y la lista de "no-clientes" que califican como los usuarios de bases de datos más importantes del planeta crece día a día. Y Oracle no vendió ni una sola licencia en ellos.

Marc menciona que antes de las soluciones libres de base de datos, de storage y sistemas diversos, cobrar 20 millones en inversiones implicaba automáticamente pagar 5 millones en software y hardware propietario complejo (bases de datos, hardware de networking y storage).

De hecho, ninguna de las "startups" de Marc utiliza software propietario complejo (Digg y Twitter entre ellas).

Hoy las soluciones opensource - de costo de licencia cero - y comerciales basadas en opensource o semipropietarias - mucho más baratas - permiten prescindir/minimizar los costos en pago de licencias que antes eran imposibles de descartar.

Más ejemplos
Hay muchos ejemplos adicionales, el decaimiento constante de soluciones SPARC - la plataforma por default de Solaris - por x86-x64 (Intel/AMD); la constante migración de sistemas unix (Solaris a la cabeza de los unix que se van despidiendo), a linux.

Es un largo etc. donde podemos seguir hablando de soluciones de backup: tradicionales - a disco y a cinta - y no tradicionales: basadas en sistemas de archivo distribuídos y alta redundancia de nodos en cluster; basados en snapshots de volúmenes, etc.

Lo mismo para el software de monitoreo, la preeeminencia de soluciones libres basadas en Nagios (o en su arquitectura al menos), es omnipresente.

Ni hablar de soluciones de webserver (Apache es la mayoría absoluta en nro. de implementaciones en Internet) y de servidores de correo (Postfix está en una situación similar a Apache).

El nuevo software propietario complejo, fuerte hoy en el mercado, lucha versión a versión -por ejemplo Vmware vSphere - para mantenerse por delante de soluciones opensource o semipropietarias sustancialmente - tanto como un 80% - más baratas (XenServer, Red Hat Enterprise Virtualization, Virtuozzo), o directamente opensource 100% y de costo de licencia cero (KVM+libvirt+virt-tools, base de RHEV; Xen base de XenServer, y Open VZ, base de Parallels Virtuozzo).

Es verdad que hay "shops" que siguen y seguirán comprando soluciones propietarias complejas, es una buena práctica incluso lo que sostiene el uso de soluciones propietarias complejas por ahora, pero todo indica que tarde o temprano la gran mayoría de los "shops" empezarán a reemplazar mucho de su software innecesariamente caro y complejo por:
* software mucho más barato y/o directamente sin costo de licencia ( lo que incluye no pagar actualizaciones), y
* mucho más barato de administrar (ya que los administradores muy especializados van a a ser mucho más caros que la mayoría de los sysadmins que sabrá administrar las soluciones estándar del mercado).

El software semipropietario
Este soft es el que es mucho más barato, el motivo es que está basado en código opensource, por ende el valor de su licenciamiento de uso y de soporte suele ser mucho más bajo que el que se encuentra hoy en día en software propietario complejo. Ejemplos: RHEL, SLES, XenServer, etc.

Los Grandes Clientes "pueden pagar y van a pagar"
Existe un prejuicio de que "grandes clientes", "clientes serios" y/o "clientes con buen presupuesto" se inclinarán forzosamente a adquirir soluciones propietarias complejas "siempre". Sin embargo, también hay ejemplos actuales de que ello no es una norma ni el que haya presupuesto implica forzosamente que un cliente vaya a comprar software propietario complejo.

Un ejemplo de lo anterior son "grandes clientes" como los "shops" de sistemas High frequency trading (HFT), que incluyen al momento a varios de los mercados de valores más importantes del mundo:
- NYSE ("bolsa de Wall Street");
- London Stock Exchange ("la bolsa de Londres"), usando SLES
- Deutsche Börse AG ("la bolsa de Frankfurt"), usando RHEL
- y los varios proveedores de HFT privados que basan sus clusteres de análisis - de tamaños similares al de Facebook - en Linux, sin que se conozca ninguno que utilice otro sistema operativo.

De hecho, recordemos que se intentó montar el sistema de la London Stock Exchange sobre Windows Server + Soft (.NET) y dicha solución terminó siendo descartada por el cliente para reemplazarla por una solución basada en Suse Linux Enterprise Server + Soft (el software .NET funcionaba muy bien de hecho, pero no tenían acceso de bajo nivel suficiente para tunear a Windows server lo suficiente para mejorar su velocidad al nivel de lo que permitió Novell con SLES).

Ejemplo de TCO reducido

Para comprender el caso de uso de software opensource y/o semipropietario en reemplazo de soluciones de software propietarias complejas, la condición básica es entender y medir objetivamente el TCO (Costo Total de Propiedad), de modo abarcativo, sin dejar de contabilizar costos ocultos y/ indirectos.

Por ejemplo el análisis - MUY básico - del TCO que ahorra Facebook (Fbk), al no usar bases de datos propietarias (utiliza Mysql), es muy simple: Fbk tiene centenares de miles de servers de base de datos corriendo a costo de licencia cero.

Dado el tipo de uso de esas bases de datos (en cluster, usando la máxima cantidad de conexiones y usuarios soportada por el hardware, etc.), es de esperar que si usaran una base de datos propietaria el costo de licencia individual por server supere fácilmente un precio de varios miles de doláres en licencia, ello multiplicado por la cantidad de servers, lo que nos recuerda el cálculo de Marc (cobrar 20 millones, pagar 5 millones en licencias).

En ese ejemplo el TCO implica contabilizar el trabajo de ingeniería en el montaje, adaptación y customización de la base de datos (Mysql), que naturalmente será alto, sin embargo ese costo, sumado a otros costos adiciones no tradicionales (sueldos del personal altamente capacitado necesario por ej.), es de hecho, considerablemente mucho menor que el TCO final hipotetico que resultaría de pagar licencias para un par de centenares de miles de servers de bases de datos.

Conclusiones
La tendencia indica que el uso de soluciones propietarias complejas seguirá teniendo un nicho de mercado y ello es razonable, debido a requerimientos legacy y pre-inversiones diversas (vigencia de años de licencias ya compradas, software basado soft propietario complejas, etc.), de hecho es perfectamente recomendable continuar con ese tipo de soluciones a corto y a mediano plazo inclusive, hasta que el TCO (Costo Total de Propiedad), para cada caso particular se incline completamente a favor de las soluciones opensource y/o semipropietarias (como se dió en el caso de la bolsa de Londres).

Es sumamente importante comprender que las soluciones opensource no son ni serán aplicables del mismo modo que las soluciones propietarias complejas. Por lo gral. implican grandes compromisos más allá del usual "llave en mano", sin embargo el potencial es bajar el TCO de sobremanera a mediano plazo, y a números casi risibles (70-80% tal vez?), a largo plazo.

De momento, se sigue vendiendo mucho software complejo aún, ello no quita que sea un mercado en obvio declive.

Links:

Marc Andreessen: The "Clock Is Ticking" On Oracle

Las startups de Marc Andreessen

Linux potencia las bolsas de comercio más rápidas

50 Places Linux is Running That You Might Not Expect

London Stock Exchange in historic Linux go-live

Mitos sobre la capacitacion

2011-09-20T16:29:00.000-07:00

Encontré este artículo buscando otra cosa, lo que sigue es un extracto del texto, básicamente lo armé para archivarlo en el blog para futuras consultas.

Tuve la idea de archivarlo porque como todos he reflexionado alguna vez cuando alguna persona mencionaba en voz alta alguno de los mitos e instintivamente me parecía que estaba equivocada, pero no tenía "a mano" una explicación simple y directa de por qué.

El texto está copy-paste (extractos), tal cual estaba en el original, todos los créditos son del posteador original, Juan Carlos Valda y del autor Ing. César Díaz Guevara.

El original completo aquí:

"Mitos sobre la capacitacion"
http://jcvalda.wordpress.com/2009/06/03/mitos-sobre-la-capacitacion/

Mitos:

1. Si les capacito se me van a la competencia..
2. Nuestro personal tiene experiencia, no necesita ser entrenado.
3. En una ocasión invertimos en capacitación y NO FUNCIONO.
4. No tenemos presupuesto para capacitación.
5. No tenemos tiempo, estamos muy ocupados trabajando.
6. Nuestra empresa es muy pequeña
7. Nuestra apolítica es contratar personal que ya venga con la competencia necesaria

1)
“No vale capacitarlos, ya que se me van a la competencia”, > deberíamos preguntarnos “Qué pasa si no les capacito y se quedan trabajando para mi empresa?"

2)
“Nuestra gente no necesita capacitarse. Ellos tienen mucha experiencia, son profesionales”. Es importante recordar la gran diferencia que existe entre tener experiencia y ser competente.

Imaginémonos a un entrenador de un equipo profesional de fútbol que dijera:

“Como todos ustedes son profesionales y tienen mucha experiencia se cancelarán los entrenamientos, son muy caros y quitan mucho tiempo. Aquí tienen el calendario de juegos, nos vemos en nuestro estadio una hora antes del partido”. ¿Cómo sería la actuación de esos jugadores ante el equipo contrario?, ¿Cuánto tiempo duraría ese entrenador en su puesto?"

3)
La capacitación no es un evento es un proceso, para que sea efectiva debe ser continua y finalmente lo fundamental, para que la capacitación sea eficaz se debe dar oportunidad a que el personal practique lo que aprendió…. “capacitación sin acción es un desperdicio!!

4)
Esto es una falacia. Si realmente creemos que la capacitación es cara debemos calcular el costo de la incompetencia.

5)
“No tenemos tiempo” no es sólo una falacia sino un engaño a nosotros mismos. Cuántas veces hemos dicho ¿Por qué nunca se tiene tiempo para hacer las cosas bien y siempre hay tiempo para corregirlas?

Aquellos ejecutivos que dicen “estamos muy ocupados no tenemos tiempo para capacitarnos”, nos recuerdan al leñador que por estar cortando árboles no tenía tiempo para afilar su hacha.

6)
Si a manera de ejemplo pensamos en una empresa de cien personas y una de ellas no está suficientemente bien capacitada la productividad puede disminuir ya que un equipo avanza tan rápido como su eslabón más lento. En una empresa o departamento de cinco personas, si una persona no está lo suficientemente bien capacitada ¿Cuántos recursos se están desperdiciando?.

7)
“Nuestra política es contratar personal capacitado” , lo que puede ocurrir es que tienen experiencia y capacitación en “otras realidades”, pero no conocen a la empresa, ni sus procesos, ni su cultura.

La pregunta final… ¿Durante cuánto tiempo me debo capacitar?
La única manera de mantener nuestra mente joven es mantenernos aprendiendo permanentemente!!

Autorecuperación de caídas de servicios

2011-09-18T19:59:00.000-07:00

Administrar bien y administrar mejor

La administración de sistemas puede hacerse de dos maneras: bien o mejor.

Administrar bien implica que las cosas van a funcionar del modo esperado, las tareas típicas se van a realizar y concluir efectivamente. Este es el modo estándar en que debe funcionar la administración.

Administrar mejor consiste en tomar la tecnología existente y hacerla funcionar mejor de lo que usualmente lo haría. Es por lo que se paga un extra, el motivo para contratar administradores más experimentados, el motivo por el que los buenos administradores - y los novatos con buenas perspectivas de mejorar - no dejan de leer y aprender nuevas maneras de hacer mejor las cosas.

Estuve leyendo un artículo en Slashdot, escrito por un sysadmin de Facebook donde cuenta acerca de un software inhouse, encargado de restaurar funcionalidad a servidores automáticamente, que se puso en producción en muchos servers de Facebook.

La entrada de Slashdot es un comentario sobre el artículo original, que básicamente cuenta muy poco del software inhouse, más que nada detalles de diseño. Sí menciona a los Event Handlers de Nagios como origen del actual sistema (no especifica realmente si se sigue usando Nagios, pero no se lo niega tampoco).

Eventos Recurrentes

Luego de pasar "un tiempo" con cierta infraestructura, uno descubre problemas recurrentes que no tienen solución definitiva posible (incluso habiendo sido apropiadamente tratados mediante root cause analysis). Estos problemas a veces son simples de resolver con pocos comandos o secuencias de comandos, con pocas variantes, fácilmente identificables. A veces ocurre el problema, y el sysadmin ya tiene el diagnóstico totalmente hecho en su cabeza, incluídos los comandos y acciones necesarios para remediar el downtime.

Es una circunstancia tan común en administración de sistemas que en Nagios se desarrolló una funcionalidad específica para atender proactivamente este tipo salidas de servicios (outages), los Event Handlers.

Event Handlers de Nagios

Los Event Handlers de Nagios son un ejemplo de administrar "mejor".

Usar bien esta funcionalidad de Nagios es un clásico ejemplo del monitoreo bien hecho: que debería tender a no solo a "Prevenir,Informar,Registrar" sino también a "Resolver". Una "marca registrada" de muy buena administración (y escasos downtimes por causas fáciles y rápidas de resolver).

Típicamente la tercer o cuarta fase de implementación de un sistema de monitoreo consiste en identificar esos puntos de fallo para utilizar características de recuperación automáticas disponibles en el software de monitoreo utilizado (casi siempre hay alguna).

Los Event Handlers son tremendamente capaces de hacerse cargo de recuperaciones automáticas. De hecho, el uso habitual de los Event Handlers es - dadas ciertas circunstancias - correr automáticamente los primeros comandos que correría un sysadmin en las primeras fases del troubleshooting de recuperación, de modo de acelerar la tarea de restauración de los servicios, incluso si los handlers no pudieran recuperar efectivamente la caída.

Implementar los Event Handlers es trivial, lo más difícil en realidad es detectar los patrones de caídas típicos más complejos y/o construir scripting de autodiagnóstico y remediación más efectivos (lo que implementó el sysadmin de Facebook).

Para empezar, al final tienen un par de tutoriales muy buenos.

Es la mejor manera? Sí y no.

Mirando los comentarios de Slashdot veo en una segunda mirada al tema, está bien, el approach de "levantar lo que se cae" o "arreglar EL servidor" parece un poco primitivo al lado de las arquitecturas de redundancia masiva como la de Google, donde no importa si se pierde un servidor o 50 servidores, ya que la infraestructura sigue operando sin registrar downtime alguno.

En la realidad del sysadmin promedio e incluyendo a muy buenas y caras infraestructuras, muchos servicios no están montados con redundancia masiva, inclusive, no sería viable reimplementarlos de ese modo (inviabilidad no técnica casi siempre, pero inviabilidad al fin), lo que hace - todavía al menos - necesario este tipo de mecanismos de autorecuperación muy relevantes.

Links:

Making Facebook Self-Healing

http://it.slashdot.org/story/11/09/18/0246229/Making-Facebook-Self-Healing

Troubleshooting Intermittent Problems

Usar el event handler de Nagios para recuperar servicios

Event Handlers

Motivos de la baja adopción de Linux en Ctes. (1ra. Parte)

2011-09-08T11:19:00.000-07:00

Primera parte :

La falacia de la falta de soporte para Linux en Corrientes.

Ya leí bastantes artículos de "20 años de Linux" y me preguntaba qué podría escribir al respecto que estuviera relacionado con el ámbito IT de la pcia. de Corrientes (Arg.), que conocía hasta hace poco y de inmediato pensé, "perooo - así con varias Ooos - Linux se usa poco en Ctes. en infraestructuras, ¿por qué?"

Ahí vamos.

La opinión que más escuché sobre la baja adopción de Linux en Ctes dice algo así:

"Linux como sistema operativo de nivel industrial todavía es "amateur", anda bien, pero todavía le falta, lo que se instala para "comenzar" y antes de "ponerse serios" y migrar a plataformas Windows o UNIX."

Conversando con un amigo le comenté de este artículo en preparación y me resumió el - verdadero - motivo por el que Linux no es popular en Ctes. a nivel profesional:

En Ctes. típicamente no se elige a Linux porque "no tiene soporte", lo que se refiere al soporte local, en la ciudad y otras plataformas sí tendrían soporte "en la ciudad". En la práctica, la debida diligencia se acostumbra a delegar hacia terceros, así la "culpa" si algo anda mal, es de otro. Si se usa Linux y aplicaciones opensource, la debida diligencia permanece en la gente de IT local (sysadmin, manager, etc.), y la "culpa" de algo que no ande bien es "de la gente de acá" (más allá de que pueda ser un bug, un problema de redes, o algo que no tiene nada ver con Linux/aplicaciones, etc.).

Por ese motivo socio-organizacional (que no suele ser culpa del admin, ni del Jefe en gral. repito, ya que trabajan "ahí" nada más, no delinean pautas organizacionales), es que con la pobre situación económica de Ctes. y de la mayoría de las organizaciones (empresas y estado), que justificaría minimizar costos (TCO), al máximo, en vez de fomentarse el uso, implementación, capacitación en Linux y aplicaciones opensource, se da al contrario.

La falacia

Si lo piensan bien, no hay motivo real en la falta de soporte "local", aunque de hecho casi no hay soporte para Linux local (acá me podrían ayudar y corregir si alguien brinda soporte por contrato/SLA para Linux en Ctes.), ya que el grueso de las aplicaciones IT de nivel industrial implementadas en infraestructuras en Ctes. no tienen soporte "local", sino en consultoras de Bs.As., que son resellers/representantes de terceros owners del software y/o harware (va desde soft de antivirus en adelante). También suele haber un representante local, que es el reseller del reseller/representante del producto en Bs.As.

Es decir, en la realidad práctica habitual, la mayoría de las organizaciones IT se maneja en soporte por contratos con proveedores locales que en realidad recurren a un soporte a no menos de 1000 km., (que levante la mano quien no escuchó de un reseller "dame 24 hs. para contactar al representante en Bs.As.".).

Por supuesto, no hay nada de "malo" en esto, es parte de la realidad IT correntina actual. Al contrario es altamente positivo que las cosas se hagan sobre "papeles" y que haya soporte local, representando a terceros, es muy positivo (empleos y locales! impuestos! > pcia. ,etc).

El punto es que el soporte de alto nivel reside en Bs.As. y ello suele durar un par de años hasta que una tecnología se "populariza" en Ctes., entonces los resellers de Ctes. van certificando en el producto a sus empleados, y - si hay presupuesto - hay training, sino cursos oficiales + certificaciones para los empleados de los clientes (los sysadmins en este caso).

Por lo que entiendo, se puede contratar soporte para Linux en Bs.As., Córdoba, Santa Fe, Resistencia (Chaco). Si alguien necesita soporte para Linux en Ctes. probablemente acercándose a conversar con empresas locales, es bastante probable que muchas estén dispuestas a comprometerse por contrato localmente (algo necesario en licitaciones), y realizar el "salto" al soporte en Bs.As. a otro reseller o a los representantes oficiales de una distribución industrial (Red Hat, Suse, Oracle Unbreakable Linux - que es RHEL con soporte de Oracle, etc.). Al cabo de un tiempo, el ciclo descrito arriba comenzaría y luego ya habría soporte local de alto nivel en Ctes.

En otras palabras, más allá de la circunstancia socio-organizacional de querer delegar la responsabilidad IT (y supuestamente no poder hacerlo con Linux), hay más cosas frenan la adopción de Linux en Ctes.

Luego sigo con la 2da. parte.

Opiniones, correcciones, críticas (constructivas, mejor), bienvenidas.

Links:
http://es.wikipedia.org/wiki/Falacia
http://en.wikipedia.org/wiki/Due_diligence

Nuevas posibilidades en arquitecturas virtuales con VMware VSA

2011-08-28T18:14:00.000-07:00

La versión 5 de VMWare vSphere ha incorporado una nueva característica que habilitará la entrada de vSphere en muchos SMB (Small and Mid-size Business), o PyMEs.

VSA (vSphere Storage Appliance) es un (free) appliance de VMware que puede ser instalado en servers ESXi y permite utilizar el espacio local disponible en esos servers en un storage virtual que puede ser utilizado desde otros nodos ESXi como si fuera una SAN/NAS típica (los volúmenes de VSA se publican como datastores NFS) y ello integrado en vSphere.

El problema del paso intermedio en la adopción de una arquitectura virtual VMware vSphere.

Hasta ahora, al iniciar la adopción de Vmware para una infraestructura virtual, el primer paso era instalar servidores ESXi individuales (disponible como freeware, a costo cero de licencias), para luego adquirir una licencia para integrar esos servidores ESXi en una infra vSphere.

El problema que se daba es que entre las características más furiosamente recomendables y usables de vSphere, practicamente toda la justificación técnica y operativa en la adquisición de la licencia, se encuentran características usables - hasta ahora - únicamente disponiendo de storages físicos como los que brinda una SAN.

Por lo anterior, un paso casi ineludible entre la adopción de hosts ESXi y el salto a una infraestructura vSphere completa era la adquisición forzosa de hardware de storage, sumando el costo de esto - típicamente - al costo de la licencia vSphere, incrementando el costo inicial en demasía.

Como ven, VSA elimina completamente el problema anterior, y crea una instancia intermedia entre los hosts ESXi individuales y una infraestructura vSphere integrada con un storage físico.

Veamos las posibilidades que brinda VSA ahora en el diseño de arquitecturas virtuales:

En la práctica hace que los potenciales usuarios de vSphere que no tienen una SAN, ahora:

- Pueden utilizar servers que ya poseen para montar una "SAN" virtual,

- Tener buen nivel de redundancia (hay un mínimo de 2 nodos necesarios, y con RAID10+8 discos mínimo en cada server debería ser suficiente salvaguarda ante fallas de discos).

- (Esta es la más importante desde el punto de vista técnico) Usar características de vSphere solo disponibles al usar una SAN: vSphere HA, vMotion, y DRS.

- Tener las siguientes ventajas, las más importantes desde el punto de vista de la PyME:

* Minimizar costos CAPEX, al no tener que adquirir una SAN

* Minimizar costos OPEX en requerimientos para los administradores en:

- Configuración: ya que los clusters VSA se integran automáticamente en la infraestructura de vSphere (y ello incluye la automatización suficiente para autoconfigurar la replicación del cluster VSA).

- Administración: ya que VSA se administra completamente desde una GUI "VSA Manager" integrada en el VMware Vcenter (se instala un plugin en el Vcenter server).

- (MUY importante también) Administración: los administradores no requerirán alto nivel de conocimiento en administración de storage / SANs. Es importante, porque no solamente implica el skillset de storage administration, sino también el gasto adicional en horas/hombre requirido para administrar la SAN.

Limitaciones y workarounds:

- Se puede usar un solo cluster VSA por server Vcenter.

Lo ideal es tener un cluster de 3 servers con un muy buen storage local cada uno. De cualquier manera un buen server con 7 a 10 bahías con capacidad para discos de 1-2 TB (en servers "viejos", suele bastar un upgrade de firmware para soportar discos de mayor capacidad), puede funcionar muy bien para el cluster VSA. Recordemos aquí tener un buen RAID (10, 6 mínimamente) para tener buena salvaguarda a nivel de arreglo de discos.

- El máximo nro. de servers por cluster VSA es 3, así que para poder usar más clusters VSA hace falta tener más licencias de vSphere disponibles. En este punto, si se llegara a esto, ya se podría evaluar optar entre adquirir una licencia adicional vSphere y/o directamente invertir en storages físicos, como algún storage iscsi relativamente barato por ejemplo.

Links:

OPEX

http://es.wikipedia.org/wiki/Opex

CAPEX

http://es.wikipedia.org/wiki/Capex

"vSphere Storage Appliance (VSA) - Introduction"

http://blogs.vmware.com/vsphere/2011/08/new-enhanced-vsphere-50-storage-features-part-4-vsphere-storage-appliance.html

El whitepaper mandatorio:

http://www.vmware.com/files/pdf/techpaper/VMware-vSphere-Storage-Appliance-Technical-Whitepaper.pdf

Audio en salida HDMI en Linux

2011-05-25T14:13:00.000-07:00

En la red (foros, blogs), vi mucho revuelo con este tema del audio por HDMI en Linux.

Usando Fedora 14/15, en mi caso fue simple, sin modificar archivos de configuración, ni escribir ningun archivo de ninguna clase.

1) Conecto el cable HDMI a la notebook, configuro la salida en KDE4.6z desde Krandrtray o Preferencias del Sistema > Pantalla y Monitor > Tamaño y Orientación (ahí van a ver opciones, deberían usar HDMI).

2) Abriendo SMplayer, Opciones > Preferencias > General > Solapa "Audio" > Output Driver >

Acá tengo a la vista 3 opciones Alsa, en la primera tengo salida normal (speakers y auriculares, cuando se conectan a la salida de audio), además tengo:

Alsa (0.0 - HD Intel)

Alsa (0.3 - HD Intel)

Eligiendo la opción "0.0", tengo salida de audio por HDMI (y el volumen se controla desde la tv).

Si no saben bien cual podría ser su salida de audio para HDMI:

[yaco@pc ~]# aplay -l

**** List of PLAYBACK Hardware Devices ****

card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog]

Subdevices: 1/1

Subdevice #0: subdevice #0

card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0]

Subdevices: 1/1

Subdevice #0: subdevice #0

Sldos.

Upgrade a Fedora 15

2011-05-25T13:03:00.000-07:00

Bueno, mucho que decir, hice el upgrade a Fedora 15 desde el 14. Resulta que Fedora tiene dos métodos de upgrade:

- vía yum:

rpm --import https://fedoraproject.org/static/069C8460.txt

yum update yum

yum clean all

yum --releasever=15 --disableplugin=presto distro-sync

Documentación:

http://fedoraproject.org/wiki/YumUpgradeFaq

- vía preupgrade

Documentación:

http://fedoraproject.org/wiki/PreUpgrade

El método recomendado es "preupgrade", pero yum funcionó bien en mis testeos con máquinas virtuales.

Preupgrade es sorprendente como método de upgrade. Tenemos dos opciones, interfaz gráfica en X o interfaz modo texto en consola. Básicamente ejecutamos el programa, seguimos los pasos y empieza a descargar los paquetes que haga falta para actualizar la distro, al terminar nos va a avisar y al reiniciar entramos automáticamente en el modo de upgrade, "siguiente-siguiente" y luego un instalador Anaconda completamente booteado (el mismo que se usaría si descargamos un CD/DVD de upgrade), ejecuta el upgrade.

Lo diferente con respecto a bajar el CD/DVD y a utilizar yum es que si cerramos el programa (el de X o el de consola), al volver a ejecutarlo, el upgrade continuará desde el punto en que hubiera quedado. En la práctica el programa va a continuar bajando los paquetes que faltaban de la lista (sin tener que iniciar de vuelta la bajada). Cerré 4 veces el programa durante el upgrade, por diferentes motivos, y funcionó muy bien.

La performance?, el upgrade con preupgrade tardó bastante luego de rebootear (una hora para upgredear 1.01 GB de paquetes), lo bueno es que si en cualquier momento durante la bajada de paquetes decidía suspender el upgrade, podía hacerlo sin problemas.

Tiendo a pensar que el upgrade vía yum directo puede ser más rápido, pero puede ser el efecto de tener el sistema en uso hasta último momento antes de reiniciar y que al reiniciar ya están todos los paquetes instalados.

Al terminar el upgrade el sistema funcionó perfectamente y fui directo a bajar el driver STA Broadcom para compilarlo para el kernel de F15, ya que todavía no hay un paquete .rpm, me costó unos 15 minutos en total (incluyendo la bajada de kernel-dev, gcc, kernel-headers y el .tar.gz del driver).

Procedimiento:

Es una integración del howto de abajo con un par de cosas tomadas del muy buen README de Broadcom (hay procedimientos para Ubuntu ahí).

Documentación:

http://www.broadcom.com/docs/linux_sta/README.txt

http://djkaos.wordpress.com/2008/10/25/installing-broadcom-80211-linux-sta-driver/

1) Dependiendo de tu sistema, elegir paquetes de 32 o 64 bits

http://www.broadcom.com/support/802.11/linux_sta.php

2) Ir a una terminal donde bajaste el paquete.

tar -xvzf hybrid-portsrc-.tar.gz

3) Bajar y aplicar el parche para kernels mayores a 2.6.37:

http://www.broadcom.com/docs/linux_sta/5_100_82_38.patch

patch -p0 < 5_100_82_38.patch

4) Instalar kernel headers y entorno de compilación

yum install kernel-dev kernel-headers gcc

5) make -C /lib/modules/`uname -r`/build M=`pwd`

Si no hubieron errores, probar así:

6) Descargar módulos (o drivers) conflictivos de memoria:

Mirando los módulos conflictivos:

# lsmod | grep "b43\|ssb\|wl"

Para removerlos

# rmmod b43

# rmmod ssb

# rmmod wl

Para ponerlos en la blacklist y prevenir que se carguen en el futuro:

# echo "blacklist ssb" >> /etc/modprobe.d/blacklist.conf

# echo "blacklist b43" >> /etc/modprobe.d/blacklist.conf

7) Insmod para cargar el driver:

(si es que no instalaste un driver wl previamente, necesitás cargar un módulo de seguridad antes de cargar el driver wl, muchos sistemas nuevos usan lib80211 y otros ieee80211_crypt_tkip. Fijáte cual funciona en tu sistema.)

# modprobe lib80211

# modprobe ieee80211_crypt_tkip

Luego:

# insmod wl.ko

8) Seguir estos pasos para cargar el driver en el proceso de booteo:

# cp wl.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless

# depmod -a

# echo modeprobe wl >> /etc/rc.local (Fedora/SUSE)

Listo

Luego de la carga del driver (el insmod), NetworkManager en KDE4.6 inmediatamente tomó la wifi local y se logueó sin problemas.

Después me puse a mirar un poco Gnome 3 en directo (por fin), y a jugar con systemd que tiene un poco de documentación como pueden ver:

http://0pointer.de/blog/projects/systemd-docs.html

Sobre systemd se puede escribir muchísimo, es bastante nuevo, pero tiene todas las cartas para ser la siguiente evolución de sistemas de arranque, haciendo una salto y mejora radical de lo mejor que había hasta el momento, Upstart (introducido por Ubuntu). Hay varios puntos a revisar y hay una chance que systemd no llegue a convertirse en el manejador "del futuro", por varias razones técnicas bastante complicadas de explicar en pocas palabras, pero si se maneja bien el desarrollo, la arquitectura de la solución es impecable, veremos si la implementación está a la altura.

Para más datos, ver los comentarios y explicaciones (extensísimos y detallados):

http://0pointer.de/blog/projects/systemd.html

http://0pointer.de/blog/projects/systemd-update.html

http://0pointer.de/blog/projects/systemd-update-2.html

Sigo usando Fedora ahora,

sldos.

yaco

Mi metodología de troubleshooting para infraestructura

2011-03-14T19:15:00.000-07:00

Cómo hacer troubleshooting en infraestructura (imho, casi un source code de troubleshooteo para administración de sistemas).

Puede haber y debería haber mejores métodos, por eso todo el tiempo estoy buscando optimizarlo (así que las críticas son más que bienvenidas).

Hay dos partes en mi metodología de troubleshooting habitual,

- la parte lógica, cómo pensamos el problema y

- la parte práctica, cómo implementamos lo que hay que hacer para avanzar en la solución.

Escenario

Con un ejemplo es más fácil: tenemos que copiar archivos entre dos servers, usamos rsync directamente (no el modo daemon), le damos enter y no anda > acá comienza el troubleshooting.

El comando rsync para los ejemplos de "no funciona".

$ rsync -avz /home/ahornero/ alberto@192.168.1.30:/home/alberto/

[ en realidad el comando está perfecto, pero vamos a hacer de cuenta que tiene algun problema que le impide ejecutarse correctamente]

Parte lógica

Esto es lo fácil. "Todos" los sistemas funcionan igual: tienen - básicamente - tres etapas

- input (datos de entrada),

- procesamiento (se procesa el input),

- (y luego dan un) output (datos de salida).

Los problemas pueden estar en cualquiera de esas 3 etapas, se ubican casi siempre en las dos primeras, pero *no hay que olvidar chequear la 3ra. (nunca).

* Que un problema se solucione, no implica nada más, puede haber otros problemas, relacionados o no con el anterior.

Ejemplos de algunos problemas posibles por etapa:

1) Input: rsync "no actualiza" porque no hay datos nuevos para sincronizar.

2) Procesamiento: rsync "no actualiza" porque el comando está mal ( o el archivo de configuración en el modo daemon), apunta a una ip erronea, no a la correcta.

3) Output: rsync "no actualiza" porque los datos supuestamente nuevos ya fueron copiados antes (en un comando previo por ej.), el output no estaba mal, nos estabamos confundiendo nomás.

Parte práctica

Esta es la difícil. Acá le ponemos "nombre y apellido" al input, procesamiento y output, luego empezamos a "trastear" con cada una de ellas.

Tenemos que identificar efectivamente qué constituye en el sistema cada una de esas etapas. Luego de identificarlas, hay que checkear la integridad de cada una, es decir comparar el estado esperado en un comportamiento normal con el estado que obtenemos nosotros en nuestro sistema con fallas.

* Sistema modelo: Acá nos puede servir muchísimo tener un sistema "modelo" que funcione bien, para compararlo con el que anda mal (comentario: los artículos de Internet pueden tener errores, doble-chequeen si ven algo "raro" en una sintaxis o en una implementación).

* Documentación: En este punto es donde solemos repasar:

- la documentación de arquitectura de un sistema (como está pensado que funcione), y

- la documentación de configuración (como se instala y configura), y

- la documentación de implementación (como lo instalaron y configuraron en la práctica).

- Cualquier fallo o debilidad en la documentación necesaria (los 3 tipos), nos va a traer (más) problemas, sepanlo desde el vamos.

- De hecho, un método práctico para convertir un alto nivel de skillset de un sysadmin experimentado en nada, es no tener documentación adecuada para troubleshooting. Para un novato, la ausencia de documentación debería ranquear entre los primeros lugares de lo peor que le puede pasar como sysadmin, sepanlo para preparar las (contra) medidas necesarias.

* KISS: esta filosofía, KISS (Keep It Simple Stupid, Mantenlo Fácil, Estúpido), de los sysadmin está fuertemente orientada al troubleshooting rápido, por ello las soluciones más genéricas y obvias posibles son las mejores. Cualquier customización innecesaria en la implementación introduce nuevas variables a analizar y, en consecuencia, nuevos puntos de fallo.

Ejemplo: en el comando rsync de antes, una customización es la ip y si estuviera mal, el comando no funcionaría.

Ejemplo de la parte práctica:

En el comando rsync de arriba, repasamos el cómo debería funcionar exactamente rsync (arquitectura), y luego vemos cómo debería estar escrito (configuración), y finalmente chequeamos cómo está escrito el comando (implementación).

Ejemplo del ejemplo: si hay un error de sintaxis, acá debería aparecer, claro como agua mineral.

Luego de este paso, ya deberíamos tener a la vista nueva información de utilidad para solucionar el problema.

La 4ta. etapa: el "medio"

* Ahora subimos la dificultad 1 (un) nivel.

A veces en el tránsito de una etapa a otra, de input a procesamiento y de ahí a output, y luego del output en sí (hasta justo antes del resultado normal esperado del sistema), puede haber problemas (también). En otras palabras, hay que agregar una etapa de chequeo al troubleshooting, el medio:

4) El "medio" por donde se transcurre de un estado al otro puede estar mal.

Ejemplo 1: rsync "no actualiza" porque el disco donde intenta escribir está lleno y no puede volcar correctamente su "output".

"Medio" no es la red siempre (como ven en el ejemplo), pero en procesos distribuídos y remotos, sí puede serlo, aparte de otros "medios".

Ejemplo 2: rsync "no actualiza" porque el puerto de red donde intenta establecer la conexión está firewalled en la red.

"Medio" es un también sinónimo de "ambiente", environment en inglés, si todo el sistema (el comando rsync en este caso), no funciona y las 3 primeras etapas están bien, puede haber un fallo en el ambiente donde corre el sistema.

Ejemplo 3: Cuando rsync no está instalado, cuando no figura en el $PATH del usuario o,

Ejemplo 3 más difícil: si solo se puede correr usando sudo (deberíamos haberlo detectado cuando leímos la documentación de implementación de hecho, ya que en este caso no sería un modo estándar de correr rsync, por lo que habría que probar primero si el "ambiente" funciona bien).

* Trágicamente, la etapa 4) consiste en realidad tres chequeos distintos adicionales, ya que estamos viendolo para las 3 primeras etapas del troubleshooting y llegamos a un total final de 6 chequeos a realizar.

Problemas del problema

Cómo se ve, en algun punto vamos a resolver las 3 etapas iniciales, input, procesamiento y output, y luego pasaremos a analizar la 4 etapa.

Se ve que puede haber fallos que tienen mucha (muchísima) interacción con software y sistemas fuera del que está fallando en sí (gracias etapa 4), y es por eso que un sysadmin debe tener un buen nivel de insight / conocimiento / información de tanto software / sistema como le sea posible.

Algun nuevo fallo recien detectado puede directamente sacarnos del troubleshooting de fallo del sistema que ya estamos analizando y llevarnos a un nuevo proceso de troubleshooting, ubicado en un sistema relacionado con el anterior y requisito necesario para que el primero funcione (gracias etapa 4, siempre nos acordamos de vos).

Ejemplo: si rsync no está instalado, tenemos que instalarlo (hay que aprender a hacerlo); si la instalación falla, hay que ver por qué falló la instalación o; si el puerto donde se conecta rsync está firewalled, tenemos que reconfigurar el firewall (o pedirle al netadmin que lo haga y luego correr diagnósticos para ver que sea así),

Iteración

Esta metodología es eso, un método, y no es una receta porque debe ser utilizada con criterio, es decir, se debe manejar analizando la situación actual y modificando las acciones de acuerdo a ello, como si fuera un automovil, si hay una curva adelante, se baja la velocidad, se ve la dificultad de la curva, se suspenden otras acciones temporalmente (no tratamos de adelantarnos), etc.

La iteración se va a dar cuando haya varios problemas, paralelos o anidados, y tengamos que ir resolviéndolos.

La habilidad y la experiencia (skillset & expertise), dan ventaja para acelerar el avance hacia la solución, principalmente porque un sysadmin experimentado descarta rápidamente los problemas posibles pero sumamente improbables (y guarda un registro de qué fue lo que obvió, para volver sobre sus pasos si fuera necesario).

Un sysadmin sin los beneficios anteriores puede igualmente tener excelente performance en un troubleshooting, simplemente prestando atención a cuando un proceso de troubleshooting deriva hacia otro nuevo proceso y por qué (así podrá retomar el troubleshooting inicial cuando solucione el problema derivado).

Links:

http://es.wikipedia.org/wiki/Rsync

(al final de la página tiene una linda lista de links con documentación)

Rsync. Ejemplos

(de ahí saqué el comando)

Conociendo servidores virtuales privados

2011-02-23T11:49:00.000-08:00

Ya un poco colapsado de gripe y de temas no técnicos, propongo dos lecturas que estoy haciendo al momento.

The ABCs of virtual private servers, Part 1: Why go virtual?

The ABCs of virtual private servers, Part 2: Getting started

Vieron cuando sale la conversación sobre servidores en la nube, suelo decir "habría que ver precios, prestaciones, detalles así, para comparar con lo que hay que no está en clouds"

Bueno, esta serie de artículos de Arstechnica hace un insight total a servidores virtuales en la nube, con - probablemente - la mayoría de los datos que hacen falta para pre-evaluar objetivamente VPS.

Digo pre-evaluar porque una evaluación real, se sabe, ya involucraría tener los requerimientos (totales: técnicos, económicos, organizacionales, etc.), concretos y "bajar" a leer las "letras chicas" de lo que brinda o no cada servicio (y va más allá de lo técnico esto), y ver si matchea con los requerimientos.

Límites

Los VPS, IMHO, tienen un límite práctico: la privacidad forzada de los datos en los servers. Es decir, hay variada legislación por país y variada reglamentación interna por organización, que obliga y fuerza a mantener el control de los datos almacenados en los servidores, so pena de X sanción a quien no lo haga.

Volcar datos privados a VPS sería imposible, por ejemplo, para las bases de datos de bancos (en Arg. están regulados por la normativa BCRA "A" 4609) o ciertos sistemas de las empresas de tarjetas de crédito (que deben en gral. estar dispuestos de acuerdo a PCI DSS).

Nuevas capacidades

Hay casos puntuales en que los VPS brindan capacidades inexistentes hasta ahora y a precios también inexistentes hasta ahora (+barato, sin contratos draconianos, etc.).

Por ejemplo, en caso de la reciente caída de servicio de Skype, se supone - no está aclarado explícitamente, pero dicen "instancias" así que... - que los ingenieros de la empresa dispusieron durante el troubleshooting, la creación (clonación) de cientos de servers - virtuales - en alguna cloud (por las prestaciones necesarias Amazon es el candidato top), para ayudar a absorber el overflow de tráfico en la infraestructura de Skype ocasionado por la caída en cascada de los servers originales de su red de soporte para el servicio.

"..In order to restore Skype functionality, the Skype engineering and operations team introduced hundreds of instances of the Skype software into the P2P network to act as dedicated supernodes.."

CIO update: Post-mortem on the Skype outage

Sigo leyendo ahora..

Links:

Análisis de la Norma BCRA “A” 4609

PCI-DSS

Que les sea util.

Organización de equipos IT, "manufacturera" vs. "cinematográficos"

2011-02-21T14:46:00.000-08:00

Update 1: El tema se siguió/sigue hablando en Comunidad TIC:

http://groups.google.com/group/comunidadit/t/82055469ee43f56

Encontré un artículo recien en Barrapunto.com,

"¿Por qué los managers y analistas ganan más que los programadores?"

del blog http://hackerdou.com.

Que es una traducción del original en StackExchange:

Why do business analysts and project managers get higher salaries than programmers?

El artículo trata acerca de 2 modos de organización de equipos de programadores, bastante comunes de encontrar hoy, inclusive más, estos modos también se utilizan ampliamente en equipos de infraestructura.

Creo que lo que puede servir de razón principal para leer el artículo y aprender (bastante), sobre organización de equipos IT es la frase final:

"Las empresas de software exitosas tienden a adoptar el punto de vista de los equipos cinematográficos. Otra filosofía no les permitiría atraer a las personas talentosas en las que se basan para producir buen software."

Resumo alguna ideas del artículo, interesantes:

- En proyectos internos y de consultoría con modelo manufacturera, managers y analistas son mejor pagados, porque se considera que ellos aportan el mayor valor.

- En el modo manufacturera, el management restringe el acceso a la información, sin acceso a ella el equipo no trabaja al máximo. Los programadores son relegados solo a tomar órdenes y esto crea la idea solo pueden hacer tareas "a dedo" y mecánicas.

- En el modo equipo cinematográfico: "Cada persona importa ya que el director cree que el software resulta de la combinación de las habilidades de todos"

-En el modo equipo cinematográfico: "Todo mundo reconoce desde el principio la importancia de que “estrellas” se unan al equipo. Los trabajadores “estrella” incrementan las posibilidades de éxito."

Solo me queda agregar al excelente artículo que en el modo "manufacturera" cuando el Manager/Project Manager/Jefe del equipo en gral., no toma buenas decisiones, sin importar el nivel individual de conocimientos ni la suma de grandes talentos individuales, el equipo se va a pique rápidamente en resultados y al poco tiempo se desarma (los "talentos" buscan y encuentran mejores equipos rápidamente).

Teoría X e Y

El artículo menciona la Teoría X e Y,

y leyendo un poco vemos que la teoría X (que sería en el artículo el modelo manufacturera), viene de los modelos Tailorianos de producción, donde hablamos en el 99% de producción industrial, con muchísimos factores estáticos (fases producción de componentes de tiempo fijo, etc.).

Comparando ambas teorías, entre otras cosas se puede extrapolar que la motivación para trabajar, para no haraganear, para crear, de un obrero industrial del siglo XIX debería ser básicamente mucho más baja que la de un programador bien pagado del siglo XXI..pero no todos se llegan a dar cuenta.

La teoría Y avanza en cambio sobre tópicos del presente, donde es posible crear ambientes de trabajo donde las presunciones sobre psicología industrial que hace la teoría X se vuelven poco relevantes en gral.

Por otra parte la teoría Y permite encarar potencialmente mejor los tipos de industria nuevos, como la industria IT, en equipos de desarrollo, en tareas de implementación de infraestructura, etc. etc. Donde los tiempos de producción y resultados medibles son extremadamente dinámicos y poco responsivos a la rigidez tailoriana y a los modelos de organización industrial tradicionales.

Para aprender a comunicarse mejor

2011-02-06T07:42:00.000-08:00

La necesidad de poseer competencia profesional completa en comunicaciones interpersonales es clave para un profesional de IT, por ello debe aprender a expresarse - muy - correctamente.

Descartando internamente las falacias también se da lugar a patrones de razonamiento válidos y se deja de lado muchos llamados "vicios" en la práctica profesional (válido para programadores, adm. de proyectos, como para gerentes IT).

http://es.wikipedia.org/wiki/Falacia

"..un patrón de razonamiento malo que aparenta ser bueno. Un razonamiento falaz no necesariamente arriba a una conclusión falsa; así como un razonamiento correcto o válido no necesariamente arriba a una conclusión verdadera."

Falacias y errores lógicos

(Explicaciones más cortas y muy buenos ejemplos)

Los costos ocultos de implementar herramientas complejas

2011-01-31T21:31:00.000-08:00

Por qué no deberías integrar una herramienta de complejidad innecesaria en tu infraestructura...

A veces por diferentes motivos y fuera del alcance del entendimiento del nivel de management no IT, se elige una herramienta de complejidad innecesaria para realizar una tarea que no lo requiere.

Dimensionamiento

El dimensionamiento apropiado de los requerimientos presentes y una escalabilidad razonable/realista a futuro es la respuesta para evitar la adquisición de un herramienta exageradamente compleja de implementar y de administrar.

Un ejemplo negativo de esto es cuando se busca la máxima flexibilidad y escalabilidad sin importar que en implementaciones a futuro y en escalas realistas, no se utilizará la herramienta a su máxima capacidad, ni siquiera a mediana capacidad.

El costo de fallar en el dimensionamiento es finalmente, económico.

Costos de personal

La complejidad de la herramienta conlleva adicionalmente altos costos de entrenamiento y altos costos de personal que se encargará de trabajar con él.

Para empezar, el costo se medirá en las horas/hombre utilizadas para el aprendizaje/entrenamiento para implementar y luego administrar la herramienta.

Si la implementación inicial fuere tercerizada (inicial porque la administración resultará finalmente interna en la mayoría de los casos), el costo de implementación de herramientas muy complejas escala alto y mucho más que el costo de implementar herramientas menos complejas.

Gracias a la combinación de los factores anteriores, no existe un gran nro. de profesionales en condiciones de utilizar este software hipotético, y por más bajo que sea el nro. de implementaciones de la herramienta, coincide con números aún más bajos de profesionales entrenados y estos, a mayor demanda, requieren sueldos que trepan muy por arriba del estándar.

Costos/tiempos de entrenamiento e implementación

Existen herramientas complejas en el mercado que muchos administradores experimentados han conocido y utilizado y de las que una apreciación en profundidad de su arquitectura y diseño interno, sumamente complejo y arbitrariamente difícil de implementar y administrar no se condice con las capacidades extendidas que brinda.

Es decir, estamos ante software innecesariamente complejo, probablemente mal diseñado y/o resultado de sucesivas integraciones de productos diferentes con el consiguiente escalamiento exponencial de "dificultades de integración" en lo interno, lo que se refleja en las interfaces de usuario, no poco amigables, sino abiertamente contra-ergonómicas que, claro, resultan en tiempos anormalmente extendidos de entrenamiento e implementación.

Costos de licenciamiento

Un software complejo deriva en - casi obvios - altos costos de desarrollo, mantenimiento y soporte, que resultan en altos costos de licenciamiento del software. Engañosamente, este alto coste de licenciamiento puede confundirse con "mayor inversión", que en teoría "garantiza mayor calidad". Esta cadena de suposiciones puede desmentirse (o no), al conocer el historial de desarrollo de la herramienta, lo que puede investigarse normalmente usando buscadores en Internet.

Conclusión

La conclusión queda abierta porque hay diversos escenarios, pero incluso en los que es rentable/viable el uso de herramientas complejas, se mantienen las variables de:

- alto costo de licenciamiento,

- altos costos de entrenamiento y,

- altos costos en personal

¿Cuales son las ventajas técnicas de una infraestructura virtual en la práctica? (zero sales engineer jargon, please)

2011-01-26T16:43:00.000-08:00

Ultimamente estoy retomando el campo de cloud computing, muy focalizado en cómo montar private clouds.

En la red pueden encontrar buen material descriptivo de qué es una nube privada, incluso hay diversas discusiones sobre si es buena o no, advierto: muy marcadas por los intereses comerciales de quienes opinan. Si tienes tu propia infraestructura a cargo, y ya conoces algo de clouds, de seguro ya habrás visto los beneficios.

Por cierto, exageradamente muchos con respecto a la infraestructura normal, principalmente un cuantioso ahorro económico a mediano plazo, muy por encima de los más salvajes ahorros que pueda mencionar un sales engineer de infraestructura tradicional.

Como algunos de uds. sabrán, hace un año presenté un proyecto completo para montar una private cloud en la infraestructura de un cliente. El proyecto no llegó a implementarse, bah, "todavía", las clouds privadas son tan inevitables como Gigabit ethernet. La frase es "Gigabit Ethernet es el nuevo Fast Ethernet", solamente pregunten cuantos están certificando cableado CAT6...

http://es.wikipedia.org/wiki/Gigabit_Ethernet

http://es.wikipedia.org/wiki/Fast_Ethernet

http://es.wikipedia.org/wiki/Cable_de_categor%C3%ADa_6

Bien, el proyecto servía (sirve), para tomar una infraestructura de servidores con almacenamiento fijo trabajando en el modo tradicional (desperdiciando cuantiosos y costosos recursos mientras que se aproximaban velozmente a diversos puntos de out-of-support y obsolescencia tecnológica), y convertirla en una infraestructura basada en SAN, iSCSI a 1 giga, escalable eventualmente a 10 gigas (invirtiendo en la infraestructura de networking de 10 gigas para la SAN), con una infraestructura de virtualización con administración de recursos (manejador de hypervisores), manejando muchos nodos (antigüamente conocidos como "servidores"), corriendo sobre ellos máquinas virtuales y dentro de las máquinas virtuales, los tradicionales sistemas operativos y aplicaciones.

Por el lado no tradicional, la infraestructura de storage y virtualización introducía un conjunto completamente nuevo de capacidades y características, solo mencionando algunas:

Snapshots de máquinas virtuales,
Imágenes pre-armadas de máquinas virtuales para rápidos deployments,
Backups ultrarápidos y con cero tiempo de ventana necesario (basados en snapshots combinados con software de backup tradicional o no, a preferencia del usuario),
Backups ultrarápidos a cualquier hora, incluído el primetime, permitiendo backupear la base de datos más importante de la empresa a las 11 de la mañana de un miércoles por ejemplo sin necesidad de "bajarla". (gracias a los snapshots de vuelta),
Migración automática - o no - de máquinas virtuales a cualquier nodo (recuerda "o servidor"), según la necesidad o no de capacidades de procesamiento/memoria (que obviamente están restringidos a la capacidad particular del nodo donde esté corriendo la máquina virtual...todavía :-), más sobre eso en otro artículo),
La posibilidad de migrar transparentemente de hardware en los nodos, con cero reinstalación de sistemas operativos (fast howto: simplemente se mueve a la máquina virtual a un nodo disponible, se apaga el nodo-server a reeemplazar, se monta el nuevo hardware, se instala el software de hypervisor, se lo integra al manejador de hypervisores y luego se vuelve a mover la máquina virtual al nuevo nodo, con cero modificaciones en el sistema operativo y en las aplicaciones ejecutando en él..de hecho no hace falta apagar la máquina virtual para realizar la migración de hardware),
La posibilidad de ir simplemente agregando capacidad a la/s SAN, es decir, ir agregando discos, que gracias a la capacidad de una capa de manejadores de volúmenes lógicos (LVM, Veritas Volume Manager, Solaris Volume Manager, etc), por debajo de los sistemas operativos (Windows Server, Linux, Unix), y la posibilidad de aumentar el tamaño de las particiones tradicionales con muy bajo riesgo (recordar aquí: antes tomar un snapshot -opciones: de la máquina virtual, del volumen lógico, de la partición, etc. - justo antes de hacer el resize de filesystem para lograr un tiempo cero de disaster recovery).
Mejoras radicales en el networking, utilizando networking virtual entre máquinas virtuales (switches virtuales, appliances virtuales - firewalls, UTMs, proxies, mails proxies, etc. ), es decir, el intercambio de tráfico de red se realiza en la memoria del nodo (server), cerca de la velocidad que tiene la memoria RAM, muy por encima de la velocidad disponible en hardware de networking.
La pregunta-consecuencia "¿esta mejora podría extenderse a los backups tradicionales si tuvierámos appliances virtuales?", exacto (ver aquí), se extiende y no para de extenderse (¿quien dijo Antivirus por ahí?), solo hay que ver los partners de appliances virtuales disponibles para cada producto, por ejemplo aquí.
La capa de virtualización (hypervisores y manejador de hypervisores), es realmente y casi por completo independiente del hardware. Se puede implementar sobre Vmware, Xen, KVM, Microsoft Hyper-V, perdiendo y ganando ventajas según el producto elegido.
La capa de SAN, cuando se progresa hacia hardware no commodity, es decir soluciones SAN propietarias, suele incluir también cada vez más numerosas capacidades de tunning de performance y características de zero-downtime a nivel de filesystems, por ejemplo: la posibilidad de armar RAIDs virtuales con volúmenes creados dentro de la SAN (lo que agrega una capa adicional de resilience, no confundir esto con los volúmenes lógicos de los sistemas operativos).
De hecho, con SANs propietarias, los RAIDs mencionados y cualquier volumen creado en el storage heredan capacidades del hardware de storage, incluyendo snapshots, movilidad y backups de volúmenes, etc. (de vuelta, esto es totalmente independiente de los volúmenes de los sistemas operativos y de cualquier capacidad en la capa de virtualización)
Es un largo etc. recursivo luego de este punto, hay muchas más funcionalidades.

Interesante no?

Bueno, eso fue un fast-track insight a infraestructura virtual, y ni hablé de la capa de software que efectivamente permite hablar de "cloud" (ver opennebula, ubuntu cloud, etc.).

En fin, acabo de encontrar un artículo de lonesysadmin al respecto, con el que veo hoy, comparto el punto de vista de una migración paulatina hacia una infraestructura virtualizada, sino una tercerización especializada; ambas con el objetivo a mediano plazo de tener al personal IT inhouse totalmente capacitado para hacerse cargo de las tareas.

Menciona casos reales y problemas simples que uno pensaría que no va a encontrar un team IT implementando virtualización, pero que en tecnologías nuevas suele darse, incluso la gente de IT especializada en infraestructuras pero aún no en virtualización puede cometer esos errores "clásicos", así que hay que poner atención a los problemas (muy) simples también.

http://lonesysadmin.net/2007/03/30/for-best-results-add-virtualization-slowly/

Salarios IT 2011 - Coming Soon

2011-01-21T15:32:00.000-08:00

Estos datos son casi de fin del 2010: Cuales son los perfiles IT más buscados y que salarios se pagan hoy en el mercado

Puntualmente en la imagen se ven los nros.

Más o menos y comparando con el año pasado, se puede ver que hay pocos cambios, sin embargo falta considerar que más allá de los ciclos internos de las empresas, la gente suele elegir cambiarse de empresa luego de volver de sus vacaciones de verano.

Por otra parte, se ve desde hace un par de meses y continúa durante el verano: hay un intenso movimiento en la gente de IT que ya ha decidido buscar mejoras laborales; de vuelta es independiente de cómo procedan los ciclos de reclutamiento y ejercicios económicos de las empresas en general.

Así que las negociaciones se están dando ahora mismo, se pide, se ofrece, se negocia, etc.

La conclusión es que vamos a ver los nuevos sueldos 2011 más o menos entre finales de febrero y antes de abril.

Si tienen un buen nivel de seniority, algo que se busca todo el año y casi no tiene bajas en la oferta de puestos, lo mejor es esperar a que todos los deptos. de RR.HH. se acomoden y consigan el OK de management para ofertar los nuevos niveles de sueldo de 2011.

Claro, los mejores RR.HH. ya van un paso adelante y ya tienen el OK de management y están ofreciendo los sueldos 2011 hoy (y por el momento parecen sueldos altísimos comparados con lo que hay ahora). Otros intentan "acomodar" la mayor cantidad de puestos posible antes de las actualizaciones de sueldos.

Un buen site para consultar (si quieren dejar su input, mejor):

Encuestas IT: Salarios y condiciones laborales

Protegiendo repositorios Yum de updates de otros repositorios

2011-01-14T09:02:00.000-08:00

Este artículo es un recordatorio online, pero vamos a escribir un poco, solo para darle trabajo al teclado.

Un par de issues al administrar paquetes de terceros

Al administrar paquetes en un server Linux nos encontramos muchas veces en la necesidad de utilizar repositorios de terceros para incorporar características muy específicas, normalmente fuera de los repositorios oficiales.

Existe toda una discusión de fondo sobre la pertinencia de utilizar repositorios no oficiales y/o de terceros, que ya traté antes en otros posteos y por supuesto, tiene casos de "ok" ("si") como de "no go" (comprensivamente, "no hacer").

Ahora bien, hay problemas de fondo con el uso de repositorios de terceros:

- Paquetes de preferencia

- Actualizaciones con repositorios preferidos

- Paquetes de preferencia: son una característica que existe en muchos manejadores de paquetes de Linux modernos, tanto para .deb, .rpm y otros formatos de paquetes. Esta característica permite preseleccionar cual repositorio es el repositorio por defecto de donde descargar un paquete cuando existe la misma versión en otro repositorio.

Es muy util, aunque no a simple vista, solo si lo combinamos con la siguiente característica:

- Actualizaciones con repositorios preferidos: es simple, se configura el manejador para que al actualizar paquetes no sobre-escriba los paquetes de los repositorios preferidos con ningun paquete de un repositorio no preferido (por más actualizado que esté con respecto al paquete instalado y al disponible en el repositorio preferido).

Esto último se hace en CentOS / yum utilizando el plugin protectbase.

(es aplicable a otras distros que usan Yum desde la versión 2.4 que permite el uso de plugins)

Y un uso típico en una instalación CentOS sería habilitarlo la protección para los repositorios [base] y [update].

El extracto de

http://www.centos.org/docs/5/html/yum/sn-yum-maintenance.html

protectbase

The purpose of the protectbase plugin is to protect certian repositories from updates from other repositories. Repositories that are to be protected will not be updated by newer files from non protected repositories. This plugin is recommended for anyone who routinely enables 3rd party repositories, as these non-CentOS repositories may update certian system files, potentially causing your CentOS installation to become unstable.

To install the protectbase plugin, ensure that the CentOS extras repository is enabled (it is enabled by default) and issue this command:

su -c 'yum install yum-plugin-protectbase'

After the plugin is installed, make sure that it is enabled. Edit the file /etc/yum/pluginconf.d/protectbase.conf and ensure that it contains the following:

[main]

enabled = 1

Next you need to edit all .repo files in /etc/yum.repos.d/ and add either:

protect = 1

protect = 0

Básicos de versionado en GIT

2010-10-26T17:43:00.000-07:00

El manejo del versionado de código (branches, merges, etc.), es clave para desarrollos grandes y/o cuando se desarrolla en equipo; y ayuda mucho si el desarrollo continua más allá de lo inmediato, con sucesivas versiones y lo que ello implica.

En el link de más abajo pueden encontrar un excelente artículo explicando un modelo de desarrollo usando GIT (uno de muchos VCS - Version Control System).

Para cualquier desarrollador profesional, el manejo de los VCS más populares es un "must", y es una de las skills que suele permitir clasificarlo como "desarrollador" en vez de "programador"; siendo la diferencia entre los dos el que el programador sabe escribir código, mientras que el desarrollador sabe escribir código y también participar activamente y/o llevar adelante las diferentes etapas de un projecto desarrollo.

Casi está demás contar que la experiencia y manejo de VCS suele ser un requisito para ingresar en buenos niveles de paga en empresas IT multinacionales.

El artículo en cuestión aquí:

"A successful Git branching model"

Fuente (con más links interesantes):

http://news.ycombinator.com/item?id=1826279

Links - VCS

(muy corta definición, en español)
"Revision Control System"

(mucho más completa, en inglés)
"Revision control"

"Comparison of revision control software"

Links - Diferencias entre programador y desarrollador

"Desarrollador de software"

"¿Qué diferencia a un desarrollador de software de un programador?"

"Un buen desarrollador equivale a diez programadores con baja productividad"

Videos Ekoparty

2010-10-10T08:59:00.000-07:00

Memory log > Videos de Ekopartys anteriores

http://vimeo.com/ekoparty/videos/sort:date

La última:

Ekoparty 2010 - 16 al 17 sept. 2010 - Bs.As. Argentina
http://www.ekoparty.org

La suricata inconformista gana la calle..

2010-10-10T08:25:00.000-07:00

Salió Ubuntu 10.10

La "suricata inconformista" ya está aquí, lo que es la traducción de maverick meerkat, el codename de la nueva versión de Ubuntu.

La explicación del nombre:

http://www.genbeta.com/actualidad/ubuntu-1010-ya-tiene-nombre-maverick-meerkat

Lo nuevo de Ubuntu es lo nuevo de Linux, muchas mejoras que ha tenido Linux y el stack de software han sido adoptadas por la nueva versión (Gnome, NetworkManager, OpenOffice, etc.), a la vez que Ubuntu incorpora sus propias mejoras como el Software Center y mucho atractivo visual en sus themes de escritorio.

Por reviews interesantes, ver allá:

http://irvingprog.wordpress.com/2010/09/05/review-ubuntu-10-10/

http://techhaze.com/2010/10/ubuntu-10-10-maverick-meerkat-review/

En el mail de liberación hay varios links útiles más, aparte de mucha buena onda del equipo de Ubuntu;

https://lists.ubuntu.com/archives/ubuntu-announce/2010-October/000139.html

Lo pueden bajar de acá:

http://releases.ubuntu.com/maverick/

Tal cual se dió desde el principio de Linux, los end users, home users, etc. se van a tirar adentro de la nueva versión testeando que tan amigable se ha vuelto Linux y por supuesto van a encontrar interesantes mejoras; los más novatos van a encontrar obstáculos que superar y los expertos van a encontrar una distribución cada vez más madura y que hoy claramente lidera la escena linuxera en distribuciones del lado de los end usuarios, junto a Red Hat que lidera el uso a nivel empresarial.

Queda mucho por descubrir todavía.. http://www.ubuntu.com/

Tips para buscar empleo IT en multinacionales

2010-10-10T07:00:00.000-07:00

Gente que debería quedar, no queda
El buscar empleo en una multinacional puede en principio reducirse a simplemente presentar el CV, obtener una entrevista, pasar el proceso de selección e ingresar.
Sin embargo, hay factores que hacen que muchos candidatos viables, que tienen todos los requisitos necesarios para acceder a una posición, no lo logren.

El CV pasa un análisis en general muy rápido, a veces automatizado, por lo cual se debe tener un buen CV. El tip más rápido es conseguir varios CVs de gente que ya accedió a posiciones en multinacionales y copiar la estructura y la jerga (esto es muy importante, usar las mismas palabras que son estándar en la industria: por ejemplo, en vez de "programador", usar "desarrollador", etc.).

Es decir, hagansela fácil a la gente de RR.HH. (Recursos Humanos), recuerden que el CV llega a gente que no tiene casi nunca real entendimiento de lo que están leyendo, sino solamente una aproximación interpretativa porque son profesionales RR.HH., y casi nunca son profesionales IT. Un lugar donde esto se puede hacer es buscando ejemplos en Linkedin.

Qué se busca y qué hace falta saber

Buscando en Linkedin también van a poder ver esto, vayamos al principio del tema: En sitios de búsqueda de trabajo en línea como Bumeran, Universobit, etc. pueden encontrar las posiciones ofertadas, pero en gral. y si es el primer empleo en una multinacional, casi de seguro no van a saber con seguridad si las skills propias "sirven" o no para postularse. Un modo de verificar eso es ir a Linkedin, buscar y ver perfiles de gente que ya trabaja en posiciones similares, y van a ver realmente si lo que tiene podría permitir o no acceder a la posición.

Lo que piden y lo que el postulante oferta

El postulante también ofrece sus servicios y skillset: el conjunto total de cosas que sabe y el potencial de lo que podría crecer. Es importante entender esto pues muchas ofertas de empleo listan los requisitos óptimos para el candidato buscado, pero NO listan casi nunca los requisitos mínimos para el puesto. Para ubicarse en este tema, la información también la pueden obtener de Linkedin (después de analizar un poco los perfiles).

Lo de los requisitos mínimos es interesante para el primer empleo en una multinacional porque si no se llega al "óptimo" presente en la oferta, igualmente se podría acceder al puesto, tal vez con cambios en la prestación (menor sueldo, horarios poco habituales, etc.).

Si llegan a obtener la entrevista, es muy importante preguntar y verificar que no existe alguna confusión o expectativa (apuesta), de parte del entrevistador de recursos humanos (RR.HH.): a veces llaman para ver si un "nivel intermedio" de inglés podría ser en realidad un "bilingüe". Cabe también la posibilidad de hacer la contra-apuesta y probar si pueden pasar las pruebas, de hecho si las pasan van a corroborar la apuesta de RR.HH. de que en realidad el perfil del candidato era mejor de lo que mostraba el CV.

¿Como saber si me llaman por una "apuesta" o porque cumplo los requisitos? Le pueden preguntar al entrevistador, directamente, también es claro si les falta totalmente alguna de las skills solicitadas para el puesto ( por ej. piden un año de experiencia en Java y Uds. tienen 2 años de experiencia en .NET, pero no tienen nada de Java).

Lo de la apuesta no es algo relacionado con el azar, sino con el potencial de crecer del candidato.

Las posiciones Jr. / Trainee

La importancia de los puestos Jr. / Trainee es que le permiten al candidato ingresar en la empresa y empezar a empaparse literalmente de la cultura corporativa y de un modo de trabajo bastante diferente de los empleos en PyMEs y por cuenta propia.

El aspecto técnico en gral. suele ser bastante poco interesante (por ej., trabajar casi exclusivamente agregando cuentas de correo), pero es un comienzo y al ingresar el novato, las posibilidades de carrera IT mejoran sustancialmente ya que es mucho más fácil a futuro acceder a otras posiciones más interesantes; de hecho las multinacionales "esperan" que eso suceda, nadie - que entienda la realidad profesional IT - pretende que un profesional IT se pase 5 años, por ej., creando cuentas de correo exclusivamente.

Cuanto tiempo se la tienen que bancar? En gral., un año, al cabo del cual si no piden nada incluso (es MUCHO mejor pedir), suele haber mejoras en el propio trabajo (les piden hacer cosas más interesantes), y/o surgen posibilidades laborales internas (dentro de la misma multinacional) y/o externas.

Logística económica y social de la mudanza

Casi todo empleo en una multinacional implica mudarse a Bs.As., Cordoba, Rosario, etc.

En gral. los entrevistadores averigüan muy rápido si un candidato tiene lo que hace falta para mudarse a otra ciudad y trabajar normalmente, por eso es que hace falta pensar bien la logística de cómo se va a tratar la mudanza: alquiler, gastos, viajes, muebles, ropa, transporte.

Es importante tener todo esto en claro y ser serios, porque si el RR.HH. elige un candidato que tiene que mudarse por sobre otros que ya viven en la ciudad, debe justificarlo muy bien, es decir tiene que confiar en el candidato casi personalmente.

La otra faceta es la social, no se puede estar en una ciudad sin tener contacto con nadie más que la gente que se conoce en el trabajo (que de por sí, no suele ser un lugar de extenso intercambio social, aunque a veces sí).

Lo óptimo es intentar vivir, o compartir de cerca al menos, con otra persona la experiencia de estar en una ciudad lejos de la familia y amigos.

Es vital entender que fuera del trabajo DEBE haber actividades que permitan a la persona sobrellevar mejor las emociones que vienen con un gran cambio; en este sentido es VITAL hacer ALGO: cursos, inscribirse en lugares para aprender algo (hobbies, cosas IT que
interesen, etc.), inscribirse en un gimnasio, hacer algun deporte de equipo. Lo importante es intentar rodearse de conocidos habituales y socializar, eso suaviza mucho cualquier situación devenida de estar lejos del lugar de origen.

En la realidad práctica, llegar al punto de tener algun conocido con quien tomar un mate un sábado por la tarde es casi tan importante como encontrar donde alquilar.

Flisol 2010 Corrientes, DVDs OpenSUSE, openSUSE Community

2010-03-30T17:18:00.000-07:00

Things are moving - somewhat - in background at the Flisol 2010 Corrientes organization, the main team from the Instel Institute (an IT local enterprise, with a very pro opensource community attitude, www.instelseguridad.com.ar), is working with the CECENA (student's centre), at FACENA-UNNE (the computer's cience faculty at the university), for to bring renovated sucess to this year Flisol Corrientes.

The last year, the Corrientes Flisol was one of the most concurred event at LATAM, and probably the most concurred Flisol at Argentina. This happened not without some surprise in the team behind the organization, but was welcomed as a recognizing from the local IT fan guys and opensource fans in general to the efforts putted before the whole thing. This year the challenge is to repeat the last year success, but not in the sense of just to have a lot of people listening the talks, but in the experience the people who will assist is going to have.

This morning I asked for event stuff - dvds - to some people at openSUSE community. I mean, to have 100 to 200 original openSUSE dvds in the middle of an install fest can't hurt anybody. Maybe - I'm waiting yet for a confirmation - even we could get some extra stuff, but I can not confirm anything at all yet. There are no more 11.2 dvds available at this point, but there many remanent 11.1 dvds, so 11.1 will be (I've asked Andreas for about 300 dvds!!!, I hope the mailmain do not miss the postal thing :-).

The talk I'm going to present, "Meet Opensuse" will be related to show the distro to a non technical audience and probably I'll include some fun technical tips for the other ones (a video taking the default Gnome and KDE to the last stable version using Yast maybe?), but I do not only want to talk about the distro, doing that could be somehow a mistake, so I'm going to talk about the openSUSE Community, diferentiating it from the "Novell people", and reviewing some achivements from it. If the time permits it, I will like to show some cool tricks you can do with the distro using the community supplied infrastructure, mainly the Build Service, the one-click stuff, the extra repositories, and additionally I'm going to review the howto material hosted at the community site, the fine openSUSE related tutorials at personal blogs all around the Internet.

Right now, I hava another talk is in standby, "Log File Analysis" but the organizers may reconsider to include it in the event because there are a lot of talk proposals for to be included in the program, we'll see.

For the install fest I've been planifying to deploy either openSUSE 11.2 or 11.1 (given the old dvds situation), but I'm considering to include also the distro updates to at least a few days before the Flisol, the KDE 4.4.2 and Gnome 2.2.29 (it'll be .30 at that date), from the optional/extra community repositories. I need to figure out how to replicate and update them in a useful way till it comes the Flisol date (some rsync and cron hackery almost certainly).

More news to come in the next days.

Opensuse Ambassador at Corrientes

2010-03-22T06:04:00.001-07:00

Yesterday I inscribed myself to be a new Opensuse ambassador. I did it at the Opensuse Community site, www.opensuse.org. Maybe you could want to inscribe yourself too as an ambassador - you can do it too!, it's quite easy - be sure to read first this page with the goals and requirements (they're not too many), to be an Opensuse ambassador.

I wanted to be an Opensuse ambassador because I readed that the community gives concrete support to the ambassadors in form of contribution like DVDs, t-shirts and other promotional materials. Given the fact that I'm going to present a pair of talks at the regional event "FLISOL" ("Open Source Latin American Install Festival"), at the local install fest (March 14, UNNE Campus, Corrientes, Argentina), I though it was a good opportunity to have an extra boost to promote the Opensuse distribution as well as the Opensuse Community.

This FLISOL my talks will be "Log Files Analysis" and "Meet Opensuse" and in both talks I'm going to use - obviously :-) - Opensuse. The last times that I participated in events related to open source (including the previous year local Flisol), I always have taken my personal deployment of Opensuse to the trenches of the talks and that awaked a lot of positive comments asking "What distro are you using? Looks Fine" - OK, I need to give credit to the kick-ass tunned KDE 4.3.x I was using, but Yast has have some big screen public seconds at the talks too - so I think this year it's time to show some extra bits a little more specifically Opensuse oriented, to show people what other good level options/distros are out there.

Note; Maybe you could excuse the crappy written english when you find it, or better, correct me, your welcome in advance.

------------

Ayer me inscribí para ser un nuevo Embajador Opensuse, lo hice en el sitio de la Comunidad Opensuse, www.opensuse.org. Tal vez podrías querer inscribirte tu también para ser un embajador - puedes hacerlo! es bastante fácil - asegúrate de leer primero esta página con los objetivos y requerimientos (no son muchos), para ser un embajador Opensuse.

Quise ser un embajador Opensuse porque leí que la comunidad da apoyo concreto a los embajadores en forma de contribuciones como DVDs, remeras y otros materiales promocionales. Dado el hecho de que voy a presentar un par de charlas en el evento regional "FLISOL", en la fiesta de instalación local (el 24 de Marzo, en el Campus de la UNNE, Ctes. Argentina), pensé que era una buena oportunidad para tener un empuje extra para promocionar la distro Opensuse así como la Comunidad Opensuse.

En esta FLISOL mis charlas van a ser "Análisis de archivos de logs" y "Conociendo Opensuse", en ambas charlas voy a usar - obviamente :-) - Opensuse. Las últimas oportunidades en que participé en eventos relacionados con software libre (incluyendo la Flisol local del año pasado), siempre he llevado mi instalación de Opensuse a las trincheras de las charlas y eso despertó muchos comentarios positivos preguntando "¿Qué distro estás usando? Se ve bien" - OK, tengo que dar crédito al tremendo y tuneado KDE 4.3.x que estaba usando, pero Yast también tuvo algunos segundos de pantalla gigante en público - así que creo que este año es tiempo de mostrar algo un poco más específicamente orientado a Opensuse, para mostrarle a la gente que otras opciones y distros de buen nivel están disponibles.

NoSql y el futuro de los datacenters

2010-03-12T17:53:00.001-08:00

Nosql avanza

Digg cambia MySQL por NoSQL

http://www.vivalinux.com.ar/eventos/digg-cambia-mysql-por-nosql

Otro gran consumidor de servicios de bases de datos - Twitter lo hizo este mes también - está abandonando MySQL y en profundidad, dejando las DB relacionales como base de sus procesos de negocios más importantes. Digg ya está usando una arquitectura NoSql basada en Cassandra, y la migración desde MySQL/DBs relacionales a Cassandra/NoSql habría comenzado hace 6 meses atrás y hoy ya tienen Cassandra/NoSql corriendo en producción.

Según comentan en el blog de la empresa, abandonan las DBs relacionales por las limitaciones que tienen cuando se escala a grandes volúmenes de datos y al tener que particionar - horizontal y verticalmente - la información, pierden las ventajas de lo "relacional" de las DBs, a la vez que mantienen todas las desventajas (sobrecarga derivada del mismo particionamiento).

También comentan que les resulta muy importante que a medida que se expanden a lo largo de múltiples datacenters para obtener redundancia, mejor performance de red, poder añadir capacidad o reemplazar nodos caídos sin ningun downtime (sin tener que apagar el hardware/servers/datacenters, ni el software/DBs). A la vez planean seguir usando hardware commodity y por lo tanto asumiendo que fallará regularmente; todo ello se vuelve constantemente más difícil de manejar usando MySQL.

Más aquí:

Saying Yes to NoSQL; Going Steady with Cassandra

http://about.digg.com/node/564

En este otro post, tenemos lo que fue la previa de la migración a Cassandra, con una intro a unas pruebas de factibilidad que corrieron los ingenieros de Digg en una feature del sistema, evaluando muy positivamente la performance de Cassandra.

Lo más importante de este post, tal vez sea que llegaron al mismo razonamiento que Google, Amazon, Yahoo, Facebook, Linkedin, Twitter y otros: es mucho más barato incorporar nuevos discos (y hard commodity ultrabarato), que lidiar con las complejidades de escalar una DB relacional típica a cientos/miles de nodos.

Más aquí:

Looking to the future with Cassandra

http://about.digg.com/blog/looking-future-cassandra

El futuro cercano del software

El software libre de DBMS de avanzada (MySQL, Postgresql, y ahora las NoSQL), y sistemas operativos (Linux, BSDs), cambiaron completamente el juego de los negocios IT altamente rentables tradicionales (sistemas operativos, bases de datos y equipamiento de datacenters). cuando los jugadores más importantes de la industria mundial (en cantidad de datos de procesamiento y por velocidad de procesamiento), migraron hacia soluciones completamente libres.

El primer salto hacia el datacenter del futuro cercano es que las organizaciones que implementan sistemas con gran consumo de recursos rápidamente necesitan implementar redundancia y replicación masivamente, lo que llevaría en el caso de estar usando software propietario, a necesitar muchas - cientos por ejemplo - licencias de sistemas operativos, y de ellas, las más caras, que son las que habilitan el uso - legal - de funcionalidades de clustering e interoperatividad que se requiere en ambientes de decenas a centenares de nodos - servers - corriendo teams de procesamiento.

La misma idea se aplica a las licencias de bases de datos propietarias, si necesitamos implementar 200 servidores de bases de datos trabajando en modo avanzado - replicación, clustering, interoperatividad avanzada - los costos se vuelven prohibitivos.

Si saltamos de 200 a 2000, los costos se vuelven imposibles de cubrir para la mayoría de las organizaciones públicas y privadas que no tengan un presupuesto de adquisición y otro presupuesto de mantenimiento similares a los de una corporación multinacional que tiene decenas de miles de millones de dolares de ganancias anuales.

De vuelta, de 200 sistemas operativos con licencia de datacenter a 2000 licencias, los costos también se vuelven prohibitivos. ¿Que tal si saltamos de 2000 a 200.000?

El futuro cercano del hardware

En este punto tocamos el hardware, si necesitamos 20 servidores, luego 200 y despues 2000 servidores, los costos de adquisición y mantenimiento se vuelven imposibles para muchos. A esto hay que sumar que la necesidad de mayor capacidad de procesamiento lenta pero progresivamente se vuelve un factor constante y presente en las infraestructuras IT de muchas organizaciones. ¿O sea que un día podría necesitar 200.000 servidores?

Este problema trae aparejado otras cuestiones profundas a analizar y que - básicamente - derivaron en que la planificación, construcción e implementación de nuevos datacenters masivos para grandes empresas como Google, Amazon, y otros se realizan utilizando grandes inmuebles en zonas extremadamente baratas que tengan el abastecimiento de energía necesario (y el más barato posible en el caso de países con mercado de energía desregulado, como es el caso de EE.UU.).

Volviendo al hardware, comprar 2000 servidores, mantenerlos (agregarles ram, reparar placas madres), se vuelve un juego en que cada 3 años aprox., cuando vencen las garantías del fabricante, se vuelve imperativo volver a comprar servidores, sin opción más que seguir usando un hardware imposible de reemplazar de inmediato - si fuera necesario - por hardware de menor costo, y en muchos casos ni siquiera disponiendo del presupuesto apropiado, se puede disponer de inmediato o en plazos razonables - horas - de reemplazos completos.

Un plazo razonable de provisión de hardware tan crítico está medido en horas porque organizaciones como por ej. bancos, no pueden asumir downtimes mayores sin sufrir un gran impacto a nivel organizativo (regulativo, económico, financiero, legal, laboral, social, etc.).

En una extensión del razonamiento de los tiempos de provisión, debemos recordar que aunque los proveedores de servers de alto nivel disponen de equipamiento en stand-by en países con un mercado de infraestructura IT fuerte, y ello se materializa en grandes cantidades de servers y equipamiento para datacenters a corta distancia geográfica y administrativa (se pueden comprar por Internet y llegan al otro día a las pocas horas y de madrugada si hace falta), de las organizaciones; todo esto no se repite en la misma magnitud en muchos países (en Latinoamérica en general los tiempos de respuesta y existencias son bajos, y los costos por "apuro" son considerablemente altos), por lo que muchas organizaciones en el mundo se ven considerablemente expuestas a riesgos mayúsculos al atarse inseparablemente de infraestructuras - servidores principalmente - que no se pueden reemplazar rápidamente.

Aunque el escenario de falla de un server cuando se usan 20, y se tienen 5 de reserva tiene un impacto relativamente menor (se activan planes de disaster recovery y/o esto se produce automáticamente, gracias a clustering, replicación o infraestructura virtualizada). Cuando se tienen 200 o 2000, las cosas cambian.

Software libre y hardware commodity

Meditando sobre el escenario anterior, vemos que es presente para organizaciones como Google, Amazon, Yahoo, Facebook, Linkedin, Twitter, Digg y muchas otras organizaciones avanzan rápidamente hacia escenarios similares a mediano plazo (un par de años), a medida que incorporan sistemas que almacenan gigabytes de datos por mes y terabytes por año (o peor, TBs por mes y EBs por año). Estos datos almacenados requieren ser accedidos cada vez a mayor velocidad gracias a la constante adición de minería de datos y en mayor medida incluso, a que los sistemas en producción simplemente acceden el pleno de datos almacenados, sin posibilidad de "retirar" conjuntos de datos como "históricos" y mejorar con ello la performance de los sistemas y bajar los requerimientos de hardware.

En este escenario es que se presenta la necesidad de mantener cientos a miles de nodos de servidores, cada uno corriendo un sistema operativo y una base de datos, con el requerimiento inevitable de que el hardware sea muy, muy barato, fácil de reemplazar y fácil - rápido - de conseguir localmente.

A este tipo de infraestructuras migraron los grandes ya mencionados, reemplazando centenares de servidores individuales (que fue el típico modelo de infraestructura "barata" de finales de los 90), de "marca", con garantía del fabricante, por cientos o miles de máquinas commodity, PCs de escritorio montadas como servidores clusterizados por software, con mínima resiliencia y máximas probabilidades de fallo por baja calidad del hardware. Pero cada nodo es extremadamente barato, fácil de conseguir y se puede mantener literalmente miles de nodos en cold-standby (apagados), listos para reemplazar a cualquier PC/Nodo/server que falle, inmediatamente.

Adicionalmente el software libre brinda costo de licencia cero (0) para cada sistema operativo y base de datos corriendo en cada uno de los miles de nodos del datacenter.

Otras infraestructuras muy simples, brindan servicios de automatización completa, por ejemplo permitiendo que la falla total de una PC/nodo/server sea insignificante a nivel de prestación de servicios del datacenter. Incluso implementar un nuevo servidor de reemplazo es decir, conectar y encender e instalar una nueva PC/Nodo/server, se automatiza al punto de que el software (sistema operativo, base de datos y configuraciones), se instala y despliega automáticamente, simplemente conectando la nueva Pc/nodo/server a la red (por ejemplo vía PXE y Kickstar). Tal como esto es el funcionamiento actual de las infraestructuras de Google, Yahoo, Twitter, Facebook, Digg y otros.

En este punto vemos que hacer un deployment con miles de sistemas operativos Ubuntu LTS Server - por ejemplo - cada uno exactamente igual al otro (excepto algunos pocos gigas de datos variables), vuelve posible adquirir un par de decenas de contratos de soporte 24x7x365 para Ubuntu LTS Server, y disponer así de soporte especializado de alto nivel que se puede maximizar dando soporte - por inferencia - a los miles de nodos que seguirán usando el mismo Ubuntu LTS Server gracias a que es de licencia libre.

De hecho, este modelo anterior de soporte "oficial" es usado por muchas organizaciones en el mundo, incluso realizando inferencias como de RHEL a CentOS, siempre con una adecuada planificación de personal especializado e inhouse (Google, Yahoo, etc.), aunque muchos tambien tercerizan tareas de este tipo sin mayores inconvenientes (Linkedin, etc.).

El futuro de las SANs, Storages e infraestructuras virtualizadas

El tema del storage, las SAN y las infraestructuras virtuales posiblemente viva un escenario parecido cuando se vuelvan masivas, básicamente es cuestión de que los administradores de hipervisores libres actuales (ya hay varios en pleno desarrollo), adquieran suficiente nivel para que sean comparativamente capaces a sus equivalentes pagos y/o propietarios (hay administradores libres con versiones pagas con más features).

Aunque el costo de infraestructuras FC (Fibre Channel), puede parecer un inconveniente de momento, con la masificación de tecnologías de networking de 10 Gigabit Ethernet (GeB), el uso de PC/nodos/servers commodity baratos con placas de red 10GeB y con iSCSI (o incluso ATA over Ethernet, mucho más barato), va a llevar las SAN, los Storage y las infraestructuras virtuales al mismo escenario que hoy previsualiza en servidores tradicionales vs. hardware commodity. Aunque de momento, los dispostivos storage de alta capacidad no tienen rivales posibles si se los implementa en conjunto con infraestructura virtual (hipervisores, administradores de hipervisores, y administradores de administradores, no no es una repetición, Vmware vSphere soporta esta funcionalidad hace más de un año).

Conclusiones

Tarde o temprano el mercado de hardware va a evolucionar hacia servidores/nodos muy baratos, más que los servidores más baratos disponibles hoy (hojas Blade con dos placas de red y un par de discos en RAID como máximo). Los sistemas operativos pagos y bases de datos pagas van a abaratarse para compras grandes, o al menos van a ofrecer algun tipo de competencia a las bases de datos de licencia gratuita (como por ejemplo, grandes descuentos en compras por volumen y/o features a pedido en compras por volumen).

Links

Cassandra

NoSql

Dynamo

10 Gigabit Ethernet

iSCSI

ATA over Ethernet

3er. Clase del sysadmin training

2010-03-01T07:30:00.001-08:00

Issues

El training tuvo su tercer clase el viernes pasado y debido al ámbito de conocimientos amplios y el tiempo limitado de dictado tuvimos un par de issues:

- Con un solo dvd de instalación, la review de instalación de cada trainee se ajustó a la posibilidad de ir pasando el dvd en mano uno por uno, lo que retrasó bastante la tarea. Por lo positivo, los distintos traineés tuvieron asistencia personalizada encarando la instalación de SLES11 (en una máquina virtual), y todos instalaron sin inconvenientes el SO, lo que nos dice que el recorrido realizado en la primera clase tuvo buenos niveles de comprensión en la gente.

- Al momento de explicar el scheduler CRON, ya estábamos escasos de tiempo restante en la clase según mi planificación, así que resolví que en vez de transmitirles a los traineés interactivamente las capacidades de CRON, decidí hacer una intro rápida, y continuar en la tercer clase, ya con templates que puedan utilizar para ir conociendo el uso de CRON sin tener que descubrir sus features desde el man hasta la entrada CRON ya configurada.

- La intro teorica a la administración de paquetes fue probablemente la 2da. más fuerte luego del análisis del arranque del sistema, el inicio de init y su progresión hacia los runlevels. En la siguiente clase planeo repetir la historia de los runlevels: aunque el comienzo tuvo mucha teoría, vamos ver distintas tareas habituales en una práctica extensiva.

La clase

Tema 2 - continuación

En conjunto con los issues, se dió la 3er. clase, arrancando con la continuación de las explicaciones teóricas del uso práctico de los runlevels y servicios (el cómo y porqué de inittab, los S y K de los links simbólicos y de ahí en adelante), y siguiendo con un práctica que recorría las distintas tareas usuales en el manejo de varias tareas de administración en el arranque de Linux:

- parámetros de booteo en Grub (cómo elegir runlevels y nociones de modificación de otros parámetros en Grub),

- servicios por defecto en runlevels, comprensión y administración del tema (si un servicio está activado, aún así puede no estar corriendo, etc.)

- nociones de creación de scripts de runlevels en el contexto de compatibilidad - asegurada - con el estándar LSB.

En los prácticos ya estuvimos recorriendo transparentemente y usando mc, Yast, X y pseudo-terminales varias, los archivos de configuración en /etc, /boot/grub, etc. No deja de sorprenderme positivamente la capacidad de aprendizaje de todos novatos del training, que evidentemente solo necesitan una buena explicación teórico-práctica para, por ejemplo, pasar directamente desde no conocer para qué sirve CTRL+ALT+F1/2/3/4/5/6, a comentar (#), entradas en /etc/inittab para deshabilitar esas posibilidades, y saltar desde X hasta terminales y de vuelta, mientras en las demos vía cañon voy saltando desde Yast a consola. Varios ya se cansaron de CTRL+ALT..y de vuelta y trabajan directamente sobre terminales Gnome...enhorabuena.

Tema 3

La explicación comenzó un poco lenta, tengo que reconocerlo, la realidad es que organizar en pocas palabras un mensaje complejo y extenso como explicar simultáneamente qué es un paquete, sistemas de administración de paquetes y sus características idénticas independientemente de la distribución, requiere hablar con suficiente precisión. Después de unos 5 minutos, de explicar cómo se construyen paquetes y - repitiendo - la noción de dependencia de paquetes, me puse a explicarles cómo se igualan funcionalmente los distintos sistemas de administración de paquetes para Linux, haciendo incapié en distros concretas (SLES, RHEL, CentOS, Ubuntu, Debian), y en yum y apt. Luego de eso ya pasamos a las tareas típicas de administración de paquetes y repositorios (siempre hablando en lenguaje común y compatible con las varias distribuciones ya mencionadas).

Para finalizar incluí una explicación consciensuda de criterios de selección de repositorios, explicando paso a paso, las consecuencias legales y prácticas de la inclusión de repositorios no soportados en el listado de repositorios oficialmente soportados en una distro comercial/empresarial. Luego de esto, los trainees ya tienen la información necesaria para decidir la pertinencia de incorporar o no software, actualizado o no, no soportado oficialmente a una instalación particular (empresarial o no, oficialmente soportada o no, empresarial o home, etc.).

Luego de lo anterior pasamos directamente a las demos en cañon usando Yast (que la mayoría de los trainees repite en sus instalaciones locales al modo de prácticos rápidos), donde recorrimos las GUI de administración de repositorios y paquetes, haciendo un racconto de capacidades y tareas usuales en la administración de paquetes, cabalmente representadas en las GUIs de Yast y que podemos encontrar en otras GUIs en diferentes distros.

El manejo de paquetes y repositorios en modo texto quedó pendiente para la próxima clase, sin embargo varios ya han tomado nota de algunos comandos rpm utilizados durante el tema 2 (rpm -qa | grep -i paquete, etc.), por lo que ya realizaron un contacto comprensivo-práctico en una situación real de uso de skills de adm. de paquetes.

De momento estoy haciendo la review del avance del training y viendo si la próxima clase se podría incluir un recuento de skills, para ver qué aprendieron a hacer hasta ahora y para qué les sirve; tal vez el recuento de skills se haga al final del training porque si bien los trainees tienen en mano mucha información específica sobre un par de componentes habituales en tareas de administración, les está faltando un poco más de contexto, por ejemplo, agregar skills de administración de almacenamiento, así la posibilidad de parametrizar Grub se puede sumar a skills de recuperación de discos.

Otra cosa que estoy viendo es si ya hago el lunes una introducción a LVM, este tema no figura como parte del temario, pero les prometí a los trainees que en vista de un poco de tiempo disponible, tenía ganas de dar este tema. Creo que el manejo de volúmenes es la clave para entender una de las principales características que hacen de Linux/*nix una opción por defecto al realizar deployments importantes.

También figura como parte de las promesas de temas adicionales - siempre ajustable esto a la disponibilidad de tiempo - los temas de administración remota (VNC, SSH, túneles de protocolos sobre SSH, redireccionamiento de puertos, etc.), y configuración básica de DNS.

Como compilar driver Nvidia con el kernel 2.6.33.x

2010-03-01T02:33:00.000-08:00

A esta altura ya debería ser un problema conocido, pero hace un par de días intenté compilar el driver Nvidia propietario, tuve el fallo, me dirigí al sitio de Nvidia y no pude localizar ninguna versión nueva. De cualquier modo si tienen alguna de estas dos versiones de driver de Nvidia para Linux:190.53, 195.30 (beta) y están usando un kernel 2.6.33 (RCx o final), puede que no hayan podido compilar ninguno de los dos drivers.

El problema está en un par de diferencias en el códido fuente del kernel, que lo hacen un poco distinto de lo que están preparados para procesar los scripts de los drivers Nvidia.

Para solucionar este problema podrían probar (sin garantías, porque no es oficial), bajar uno de los parches nvidia-190.53-2.6.33.patch.txt (2.8 KB), nvidia-195-2.6.33.patch.txt (2.6 KB):
de:

http://www.nvnews.net/vbulletin/showpost.php?p=2164440&postcount=20

Que modifican el archivo nvacpi.c and conftest.sh inside /usr/src/nv.

Y aplicarlos a su respectivo binario de instalación, luego de lo cual van a poder compilar el driver sin problemas en kernels 2.6.33 RC1 a RC4 y versiones finales. El comando para aplicar no es más complicado que:

./NVIDIA-Linux-x86-190.53-pkg1.run --apply-patch nvidia-190.53-2.6.33.patch.txt
./NVIDIA-Linux-x86-195.30-pkg1.run --apply-patch nvidia-195-2.6.33.patch.txt

Este editor ha probado en particular esto sobre un driver x64 Beta, sin problemas.

MaríaDB es el nuevo MySQL (probablemente)

2010-03-01T02:18:00.000-08:00

Al estilo de hace unos años en los comics en Superman murió y renació con otro nombre, Monty lo hizo de nuevo, y creó un nuevo proyecto de base de datos open source llamado MariaDB, basado en el código de MySQL 5.1 (la última versión oficial antes de la compra de Oracle).

El creador de MySQL AB, la empresa que derivó del proyecto open source MySQL, y que fue comprada primero por Sun, y luego terminó en manos de Oracle, forkeó el código del proyecto "oficial" MySQL, cada vez menos oficial a medida que los usuarios actuales de MySQL empiezan a desconfiar masivamente del futuro de MySQL en manos de Oracle, con pocas precisiones empresariales de parte de Oracle y con muchos rumores nefastos: pagar por features enterprise para MySQL, eliminación o reducción de capacidades de MySQL en próximas versiones (imaginen un MySQL Express, al estilo SQL Server Express), o peores presagios.

Pocos especialistas en open source y aficionados pensaron que la compra de Sun de MySQL en su momento fuera "mala", sino al contrario, un apoyo empresarial reforzado, para disparar MySQL al mundo corporativo definitivamente. Finalmente, y al contrario cuando Oracle compró a Sun, todo quedó a la vista, y pocos pensaron que no era algo arreglado de antemano entre ambas empresas, es decir casi todos pensaron "listo, se acabó MySQL".

Monty se embolsó 16 millones de euros en la venta a Sun, así que está en posición perfecta para retomar el desarrollo del código, así nació MariaDB - tal vez - el reemplazo real a futuro para MySQL. Hoy ya está disponible la versión 5.1.41 RC1 de la MariaDB, que es un reemplazo directo de MySQL, así que podemos tomarla una base de datos funcionando sobre MySQL 5.1 y usarla desde MariaDB sin hacer ningun cambio en la base.

Faltaría leer la "letra chica" de MaríaDB, pero si es un reemplazo 100% de MySQl 5.1, todas las herramientas compatibles con MySQL 5.1 deberían poder conectarse e interactuar transparentemente con un engine MaríaDB.

Ahora el código fuente abierto le da un giro a los acontecimientos y tal vez en poco tiempo vemos si sirve de algo pagar decenas/ cientos de millones de euros para terminar con el desarrollo de un software open source de calidad con mucho mercado ganado o no sirve para nada, y solo consiguen dejar mejor parado al proyecto (y hacer millonario al propietario del proyecto de paso), aunque cambie el nombre del software.

La iniciativa de Monty de juntar firmas para impedir la fusión de Oracle-Sun quedó en el pasado ya, porque la idea era evitar la Union Europea autorizara a Oracle a comprar Sun por la presencia en el "paquete" de MySQL, un competidor indirecto de Oracle, lo que se constituía - para algunos evidentemente - en práctica monopólica, al comprar una empresa con gran cuota de mercado a un competidor, pero no fue visto así por la UE, y de hecho ni siquiera se consideró la "presencia" de MySQL en el paquete de adquisición que ofrecía Sun a Oracle.

El futuro parece promisorio por el momento, y los probablemente centenares de miles de deployments empresariales que incluyen importantes deployments mysql de Google, Twitter y muchos otros de similar criticidad (múltiples bases, de decenas a miles o más, y de las cuales dependen productos clave de empresas y sistemas en organizaciones), de seguro están analizando en qué momento van a dar el salto desde Oracle (su proveedor actual de servicios MySQL), a una nueva empresa basada en el código de MySQL, probablemente, MaríaDB.

* Página de "Clientes" de MySQL AB con entradas sobre Twitter

* Twitter and us (habla de un crash) - May 29, 2008

* Haciendo Twitter 1000% más rápido - June 27, 2009

Este último menciona en un resumen lo que sería la plataforma de Twitter (y muchos datos muy interesantes), más o menos esto:

- Ruby on Rails
- Erlang
- MySQL
- Mongrel - hybrid Ruby/C HTTP server designed to be small, fast, and
secure
- Munin
- Nagios
- Google Analytics
- AWStats - real-time logfile analyzer to get advanced statistics
- Memcached

Fuente:

MariaDB, el grano en el culo de Sun-Oracle

Experiencias con Hyper-V y Windows Server 2008 Core

2010-02-28T15:33:00.000-08:00

Hace un par de semanas, estuve trasteando con un Hyper-V. Como pueden saber, comprando un Windows 2008 Server Enterprise, se posee licencia para correr legalmente hasta 4 (cuatro) instalaciones virtuales de Windows 2008 sobre un hypervisor Hyper-V.

No me interioricé fuertemente en Hyper-V más allá de este primer contacto porque arrancó como una experiencia piloto. Básicamente se instala Windows 2008 Server en modo "Core", es decir, sin interfaz gráfica, así que al loguearnos nos aparece una consola (cmd) y ahí tenemos que interactuar con la instalación recién realizada, acá viene la parte clásica de configuración del server y de networking (para poder empezar a hacer algunas cosas), luego hay que añadir el Rol de Hypervisor, para lo cual el instalador modo texto de Win08, se conecta a Internet a un sitio de Microsoft checkeando que el paquete de Rol Hyper-V de nuestro instalador (un dvd oficial), es el último disponible, y si no lo fuera, descarga automáticamente una nueva versión y la instala.

Parece que el modo de instalación y la consola pelada por default del server core 2008 es bastante áspera para la configuración inicial, por lo que me figuré que todo iba seguro por un tutorial rápido de Technet para ver qué comandos correr para configurar el servidor desde la consola cmd (por ejemplo, para darle una ip estática a la placa de red, netsh y argumentos; pero no se olviden de habilitar antes el firewall). La solución fue utilizar unos scripts .vbs con GUI modo texto (esas que se arman con un menú que sale de un while en loop infinito y hay que darle opciones numéricas para que ingrese en cada opción de la GUI), muy buenos, y que configuraron el server core en un par de minutos con 0 (cero) overhead de manejo profundo de comandos Win 08 Server.

Luego de correr los scripts, agregamos el Rol hypervisor al Core y Windows se descargó un paquete de un server oficial (la ip/host.dominio la manejó internamente, no hubo que cargar ninguna información), lo instaló y ya quedó el núcleo operativo principal del Windows Server 2008 Core + Hyper-V listo para ser accedido vía msc desde otra PC.

La GUI del hypervisor, de la que no recuerdo el nombre (ver en google "technet hyper-v gui tools"), es otra herramienta de descarga freeware desde algun reducto de microsoft.com y dominios amigos. Para funcionar requiere Vista o Seven en adelante (no XP), y por lo que pudimos ver en una demo rápida de una GUI ya instalada es bastante poderosa, es un rich-client con opciones un poco más granulares y detalladas que la GUI de administración de Vmware ESXi.

Hasta aquí todo perfecto, el problema fue que no teníamos en nuestro equipo cliente de administración ninguna dependencia de las que necesita la GUI de administración de Hyper-V, así que en un tun-tun, ida y vuelta, estuvimos bajando paquetes (.exe), de instalación de varias utilidades "base" (son dependencias, como en los rpm/deb de Linux), para esta GUI, yo tenía que irme y pude ver antes de salir del "laboratorio" que nuestro win admin iniciaba una descarga de 200.x MB con tiempo de download estimado en 40 min. y ahí me fui.

La conclusión parcial hasta ahora es: Hyper-V es poderoso, la GUI es excelente, los downsides de instalación son esquivables fácilmente (gracias a scripts como en Linux/*nix), pero parece que a Microsoft le falta mirar un poco a Vmware en cuanto a la instalación de la GUI administrativa.

En hypervisores ESX (y ESXi), que uso y tengo implementados en producción hace un par de años, luego de una instalación de 5-10 minutos, totalmente automática, el server hypervisor queda listo para funcionar. Para administrarlo, tenemos que ir a una página web (el instalador configura automáticamente un webserver), y descargar un cierto "setup.exe", compatible con plataformas win desde XP "1", pasando por service packs, hasta el último Seven; luego de un clickeo repetitivo estilo siguiente-siguiente, ejecutamos el ícono en el escritorio y llegamos al login del hypervisor. Eso es todo, nada adicional. Tiempo estimado de realización del procedimiento: 5 minutos (tardando más en descargar el .exe, que en instalarlo y llegar al login del ESX).

Por ahora me queda la sensación de que Hyper-V va a andar muy bien, aunque tiene un par de bordes sin pulir por ahí, aunque Technet puede ayudar muchísimo a suavizar el impacto de estos detalles sin afinar. Continuó luego con más info sobre estos temas.

Avanza el training de sysadmins..

2010-02-24T17:08:00.001-08:00

Primera Clase

El training para sysadmins comenzó el lunes, mucha teoría, por el lado de la autocrítica creo que comenzó un poco desordenado para el tipo de training al que estoy acostumbrado a asistir, pero por lo positivo rescato que solo tenemos 25 hs. (un poco menos incluso, restando las horas de la evaluación final), y no hay libro ni tutorial que permita llegar hasta un buen nivel en tareas administrativas relativamente básicas (package management, logical volume administration, etc.), que contemple menos de 150 a 250 hojas de explicaciones largas sobre infinidad de temas relativos a la administración, mayormente enfocados en detalles muy buenos de conocer, pero que se pueden aprender mejor luego si se da una buena base a los trainees.

La conclusión es que el primer tema lo planifiqué sobre lineamientos generales y lo expuse haciendo un pipe literal de mi memoria+experiencia a lo que decía y escribía en el pizarrón. El resultado fue al principio un poco entrecortado, pero después de un rato ya se empezó a ver cómo muchos trainees pasaban de pensar en Linux como algo semi-misterioso a verlo como si fuera una versión ligeramente más difícil de manejar que un Windows típico.

Segunda Clase

Hoy empecé a dictar el segundo tema, pero primero hicimos un raid rápido sobre algunas tareas necesarias para correr VirtualBox y realizar una instalación de SLES11 en una vm (virtual machine), al final VirtualBox pidió un cierto pam-devel que no existía en los dvds de instalación (?, lo estoy viendo..leer más adelante), así que suspendimos esa parte del práctico y avanzamos sobre el tema 2 en sí.

Está bueno darles a los trainees tareas miscelaneas a realizar, incluso aunque sea bajo supervisión, ya que van viendo que "hacer cosas complejas" en Linux está al alcance de cualquiera. En particular la gente configuró un repositorio remoto (configurado localmente en un webserver en el laboratorio), cargaron los paquetes de desarrollo para compilar aplicaciones (-devel varios, kernel-src y demás tools), conocieron de primera mano sus primeros comandos de consola (whoami, ls, etc.), hicieron algo de troubleshooting cuando vimos que varios no tenían configurada la placa de red y tuvimos que configurarla y ver que estuviera en línea y llegando un server remoto (yast, ifconfig, ping), se ubicaron en un uso real de los comandos, cuando necesitamos hacer o saber algo y corremos comandos para ello, finalmente se copiaron un archivo remoto vía scp y tocaron la superficie de las tareas típicas de adm. remota (ssh, puertos, confirmar aceptación de keys, entender que necesitan idenficarse con usuario/pass, que tienen que ubicar una pc remota por ip, etc.), descubrimos juntos que hay que ser preciso al escribir comandos, mayúsculas y escribir los nombres y paths tal como son, y varios ya empezaron a desarrollar su precisión al tipear, para ahorrar tiempo en correcciones.

El segundo tema arrancó con algo que me pareció un poco difícil para algunos trainees, ya que tenemos inscriptos que tienen poca experiencia con Linux (una instalación exitosa reciente o menos experiencia inclusive), el tema era "Grub" y nos fuimos con mc directamente a /boot/grub/menu.lst y el impacto fue considerable, especialmente gracias a los "disk-by-id" de SLES (con sus identificadores de dispositivo estilo kilométrico). Por lo positivo, muy bueno, por cierto, es que pasado el breve shock inicial y ya comentadas las diferentes secciones y la lógica de "menu.lst", todo se volvió una "pavada", bien por los novatos.

Después estuvimos un rato trabajando con Yast haciendo modificaciones simples a Grub, y luego mostré un poco el manejo de consola, y aunque grub-install.unsupported (el grub-install funcional de SLES), funciona, no grabé los cambios porque ya se hacía tarde y me había olvidado como se parametrizaba el disco destino (aparte de /dev/sda y similares) y no daba para googlear ni 3 minutos siquiera. En un momento, reconfiguramos Grub con Yast, rebooteamos la pc y tuvimos un error de "no hay boot record viable" típico de un MBR sin booteador...que fue otro ejercicio de troubleshooting inesperado cuando me corrigieron preguntandome si había un llavero USB conectado a la pc...era así en efecto, lo sacamos y Grub "volvió" a funcionar.

Hubo otro incidente que llevó al troubleshooting cuando pasó lo de pam-devel y el paquete de VirtualBox, buscamos en Yast el pam-devel y como no estaba, les conté que en el repositorio local solamente estaba cargado uno de los dos dvds de instalación de SLES, y que tenía la .iso del otro en un llavero USB, así que nos pusimos a pensar soluciones para el problema, finalmente salió el tema de "mount -o loop" para extraer directamente el .rpm de la imagen .iso...y averigûamos que no existía un pam-devel en ninguno de los 2 dvds de instalación (es un tema que estoy viendo todavía).

Luego de esto continué explicando el proceso de arranque, init, runlevels y demás, y fue bastante más teórico de lo que había previsto que fuera. Terminamos al filo de poder ya encarar los prácticos para el tema 2 en mayor profundidad.

Es cierto que elegí un enfoque ligeramente complicado al dictar un curso utilizando múltiples fuentes de información (varios libros, en inglés y español, y tutoriales), y especialmente al momento de tratar procedimientos y metodología para SLES al mismo tiempo que comento comparativamente los mismos temas, durante el desarrollo del curso, relacionando SLES, RHEL y Ubuntu LTS. A pesar de la dificultad incrementada de ese enfoque, estoy contento porque puedo ver en los trainees la cara de "entendí, era fácil al final", y lo era, solo que ese tipo de información no se puede sacar ni recitar desde una sola fuente de material escrito, ya sea comercial o gratuito.

Cuando terminé la clase, 17.10 hs. aprox., probé la técnica "martillo por destornillador" para el "tornillo" virtual que era el paquete .rpm de VirtualBox pidiendo una dependencia que no existía para SLES. Un cierto "rpm -ivh --nodeps paquete.rpm" y se instaló sin más problemas (ninguna salida de fallos en los scripts que compilan módulos de Vbox para el sistema por ejemplo), luego arranqué el programa y se ejecutó sin problemas, así que para la próxima ya vamos a ir con "--nodeps" si es que mi vm local no presenta mayores errores con el VirtualBox forzado.

El viernes termina la semana y ya están completados los materiales para los primeros 3 temas del curso, la documentación completa del curso está montada en un webserver privado en el laboratorio y la tiene el bedel encargado para los asistentes al curso. La tercera clase se perfila como la clase más práctica de todas y espero poder arrancar con el tema 3, adm. de software y mostrar la facilidad con la que se adm. aplicaciones en Linux, que podría ser una habilidad crítica para incentivar a los trainees a mejorar sus skills de administración.

Sysadmin Linux Trainings - UNNE 2010..arranca

2010-02-20T01:49:00.000-08:00

Ayer instalé los 16 servidores SLES 11 (Suse Linux Enterprise Server 11), que vamos a usar en el training en el Laboratorio Multimedial (aula Auxiliar), de la UNNE. Hasta anoche había 17 inscriptos, así que el lunes ya estaremos comenzando sin problemas.

La inscripción está abierta (!!!), hay lugares disponibles, aunque no muchos, si se apuran, les queda el lunes por la mañana para confirmar sus lugares. Luego de iniciado el training, tampoco habría problemas en inscribirse, solo que van a arrancar desde donde esté el grupo (les voy a dar una mano en lo posible y van a tener la documentación para leer).

Vamos a trabajar con 16 PCs AMD Phenom x2, 2GB de RAM y 160 GB de disco, DVDRW, 2 plugs USB frontales, etc., monitores LCD Samsung de 15' wide (1280x800 de resolución). Preferentemente la temperatura ambiente va a ser subcero :-), gracias a un split bien ubicado..(no pudieron faltar las fotos). Como se ve, tenemos un pizarrón de tamaño razonable, está puesta la mesa donde va el cañon, sin cañon, pero no se preocupen, hay uno por cada laboratorio por lo que todos los cursos van a tener siempre su propio cañon "online".

Ya conocí a un par de los trainees ayer y me reencontré con amigos de la Comunidad TIC, pero todavía no ví la lista de inscriptos, así que nos veremos todos el lunes recién. Ví bastante movimiento con el encargado del Laboratorio con respecto a las inscripciones así que creo que varios de los cursos van a tener buen nivel de asistentes.

También me preguntaron por el nivel del training para Linux: definitivamente avanzado. No es lo que pueden suponer muchos al ver "cron" o "adm. de paquetes" en el temario, pero recuerden que la orientación es entrenar a futuros administradores de sistemas, por lo que estas tareas se dan siempre en profundidad y pensando en deployments enterprise, no en instalaciones home.

Empecé a instalar los servers a las 18,46 hs. y terminé a las 21.50 hs., básicamente tenemos unos 9 GB por servidor dedicados a SLES11, una swap mínima, 500 MB (no hace falta más, si quieren saber por qué, los espero en el training..o miren en google), una partición raíz (/) de 8.5 GB con 5 GB libres de momento.

Realicé un deployment básico, el esqueleto funcional típico de un SLES11, con GUI Gnome y apps de trabajo; no es una instalación mínima, sino lo que necesitaremos. A medida que avance el training iremos agregando funcionalidad a los servidores.

Ví el poder de procesamiento y storage de los equipos y casi de seguro estaremos sacando partido del mismo de múltiples maneras..pero eso ya es parte de las sorpresas para los trainees.

El mail para inscribirse (y despues tendrían que ir a confirmar su lugar, ya durante la mañana del lunes), es cursosveranofacena@gmail.com

Cursos de Verano UNNE 2010, Adm. de Sistemas Linux

2010-02-15T05:11:00.000-08:00

Está abierta la inscripción a los cursos de verano 2010 de la UNNE-FACENA, pueden consultar la información en la página de los cursos.

Para consultas e inscripción: cursosveranofacena@gmail.com

Hay 25 lugares para cada curso, las aulas están climatizadas y no está demás decir que hay pocas ofertas de cursos de administración de sistemas con tanto contenido/hs. de dictado en tan poco tiempo (25 hs. de curso en menos de 3 semanas).

El dictante: Dardo Valdez
http://ar.linkedin.com/in/dardovaldez

co-Responsable de Infraestructura IT y administrador de sistemas para el Poder Judicial, Pcia. de Ctes.

Se desempeña a diario en una infraestructura de redes y servidores en continuo crecimiento; un stack de servicios IT de misión crítica en un ambiente multiplataforma complejo.

En noviembre 2008 asumió la responsabilidad directa de la administración de todos los servers en la infraestructura; 50+ servers, 500+ servicios en toda la pcia. y en varios datacenters remotos.

El resumen oficial (publicado por la UNNE para el curso)

Título: Administración de Sistemas Linux

Dictantes: Dardo Augusto Valdez, Lic. Paola Insaurralde

Objetivo: Brindar los conocimientos básicos para administrar sistemas Linux en servidores.

Contenidos: Implementación y Adm.de Linux en Ambientes de Servidor. Buenas Prácticas de Implementación y Administración de Sistemas. Administración de servicios. Instalación y Administración de Software. Compilación e Instalación de Software. Administración de Usuarios y Grupos. Administración de Almacenamiento. Técnicas de Trabajo y de Resolución de Problemas.
Implementación y Administración de un Servicio de Compartición de Archivos. Implementación y Administración de un Servidor Web con soporte PHP y conexión a Base de Datos. Implementación y Administración de un Servicio de Proxy Caché.

Metodología: Encuentros presenciales con exposiciones teóricas y desarrollo de ejemplos prácticos, ejercitación en la modalidad "frente a la máquina". Requiere conocimientos de sistemas operativos, de preferencia sobre Linux.

-----------------------------------------------

Carga Horaria:
24 hs. totales distribuídas en 8 clases de 3 hs. Cada una.

Días y horarios:
Lunes, Miercoles y Viernes, de 14.00 a 17.00 hs.

Costos:
- Profesionales: $150
- Personal UNNE (docentes y no docentes): $120
- Programadores y analistas (pregrado universitario): $90

Requisitos:
El nivel del curso es intermedio a avanzado y está orientado a estudiantes avanzados, profesionales de informática y en general personas con experiencia previa en sistemas operativos de nivel operador avanzado.

Para realizar efectivamente el curso se recomienda tener experiencia el uso de Linux como sistema operativo de uso diario y hogareño.

Documentación oficial del curso:
La documentación oficial del curso está en idioma inglés:

Pro Linux System Administration, Apress
Copyright © 2009 by James Turnbull, Peter Lieverdink, Dennis Matotek
ISBN-13 (pbk): 978-1-4302-1912-5
http://www.apress.com/book/view/1430219122

La documentación basada en "Pro Linux System Administration" también provee la ventaja de organizar temáticamente las habilidades de administración, a diferencia de otra documentación focalizada en distribuciones particulares.

Documentación en español:
La documentación en español va a estar disponible por tema a dictar, sin dejar de documentar ninguno, en forma de lecturas recomendadas de diferentes fuentes, con copia electrónica local disponible para los asistentes.

Las lecturas recomendadas van a ser un acercamiento conceptual al 90% de lo disponible en el libro en inglés, con las obvias posibles diferencias al ser información de fuentes distintas.

Algunos libros en español a utilizar son:
- Implementación de Servidores GNU/Linux, Alcance Libre, 2009
- Administración de Sistemas Linux, Anaya, 2007
- Linux Server. Los Mejores Trucos, Anaya, 2006
- Administración Avanzada de GNU/Linux, 2004
- Unix y Linux. Guía Práctica, 3ra. Edición, Ra-Ma, 2004

Distribución y portabilidad de habilidades a adquirir en el curso:
La distribución a utilizar en el curso será Suse Linux Enterprise Server - SLES 10 SP2.

La documentación oficial del curso abarca explicaciones teóricas aplicables a cualquier distribución, ello también se da en los procedimientos prácticos de consola (CLI). Por otra parte, la documentación oficial está focalizada en Red Hat Linux Enterprise (RHEL) Server y Ubuntu y ello se refleja en algunos procedimientos listados en el libro, vía interfaz para RHEL y en explicaciones particulares de procedimientos de consola para Ubuntu.

Se eligió la distribución y la documentación de modo que los asistentes adquieran un conocimientos de Red Hat y Ubuntu, a la vez que aprenden y trabajan sobre SuSE, de ese modo, transparentemente van a ir adquiriendo la noción de portabilidad de las skills entre distribuciones, y cuales pueden ser sus mínimas diferencias.

Temario:

Instalación de Linux
- Recomendaciones hardware
- Instalación básica de Linux

Inicio y servicios
- Entendiendo el adm. de booteo Grub
- ¿Qué sucede luego de bootear?
- Administrando servicios
- Agendando servicios y comandos con cron

Administración de paquetes
- Introducción a la adm. de paquetes
- Adm. de paquetes en Opensuse Linux
- Compilando desde código fuente

Usuarios y Grupos
- ¿Qué sucede cuando te logeas?
- Trabajando con usuarios y grupos
- Controlando el acceso a tu host
- Más acerca de sudo

Compartición de archivos e impresión
- Samba

Administración de almacenamiento y recuperación de desastres
- Básicos de almacenamiento
- Usandos Sistemas de Archivos
- Recuperación desde fallas

Otros
- Acceso Remoto
- Sistema y archivos
- Trabajando con archivos

Servicios SQL y Web
-Apache Web Server
- MySQL
- Instalando sitios web
- Squid Cache

Suspender temporalmente screensaver en KDE SC 4.3

2010-01-14T04:02:00.001-08:00

A veces estamos trabajando sobre varias computadoras simultáneamente y no queremos que el screensaver bloquee en ningún momento la pantalla de una que no estamos atendiendo, menos aún si se bloquea el acceso al escritorio al ejecutarse el screensaver (una medida de protección típica).

Con el comando:

qdbus org.kde.krunner /ScreenSaver SimulateUserActivity

Se puede simular actividad del usuario y por lo tanto el screensaver no entrará en funcionamiento ni bloqueará la pantalla si se corre este comando cada cierto intervalo menor que el tiempo máximo de espera para activar el screensaver (unos minutos normalmente).

Una posibilidad manual rápida es correrlo con watch:

watch -n 120 qdbus org.kde.krunner /ScreenSaver SimulateUserActivity

Que correrá el comando automáticamente cada 2 minutos; si nuestro screensaver está configurado para activarse en 3 minutos, no lo podrá hacer mientras esté corriendo este watch.

Otra posibilidad es usar un script que podamos invocar desde un ícono en el escritorio. El script sería así:

### copiar desde aquí ######

#!/bin/sh

if [ -f $HOME/.screensaver-suspendido ]

then

rm -f $HOME/.screensaver-suspendido

killall screensaver-suspendido.sh

else

touch $HOME/.screensaver-suspendido

while true; do

qdbus org.kde.krunner /ScreenSaver SimulateUserActivity

sleep 120

done

exit

### copiar hasta aquí ######

Lo creamos con un editor de texto (kwrite, etc.), en un lugar del PATH (en $HOME/bin por ejemplo), con el nombre "screensaver-suspendido.sh" (se lo pueden cambiar, pero modifiquen el script con el nuevo nombre), y damos los permisos de ejecución apropiados (chmod +x $HOME/bin/screensaver-suspendido.sh).

Uso del script

Si lo corremos una vez, activa la suspensión del screensaver, si lo corremos una 2da. vez, desactiva la suspensión. Es ideal para usar dentro de un ícono en el escritorio.

Explicación del script

El script busca un archivo de referencia ".screensaver-suspendido" en nuestro $HOME (típicamente sería un cierto /home/nombre-de-usuario), el "." delante del nombre es para que no aparezca listado en Dolphin u otros administradores de archivos. Si lo encuentra, lo borra y mata cualquier proceso con el nombre del script (lo que sería un apagado factual del programa). Si no encuentra el ".screensaver-suspendido", entonces lo crea y luego corre el comando qdbus en un loop - infinito - que lo ejecuta una vez cada 120 segundos.

Que les sea util.

Algunas pavadas escritas sobre KDE4 SC

2009-12-27T18:19:00.000-08:00

Leí recién un thread en OSnews de los editores del site pidiendo opiniones, y leí hasta que me cansé de leer cosas inexactas, subjetivas o muy cortas de miras.

"OSNews Asks: Your KDE4 Experiences"

http://www.osnews.com/story/22662/Your_KDE4_Experiences

Algunas ideas generales sobre las quejas para KDE4 del usuario no avanzado y sus respuestas objetivas - o mi mejor intento al menos:

* La inestabilidad de KDE4 en general.

La gente que critica no usa ninguna de las distros conocidas por tener una implementación muy buena de KDE4 (Mandriva, Opensuse, Archlinux, etc.), y suele usar Kubuntu, que al momento es conocida - vox-populi en la red - como la peor implementación de KDE4 (hasta la última versión estable).

Otros comentarios hablan opinando sobre versiones anteriores, KDE 4.2 fue relativamente buena, sin embargo la 4.3.x es un salto bastante largo en bug-fixes y estabilidad gral. (se verifica en los listados de bug-fixes oficiales, un par de miles); esto es muy significativo si consideramos que es la 2da. versión estable a nivel código liberada (4.0 no cuenta porque casi era una beta, 4.1, 4.2 y .4.3).

Los usuarios conocedores de KDE en general reportan que la estabilidad es excelente, y prácticamente no se dan cuelgues de la interfaz si se trabaja sin Compiz.

* La inestabilidad de Compiz habilitado en KDE4.

La implementación de KDE4 de compiz hasta el momento no parece ser muy buena. En algunos casos funciona perfectamente, y en otros no se comporta ni medianamente bien. Si se usa KDE4 sin efectos habilitados, sin compiz, la estabilidad regresa y se mantiene en un muy buen nivel.

Por otra parte, los usuarios están acostumbrados a usar implementaciones de compiz bastante estables, como la de Gnome por ejemplo, y lo hacen con los drivers que tengan a mano, lo que no funciona siempre con KDE4. Los problemas en particular parecen empeorar usando drivers libres de ATI y NVIDIA (lo que es un tema a arreglar evidentemente).

Este tema en teoría se está trabajando y muchos usamos KDE4 con compiz sobre NVIDIA y ATI+ drivers propietarios sin problemas y tuve dos cuelgues en 3 meses de uso con KDE 4.3.2. Otros usan placas INTEL (notebooks mayormente), sin mucho problema.

* Muchas quejas tienen que ver con la filosofía de KDE4, no con la estabilidad u otro factor técnico.

Aquí de vuelta volvemos a la vieja pelea Gnome/KDE, muchos usuarios prueban KDE4 y lo encuentran "mal" solo porque no se ve como Gnome. En este punto parece caber el recordar que para eso tenemos opciones...en fin, la filosofía de diseño de KDE4 tiene características que lo hacen deseable como GUI para muchos usuarios, para otros no. Típicamente los usuarios avanzados encuentran en KDE4 las opciones que buscan y los usuarios que recien ingresan optan en su mayoría por Gnome y otros entornos más simples de manejar.

Cabe la aclaración de que hay usuarios avanzados que eligen Gnome tambien, mayormente por una cuestión de estabilidad y predictibilidad del comportamiento de la GUI, por ejemplo, porque no se va a colgar en el medio de una sesión de comandos remotos vía ssh.

* El arranque lento y el apagado lento en KDE4.

Otro tema para trabajar, como siempre, al comienzo, KDE4.0/.1 y .2 el arranque fue bastante rápido, mucho más que en KDE 3.5.x; ya en 4.3.x notamos que el arranque iba un poco más lento sin motivo aparente hasta que empezamos a ver que internamente KDE4 ha iniciado la adopción de varias tecnologías que requieren cargar componentes al arranque y de ahí tenemos cierta lentitud. ¿Cual es el nivel aceptable de "lentitud"? Es algo muy subjetivo, normalmente viniendo de un entorno de carga rápida, LXDE o XFCE, KDE 4.3.x puede parecer sumamente lento, comparado con Gnome, el tiempo de carga es mayor, pero no mucho más de 2 o 3 segundos (una eternidad para la percepción en muchos casos).

Conclusiones

En gral. las quejas vienen de usuarios poco experimentados y que no tienen un background IT fuerte, usuarios hogareños típicos acostumbrados a utilizar entornos estables como Gnome, XFCE y otros, casi todos con muchos años de depuración de bugs y con base de código muy depurada, lo que no es el caso de KDE4 al momento.

A futuro sin embargo, KDE4 se muestra muy fuerte habiendo implementado ya en estas versiones iniciales mucha tecnología innovadora y con más mejoras por venir, y a poco menos de 2 años de su reescritura completada - la 4.0 se liberó un 11 de enero de 2008 - y si tenemos en cuenta que el equipo de desarrollo de KDE considera la versión 4.1 como la primera versión estable - liberada en julio de 2008 - estamos hablando de un entorno gráfico completo - como Gnome - pero escrito prácticamente desde cero (en la mayoría de sus módulos de bajo nivel es exactamente así), con no más de un año y medio de desarrollo.

Realmente muchos comentarios negativos se dan siempre en versiones iniciales; en particular recuerdo que hace unos años usaba Gnome 2.x y lo compilaba desde código, desde GTK y librerías hasta las aplicaciones, por lo que normalmente estaba a tono con la última subversión liberada - con todas las mejoras y bugfixes incluídos - a diferencia de los usuarios que trabajaban con versiones precompiladas y viejas de las distros (por ejemplo una 2.0.1 vs. la última 2.0.34), y siempre leía comentarios poco fundados y alagûeños sobre el futuro de Gnome, y que al igual que ocurre hoy con KDE4, no eran ni por lejos lo que se pensaba en la comunidad de usuarios avanzados y desarrolladores de Gnome 2.0.x ni es lo que se piensa puertas adentro del desarrollo y de la comunidad de usuarios avanzados de KDE4.

http://www.kde.org/announcements/4.0/

http://www.kde.org/announcements/4.1/

Contra las distros personalizadas

2009-12-18T06:00:00.000-08:00

Estoy leyendo de otra distro personalizada más, acá:

PorteSur Linux 1.0
http://www.vivalinux.com.ar/distros/portesur-linux-1.0

Los entusiastas de Linux decían/decíamos hace algun tiempo que era algo bueno que salieran nuevas distros, especialmente cuando algunas populares como Mandrake, Conectiva, RedHat, etc. iban desapareciendo sin herederas fiables en principio (después aparecerían firmes Mandriva, Fedora, etc.).

Ahora las cosas se descontrolaron un poco, IMHO, realmente hay buenas distros y el ciclo natural que se da desde hace años hace que cuando desaparece una buena distro, aparece otra y la reemplaza, tal el caso de WhiteBox (clon de RedHat Enterprise) y CentOS (incluso en las primeras versiones de CentOS se podía migrar aplicaciones casi sin cambios desde WhiteBox).

Ahora bien, está de moda "sacar un Linux" como proyecto "importante" cuando algun ente quiere "hacer algo con el software libre"; son estatales últimamente, algunos académicos, y especialmente tienen su origen en áreas geográficas donde Linux recién está empezando a ganar auge y tambien donde no se maneja mucho los idiomas inglés, alemán y un par más de los más usados por los developers de distros grandes, como Ubuntu, Fedora, Opensuse, etc.

IMHO y por mi experiencia, las distros "sacadas" por X universidad, ONG, Drugstore 24 hs., etc. desaparecen sin dejar rastros al poco tiempo, con suerte duran un par de años. Aún si duran, el soporte a los usuarios suele ser mediocre a inexistente, ni hablar de ello si es que la distro está fuertemente scripteada y personalizada, casi ninguno de los que suele "manejar" los foros de soporte llega a entender totalmente qué hizo "el linuxero" que armó la distro, que a veces es un empleado contratado por obra, 3 meses (en Argentina) y que usó scripts implementados según lo que le pedía la "autoridad" y según lo que buscaba el proyecto.

Ni hablemos de updates de seguridad regulares o updates de aplicaciones con fallos/bugs, ya que las mejoras y parches se "incluyen" - solo - dentro de las nuevas versiones de la distro "sacada", es decir los updates de seguridad se instalan cada vez que sale una versión nueva, digamos, cada 6 meses o un año.

Conclusión, si tienen ganas de aportar o usar software libre, o tienen ganas de adoptar software libre dentro de sus instituciones, entes, etc., traten de usar distros populares (Ubuntu, Fedora, etc.), y dejen de crear distros inmantenibles, que solo conocen realmente cómo está armada 3 personas y los demás son "fanáticos" que quedan solos y sin distro cuando se termina el "proyecto" (o cuando se acaba el subsidio que consiguió el funcionario que "encabeza" el proyecto, o cuando el funcionario que impulsó el proyecto consigue el ascenso que estaba buscando, etc.).

Por otra parte si tienen ganas de aportar al software libre, lo mejor es sumarse a los equipos de trabajo de las distros, o en su defecto, sumarse a los equipos de trabajo de algun software libre en particular, todo eso en vez de crear una distro.

Una posibilidad realista en cambio es armar repositorios de aplicaciones puntuales para ser implementados dentro de la distro que se va a usar, de ese modo de puede llegar a construir un repositorio que fácilmente puede personalizar un Ubuntu, Opensuse, Fedora, Mandriva, etc. (todas ellas soportan repositorios y tienen auto-resolución de dependencias, es decir funcionan igual que Ubuntu+apt). Así tendríamos algo mucho más fácil y factible de mantener, por ejemplo, un tema de escritorio para Gnome (wallpaper, íconos de aplicaciones por defecto en el escritorio, colores de la interfaz - que pueden ser los colores propios del ente), algunos programas a instalar para brindar la funcionalidad que se busca que tenga la distro para el ente/institución (si es un depto. de Matemáticas, podría tener apps útiles para hacer matemática, etc.). Inclusive, casi todas las distros mencionadas soportan el uso de un solo "meta-paquete", un solo .deb o .rpm que al ser instalado, automáticamente invoca la instalación de un grupo completo de otros paquetes y sus dependencias. Las dependencias suelen ser automáticas y se bajan casi siempre directamente de los repositorios oficiales de la distro, que incluyen cosas signficativas como parches de seguridad por ejemplo, siempre uno de los puntos débiles de las distros "sacadas".

Otro opción muy interesante en distros, que se está dando ahora por suerte, son pequeñas personalizaciones de distros populares, es decir, la distro de base es la misma, un Ubuntu por ejemplo, pero un grupo de gente lo customiza un poco y tenemos Linux Mint, que tiene algunas características propias pero básicamente es casi lo mismo que si instalaramos un Ubuntu más algunos paquetes adicionales.

Digamos que si llegáramos a implementar Linux Mint - siguiendo el ejemplo - y de repente se suspende su desarrollo y dejan de sacar nuevas versiones, no hay problema, en la siguiente etapa o en nuevas máquinas a implementar se puede usar Ubuntu sin problemas.

Se gana el que los que participan del proyecto ya van a saber usar casi de seguro las herramientas de Ubuntu y no va ser un problema abandonar Linux Mint (incluso puede que con un par de golpes de apt-get se convierta a los Linux Mint en puros Ubuntu sin mucho inconveniente).

Bueno, basta de "distros basura" que duran 1 año o 1 mes. Ah, y las distros que sacan "nuevas versiones" y que no tienen nada que ver una con la otra (una basada en Slackware y la más nueva basada en Opensuse por ejemplo), tampoco sirven para mucho en la vida real por cierto.

Gnome podría dejar de ser un proyecto GNU

2009-12-12T14:32:00.000-08:00

De vuelta me encuentro escribiendo sobre Gnome, después de varios años de no usarlo. Resulta que Miguel de Icaza tiene un blog personal, donde publicó un artículo que luce exactamente igual a publicidad técnica de primera, impulsando el uso de Silverlight (el reemplazo propietario de Microsoft de Flash), como herramienta para crear aplicaciones desktop completas - no solo web apps - y multiplataforma.

Este artículo fue publicado luego en PlanetGnome - http://planet.gnome.org/ (que es inaccesible al momento por mantenimiento), que recoge automáticamente los posteos de los blogs de sus afiliados, por ejemplo, Miguel de Icaza.

RM Stallman hizo un comentario bastante moderado en una lista sobre que el Proyecto Gnome debería colaborar mínimamente al ser un proyecto GNU oficial y no dejar que en sus sitios - como el blog aggregator PlanetGnome - se hable y se presente software propietario como "legítimo", es decir como una opción viable dentro del software libre.

Parece muy razonable el pedido, pero en medio de la conversación sobre el tópico, algunas voces se fueron de 1 a 10 en un segundo y en este momento hay una discusión de fondo en la red y de seguro en privado, entre miembros del Proyecto Gnome. La discusión comenzó con la propuesta de separar el Proyecto Gnome del proyecto GNU (http://mail.gnome.org/archives/foundation-list/2009-December/msg00054.html).

De aquí en adelante, todo se desbandó en la red y estamos recordando por qué comenzó Gnome, se habla de KDE, se habla de la historia de cómo llegó el Proyecto Gnome hasta donde está, etc.

"Gnome to Split Off from GNU Project?"
http://www.pwnage.ca/?p=433

"GNOME Developer Suggests Split From GNU Project"
http://linux.slashdot.org/story/09/12/12/135209/GNOME-Developer-Suggests-Split-From-GNU-Project

La lista de correo y PlanetGnome están caídos o completamente colapsados al momento, así que difícil entrar en cualquiera de los dos para recoger la historia in-situ, que de seguro la veremos en frío en las próximas horas.

En particular recuerdo que cuando usaba Gnome, lo compilaba completo desde las fuentes, persiguiendo pequeñas mejoras que iban surgiendo subversión a subversión (esto es, disponible a a partir de X.X.2, pero no en la X.X.1). En este punto, Gnome estaba en 2.1.x y se veía bastante parecido a lo que es ahora incluso, pero había muchas menos aplicaciones disponibles. Fue en este momento en que surgió una gran movida interna, que promulgaba la simplificación del escritorio, que tuviera menos opciones, que se estudiara qué hacía falta y era indispensable y que todo lo demás se descartara.

El trasfondo del pedido tenía un asidero claro, el Proyecto Gnome, aparte de desarrollar el entorno gráfico, también desarrolla sus librerías base, GTK y derivadas, y GTK por ese entonces se estaba comparando funcionalmente y a mediano plazo como una alternativa no muy deseable frente a QT, la librería base de KDE. Ya en ese momento la escasa amplitud de funcionalidades, características y opciones de las aplicaciones GTK en general con respecto QT+KDE, empezaba a promover la pregunta de si hacía falta tener tanto poder de codificación divido en dos proyectos diferente buscando la misma cosa.

QT+KDE por su parte ya saltaban de versión por primera vez, y la comunidad empezaba a mostrar que era capaz de recodificar completamente KDE desde cero, y crear un escritorio nuevo (tal como lo hicieron de vuelta en KDE4); al mismo tiempo las apps QT/KDE creadas dentro del proyecto KDE eran en ese momento histórico mucho más funcionales comparativamente hablando, que las apps GTK creadas dentro del proyecto Gnomė (asi que no intervienen ni Firefox, ni OpenOffice en este tema).

La salida del proyecto Gnome funciono bien, y luego de un tiempo el escritorio empezo a brillar en parte gracias a la solidez de un codigo bastante viejo y sumamente estable, a la aparicion de nuevas apps y al exito de Gnome como herramienta libre a ser utilizada en proyectos propietarios, gracias a la licencia LGPĿ

La movida del proyecto Gnome habia anticipado el que la libreria QT dejara su licencia propietaria para ser GPL primero, y luego LGPĻ igualando legalmente y como software libre completo a la libreria GTK.

Mas o menos en la mitad de esa historia me encontraba usando Gnome y más o menos un 90% de aplicaciones QT/KDE dentro de Gnome, por ejemplo K3b, Opera (solo QT), Krusader, Amarok, etc. Así que dí el salto a KDE y no miré atrás.

Sí fui leyendo de a ratos sobre la evolución de Gnome y fui viendo como lentamente el clon libre de .NET, el framework Mono iba ganando popularidad dentro del proyecto Gnome, hasta que se llegó a incluir dentro del pack de software oficial de Gnome. Hace poco surgió Silverlight, la tecnología de reemplazo de Flash que más bien funciona como reemplazo de Adobe Air, y ahora ya se ve a Silverlight, en su implementación libre, Moonlight, como un firme candidato para se incluído a largo plazo dentro de Gnome. La idea es la de siempre aparentemente, potenciar la aparición de muchas aplicaciones dentro de Linux, y de Gnome particularmente, utilizando un motor de ejecución compatible al 100% con aplicaciones programadas para correr en Windows.

Realmente es una opción técnica excelente, con tremendo potencial para el escritorio, mucho mayor que el ahora caído en desgracia en el desktop, Java. Sin embargo, el problema con Mono y con Moonlight es que penden literalmente de un hilo legal. Son reimplementaciones - de código - realizadas sobre tecnología patentada, lo que pone serias dudas a si en el futuro - en cualquier futuro - Microsoft no decidirá salir de su actual posición benevolente y simplemente impedir que se contínue utilizando gratuitamente sus patentes.

Los adeptos a Mono y Moonlight aducen que ambos son proyectos nacidos en el mismo espíritu de Linux, como una reimplementación de tecnologías propietarias y patentadas (UNIX). Y así sigue la polémica Mono-.NET-Silverlight-Moonlight.

Veremos como sigue la historia en las próximas horas...

Revisión del upgrade de Opensuse 11.1 a 11.2 RC2

2009-11-03T15:54:00.000-08:00

Hace un rato terminé de testear la nueva característica de actualización de distro desde Opensuse 11.1 a 11.2 RC2 + updates, unos 7 días de updates desde la liberación de la RC2, 2+ GB de download y unos 96 MB extra de espacio en disco ocupado, adicional a lo que ya estaba ocupado, luego del upgrade.

Todo anda bien, el upgrade respetó la correspondencia de paquetes conflictivos, por ejemplo, los rpms que tienen los drivers wifi bajados de un repositorio alternativo (es decir que sigo teniendo wifi), se actualizó todo el backend del sistema operativo, librerías base y librerías accesorias (python, perl y demás); se actualizaron por completo Gnome (de 2.26 a 2.28, la última estable), y KDE 4 (ya tenía el 4.3.2, básicamente se instalaron los mismos paquetes pero compilados para Opensuse 11.2, con el nuevo compilador gcc, al que le pusieron un par de parámetros de optimización, etc.

Hice el upgrade desde consola, después de cargar los repos online, cargué la .ISO de la RC2 también como repositorio local de paquetes, pero no tuvo mayor incidencia en el download, dado que las versiones de paquetes están avanzando rápidamente - en pequeños e insignificantes incrementos - hacia las "versiones" finales que saldrán en días con Opensuse 11.2 Final (básicamente son saltos de números de subversión por nuevas compilaciones que se dan cuando se incorpora algun componente que requiere la recompilación de algun paquete..algo así como soft-ejemplo-2.34.2 a soft-ejemplo-2.34.3, y ese cambio insignificante requiere un download, en vez de usar la versión en disco 2.34.2 por ejemplo).

Todo funciona como rejoj, la verdad se nota que la característica de upgrade se está perfilando como método estándar de actualización de las versiones comerciales de Opensuse (Suse Linux Enterprise Server).

En cuanto a los repositorios, ya encontré varios repositorios extra "oficiales-no-oficiales" (los mantiene -pone plata e infraestructura para sostener los servers de donde se descargan, gestionan mirrors, etc. - el proyecto Opensuse y Novell, pero esos paquetes no tienen soporte comercial comprable a Novell); estos repos los puse también junto a los repos oficiales de instalación y el distro-upgrade tomó los paquetes del repo no oficial y los incluyó en el proceso de actualización de la distro y los instaló, en vez de instalar alguna versión mínimamente menos actualizada que hubiera en los repos oficiales (por ejemplo, la mayoría de los paquetes de módulos de php5 y varios mod de Apache2).

Ahora el sistema tiene todo el esquema de booteo de Opensuse 11.2, tendría que bootear más rápido que antes, no lo probé aún (igualmente no hay modo de ganarle a la vuelta de suspensión a disco, que tiene el sistema completo reactivado en menos de 10 seg. con mi hardware prehistórico, que es lo que usé habitualmente sin ningun problema durante un año con Opensuse 11.1).

El zypper dup (zypper distribution upgrade), respetó el kernel instalado, un cierto Desktop kernel con parches no oficiales para mejorar la reactividad (algo así como un real time kernel, pero no "tan" real time), y así el kernel desktop sigue instalado, igual que sus fuentes, integrado al nuevo esquema de scripts de booteo (eso se debe probablemente a que el paquete del kernel altternativo es un paquete no oficial, pero incorpora todas las facilities - scripts de pre-post instalación - típicas de un kernel opensuse standard); así pude restaurar mi driver nvidia en un par de enters, previo a volver a KDE 4.3.2.

Por cierto que corté el upgrade a la mitad - un CTRL+C clásico - cuando iba más o menos al 80% del mismo - me dí cuenta al rearrancar el proceso - más tarde arranqué de vuelta la máquina, entré a consola, apagué X (por las dudas, ya que igualmente había booteado sin problemas hasta el runlevel 5,, con un driver VESA y en el KDM de 4.3.2), y luego volví a arrancar el upgrade, de vuelta "zypper dup", un nuevo análisis, me informó de vuelta cuantos MBs iba a bajar de Internet y cuanto espacio iba a ocupar una vez instalado en disco, le dí "yes" y el upgrade se completó sin incidentes, ni siquiera un mensaje de "éxito", solo terminar y de vuelta al prompt de consola.

El zypper nuevo de Opensuse 11.2 cuenta con la posibilidad de configurar la descarga e instalación de paquetes, incluídos los paquetes de un upgrade de distro, de varios modos. Un modo es por ejemplo, descargar todos los paquetes, antes de instalarlos, así por ejemplo, podría ir a un cybercafé, o a la casa de un amigo, descargar todos los paquetes necesarios, incluso podría ir descargándolos en varias veces, luego podría - o no - hacer el upgrade a la distro de mi máquina, y luego, con otra característica de zypper habilitada, conservaría los paquetes bajados.

Luego de eso es cuestión de cargar el directorio local en la instalación de Opensuse 11.1/2 que se quiera upgredear.

Como nota, el update de paquetes estándar de Opensuse 11.1 ya carga el nuevo zypper en la versión 11.1, así que si actualizamos nuestro actual Opensuse 11.1 con los últimos updates, ya podremos utilizar las características mencionadas, incluído el upgrade.

Bueno, es todo por ahora, sigo testeando.

Opensuse 11.2, upgrade de distribución y más sobre lo nuevo

2009-11-01T03:40:00.000-08:00

Bueno, de vuelta bloggeando después de unas semanas. Voy a ir subiendo unos posteos que hice en algunas listas, pero mientras hago este...

Hay mucho revuelo en la comunidad de Opensuse por el próximo lanzamiento de la versión 11.2 en pocos días.

Upgrade de la distribución

La nueva característica de upgrade de distribución de Opensuse 11.2 va a hacer que muchas instalaciones de servidores basadas en Debian y Ubuntu se pasen a Opensuse. Ya en su momento, la posibilidad de hacer updates centralizados se había adquirido al usar "zypper"; sin embargo muchos sysadmins que no usan distros empresariales que incluyen constantes actualizaciones y services packs regulares (que en los hechos mantienen a un SLES actualizado a nivel de la última versión estable de todo el software de Suse/Novell portable a la versión de SLES según las librerías disponibles), no encontraban suficiente incentivo en usar un Opensuse semestral (se publicaba una nueva versión cada 6 meses, a partir de Opensuse 11.2 se publica cada 8 meses), y con ciclos de soporte de 2 años o 4 versiones más o menos versiones (mm, creo, vean www.opensuse.org), eso llevaba a que, para mantener la distro a buen nivel de tecnología y vigente para el nuevo software a instalar, hubiera que reinstalar y migrar la distro completa junto con las aplicaciones implementadas cada cierto tiempo menor a 2 años a lo sumo.

En cambio al utilizar Ubuntu o Debian, y poseer una herramienta fiable de actualización resulta/ba mucho más conveniente instalar un Ubuntu (un server LTS mejor aún), o Debian e ir manteniendolo actualizado, dando pequeños upgrades en cada nueva versión. Desde la primera RC (Release Candidate), de Opensuse 11.2 ya se puede realizar este upgrade de distro fiablemente desde una versión a la siguiente (11.1 a 11.2 y luego serán entre saltos de versión, 11.2 a una hipotética 11.3, y así sucesivamente).

Esta característica de upgrade de distro no está disponible aún en la versión comercial SLES11 (es dudoso que se implemente en las SLES10 - con 2 service packs al momento - menos aun en las SLES9 - con cuatro service packs hasta ahora), así que no hay modo de saber como lo van a implementar, aunque presumiblemente los saltos de upgrade serán posibles entre el último service pack aplicado y la versión más reciente a continuación.

Creo que muchos sysadmins van a incorporar Opensuse como distro a proponer para implementaciones empresariales por el simple camino (en casi todo, capacitación y certificación, licenciamiento, soft testeado/implementado, soporte para soft a implementar, adquisición de soporte, etc.), que implica pasar desde un Opensuse a un Suse Linux Enterprise Server (que es muy parecido a lo que se puede hacer hoy con CentOS y Red Hat Enterprise Linux). Sería muy interesante a futuro que los SLES y Service Packs siguientes incorporaran características de validación de paquetes/versiones y la capacidad de llevar un Opensuse a un SLES.

Aquí tienen el link de pedido de la funcionalidad, el check de añadida a la distro y la explicación de cómo va a funcionar:
https://features.opensuse.org/305634

Nuevas Características

Otras nuevas características de 11.2 son el uso por default de EXT4 y la inclusión en producción real de KDE4 (4.3.2).

EXT4

No hay mucho que decir sobre EXT4, aparte de los detalles de "mejor y más rápido", pero para administradores, leer esta página es mandatorio:
http://kernelnewbies.org/Ext4

KDE 4.3.2

Muchos developers de KDE4 trabajan directamente para Novell y muchos activos participantes del proyecto KDE usan Opensuse desde tiempo atrás, por otra parte la comunidad de Opensuse se "siente" masivamente usuaria de KDE, y por ello se decidió que KDE fuera la opción por defecto seleccionada en la instalación, aunque justo al lado de la opción preseleccionaada está disponible la opción de Gnome en una implementación impecable de Gnome en Opensuse (el creador de Gnome y Mono trabaja para Novell/Suse), con artwork específico, apps completas por defecto (las que incluye la versión oficial del proyecto Gnome), y otras más añadidas por Opensuse para complementar capacidades.

Comentarios en la red sobre esto último:
http://linuxcrunch.com/content/opensuse-112-perfect-kde-distribution
http://news.opensuse.org/2009/10/27/sneak-peeks-at-opensuse-11-2-kde-4-3-experience-with-lubos-lunak/

Upgrade de Opensuse 11.1 a 11.2 para usuarios avanzados

Las novedades de Opensuse son varias internamente, mejores tiempos de arranque, mejor compresión de paquetes (va a acelerar las instalaciones desde Internet y vía red), mejoras en las GUI de configuración e instalación (YaST). En el artículo de Linuxcrunch de antes pueden leer sobre esto último también.

El upgrade desde 11. 1 a 11.2 si bien es viable perfectamente al momento, para muchos usuarios avanzados que tiene configurados repositorios apuntados hacia versiones de 11.1, un upgrade de la distro únicamente los puede llevar a que sean desinstalados aplicaciones con dependencia en viejas librerías y facilities de la distro (y sin rpms de retro-compatibilidad, que igualmente se dan en contados casos).

Lo mejor es ver qué repositorios no oficiales tenemos configurados en nuestro 11.1, ir a software.opensuse.org y localizar los mismos repositorios para la versión 11.2, y si estuvieran disponibles hay que cargarlos junto con los repositorios oficiales de 11.2 y seguir el procedimiento de manual (que no incluye el uso de repositorios extra no oficialmente soportados).

Técnicamente, el grueso de la versiones de aplicaciones actualizadas desde repos no oficiales en Opensuse 11.1, KDE 4.3.2 por ejemplo, deberían estar en casi la misma versión que estuvieren usando ahora al momento de "traerlos" desde los repos oficiales para 11.2; excepto algunos paquetes no oficiales (como los de los repos de módulos PHP y Perl por ejemplo).

Recordar que es muy interesante para acelerar el upgrade, bajarse un dvd de instalación (el del RC2 está disponible ahora), y cargarlo como fuente de instalación, aparte de cargar los demás repositorios en línea (especialmente el de update, indispensable hoy para llevar el 11.1 lo más cerca posible en versiones a lo que va a ser el 11.2 final).

Un ejemplo lo tienen aquí:

"Updating from Factory to openSUSE 11.2"
http://lizards.opensuse.org/2009/10/29/updating-from-factory-to-opensuse-11-2/

El tema del seniority

2009-10-29T13:08:00.000-07:00

Recién cambié de SSr. a Sr. la descripción de mi seniority en Linkedin. Ojo, no dije "experiencia" sino seniority. La diferencia está bien explicada en varios blogs de trabajo y seguro que pueden pedirla de vuelta en muchos grupos en Linkedin y en la red, los IT Pro siempre están con ganas de explicar que una cosa no es la otra y por qué.

Por mi parte, hace rato que veo que en la red y en la vida real muchos system administrators se declaran Sr. con skills en apariencia menos numerosas que las que listo en Linkedin, incluso con menos detalles y hasta parece que manejan un poco menos en profundidad esas herramientas. Pero las apariencias engañan, como es sabido.

En algun momento hace un par de años atrás me dí cuenta que no había software o hardware que no me animara a implementar sobre Linux, no es una cuestión de coraje o de audacia, sino de cálculo; simplemente era una estimación propia de que podría llegar a aprender o perfeccionarme sin mayor problema hasta llegar a un buen nivel de especialización en cualquier software o hardware a planificar, configurar, implemenar, administrar, etc. sobre Linux.

Esa noción se fue demostrando a sí misma a lo largo de varios proyectos y fui sumando a mis skills habilidades laterales, la "visión" como se suele decir, es en realidad management, capacidad de dirección y administración, etc.

La conclusión es que despues de una ya bastante retrasada autoevaluación y varios consejos de experimentados profesionales, es tiempo de usar este tag, ganado a puro golpe de mente sobre oportunidades, dificultades, y problemas, y luego de haberlos superado cabalmente.

Bueno, hace rato que no escribía y hablaba a título propio, pero ya es tiempo de darle a los siguientes posteos, técnicos esta vez.

3Trex Sysadmin Linux Training Sessions - Corrientes 2009

2009-09-19T07:21:00.000-07:00

CURSO CANCELADO por razones de causa mayor.

Si quieren pueden seguir leyendo del tema en próximos posteos.

Gracias por su interés a todos los que se acercaron y estén atentos a nuevos cursos.

---------------------

Estoy contento de presentarles en conjunto con 3Trex Tech Solutions las

3Trex Sysadmin Linux Training Sessions - Corrientes 2009

Inscripciones abiertas...

Vacantes disponibles:
16 sillas totales, en 2 turnos de 8 sillas cada uno.

Inicio del Training:
Al momento en que se concrete un mínimo de 6 reservas por turno

Cantidad de Reservas al 2009-09-24 16:45 hs.

Turno Lunes: 0 (cero) reservas.
Turno Martes: 1 (una) reserva. 7 sillas libres.

Las preinscripciones en línea se reciben en la dirección de correo yacolinux@yahoo.com.ar, en el teléfono:

3TX SRL (3Trex Tech Solutions)
+549 3783 428758

Alternativamente puedes pre-inscribirte online aquí.

Luego de confirmadas, se les informará por correo los datos de contacto y la dirección de dictado del curso y se les solicitará que hagan efectiva la inscripción allí en el plazo de 2 días hábiles, luego de los cuales perderán su preinscripción.

Pueden chequear días y horarios de dictado más abajo (ya figuran al momento), muchas gracias a los interesados y esperemos encontrarnos semanalmente mientras se van convirtiendo sesión a sesión en capaces administradores de sistemas Linux.

Gracias por su interés.

Dardo Valdez

Precios
El costo del curso quedó definido en $150 mensuales por persona. Se obtiene un lugar con acceso a una pc por persona.

La reserva de lugar se hace pagando $50 y se confirma pagando la totalidad de los $150, 5 días antes de comenzar el curso.

Descuentos

* Opción Acompañante :
Los asistentes que ya tengan un lugar pueden tomar un acompañante, con el que compartirán la pc durante el cursado, con un costo de $100 mensuales adicionales. El costo quedaría en un total de $250 mensuales para los dos asistentes al curso.

* Opción Notebook :
Hay descuentos para alumnos que decidan trabajar exclusivamente desde sus notebooks. En este caso el costo queda en $130 mensuales. Vale aquí la opción Acompañante con costo ya mencionado de $100 adicionales, con un total de $230 mensuales en este caso.

Carga horaria y modalidad de dictado
El training garantiza un mínimo de 16 hs. de capacitación por módulo y 48 hs. de capacitación totales con el training completo.

Se contempla el dictado horas extra de dictado de clases, que podría llevar el training hasta un total de 24 hs. de capacitación por módulo y 72 hs. de capacitación después de realizado el training completo.

Las clases extra se dictarán a criterio del dictante del curso según considere necesario.

La carga horaria total será de 2 hs. de clase semanales durante 6 meses, con 2 clases extra de 2 hs. cada una mensuales y opcionales.

En cada módulo se dicta por completo los temas incluídos en el temario.

Los tres módulos del curso se dictarán de corrido con un intervalo de entre 2 y 4 semanas a darse durante las fiestas de fin de año y los primeros días de enero.

Los horarios de clases confirmados son:

- Martes de 20.00 hs. a 22.00 hs.
- Lunes de 20.00 hs. a 22.00 hs.

Las clases extras si fuera necesario darlas se podrían dar, con previo acuerdo con los asistentes, tanto los jueves como los viernes, de 20.00 hs. a 22.00 hs.

Día a día
Durante el training voy a ir comentando en el blog el desarrollo de las sesiones y las distintas experiencias que vamos a ir compartiendo con los asistentes.

El Trainer y Organizadores
La persona que dictará el training es Dardo Valdez, ver referencias en:
http://www.linkedin.com/in/dardovaldez

Mi acompañante en este proyecto, 3Trex Tech Solutions tiene una trayectoria de años en mercado local como proveedor de soluciones de desarrollo, ellos aportan el marco y la infraestructura para llevar a la realidad las Linux Sysadmin Training Sessions.

Nivel del Training
El nivel de las Sysadmin Training Sessions es intermedio a avanzado.

El training está orientado a profesionales de informática, administradores de sistemas, administradores de red y en general personas con experiencia previa en sistemas operativos de nivel operador avanzado.

Las Sysadmin Training Sessions no son un curso de nivel inicial y se da por sentado que el asistente maneja cómodamente los conceptos de sistemas operativos y redes implícitos en las temáticas a tratar.

Requisitos para los candidatos
* Experiencia previa : Se recomienda tener experiencia extensiva en el uso de Linux como sistema operativo de uso diario y hogareño.

* Entrevista previa : El dictante aspira conocer de antemano a los asistentes y por ello se solicita una entrevista previa antes de iniciar el training para asegurar que le va a ser de utilidad, a la vez que ello no va influir en la calidad del dictado para con los demás alumnos.

* Idioma inglés : Es muy recomendable para los asistentes poder leer fluídamente texto en inglés (no hace falta nivel de conversación).

* Publicación : Los asistentes al training tendrán el requisito adicional de dar su consentimiento expreso para la publicación online del nombre del asistente en un listado a publicar en el sitio de 3TX Tech Solutions y en Sysnotas Blog.

Enterprise Training
Las Sysadmin Linux Training Sessions están disponibles como servicio de capacitación empresarial. Para contactarse por este interés, dirigir consultas a yacolinux@yahoo.com.ar.

Cómo es el training
Las sesiones de training serán teórico-prácticas, el asistente recibirá previo a la clase el material de teoría, las guías de trabajos práticos se irán poniendo a disposición por clase.
La práctica se dará paso a paso y tema por tema del curso, buscando integrar un ideal de 50% de teoría y 50% de práctica.

Servicios para los asistentes
Los asistentes al training ganan acceso a una lista privada, solo accesible con membresía, donde podrán realizar consultas técnicas directas al dictante. También podrán tratar con el dictante online cuando esté disponible, temáticas y dudas técnicas relativas al training.

Feedback anónimo
Los asistentes recibirán un nombre de usuario y contraseña a repartir al azar, con esos datos ganarán membresía en una lista de feedback anónimo, donde podrán subir sus críticas y requerimientos a los organizadores del training.

Esta lista estará disponible para lectura pública desde Internet durante todo el curso recogiendo las críticas y el feedback de los asistentes al training.

Las requisitorias directas de los asistentes también son bienvenidas y serán atendidas en la medida de lo posible.

El lugar de dictado
El lugar seleccionado para el dictado del curso es la sede de 3TX Tech Solutions, una locación céntrica en Corrientes, Capital con dependencias con aire acondicionado y baños a disposición de los asistentes.

Se dispondrá en el lugar de insumos como: agua caliente, café, té, yerba, leche y azúcar.

3TX SRL (3Trex Tech Solutions)
+549 3783 666897
+549 3783 428758
Belgrano 1768 | CP W3400ABH | Corrientes | Argentina

Documentación oficial del curso
La documentación oficial del curso está en idioma inglés:

Pro Linux System Administration, Apress
Copyright © 2009 by James Turnbull, Peter Lieverdink, Dennis Matotek
ISBN-13 (pbk): 978-1-4302-1912-5
http://www.apress.com/book/view/1430219122

De este libro proviene la estructura primaria del training y excepto 3 temas, el resto de los temas serán dictados subtema por subtema incluído del capítulo respectivo del libro. De hecho, los nombres de los temas del curso son una traducción del libro de los nombres de capítulos y temas incluídos.

Como documentación de apoyo se utilizará un libro focalizado en Suse Linux Enterprise Server, también en idioma inglés:

The Definitive Guide to SUSE Linux Enterprise Server, Apress
Copyright © 2006 by Sander van Vugt
ISBN-13: 978-1-59059-708-8
http://www.apress.com/book/view/9781590597088

Documentación en español
La documentación en español va a estar disponible por tema a dictar, sin dejar de documentar ninguno, en forma de lecturas recomendadas de diferentes fuentes, con copia electrónica local disponible para los asistentes.

Las lecturas recomendadas van a ser un acercamiento conceptual al 90% de lo disponible en el libro en inglés, con las obvias posibles diferencias al ser información de fuentes distintas.

Por ejemplo para el tema 2 del módulo 1 del training "Trabajando con usuarios y grupos" (pág. 110 de la documentación oficial), las lecturas recomendadas en español son:

(en orden según pertinencia con la documentación oficial)

* Implementación de Servidores GNU/Linux, Alcance Libre, 2009
12 (puntos 1, 2 y 3) Cómo crear cuentas de usuario (pág. 116 a 119)
* Administración Avanzada de GNU/Linux, 2004
5.5 Usuarios y Grupos (pág 192 a 197)

La guía de lecturas recomendadas va a estar disponible a medida que transcurra el training y previo al cursado de los distintos temas.

Los libros en español que usaremos durante el training son:

- Implementación de Servidores GNU/Linux, Alcance Libre, 2009
- Administración de Sistemas Linux, Anaya, 2007
- Linux Server. Los Mejores Trucos, Anaya, 2006
- Administración Avanzada de GNU/Linux, 2004
- Unix y Linux. Guía Práctica, 3ra. Edición, Ra-Ma, 2004

Distribución y portabilidad de skills
La distribución a utilizar en el training será Suse Linux Enterprise Server - SLES 10 SP2.

La documentación oficial del training abarca explicaciones teóricas aplicables a cualquier distribución, ello también se da en los procedimientos prácticos de consola (CLI). Por otra parte, la documentación oficial está focalizada en Red Hat Linux Enterprise (RHEL) Server y Ubuntu que se refleja en algunos procedimientos vía GUI para RHEL y en explicaciones particulares de consola para Ubuntu.

Hemos seleccionado la distribución y la documentación de modo que los asistentes adquieran un experiencia basada en Red Hat y Ubuntu, a la vez que aprenden y trabajan sobre SLES, de ese modo, transparentemente van a ir adquiriendo la noción de portabilidad de las skills entre distribuciones, y cuales pueden ser sus mínimas diferencias.

La documentación basada en "Pro Linux System Administration" también provee la ventaja de organizar temáticamente las skills de administración, a diferencia de otra documentación focalizada en la distribución, tal como es la documentación secundaria basada en el libro "The Definitive Guide to Suse Linux Enterprise Server".

Temario Oficial del Training:

Módulo 1

Instalación de Linux
- Recomendaciones hardware
- Instalación básica de Linux

Usuarios y Grupos
- ¿Qué sucede cuando te logeas?
- Trabajando con usuarios y grupos
- Controlando el acceso a tu host
- Más acerca de sudo

Administración de paquetes
- Introducción a la adm. de paquetes
- Adm. de paquetes en SLES Linux
- Compilando desde código fuente

Redes y Firewalls (1)
- Introducción a las redes y networking

Administración de almacenamiento y recuperación de desastres
- Básicos de almacenamiento
- Usandos Sistemas de Archivos
- RAID
- LVM (Logical Volume Management)
- Recuperación desde fallas

Módulo 2

Servicios SQL y Web
-Apache Web Server
- MySQL
- Instalando sitios web
- Squid Cache

Montaje de soluciones Linux
- Requerimientos
- Soft precompilado
- Puertos y protocolos
- Permisos, usuarios y grupos
- Montaje
- Ping, telnet para availability testing
- Caso Squid

Linux Básico
- Acceso Remoto
- Sistema y archivos
- Trabajando con archivos

Inicio y servicios
- Entendiendo el adm. de booteo Grub
- ¿Qué sucede luego de bootear?
- Administrando servicios
- Agendando servicios y comandos con cron

Redes y Firewalls (2)
- Resolución de problemas de networking
- Netfilter e Iptables
- Como funcionan Netfilter/iptables

Servicios de Infraestructura
- NTP
- DNS
- DHCP
- SSH
- FTP

Monitoreo de Rendimiento y Optimización
- Checkos Básicos de Estado
- Herramientas Avanzadas
- Optimización de Rendimiento

Módulo 3

Logeo y monitoreo
- Logeo
- Monitoreo

Bash Scripting
- Técnicas básicas
- Conceptos avanzados
- Recetas Utiles

Compilación de kernel

Compartición de archivos e impresión
- Samba
- Servidores de impresión

Resguardo y Recuperación
- Planificación de Recuperación de Desastres
- Proceso de Backup
- Backups de Red
- Usando Rsync
- Usando Bacula

Servicios de Correo
- Cómo funciona el correo electrónico
- Configurando Servicios de Correo
- Extendiendo la Configuración de Postfix
- Combatiendo Virus y Spam
- Configurando IMAP y POP3
- Usuarios y Dominios Virtuales

Servicios de Directorio
Servicios de Directorio
- ¿Qué es LDAP?
- Implementación
- Instalación
- Configuración.
- Administración LDAP y herramientas
- Integración con otros servicios

Temario en inglés
Los títulos y temas coinciden con capítulos y temas del libro "Pro Linux System Administration", documentación oficial del training.

Los títulos y temas en español se documentan de distintos ítems en el libro de apoyo y en la documentación en español.

Módulo 1

Instalación de Linux
- Recomendaciones hardware
- Instalación básica de Linux

Users and groups
- What Happens When You Log In
- Working with Users and Groups
- Controlling access to Your Host
- More about sudo

Package Management
- Introduction to Package Management
- Package Management on Red Hat Linux
- Package Management on Ubuntu
- Compiling from Source

Networking and firewalls (1)
- Introduction to Networks and Networking

Storage Management and Disaster Recovery
- Storage Basics
- Using your File Systems
- RAID
- Logical Volume Management
- Recovering from Failure

Modulo 2

Web and SQL Services
-Apache Web Server
- MySQL
- Installing Websites
- Squid Cache

Montaje de soluciones Linux
- Requerimientos
- Soft precompilado
- Puertos y protocolos
- Permisos, usuarios y grupos
- Montaje
- Ping, telnet para availability testing
- Caso Squid

Linux Basics
- Remote Access
- Files and Systems
- Working with files

Startup and Services
- Understanding the Grub Boot Loader
- What Happens after you boot?
- Managing Services
- Scheduling services and commands with cron

Networking and Firewalls (2)
- General Network Troubleshooting
- Netfilter and Iptables
- How Netfilter/iptables Work

Infraestructure Services
- NTP
- DNS
- DHCP
- SSH
- FTP

Performance Monitoring and Optimization
- Basic Health Checks
- Advanced Tools
- Continuous Performance Monitoring
- Performance Optimization

Logging and Monitoring
- Logging (syslog)
- Monitoring (nagios)

Networking with VPNs
- Our example network
- Introducing OpenVPN
- Troubleshooting OpenVPN

Modulo 3

Bash Scripting
- Técnicas básicas
- Conceptos avanzados
- Recetas Utiles

Compilación de kernel

File and Print Sharing
- Samba
- Print servers

Backup and Recovery
- Disaster Recovery Planning
- Backup Process
- Network Backups
- Using Rsync
- Using Bacula

Mail Services
- How Does E-Mail Work?
- Configuring E-Mail
- Extending Postfix Configuration
- Combating viruses and spam
- Configuring imap and pop3
- Virtual Domain and Users

Directory Services
- What is LDAP
- Implementation
- Configuration
- LDAP Management and Tools
- Integration with Other Services

Charlas propuestas para las Software Freedom Day de Ctes. y Resistencia

2009-09-14T06:28:00.000-07:00

Estoy proponiendo las siguientes charlas para presentar en los próximos eventos Software Freedom Day:

Para el evento SFD2009 de Resistencia (charla aceptada), el sábado 26 de septiembre:

"Selección de hardware de infraestructura y armado de presupuestos para licitaciones"

Se tratará las temáticas y procedimientos típicos con que se trabaja desde el punto de vista del administrador de sistemas para la planificación de incorporaciones y renovación de hardware de infraestructura. Adicionalmente se explicará las sutilezas de estas temáticas en el marco de adquisiciones vía licitaciones públicas.

y para el evento SFD2009 de Corrientes (pendiente), el sábado 19 de septiembre:

"Montaje de soluciones Linux, caso de estudio: Proxy con categorías de usuario y filtro de sitios no deseados"

Se tratará sobre los procedimientos típicos a seguir en una solución basada en Linux, en la transición desde el planteo de requerimientos, pasando por la integración de componentes software y llegando a la puesta en producción. Se hablará de un caso de estudio real que contempla la implementación de un proxy basado en Linux que reunirá ciertas funciones, que deberemos cumplimentar.

Curso de administración de sistemas Linux

2009-09-13T06:15:00.000-07:00

Que tal, estoy terminando la planificación del curso de administración de sistemas Linux que planeo empezar a dictar en las próximas semanas.

Ya quedaron cerrados varios bloques temáticos, ya tengo definidas muchas de las prácticas que se van a realizar y voy continuando hacia la culminación de los primeros meses de curso (al final pueden ver las definiciones para el 1er. módulo). La planificación va quedando así al momento:

Enterprise Training
El curso completo está disponible como training con una carga horaria de 16 hs. a dictar durante dos días, para contactarse por este interés, dirigir consultas a yacolinux@yahoo.com.ar.

El lugar de dictado
Al momento el lugar seleccionado para el dictado del curso es una locación céntrica, con dependencias apropiadas (aire acondicionado, baños, cocina).

Requisitos para los candidatos
Como ya pueden ver, el curso está orientado a alumnos de un nivel técnico inicial razonable para que llegue a ser de utilidad para el que lo curse.

Espero conocer de antemano a los alumnos y en caso de que se presente alguna persona/s de las que no conozca su nivel técnico, voy a solicitar primero un contacto previo antes de iniciar el curso, para asegurar que le va a ser de utilidad, a la vez que ello no va influir en la calidad del dictado para con los demás alumnos.

Se mantiene el requisito de permitir la publicación online del nombre del asistente en una lista a publicar en este blog.

Reservas y precios
El costo del curso quedó definido en $150 mensuales por persona. Se obtiene un lugar con acceso a una pc por persona.

Hay una opción para los que ya tengan un lugar en una pc para tomar un acompañante, con el que compartirán la pc durante el cursado, que tiene un costo de $75 mensuales adicionales (entonces dos personas podrán hacer el curso en una pc por $225 mensuales en total).

La reserva de lugar se hace pagando $50 y se confirma pagando la totalidad de los $150, 5 días antes de comenzar el curso.

Opción Notebook
Según disponibilidad de lugar físico, se está viendo ofrecer lugares para alumnos que decidan trabajar exclusivamente desde sus notebooks.

Carga Horaria
Las horas a dictar ya quedaron definidas, y va ser un poco duro el cursado, trataremos de que sea ameno. La carga horaria sería una clase semanal de 3 hs. durante 2 meses, sumando 24 hs. de curso para el primer módulo y 72 hs. totales después de los 3 módulos; planteado así el curso estaría terminado en abril/mayo de 2010.

Ya estuve cerrando los "frametimes" de temas-prácticas-horas, así que falta un poquito para ver qué temas concretamente llegarían a entrar en el primer módulo, pero como pueden ver, estoy planificando 8 temas centrales, que constituirían - idealmente - los temas a dictar durante las 8 clases del primer módulo.

Temas a incluir
Ya mencioné que se incluirán oficialmente temas que seguro van a llegar a darse (garantizando así los temas a enseñarse durante el módulo), incluso si tengo que establecer el límite oficial en 6 temas a dictar en el primer módulo, pero si queda tiempo (es inevitable cierta imprecisión la primera vez que se dicta un curso nuevo), se avanzará con otros temas.

Si alguno ya ha tomado cursos - digamos que sí en principio - ya sabrá que hay cierta flexibilidad en el dictado dados los tiempos variables obvios de reexplicaciones, aclaraciones, el intercambio típico de preguntas y respuestas, etc.

De seguro si hay gente nueva para el 2do. módulo les voy a tener que dictar un update - free of charge - de los temas del 2do. módulo que se adelantaron en el primero (que no deberían ser muchos). Se mantiene la idea de que los asistentes al primer módulo tienen reservado un lugar para el 2do. y así sucesivamente.

Material del curso
Por cierto, el material del curso va a estar disponible y accesible a los alumnos en formato electrónico y como lecturas recomendadas. El idioma primario del material va a ser español, pero también voy a incluir lecturas recomendadas en inglés.

La idea de esto es que aprendan a "navegar" y obtener información de documentación diversa leyendo material a nivel temático, complementando la información desde varios puntos de lectura, a la vez que van a ir conociendo diverso material disponible de aprendizaje (si tienen un capítulo "12" de un libro para mirar, de seguro van a ir dándole una mirada a los demás para curiosear un poco).

Como pueden ver en el temario, es mucho más fácil dictar un curso desde cero en contraste con diseñar un curso de administración de sistemas que abarque exhaustivamente las skills que se le van a solicitar a un sysadmin Linux.

Espero estar dando a publicidad el curso en la semana siguiente, durante la charla del Freedom Day en Ctes. o en su defecto, en la charla del Freedom Day de Resistencia, la última semana de septiembre.

Al momento ya cuento con al menos 3 reservas - informales, hasta que se publicite oficialmente el curso- para amigos y conocidos.

Temario tentativo del 1er. módulo:
0) Recomendaciones hardware
1) Instalación básica de Linux
2) Usuarios y grupos
3) Administración de software
4) Networking Basics
5) Administración de discos
6) LVM - Configuración y Administración
7) Compilación de software
8) LAMP

Borrador detallado del temario del 1er. Módulo:

0) Recomendaciones hardware
- hard redundante
- selección de OS de server
. updates regulares y por años
. estabilidad
. documentación oficial
. documentación no oficial
- RAID por hard y servers
. no más RAID por soft
. uso de RAID por soft? small scale
- RAID por hard y LVM

1) Instalación básica de Linux
- Meta-paquetes recomendados
- Particionamiento
- Instalación por default / y swap
- LVM - Intro
- Configuración del servidor
- NTP Client
- FQDN
- resolv.conf (DNS)
- MTA
- Tunning de servicios
- Networking por default (DHCP)
.Gateway por default
- Firewall basics

Tunning: uso de mc, creación de directorios y archivos vacíos, edición
de archivos de texto.
Tunning: Yast, la GUI de administracion de sistemas de SLES

2) Usuarios y grupos
- crear usuarios y grupos
- desactivar usuarios: nologin, /bin/false, /bin/noshell, etc.
- problemas de grupos y acceso
- su (distintas técnicas de impersonamiento)
- sudo (varias técnicas)

Tunning: I-O redirecciones, Text processing tools.

3) Administración de software
- Rpms, debs, dependencias
- Tools
. comandos rpm básicos y utiles
- Repositorios
- Búsqueda de software
- Software no oficial, ciclos de updates
- Updates automáticos

Tunning: primera introducción a DNS.

4) Networking Basics
- Client configuration basics
. static configuration issues
. configuration testing tasks
. manual reconfiguration
. basics: trabajo en consola ifconfig, route (configuración de
red, gateway)

5) Administración de discos
. añadir disco, práctica con VM (fdisk, creación de filesystem
manual, yast)

6) LVM - Configuración y Administración
- Hardware de storage
- Conceptos de volúmenes
- Uso y utilidad en la práctica
- Comandos y tareas básicas
- GUI
- Comandos avanzados

Tunning: Bash básicos

7) Compilación de software
- Meta paquetes, requerimientos
. gcc, etc.
- Compilación típica de fuentes
. debugging y detección de requerimientos
. solución de requerimientos
- Tunning de opciones
- Recompilación de source rpms

8) LAMP
- Instalación y configuración básica de una herramienta LAMP
. meta-paquetes
. software adicional (repo extra)
. adm. básico de Mysql (crear, dropear bases, otorgar permisos,
asignar usuarios, recuperar pass root)
. configurar app PHP
. configurar montaje en Apache (.conf por default)
. backup de mysql (dump)
. demo de app php en funcionamiento

Evento empresarial de Blade servers, Storage y Virtualización

2009-09-13T05:23:00.000-07:00

La verdad no sé por qué casi nadie comenta de estos eventos, cada dos meses más o menos hay eventos privados de difusión-venta de productos de alto nivel en la ciudad de Ctes. Estos eventos los realizan las empresas locales asociadas a empresas-representantes de Cap.Fed./Bs.As. que son representantes de casi todo lo que se pueda vender en IT: antivirus corporativo, software variado ERP,CRM (no vi mucha charla sobre estos, pero sí papelería en cantidad), sistemas operativos, hardware de redes, de seguridad, de refrigeración, etc. etc.

Hace unos días se realizó un evento privado organizado por Desarrollos NEA, con representantes de IBM Argentina y Tallard. La temática del evento trató acerca de servidores blade, storage y backup de IBM y Vsphere 4.0 de Vmware.

Nos recibió Humberto Oraisón de Desarrollos NEA, invitándonos a varias horas de explicaciones y datos sobre tecnología de blades y storage de IBM y de virtualización empresarial de IBM y Vmware.

El evento comenzó a las 10,30 pasadas y arrancó con la presentación de Carina Spero de IBM Argentina comentando acerca de IBM en la región, esta persona es la responsable por el area Litoral (que incluye al NEA también), y destacó la buena onda que hay con hacer negocios en la zona y como ya tienen viejos clientes por aquí. Algo interesante que comentó es que por aquí tienen 5 especialistas IBM que atienden a los clientes de Ctes. y Resistencia.

Luego vino el turno de Sebastian Pinna y Daniel Husar comentado sobre tecnologías Blade y sus distintas posibilidades y ventajas; nos contaron mucho sobre la flexibilidad en el montaje de las "hojas" en el blade, como pueden ser de distinto tipo, integrando en un Bladecenter procesadores Intel, AMD con RS6000. También se pueden integrar otros componentes como switches L2 y switches fibre channel de distintas marcas directamente en el chasis del blade. Incluso hay un modelo para oficina (con una turbina "así" de grande y un silenciador atrás), que no requiere un datacenter y trae rueditas y todo (y es para estudiar mucho con los calores de acá y el ahorro que hacen las oficinas típicas en aire acondicionado).

Lo mejor de un blade como adquisición inicial en un datacenter es que se puede llegar a montar el datacenter completo en un solo rack (en orden de montaje: las ups, el storage, el blade, etc.); básicamente todo se concentra en esos componentes. Otro tema que sorprendió a muchos, pero no a quien escribe (que ya va diseñando varias arquitecturas SAN/Virtual Infraestructure al momento), es que las "hojas" de los bladecenter solo tienen, a lo sumo, 2 discos en raid (1 recomendado), para bootear el SO, y no tienen posibilidad alguna de expansión y ello se da como explicaron por extensión Sebastián y Daniel porque un blade está pensado para ser integrado totalmente con una solución de storage externo.

Después de esto vino el lunch, y comimos de primera, bocaditos de siempre y una patita de cerdo que trabajaron fileteando en vivo entre dos mozos mientras iban sirviendo los trozos en pancitos ahí mismo, con cuencos con varias salsas para acompañar; había una mesa de bebidas con varias gaseosas y otros mozos dando vueltas recargando copas, fue todo en general un eficiente reemplazo de un almuerzo formal.

Nos encontramos con varios amigos y conocidos, estuve hablando mucho - de vuelta - con Seba del Prado que estaba ese día en representación oficial de su empleador y con las ínfulas de negocios requeridas - igual que yo - por la situación, igual no nos privamos de la patita de cerdo ni de las bromas, jajaja. También hubo varias presentaciones, y bueno, evidentemente el ámbito de negocios IT es bastante desconocido para gente recien llegada a él como yo, igual que a ellos les resulto desconocido seguramente, sin embargo la gente habitué parecía conocerse de anteriores encuentros y el ambiente estaba muy cordial y entusiasta.

En algun momento me acerqué a uno de los representantes de IBM y hablando del evento le comenté que la concurrencia al evento tenía mucho que ver con el respeto y la reputación que Humberto Oraisón tiene en el ámbito IT local, y como eso respaldaba muchísimo la iniciativa de Desarrollos Nea de pisar fuerte en infraestructura; claro que hubo feedback y estos muchachos de Bs.As. estaban sabiendo la calidad profesional de sus socios de negocios; igualmente los comentarios fueron agradecidos y continuó el intercambio.

Las siguientes dos charlas iban a cerrar el evento, ya en plena siesta correntina, es decir, solo con pajaritos y algo de viento haciendo ruido aparte de la voz del ponente, los estómagos cargados iban haciendo mella lentamente - vía digestión - en el nivel de atención de los asistentes, y estuvimos luchando contra la modorra durante la primera charla, que por suerte nos mantuvo interesados mayormente, incluso muchos estuvieron respondiendo preguntas y vaciando de regalos al ponente.

La primer charla de la siesta arrancó con storage y backup, y fue la continuación natural de la de los blade, que como ya les dije, no sirven de mucho sin un almacenamiento externo masivo. En este caso las opciones son muchas y la gente de IBM tocó fuertemente la línea básica e intermedia de productos comentando distintas posibilidades y capacidades, más o menos todo en rango con lo último disponible en tecnología de almacenamiento, aunque las capacidades de disco probablemente desilusionaron a más de uno ya que si bien los discos rígidos para usuarios finales están siempre a lo último, los discos usados en storage industrial van un poco atrás en capacidad, rondando de momento los 300 GB- 1TB con precios desde razonables hasta U$S 2000 por discos de 1 TB, siempre hablando de discos SAS y SATA integrables en dispositivos de storage (oficiales de la marca y con garantía de uno a tres años).

Ahora estoy recordando una charla flash, no lista en el cronograma que nos dieron sobre PowerVm, la solución de virtualización de IBM que corre, más o menos entendí (y no fui a corroborar en datasheets), sobre servers Power y RS600 y permite virtualizar Linux (SLES y RHEL), AIX e "I" (ex AS400). Un detalle es que no hay productos de virtualización para Power y RS6000, es decir no hay Vmware que corra sobre esos micros. PowerVM hace un trabajo excelente sobre virtualización permitiendo alcanzar (y superar en un par de características), las capacidades típicas de Vmware Vsphere (ex Virtual Infraestructure).

Al terminar la primera charla de la siesta se hizo presente una pausa para el café, muy agradecida por los presentes, donde se repitieron los contactos y algún que otro cierre de negocios.

Para cerrar la tríada "Blades+Storage+Virtualización", vino la charla sobre Vmware Vsphere, la solución empresarial de Vmware. Básicamente es un producto que hace casi cualquier cosa si dispone de nodos (servidores), donde correr los OS virtualizados y espacio de storage donde guardar los datos (una SAN full es recomendable). Se dieron fuertes comparativas con soluciones Microsoft demostrando las capacidades inferiores aparentes de la tecnología de Hyper-V, el hypevisor de MS (Microsoft también tiene un producto de administración de hipervisores, similar a Vsphere y sería interesante ver qué pueden contar en una charla de preventa).

El nivel técnico de las exposiciones fue superlativo, unicamente limitado por la necesidad de los oradores de explicar detalles prácticos de "nueva" tecnología a gente de IT "no técnica", y lograr captar su atención para comunicar los detalles importantes y potencialmente útiles para ambos (para el que puede comprar y para el que puede vender).

Destaco que es el primer evento en Corrientes y de este tipo en que veo el "nuevo" enfoque (ya tiene un par de años en el mundo al menos), de integrar soluciones de servers (blades en este caso), con storage (SANs, iSCSI, etc.) y administradores de hipervisores/software de infraestructura virtual (Vmware Vsphere y ESX, PowerVM). Esta tendencia tiene una firme aceptación y continúa a buen ritmo integrandose con las clásicas opciones de deployment de hardware de datacenter.

Cerramos la tarde, y Humberto nos despidió agradeciendo la visita de gente de otras pcias. que vinieron para escuchar acerca de nuevas tecnologías y contactarse con los proveedores de sus probables futuras soluciones. Terminamos el evento comiendo unas masas y facturitas en el patio del hotel, y conversando un poco ya para ir saliendo de vuelta al hogar.

Globant se mueve en Resistencia

2009-09-13T05:16:00.000-07:00

Que tal, hace un par de días surgió el rumor fuerte de que Globant había empezado a trabajar sobre un edificio a unas cuadras de la plaza central de Resistencia ("25 de Mayo", puede ser?), un edificio grande que se encuentra en refacción y podría albergar cómodamente a las hipotéticas 300 personas que tenía supuestamente el proyecto 2008 original de Globant-Resistencia.

Resulta que consulté por mi cuenta y me dijeron EXTRAOFICIALMENTE y con buen grado de certeza que la empresa se está preparando para abrir oficinas en Resistencia, Chaco. No dicen nada del nro. de posiciones que van a abrir inicialmente ni a cuanto quieren llegar, los datos de los "300" son del proyecto 2008 (pueden leer diarios online del año pasado en las cachés de la red y ver las notas por el tema Globant- Resistencia 2008).

Aquí vienen las consideraciones prácticas:

* Casi seguro que el trabajo sea "en blanco" para los candidatos, más teniendo en cuenta que Globant buscaría realizar una oferta pública de acciones en Wall Street en 2012 y eso requiere empleados en blanco entre otras cosas (150 millones de U$S de ganancias anuales libres de impuestos, etc.).

* Las obvias exenciones y beneficios que podrían haber obtenido en el Chaco deberían asegurar una presencia con mínimos gastos operativos por al menos 5 años, con 10 años recomendados (más teniendo en cuenta la intención de salida a bolsa).

* El nivel de sueldos no va a ser el de Bs.As., pero sí debería ser un sueldo por especialidad/seniority por arriba del promedio regional, para poder captar talentos IT que están ocupados y con buenos sueldos en Ctes. y Resistencia. Claro que los talentos IT que estén subocupados con monotributo y similares (full black digamos), van a ser beneficiados con ese rango de sueldos también.

* No vendrían a buscar una gran nro. de juniors, pero los necesitan para bajar los gastos operativos iniciales y realizar el "modelado" de gente para la empresa, es el momento de un junior talentoso de empezar a publicar blogs y dar charlas técnicas mostrando el nivel técnico que lo destaque de los demás estudiantes y jovenes profesionales.

* La pelea por los puestos técnicos y gerenciales de nivel intermedio-alto va a ser fuerte, el target obvio inicial son los egresados de la UTN y los requisitos de aceptación van a estar al nivel de experiencia y cualificación que tienen los AUS e ISIs (Analista Universitario de Sistemas e Ing. en Sistemas de Información, respectivamente).

* El nivel de inglés, "conversacional" o full bilingûe puede ser un switch on-off para la aceptación o no en un puesto, dado el bajo nivel general en idiomas de la región. Esto incluso es cierto a nivel intermedio-alto, muchos profesionales de muy buen nivel (y años de experiencia incluso), en la zona leen bien, pero no pueden escribir un mail en inglés, eso le da una ventaja potencial a los talentos IT con poca experiencia, para alcanzar puestos intermedios.

Es decir que si alguien quiere mejorar sus chances de ingreso, sería bueno empezar a mirar qué proyectos maneja Globant, cuales son los requerimientos técnicos y especialidades solicitadas en búsquedas laborales activas (un indicador de a qué proyectos se dedica la empresa), ni hablar de empezar a tomar clases de inglés.

Ya faltan 4 meses para 2010 y el edificio podría estar terminado para ese momento, más o menos cerca de cuando el lugar físico esté disponible, deberían comenzar los procesos de selección, así que ya lo saben, puede que se venga un cambio interesante en la región.

Ni hablar de las consecuencias para los IT shops locales si se llegara a concretar este proyecto, va a provocar sustanciales cambios en los lugares donde haya gente de buen nivel técnico. O sea casi todos los empleados IT de buen nivel están en posiciones importantes en empresas IT de Ctes. y Resistencia, pero con sueldos, perspectivas y prestaciones potencialmente bajas comparadas con las que podrían obtener de una empresa de nivel internacional.

Update 1: la cantidad inicial de empleados serían 100

Update 2: tal vez o no relacionado con esto, hubo recientes procesos de selección con gente de la UTN FRRE, pero no queda definido concretamente si ya ha comenzado el recruitment para Resistencia.

Trabajo remoto en IBM y EDS

2009-09-13T05:13:00.000-07:00

Que tal, en las últimas dos semanas estuve recibiendo comentarios y luego confirmándolos; los hechos son:

IBM y EDS cerraron acuerdos el último par de meses (yo me enteré hace poco), con gente de la zona para trabajar en modalidad remota a tiempo parcial.

En ambos casos se considera a partir de un 50% de las horas de trabajo mensuales a cumplir para realizarlas desde el interior del país (porque se entiende que el empleado no va poder acercarse de inmediato a la empresa en Bs.As. si se lo pidieran).

Ejemplos concretos tengo confirmados en IBM del 50% remoto y 50% en Bs.As., y de EDS del 75% remoto y 25% en Bs.As.

Por otra parte tengo datos que apuntan a que EDS cierra acuerdos con trabajo 100% remoto.

La modalidad sería ir a Bs.As. a los trainings por un par de meses (con posibilidades de viajar en fines de semana y feriados, como es lo normal), y luego sí, se implementa el trabajo remoto.

Los perfiles para los cuales se estaría adoptando esta modalidad serían Ssr. y Senior, (2 años y 4 años en adelante respectivamente, de experiencia de buen nivel en campo del seniority: desarrollo, adm. de redes, adm. de sistemas, etc.), que al momento tienen sueldos de $5.500 netos en adelante para Ssr. y $7.000 Senior para adm. de redes y sistemas, con respecto al perfil developer no tengo información concreta, pero es más complejo, los Java y .NET developers irían al tope de sueldos.

Si consideramos un gasto local de entre $500 y $1000 de alquiler local, y arreglando estadías en Bs.As. compartidas con conocidos o compañeros de trabajo (alquiler compartido), las perspectivas de sueldos desde $5.000 son positivas.

Próximo curso de administración de sistemas Linux en Corrientes

2009-09-05T17:29:00.000-07:00

Bueno, estoy armando un curso de administración de sistemas Linux desde hace unos días, luego de haber obtenido el OK para realizarlo en un buen sitio en la ciudad.

La didáctica de enseñar a administrar sistemas Linux

La cosa es así, para administrar un sistema operativo primero hay que saber configurarlo al milímetro como usuario, ello sería poder llamarse un "power user", y saber hacer en el OS cualquier tarea, y si no se supiera, poder investigar brevemente y luego poder realizarla.

Esa la principal cuestión con los cursos de adm. Linux, la mayoría de los potenciales alumnos vienen al curso con un perfil de usuarios de Linux muy básico y conceptos simples a nivel de OS los confunden bastante.

Por ejemplo, el manejo de usuarios y grupos, y como se trabaja en una distribución usando permisos estándar y por default para administrar el acceso a recursos, un problema típico es mostrarles que, por ejemplo, que un usuario que no pertenece al grupo "dvdrw" no puede grabar con una grabadora de DVD cuando cierto dispositivo /dev/dvdrw (la grabadora) solo tiene tiene acceso de escritura para ese grupo ("dvdrw"), y que dado el caso habría que agregar al usuario al grupo "dvdrw" para poder grabar dvds. La pregunta suele ser "¿la grabadora tiene permisos también?", y ya vemos que se va a dificultar explicar como los servicios del OS suelen correr con distinto usuario/grupo que "root" y como ello es un parámetro a considerar en el montaje y operación del software (ejemplo: un soft php, donde los archivos no pertenecen a "wwwrun", grupo "www" - por ejemplo - y aunque estén en el directorio correcto para correr en Apache, no van a poder ser accedidos, mucho menos utilizados por el soft webserver).

Hay varios ejemplos más de este tema, por otra parte no hay que subestimar a los potenciales alumnos por lo anterior, ellos quieren aprender en serio y mostrarles una GUI (Yast y similares), como "path" de configuración no cambia sus ideas y conocimientos previos que exigen comprender perfectamente el manejo de usuarios y grupos; eso añade un tema más a un curso de adm. de Linux.

..y así podemos ir recorriendo distintas facetas de la configuración de Linux como OS que influyen agregando temas para entender y aprender a configurar el OS vs. aprender a montar y administrar servicios, lo que sería el foco del curso de adm. de sistemas propiamente dicho.

Por otra parte están los servicios que se puede elegir para dar un curso. En la realidad los servicios son muchos, y según el escenario de administración no se usan en absoluto o son el foco central de las tareas administrativas del server.

Como va a ser el curso

Pasaron un par de días de los razonamientos anteriores y ya estoy por empezar a armar el temario del curso, he tomado varias decisiones al respecto de los problemas anteriores y por cierto, el curso va a tener 2 etapas de 3 meses.

Requisitos extra

Un requisito para ingresar al curso va a ser acceder a la publicación en un listado de asistentes al curso de nombre, apellido y otros datos como lugar de trabajo, y títulación. De ese modo el dictante del curso y sus auspiciantes obtienen un rédito profesional no económico sumamente valioso en la región, relativo al de los asistentes, que se espera sean parte de lo mejor del ámbito informático de la región.

La primera etapa

- Los asistentes a la primera etapa van a tener un training intensivo sobre configuración de un sistema Linux a bajo nivel y van a aprender a realizar diferentes tareas típicas y un listado seleccionado de trucos interesantes que van a demostrarles cómo entender a bajo nivel el OS, les permite encontrar maneras alternativas de resolver diferentes problemas, más allá del mero uso avanzado de las herramientas disponibles.

- La primera etapa va tratar la configuración completa de un servidor, dejándolo listo para trabajar en la configuración de servicios.

- Los servicios a configurar van a ser un mix de servicios requeridos en entornos de misión crítica y servicios más tradicionales de Linux

- Esta primera etapa no es una introducción a básicos de Linux, sino como una evolución desde el usuario medio-avanzado hacia el usuario avanzado y capacitado para implementar el OS a nivel empresarial sin problemas.

- Los servicios incluídos van ser la mayoría de los básicos inevitables: ntp, ssh, telnet, ftp, etc. Pasando por otros menos conocidos como configuración de puertos seriales, y llegando los demás locales y de red: xinetd, httpd, samba y nfs.

- Claro que son múltiples los temás que serán tratados aparte de los servicios: selección de hardware, particionamiento, volúmenes LVM, hardening del sistema operativo, operación remota de sistemas vía CLI y vía gráfica, backup, actualización dinámica del sistema (políticas, buenas prácticas, implementación), etc.

La segunda etapa

- Varios servicios de red y algunos servicios locales van a quedar para ser dados en la segunda etapa. La segunda etapa se concentrará fuertemente en el training de servicios, dejando totalmente de lado cualquier enseñanza relacionada con básicos: adm. de usuarios y grupos, dispositivos, tareas de power-user (como grabar una .iso desde la CLI, etc.), etc.

- La segunda etapa va a incluir teoría y práctica de resolución de problemas, con training intensivo práctico que incluirá casos reales de problemas donde el asistente va a tener que encontrar la solución e implementarla, utilizando la metodología aprendida.

- La segunda etapa va a incluir teoría y práctica de software de monitoreo y de alta disponibilidad. Este training va a requerir mucha base teórica y dominio de la práctica de la etapa anterior.

- En la segunda etapa se va a trabajar el montaje de soluciones complejas sobre Linux, tocando las temáticas de análisis de requerimientos, ver como cumplimentarlos en la plataforma elegida (Suse, RedHat, etc.), y la integración de la solución Linux.

Bueno, la idea está planteada, en unos días más voy a publicar por aquí el temario del curso y al poco tiempo, ya con la infraestructura del curso disponible (máquinas virtuales instaladas y funcionando, prácticos listos, material de estudio e impresos listos, etc.), estaremos abriendo la inscripción, serían mas o menos 2 semanas si no hay inconvenientes imprevistos.

Sitio de preguntas y respuestas colaborativas

2009-08-29T15:12:00.000-07:00

Mirando en la red encontré estos sitios:

Stack Overflow, Server Fault, SuperUser , DocType, y un par similares de la familia, How-to Geek y MetaStack Overflow.

Los cuatro primeros sitios contienen un engine de enfoque colaborativo en la resolución de problemas, de modo similar a un foro, pero sumando a las capacidades de búsqueda el tagging de las preguntas, lo que genera una base de conocimiento vasta que se expande rápidamente.

A la vez no requieren suscripción, lo que elimina gran parte de la molestia de "entrar" que se da en sitios similares, impulsando al usuario eventual a cargar rápidamente una respuesta cuando ve un problema del cual conoce la solución.

Los sitios están orientados a tipos específicos de pregunta por áreas:

StackOverflow > Orientado a Desarrollo

ServerFault > Orientado a Administración de Sistemas

SuperUser > Orientado a Usuarios Avanzados

DocType > Orientado a Diseño Web

Howto Geek > Tutoriales de sistemas operativos (totalmente categorizados, fácil localización)

MetaStack Overflow > Dedicado al análisis colaborativo público de la evolución de los demás sitios.

Más allá de ser un enfoque relativamente nuevo en la creación colaborativa de contenido (al estilo Taringa.net o Uimpi.net y similares), estar orientado a esas áreas temáticas permite a cualquiera que esté investigando una temática X (MSSQL como servidor de BD, por ejemplo), ver las preguntas usuales que surgen de ese tag general, "sqlserver", y ver que los administradores MSSQL suelen necesitar tal o cual cosa, o tener problemas en X tipo de configuraciones.

Detrás del desarrollo de estos sitios está la gente de Joel Spolsky.

Lista de correo de Sysnotas

2009-08-29T03:40:00.000-07:00

Bueno, recién creé la lista de correo de Sysnotas, la idea es juntar ahí a los lectores de este blog, pero más puntualmente a gente reconocible, si alguno quiere participar anónimamente, esta lista no es una opción viable muchachos, y hay muchas disponibles en la red, sin resentimientos.

Acá estoy publicando el mensaje de invitación que van a recibir algunos amigos, conocidos y contactos del ambiente IT. Como va a ser una lista cerrada, este probablemente sea uno de los pocos mensajes públicos que vaya a salir a Internet.

"Que tal, armé una lista para compartir información técnica. El requisito de admisión es que al aceptar la invitación vos o yo publiquemos una presentación para la lista contando quién sos (nombre y apellido real), y qué hacés (estudiante, trabajo en tal lugar, etc.).

No hay posibilidad de ingreso al grupo sin informar nombre y apellido real y ocupación de quien ingresa. Este requisito se da porque quiero incluir personas que conozco personalmente, pero que no se conocen entre sí, y mantener igualmente la confianza dentro de la lista para publicar artículos.

La admisión automática - incluída la presentación al grupo - se va a dar si el que pide ingresar cuenta con una presencia e identificación factible en línea reconocible, blogs y entradas en redes sociales que incluya nombre y apellido real.

Los que no cumplimenten el requisito de presentación a poco de ingresar, van a ser automáticamente excluídos de la lista, hasta cubrir el requisito de admisión.

Reconozco que el requisito de admisión es duro, pero la lista va a ser privada al 100%, solo legible con membresía, y sin posibilidad de ingreso a personas que no puedan ser identificadas con un grado razonable de certeza, incluído el nombre y apellido.

De vuelta aclaro, para los que quieran mantener su anonimato (y permanecer fuera de esta lista), el aceptar la invitación implica que se va a publicar una presentación al grupo del nuevo miembro, que va a incluir nombre y apellido, ocupación e interesés en el grupo, junto con cualquier dato que permita identificar en línea a esa persona."

Corriendo Nikto

2009-08-28T15:47:00.000-07:00

Nikto es un scanner open source (GPL) que permite realizar test exhaustivos contra webservers que permiten detectar múltiples problemas incluyendo alrededor de 3500 archivos/CGIs potencialmente peligrosos y problemas específicos por versión de webserver en alrededor de 250 de ellas. Los ítems y plugins se actualizan regularmente y se puede actualizar el programa sin limitaciones (esto 28 de agosto de 2009).

Es particularmente interesante para los novatos el que Nikto detecte múltiples potenciales problemas en sus reportes de corrida contra X webserver, al mismo tiempo que otros programas, comerciales incluso y bastante caros, detectan unas pocas o mucho menos vulnerabilidades que Nikto, para entender esto hay que sopesar algunas "advertencias" de Nikto que no son necesariamente vulnerabilidades. Para más datos leer la información disponible en el sitio.

Correr Nikto básicamente consiste en tener instalado Perl, que está en el 99% de las distros Linux y versiones de Unix del planeta...luego de eso queda bajar Nikto (así figura en el sitio):

"Posted by sullo | 10/06/2007
Download
Version 2.03 .gz or .bz2 | Plugins & DBs"

Una vez descomprimido, vemos que las fechas de acceso de los archivos disponibles hoy (agosto-09), fueron modificados en sept. 2008 por última vez, lo que es interesante recordar cuando lo utilicemos para escanear por posibles problemas relativos a las vulnerabilidades más nuevas (falsos positivos, total indetección, etc.). Igualmente hay que sopesar esa evaluación contra la disponibilidad de los updates de Nikto y el que la lista de correo muestra actividad en el desarrollo (...tal vez habría que testear sitios con Nikto también desde una versión SVN reciente - para comparar outputs - pero antes habría que darse una vuelta por los threads de la lista para estudiar los cambios no documentados sobre la versión estable publicada...).

Correr Nikto es fácil, interpretar los informes es la parte complicada normalmente, pero brinda una linda salida HTML que se puede utilizar como base de informes regulares; incluso gracias a su interfaz de línea de comandos, se puede llegar a "cronearlo" (CRON), para que corra regularmente y envíe sus datos.

Los paranoicos a los que nunca les pasa nada pueden llegar a hablar de integrar en el CRON algun script que "grepee" el informe regular de Nikto buscando cadenas alarmantes relevantes (incluído el mail de alerta urgente), de las que podríamos llegar a hacer una buena lista, simplemente accediendo a los plugins (o al SVN de Nikto en su defecto). Algun avezado paranoico ha llegado a optimizar esto incluyendo la ejecución de Nikto+script de grepeo como reacción en un Nagios ante un cambio en el rendimiento de un website...en fin las posibilidades son muchas.

La documentación de Nikto: aquí

Libros en los que pueden leer sobre Nikto: aquí (y pueden buscar con Google dentro de esos libros en la red...)

Una corrida típica de Nikto sería así:

./nikto.pl -h www.sitio-a-escanear.com -Format html -output informe.html

Instalación de Openvas en Opensuse

2009-08-28T15:08:00.000-07:00

Este artículo trata sobre el software "OpenVAS - OpenVAS - Open Vulnerability Assessment System Community"

La instalación se puede hacer desde las fuentes y un buen tutorial para hacer eso en Opensuse sería:

http://www.susegeek.com/security/openvas-opensource-vulnerability-assessment-scanner/

Por otra parte también queda el camino alternativo de instalar directamente desde 1-Click-Install:

* El cliente

* El server

La posibilidad alternativa es instalar ambos desde Yast, luego de agregar algun repositorio que puede localizarse (buscar "openvas" en el box), en http://software.opensuse.org/search

Por ejemplo: security:openvas:STABLE/openSUSE_11.1

Finalmente queda la configuración:

1) Crear los certificados "openvas-mkcert"

2) Ejecutar el servicio con "rcopenvas-server start"

3) Actualizar Openvas con "openvas-nvt-sync"

4) Agregar un usuario con "openvas-adduser" (para optar por el acceso al server vía contraseña, recordar hacer un enter solamente cuando pregunte por la autenticación vía certificados)

4) Reiniciar el servicio con "rcopenvas-server restart"

5) El cliente se llama "OpenVAS-Client" (por si le dan al TAB y no se autocompleta nada cercano al nombre del cliente).

Antes de usar OpenVAS, deberían leer antes las review comparativas con Nessus.

* "openvas vs. nessus" en Google

Hacer andar VirtualBox como usuario en Opensuse

2009-08-28T04:14:00.000-07:00

Una reciente actualización me dejó sin poder arrancar VirtualBox como usuario (sí como root), con este lindo error:

/usr/bin/VirtualBox: line 72: /usr/lib/virtualbox/VirtualBox: Permission denied
/usr/bin/VirtualBox: line 72: exec: /usr/lib/virtualbox/VirtualBox: cannot execute: Success

Claro, uno se siente tentado a correr hacia el binario y darle permisos para todo el mundo...sin embargo recuerdo que el instalador decía claramente por consola que debía agregarse los usuarios de VirtualBox al grupo "vboxusers", fui a Yast lo hice y no funcionó.

Mirando un poco en google encuentro esto:

"Running in Konsole as normal user, it failed with an error that pointed me at the executable /usr/lib/virtualbox/VirtualBox, and on inspection it didn't have permissions for non-root user (i.e. Others). As root, I gave read and execute permissions to Others. It still failed to run from command line as normal user, this time with the error: Wrong owner (0) of '/tmp/.vbox-username-ipc'. This file was probably left there when I ran VirtualBox as root.

So, I went to /tmp as root and deleted the hidden vbox file (its name will include your user name). I made sure there was nothing else left there to do with VirtualBox. Then it worked! Maybe not exactly the same as your problem - but worth a look."

"Mc", ir a /usr/lib/virtualbox/VirtualBox y darle permisos de ejecución para terceros y tema solucionado.

Nessus 4.0.1 en Opensuse 11.1

2009-08-28T03:56:00.000-07:00

Resulta que Opensuse 11.1 no está formalmente soportado en la versión Nessus 4.0.1, pueden bajar el binario genérico en un comprimido (casi de seguro con librerías estáticas adentro, ya que pesa 8 mb vs. los demás por debajo de 3 mb aprox.):

*Generic Linux binary (intel/64 bits)
Nessus-4.0.1-linux-generic64.tar.gz 8815 KB

Yo quise probar primero instalar los rpms para Suse10 y el cliente para Red Hat/CentOs 5:

* SuSE 10
Nessus-4.0.1-suse10.0.i586.rpm 2453 KB

*NessusClient-4.0.1-es5.x86_64.rpm
(Red Hat ES 5 (64 bits) / CentOS 5) (4856 KB)

Ambos van con "rpm -ivh --nodeps" y se instalan tranquilamente.

Para hacer funcionar el server Nessus hay que ir hasta /usr/lib y crear dos enlaces simbólicos:

ln -s libcrypto.so.0.9.8 libcrypto.so.0.9.7
ln -s libssl.so.0.9.8 libssl.so.0.9.7

Con eso ya podemos arrancar el servidor (previa registración ), y luego agregar el usuario Nessus para acceder. Ver instrucciones aquí:

http://www.taringa.net/posts/linux/1190104/Instalacion-y-configuracion-de-Nessus_.html

o aquí

http://www.susegeek.com/security/nessus-vulnerability-scanner-in-opensuse/

Para hacer funcionar el cliente gráfico hay que crear dos nuevos enlaces simbólicos, esta vez en /usr/lib64:

ln -s libcrypto.so.0.9.8 libcrypto.so.6
ln -s libssl.so.0.9.8 libssl.so.6

Luego de eso el cliente gráfico va a funcionar bien para realizar escaneos, solo recuerden trabajar como usuario root para eliminar problemas de acceso varios.

Crónicas de SSHN4: Día Dos

2009-08-26T08:35:00.000-07:00

Día Dos

Rememorando
Me estuve acordando un poco del viernes y tengo una nota mental clara: "revisar www.soulblack.com.ar", que es el sitio matriz donde se ubica la investigación de un grupo de hacking de Tucumán (¿?), donde está también la gente de Tuquito y al que hicieron referencia en el comienzo de la última charla que comencé a ver antes de retirarme y que trató de vulnerabilidades web, XSS (cross site scripting), y demás malas artes...obviamente veía "ojos de huevo" en las caras de los asistentes por el interés (malas lenguas hablan de alta presión intraocular solamente....jajaja, pero eso se debería también al factor positivo de estar viendo las pantallas gigantes todo el día, por estar presentes en muchas charlas del evento), después me fui a recuperar sueño....o eso pensé que iba a hacer.

Arranca el día dos
El día dos comenzó el viernes de madrugada, con varios cafés navegando por mi torrente sanguíneo zarandeando todo tipo de tripas para que se pongan a laburar...arranqué a la noche como decía, estuve con laburo en la semana así que mi charla estaba bien de estructura pero mal de contenido. Después de ver las charlas del día uno me dije que no podía caer y explicar de palabra algunos conceptos que en adm. de redes se dan exclusivamente con gráficos, así que manos a la obra, estuve unas hs. recargando la presentación, luego hice una breve siesta nocturna y la mañana arrancó oficialmente 6.34 según mi despertador, que no llegó a sonar nunca (estaba a las 7.00).

Estuve repasando y reviendo ideas de explicaciones y demos, tenía un par de videos hechos de antes sobre el tema, pero la verdad lo había probado 25 veces a cada procedimiento y dije, "no, esto va en vivo"...si falla va el video, failback nunca falla.

Cerca de las 9 le aviso a los organizadores que voy a llegar cerca de la hora de la presentación, como para disminuir a niveles tolerables el pánico típico de esas situaciones.

A las 10.36 estaba en la vereda buscando un remise para llegar al evento y mi charla. Caí al rato, previa charla sobre política nacional con el remisero (todos los remiseros andan a full con la política nacional últimamente, debe ser un código que no conocemos o algo > debuggin social).

Al llegar al evento me contaron que Seba del Prado estaba metiendole a Forensics, mucho NTFS alternate streams, tooles diversas, exploración de metadatos en archivos de textos e imágenes, algo de auditoría de equipos de networking, etc. La gente se veía muy interesada en el tema y Seba estaba en una raramente relajada postura vs. el ya esperado solo de parado frente al público, igualmente la gente también se veía muy tranquila, recien despegando en la madrugada...digo mañana temprano del sábado.

Al entrar al auditorio saludé y me sumergí rápidamente en mi presentación, arranqué las máquinas virtuales y probé todos los procedimientos que iba a mostrar, todo de perlas, aunque ya sabía que algo iba a fallar seguro, creo que cada vez que alguien organiza algo, el universo crea una singularidad de improbabilidad condensada en un ámbito reducido...así si algo tiene chances de fallar escasas - como un programa estable que no se tiene bugs hace 3 años por ejemplo - seguro que en ese evento se va a encontrar un caso muy raro de falla...con el orador de pie haciendo la demo...jajajaj

En fin Seba me hizo preguntas en un idioma incomprensible y obviamente le dije "sí" y asentí... Al rato ví que todos se quedaron callados y el micrófono estaba para que lo agarre..je..5 minutos y arrancamos dije.

Mi charla
La charla era para 45 min. no de reloj sino de suposición, salió como de una hora y media o más, rescato que las almas generosas de los asistentes se bancaron al 99% todos sentados la primera hora y media, se habrán ido por exceso de apetito...

El título fue poco descriptivo esta vez, los temas tocados fueron 3: shells inversas (o shells reversas, reverse shells, etc.), troyanización de archivos .rar, medidas preventivas y mucha conversación sobre cómo con ingeniería social y OSINT (Open Source Intelligence, Inteligencia de Fuentes Abiertas), se ataca al usuario final ahora, en conjunto con la idea de evitar atacar directamente a la infraestructura (servers, firewalls, routers), como se hacía hace un par de años.

Creo que ví varias caras de pánico, no fue mi intención, pero la claridad de la amenaza patente desvelada durante las explicaciones sorprendió a más de uno. Como dije, no es para salir corriendo, pero hay que dejar la inacción y sobre todo la inconsciencia sobre estos problemas de seguridad.

Mi autocrítica: realmente no me gusta presentar las charlas como recitaciones de poesía, pero esta vez me hubiera gustado recitar algunos conceptos técnicos más fuertes y usar menos reaclaraciones constantes de la explicación que había dado 5 min. antes, en realidad estaba esperando muchas preguntas y que la gente diga que no entendió, pero parece que entendieron todo o no hubo feeling para comunicar dudas...eso queda a revisión del que escribe.

Llevé a cabo varias demos en vivo mostrando cómo se implementaban shells inversas típicas, de un modo muy conceptual, pero no muy lejos de las típicas shells inversas obtenidas de explotaciones clásicas. La demo que tenía planificada sobre la troyanización fue el núcleo de la ponencia y mostré como se corre un programa (un setup de una herramienta), mientras por detrás se establece una shell inversa y el atacante queda con acceso pleno a la pc de la víctima. Tenía planeadas varias demos más, pero por falta de tiempo no las día, asumo ese costo a cambio de darme más tiempo para con la gente y por estar presentando cada vez que hablo, charlas nuevas.

Al terminar los aplausos de la gente, al toque Pedro largó una charla corta sobre servicios profesionales de seguridad IT que brinda Instel contando un poco la clásica temática - lamentablemente de nuevo - de cómo se infravalora los recursos IT locales al tiempo que se sobreestima los recursos IT de afuera, y como eso se refleja en los negocios. Plus, les dejó a todos algo que siempre me gusta sugerir y es un contacto para que los interesados puedan llevar sus requerimientos de servicios comerciales formales si los tuvieran, para efectivizar sugerencias y recomendaciones aprendidas durante las ponencias.

Instel servicios y sorpresas (descuentos y cosas gratis!!!)
Al final del medio día, luego de lo de Instel, la gente se acercó y siguió la conversación sobre los temas tocados en mi charla y los pedidos de datos de cursos y talleres de Instel. Hubo buen nivel de feedback de la audiencia, haciendo algunas preguntas interesantes, hubo una de redireccionamiento de puertos que me dejó pensando, me sacó de los rieles, ya iba en automático, concentrado en los conceptos y pensando cual demo iba a hacer, pero paré la charla, pensé unos 15 seg. que habrán sido eternos para algunos con tendencia a la verguenza ajena, la verdad yo estuve reviendo un par de posibilidades y viendo si contaba el tema de redireccionar puertos cambiando de puerto del router al host, pero dije que los hackers en la sala iban a reconocer el truco, pero la audiencia iba a quedar perpleja, así que expliqué bien la respuesta y pregunté si había más dudas, todo bien y listo.

Se habló de los próximos pasos en cursos y talleres pagos (SQL Injection, Forensics, etc.), que los interesados pueden ver en la página del instituto Instel (por si alguno lee, todavía no están los días-horarios de los talleres, fijénse nomás). Esto está bueno, la gente quiere aprender a hacer, aparte de "ver", y aunque no sea masiva la concurrencia, el poder ofrecer talleres - incluso pagos - es algo positivo para la SSHN4.

Con un golpe de efecto bárbaro, justo al terminar de hablar Pedro Cacivio, se acercó Leonardo Pigner y comentó sobre el aporte de la gente de la Ekoparty a la Security Hacking en forma de entradas gratis para sortear, regalar y en forma de un descuento exclusivo para la Ekoparty 2009 (falta poco...www.ekoparty.com.ar).

La siesta de impasse
Terminó el ritmo del medio día ajetreado a las 14.00 más o menos, todos se fueron a comer, para arrancar de vuelta a las 15.30, ahí se armó un feedback entre los que nos quedamos, retomando temas de las charlas dictadas, los ponentes dando muestras de ganas de difundir y callándose poco en general. Fotos por montón, todas a la web de seguro, para alimentar las futuras ingenierías sociales y sustituciones de identidad como les decía en mi charla, pero es el espiritu y el miedo no puede reemplazar la prudencia ni paralizar el vivir.

Al rato largo llegaron unas docenas de empanadas para la gente del staff, y que se repartieron cooperativamente entre todo el que se acercó a llevarse una, igual que las cocas. Yo anduve paseando con una bandeja ofreciendo comidas por locaciones no estándares del evento, y cuando volví todos me miraban con cara de "Ahhh, vos te llevaste la comida" jajaaj, pero se arregló rápido porque no daba para más el delay que inyecté en la ingesta de la comida..

Hubo varias máquinas OLPC dando vueltas que trajeron los muchachos de Tuquito (varias versiones de ellas y todo), y los asistentes metieron mano, hicieron criticas, etc.

En cierto momento de la previa de las charlas de la tarde, Pedro se puso a vender los cds de Tuquito para hacer "la vaca" para la gente que vino de visita con cosas que ofrecer, y los asistentes aportaron generosamente unos módicos 10 mangos por un cd del último Tuco, con arte impreso y todo arriba del disco...ahí lo tengo en testing en un máquina virtual, llegué hasta el reboot y apagué la vm para crear suspenso...

Las charlas de la tarde
Al rato entró la gente de Tuquito a dar su 2da. charla del evento, esta vez presentando su distribución en versión 3 directamente en el evento. La buena onda y la calidez de los ponentes fue la nota sobresaliente de la charla, contaron mucho sobre la actualidad de las distros argentinas y sobre el proyecto Tuquito y sus diversas ramificaciones (Garfio, Openweb, etc.). Esta no era una charla técnica así que muchos asistentes primero se inquietaron un poco y después fueron claramente superados por la habilidad de oratoria de los ponentes.

En esta charla estuve full, aprendiendo oratoria top de Mauro y Cía., al rato aplausos, despedida y corte..suspenso para la esperada charla de Pigner.

Arrancó Leonardo contando un poco quien era a la audiencia, bastante numerosos lo que demuestra algunas capacidades investigativas básicas como mínimo de los asistentes, ya que no se hizo mucho ruido sobre el importante background de Leonardo, y así incluso había más gente que en otras charlas.

Después vino una intro a la Ekoparty que algunos no conocían y cuando vieron la breve intro en video ya estaban preguntando por lo bajo como llegar...parece que veremos más gente del interior en la Eko de este año...

La temática de la charla trató sobre atacar al usuario final dentro de las redes en vez de atacar la infraestructura, Pigner abarcó diversos subtemas haciendo entrar de vuelta en pánico a la gente, jeje, sin anestesia; después llegó el momento de los incómodos metadatos de fotos bajadas de Internet (incluídos un par de desnudos públicos no intencionales), lo que llevó los movimientos incómodos dentro de las butacas a un pico...Después vino la exposición de varias fuentes de información pública en la red mostrando como se puede apuntar al usuario final usando redes sociales y sistemas públicos derivados disponibles en la red. Hubo cuatro demos en vivo mostrando la explotación y posterior reverse shell vía ejecución de archivos .doc, .pdf, por contacto con Firefox e Internet Explorer.

Todo se dió como reloj y la gente quedó muy contenta, aparte de interesada. Aplausos que duraron un rato...la firma de una buena ponencia.
Yo me fui saltando de contento de la ponencia porque ví que no importa la distancia, un buen análisis siempre llega a conclusiones similares y mi ponencia se tocó temáticamente con la de Leonardo casi punto por punto, y que voy a decir, soy un orgulloso novato en el hacking ahora..

Para cerrar el evento se sortearon entradas gratis a la Ekoparty y remeras de la SSHN4, sldos. a todos e invitación para ir "a los bifes" en la competencia de hacking...asistencia libre, como participante o espectador.

Los Juegos
No terminaba nada todavía, ahora se venía la competencia de hacking. Este tema fue crítico durante la planificación, con expectativas mixtas en cuanto a la participación de gente, sin embargo al llegar al salón donde estaba montada la LAN de laboratorio para la competencia, ya había varios teams listos para empezar el zafarrancho de combate, y algunos nuevos se estaban armando...

Aquí me invitó a hacer team con él Ulises2k, yo accedí a participar aclarando mi calidad de co-piloto/novato full en hacking...pero no en informática. Así arranco la competencia con 3 juegos disponibles, 3 niveles de dificultad y por tiempo.

El primer juego era bastante simple, básicamente un share compartido netbios a disposición de quien quisiera montarlo; sin embargo la emoción del arranque hizo que todo el mundo le "tirara" con todo a la IP target, incluídos varios scripts propios, scanners de puertos con parámetros exprimidores al mango, algun Metaexploit "al boleo" luego, etc. Alguno cazó el router wifi por default, le cambió el user/pass de administración y todos los demás quedaron afuera...jeje
Al final terminó el tiempo y nadié ganó, jajaja, con las caras de no-era-tan-bueno-como-creía cuando Pedro, Bosco y Zapiola contaron como de fácil era el tema...jajaja

Acá ya había ganas de revancha, el 2do. desafío era taladrar un acceso a un server vía sql injection, con user/pass, para usarlo luego en un panel de administración (eso entendí). Acá sí, múltiples estrategias, desde el testing manual, hasta el automatizado hicieron aparición. Yo estuve con el ganador de este nivel como les decía; Ulises2k desarrolló una estrategia clásica y metódica, usando varias herramientas dumpeando la información necesaria hasta encontrar los datos...y se quedó con una placa recordatoria creo.

El tercer nivel arrancó al toque, otra IP, un server windows, nos dieron 2 exploits, uno python y otro C, fuentes para compilar, con compiladores y un .exe server tftp para win también. Los exploits no compilaban, tenían errores y había que encontrarlos, un par cada uno. La otra parte del desafío era conectarse al XP target y crear una cuenta con el nombre del competidor.

Rápidamente varios corrigieron los fuentes de los exploits, pero había una cierta confusión, varios preguntando "esto es así nomás?", se ve que a muchos les estorbaba su alto nivel y estaban buscando algo más oculto..pero era así de fácil: arreglar el fuente python, "tirarlo" contra el XP, ahí volvía una shell y...después había que descargar el otro exploit para añadir el usuario...solo que el fuente C no era un exploit sino solo una listado de comandos a correr en el XP...

En un punto se "cayó" el switch (Deny Of Service adrede, lo tumbaron lo' vago' para hacer tiempo claro), después el server tuvo un problema, colgado, tal vez un DOS para hacer más tiempo todavía...jajaja. Al final se levantó el server y todos los competidores entraron juntos al XP, mientras algunos trataban de levantar el 2do. exploit al XP, con Ulises2k vemos el prompt de la consola "document and settings\administrador"...jajaj, el python era un exploit de vulnerabilidad crítica..shell root remoto en seco..no hacía falta escalar nada, ningun nivel, nada de 2do. exploit..miramo el código C y nos damos cuenta que no es nada...comandos nomás..copy-paste de comandos y usuario ulises2k creado..listo.

Acá el premio fue groso, la entrada gratis a la Ekoparty y una remera de la SSHN4, fotos, más fotos y luego todos a sus respectivas casas. La gente que se quedó hasta el final tuvo un meeting despedida a continuación en una buena pizzería de la ciudad, bebidas y charla animada por lo que vi en las fotos, yo me fui a dormir de una.

Nota: críticas para la competencia, bah, siempre suelen ser un poco engorrosas, mucho gente, hardware dando vuelta, sin embargo:

- Es bueno tener buena ram, un par de máquinas virtuales en pausa con las mismas configuraciones, por si "bajan" alguna :-), para poder subir de nuevo la otra de inmediato..
- El tema electricidad fue crítico, cortó una competencia en curso, para la próxima, más de una zapatilla para enchufes y no más de una zapatilla por tomacorriente.
- Otra crítica es la definición de las competencias, parte de la dificultad de los retos fue que los partipantes tuvieron que averiguar a los gritos que había que hacer porque no había definiciones por escrito en ningun lado..para la próxima, pizarrón, tiza y listo.
- La competencia estuvo muy buena, la próxima vez podría hacerse más temprano, a mitad del evento y en el auditorio principal, para que los espectadores sean la mayoría de los asistentes y puedan disfrutar del espectaculo y de las explicaciones.

Terminada la SSHN4, todo listo para el año que viene...

Fotos y otros comentarios aquí:

http://kungfoosion.blogspot.com/2009/08/de-vuelta-de-sshnea.html

http://picasaweb.google.com/lpigner/SSHNEA42009

Crónicas de SSHN4: Día Uno

2009-08-26T08:16:00.000-07:00

Bueno, estuve juntando ganas de escribir algo muy interesante, bien estructurado y no se dió...disculpen. Voy a poner lo que salió en vez de lo anterior.

Día Uno

Hacia la SSHN4...
Llegué al evento después del laburo, quería arrancar poniendo la cara desde el vamos pero salió trabajo y la debida responsabilidad - hablando del término legal - es un lindo incentivo para poner hs./hombre al servicio del empleador cuando tu voluntad se toma el día libre (no vos); así que ya había pasado la primer charla de Pedro, donde mostró un par de cosas sobre intrusiones y vulnerabilidades que no pude ver, así que arranqué al llegar más o menos, 15.00 hs. del viernes.

El ambiente del equipo de trabajo estuvo excelente durante las dos jornadas, estuvimos mano a mano compartiendo impresiones, charlando sobre tecnologías y técnicas de todo tipo, coca,mate,torta de por medio (ese día había un cumpleaños en ciernes por cierto). Asi que el hall del evento estuvo a full, las chicas de Instel trabajando codo a codo recibiendo gente, orientando invitados y visitas de diversos lugares.

La asistencia
Hablando de los asistentes, fue menos de lo esperado, una lástima; causa probable al 99%: el costo de la entrada. La mayoría de los asistentes estaba repartida en un grupo casi igualado de estudiantes de sistemas, profesionales de informática y profesionales de especialidades no informáticas con interés en el campo de la seguridad.

Hay mucho análisis socio-económico para hacer aquí (no hay aumentos de sueldos en Ctes. hace casi un año, casi todo dicho), lo concreto es que a pocos novatos y estudiantes - normalmente sin ingreso fijo - le sobran $50-35 y la seguridad informática evidentemente no es de fuerte interés en la comunidad de profesionales IT asalariados de Corrientes.

En una nota positiva debo recordar la presencia de muchos interesados que se movilizaron dentro de sus organizaciones mostrando la necesidad de participar de conferencias locales como la SSHN4, logrando no solo el permiso de asistencia sino también la cobertura de gastos y entradas.

La comunidad no técnica correntina y de otras pcias. acompañó fielmente el evento aportando una gran cantidad de asistentes que recibieron al debida atención de los ponentes cuando se simplificaban y se re-explicaban conceptos ya mencionados des-tecnificandolos para mejor comprensión de la audiencia no técnica.

Se mencionó algo también como posible razón de la baja asistencia, el prejuicio - algunos dicen masivo - de muchas personas de IT en Corrientes para con el evento, devenido de eventos negativos de la edición SSHN3-2008, que se hizo en Resistencia. Yo no estoy de acuerdo con esto y creo que el tema económico prevaleció por lejos como razón para no asistir.

Al final creo que se llegó a las 200 personas por jornada, pero no tengo a mano números oficiales, y lo calculo sobre sillas cubiertas a simple vista (el auditorio tiene capacidad para 400 personas aprox.), que eligieron diversas charlas para ir masivamente y algunas no tanto. La idea principal fue al parecer comprar la entrada y venir a la hora en que se esperaba se diera una charla de interés para el asistente (lo que nos dice mucho de cuanto hay que respetar horarios y charlas).

Charlas que no se dieron
Como siempre, puede fallar. Algunas charlas fueron reemplazadas y corridas de horario imprevistamente, justo a media mañana del viernes, por lo que muchos de los compraron las entradas no lo sabían. El motivo fue una afección de salud inesperada de uno de los ponentes y accidente de tránsito (sin consecuencias graves), en el otro caso.

Los imprevistos fueron múltiples - la mala suerte llega en patota decía un amigo - y la gente mostró comprensión en la medida de lo posible y hubo caras largas por varios motivos (permisos pedidos para salir en hs. de trabajo a la cabeza). Finalmente se dieron algunas de las charlas corridas (no sé bien cuales no se dieron porque estuve bastante tiempo fuera del auditorio durante el viernes).

El lugar
Quiero contar un poco el contexto, como estaba el lugar. No conocía de antemano el salón del Hogar Escuela así que me sorprendió lo grande y cómodo que era. Asientos y respaldos individuales con almohadon, tipo butaca...una gran mejora desde los típicos asientos duros de facultad que acostumbramos usar en otros eventos. El escenario tenía buen espacio, tuve que mirar dos veces para razonar que había dos pantallas gigantes. Una tenía proyectada la imagen de un cañon conectado a la notebook del ponente de turno y la otra tenía proyectada - otro cañon - la imagen tomada en vivo de una cámara de video manejada por un operador que estaba constantemente mostrando con el zoom apropiado, las partes más relevantes del monitor del ponente, segundo a segundo durante toda la charla. Groso, esto último no lo vi acá en un evento de informática o me perdí alguno muy bueno.

Desde otro punto de vista quedó habilitada la posibilidad de decir "sí, señor Juez, quedó todo grabado" (por las dudas legales).

El equipo de sonido del lugar estuvo bien dispuesto y no tuvimos problemas en escuchar a los ponentes y a los asistentes en ningun momento, un par de micrófonos inalámbricos le dieron libertad de movimiento a los ponentes, que utilizaban a cada minuto para conectarse mejor con su audiencia.

Los baños estaban bien para ir, no para quedarse; los baños de mujeres suelen tener el requerimiento de quedarse, habría que preguntar a las chicas por críticas de ese lado. Yo les doy un 8 del 1 al 10.

La movida estuvo bárbara, había en el aire las ganas de la gente de ver algo nuevo, de escuchar cosas interesantes, lo que la seguridad informática suele brindar casi siempre a los no especializados en ese ámbito. El arranque fue un bache largo para mí ya que llegué a media siesta pero me contaron que estuvo muy movido mostrandose algunas evidencias de que la inseguridad informática puede estar en cada rincón (muchos hablaban de la charla de Pedro y de repente bajaban la voz diciendo "banco" y miraban para los costados...en fin), incluso los que consideramos y esperamos que sean seguros.

Durante las charlas en breves escapadas y entre charlas se dió la conversación todos contra todos y cualquier asistente podía acercarse al grupo de Instel permanentemente disponible en el Hall y conversar de cualquier tema que se les ocurriera. Hubo poca timidez y la audiencia se lanzaba directamente a los ponentes de charlas anteriores que estaban/estabamos dando vueltas fuera del auditorio para preguntar cosas, aclarar dudas, etc. algunos nos trajeron ideas interesantes, y se armaban rondas de bastante a cada rato, hicimos conocidos que se mantendrán en el tiempo.

Crítica oída: faltó el café y las facturas a la mañana, una mesa con agua fría y jugos, y algun convite a la tarde y coincidí, la comida gratis en un evento pago es esperada y deseada.

El evento
Ví unas fotos comprometedoras para las múltiples dietas en proceso de extinción crónica constante típicas del invierno, donde se veía a los perpetradores atacar rápida y efectivamente cuantiosas porciones de $COMIDA-CHATARRA en el local de comida agraciado con la visita de más comensales que de costumbre, en pleno medio día de almuerzo. Risas y demás, el acompañamiento posta de un pecado bien implementado.

Arranqué en serio viendo las charlas de Bosco y Zapiola ya casi superada la siesta, de muy buen nivel ambas. Bosco debutando como ponente y de primera, muy buen nivel técnico; Zapiola mostrando que si se entiende bien un tema, se puede encontrar la manera de explicarlo de modo simple.

Algo que se discutió puertas adentro fue la posibilidad o no de subir el nivel de las exposiciones de ser meramente demostrativas a directamente ser workshops en vivo sin práctica, y se optó por lo segundo, con resultados a la vista.

La charla de inyección sql recorrió lo básico del tema, después avanzó a otro nivel al tiempo que J.F. Bosco enseñaba a la audiencia las técnicas siguientes en escala de dificultad (Timed Sql Injection y Blind Sql Injection se salen de escala para calificarlas "básicas" o no?), para finalizar esas explicaciones en un largo y detallado paso a paso, explicando punto por punto un caso real de inyección realizada a mano (artesanalmente vs. el empleo de herramientas automatizadas, muy usadas al momento). Se vió claro el tiempo dedicado a perfeccionar las explicaciones para que salga todo bien en vivo, y los asistentes estaban muy contentos al final me pareció.

Al rato arrancó la charla de Zapiola, primero lento, muy tranquilo al estilo de Alejandro, se apreciaba a simple vista la concentración necesaria para condensar un gran cúmulo de información disponible mentalmente en pocas y significativas palabras. Como en el caso de Bosco, toda explicación era tendiente a lograr la comprensión cabal del concepto de parte de la audiencia. Bueno, acá viene la parte en que el almuerzo, el sistema digestivo y varias horas de laburo me dieron sueño, así que salí a despejarme con unos mates en el Hall; vía puertas de vidrio veía como la charla de Zapiola seguía en pie a full (simple de ver: la charla se pone más dura a nivel técnico y nadie se levanta de sus asientos). Aplausos, un ratito de más, rompiendo la idea de que eran para cumplir, ja, Bosco pensó que iba a ser el único con aplausos de más de 5 seg. de duración.

Mucho video, stop, explicación, preguntas, ponente pensante por varios segundos (pensando en serio), respuesta, y devolución de pregunta "¿conforme con la respuesta?", "todo bien" en respuesta, se dieron durante esas charlas explicativas.

Una constante durante todas las charlas fue el que los ponentes interrumpían regularmente sus presentaciones para dar lugar a los asistentes a plantear preguntas, pedir re-explicaciones de temas, etc. Muy bueno eso y espero verlo de seguido en otras charlas porque ya nos mal-acostumbramos todos a no esperar hasta el final de las presentaciones para entrarle a los ponentes con preguntas.

Estuve en las dos charlas y me parece que cualquiera que hubiera tenido ganas de preguntar algo complejo o de buen nivel podía haberlo hecho, si no se dió tal vez fue por decisión interna de cada uno.

Estuvo presente también una audiencia de visitas de muy alto nivel y en ese caso y por ahí conversando calificaron el nivel de algunas charlas en general como un poco básico, lo hicieron sin mala onda, con todo respeto y sin dejar de rescatar la habilidad de los ponentes para enseñar y mostrar todo el conjunto de conceptos de técnicas complejas en poco más de hora y media; yo les hice el feedback de lo del nivel de la audiencia, distinto de la gente de Bs.As. y que hace falta bajar un poco a los conceptos, por eso Bosco, Zapiola y cía. estuvieron a full de conceptos básicos, casi repitiendo papers originales de las temáticas que tocaron, y hablamos de publicaciones de los 90` y principios de 200x. Más tarde durante la competencia de hacking se mostró realmente el nivel de varios locales, y Bosco y Zapiola pedían pista, pero Cacivio les dijo que no, hay que dejar espacio para la nueva generación muchachos...

La tarde continuó para mi en presentaciones de gente y conversaciones fuera del auditorio, aunque pude ver a mucha gente quedarse hasta bien pasada la tarde y ya llegada la noche. Alguno contará que tal les fue en las demás charlas.

Por mi parte conversé mucho con los asistentes al evento, compartiendo información y tips de todo tipo, mostramos fierros (notebooks) y como siempre las otras nos gustan más que la nuestra (había fierros increíbles y las Dell que todo el mundo quiere estaban como plaga por todo el evento). En este punto ví el profile neutro para sistemas operativos de la mayoría, con muchos win-vista a la vista, ja, varios xp ultratuneados (50 íconos a la vista en el escritorio), y claro, varios Ubuntu, un par de Backtracks que todos miraban para ver si estaban haciendo algo "interesante"...sin suerte, solo lectura de papers muchachos, full legal la gente, un chiche.

Conversamos mucho con Leonardo Pigner (kungfoosion.blogspot.com), la visita de lujo oficial y también con Ulises2k (www.ulises2k.com.ar), la visita de lujo no oficial (para la próxima ya va a ser oficial, es la promesa, y vamos a ver si lo convencemos de dar el salto al escenario), ambos especialistas en seguridad sumamente calificados y que vinieron aquí motivados por el contacto con la gente de seguridad IT local, para conocer a estos hackers del interior que estaban haciendo ruido por los foros de la red; se agradece la buena onda, la buena predisposición para hacer de todo, por compartir todo tipo de información técnica, tips sobre seguridad IT sin limitaciones y sobre todo por la empatía con la gente de acá; vinieron de visita, pero jugaron de locales como ya se dieron cuenta a los minutos de estar acá. En algun momento todos nos dimos cuenta que Leo y Ulises estaban entre pares, hablando mano a mano locales y visitas, casi con sorpresa largando jeringoza técnica alegremente y esquivando limpiamente ellos y nosotros el prejuicio típico de que lo de afuera es mejor.

Yo me retiré temprano del evento, cuando el sueño concretó su objetivo con el éxito habitual al que está acostumbrado...los muchachos y la audiencia siguieron un rato largo, y el equipo organizador+visitas se fueron a cenar para recargar pilas. 9.00 hs. era el horario de arranque del sábado y yo ya estaba sintiendo las primeras pulsaciones de adrenalina típicas de la presentaciones.

Solucionado: Arreglar el automontaje de dispositivos USB en Opensuse

2009-08-20T08:41:00.000-07:00

Los trucos simples son los más olvidados de todos, alguien descubre o deduce como se resuelve algo, lo hace y lo olvida; al cabo de un tiempo el problema vuelve a surgir...vamos a Google y encontramos 40.000 personas en la misma situación, pero empeora...todos están posteando simultáneamente sus medias-soluciones a foros, blogs, howtos...y tenemos que explorar hasta encontrar la solución real.

Un tip, busquen "solved" y "solucionado" en el navegador, acelera mucho el tema aunque encontramos montones de soluciones a problemas parecidos y estamos casi en lo mismo...

Resulta que usando USB keys (llaveritos), en algun momento podemos tener algun problema, corrupción del filesystem y similares (hay uno relacionado con un cuelgue de gparted que deja una regla HAL de no montar...el peor por lejos).

Si estamos en Opensuse y se nos ocurre formatear el llaverito con YAST, nos quedamos sin automontaje USB.

Es raro el problema porque se puede montar desde la línea de comando, como root, con sudo con usuarios, todo funciona bien menos el montaje, ni en KDE 3, 4 ni en Gnome, toda herramienta "automontadora" deja de funcionar. Si rebootemos la pc, aparece montado como si nada estuviera mal...

Esto nos lleva directamente a un problema generalizado, así que hay que ir a la fuente. Lo de HAL está bueno, y hay que revisarlo especialmente si estuvimos chequeando el /var/log/messages y saltaron muchos errores de bloqueos diversos.

Sin embargo lo anterior podemos verlo después de mirar un poco /etc/fstab, de seguro que justo antes de formatear no lo teníamos a la vista, pero si miramos luego del formateo nos encontraremos con dos líneas sospechosas:

usbfs /proc/bus/usb usbfs noauto 0 0
...
/dev/disk/by-id/usb-Kingston_etc.etc. /media/KINGSTON vfat users,gid=users,umask=0002,utf8=true 0 0

parece como que YAST configuró nuestro llaverito USB como una partición estándar, de seguro que si lo tenemos conectado a la pc y la encedemos vamos a encontrarlo....montado..que es lo que vimos al rebootear la pc!!!

El "noauto" es claro, no automontar filesystems USB, una instrucción directa al kernel desde /etc/fstab.

Así que dejamos esto así:
usbfs /proc/bus/usb usbfs noauto 0 0
...
# /dev/disk/by-id/usb-Kingston_etc.etc. /media/KINGSTON vfat users,gid=users,umask=0002,utf8=true 0 0

(la línea "Kingston" queda comentada completa, no en dos renglones si les aparece así en su navegador).

Desde MC hago (guardar), saco mi llaverito, lo conecto de vuelta y vualá! - como e escriba - los viejos mensajitos popup saltan avisando que hay un dispositivo conectado y...automontado...por fin.

De yapa les dejo un link para aumentar la velocidad de copia si les anda muy lenta la transferencia de archivos hacia llaveritos USB:
http://en.opensuse.org/SDB:Automounting_without_the_sync_Option

Reinstalando Opensuse vía USB key, Unetbootin a la cabeza

2009-08-07T04:49:00.001-07:00

Que tal, resulta tuve un percance con una partición del disco, se llenó y no tenía ningun monitor configurado, plus había configurado un par de cositas para que el comit de transacciones fuera más lento que de costumbre (menos escritura a disco, más batería para la notebook), y como es un filesystem journaling, al llenarse hubo un temita de sobreescrituras en el espacio reservado por el filesystem para su laburo normal.

Al final me encontré sin DVD/CD de instalación y queriendo instalar vía red Opensuse, había recuperado unos "pedazos" de la partición, pero se estropeó definitivamente la GUI (librerías presentes de nombre, pero sobreescritas con basura durante el fsck de rigor). Asi que me puse a mirar cómo instalar Opensuse vía llaveritos USB...

Opensuse no soporta formalmente este método, así que, claro, hay varios tutoriales oficiales incluso, los probé, hay uno en

http://en.opensuse.org/SuSE_install_from_USB_drive

y no me sirvió para nada, completé todos la pasos y requerimientos y el script falló con mensaje de error y todo, no seguí viendo eso, y probé de vuelta con Google, ahí encuentro mi pregunta repetida varias miles de veces "how to install opensuse from usb key"....y un flaco le responde a otro tipo - english - "por qué no usás Unetbootin que es la posta" y yo dije, "por qué no?" (lo tenía instalado en los restos de mi viejo sistema, y un oportuno LXDE que sí funcionó, y las librerías de KDE3 en buen estado ayudaron bastante).

Unetbootin, básicos
http://unetbootin.sourceforge.net/

Es una aplicación KDE3, así que preparénse para instalar un par de dependencias si quieren correrla y no usan nada de KDE3 (mmm, seguro que un K3B tienen por ahí...), por lo demás todos aseguran que funciona al 100%. Por mi parte comprobé el tutorial básico exitosamente:

- bajar una .iso instaladora
- ejecutar el programa...

* autodetecta el drive usb y muestra los demás discos-unidades (por las dudas),
* permite elegir la distro de la que se quiere crear el USB booteable, por el nombre
(esta parte me pareció excelente, hay listadas distros nuevas, opensuse 11.1 entre ellas,
y son un montón)

- después se elige la distro de la que se va a crear el USB booteable

*el USB tiene que estar en FAT32 por cierto y con espacio libre...
* no hace falta que esté vacío, para quienes tengan datos, unetbootin no borra nada, a menos que coincida con algun nombre de archivo o directorio que esté en la .iso elegida (un cierto "windows-bak" es difícil encontrar en una .iso instaladora de Linux por ejemplo, ahí pueden guardar lo que ya tenga el llaverito)

- se crea el USB booteable

* Unetbooting copia los archivos de la .iso al llaverito, ya sean 70 MB (en la mini .iso instaladora vía red para Opensuse), o un dvd/cd completo de instalación de nuestra distro preferida.

Unetbootin tiene otra función, incluso listada en su sitio, como les dije la interfaz tiene listadas todas las unidades de disco, las particiones disponibles, y nos permite crear una partición de disco que contenga - como si fuera un USB-key - todo un CD/DVD de instalación normal...o sea que si tenemos un poco de espacio disponible, 5 GB, podemos crear una partición ahí, volcar nuestro instalador - opensuse, mandriva necesitan espacio para acomodar lo que contiene un DVD, Ubuntu necesitaría menos, 800 mb).
Para accederla nos faltaría tener una entrada extra en nuestro Grub/Lilo para cuando haga falta reinstalar (fácilmente creable desde los respectivos panelles de control de Opensuse, Fedora, etc.); también se podría acceder directamente desde cualquier Grub contenido en discos de instalación de cualquier distro (Fedora para instalar Mandriva, Ubuntu, etc. etc.)...eso ya tiene más que ver con Grub.

Obviamente también nos queda "derecho" para usarla desde el dvd/cd instalador de la distro eligiendo como origen una partición en el disco.

Reinstalando Opensuse vía USB

Finalmente, ya booteando el USB-drive (historia aparte es como realizar eso en cada pc-notebook, aparte de ver en la bios en sí, vean las "F" en la pantalla de boot del bios, para elegir el dispositivo a bootear), elegimos "linux" de un feo - por los colores, fuentes - listado (en la .iso instaladora vía red también está la GUI - tamaño de descarga menor - de reparación y la de rescate propias de Opensuse), y va a arrancar la carga normal del instalador, arranca una GUI modo texto, ncurses de la vieja escuela, Debian, etc., llega un momento en que pide el "DVD1" o "back", hacemos "back" y luego le damos a comenzar la instalación de red, me pide elegir entre las dos interfaces (eth0 y wlan0), cual quiero configurar y usar para la instalación, le doy a la eth0, ¿quiere configura por DHCP? sí, configura, pide un server de red (http, nfs, ftp, etc.), escribo "http://download.opensuse.org", no encuentra el server, ¿cómo?, alt+2, 3, 4, encuentro una consola, digo "sos boleta instalador medio pelo", ifconfig, está la ip esperada, ping www.google.com, anda, resuelve el nombre, vuelvo al instalador alt+1...escribo "download.opensuse.org", entra bien, pide directorio donde buscar el instalador..."distribution/11.1/repo/oss", listo, empieza a bajar el instalador - unos megas sí - con alt+4 sigo viendo como bajan los archivos en modo texto (en la GUI veo un slide que no avanza nunca y altera la presión arterial), al rato termina en un error de update (¿?), alt+1, vuelvo a la GUI y le doy aceptar...arranca la GUI QT full de instalación de Opensuse, paso a 1024x768 en 16 bits...y hago una instalación normal, pero vía red (igualmente el instalador permite cargar manualmente nuevas fuentes de instalación, por ejemplo un dvd recien encontrado...sin palabras).

De lujo todo..que les sea util

Desde el backstage de la SSHN4

2009-08-04T16:15:00.000-07:00

Bueno, la SSHN4 (Seminario Security Hacking NEA 4ta. Edición), se mueve, la gente lo mueve. Esperemos el reconocimiento al esfuerzo de este año para superar por lejos la 3ra. edición y un par de glitches que tuvo (si recuerdan, critiqué el tema personalmente y ahora, dada la oportunidad, me puse a ver que podía hacer para que mejore).

Este año estuve colaborando con la organización, un aporte mínimo mío - en serio, no más de 5 hs. hasta ahora creo - a las sustancialmente mayores horas de esfuerzo de Seba del Prado, Pedro Cacivio y varias personas de Instel, para que la edición correntina de la SSHN salga "posta".

Recuerdo mucho una frase que leí ayer por el tema de Suse Studio: "Que tipos despreciables, quieren cobrar por el laburo que hacen" (es una ironía), y esperemos de nuevo que no sea ese el espiritu que mueva la opinión de la gente por el costo que tiene la entrada (30 mangos), también por eso quería contar un poco como es el backstage de la SSHN4.

Durante un par de charlas organizativas se tocó un tema importante en este tipo de eventos, personalmente trato de apuntar a mostrar y demostrar al público un alto nivel de detalles técnicos durante las charlas, creo que es la forma en que la audiencia profesional IT recepciona con mayor aceptación cualquier charla de temas IT...sin embargo mi punto de vista tiene un límite práctico: no toda la audiencia son profesionales de alto nivel de cualificación, hay muchos estudiantes, autodidactas en distintas fases de aprendizaje, público en general, etc.
En ese caso, la charla con mucho detalle técnico no "aclara" sino "oscurece"; así que conversando decidí presentar un tema simple en apariencia, pero que demuestra de modo amigable conceptos clave del hacking típico, el que supuestamente toda la gente de IT debería conocer, pero no siempre lo hacemos.

Las otras charlas de la SSHN4 también portan el espirítu de mostrar de modo simple temas complejos, para que todos vayamos, nos sentemos, escuchemos, y entendamos, no solo algunos pocos "gurues" o tipos que "saben un montón" (que también van a entenderlo).
Les recomiendo a los IT pro de alto nivel técnico y experiencia ir con ganas de hacer preguntas difíciles a los ponentes cuando llegue el momento, puede que se sorprendan gratamente por el nivel de las respuestas, ya que muchos ponentes tuvieron que hacer un esfuerzo considerable para simplificar su forma típica de explicar diversos temas, y cuando responden las preguntas, se van "de 1ra. a 6ta." en un tirón normalmente.

Hay varias charlas que pueden parecer ya rutinarias para los asistentes a otras charlas de Instel, pero que se renovaron y mantuvieron porque tienen buena acogida del público, y eso es importante (más teniendo en cuenta que tiene costo la entrada); hay otras charlas este año tocando temas interesantes, de las que puede rescatar importantes comentarios sobre tematicas de la seguridad IT actual.

Para los que recuerden ediciones anteriores y otros eventos en que escucharon a algunos ponentes locales, les recuerdo que el tiempo pasa y los muchachos siguen mejorando, algunos novatos de antes ya están maduros al día de hoy - hay un pibe, Seba del Prado que la tiene con la Wifi Security, ahora sabe un par de cosas ;-) - y tienen mucho que decir, y ahí tienen sus charlas, recomiendo obviar por esta vez las típicas subestimaciones basadas en haberlos escuchado "alguna vez", lo de la 2da. oportunidad aparte de linda frase está bueno como un modo entender que las cosas son dinámicas, todo cambia, y puede mejorar.

Entre varias visitas, destaco la presencia de Leonardo Pigner, un groso hacker para acortar las referencias; que es co-fundador de BASE4 Security, una empresa de seguridad IT en Bs.As., y también es uno de los fundadores de la conferencia de seguridad y hacking más grande de latinoamérica, la Ekoparty - www.ekoparty.com.ar.

Pueden ver algunas referencias de Leonardo en su perfil Linkedin y en su blog:

http://www.linkedin.com/in/lpigner
http://kungfoosion.blogspot.com/

Personalmente estuve conversando con otros grosos hackers del ambiente nacional, y la gente de la SSHN4 también, sin embargo no dan los recursos locales todavía para traer a toda la gente que tiene ganas de venir, pero que de momento, no pueden donar su tiempo sin alguna retribución que no hubiera sido posible brindar si se quería mantener accesible el costo de la entrada.

Recomiendo mucho aprovechar la data que tiró Sebastian del Prado en la lista de la Comunidad TIC e ir buscando en Google, nombre y apellido de los ponentes, ya que se van a encontrar con lindas sorpresas detrás de los nombres que muchos podemos no conocer.

Para cerrar, quiero contar que organizar estos eventos conlleva un buen número de horas de trabajo, se gasta plata de bolsillo propio, no se gana plata - al menos por ahora (aunque se gane unos mangos, no representa "buena plata" frente a la cantidad de horas trabajadas), la gente que lo hace se suma a otros, los invitados vienen de afuera a invertir su tiempo - y plata incluso - y no se van a llevar miles de nada, vienen a colaborar hasta donde pueden con la gente de IT local.
Hay diversas motivaciones personales y grupales, obviamente algunas económicas (no se puede vivir del aire, pese a los rumores al contrario), otras profesionales, y otras más, de fondo siempre, mucha - pero mucha - buena onda con la seguridad IT y ganas de hablar un poco de lo que nos gusta, seguridad, hacking, etc. ...en conjunto todo tira a "estar", acá, en el NEA, a crear un ambiente IT local groso y si llegara a salir eso, todos van - vamos - a salir ganando, por eso creo que es bueno apoyar estos eventos, llámese SSHN4 y otros anteriores Flisol, Whyfloss, etc. etc.

Suse Studio: distros personalizadas con soporte oficial

2009-08-03T08:47:00.000-07:00

Novell ha publicado un servicio de creación de distribuciones personalizadas desde una interfaz web. Con Suse Studio puedes ir al sitio, diseñar tu distribución desde el navegador, podrás probarla y arrancarla en una máquina virtual y ver cómo se ve desde tu navegador, luego tendrás tu .iso para bajar e instalar.

Lo más importante es que Novell brinda soporte oficial a estas distros personalizadas, con lo que la creación de appliances pasa a convertirse ahora en otro servicio que se puede comprar y utilizar empresarialmente.

El deployment de software enterprise acarrea muchos desafíos técnicos serios. Lograr que una pieza compleja de software de servidor entre en funcionamiento en una infraestructura requiere a menudo que los administradores de sistemas luchen con problemáticas de dependencias lógicas y de configuración. Los appliances están siendo vistos últimamente como una solución de fondo a este problema.

Un appliance es un montaje preconfigurado que incluye el software y un sistema operativo mínimo que lo puede correr con un mínimo de uso de recursos. Este concepto se denomina JeOS ("Just Enough Operating System").

Hasta ahora, si bien había excelentes y múltiples herramientas para crear appliances o distros personalizadas Linux, varias con interfaz gráfica, incluso algunas con interfaz web, ninguna tenía la posibilidad de ser adquirida por una empresa y recibir soporte oficial.

Los appliances de Suse Studio heredan el hardware y software soportado y certificado, derivado de SuSe Linux Enterprise Server (SLES), a la vez que un appliance también puede ser montado usando OpenSuse como base (con las últimas versiones de software, aunque con menos tiempo de soporte oficial y no oficial); Novell se mueve así en una jugada claramente orientada a los nuevos mercados abiertos por la virtualización en sus diferentes implementaciones.

Suse Studio puede construir appliances en varios formatos, y se puede generar imágenes que pueden ser instaladas en hardware físico tradicional, entornos virtualizados y servicios "cloud". Puede crear imágenes en formato estándar de VMware y Xen, ISO de live-cds instalables, e imágenes raw que pueden ser volcadas directamente en discos rígidos o medios removibles como llaveros USB o discos SD. Novell dice que próximamente incorporará soporte para imágenes Amazon EC2 (cloud computing).

En el sitio de Suse Studio puede verse un screencast flash donde se muestra la creación de un appliance, también hay varios artículos en la red con screenshots que muestran la interfaz de Suse Studio en acción:

http://www.genbeta.com/linux/suse-studio-a-fondo-crea-tu-distro-a-medida-y-pruebala
http://www.cesarius.net/las-primeras-imagenes-de-suse-studio-crea-tu-distribucion-linux-via-web/

Suse Studio ya está abierto al público (sin soporte oficial), pero por ahora se puede ingresar solo con invitación, que tarda de 3 a 6 meses en llegar luego de registrarse.

http://susestudio.com/

Fuente:
http://arstechnica.com/open-source/reviews/2009/07/hands-on-linux-appliances-made-easy-with-suse-studio.ars

Script para aleatorizar grandes colecciones de wallpapers en KDE4

2009-07-29T20:58:00.000-07:00

#!/bin/sh

# Este script sirve para crear un directorio de enlaces simbolicos
# a imagenes en otros directorios de una coleccion
#
# Escribí el script porque KDE4 lee todos las imagenes incluídas en
# el arranque cuando se elije el modo "Presentación"
# lo que eleva el tiempo de arranque y utiliza memoria inutilmente
# (no vas cambiar entre 20.000 imagenes en una sesion de 3 hs.)
#
# El modo en que se crean los nombres de archivo - los de los enlaces -
# garantiza que KDE4 no dejará de usar los nuevos wallpapers
# (ya que usará el nombre cargado en memoria, no conoce en particular
# ninguna imagen).
#
# Necesitas ordernar tu coleccion ordenando las imagenes en subdirectorios
# dentro de una carpeta que luego puedes colocar en la variable "COLECCION"
#
# Necesitas crear también un directorio donde se crearan los enlaces
# "WALLS"
# debes ubicarlo fuera de particiones de Windows (FAT32 y NTFS)
# ya que no soportan crear enlaces simbolicos
#
# El script elige aleatoriamente - sort -R - 6 directorios de
# de imagenes del directorio donde este la coleccion, luego elige
# al azar de vuelta, 50 imagenes de cada directorio.
#
# El script crea los enlaces con nombres genéricos y extension .jpg.
#
# No lo probé exhaustivamente, pero casi de seguro KDE4 carga las
# imagenes basado en el contenido del archivo, asi que la extension .jpg
# no importaría mucho en eso caso...
#
# El script vuelve a elegir al azar imagenes de la coleccion
# cada 30 min. (sleep 1800s)
#
# El mejor modo de usarlo en KDE4 sería
# probablemente lo ideal sería correrlo desde CRON o desde un script
# accesorio que ponga este otro script en background y cargar ese otro
# script desde la opción del panel de control de KDE4
# "Avanzado">"Autoarranque">"Añadir script"
#
# un ejemplo de un script lanzador de otros scripts?
#
# #!/bin/sh
# exec script.sh &
# exec otro-script.sh &
# exit

# directorio con directorios de wallpapers
COLECCION=/home/usuario/path/a/tus/carpetas/de/imagenes

# donde crear los links
WALLS=/home/usuario/crea/un/directorio/para/esto

while true; do

# esperar 30 min. antes de correr
sleep 1800s

# limpia los enlaces anteriores
rm -f $WALLS/*

# usar al azar 6 - seis - directorios de wallpapers
NUEVOS=`ls $COLECCION| sort -R | tail -n 6`

let NOMDIR=0
let NOMFILE=0

for i in $NUEVOS
do

let NOMDIR=$NOMDIR+1

# contar 50 archivos por directorio
CUENTA=`ls $COLECCION/$i/* | sort -R | tail -n 50`
# si quieres mas de 50, solo cambia el número luego de -n
for c in $CUENTA
do
let NOMFILE=$NOMFILE+1
ln -s $c $WALLS/$NOMFILE.jpg
done
done

done

exit

Charla para la SSHN4*

2009-07-15T07:42:00.000-07:00

* Seminario Security Hacking Nea 4ta. edición

Bueno, hace un mes más o menos me invitaron a participar del Seminario Security Hacking NEA (SSHN) 4ta. edición, que se va a realizar en Corrientes el 21 y 22 de agosto en el Hogar Escuela de esta ciudad (si quieren llegar, pregunten que todo el mundo sabe donde queda y tiene 4 manzanas de grande, no se pueden perder).

Al principio estuve pensando en presentar algun tema relacionado con administración de sistemas, un candidato interesante era Heartbeat+DRBD (un ejemplo), como solución de alta disponibilidad y replicación a nivel de bloques, algo en lo que estuve trabajando últimamente.
Otra idea era mostrar la construcción de una solución de proxy y filtrado usando Squid y Squidguard (plus otras herramientas), un tema del que estoy preparando un workshop y hubiera sido interesante mostrar a la audiencia como se monta una "solución" basada en Linux y como se van cubriendo las necesidades de la misma al estilo Unix, integrando componentes altamente especializados en un sistema que realiza el trabajo y satisface los requerimientos.

Luego estuve leyendo el blog del "chico malo" (Un Informático en el Lado del Mal), y encontré una serie de artículos muy buenos sobre LDAP Injection, con mucho repaso y puesta en práctica de ideas sacadas directamente de los papers de obligada referencia técnica en LDAP Injection, plus un par de cosas originales. Este tema lo propuse y fue aceptado, la idea original era hacer un replay de los artículos del "chico malo" en vivo + explicaciones de conceptos, y claro, el efecto "revelación" de ver un Active Directory y un OpenLdap largando alegremente toda la información que los administradores se preocupan tanto de restringir.
Finalmente no voy a hacer esta charla porque lo estuve analizando y el tipo de audiencia que se espera va a ser bastante diverso, inclusive se espera mucho público en general, no muy versado en casi oscuras cuestiones informáticas (levante la mano quien escuchó hablar de LDAP antes de haber pisado un NOC o un datacenter...). Por otra parte este tema si bien es muy interesante ya que es teoría y práctica de extracción de información, más potencial explotación, dentro de redes privadas y con credenciales limitadas; la realidad es que ví bastante complicado llegar a la simplificación necesaria para que un público no técnico pueda captar y entender la importancia de este tipo de vulnerabilidades, y por ende era factible que la charla quedara como una curiosidad técnica.
Ya ví este efecto "animal exótico" en muchas charlas muy buenas en las que estuve donde la mayoría de la audiencia estaba de "espectador" y más bien admiraba la complejidad del tema y la habilidad del ponente, sin entender mucho de lo que estaba diciendo (recuerdo puntualmente una sobre web semántica, que fue la primera vez que escuché a alguien hablando en español de este tema por cierto).

Así que estuve buscando tema nuevo, y me decidí por demostrar algunas prácticas de troyanización de ejecutables, una vieja práctica de los días del pkzip/pkunzip y los archivos .bat en DOS (Disk Operating System), y que hoy muchos creen solo al alcance de "experimentados" hackers, craso error ya que hoy en día no podría ser más simple este tipo de cosas. Saqué toda la idea, al 100% de un ezine muy buena, "Insecurity" Nro. 3, del artículo "Jugando con Cryptcat I y II"; a esto claro voy a agregar algunos conceptos propios y la demostración en vivo de rigor.

Espero que con este tema muchos IT pro y aspirantes puedan llevarse a casa una conciencia clara sobre la seguridad IT como parte integral de los sistemas de información, a contrapartida de las suposiciones que lo toman por "opcional", "si hay plata", "no hay tiempo para eso", etc.

Serie de artículos sobre LDAP Injection
LDAP Injection & Blind LDAP Injection (Parte I de III)
LDAP Injection & Blind LDAP Injection (Parte II de III)
LDAP Injection & Blind LDAP Injection (Parte III de III)

Ezine "Insecurity"
http://hispasystem.wordpress.com/2008/03/26/descargas-ezine-insecurity/

Seminario Security Hacking Nea 4ta. Edición (SSHN4)