Le Blog Utux

HTTP 200 GET /

Les PC, c'est de la merde

Rédigé par uTux 22 commentaires

Derrière ce titre provocateur se cache un triste constat : je ne peux recommander aucune marque de PC. Pourquoi ? Parce qu'on assiste à une "tabletisation", c'est à dire un prix bas destiné à vendre en masse, avec des composants sous-dimensionnés, plein de crapwares préinstallés et pas de choix de l'OS.

Secure boot c'est génial, c'est du pain béni pour Microsoft et les constructeurs. On vous impose Windows 10, l'OS qui n'a pas de mode sans échec, et on ne vous fourni pas les CD. En cas de problème faites une restauration système ce qui remettra tous les crapwares que vous avez désinstallé pendant des heures. Oui, exactement comme sur les tablettes et smartphones.

En poussant l'idée plus loin, je dirais même que le dépannage de machines est devenu chiant. Avant on avait des pannes matérielles, des demandes d'évolution (ajout de RAM ou SSD), des nettoyages de virus. Aujourd'hui le dépannage ça se résume à dézombifier des machines, l'utilisateur ayant installé n'importe quoi il se retrouve avec une avalanche d'adwares et de services non désirés. Et donc le boulot consiste à les nettoyer sachant que Windows est l'un des seuls OS en 2016 qui ne peut désinstaller que 1 logiciel à la fois de manière PUTAIN D'EXTRÊMEMENT LENTE. Sérieusement on a 8GB de RAM, des CPU 8 coeurs, des SSD, et pourtant DÉSINSTALLER UN LOGICIEL SUR WINDOWS EST TOUJOURS UN CALVAIRE.

Ah oui et depuis quelques mois j'ai constaté beaucoup de problèmes avec les mises à jour de Windows 7, Windows Update ne les trouve plus ou l'installation échoue (après de longues minutes voire heures bien entendu). De là à y voir un complot de Microsoft qui veut une fois de plus vous forcer à manger du Windows 10, il n'y a qu'un pas que je franchis. Des heures et des heures passées à bidouiller le registre, renommer des dossiers dans System32 en espérant que cela débloque Windows Update.

Faire du dépannage informatique aujourd'hui c'est comme un mécanicien automobile qui passerait sa journée à bricoler des voitures lowcost qui n'avancent pas car le moteur est sous-dimensionné et alourdit par des pièces de fonte que l'utilisateur aurait ramassé involontairement sur la route.

La solution ? Taper dans les gammes PRO des constructeurs (et encore, pas tous) car on a du matériel un peu plus sérieux, un OS moins crapwarisé et un peu plus de souplesse (secure boot désactivable, voir retour au BIOS). Malheureusement c'est un peu moins accessible et plus cher, mais il serait temps que les gens comprennent qu'acheter une tablette à 50€ et un PC à 150€ est une mauvaise idée et ne sert qu'à alimenter un marché qui s'est emballé et finira par exploser en laissant un tas de gens sur le bord de la route. Faites des achats plus raisonnés et choisissez des marques sérieuses, oubliez le lowcost. Et au passage utilisez LINUX l'un des derniers OS qui n'envoie pas vos données sur internet et ne vous force pas à migrer vers la version supérieur : Ubuntu ou Mint si vous débutez, Manjaro ou Fedora si vous voulez un truc très à jour, Debian ou Mageia si la stabilité est un point important pour votre utilisation.

systemd, c'est bien.

Rédigé par uTux 22 commentaires

Systemd est un système d'init "moderne" qui remplace le vieillissant sysvinit. L'init c'est le premier process qui démarre après le boot et qui va "orchestrer" le lancement des services : réseau, logs, ssh ... Mais wikipedia explique cela mieux que moi.

Dire que systemd a provoqué de nombreuses polémiques et levées de boucliers de la part des utilisateurs est un euphémisme, c'est un beau bazar dans lequel des troll s'affrontent au lance-flammes. On lui reproche de nombreuses choses : réinventer l'eau chaude alors que sysvinit marche bien, être monolithique et donc contraire à la philosophie UNIX, être le cheval de troie de Red Hat pour à terme remplacer de plus en plus de composants dans Linux, ne pas être portable sur les autres OS, etc. Je pense que la plupart des critiques sont vraies et que dans quelques années nos distributions ne seront plus GNU/Linux mais SystemD/Linux. Néanmoins il est intéressant d'observer qu'après 6 ans d'existence, systemd s'est imposé partout à l'exception de Gentoo (+et Slackware) et ce n'est pas par hasard.

Je ne vais pas énumérer point par point les fonctionnalités de systemd, je vais me contenter d'en présenter deux aspects que je trouve intéressants : création d'un service et d'un containers (nspawn).

