Consultas WMI desde Linux

Ya llevo tiempo trabajando con la herramienta Nagios WSC que me permite monitorizar en Nagios los equipos Windows, sin desarrollar los incómodos scripts en Windows e invocarlos del port NRPE que existe para ellos, gracias a WMI. En los servidores Nagios, desarrollo unos pequeños scripts, que invocan las URLs del Web Service de Nagios-WSC que publico en IIS en un servidor Windows (habitualmente llamo a estos equipos Wagios), y transforman la salida del servicio web para al final tener una respuesta válida interpretable por Nagios.

Esta mañana me he planteado solucionar la monitorización de los clusters Microsoft a través de WMI. Para investigar que consulta realizar y qué clases consultar, siempre utilizo WMI Explorer, una pequeña utilidad Windows, que sin necesidad de instalar mucha cosa, me permite navegar por las clases. Para ello, lo primero que hay que hacer es tener claro el namespace que tenemos que consultar, y NameSpaces hay varios: root\aspnet, root\CIMV2, root\Cli, root\DEFAULT, root\directory, root\Microsoft, root\MicrosoftActiveDirectory, root\MicrosoftIISv2, root\MicrosoftNLB, root\MSCluster, root\perfmon, root\Policy, root\RSOP, root\SECURITY, root\subscription, root\WMI. Si no se tiene ni idea de WMI, como yo, se tarda un rato en descubrirlo :).

El NameSpace que aparece siempre seleccionado por defecto, y en que el que se basan la mayoría de ejemplos es root\cimv2, pero el que a mí interesaba era root\MSCluster. He realizado varias consultas y al final he comprobado que la clase que tenía los datos que me interesaban consultar era MSCluster_NodeToActiveGroup. Cuando he ido a Nagios WSC para cambiar el namespace, me he encontrado que no era posible, o yo no he sabido encontrar la forma de poder cambiarlo.

He empezado a buscar clientes para Linux (con idea de usarlos desde el propio servidor Nagios, en vez de usar el equipo intermediario Windows, wagios), y me he encontrado que tog-pegassus incorpora el comando wbemexec, pero después de leerme el manual tampoco he sabido construir un fichero XML con una petición que me funcionara, lo más cerca que he estado ha sido tener un fichero peticion.xml con este contenido,

