cURL ignore les paramètres proxy du système

En utilisant cURL pour vérifier le bon fonctionnement d’une application web exécutée en locale, je prenais systématiquement un retour du serveur proxy demandant une authentification.

Pourtant, sur cette machine fonctionnant sous Ubuntu (16.04), dans /etc/environment était bien configuré le paramètre no_proxy avec sa liste d’exclusions.

 http_proxy="http://proxy.local/"
 https_proxy="https://proxy.local/"
 no_proxy="127.0.0.1, localhost"

cURL outrepasse donc les paramètres renseignés dans ce fichier. Afin de lui indiquer les paramètres à utiliser, il faut créer un fichier .curlrc et y ajouter les paramètres nécessaires.

enguerrand@ubutest01:~$ nano .curlrc

Pour ignorer le proxy sur la boucle locale, il suffit d’ajouter ce paramètre :

noproxy = localhost,127.0.0.1

Il est également possible d’utiliser l’argument –noproxy « * » lors de l’utilisation de cURL pour le bypasser pour cette exécution.

curl --noproxy "*" -0 http://localhost:8080/

J’ai testé (pas longtemps) Nextcloud

NextCloud, c’est le fork d’ownCloud, qui se veut être une plateforme collaborative de stockage et partage de fichiers dans le nuage.

Utilisant au quotidien OneDrive et iCloud, il m’était impossible de ne pas finir par essayer Nextcloud pour avoir un espace de sauvegarde de mes deux autres services mais hébergé par mes soins. Les arguments avancés par Nextcloud sont plutôt flatteurs : c’est un logiciel libre, les données sont auto-hébergées et peuvent être encryptées, les clients sont disponibles pour quasiment tous les OS usuels, que ce soit desktop ou mobile.

Je me documente sur les configurations nécessaires, et monte sur un petit VPS (1 core Xeon et 2 Go de RAM, suffisant pour réaliser des tests) une distribution Ubuntu 18.04 LTS et me lance pour l’installation de Nextcloud. Plutôt bien documentée me dis-je, avant de tomber sur mon premier couac – et il va y en avoir un paquet, sans mauvais jeu de mots – : l’installation par snap ne fonctionne pas et n’opère aucune modification sur mon système, je dois donc installer tous les paquets à la main. Admettons.

J’installe donc Apache, mariaDB et php conformément à ce qui est indiqué. En suivant scrupuleusement la documentation, j’arrive donc avec une base de données qui n’est pas configurée et un Apache incapable d’exécuter le moindre bout de code php (en cause : libapache-mod-php qui visiblement ne fonctionne pas, j’ai dû utiliser php-fcm). Passionnant ; je dois donc me rendre sur divers sites ou faire appel à mes connaissances perdues d’Apache pour réussir à faire fonctionner php. La configuration de mariaDB/MySQL ne pose pas de problèmes, il faut simplement se souvenir de finir le déploiement pour configurer un mot de passe root, puis créer un user lambda sur le SGBD pour lui donner les privilèges sur la future base nextcloud. Après quelques heures de perdues, j’arrive enfin sur la page d’accueil, qui m’indique qu’il me manque encore des modules php. L’installation et la configuration d’Apache prend quelques secondes et je peux ENFIN finir l’installation de Nextcloud, mo gwai !

Je me rends donc dans les menus et tombe sur des avertissements de sécurité et de conformité par rapport à des best practices. Je dois sécuriser un peu mieux mon infrastructure, changer quelques paramètres dans Apache et php pour rendre l’utilisation de l’outil plus fluide. Si les réglages propres à php se font facilement, les changements dans les configurations de Nextcloud sont bien plus anarchiques. Selon la documentation, je devais modifier le fichier de configuration de Nextcloud pour y définir proprement ma racine web, et relancer le script de vérification d’intégrité. Je suis donc toujours la documentation, modifie proprement ma racine web, définit les IP seules autorisées à se connecter, et relance le script de vérification d’intégrité.

Grave erreur. Très grave erreur. Maintenant, je n’ai plus accès du tout à mon Nextcloud. Non pas car mon IP n’est pas reconnue (en fait, le filtrage par IP dans la configuration ne marche pas du tout, peu importe mon IP j’avais accès à la plateforme, excellent) mais j’arrive directement sur l’arborescence des répertoires d’Apache comme si il n’y avait plus d’index.php ; je ne peux même pas fermer ma session. Changement de navigateur, impossible de me connecter : c’est déjà ça, personne à part moi grâce à ma session active ne peut parcourir le contenu des répertoires. Je cherche donc à faire machine arrière et à remettre la valeur par défaut dans le fichier de configuration concernant mon adresse web : impossible d’exécuter le script de vérification d’intégrité car il ne reconnaît pas l’URL d’origine! Du coup, je me retrouve avec un Nextcloud complètement cassé et inutilisable. J’interroge les forums, j’ai l’impression d’être le seul à utiliser Apache et pas nginx. Finalement, il a fallu que j’aille sur la documentation d’une précédente version de Nextcloud pour y trouver la bonne configuration à donner au site virtuel pour que cela fonctionne. Intéressant.

