Si toi aussi t'as la flemme de retrouver comment réussir à envoyer un fichier sur un mutu web que tu connais pas avec des identifiants que tu as oublié, mais que tu veux quand même envoyer un fichier de plus de 2Mo sur le wordpress vite-fait, il y a effectivement quelqu'un qui s'est amusé à coder le plugin qui va bien pour contourner la limitation en coupant le fichier en rondelles et le reconstituant derrière. \o/
Si toi aussi tu galères en cherchant ce plugin-miracles, peut-être que tu seras content de trouver l'info sur un shaarli, malgré les phrases à rallonge de l'auteur…

J'ai voulu tester un hébergement web + PHP + MariaDB rapidement et j'avais vu passer adminer sans vraiment prêter attention. J'ai donc testé… et oui ça juste marche. Un simple fichier PHP et c'est parti on peut a priori faire ce qu'on veut avec ses bases de données (il y a plein de SGBD reconnus) sans se prendre la tête avec les commandes SQL reloues. Ça permet de mettre son nez "graphiquement" et tester toute la chaine, tester des sauvegardes, etc.

En tous cas beaucoup plus simple que phpMyAdmin…

J'ai quelques sites web qui tournent chez moi depuis un moment (2010…), et au fur et à mesure j'ai appris des choses, mis d'autres choses en vrac, changé des configurations, etc.

Je suis en train de migrer une partie de mes services dans des VM sur d'autres machines. C'était donc le moment de revoir de fond en comble mon setup web.

J'ai beaucoup cherché s'il n'y aurait pas moyen de tout mettre dans un système magique qui s'occupe un peu de tout, calcule des infos en plus (graph), permet de filer un coin de web rapidemement à quelqu'un sans se prendre la tête etc. et forcément il y a plein d'outils qui existent et qui prétendent faire le café.

Grosso modo j'ai vu soit des gros trucs pour revendeurs à la cpanel/vesta/ispconfig/… soit des scripts maison mais qui du coup ne fonctionnent que sur par exemple Ubuntu (LEMPer) ou CentOS (VPSSIM). Or toute mon infra est en Debian, et je n'ai pas besoin d'intégration mail/DNS/TLS/… car tout cela est déjà géré par d'autres briques. Sortent un peu du lot, froxlor et tinycp…

J'ai hésité pour froxlor mais beaucoup de doc date de Debian wheezy, il y a tout de même cette notion de revendeur, DNS, mail, … qui ne m'intéresse pas (mais il suffit de ne pas les utiliser, on est d'accord… alors que ça rajoute quand même de la complexité et des risques de failles). Et au final ça ne semblait pas me rajouter beaucoup de facilité. Il aurait aussi fallu gérer les mise à jour et mises à niveau (comme pour tout outil quoi).

Tinycp avait l'air vraiment sympa mais actuellement les dev sont en train de se demander comment ils vont fournir leur bidule et dans tous les cas le code n'est pas libre. Donc compliqué dans le temps si on a pas envie de se prendre le chou et pas propre éthiquement.

J'ai donc perdu beaucoup de temps pour au final écrire le script qui fait juste ce que je veux et voilà. J'espère que je ne suis pas passé à côté de certaines notions élémentaires que les panel sus-cités ont déjà pris dans la tronche et corrigé : le web c'est compliqué et pas vraiment passionnant.

La commande "pv" a pas mal d'options. Pour avoir rapidement une idée du nombre de requêtes sur une page web qui se fait par exemple DDoS, on peut construire quelque chose comme :
tailf /var/www/<site>/access.log | grep lapage | pv -l -i 10 -r > /dev/null
On aura le nombre de ligne par seconde, sur les 10 dernières secondes.

Les userdir apache, vieux comme le monde. Mais je ne connaissais pas la variante "hors home" où en fait on peut choisir n'importe quel dossier racine dans lequel seront, par dossier, les données de chaque utilisateur. Ça me semble pas mal pour éviter de devoir ajuster les permissions x de tout le home par exemple.
Je ne savais pas non plus qu'on pouvait activer/désactiver des utilisateurs, ou rediriger vers des URLs externes.

Je viens de faire une installation d'etherpad-lite sur une Debian Jessie, au final c'est assez rapide de nos jours, parce que même si avant il fallait compiler nodejs et qu'on le lit de partout encore, apparemment il suffit de fait un lien node ⇒ nodejs et ça fonctionne ! Et npm a été rapide ce coup-ci…
Le tuto ci-lié a aussi une petite variante, c'est de faire un utilisateur système et de poser les fichiers dans /var/www je me dis que c'est peut-être légèrement plus propre que dans le home au final…

Je suis pas très "appli web" en général, mais pour essayer de faire se parler les gens dans une équipe, il faut bien avouer que IRC c'est pas spécialement pratique pour un usage non-intensif (sans rester connecté tout le temps, sans lire forcément tout, en laissant tomber quand y'a beaucoup de log, …). Donc pour de petites équipes de non-geek c'est pas pratique : j'ai essayé au labo où je suis et boarf à part 2 personnes ça a pas vraiment marché.