<?xml version="1.0" ?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="51000" PROTOCOLVERSION="1.0">
<SIMPLEREQ>
<IMETHODCALL NAME="EnumerateInstances">
<LOCALNAMESPACEPATH>
<NAMESPACE NAME="root"/>
<NAMESPACE NAME="MSCluster"/>
</LOCALNAMESPACEPATH>
<IPARAMVALUE NAME="PartComponent">
<CLASSNAME NAME="MSCluster_NodeToActiveGroup"/>
</IPARAMVALUE>
</IMETHODCALL>
</SIMPLEREQ>
</MESSAGE>
</CIM>
y luego ejecutar:
wbemexec -h vip-cluster -p 5989 -u 'DOM\\user' -w contraseña peticion.xml
wbemexec: Unable to use requested input file: file does not exist
pero no me ha funcionado :(. Al final he encontrado este otro cliente WMI, SBLIM (pronunciado "sublime"), que me permite ejecutar:
wbemcli ein -nl -noverify 'https://DOM\user:contraseña@vip-cluster:5989/root/MSCluster:MSCluster_NodeToActiveGroup'
y que sí funciona al pelo.

Gnokii: ¿qué significa un "+CMS:500"?

Cuando trabajamos con Gnokii, a menudo obtenemos códigos de error +CMS:500, +CMS:38, etc. Podemos encontrar un relación detallada de los códigos de error en el blog: http://blog.nowsms.com/2008/07/gsm-modem-cms-error-code-list.html, y el listado todos en http://www.activexperts.com/activsms/sms/gsmerrorcodes/.

De Apache FOP 0.20.5 a 0.94 (parte I)

Esta tarde he estado probando Apache FOP 0.94 con mis documentos XML, FO, XSL, etc, que hasta ahora no había tenido mucho tiempo. Las impresiones que puedo sacar con un primer vistazo son las siguientes:

  1. Con el nuevo FOP tendré que retocar los márgenes y distancias. Me consta que han mejorado el soporte para tablas, borders y dimensiones, y han implementado algunos atributos de XSL:FO que aún no estaban soportados en las versiones 0.20.X, por lo que me va a tocar revisar mis plantillas, para quitar todos los inventos que tenía que hacer para colocar el texto donde quería, mediante tablas.
  2. Las tablas ya no permiten elementos <fo:table-cell></fo:table-cell>, por lo que toca sustituirlas por <fo:table-cell><fo:block/></fo:table-cell>.
  3. Las imágenes no se redimensionan automáticamente para ajustar en la página, cuando no se tenemos valor para los atributos width y/o height. Para conseguirlo, debemos indicar width="100%" content-width="scale-to-fit" content-height="100%". Hay ejemplos en images.fo dentro del directorio examples/fo/basic/ de la distribución.

Seguiremos probando. Lo siguiente que quiero hacer es incluir mis propios tipos de fuentes, y rediseñar los formatos de las páginas.

Repositorios YUM personalizados en RHEL4 ( y RHEL5 y RHEL3)

Para tener yum en RHEL4, lo primero que necesitas es instalar los siguientes paquetes: python-elementtree, python-sqlite, python-urlgrabber, sqlite y yum

... y los podrás encontrar en la página:
http://rpmfind.net/linux/RPM/Dag_Apt_Repository_for_Red_Hat_Enterprise_Linux_4.html

... hay que tener paciencia a que termine de cargar que es muy grande. Las versiones que yo estoy usando en RHEL4, en todos los Updates hasta en el 6, y de momento no me ha dado ningún problema, que yo sepa, son:

   python-elementtree-1.2.6-7.el4.rf.i386.rpm
python-sqlite-0.5.0-1.2.el4.rf.i386.rpm
python-urlgrabber-2.9.7-1.2.el4.rf.noarch.rpm
sqlite-2.8.17-1.el4.rf.i386.rpm
yum-2.4.2-0.4.el4.rf.noarch.rpm
Las dependencias de estos paquetes (si tuvieran) las instalo desde la distribución oficial de RHEL4 que esté usando, poniendo el contenido de los CDs accesible vía NFS. Instalando todo esto tendremos el comando "yum" en nuestro equipo RHEL4 donde ya podremos configurar los repositorios que nos interese, igual que si estuviéramos en RHEL5: /etc/yum.conf y/o /etc/yum.repos.d/. A efectos practicos, llamaremos a todas estas máquinas hostclient.

Para publicar nuestro repositorio de paquetes, además necesitaremos el comando "createrepo", en al menos una máquina RHEL4 con el que poder crear la estructura del repositorio, por lo que habrá que descargar también el paquete: createrepo (yo uso: createrepo-0.4.4-1.noarch.rpm). A efectos prácticos, llamaremos a esta máquina configurator.

Luego tendremos que disponer de una máquina con el servidor Web o FTP configurado y con espacio suficiente, como para ir dejando ahí todos los paquetes que conformarán nuestros diferentes repositorios. Si este equipo es diferente de la máquina configurator, necesitaremos tambien que esta pueda montar por NFS los directorios donde tengamos los repositorios de paquetes, y así poder ejecutar el comando createrepo. A efectos prácticos, llamaremos a este equipo reposerver.

Imaginar que en el reposerver queremos publicar varias distribuciones:
- RHEL4U6, en el directorio /opt/repos/RHEL4U6
- RHEL4U5, en el directorio /opt/repos/RHEL4U5
- RHEL4U1, en el directorio /opt/repos/RHEL4U1

Crear estos directorios en reposerver y copiar el contenido de todos los CDs o DVDs (sobreescribiendo si hubiera conflictos) en ellos, de manera que los directorios con los RPMS de RHEL4U1 (por ejemplo) quedarán en /opt/repos/RHEL4U1/RedHat/RPMS. El hacerlo así, es porque también podremos usar scripts personalizados de anaconda para instalar las distribuciones, dejando los paquetes vía http.

En reposerver, debemos exportar por NFS el directorio /opt/repos para que configurator pueda escribir. Una vez en configurator, montaremos el directorio NFS (mount -t nfs reposerver:/opt/repos /mnt/reposerver) y ejecutaremos:
 cd /mnt/reposerver
for i in RHEL4*
do
cd /mnt/reposerver/$i/RedHat/RPMS
createrepo .
done
sync
cd
umount /mnt/reposerver
Con esto, deberíamos tener directorios repodata dentro de cada /opt/repos/RHEL*/RedHat/RPMS/.
De nuevo sobre la máquina reposerver, crearemos el siguiente enlace simbólico:
ln -s  /opt/repos/RHEL4U6  /opt/repos/RHEL4-ultima
Configurar Apache para que podamos navegar por los subdirectorios de /opt/repos desde nuestra red sin problemas, y que se sigan los enlaces simbólicos, de manera que si desde nuestro navegador accedemos a http://reposerver/repos/RHEL4-ultima/ ... veamos los mismos archivos que si lo hacemos en la URL http://reposerver/repos/RHEL4U6/


Una vez hecho esto, ya podemos acceder a cualquiera de las máquinas "hostclient". Supongamos que lo hacemos a una máquina RHEL4U1. Editaremos /etc/yum.conf (o crear un fichero /etc/yum.repos.d/) y añadiremos el siguiente contenido:

[base]
name=RedHat 4 Update 1
baseurl=http://reposerver/repos/RHEL4U1/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

Para una máquina RHEL4U5, escribiremos...

[base]
name=RedHat 4 Update 5
baseurl=http://reposerver/repos/RHEL4U5/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

... y un hostclient con RHEL4U6:

[base]
name=RedHat 4 Update 6
baseurl=http://reposerver/repos/RHEL4U6/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

Una vez hemos editado el fichero de los repositorios, guardaremos los cambios, y ejecutaremos "yum update", para que se refresquen la lista de nuestros repositorios. En teoría, no debería pedirnos actualizar nada, porque solo hemos dejado visible el repositorio de paquetes el repositorio de paquetes de nuestra distribución. Esto nos permite, que cuando tenemos que instalar cualquier paquete de la distribución, en vez de andar como locos poniendo y quitando CDs, y de vueltas con el comando "rpm -ivh, rpm -Uvh", lo hagamos directoramente con "yum install", lo cual ya es una comidad, porque yum resolverá las dependencias e instalará los paquetes que le digamos.

En un momento dado, nos puede interesar actualizar los hostclient a la última distribución que tengamos publicada (RHEL4-ultima), por lo que en ese momento, tendremos que editar el fichero de yum.conf y descomentar la sección:

[updates-released]
name=RedHat 4 Updates
baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

y luego ejecutar "yum -y update", lo cual provocará que nuestra distribución quede completamente actualizada.

Esto muchas veces no es posible hacerlo, porque generaría conflicto con el aplicativo que tengamos en el servidor ( Oracle, SAP, BEA, etc) y romperíamos la matriz de certificación. Para estos casos, tendremos dos alternativas:

1. Usar el parametro "exclude=" en /etc/yum.conf, y evitar que se actualicen los paquetes conflictivos, que nos romperían la matriz de compatibilidad:

[updates-released]
name=RedHat 4 Updates
baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/
exclude=kernel,glibc

2. Tener un directorio especial en reposerver, donde vamos colocando los paquetes que sólo queremos actualizar, por ejemplo /opt/repos/RHEL4-especial. Cada vez que copiemos ahí un archivo tendremos que ejecutar createrepo desde el configurator, y luego en los hostclients tendremos que tener un repositorio, con esta pinta más o menos:

[updates-especial]
name=RedHat 4 Updates Especial
baseurl=http://reposerver/repos/RHEL4-especial/


Este último mecanismo, podríamos usarlo para tener una máquina registrada en RHN configurada, para desacargarse todas las actualizaciones que publiquen en RedHat-Network, y copiarlas desde /var/spool/up2date/ a este directorio. Esto sería una forma de mantener completamente actualizados nuestros equipos, habiendo registrado sólo uno, aunque debo reconocer que nunca lo he probado y no se si funcionará.

Lo que últimamente sí estoy probando es a disponer en un repositorio de yum todos los scripts, personalizaciones, y scripts de administración que desarrollo de manera personaliza para mis clientes: Por ejemplo, los scripts de monitorización de Nagios, o los scripts de backup del sistema. Todos estos scripts, ficheros, etc, los desarrollo bajo un control de versiones basado en Subversion y les preparo con ant, reglas para construir un RPM, que tras construirlo coloco directamente en ese directorio especial. Luego a cada servidor, le programo un "yum -y update" nocturno/semanal y mantengo completamente actualizada la infraestructura, sin necesidad de ir servidor por servidor.

Esto tiene otra ventaja. Ultimamente los servicios de informática para los que trabajo, están en proceso de certificación en alguna norma de calidad: ISO27000, ISO9000, ITIL, etc. En la mayoría de los sitios, tienen definido de manera bastante nítida, el proceso de desarrollo de aplicaciones, o correcciones de las aplicaciones que tienen en producción, y como trabajar con diferentes entornos productivos, lo que habitualmente se conoce como Desarrollo, Pruebas y Producción y el paso y maduración del código en estas plataformas. Trabajar con repositorios yum y control de versiones como he contado, permite convertir los trabajos del departamento de sistemas, como retocar una configuración, desarrollar un script, etc, en casi el trabajo de un programador-analista del departamento de desarrollo, y con ello no tener que definir procesos específicos para la administración de sistemas, lo cual me ayuda a vender mejor mis ideas ;).