Création d'un service

Avez-vous déjà écrit des scripts d'init pour un logiciel sur Linux ? Moi oui. Et entre sysvinit et systemd, c'est le jour et la nuit. Prenons pour exemple Nginx :

C'est quand même beaucoup plus simple avec systemd puisqu'une grosse partie du boulot est faite nativement, par exemple la gestion du pid et des logs. Pour sysvinit par contre c'est au développeur du script de prévoir tous les cas, de coder la vérification du pid, des logs, bref c'est long et pas forcément utile puisque même sur Windows on ne fait plus ça depuis 20 ans.

Création d'un container

Systemd est très lié à Linux et aux cgroups, il est possible d'isoler des processus dans leur propre contexte, de là à créer des containers avec une application ou un système entier il n'y a donc qu'un pas qui a été franchit. Pour l'exemple on va créer un container ubuntu-server-16.04 à partir d'une image cloud (pour nous épargner les étapes debootstrap qui n'ont pas vraiment d'intérêt dans cet article) :

root@localhost:~# wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz
root@localhost:~# mkdir /srv/containers/xenial01
root@localhost:~# tar -xf xenial-server-cloudimg-amd64-root.tar.gz -C /srv/containers/xenial01

Note : sur les versions plus récentes de systemd (non disponible sur Debian Jessie), l'utilitaire machinectl permet de télécharger et déployer une image automatiquement. Voir la section Examples de la documentation machinectl.

Puis démarrer un shell dans le container afin de pouvoir créer un mot de passe root :

root@localhost:~# systemd-nspawn -D /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
root@xenial01:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@xenial01:~# exit

Maintenant on peut - si on veut - démarrer complètement le container :

root@localhost:~# systemd-nspawn -bD /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR
+SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ 
-LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Ubuntu 16.04 LTS!

Ensuite la séquence de démarrage s'affiche et il est possible de se loguer, puis d'arrêter le container avec la commande poweroff :

Ubuntu 16.04 LTS ubuntu console

ubuntu login: root
Password: 
Last login: Mon May 23 09:12:29 UTC 2016 on console
run-parts: /etc/update-motd.d/98-fsck-at-reboot exited with return code 1
root@ubuntu:~# poweroff

Si on ne spécifie aucune option au niveau du réseau, le container utilisera l'interface de l'hôte. Attention donc aux services qui écoutent sur les mêmes ports, typiquement SSH, le mieux est encore d'utiliser une interface réseau virtuelle. Je ne rentre volontairement pas dans les détails afin de ne pas faire un article indigeste, mais il est possible d'aller plus loin notamment au niveau des interfaces réseau (bridge, macvlan, veth), des limitations du système (mémoire, cpus...) ou encore de l'intégration avec SELinux. On peut aussi utiliser debootstrap, dnf ou pacstrap pour créer un container (pas besoin d'une image cloud). Pour cela voir la documentation systemd-nspawn et systemd.resource-control (elles ne sont pas si indigestes que ça).

Systemd-nspawn est une alternative intéressante à LXC permettant de gérer des containers thin (on lance uniquement une application) ou thick (on lance tous les services) sans avoir à installer quoi que ce soit.

BONUS : sous debian, ça ne change rien pour les utilisateurs

Si je peux comprendre que beaucoup de gens n'aiment pas systemd et ne souhaitent pas l'utiliser, en revanche je ne comprends pas pourquoi cette grogne est focalisée chez les utilisateurs de debian au point de créer le fork devuan. Parce que si vous êtes utilisateur de debian, systemd ne change rien pour vous. Tout d'abord le boulot est fait par les mainteneurs des paquets, vous n'avez jamais touché à un système d'init de votre vie, et avec systemd vous n'y toucherez pas non plus. Ensuite, si vous faites un peu de sysadmin, là encore rien ne change pour la majorité des opérations.

Voici pour comparer la manière dont on démarre apache :

root@localhost:~# service apache2 start # avec sysvinit
root@localhost:~# service apache2 start # avec systemd

C'est pareil, parce que debian est une distribution pour fainéants (comme moi) très bien foutue. Même chose pour le réseau, ça se gère toujours dans /etc/network/interfaces rien ne change.

Sous Archlinux par contre tout change par exemple le fichier /etc/rc.conf a disparu au profil de fichiers éclatés pris en charge par systemd. Ce n'est pas méchant mais il a fallu réapprendre certaines choses. Malgré une grogne passagère la chose semble avoir bien été acceptée par les utilisateurs, en tous cas ils ne sont pas partis forker leur distribution.

Conclusion

