Gérer un SPIP mutualisé avec SSH et SVN

dimanche 5 décembre 2010, par Maïeul

| 15

Pourquoi installer trois fois SPIP lorsqu’on a trois sites chez le même hébergeur ? Pourquoi ne pas garder un seul noyau qui servirait aux trois sites ? Voici un petit tutorial sur :

utiliser ssh et svn chez un hébergeur
mutualiser un site SPIP.

Ce tutoriel explique comment j’ai pratiqué chez l’Autre.net pour avoir un site mutualisé.

Définition

SSH est un protocole qui permet d’exécuter des lignes de commandes sur un ordinateur distant, via internet, et ce de manière sécurisé.

SVN est un système de gestion de versions de code sources. C’est celui utilisé par SPIP.

Un SPIP mutualisé, c’est la possibilité d’avoir une seul fois le code de SPIP pour plusieurs sites chez le même hébergeur.

Ce qu’on cherche à faire

Avoir un SPIP mutualisé.
Pouvoir facilement le mettre à jour.

Interêt

La mutualisation permet un gain de place et de temps lors des mises à jour de SPIP : un seul SPIP à mettre à jour.

L’accès SSH évite d’avoir à passer par FTP depuis votre ordinateur, et donc de subir la lenteur des connexions sortantes proposés en ADSL.

Préalable

Il est nécéssaire de pouvoir faire du SSH. Sur mac / linux, il faut utiliser le terminal ou l’invite de commande. Sous Windows il faut un logiciel spécifique. Voir le tutoriel de l’Autre.net.

Tout les hébergeurs ne proposent pas d’accès SSH, car cela pose des problèmes en termes de sécurité. L’Autre.net en plus d’être un Alter-Hébergeur le permet. Tant mieux ! [1]

Tout les hébergeurs proposant SSH ne proposent pas forcément SVN. Si c’est le cas du votre, négociez avec lui. Et si vous échouez, ce tutoriel vous sera inutile.

J’ai trois site :

bidule.tld
truc.tld
machin.tld

Il est nécessaire de régler les DNS pour qu’ils pointent sur le même hébergeur, puis chez l’hébergeur, il faut que chaque domaine pointent vers le même répertoire.

Voir avec l’hébergeur pour cela.

J’imagine ici que mes trois domaines sont réglés pour accéder au répertoire spip_mutu.

Se connecter via SSH

Dans le terminal [2], taper [3] :

% ssh login@adresse

Le login et l’adresse ssh sont fournis par l’hébergeur.

A l’invitation, taper votre mot de pass SSH.

Désormais, tout ce que vous frapperez sera exécuté sur le serveur de votre hébergeur. Donc attention !

Récuperer le code de SPIP

Tout d’abord, se déplacer dans le dossier spip_mutu :

% cd spip_mutu

Il existe sur le serveur SVN de SPIP un dossier tags qui contient des « instanés » des version de SPIP. En gros, il contient les versions distribuées sur SPIP.net.

Récuperons cela par SVN. Ici la version 2.1.2

% svn co svn://trac.rezo.net/spip/tags/spip-2.1.2 .

! Attention, ne pas oublier le point final. Il permet que le contenu du dossier spip-2.1.2 soit mis directement dans le dossier courant.

Le jour où SPIP passera en 2.1.3, il suffira de faire

% svn switch svn://trac.rezo.net/spip/tags/spip-2.1.3

qui basculera seulement les fichiers modifiés entre la 2.1.2 et la 2.1.3

Récuperer le gestionaire de mutualisation

Il existe un pseudo-plugin SPIP qui permet de gérer un SPIP mutualisé. Récuperons le

% svn co svn://zone.spip.org/spip-zone/_plugins_/mutualisation

Il faut ensuite créer un dossier sites, dans lequel chaque site aura un dossier spécifique. Pour cela :

% mkdir sites

Installer les plugins

La plupart des plugins SPIP sont dévellopés sur la SPIP-Zone, en SVN. Trouvez ici la liste : http://zone.spip.org/trac/spip-zone/browser/_plugins_/, et les squelettes sont par là http://zone.spip.org/trac/spip-zone/browser/_squelettes_