Además, el tener los repositorios organizados de esta manera, me permite instalar de forma remota (vía http) los servidores, con ayuda de anaconda. La idea, es instalar un servidor RHEL4 con CDs, de manera atendida de manera que al terminar la instalación nos deje un fichero anaconda-ks.cfg, con todas las opciones que elegimos para la instalación. Luego lo editaremos y nos aseguraremos de incluir las siguientes opciones:
 
url --url http://reposerver/repos/RHEL4U6/
network --device eth0 --bootproto dhcp --hostname unattended-rh4u6

Este fichero anaconda-ks.cfg editado, lo renombro a rh4u6.cfg y lo coloco en un servidor Web (puede valer el mismo reposerver), en un subdirectorio HTTP llamado ks, (/opt/repos/ks/) de forma que podamos acceder con el navegador a http://reposerver/ks/rh4u6.cfg y veamos el fichero que hemos editado.

Luego, para instalar meto el primer de la distribución y cuando estamos ante el prompt de lilo, tecleo:
linux text ks=http://IP_de_reposerver/ks/rhel4u6.cfg

Suelo evitar la resolucion DNS en este punto de la instalación, para ganar velocidad y evitarme problemas. Esta linea esta indicando que queremos instalar en modo texto, y que la secuencia de repuestas para anaconda la encontrará en esa URL.
Este mecanismo de instalación, tiene sus problemas en con RHEL5, porque anaconda usa yum en la instalacion, por lo que cuando hacemos la copia de los CDs a /opt/repos/RHEL5UXX debemos conservar los directorios repodata que vienen con los paquetes en CD, y habilitar el FTP. En el script de instalación de anaconda pondremos:

