GuiGui's Show

Avec SSH, on veut autoriser uniquement root à se connecter à distance (afin d'administrer la machine), mais on veut que tous les utilisateurs du système puisse se connecter en local.
En effet, Hadoop est lancé par nos utilisateurs avec leur compte personnel et celui-ci effectue des connexions SSH locales pour lancer ses différents composants.

Réponse :

Il faut ajouter cela dans /etc/ssh/sshd_config :

AllowUsers root 

Match Address 127.0.0.1,::1
    AllowUsers *

Puis recharger la configuration de SSH : systemctl reload ssh.

Notons qu'avant la version 8.4 d'OpenSSH, à cause d'un bug, il n'est pas possible de déposer ce bout de configuration dans le dossier /etc/ssh/sshd_config.d.

Depuis mon VPN FDN (FDN est un Fournisseur d'Accès à Internet associatif), je veux renouveler mon abonnement à NextInpact, journal sur le numérique et le droit afférant. L'intermédiaire de paiement par carte bancaire est Payzen. Dans le cadre de 3-D Secure, Payzen affiche une pop-up qui, in fine, me redirige vers ma banque pour la saisie d'un code à usage unique.

Cette pop-up, dont l'URL est « https://natixispaymentsolutions-3ds-vdm.wlp-acs.com/acs-challenge-browser-service/challenge/challengeRequest/browserBase », ne s'affiche pas.

Je désactive une à une mes extensions Firefox (uBlock Origin, uMatrix, Privacy Badger, LocalCDN, SmartReferer, NoScript, etc.). Ça ne fonctionne pas mieux. J'utilise Chromium avec un profil vierge (pas d'extension, pas de configuration personnalisée) : même absence de résultat. Dans les deux cas, le « délai de la réponse » est « dépassé ».

Regardons ça.

Depuis ma station de travail

$ host natixispaymentsolutions-3ds-vdm.wlp-acs.com
natixispaymentsolutions-3ds-vdm.wlp-acs.com is an alias for natixispaymentsolutions-3ds-vdm.as8677.net.
natixispaymentsolutions-3ds-vdm.as8677.net has address 160.92.41.82

$ telnet 160.92.41.82 443
Trying 160.92.41.82...
telnet: Unable to connect to remote host: Connection timed out

D'après Wireshark, mon telnet reçoit aucune réponse à son TCP SYN. Il ne s'agit donc pas d'un problème de MTU, mais de joignabilité du service.

Ce que confirme mtr :

$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-20T14:54:48+0100
HOST: <CENSURE>                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 80.67.179.1                0.0%     1   16.9  16.9  16.9  16.9   0.0
  2.|-- 80.67.169.42               0.0%     1   16.5  16.5  16.5  16.5   0.0
  3.|-- 80.67.168.210              0.0%     1   16.8  16.8  16.8  16.8   0.0
  4.|-- 37.77.34.14                0.0%     1   18.3  18.3  18.3  18.3   0.0
  5.|-- 193.253.13.205             0.0%     1   22.1  22.1  22.1  22.1   0.0
  6.|-- 193.252.98.122             0.0%     1   18.6  18.6  18.6  18.6   0.0
  7.|-- 193.252.230.34             0.0%     1   19.5  19.5  19.5  19.5   0.0
  8.|-- 160.92.6.57                0.0%     1   28.5  28.5  28.5  28.5   0.0
  9.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0

Mes paquets se perdent à l'entrée du réseau de Worldline France Hosting, qui héberge le site web.

Notons que j'ai bien effectué un test en TCP (« -T ») et sur un port forcément ouvert (« -P 443 » = HTTPS) afin de ne pas obtenir un faux positif lié au blocage très fréquent d'ICMP dans ce milieu-là (même si c'est une connerie car des pans d'ICMP sont inoffensifs et utiles pour dépanner, comprendre l'origine d'une panne, retourner une erreur, etc.).

S'agit-il d'un problème général ou localisé ?

Depuis le serveur qui héberge ce shaarli

$ telnet 160.92.41.82 443
Trying 160.92.41.82...
Connected to 160.92.41.82.
Escape character is '^]'.

Ha, tiens, ça fonctionne.

$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-20T14:59:16+0100
HOST: viki.guiguishow.info        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 51.77.212.1                0.0%     1    0.3   0.3   0.3   0.3   0.0
  2.|-- 192.168.143.254            0.0%     1    0.2   0.2   0.2   0.2   0.0
  3.|-- 10.224.71.126              0.0%     1    0.4   0.4   0.4   0.4   0.0
  4.|-- 10.224.68.50               0.0%     1    0.4   0.4   0.4   0.4   0.0
  5.|-- 10.69.96.102               0.0%     1    0.4   0.4   0.4   0.4   0.0
  6.|-- 10.17.193.104              0.0%     1    0.7   0.7   0.7   0.7   0.0
  7.|-- 10.73.8.114                0.0%     1    0.3   0.3   0.3   0.3   0.0
  8.|-- 10.95.48.8                 0.0%     1    1.5   1.5   1.5   1.5   0.0
  9.|-- 94.23.122.137              0.0%     1    3.9   3.9   3.9   3.9   0.0
 10.|-- 10.200.0.0                 0.0%     1    3.4   3.4   3.4   3.4   0.0
 11.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
 12.|-- 62.115.124.118             0.0%     1    3.5   3.5   3.5   3.5   0.0
 13.|-- 62.115.121.5               0.0%     1   26.3  26.3  26.3  26.3   0.0
 14.|-- 62.115.153.109             0.0%     1    3.8   3.8   3.8   3.8   0.0
 15.|-- 160.92.6.39                0.0%     1    3.8   3.8   3.8   3.8   0.0
 16.|-- 160.92.6.54                0.0%     1   13.6  13.6  13.6  13.6   0.0
 17.|-- 160.92.6.10                0.0%     1   16.6  16.6  16.6  16.6   0.0
 18.|-- 160.92.41.82               0.0%     1   16.4  16.4  16.4  16.4   0.0

On remarque que le routage est différent.
OVH utilise l'un de ses transitaires, l'opérateur Telia.
Gitoyen (l'opérateur associatif duquel FDN est membre) passe par Hopus / Orange.

À ce stade, j'ai utilisé la fonctionnalité proxy SOCKS / transfert dynamique de ports de SSH (ssh -D) tout en configurant mon Firefox pour l'utiliser, et, hop, j'ai pu renouveler mon abonnement NextInpact.

Depuis un abonnement fibre Orange

$ telnet 160.92.41.82 443
Trying 160.92.41.82...
Connected to 160.92.41.82.
Escape character is '^]'

Ça fonctionne également.

$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-20T15:09:14+0100
HOST: <CENURE>                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%     1    0.5   0.5   0.5   0.5   0.0
  2.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  3.|-- 193.253.91.46              0.0%     1    3.2   3.2   3.2   3.2   0.0
  4.|-- 193.252.160.150            0.0%     1    2.2   2.2   2.2   2.2   0.0
  5.|-- 193.251.126.18             0.0%     1    7.7   7.7   7.7   7.7   0.0
  6.|-- 193.252.99.102             0.0%     1    9.2   9.2   9.2   9.2   0.0
  7.|-- 193.252.98.122             0.0%     1    8.7   8.7   8.7   8.7   0.0
  8.|-- 193.252.230.34             0.0%     1   10.7  10.7  10.7  10.7   0.0
  9.|-- 160.92.6.57                0.0%     1   11.6  11.6  11.6  11.6   0.0
 10.|-- 160.92.6.10                0.0%     1   13.3  13.3  13.3  13.3   0.0
 11.|-- 160.92.41.82               0.0%     1   15.0  15.0  15.0  15.0   0.0

On remarque que l'on transite aussi par les routeurs 160.92.6.57, 193.252.230.34, 193.252.98.122, comme depuis mon VPN FDN. Mais, ici, ça fonctionne. Curieux.

Ça ressemble quand même à un problème localisé, pas général. Dois-je signaler la panne à mon FAI (FDN) ? Est-ce de sa responsabilité ? Pas sûr du tout.

D'autres abonnés de mon FAI ont-ils le même problème ?

Je pourrais les solliciter sur les listes de diffusion… ou utiliser RIPE Atlas. Faisons ça.

Je crée deux mesures :

• SSL (qui porte très mal son nom : SSL a été remplacé par TLS depuis fort longtemps) :
  • Target : 160.92.41.82
    
    
  • Hostname (SNI) : natixispaymentsolutions-3ds-vdm.wlp-acs.com
• Traceroute :
  • Target : 160.92.41.82
    
    
  • Protocol : TCP
    
    
  • Port : 443

Paramètres communs aux deux mesures :

• Probe selection :

  • ASN = AS20766 (il s'agit du numéro d'opérateur de Gitoyen)
• One-off

Résultats des mesures :

• TLS :

  • 3 sondes sur 4 parviennent à établir une session TLS. Celle qui n'y parvient pas en affichant « handshake failure » est probablement trop ancienne pour savoir établir une session TLS 1.2 (seul protocole supporté par la cible). Merci Stéphane ;
    
    
  • On remarquera la présence d'une sonde située derrière un VPN FDN. Cette sonde parvient à établir une session TLS ! Son traceroute est identique au mien !
• Traceroute :
  • Toutes les sondes passent par le même chemin mais se font bloquer avant d'entrer sur le réseau de Worldline. D'après la documentation, « !A » dans le traceroute d'une sonde Atlas signifie que l'erreur ICMP « administratively prohibited » a été renvoyée à la sonde. Merci Stéphane.

Si l'on fait une mesure TLS depuis la France entière (et pas uniquement depuis l'opérateur Gitoyen), on constate que 797 sondes sur 874 (91 %) parviennent à établir une session TLS, 75 n'y parviennent pas (« handshake failure ») et 2 sondes ne parviennent pas à joindre la cible (timeout). Voir la mesure numéro 29125405.

Afin de tester le chemin retour (qui est rarement identique au chemin aller), j'aurais bien effectué une mesure ping / traceroute depuis Worldline vers ma station de travail, mais aucune sonde Atlas est présente dans le réseau de Worldline.

Conclusion

Il ne s'agit pas d'une panne généralisée, car l'écrasante majorité des sondes Atlas et des machines que j'ai sous la main parviennent à joindre le site web.

Pire, les autres abonnés de mon FAI parviennent à joindre le site web, y compris un autre VPN qui est dans le même réseau que moi. Nous suivons le même itinéraire pour atteindre l'hébergeur du site web, donc, a priori, il n'y a pas de problème à ce niveau-là.

Comment expliquer ce problème lié à mon adresse IP ?

• Certaines adresses IP (X.X.X.0 ou X.X.X.255) sont désavantagées car considérées comme invalides selon des normes qui ne sont plus en vigueur depuis plusieurs décennies. Mon adresse IP ne fait pas partie des lots problématiques connus ;
  
  
• Limitation de trafic ou bannissement temporaire (type fail2ban) dûs à mes essais infructueux en désactivant mes extensions Firefox. Cela me semble être improbable car :
  • Mes premiers essais datent de mercredi 17/02 (et déjà RIPE Atlas voyait aucun problème général) et je rencontrais encore ce problème le 20/02, ce qui est inhabituellement long pour ce type de blocage et dans ce contexte (on préfère prendre plus de risques mais encaisser le pognon que de faire perdre des ventes) ;
    
    
  • Depuis mon serveur OVH, j'ai effectué des rafales de plusieurs centaines de requêtes HTTP, GET et POST, avec curl et wget ainsi que des dizaines de telnet et de mtr TCP et je n'ai pas été bloqué.

Au moment de publier ce shaarli (le 23/02, 6 jours après le premier constat), j'accède de nouveau à ce site web depuis mon VPN FDN :

$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-23T10:53:57+0100
HOST: <CENSURE>                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 80.67.179.1                0.0%     1   22.1  22.1  22.1  22.1   0.0
  2.|-- 80.67.169.42               0.0%     1   18.3  18.3  18.3  18.3   0.0
  3.|-- 80.67.168.210              0.0%     1   16.8  16.8  16.8  16.8   0.0
  4.|-- 37.77.34.14                0.0%     1   21.7  21.7  21.7  21.7   0.0
  5.|-- 193.253.13.205             0.0%     1   16.7  16.7  16.7  16.7   0.0
  6.|-- 193.252.98.122             0.0%     1   19.2  19.2  19.2  19.2   0.0
  7.|-- 193.252.230.34             0.0%     1   19.9  19.9  19.9  19.9   0.0
  8.|-- 160.92.6.57                0.0%     1   28.2  28.2  28.2  28.2   0.0
  9.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
 10.|-- 160.92.41.82               0.0%     1   35.1  35.1  35.1  35.1   0.0

On constate que j'emprunte le même chemin, à l'intérieur des réseaux d'Orange et de Worldline, que la machine hébergée sur un abonnement fibre Orange, ce qui est cohérent. L'hypothèse d'un problème de routage (sur le chemin retour) s'effrite encore plus.

On constate également que je me trompe ci-dessus : mes paquets ne se perdaient pas à l'entrée du réseau de Worldline, mais au contraire, à ma destination dans ce réseau. Cela conforte l'hypothèse d'un banissement temporaire type fail2ban.

Bizarre… Je viens d'effectuer des centaines de requêtes GET et POST et je ne suis pas bloqué…

Au final, je ne saurai pas ce qui s'est passé… Les ninjas de l'informatique ne savent pas tout…

Version rap de comptines enfantines.

:'D :'D :'D :'D

Boot Repair, un énième outil magique censé réparer les problèmes de démarrage d'un système GNU/Linux.
J'ai testé : je suis déçu, comme avec les autres outils magiques de ce genre-là.

Contexte : un ordinateur portable Ubuntu tombé sur le sol durant son fonctionnement qui, depuis, affiche le shell grub rescue.

Boot sur un live USB Boot Repair + utilisation en mode kikoo (clic sur « Réparation recommandée »). L'outil affiche qu'il « restaure GRUB » et d'autres bricoles. Le journal ne montre pas d'erreurs.

Par acquit de conscience, je lance un fsck sur les partitions ext4 présentes sur le disque dur. Pas mal d'erreurs (superblock endommagé, inodes manquants, etc.). De mon expérience, ce genre d'erreurs signalent un sérieux problème voire de la perte de fichiers. fsck demande s'il faut ignorer ceci, ré-écrire cela, et comme il y a de nombreuses erreurs, je fini par craquer et lancer le mode automatique (fsck -y).

Reboot : ho, un winwin 7 sans passer par le menu GRUB. (Ubuntu a été installé à côté de winwin et GRUB a été configuré pour ne pas afficher son menu).

Reboot sur Boot Repair + nouvelle utilisation en mode kikoo. Cette fois-ci, l'outil annonce qu'il réinstalle GRUB (sur le bon disque dur), qu'il effectue un update-grub2, etc.

Je pense que la partition système Ubuntu était suffisamment abîmée pour qu'il ne la détecte pas lors du premier lancement, ce qui l'a conduit à penser que le système principal était winwin et qu'Ubuntu était un reliquat, et donc qu'il était mieux de virer GRUB.

Reboot : toujours winwin.

Reboot sur Boot Repair. mount la partition Ubuntu + mount -o bind /proc /sys /dev /dev/pts + chroot + grub-install + umount + reboot. Le menu GRUB apparaît.

Bref : rien vaut la méthode manuelle habituelle.

Pour être honnête, la méthode manuelle a aussi foiré.

En effet, le menu GRUB affiche une entrée « Debian GNU/Linux » (wtf ?! Il s'agit d'un Ubuntu !) et deux entrées winwin 7.
L'entrée Debian nous conduit a une erreur « /boot/grub/i386-pc/video_cirrus.mod not found ». Si l'on presse la touche « entrée » comme proposé, on a un kernel panic…

Un chroot + update-grub2 génère bien un grub.cfg avec autant d'entrées dans le menu GRUB qu'il y a de versions du noyau présentes dans la partoche Ubuntu, mais, quand on reboot, le menu GRUB affiche une seule ligne. Mais ça change rien : le démarrage reste bloqué sur l'absence de video_cirrus.mod.

Ces deux incohérences laissent à penser que l'on ne démarre pas sur le bon GRUB (peut-être est-il installé à plusieurs endroits ?).

Peut-être qu'une réinstallation du paquet grub2 aurait fait le job ?

ArubaOS (utilisé dans le produit Aruba Mobility Master v8.6) refuse de démarrer / booter dans une machine virtuelle KVM sur un hyperviseur Proxmox 6 car il manque les instructions CPU SSSE3.

On se dit qu'on va faire un qm set, mais, d'après la doc', les drapeaux activables sont limités, et il n'y a pas SSSE3.

Il y a qu'à choisir un modèle de CPU virtuel qui prend en charge SSSE3. Par défaut, le type de CPU émulé par Proxmox+KVM est kvm64, qui est un Pentium 4 avec des jeux d'instructions retirés.

Dans les propriétés de la VM, onglet « Hardware », « Processors », on peut choisir le modèle de CPU dans la liste déroulante « Type ». SSSE3 étant ancien (2004), n'importe quel modèle de CPU devrait faire l'affaire. Nous avons choisi IvyBridge, fin du problème.

On a souvent besoin d'autrui pour mener à bien / faire avancer un projet / combat. Parfois, les personnes que l'on sollicite car elles nous semblent être les plus à même d'aider (compétences, détention d'informations, situation / position, affinité, etc.) refusent d'apporter leur concours. Pire, certaines personnes se désistent et retroussent chemin après avoir engagé leur premier coup de papatte. Souvent pour des motifs vaseux comme une peur irrationnelle.

