ATTENTION , cet article nécessite d’utiliser une version stable > à 2.0
Les prérequis (au 1er janvier 2008) :
- posséder un nom de domaine disponible
- avoir la possibilité de modifier la configuration apache
Dans l’exemple suivant on supposera que l’on cherche à mettre la ferme sur le site GrmlEU [1]
Installation SPIP
Installer un SPIP (une version récente est recommandée). Pour la suite de l’exercice on supposera que le SPIP est installé dans le répertoire « /home/grml/public_html/ ».
Installation plugin mutualisation
Installer le plugin Mutualisation [2] (il est plus simple de ne pas le mettre dans le répertoire plugin) . Nous avons donc « /home/grml/public_html/mutualisation »
Configuration apache
Modifier la configuration apache
Si vous êtes sur apache2 il faut créer un fichier grml.eu.
etc/apache2/sites-available# more grml.eu
<VirtualHost *>
ServerName grml.eu
ServerAlias *.grml.eu
DocumentRoot /home/grml/public_html
</VirtualHost>Ce qui veut dire que tous les sous domaines de grml.eu vont pointer vers le répertoire « /home/grml/public_html ».
Ensuite il faut faire une lien symbolique pour que le domaine soit actif
cd etc/apache2/sites-enable
ln -s /etc/apache2/sites-available/grml.eu grml.eu Enfin il faut prendre en compte ces changements
/etc/init.d/apache2 force-reload Configuration DNS
Il faut maintenant que lorsque l’on tape grml.eu, il redirige vers l’adresse ip du serveur
voici la config utilisée chez gandi
Configuration de la mutualisation
Copier le fichier /home/grml/public_html/mutualisation/mes_options.php.txt vers « /home/grml/public_html/config » et enlevez l’extension « .txt » . Ouvrez ce fichier et procédez au paramétrage.
Pour vous aider voici le fichier de config utilisé sur scriibe
<?php
$GLOBALS['taille_des_logs']=1000;
#parametrage a faire
$monTld="scriibe.net";
require _DIR_RACINE.'mutualisation/mutualiser.php';
define ('_ID_WEBMESTRES', 1);
$site = $_SERVER['HTTP_HOST'];
$type_urls = 'propres2'; # par defaut, surchargeable ci-dessous
switch($site) {
case "www.$monTld":
$site=$monTld;
break;
case 'www.spip-blog.net':
$site='spipblog';
break;
case 'spip-blog.net':
$site='spipblog';
break;
default :
$site = str_replace('.scriibe.net', '', $site);
break ;
}
define ('_SITES_ADMIN_MUTUALISATION', ''); // ici sites esclaves
define ('_INSTALL_SERVER_DB', 'mysql');
define ('_INSTALL_HOST_DB', 'plouf');
define ('_INSTALL_USER_DB_ROOT', 'plouf');
define ('_INSTALL_PASS_DB_ROOT', 'plouf');
define ('_INSTALL_TABLE_PREFIX', 'spip');
define ('_INSTALL_NAME_DB', 'scr_'.prefixe_mutualisation($site));
if ($site != "$monTld") {
demarrer_site($site,
array(
'creer_site' => true,
'creer_base' => true,
'code' => 'plouf',
'url_img_courtes' => true,
'creer_user_base' => true,
'mail' => 'ben.spip@gmail.com'
)
);
}
else {
$GLOBALS['dossier_squelettes']=":mutualisation";
}
?>pour celui sur GrmlEU
<?php
if (!defined("_ECRIRE_INC_VERSION")) return;
require _DIR_RACINE.'mutualisation/mutualiser.php';
$site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
if ($site != $_SERVER['HTTP_HOST']) {
include_spip('inc/headers');
redirige_par_entete('http://'.$site.'/');
}
define ('_INSTALL_SERVER_DB', 'mysql');
define ('_INSTALL_HOST_DB', 'localhost');
define ('_INSTALL_USER_DB', 'plouf');
define ('_INSTALL_PASS_DB', 'plouf');
define ('_INSTALL_NAME_DB', 'grml');
#define ('_INSTALL_TABLE_PREFIX', 'spip');
define ('_SITES_ADMIN_MUTUALISATION', 'grml.eu');
demarrer_site($site,
array(
'creer_site' => true,
'creer_base' => false,
'creer_user_base' => false,
'mail' => 'ben.spip@gmail.com',
'code' => 'ecureuil',
'table_prefix' => true,
'cookie_prefix' => true,
'repertoire' => 'sites',
'url_img_courtes' => true,
'url_creer_base' => ''
)
);
?>On peut noter que pour scriibe, une base et un utilisateur mysql sont créés pour chaque site. Par contre sur GrmlEU, il n’y a qu’un user et qu’une seule base, avec un préfixe différent pour les tables de chaque site.
Discussions par date d’activité
2 discussions
Bonjour,
Je dois faire une mise à jour de ma ferme. Est-ce qu’il y a un qq part tuto sur la procédure à suivre ?
Je m’interroge notamment dans le cas où la BDD doit être mise à jour, ça va bien se passer ?
Merci pour vos éclairages.
Répondre à ce message
Bonjour,
J’ai mise en place une ferme SPIP 4.1.9 (PHP 7.4) d’une dizaine de sites.
J’ai voulu faire une mise à jour complète et :
1 - la mise à jour de SPIP via spip_loader ne fonctionne pas (page blanche). Quelle est la procédure recommandée ?
2 - la mise à jour des plugins provoque leur inactivation sur les sites dépendants de la ferme (les anciennes versions des plugins n’étant pas conservées). Quelle est là aussi la meilleure procédure ?
Merci pour vos conseils.
Bonjour,
1. tu as quel version du loader ?
2. oui il est recommander de travailler avec git pour géré une mutualisation car quand on met à jour les plugins cela changement le chemin si tu le fait avec SVP. Sinon il faut que chaque site est son répertoire de plugins
Bonjour Pierre,
Pour spip_loader, j’utilise la version 6.1.2, et j’obtiens une erreur SHA512. Cela ne semble pas une erreur propre à la ferme, je m’en rends compte maintenant.
Pour la mise à jour des plugins, j’ai contourné le problème en mettant en place un mini-plugin qui spécifie la nécessité d’activation de tous plugins. C’est un peu fastidieux, mais c’est pratique.
Je ne sais pas ce que travailler avec GIT signifie, mais si ça peut aider, je suis preneur.
Merci pour ton aide _||_
Faire de git clone et autre commande du coup ton chemin de plugins ne change pas
Après tu as spip-cli qui avec des ligne de commande rajoute des plugins et les actives ou met à jour la bdd sans passer dans le BO mais je ne l’utilise pas.
Merci encore pour ton aide si rapide !
Je ne connais pas du tout ces outils Git, et ne saurai pas pour l’instant procéder de cette manière. Mais j’ai partiellement résolu mes problèmes :
1) je vais faire la mise à jour du SPIP centralisé de la ferme de manière manuelle.
2) je vais créer un plugin pour chaque website qui liste tous les plugins et les qualifie comme nécessaires. Ainsi je mets à jour tous les plugins en 1 clic.
Pour autant, ce qui aurait été sécurisant et pratique, c’est que le dossier Plugins de la ferme SPIP conserve les versions anciennes des plugins après mise à jour. SPIP est manifestement maintenant structuré pour rendre possible cette option, mais comment la rendre effective ?
A propos du problème SHA512 « spip_loader.php on line 18 », il semble que ce ne soit pas propre à la ferme mais général... Affaire à suivre.
@Pierre Kuhn : Cette histoire de git m’interesse...
Quelle sont les commande git pour mettre à jour un plugin ? Pour changer de version (rétrograder comme mettre à jour la dernière version) ? Y a-t-il un petit memento quelque part à ce sujet ?
Merci d’avance
J’utilise https://git.spip.net/spip-contrib-outils/checkout
Je pense pas que tu puisse retrograder, je vois pas le besoin non plus d’ailleurs.
Si tu git pull un dossier pour le mettre à jour cela met à jour le plugins sur la dernière version, attention au branche pour ne pas se perdre ou casser le site
Pour solution,
j’ai opté pour la création d’un petit plugin « Activation Automatique » (un simple paquet.xml) dédié à chaque site, qui liste les plugins nécessaires à l’utilisation du site.
Quand je fais une mise à jour, je n’ai qu’à le réactiver AA pour que tous les plugins soient eux-mêmes réactivés.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
