Journal Ethernet, Udev, systemd et CUPS sont dans un bateau, tout le monde saute à l’eau

Posté par  . Licence CC By‑SA.
Étiquettes :
73
6
fév.
2025

Sommaire

Une histoire pleine d’aventure où l’on commence par un problème, puis sa solution, puis après cette solution, l’envie de résoudre d’autres problèmes.

Préambule

Je ne contribue pas beaucoup à la vie de LinuxFr alors que j’en apprécie beaucoup la lecture. J’ai toujours l’impression de n’avoir pas grand chose de bien intéressant à raconter. Heureusement une série de journaux récents à la pertinence tout à fait discutable me rend la comparaison moins impressionnante. Même si, parmi les journaux listés précédemment, l’un d’eux est plus impertinent qu’inutile et m’a quand même bien fait rire1. En plus, il m’est arrivé des trucs avec mon ordinateur récemment. Alors, allez, je vous raconte.

D’abord un peu de contexte, j’avais depuis un certain temps une station d’accueil pour mon ordinateur portable au bureau, qui attendait dans une armoire. Commandée en même temps que l’ordinateur, elle a très mal fonctionné dès le moment où mon service info me l’a filée, et elle donc a rapidement été remplacée avec davantage de succès par un simple adaptateur USB vers ethernet+USB+HDMI. Sauf que ces adaptateur qu’on transporte facilement se prêtent et se perdent aussi facilement qu’ils se transportent et qu’un triste jour de longues réunions en visio je suis venu à en manquer. J’ai donc mis dans mon sac celui qui trônait sur mon bureau et pris mon courage à deux mains pour essayer de faire fonctionner ma station d’accueil.

Le problème

Cette station d’accueil prétend pouvoir faire de l’« Ethernet Pass-through ». Le nom en jette parce-que c’est un pur truc marketing. En fait, c’est juste une solution pour se connecter au réseau avec la station d’accueil en utilisant l’adresse MAC de la carte réseau de l’ordinateur portable connecté à la station, sauf que c’est une technologie exclusive à un constructeur. Comme toute technologie propriétaire, le fonctionnement est parfois peu fiable, mais plus souvent encore complètement inopérant. Effet bonus, comme le constructeur est tout content de vendre sa formule super tip-top, il se fiche qu’on puisse faire aussi bien sans utiliser sa technologie à lui en indiquant juste une adresse MAC à cloner dans les réglages réseau du système. Fort de sa techno à lui, il fournit donc des pilotes qui ne marchent qu’à moitié pour changer l’adresse MAC de ses stations d’accueil. Après avoir sollicité la sagesse des moules déhèlefpiennes sur le forum, j’ai compris (et même compris pourquoi) il fallait que j’active le mode « promiscuous » sur la connexion réseau de la station pour que je puisse utiliser sa connexion avec une autre adresse MAC que celle d’origine. C’était une belle histoire, mais ce n’est pas celle que je vais vous raconter aujourd’hui.

L’histoire du jour, c’est que sur mon réseau au taf, je ne peux me connecter qu’avec un adresse MAC validée, à savoir celle de la carte de l’ordinateur portable, et non celle de la station. Vu ma situation, il faut donc que j’active le mode « promiscuous » avant de chercher à me connecter au réseau. Des recherches en ligne disent comment régler de manière permanente une interface réseau en mode promiscuous depuis NetworkManager Dispatcher, mais ces solutions ne fonctionnent pas si vous avez besoin que l’interface soit en mode « promiscuous » avant d’établir la connexion ou si l’interface réseau n’est pas présente à chaque démarrage du système (j’utilise aussi mon ordinateur sans sa station d’accueil). Impossible donc d’indiquer ce réglage dans NetworkManager (ni dans ceux de NetworkManager Dispatcher).

La solution…

Finalement, elle est plutôt simple, même si j’ai mis beaucoup de temps à la trouver : ajouter une règle udev :

cat > /etc/udev/rules.d/50-ethstation.rules << EOF
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ad:re:ss:em:ac:do:ri:gi:ne", NAME="ethstation"
   RUN+="/usr/bin/ip link set ethstation promisc on"
EOF

