Le Blog Utux

HTTP 200 GET /

OpenBSD + httpd: marrant, mais trop limité

Rédigé par uTux 2 commentaires

J'aime bien OpenBSD. Malgré sa réputation de vieux système Unix implacable sur la sécurité, il est d'une simplicité déconcertante, cohérent, et bien documenté. Un inconvénient tout de même était la difficulté d'installer les mises à jour (il fallait télécharger et décompresser soi-même les sets, ou booter sur un CDROM) mais ce point a enfin été résolu avec syspatch et sysupgrade. Mettre à jour OpenBSD est désormais aussi simple que n'importe quelle distribution Linux !

Sachez qu'il est possible d'installer OpenBSD chez hetzner, car l'hébergeur fournit un accès kvm (même sur les serveurs virtuels à bas prix) et permet de piocher dans une bibliothèque d'ISOs bootables. NixOS, Arch, FreeBSD, ... et OpenBSD. Un gros +1 pour Hetzner qui laisse cette liberté aux utilisateurs (et en plus ils ont un provider Terraform, si ça c'est pas qualitatif...).

J'ai donc installé un petit serveur OpenBSD afin d'héberger 1 ou 2 sites statiques pour un side project. Le but était surtout de m'amuser et utiliser httpd, le serveur web builtin de ce système d'exploitation.

Commençons par parler des points positifs. OpenBSD et httpd sont très simples à configurer, la lecture des manpage est presque suffisante en soit, alors que pour Linux je commence toujours par regarder des exemples, avant d'attaquer la documentation. Un client acme est également intégré dans le système, il n'y a rien besoin d'installer pour se générer des certificats Let's Encrypt. Et... c'est à peu près tout. Je pourrais dire que httpd est léger et sécurisé, mais quand il s'agit de servir des contenus statiques, c'est à peu près toujours le cas.

Passons maintenant aux points négatifs. Tout d'abord, il y a cette blague (pas drôle) des messages d'erreur en Comic Sans MS (et oui) dont on peut heureusement se débarrasser, au prix d'une petite bidouille. Mais ça ce n'est pas grand chose, car le plus gros problème avec httpd selon moi, c'est qu'il ne fait vraiment pas grand chose, à part servir des pages web. Par exemple il n'est pas possible de spécifier de Header set Cache-Control "max-age=604800, public", qui permet d'indiquer aux navigateurs qu'ils doivent mettre en cache les ressources statiques. Et ça se ressent fortement sur le temps de chargement de vos pages.

En fait, httpd a besoin d'être complété par relayd, un reverse-proxy beaucoup plus complet. Le problème est que sa configuration est un poil plus complexe, et que ça m'ennuie un peu d'avoir un reverse-proxy sur la même machine tout ça pour ajouter un simple header dans les réponses. Au final, je suis resté sur du 100% httpd, sans le cache, et mes sites ont du se contenter de performances honorables mais pas optimales.

Aujourd'hui l'expérience est terminée, et j'ai re migré mes sites statiques vers NixOS + Apache.

2 commentaires

#1  - Jean-Philippe a dit :

Bonjour,

Pour moi l'intérêt de mettre un proxy inverse (je ne parle pas que de "relayd") devant un site web va au delà de modifier des entêtes de pages web. Je pense particulièrement à utiliser un pare-feu applicatif (on a le choix).

Salutations.

Répondre
#2  - uTux a dit :

Oui c'est un peu ce que je disais, un reverse proxy juste pour ajouter un header c'est complètement overkill.
En général on les utilise pour du ssl offloading, load balancing, waf...
Pour moi qui propulse 2 petits sites statiques à faibles visites sur un unique serveur, c'est inutile.

Répondre

Écrire un commentaire

Quelle est le dernier caractère du mot hvm13c ?