Créons notre dossier plugins, puis allons y.

% mkdir plugins
% cd plugins

Maintenant récuperons les plugins qui nous intéresse

% svn co svn://zone.spip.org/spip-zone/_plugins_/dossierduplugin

ou dossierduplugin est à remplacer à chaque fois par le dossier du plugin qui nous intéresse.

Lorsqu’on voudra mettre à jour un plugin, on fera

%svn up dossierduplugin

Configurer la mutalisation

Tout d’abord retournons à la racine de notre site

% cd ..

Puis copions le fichier mes_options.php.txt dans le dossier config de SPIP, en le renommant.

% cp mutualisation/mes_options.php.txt config/mes_options.php

éditons avec pico le fichier copié

% pico config/mes_options.php

Voici le fichier tel que livré aujourd’hui :

<?php

	if (!defined("_ECRIRE_INC_VERSION")) return;
	require _DIR_RACINE.'mutualisation/mutualiser.php';

	/* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */ 
	$www = array();
	
	$site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
	if ($site != $_SERVER['HTTP_HOST'] AND !in_array($site, $www)) {
		include_spip('inc/headers');
		redirige_par_entete('http://'.$site.'/');
	}

	define ('_INSTALL_SERVER_DB', 'mysql'); 
	define ('_INSTALL_HOST_DB', 'localhost'); 
	define ('_INSTALL_USER_DB', 'loginsql');  
	define ('_INSTALL_PASS_DB', '123456HDJ'); 
	define ('_INSTALL_NAME_DB', 'mu_'.prefixe_mutualisation($site));
	
	/* mettre en commentaire la ligne suivante si vous utilisez l'option table_prefixe plus bas dans la config */ 
	define ('_INSTALL_TABLE_PREFIX', 'spip');

	/* 
	 * Si le nom du serveur est different du nom dns, 
	 * ca peut parfois poser probleme
	 * il faut alors le definir ici
	 */
	# define ('_INSTALL_HOST_DB_LOCALNAME', 'nom_serveur');
	
	/* 
	 * Si le serveur n'est pas mysql, il faut le preciser obligatoirement.
	 * # define ('_INSTALL_SERVER_DB', 'pg'); // mysql|pg|sqlite2|sqlite3
	 * 
	 * /!\ En PG, il est conseille d'utiliser la creation d'utilisateur SQL
	 */
	
	/*
	 * Creer automatiquement les users SQL (pg|mysql)
	 * 
	 * Cela permet 
	 * - d'avoir un utilisateur root possedant les droits 
	 * de creation de bases (cet utilisateur possedant obligatoirement 
	 * une base a son nom en PG - PG ne se connecte pas sans donner un nom de bdd)
	 * - de creer des utilisateurs sql automatiquement 
	 * ne possedant que les droits d'administation 
	 * de leur base de donnee qui sera creee
	 * 
	 * Il faut remplacer alors 
	 * _INSTALL_(USER|PASS)_DB par _INSTALL_(USER|PASS)_DB_ROOT
	 * 
	 * et ajouter dans demarrer_site l'option
	 * 'creer_user_base' => true
	 */ 
	# define ('_INSTALL_USER_DB_ROOT', 'mon_root');
	# define ('_INSTALL_PASS_DB_ROOT', '********');
 
	/*
	 * Creer les bases de donnees via un ping sur une URL (methode AlternC)
	 *
	 * Il suffit de renseigner l'option url_creer_base, en lui passant les bons parametres :
	 * 'url_creer_base' => 'https://bureau.tld/admin/sql_doadd.php?username=USER&password=PASS&dbn='.prefixe_mutualisation($site)
	 */
	 
	 
	/*
	 * Transformer sur les pages publiques les url des images
	 * /sites/mon_site/IMG/* -> /IMG/*
	 * /sites/mon_site/local/* -> /local/*
	 * 
	 * - Necessite le mod_rewrite (reecriture d'url) d'apache
	 * - Ne fonctionne qu'avec des mutualisations de nom de domaine 
	 * ('http_host' : http://mon_site_mutu.tld)
	 * (donc pas avec une mutualisation de repertoire - http://site/mon_spip_mutu/)
	 * 
	 * et ajouter dans demarrer_site l'option
	 * 'url_img_courtes' => true
	 * 
	 * Il est possible de regenerer les fichiers .htaccess 
	 * crees automatiquement dans /IMG et /local
	 * grace a ?var_mode=creer_htaccess_img
	 * 
	 */
	
	/*
	 * Inscrire ici le nom du site d'administration du tableau de bord
	 * de la mutualisation (ou plusieurs, separes par des virgules)
	 * (dans cet exemple, 'scriibe.net' est le top level domain, TLD)
	 * pour autoriser tous les sites, ne pas definir la constante ;
	 * Si le site maitre n'est pas dans sites/ mais a la racine, mettre ''
	 * et ajouter 'mutualisation' dans $dossier_squelettes
	 */
	define ('_SITES_ADMIN_MUTUALISATION', 'scriibe.net');

	
	demarrer_site($site,
		array(
			'creer_site' => true,        // Creer ou non le site s'il n'existe pas (defaut: false) 
			'creer_base' => true,        // Creer ou non la base de donnee si elle n'existe pas (false) 
			'creer_user_base' => false,  // Creer ou non un utilisateur pour la nouvelle base de donnee (false)
			'mail' => '',                // Adresse mail pour recevoir un mail lors d'une creation de site mutualise ('') 
			'code' => 'ecureuil',        // Code d'activation ('ecureuil') 
			'table_prefix' => false,     // Definir automatiquement le prefixe de table (false) ... mettre true si tous les sites dans la meme base 
			'cookie_prefix' => true,     // Definir automatiquement le prefixe de cookie (false)
			'repertoire' => 'sites',     // Nom du repertoire contenant les sites mutualises ('sites')
			'url_img_courtes' => true,   // Utiliser la redirection des URL d'images courtes dans la partie publique (false)
										 // /!\ il faut qu'apache ait le droit d'ecrire dans les dossiers IMG/ et local/ a la racine du site !
										 // C'est la que la mutualisation va ecrire les regles de redirection automatiques pour les images de chaque site
			# 'utiliser_panel' => false, // Utiliser une table externe pour recuperer des identifiants ... (code, user, pass) permettant a un utilisateur d'installer le site (false) 
			# 'annonce' => '<p>Un service propos&eacute; par <a href="http://www.spip.net/">la communaut&eacute; SPIP</a></p>', // Texte a afficher en bas du formulaire d'activation de la mutualisation
			'url_creer_base' => ''       // Creer la base de donnees via une URL (methode AlternC)
		)
	);

	/*
	 * Notes concernant SQLite
	 * 
	 * 1) creer_base = false
	 * 	Avec SQLite, il est inutile de mettre creer_base a true.
	 * 	Si creer_base est true, une base sera cree (par l'outil de mutualisation)
	 * 	dans le repertoire defini par la constante _DIR_DB.
	 * 
	 * 	Si cette constante n'est pas renseignee, elle vaudra
	 * 	_DIR_ETC/bases/ soit : config/bases/, ce qui ne correspond pas
	 * 	a l'emplacement du futur site : sites/X/config/bases.
	 * 
	 * 	En laissant l'option a false, SPIP creera la base de donnee
	 * 	au moment de l'installation (exec=install) et a ce moment
	 * 	la, _DIR_ETC vaudra 'sites/X/config' donc la base sera stockee
	 * 	ou il faut si _DIR_DB n'est pas defini.
	 * 
	 * 2) creer_user_base = false
	 * 	SQLite ne gerant pas de droits d'utilisateurs,
	 * 	(les droits sont ceux du fichier .sqlite)
	 * 	mettre true provoquera des erreurs (je suppose)
	 *  
	 * 3) constantes a definir :
	 *  define ('_INSTALL_SERVER_DB', 'sqlite3'); //  sqlite2 ou sqlite3
	 *  define ('_INSTALL_NAME_DB', 'mu_'.prefixe_mutualisation($site));
	 * 
	 * 	les constantes _INSTALL_(HOST|PASS|USER)_DB sont inutiles.
	 */
	
	/*
	 * Notes concernant MySQL
	 * 
	 * - Pour la creation d'utilisateurs MYSQL
	 * (creer_base+creer_user_base)
	 * il est possible de definir les droits de ces utilisateurs avec la constante 
	 * _PRIVILEGES_MYSQL_USER_BASE (ici avec les valeurs utilisees par defaut) :
	 * 
	 *  define('_PRIVILEGES_MYSQL_USER_BASE','Alter, Select, Insert, Update, Delete, Create, Drop');
	 *
	 */
