● Demander une adresse IP full stack chez Free pour avoir tous les ports
● Réparation d'un radio réveil impossible à mettre à l'heure et qui affiche 7L7
● Réparation d'une VMC: condensateur HS
● Raspberry Pi en récepteur audio Bluetooth (A2DP audio sink)
● Twitter devient x.com et son logo n'est pas sans rappeler celui x.org
● Enfouissement de pales d'éoliennes: vrai ou faux?
● Mettre à jour Postgresql vers une nouvelle version
● Réduire la taille d'une image de carte SD d'un Raspberry Pi
Bonjour! J'ai enfin réussi ! Le problème résidait dans bluez, malgré les multiples distros que j'ai testé j'avais toujours un conflit quelque part, et là après une énième réinstalle propre et de longues recherches sur toutes les l[...]
Le problème doit venir du réseau Free. Si c'était le VPN de l'entreprise ça ne fonctionnerait pas quelque soit le fournisseur. Et l'IP partagée n'empêche pas l'utilisation d'un VPN, c'est surtout utile si comme moi tu héberges un serveur web et que tu [...]
Bonjour, Merci pour ton blog et toutes ces infos. J'ai un soucis un peu tricky. Depuis quelques semaines (impossible de me rappeler quand exactement), lorsque je suis en télétravail via le VPN de mon entreprise (via ma freebox pop), j'ai des erreurs reseau (fermeture de socket) entre l[...]
Le décollage et le rattrapage du booster vu par les caméras de NASASpaceflight. ▶
D'après un tweet d'Elon Musk, l'explosion serait due à une fuite d'oxygène ou de carburant au dessus du pare-feu d'un des moteurs. Cette fuite trop importante a causée une surpression et serait la cause de l'explosion. Le moment exact de l'explosion à 3'11": [...]
Voilà comment a fini le Ship au niveau des Îles Turques-et-Caïques juste à côté de Cuba. Vidéo 1 ▶
Malheureusement, juste après le rattrapage du booster et ce grand moment d'émotions, le Starship a été perdu. C'était le premier vol de la version 2, on devrait en apprendre davantage dans les prochains jours sur ce qu'il s'est passé. Il ne faut pas oublier [...]
Rattrapage du booster réussi!
C'est confirmé, un petit avion de la NASA est en vol depuis quelques instants au large de l'Australie pour suivre la rentrée atmosphérique du Starship. Lien de suivi sur Flightradar 24.
Merci pour ton retour, je vais faire des recherches dans ce sens.
Sur un serveur Linux avec un partage de fichiers Samba, je voulais que lorsque l'on connecte une clé ou un disque USB il soit automatiquement monté afin d'être accessible par le réseau Samba.
Si les environnements de bureau permettent de réaliser facilement cette opération, dans le cadre d'une installation serveur (sans environnement graphique) c'est plus compliqué. Il existe des paquets permettant de faire ça mais le problème c'est soit qu'il faut installer l'environnement graphique qui va occuper inutilement le disque et la RAM, soit le paquet n'est plus maintenu et est absent des dépôts.
Comme d'habitude, j'ai pas mal galéré pour trouver une solution simple et propre. La solution que j'ai trouvée est d'utiliser les règles UDEV et en plus, il n'y a rien à installer!
UDEV est le gestionnaire de périphériques de Linux et on peut lui faire exécuter des actions à la connexion/déconnexion d'un périphérique. Je ne suis pas familier avec les règles UDEV mais c'est similaire à un script shell.
Voilà les règles UDEV que j'ai écrites. Se connecter en root.
#
# Montage automatique de clés ou disques durs USB
# Créer le fichier: /etc/udev/rules.d/10-usb-drive-automount.rules
#
# Si le périphérique n'est pas une partition (ex: sda1, sda2, sdb1) on quitte ce script
# ATTENTION! ce script est fait pour un Raspberry Pi, sur un autre système il faudra exclure les partitions sd** montés automatiquement pas fstab
KERNEL!="sd[a-z][1-9]", GOTO="usb_drive_automount_end"
# Chemin du dossier où est crée le point de montage
ENV{mount_point}="/media"
# Nom du point de montage
# Le point de montage prends le nom de la partition (ex: sda1) suivi du label de la partition s'il existe
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%k-%E{ID_FS_LABEL}"
ENV{ID_FS_LABEL}=="", ENV{dir_name}="%k"
#
# ACTIONS À L'INSERTION DE LA CLÉ USB
#
# Création du dossier qui va servir de point de montage
ACTION=="add", RUN+="/bin/mkdir -p '%E{mount_point}/%E{dir_name}'"
# Montage de la partition avec "systemd-mount". Ne pas utiliser "mount" car ça ne fonctionne pas
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --options=dmask=000,fmask=000 --owner=nobody --collect $devnode %E{mount_point}/%E{dir_name}"
#
# ACTIONS AU RETRAIT DE LA CLÉ USB
#
# Démontage de la partition
ACTION=="remove", RUN{program}+="/usr/bin/systemd-umount '%E{mount_point}/%E{dir_name}'"
# Suppression du dossier de point de montage
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/rmdir '%E{mount_point}/%E{dir_name}'"
# Sortie du script
LABEL="usb_drive_automount_end"
Tu as juste besoin de créer un fichier dans /etc/udev/rules.d et les modifications s'appliquent instantanément sans redémarrage. La clé USB est automatiquement montée au démarrage si elle est présente.
Si la clé est retirée, le point de montage est supprimé. Si tu veux retirer la clé sans la démonter proprement, vérifie que le voyant de la clé n'indique plus d'activité afin de limiter les pertes de données.
À toi d'adapter ces règles, ici la clé USB est montée dans /media avec pour nom le périphérique (ex: sda1) suivi du nom de volume s'il existe.
Pour débugger, tu peux t'aider de ces commandes:
Afficher les variables d'un périphérique pour les utiliser dans les règles UDEV.
udevadm info <CHEMIN_DU_PÉRIPHÉRIQUE>
Tester les règles appliqués. DEVPATH est le contenu de la variable DEVPATH obtenu par la commande précédente “udevadm info”.
udevadm test <DEVPATH>
Afficher en direct les évènements UDEV
udevadm monitor -u
Afficher les infos détaillés pour débugger à la connexion / déconnexion d'un périphérique. On change la verbosité des logs en les passant mode debug et on affiche les logs système en continu, ce qui signifie que tu verras tous les logs du système en pas uniquement ce qui est en rapport avec UDEV.
udevadm control --log-priority=debug
journalctl -f
Cette modification est perdue lors d'un reboot ou du redémarrage du service udev. Pour repasser les logs en mode normal sans redémarrer, exécuter:
udevadm control --log-priority=info
Bonsoir,
Un grand merci c'est très efficace avec debian11 server,
fonctionne très bien avec Jellyfin.
Encore bon boulot et merci