Mapa de contagiados por coronavirus en España

Mapa del estado de contagios por coronavirus en España actualizado a 14 de marzo de 2020, datos por comunidades autónomas (datos distribuidos por el Ministerio de Sanidad de España)

Información suministrada por la OMS (Organización Mundial de la Salud) sobre el coronavirus

El COVID-19 es una enfermedad infecciosa causada por un nuevo virus (SARS-CoV-2) que no había sido detectado en humanos hasta la fecha y que se ha convertido en pandemia mundial a inicios de 2020. El virus causa una enfermedad respiratoria como la gripe (influenza) con diversos síntomas (tos, fiebre, etc.) que, en casos graves, puede producir una neumonía. Como medida de protección puede lavarse las manos regularmente y evitar tocarse la cara.

¿CÓMO SE PROPAGA?

El nuevo coronavirus se propaga principalmente por contacto directo (menos de 1 metro de distancia) con una persona infectada cuando tose o estornuda, o por contacto con sus gotículas respiratorias (saliva o secreciones nasales).

Síntomas

El COVID-19 se caracteriza por síntomas leves, como, secreciones nasales, dolor de garganta, tos y fiebre. La enfermedad puede ser más grave en algunas personas y provocar neumonía o dificultades respiratorias. Más raramente puede ser mortal. Las personas de edad avanzada y las personas con otras afecciones médicas (como asma, diabetes o cardiopatías) pueden ser más vulnerables y enfermar de gravedad.

Los signos y síntomas pueden ser: secreciones nasales, dolor de garganta, tos, fiebre o dificultad para respirar (en casos graves).

Prevención

Actualmente no existe vacuna para prevenir el COVID-19. Aunque varios laboratorios a nivel mundial trabajan a contrareloj para encontrar una vacuna.

Puede reducir el riesgo de infección con estos consejos:

  • Lavándose las manos regularmente con agua y jabón o con desinfectante de manos a base de alcohol.
  • Cubriéndose la nariz y la boca al toser y estornudar con un pañuelo de papel desechable o con la parte interna del codo.
  • Evitando el contacto directo (1 metro) con cualquier persona con síntomas de resfriado o gripe.

Tratamientos

No existe ningún medicamento para prevenir o tratar la COVID-19. Algunos pacientes pueden necesitar tratamiento sintomático que les ayude a respirar.

Cuidados personales:

Si presenta síntomas leves, quédese en casa hasta recuperarse. Puede aliviar sus síntomas:

  • descansando y durmiendo
  • manteniéndose caliente
  • bebiendo muchos líquidos
  • utilizando humidificadores o tomando duchas calientes para aliviar el dolor de garganta y la tos

Tratamientos médicos:

Si presenta fiebre, tos y dificultad para respirar, busque inmediatamente atención médica. Llame con antelación a su proveedor de atención de salud e indíquele si recientemente ha viajado o estado en contacto con personas que hayan viajado.

Redimensionar innodb_log_file_size de MySQL

Tras realizar un análisis del estado del servidor de MySQL con MySQL Tunner, mostraba que deberíamos cambiar el valor del parámetro innodb_log_file_size.

Así que nos vamos al fichero de configuración (my.cnf) y, como no existe, añado innodb_log_file_size=16M. Reinicio el servicio de base de datos y… no arranca el servicio. En el log veo el motivo, sólo se permiten valores entre 0 y 5M.

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 1073741824 bytes!
InnoDB: Possible causes for this error:
 (a) Incorrect log file is used or log file size is changed
 (b) In case default size is used this log file is from 10.0
 (c) Log file is corrupted or there was not enough disk space
 In case (b) you need to set innodb_log_file_size = 48M

Tras realizar una búsqueda por Google, encuentro la solución en una entrada de Andy Hayes en DBA Diaries, donde se explica detalladamente que hay dos motivos por los que se bloquea esa modificación: por un lado el valor de innodb_fast_shutdown (no era nuestro caso) y por otro los errores de los ficheros de log.

