Utilisé dans Ansible pour récupérer automatiquement l'UUID de la partition actuellement montée sur /boot :

  - name: '/boot'
    # Get UUID from device currently mounted to /boot
    src: "UUID={{ ansible_mounts | json_query('[?mount == `/boot`] | [0].uuid') }}"
    fstype: 'ext3'
    opts: 'defaults,ro,nodev,nosuid,noexec'

Afin de lui coller automatiquement quelques options lors d'une installation 👍 :)

objcopy below image base no efi bootable devices

Du jour au lendemain, l'UEFI qui veut plus démarrer mon système Debian…

Ma configuration :

• Un noyau unifié EFI - kernel efi stub;
• Plus de grub installé depuis 3~4 ans 👍

Problème :

• Au démarrage, peu importe l'entrée UEFI sélectionnée, le résultat restait : No bootable devices found…

Comportement attendu :

• Démarrage de Linux;
• Prompt pour entrer ma passphrase Luks;
• Fin du démarrage de Debian et atterrissage dans tty1 👍

Version courte

J'ai dû mettre à jour ma commande ''objcopy'' afin qu'elle tienne compte de "l'adresse" du fichier de base et par la même occasion de la taille des différentes sections ajoutées. Cette nouvelle commande fonctionne :

osrel_offs=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}')
cmdline_offs=$((osrel_offs + $(stat -Lc%s "/usr/lib/os-release")))
linux_offs=$((cmdline_offs + $(stat -Lc%s "/proc/cmdline")))
initrd_offs=$((linux_offs + $(stat -Lc%s "/boot/vmlinuz-6.3.0-1-amd64")))

objcopy \
        --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \
        --add-section .cmdline="/proc/cmdline" --change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \
        --add-section .linux="/boot/vmlinuz-6.3.0-1-amd64" --change-section-vma .linux=$(printf 0x%x $linux_offs) \
        --add-section .initrd="/boot/initrd.img-6.3.0-1-amd64" --change-section-vma .initrd=$(printf 0x%x $initrd_offs) \
        /usr/lib/systemd/boot/efi/linuxx64.efi.stub /boot/efi/EFI/debian/debian.6.3.0-1.efi

La dernière version de cette commande est présente dans mon script create-efi-kernel qui s'occupe également de "plein" d'autres trucs afin d'avoir automatiquement les noyaux unifiés à partir des noyaux Linux disponibles, d'ajouter les entrées efi correspondantes, nettoyées les anciennes,…

Version longue

Ma précédente commande avec des valeurs d'adresses fixes qui fonctionnait jusqu'à systemd ≤ 253 :

objcopy \
        --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=0x20000 \
        --add-section .cmdline="/proc/cmdline" --change-section-vma .cmdline=0x30000 \
        --add-section .linux="/boot/vmlinuz-6.3.0-1-amd64" --change-section-vma .linux=0x2000000 \
        --add-section .initrd="/boot/initrd.img-6.3.0-1-amd64" --change-section-vma .initrd=0x3000000 \
        /usr/lib/systemd/boot/efi/linuxx64.efi.stub /boot/efi/EFI/debian/debian.6.3.0-1.efi

Mais qui pose problème à partir de systemd 254, en m'indiquant des "erreurs" :

objcopy: /boot/efi/EFI/debian/debian.efi:.osrel: section below image base
objcopy: /boot/efi/EFI/debian/debian.efi:.cmdline: section below image base
objcopy: /boot/efi/EFI/debian/debian.efi:.linux: section below image base
objcopy: /boot/efi/EFI/debian/debian.efi:.initrd: section below image base

Ça tient plus du warning parce que la commande se termine correctement… (code retour = 0 🤦).
Et ça me donne un noyau "debian.efi" qui fait la même taille que d'habitude…

➡️ Je vais donc tenter de récupérer le fichier /usr/lib/systemd/boot/efi/linuxx64.efi.stub pour chaque version de systemd (celle qui fonctionnait et la nouvelle) pour comparaison + le détails du cheminement pour y arriver.

1. Vérifier le paquet qui contient le fichier recherché :

apt-file search /usr/lib/systemd/boot/efi/linuxx64.efi.stub
systemd: /usr/lib/systemd/boot/efi/linuxx64.efi.stub
systemd-boot-efi: /usr/lib/systemd/boot/efi/linuxx64.efi.stub

• ➡️ Dans les récentes versions de systemd, le "boot-efi" a été envoyé dans un paquet dédié, on va donc se focaliser sur systemd-boot-efi.