Je suis tombé sur cette appli web par hasard en regardant cette liste : https://github.com/Kickball/awesome-selfhosted

Alors OK c'est en node (mais c'est dispo dans les paquets), OK il faut une base (mais du mongo c'est moins relou, et c'est aussi dans les paquets), il n'empêche qu'il y a le support LDAP (qui juste marche (sauf si on a pas d'adresses mails enregistrée pour tout le monde mais bon…), voir https://github.com/sdelements/lets-chat-ldap) et que globalement ça fonctionne bien, y compris quand on joue à faire tomber le serveur.

On a donc des salons de discussion, avec historique + recherche même lorsqu'on n'est pas connecté, on peut y insérer des images (pratique si y'a un problème sur un microscope par exemples, mettre une capture d'écran), les comptes sont unifiés (LDAP), auto-hébergé en interne… et juste ça. Ce n'est pas une usine comme mattermost ou rocket.chat et l'interface est claire et "moderne".
On va voir si ça prend chez les utilisateurs…

Un afficheur web d'images en tuiles pour panorama ou toute image très grande, qui prendrait trop de temps à télécharger entièrement pour afficher normalement.
Celui-là est plutôt bien fichu, avec assez d'options (minimap par exemple) et simple à mettre en place (exemple : https://openseadragon.github.io/docs/).
Il y a une liste de générateurs de tuiles compatibles, j'ai testé un script shell basé sur convert d'imagemagick (https://github.com/VoidVolker/MagickSlicer), ça juste marche bien et c'est tout simple à utiliser.
J'en ai profité pour mettre en lignes quelques-uns des panorama que j'avais en stock (http://jonathan.michalon.eu/pano).

Tiens, ça y est, Mozilla et Debian s'entendent enfin sur les histoires de licence pour avoir le droit d'utiliser "Firefox" ? :)
Tant mieux, pas la peine de faire des exceptions de partout. Après ça a pas l'air non plus si simple et clair, avec des avis divergents (comme toujours)…

… et c'est packagé dans Debian. :)
Si on peut éviter de s'embêter avec un awstats pour par exemple voir la BP ou les hits qui finissent 404, c'est pas si mal.
En ce qui me concerne, je dois choisir "NCSA Combined Log Format".

Problème avec des certifs x509 sur des ESXi pas mis à jour, une histoire de param DH trop faibles. C'est bien de check. C'est bien d'avertir. C'est pas forcément idiot de faire peur. C'est con d'empêcher de contourner (oui les gens le font sans réfléchir du coup mais il faut aussi pouvoir faire ce qu'on veut à un moment). Et quand t'es en interne, que t'as besoin d'administrer ça vite-fait et que l'alternative c'est le client lourd fenêtre-only, bah c'est moins pire.
Donc sous Firefox, ça se désactive (complètement du coup…) dans about:config, sous chromium via un param de ligne de commande.

Ci-lié un post où j'explique comment j'ai mis en place des certificats Let's Encrypt sur mon serveur.

En passant j'ajouterai que dans le cas d'un site mod_proxy d'apache, on peut sortir le dossier de vérification du proxy comme cela :
ProxyPass /.well-known/acme-challenge/ !

Occupation d'une soirée, d'une partie de matinée et d'une après-midi : passer de Drupal7 à Pelican. C'est fait. Ouf.

Petit outil livré avec apache pour benchmark un serveur web, avec stats assez lisibles à la fin.

Perso je l'ai attaqué comme ça (pour avoir une page avec accès BDD) :
ab -k -c 100 -n 1000 https://strasweb.fr/actualite/

Et puis à la fin pour nettoyer un peu les kilomètres de log, à coup de 1000 requêtes ça va vite :
sed -i -E '/(ApacheBench|server-status)/d' /var/log/apache2/access.log
EDIT: /!\ attention cela change le fichier (numéro d'inode en tous cas) et après apache a plus l'air de loguer… il faut le relancer a priori…

Les expressions (if etc.) dans apache 2.4 ont changé (depuis 2.3.xx apparemment). Voici la nouvelle doc :)

Setup de php-fpm avec apache 2.4 : faisable mais pas immédiat.

En fait selon les sources on n'a pas les mêmes infos, en particulier concernant le lien entre apache et fpm : socket unix ou TCP ?
Ici (http://www.vincentliefooghe.net/content/configuration-apache-24-php-fpm) on lit que les socket unix sont pas dispo, dans la doc shaarliée que si. D'autres (https://bz.apache.org/bugzilla/show_bug.cgi?id=54101 en bas) disent qu'il faut donner le chemin du document_root à chaque vhost (donc chiant).
Au final en compilant avec encore une autre source (http://z-issue.com/wp/apache-2-4-the-event-mpm-php-via-mod_proxy_fcgi-and-php-fpm-with-vhosts/) on obtient quelque chose de satisfaisant :

• on utilise bien le socket unix (apparemment dispo depuis 2.4.9, on a 2.4.10 dans Debian Jessie), probablement moins d'overhead pour du local.
• on a bien une config globale, en ne donnant pas le chemin de la racine de chaque vhost mais le nom du pool fpm (c'est quoi l'embrouille ?!)

La seule chose à faire donc, à part activer les modules apache, serait de créer une fichier /etc/apache2/conf-available/php5-fpm.conf en mettant :
<FilesMatch ".php$">
SetHandler "proxy:unix:///var/run/php5-fpm.sock|fcgi://www/"
</FilesMatch>

<Proxy fcgi://www/>
</Proxy>
et de l'activer : a2enconf php5-fpm
Ici, "www" est le nom du pool fpm, défini par défaut à l'installation du paquet.

En tous cas chez moi ça marche comme ça, avec le MPM event.

Apache 2.4 est supposé permettre d'utiliser le MPM event en prod' car stable. Ici une explication de ce que ce MPM a de mieux que worker.
En gros il y a un thread spécial qui réagit aux événements sur les socket en attente (connexions en mode keepalive etc. avec epoll ou kqueue), au lieu de laisser ça à chaque thread. Les thread ayant effectué les traitements sont donc libres de travailler à autre chose pendant les temps morts.
A priori ça se remarque avec un apache2ctl status, même avec des sessions en keepalive on ne voit plus de thread marqué 'K' : c'est le thread dédié qui attend, les autres sont dispos.

Dans NGINX, les blocs "location" c'est un peu compliqué… pour savoir dans quel ordre est pris quoi, il faut s'accrocher un peu.

"To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used."

Ce que je traduis par « le plus grand match sans regex (prefix location) est retenu puis on cherche dans les regex, on prend la première ; si pas de regex on prend le bloc retenu avant ».
J'ai pas tout essayé mais ça semble coïncider avec la réalité :P

En passant à nginx, ne pas oublier de réincorporer les blocages par htaccess à la config… ici un exemple pour dokuwiki.
Pour galette j'ai mis ça :
location ~ /(data|config|lib)/ {
deny all;
}

Exemple de base d'utilisation de marqueurs avec OpenLayers et OSM. Je pensais que c'était plus compliqué, ça juste marche en fait. Penser à copier la lib en local pour les bonnes pratiques (ne pas dépendre du serveur et ne pas le charger pour rien).