où « ad:re:ss:em:ac:do:ri:gi:ne » est l’adresse MAC de la carte de la station d’accueil. Cette règle exécute une commande qui active le mode "promiscuous" au moment ou l’interface apparaît (c’est-à-dire quand on branche l’ordinateur sur sa station d’accueil) et en profite pour donner un nom explicite à l’interface réseau "ethstation" ce qui facilite un peu la vie pour régler NetworkManager ensuite.
Au cas où je démarre avec la station d’accueil déjà branchée à l’ordinateur, j’ajoute aussi la règle udev dans l’initramfs (ici avec l’outil initramfs-tools qui génère l’initramfs sur une Debian) :

cat > /etc/initramfs-tools/hooks/ethstation << EOF
#!/bin/sh

case $1 in
prereqs)
    echo "udev"
    exit 0
    ;;
esac

. /usr/share/initramfs-tools/hook-functions

mkdir -p $DESTDIR/lib/udev/rules.d/
for rules in 50-ethstation.rules; do
    if   [ -e /etc/udev/rules.d/$rules ]; then
        cp -p /etc/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
    fi
done
EOF

update-initramfs -u

Et voilà, maintenant dès que je branche ma station d’accueil en USB, son interface réseau apparaît avec le nom « ethstation » et est tout de suite mise en mode « promiscuous », et dans mes réglages NetworkManager, j’ai activé le clonage d’adresse MAC pour cette connexion.

… mais ce n’est pas fini !

Mon probème est résolu, mais comme j’ai galéré pour le régler, entre temps je me suis péter de la lecture sur NetworkManager Dispatcher et systemd et ça m’a donné une autre idée. Pour faciliter l’utilisation des imprimantes sur le réseau du boulot, notre service info a installé un serveur d’impression CUPS qui expose les imprimantes. Donc quand je suis au taf, un coup de :

cat > /etc/cups/client.conf << EOF
ServerName 192.168.1.1
EOF

où « 192.168.1.1 » est l’adresse du serveur d’impression, et j’ai accès aux imprimantes, sans me soucier des pilotes, y compris quand le parc d’imprimantes est renouvelé et que les modèles changent.

Problème de cette solution, quand je ne suis pas connecté au réseau du boulot, le serveur est injoignable et dès que je tente de lancer une impression mes programmes figent pendant presque une minute en attendant le time-out avant de se rabattre sur le serveur local et me permettre d’imprimer. Donc, quand je suis sur un autre réseau que celui du boulot, j’ajoute un petit « # » devant « ServerName » pour commenter ce réglage. C’est laborieux, et chaque fois que j’oublie la manip’, la punition dure une minute à attendre que CUPS time-out, chaque fois que j’ai oublié d’enlever le maudit croisillon, ou alors je dois redémarrer mes logiciels pour qu’ils rechargent la configuration CUPS client si j’ai laissé le croisillon mais que je suis au taf.

Comme je sais désormais quand je suis connecté au boulot ou ailleurs en fonction de ma connexion via ma station d’accueil, autant utiliser cette information pour mettre à jour mon fichier cups.client. Entre en jeu NetworkManager Dispatcher, avec :

cat /etc/NetworkManager/dispatcher.d/50-cupsserverdutaf << EOF
#!/usr/bin/bash -e
if [[ "$1" = "ethstation" ]] ; then
    case "$2" in
        up)
        /usr/local/bin/cupsserver.sh set-server
            ;;
        down)
        /usr/local/bin/cupsserver.sh unset-server
            ;;
    esac
fi
EOF

cat > /usr/local/bin/cupsserver.sh << EOF
#!/usr/bin/bash -e
case "$1" in
    set-server)
            sed -i ’s/^#*\(ServerName\)/\1/’ /etc/cups/client.conf
        ;;
    unset-server)
            sed -i ’s/^\(ServerName\)/#\1/’ /etc/cups/client.conf
        ;;
esac
EOF

Et pouf, j’ai un petit script /usr/local/bin/cupsserver.sh qui commente ou décommente la ligne "ServerName" dans mes réglages de CUPS en fonction de l’état de ma connexion. Sauf que…

Ce n’est toujours pas fini !

