installation, base de données, echec accès privé

declic

Septembre 2010

Bonsoir,

Lors de l’installation de spip 2.1 en ligne, une fois la procédure terminée, j’accède à la fenêtre de connexion, j’indique les noms et mots de passe créés lors de l’installation, malgré la verification des droits d’accès sur les dossiers tmp, local, ecrire, img... ( 777),

je vois le nom=oui dans la barre d’adresse, mais la page s’arrête et j’obtiens le message suivant :

vérifier les droits d’écriture
Le système a rencontré une erreur lors de l’écriture du fichier local//.ok. Veuillez, en tant qu’administrateur du site, vérifier les droits d’écriture sur le répertoire ecrire/local.

mais il n’y a pas de repertoire ecrire/local.

j’ai refait plusieurs fois la procédure sans résultats :
– connexion à la base php/mysql chez l’hébergeur, effacement des tables spip,
– supression des fichiers chmod.php et connect.php
– vérification des autirisation
– réinstallation via nomdedomaine/ecrire/

J’ai pourtant installé plusieurs site spip chez le même hébergeur, dans les mêmes conditions, sans avoir ces problèmes.

Merci de votre aide

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

Septembre 2010

essaie après avoir créé un répertoire /local à la racine
Indiquez l’intérêt que vous portez à cette réponse

0

declic

Septembre 2010

Merci de ta réponse,

mais il y a déjà un repertoire local créé à la racine par spip, ses autorisations sont bonnes (777)...
Indiquez l’intérêt que vous portez à cette réponse

0

gazgaz

Septembre 2010

Bonjour
Appliquez vous ces droits aux fichiers et sous-dossiers des répertoires ??
Indiquez l’intérêt que vous portez à cette réponse

0

Septembre 2010

Bonjour,

Après une nuit passer à faire et refaire, j’ai pu faire fonctionner une spip2.08, site public et privé, en créant moi même en FTP les dossiers temp et local ainsi que leurs sous-dossiers, et en gérant leurs autorisations d’accès. Par contre je n’ai pas réussi avec la version spip2.1.2... en faisant pourtant la même chose.

J’aurais pu me contenter de la 2.08, mais j’avais le soucis suivant :
impossible d’importer des .pdf ou des docs de mon ordi dans un article ou une rubrique alors que le jpg ne pose aucun problème !!
de même le upload ne fonctionne pas.

Pourtant vous imaginez bien qu’échaudée par l’installation, espérant que la la 2.1.2 corrigerait ce défaut, j’avais pris soin de créer moi même les dossiers et sous-dossier IMG et de géré leurs autorisations...

Evidement, en installant dans un autre dossier la 2.1.2, qui pointe vers la même et unique base de l’hébergement avec les même login et pw, j’ai perdu sur la 2.08 les autorisations d’accès que j’avais eu temps de mal à avoir...! mais maintenant je sais comment faire pour la ré-installer... Patience et précision...

Mon soucis aujourd’hui c’est donc de charger des pdf et des docs, il y a du progrès !

Merci à ceux qui participent à mon éducation Spip !
je suis une infographiste qui met les mains dedans, j’en suis à mon deuxième site spip, mais je n’ai pas la culture "développeur"... sans tout ce que je lis sur ce site je ne serais rien !
Indiquez l’intérêt que vous portez à cette réponse

0

gazgaz

Septembre 2010

Créez les dossiers /pdf et /odt ou /doc dans /IMG et donnez ensuite un accés en écriture récursivement au dossier /IMG. Cela pour les 2 versions de spip
puis —>Ajouter une image ou un document
Indiquez l’intérêt que vous portez à cette réponse

0

declic

Septembre 2010

Pour la version 2.1.2, je ne me sors pas des histoires de droits... j’ai créer moi même en ftp tous les dossiers temp (et tous les sous-dossiers cache/sessions/ upload..), IMG (et tous les sous-dossiers jpg/pdf/gif/doc.., local), local (et tous les sous-dossiers cache-vignettes/cache-css...). J’ai mis tout le monde en 777

J’arrive à me connecter à l’espace privé, mais j’ai des messages d’erreur partout :

"Warning : Cannot modify header information - headers already sent by (output started at /home3/sites/site11/web/spip/ecrire/exec/naviguer.php:59) in /home3/sites/site11/web/spip/ecrire/inc/headers.php on line 147
vérifier les droits d’écriture