url --url ftp://reposerver/repos/RHEL5U2/
network --device eth0 --bootproto dhcp --hostname unattended-rh5u2

Para publicar repositorios yum, tendremos la precaución de ejecutar en configurator el comando createrepo sin sobreescribir el directorio repodata que teníamos del CD:

cd /mnt/reposerver
for i in RHEL5*
do
for k in `find /mnt/reposerver/$i -type d -maxdepth 1 `
do
if [ -d $k/RedHat/RPMS ]
then
cd $k/RedHat/RPMS
mv repodata repodata.cd
createrepo .
mv repodata repodata.web
mv repodata.cd repodata
fi
done
done
sync
cd
umount /mnt/reposerver


Luego en Apache, tendremos crear diferentes alias para que la URL
http://reposerver/repos/RHEL5UX/YYYYY/RedHat/RPMS/repodata
apunte a /opt/repos/RHEL5UX/YYYYY/RedHat/RPMS/repodata.web
... donde UX será el Update de nuestra distribución RHEL5, e YYYYY, será el directorio de paquetes: Cluster, cluster-Storage, Server, etc...


Como este planteamiento nos obliga a tener varias máquinas configurator para crear los repositorios de diferentes distribuciones, lo que se puede hacer es usar el reposerver como DOM-0 con XEN, que ejecuta el mismo, el resto de máquinas configurator, las cuales son máquinas virtuales XEN ejecutadas como ya he dicho en el propio reposerver.


