Voir les infos déjà données sur la page:
La procédure suivie est celle sui a été décrite ici, afin de pouvoir héberger éventuellement plusieurs instances de Wordpress:
https://www.digitalocean.com/community/tutorials/how-to-configure-single-and-multiple-wordpress-site-settings-with-nginx
Il y a trois fichiers qui peuvent être utilisés par l'ensemble des sites Wordpress qui seront installés:
/etc/nginx/global/common.conf /etc/nginx/global/multisite.conf /etc/nginx/global/wordpress.conf
Le fichier qui correspond au sites est:
/etc/nginx/sites-available/labx_blog
Pour qu'il soit pris en compte il y a un lien symbolique dans /etc/nginx/sites-enabled/ qui est automatiquement lu au redémarrage de nginx.
Voir s'il est possible de factoriser avec les fichiers de conf du dokuwiki.
La méthode qui a été suivie a le mérite de bien marcher.
Par contre il ne faut pas oublier que la conf multisite correspond au cas où les mêmes fichiers .php peuent être utilisés par plusieurs instances wordpress:
http://codex.wordpress.org/Create_A_Network
Il y a d'autres méthodes recommandées pour l'installation de Wordpress.
http://wiki.nginx.org/WordPress
Elle a pas l'air bien folichonne, tout est dans le même fichier. Elle déconseille le copier coller brutal d'un blog... ça donne mauvaise concience.
http://codex.wordpress.org/Nginx
Elle a l'air mieux que l'actuelle. Il semble que la liste de fichier proposés permette de factoriser certains fichiers avec ceux de dokuwiki
⇒ Il serait peut être bon de remplacer la conf actuelle avec celle-ci donnée par Wordpress en espérant qu'elle marche.
Détaillée ailleurs:
Le plugin wordpress pour le LDAP est appelé au lancement de la page. Etant donné qu'il n'y a pas de LDAP, ça plante!
C'est ce qu'il reste à faire, tant que le plugin vers le LDAP est actif il n'est pas possible de voir la page, sauf depuis lme serveur lui même, pour une raison bizarre
# nc vm_labx 80
renvoie le code html.
Remarque: déjà vu la tête des caractères dans le html renvoyé il semblerait que l'encodage utilisé pour l'export de la base de données n'était pas forcément le bon.
Si les versions n'avaient pas été les bonnes, ça aurait été un bon prétexte pour réinstaller. Mais ce sont les versions à jour.
cat wp-content/plugins/simple-ldap-login/Simple-LDAP-Login-Admin.php => Dans le html on distingue un "Version 1.4"
cat readme.html => la version 4.1 qui est l'actuelle.
Il va donc falloir désactiver le plugin en gardant les fichiers installés. La bonne nouvelle est qu'il ne sera pas nécessaire de rechercher à la main les photos et le thème.
L'aide du site de Wordpress n'est que très relative:
Le Codex explique que l'installation se fait grâce à l'interface web de Wordpress:
https://wordpress.org/plugins/simple-ldap-login/installation/
Il y a une option “LDAP Exclusive mode” qui a due être cochée vu que l'on ne peut visiblement plus y accéder que par le LDAP.
De la même manière sur la page traitant des plugins, il faut forcément se connecter à la page de gestion de plugins si l'on veut l'activer/désactiver, même manuellement. Super.
http://codex.wordpress.org/Managing_Plugins#Manual_Plugin_Installation http://codex.wordpress.org/Managing_Plugins#Uninstalling_Plugins
En cherchant (“deactivate wordpress plugin file”) dans quel fichier se trouve la conf pour les plugins, apparait une page de 2012:
http://www.wpbeginner.com/plugins/how-to-deactivate-all-plugins-when-not-able-to-access-wp-admin/
⇒ La liste des plugins actifs se trouve en fait dans la base de données!!!
mysql> show columns from wp-options; mysql> select option_name from wp_options; //là on voit un paquet d'options relatives au LDAP. mysql> select option_value from wp_options where option_name='active_plugins'; +------------------------------------------------------------------------------------------------------------------+ | option_value | +------------------------------------------------------------------------------------------------------------------+ | a:2:{i:0;s:43:"http-authentication/http-authentication.php";i:1;s:39:"simple-ldap-login/Simple-LDAP-Login.php";} | +------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)
C'est là où la page donnait simplement l'info pour tout désactiver en mettant 'a:0:{}'. Il va falloir (lire la doc) y aller au pif.
mysql> UPDATE wp_options SET option_value='a:1:{i:0;s:43:"http-authentication/http-authentication.php";}' WHERE option_name='active_plugins';
En esperant que 'a' c'est le nombre de plugins.
mysql> select user_login from wp_users;
Maintenant que le Wordpress est accessible, il apparait clairement que le copier/coller de la conf nginx était un geste malheureux, les URLs se réécrivent n'importe comment.
=> renvoie vers une url invalide...