?>

par mesure de sécurité, on veut qu’à chaque nouveau site les logins/mdp mysql soient demandés. On veut également que le webmestre crée à la main le dossier du site (voir plus bas).

Donc il faut supprimer les lignes suivantes :

define ('_INSTALL_SERVER_DB', 'mysql'); 
	define ('_INSTALL_HOST_DB', 'localhost'); 
	define ('_INSTALL_USER_DB', 'loginsql');  
	define ('_INSTALL_PASS_DB', '123456HDJ'); 
	define ('_INSTALL_NAME_DB', 'mu_'.prefixe_mutualisation($site));

et également remplacer les lignes suivantes

			'creer_site' => true,        // Creer ou non le site s'il n'existe pas (defaut: false) 
			'creer_base' => true,        // Creer ou non la base de donnee si elle n'existe pas (false)

par

			'creer_site' => false,        // Creer ou non le site s'il n'existe pas (defaut: false) 
			'creer_base' => false,        // Creer ou non la base de donnee si elle n'existe pas (false)

Et puis remplacer « ecureuil » par un autre mot de passe.

Créer les dossier des sites

Chaque site aura un dossier à lui dans le dossier sites. Ce dossier sera l’url du site, sans le http://www. Comme nous voulons les créez nous même, et non pas confier la tâche à SPIP, il faut faire cela, dans notre cas :