Dans ces moments-là, je me sens déçu par la personne voire trahi, et donc triste. Je fonctionne à l'affinité / l'affect (je choisis une personne pour un projet pour ses compétences, mais aussi parce que je sens bien cette personne-là, à ce moment-là, sur ce projet-là), donc, forcément, ça me fait mal. Surtout quand une personne affirme adhérer à fond à ma démarche et qu'elle m'a bien chauffé au préalable en mode "t'as trop raison, faut faire ça, vas-y mon poulain !".

On peut y voir de la lâcheté, voire de l'hypocrisie (afficher son soutien sans rien produire de concret). Oui, c'est vrai, mais…

Il y a plus de 5 ans maintenant, une amie m'a dit quelque chose. Je constate que le souvenir de ces paroles m'a apaisé à plusieurs reprises ces derniers mois dans des contextes comme celui exposé ci-dessus.

Il y a plein de façon de contribuer à un projet / combat, plein de manière de changer le monde. On n'est pas obligé de poser des bombes ni de saboter les moyens de production. On peut gérer la logistique (autour de la pose de la bombe ou du sabotage). On peut héberger les militants radicaux (comme les Résistants qui faisaient sauter les voies ferrées). On peut diffuser la propagande (afin d'expliquer l'utilisation de bombes / sabots). On peut fournir des informations (car, comme la personne est restée irréprochable, le système lui en filera). On peut mettre en relation des personnes. On peut soutenir moralement l'acteur principal. On peut lui remonter le moral. On peut dévier le coup de grâce que tentera s'asséner le système à l'actrice principale (en restant irréprochable aux yeux du système, une personne sera à même de peser de tout son poids dans la décision). On peut contribuer aux caisses de grève plutôt que d'aller se faire gazer par les flics ou perdre quelques précieux euros sur un salaire précaire. Etc. Bref, il faut accepter que tout le monde n'ait pas le même niveau d'engagement dans un projet / combat… Et ne pas insulter le futur.