Et, ça fonctionne ! Je n’ai plus d’avertissements de mauvais réglages – enfin presque, car visiblement mon infrastructure n’est toujours pas bien sécurisée malgré le suivi de la documentation et la vérification d’intégrité, les hash ne sont pas identiques entre ce qu’il veut et ce que j’ai. Visiblement je ne suis pas le seul et j’adopte la bonne vieille méthode qui consiste à tout claquer sous le tapis car j’ai autre chose à faire que de tenter de débugger moi-même, j’aimerais pouvoir vraiment me servir de l’outil, et je me suis dit que je regarderais plus tard : je décide donc de shunter le check d’intégrité comme conseillé sur les forums (sic).

Plutôt satisfait d’avoir un peu lutté pour arriver à quelque chose qui fonctionne, je configure donc l’application, y ajoute 2 ou 3 add-ons, configure l’encryption des données et installe le client sur macOS. Je commence donc par uploader environ 5 Go de données… plutôt devrais-je dire 50 Mo de données car je me heurte bien rapidement à un souci de synchronisation : certains fichiers coincent et bloquent complètement le transfert (pas possible de les zapper pour au moins transférer le reste). Certains fichiers font planter la connexion. Rien de particulier dans les logs, seulement que la connexion se ferme et que les fichiers peuvent pas être écrits. Admettons. Je relance Apache, aucun succès, je relance le serveur complet, aucun succès. Je tente de renommer en local (sur mon Mac, s’entend) les fichiers et le répertoire, aucun succès. Je décide donc de tenter de supprimer les fichiers du serveur : impossible. Que ça soit tout le répertoire ou même chaque fichier à la main : impossible, « erreur inconnue ». Je tente donc de passer outre l’interface web et tente de passer par WebDAV. Je prends donc le lien WebDAV disponible sur la page d’accueil : celui-ci ne fonctionne pas. Encore une fois, je dois aller fouiner dans la documentation d’une ancienne version de Nextcloud pour modifier le lien WebDAV afin qu’il fonctionne. J’accède donc à mes répertoires et tente de supprimer ceux qui posent problème. Impossible : verrouillé par HTTP. Intéressant, ça.

Agacé, je décide donc d’envoyer ce serveur à la poubelle, non sans constater par ailleurs que les fichiers que j’avais uploadé et qui devaient être encryptés lors de l’envoi étaient bel et bien lisibles en clair sur le système de fichiers de l’OS. Super.

Me disant que je suis peut-être une quiche et que j’ai été trop vite sur cet outil, que j’ai loupé quelque chose lors de l’installation, je décide de donner une nouvelle chance à ce produit qui semble pourtant être pétri de qualités lorsqu’il fonctionne. Je jette donc mon dévolu chez un prestataire qui propose de l’hébergement Nextcloud, avec une instance déjà installée clef en mains, où il ne reste juste qu’à configurer ses utilisateurs, ses répertoires et add-ons. Je signe donc pour une offre d’un mois, et accède au même portail que celui que je viens de détruire. Je me connecte sans erreur, pas de message par rapport à l’intégrité (j’avoue que l’idée que les tests aient été désactivés m’a bien effleuré l’esprit), je commence à configurer mes clients et repars pour le même upload d’environ 5 Go de documents. Si le transfert s’effectue apparemment proprement, j’ai quand même de belles erreurs dans le client de synchro qui vire au rouge sur des erreurs d’écriture de clés primaires pour un bon paquet de fichiers. Au final, j’ai un message comme quoi la synchronisation est OK. C’est sans doute psychologique, mais quand on me dit que tout s’est bien passé en rouge et pas en vert ou dans une couleur neutre, j’y crois pas trop. Je regarde rapidement, tout à l’air d’y être… le lendemain, une nouvelle synchro se fait suite à modification et il upload (remplace ?) des fichiers auxquels je n’avais pas du tout touché : est-ce des fichiers qu’il avait oublié la veille ou bien a-t-il remplacé ces fichiers ?.. synchronisation qui ne se fait pas sans son lot d’erreurs SQL. Le test de la petite synchronisation ayant à peu près fonctionné (à vrai dire, je n’avais aucune confiance), je cherche à copier un gros répertoire d’environ 300 Go d’images ISO, de sauvegardes en tout genre. Bien évidemment, ça n’a pas loupé, l’application a commencé à envoyer les fichiers avant de lamentablement se noyer dans diverses erreurs de fichiers non accessibles, de serveur ayant rejeté la requête et d’autres joyeusetés SQL.

Je décide alors de jeter complètement l’éponge sur ce produit qui pourtant, a de beaux arguments, semble avoir de belles fonctionnalités et sur le papier, facile à installer et à déployer, mais desservi par une documentation incomplète, des forums où les participants et contributeurs semblent être complètement perdus dès qu’on sort des erreurs de configuration basique d’Apache ou de php ou de firewall, et surtout, un besoin de tout régler au millimètre près pour avoir un fonctionnement « propre ». Dommage, j’ai même pas pu vraiment profiter de Nextcloud.