• Installer ddcutil :
  sudo aptitude install ddcutil
• Charger le module i2c-dev :
  sudo modprobe i2c-dev
• Détecter les écrans :
  sudo ddcutil detect
• Lister les propriétés d'un écran :
  ddcutil capabilities | less
  ddcutil capabilities --bus XX | less
• Vérifier la source d'un écran :
  ddcutil getvcp 60
  VCP code 0x60 (Input Source ): DisplayPort-1 (sl=0x0f)
• Changer la source d'un écran (vérifier les valeurs possibles via la liste des "capabilities") : ❗
  ddcutil setvcp 60 0x11
  ddcutil setvcp --bus 10 60 0x0f
• Changer la luminosité d'un écran :
  ddcutil getvcp 10
  ddcutil setvcp 10 70
• … ~30 fonctionnalités sur mon écran actuel, dont :
  • Color temperature request
  • Brightness
  • Contrast
  • Input Source
  • Power mode
  • 😍

Sources :

• https://lord.re/posts/50-controller-ecran/
• https://sebsauvage.net/links/?Z-WRLA
• https://wiki.archlinux.org/title/Backlight#External_monitors

Plus qu'à scripter un peu ça. Et espérer que ça fonctionne également avec le vidéo proj 🤞

Liste des variables utilisables dans un unit systemd.

WIP

Vosk

• Les fichiers utilisés dans ce tuto : https://www.mediafire.com/folder/fl511k0sieq2e/Fichier+reco
• Les exemples d'utilisation du projet Vosk : https://github.com/alphacep/vosk-api/tree/master/python/example
• Les modèles de langues disponibles : https://alphacephei.com/vosk/models
• Doc d'installation : https://alphacephei.com/vosk/install
• Forum gladys 4 − reconnaissance vocale : https://community.gladysassistant.com/t/gladys-4-reconnaissance-vocale/5157/44?page=2

Kalliope

• Qui semble également très bien d'après la vidéo présente dans le README.md : https://github.com/kalliope-project/kalliope
• Sans réelles activités depuis ~1 ans 😥
• Évoqué ici : https://quotech-23.webself.net/blog/2020/04/24/kalliope-lassistant-vocal-sur-mesure
• Elle a même réussit à intégrer Vosk pour en faire un speech-to-text : https://quotech-23.webself.net/blog/2020/04/24/integration-de-vosk-a-kalliope
• Un des problèmes majeurs semble être l'arrêt du développement de Snowboy utilisé jusque là pour détecter le réveil… voir les tickets en lien avec ce trigger
• La vidéo donne envie… Mais ça semble particulièrement compliqué de mettre les mains dedans et en plus de réussir à en sortir quelques choses de fonctionnel… Avec Vosk, c'est relativement basique (pour le moment ?) et je bricole/apprends du Python ^^

Hassil

• https://github.com/home-assistant/hassil
• Assistant audio pour Home Assistant.
• Semble très orienté domotique et passablement compliqué à avoir en standalone.

Voice-assistant by hwpoison

• https://github.com/hwpoison/voice-assistant
• Assistant "basique" (>25 commits) mais bien plus évolué et propre que ce que je peux faire pour l'instant 😅
• Les commandes/actions/… sont à écrire dans un fichier .json (dommage ça n'autorise pas les commentaires…).
• Développé sous/pour Windows, mais ça s'adapte assez facilement (en modifiant le utils.py).
  • autoit pour remplacer Pyautoit ?
• Pensé pour le multi-langue 👍
• Ça ne correspond pas tout à fait à mon besoin mais c'est du Python avec plein de choses qui me manquent et qui pourraient donc me servir (liste des entrées/sorties, TTS, parsing d'un fichier de configuration, la façon de dev,…).

Rhasspy

• https://github.com/rhasspy/rhasspy
• Semblait un peu au point mort depuis septembre 2022.
• Mais home-assistant va visiblement tenter de l'intégrer à partir de 2023 dans sa solution logicielle : https://www.home-assistant.io/blog/2022/12/20/year-of-voice/
• À suivre.

Autres

• La liste des projets Github avec Vosk : https://github.com/topics/vosk?o=desc&s=updated

Le paquet systemd ne fournit visiblement plus le fichier linuxx64.efi.stub que j'utilise pour créer mes noyaux EFI Stub, c'est maintenant (depuis quand… ?) disponible dans le paquet systemd-boot-efi !

Ça a été l'occasion de réécrire quelques lignes sur comment refaire ses noyaux EFI Stub depuis le mode rescue 😅

Pour rappel, "EFI Stub" permet de créer des noyaux "complets" directement utilisables par UEFI, et donc, de se passer de Grub ! :)

Pour vérifier les versions disponibles sur son système :
strings /lib/x86_64-linux-gnu/libm.so.6 | grep GLIBC
…
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_PRIVATE

