GuiGui's Show

(Réponse perso au titre, j'ai pas lu le contenu) Parce que le sommeil est la meilleure partie de la vie, exception faite de la mort. Personne vient t'emmerder quand tu dors (sauf si t'es assez idiot pour dormir en présence d'un autre être vivant, humain ou non). Personne attend quoi que ce soit de toi. Personne te presse. Personne te juge. Pas besoin de réfléchir. Pas de déception. Le bonheur total. La paix intégrale.

Sur un puppet master 6.X, je crée un nouvel environnement en reprenant la structure d'un environnement qui fonctionne sur un puppet master 5.X. Il fonctionne. Jusqu'à ce que j'essaye d'inclure un module depuis le manifest principal. L'agent puppet 5.5.X me retourne alors l'erreur suivante :

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Unacceptable location. The name '<NOM_MODULE>' is unacceptable 
  in file '/etc/puppetlabs/code/environments/<CENSURE>/site/modules/<NOM_MODULE>/manifests/init.pp' (file: /etc/puppetlabs/code/environments/<CENSURE>/site/modules/<NOM_MODULE>/manifests/init.pp, line: 3, column: 1) on node <CENSURE>

L'écrasante majorité des résultats d'une recherche web pointent sur un renforcement de la convention de nommage des fichiers et classes Puppet. La version 6.X ne laisse plus passer les écarts.

Je vérifie plusieurs fois : je respecte la convention de nommage imposée par Puppet.

En effet, voici mon arborescence :

/etc/puppetlabs/code/environments/envi
                                    - modules
                                    - manifests
                                        - site.pp
                                    - site
                                        - modules
                                            - modu
                                                - manifests
                                                      - init.pp (qui contient la classe « modu »)
                                        - profils
                                            - manifests
                                                - pro.pp (qui contient la classe « profils::pro »)
                                        - roles
                                            - manifests
                                                - ro.pp (qui contient la classe « roles::ro »)

Et mon modulepath (dans environment.conf) : site:site/modules:modules. Ce fichier est bien pris en compte comme nous le montre la commande suivante :

$ puppet config print modulepath --section server --environment envi
/etc/puppetlabs/code/environments/envi/site:/etc/puppetlabs/code/environments/envi/site/modules:/etc/puppetlabs/code/environments/envi/modules

Ainsi, un « include modu » depuis manifests/site.pp devrait fonctionner. Or, ça génère l'erreur mentionnée au début de ce shaarli.

En revanche, aucun problème avec un « include profils::pro » depuis manifests/site.pp.

Je te passe le debug : l'ordre dans le modulepath est important. Avec une valeur « site:site/modules:modules », Puppet cherche la classe d'abord dans le dossier site. « include profils::pro.pp » fonctionne puisque profils/manifests/pro.pp est bien dans le dossier site. En revanche, « include modu » ne fonctionne pas car, si site/modules/modu/manifests/init.pp existe, on ne peut pas l'inclure avec « include modu » sans outrepasser la convention de nommage. Il est d'autant plus difficile de parvenir à ce constat sur l'invalidité du modulepath puisque le message d'erreur de Puppet indique qu'il a trouvé le module (or, un path sert à trouver quelque chose…)

En changeant la valeur du modulepath pour site/modules:modules:site, cela fonctionne, car le chemin « site/modules » est examiné d'abord et que site/modules/modu/manifests/init.pp existe et respecte la convention de nommage. Dans le cas de « include profils::pro.pp », rien est trouvé dans site/modules, ni dans modules/, donc la recherche se termine dans site/ et cela fonctionne car site/profils/manifests/pro.pp est trouvé.

Cela fonctionne aussi si le modulepath a pour valeur modules:site/modules:site. Ce dernier est d'ailleurs le plus logique : on cherche d'abord dans les modules externes puis dans les modules maison, puis dans les profiles et les rôles maison.

Depuis plusieurs mois, j'utilise quelques extensions Firefox supplémentaires par rapport à mon tas d'extensions :

• Redirect AMP to HTML : utiliser la version normale, pas AMP, d'une page web. AMP est une technologie d'optimisation pas vraiment normalisée pondue par Google. Construire des pages web selon la manière de faire de Google, avec du JavaScript de Google et les héberger, en option, chez Google = non merci ;
  
  
• I don't care about cookies : faire disparaître les demandes de stockage de cookies. Quand on les refuse ou qu'on les supprime à chaque fermeture du navigateur, ces demandes incessantes sont insupportables. Bonus : cette extension valide automatique les pop-up « Avant de continuer » sur Google Search ;
  
  
• Never-Consent : refuser le dépôt de cookies et le flicage auprès de quelques (trop rares) plateformes de gestion du consentement (CMP) genre Cookie Law Info / Quantcast / SirData (aka consentframework.com) utilisées par les sites web pour mutualiser la collecte du consentement ;
  
  
• First Party Isolation. First Party Isolation est une préfèrence de Firefox (que l'on peut donc activer dans about:config) importée du Tor Browser qui limite l'accès aux cookies, au cache, au stockage, etc. par domaine. Ainsi, le flicage inter-domaines par un même prestataire présent sur plusieurs sites web n'est plus possible. La fonctionnalité Total Cookie Protection de Firefox 86 est une amélioration de cela. Pourquoi une extension ? FPI casse certains mécanismes d'authentification centralisée (genre compte Google ou Facebook). De mon côté, cela casse NextInpact (car certains cookies sont en dehors du domaine visité) et le stockage de mes préférences sur Qwant (je ne comprends pas pourquoi). Donc avoir une extension pour activer / désactiver FPI à la demande, c'est très pratique. ÉDIT DU 23/04/2022 : il n'y a plus de problème sur NextInpact depuis quelques mois. FIN DE L'ÉDIT ;
  
  
• Cookie Autodelete : supprimer les cookies (ainsi que le cache, le stockage persistant, etc. en option) X secondes après avoir quitté un site web (en cliquant sur un lien ou en fermant un onglet) sauf pour ceux en liste blanche. Cette extension permet un nettoyage plus régulier que celui que l'on peut demander à la fermeture du navigateur web. Je l'ai installé après avoir constaté que le refus des cookies (sauf pour quelques domaines genre ma banque ou mes journaux) casse des sites web et que uMatrix, configuré pour tej les cookies (sauf liste blanche), en laisse passer.

Je recommande l'utilisation de ces extensions. Les trois premières peuvent être installées chez des novices car elles m'ont posé aucun problème.

TL;DR :

• « ca md too weak » : le certificat x509 utilisé est signé avec un algorithme cryptographique déprécié dans /etc/ssl/openssl.cnf (à la fin) ;
  
  
• « Packet size=XXXXXX too big » : rupture de compatibilité entre deux composants de Bacula car l'un est à jour alors que l'autre ne l'est pas.

L'un de nos prestataires met à jour, vers Debian 10, un serveur placé sous sa totale responsabilité. C'est notre premier serveur Debian 10. Depuis ce moment-là, nos sauvegardes Bacula de ce serveur ne se font plus.

Les journaux du directeur Bacula indiquent :

<CENSURE>-dir JobId XXXX: Warning: bsock.c:107 Could not connect to Client: <CENSURE>-fd on <CENSURE>:9102. ERR=Connection refused
<CENSURE>-dir JobId XXXX: Fatal error: bsock.c:113 Unable to connect to Client: <CENSURE>-fd on <CENSURE>:9102. ERR=Connection refused

Sur la machine à sauvegarder Debian 10, le file daemon de Bacula n'est pas démarré. Une erreur empêche de le démarrer :

<CENSURE>-fd: openssl.c:68 Error loading certificate file: ERR=error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak

OpenSSL = implémentation de TLS. « md » = message digest = fonction de condensation / hachage. Nous utilisons une autorité de certification x509 interne / privée / maison. Avant signature, les certificats émis / clients sont signés avec SHA-1. Cette fonction cryptographique est très fortement dépréciée car elle n'offre plus un niveau de sécurité acceptable. C'est l'un des changements entre Debian 9 Stretch et Debian 10 Buster.

Pour autoriser l'utilisation de SHA-1, il suffit de mettre en commentaire la ligne CipherString = DEFAULT@SECLEVEL=2 du fichier /etc/ssl/openssl.cnf. La solution durable sera de remplacer notre autorité de certification x509 maison par une nouvelle utilisant des algorithmes de signature plus récents.

Désormais, le file daemon de Bacula démarre. bconsole depuis le director fonctionne. Tout va bien. Enfin, on le croit…

La nuit suivant la réparation sus-rapportée, la sauvegarde de ce serveur Debian 10 ne se fait toujours pas. Le journal du directeur Bacula consigne :

<CENSURE>-sd JobId XXXX: Fatal error: bsock.c:569 Packet size=XXXXXX too big from "client:<CENSURE>:9103. Terminating connection.
<CENSURE>-sd JobId XXXX: Fatal error: Error creating JobMedia records: 1000 OK VolName=Inc-2881 VolJobs=1 VolFiles=0 VolBlocks=3 VolBytes=193738 VolABytes=0 VolHoleBytes=0 VolHoles=0 VolMounts=35 VolErrors=0 VolWrites=289795 MaxVolBytes=0 VolCapacityBytes=0 VolStatus=Used Slot=0 MaxVolJobs=1 MaxVolFiles=0 InChanger=0 VolReadTime=0 VolWriteTime=320926443 EndFile=1 EndBlock=3432546605 VolType=1 LabelType=0 MediaId=2881 ScratchPoolId=0
<CENSURE>-dir JobId XXXX: Error: getmsg.c:185 Malformed message: Jmsg JobId=XXXX type=4 level=1611790411 <CENSURE>-fd JobId XXXX: Error: bsock.c:388 Wrote 2134 bytes to Storage daemon:<CENSURE>:9103, but only 0 accepted.
<CENSURE>-dir JobId XXXX: Error: getmsg.c:185 Malformed message: Jmsg JobId=XXXX type=3 level=1611790411 <CENSURE>-fd JobId XXXX: Fatal error: backup.c:843 Network send error to SD. ERR=Connection reset by peer
<CENSURE>-dir JobId XXXX: Error: getmsg.c:185 Malformed message: Jmsg JobId=XXXX type=4 level=1611790411 <CENSURE>-fd JobId XXXX: Error: bsock.c:271 Socket has errors=1 on call to Storage daemon:<CENSURE>:9103
<CENSURE>-dir JobId XXXX: Fatal error: bsock.c:569 Packet size=XXXXXX too big from "Client: <CENSURE>-fd:<CENSURE>:9102. Terminating connection.
<CENSURE>-dir JobId XXXX: Fatal error: No Job status returned from FD.

Hum… Problème de communication entre la machine à sauvegarder et le serveur de stockage Bacula (storage daemon).

J'avoue, j'ai cru à une erreur TLS (genre version minimale de TLS imposée par Debian 10 = TLS 1.2 alors que le storage daemon ne sait pas parler cette version). Mais j'ai la même erreur sur une machine virtuelle Debian 10 montée à l'arrache dans laquelle je configure Bacula pour ne pas utiliser TLS.

Une recherche sur le web donne un diagnostic convergeant : Bacula Packet size too big | deranfangvomen.de, Bacula - Users - Packet size too big from client, Bacula Frequently Asked Questions.

Un démon de stockage en version 5.X (Debian 8) est incompatible avec un file daemon en version 9.X (Debian 10).

Solution à court terme : downgrader les paquets Bacula sur la machine Debian 10. Pour ce faire, il faut ajouter les dépôts Stretch dans /etc/apt/sources.list (ne pas oublier le dépôt security), apt-get upate, apt-get install bacula-fd=7.4.4+dfsg-6+deb9u2 bacula-common=7.4.4+dfsg-6+deb9u2.

Solution à long terme : installer une deuxième architecture Bacula pour nos machines >= Debian 10. L'infra actuelle continuera de s'occuper de nos serveurs < Debian 10…

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.