Desinstalar paquetes problemáticos de un Synology

Si alguna vez te has encontrado con problemas al desinstalar un paquete de tu Synology, prueba estas instrucciones para hacerlo directamente desde la raíz del sistema.

Desde hace varios años que trabajo en casa con un par de Synology DiskStation DS216se. Es una buena manera de tener backups en casa con un gran panel de gestión y de forma sencilla. Seguramente ahora tomaría la decisión de hacer algunos cambios (y probablemente los haga) como añadirle discos SSD que he tenido la posibilidad de comprobar con clientes y amigos, pero es lo que hay.

Uno de los problemas que me he encontrado en uno de los que tengo es la imposibilidad de desinstalar un paquete desde el propio panel. El problema estaba (seguramente) en que en una primera desinstalación algo falló y se quedó colgado y a medias. Al intentar desinstalarlo me decís que no podía acceder al MariaDB, pero si accedía por CLI ya no existían las bases de datos ni nada. Estaba corrupto el sistema.

Tras probar y probar finalmente decidí que la mejor solución era desinstalar los paquetes manualmente por bash, así que activé el SSH y me metí en el sistema. Para esto, lo primero que hay que tener es acceso SSH, que está en el Panel de Control -> Terminal y SNMP. Allí se activa la opción SSH y se aplican los filtros del Firewall. Si dejáis el puerto 22 por defecto la cosa será muy compatible con todo.

Una vez esté activado el SSH, lo siguiente es entrar por un terminal (tipo el Putty), entrar en vuestra IP por el puerto 22, con vuestro usuario (y teniendo permisos de root, que os hará falta).

Lo siguiente es ir a estas carpetas y erradicar todo su contenido:

  • cd /volume1/@appstore
  • sudo rm -rf nombredelpaqueteaeliminar
  • cd /var/packages
  • sudo rm -rf nombredelpaqueteaeliminar
  • cd /usr/local
  • sudo rm -rf nombredelpaqueteaeliminar

Una vez hecho esto, podéis volver al panel del Synology, entrar en la zona de paquetes y ya os habrá desaparecido el paquete por completo.

Community Managers ¿son rentables?

¡Hola amigo! Hoy te voy a demostrar si esa moda tuya de tener a alguien cobrando por hacer de Community Managers es rentable o no. Y es que en lo que respecta a Internet, todo se puede medir.

Sé que con este artículo puedo ganarme muchos enemigos, y la verdad es que el origen de lo que voy a explicar aquí no venía por la pregunta de sí es o no rentable alguien que gestiona las redes sociales sino que venía por la posibilidad de medir o de tener cierta inteligencia en Google Analytics con respecto a las redes sociales (en primera instancia, Twitter).

El pasado viernes en la clase del Postgrado Web Analytics comenzamos a medir la información de las fuentes de tráfico. Uno de estos informes es el de los referral y en él encontramos, por norma general, el tráfico que llega desde Twitter, Facebook y demás. En principio estos datos deberían ser fiables (luego os comentaré cómo mejorar esa fiabilidad) y partiendo de estos datos salieron dudas.

Si entramos en Google Analytics, seleccionamos un sitio web, y nos vamos al menú a Fuentes de Tráfico -> Fuentes -> Referencias tendremos un bonito listado de fuentes, entre la cuales suele aparecer [t.co] y [facebook.com]. Como decía antes, voy a focalizarme en Twitter y su acortador [T.CO], que es la forma de poder medirlo. Así que si entramos en esta fuente obtendremos una lista de las Rutas de Referencia (aká, la URL) que se han pulsado en el acortador.

Estos datos son de varios meses y podemos ver cómo algunos de los enlaces han conseguido bastante relevancia hasta conseguir más de 4.000 visitas. Además también podemos ver que hay más de 13.000 enlaces distintos del acortador de Twitter, lo que supone, en principio, un trabajo bastante elevado de gestión.

Un Community Manager ahora te diría que es una persona extraordinaria porque te ha generado más de 300.000 visitas desde Twitter en unos pocos meses… pero no es cierto, ya que estos enlaces pueden haberse generado gracias al botón de compartir o similares… así que, primer punto: ¿cómo puedo medir el trabajo propio de esta persona? La respuesta es relativamente sencilla, y es un pequeño truco que podemos aprovechar de Google Analytics: el parámetro utm_content. Según la ayuda, significa lo siguiente:

Campo utilizado para las pruebas del contenido A/B y los anuncios orientados a la Red de Display. Utilice utm_content para diferenciar los anuncios o enlaces que llevan a la misma URL.

Aunque esto implica algo más de trabajo, podríamos montarnos un sistema sencillo que permita controlar las páginas de destino de los tweets generados. Para ello, cuando añadamos uno, deberíamos hacer algo tal que así:

Tweet Original:

Acabo de escribir un tweet sobre los Community Managers http://javiercasares.com/blog/rentabilidad-community-manager/

Tweet Mejorado:

Acabo de escribir un tweet sobre los Community Managers http://javiercasares.com/blog/rentabilidad-community-manager/?utm_content=201305061000+Community+Managers&utm_source=twitter.com

La diferencia entre uno y otro es que el segundo incorpora dos parámetros en la URL:

  • utm_content = 201305061000+Community+Managers: Con esto podemos incluir una fecha y hora (año mes dia hora minuto) seguido de un texto que identifique el enlace del tweet.
  • utm_source = twitter.com: COn esto podemos sobre escribir la fuente original del tweet, dejando de lado el acortador de twitter [t.co] y sustituyendo esa información por el propio twitter [twitter.com]

