[ArchLinux] Retrouver du son

Suite à une mise à jour, j’avais constaté une perte totale de son sur toutes les sorties audio de mon système (toutes celles testées en tout cas). Le wiki ArchLinux indique que par défaut tous les canaux sont muets dans ALSA. J’ai donc tenté de leur « rendre la parole » et la première de trois commandes ci-dessous a suffi:

$ amixer sset Master unmute
$ amixer sset Speaker unmute
$ amixer sset Headphone unmute

Un pense-bête pour servir de référence si le problème survient à nouveau.

Citation [13] – Abbé Sieyès

Les citoyens qui se nomment des représentants renoncent et doivent renoncer à faire eux-même la loi; ils n’ont pas de volonté particulière à imposer. S’ils dictaient des volontés, la France ne serait plus cet État représentatif; ce serait un État démocratique. Le peuple, je le répète, dans un pays qui n’est pas une démocratie (et la France ne saurait l’être), le peuple ne peut parler, ne peut agir que par ses représentants.

Abbé Sieyès, 7 septembre 1789.

RSSHub

Ayant testé un moment la plateforme Instagram et souhaitant être en mesure de suivre les publications d’une sélection de comptes publiques directement dans mes flux RSS, je me suis tourné, après quelques recherches, vers une solution open source plus que prometteuse, à savoir RSSHub.

On peut constater rapidement en parcourant le github du projet que les principaux contributeurs sont d’origines asiatiques, comme l’attestent les caractères. Cela ne nuit en rien au projet, puisque la documentation en langue de Shakespeare est plutôt complète, si ce n’est pour la lecture des commentaires présents dans le code, ou des issues sur Github.

J’ai donc fait le choix de tester cette solution, et pour une fois, plutôt que de l’héberger sur l’une de mes machines, j’ai choisi de suivre la solution GCP décrite dans la documentation du projet. Le but étant de savoir si mon utilisation reste dans le palier gratuit fournit par Google pour l’utilisation d’un App Engine, et surtout, de pouvoir tester facilement l’intégration avec FreshRSS. Enfin dernier point, cela me permet de ne pas me poser la question de l’hébergement d’une solution NodeJS, qui nécessiterait un peu de travail de configuration pour arriver à une situation satisfaisante dans mon infrastructure auto-hébergée.

Commençons par quelques notes concernant la gestion de profils au niveau de l’utilitaire gcloud. En premier lieu, création d’un profil rsshub.

gcloud config configurations create rsshub

Voir le détail de la configuration active.

gcloud config list

Lister toutes les configurations de comptes disponibles.

gcloud config configurations list

Et enfin, activer la configuration rsshub.

gcloud config configurations activate rsshub

Passons ensuite à la préparation du déploiement de l’application. Pour cela, je créé un fichier app.yaml à la racine du projet afin de décrire la façon de déployer le programme sur la GCP et le configurer.

# [START app_yaml]
runtime: nodejs10
basic_scaling:
   max_instances: 1
network:
   forwarded_ports:
       - 80:1200
       - 443:1200
# environment variables section, refer to Settings
env_variables:
   CACHE_EXPIRE: '300'
   HTTP_BASIC_AUTH_NAME: '<username>'
   HTTP_BASIC_AUTH_PASS: '<password>'
#[END app_yaml]

Pour terminer, déploiement de l’application dans App Engine.

gcloud app deploy

À ce stade, je dispose donc d’un RSSHub agissant comme proxy entre mon lecteur de flux RSS et Instagram. Celui-ci est hébergé sur le cloud Google et la faible utilisation ne semble pas dépasser les paliers gratuits, ce qui n’est pas plus mal. RSSHub permet également de générer des RSS pour des comptes Twitter ou encore, pour des résultats de recherche leboncoin; la liste est plutôt bien fournie et semble aller en augmentant.

RSSHub est donc un programme que je trouve particulièrement intéressant pour ne plus dépendre d’un compte ou d’une application téléphone pour consommer du contenu. C’est un véritable gain sur bien des aspects, pour Instagram en tout cas, je note: pas de publicité dans le flux (sauf contenu sponsorisé d’un compte), possibilité de supprimer l’application, donc pas de tentation de l’utiliser pour passer le temps ou en cas d’ennui, pas de pistage (ou en tout cas, moins aisé). Au final, retour à un système qui me convient et que je maîtrise, où l’information arrive quand je l’ai décidé et sans essayer de me rendre accro.

[GCP] Logs du script exécuté au démarrage d’une VM sur Compute Engine

Pour référence, petite note sur la manière de consulter les logs d’exécution d’un script de démarrage attaché à une VM Compute Engine de la Google Cloud Platform (via l’option –metadata-from-file startup-script=<script>).

Sur Container-Optimized OS :

sudo journalctl -u google-startup-scripts.service

Sur les images Debian, CentOS, RHEL, SLES, Container-Optimized OS et Ubuntu :

sudo google_metadata_script_runner --script-type startup --debug

Référence: Exécuter des scripts de démarrage

[ArchLinux] unclutter

Petit pense-bête concernant l’intégration du programme unclutter à mon système ArchLinux. Ce programme ayant pour but de cacher l’affichage du pointeur de la souris après quelques secondes d’inactivité.

L’installation coule de source.

sudo pacman -S unclutter

Démarrage au lancement de la session graphique par ajout dans le fichier .xprofile de la ligne suivante :

# Hide the cursor when idle.
unclutter &

Mon curseur disparaît désormais au bout de quelques secondes. Je n’ai pour l’instant pas détecter de problème de fonctionnement ou de comportement perturbant de réinitialisation de l’emplacement du curseur, tels que mentionnés dans le wiki ArchLinux.