PASS: Le pass partout

2021-09-14 09:58:53 by MatMoul

Suite à mon post "COVID-19: C'est quoi ce délire de pass" du 13.09.2021, j'ai fouiné un peu le Github d'admin ch.

Et que ne fût pas ma surprise de trouver un premier commit qui date du 5 mai 2020 nous venant tout droit de l'EPFL. Cela ne date donc pas de quelques mois et cela se préparait depuis un moment.

Le projet semble maintenant gérer par Ubique (une entreprise privée).

Petit rappel, le 7 mars 2021, il y a tout juste 6 mois, la Suisse votait sur l'e-id gérer par une entreprise privée.
Le résultat du vote était sans appel, NON.

Mais ce matin je lis par hasard un article sur l'identité numérique Européenne.
Puis en fin de journée je tombe sur un article de notre torchon de 20 Minutes qui nous reparle de l'e-id.

On sent vraiment qu'il y a des choses dans les cartons...

Cela me rappelle aussi la première tentative de Post Swiss qui prévoyait de nous fournir l'e-voting.
Le BugBounty de février 2019 n'a pas résisté plus d'une semaine.

Mais quelle ne fût pas ma surprise de trouver un nouvel article le 14 septembre 2021 nous annonçons un nouveau BugBounty de l'e-voting de la Post (Une société privée).

Est-ce moi qui me pose la question ou lorsque l'on refuse une identité numérique gérée par une entreprise privée par votation, on pourrait accepter un système de votation ou un pass sanitaire géré par une entreprise privée ?

Cette dernière phrase tourne un peu la tête mais c'est fait pour...

Update :
Et je vous propose mon premier tools pour lire les données de votre pass européen ou suisse (c'est un peut brut mais c'est un début) :
https://matmoul.ch/codescanner

Cette petite capsule temporelle sera sûrement très intéressante à relire dans quelques années.

COVID-19: C'est quoi ce délire de pass.

2021-09-13 08:19:01 by MatMoul

Mais que ce passe t'il en Suisse.

Lors de la mise en place des pseudos logiciels de traçages qui n'ont jamais vraiment fonctionnés, voici que l'on nous sort le SwissCovid (premier commit trouvé le 5 mai 2020).

Ce projet est même disponible en Open Source sur GituHub et vous pouvez l'installer depuis F-Droid.

Ils ont pensé à tout en quelques mois.

Lorsque l'on regarde le Github d'admin.ch, on constate un travail intense.

M. Berset nous dit que c'est temporaire mais malheureusement, vu l'investissement, il y a peu de chance que ce travail soit mis à la poubelle.

De plus j'ai décodé le QR Covid et il se décode de la même manière en Europe qu'en Suisse.

Que dire, j'ai analysé ce que je pouvais du code et c'est vraiment du haut niveau.

Quand on pense à nos scandales informatiques en Suisse, difficile d'avaler un développement aussi rapide et professionnel.

A méditer...

Debian: Montée en version Debian 10 (buster) -> 11 (bullseye)

2021-09-03 07:30:27 by MatMoul

Petit retour suite à la montée en version de Debian 10 Buster vers Debian 11 Bullseye.

Comme tout le monde, j'ai utilisé les commandes suivantes :

apt update
apt dist-upgrade

Une fois la dernière version de Debian 10 installée, j'ai utilisé ces commandes pour mettre à jour les dépôts :

