David

Logitech Media Server en Ubuntu 22.04

Logitech Media Server en Ubuntu 22.04

Pues eso, una entrada rápida para dejar registro del calvario que supone, en ocasiones, actualizar a una versión nueva y radiante de Ubuntu. El asunto: un servidor con LMS deja de funcionar al actualizar a Ubuntu 22.04, así, sin más.

Algún día daré cuenta de cómo es eso de instalar un sistema de audio distribuido por toda la casa con software libre y hardware casero. Algo a la altura de los carísimos sistemas propietarios de varias marcas de prestigio pero al alcance de cualquier bolsillo modesto. Una auténtica gozada. Y prácticamente gratis. Envidia, ¿¿eh??

Pero ahora vamos al lío. Lo primero es recabar un poco de información.

1.- Lo primero, ojear el estado del servicio logitechmediaserver. Al parecer no se está ejecutando y cada vez que lo arranco muere inmediatamente:

$sudo systemctl status logitechmediaserver
○ logitechmediaserver.service - Logitech Media Server
     Loaded: loaded (/lib/systemd/system/logitechmediaserver.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Wed 2022-05-11 00:47:56 CEST; 1s ago
    Process: 113300 ExecStart=/usr/sbin/squeezeboxserver --prefsdir $PREFSDIR --logdir $LOGDIR --cachedir $CACHEDIR --charset $CHARS>
   Main PID: 113300 (code=exited, status=0/SUCCESS)
        CPU: 450ms

May 11 00:47:56 blackstone squeezeboxserver[113300]: If you're running some unsupported Linux/Unix platform, please use the buildme.>
May 11 00:47:56 blackstone squeezeboxserver[113300]: script located here:
May 11 00:47:56 blackstone squeezeboxserver[113300]: https://github.com/Logitech/slimserver-vendor/tree/public/8.2/CPAN
May 11 00:47:56 blackstone squeezeboxserver[113300]: If 8.2 is outdated by the time you read this, Replace "8.2" with the major vers>
May 11 00:47:56 blackstone squeezeboxserver[113300]: You should never need to do this if you're on Windows or Mac OSX. If the instal>
May 11 00:47:56 blackstone squeezeboxserver[113300]: don't work for you, ask for help and/or report a bug.
May 11 00:47:56 blackstone squeezeboxserver[113300]: *******
May 11 00:47:56 blackstone squeezeboxserver[113300]:                         
May 11 00:47:56 blackstone squeezeboxserver[113300]: Exiting..
May 11 00:47:56 blackstone systemd[1]: logitechmediaserver.service: Deactivated successfully.

2.- Para tener una idea de por qué se aborta puedo correr el servidor directamente desde el ejecutable:

$squeezeboxserver
The following modules failed to load: DBI EV XML::Parser::Expat HTML::Parser JSON::XS Digest::SHA1 YAML::XS Sub::Name

Lo que ya me está indicando un problema con la carga de los módulos de Perl el cual, por cierto, está instalado en su última versión.

3.- Veamos un poco más información sobre la versión de Perl actualmente instalada:

$perl -v

This is perl 5, version 34, subversion 0 (v5.34.0) built for x86_64-linux-gnu-thread-multi
(with 50 registered patches, see perl -V for more detail)

Copyright 1987-2021, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

Es decir, que tenemos la versión v5.34. ¿Y por qué no cargan los módulos? Pues vaya usted a saber. O mejor aún, búsquelo usted en DuckDuckGo (je, je…)

La primera idea es que la actualización a Ubuntu 22.04 haya implicado un cambio a una versión más reciente de Perl (no comprobado) y que cuando LMS se ejecuta busca los módulos correspondientes a esta versión. Pero como LMS se instaló con una versión de Perl anterior, dichos módulos, simplemente, no están. Así que lo lógico parece reinstalar LMS (y, de paso, instalar la última versión). Sin embargo, esto no parece funcionar…

Así que me fijo en los mensajes de la primera salida, que había pasado por alto, y veo que los muchachos de Logitech en realidad ya me han dejado una pista que seguir, aunque de una manera un pelín críptica. Ubuntu NO es, o al menos hasta la fecha no lo era, una plataforma no soportada para su Media Server (Por eso la primera vez ni seguí leyendo) Pero, como lo cierto es que no está funcionando, empecé a pensar que, de hecho, ahora SÍ que lo es. De modo que me puse a seguir el rastro de migas.

El enlace lleva a un repositorio de github con un software que hay que compilar para parchear la instalación del servidor. También hay un archivo de ayuda (README.md) con unas austeras indicaciones de qué hacer con este software. Así que cloné el repositorio, lo compilé con el script proporcionado (buildme.sh) y realicé la copia de las dos carpetas generadas a la ruta donde squeezeboxserver está instalado, tal como indican las instrucciones. Por cierto, que me costó un poco encontrar la dichosa ruta, así que la dejo anotada aquí:

$cd /usr/share/squeezeboxserver/CPAN/arch/

Curioseando en esta carpeta compruebo, para mi sorpresa, que hay compilaciones instaladas automáticamente con cada una de las versiones anteriores, pero ninguna para la actual versión de Perl, la 5.34. Es decir, que cada instalador ha generado su carpeta con sus módulos salvo la última ¿Y eso por qué? Efectivamente, algo aquí no está funcionando bien. Y, efectivamente, una vez compilado el software y copiado a la ruta en cuestión, mi querido Logitech Media Server vuelve a funcionar. Eso sí, queda sin explicar por qué ya no se incluyen automáticamente estos módulos durante la instalación, si es que los de Logitech han decidido dejar de dar soporte a Ubuntu, si tiene que ver con la versión de Perl o qué, por lo que no sabemos qué pasará cando haya nuevas actualizaciones. Como siempre, cruzaremos ese puente cuando lleguemos a él. Y si eso… ya lo comentaremos.

Publicado por David en Blog, Domótica, Linux, 0 comentarios
De como me independicé de Google (ii) – Navegar sin temor…

De como me independicé de Google (ii) – Navegar sin temor…

… en el mar es lo mejor 𝅘𝅥𝅰  𝄞 ¿Alguien se acuerda de la canción de los payasos de la tele? Qué tiempos aquellos… en los que se podían surcar los procelosos mares de internet sin tener a un señor de negro subido a la chepa. Por cierto, dejaré un enlace a la canción al final del artículo, por eso de la nostalgia, y tal…

El navegador

Empecemos por el principio. Ahora bien, no voy a meterme a hacer una comparativa en cuanto a navegadores. Si quieres una, hay miles en internet (Si no me crees puedes buscarlas en Google, je, je…). Aquí me limitaré a mostrar algunas conclusiones. Y en este punto lo tengo claro: Mozilla Firefox.

Es un proyecto de código abierto, apoyado por una comunidad madura y comprometida, con un desarrollo de largo recorrido, continuo y con frecuentes actualizaciones. Está construido desde su base con la privacidad como objetivo y aunque quizás no sea de los más espectaculares en rendimiento y prestaciones, funciona francamente bien. Por algo es el navegador predeterminado en Ubuntu y para mí es más que suficiente.

Respecto a los navegadores basados en Chrome diré que hay algunos que son estupendos, pero todos tienen un pequeño inconveniente: y es que están basados en Chrome. Y sí, ya sé que a partir del código abierto de Chrome se puede hacer un buen navegador que no comprometa la privacidad y tal. Pero ya desde el título de esta entrada dejo claro que lo que quiero es alejarme lo más posible de Google así que… ajo y agua.

Migrar desde Chrome a Firefox resulta muy sencillo, ya que el propio Firefox permite realizar la importación de todos los datos de navegación de un navegador a otro. Sin embargo, una de las cosas que quizás tiene peor resueltas es el tema del uso de varios perfiles dentro de una misma cuenta, algo que a mí me resulta muy útil. De hecho, las opciones para crear perfiles y cambiar de uno a otro no están a la vista. Es necesario ingresar en una página local introduciendo la expresión about:profiles en la barra de direcciones. Una solución un tanto rara, la verdad, pero que se arregla añadiendo un marcador a la barra de marcadores. No es elegante pero funciona.

Ni que decir tiene que si queremos mantener una navegación suficientemente privada no basta con utilizar este navegador (ni cualquier otro). Por defecto Firefox adopta medidas como la ocultación de la ubicación y el bloqueo de rastreadores, sin embargo es importante tener mucho cuidado a la hora de instalar complementos que puedan comprometer la privacidad.

El buscador

Pero quizás, incluso antes de pensar en cambiar de navegador merece la pena reflexionar sobre el buscador. ¿Alguien se acuerda de Altavista? ¿O de Yahoo? ¿Cuándo y cómo llegamos a convencernos de que buscar en Internet era equivalente a buscar en Google? Tan acostumbrados estamos que da escalofríos sólo pensarlo.

Y no es cuestión baladí. Aquí conviene tener presente que la privacidad va en dos sentidos (por lo menos): que los buscadores no almacenen nuestras búsquedas es sólo una parte. Luego está la neutralidad de los resultados que el buscador arroja, incluyendo publicidad, o resultados que el buscador deduce que son «más relevantes» para nosotros, como les gusta llamar a estas compañías el hecho de mostrarnos aquella información que más fácil nos va a entrar para satisfacer a un tiempo nuestros impulsos y sus intereses.

(Dejo este enlace a un artículo que me resultó bastante interesante)

Igual que antes, no me enredaré en comparativas y me limitaré a señalar a DuckDuckGo como la opción más interesante. Merece la pena configurarlo como buscador por defecto. Por cierto, existe un complemento para Firefox llamado DuckDuckGo Privacy Essentials que resulta muy interesante instalar. Entre otras cosas, nos va informando de todos los rastreadores y anuncios que nos va bloqueando conforme navegamos, lo cual no hace sino contribuir a ponernos los pelos de punta al hacernos conscientes de hasta qué punto las grandes plataformas se dedicaban a cotillear en nuestras cosas cuando aún no usábamos estas herramientas.

¿Y para el móvil?

En el caso del móvil tenemos tres navegadores que merece la pena utilizar para reemplazar tanto a Chrome como al navegador que traiga nuestro móvil por defecto y que, por cierto, suele ser un churro:

  • Firefox para Android: Muy similar al de escritorio y abierto a múltiples configuraciones. Entre otras cosas, permite sincronizar los datos de navegación y las contraseñas con el resto de navegadores Firefox en otros dispositivos. Muy conveniente, para quien le convenga, claro.
  • Firefox Focus: Una versión del anterior minimalista y muy ligera, preconfigurada para la mayor privacidad y muy cómoda para navegar sin distracciones aunque tenga menos características.
  • DuckDuckGo Privacy Browser: Como podemos imaginar, un navegador que trae por defecto todas las opciones de privacidad habidas y por haber. Pero lo más interesante es que incorpora un widget de búsqueda similar al típico que viene por defecto con Android y que resulta perfecto como sustituto. Sólo por eso ya merece la pena instalarlo, aunque luego usemos otro navegador.

Edición de mayo de 2022: Recientemente he sabido acerca de un acuerdo de sindicación entre DuckDuckGo y Microsoft que impide a la primera compañía bloquear los rastreos por parte de la segunda. Al parecer, esto ocurriría exclucivamente en el navegador de Android y no en los de escritorio, siempre según fuentes de Duckduckgo, claro. Por lo tanto, la mejor opción para Android sigue siendo, siempre en mi humilde opinión, Mozilla Firefox. No obstante, no está de más tener también instalada la aplicación móvil de DuckDuckGo para disponer del widget de búsqueda como sustituto del de Google.

Y en el próximo capítulo espero dedicarme al peliagudo tema de los calendarios y las agendas de contactos. Uno de los anzuelos que más enganchados nos mantienen al ojo que todo lo ve.

Nos vemos pronto. Y de momento, ahora sí, para los nostálgicos, tal y como estaba prometido… la canción:

Publicado por David en Blog, Herramientas, Linux, Seguridad, 0 comentarios
Aquel maldito indicador de Dropbox…

Aquel maldito indicador de Dropbox…

Los que llevamos un tiempo funcionando con Dropbox en ubuntu hemos tenido ocasión de ver diversos comportamientos raros con el indicador de la aplicación en el área de notificación. En ocasiones, directamente desaparecía. Otras, el menú no se despliega o no funciona. Normalmente, rebuscando un poco por la red termino encontrando una solución pero, inevitablemente, para la próxima vez que me encuentro con el mismo error en una nueva instalación ya me he olvidado.

Por cierto, decir que escribo esto justo después de instalar la versión 21.10 de Ubuntu y eso me lleva pasando por lo menos desde hace unos seis o siete años… y ahí sigue. Haciendo un poco de historia y revolviendo un poco por Internet, parece que la cosa comenzó en la versión 14.04 y afectaba a los escritorios no Unity. Lo malo es que cuando Unity desapareció definitivamente nadie se molestó en reparar el paquete con lo cual el error ha seguido propagándose hasta nuestros días. Afortunadamente tenemos dos noticias, una buena y otra mejor.

La buena noticia es que la reparación es bastante sencilla y que se aplica en unos minutos. Y la mejor, es que los mantenedores de la distribución Ubuntu Mate han parcheado el paquete en sus repositorios oficiales desde la versión 16.04. Así que tenemos dos maneras de solucionar la cosa:

1.- Aplicamos el apaño a mano, o bien…

2.- …instalamos directamente el paquete de Ubuntu Mate en lugar del habitual. Su nombre es caja-dropbox

Por cierto, que esta información está tomada de este artículo pero por si acaso dejo también el código del apaño aquí a mano. Nunca se sabe…

cp ~/.config/autostart/dropbox.desktop ~/.config/autostart/start_dropbox.desktop
sed -i 's/^Exec=.*/Exec=dbus-launch dropbox start -i/' ~/.config/autostart/start_dropbox.desktop
dropbox autostart n
mkdir -p ~/.local/share/applications/
cp /usr/share/applications/dropbox.desktop ~/.local/share/applications/
sed -i 's/^Exec=.*/Exec=dbus-launch dropbox start -i/' ~/.local/share/applications/dropbox.desktop
Publicado por David en Blog, Herramientas, Linux, 0 comentarios
De como me independicé de Google (i) – No sos vos, soy yo.

De como me independicé de Google (i) – No sos vos, soy yo.

Hace unos meses me hacía eco de una curiosa noticia. Google iba a empezar a tomarse la libertad de monitorizar el contenido que mantenemos en Drive por si acaso guardamos algo que ellos puedan considerar «inadecuado». Y en tal caso, podría tomar partido con acciones que irían desde restringir el acceso al contenido ofensivo hasta eliminarlo. Y recordemos… que cuando Google habla de «contenido» se está refieriendo a nuestro material (nuestras fotos, por ejemplo)

Un poco de memoria

Que Google lleva años pasándose nuestra privacidad por el arco del triunfo y que sabe más de nuestra intimidad que nuestro terapeuta no es ningún secreto. Y que nosotros le hemos ido consintiendo cada vez más a cambio de sus servicios «gratuitos», tampoco. No estará mal hacer un poco de memoria:

Antes que nada Google fue el buscador que todos adoptamos ilusionados de manera totalmente acrítica hará como unos veinte años. Un buscador que, por cierto, toma nota de cada búsqueda que hacemos y selecciona cuidadosamente los resultados que nos muestra para que sean «relevantes» para nosotros. Un nosotros que pronto se materializó en una dirección de correo Gmail, también «gratis», alojada en sus servidores, y que se convirtió a efectos prácticos en el carné de identidad dentro del universo Google. Después llegó Chrome, ese estupendo navegador. Y lo digo sin ironías: rápido, ágil, lleno de prestaciones, que nos permitía trasladar nuestra experiencia de navegación de una máquina a otra de manera transparente a golpe de recopilar información sobre cada uno de nuestros gustos construyendo así nuestro «perfil». Y, como no, para todos los que nos afanábamos manejando las agendas de aquellas primeras «palmtop» (hay que ver qué mal envejecen algunos términos) llegaron en nuestro auxilio los servicios de Google Calendar. Menos mal que en cuanto la tecnología de aquellos primeros computadores de mano con teléfono integrado, a los que de pronto todos empezamos a denominar con el hortera anglicismo de «smart phone», empezó a madurar, apareció Google de nuevo con su sistema operativo «gratuito» Android para hacerlos funcionar. Y tan bien funcionaron que pronto integramos toda nuestra agenda, tanto telefónica como de email en Google Contacts, lo que además nos permitía pasar de un teléfono a otro sin perder un solo número. Y hacíamos copia de seguridad de todos nuestros datos en la nube de Google Drive, incluyendo las fotos. Y felices dijimos adiós a aquellos «carísimos» navegadores TomTom y Garmin, adoptando los mapas de Google Maps y su servicio «gratuito» de navegación. Y hubo tal regocijo que pronto todos quisimos que formara parte permanente de nuestro vehículo, así que llegó Android Auto para instalarse en nuestros coches. Y suma y sigue, y seguro que me dejo cosas. ¡Y lo que está por venir!

Algo pasa con Google

Google sabe qué nos gusta, qué miramos, qué nos entretiene, qué nos interesa, con quién nos comunicamos, a qué nos dedicamos, qué horarios tenemos, por dónde nos movemos, adónde viajamos o vamos de vacaciones, dónde vivimos nosotros, nuestra familia y nuestros amigos, cuánto tiempo pasamos en la panadería, en ese bar de mala muerte o en casa de fulanita, dónde caí borracho por última vez o lo poco que salgo de casa y el tiempo que hace que no me como un rosco, a que manifestación decidí ir, o si es que quizás preferí no ir…

Vamos, que no es de ayer precisamente el que tengamos sobrados motivos para recelar de esta compañía. Pero lo de Google Drive… no sé cómo decirlo, ha sido la puntilla, la gota que ha colmado el vaso. Ya sólo faltaba que el día que por la razón que sea lleguen a la nube aquellas fotos que nos hiciéramos mi churri y yo aquel verano en el Pirineo, cuando la euforia debida seguramente a la altitud nos llevó a pensar que era buena idea inmortalizar el momento de chapuzarnos en pelotas en un ibón, llegue el Sr. Google a meter las narices y les eche un vistazo no vaya a ser que le parezcan o le dejen de parecer lo bastante «adecuadas» para existir en su exquisita nube. Como si ese maldito criterio moralista y puritano que lo está embarrando todo tuviera que perseguirnos también a nuestra alcoba digital. Bueno, pues hasta aquí hemos llegado. Igual que hay cosas en la vida que es mejor no ver, también hay experiencias por las que es mejor no tener que pasar. Y para los que penséis que exagero, molestaros en echar un vistazo a sus políticas, sobre todo la parte en la que dice eso de que «podemos revisar el contenido y tomar las medidas que estimemos oportunas», teniendo en mente que esto incluye su servicio Drive, ese lugar donde el común de los mortales guarda su material más intrascendente pero también el más personal.

Así que aquí estoy, embarcado en una trayectoria que ha de llevarme poco a poco, o eso espero, a la independencia total de Google y su omnipresente actitud vigilante cual ojo de Sauron. Trayectoria que en su momento ya recorrí con Microsoft con notable éxito, aunque por razones diferentes.

Lo que empezó siendo una entrada en la que recoger algunas conclusiones para que no cayeran en el olvido ha terminado convirtiéndose en la crónica de un peregrinaje en busca de un uso más libre y neutro de la red. Una red que, para quienes la vimos aterrizar en medio de nuestras vidas, nunca debería haber dejado de encarnar ese espíritu de interconexión y libertad con el que todo empezó. De manera que dedicaré varias entradas, una por cada etapa del camino, y a medida que las vaya publicando, las iré enlazando también desde aquí.

Empezamos:

  1. De como me independicé de Google (ii) – Navegar sin temor…
  2. De como me independicé de Google (iii) – La nube
Publicado por David en Blog, Herramientas, Linux, Seguridad, 0 comentarios
A vueltas con los discos duros

A vueltas con los discos duros

Ampliar partición de sistema

Al instalar según que versión de Ubuntu (me consta que pasa con varias de ellas) puede ocurrir que, al dejar los ajustes por defecto para el particionado que proporciona el asistente de instalación, nos encontremos con que la partición de sistema no está utilizando la totalidad del disco duro. La última vez que me ocurrió tal cosa fue con una de las versiones de la distribución LTS 20.04, dejándome reducido un disco de 250Gb a la mitad, pero sé de gente que le ha ocurrido encontrarse con particiones de sistema ridículamente pequeñas en algunas versiones de la distribución 18.

Sea como fuere, es muy probable que deseemos aumentar el tamaño de nuestra partición al máximo disponible. Afortunadamente, el sistema LVM hace que esta tarea resulte sencilla, pudiéndose hacer al vuelo y sin siquiera tener que reiniciar la máquina.

Empezamos por redimensionar el volumen lógico para usar la totalidad del grupo, que coincidirá con el tamaño del disco. Esto se puede hacer de dos maneras. O entramos en la consola de LVM…

sudo lvm
lvm> lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
lvm> exit

…0 bien tecleamos el comando directamente, que viene a ser lo mismo:

sudo lvm lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

A continuación, redimensionamos la partición para que ocupe todo el volumen disponible:

sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/ubuntu-vg/ubuntu-lv is mounted on /; on-line resizing required
old_desc_blocks = 15, new_desc_blocks = 29
The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 60655616 (4k) blocks long.

Y… ya está! Ya podemos comprobar el nuevo tamaño de nuestras particiones con

df -h

Comprobación de discos al inicio

Hay una herramienta que resulta muy útil para este propósito: tune2fs. Lo primero que podemos hacer es obtener información de los parámetros actualmente configurados. Para ello lo ejecutamos con la opción -l (list):

tune2fs -l /dev/sda1

Si sabemos con exactitud lo que estamos buscando podemos combinar la salida anterior con grep. En cualquier caso, los parámetros que nos ocupan ahora son Mount count y Maximum mount count. el primer nos proporciona la cuenta de las veces que el disco se ha montado desde la última comprobación, y el segundo el conteo máximo para el cual tendrá lugar la comprobación de discos.

Publicado por David en Herramientas, Linux, 0 comentarios
Visualización de métricas con Prometheus y Grafana

Visualización de métricas con Prometheus y Grafana

¿Prometheus, Grafana o los dos?

Grafana es una de las herramientas más extendidas y populares para visualizar datos de manera gráfica. Además, estos datos pueden ser adquiridos en tiempo real de sistemas en funcionamiento, lo que permite controlarlos y monitorizarlos con detalle.

La verdad es que a poco que nos hayamos movido por el entorno de Cardano seguro que ya nos hemos encontrado con Grafana, ya que se trata de la opción más extendida y recomendada cuando se trata de supervisar un nodo de la red. No obstante, sus aplicaciones son prácticamente ilimitadas, y en mi caso concreto también me resulta muy útil como panel de control del sistema domótico Openhab.

Grafana puede conectarse a varias fuentes de datos. Una de las más populares, por ser la utilizada por Cardano, es Prometheus. También puede conectarse a InfluxDB, lo cual es muy conveniente, al ser una de las opciones más comunes de entre las disponibles en Openhab.

Prometheus es un software que tiene algunos puntos en común con Grafana. Por sí sólo también es capaz de recolectar datos y mostrarlos en forma de gráficas, aunque sus posibilidades en este sentido son mucho más limitadas. En realidad, sólo con Prometheus ya podríamos realizar la monitorización de un sistema, incluyendo el nodo de Cardano, pero Grafana añade una capa de funcionalidad y prestaciones que resultan muy convenientes. De ahí que, a menudo, en todos los artículos referidos a la monitorización en Cardano aparezcan juntos.

A efectos prácticos utilizaremos Prometheus como un sistema para recolectar y recopilar las métricas que nos interese monitorizar y Grafana como una capa adicional para transformar y visualizar estos datos de la manera que nos resulte más conveniente.

Empecemos por Prometheus

Prometheus recolecta métricas a partir de lo que llama end-points, los cuales no son sino puntos de conexión mediante el protocolo http en los que se encuentran expuestas dichas métricas en un formato XML entendible por Prometheus.

Configuración

La configuración es sencilla, pero si no queremos desorganizar demasiado los scripts de inicio del servicio systemd conviene hechar un vistazo al contenido de éste:

sudo nano /lib/systemd/system/prometheus.service
...
EnvironmentFile=/etc/default/prometheus
ExecStart=/usr/bin/prometheus $ARGS
...

Por cierto, si quieres recordar cómo encontrar la ubicación de los scripts de servicio, echa un vistazo a esta entrada.

En este archivo vemos que el ejecutable es invocado con una variable de entorno $ARGS que contiene los argumentos que se pasan al programa. Vemos también la ubicación del archivo de entorno donde encontraremos la asignación de dicha variable. Si editamos dicho archivo:

sudo nano /etc/default/prometheus

# Set the command-line arguments to pass to the server.
ARGS=""

# Prometheus supports the following options:
#  --config.file="/etc/prometheus/prometheus.yml"
#                             Prometheus configuration file path.
#  --web.listen-address="0.0.0.0:9090"
...

Observamos que la variable de entorno está vacía, lo que nos indica que se toman los argumentos por defecto. Vemos también, comentados, todos los argumentos que pueden ser pasados al ejecutable. Una opción sería especificar dichos parámetros directamente en el archivo de servicio donde se llama al ejecutable, eliminando la variable de entorno $ARGS. Sin embargo, una opción más elegante es colocar dicho parámetro dentro de la cadena $ARGS y permitir que para el resto de parámetros no especificados se apliquen los valores por defecto. Por ejemplo, para modificar el puerto al 9095 podríamos dejar el archivo así (observar las secuencias de escape para las dobles comillas):

sudo nano /etc/default/prometheus

# Set the command-line arguments to pass to the server.
ARGS="--web.listen-address=\"0.0.0.0:9095\""

# Prometheus supports the following options:
#  --config.file="/etc/prometheus/prometheus.yml"
#                             Prometheus configuration file path.
#  --web.listen-address="0.0.0.0:9090"
...

Para configurar los endpoints a los que conectarse, editar el archivo:

sudo nano /etc/prometheus/prometheus.yml

Métricas de Cardano

El software cardano-node ofrece, de manera nativa, un end-point con las métricas de funcionamiento del nodo. En el archivo de configuración de cardano-node encontraremos un apartado donde configurar el número de puerto (por si necesitáramos cambiarlo) y las direcciones desde las cuales es posible conectarse al end-point (punto importante cuando el servidor Prometheus está en una máquina diferente). Concretamente, esta sección tiene el siguiente aspecto:

"hasPrometheus": [
    "127.0.0.1",
    12798
  ]

Ésta es la configuración por defecto. Indica que la conexión sólo es posible desde la máquina local y en el puerto 12798. Si necesitamos conectarnos desde otra máquina, deberemos especificar, o bien la dirección IP de la misma, o bien «0.0.0.0» para la conexión desde cualquier dirección IP. No olvidemos que, en este caso, además deberemos habilitar este puerto en el firewall.

Si queremos echar un vistazo a los datos en crudo ofrecidos por el end-point de nuestro nodo bastará con dirigir nuestro navegador a la dirección:

http://<ip_nodo>:12798/metrics

Obviamente, el end-point deberá ser accesible desde la máquina en la que tengamos el navegador. Como es posible que eso no coincida con la configuración que estamos planeando, y para no andar toqueteando aquí o alla, una buena alternativa al navegador es el comando curl en la misma máquina en la que se encuentre el end-point:

curl -s http://localhost:12798/metrics

Métricas del nodo

Otro conjunto de datos que suele resultar interesante para comprobar el buen desempeño de una máquina es el relacionado con el correcto funcionamiento y rendimiento del hardware y del sistema operativo: temperaturas, carga de la CPU, uso de memoria, etc. Estas métricas pueden obtenerse instalando el software prometheus-node-exporter, el cual recopila todos estos parámetros y los expone en un nuevo end-point en el puerto 9100. Como antes, para comprobar el buen funcionamiento del end-point:

curl -s http://<ip_nodo>:9100/metrics

Aunque parezca una trivialidad, no está de más no confundir el software prometheus-node-exporter, el cual sólo crea un end-point donde exponer métricas de funcionamiento de la máquina, con el servidor Prometheus, que es el que se encarga de recopilar y almacenar todos los datos obtenidos de los diferentes end-points. Aunque a menudo se instalen a la vez, son piezas de software diferentes y ni siquiera es necesario que vayan juntos.

Métricas de dispositivos de red

El protocolo SNMP (Simple Network Management Protocol) permite el intercambio de información entre dispositivos conectados a una misma red. Entre sus usos más frecuentes se encuentra la configuración automática de routers o firewalls por parte de aquellos programas que lo necesiten. Sin embargo, también es posible utilizarlo para obtener métricas de dispositivos de red y mostrarlas en Grafana. Por ejemplo, podemos monitorizar el router y comprobar el buen funcionamiento de nuestra conexión a internet.

Necesitaremos dos cosas:

  • Que nuestro router sea compatible con SNMP y que éste se encuentre habilitado
  • Tener instalado prometheus-snmp-exporter en nuestro servidor. Este software es capaz de comunicar con dispositivos que hablen SNMP y de ofrecer las métricas así obtenidas exponiendo un end-point para Prometheus. Este software se puede instalar directamente desde los repositorios de Ubuntu o bien descargándolo desde github, concretamente, aquí.

Su configuración se encuentra en el archivo:

sudo nano /etc/prometheus/snmp.yml
# Due to licensing reasons, it is not possible to ship a ready-to-use snmp.yml
# config file.
#
# See /usr/share/doc/prometheus-snmp-exporter/README.Debian for instructions
# on using prometheus-snmp-generator to create a suitable snmp.yml config.

En el que nos encontramos este curioso mensaje. La lectura del archivo README.Debian tampoco proporciona mucha más información.

La manera de proceder es sencilla. En github, que es donde se aloja el proyecto, viene un archivo snmp.yml por defecto que en la mayoría de las ocasiones nos funcionará correctamente, así que podemos, simplemente, descargarlo en el directorio arriba mencionado.

Importante: dependiendo del método escogido para instalar prometheus-snmp-exporter nos encontraremos con una versión u otra. Normalmente, las versiones disponibles en los repositorios oficiales de Ubuntu suelen estar algo desfasadas con respecto a la última versión disponible en GitHub. Esto es importante, porque si el software instalado y el archivo de configuración descargado corresponden a versiones diferentes, podría no funcionar.

Por ejemplo, en el momento de escribir esta entrada, la versión instalada a partir de los repositorios de Ubuntu es la v0.16.1, bastante anterior a la versión actual de GitHub, que es la v0.20.0. Por lo tanto necesitamos buscar el archivo de configuración de la versión adecuada, lo que conseguimos tecleando:

sudo wget https://raw.githubusercontent.com/prometheus/snmp_exporter/v0.16.1/snmp.yml

Si todo va bien, podemos observar las métricas en el endpoint correspondiente:

curl http://<server_ip>:9116/snmp?target=<router_ip>

Visualizando con Prometheus

Como decíamos, Prometheus por sí mismo puede ser utilizado como herramienta de monitorización y visualización. Para ello, sólo hay que conectarse desde un navegador a la dirección de la máquina donde se esté ejectuando el servidor:

http://<nodo_prometheus>:9010

Y veremos algo como esto:

Prometheus

En esta página disponemos de algunas opciones que nos permiten ir añadiendo gráficas y seleccionando las métricas deseadas.

Y sigamos con Grafana

Grafana suele ser instalada en la misma máquina en la que tenemos el servidor Prometheus pero, en realidad, podría estar en cualquier otro. Dispone de la posibilidad para conectar con diferentes fuentes de datos, entre ellas, como ya hemos comentado, con Prometheus y con InfluxDB.

Contrariamente a lo que pensé en un principio, Grafana no es capaz de conectar directamente con los end-points que proporcionan los datos para Prometheus, sino sólo con éste último. Es decir, que para monitorizar un nodo de Cardano, Grafana nos la podríamos ahorrar, pero Prometheus no.

Base de datos

Grafana utiliza una base de datos de tipo SQLite ubicada en /var/lib/grafana/grafana.db

  • Si en algún momento metemos la pata y deseamos deshacer el desaguisado manualmente, siempre podemos descargar el archivo y editarlo manualmente con esta excelente herramienta de código abierto: DB Browser for SQLite
  • No está de más incluir este archivo entre aquellos de los que solemos hacer copia de seguridad.
Publicado por David en Cardano, Domótica, Linux, 0 comentarios
Acceso remoto mediante SSH. Generalidades

Acceso remoto mediante SSH. Generalidades

En ocasiones, si hemos cambiado el nombre o la dirección IP de la máquina a la que deseamos acceder, puede que al conectarnos nos aparezca el siguiente mensaje de aviso:

Warning: the ECDSA host key for 'pioneer' differs from the key for the IP address '192.168.1.x'
Offending key for IP in /home/david/.ssh/known_hosts:<n>
Are you sure you want to continue connecting (yes/no)?

Donde <n> es un número entero.

Se trata de un aviso estándar de seguridad que nos advierte de una posible brecha de seguridad. Obviamente, si estoy funcionando en mi red privada y soy consciente de que he estado haciendo cambios, este mensaje puede ignorarse con total tranquilidad. No obstante, si queremos deshacernos del mismo, hay dos maneras muy simples.

  1. Las máquinas a las cuales nos hemos conectado se guardan en el archivo mostrado en la ruta del mensaje (known_hosts). Si abrimos este archivo veremos que el formato no es muy amigable, pero tiene la ventaja de que cada host se guarda en una línea de archivo. Así que bastará con borrar la línea número <n> y ya estará.
  2. Lo anterior es sencillo si en dicho archivo tenemos una lista de tres o cuatro máquinas. Pero ¿qué pasa si, como me acaba de ocurrir, resulta que n = 61? Bien, siempre podemos editar el archivo de manera que nos muestre los números de línea, lo cual facilita mucho las cosas:
    nano ~/.ssh/known_host -l
  3. Y si no, siempre podemos usar el siguiente comando, que es de lo más molón:
    sed -i '61d' ~/.ssh/known_hosts
Publicado por David en Linux, SSH, 0 comentarios

Manejo de paquetes de instalación en Ubuntu

Linux packages

El misterio de los paquetes marcados como instalados manualmente

En ocasiones, cuando intentamos instalar un paquete que ya está instalado, el sistema nos devuelve el siguiente mensaje:

<package> is already the newest version (<ubuntu_version>).
<package> set to manually installed.

En realidad, este mensaje no tiene la menor importancia. Muchos paquetes se instalan de manera automática, bien durante la instalación inicial del sistema, bien como dependencias de otros paquetes. Y luego están los paquetes que los instalamos nosotros manualmente de manera explícita cuando los necesitamos. El gestor de paquetes simplemente guarda esta información en forma de un marcador que indica si la instalación del paquete se hizo de forma automática o manual. Esta información es la que el gestor utiliza, cuando desinstalamos un paquete, para decidir cuáles de sus dependencias ya no son necesarias y pueden ser desinstaladas, y cuáles es mejor mantener.

El tema viene cuando intentamos instalar un paquete que ya está instalado. Si este paquete se instaló en su momento de manera automática, el gestor lo marcará ahora como instalado manualmente. La única implicación práctica, que yo sepa, es que si ese paquete se había instalado automáticamente como dependencia de otro instalado anteriormente, cuando desinstalemos éste el gestor no nos sugerirá desinstalar la dependencia (lo cual es bastante conveniente en la mayoría de los casos, por cierto). No obstante, a los obsesivos un tema así nos puede traer de cabeza, así que si queremos devolverlo a su estado original, sólo tenemos que hacer lo siguiente:

sudo apt-mark auto <package>

Y listo.

Publicado por David en Herramientas, Linux, 0 comentarios
Acceso remoto SSH con clave pública

Acceso remoto SSH con clave pública

El acceso a un servidor mediante el uso de clave pública es una alternativa cómoda y segura al tradicional acceso con contraseña. Para ello, lo primero que tenemos que hacer es generar un par de claves pública y privada en el mismo cliente desde el que queramos acceder al servidor por primera vez:

~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<USER>/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/<USER>/.ssh/id_rsa
Your public key has been saved in /home/<USER>/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:mU/wwq4it1/2pIYfl9o5hM4WughDxubXZuGDvR9vo78 engineer@home
The key's randomart image is:
+---[RSA 3072]----+
|                 |
|                 |
|        .        |
| .     . =       |
|  =   . S.o      |
| =   = oo+..     |
|  + o B=*o=      |
|  .+o+o*=@+.     |
|   oo+=**+E+     |
+----[SHA256]-----+

Al generar las claves podemos dejar todos las opciones por defecto, en cuyo caso se nos generarán los archivos correspondientes a una identidad genérica de nombre id_rsa en el directorio /home/<USER>/.ssh/ Sin embargo, es posible y, en ocasiones, aconsejable, utilizar un nombre personalizado para dichos archivos. De esta manera podemos crear varias identidades diferentes, lo que nos permitirá acceder a los servidores remotos bajo diferentes nombres de usuario. En nuestro ejemplo, los archivos creados son los siguientes:

ls ./.ssh/
id_rsa id_rsa.pub

Como podemos ver, la clave pública se guarda en un archivo con la extensión .pub, mientras que la clave privada está en un archivo sin extensión. Cada vez que generemos un nuevo par de claves, éste es el lugar en el que se almacenarán. Por supuesto, las claves pueden ser copiadas de una máquina a otra para poder conectarnos desde diferentes lugares.

En este sentido, es evidente que sólo será necesario generar un nuevo par de claves si no las hemos generado previamente en ésta o en cualquier otra máquina. En este caso, podemos saltarnos este paso y, simplemente, asegurarnos de tener las claves que queremos utilizar en este directorio.

Ahora ya podemos enviar nuestra clave pública al servidor al cual deseamos tener acceso para que nos reconozca a través de la clave privada, la cual permanecerá a buen recaudo en nuestro ordenador cliente.

ssh-copy-id <USERNAME>@<HOSTNAME>

O bien, si hemos especificado un nombre personalizado para el fichero (sin extensión):

ssh-copy-id -i <identidad> <USERNAME>@<HOSTNAME>

Obviamente, necesitamos tener acceso al servidor remoto mediante nombre de usuario y contraseña, los cuales se nos pedirán a continuación. El programa cliente ssh de nuestra máquina local conectará entonces con el servidor y transferirá la clave pública de la identidad especificada, la cual quedará almacenada en el servidor.

A veces, sobre todo si hemos elegido un nombre personalizado para la identidad, puede ser necesario especificar el directorio en el cual se encuentran las claves, es decir: ./.ssh/<identidad>

Insistimos en este punto: A pesar de que cuando especificamos la identidad en el comando anterior no ponemos la extensión, con lo que en realidad la ruta que hemos de escribir coincide con la de la clave privada, la única clave que se transfiere al servidor es la clave pública. Como regla general, una clave privada debe siempre permanecer en nuestro poder y jamás debería ser subida a ningún servidor público ni copiada a ninguna máquina que no está directamente bajo nuestro control y que sea lo bastante segura. Por algo se llama privada.

Y ya está. Sólo nos queda comprobar que podemos conectarnos sin problemas. Como al subir la identidad ésta queda asociada al nombre de usuario podemos, simplemente, escribir:

ssh <USERNAME>@<HOSTNAME>

¿Y si no puedo entrar?

En primer lugar, deberíamos comprobar que el servidor remoto ssh está correctamente configurado para aceptar conexiones mediante autenticación por clave pública. Ésta es la configuración por defecto, por lo que, en principio, no debería ser necesario. Sin embargo, cuando la cosa no funciona, éste uno de los puntos a comprobar, sobre todo si hemos estado toqueteando la configuración del servidor, la cual se encuentra en el siguiente archivo:

sudo nano /etc/ssh/sshd_config

Y comprobar que el parámetro PubkeyAuthentication no esté inadvertidamente configurado en no

Por cierto, ya que estamos, para incrementar la seguridad no está de más desactivar el acceso mediante contraseña:

PasswordAuthentication no

Otra causa frecuente por la que puede estar fallando es que el cliente no esté seleccionando de manera automática la identidad correcta. Esto puede pasar cuando ya llevo un tiempo creando y borrando identidades para entrar en distintos servidores bajo diferentes cuentas. En cualquier caso, la manera de asegurar el tiro es tan sencillo como explicitar la identidad de la que se trata:

ssh -i .ssh/identidad <USERNAME>@<HOSTNAME>
Publicado por David en Linux, Seguridad, SSH, 0 comentarios
A vueltas con openHAB

A vueltas con openHAB

Actualizando Openhab

Si hemos instalado Openhab siguiendo las recomendaciones, lo más probable es que hayamos elegido Zulu como la plataforma de Java. Sin embargo, Openhab no es compatible con versiones de Java mayores que 11 y si instalamos Zulu a partir de los repositorios, cada vez que haya una actualización inevitablemente se configurará la más reciente como versión por defecto. Por eso es necesario, antes de reiniciar Openhab, seleccionar la versión correcta de Java:

~$ sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                          Priority   Status
------------------------------------------------------------
  0            /usr/lib/jvm/zulu15/bin/java   2153801   auto mode
* 1            /usr/lib/jvm/zulu11/bin/java   2115401   manual mode
  2            /usr/lib/jvm/zulu15/bin/java   2153801   manual mode

Press <enter> to keep the current choice[*], or type selection number:
1 

Consola Karaf

OpenHab proporciona una consola desde la que poder monitorizar y gestionar algunos aspectos del sistema. Podemos conectarnos de dos maneras:
Si estamos estamos conectados con una sesión remota de shell:

openhab-cli console

Mediante ssh, solamente si estamos conectados localmente

ssh -p 8101 openhab@localhost

Por cierto, que las credenciales por defecto son:
usuario: openhab, contraseña: habopen

Archivos de log

El archivo principal de log se encuentra en la siguiente ubicación

 tail -f /var/log/openhab/openhab.log

Ahora bien, para definir qué es lo que queremos que quede registrado, la manera más sencilla es abrir una consola y ajustar el nivel de registro de depuración deseado:

log:set <nivel> <paquete>

Los niveles de depuración están definidos por constantes de este pelo: OFF, ERROR, WARN, INFO, DEBUG, TRACE, DEFAULT

Respecto a los nombres de los paquetes, podemos obtener un listado de la siguiente manera:

list -s

 

Publicado por David en Domótica, Linux, 0 comentarios