Con este sistema, entonces, podrás diferencias tus entradas de las que se hagan por otros métodos. Además, si se hace un informe (ahora en el que la fuente es [twitter.com] y no [t.co]) en el que indicamos la página de destino y le incluimos una dimensión secundaria con el Contenido del anuncio (que es el valor del parámetro utm_content) tendremos información exacta del trabajo que ha realizado concretamente nuestro Community Manager, incluyendo, y esto es importante, únicamente sus tweets y el ruido que haya generado (con sus retweets, o sus citas).

Vale, este es uno de los puntos que quería tratar, pero con esto simplemente tenemos información de lo que hacen, pero no de la rentabilidad que tienen. Por norma general muchos de los sitios web tienen Google Adsense, y una de las cosas interesantes es que como se puede relacionar Google Adsense con Google Analytics tenemos un detalle interesante: saber cuánto dinero generan los tweets.

Para ello en los mismos informes en los que estábamos sólo debemos activar la opción Adsense y veremos los ingresos. Particularmente no me convence esta opción porque no se pueden relacionar datos, así que lo mejor es crearse un informe personalizado en el que se incluyan, principalmente, datos como las visitas, páginas vistas, tasa de rebote e ingresos…

Para que os hagáis una idea, según el propio Google Analytics, los ingresos en publicidad de Adsense generados desde Twitter en los últimos meses han sido de poco más de 90 dólares (unos 80 euros). Vale, ahora podéis decirme que también hay publicidad (lo que significa que podemos sacar una media de ingresos por CPM) y que si hemos tenido en varios meses más de 400.000 páginas vistas, a una media de, por ejemplo, 1 euro de CPM, habríamos generado unos 400 euros. Vale, 400 euros de Display + 80 euros de Adsense: 480 euros en un término de varios meses. No da para pagar ni a un becario.

En fin, todo es medible, las redes sociales también, y ello implica que las modas pasajeras pueden ser muy peligrosas.

Los DNAME en las DNS

Aunque ahora mismo es tan sólo una propuesta, creo muy acertada esta nueva posible entrada de las DNS porque, sobretodo a nivel de rendimiento de WPO podría dar un salto cualitativo en cuanto a determinadas acciones que hacemos habitualmente con los dominios, más concretamente con las redirecciones. Incluso, he de añadir, para reducir el impacto de la cantidad de líneas que puede haber en los servidores DNS.

Para situarnos estoy hablando de la propuesta del RFC 6672 (DNAME Redirection in the DNS) que propone incorporar una entrada nueva llamada DNAME.

Para no entrar en detalles muy raros, voy a intentar poner un caso para ver el sentido que tiene. Imaginad que tenemos dos dominios iguales, con las mismas entradas DNS. Por ejemplo [example.com] y [dominio.es]. Dado este caso, en que los dos dominios son exactamente iguales (a nivel DNS)… ¿tiene sentido mantener dos copias de las entradas DNS? ¿No sería más fácil decir que las entradas DNS de [dominio.es] son una copia de las de [example.com] y simplemente cambiando las del .com que se actualizase todo?