… si je ne débranche pas ma station avant d’éteindre mon ordinateur, le fichier cups.client reste avec le "ServerName" décommenté à l’extinction, et si je suis sur un autre de réseau au prochain démarrage, sblam, punition d’une minute à la prochaine tentative d’impression. Si seulement il existait un logiciel simple et élégant qui permette de gérer l’état du système et de s’assurer de la cohérence de celui lors des phases de démarrage et d’arrêt. Bon, on ne peut pas tout avoir, mais si on enlève les deux premiers qualificatifs, systemd répond au besoin. Donc on va faire appel à lui plutôt que d’appeler le script directement, comme ça, systemd pourra remettre le fichier cups.client dans un état acceptable lors de l’arrêt. C’est reparti :

cat /etc/NetworkManager/dispatcher.d/50-cupsserverdutaf << EOF
#!/usr/bin/bash -e
if [[ "$1" = "ethstation" ]] ; then
    case "$2" in
        up)
                systemctl start cupsserverdutaf.service
            ;;
        down)
                systemctl stop cupsserverdutaf.service
            ;;
    esac
fi
EOF

cat > /etc/systemd/system/cupsserverdutaf.service << EOF
[Unit]
Description=Network CUPS server at mon taf

[Service]
RemainAfterExit=yes
ExecStart=/usr/local/bin/cupsserver.sh set-server
ExecStop=/usr/local/bin/cupsserver.sh unset-server
EOF

Alors attention, ici toute la subtilité est dans le « RemainAfterExit=yes » qui dit à systemd que ce service « tourne » encore même quand le script ExecStart a fini de s’exécuter et qu’il faut donc exécuter le script ExecStop pour arrêter le service au moment voulu. Comme ça, quand on démarre le service systemd exécute /usr/local/bin/cupsserver.sh set-server et considère que le service (qui enregistre ici l’état du système connecté sur station d’accueil) est actif. Et quand on arrête de service, soit via l’appel depuis le script de NetworkManager Dispatcher ci-dessus, soit lors l’arrêt du système, systemd exécute la commande ExecStop.

Conclusions et perspectives

Maintenant, sur le réseau du boulot, dès que je connecte la station, udev met la carte réseau en mode « promiscuous » qui me permet de l’utiliser. Jusqu’ici ce n’est que du contournement de bug pour que NetworkManager puisse lancer le réglage de la connexion. Lorsque celle-ci est établie, NetworkManager Dispatcher s’active et lance un service systemd qui, via un simple script, met à jour le fichier cups.client. Si je me déconnecte du réseau via ma station (si je passe en Wifi par exemple), si je déconnecte la station ou si j’éteints l’ordinateur, le service systemd est arrêté (par NetworkManager Dispatcher ou par la séquence d’arrêt du système) et met à jour le fichier cups.client. La vie est belle, les oiseaux chantent, et je peux continuer à imbiber d’encre hors de prix des fibres d’arbres morts pour maximiser mon empreinte carbone. Et en plus, ça me fait une aventure à partager avec vous, mes très chères moules. J’espère que ça vous a plu !

  1. C’est celui qui est discutable, pour ceux qui suivent. ↩

  • # Merci

    Posté par  (Mastodon) . Évalué à 10 (+8/-1).

    Merci pour ce journal instructif dans cet océan de journal memes/comique de répétition.

    • [^] # Re: Merci

      Posté par  (Mastodon) . Évalué à 8 (+5/-0).

      comique de répétition

      "répétition", on est d'accord.

      "comique", c'est un autre débat…

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # s/SystemD/systemd/g

    Posté par  (site web personnel) . Évalué à 5 (+4/-1).

    Un modérateur peut-il faire un gros sed s/SystemD/systemd/g, qu'on aime ou pas, c'est important de respecter le nommage des services (httpd, mpd, sndiod, nsd, etcd).

    Je ne comprends toujours pas d'où cette orthographe a pu voir le jour…

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: s/SystemD/systemd/g

      Posté par  . Évalué à 3 (+1/-0).

      https://fr.m.wikipedia.org/wiki/Syst%C3%A8me_D

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: s/SystemD/systemd/g

      Posté par  . Évalué à 3 (+1/-0).

      La source https://brand.systemd.io/ nous dit en effet :

      Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either.

      À ne pas confondre avec Mike D :)

    • [^] # Re: s/SystemD/systemd/g

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      Un modérateur peut-il faire un gros sed s/SystemD/systemd/g

      Nous pouvons, mais nous ne le faisons que si la demande vient de l'auteur du journal :)

      • [^] # Re: s/SystemD/systemd/g

        Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0). 

        gilcot$ sudo -u jyes write julien_jorge