Au final, après avoir lu tant de troll, tant de FUD sur systemd, je trouve que c'est plutôt bien. C'est simple à utiliser et c'est puissant puisqu'on peut imaginer un jour remplacer LXC et cela ouvre plein de possibilités au niveau des serveurs, par exemple avoir des instances apache et nginx isolées dans les containers thin, ou encore des applications portables à la manière de Snap ou xdg-app. Pour 99% des utilisateurs de Linux la transition est transparente puisque prise en charge en amont par les mainteneurs.

Je prends donc le risque d'invoquer une armée de troll dans les commentaires mais moi j'approuve systemd.

ESET Nod32 usurpe mes certificats SSL ?

Rédigé par uTux 5 commentaires

J'ai un ordinateur de gaming sous Windows avec l'antivirus ESET Nod32 (il me restait une licence dans un coin). Et ce matin j'ai remarqué un truc intéressant : ce bougre usurpe l'identité de mes certificats SSL. En effet mon blog, utux.fr, est signé par Let's Encrypt. Or, sur ma machine avec ESET Nod32 installé, voici ce que Firefox affiche :

ESET

ESET installe sa propre autorité de certification dans Windows (ce qui rend l'usurpation possible) et re signe les certificats que vous utilisez. Pourquoi ? Le but des certificats signés c'est pas justement de valider la chaîne de confiance jusqu'au serveur ? D'empêcher des interceptions ? Ce que fait ESET Nod32 est justement ce que l'on cherche à éviter non ? Que se passe-t-il si une porte dérobée est découverte dans Nod32 et permet à des personnes mal intentionnées de signer tout et n'importe quoi sur ma machine ?

De Thunar vers Nemo

Rédigé par uTux 12 commentaires

Sur une de mes machines j'utilise Debian testing en version Xfce et je rencontre un bug ennuyeux avec Thunar qui dure depuis des mois : si je fais un glisser-déposer d'un fichier zip entre deux fenêtres, il y a 50% de chances pour qu'il crashe.

Xfce fut un temps le cousin de GNOME, donc j'ai essayé de passer sur Nautilus. Mais GNOME3 et son écosystème logiciel vit selon ses propres règles, ainsi l'intégration dans Xfce est plutôt sale allant même jusqu'aux glitchs graphiques. On m'a conseillé de tester Nemo, le gestionnaire de fichiers de Cinamon né d'un fork de Nautilus. Et c'est plutôt bon.

Nemo (en haut) VS Nautilus (en bas). La bordure noire est un glitch visuel.

Nemo a un look & feel plutôt naturel avec Xfce tout en étant très stable et rapide à charger. Je l'utilise donc en remplacement de Thunar et je le vis plutôt bien pour le moment.

Pour l'installer sur Debian :

$ sudo apt-get install nemo

Puis, pour le passer en gestionnaire de fichiers par défaut dans Xfce : Paramètres > Applications Favorites > Utilitaires > Gestionnaire de Fichiers.

Snap et l'art de basher Canonical

Rédigé par uTux 22 commentaires

Ubuntu 16.04 est sortie et apporte une nouveauté de taille : un système de paquets nommé Snap qui permet d'embarquer un logiciel + ses dépendances afin de ne plus être lié aux versions des librairies présentes sur le système. Une bonne idée à mon sens qui rappelle PC-BSD et ses pbi même si c'est quand même plus moderne et plus poussé notamment avec l'utilisation de containers pour isoler proprement.

Mais comme il s'agit de Canonical, la tête à claques du monde de l'opensource, tout est bon pour lui taper dessus. Et ça commence déjà avec cet article : Linux Ubuntu 16.04 touché par une sérieuse faille de confidentialité avec son titre bien racoleur à la limite du FUD. Après lecture on se rend compte que les reproches sont adressées à Xorg qui ne permet pas d'isoler des fenêtres. En gros un logiciel lancé depuis un container Snap peut très bien récupérer les informations d'un logiciel dans un autre container si les deux ont ouvert des fenêtres. C'est tout ? Certes c'est pas cool mais :

  • Ça existe aussi sans Snap puisque le problème c'est Xorg.
  • Ce n'est pas vraiment une faille mais un problème de conception (Xorg est vieux).
  • Les Keyloggers existent sur tous les OS.
  • Et pour finir, la "faille" n'est pas exploitable avec Mir.

S'il est si facile de taper sur Canonical, c'est peut-être parce qu'ils essaient de faire des choses : des smartphones sous Ubuntu notamment ce qui est là encore une bonne idée vu que l'offre Linux est inexistante en dehors de Android. Snap répond à un besoin et exploite les outils modernes comme les containers donc donnons une chance à ce produit au lieu de l'utiliser comme prétexte pour troller.

Fil RSS des articles de cette catégorie