[spip-dev] Rationalisation de l'arborescence

Dev
1

Salut,

je cherche à rationaliser l'arborescence de spip (pour unix).

Serait-il envisageable d'utiliser des variables pour différents
répertoires dont :

ecrire
ecrire/upload
ecrire/data
CACHE
IMG
NAVPICS

et utiliser ces ficheirs pour tous les open/wirte/include des fichiers
là dedans ?

L'idée c'est de pouvoir monter une partition en lecture seule, avec des
bouts de spip dedans, et une partition en rw, avec la partie dynamique
de spip ?

Considérer que spip n'est pas forcément un jeu de fichiers php pour
apache, mais une appli à part entière ?

2

Gaetan Ryckeboer wrote:

Salut,

je cherche à rationaliser l'arborescence de spip (pour unix).

Serait-il envisageable d'utiliser des variables pour différents
répertoires dont :

ecrire
ecrire/upload
ecrire/data
CACHE
IMG
NAVPICS

et utiliser ces ficheirs pour tous les open/wirte/include des fichiers
là dedans ?

L'idée c'est de pouvoir monter une partition en lecture seule, avec des
bouts de spip dedans, et une partition en rw, avec la partie dynamique
de spip ?

Considérer que spip n'est pas forcément un jeu de fichiers php pour
apache, mais une appli à part entière ?

je ne sais pas tres bien ce que cette idée lumineuse va t'apporter.
si tu souhaites avoir plus de stabilité, monte ton filesysteme en ext3.

dans le meme ordre d'idée de rationalisation, il est assez desagreable
en tant que developpeur de squelette de massacrer la racine de SPIP
avec ses propres scripts.

actuellement pour travailler au mieux, il faut dans $spip_root/mes_fonction.php3

// positionnement d'un repertoire pour le squelette
// http://www.uzine.net/article1825.html
$GLOBALS['dossier_squelettes'] = "dir/....";

puis travailler au maximum dans ce repertoire. Visiblement le standard a
l'air d'etre $spip_root/_template

Par la suite pour les pages externes que je doit ajouter au site, je me
suis donné la convention suivante : je les mets a la racine de SPIP
($spip_root), puis je les prefixe d'un __ ; ex :

   $spip_root/__articles_tous.php3

Les parties de squelette incluses peuvent rester dans le repertoire dedié
aux squelettes.

  <INCLURE (_header_full.php3)>

Sinon, sur le plan du code, il faudrait separer plus clairement la partie
administration du site de la partie exploiation. Je verrais bien qq chose
comme ca :

$spip_root/spip/ (parties communes : moteur de template et des racourci)
$spip_root/admin/ (correspond plus ou moins au contenu de ecrire, mais sans le moteur)
$spip_root/cache/ (le cache, pas de changement)
$spip_root/plugins/ (les extentions)
$spip_root/squelettes/nom/[html|lib|misc]

autre point a considerer, sur Free.fr, pas possible de changer l'include_path.
mais le repertoire racine/include est automatiquement pris en compte. Ce qui signifie
qu'on pourrait faire directement ceci :

$spip_root/include/inc_spip.php
$spip_root/include/inc_*.php

3

Monter un maximum de choses en readonly est une barrière
supplémentaire pour ceux qui voudrait bricoler ton site dans ton dos.
  Si quelqu'un trouve une faille qui lui permet d'écrire dans tes
fichiers et donc de défigurer ton site, le read only rendra cette manip
impossible.
  Si c'est bien gaulé, même qulqu'un qui arrive à se pointer sur ton
serveur, et à passer root ne pourra pas modifier tes fichiers (bon
d'accord, il pourra faire un max de saloperies, mais pas celle là :slight_smile:

À+, Pif.

4

  Monter un maximum de choses en readonly est une barrière
supplémentaire pour ceux qui voudrait bricoler ton site dans ton dos.
  Si quelqu'un trouve une faille qui lui permet d'écrire dans tes
fichiers et donc de défigurer ton site, le read only rendra cette manip
impossible.

Effectivement, Pif et moi parlons en connaissance de cause à ce niveau,
et c'est loin d'être toujours évident à réaliser :-))))

Oui, Gaétan, si tu as la soluce, je suis TRES TRES preneur, à titre
professionnel hein.

  Si c'est bien gaulé, même qulqu'un qui arrive à se pointer sur ton
serveur, et à passer root ne pourra pas modifier tes fichiers (bon
d'accord, il pourra faire un max de saloperies, mais pas celle là :slight_smile:

A la, pas d'accord, mount -o remount, rw /dev/mondisque /mnt/spip et
c'est fini. Pour un root, c'est facile :-)))))

Par contre oui, si jamais le safe mode suffit pas, c'est une protection de plus non négligeable.

5

A la, pas d'accord, mount -o remount, rw /dev/mondisque /mnt/spip et
c'est fini. Pour un root, c'est facile :-)))))

Par contre oui, si jamais le safe mode suffit pas, c'est une protection de plus non négligeable.

sans parler que les failles les plus nombreuses sont dans le code
php lui-meme. Il faudra aussi supprimer les fopen() en ecriture,
les copy(), les system() et autres exec

Bon, c'est vrai qu'a partir de la, le systeme du mode ro est plutot
favorable.

Quels sont donc les fichiers ou repetoires modifiés par SPIP. Il
y'a principalement le CACHE. Dans la partie administration du site
il y a aussi d'autre repertoires :

spip_test_dirs.php3 :

         $test_dirs = array("CACHE", "IMG", "ecrire", "ecrire/data");

essaie de fabriquer des liens pour tous ces repertoires et le tour est joué.

6

Marc Quinton a écrit :
[...]

Quels sont donc les fichiers ou repetoires modifiés par SPIP. Il
y'a principalement le CACHE. Dans la partie administration du site
il y a aussi d'autre repertoires :

spip_test_dirs.php3 :

        $test_dirs = array("CACHE", "IMG", "ecrire", "ecrire/data");

essaie de fabriquer des liens pour tous ces repertoires et le tour est joué.

Quid de la config apache ? chez moi, par exemple, je désactive le suivi des liens symboliques :-p

En tout cas, l'idée est bonne, mais va falloir le mettre en gros (très gros même - voire même avec des lumières clignotantes tout autout) au niveau de l'install : parce que sinon, faut s'attendre à quelques (beaucoupde) mails sur le sujet : spip ne s'installe pas, j'ai une erreur machin-truc à la ligne xxx :wink:

Claude

7

Quid de la config apache ? chez moi, par exemple, je désactive le suivi des liens symboliques :-p

En tout cas, l'idée est bonne, mais va falloir le mettre en gros (très gros même - voire même avec des lumières clignotantes tout autout) au niveau de l'install : parce que sinon, faut s'attendre à quelques (beaucoupde) mails sur le sujet : spip ne s'installe pas, j'ai une erreur machin-truc à la ligne xxx :wink:

Claude

tout a fait !

dans ce cas, il faut prevoir ce fonctionnement en option, $GLOBALS['spip']['config']['fs']['ro'] = true;
et l'accompagner d'un joli article d'installation-configuration.

PS : zut, les reponses a la liste !!! on pourrait pas inverser ca ?