1.- Cambiar el valor de innodb_fast_shutdown a 0 o 1
2.- Para el servidor de MySQL y revisar que no existan errores
3.- Mover los ficheros de log fuera del directorio de datos (ib_logfile0, ib_logfile1, etc)
4.- Cambiar el valor de innodb_log_file_size en my.cnf
5.- Iniciar el servicio de MySQL

DNS de Quad9: EDNS Client-Subnet

En noviembre del año pasado se presentaba un nuevo proveedor de DNS independiente: Quad9. Su IP primaria en 9.9.9.9, claramente se posicionaba como alternativa al conocido servicio 8.8.8.8 de Google.

Sin entrar a valorar si funciona bien o mal, esta mañana me he despertado con un «tweet» de Diego Parrilla donde nos avisaba de un posible bloqueo por parte de este servicio DNS.

Después de revisar a través de la web de Quad9 que no había un bloqueo. Y que añadiendo ese servicio de DNS resolvía sin problema el site de El Español empezamos a buscar donde podría estar el problema.

El problema principal estaba en que la resolución de DNS llevaba al usuario a obtener respuesta desde USA, en lugar de hacerlo desde nuestros servidores en Madrid, los que le corresponderían por posicionamiento geográfico. Sin embargo, utilizando el servicio de DNS de Google, sí que obtenía respuesta desde Madrid.

La respuesta a esta «misterio» podemos encontrarla a través de las FAQ’s de Quad9 y el uso de EDNS Client-Subnet (gracias Fermín y Diego).

Para el servicio en la IP primaria 9.9.9.9 no se envía EDNS Client-Subnet como medida de proteger la privacidad del usuario. Esto se traduce en que no sabemos desde donde está haciendo la petición el usuario y no es posible «llevarle» al servidor más cercano y que, por tanto, ofrecerá una respuesta más rápida.

Como alternativa con soporte para EDNS Client-Subnet desde Quad9 ofrecen el servicio en 9.9.9.10, aunque con esta opción «perdemos» el bloqueo de seguridad que nos ofrece el servicio principal.

Logrotate, rotado automático de logs en Linux

Una de las tareas más importantes de un administrador de sistemas es la correcta gestión de los logs que se generan. Almacenar información que nos permita descubrir un error es importante, pero esa información no debe terminar por saturar nuestros sistemas.

Y una de las herramientas que nos van a permitir cumplir ese objetivo es logrotate, esta utilidad en linux nos permite rotar, comprimir y renovar los ficheros de log de forma automatizada. En este post voy a exponer algunos ejemplos que yo utilizo para este cometido, pero desde «man logrotate» tenéis información adicional para adaptar la configuración a vuestras necesidades.

El fichero principal de configuración está accesible por defecto en /etc/logrotate.conf

$ cat /etc/logrotate.conf
weekly
rotate 4
create
include /etc/logrotate.d
/var/log/mail {
    daily
    size 1M
    create 0664 root utmp
    rotate 1
}

El directorio /etc/logrotate.d/ contiene ficheros de configuración de otras aplicaciones instaladas en el sistema, como Apache (httpd) por ejemplo. Y allí podéis crear vuestro propio fichero para ejecutar la rotación de logs.

Así la configuración básica, incluye una ruta, seguida de llaves, donde se incluye la configuración que se quiere para el rotado de logs en esa ruta.

A través de las opciones daily, weekly, monthly, yearly se le indica cada cuanto tiempo se debe ejecutar el rotado. Así si elegimos weekly, una vez a la semana se hará el rotado del fichero indicado.

Rotar cuando se alcanza un determinado tamaño de fichero

/var/log/mail.log {
        size 1M
        rotate 4
}

Con la opción size se le indica a partir de que tamaño deber rotar, si el fichero no ha alcanzado el tamaño, en nuestro ejemplo 1 mega, el fichero no será rotado.