2. Vérifier les version de systemd-boot-efi disponible :

apt-cache policy systemd-boot-efi
systemd-boot-efi:
  Installed: 254~rc2-3
  Candidate: 254~rc2-3
  Version table:
 *** 254~rc2-3 500
        500 http://deb.debian.org/debian sid/main amd64 Packages
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     253.5-1 100
         -1 http://deb.debian.org/debian trixie/main amd64 Packages
…

• ➡️ La version actuellement installée, 254~rc2-3 c'est celle qui ne fonctionne pas. On va donc tenter de récupérer la version disponible dans Debian Trixie.

3. Télécharger la version 253 et extraire le fichier linuxx64.efi.stub de ce premier paquet :

aptitude download systemd-boot-efi=253.5-1
ar p systemd-boot-efi_253.5-1_amd64.deb data.tar.xz | tar xJ -C . --strip-components=6 ./usr/lib/systemd/boot/efi/linuxx64.efi.stub
mv linuxx64.efi.stub linuxx64.efi.stub.253

4. Idem pour la version 254 :

aptitude download systemd-boot-efi/unstable
ar p systemd-boot-efi_254\~rc2-3_amd64.deb data.tar.xz | tar xJ -C . --strip-components=6 ./usr/lib/systemd/boot/efi/linuxx64.efi.stub
mv linuxx64.efi.stub linuxx64.efi.stub.254

5. Et maintenant si je compare la "taille + offset" des deux fichiers linuxx64.efi.stub.253 et linuxx64.efi.stub.254 :

objdump -h "/tmp/linuxx64.efi.stub.253" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}'
 82187

objdump -h "/tmp/linuxx64.efi.stub.254" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}'
 5603209336

6. Ah bah oui… 😅 82187 vs 5603209336 ! Le message d'objcopy est donc cohérent.

En vrai, ci-dessus c'est quand même une version condensée/expliquée du problème… Le cheminement pour arriver jusque là a été un poil plus long et "stressant"…

1. Plusieurs passages en mode rescue.
2. La crainte d'un défaut de l'UEFI (on est pas à l'abri sur les Dell…).
3. Recherche de bug/documentation/… pas très fructueuse (une recherche "noyau unifié + debian" c'est pas la panacée, heureusement il y a ArchLinux et Gentoo).
4. Même le manuel Debian qui évoque un assemblage de ce type de noyau utilise potentiellement des valeurs d'adresses trop petites 😀
5. Vérification des derniers paquets mis à jour (en regardant la fin du fichier /var/log/apt/history.log).
6. Via le mode rescue, un petit downgrade de tous les récents paquets systemd qui ont été mis à jour et là j'arrive bien à générer des noyaux fonctionnels ! Début de piste…
7. Maintenant que j'ai accès à mon système la recherche d'info sur le net et les tentatives de génération de noyaux sont plus simples ! J'augmente au fur et à mesure la valeur de chaque adresse jusqu'à ne plus avoir ce warning. Oh "miracle", j'ai un noyau généré sans "erreurs" ! Je tente le boot et obtiens un message d'erreur différent "kernel not found". Ok, donc lien de cause à effet confirmé :)
8. Délivrance avec le wiki ArchLinux et la génération manuelle des noyaux unifiés qui calcule la taille de l'image et de chaque sections (la solution détaillée ci-dessus) 👌

Conséquences

1. J'ai perdu un peu de temps…
2. Les adresses utilisées par chaque section sont maintenant cohérentes et moins sujettes à problème 🤞
3. Je conserve maintenant quelques versions des noyaux unifiés précédents. Comme ça si les derniers plantent, je peux toujours m'ajouter manuellement une entrée EFI qui pointe vers un précédent noyau (théoriquement) fonctionnel et "retrouver" mon système ! 🤞🤞
4. TODO: Il faut que j'investigue sur Dracut et la possibilité d'avoir des noyaux signés et ainsi pouvoir activer le SecureBoot…
5. J'ai "appris" la possibilité d'ajouter un splash screen dans un noyau unifié. Bon par contre, c'est forcément en bmp (d'après le peu de tests que j'ai réalisé) donc ça alourdit quand même le noyau pour un intérêt limité… J'ai déjà pas de gestionnaire de session, alors le fait de voir un logo Debian pendant deux secondes au démarrage… ¯_(ツ)_/¯

• 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 🤞

Comment avoir un bind Tmux à base de 2 touches :)