Le système a rencontré une erreur lors de l’écriture du fichier local/cache-vignettes//.ok. Veuillez, en tant qu’administrateur du site, vérifier les droits d’écriture sur le répertoire ecrire/local/cache-vignettes."
Indiquez l’intérêt que vous portez à cette réponse

0

gazgaz

Septembre 2010

Qui fonctionne ?
La 2.08 ?
Revenez dessus et au besoin faites une sauvegarde dans /tmp/dump.
Cette sauvegarde ne sera utilisée exclusivement que sur un système 2.0.8 !!. Gardez l’archive dans un répertoire de sauvegarde.
Si vous avez toujours des problèmes de base, reprenez avec gestionnaire de base une ancienne sauvegarde de votre site(en espérant que vous en avez fait une).
Ensuite essayez les fichiers pdf doc dessus avec les droits.
Indiquez l’intérêt que vous portez à cette réponse

0

declic

Septembre 2010

Merci de votre réponse,
j’ai effectivement laissé tombé la 2.1.2, et je travaille maintenant sur la 2.08.
même problèmes :
– l’importation jpg marche très bien, l’importation pdf non (alors qu’en local oui). Pourtant dans les 2 cas j’ai créer moi-même les dossier jpg et pdf (777)... bizarre !!

j’ai re-importé une sauvegarde plus ancienne, idem...

– Autre bizarrerie, lors de la sauvegarde de la base, il crée un fichier statuts-dump_1base.xml, au premier niveau du dossier tmp et dans le dossier dump, un sous dossier statuts-dump...

Le reste fonctionne normalement
Indiquez l’intérêt que vous portez à cette réponse

0

gazgaz

Septembre 2010

Quelles sont vos possibilités au niveau hébergement ?
Un sous domaine ou un autre espace puis une reprise à neuf d’une install avec création d’une nouvelle base, ensuite injection de votre sauvegarde xml.gz via configuration maintenance... ou alors reinstall avec suppression de vos anciens répertoires (faire une sauvegarde avant) et votre base existante avec les paramètres (nom,user, passwd )
Indiquez l’intérêt que vous portez à cette réponse

0

declic

Septembre 2010

Je suis sur le nouvel hébergement (rapodomaine) de mon client,
je suis partie d’une base vierge et d’une version d’installation spip2.1.2.
Comme je n’arrivais pas à me sortir des droits d’accès, j’ai supprimé toutes les tables spip de la base (phpadmin), installé en ftp une version d’installation 2.08,

les pbs persistent
– importation jpg ok, mais ni pdf, ni doc
– le upload qui ne fonctionne pas
– la sauvegarde dans le dossier dump qui ne fonctionne pas non plus :
spip crée un fichier statuts_dump.xml, j’ai tenté une restauration via ce fichier pour voir, j’ai eu le message suivant

Action : Restauration de la sauvegarde status_dump_1_Centre_de_Formation_20100929.xml

Attention ! Le fichier .. / tmp / dump / status_dump_1_Centre_de_Formation_20100929.xml correspond à une autre version de SPIP que celle que vous avez installée. Vous allez au-devant de grosses difficultés : risque de destruction de votre base de données, dysfonctionnements divers du site, etc. Ne validez pas cette demande d’importation.
Pour plus d’informations, voyez la documentation de SPIP.

– j’ai essayé plusieurs anciennes sauvegardes xml, sans résultats

On voit bien que le problème des autorisations d’écriture persiste malgré les moults essais en re-créeant les dossiers et les droits, spip n’arrive pas à écrire comme il veut ou il veut, par exemple le dossier cache du dossier temp est bourré de .plat que je n’avais jamais vu avant...
Indiquez l’intérêt que vous portez à cette réponse

0

Septembre 2010

Avant de supprimer les tables, j’espère que vous avez une ancienne sauvegarde de votre base faite par phpmyadmin sur votre disque local...
Si ce n’est pas le cas, il vous reste le secours : votre local en retransférant via phpmyadmin la base du site local et en la renommant site_bis sur le serveur sql de l’hébergeur.
Puis reessayé comme ci-dessus.
Pour le reste
les droits des fichiers spip et les droits aux bases sql sont différents d’ailleurs , ils n’ont pas les mêmes attributs. Une base sql n’est pas placé dans votre espace, mais ailleurs peut-etre sur un autre serveur physique avec d’autres droits de groupe(vous n’utilisez pas sqlite ) le seul lien, c’est l’hébergeur qui le fait en vous intégrant au groupe de la base de votre compte
Indiquez l’intérêt que vous portez à cette réponse

