moi aucun probleme. Regarde peut etre au niveau du .htaccess

bonjour peux tu me donner plus de détail sur environnement sur lequel tu as installé SPIP.

Merci pour vos réponses,

le htaccess est en .htaccess Pour ce qui est de l’environnement, il s’agit d’une installation sur un serveur Amen. Ayant déjà instatllé spip de 1.3 à 1.8 chez eux, je ne pense pas qu’il y ait un problème avec mon hébergeur. Je refais une nième tentative sur un nouveau compte et vous tiens au courant. J’avoue que c’est étrange car j’ai eu le même problème en essayant d’installer la version 1.9.3.

Bonjour,

Je pense avoir trouvé le problème. Il vient du logiciel que j’utilise pour transférer les fichiers par FTP (Filezula) Ce dernier ne permet pas toujours de modifier le chmod. J’ai utilisé cuteFTP et j’ai eu un message d’accès interdit pour attribuer les droits en écriture. J’ai donc effacé le répertoire via cuteFTP et j’en ai créé un nouveau du même nom, les droits se sont créés "avec succès". Cela fonctionne.

Tu veux dire que tu as renvoyé tous les fichiers spip ?
J’ai le même problème sur une Sarge avec Plesk 8.6.0 (apache2, php5.2.6 et mysql 4.1.11)

par contre dans /tmp/spip.log, ça commence mal :(
Oct 07 20:00:13 IP (pid 16131) faux sous-repertoire tmp/cache Oct 07 20:00:13 IP (pid 16131) echec creation cache/1 Oct 07 20:00:13 IP (pid 16131) echec creation tmp/cache/skel

et plusieurs lignes :
Oct 07 20:00:13 IP (pid 16131) Creation du cache log-log-%2Fec-fr—66273360f83e20c pour 86400 secondes (erreur !) Oct 07 20:00:14 IP (pid 16131) Creation du cache for-lan-var-lan-ecr-htt—c1139889 pour 3600 secondes (erreur !)

Pourtant les droits de /tmp semblent correcte :
drwxrwxrwx 4 spip2beta psacln 4096 Oct 7 20:08 tmp

Je n’ai pas eu tous ces messages d’erreurs mais que ce soit avec les spip 2.0 et 1.9.X dev j’avais toujours le même message après l’installation pour l’identification. J’ai insallé la version 1.9.3 et j’ai eu le même problème. donc, cela ne venait pas de spip. D’où l’idée que cela était dû à mon FTP. J’avais une version de cuteFTP que je n’utilisait plus et là miracle, les droits en écriture se mettaient normalement. Comme je l’ai déjà signalé, lorsque je ne pouvais pas mettre les droits, j’ai effacé les répertoires en question pour je les ai recréés. Depuis cela fonctionne. Je ne pourrais pas expliquer d’avantage car c’est la seule solution que j’ai trouvée pour continuer à tavailler avec SPIP. J’ai utilisé le squelette de sarkaspip qui est génial. Voir le site : infoval74.com

Bon, Après quelques essais de renvois de fichiers, et des modifications de droits, j’ai trouvé d’où ça venais pour mon serveur.
Il s’agit du mode safe_mode de php que Plesk active par défaut.
voilà voilà...

Normalement SPIP est comptible avec presque toutes les options du safe_mode

Je pense que c’est une question de droit d’utilisateur ou de group.

Une fois le login/pass donné, j’arrive sur l’URL /spip.php ?page=login&url=%2Fecrire%2F%3Fexec%3Daccueil où il y a le message "login : Accès interdit"

Les valeurs de php concernant le safe_mode sont :

Ça fait donc une comparaison de groupe. /tmp/cache possède les droits de apache (www-data) et le fichier qui cherche à créer des sous-dossiers reste le propriétaire de l’utilisateur ftp.

C’est bien un problème de vérification de propriétaire. Dans le cas de Plesk, l’utilisateur apache n’appartient pas au groupe des utilisateurs FTP, et inversement.

La solution la plus simple est de passer tout les fichiers envoyé dans le groupe d’apache, le dossier des squelettes excepté.

j’aimerai voire et installer les images ou l’on voie de nembreses oasis etimages de tata,merci

Il semblerait que dans ce cas là si on laisse le répertoire squelettes pas à www-data, spip ne prend pas en compte les squelettes à l’intérieur. Même si on met un 777. Les joies de plesk, du safe_mode et d’apache :)

Bonjour,

Je viens de faire une mise à jour de spip 1.9.2.c vers spip 2.0 par ftp (site hébergé par ifrancepro.com). Depuis lors, je n’ai plus accès à la partie privée.

Que faire ?

J’ai mis tous les droits tous les fichiers en 777 mais rien n’y fait.

Cordialement.

Platonas

il te faut supprimer les anciens fichiers 1.9.2 résiduels que 2.0 n’a pas effacé (il se contente d’écraser les anciens par ses neufs)

je souhaite télécharger spip 2.0 , s’il ai performent et je vous félicite pour le travail que vous fournissez , pour que ça soit réaliser

Merci Denis,

J’ai bien effacé tous les fichiers de l’ancienne version de spip.

J’ai renvoyé tous les nouveaux fichiers (spip 2.0) sur le site.

Je me suis reconnecté à la base.