Exemple pour source un fichier avec <prefix> + s + i :

unbind s
bind-key -T prefix s switch-client -T prefix_s
bind-key -T prefix_s i source-file ~/.tmux/splitAUTHENTICATION

Nan mais à force de pas pratiquer, on oublie à quoi ça peut (doit ?) ressembler un OS "grand public"…

• Après une mise à jour, touchpad qui ne fonctionne plus. Mais plus du tout, pu de déplacement, plus de clic gauche/droit…

  • Un reboot : quedal.
  • La touche de fonction censée (dés)activer le bousin ? Absente du clavier.
  • Dans le doute… aucune touche de fonction/FXX ne résout le problème.
  • "Solution" de Micro$oft ? Désinstaller le pilote et redémarrer 👌 Et dans les instructions, il y a "Cliquez avec le bouton droit…" 🤣

• Les redémarrages… NAN MAIS LES SALETÉS DE REDÉMARRAGES… C'est l'action que j'ai le plus fais sur cet OS aujourd'hui…

• Dans un registre plus "admin"… La génération d'une paire de clef SSH sans phrase de passe : ssh-keygen -b 2048 -t ed25519 -f C:/temp/sshkey -q -N ""

  • Dans CMD fonctionne ✅
  • Dans "Power"Shell ne fonctionne PAS ❗😫
  • La "solution" ? ssh-keygen -b 2048 -t 25519 -f C:/temp/sshkey -q -N '""' aka : quote simple '; suivi des deux guillemets doubles ""; terminé par une quote simple ' 🤦

Windows ou comment dégouter les utilisateurs de l'informatique… #nechangezrien

Tout ça pour (enfin) arriver à :
ffmpeg -i INPUT.mkv -c:v libx265 -preset fast -crf 28 -c:a copy -c:s copy -map 0:v -map 0:a:0 -map 0:s OUTPUT.x265.mkv

➡ Convertir en H265 (obvsiouly)
➡ Conserver uniquement la première piste audio
➡ Conserver tous les sous-titres intégrés
➡ Conserver les codecs d'origine pour l'audio et les sous-titres

Par défaut dans Kodi, les commandes pause, play et toggle font la même chose, un phucking TOGGLE ! 😑

Donc pour envoyer une vraie commande pause… :

• Vérifier le type de média dans la playlist (si playlist) : curl -s -X POST http://"${KODI_HOST}:${KODI_PORT}"/jsonrpc -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"Player.GetActivePlayers","id":0}' | sed -n 's/.*"type":"\(.*\)".*/\1/p'
• Récupérer la vitesse de lecture d'un média audio : curl -s -X POST http://"${KODI_HOST}:${KODI_PORT}"/jsonrpc -H 'Content-Type: application/json' --data '{"jsonrpc": "2.0", "method": "Player.GetProperties", "params": { "playerid": 0, "properties": [ "speed" ] }, "id": "AudioGetItem" }' | sed -n 's/.*"speed":\(.\).*/\1/p'
• Récupérer la vitesse de lecture d'un média video : curl -s -X POST http://"${KODI_HOST}:${KODI_PORT}"/jsonrpc -H 'Content-Type: application/json' --data '{"jsonrpc": "2.0", "method": "Player.GetProperties", "params": { "playerid": 1, "properties": [ "speed" ] }, "id": "VideoGetItem" }' | sed -n 's/.*"speed":\(.\).*/\1/p'
• Vitesse à 0, la lecture est déjà en pause.
• Vitesse à 1, le média est en cours de lecture.

Pfiu comment j'ai galéré 😆

• quelques exemples de requêtes vers l'API de Kodi
• un script kodi-cli qui donne d'autres exemples

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

Comment vérifier que la passphrase d'une clef GPG a bien été saisie.

Problème rencontré : Lorsque mon ordi passe en veille pendant >60 minutes, l'agent GPG ne dispose plus de clef GPG valide (TTL fixé à 60 minutes). Et donc, si je ne resaisi pas ma passphrase assez rapidement, mon service vdirsyncer va se lancer et tenter des commandes GPG pour récupérer les identifiants qui vont bien pour communiquer avec mes services distants…

Sauf que si une commande gpg est lancée sans passphrase valide, gpg va la demander cette passphrase… et donc :

1. bloquer vdirsyncer
2. bloquer la saisie de passphrase…

En ajoutant une petite vérification qu'une clef GPG est bien dans le cache de l'agent GPG avant d'utiliser les commandes qui vont bien pour récupérer mes identifiants, ça ne bloque plus 👌