Entre las opciones más destacadas encontramos rotate, seguido de un número entero, le indica cuantos ficheros debemos conservar. Una vez alcanzado ese número se borrará el más antiguo.

Otra opción interesante es copytruncate, que realiza una copia del fichero original y luego vacia el fichero para que los procesos que estaban trabajando con ese fichero puedan seguir haciéndolo a pesar de la rotación.

Y la otra opción, que casi diría que es fija para la mayoría de administradores, es poder comprimir los logs una vez realizada la rotación para reducir espacio. Esta opción se indica con compress. Una última opción que puede ser de mucha utilidad es missingok, que evita retornar un error en caso de que se produzca.

Así una configuración básica que rotase todos los logs dentro del directorio /var/log/ cuando alcancen el mega de tamaño, manteniendo 5 rotados y comprimiendo los antiguos, quedaría así:

/var/log/*.log {
        size 1M
        copytruncate
        rotate 5
        compress
        missingok
}

Para ejecutar el comando manualmente haríamos lo siguiente:

logrotate -vf /etc/logrotate.conf

Facebook, comScore y el elefante en la habitación

Con el recién iniciado 2018, he decidido compartir algunas reflexiones sobre la situación por la que atraviesan los medios de comunicación. A pesar de llevar algunos años trabajando en este sector, los cambios son continuos y sería un imprudente por mi parte pensar, aunque fuese sólo por un momento, que esta es la realidad, como digo, sólo son reflexiones en voz alta.

Tradicionalmente, los medios de comunicación, sobre todo en la parte digital, han vivido de la publicidad. No es que la venta de periódicos no ofreciese una suculenta recompensa económica para las empresas editoras, pero ese negocio se sustenta en una ecuación bastante sencilla, los costes de creación de contenido son los mismos para 100 que para 100.000 ejemplares así que la rentabilidad se obtiene de vender muchos.

En los últimos años ese número de ejemplares ha bajado considerablemente. Esto ha provocado que todo el sector mire a Internet como la forma natural de reconversión, aunque trasladar el negocio a la red de redes, se ha vuelto más complicado de lo que podría parecer a priori.

Facebook volvió a cambiar las reglas de juego

En medio de esa complicada tarea, llegó al mercado otro actor: Facebook. El gigante tecnológico ofreció a los medios otra forma de llegar a potenciales lectores, invitó a los medios a crear páginas en su plataforma y desde ahí llegar a sus usuarios.

Poco a poco, el tráfico que llegaba desde Facebook se hizo un hueco en los canales de captación de usuarios. Y lo peor de todo, desde el punto de vista de los medios, llegó con la pérdida de marca. La mayoría de los usuarios no recuerda donde estaba publicada una noticia que han leído a través de Facebook. Sólo retienen en su mente la marca de Mark Zuckerberg.

Al tiempo, los Instant Articles llegaron en el verano de 2015, algo más de dos años más tarde, suponen una retención mayor de los usuarios dentro de la plataforma. Y entonces llegó la lucha contra las «noticias falsas». Eso no debería preocupar a los medios, pues salvo contadas excepciones, las noticias se verifican antes de su publicación, ante el riesgo de perder rigor periodístico.

Y en este punto, vamos a dejar Facebook de a un lado, volveremos más adelante, y girar el foco hacia otro de los actores relevantes en esta historia: comScore. La Asociación para la Investigación de Medios de Comunicación (AIMC), el Internet Advertising Bureau (IAB Spain), que representa a los anunciantes digitales, y la Asociación Española de Anunciantes (AEA), decidieron renovar a comScore como medidor de las audiencias digitales en España hasta 2018.

ComScore o la medición que no se sabe que mide

Los datos de la empresa de medición sirven para elaborar el ranking que las agencias utilizan como guía para decidir que presupuesto destinan a la publicidad. Y las dudas sobre como realiza esas mediciones surgen por todas partes, sobre todo alentadas por el sistema opaco que utiliza para realizarlo.

Los medios de comunicación viven en un sin vivir marcado por las estadísticas. No en vano, de esos datos y rankings dependen una buena parte de los ingresos que sustentan las redacciones. Y por eso la mayoría, por no decir la totalidad, han decidido mirar a Facebook en busca de los codiciados usuarios. Y ya estamos en el punto de partida.

En este punto, la red social se ha dado cuenta de que los medios intentan llenar los muros de los usuarios de noticias y artículos que atraigan su atención para seguir sumando en los rankings. Llegados a este punto, el autentico valor de los medios de comunicación, que es servir de sistema de información, parece importar poco, lo importante es sumar páginas vistas que muestren inventario de los anunciantes y sumen usuarios a los rankings.

Y este es un mal negocio para Facebook, el pegamento que sustenta su plataforma, la conexión entre amigos, se ve debilitada por la cantidad de información que no tiene que ver con los contactos personales, sino con la información generada por los medios. Así que se han puesto manos a la obra para atajar el problema.

La compra de tráfico y la rentabilidad del negocio

Los medios ya contaban con una buena cuota de usuarios que llegaba por esta vía, así que el recurso ha sido ir a comprar tráfico, a través de publicaciones promocionadas en la red social. Mientras desde Facebook llegaban varias actualizaciones que, bajo el paraguas de la lucha contra las «noticias falsas» y la «protección de los usuarios», han llevado a los medios a ver como bajaba todavía más su impacto en los muros de Facebook.

Y ya está el problema generado, Facebook se ha convertido en la droga de los medios. Acuden a ella cuando necesitan mejorar sus datos en los rankings, «comprar tráfico», y cuando quieren dejarlo, el gigante tecnológico les penaliza por dejar de invertir en publicidad.

El «elefante en la habitación» lo forman Facebook, comScore y la búsqueda del hueco en el mundo digital para los medios de comunicación. Nadie parece haber encontrado una forma de afrontarlo, quizás por eso, nadie quiere hablar abiertamente del problema. Pero este 2018 que comienza, si nadie lo remedia, puede ser un año difícil para cuadrar la cuenta de resultados, una vuelta de tuerca a un sector que no acaba de encontrar su hueco.

Mostrar colores en command line (Console – Symfony2)

Desde hace algún tiempo que utilizo el component Console de Symfony2 para crear mis propios comandos en las aplicaciones Symfony2 o en solitario para otros proyectos. Una de las ventajas, es su formato colorado en pantalla, que permite distinguir de un vistazo cuando ha fallado algo o si todo ha sido correcto.

Este coloreado resulta de aplicar unos estilos predeterminados (podemos generar los nuestros propios si lo necesitamos), pero para que esto funciones es necesario tener instalados algunos paquetes. En Linux haremos uso de php-process, mientras que en Mac debemos utilizar php-posfix.

Paquetes para probar PHP 7 en Fedora y RHEL

Para los que queráis ir probando las novedades que trae PHP 7 sin necesidad de compilar desde los fuentes, el repositorio de Remi ya tiene disponible el paquete php70 en remi-test, para sistemas RHEL y Fedora.

Si no tienes los repos de Remi, puedes descargarlos desde su página, seleccionando el sistema operativo que corresponda. Puedes hacer la instalación del repo manualmente o bajarte el paquete rpm de auto-configuración del repositorio.

El paquete está disponible para Fedora 20, 21, 22 y para Enterprise Linux 6 y 7 (RHEL, CentOs, …) como una instalación separada, por lo que puedes hacerla vivir fácilmente con otros paquetes de PHP que tengas ya instalados. Para realizar la instalación:

yum --enablerepo=remi,remi-test install php70 
[salva@localhost ~]# php70 -v
PHP 7.0.0-dev (cli) (built: Apr  3 2015 08:04:28) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 
1998-2015 Zend Technologies

La instalación se realiza bajo /opt/remi, sólo está disponible bajo arquitectura x86_64 y, por el momento, sólo instala la versión 7.0.0-dev. En el blog de Remi podéis encontrar más información.