0

gazgaz

Septembre 2010

Un deux essai
Le dernier message, mon pseudo n’était pas visible
Indiquez l’intérêt que vous portez à cette réponse

0

declic

Septembre 2010

je vous remercie vivement de suivre mes galères !

je n’ai pas de sauvegarde phpadmin... pour être franche, je ne sais pas le faire.. je n’y connait pas grand chose en phpadmin, j’ai juste trouvé l fonction "export", mais je ne sais pas la paramétrer et je ne sais pas non plus ou va l’export (pardon pour ce niveau déplorable)

Donc j’ai fait avec mes moyens... à force de patience, en recréant tous les sous-dossier un à un des dossiers /local, et /temp/cache, j’ai pu retrouver le upload et la possibilité de charger des pdf, gif et autres !

Par contre le gros problème c’est toujours la sauvegarde !
la création de fichiers inexploitables (statuts_dump)..
même si je re-crée le dossier dump...
j’en ai fait les frais car j’ai essayé.. et après j’ai du tout re-configurer..
Indiquez l’intérêt que vous portez à cette réponse

0

gazgaz

Septembre 2010

Je crois qu’insister sur les /dump/fichierxml est une erreur.
Je ferais plutôt avec phpmyadmin à partir d’une source qui fonctionne.
– ouvrez phpmyadmin et allez dans export
2 parties une grande et une petite dessous, allez dans la grande à gauche et choisissez dans le menu votre base cliquez puis cliquez sur sql, partie droite laissez les valeurs par défaut ; puis 2° partie (inférieure ) intitulée transmettre cliquez sur gzippé Exécuter —> ouverture d’une fenêtre ->enregistrer le fichier et mettez le où bon vous semble.
Indiquez l’intérêt que vous portez à cette réponse

0

declic

Septembre 2010

Merci de vos conseils,

j’ai exporté la base via phpadmin,
je l’ai importée dans ma base locale via php admin local, et ma version spip locale fonctionne bien, j’ai effectué une sauvegarde qui s’est bien rangée dans le dossier dump, j’ai ensuite transféré ce fichier en ftp sur mon dump distant, quand je restaure la base spip tout se passe bien, les droits sont respectés et je peux tout importer..

Merci !! c’est déjà bien rassurant de pouvoir sauvegarder de cette façon...

Par contre quand j’ai voulu restaurer la base via phpadmin, j’ai eu le message suivant :

Request Entity Too Large
The requested resource
/mysql/import.php
does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.

Du coup j’ai du exporter ma base locale par paquet de tables, pour les importer paquet par paquet sur la base distante, et tout est rentré dans l’ordre.

Comme TOUT MARCHE bien (!), je suis plutôt contente, mais c’est un peu compliqué pour mon client qui a appris à utiliser l’interface spip pour ses sauvegardes (son site était en test sur mon hébergement). N’y a t-il aucun espoir de pouvoir utiliser le dump et la sauvegarde standard ???
Indiquez l’intérêt que vous portez à cette réponse

0

Octobre 2010

C’est réglé, et c’est bon à savoir,

le problème venait de l’hébergeur (rapidomaine) qui a effectué des maj sur ses serveurs cet été.
voici se réponse :
Réponse du support envoyée le 30/09/2010 18:43

Bonjour,

Nous avons bien reçu votre message. Suite à cela, nous avons fait plusieurs vérifications sur votre site. Nous avons constaté que le virtualhost de votre hébergement ne fonctionne pas bien. Pour cela, nous avons recréé le virtualhost ce qui a probablement corrigé ce bug. Si cela ne fonctionne pas cela peut venir du mod security à désactiver pour ce site. Merci de nous tenir informer.

Depuis tout fonctionne, y compris les sauvegardes !
Il reste cependant un truc, c’est que je ne peux pas charger dans spip des documents jpg, pdf, gif... au dessus de 120ko !
là aussi je me suis adressée à rapidomaine et j’attend la réponse

Merci de votre aide