Afin d'améliorer les performances et limiter la consommation mémoire, on va passer une configuration apache + mod_php en nginx + php-fpm.
Ceci va se faire en plusieurs étapes, qui peuvent être mises en place progressivement :
Dans la série sur ISIM6, j'avance sur la mise en place via un processus de migration en 2 étapes (sur une machine différente).
La migration elle-même s'est correctement passée, et je voulais passer le dernier Fix Pack ISIM, histoire d'avoir la dernière version.
Autant dire que ça ne s'est pas passé tout seul. Mais au final ça fonctionne, après quelques réglages. Le fait que l'on lance les FixPack en mode silencieux / scriptés nécessite également des adaptations.
Les problèmes rencontrés sont de plusieurs types :
J'ai récemment eu besoin d'archiver des sites initialement créés avec les CMS Drupal et Wordpress, de clients HebInWeb ayant arrêté leur activité (et donc également leur site).
Le nom de domaine n'a pas été renouvelé, et a été détruit.
Plutôt que de supprimer complètement les sites, j'ai décidé de les archiver, mais en utilisant un site 100% statique en html/css/js, plutôt que de rester sur les CMS initiaux.
Ceci a plusieurs avantages à mes yeux :
Depuis la version 7.33, Drupal embarque dans le "core" un mode de debug pour le thème.
On peut voir dans le fichier CHANGELOG.txt
Comme le dit Wikipedia, chroot (change root) est une commande des systèmes d'exploitation UNIX permettant de changer le répertoire racine d'un processus de la machine hôte. Ceci est un bon moyen de cloisonner les utilisateurs sur une machine, en les isolant, sans leur permettre d'avoir accès à toute l'arborescence. C'est généralement ce qui est utilisé, par exemple, sur les hébergements mutualisés pour les accès ftp.
Un exemple sans le chroot. L'utilisateur a accès à toute l'arborescence, depuis / :
J'utise sur mes serveurs une combinaison nginx + PHP5-FPM (avec le drivers php5-mysql) + MariaDB, et j'ai remarqué dans mes logs des messages d'erreurs :
Il est parfois intéressant de pouvoir se créer un compte avec les droits "Administrateur" sur un CMS Drupal ou Wordpress.
Par exemple si on récupère en infogérance un site internet développé par un client, qui n'a pas forcément envie de vous communiquer ses identifiants.
Si on a accès au serveur (ce qui est le cas quand on l'exploite), ceci est facilement faisable via quelques lignes de code.
OpenIDM, la solution de gestion des identités de Forgerock, va bientôt sortir en version 3.1, avec un grand changement par rapport aux versions précédentes : une interface d'administration / configuration.
Jusqu'ici, la configuration se faisait uniquement via des fichiers Json, ce qui avait l'avantage de pouvoir être facilement versionné, mais plaçait le produit loin de ses compétiteurs quant à l'aspect "interface d'admin".
Dorénavant, il est possible d'avoir une visu des ressources, en se connectant à http://localhost:8080/admin
La mise en place de SSL pour OpenLDAP permet de sécuriser les échanges, que ce soit en utilisant LDAPS ou START/TLS (dans ce dernier cas, la connexion démarre sur le port LDAP et passe ensuite en mode sécurisé).
En préalable, on aura généré une clé privée, récupéré un certificat, ainsi que celui de l'autorité de certification. (voir un article précédent sur le mémento OpenSSL ).
Les étapes pour la sécurisation sont :
J'ai récemment installé un serveur de développement / intégration sur une machine dédiée SP 128 OVH assez "costaud" :
La machine est installée avec une distribution linux Ubuntu 14.04 LTS.