Comme dit dans le film Fight Club, c'est à chaque personne de définir son niveau d'engagement. Comme d'hab', forcer les gens amène rien de positif (travail bâclé, dernier coup de main, mauvaise ambiance, etc.). Ma fierté de ces dernières années est de parvenir à commencer à faire la différence entre un refus de ma personne et un refus de l'une de mes idées, et d'accepter un refus de coup de main. Je progresse à petits pas.

Il est très rare qu'une caisse automatique d'un supermarché me refuse un article. Mais c'est arrivé. « Erreur somme de contrôle, êtes-vous sûr d'avoir déposé le bon article ? ».

La caissière m'explique que mon pack de binouzes est un assemblage de 4 bouteilles qui sont aussi vendues séparément. Donc il contient en réalité 5 codes-barres (un sur chaque bouteille + sur le carton). Il faut scanner le bon (celui sur le carton).

Depuis, je fais attention à masquer le code-barre des bouteilles aux yeux du scanner et tout se passe bien.

Si jamais ce tuyau peut te servir autant qu'à moi… :)

Vitrine d'un café fin 2020.

Des ours en peluche remplacent les humains par temps de covid.

• Original, mais glaçant ;
  
  
• Un aperçu du monde des bisounours ?

Bien sentie, cette photo. :)