Si la version souhaitée n'est pas disponible, il y a plus qu'à mettre à jour son OS ou à installer la version souhaitée depuis : http://ftp.gnu.org/pub/gnu/glibc/

Comment contrôler MPV "à distance".

Parce que :

1. Je n'utilise que trop rarement un gestionnaire de fichier graphique.
2. C'est assez léger (~18 paquets supplémentaires pour ~31M d'espace disque).
3. Nemo précedemment installé nécessitait 67 paquets supplémentaires le tout pour ~85M d'espace disque en plus de venir avec plein de cochoneries (gvfs, udisks2,…).
4. Parce Alacritty, tmux, vim, mv, ls,… c'est quand même vachement plus adapté à mon usage :)

Ou comment passer d'un système Proxmox qui consomme ~980M de RAM à ~570M.

Quelques services "inutiles" dans la cas d'un serveur Proxmox isolé et/ou avec peu de ressources :

• pve-ha-crm : Proxmox-Cluster-Ressource-Manager
• pve-ha-lrm : Proxmox-Local-Ressource-Manager
• pve-firewall : Proxmox Firewall
• pvfw-logger : Proxmox Firewall Logger
• spiceproxy : Proxmox-Spice-VM-connection
• pvesr : Proxmox-Replication

Et pour arrêter tout ça :
sudo systemctl stop pve-ha-crm.service
sudo systemctl stop pve-ha-lrm.service
sudo systemctl stop pve-firewall.service
sudo systemctl stop pvfw-logger.service
sudo systemctl stop spiceproxy.service
sudo systemctl stop pvesr.service

Désactiver les units au niveau de systemd serait préférable, mais il y a beaucoup d'inter-dépendances avec les autres services Proxmox "utiles". Seul pvesr peut être désactivé sans trop foutre la merde…

Quick and dirty fix : Arrêter ces services quelques secondes après le démarrage du serveur… 👍

EDIT : Il vaut mieux éviter de couper pve-cluster 😅