Si queremos usar todo esto en RHEL3, es posible, siguiendo las instrucciones de RHEL4, sólo que en los clientes necesitaremos instalar los paquetes: python-urlgrabber y yum, que podremos encontrar en
http://rpmfind.net/linux/RPM/Dag_Apt_Repository_for_Red_Hat_Enterprise_Linux_3.html

Yo uso las versiones: python-urlgrabber-2.9.7-1.1.el3.rf.noarch.rpm y yum-2.0.8-0.1.el3.rf.noarch.rpm, y tampoco me han dado problemas que yo sepa. Las dependencias como siempre, de los paquetes oficiales de la propia RHEL3.
Luego se hace todo de la misma forma que antes, pero en vez de usar el comando "createrepo ." se usará "yum-arch .", y no creará directorios "repodata" sino "headers".

¿Cuántos Watios consume mi CPD?

Ayer tuve quehacer una estimación de consumo eléctrico para un CPD pequeño, donde tenían gran variedad de equipamientos: Dos Racks de servidores, no completos, un clariion, un centera, la electrónica del edificio y la centralita. Este es
el resultado del análisis y por supuesto puede ser totalmente erróneo.

Me he basado en las especificaciones técnicas
de los equipos, porque la cuenta de Wattios=Voltios * Amperios,
disparaba los números, y he decidido ir al fabricante de cada
componente para ver cuánto dice él que consumen sus cacharros.


https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-4VUGY7&brandind=5000008
* (1U) 1 x IBM xSeries 330 => 200W
* (3U) 7 x IBM xSeries 340 (8656-6RY) => 270W



https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-44204&brandind=5000008
* (1U) 4 x IBM xSeries 335 (8676-L1X) => 411W (¿por fuente?)




https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-43694&brandind=5000008
* (2U) 8 x IBM xSeries 345 (8670-Varios) => 514W (¿por fuente?)

https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-56806&brandind=5000008
* (2U) 9 x IBM xSeries 346 (8840-Varios) => 625W (¿por fuente?)


https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-50053&brandind=5000020
* (6U) 1 x IBM BladeCenter (Type 8677) => 5500W


http://www.emc.com/products/detail/hardware/clariion-cx3-model-20.htm
* 1 Clariion CX3-20:
(3U) 2 x 230W (controladoras) => 460W
(3U) Por cada cajon de discos => 425W (maximo nº cajones= 10)




http://h18004.www1.hp.com/products/quickspecs/12028_na/12028_na.HTML
* (2U) 7 x HP Proliant DL380G4 => 575W (¿por fuente?)


Del centera no encuentro nada oficial: artículos y referencias. Parece que ...
2 x 250W (CUA=>1U c/u) => 500W
2 x 250W (Centera=>1U c/u) => 500W
(2U) Supongo cajones igual que clariion=> 425W (maximo nº cajones=15)


Aires acondicionados: La relacion entre Watios y Frigorias es:
* 1 frigoría o caloría = 1.16W
* 1 Watio = 0,86 Figrorías o calorías
* Cada aparato de 3000 Frigorías consume => 3480W
En el CPD de arriba tenemos 4 máquinas de aire no sé de cuanto cada una.



http://www.brocade.com/products/switches/silkworm_200E/index.jsp
* (2U) 2 Switches de fibra (60W c/u) => 120W



http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5023/product_data_sheet0900aecd80371991.html
* (1U) Switches Cisco Catalyst 3750 => 200W (cada uno) como media van desde 190W -> 590W
Tenemos 5 de estos



http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6545/product_data_sheet0900aecd80322aeb.html
* (1U) Switches Cisco Catalyst 500 => 110W
Tenemos 1 de estos.