Tout est à peu près rentré dans l’ordre : je peux à nouveau me reconnecter à l’espace privé.

Petits hics : - le cache reste désespérément vide et le site est devenu très lent. J’ai des messages d’erreurs,

J’ai vérifié les droits : ils sont bons, mais il n’existe pas de fichier fr-aide.html.

autre message d’erreur :

Précisions : j’ai installé cfg et sarkaspip et ça a l’air de pas mal bugger.

Quand je désactive les plugins, tout refonctionne bien, sauf le cache qui reste vide.

A +

apparemment, les droits sur les répertoires et fichiers posent problème.

par ftp, renommer le répertoire tmp/ en old_tmp/ ;
créer un (nouveau) répertoire tmp/

retourner en page de configuration pour les plugins.
voir ce qui se passe.

parfois l’affichage des droits n’indique pas la valeur du propriétaire du répertoire/fichier...

Le problème viens des autorisations des dossiers : "cache" et "sessions" dans la racine "tmp" il faut les supprimer et ensuite les recréer et redéfinir leurs autorisation qui doit être en 777. Ensuite vous pourrez normalement vous connecter dans la partie administration

bonjour

je viens de tenter une mise a jour de 192f à spip 2 j’ai le plugin magusine qui ne semble pas compatible mais impossible d’aller dans l’espace privé pour le désactiver je l’ai renommé dans le dossier plugins

si je vais sur /ecrire j’ai un message qui me dit que cette page n’existe pas Erreur 404

impossible aussi de changer le dossier tmp/cache en 777 Requested action not taken (e.g., file or directory not found, no access).

pourtant j’avais précédemment testé la version bêta et cela fonctionnait

l’adresse de mon site (qui est en miroir) http://ops.apinc.org/spip/

merci claire

problème résolu j’avais spip dans un sous répertoire

une fois les dossiers remis a la racine du site cela a fonctionné a part magusine ;-)

mais je pense que c’est une question de jours

claire

Bonjour, je viens d’avoir le même problème en installant spip2.0 (en fait j’ai déjà eu ce pb avec les autres versions APRES transfert des fichiers vers le serveurs distant.

j’ai trouvé comme solution : 1-supprimer les répertoires /cache /sessions 2-recréer les ces mêmes répertoires et leurs donner les droits 777

je viens de le faire et ça marche bien.

bon courage

J’ai suivi, les indications, effacer et recréer les repertoires et mettre en chmod 777. Malheureusement le vidage du cache supprime et recrée les répertoires.

Alors avez vous une autre soluce plus efficace ???

testé avec une version spip 2.0.2 vierge... aucun plugin...

Installation Spip 2.0.7 avec Mamp, aucun souci.

La galère : Installation sur serveurs dédiés 1&1, divers OS testés, Php4 et 5, Plesk 8.6.

Une seule réponse aux identifiants corrects :

Login : accès interdit.

jusqu’à ce que je décoche le safemode php dans la configuration du serveur (interface Plesk), après avoir vidé les répertoires tmp et config et réinitialisé la Base de données à tout hasard.

Puis redémarré Apache, on sait jamais ça peut aider ?

J’ai enfin accès au back-office. En php 4.

Prochainement dans ce même thème :

Je teste avec CentOs et Php 5.

j’importe une sauvegarde des données.

La suite : Je teste avec CentOs et Php 5.

Première erreur à propos du fichier tmp/prive_spiplog. J’efface ce document qui vient d’être créé et je relance la procédure d’installation.

Deuxième et troisième erreur : fichier fr introuvable. Je ne me décourage pas, à chaque fois j’efface le fichier tmp/prive_spiplog (à tout hasard) et je relance l’installation.

Quatrième tentative : j’accède enfin à la suite de l’installation qui se déroule normalement et le back-office s’affiche.

C’est un peu comme au temps où l’on démarrait les Deux-chevaux à la manivelle ; il en fallait de la patience !

Bientôt, la personnalisation avec le transfert par ftp des dossiers squelettes et IMG et l’import d’une sauvegarde de la base des données, le tout provenant de l’installation sous Mamp.

La personnalisation :

Transfert des dossiers IMG, squelettes, plugins et du favicon.ico. Réglages généraux du site. Réglage des plugins (ne pas oublier de recréer les champs extra pour accueillir la sauvegarde de la base).

Puis Configuration/Maintenance du site pour effectuer la restauration de la base.

La sauvegarde a bien été transférée par ftp dans tmp/dump, mais aucune fonction de restauration n’apparaît.

Grande perplexité.

Puis la lumière jaillit, dans le plugin "Autorité" existe le réglage : Qui peut effacer la base de données du site ? qui était fixé à "personne" et une restauration est aussi une atteinte à l’intégrité de la base en cours !

Une fois ce détail réglé, l’accès à la restauration réapparait et qqs secondes plus tard le site fonctionne sur le serveur dédié.

Question :

Est-ce que maintenant que Spip est installé, je peux remettre le safemode php à ON ?

Ce sera l’objet du prochain test.

Retour au safemode à on.

Le site fonctionne bien, mais l’accès au backoffice est à nouveau impossible.

login : Accès interdit

 :-(

Emise en route du au safemode off

Merci à lp* pour la solution.