I agree, please proceed.
^D
gilcot$

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: s/SystemD/systemd/g

        Posté par  (site web personnel) . Évalué à 4 (+1/-0).

        Non on le fait aussi si la faute est avérée car la personne ne peut corriger seule et qu'attendre un aller-retour est inutile dans ce cas (faut pas se rater sur fôte avérée par contre).

        • [^] # Re: s/SystemD/systemd/g

          Posté par  . Évalué à 3 (+1/-0).

          Si faute avérée à moitié pardonnée, il y en a de plus graves. Par exemple, il manque des « > » après certains « cat », ce qui change beaucoup ce que font ces commandes.

          Bon, je ne recommande de toute façon pas de taper ces commandes « cat » dans un terminal administrateur sans les comprendre… on pourrait dire que c‘est un friture de sécurité, mais dans ce cas les autres « > » sont en trop :-).

        • [^] # Re: s/SystemD/systemd/g

          Posté par  (site web personnel) . Évalué à 5 (+3/-0).

          Tu dois être nouveau ici Ah non ça ne fonctionne pas avec toi :D

          En l'occurrence c'était bien un parti pris de l'auteur, cf. son commentaire plus bas.

          Je ne suis pas convaincu qu'il y ait de bonnes raisons de modifier le contenu d'un journal à l'insu de son auteur, dans les limites de la pénibilité et de l'illégalité bien sûr. Dans les journaux comme dans les commentaires, ça me semble normal de laisser la responsabilité de la forme comme du fond à l'auteur.

    • [^] # Re: s/SystemD/systemd/g

      Posté par  (Mastodon) . Évalué à 4 (+1/-0).

      Corrigé, merci

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: s/SystemD/systemd/g

      Posté par  . Évalué à 5 (+6/-3).

      Je ne comprends toujours pas d'où cette orthographe a pu voir le jour…

      J‘utilise SystemD à dessein, car je trouve que systemd ressemble davantage à une coquille qu’au nom d’un logiciel (non, non, je ne juge pas sur le fond ici). Les majuscules sont plus habituelles pour les noms propres. Le nom de systemd est inspiré du nom des binaires des daemons sur un système Unix, à la cupsd, smbd ou snapperd mais ces autres outils ne cherchent pas à se distinguer en imposant la casse dans leur nom quand on mentionne le logiciel dans son ensemble plutôt que le binaire.

      Donc quand j’écris un texte qui a pour vocation d’être lu, je préfère la clarté de SystemD à la coquetterie pédante de systemd. Maintenant, puisque sur LinuxFr on peut utiliser l’italique, n’en déplaise à ploum, la « bonne » solution serait d’écrire _systemd_ pour que systemd apparaisse en italique et ressorte ainsi comme un nom propre ou une forme reprise telle quelle. Mais dans ce cas, il faudrait le faire dans tout le texte, ce que je n’ai pas pris le temps de faire lors de sa conversion en Markdown. D’ailleurs, tu tiques sur la casse de « SystemD » mais pas sur le gloubiboulga de guillemets incohérents que j’ai laissé passé à la relecture et qui me chiffonne davantage. Comme quoi, chacun ne voit pas l’importance aux mêmes endroits.

      Tu as eu gain de cause, et ça ne m’empêchera pas de dormir que mes SystemD soient devenus des systemds. Moi, je trouve ça moins lisible, mais comme j’ai de toute façon ma version du journal en texte brut sur mon disque dur que je peux relire à l’envie, avec les casses que j’ai choisies, je préfère que la version en ligne soit écrite avec la forme préférée du lectorat de LinuxFr, alors systemd ce sera.

      • [^] # Re: s/SystemD/systemd/g

        Posté par  (site web personnel) . Évalué à 0 (+2/-4).

        Donc quand j’écris un texte qui a pour vocation d’être lu, je préfère la clarté de SystemD à la coquetterie pédante de systemd.

        Ce que tu préfères et pense comme lisible est subjectif et ne respecte pas le nommage souhaité des auteurs. Il en va de même avec Lua qui n'est pas un acronyme et dont les auteurs souhaitent qu'on écrive Lua et non LUA. Je vois pas en quoi un D majuscule améliore la lisibilité, sinon je peux aussi écrire un article comme tel :

        À la découverte de GnomE sous ArcH LinuX. Pour installer le bureau GnomE, on utilise PacmaN :