% mkdir sites/bidule.tld
% mkdir sites/truc.tld
% mkdir sites/machin.tld

Chacun de ces sous dossiers contiendra les dossiers tmp IMG, local,config spécifique au site.

Renommer le fichier .htacesss

Pour utiliser la réécriture d’URL et les URLs propres de SPIP, il faut faire :

% mv htaccesss.txt .htaccess

afin de renommer le fichier htaccess.tex en fichier .htaccess.

! Attention : la réécriture d’url via .htaccess ne fonction que sur les serveurs Apache. C’est pourquoi, si vous n’êtes pas sous Apache, dans le fichier mes_options.php cités plus haut, changer la ligne suivante

'url_img_courtes'=>true,

par

'url_img_courtes'=>false,

Se déconnecter du SSH

Ca y est, tout les fichiers sont biens en place chez l’hébergeur. Pour quitter l’accés SSH :

% logout

Configurer chaque site

Il suffit désormais de vous rendre sur http://machin.tld pour configurer le site machin.tld, comme vous le feriez à l’install de n’importe quel site SPIP. Il faudra simplement donner le mot de passe que vous avez réglé dans le fichier mes_options.php

Vos commentaires

# Le 16 décembre 2010 à 17:56, par Loiseau2nuit En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

Hello Maieul,

Tu me coupes l’herbe sous le pied là, j’avais prévu de l’écrire sur contrib cet article là :-D

2 choses en revanche :

Le jour où SPIP passera en 2.1.3, il suffira de faire
% svn switch svn://trac.rezo.net/spip/tags/spip-2.1.3

Négatif ! Un svn up suffit (enfin chez moi, ca a suffit). c’est pas une montée de version majeure. Ca, ca sera nécessaire le jour où on changera de branches, et on en est pas encore là :-)

Sinon, un script qui automatise ton process SSH est dispo sur la zone : http://zone.spip.org/trac/spip-zone/browser/_outils_/svn_install_spip2_0.sh