http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5528/product_data_sheet09186a00801f3d7d.html
* (1U) Switch Cisco Catalyst 3560G => 160W
Tenemos 1 de estos



No encuentro nada oficial para los Cajun P334T (aprox.200W)
* (3U) Cajun P334T => 200W
Tenemos 4 de estos



No encuentro el consumo de la centralita que tenemos que creo es Alcatel NextiraOne, pongamos que consume 1000W.



--- ESTIMACIONES TOTALES --------------


En un CPD como este, donde hay diferentes modelos de
servidores, con fuentes redundantes y sin redundancia, con fuentes que
consumen más, etc... tenemos que hacer medias (suponiendo todas las
fuentes redundantes):


* Servidores de 1U (antiguos) => consumo medio 500W


* Servidores de 2U => consumo medio 1100W ( consumo medio por 1U=>560W)


* Servidores de 3U (muy antiguos) => consumo medio 540W ( consumo medio por 1U=>180W)


* Servidores Blade => consumo medio 5500W ( consumo medio por 1U=>920W)
  +--> Pero suponen un ahorro, porque en 1U no metemos un servidor si no 14.
  * 14 servidores de una 1U modernos pueden consumir 500W * 14 = 7000 y 14U de espacio
  * 14 blades consumen 5500W (390W por equipo, sin contar que incluye al menos un par de switches interno) y solo 6U de espacio.


* La media de consumo por 1U podría estar en torno a los 540W por 1U
de un RACK y los Rack de servidores tienen 42U, por lo que un Rack
lleno de servidores, estaría en torno 22500W de consumo (22,5Kw)


* La media de consumo de un switch de entre 24 y 48 bocas, puede
estar en 160W, y para tener todo cableado se necesitan al menos 10
switches... lo supondría entorno a 1,6Kw para electrónica. Esto es
electrónica sin PoE (Power over Ethernet, que consume casi tres veces
más, y es recomendable para VoIP).


* El almacenamiento en Clariion estaría estando lleno en torno a los 4800W (4,8Kw)


* El almacenamiento en el Centera estaría, estando lleno, en torno a 7000W (7Kw)


* Ahora mismo en todo el CPD hay cuatro máquinas (supongamos de 3000frigorias) para enfriar en total:
= 1600W (electronica) + 2160W (clariion) + 1425W (centera) + 29700W (55Us de servidores) +
+ 1000W (centralita) + 13920W (aire acondionado) = 50000W aproximadamente ...


... por lo tanto 13920/50000= 0,27W aprox. ... esto quiere decir que
por cada Watio de consumo del CPD, necesitamos consumir 0,27W en aire
acondicionado, lo que se traduce en que por cada U de un Rack
necesitamos 145W (125 frigrorias)... por tanto:


TOTALES:
   2 RACKS Llenos de servidores    => 45000W
   1 CLARIION lleno de discos        =>   4800W
   1 CENTERA lleno de discos        =>   7000W
 10 Switches (electronica edificio)   =>   1600W (sin VoIP)
   1 CENTRALITA                          =>   1000W
   X AIRES ACONDICIONADOS      => 16000W
====================================================
                                                         75500W (75'5Kw)



Estas son las cuentas que he visto, me puedo haber equivocao, porque
no estoy muy ducho en esto, por eso lo he detallado, para que vosotros
veais en qué me he basado para hacer todo este razonamiento.

Compartir en Google Reader



Hace tiempo que Puche me lo estaba diciendo: "Comparte tus noticias en Google-Reader", y luego a mí me aparece lo que tú filtras y a tí lo que yo, y así con todos tus contactos. Es una forma de poder estar al día de más cosas, porque lo a mí me interesa puede interesarte y no lo sabes por que no solemos leer los mismos feeds", y como siempre Puche tenía razón.
Hasta ahora no había caído en hacer click en el enlace "Compartir" que aparece en la parte inferior de cada noticia, y desde esta semana lo estaba haciendo, pero claro, seguía sin ver lo que mis contactos compartían. Esta mañana acabo de verlo: El problema es que parece que esto sólo está disponible para la versión en inglés.