# pacman -S gnome

        C'est encore plus remarquable à quel point ça met en erreur puisque les commandes n'ont pas du tout cette orthographe.

        Mon cousin s'appelle Thiebault, je pense qu'il préfère que je l'orthographie comme ça et non Thibaut, Thibault ou encore Tibo sauf autorisation explicite de sa part.

        Personne n'écrit SndioD, HttpD, TftpD, VmD alors il n'y a aucune raison de le faire avec systemd.

        git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: s/SystemD/systemd/g

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 07 février 2025 à 18:08.

        Je préfère aussi systemd. C'est la forme la plus répandue, celle que préfère les gens du projet concerné. « SystemD » saute aux yeux et donne l'impression d'être une erreur, et que c'est juste écrit par quelqu'un qui ne fait pas trop gaffe à l'orthographe / la typographie (ce qui n'est pas un problème, il y a vraiment des choses plus importante dans la vie).

        J'étais loin de m'imaginer que ça pouvait être justement volontaire.

        C'est probablement juste une question d'habitude, c'est vrai que je crois me souvenir que ça m'avait un peu titillé au début.

        je préfère que la version en ligne soit écrite avec la forme préférée du lectorat de LinuxFr

        C'est bien urbain :-)

  • # Il y a longtemps, dans un autre pays...

    Posté par  . Évalué à 8 (+6/-0).

    vraiment il y a très longtemps, avant systemd, avant NetworkManager, il y avait netenv pour faire ce genre de trucs.

    Chouette journal bien sympa à lire, merci d'avoir pris le temps de l'écrire !

    Note : les admins sys/réseau ont mis du filtrage par adresse MAC, mais te laissent être root sur ton ordi. Tu pourrais donc prendre l'adresse MAC de n'importe quel autre ordi, entre autres choses sympa… C'est assez amusant en soi :).

    • [^] # Re: Il y a longtemps, dans un autre pays...

      Posté par  (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 07 février 2025 à 04:23.

      Il est possible de bloquer les adresses MAC au niveau d'un commutateur réseau : on peut déterminer pour chaque port quelle adresse MAC est autorisée ou non (il est aussi possible de définir une petite liste et non pas une unique adresse).

      ("switchport port-security" sur du matériel Cisco proposant ce type de configuration)

      Copier l'adresse du voisin n'est donc pas forcément une solution efficace.

      • [^] # Re: Il y a longtemps, dans un autre pays...

        Posté par  . Évalué à 4 (+2/-0).

        C’est effectivement ce qui est fait chez nous. Je ne sais si ça apporte beaucoup en terme de sécurité mais ça met en évidence que nous ne sommes pas censés nous connecter au réseau depuis n’importe où avec n’importe quoi, puisque nous avons des restrictions d’accès à respecter. Comme il est très aisé de changer d’adresse MAC, ça se contournerait facilement, mais ce faisant, on ne pourrait pas ignorer qu’on contrevient aux règles du lieu de travail, donc le filtrage MAC a pour rôle premier, à mon avis, de favoriser les bonnes habitudes. Il y a le WiFi pour être connecté partout, en salle de réunion par exemple, mais tous les services n’y sont pas accessibles (notamment les imprimantes, le cœur de ce journal!).

  • # c'est pour ca que j'aime linux

    Posté par  . Évalué à 5 (+4/-0).

    Parce que si on veut comprendre comment ça marche. On peut. Et si on veut un truc qui marche, tout le temps. On peut aussi. J'ai des bureaux dans un "tiers lieu" depuis pas mal d'années maintenant. Je fréquente donc au bureau des gens "normaux", windows, office, imprimante prof installée par la mairie etc. J'ai, je pense, de quoi écrire un bon tome d'anecdote bien drôle par an. Chez nous c'est debian stable pour tout le monde. Et ça marche parfaitement. Tellement bien qu'il n'y aurait vraiment rien à raconter :(

    gros bisous :)

  • # Réponse technique à un soucis organisationnel

    Posté par  (site web personnel) . Évalué à 4 (+2/-0).

    Merci pour ce partage instructif. C'est super intéressant d'un point de vue technique mais d'un point de vue organisationnel, ça me semble très louche.

    Dans ton journal, tu dis:

    j’avais depuis un certain temps une station d’accueil pour mon ordinateur portable au bureau, qui attendait dans une armoire. Commandée en même temps que l’ordinateur, elle a très mal fonctionné dès le moment où mon service info me l’a filée, et elle donc a rapidement été remplacée avec davantage de succès par un simple adaptateur USB vers ethernet+USB+HDMI.

    Puis

    L’histoire du jour, c’est que sur mon réseau au taf, je ne peux me connecter qu’avec un adresse MAC validée, à savoir celle de la carte de l’ordinateur portable, et non celle de la station.

    Mon réflexe aurait été de demander à ce que l’adresse MAC de cette station soit mise sur liste blanche. Pourquoi n'est-ce pas la solution choisie ?
    Travailler en mode promiscuous n'est pas si anodin et pas franchement utile si on écoute pas du trafic (à ma connaissance). Pourquoi le matériel de l'entreprise n'est-il pas autorisé dans l'entreprise ?

    • [^] # Re: Réponse technique à un soucis organisationnel

      Posté par  . Évalué à 6 (+4/-0).

      Mon réflexe aurait été de demander à ce que l’adresse MAC de cette station soit mise sur liste blanche. Pourquoi n'est-ce pas la solution choisie ?

      Si tu fais ça, tu masque la MAC de l'appareil qui est derrière, et donc tu peux y brancher n'importe quoi, ce sera accepté par le réseau via la MAC du dock.

      Le filtrage par MAC n'est plus très efficace avec des appareils mobiles de nos jours. Au boulot, on commence à déployer 802.1x avec des certificats clients, pour avoir une authentification aussi forte que sur le Wi-Fi.

      • [^] # Re: Réponse technique à un soucis organisationnel

        Posté par  . Évalué à 5 (+4/-1).

        Ça n'a jamais été une sécurité sérieuse. Je truandais déjà gentiment ce genre de trucs il y a 15 ans sans difficulté particulière.

        Il n'y a pas vraiment de secret, il faut un VPN ou quelque chose comme ça pour que ce soit une véritable sécurité

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Inutile pour cups

    Posté par  . Évalué à 3 (+1/-0). Dernière modification le 07 février 2025 à 14:27.

    Normalement il n'est pas nécessaire de configurer le client.conf de cups pour avoir accès aux imprimantes locales si celles ci sont bien partagées sur le LAN (c'est même une mauvaise pratique qui bypass ton spooler local). Au boulot j'ai bien accès aux imprimantes réseau sans une seule ligne de configuration sur ma machine

  • # La réponse est là

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    L’histoire du jour, c’est que sur mon réseau au taf, je ne peux me connecter qu’avec un adresse MAC validée

    Si le passthrough est désactivé dans le BIOS, alors ta machine (et n'importe quelle machine) aura une MAC valide sur le réseau de ton entreprise…

    On va dire que ça permet juste d'éviter que n'importe qui de bien intentionné récupère une ip sur ton réseau.

    Pour les personnes mal intentionnées, reste l'authentification par mot de passe, mais même ça on peut le contourner…

  • # +1 Non à la politique/morale or informatique

    Posté par  (site web personnel, Mastodon) . Évalué à -6 (+3/-10). Dernière modification le 07 février 2025 à 23:46.

    Très bon journal, dans le style qu'on aime ici.

    Mais je commente pour te soutenir contre les journaux politique/moraux qui n'ont rien à faire ici sauf si bien sûr ils ont un lien avec l'informatique. Exp l'open-source dans les administration public, le woke dans les projets open-sources (Git remplace master par main), le parti-pirate…

    Et pourtant je ne suis pas toujours en désaccord avec les propos tenu mais l'on peut être de droite, ou de gauche, athé, catho, ou musulman, peu importe, quand on est ici, ce n'est pas pour en parler (hormis peut-être un passage mais pas un sujet). Quand on est ici, c'est pour être en mode open-source.

    Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.