Ça date de fin 2019.

Mignon, les mots de passe des pionniers de BSD / UNIX :

• Ken Thompson : p/q2-q4! (mouvement d'échec :O )
  
  
• Dennis Ritchie : dmac (le composé chimique ou un jeu avec ses initiales ?)
  
  
• Stephen R. Bourne : bourne (haha la faiblesse du mdp)
  
  
• Brian W. Kernighan : /.,/.,

Le mot de passe de Bill Joy (le ouf qui a codé la première implémentation de TCP/IP, sur BSD) n'a pas encore été retrouvé.

Sur FRnOG (liste de discussion par emails destinée aux opérateurs téléphoniques et Internet ainsi qu'aux curieux), on peut lire plusieurs témoignages du type "je téléphonais, et, soudainement, mon interlocuteur m'a redit les mêmes choses, au mot près, dans le même ordre". Une variante est d'entendre ce qu'on a soi-même dit quelques minutes auparavant. Certains nomment ça « effet matrix ». Il ne s'agit pas d'espionnage mais d'une fraude nommée Call Stretching. Je résume l'animation LinkedIn :

• Quand Alice téléphone à Bob, l'opérateur de Bob facture l'appel à l'opérateur d'Alice via les opérateurs intermédiaires qui transportent l'appel (c'est le cas pour des appels internationaux) ;
  
  
• Pour faire du bénéfice, l'opérateur intermédiaire (que l'on nomme « carrier ») applique une marge sur le prix demandé par l'opérateur de Bob, et ainsi de suite sur toute la chaîne ;
  
  
• Après quelques minutes de conversation, l'opérateur intermédiaire raccroche l'appel avant son terme mais uniquement d'un des deux côtés (Alice ou Bob). Une variante consiste à maintenir l'une des extrémités de l'appel après que l'autre ait raccroché. Dans les deux cas, l'opérateur diffuse soit un message pré-enregistré, soit un enregistrement de la conversation qui vient d'avoir lieu ;
  
  
• Alice (ou Bob) ne s'en rend pas forcément compte, car certaines conversations se prêtent bien à la répétition genre les démarchages commerciaux durant lesquels tu peux demander 3 fois la même info (genre le prix) sans que l'interlocuteur, qui veut vendre, s'en émeuve. Et même si l'un des interlocuteurs s'en rend compte, son comportement sera, en moyenne, de dire "allô ?", "il y a un problème technique, non ?" ou autres propos ;
  
  
• Pendant ce temps-là, le compteur de facturation tourne, et l'opérateur intermédiaire fait 100 % de marge : il sera payé par l'opérateur d'Alice, mais il ne redistribuera pas un kopeck à l'opérateur de Bob puisque, pour cet opérateur, l'appel est terminé (il ne le facture donc plus à l'opérateur intermédiaire fraudeur).

A priori, ça fait partie d'un groupe de fraudes plus vastes nommées False Answer Supervision (qui consistent à facturer avant l'établissement complet de l'appel ou après la fin de l'appel).

Je suis impressionné par ce que l'humain est capable de mettre en place pour faire chier son prochain tout en encaissant de l'argent de poche… Si ça ce n'est pas un abus du capitalisme (tirer profit d'une action inutile qui ne rend pas service)… À côté de ça, t'as évidemment des vendeurs de solutions à ce problème… Fabuleux…