sed -i 's/buster\/updates/bullseye-security/g;s/buster/bullseye/g' /etc/apt/sources.list
sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/*

Attention à cette dernière commande qui change les dépôts annexes (nodejs, proxmox, ...).
Ensuite :

apt update
apt dist-upgrade
apt autoremove -y
apt autoclean
apt purge
reboot

Dans l'ensemble, cela s'est bien passé mais j'ai eu un certain nombre d'effets secondaires....


Conteneurs LXC :

J'ai commencé par mettre à jour mes conteneurs LXC Debian hébergés sur Proxmox 6 qui fournissent un seul service (bind, nodejs, ...).
Après le reboot, j'ai constaté un problème de réactivité (latence clavier, requêtes aux services interminables, ...)
Pour ce premier problème, j'ai constater que Debian 11 nécessitait plus de RAM que Debian 10.
Mes plus petits conteneurs sont passés de 256MB à 320MB de RAM afin de résoudre ce problème.

Le deuxième problème était le Login en TTY ou SSH qui prenait une plombe...
Le problème venait de l’utilisation des NameSpaces par systemd-logind.
Proxmox préconise d'activer le "nesting" et il est maintenant activé par défaut pour les conteneurs dans Proxmox 7.
Comme je ne suis pas encore au clair avec tous cela, j'ai préféré masquer logind dans les conteneurs pour le moment.

systemctl mask systemd-logind.service

Je vous conseille cette page du forum pour vous faire une idée :
https://forum.proxmox.com/threads/lxc-container-upgrade-to-bullseye-slow-login-and-apparmor-errors.93064/


PHP 7.3 -> 7.4 :

Lors de la montée en version certains serveurs utilisant PHP 7.3 sont passés en PHP 7.4.
Les configs n'ont pas suivis de "/etc/php/7.3/*" à "/etc/php/7.4/*".
Comme je n'avais que quelques serveurs, j'ai fait ça à la mano et c’était laborieux...


Proxmox (Mail Gateway, Backup) :

J'ai commencé par mon cluster "Proxmox Mail Gateway" en LXC sur deux sites distants, aucun problème.
Puis par mes serveurs "Proxmox Backup" en VM sur deux sites distants, aucun problème.


Proxmox VE :

J'ai commencé par mon Cluster "Domestique", 3 vielles machines gonflées à bloque pour mes tests en campagne avec la connexion qui va avec.
Sur ces machines, j'utilise la carte réseau de la carte mère pour l'accès à Proxmox.
La mise à jour s'est bien passée à l’exception des cartes réseaux supplémentaires qui changent de noms.
Sur cette infrastructure plutôt simpliste, tout peux être réglé en ssh ou https.

Puis je suis passé à mon cluster "Pro" distant (3 serveurs identiques avec 1 interface réseau sur le board et 4 interfaces réseau sur carte PCI).
J'ai commencé par le serveur de test qui utilisait pourtant ifupdown2 mais lors du reboot, plus de réponse.
J'ai checké sur le switch et les 4 interfaces supplémentaire étaient down.
Comme l'interface d'administration était sur cette carte, j'ai du aller sur site pour gérer les bridges (vmbr) avec les nouveaux noms d'interface (pour info, le nom de l'interface du board n'a pas changé).

Ensuite je suis passé au deuxième serveur qui héberge les services qui peuvent être dégradés.
Ayant appris du premier serveur, j’ai anticipé les problèmes et les évités.
Toutefois, j'avais deux conteneurs CentOS7 qui ne fonctionnaient plus et cela était clairement indiqué dans la doc de Proxmox (migration sur les cgroup v2 incompatible avec la version systemd de CentOS 7).
Pour supporter ces vieux services qui ne sont pas exposé sur internet, j'ai installé un Proxmox 6 dans une VM du Proxmox 7 afin de gérer ces 2 conteneurs.

Et pour le troisième qui devait passer comme une lettre à la poste, ce fut plus compliqué....
J'ai lancer la mise à jour en anticipant les changements de nom d'interfaces réseaux et lors du reboot, plus de réponse.
Intervention sur site et que vois-je, le nom de l'interface n'avait pas changé.
Je corrige le bridge et redémarre.
Tous semble rentré dans l'ordre, sauf que...
Mes VM restent figées au boot et même un stop dans l'interface de Proxmox prend une plombe.
Je migre une VM sur un autre serveur et elle fonctionne, je la migre à nouveau sur ce troisième serveur et je me retrouve dans la situation précédente.
Je fini par comprendre que ce serveur avait redémarrer sur un ancien Kernel.
Je nettoie l'ancien Kernel et redémarre me retrouvant sans accès réseau.
Le nom des interfaces avait changé et j'avais oublié ce problème entre temps.
Il m'aura fallu retourner sur site encore une fois mais ce fut la dernière.


Conclusion :

La montée en version est assez facile mais il vaut mieux avoir un accès physique ou virtuel à la console et prévoir un peut de temps pour gérer les imprévus.

Business : Mon entreprise en 2021

2021-01-15 09:26:44 by MatMoul

Nous voilà déjà en 2021 avec toutes les entraves de nos politiques...

Je tiens bon et la majorité de mes clients aussi.

Mon parc informatique a massivement évolué comme celui de de mes clients qui vont survivre à cette crise.

C'est dure à dire mais il y a ceux qui prennent le train en route et ceux qui reste sur le quai...

Bon courage à vous !

COVID-19 : Que fait un SysAdmin lors du COVID-19 ?

2020-04-10 01:00:52 by MatMoul
Avant le COVID-19, il essayait de migrer tous ses clients de Win7 à Win10 et se débarrasser des Win8...

Maintenant, il a tout mis en pause et installe des solutions de télétravail et se repose sur les solutions de sauvegarde actuellement mis en place en espérant que cela soit suffisant...

Mais quand cela va t'il se terminer ?