J'ai commencé à rédiger cet article il y a presque un mois, mais par manque de temps et d'inspiration il est resté à l'état de brouillon. Je le publie aujourd'hui car même si l'événement n'est plus d'actualité, les réactions de certaines personnes m'ont vraiment indigné et donné l'envie d'écrire.
Vous connaissez l'histoire, en 2008 un utilisateur, Vincent Deroo-Blanquart, achète un ordinateur SONY et porte plainte parce que l'ordinateur est fourni avec Windows et tout un tas de logiciels dont le prix n'est pas clairement indiqué et surtout il n'y a pas de moyen de les refuser sans renoncer à l'achat. Il est finalement débouté et la vente liée que l'on a toujours cru illégale est même déclarée explicitement comme acceptable par la justice européenne : résumé (NextINpact). Ce jugement est potentiellement lourd de conséquences puisqu'il pourrait inciter les constructeurs qui pratiquent aujourd'hui des remboursements du système d'exploitation à cesser cette pratique.
La vente liée est le ciment du monopole de Microsoft, l'écrasement absolu de toute concurrence puisque quoi qu'il arrive chaque ordinateur vendu dans le monde = 1 licence Windows. Et elle n'est pas gratuite, elle représente une partie du prix du PC. C'est un fait dénoncé entre autres par les utilisateurs de Linux depuis des années mais qui touche en réalité bien plus de gens, par exemple ceux qui veulent installer leur propre copie de Windows 7 ou encore les professionnels qui ont des licences en volume et qui se retrouvent à payer en double pour rien lors des achats de matériel.
Cyrille donne un avis tranché et considère le plaignant comme un emmerdeur puisque de toutes manières il existe des ordinateurs sans OS tels que ceux proposés chez LDLC. Si sa démarche était réellement d'emmerder le monde alors je tiens à le féliciter, s'attaquer seul aux poids lourds que sont SONY et Microsoft , faire remonter l'affaire jusqu'à la justice européenne avec ses propres deniers tout ça pour en arriver à une conclusion qui constitue un retour en arrière pour les droits des consommateurs, c'est le troll du siècle. Sauf que la plainte date de 2008, époque à laquelle il était encore plus difficile qu'aujourd'hui de trouver des ordinateurs sans OS, et qu'en plus on a pas forcément envie d'acheter la marque LDLC. Et enfin les vraies questions de la vente liée sont, une fois de plus, évitées.
L'approche de ce jugement est purement pragmatique : les gens veulent un OS sur leur ordinateur, et même si le prix était clairement indiqué, même si on pouvait refuser, ça n'influencerait pas la décision d'achat, donc il est inutile de détailler le prix des logiciels ou donner la possibilité de refuser. Admettons, mais dans ce cas pourquoi Microsoft ? Pourquoi ne pas permettre à d'autres éditeurs de préinstaller leurs OS ? Même sans évoquer Linux, la question de l'illégitimité du monopole de Microsoft n'est jamais soulevée. Et puis si on va au bout du raisonnement, pourquoi continuer à indiquer les ingrédients et compositions sur les produits que l'on achète au supermarché, puisque ça n'influencerait pas les achats des consommateurs ? Ou dans l'autre sens : s'il n'y a pas d'influence négative sur le marché, pourquoi ne pas afficher les prix ? De plus on ne demande pas le retrait de Windows sur chaque machine, on demande l'affichage du prix réel des logiciels ainsi que la possibilité de les refuser sans devoir renoncer à l'achat.
Morgan Spurlock, protagoniste et réalisateur du film Supersize Me aurait pu être lui aussi être qualifié d'emmerdeur, mais aujourd'hui tout le monde considère qu'il a raison et que derrière l'économie, les emplois et le succès des fastfood, il y a la malbouffe, les maladies, l'endoctrinement des enfants, la désinformation des adultes. De là à transposer cette situation à l'informatique et à dire que dans quelques gouvernements années on réalisera que donner les clés de notre industrie / éducation / défense à Microsoft n'est pas une bonne idée et qu'on indiquera au moins le prix des logiciels sur les ordinateurs en grande surface, il n'y a qu'un pas utopiste que je franchis.
En conclusion, non, notre plaignant, Vincent Deroo-Blanquart n'est pas un emmerdeur, ou alors si mais dans le bon sens, et en tant que geeks nous devrions le remercier d'être allé aussi loin alors que tout le monde se contente de râler ou fermer les yeux, parce qu'au final ce n'est pas le desktop linux qui importe, c'est que le PC reste une plateforme ouverte avec du choix sur laquelle nous pouvons bidouiller.
L'environnement ARM est trop fragmenté et pas assez ouvert. Qui n'a jamais essayé de recycler une vieille tablette en lui installant une distribution Linux ? C'est souvent impossible. Les spécificités hardware, les bootloaders, les verrous, les blobs propriétaires font qu'un kernel vanilla ne fonctionne pas et qu'il faut alors prier pour que le constructeur fournisse la documentation/procédure/code source pour espérer faire quelque chose, et bien sûr cela n'arrive jamais. L'idée de pouvoir un jour booter une simple iso de debian est une douce utopie totalement hors de portée.
Tous les produits à base d'ARM sont conçus dans une optique de consommation rapide, du jetable, le but est simplement de briller dans les benchmark pendant 2 mois et permettre l'accès à Google Play pour que l'utilisateur puisse dépenser son argent, le reste est secondaire.
C'est simple, je ne serai jamais devenu un geek si j'avais grandit avec ce genre de produit non bidouillable entre les mains, je n'en aurais pas fait mon métier non plus.
Dans l'article systemd, c'est bien je citais systemd-nspawn qui est plus ou moins un équivalent à docker exec (lancement d'un binaire dans un container) ou lxc (démarrage complet du container) mais en upstream. Voici un petit cas pratique avec le lancement d'une application graphique :
Avertissement : cet article a pour but de montrer un cas d'utilisation intéressant de systemd-nspawn, mais la manipulation ci-dessous n'est pas propre, ne la faites pas à l'aveugle. La commande xhost autorise les connexions au serveur graphique tandis qu'un peu plus bas je lance l'application graphique directement en root. Vous devez donc être sûr que votre application n'est pas un keylogger ou un spyware.
La commande xhost +local: est volatile donc à refaire après un redémarrage de l'hôte. C'est pareil pour export DISPLAY=:0 dans le container car c'est une variable d'environnement.
Cette petite astuce en vrac me sert pour pac que je fais tourner dans un container Debian Jessie car il ne fonctionne actuellement plus en Testing.
Je connais bien OpenBSD pour y avoir fait tourner mon serveur pendant plusieurs mois. J'en ai un bon souvenir, c'est un système simple à comprendre et à configurer grâce à des syntaxes humainement lisibles dans les fichiers de configuration. Malheureusement OpenBSD est encore primitif sur de nombreux points, par exemple les mises à jour. En fait il n'y a aucun dispositif de mise à jour, il faut télécharger les sets en .tgz et les décompresser en écrasant le système, voire même tout recompiler. Deux autres problèmes majeurs que je vois sont d'une part le fs UFS vieillissant et lent (surtout si on compare à FreeBSD et son ZFS) et d'autre part les ports pas toujours à jour car il y a beaucoup moins de mainteneurs disponibles. C'est pourquoi je pense qu'OpenBSD est bien pour certains usages spécialisés qui peuvent se contenter des daemons de base, mais dans beaucoup d'autres cas il se fait éclater par FreeBSD et Linux, par exemple en usage stockage ou desktop.
A l'époque où j'utilisais OpenBSD (2011), le daemon web était un Apache 1.x lourdement modifié et le projet était en cours de migration vers Nginx. Mais ce dernier a été délaissé à son tour au profil de httpd, un serveur maison. Je n'y ai pas vraiment prêté attention jusqu'à récemment avec la lecture du blog de thuban (ou encore De l'épice pour la pensée) qui m'a rendu curieux. Thuban est tellement amoureux d'OpenBSD que quelques temps après l'avoir essayé, il a migré son serveur et écrit un livre.
Exemple simple
Puisqu'on est sur OpenBSD, la configuration sera forcément humainement lisible et centralisée dans un fichier. Le manpage est consultable ici. OMG UN MANPAGE, MER IL ET FOU ! Et oui, sur Linux les manpage sont souvent imbuvables, mais sur OpenBSD ce n'est pas le cas. Pas de panique, on va faire un exemple ensemble :)
On va simplement configurer notre httpd pour servir une page lorsque l'IP du serveur est appelée.
Voici ce qu'on met dans notre /etc/httpd.conf :
server "default" {
listen on * port 80
}
Par défaut, notre serveur travaillera dans /var/www/htdocs et /var/www/logs. On créé une page html de test :
echo "Hello" > /var/www/htdocs/index.html
On autorise httpd à démarrer :
echo httpd_flags="" >> /etc/rc.conf.local
Puis on démarre httpd :
/etc/rc.d/httpd start
En tapant l'adresse IP du serveur dans votre navigateur, vous devriez avoir le Hello sur fond blanc.
Vous pouvez éventuellement jeter un œil aux fichiers de logs :
On édite notre /etc/httpd.conf dans lequel on va définir nos paramètres globaux, ainsi que nos fichiers splittés de vhost :
chroot "/var/www"
logdir "/var/log/httpd"
include "/etc/httpd/site1.conf"
include "/etc/httpd/site2.conf"
Note : la ligne chroot est inutile ici car sa valeur par défaut est déjà /var/www néanmoins je trouve utile de la préciser, par souci de lisibilité.
/etc/httpd/site1.conf :
server "default" {
listen on * port 80
root "/htdocs/site1"
}
/etc/httpd/site2.conf :
server "ssl" {
listen on * tls port 443
root "/htdocs/site2"
tls certificate "/etc/ssl/cert.pem"
tls key "/etc/ssl/key.pem"
}
Note :root doit être un chemin relatif au chroot. Par exemple le /htdocs/site2 se rapporte implicitement à /var/www/htdocs/site2.
Après avoir rechargé httpd, l'accès à notre serveur en http (port 80) doit afficher le site 1 :
Et l'accès en https (port 443) doit afficher le site 2 :
Conclusion
httpd est un serveur web simple à prendre en main qui ne plaisante pas avec la sécurité, le chroot ayant une place importante dans son fonctionnement. Alors faut-il laisser tomber Apache et Nginx ? Pour un usage basique, c'est à dire servir des pages web, pourquoi pas, car c'est simple et robuste. En revanche, pour des usages avancés, non. À part renvoyer les requêtes dans un socket en fastcgi et servir du contenu statique, on ne peut pas faire grand chose. Pas de reverse proxy par exemple, ce rôle étant confié à relayd. Un autre point agaçant est le fait qu'en cas d'erreur le daemon httpd refuse de démarrer mais n'affiche aucune erreur et ne produit aucun log, donc bonne chance pour debugger.
Si vous êtes un amoureux d'OpenBSD, il est évident que vous ne tarderez pas à migrer vers httpd. Si vous n'êtes qu'un simple Linuxien, j'espère que cet article aura chatouillé votre curiosité.
J'utilise backuppc sur mon NAS à la maison pour sauvegarder mes VPS. J'aime cet outil car il est assez simple et s'appuie sur SSH + rsync des logiciels connus.
Pour un serveur Linux avec rsync, backuppc va tout sauvegarder à partir de /, ce qui est bien mais il y a des répertoires qu'on a pas forcément envie d'inclure, par exemple /tmp et /run qui sont volatiles ou /mnt qui est utilisé comme point de montage.
Avant je faisais comme ça :
Sauf qu'il s'avère que cette exclusion est un peu violente puisqu'elle ne va pas s'appliquer qu'aux répertoires situés à la racine, mais à tous. Et donc j'ai eu des surprises en constatant que dans ma sauvegarde, /var/www/dokuwiki/data/media était lui aussi exclu, ainsi que /var/www/dokuwiki/data/tmp.
Bon cette fois ce n'était pas méchant, mais voici la bonne pratique pour les exclusions, utiliser des chemins absolus :