La configuration de vdirsyncer est disponible ici : https://wiki.101010.fr/doku.php?id=documentation:securite:vdirsyncer#configuration
vdirsyncer : Permet de synchroniser des ressources CardDAV/CalDAV/… distantes en local 👍

Et en dehors de vdirsyncer :
gpg-connect-agent 'keyinfo --list' /bye 2>/dev/null | awk 'BEGIN{CACHED="nok"} /^S/ {if($7==1){CACHED="ok"}} END{if(CACHED=="ok"){exit 0} else {exit 1}}'

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

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" :)

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.

Redimensionner la taille d'un système BTRFS présent dans un LV

Aaaahhhh ! Pourquoi j'ai pas vu plus tôt que ça existait !

Entre cette nouvelle (pour moi…) intégration à Git (utile quand pas d'accès SSH !) et rofi-pass qui me permet d'utiliser ma base password-store partout… Ça va être compliqué de passer à autre chose…

"partout" :

• Tous les navigateurs et sans extension. Toutes les applications susceptibles d'avoir des champs à remplir.
• Même pour authentifier des connexions git précédemment à coup de sleep/delay ^^
• Possibilité de modifier la façon dont vont être saisi les identifiants à coup de tabulation/retour chariot/délais/…. Le site des impots par exemple… (autotype: user :delay 1 :enter pass :enter) :
  1. Saisir l'identifiant.
  2. Valider
  3. Patienter une seconde
  4. Saisir le mot de passe
  5. Valider

Remplace sans problème ma vieille configuration à base de ifscheme…

• une excellente documentation :
• Dokuwiki dédié à iwd sur kernel.org : https://iwd.wiki.kernel.org/start
• Page dédiée à la génération aléatoire d'adresse MAC : https://iwd.wiki.kernel.org/addressrandomization
• Page dédiée aux fichiers de configuration par connexion : https://iwd.wiki.kernel.org/networkconfigurationsettings
• Page wiki ArchLinux dédiée à iwd : https://wiki.archlinux.org/index.php/Iwd
• wiki ArchLinux Génération aléatoire d'adresse Mac avec iwd : https://wiki.archlinux.org/index.php/MAC_address_spoofing#iwd
• Page wiki ArchLinux dédiée à systemd-networkd : https://wiki.archlinux.org/index.php/Systemd-networkd

kodi-send (disponible dans kodi-eventclients-common ou kodi-eventclients-kodi-send sous Debian) permet d'envoyer des commandes à un Kodi (au moins local).

• Liste des fonctions Kodi : https://kodi.wiki/view/List_of_built-in_functions#List_of_functions

• Liste des actions : https://kodi.wiki/view/Action_IDs

• Exemples :

  kodi-send --action="PlayerControl(play)"
  kodi-send --action="PlayerControl(partymode)"
  kodi-send --action="PlayerControl(next)"
  kodi-send --action="PlayerControl(previous)"

• Associé à un autre petit script (qui mixe youtube-dl et kodi-send), c'est aussi possible d'envoyer directement des adresses YouTeub : https://github.com/NapoleonWils0n/ubuntu-bin/blob/master/yank

• Je découvres également qu'il y a un petit script intégré dans le dépôt Github de Qutebrowser pour envoyer des liens vers Kodi directement depuis le navigateur : https://github.com/qutebrowser/qutebrowser/blob/master/misc/userscripts/kodi

Simple outil de notification.

Bon… pas certain d'avoir envie de me tapper des notifications sur mon système… Mais ça peut être pas mal pour la luminosité ou le son :)

From : https://www.reddit.com/r/unixporn/comments/fkxeqr/i3gaps_neomutt_taskwarrior_khal_nvim_zathura/

Un peu passé à côté de la simplification des rebonds avec SSH (précédemment avec ProxyCommand).

https://www.redhat.com/sysadmin/ssh-proxy-bastion-proxyjump

Vraiment plus simple ?

• En ligne de commande :

  ssh -J first.jump.host,second.jump.host,….jump.host fqdn.remote.host

• Et dans un fichier ~/.ssh/config :

  Host remote.final.host
  hostname fqdn.remote.host
  ProxyJump first.jump.host,second.jump.host,….jump.host
  #LocalForward  8080  127.0.0.1:8080

  • Simplement suivi de ssh remote.final.host.

On va donc dire oui comparé à ProxyCommand :

ProxyCommand ssh first.jump.host nc %h %p 2> /dev/null