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.
Après avoir pas mal "joué" avec les certificats SSL ces derniers temps, pour des besoins de sécurisation d'accès à un annuaire LDAP entre autre, je me fais un petit mémo des commandes les plus utilisées.
OpenSSL permet de gérer les certificats utilisés dans les connexions SSL (https, ldaps, etc.). Sur les O.S. de type Unix/Linux, il est généralement présent dans les dépôts et s'installe facilement :
yum install openssl
ou encore
Par défaut, Drupal permet de "bannir" des adresses IP manuellement, via la console d'administration.
Ceci est une première étape, mais peut vite devenir ingérable sur un site fréquenté. De plus, les requêtes http vont quand même arriver jusqu'au CMS, puisque c'est lui qui gère ces exclusions.