Logo du site un pigeon rissa assie sur un caillou pianontant sur un ordinateur dans le noirLogo du site un pigeon rissa assie sur un caillou pianontant sur un ordinateurLibérer les connaissances

L'enfer de Caddy, simplement inutilisable.

Categories:
  • Caddy
  • Serveur Web
  • Test
Tags:

Pour ce post, je vais vous conter l'histoire d'une tentative de migration d'un serveur web. Un simple balade qui se transforma en torture.

Mise en bouche:

Cette migration fait suite à une utilisation de Apache sur une Orange Pi PC (un équivalent d'un Raspberry Pi). Cette carte avec architecture ARMv7 et 1Go de RAM, a commencé à souffler du nez lorsque je lui installa nombre de petit logiciel dans le but de m'auto-héberger et in fine être auto-suffisant dans le monde des services d'internet. Plus de détail sur cet auto-hébergement dans un prochain post.

Caddy est un logiciel qui à pour but initial de servir des pages web de façon sécuriser. Et cette dernière informations est importantes car il érige cette possibilité comme une obligation et une facilité déconcertante avec Auto-Magic, une fonction qui permet de délivrer un certificat de manières automatique et magique!!! Pour rappel: la sécurité n'est pas un produit. Alors il est de bonne intention de ce méfier d'un tel slogan.

Pourquoi avoir choisi Caddy, plutôt qu'un autre?
Inconvénient connu avant la tentative de migration:

But:

Mon projet dans cette migration est extrêmement simple dans un premier temps:
Héberger un site web statique: c'est à dire qu'il y a simplement des fichiers à délivrer sans aucun moteur derrière, tel que PHP, python ou Perl.
Une seul contrainte: Je refuse la fonction AutoMagic, car je ne souhaite pas qu'une autre applications possèdent des droit de modification sur mes certificat, ou encore que de nouvelles clées publique(/priver) pop de façon incontrôlées sur internet sans que je sache si elles ont été créée par moi-même.
Par conséquent: Je lui fournirai moi-même la clé privée, ainsi que le certificat Let's encrypt.

Compte rendu de ma tentatives de migrations:

Comme vous le voyez dans le titre, cette migration ne s'est résumé qu'à une tentative car elle s'est soldé par un échec.
En terme de temps, vous pouvez vous dire que j'ai essayé de le faire fonctionner pendant de longues heures. Après y avoir passé une journée entière (entre 9/10h de travail effectif), j'ai décidé, in fine, d’abandonner.

La première embûche: Le téléchargement fut un calvaire. Faute d'avoir un package tout fait, il faut aller sur le site CaddyServer.com et le télécharger à la main.
Pour commencer j'ai voulu prendre la V1 qui est stable.
Je vais d'abord sur le site download et je constate 2 liens:

Je souhaite juste le tester avant le l'intégrer entièrement dans le système par conséquent le télécharge directement le binaire.
Je constate un GRANDS choix de plugin... Je passe pour le premier test.
Passons mon erreur de choix d'architecture.
-> Impossible d’exécuter mon exécutable. le serveur m'affirme haut et fort que ce que je tiens entre mes mains n'est pas un exécutable. je m'étonne... j'abandonne l'idée du binaire.
Je me retourne sur le script one-step que j’exécute. Il me demande des informations sur la licence et rien... Aucun retour.Rien, il me dit juste qu'il a téléchargé Caddy... mais aucun fichier n'est apparu ou a été modifié.
Je scrute l’exécutable: je constate qu'il a besoin des droits sudo, cependant je ne souhaite pas donner de tel droit à un script que je ne connais pas plus que ça.
Je me re-retourne sur l’exécutable... et après analyse du script: il s’avère que l’exécutable est simplement compressé (en tar.gz), une information omit PARTOUT!!!
Nous avons finalement un script qui démarre: OK, on peux commencer!!!

Deuxième embûche: Impossible de faire fonctionner le moindre exemple!!!!
J'ai du commencer par lui donner de nombreux droit, dont ceux de bind le port 80... qui est obligatoire...
Apache continuais de tourner à coté et était en charge de faire les redirection du port 80. mais en grand seigneur, je donne à Caddy le droit de bind tous les ports qu'il veut sur mon interfaces WAN... Mais ce n'est pas suffisant. Si on ne le lui dit pas explicitement, il EXIGE toutes les interfaces, dont une interface privé.
Je passe l'affaire... et je test... encore et encore... toutes les combinaisons possible... IMPOSSIBLE de faire tourner le moindre exemple, mais encore pire, il ne me donne AUCUN message d'erreur!!!
Si message d'erreur il y a: il s'agit simplement de la ligne dans le code ou l'erreur c'est produite

Il s'agit d'ailleurs de la fonction Func1 .... .... ....

Chat blasé

POUVEZ-VOUS DONNER DES PUTAINS DE NOMS A VOS FONCTIONS!!!!!!!MEEEEEEEEEERDE!!!!!!!!!

De rage, j'abandonne la V1 et j'essaye la V2 RC2.

Troisième embûche:
Comme pour la V1, elle est compressé. Cependant, ici c'est marqué... Le nom du fichier termine par .tar.gz

Et là je retombe en boucle encore et encore sur des erreurs incompréhensible, que je suis le seul au monde à avoir.
Certaines section de la doc sont juste vide.
Les développeurs précise dans la doc de la V2 que le langage de configuration natif ne sont pas leur Caddyfile (lisible par un humain...), mais un fichier JSON et que certainnes fonctionnalitées ne seront pas implémentées dans la version Caddyfile.
Je retombe encore et encore sur des erreurs bizarre où cette fois le serveur me parle de problème avec la poignée de main TLS(/pareil du coté client).

Et d'un seul coup... plus d'erreur...
Mais absolument rien non plus...une page vide... juste totalement vide... mais j'arrive à afficher un hello world si je le passe directement dans le fichier de configuration.

Cela n'a aucun sens, et c'est là le problème: Le logiciel nous indique tout et n'importe quoi sans queue ni tête.

Et pour information, voici l'explication à pourquoi rien ne marchait:
Il manquait un espace entre le nom de la propriété et l'accolade!!!

file_server {

}

Le logiciel est tellement inconsistant que quand on lui demande de valider la syntaxe rien ne le choc...

le final:
J'ai réussi, tant bien que mal à afficher mon site web, il semble bien, à un truc près:
la fonction try_files (qui est belle et bien documenté et qui a la même fonction de nginx) ne fonctionne tout simplement pas. Ce qui a pour conséquence que lorsque les liens ne finissent pas par .html, cela ne fonctionne pas.

J'ai abandonnée après cette dernière fantaisie.

Conclusion :

Après autant de péripéties: je ne peux que déconseiller Caddy en l'état. Il est non-fini et inutilisable, mais j'ai probablement une explication à cela.
C'est que l'entreprise de Caddy(Ardan Labs) va vendre du S.A.V. aux entreprises(ce qui n'est pas une mauvaise chose en soi), mais il n'y a aucune communautée pour compenser cela. Le logiciel étant relativement jeune, il n'y a aucun moyen d'avoir un bon support.

Le principe du Caddyfile est extrêmement bien, car on a tendance à se perdre dans les configurations de Apache qui nécessite des fois beaucoup de lignes pour simplement avoir une configuration TLS potable.
Mais si le fichier est trop consistant, la moindre erreur tel qu'un espaces peu prendre des heures si on n'est pas informé.

Un tel logiciel permettrai également de compenser les imbécilitées des entreprises qui ne prennent même plus la peine de sécuriser leurs connexions TLS.

Un autre inconvénient que je n'avais pas pensé au départ: c'est le fonctionnement des mise à jour. Il est complexe en l'état de vérifier que le binaire est toujours le dernier sortie. Il faudrait créer un script plutôt qu'un simple apt-get, se qui est encore un désavantage.

Ce logiciel a du potentiel, mais n'est pas encore utilisable hors test et développement, et encore moins en production comme le sous-entendes l'entreprise qui le gère.


Licence Creative Commons
L'enfer de Caddy, simplement inutilisable. de Clément Cachinho est mis à disposition selon les termes de la licence Creative Commons Attribution - Partage dans les Mêmes Conditions 4.0 International.
Fondé(e) sur une œuvre à https://blog.noknow.ovh/article/L_enfer-de-Caddy_Simplement_inutilisable.html.