Exemple d'erreur rsync obtenue récemment :
deflate on token returned 0 (1326 bytes left)
rsync error: error in rsync protocol data stream (code 12) at token.c(476) [sender=3.2.3]
rsync: connection unexpectedly closed (117 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [receiver=3.1.3]
rsync: connection unexpectedly closed (117 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [generator=3.1.3]
zsh: exit 12 rsync -avz --progress -e "ssh -p 22"

1. Vérifier le protocole de rsync sur chaque machine :
   rsync --version
   rsync version 3.1.3 protocol version 31
2. Si les protocoles diffèrent, utiliser le protocole le plus bas (option --protocol) :
   rsync --protocol=31 …
3. Vérifier les algorythmes de compression supportés (si listés avec --version), sinon simplement désactiver la compression (option --compress ou -z).
4. Si ça démarre, essayer avec l'ancienne compression (option --old-compress) :
   rsync --old-compress

Avec la "récente" faille log4Shell il est maintenant demandé de filtrer tout le contenu des serveurs.

1. Proxy sortant au niveau du système, via /etc/profile :

   MY_PROXY_URL=http://proxy.tld:PORT
   HTTP_PROXY=$MY_PROXY_URL
   HTTPS_PROXY=$MY_PROXY_URL
   FTP_PROXY=$MY_PROXY_URL
   http_proxy=$MY_PROXY_URL
   https_proxy=$MY_PROXY_URL
   ftp_proxy=$MY_PROXY_URL
   export MY_PROXY_URL HTTP_PROXY HTTPS_PROXY FTP_PROXY http_proxy https_proxy ftp_proxy

2. Pour APT, via /etc/apt/apt.conf.d/proxy.conf :

   Acquire {
   HTTP::proxy "http://proxy.tld:PORT";
   HTTPS::proxy "http://proxy.tld:PORT";
   }

3. Pour YUM, via /etc/yum.conf :
   proxy=http://proxy.tld:PORT

4. Pour les services systemd via :

   systemctl edit my-service

   [Service]
   Environment="HTTP_PROXY=http://proxy.tld:PORT/"
   Environment="HTTPS_PROXY=http://proxy.tld:PORT/"

   systemctl restart my-service

Impossible d'envoyer des données (et donc de partager un torrent) depuis transmission à cause de cette satanée erreur !

Possiblement lié à une "amélioration" de youteub : https://blog.youtube/inside-youtube/new-era-video-infrastructure/

MPV

1. Issues sur le dépôt du projet :
   • mpv slow download speed? − https://github.com/mpv-player/mpv/issues/8655
   • youtube-dl is dead, add yt-dlp as default − https://github.com/mpv-player/mpv/issues/9208

2. Fix :

   • Installer yt-dlp : sudo aptitude install yt-dlp
   • Tester en utilisant l'option --script-opts=ytdl_hook-ytdl_path=yt-dlp mpv : `mpv --script-opts=ytdl_hook-ytdl_path=yt-dlp "YT_URL"
   • Si c'est bon, créer un fichier de configuration pour MVP (~/.config/mpv/mpv.conf) et ajouter :

   script-opts=ytdl_hook-ytdl_path=yt-dlp

Youtube-dl

1. Issues sur le dépôt du projet :
   • [YouTube] Randomly slow youtube download speed − https://github.com/ytdl-org/youtube-dl/issues/29326
   • My downloadspeed of my Youtube Downloads are being reduced/limited. What is the Problem? − https://github.com/ytdl-org/youtube-dl/issues/29361
2. Fix :
   • Idem, installer et passer à yt-dlp… : sudo aptitude install yt-dlp
   • Je ne sais pas encore si ça fait tout "aussi bien/pareil", mais au moins ça permet de lire les vidéos YouTube… 👍
   • Ajouter un alias youtube-dl="yt-dlp" ?

Kodi

1. Issues avec l'extension YouTube pour Kodi (plugin.video.youtube) :
   • Buffering when playing − https://github.com/anxdpanic/plugin.video.youtube/issues/211
2. Fix :
   • Le problème semble résolut à partir de la version 6.8.18.alpha3. Mais ça nécessite quand même encore quelques tests pour éviter des régressions ou autres pertes de fonctionnalités…

Bon… tout n'est pas résolut mais ça progresse.

Réaliser pour corriger une limitation lorsque Grub est installé directement sur un LVM, j'ai dû diviser la première partition de mon disque en deux plus petites puis ré-ordonner les partitions.

Tout ça s'est magnifiquement bien déroulé… "troublant" :)

Et ddclient est toujours vivant :) Pfiu, ~7 ans depuis la dernière utilisation. Mais bon, tant que des FAI fourniront un service "passable"… (ip non fixe, box,…).

Et en bonus ça fonctionne bien avec une petite commande dig :

# /etc/ddclient.conf

daemon=2
protocol=dyndns2

use=cmd,cmd="dig +short myip.opendns.com @resolver1.opendns.com"

server=www.ovh.com
login=identifiant DynHost OVH
password=mot de passe lié à l'identifiant DynHost
sous-domaine.domain.tld

Changement de serveur DNS @home et les conteneurs Docker n'arrivaient plus à accéder à internet.

Dans les conteneurs, le fichier /etc/resolv.conf contenait effectivement les informations liées au précédent serveur DNS (IP,…).

Pour corriger ça, éditer le fichier /etc/docker/daemon.json sur l'hôte et redémarrer pour vérifier que tout fonctionne correctement.

Comment détecter/vérifier si un câble est connecté sur un poste Linux depuis la ligne de commande.

Je fais pas souvent d'installations Linux pour un utilisateur standard, quelques liens potentiellement utiles pour les utilisateurs graphiques friendly:

• https://lehollandaisvolant.net/linux/checklist/
• https://github.com/yeKcim/complique-comme-manjaro
• https://sebsauvage.net/wiki/doku.php?id=mint_customization_19_3#apparence_comportement
• https://sebsauvage.net/wiki/doku.php?id=ubuntu2104#configuration_apres_redemarrage

Les logs susceptibles d'apparaître pour un service systemd dans un conteneur LXC :

Mar 31 15:19:26 MYHOST systemd[7683]: MY_APP.service: Failed to set up mount namespacing: Permission denied
Mar 31 15:19:26 MYHOST systemd[7683]: MY_APP.service: Failed at step NAMESPACE spawning /usr/sbin/MY_APP: Permission denied

Les logs Apparmor susceptibles d'apparaître sur l'hôte :

Mar 31 13:19:26 ks10 audit[15289]: AVC apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-42_</var/lib/lxc>" name="/run/systemd/unit-root/" pid=15289 comm="(MY_APP)" srcname="/" flags="rw, rbind"
Mar 31 13:19:26 ks10 kernel: audit: type=1400 audit(1617196766.574:196): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-42008_</var/lib/lxc>" name="/run/systemd/unit-root/" pid=15289 comm="(MY_APP)" srcname="/" flags="rw, rbind"

Les solutions pour "résoudre" ce problème :

1. Activer l'option nesting pour ce conteneur LXC.
2. Modifier les options du service systemd :
   • Tester les différentes options :

     PrivateDevices=no
     PrivateMount=no
     PrivateTmp=no
     NoNewPrivileges=no
     ProtectHome=no
     ProtectSystem=no
     ProtectKernelTunables=no
     ProtectKernelModules=no
     ProtectControlGroups=no

   • Puis recharger la configuration de systemd :
     sudo systemctl daemon-reload
   • Et redémarrer le service :
     sudo systemctl restart MY_APP.service

En commençant par le moins consommateur en courant :
echo disk | sudo tee /sys/power/state
echo deep | sudo tee /sys/power/mem_sleep && echo mem | sudo tee /sys/power/state
echo freeze | sudo tee /sys/power/state

Si déjà configuré, une requête WakeOnLan permet de réveiller la machine depuis l'un de ces états.