tag:blogger.com,1999:blog-79190472933287135022024-03-14T01:19:03.761-07:00SysnotasExperiencias administrando sistemasAnonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.comBlogger306125tag:blogger.com,1999:blog-7919047293328713502.post-40787701369040229152013-08-17T13:13:00.000-07:002013-08-17T13:22:08.333-07:00SDN a pelo, amañada, pero funcionalDesde que leí la primera vez sobre SDNs pensé que muchas de las funciones básicas de "pushing" scheduleado de configuraciones de red se pueden hacer de modo bastante simple si es que los equipos de red tienen SSH+SCP, como es el caso de muchos Cisco.<br />
<br />
Tenés que tener key SSH (o un script wrapper basado en expect, para que le pase la passwd al equipo luego del login), y luego vas "pusheando" los cambios que necesités, claro es mucho más manual que hacerlo vía APIs.<br />
<br />
Por ejemplo, la idea es que podés hacer cosas simples fácilmente: configurar que todos los días, de 8 a 13 y de 17 a 21, todos los puertos de la red tengan el nivel más bajo de seguridad, y que en otro horario, la seguridad de los puertos sea máxima, inclusive que todos los puertos de estaciones de trabajo estén "down" (apagados), fuera del horario de trabajo.<br />
<br />
Básicamente necesitás un SO que te permita schedulear dos scripts, uno que suba (y aplique) cada configuración, en el horario apropiado. Y otro que haga lo mismo, con otra configuración.<br />
<br />
Tu scripting va a tener que manejar un juego completo de configuraciones "base", u "originales", las están activas en los equipos de red. Luego en el horario apropiado, el otro script se conecta a todos los equipos de red, copia la otra configuración, la activa, y la pone en producción.<br />
<br />
En realidad, podés desarrollar un solo script y pasarle como parámetro un archivo de configuración completa para cada equipo de red, con los parámetros que quieras modificar cambiados en esos archivos, el script simplemente los va a "pushear" a los equipos y los va a poner en producción.<br />
<br />
No sería mucho pedir también, incorporar un mínimo manejo de errores en los scripts:<br />
<br />
- Volcar todo el trabajo a logs.<br />
- Verificar luego de la aplicación qué configuración está online, en qué equipos, desde qué hora.<br />
- Enviar correos de aviso en caso de cualquier fallo.<br />
<br />
<br />
La idea central de todo esto es que la noción de "SDN" se podría poner a funcionar "a caballo" de una infraestructura de red tradicional, que no soporta en hardware ninguna API ni estándar de SDN formal, y ello utilizando recursos fáciles de conseguir, e implementandolo de un modo relativamente muy sencillo.<br />
<br />
Vualá: "SDN" a pelo, sin APIs, ni siquiera requiriendo soporte en hardware :-)Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-72311619859740262762013-08-03T16:37:00.002-07:002013-08-03T16:37:54.597-07:00Desastres organizacionales, cómo ocurren y cómo prevenirlos.En mi experiencia como sysadmin ví explotar literalmente proyectos de toda escala presupuestaria, que quedaron inconclusos, penando las consecuencias de los recursos ya gastados sin haber conseguido los objetivos, por ello me volví afín al estudio de las causas sociológicas de los desastres organizacionales, leyendo material como el de abajo; que considero una buena introducción.<br />
<br />
Lo de abajo me parece una muy buena noción inicial, es el primer párrafo del paper (traducido):<br />
<br />
"Cuando pensamos en desastres organizacionales mayores, como el colapso de una corporación o un accidente en una planta química, tendemos a hacer dos suposiciones: que la falla fue causada por un error humano o por una falla de máquinas/equipamiento, y que la falla ocurrió súbitamente con poca o ninguna advertencia. De hecho, la investigación de desastres organizacionales sugiere que ambas suposiciones son incorrectas o al menos incompletas. Mientras el error humano o de máquinas/equipamiento puede ser el evento que precipita el desastre, tal error yace al final de una cadena de otros factores causales. Incluso más, muchas organizaciones incuban desastres durante largos períodos de gestación durante los cuales, los errores y llamadas de atención se acumulan. Aunque estas señales de alarma son doloramente claras en retrospectiva, ¿por qué es tan difícil para las organizaciones detectar, reconocer y actuar sobre estas condiciones precursoras antes de que se vuelvan una tragedia? Este estudio sugiere que las señales de alarma no son reconocidas y no se actúa por impedimentos en la circulación de información que causa que las organizaciones ignoren las señales de advertencia lo que permite a los errores crecientes y problemas escalar, llevando eventualmente a un quiebre a gran escala. Identificamos tres tipos de impedimentos de información derivados de la investigación teórica y de análisis de casos de desastre organizacional: puntos ciegos epistémicos, negación de los riesgos, e impedimentos estructurales."<br />
<br />
<a href="http://www.researchgate.net/publication/235275618_Organizational_disasters_why_they_happen_and_how_they_may_be_prevented?ev=pub_cit_inc">http://www.researchgate.net/publication/235275618_Organizational_disasters_why_they_happen_and_how_they_may_be_prevented?ev=pub_cit_inc</a>Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-50058798108856725162013-08-03T07:29:00.001-07:002013-08-03T07:29:59.487-07:00Lo "último" en monitoreo opensourceLas startups IT y empresas de éxito como Arista, Cloudera, Sonian, Etsy, Netflix, etc. usan - y crean - herramientas de monitoreo opensource de nueva tecnología, muy buenas, estables y confiables, apropiadas para mantener funcionando los sistemas de empresas muy exitosas o rumbo al éxito, pero no son muy populares, más que nada por desconocimiento.<br />
<br />
<i><b>¿Qué herramientas de monitoreo opensource se están usando en la "frontera"? </b></i><br />
<i><b><br /></b></i>
<i><b>¿Qué es lo último que funciona bien en producción, soluciona problemas importantes, es seguro, estable, pero todavía no es un software de monitoreo popular (como Ganglia o Nagios)?</b></i><br />
<br />
La homework es ver qué hace cada herramienta, de qué puede consumir y hacia donde puede publicar datos (cof cof Nagios cof cof).<br />
<br />
<b>OpenTSDB</b> - Monitoreo con soporte de altas cargas (vía HBase/Hadoop)<br />
<a href="http://www.slideshare.net/thecupoflife/opentsdb-in-a-real-enviroment">http://www.slideshare.net/thecupoflife/opentsdb-in-a-real-enviroment</a><br />
<a href="http://www.slideshare.net/geoffanderson/monitoring-mysql-with-opentsdb-19982758">http://www.slideshare.net/geoffanderson/monitoring-mysql-with-opentsdb-19982758</a><br />
<a href="http://www.slideshare.net/cloudera/4-opentsdb-hbasecon">http://www.slideshare.net/cloudera/4-opentsdb-hbasecon</a><br />
<br />
<b>Sensu </b><br />
<a href="https://github.com/sensu">https://github.com/sensu</a><br />
<a href="https://speakerdeck.com/joemiller/practical-examples-with-sensu-monitoring-framework">https://speakerdeck.com/joemiller/practical-examples-with-sensu-monitoring-framework</a><br />
<br />
<b>Graphite</b><br />
<a href="http://graphite.wikidot.com/">http://graphite.wikidot.com/</a><br />
<a href="http://graphite.readthedocs.org/en/1.0/tools.html">http://graphite.readthedocs.org/en/1.0/tools.html</a><br />
<br />
<b>Logster</b> - Generador de métricas desde Logs para Graphite y Ganglia<br />
<a href="https://github.com/etsy/logster">https://github.com/etsy/logster</a><br />
<br />
<b>Logstash</b> - (fijáte la parte de "outputs" > Nagios, Ganglia, OpenTSDB, Graphite, Pagerduty, etc.)<br />
<a href="http://logstash.net/docs/1.1.13/">http://logstash.net/docs/1.1.13/</a><br />
(GUI para Logstash) - <a href="http://kibana.org/about.html">http://kibana.org/about.html</a><br />
<br />
<br />
- Etc.Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-9208607079990407642013-07-27T14:08:00.001-07:002013-07-27T14:08:38.623-07:00Gnome empieza a desaparecer? QT (y KDE) avanzan.Como ya se anticipaba hace un tiempo, LXDE y Razor-QT van a ser un solo escritorio, LXDE-QT, que va a dejar de lado GTK y su herencia de GNOME para adoptar tecnologías QT (que se llevan muy bien con KDE, y se van a llevar mejor todavía próximamente).<br />
<br />
Por otro lado, Gnome se empieza a apagar como entorno de escritorio. La conferencia anual de desarrolladores Gnome, GUADEC, no se hizo en 2013, y muchos ya están abandonando el barco que no parece que fuera a durar tanto más tiempo. Muchas apps están planeando migrando a QT (como Subsurface de Linus Torvalds), muchas desde el vamos se basan en QT, y otras como LXDE se encuentran en plena migración. Además, el entorno de escritorio se encuentra cada vez más desplazado del escenario de ser escritorio por defecto de distribuciones populares: Ubuntu migró a Unity (de fondo tenemos a XFCE muy fuerte), Mint pisa muy fuerte con Cinnamon y de fondo KDE, XFCE y LXDE, Opensuse sigue con KDE como escritorio principal, y solamente Fedora - que no es demasiado popular al momento en realidad - lo sigue manteniendo como entorno por defecto.<br />
<br />
El patrocinador principal del desarrollo de Gnome3 (la empresa que paga a la mayoría de los top developers de Gnome), Red Hat, decidió no usar la nueva interfaz de Gnome 3 para próximas versiones de su versión Enterprise (van a usar el modo Fallback como entorno por defecto), y ello es una demostración evidente de que la nueva interfaz, luego de ya bastante tiempo - años - no ha podido resolver algunos problemas de compatibilidad con cierto hardware gráfico (problemas que no existían en Gnome 2 por cierto).<br />
<br />
Otras distribuciones Enterprise de uso actual tampoco tienen a Gnome 3 como entorno por defecto; SuSe Enterprise tiene Gnome 2 o KDE, Ubuntu LTS tiene Unity u otros entornos, pero no Gnome 3, CentOS sigue usando Gnome 2, y así sucesivamente.<br />
<br />
Al parecer nos vamos despidiendo de Gnome, lo que en realidad no es grato, ya es un buen software en general; sin embargo queda todavía ver si su comunidad lo puede salvar, tal como lo hizo la comunidad de developers de KDE, luego del fiasco inicial de KDE4 y tal como lo hizo la comunidad de XFCE cuando todos decían que no hacía falta un 2do. entorno gráfico basado en GTK+.<br />
<br />
<br />
El último GUADEC<br />
<a href="http://tech.slashdot.org/story/13/07/24/0157210/the-last-guadec">http://tech.slashdot.org/story/13/07/24/0157210/the-last-guadec</a><br />
<br />
<br />
Por otro lado KDE como entorno que promovió originalmente el uso de QT, se afianza con nuevas versiones estables regulares, inclusive con un cambio de tecnología mayor detrás de escena en las últimas y en las que se vienen (QT 4 a QT 5), y se preparan para tener en unos meses, no una sino dos versiones estables. La actual KDE 4.X y el próximo KDE 5.<br />
<br />
<a href="http://www.muylinux.com/2013/07/22/lxde-razor-qt-se-fusionan-proyectos/">http://www.muylinux.com/2013/07/22/lxde-razor-qt-se-fusionan-proyectos/</a><br />
<br />Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-82807532571586968152013-07-23T17:28:00.001-07:002013-07-23T17:41:06.676-07:00Playbook para la buena gestión de servicios informáticos en una organización<div style="text-align: justify;">
<span style="font-size: small;">La <b>primer página</b> del playbook ("Libro de Jugadas") para la gestión de servicios informáticos para una organización (incluye administración de infraestructura y soporte a usuarios por ejemplo), que estuvimos manejando en 2012 y 2013 con el equipo de trabajo del que formo parte hoy, es esta:</span></div>
<div style="text-align: justify;">
<span style="font-size: small;"></span><br />
<span style="font-size: small;"></span><br />
<span style="font-size: small;"><span style="font-size: large;"><b>El Playbook (Libro de Jugadas)</b></span><br /><br /><b>Regla 1: Atender todos los pedidos de soporte y ayuda de los usuarios.</b></span><br />
<span style="font-size: small;"><b> </b><br /><b>Regla 2: Atender los pedidos lo más rápido posible</b>.</span><br />
<span style="font-size: small;"></span>
<span style="font-size: small;"></span>
<span style="font-size: small;"><br /><b>Regla 3: Atender los pedidos de cualquier importancia</b>. No importa si es un usuario que no sabe cómo subrayar un título en un documento, un cartucho de impresora vacío o un switch que no funciona y deja sin conectividad a 20 usuarios. Hay diferentes prioridades, pero todos los pedidos de atención son atendidos.<br /><br /><br /><b>Regla 4: Simplificar la arquitectura organizativa publicando - internamente - servicios de atención</b>: X se encarga de soporte, X se encarga de gestión , X atiende servers & redes, X coordina y gestiona recursos con la organización, etc. Se evita la confusión, y los usuarios saben qué persona está manejando su problema, y trabajando para resolverlo.<br /><br /><b> </b></span><br />
<span style="font-size: small;"><b>Regla 5: Automatizar la gestión operativa</b>, implica:<br /><b> </b></span><br />
<span style="font-size: small;"><i><b>- Gestión de sistemas</b> </i>(trabajo de adm. de redes y servidores): Todas las tareas automatizables en la infraestructura deben llegar a ser automatizadas, a medida que se incrementa la automatización, se incrementa el tiempo disponible de adm. de sistemas que se puede re-utilizar en optimización/mejoramiento y en nuevos proyectos.<br /><b> </b></span><br />
<span style="font-size: small;"><i><b>- Gestión organizativa</b></i> (apoyándose en la Regla 4): Se evita al máximo la duplicación de tareas, por ende cada elemento del equipo puede realizar sus tareas más eficientemente (completa más tareas en igual tiempo que antes tomaba hacer menos cosas).</span></div>
<div style="text-align: justify;">
<span style="font-size: small;"></span></div>
<div style="text-align: justify;">
<span style="font-size: small;"></span></div>
<div style="text-align: justify;">
<span style="font-size: small;"></span><br />
<span style="font-size: small;"><br /><b>Regla 6: Aprovechar las oportunidades únicas de la "nube"</b>: <br />La adopción de tecnologías de virtualización nos permitió adquirir una flexibilidad muy alta para la rápida adaptación a los desafíos y requerimientos cambiantes en la gestión y administración de la infraestructura, tendientes a mejorar la prestación de servicios informáticos; siempre interactuando y unificando esta idea con los conceptos de las demás Reglas.<br /><br />La Gestión organizativa puede ofrecer así a la organización, un nivel inusitado de posibilidades disponibles de inmediato para nuevos servicios y soluciones que se necesite, gracias a que la Gestión de sistemas va a poder absorber bien nuevos requerimientos, inclusive inesperados.</span></div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-83917605741731000202013-07-22T22:39:00.000-07:002013-07-22T22:39:26.618-07:00Muchos pasos cortos pueden completar un camino largo<div style="text-align: justify;">
La gente se acostumbró a ver el éxito en términos de la filosofía "jolibudense" de pocas, grandes acciones con resultados espectaculares, cuando en realidad son casi siempre, muchas pequeñas acciones, con poco brillo propio, pero que sumadas llevan una idea a concretarse.</div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-53557664732695016292013-07-12T21:26:00.001-07:002013-07-13T06:25:20.568-07:00La posibilidad de backdoors en productos de software y hardware: la ruleta<div style="text-align: justify;">
<b><span style="font-size: large;">Esa sensación de que algo no anda bien</span></b><br />
Desde ayer u hoy (según tu zona horaria), el consenso general en foros y chats entre gente del ambiente de seguridad IT por todo el mundo es que si corrés un producto de software o hardware, relativamente popular (digamos por arriba de las decenas de miles de usuarios), y si el producto es un componente de infraestructura (sistemas operativos, bases de datos, software de CRM/ERP, gestión documental, servidores, SANs, switches de core, firewalls, dispositivos de threat management, appliances de correo/antivirus, etc. etc), cuanto más caro sea, mejor (o peor en realidad); y si además el producto fue fabricado en algún país con leyes poco favorables a la privacidad de datos, las chances se dan a favor de que en algún momento, alguien descubra que la mayoría corrieron o corren un backdoor y/o vulnerabilidades críticas explotables remotamente, como máximo, o como mínimo backdoors y/o vulnerabilidades explotables localmente (con previo acceso físico y/o acceso con permisos bajos, de usuario). Ellas codeadas por el mismo fabricante, con las consiguientes dificultades que ello implica (legales, prácticas, de management, de seguridad, etc. etc.).<br />
<br />
La posibilidad de permanecer indiferente está siendo desafiada ahora mismo por una certeza probabilística, "tienen que estar backdoreados", "alguno debe estar backdoreado", y el premio va a ser grande, en reconocimiento de la comunidad de seguridad y en negocios + éxito económico para quienes descubran primero cuales son los productos de soft y hard que tienen backdoors funcionales (o inclusive, si en versiones viejas los tuvieron).<br />
<br />
Ni hablar de que los "chicos malos" del ambiente de seguridad IT de siempre (desde los script kiddies hasta - especialmente - las grandes organizaciones criminales ), son los primeros que se anotaron en una tarea, que si bien puede ser desafiante desde lo económico (por la inversión necesaria en I+D), puede devolver ganancias extraordinarias si pueden descubrir un mínimo de uno o dos productos de soft/hard backdoreados o con vulnerabilidades plantadas.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Ya hay evidencia más que suficiente de lo fiable de estas previsiones, devenidas de las experiencias de los últimos tres años: caros appliances de threat management con backdoors, hardware de storage con backdoors, etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Cómo sabemos que es un backdoor</span></b></div>
<div style="text-align: justify;">
¿Cómo sabemos que es un backdoor y no una "característica oculta al cliente" (por más anti-ético que esto sea igualmente)?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Cuando es un backdoor en toda la regla, los usuarios legítimos del sistema (incluídos los de mayor privilegio: los administradores), no tienen ninguna evidencia en el sistema de que este ha sido accedido y/o sus recursos han sido utilizados por un tercero no autorizado.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
No hay logs, los procesos no figuran en la lista del sistema, el tráfico de red originado desde estas sesiones se oculta, no hay evidencia de accesos realizados en ninguna interfaz gráfica, los rastros de archivos temporales en el sistema están ocultos, sino es que directamente se borran automáticamente al terminar la sesión iniciada desde el backdoor.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Inclusive tenemos el caso de una línea completa de hardware - sumamente costoso - de storage SAN que corre una copia completa del sistema operativo que corre la SAN (justo al lado del sistema operativo que usan los administradores de la SAN), copia que estaba oculta - hasta hace muy poco - y era totalmente desconocida para los dueños de esas SAN, y clientes de una empresa de las "grandes", que figura entre varias de las cuales escuché opiniones como "son de confianza", "son de prestigio mundial, no se van a ensuciar así", etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">La gran ruleta</span></b></div>
<div style="text-align: justify;">
En fin, solo queda sentarse a esperar a ver cual de todos los jugadores del tablero de la seguridad IT a nivel mundial hace el primer descubrimiento, si es que llegan a hacerlo, ya que sabemos que están compitiendo contra los mejores hackers del mundo, aquellos que pueden hackear millones de sistemas simultáneamente y no ser detectados más que unas pocas veces (sobran dedos, etc.), de entre millones de trabajos exitosos (y que pasaron completamente desapercibidos), simplemente por eso les vale la pena el desafío.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
¿Quiénes serán los primeros? Algun/os bancos importantes? Tal vez alguna empresa de energía? Filtraciones masivas de información estatal, provincial, judicial, fiscal, militar, etc.?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Seguramente cualquiera que esté usando software o hardware construído en países con leyes poco favorables a la protección de datos privados es ahora mismo un lugar más en una gran ruleta, que ya empezó a girar. A alguno le va tocar.</div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-48806180296157194962013-07-12T08:39:00.001-07:002013-07-12T09:18:52.840-07:00La posibilidad de backdoors en Linuxes comerciales<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Una hipótesis</span></b></div>
<div style="text-align: justify;">
Similar al caso de varias empresas (la de las ventanas es la última), y el que se vean obligadas a colaborar con cualquier pedido para "facilitar futuros accesos que puedan ser solicitados" a sus servicios y productos, encontramos que los Linux comerciales que tienen sus empresas creadoras con sede en países que tienen leyes desfavorables para la privacidad de datos podrían estar igual, potencialmente backdoreados.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Muchos creen que no se puede, sin embargo se olvidan que quien controla la infraestructura de actualización de paquetes, controla qué se instala en el sistema operativo.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Los updates "oficiales" de los Linux comerciales se hacen contra un grupo de IPs puntuales, que son el front-end de una infraestructura mayor que brinda updates de paquetes a todo el mundo vía Internet.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>En el caso de un Linux no comercial como Debian, los servidores de actualización pueden estar en cualquier IP y país. Si queremos que los updates se hagan eligiendo al azar servers de Brasil, China, Chile, Uruguay, etc. y solamente saltando entre esos servers, se puede hacer fácilmente.</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
De todos modos, al estar tan replicados los servers de update de Debian a nivel internacional sería muy difícil lograr ubicar un software de backdoor o alguna vulnerabilidad crítica en algun paquete de Debian, sin que eventualmente sea detectado. Como ya pasó antes:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-family: inherit; font-size: small;"><a href="http://www.schneier.com/blog/archives/2008/05/random_number_b.html" target="_blank"><b>Random Number Bug in Debian Linux</b></a></span></div>
<div>
<div style="text-align: justify;">
<a href="http://it.slashdot.org/story/08/05/13/1533212/debian-bug-leaves-private-sslssh-keys-guessable" target="_blank"><b><span style="font-family: inherit;">Debian Bug Leaves Private SSL/SSH Keys Guessable</span></b></a></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div style="text-align: justify;">
<b>En una infraestructura privada de update de paquetes las cosas son muy diferentes, cada una de las IP de front-end puede redirigir el tráfico hacia cualquier servidor interno de la infraestructura, que puede estar ubicado en cualquier país, inclusive esos que tienen "issues" con la privacidad últimamente, de hecho, muchas infraestructuras privadas de actualización están totalmente localizadas fronteras adentro de estos países con "issues".</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Problemas posibles</span></b></div>
<div style="text-align: justify;">
Una infraestructura privada de actualización de paquetes va a tener problemas para desplegar un software de backdoor a nivel global, ¿cuales? el que casi seguramente dicho acto será detectado en algún momento, por varios motivos técnicos, pero si en cambio se ataca a un solo cliente, a unos cuantos servidores puntuales de entre millones, la chance de ser detectados por comparaciones y análisis - <b><i>de paquetes, de fechas de update, de conexiones realizadas, de tráfico que atravesó la red en X cantidad, en X fecha, para X IPs hacia Y IPs para unos servers sí, pero para otros no, para una empresa sí, para otra empresa no, etc</i></b>. - es mínima, casi nula inclusive.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">El ataque dirigido</span></b></div>
<div style="text-align: justify;">
Es decir, tiene mucho más sentido un ataque dirigido, después de todo los Linux comerciales pueden efectivamente tener en algun lugar un código identificador únido (similar a un user id), y se lo puede emparejar con otros datos importantes: Nombre y ubicación del cliente*, IPs usuales desde donde se producen las conexiones a la infraestructura, etc.</div>
<div style="text-align: justify;">
<br />
<i><b>* Al hablar de "cliente" aquí, me estoy refiriendo a "Empresa SRL", "Banco de la Región SA", "Ministerio de lo Quesea de la Pcia. de LoQueSea", "Subsecretaría de LoQuesesa", "Administración Federal de Manejo de lo Quesea", etc. y sus datos puntuales: dirección y código postal, teléfono, datos de contacto con el cliente (telefóno directo de un contacto, mail del contacto, horarios de disponibilidad), etc.</b></i><br />
<br /></div>
<div style="text-align: justify;">
<i>[Las IPs de origen de las conexiones suelen ser estáticas, por ser servidores. De todos modos, un identificador único va a permitir asociar un server/workstation que se conecta desde una conexión dinámica a los datos de un cliente específico, por cierto.]</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Si se apunta a un cliente específico a backdorear, cuando el cliente se conecta para actualizar su instalación, es redireccionado a un server "especial" de actualización, donde el primer paquete que va a pedir actualizar va a ser el mismo cliente de actualización. Luego de terminar de instalar el nuevo cliente de actualización, este ya contiene un poco del código necesario para hacer que aunque se descargue un software X y sus chequeos de integridad fallen, igualmente se instale, sin informar de ninguna manera al cliente (sin dejar rastros de los fallos de chequeos de integridad de los paquetes a nivel de logs, etc.etc.). Y un componente más: la posibilidad de bajar e instalar un paquete transparentemente, sin que dicha descarga/instalación sea visible de cualquier manera para el usuario, y sin que quede tampoco registro alguno de esa tarea a nivel de logs o interfaces gráficas.<br />
<br />
<i>En criollo, el usuario no se va a dar cuenta de nada, a menos que esté monitoreando directamente lo que hay en la memoria del sistema operativo, los procesos activos y al mismo tiempo el tráfico de red, justo en el momento que supuestamente se descarga e instala 2 mb de paquetes (y ocupan 4 mb en storage local), pero en realidad bajan 2.4 mb (y en realidad ocupan 6 mb en storage local).</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Luego de esto, en la siguiente actualización (que va a ser disparada casi de inmediato, o quedará scheduleada para la siguiente iteración de actualizaciones), si este cliente target se conecta, no accederá a ningun servidor estándar de la infraestructura de actualización (que contiene paquetes libres de todo backdoor), sino a un servidor "especial" que puede llegar a contener "actualizaciones" que serán instaladas transparentemente sobre las versiones actuales, inclusive sin llegar a modificar las versiones del software que se puede ver desde las herramientas estándares. Esas "actualizaciones" pueden contener el software que sea, desde un backdoor que habilite un servicio "fantasma" con SSH corriendo en un puerto alternativo (no el 22), hasta un túnel HTTP, DNS, o de cualquier protocolo que tenga comunicación a Internet.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">El trabajo</span></b></div>
<div style="text-align: justify;">
Desde ese punto lograr la comunicación desde Internet hasta dentro del server es trivial y los métodos son comunes: port knocking, que el backdoor solo responda si hay intentos de conexión desde un rango de IPs específico (esto evitaría esos servicios "fantasma" sean visibles para escáneres como Nmap y similares), que los servicios "fantasma" solo se activen (sean arrancados y se carguen a memoria), en un rango horario limitado (de 4 a 5 de la mañana), cada X cantidad de días, y solo si encuentran una respuesta en servers de C&C (comando y control), prosigan con más actividades, etc. etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
La transferencia - masiva si es necesario - de datos salientes se gestiona igualmente por métodos comunes: en gral. se va a buscar algún protocolo encriptado que tenga tráfico saliente y se lo va a usar, para evitar que los <a href="http://en.wikipedia.org/wiki/Unified_threat_management" target="_blank">dispositivos de threat management</a> que puedan estar inspeccionando el tráfico de protocolos encriptados, se suele recurrir a técnicas diversas (en gral. esteganografía en lo que haya "en movimiento" en el tráfico: audio, video, documentos, etc.). Eso claro, si es que los mismos <a href="http://en.wikipedia.org/wiki/Unified_threat_management" target="_blank">dispositivos de threat management</a> no tiene backdoors intercontruídos que simplemente se accedan y permitan desactivar contramedidas y detecciones varias, antes de iniciar el tráfico de datos saliente masivo.<br />
<br />
Si hace falta, la transmisión de datos masiva - GBs de datos - se puede realizar por etapas o aleatoriamente, enviando unos pocos GBs de datos de a poco, durante días o semanas, hasta completar el trabajo.<br />
<br />
Si el grado de securización de la infraestructura es bajo y/o manejable, ello inclusive podría llegar a acelerar los tiempos prescindiendo de diversas tareas de ocultamiento y prevención de detecciones.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">La despedida</span></b></div>
<div style="text-align: justify;">
Una vez terminado el interés en el objetivo, la misma infraestructura de actualización puede fácilmente devolver a los paquetes instalados a su estado anterior, y dejar efectivamente cero rastro de la intrusión dentro del server. A lo sumo, el tráfico saliente - y en protocolos y puertos totalmente autorizados a hacerlo - del server es lo único podría permitir pinpointear una intrusión de este tipo, luego de eliminado todo rastro de los binarios que la permitieron.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Luego de esto, al revisar el server no se va a detectar ninguna diferencia entre los binarios instalados y los oficiales, son los mismos.<br />
<br />
El trabajo puede durar desde pocos minutos a varias semanas, inclusive intercalando ataques con períodos "limpios", offline, donde los servers atacados son limpiados y devueltos a su estado original, para luego ser atacados de vuelta.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Contramedidas?</span></b></div>
<div style="text-align: justify;">
Si hubiera otro tipo de medidas de seguridad para prevenir el uso de binarios alterados, un <a href="http://es.wikipedia.org/wiki/Sistema_de_detecci%C3%B3n_de_intrusos#Tipos_de_IDS" target="_blank">HIDS (HostIDS)</a>, fácilmente podría ser pinpointeado por un componente de software "fantasma" antes de instalar nada más que el update del cliente de actualización que arrancara totalmente autorizado (y no va a disparar ninguna alarma porque es una versión nueva justamente, y es esperable que los nuevos binarios en disco disparen alarmas en el HIDS, que rápidamente van a ser descartadas como "falsas alarmas", si que directamente ya no hay reglas que impiden que el HIDS dispare alarmas cuando se actualiza el cliente de actualización), y luego efectivamente desactivado, inclusive para ello hiciera falta "actualizar" los binarios y librerías del HIDS.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Conclusiones</span></b></div>
<div style="text-align: justify;">
Es decir, quien controla la infraestructura de actualización y además cuando los servidores de actualización son privados, y no hay acceso público o semipúblico que permita controlar qué hay en esos repositorios en cualquier momento y además controla el código fuente del cliente de actualización, está en perfecta posición para montar una infraestructura de backdoring y troyanización perfectamente efectiva, pudiendo entrar, instalar, borrar y luego salir de cualquier server conectado a Internet, sin que los administradores (de sistemas, redes, seguridad, etc.), a cargo de los servidores lleguen a darse cuenta siquiera de que hubo algún acceso no autorizado.</div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-73057380578836668502013-07-09T08:01:00.000-07:002013-07-09T08:01:09.749-07:00Como trastean los quantos con sus darkpoolsLeía sobre los quantos y sus darkpools (los operadores de HFT y su laburo en los mercados abiertos a ofertas anónimas), y me acordaba de una pila - así - de artículos y de un libro que leía hace poco:<br />
<br />
<b>Inside the Black Box: A Simple Guide to Quantitative and High Frequency Trading (Wiley Finance)</b><br />
<a href="http://www.amazon.com/Inside-Black-Box-Quantitative-Frequency/dp/1118362411">http://www.amazon.com/Inside-Black-Box-Quantitative-Frequency/dp/1118362411</a><br />
<br />
Donde claramente explican que "todas las decisiones son tomadas por humanos, ninguna por las máquinas"<br />
<br />
Y ahora leyendo el artículo del link del fondo,<br />
<b><i>"The computers that run the stock market</i></b><br />
<b><i>NEW YORK (CNNMoney)</i></b><br />
<b><i>Citadel Securities has quietly become one of the largest forces in U.S. stock trading."</i></b><br />
<br />
Cito:<br />
<br />
<i>"All the decisions are made by the computers," Jamil Nazarali, Citadel's head of electronic execution, told CNNMoney during an exclusive behind-the-scenes tour. "The people here are not making any decisions with respect to whether an order should be filled or at what price it should be filled. That's all done in an automated way."</i><br />
<br />
Trans:<br />
<br />
"Todas las decisiones son tomadas por las computadoras," Jamil Nazarali, Jefe de Ejecución Electrónica de Citadel, le contaba a CNNMoney durante un exclusivo tour tras las puertas. "La gente aquí no toma ninguna decisión respecto de si una orden debe ser hecha o qué precio debería tener. Así es como se hace todo de modo automatizado."<br />
<br />
Y después nos extrañamos cuando hay un flash-crash, y termina un montón de quantos dando explicaciones en el congreso de US de qué creen que pasó; porque hay teorías de qué fue lo que pasó, pero ninguna explicación concreta, lo mejor que se pudo lograr como "explicación técnica" fue una aproximación a las causas que podrían haber creado la circunstancia en que las máquinas HFT crearon el flash-crash (básicamente una especie de loop retroalimentado, similar a lo que pasa cuando conectas en loop varios switches en redes informáticas).<br />
<br />
<a href="http://en.wikipedia.org/wiki/2010_Flash_Crash">http://en.wikipedia.org/wiki/2010_Flash_Crash</a><br />
<br />
<br />
No hay que tener miedo, sino tener un poco de cuidado con estas tecnologías, hay algunas tecnologías con las que se puede probar y si no funcionan, no hay problema, si probamos un barrilete, y se cae y se rompe, no hay problema, se hace otro mejor y listo. Si construís mal un transbordador espacial y no funciona bien y se termina estrellando en una ciudad, ese error no se puede reparar.<br />
<br />
Algo parecido puede ocurrir con tecnología avanzada - como los HFT - que no es manejada de manera suficientemente cuidadosa.<br />
<br />
<span style="font-size: large;"><b>Links:</b></span><br />
<br />
<b>"The computers that run the stock market</b><br />
<b>NEW YORK (CNNMoney)</b><br />
<b>Citadel Securities has quietly become one of the largest forces in U.S. stock trading."</b><br />
<a href="http://money.cnn.com/2013/07/08/investing/stock-market-citadel/index.html?iid=HP_LN">http://money.cnn.com/2013/07/08/investing/stock-market-citadel/index.html?iid=HP_LN</a><br />
<br />
<br />
<b>High-frequency trading</b><br />
<a href="http://en.wikipedia.org/wiki/High-frequency_trading">http://en.wikipedia.org/wiki/High-frequency_trading</a><br />
<br />
<b>Algorithmic trading</b><br />
<a href="http://en.wikipedia.org/wiki/Algorithmic_trading">http://en.wikipedia.org/wiki/Algorithmic_trading</a>Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-36786958305140395102013-07-07T19:02:00.001-07:002013-07-07T19:02:40.149-07:00SÍ SE PUEDE hacer live-migration SIN SANs<div style="text-align: center;">
<b><span style="font-size: large;"><br />SI se puede hacer Live migration de máquinas virtuales SIN hardware de SANs (shared storage).</span></b></div>
<br />
Es un mito entre sysadmins que no son especialistas en virtualización el que "sí o sí" hace falta una SAN para poder tener live-migration, "o sino no se puede".<br />
<br />
<b>Claro, si tenés que preguntar a un vendedor de hardware, la mayoría te va "confirmar" que es "mejor" si tenés la SAN, y claro, a alguien tenés que comprarsela ¿verdad?</b><br />
<br />
<b>En cambio, lo que podrías confirmar por vos mismo es</b> ir hasta los sitios de los fabricantes del software y bajarte los documentos de KB (Knowledge Base), ver los casos de estudio, los foros de ayuda, y en último lugar tal vez, los manuales y documentación, según el nivel de feedback que tengas ya vas a ir viendo - por vos mismo - qué tanto funcionaría o no, tener o no una SAN, y si vale la pena invertir en comprar una.<br />
<br />
<br />
<b>Veamos algunos links que lo confirman NO hace falta una SAN para tener live-migration:</b><br />
<br />
<b><span style="font-size: large;">Microsoft Hyper-V 2012</span></b><br />
<a href="http://blogs.technet.com/b/canitpro/archive/2013/03/21/step-by-step-completing-storage-live-migration-in-hyper-v.aspx">http://blogs.technet.com/b/canitpro/archive/2013/03/21/step-by-step-completing-storage-live-migration-in-hyper-v.aspx</a><br />
<br />
<a href="http://blogs.technet.com/b/canitpro/archive/2013/01/03/shared-nothing-live-migration-goodbye-shared-storage.aspx">http://blogs.technet.com/b/canitpro/archive/2013/01/03/shared-nothing-live-migration-goodbye-shared-storage.aspx</a><br />
<br />
<br />
<b><span style="font-size: large;">Vmware vSphere</span></b><br />
<a href="http://blogs.vmware.com/performance/2012/08/vmware-vsphere-5-1-vmotion-architecture-performance-and-best-practices.html">http://blogs.vmware.com/performance/2012/08/vmware-vsphere-5-1-vmotion-architecture-performance-and-best-practices.html</a><br />
<br />
<br />
<b><span style="font-size: large;">XenServer</span></b><br />
<a href="http://blogs.citrix.com/2012/09/11/demo-live-migration-without-shared-storage-using-xenserver-and-openstack/">http://blogs.citrix.com/2012/09/11/demo-live-migration-without-shared-storage-using-xenserver-and-openstack/</a><br />
<br />
<br />
<b><span style="font-size: large;">KVM</span></b><br />
<a href="http://blog.allanglesit.com/2011/08/linux-kvm-management-live-migration-without-shared-storage/">http://blog.allanglesit.com/2011/08/linux-kvm-management-live-migration-without-shared-storage/</a><br />
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-11671334064568444462013-07-07T14:22:00.001-07:002013-07-07T18:41:20.362-07:00Consolidar y desagregar/distribuir servicios en infraestructuras virtuales<div style="text-align: justify;">
Ayer en la Hackathon Express 2013, estaba conversando con un par de IT guys y les comento que estuve trabajando con un cliente familiar para ellos, y que pasamos de unas pocas máquinas físicas a varias decenas de máquinas virtuales en producción, esto causó cierta sorpresa, principalmente porque la cantidad de servicios en producción permaneció más o menos igual, pero la cantidad de servidores virtuales parecía un poco elevada..en otras palabras, tal vez haría falta "consolidar".</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Consolidar</span></b></div>
<div style="text-align: justify;">
Había hace un tiempo la tendencia a "consolidar": incluir la mayor cantidad de servicios posible de correr por servidor físico y por sistema operativo. Esta noción brinda ciertos beneficios por sobre tener muchos servidores y servicios en cada uno.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Sin embargo no es una visión correcta para ser aplicada en un entorno de infraestructura virtualizada. El fundamento detrás de "consolidar" se basa principalmente en limitaciones propias del hardware físico, que no existen más en las infraestructuras virtuales.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
La idea principal de "consolidar" se daba cuando un servidor físico se iba haciendo "viejo", y se acerca al fin de garantía o ya lo superaba e iba en camino a ser descontinuado por el fabricante, aquí se buscaba "consolidar", concentrando la mayor cantidad de servicios posibles en servidores físicos que aún tenían garantía o que se encuentraban aún plenamente soportados - en partes y respuestos - por el fabricante.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Otra noción importante devenía del mejor aprovechamiento de recursos además del hardware con garantía: los mismos recursos del hardware (ram, procesador, disco, etc.), los recursos externos (alimentación, disponibilidad de conectividad, etc.). Al consolidar, los servicios se ubicaban de modo tal de poder acceder a un conjunto de ciertos recursos que tal vez no estuvieran disponibles en otro hardware (un server viejo fuera de garantía idealmente), o inclusive, accediendo a facilidades de recursos solo disponibles en el lugar físico donde se iba a reubicar - consolidar - los servicios (por ejemplo: algún link de fibra óptica más cercano al backbone y/o core de la organización, brindando al servicio potencial mayor conectividad hacia la red interna).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Es decir, si pensamos la idea de "consolidar" basándonos en infraestructuras puramente basadas en servidores físicos, y en gral. en recursos físicos, consolidar tiene mucho sentido.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Distribuir, desagregar</span></b></div>
<div style="text-align: justify;">
Las infraestructuras virtuales crean una "capa intermedia" de administración y gestión de recursos (hipervisores y sus dispositivos virtuales, manejadores de hipervisores), que son luego entregados a servidores virtuales.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Esos servidores virtuales consumen los recursos entregados por la capa de virtualización, incluyendo procesador, ram, discos, conectividad, etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
La capa de virtualización se encarga de proveer servicios avanzados de gestión de recursos, por ejemplo, permitiendo tener servidores virtuales, cuya suma total de memoria ram virtual asignada es mayor que la memoria ram física disponible en la capa física (en el servidor en el que corre el hipervisor en gral.). Similares características se encuentra en cuanto a procesadores, espacio en disco, conectividad, etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Entonces, si de repente tenemos un solo servidor virtual con 3 servicios que consumen X cantidad de ram, y los separamos en 3 servidores virtuales, en algún punto no estamos desaprovechando la memoria ram física en realidad. Una parte mínima de memoria adicional será ocupada para mantener tres sistemas operativos diferentes funcionando al mismo tiempo (3 kernels y poco más), y la memoria individual que ocupa cada servicio será muy similar en cada server separado, respecto de lo que ocupaba cada uno cuando estaban "consolidados" en un solo server virtual.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Las ventajas que obtenemos al desagregar servicios, al distribuirlos en varias máquinas virtuales en vez de consolidarlos es que nos hacemos de piezas más pequeñas para manejar, servidores que ocupan menos memoria ram (algo que es barato, pero no siempre está disponible en demasía), y si necesitamos mover una máquina virtual de un hipervisor a otro, casi seguramente lo podremos hacer.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Hay otras ventajas evidentes de la desagregación: si un kernel falla, los otros dos servicios siguen funcionando, si un servicio tiene una brecha de seguridad, los otros dos permanecen - en lo inmediato - sin ser alcanzados, etc. etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Cualquier "cosa" que le suceda a un servicio (en un servidor virtual), a nivel de software y hasta el nivel del mismo sistema operativo que lo está corriendo, continúa sin afectar los otros dos servicios, que si son independientes del servicio afectado, van a continuar operando normalmente mientras la capa de virtualización funcione normalmente.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-size: large;"><b>Consolidar y desagregar servicios en servidores, pero en un contexto pertinente</b></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Como ven "consolidar" es una noción, no "prehistórica" ni poco útil en la actualidad, sino perfectamente útil y pertinente en un contexto específico: infraestructuras de servidores físicos.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Los beneficios de la desagregación de servicios en varios servidores virtuales - en entornos virtualizados - inclusive suponen, como estrategia de gestión de recursos de infraestructura, un número mucho más elevado de ventajas respecto de lo que se obtiene "consolidando" al trabajar con servidores físicos. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Además de simples ventajas prácticas (el mencionado incremento de resiliencia de servicios gracias a que cada uno corre en sistemas operativos diferentes, por ej.), hay diferentes posibilidades exclusivamente disponibles en entornos virtualizados se hacen disponibles a los administradores al desagregar servicios .La migración live de máquinas virtuales sería casi lo más útil:<br />
<br />
<a href="http://en.wikipedia.org/wiki/Live_migration">http://en.wikipedia.org/wiki/Live_migration</a><br />
<br />
<a href="http://www.vmware.com/products/datacenter-virtualization/vsphere/vmotion.html">http://www.vmware.com/products/datacenter-virtualization/vsphere/vmotion.html</a><br />
<a href="http://blogs.citrix.com/2012/08/24/storage_xenmotion/">http://blogs.citrix.com/2012/08/24/storage_xenmotion/</a><br />
<a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html">http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html</a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;"><br /></span></b>
<b><span style="font-size: large;">Subutilizando recursos con infraestructura virtual, un ejemplo</span></b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Al contrario, cuando se tiene servidores "consolidados" en entornos virtuales, nos encontramos con grandes consumidores de recursos, que tienden a replicar la misma situación de sub-utilización o poco óptima utilización de recursos que había previo a la virtualización, pero agregando en el medio una capa de hipervisores.<br />
<br />
Por ejemplo, sin virtualización, en un servidor físico dado, se corría un Linux con 3 servicios críticos, ahora, con un hipervisor corriendo sobre el servidor físico, se tiene de vuelta un Linux con los mismos 3 servicios críticos, y al ocupar estos tantos recursos, no dejan "lugar" para incluir más servidores virtuales en el mismo hipervidor.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Puede ocurrir que uno de esos servicios críticos se use a la mañana, otro a la tarde y un tercer servicio es de backup y está funcionando toda la noche, entonces en ningun momento del día se tiene realmente libres los recursos físicos disponibles, si hubiera mínimas cantidades libres de alguno, la criticidad del uso del servicio activo al momento o que otros recursos estén siendo ocupados al máximo al momento (mucho procesamiento/ram a la mañana en una base de datos, mucho storage por la tarde en el volcado a disco de datos, y mucha conectividad a la noche cuando se hacen los backups).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Desagregando los 3 servicios en 3 servidores virtuales, podríamos encontrar que a la tarde, en un hipervisor diferente de donde corren los 3 servidores virtuales, hay suficiente "tranquilidad" como para que el servicio que es intensivo en storage corra, así que lo podríamos mover allí, de ese modo la tarde queda libre para poder correr diagnósticos sobre el servidor virtual que se encarga del backup a la noche, y cuando llegue el momento de hacer backups, tenemos de ante-mano cierto stock de pre-diagnósticos del sistema, y si hay alguna falla inclusive podríamos tener un pre-aviso antes de que ocurra la falla.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Si hubiéramos tenido los el servicio intensivo en storage a la tarde y el de backup intensivo a la noche, consolidados en un mismo server, esa situación de prevención de errores tal vez no hubiera sido posible de alcanzar por falta de recursos (no se podía "molestar" al server a la tarde mientras estaba ocupado en otra cosa).</div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-14139669846905532042013-07-04T13:21:00.000-07:002013-07-04T13:57:54.914-07:00QT avanza en su adopción en entornos libres: LXDE migra a QT<br />
<div style="text-align: justify;">
QT (la librería base de KDE y muchas apps libres/freeware), empieza su camino avanzando lentamente sobre el GTK+ (la librería base de Gnome).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
El popular entorno de escritorio LXDE ya se portó QT y su primer batch de código ya puede ser compilado, dejando apreciar cómo va a ser LXDE-QT. Así que las siguientes versiones estables de LXDE van a estar basadas en algún momento, solamente en QT, dejando atrás la herencia de Gnome/GTK+.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>LXDE-QT PREVIEW</b> - <a href="http://blog.lxde.org/?p=1013">http://blog.lxde.org/?p=1013</a></div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
<span style="font-size: large;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-size: large;"><b>El desarrollo de LXDE, mirando un poco al futuro cercano</b></span></div>
<br />
<div style="text-align: justify;">
Leyendo un poco vemos que la gente de LXDE está honrando la inteligente decisión de no reinventar la rueda y están aprovechando el código y expertise de los developers de Razor-QT, un entorno gráfico liviano, bastante bueno que empezó su desarrollo hace poco (no llegando al nivel de LXDE o XFCE todavía), es de esperar que en algún momento, tal vez, las ideas se integren en un solo código (ya hay esa "onda" de no repetir el error de tener dos grandes grupos de developers haciendo casi lo mismo, tal como ocurrió con Gnome y KDE*).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
De hecho la nueva versión 4.11 de KDE apunta a la posibilidad de tener varios shells intercambiables (al vuelo inclusive, con un solo click), totalmente funcionales, sobre el mismo conjunto de componentes base. Así, a futuro, si alguien quisiera implementar una copia fiel del estilo de interfaz gráfica de Gnome3, podría hacerlo sin problemas, aprovechando todo lo hecho para los demás shells (Plasma es el shell actual que se suele ver en los screenshots, y Plasma Active es otro shell para tabletas, también funcional y en versión estable).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Otros entornos como LXDE-QT y Razor-QT e inclusive una hipotética futura reescritura de XFCE, podrían llegar a usar la base de KDE, y convertirse en un shell.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Esta idea de muchos shells gráficos y una sola base de componentes surgió al ver los problemas propios de replicación de esfuerzos para desarrollar Plasma y Plasma Mobile, y también la problemática asociada GTK+3, en la que Gnome3 se integra tan fuertemente en GTK+3 que vuelve muy complicado escribir/generar otros shells gráficos sobre GTK3, tal como Cinnamon (de Linux Mint), MATE (cuyo desarrollo ya empezó a adoptar componente de Gnome3 y GTK3).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-size: large;"><b>Los problemas de GTK+3</b></span></div>
<div style="text-align: justify;">
El desarrollo de GTK+3 luego de la versión 2 (sobre la que estaba construído Gnome 2), viene pasando por muchas instancias de problemas, el más importante es la falta de cuidado de los manteiners de GTK+3 cuando se desarrollan mejoras: muchas APIs cambian sin aviso, no hay documentación de los cambios, no hay retrocompatibilidad con lo que ya está codeado, etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
El resultado es las aplicaciones GTK+3 tienen que ser parcialmente reescritas y/o corregidas (corrigiendo código que funciona bien y no tiene bugs), cada vez que ocurren cambios en GTK+3, más o menos impredeciblemente.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Esto está causando dolores de cabeza mayores a los developers que se pasaron a GTK+3 y por ello es que vemos pocas aplicaciones migrando a GTK+3 a pesar de que ya ha transcurrido bastante tiempo desde que está disponible.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
El trasfondo de Gnome3 como entorno poco aceptado en Linux y ahora, ciudadano de 2da. en Red Hat Enterprise Linux (que no va a usar Gnome 3, sino la opción de Fallback), justamente su principal espónsor corporativo (la mayoría de los developers pagos de Gnome3 - los más activos, que llevan la voz cantante - son empleados de Red Hat), deja entrever circunstancias políticas complicadas en el presente de GTK+3, hay que "adaptarse" a mucho, para obtener lo mismo que en otras opciones está disponible sin esfuerzo.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
GTK+2 era la opción de cero necesidad de adaptación, pero, ya fue descontinuado su soporte en favor de GTK+3, y con el rápido avance de las tecnologías gráficas en Linux (Wayland, el rápido desarrollo y mejora de drivers de Intel, ATI y Nvidia, etc.), quien permanezca "cerca" de GTK+2 mucho tiempo más corre el riesgo de que de una versión a otra de una distribución, sus aplicaciones ya no puedan siquiera arrancarse en Linux.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-size: large;"><b>La opción de QT</b></span></div>
<div style="text-align: justify;">
Aquí es donde QT se presenta como la opción más indicada: todo lo que es negativo en GTK+3, se da a la inversa en QT.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
</div>
<ul>
<li><b><i>Las versiones viejas son mantenidas en tiempos pre-definidos, inclusive adaptándolas a nuevas tecnologías, como las ya mencionadas. </i></b></li>
<li><b><i>Las versiones nuevas soportan cierto nivel de retro-compatibilidad para compilar código de versiones viejas (piden menos cambios o ninguno). </i></b></li>
<li><b><i>Las nuevas versiones de QT van implementando tecnología gráfica actualizada al año 2013, donde se puede llegar a construir aplicaciones usando lenguajes interpretados populares (Ruby, Python, etc.), QML a la cabeza de ellos con su QT Quick (que permite a los developers trabajar con QML para crear interfaces de usuario en vez de usar C++). El viejo C++ sigue plenamente disponible también.</i></b></li>
<li><b><i>La documentación de QT es extensiva, los entornos gráficos IDE para trabajar con QT (QT Creator, KDevelop, etc.) están a la altura de lo mejor disponible en el mercado.</i></b></li>
<li><b><i>El soporte multiplataforma de QT (Linux, Windows, Plataformas Mobile, etc.), y sus lenguajes soportados, permite que sea muy atractivo como expertise para los developers que colaboran en proyectos abiertos, ya van a poder portar esas skills ganadas en colaboración en proyectos opensource a proyectos laborales propios y a empleos pagos.</i></b></li>
<li>Etc.</li>
</ul>
<br />
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Hay una especie de broma interna entre los desarrolladores de KDE (que está totalmente escrito sobre QT), y dice que lo único malo de KDE es que reescribió mal muchas cosas que QT ya hacía bien. Justamente desde la versión 4.10 en adelante, el foco del desarrollo de KDE es deshacerse de tanto código "solo KDE" como sea posible y en cambio utilizar solamente QT para programar aplicaciones.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-size: large;"><b>Links</b></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>LXDE-Qt: Primer contacto</b></div>
<div style="text-align: justify;">
<b><a href="http://blog.desdelinux.net/lxde-qt-primer-contacto/">http://blog.desdelinux.net/lxde-qt-primer-contacto/</a></b></div>
<br />
<div style="text-align: justify;">
<span style="font-weight: bold;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-weight: bold;"><br /></span></div>
<div style="text-align: justify;">
<b>QT Creator</b></div>
<br />
<div style="text-align: justify;">
<b><a href="http://qt-project.org/wiki/Category:Tools::QtCreator_Spanish">http://qt-project.org/wiki/Category:Tools::QtCreator_Spanish</a></b></div>
<br />
<div style="text-align: justify;">
<span style="font-weight: bold;"><br /></span></div>
<div style="text-align: justify;">
<b>QML</b></div>
<br />
<div style="text-align: justify;">
<b><a href="http://es.wikipedia.org/wiki/QML">http://es.wikipedia.org/wiki/QML</a></b></div>
<br />
<div style="text-align: justify;">
<span style="font-weight: bold;"><br /></span></div>
<div style="text-align: justify;">
<b>Qt QML</b></div>
<br />
<div style="text-align: justify;">
<b><a href="http://qt-project.org/doc/qt-5.0/qtqml/qtqml-index.html">http://qt-project.org/doc/qt-5.0/qtqml/qtqml-index.html</a></b></div>
<br />
<div style="text-align: justify;">
<span style="font-weight: bold;"><br /></span></div>
<div style="text-align: justify;">
<b>Qt Quick Release Notes</b></div>
<br />
<div style="text-align: justify;">
<b>Qt 5.0 - QtQuick C++ Module</b></div>
<div style="text-align: justify;">
<b><a href="http://qt-project.org/doc/qt-5.0/qtquick/qtquick2-qtquick-releasenotes.html">http://qt-project.org/doc/qt-5.0/qtquick/qtquick2-qtquick-releasenotes.html</a></b></div>
<br />
<div style="text-align: justify;">
<span style="font-weight: bold;"><br /></span></div>
<div style="text-align: justify;">
<b>Porting QML Applications to Qt 5</b></div>
<br />
<div style="text-align: justify;">
<b><a href="http://qt-project.org/doc/qt-5.0/qtquick/qtquick-porting-qt5.html">http://qt-project.org/doc/qt-5.0/qtquick/qtquick-porting-qt5.html</a></b></div>
<br />
<div style="text-align: justify;">
<span style="font-weight: bold;"><br /></span></div>
<div style="text-align: justify;">
<b>KDevelop</b></div>
<br />
<div style="text-align: justify;">
<b><a href="http://www.kdevelop.org/">http://www.kdevelop.org/</a></b></div>
<div style="text-align: justify;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-14403476848835219572013-07-04T02:10:00.000-07:002013-07-04T02:46:45.969-07:00Autoservicio de Infraestructura como Servicio II: diseño del prototipo completoContinuando la idea planteada en el post...<br />
<span style="background-color: #30270e; color: #cbcbcb; font-family: 'Droid Sans'; font-size: 18px;">Autoservicio de Infraestructura como Servicio</span><br />
<a href="http://sysnotas.blogspot.com.ar/2013/06/autoservicio-de-infraestructura-como.html">http://sysnotas.blogspot.com.ar/2013/06/autoservicio-de-infraestructura-como.html</a><br />
<br />
<div style="text-align: justify;">
Aprovechando una noche en vela por una gripe galopante, entre pañuelo y pañuelo, más la tos carrasposa eventual, me puse armar los rudimentos del "Autoservicio de Infraestructura como Servicio", o "Autoservicio IAAS". Totalmente basado en software libre (aunque podrá correr Windows Server, tanto como Linux o o - eventualmente y refinando el diseño - cualquier sistema operativo soportado por el hipervisor).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Ya quedó armado el diseño del prototipo de la Caja de provisión de Infraestructura como Servicio. 0% de administración manual, servidores (debian, ubuntu, Windows Server, veremos), creados automáticamente y de inmediato, desde una interfaz web, descartados al vencer la sesión, de 2 horas en el prototipo.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>La idea central es que una vez arrancada la caja, inmediatamente quede disponible para brindar IAAS (máquinas virtuales), y toda esa gestión se realice 100% automáticamente, sin que un administrador de sistemas tenga que conectarse en ningún momento ni correr ningún comando.</b></div>
<div style="text-align: justify;">
<b><br /></b></div>
<div style="text-align: justify;">
<b>Básicamente el administrador de sistemas va a tener el trabajo de loguearse a la PC (recordemos que es una PC barata, aunque potente), y apagarla al final del día, si es que no lo quiere schedulear vía CRON, claro, suponiendo que no se publican en una IP pública, al igual que sus máquinas virtuales.</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
La sesión iniciada en una máquina virtual vía SSH pediría un mail y password, y si la caja puede conectarse a un servidor smtp (correo), le envía al usuario todo el historial de comandos corridos en la sesión, antes de apagar el servidor y luego borrarlo poco después. Básicamente el usuario se estaría enviando el correo a sí mismo en la práctica (y se evita el riesgo de configurar una cuenta de correo en el server, que puede llegar a ser robada y abusada con envío de SPAM o peores cosas).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
En el prototipo planeo que el usuario solo se pueda conectar vía SSH, aunque una conexión vía VNC no es difícil de configurar en la máquina virtual de plantilla (sí es más difícil manejar un logout+apagado de la vm por inactividad).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
* Para Windows Server evidentemente va a hacer falta disponer de una licencia y utilizar RDP para conectarse a la máquina virtual.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
En primera instancia no hay ningún stopper importante para este proyecto, más que nada hay sentarse y resolver el código de scripting de automatización de gestión de las máquinas virtuales.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Dentro de poco me pongo a construir efectivamente el prototipo y vemos si se puede volver algo más sólido.</div>
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-12568043893259547372013-07-03T20:18:00.000-07:002013-07-03T21:39:39.799-07:00La psicología de la marginación los super-colaboradores de comunidades y/o equipos.<div style="text-align: justify;">
<b><span style="font-size: large;">"Ninguna buena obra queda sin castigo"</span></b><br />
Los que intentamos postear cosas útiles, intentamos dar una mano, escribimos tutoriales, etc. estamos muy familiarizados con la "mala onda" que eventualmente aparece, y algunos individuos empiezan a desconfiar (¿de qué?), inferir intenciones ocultas en el comportamiento generoso / caritativo (¿cuales exactamente?), y por ende empiezan a "opinar mal" de las colaboraciones / posteos útiles, y del tipo que pone su tiempo para hacerlas.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>Me ha pasado, le pasa a casi todo blogger y colaborador que ande suelto por Internet. Le pasa a los pibes/as que dan charlas en eventos ("quién se cree este/a"), o - un clásico - cuando un "don nadie" tiene el "atrevimiento" de corregir - correctamente inclusive - a un "entendido / experto" en alguna temática (aunque sea durante un intercambio en público).</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Ese comportamiento - sumamente predecible por cierto - antisocial y contra la colaboración en equipo, tiene una explicación en psicología que muchos desconocen, pero pueden leer muy bien explicada en el link del artículo de Arstechnica de más abajo.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">La causa</span></b></div>
<div style="text-align: justify;">
La causa del "descontento" > las reglas socioculturales imperantes típicamente hacen que la persona que está "disconforme" con el tipo que colabora lo "perciba" como:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
- Alguien que quiere auto-proveerse méritos (sea que los tenga realmente o no)<br />
<br />
<ul>
<li>¿Una especie de <a href="http://www.youtube.com/watch?v=8Nx5_gRgwVA" target="_blank">"Síndrome de la Llama que llama" :-D, "lo más de Zamora" jajaja</a>?</li>
</ul>
</div>
<div style="text-align: justify;">
- Alguien que quiere hacer quedar mal a los demás (una alternativa: "destacar lo mal que trabajan los demás", sea cierto o no claro).</div>
<div style="text-align: justify;">
<br />
<b>Por ende su respuesta psicológica casi automática es "estar en desacuerdo" con todo lo que opine / postee / escriba su colaborador voluntario de turno y además, creer que hay "algo malo", detrás de ese comportamiento generoso y colaborativo.</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Traduzco un párrafo muy interesante, referido a cómo se margina a los "super-colaboradores" de una comunidad o equipo de trabajo:<br />
<br />
<i><b>"Cuando hablamos del interés propio, este comportamiento es completamente contra-intuitivo; parece absurdo sancionar a estos super-colaboradores y querer expulsarlos del grupo. Después de todo, su generosidad incrementa las posibilidades de éxito de los demás, generalmente a expensas de las suyas propias. Pero la adherencia de los humanos a la conformidad es fuerte, y cuando las apuestas no son altas (N.del.Traductor > por ende no hace falta ayuda del super-colaborador), las normas sociales pueden ganarle al interés propio."</b></i><br />
<br />
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Publicidad profesional</span></b></div>
<div style="text-align: justify;">
Un clásico de la queja contra la gente que colabora en la red es <b>"Se hace publicidad a sí mismo/a".</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Y la respuesta es: <b>Por supuesto</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>La publicidad profesional, siempre necesaria es una resultante natural de los posteos públicos referidos a una cuestión / tema que es de interés laboral</b>, y es parte del "rédito no económico", que se lleva el blogger / posteador por tener la buena onda de tomarse su tiempo para buscar / escribir / postear / responder, y todo sin ganar un mango en general.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Aunque tampoco está mal si hay algo de auspicio económico: que es más que nada ads -en muchos blogs - y algun auspicio de bajo monto en la mayoría de los casos, excepto contadas excepciones; que de vuelta, no implica nada malo - sobre todo si los auspiciantes figuran a plena vista en el sitio, en los posteos., etc.</div>
<br />
<br />
<b><span style="font-size: large;">Utilidad para el gerente y/o líder de equipo</span></b><br />
Lo explicado arriba son nociones importantes a tener en cuenta la próxima vez que tengas un "super-colaborador" en tu equipo y por ejemplo tenerlo en cuenta al momento de las "peer-review" (lo que opinan los compañeros del super-colaborador), que obviamente pueden resultar desastrosas para el "super-colaborador".<br />
<br />
O como alternativa (no muy productiva), se puede promover un ambiente de performance "promedio", donde nadie se destaque del resto; más o menos la noción - o prerrogativa en los equipos menos productivos - anti-productiva conocida como "el clavo que sobresale recibe el martillazo".<br />
<br />
Ahora bien, imaginemos que vamos en el sentido inverso y buscamos formar equipos compuestos al completo por super-colaboradores, vas a tener una especie de dream-team.<br />
<br />
[<i>Una alternativa más realista: crear equipos con la mayor cantidad de super-colaboradores posible Y circunstancias que desalienten las acciones contra los super-colaboradores.</i>]<br />
<br />
<b>Por ejemplo es lo que se busca en empresas como Valve, GitHub, etc.</b><br />
<br />
<h1 class="heading" style="-webkit-font-smoothing: antialiased; background-color: white; color: #263034; font-family: NoticiaBold, 'Times New Roman', serif; font-size: 30px; list-style: none; margin: 0px; padding: 0px; text-rendering: optimizelegibility;">
<span style="font-size: large;">Links</span></h1>
<h1 class="heading" style="-webkit-font-smoothing: antialiased; background-color: white; color: #263034; font-family: NoticiaBold, 'Times New Roman', serif; font-size: 30px; list-style: none; margin: 0px; padding: 0px; text-rendering: optimizelegibility;">
Why good deeds don’t go unpunished</h1>
<h2 class="standalone-deck" style="background-color: white; border-bottom-color: rgb(221, 221, 221); border-bottom-style: solid; border-bottom-width: 1px; color: #657b83; font-family: Arial, sans-serif; font-size: 16px; font-weight: normal; list-style: none; margin: 0px 0px 8px; padding: 0px 0px 12px;">
Being overly generous can get you punished as a nonconformist.</h2>
<a href="http://arstechnica.com/science/2013/07/why-good-deeds-dont-go-unpunished/">http://arstechnica.com/science/2013/07/why-good-deeds-dont-go-unpunished/</a>Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-63736061401414943912013-07-01T20:43:00.000-07:002013-07-01T20:43:19.960-07:00La confusión: bajo nivel jerárquico no implica bajo nivel de expertise técnicoMiraba la noticia del link de abajo y pensaba, "es un malentendido, capaz se confundieron con el tipo". Es decir, lo subestimaron en vez de evaluar objetivamente el nivel de amenaza que representa un especialista de alto nivel técnico, muy experimentado. Es un error organizacional bastante común, muy explotado por los mejores hackers (esos que no salen por ningún diario).<br />
<br />
Explico: cuando un administrador de sistemas experimentado de buen nivel empieza a trabajar en una organización muchas veces arranca en posiciones de bajo nivel jerárquico, más allá del nivel de remuneración y el nivel técnico del laburo que haga.<br />
<br />
<b>El bajo nivel jerárquico del administrador en una organización puede ser malentendido por las personas en otros cargos jerárquicos superiores de áreas no informáticas</b> (gerenciales típicamente), como <i>"este tipo/a no tiene suficiente currículum / experiencia / conocimiento para hacer el trabajo de sus jefes técnicos, el de los líderes técnicos, ni el de otros puestos importantes"</i><br />
<br />
La realidad es que mucho laburo se acepta de lo que hay disponible, y las mejores posiciones, las mejor pagas, con mayor responsabilidad ya suelen estar ocupadas cuando un nuevo administrador llega a una organización.<br />
<br />
¿Eso significa que la persona no podría hacer el trabajo de cualquiera de sus compañeros de equipo y jefes técnicos hasta el nivel más alto?<b> En muchos, casos probablemente la respuesta es "no":</b><br />
<br />
Un buen administrador de sistemas, experimentado y capaz probablemente podría sentarse en la silla del jefe, tanto como la del líder técnico, tanto como la de otros administradores (DBA, Networking, Seguridad, etc.), sin mucho problema y haciendo un trabajo bastante bueno, inclusive mejorando sustancialmente las decisiones de la persona que esté ocupando la posición en ese momento; tal vez, simplemente llegó luego de que se "repartieron" todos los puestos importantes.<br />
<br />
Entonces, cuando ves un/a adm. de sistemas, redes, DBA, un developer con mucha "calle", etc. trabajando en una posición de bajo nivel jerárquico, ello no implica que la persona no pueda agarrar todos los sistemas de la organización (redes, servidores, bases de datos, etc.etc.), y administrarlas y gerenciarlas él/ella mismo/a.<br />
<br />
<br />
<a href="http://www.washingtonpost.com/world/national-security/edward-snowden-bradley-manning-and-the-risk-of-the-low-level-tech-savvy-leaker/2013/06/11/f5e3ad72-d2c7-11e2-a73e-826d299ff459_story.html">http://www.washingtonpost.com/world/national-security/edward-snowden-bradley-manning-and-the-risk-of-the-low-level-tech-savvy-leaker/2013/06/11/f5e3ad72-d2c7-11e2-a73e-826d299ff459_story.html</a>Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-34618537256030497832013-07-01T07:12:00.002-07:002013-07-01T07:19:30.154-07:00Appliances de red seguros ¿son seguros? ¿lo podés verificar?<span style="color: white; font-family: inherit; line-height: 15.453125px;">En otra disclosure de archivos del espionaje, hay un detalle importante: un hardware (Cryptofax), bastante caro, exclusivo y destinado a manejar comunicaciones seguradas y confidenciales, aparentemente viene "pinchado" de fábrica, incluyendo un backdoor.</span><br />
<span style="color: white; font-family: inherit;"><span style="line-height: 15.453125px;"><br /></span>
<span style="line-height: 15.453125px;">Da para pensar cuanto hardware caro, sofisticado y destinado a manejar comunicaciones seguras fabricado por estos muchachos (o mandado a fabricar), incluirá backdoors.</span></span><br />
<span style="color: white; font-family: inherit;"><span style="line-height: 15.453125px;"><br /></span>
<span style="line-height: 15.453125px;">Uds. saben cuanto hardware de este tipo hay instalado como firewalls/appliances diversos, en los bordes de las redes de bancos, financieras, empresas diversas, conectados directamente a Internet, e incluso en los peores casos, con conectividad abierta e irrestricta, para que el hardware se pueda conectar a ciertos servidores "seguros" en Internet para "actualizarse", y claro, para esto utiliza un protocolo propietario y comunicaciones encriptadas.</span></span><br />
<span style="color: white; font-family: inherit;"><span style="line-height: 15.453125px;"><br /></span>
<span style="line-height: 15.453125px;">Ahora, hasta donde podés estar seguro de que ese appliance conectado a Internet que tenés en la red del banco - por ejemplo - está "actualizando algo" o en realidad alguien está usando el backdoor para acceder a la red interna del banco (del ejemplo), y hacer cosas que no tenés idea de cuales pueden ser (ni predecir si va a ser contraproducente o no para el banco).</span></span><br />
<span style="color: #333333; font-family: lucida grande, tahoma, verdana, arial, sans-serif; font-size: x-small;"><span style="line-height: 15.453125px;"><br /></span></span>
<span style="color: #333333; font-family: lucida grande, tahoma, verdana, arial, sans-serif; font-size: x-small;"><span style="line-height: 15.453125px;"><a href="http://www.guardian.co.uk/world/2013/jun/30/nsa-leaks-us-bugging-european-allies" style="background-color: blue;">http://www.guardian.co.uk/world/2013/jun/30/nsa-leaks-us-bugging-european-allies</a></span></span><br />
<span style="color: #333333; font-family: lucida grande, tahoma, verdana, arial, sans-serif; font-size: x-small;"><span style="line-height: 15.453125px;"><br /></span></span>
<br />
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-17245576243945886292013-06-27T11:52:00.002-07:002013-06-27T12:06:50.598-07:00El peligro de los sistemas de escaneo de matrículas y otras bases de datos no autorizadas<br />
<div style="text-align: justify;">
Los sistemas de escaneo de matrículas permiten construir bases de datos que sirven para dibujar el recorrido de un vehículo dentro de una zona geográfica donde haya una cierta mínima cantidad de cámaras de vigilancia conectadas al sistema de captura/escaneo/identificación de matrículas.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
De ese modo, se puede lograr metadatos sumamente valiosos, y la infraestructura tecnológica necesaria para obtenerlos es relativamente barata y accesible en Argentina.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
El problema está en que son una área gris para regular: es una base de datos que guarda información públicamente disponible (la matrícula, está a la vista de cualquiera en la calle), pero acumula metadatos extremadamente sensibles: <b>debido a que el Estado tiene la información y la capacidad de asociar los datos de la patente (propietario, modelo, etc.), a las rutas habituales que recorre un vehículo que tiene determinada matrícula.</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i>En Argentina el área gris se da en que este tipo de base de datos "derivada" no está totalmente regulada por la legislación, a lo sumo podría ser desafiada legalmente en algún momento, si es que los datos de tránsito/recorrido se llegaran a usar como prueba en un juicio.</i></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Igualmente, esa noción es preferentemente evitada a como dé lugar, y los metadatos de recorrido se utilizan principalmente para la investigación y la obtención de otros medios de prueba de delitos, menos polémicos y/o con potencial para ser cuestionados legalmente; <b>sino inclusive desatar una polémica en la opinión pública que lleve a regular un área gris que hoy no está regulada.</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-size: large;">Ejemplos de posibles problemas</span>:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
La mayoría de estas bases de datos de uso "interno" en las fuerzas de seguridad son accedidas por operadores que no son especialistas, y muchos procedimientos rígidos y estrictos de securización del acceso deben seguirse para poder garantizar que el acceso a los metadatos del seguimiento de matrículas permanecen disponibles solo para aquellos específicamente designados, autorizados - y eventualmente auditables - para ello, y no se hacen disponibles para terceros ojos interesados, y peor aún, terceros interesados de los que no se tiene conocimiento y a los que nadie va a auditar.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
El problema está dado en que las bases de datos actuales están inmersas en sistemas altamente conectados, y una base de datos de la que pocos o casi nadie tiene conocimiento se presta especialmente al acceso no autorizado, justamente porque muchos usuarios de las redes y sistemas que podrían llegar a estar conectados con la base de datos, no tienen real noción de la importancia de equivocarse y/o saltarse mínimas reglas de securización.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Por ejemplo, son <b>clásicos ejemplos de des-securización de instalaciones y redes informáticas seguras</b> los siguientes:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>- Puertos USB disponibles en las terminales de acceso a la base de datos, donde cualquier persona puede conectar</b>:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
* <b><i>Llaveros USB</i></b>: que podrían contener troyanos construídos para trabajar en redes desconectadas (con "air gap", que no tienen ningun enlace de red con Internet) e ir montando una infraestructura de "dropboxes" de datos (donde van a guardar la información robada, que será transferida al llavero la próxima vez que se conecte), sino directamente ir instalando backdoors que intentan conectarse a Internet.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
* <b><i>Dispositivos USB con conectividad vía 3G o Wifi:</i></b> de ese modo, una supuesta red segura se convierte inmediatamente en una red conectada a Internet, con el sinnúmero de posibles problemas que esto acarrea.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
- <b>Que se permita el acceso a las instalaciones con smartphones</b>: las posibilidades de hacking son desde pocas a totales en el caso de un ataque dirigido que esté usando smartphones como "posta" para lograr sortear el "air gap" que mantiene a la red segura de la base desconectada.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
- <b>Que no haya ningún tipo de vigilancia, registro automático constante de vídeo para los operadores</b>: Una medida de seguridad extremadamente simple de usar (prácticamente todos los supermercados de tamaños medio en adelante la implementan en sus cajas de cobro), si está ausente, genera la posibilidad deshusada de invalidar todas las demás medidas, por ejemplo: simplemente porque si algún operador perdió o le robaron las credenciales (idealmente 2-factor: credenciales-smartcards/contraseña), de ese modo si alguien más - inclusive otro operador autorizado - utiliza el acceso, no hay forma de individualizar a la persona que impersonó al operador.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
etc.etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b><span style="font-size: large;">Conclusiones</span></b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Es decir, <b>el potencial para el mal uso de bases de datos con metadatos sensibles es grande, y los problemas no tienen antecedentes - todavía - simplemente porque muy poca gente - ciudadanos comunes y "civiles" no vinculados a fuerzas de seguridad principalmente - está al tanto del potencial de este tipo de herramientas en los habituales juegos políticos, económicos, socio-económicos, etc.</b><br />
<b><br /></b>
<b>En cuanto "jugadores" suficientemente motivados y bien financiados requieran acceder - legal o ilegalmente - a los metadatos, es posible que veamos aparecer los primeros casos - públicos - de mal uso de esas bases de datos.</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Si en Argentina es casi una costumbre el que aparezcan expedientes completos - privadísimos y de acceso muy restringido - fotocopiados fuera de los juzgados, es de esperar que dado el valor superlativo de los metadatos (en comparación con un "simple" expediente por ejemplo), eventualmente dé lugar a que importantes intereses se muevan hacia intentar accederlos ilegalmente, lo que efectivamente va a ser mucho más sencillo si los ciudadanos ignoran totalmente el peligro y el valor real de esas bases de datos.<br />
<br />
<b><span style="font-size: large;">Links:</span></b><br />
<b><a href="http://cironline.org/reports/license-plate-readers-let-police-collect-millions-records-drivers-4883" target="_blank">License-plate readers let police collect millions of records on drivers</a></b><br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com1tag:blogger.com,1999:blog-7919047293328713502.post-73508288631170973822013-06-27T08:34:00.002-07:002013-06-27T08:59:53.079-07:00Tips para diseñar sistemas de backup realmente útiles<br />
El sistema de backup de una infraestructura compleja tiene que ser lo más simple posible: fácil de entender por alguien - un administrador - que no sea un especialista, y se haga cargo de la administración.<br />
<br />
Fácil de usar para quienes no sean admins especialistas en backup, fácil para trabajar en una emergencia, cuando se necesita del backup y no se puede prestar atención a los detalles técnicos intrincados de un sistema de backup complejo; y finalmente fácil de restaurar a su funcionamiento normal cuando hay alguna falla interna.<br />
<br />
Catálogos internos que se guardan en bases de datos propietarias, backends en bases de datos que pueden fallar, múltiples componentes distribuídos (que necesitan literalmente matemática combinatoria y grafos para llegar a conocer todos los posibles estados de error del sistema), etc. conspiran contra sistemas de backup simples y realmente manejables.<br />
<br />
<b>Los casos en que hace falta que un sistema de backup sea complejo e intrincado son escasos, muy raros. La mayoría de la infraestructura se puede diseñar y configurar de modo tal de disponer de "dropboxes" fácilmente recuperables: son directorios/carpetas donde se depositan o hacen disponibles los datos a resguardar.</b><br />
<br />
Un ejemplo de "dropboxes" se da cuando se quiere backupear una base de datos y se guarda datos a un directorio que luego será backpeado:<br />
<br />
- Con el clásico procedimiento de dumpear bases a backupear, o<br />
- En un backup "raw", en crudo, bajando la base y backupeando limpiamente todos los directorios donde el software guarde y escriba datos. Lo que es posible en gral. y sin mucho problema en sistemas Linux y *Nix, y suele ser más complicado en Windows Server, debido a que muchos valores de configuración pueden estar guardados en el registro (hace falta crear un paso intermedio donde se "dumpea" todos los valores relevantes del registro a un archivo .reg que permita luego recuperar "crudamente" el software en un Windows "limpio").Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-19158852189704492252013-06-23T13:03:00.001-07:002013-06-23T13:03:42.390-07:00Autoservicio de Infraestructura como Servicio <span style="font-size: large;"><b>Objetivo</b></span><br />
Una "caja" que se conecte a en cualquier puerto de la red, si se puede conectar al menos 2 puertos, mejor (redundancia).<br />
<br />
Esta "caja" va a brindar un autoservicio a un grupo de usuarios acreditados (con usuario/contraseña), creandoles máquinas virtuales desde plantillas, para que puedan trabajar / experimentar / estudiar con ellas.<br />
<br />
Un número ilimitado de estas cajas se puede conectar a la red y elevar la cantidad de recursos disponibles; cada caja es independiente de las demás, simplificando y eliminando la necesidad de administrar y coordinar - manual o semi-manualmente - esos recursos distribuídos.<br />
<br />
<b><span style="font-size: large;">Servicio</span></b><br />
Los usuarios se conectan a la caja (vía IP o nombre) a una interfaz web, piden su máquina-servidor virtual, la caja lo crea en base a una plantilla (inmediatamente), les entrega las credenciales (root, pass, IP, SSH, root mysql para phpmyadmin, etc.). La máquina virtual entregada permanece activa durante un tiempo fijo máximo (2 a 8 horas), luego es borrada automáticamente.<br />
<br />
Los usuarios al conectarse a la interfaz pueden ver si hay recursos disponibles para crear la máquina virtual en ese momento, y cuanto tiempo falta para que haya recursos suficientes. En ese momento si se conectan van a poder crear su máquina virtual.<br />
<br />
Los usuarios pueden agendar - con limitaciones - a qué hora quieren crear su máquina virtual, con al menos dos días de retraso, de ese modo pueden asegurar que el servidor virtual va a estar activo y funcionando justo cuando lo necesiten.<br />
<br />
Las máquinas que no registren actividad, luego de 30 minutos, serán borradas automáticamente.<br />
<br />
<br />
<span style="font-size: large;"><b>Ingredientes para una caja</b></span><br />
Una PC, con 2 discos de 1TB, en mirror, 8 GB Ram*, y un buen procesador.<br />
<span style="font-size: x-small;">* A más ram, mayor cantidad de máquinas virtuales simultáneas se puede correr.</span><br />
<br />
<span style="font-size: large;"><b>Instrucciones generales</b></span><br />
Se va a instalar un hipervisor sobre la máquina, dentro de una máquina virtual, se va a configurar el sistema de gestión del autoservicio, una vez iniciado el sistema, quedará disponible en una IP, donde los usuarios van a poder empezar a crear sus máquinas virtuales.<br />
<br />
<b><span style="font-size: large;">Plantillas estándar de máquina virtual:</span></b><br />
- Debian Linux 7.1 - LAMP - 15 GB de disco rígido (12 GB libres aprox.), 1 GB de RAM, 1 núcleo.<br />
- Ubuntu LTS 12.04 - LAMP - 15 GB de disco rígido (12 GB libres aprox.), 1 GB de RAM, 1 núcleo.<br />
- Ubuntu 13.04 - Imagen Booteable - 1 GB de disco rígico (1 GB libre) , 1 GB de RAM, 1 núcleo<br />
etc.<br />
<br />
<div style="text-align: center;">
<b>¿Querés una caja? Podés hacerla con software opensource o solicitar consultoría a <a href="https://www.facebook.com/LibresConsultores" target="_blank">Libres Consultores</a> al respecto.</b></div>
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-7826047412346639222013-06-22T06:04:00.002-07:002013-06-22T06:09:06.933-07:00Tip: Usando egrep con más de una expresiónA veces necesitamos filtrar más de una expresión en un output y el filtrado con grep nos va pedir que corramos el comando más de una vez para ver todos los resultados, así:<br />
<br />
<i><span style="font-family: Courier New, Courier, monospace;"><b>lspci | grep -i audio</b></span></i><br />
<i><span style="font-family: Courier New, Courier, monospace;"><b>lspci | grep -i vga</b></span></i><br />
<br />
<br />
Se puede ver todos los resultados de una sola vez con egrep, así:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;"><b>lspci | egrep -i 'audio|vga'</b></span><br />
<span style="font-family: Courier New, Courier, monospace;">00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12)</span><br />
<span style="font-family: Courier New, Courier, monospace;">00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">El parámetro "-i" es para que egrep busque sin distinguir mayúsculas.</span><br />
<br />
<br />
Claro, es más escalable, ya que podemos buscar una gran cantidad de patrones simultáneamente:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;"><b>lspci | egrep -i 'audio|vga|ethernet|network'</b></span><br />
<span style="font-family: Courier New, Courier, monospace;">00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12)</span><br />
<span style="font-family: Courier New, Courier, monospace;">00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)</span><br />
<span style="font-family: Courier New, Courier, monospace;">03:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)</span><br />
<span style="font-family: Courier New, Courier, monospace;">04:00.0 Ethernet controller: Atheros Communications Inc. AR8152 v1.1 Fast Ethernet (rev c1)</span>Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com1tag:blogger.com,1999:blog-7919047293328713502.post-59417755763733184562013-06-22T05:44:00.003-07:002013-06-22T05:44:51.745-07:00Convertir logs Squid estándar para ver los horarios en formato human readableEs un one-liner muy interesante y útil:<br />
<b><br /></b>
<b>perl -p -e 's/^([0-9]*)/"[".localtime($1)."]"/e' < access.log > access.log.h</b>Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-32913904465494596462013-06-20T06:51:00.003-07:002013-06-20T06:53:55.420-07:00Nuevo sitio web de la Facultad de Medicina - UNNE<br />
<div class="separator" style="clear: both; text-align: justify;">
Lo terminamos de migrar y este es un screenshot mostrando su nuevo diseño y funcionalidades. </div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
<b>Laburo de equipo 100%</b>: </div>
<div class="separator" style="clear: both; text-align: justify;">
La empresa Coninfo implementando su producto Notix y el equipo de la Facultad (re)cargando el contenido y las nuevas páginas; implementando la infraestructura necesaria para que todo funcione bien.</div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
<a href="http://med.unne.edu.ar/">http://med.unne.edu.ar/</a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-2neRIbwrHy4/UcMI0sla8BI/AAAAAAAAAMU/KLhLqQfLx8w/s1600/shot15.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="267" src="http://2.bp.blogspot.com/-2neRIbwrHy4/UcMI0sla8BI/AAAAAAAAAMU/KLhLqQfLx8w/s400/shot15.jpg" width="400" /></a></div>
<br />Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-53126864726452175692013-06-19T05:41:00.004-07:002013-06-19T05:43:00.961-07:00You're not gonna change the world- When somebody tells you the world can't be changed, they're telling you that they can't do it, or they don't know how to do it, but they're not talking about you.<br />
<br />
- Can the world be changed?<br />
<br />
- Yes, it can be changed, the world changes all the time, people never stop changing the world, for good or bad.<br />
<br />
Gengis Kan, Julio César, the Medici guys, Da Vinci, Newton, Washington, Ben Franklin, Mao, Stalin, San Martín, Hitler, Einstein, Kennedy, those who killed Kennedy, all them changed the world.<br />
<br />
If you are not changing the world, somebody else is doing it for you, right now. You should worry about if you're gonna like or not what they've got planned to do with it and if you're going to do something about.Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-62975642944307872252013-06-17T20:39:00.002-07:002013-06-17T21:14:25.453-07:00¿Pedir consejo / opinión sobre soft libre / opensource a vendedores de soft propietario?<br />
Parece obvio, pero..<b>pedirle consejo / opinión a un vendedor de soft propietario / pago sobre lo buenas / malas que pueden ser las soluciones basadas en software libre / opensource </b>> ¿Qué creen que va a responder?<br />
<br />
El negocio IT es un negocio, y<b> los consultores / empresas de soft propietario hacen su negocio, lo que está totalmente bien.</b><br />
<br />
Si Uds. fueran vendedores de soft propietario y en el marco de una posible oportunidad de negocios - vender software - alguien les preguntara por un software que Uds. no venden, que no pueden vender (por acuerdos y lealtad comercial con los fabricantes de soft propietario), del que no pueden vender soporte (razón, idem anterior), que se descarga gratis de Internet, etc... de vuelta <b>¿Qué responderían Uds.?</b><br />
<br />
Escribo esto porque hace poco, por enésima vez escuché de al menos un par de IT guys, y al menos dos empresas / organizaciones que les piden consejo sobre la calidad / fiabilidad / utilidad de software opensource / libre a vendedores de software propietario. y<b> ¿Cuál creen Uds. que pudo haber sido la respuesta?</b><br />
<br />
<span style="font-size: large;"><b>"El tipo que sabe"</b></span><br />
La fundamentación de por qué se pregunta a un vendedor de soft propietario sobre soluciones basadas en soft libre / opensource suele ser <i>"Es un ingeniero / licenciado / tipo con mucha experiencia, trabajó mucho en X e Y especialidades, de mucho nivel técnico", etc.</i><b> Además de eso</b>, ahora está actuando como vendedor / empleado / socio de su empresa de IT que vende soft propietario. <b><u>Cuando se le pregunta, se plantea un conflicto de intereses, que éticamente el vendedor / profesional, está habilitado de resolver a favor de su conveniencia comercial.</u></b><br />
<br />
Así que, más allá de lo buen profesional que sea el vendedor, no se discute la cuestión técnica, sino el interés comercial. <b>El vendedor, la mayoría o en todos los casos en que se le pregunte, va a terminar respondiendo que él - personalmente inclusive - implementaría una solución propietaria.</b><br />
<b><br /></b>
<b><span style="font-size: large;">Conclusión</span></b><br />
<b>Como responsables de IT de organizaciones / empresas no solo es una responsabilidad conseguir las mejores respuestas, también hay que saber hacer las preguntas correctas y saber a quien/es preguntar sobre qué temas.</b><br />
<br />
Correcciones, bienvenidas.Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0tag:blogger.com,1999:blog-7919047293328713502.post-20413106945050675152013-06-17T07:10:00.000-07:002013-06-17T07:16:05.691-07:00Perder conexión remota, correr comandos, recuperar conexión remota<br />
Resulta que a veces tenemos un server remoto configurado con una IP, nos conectamos, pero tenemos que desactivar la IP a la cual nos conectamos, correr comandos y luego necesitamos volver a poder conectarnos (y activar la IP a la cual nos conectamos por ende).<br />
<br />
Por ejemplo, nos conectamos al server para trabajar, vía SSH a la IP 192.168.0.117, pero luego necesitamos - por algun motivo - desactivar esta interfaz/IP, correr algún comando y luego volver a configurar la IP 192.168.0.117.<br />
<br />
En el camino vamos a perder la conexión remota, luego cuando la IP vuelva a estar accesible, la vamos a poder reestablecer.<br />
<br />
Este es un one-liner que hace eso:<br />
<br />
<i>ifconfig eth0 down ; ifconfig eth1 10.17.15.19 netmask 255.255.255.0 up ; route add default gw 10.17.15.1 eth0 ; echo "Este comando corrió al tener desactivada la interfaz eth0 y bajada la IP a donde nos conectamos en forma remota" ; sleep 240 ; route del default gw 10.17.15.1 ; ifconfig eth1 down ; ifconfig eth0 192.168.0.117 netmask 255.255.255.0 up ; route add default gw 192.168.0.1 eth0</i><br />
<br />
<b>Desglosando el one-liner, por comandos:</b><br />
<br />
<b>1) Baja la interfaz eth0</b><br />
<b>--</b><br />
<b>En este punto perdemos la conexión remota SSH</b><br />
<b>--</b><br />
<b>2) Configura la interfaz eth1</b><br />
<b>3) Carga una ruta estática para eth1</b><br />
<b>4) Ejecuta un comando mientras eth0 está desactivada</b><br />
<b>5) Ejecuta otro comando, haciendo una pausa de 4 minutos, luego contínua con el siguiente comando.</b><br />
<b>6) Borra manualmente la ruta estática para eth1</b><br />
<b>7) Baja la interfaz eth1</b><br />
<b>7) Activa y configura de vuelta eth0</b><br />
<b>8) Carga la ruta estática de eth0</b><br />
<b>--</b><br />
<b>En este punto podremos volver a conectarnos al host remoto vía SSH</b><br />
<b>--</b><br />
<br />
Como ven es un ejemplo con muchas posibilidades de mejora, y si en vez de usar un one-liner lo ponen en un script, puede funcionar mucho mejor incluso.<br />
<br />
Que les sea útil.Anonymoushttp://www.blogger.com/profile/08062068068182578270noreply@blogger.com0