A adapter légèrement pour les dernières versions et pour le noms de certains plugins, renommés entre temps ;)
# Le 16 décembre 2010 à 18:17, par Maïeul En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

Cool pour le script :)

En revanche, pour la commande de svn, pas d’accord. Tout dépend de savoir si au départ tu a récupéré dans branches ou dans tags.

Si tu récupère dans branche, effectivement un up fonctionne. En revanche si tu a récupéré dans tags il faut changer de répertoire, ce qui passe par un switch.
# Le 16 décembre 2010 à 18:27, par Loiseau2nuit En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

OK donc finalement, récupérer dans branche évite pas mal de problème alors :-D
# Le 16 décembre 2010 à 18:33, par Maïeul En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

ou peut en causer si les dev de SPIP postent des instabilités dans branche (ce qui est pas toujour le cas). Dans tags tu est sûr d’avoir la même version que celle distribuée sur le site officielle.

Dans branche, pour peu que tu sois pas juste après la sortie de la version lorsque tu fait ton co, tu peu être dans la loose (c’était ce qui m’est arrivé une fois, et du coup ma BDD local avait pas la même structure que la BDD distante)
# Le 17 décembre 2010 à 11:03, par Loiseau2nuit En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

Ben en fait ce qui m’intéresse c’est justement une version évolutive donc si via un tag je chope une version figée, le côté « evolutif » perd d’un coup toute sa saveur en fait.

(bon, pour un comm de test, ca devrait aller là je pense :P )
# Le 17 décembre 2010 à 11:05, par Maïeul En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

oui, ca le fait.

mais moi j’ia envie d’avoir du stable en ligne :)
# Le 5 janvier 2011 à 07:39, par Beaul40 En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

Hello

Je tente de suivre le tutot mais si je fait :
% svn switch ...

Il me sort une erreur no such job

Oublirais je un morceau de code ?
# Le 5 janvier 2011 à 08:55, par Maïeul En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

Comme j’ai précisé, il ne faut pas mettre le %. C’est l’invite de commande (le message qui apparaît sur ton terminal avant que tu tape ton code.

Et le svn switch c’est une étape pour la mise à jour. La 1^er chose à faire c’est un co.
# Le 5 janvier 2011 à 09:28, par Beaul40 En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

Bonjour Maïeul

Si je retire le % il me sort aussi une erreur mais cette fois ci de commande invalide. Je fais un switch car mes site sont déjà monter et que je veux les mettre a jours plus vite et plus facilement.
# Le 5 janvier 2011 à 09:30, par Maïeul En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

et mais si tu fais pas d’abord une install par co ca peut pas marcher.
# Le 2 février 2011 à 20:56, par ppds En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

Il s’avère quand suivant le tuto, je rencontre les mêmes erreurs que certains :

- cas de commande invalide

du au fait qu’il vous faut installer svn par ssh , voici donc la commande a faire avant d’aborder la suite ==> récupérer le code de SPIP

- apt-get install subversion libapache2-svn python2.5 libsqlite3-0 php5-sqlite python-svn python-subversion python-pysqlite1.1 python-genshi subversion-tools
# Le 10 août 2012 à 12:19, par Loiseau2nuit En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

HAN !!!!!!!!!!!!!!!!!
J’ai eu *très* mal au ... l’espace d’un moment en voyant la tête de ton nouveau thème, j’ai cru que t’étais passé chez « ceux d’en face » ^^
# Le 10 août 2012 à 12:23, par Maïeul En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

non, j’ai simplement adapté le thème, parceque j’en trouvais pas d’aussi leger sous ZPIP. Et puis j’ai profité pour mettre de la polyhierachie.
# Le 10 août 2012 à 12:26, par Maïeul En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

crois moi, je teste WP pour un autre site et j’ai pas envie de migrer ailleurs.
# Le 20 janvier 2015 à 16:04, par momo En réponse à : Gérer un SPIP mutualisé avec SSH et SVN

merci pour ce tuto
je comprenais rien à svn
j’ai avancé sérieusement aujourd’hui et te remercie pour la partie récupération des plugins par svn

maintenant, je vais cherche comment les envoyer sur la mutu