Pues básicamente este es el objetivo de la entrada DNAME. El ejemplo visual (los que tocáis mucho las DNS seguramente lo pilléis enseguida:

    QNAME            owner  DNAME   target         result
    ---------------- -------------- -------------- -----------------
    com.             example.com.   example.net.   <no match>
    example.com.     example.com.   example.net.   [0]
    a.example.com.   example.com.   example.net.   a.example.net.
    a.b.example.com. example.com.   example.net.   a.b.example.net.
    ab.example.com.  b.example.com. example.net.   <no match>
    foo.example.com. example.com.   example.net.   foo.example.net.
    a.x.example.com. x.example.com. example.net.   a.example.net.
    a.example.com.   example.com.   y.example.net. a.y.example.net.
    cyc.example.com. example.com.   example.com.   cyc.example.com.
    cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
    shortloop.x.x.   x.             .              shortloop.x.
    shortloop.x.     x.             .              shortloop.

El objetivo es que el campo “target” sea como el sustituto del patrón que se le pasa. De esta forma, poniendo la tercera línea de ejemplo, tendríamos que, partiendo de la base de [a.example.com] el dominio sería [example.com] y el DNAME sería [example.net], si hacemos un “sustituir” de [example.net] por [example.com] nos quedaría [a.example.net].

El planteamiento, a nivel de similitud, es como un CNAME con esteroides, ya que no deja de ser como un alias, pero que además sustituye fragmentos de las entradas DNS por otras que pueden ser de otro dominio.

Un detalle interesante es que, aunque no se recomienda su uso, se podría a llegar a utilizar el “wildcard” (o sea, el [*.example.com] para sustituir grandes cantidades de entradas DNS por otras. No se recomienda el uso porque podría invalidar el DNSSEC, pero la verdad, teniendo en cuenta la poca penetración que tiene, tampoco tengo claro que, para la mayoría, sea un problema.

Aunque no deja de ser una propuesta (en mi opinión muy interesante) no tengo claro que sea algo que se vaya a implementar rápidamente. Seguramente dependerá más de los ISP que comiencen a implementar servidores que lo soporten, pero, tampoco es algo que creo que sea muy recomendable para la gran mayoría de los usuarios, ya que un pequeño error puede provocar la invalidación de las DNS. Así que, lo más probable es que para añadir una entrada de este tipo se tengan que hacer varias validaciones “automáticas” para controlar las posibles cagadas poniendo estas entradas.

Dominios reservados

¿Cuál es el dominio que no existe y que deberíamos usar siempre que hacemos referencia a una dirección URI que no existe? Pues hay varios, no os lo voy a negar, y todo depende de las necesidades que tengamos.

Y es que existe el RFC 2606 que habla de esto mismo… los Reserved Top Level DNS Names. Básicamente este documento nos informa de los 4 TLD que hay cuando queremos hacer referencia a pruebas.

  • .test: Se recomienda para probar DNS.
  • .example: Se recomienda cuando en un documento se hace referencia a alguna dirección.
  • .invalid: Se recomienda cuando se hace referencia a dominios incorrectos o errores.
  • .localhost: Este es el único que técnicamente no es del todo un error o un ejemplo, ya que se puede utilizar internamente en las DNS para hacer una autollamada o hacer uso de direcciones IP privadas sobre él.

Claro está, esto es siempre para los TLD, pero ¿qué ocurre en los segundos nivele? Vamos, en lo que normalmente conocemos como un “dominio”? Para ello el sistema es claro: example.com, example.net y example.org.

Hay otros TLD de los nuevos que, ya de base, llevan una serie de limitaciones. Por ejemplo el .INFO define el dominio [example.info] como un dominio .info reservado en este caso para la IANA. Esto mismo ocurre con los dominios .biz reservados que excluyen el [example.biz]. En principio, el resto de dominios, como desde hace tiempo, son asignados y aprobados por IANA, ocurre lo mismo.

En el caso de los ccTLD no se especifica nada a nivel general, sino que el bloqueo de los dominios queda en manos de cada uno de los organismos. Por ejemplo, en NIC.ES, el organismo que regula los dominios “.es”, quedan prohibido según su documentación el [dominio.es]. Hay otros tantos, pero este parece ser el único que el organismo no usará (ya que aunque está prohibido, el [dominio.es] sí que lo utilizan como promoción, saltándose sus propias reglas (como decenas de veces han hecho en e pasado).

En otros casos, como por ejemplo el dominio francés .FR (y todos los que gestiona el organismo) no plantea un dominio de segundo nivel reservado para este uso. Sí que es cierto que disponen de varios dominios reservados, pero concretamente para hacerse eco de un ejemplo de uso no.

Así que a partir de ahora, si vas a escribir una entrada hablando de dominios de ejemplo, o tienes que referirte a ellos, ya sabes que has de analizar de forma diferente lo general de los dominios territoriales.

Mis plugins para Firefox

De tanto en tanto se hace recurrente en mi vida una pregunta que me hacen: ¿Y tú que navegador usas? La respuesta es sencilla: Firefox. Y es que uso Firefox desde prácticamente cuando aún era Netscape Navigator. Y luego, viene la siguiente pregunta: ¿Y por qué Firefox? Pues básicamente por las ampliaciones que lleva. Y entonces comienzan las discusiones con los amantes de Chrome. En ese momento, casi antes de comenzar, simplemente me voy.

El hecho de usar Firefox (incluso os puedo decir que desde hace unas semanas ya me he lanzado a la piscina porque usaba primero las betas, luego Aurora y ahora Nightly de 64 bits -lo que significa que en este momento estoy con una alpha de Firefox 21-) viene dado principalmente por su lista de “plugins” (o addons).

¿Y cuáles son esas ampliaciones que utilizo? Pues es la siguiente:

  • Adblock Plus: Simplemente para no ver publicidad. Que conste que no siempre lo tengo activado, pero para desarrollar va bastante bien.
  • Advertising Cookie Opt-out: Pasando de las cookies de Adsense y Doubleclick.
  • Beef Taco: pasando de las cookies de otra decena de sitios de publicidad y de basurilla.
  • Classic Retweet: Lo siento, pero añoro el primer Twitter…
  • ColorZilla: Permite seleccionar cualquier color de una web. No lo uso mucho, que conste.
  • DNS Flusher: Cuando trabajas con muchas máquinas en desarrollo, preproducción y producción se vuelve algo básico la limpieza de las DNS.
  • Firebug: Herramienta básica del desarrollador.
  • Flash Video Downloader: Útil en algunas ocasiones. No lo suelo usar casi nunca.
  • Ghostery: Informa de todos los “spyware” que intentan colarte las webs…
  • HTTPS Everywhere: El nombre ya lo indica todo.
  • Live HTTP Headers: Un clásico para ver las cabeceras. Básico para el WPO.
  • Long URL Please: Muestra las URL de acortadores en su versión completa.
  • MeasureIt: Para medir anchos y altos de elementos web.
  • LessChrome HD: Oculta el menú. Pensando en saltar al LessChrome Modified.
  • Page Speed: Otro de los complementos básicos del WPO.
  • PDF Viewer: Muestra los PDF integrados en el navegador, sin el plugin de Adobe.
  • Pearl Crescent Page Saver Basic: Capturador de pantalla o de toda la página.
  • Pocket: Si usas Pocket, es necesario tenerlo también en el navegador bien integrado.
  • Web Developer: La barra básica en mi vida… si veo un Firefox sin ella, la instalo, porque lo digo yo.
  • YSlow: Otra de las herramientas clave en el WPO.

Tengo una lista de plugins pendientes de usar y/o de decidir si se quedan o no se quedan en mi lista de establecidos…

  • Cache Status: permite gestionar la caché de forma rápida (algo también de uso habitual en mi caso).
  • Modify Headers: A veces no sólo es necesario “ver” cabeceras, sino que hay que “tocarlas”.
  • Poster: Otro más que tiene que ver con las cabeceras. Lo veo muy completo, pero no sé si es lo que necesito, aún.

Vuelvo a decir, ya sé que Chrome y Opera tienen muchos plugins y muchas cosas… pero me gusta el zorro, ¡qué le vamos a hacer!

Ninja Team

Cuando desde Keep It Simple Lab nos llega un correo porque alguien quiere que le ayudemos con temas de SEO y WPO cada vez se esta haciendo más frecuente la pregunta de qué software se está utilizando y dónde (en casa o externalizado) está el equipo de desarrollo. Y depende mucho de esta respuesta que queramos trabajar con esa persona o empresa. ¿Por qué? La respuesta es muy sencilla: no queremos trabajar con gente inútil. Y no me entendáis mal, no quiero decir que la gente sea tonta o similar, sino que no es útil. Tanto en temas de SEO y aún más en temas de WPO es muy importante hacer las cosas exactamente como se piden. Por eso somos buenos, porque sabemos con exactitud lo que hay que hacer, pero sobretodo si se puede o no hacer. Y aquí es donde entran los “problemas”.

Pero antes de seguir me gustaría introducir varios conceptos:

  • Ninja: Los ninjas eran un grupo militar de mercenarios entrenados especialmente en formas no ortodoxas de hacer la guerra, en las que se incluía el asesinato, espionaje, sabotaje, reconocimiento y guerra de guerrillas, con el afán de desestabilizar al ejército enemigo, obtener información vital de la posición de sus tropas o lograr una ventaja importante que pudiera ser decisiva en el campo de batalla.
  • Código Spaghetti: El código spaghetti es un término peyorativo para los programas de computación que tienen una estructura de control de flujo compleja e incomprensible. Su nombre deriva del hecho que este tipo de código parece asemejarse a un plato de espaguetis, es decir, un montón de hilos intrincados y anudados.
  • Framework: Un framework para aplicaciones web es un framework diseñado para apoyar el desarrollo de sitios web dinámicos, aplicaciones web y servicios web. Este tipo de frameworks intenta aliviar el exceso de carga asociado con actividades comunes usadas en desarrollos web.

Ahora que ya sabemos lo que es un ninja, un framework y el spaghetti-code podéis haceros una idea de por dónde quiero ir. Y es que estoy muy cansado de los frameworks. Son una putas cajas negras que las cosas más sencillas de hacer en spaghetti se vuelven muy complejas. Como digo esto lo explico desde la propia experiencia, porque dos de los últimos proyectos que nos hemos encontrado hechos en Symfony o se han ido al retrete o se tienen que rehacer, y ya no os cuento cosas hechas en CodeIgniter. También he sufrido mierdas hechas con Zend que han acabado en la Papelera de Reciclaje.

Y que conste que no estoy en contra de los frameworks, estoy en contra de los programadores que no saben qué hace un framework ni cómo solventar problemas que generan. Y aunque no estoy en contra de ellos, sí que estoy en contra de los que usan uno y no saben bien bien qué configuración genera por defecto. Por ejemplo, hace unos días nos encontramos un marrón con Symfony en el que devolvía unas cabeceras HTTP/1.0 (tecnología de Internet que hace más de 10 años tiene una versión 1.1) y por otro lado unas configuraciones multiidiomas que sí, que están estandarizadas en el RFC2616 pero que cuando la “gente” te pide SEO es para tirar a la basura el proyecto porque vuelves loco a los buscadores.

Y esto me lleva al tema de la eficiencia. Está bien hacer las cosas, pero es mejor hacer las cosas perfectas. Y si a eso le sumamos la simplicidad, tenemos lo que hacemos en Kisslab. De ahí tener un equipo ninja, equipo en el que, a la hora de desarrollar, me incluyo. Y es que hay que ser resolutivos. Frente a una situación desagradable hay que poner un poco de cabeza, buscar la manera más simple de solventarla y solventarla, y, por experiencia, lo mejor en un sitio web es el spaghetti-ninja, un monstruo que llega y arraza por donde paza.

Sé que lo que voy a decir puede sonar muy nazi, pero a los programadores, por norma general, no hay que dejarlos pensar, hay que dejarlos programar. Para pensar ya hay otras cabezas que son las que en determinados proyectos tienen un medio-largo plazo y a veces piden a los programadores cosas con cierta visión. Esto no significa que un programador sólo tenga que picar teclas, porque hay otros proyectos donde se puede hacer pajas mentales y que salga lo que salga… eso sí, luego suelen llegar llorando porque el SEO y WPO no acaban de irles bien. Suelen usar tecnologías que sólo usan ellos (y que por supuesto no saben escalar cuando eso se va de madre), las últimas versiones de sus lenguajes de programación favoritos (y porque son conscientes de que las versiones alpha pueden fallar, que sino te las cuelan) y lo mismo con usar bases de datos no-relacionales. Es todo muy bonito en su cabeza, pero en la realidad de Internet eso no funciona.

Y en este sentido puedo decir que tengo un equipo que no me lo merezco. Seguramente Jaume puede opinar mucho más que ha tenido entre manos a decenas de personas de estos ámbitos y en vista a los proyectos (propios) que tenemos he de decir que a veces me dan ganas de mandar de vacaciones a parte del equipo porque cuando tienen claro lo que hay que hacer, lo hacen rápido y bien, y eso no tiene precio.

Bueno, ahora ya podéis venir a abroncarme, aunque no vais a conseguir hacer cambiarme de opinión.

Google, publicidad y adservers

Ayer fue un día dramático en Grupo ITnet (como en muchos otros sitios de la Internet española) ya que tuvimos un problema porque a Google se le antojó que la mitad de las webs estaban infectadas (como los programadores errantes).

La situación es la siguiente: te llaman a las 8 de la mañana diciendo que una de las webs, cuando entras, aparece un mensaje en rojo diciendo que la web es peligrosa. Primera acción: comprobarlo (que me lo creo, pero quiero que mis ojos lo vean). Segunda acción: entrar en Google Webmaster Tools y comprobar que no era el único sitio en el que ocurría esto. Entre los sitios estaba también JocJuegos sitio que desde hace unas semanas vuelvo a gestionar parcialmente yo.

La situación era que al entrar en la sección de Salud del panel me salía una alerta diciendo que el “malware” se encontraba en nuestro adserver (en este caso SmartAdserver). Primera solución rápida: eliminar la publicidad del sitio y solicitar una reinclusión. ¡Muerto el perro, se acabó la rabia!

El resto de día fue bastante estresante. Lo primero que hice al llegar a la oficina fue hablar con la gente de SmartAdserver, que no acababan de entender nada, por lo que les puse en antecedentes y les mandé cierta información sobre lo que era. Como era de esperar “no era culpa suya” (ni yo les estaba diciendo que lo fuera) pero al verse afectado su dominio hacía que afectasen a muchas de las páginas que usaban su publicidad.

El resto del día fue muy burocrático y a la vez muy estresante, ya que al fin y al cabo las páginas que tienen esos códigos de publicidad en general viven de eso, de la publicidad, por lo que si la web no funcionaba (porque al entrar en ellas saltaba el mensaje de sitio peligroso) o estaban sin anuncios, a final de mes no comemos.

Ayer acabó siendo un día de esos que “molan” por la parte de tener un subidón de adrenalina por ir contra reloj en casi todo, y de los días más estresantes que he tenido en los últimos años.

Esta mañana revisando el correo la gente de SmartAdserver y tras hablar con Google, han confirmado lo que yo ya sabía: que había alguna campaña de publicidad que estaba infectada (por lo que parece ha sido una empresa española bastante importante y conocida) y que no era culpa suya, pero como afectaba a su dominio se han visto salpicados por el asunto. Por su parte dicen que van a tomar medidas y van a aplicar un protocolo por si se diera de nuevo el caso.

Por mi parte también he creado un protocolo de actuación principalmente dentro de las empresas que hay en la oficina y que supongo que acabarán extendiéndose a otros proyectos y sitios… Comenzando por aislar el dominio del adserver y teniendo un plan B en caso de que algo similar ocurra de nuevo, que permita corregir la situación en un tiempo menor (de 2-4 horas y no de cerca de 12-24).

La cuestión que me queda es que Google está llegando a unos extremos un poco extraños, ya que la cadena de perjudicados en este asunto es demasiado amplia, la forma de penalizar los sitios muy rápida y la solución muy compleja. Entiendo que hagan eso de pedir perdón antes que pedir permiso, pero podrían dar al menos unas horas de margen para poder corregir los problemas y no tomar decisiones unilaterales (ya que su aviso acabó en un montón de sitios de información de malware y todos los sitios afectados están perdiendo cierta cantidad de tráfico que será complicado recuperar a corto plazo).

Desarrolladores vs. Administradores de Sistemas

Como algunos ya sabéis yo de formación soy Administrador de Sistemas, aunque en general estos últimos 10 años me he dedicado principalmente a desarrollar. Pero estos últimos meses (principalmente desde principios de año) estoy dedicando la mayor parte del tiempo a dirigir y organizar proyectos y, sobre todo, a ejercer de SysAdmin. Como decía, había tenido ya experiencia en combinar ambas historias, pero en general la parte de sistemas siempre venía respaldada por alguien y yo “intentaba mirar” en vez de trabajar.

Ahora eso ha cambiado y me ha llevado a plantearme estos dos estilos de vida conjuntamente y por separado. Y es que he de decir que, aunque sea un trabajo algo más duro el de Administrador de Sistemas, no cabe duda que en general la satisfacción personal es mucho mayor.

La cuestión es que en el día a día, el desarrollador suele encontrarse puntos de dificultad pero que creo que son relativa. Una cosa clara, hablo de desarrollador y no de maquetador, que es otra historia (esto sí que hace ya un par de años que intento no tocar ni una línea de código). Volviendo al tema, desarrollar, hoy en día es muy sencillo. Que conste que yo sigo programando con el Notepad++ y sin frameworks ni mierdas varias de esas. Podemos discutirlo, por ahora siempre he ganado yo; los frameworks se supone que te han de aliviar el trabajo pero, cuando luego voy a pedirles algo a los desarrolladores que hagan un cambio se vislumbra el drama porque “eso lo hace el framework así y tocarlo es complicado”. No, no es complicado, simplemente sobrecargas la función, o creas una función nueva y se acabó, porque si te digo que eso ha de ser así (por SEO, por WPO, por eficiencia o por lo que sea, es así). También he de reconocer que en general desarrollar depende de cada uno. Cuando pasan años y veo algún trozo de código que he hecho yo lo reconozco al momento. Supongo que mi código tiene mi firma. Para acabar, también creo que la parte de desarrollo, aunque siempre hay alguien presionando por “las fechas” es algo que puede llegar a ser muy laxo, porque simplemente cuando vas a comenzar el desarrollo, te sobras con unas cuantas semanas de más y tan a gusto.

En cambio la administración de sistemas es bastante distinta. En general hay dos tipos de actuaciones: el “ha petado todo” y el “hay que actualizar”. En general las dos situaciones son bastante mierdas. Cuando falla algo, normalmente hay que arreglarlo “para ya”. Esto implica unos niveles de estrés bastante duros ya que sueles tener a moscas cojoneras molestando y revoloteando a tu alrededor. Por desgracia la gente no parece percatarse de que en la mayoría de los casos cuando algo falla tú ya te has dado cuenta porque te han llegado 10 correos avisando de que nosequé está fallando.

La otra situación, la de los mantenimientos tiene su parte positiva y su parte negativa. La positiva es el I+D. La evolución en la parte de la programación suele producirse cada unos pocos años y los saltos no son muy grandes (yo podría programar con lo mismo que aprendí en 2001) pero en cambio la parte de infraestructura suele ser distinta. Las máquinas van evolucionando cada poco tiempo (cada 6 meses suele haber servidores más potentes) y hay que ir adaptando el software al hardware para sacar el máximo provecho.

Por poner un ejemplo, en estos dos últimos meses que he podido ponerme un poco más a fondo con Varnish creo que he hecho hasta 5 versiones nuevas de la configuración. A veces es un simple cambio de una cifra, otras veces es añadir una funcionalidad completamente nueva, pero en cualquier caso pueden llegar a ser varias horas (o días) dedicados a intentar rascar un poco de aquí y de allá para que todo funcione mejor. Yo no conozco a muchos programadores que tras acabar un proyecto vuelvan a abrir el programa y se revisen el código en busca de mejoras (y que conste que me incluyo, aunque sí que de tanto en tanto me pongo a revisar código para optimizarlo de alguna manera).

Sé que muchos lusers #BOFH no van a entender la mitad de lo que digo (ni falta que hace) pero creo que necesitaba desahogarme un poco después de unos días en los que entre unos (desarrolladores) y otros (administradores) están acabando conmigo…

Servidores DNS públicos

No es la primera vez que hablo de las DNS, aunque en este caso no voy a hablar de los NS de nuestros sitios web, sino de los que usamos en nuestro ordenador… las que utilizamos para resolver los sitios web desde nuestra conexión de casa. Y es que cada vez más los servidores que habitualmente usamos en casa sólo funcionan en las conexiones de casa (es decir, cada operador limita las peticiones a su propia conectividad) ha llevado a que existan servidores DNS públicos que ofrecen servicios añadidos interesantes.

Quizá uno de los servidores DNS abiertos más conocidos sea el de Google Public DNS que nos ofrece las direcciones:

  • 8.8.8.8
  • 8.8.4.4

Y también las ofrece para IPv6:

  • 2001:4860:4860::8888
  • 2001:4860:4860::8844

Personalmente los servidores de Google no me acaban de convencer… mi experiencia con ellos no se puede decir que haya sido la mejor hasta el momento, pero por sus números fáciles de recordar siempre te sacan de un apuro cuando no sabes qué utilizar. Últimamente estoy usando los servidores de OpenDNS:

  • 208.67.222.222
  • 208.67.220.220

Estos también tienen direcciones DNS para IPv6:

  • 2620:0:ccc::2
  • 2620:0:ccd::2

Lo interesante de este servicio es que si te registras, de forma gratuita, y te instalas el programita que hay puedes entrar en un panel y mirar las peticiones que haces y tienes ciertas estadísticas que pueden ser bastante curiosas… Además, en los casos en los que hay phishing y demás, el sistema lleva alertas de seguridad para que no funcionen, lo que sirve también como una especie de “antivirus de DNS”.

A parte de estos dos servicios también hay otros. Por ejemplo los siguientes:

SmartViper:

  • 208.76.50.50
  • 208.76.51.51

DNS Reactor:

  • 204.45.18.18
  • 204.45.18.26

Comodo Secure DNS:

  • 8.26.56.26
  • 156.154.70.22

DNS Advantage:

  • 156.154.70.1
  • 156.154.71.1

Norton DNS aquí nos encontramos con 3 niveles de seguridad dependiendo de lo que quieras filtrar o no.

Simplemente seguridad (phishing, malware…)

  • 198.153.192.40
  • 198.153.194.40

Seguridad y pornografía:

  • 198.153.192.50
  • 198.153.194.50

Seguridad, pornografía y “no familiar”:

  • 198.153.192.60
  • 198.153.194.60

Scrub IT:

  • 67.138.54.100
  • 207.225.209.66

También tenemos las DNS de Verizon/Level 3 que aunque no hay una web oficial (si alguien la encuentra que me la pase) da una lista de algunas IP muy sencillas de recordar pero que en este caso vuelven a depender de una operadora…

  • 4.2.2.1
  • 4.2.2.2
  • 4.2.2.3
  • 4.2.2.4
  • 4.2.2.5
  • 4.2.2.6

Finalmente encontramos una serie de servidores de OpenNic que actualmente ronda los 70 servidores y que en general son servidores anónimos que no hacen log de las peticiones distribuidos por distintas partes del mundo.

Una forma de probar cuáles son los mejores servidores DNS para nuestro ordenador (dependiendo de la conexión que tengamos, localización y demás) podemos usar la herramienta namebench (Open-source DNS Benchmark Utility) o Domain Name Speed Benchmark. Haciendo una prueba desde un ADSL de Telefónica en Barcelona, los resultados son (top-5):

  • 156.154.70.1 (DNS Advantage)
  • 198.153.194.60 (Norton DNS)
  • 8.8.8.8 (Google DNS)
  • 156.154.70.22 (Comodo Secure DNS)
  • 8.8.4.4 (Google DNS)

Final benchmark results, sorted by nameserver performance:
 (average cached name retrieval speed, fastest to slowest)

  156.154. 70.  1 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,068 | 0,070 | 0,073 | 0,001 | 100,0 |
  - Uncached Name | 0,069 | 0,160 | 0,416 | 0,101 | 100,0 |
  - DotCom Lookup | 0,069 | 0,096 | 0,175 | 0,030 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
                   rdns1.ultradns.net
                         NeuStar

  198.153.194. 60 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,071 | 0,073 | 0,077 | 0,001 | 100,0 |
  - Uncached Name | 0,072 | 0,162 | 0,414 | 0,104 |  98,0 |
  - DotCom Lookup | 0,075 | 0,139 | 0,196 | 0,034 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                  SYMANTEC CORPORATION

    8.  8.  8.  8 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,072 | 0,074 | 0,076 | 0,001 | 100,0 |
  - Uncached Name | 0,075 | 0,161 | 0,422 | 0,099 | 100,0 |
  - DotCom Lookup | 0,082 | 0,114 | 0,235 | 0,044 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
             google-public-dns-a.google.com
                   Google Incorporated

  156.154. 70. 22 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,072 | 0,074 | 0,077 | 0,001 | 100,0 |
  - Uncached Name | 0,074 | 0,163 | 0,530 | 0,103 | 100,0 |
  - DotCom Lookup | 0,074 | 0,125 | 0,183 | 0,042 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                         NEUSTAR

    8.  8.  4.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,073 | 0,075 | 0,083 | 0,002 | 100,0 |
  - Uncached Name | 0,077 | 0,164 | 0,661 | 0,116 | 100,0 |
  - DotCom Lookup | 0,082 | 0,105 | 0,165 | 0,025 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
             google-public-dns-b.google.com
                 Level 3 Communications

    4.  2.  2.  6 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,076 | 0,078 | 0,087 | 0,002 | 100,0 |
  - Uncached Name | 0,078 | 0,151 | 0,577 | 0,107 | 100,0 |
  - DotCom Lookup | 0,080 | 0,096 | 0,204 | 0,026 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                 Level 3 Communications

  156.154. 71.  1 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,077 | 0,078 | 0,082 | 0,001 | 100,0 |
  - Uncached Name | 0,078 | 0,156 | 0,520 | 0,108 | 100,0 |
  - DotCom Lookup | 0,080 | 0,128 | 0,202 | 0,041 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
                   rdns2.ultradns.net
                         NEUSTAR

  198.153.194. 40 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,077 | 0,078 | 0,081 | 0,001 | 100,0 |
  - Uncached Name | 0,077 | 0,158 | 0,476 | 0,101 | 100,0 |
  - DotCom Lookup | 0,078 | 0,125 | 0,211 | 0,042 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                  SYMANTEC CORPORATION

    4.  2.  2.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,075 | 0,078 | 0,089 | 0,002 | 100,0 |
  - Uncached Name | 0,077 | 0,191 | 0,541 | 0,126 | 100,0 |
  - DotCom Lookup | 0,076 | 0,219 | 0,369 | 0,095 |  98,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                 Level 3 Communications

    4.  2.  2.  3 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,079 | 0,081 | 0,084 | 0,001 | 100,0 |
  - Uncached Name | 0,079 | 0,144 | 0,411 | 0,090 | 100,0 |
  - DotCom Lookup | 0,080 | 0,183 | 0,336 | 0,096 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
                  vnsc-lc.sys.gtei.net
                 Level 3 Communications

  198.153.194. 50 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,080 | 0,082 | 0,084 | 0,001 | 100,0 |
  - Uncached Name | 0,081 | 0,165 | 0,447 | 0,099 | 100,0 |
  - DotCom Lookup | 0,082 | 0,136 | 0,221 | 0,043 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                  SYMANTEC CORPORATION

  208. 67.220.220 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0,080 | 0,082 | 0,084 | 0,001 | 100,0 |
  + Uncached Name | 0,081 | 0,165 | 0,397 | 0,090 | 100,0 |
  + DotCom Lookup | 0,086 | 0,168 | 0,254 | 0,056 | 100,0 |
  ------+-------+-------+-------+-------+-------+
                  resolver2.opendns.com
                      OpenDNS, LLC

  198.153.192. 60 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,080 | 0,082 | 0,094 | 0,002 | 100,0 |
  - Uncached Name | 0,081 | 0,166 | 0,420 | 0,100 | 100,0 |
  - DotCom Lookup | 0,085 | 0,147 | 0,210 | 0,043 |  98,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                  SYMANTEC CORPORATION

  208. 67.222.222 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0,080 | 0,082 | 0,086 | 0,001 | 100,0 |
  + Uncached Name | 0,082 | 0,177 | 0,467 | 0,108 | 100,0 |
  + DotCom Lookup | 0,084 | 0,164 | 0,271 | 0,059 | 100,0 |
  ------+-------+-------+-------+-------+-------+
                  resolver1.opendns.com
                      OpenDNS, LLC

    8. 26. 56. 26 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,076 | 0,082 | 0,195 | 0,017 | 100,0 |
  - Uncached Name | 0,078 | 0,234 | 0,953 | 0,206 | 100,0 |
  - DotCom Lookup | 0,086 | 0,126 | 0,187 | 0,034 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
                  ns1.recursive.dns.com
                 Level 3 Communications

  198.153.192. 40 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,081 | 0,083 | 0,087 | 0,001 | 100,0 |
  - Uncached Name | 0,082 | 0,170 | 0,482 | 0,104 | 100,0 |
  - DotCom Lookup | 0,084 | 0,152 | 0,194 | 0,035 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                  SYMANTEC CORPORATION

    4.  2.  2.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,084 | 0,086 | 0,089 | 0,001 | 100,0 |
  - Uncached Name | 0,086 | 0,151 | 0,449 | 0,092 | 100,0 |
  - DotCom Lookup | 0,095 | 0,132 | 0,332 | 0,056 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                 Level 3 Communications

  198.153.192. 50 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,085 | 0,087 | 0,089 | 0,001 | 100,0 |
  - Uncached Name | 0,086 | 0,172 | 0,482 | 0,099 | 100,0 |
  - DotCom Lookup | 0,086 | 0,127 | 0,211 | 0,040 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                  SYMANTEC CORPORATION

    4.  2.  2.  1 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,080 | 0,150 | 0,263 | 0,064 | 100,0 |
  - Uncached Name | 0,091 | 0,366 | 1,470 | 0,256 |  96,0 |
  - DotCom Lookup | 0,168 | 0,390 | 0,844 | 0,170 |  97,9 |
  ---< -------->---+-------+-------+-------+-------+-------+
                  vnsc-pri.sys.gtei.net
                 Level 3 Communications

  204. 45. 18. 18 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,194 | 0,209 | 0,322 | 0,030 | 100,0 |
  - Uncached Name | 0,219 | 0,276 | 0,593 | 0,066 |  98,0 |
  - DotCom Lookup | 0,220 | 0,228 | 0,271 | 0,012 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
                 smtp18.cleargateway.net
                     FDCservers.net

  204. 45. 18. 26 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,191 | 0,231 | 0,575 | 0,076 | 100,0 |
  - Uncached Name | 0,214 | 0,275 | 0,519 | 0,063 | 100,0 |
  - DotCom Lookup | 0,217 | 0,233 | 0,280 | 0,016 | 100,0 |
  ---< -------->---+-------+-------+-------+-------+-------+
                 smtp26.cleargateway.net
               FDCSERVERS - FDCservers.net

    4.  2.  2.  2 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0,152 | 0,243 | 0,326 | 0,044 |  89,4 |
  - Uncached Name | 0,181 | 0,512 | 1,333 | 0,328 |  90,5 |
  - DotCom Lookup | 0,165 | 0,639 | 1,208 | 0,318 |  86,8 |
  ---< -------->---+-------+-------+-------+-------+-------+
                  vnsc-bak.sys.gtei.net
                 Level 3 Communications

   67.138. 54.100 | DNS queries are not answered at this IP.
  ---< -------->---+-------+-------+-------+-------+-------+
          ··· no official Internet DNS name ···
                 NSI Communications, LLC

  207.225.209. 66 | DNS queries are not answered at this IP.
  ---< -------->---+-------+-------+-------+-------+-------+
              207-225-209-066.scrubdns.com
                  Qwest Communications

  208. 76. 50. 50 | The DNS server at this IP address does
  not provide domain name service answering client queries.
  It should not be used for normal client-based resolution.
  ---< -------->---+-------+-------+-------+-------+-------+
               ip-50.50.76.208.datasub.com
                Gold Star Advantage, LLC.

  208. 76. 51. 51 | The DNS server at this IP address does
  not provide domain name service answering client queries.
  It should not be used for normal client-based resolution.
  ---< -------->---+-------+-------+-------+-------+-------+
               ip-51.51.76.208.datasub.com
                Gold Star Advantage, LLC.

  UTC: 2012-05-30, from 17:14:11 to 17:15:58, for 01:47,538

Splunk Live 2012 Barcelona

Esta mañana he podido asistir al primer evento oficial de Splunk en España, de la mano de OpenS3 en Barcelona y como me ha parecido interesante algunas de las cosas que se han comentado, os las dejo.

Splunk comenzó en 2004 en San Francisco y tiene más de 400 empleados en 8 países. Las principales oficinas están en Hong Kong y Londres. Tienen más de 3500 clientes de 70 países, de los cuales 48 están en el Fortune 100.

Hay muchos casos en los que Splunk está analizando más de 10 TB diarios de información. Algunas empresas como Facebook, eBay, Linkedin, Sony, BBC, Symantec y otros están utilizando esta herramienta. Con sistemas similares a MapReduce no hay limitación en cuanto a la escalabilidad de la plataforma. Cisco además de ser un cliente es un partner en cuanto en algunos casos integran en sus sistemas Splunk. Según Cisco, Splunk es el único software capaz de interpretar cualquiera de los logs que se generan en las máquinas de Cisco, y no como en otros casos que tienen muchos pequeños productos que leen una parte de la información.

Splunk además es una gran herramienta de seguridad, ya que es pro activa en analizar comportamiento extraños en los logs. Por ejemplo, si estás recibiendo un ataque desde una serie de direcciones rusas, sería capaz de detectar qué máquina o qué servicio es el que está enviando o recibiendo esta información. A parte de logs, es capaz de recibir información de bases de datos, GPS, registros de sistema, cualquier elemento que se pueda concebir como “datos IT”. Esta información, además de ser útil para los técnicos, puede ser útil para marketing o seguridad.

Otra de las funcionalidades interesantes de Splunk es la posibilidad de ser utilizado como sistema de Web Analytics, aunque es una pequeña parte del sistema, es capaz de analizar cualquiera de los elementos: páginas, vídeos, imágenes…

Splunk se divide en 3 partes: Collectors, Indexers y Search Heads (que es la web donde se ve la información). Se puede escalar horizontalmente, tienen alta disponibilidad y podría recoger unos 25 GB diarios. Cada máquina podría ser un quad-core con 8GB de RAM. El despliegue es bastante rápido y es capaz de usarse independientemente de cada lugar. Los Indexer pueden estar geolocalizados y el Search Head cercano a donde los usuarios lo van a utilizar.

El sistema es capaz de interpretar expresiones regulares para los distintos elementos que pueden encontrarse en los logs, de forma que es capaz de interpretar cualquier tipo de fichero. Es capaz de monitorizar el sistema de ficheros, registros del sistema operativo, control de hypervisores de máquinas virtuales, aplicaciones web, tablas o esquemas en bases de datos, configuraciones de red…

Splunk aparece como base como un buscador al estilo de Google en el que puedes realizar cualquier tipo de datos (buscar una IP, una dirección URL…) además de permitir generar informes personalizados en base a la información recogida. Además se puede hacer seguimiento de transacciones. Un ejemplo podría ser que un sitio web genere un identificador de una venta, se cruzan datos con que se haya enviado un correo avisando de la venta al usuario, y finalmente que el paquete (logística) se haya enviado.

Splunk tiene un sistema de geolocalización de direcciones IP, de forma que se podría analizar de una forma muy sencilla y mostrar o geolocalizar las visitas con mucho detalle (dependiendo incluso de qué sea, con datos de coordenadas GPS).

Existe un repositorio de paneles ya creados que analizan directamente los logs o datos. Muchas de estas extensiones están realizados directamente por la gente de Splunk aunque hay una gran comunidad detrás generando estos paneles.