Bonjour,
Voilà on est une association. Dolibarr était installer jusque là sur un pc local (doliwamp).
Nous voulons le passer sur notre serveur mutualisé (A-a-hebergement)
On y a installer Dolibarr 9.0.3.
Du coup on a fait passer la version local à 9.0.3 aussi.
On exporte vie l’outil de sauvegarde les bases de données
On les charge sur le serveur distant : pas d’erreur les tables sont bien remplies après vérification
Mais lorsqu’on relance la page d’admin du serveur, on obtient ceci :
« Not Found
The requested URL /dolibarr/install/index.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. »
La vrai page d’admin étant : « https://collectif-irs.org/dolibarr/admin/index.php »
On ne comprend pas pourquoi il cherche à pointer sur /dolibarr/install/index.php
On est bloqué là sans trop savoir ce qui peut bloquer ni vers ou regarder.
Merci d’avance pour vos éclairage
Michael
Bonjour, (suite)
Je rappelle que tout fonctionne après installation sur le serveur et avant l’entrée des bases (si je rentre un nom d’organisation)
Dans phpmyadmin que je coche (clé étrangère ou pas) le résultat fonctionne très bien, 846 factures et 2 users après contrôle.
Voilà le fichier conf.php avant le dump :
<?php
//
// File generated by Dolibarr installer 9.0.3 on Jun 07, 2019
//
// Take a look at conf.php.example file for an example of conf.php file
// and explanations for all possibles parameters.
//
$dolibarr_main_url_root='https://xxxxxx.org/dolibarr';
$dolibarr_main_document_root='/home/xxxxxxx/public_html/dolibarr';
$dolibarr_main_url_root_alt='/custom';
$dolibarr_main_document_root_alt='/home/xxxxxx/public_html/dolibarr/custom';
$dolibarr_main_data_root='/home/xxxxxxx/dolibarrdata';
$dolibarr_main_db_host='localhost';
$dolibarr_main_db_port='3306';
$dolibarr_main_db_name='xxxxxxx';
$dolibarr_main_db_prefix='llx_';
$dolibarr_main_db_user='xxxxxxx';
$dolibarr_main_db_pass='xxxxxxx';
$dolibarr_main_db_type='mysqli';
$dolibarr_main_db_character_set='utf8';
$dolibarr_main_db_collation='utf8_general_ci';
// Authentication settings
$dolibarr_main_authentication='dolibarr';
//$dolibarr_main_demo='autologin,autopass';
// Security settings
$dolibarr_main_prod='0';
$dolibarr_main_force_https='0';
$dolibarr_main_restrict_os_commands='mysqldump, mysql, pg_dump, pgrestore';
$dolibarr_nocsrfcheck='0';
$dolibarr_main_cookie_cryptkey='xxxxxxx';
$dolibarr_mailing_limit_sendbyweb='0';
//$dolibarr_lib_FPDF_PATH='';
//$dolibarr_lib_TCPDF_PATH='';
//$dolibarr_lib_FPDI_PATH='';
//$dolibarr_lib_TCPDI_PATH='';
//$dolibarr_lib_ADODB_PATH='';
//$dolibarr_lib_GEOIP_PATH='';
//$dolibarr_lib_NUSOAP_PATH='';
//$dolibarr_lib_PHPEXCEL_PATH='';
//$dolibarr_lib_ODTPHP_PATH='';
//$dolibarr_lib_ODTPHP_PATHTOPCLZIP='';
//$dolibarr_js_CKEDITOR='';
//$dolibarr_js_JQUERY='';
//$dolibarr_js_JQUERY_UI='';
//$dolibarr_js_JQUERY_FLOT='';
//$dolibarr_font_DOL_DEFAULT_TTF='';
//$dolibarr_font_DOL_DEFAULT_TTF_BOLD='';
et après le chargement de la base :
<?php
//
// File generated by Dolibarr installer 9.0.3 on Jun 07, 2019
//
// Take a look at conf.php.example file for an example of conf.php file
// and explanations for all possibles parameters.
//
$dolibarr_main_url_root='https://xxxxxx.org/dolibarr';
$dolibarr_main_document_root='/home/xxxxxxx/public_html/dolibarr';
$dolibarr_main_url_root_alt='/custom';
$dolibarr_main_document_root_alt='/home/xxxxxx/public_html/dolibarr/custom';
$dolibarr_main_data_root='/home/xxxxxx/dolibarrdata';
$dolibarr_main_db_host='localhost';
$dolibarr_main_db_port='3306';
$dolibarr_main_db_name='xxxxxx';
$dolibarr_main_db_prefix='llx_';
$dolibarr_main_db_user='xxxxxx';
$dolibarr_main_db_pass='xxxxx';
$dolibarr_main_db_type='mysqli';
$dolibarr_main_db_character_set='utf8';
$dolibarr_main_db_collation='utf8_general_ci';
// Authentication settings
$dolibarr_main_authentication='dolibarr';
//$dolibarr_main_demo='autologin,autopass';
// Security settings
$dolibarr_main_prod='0';
$dolibarr_main_force_https='0';
$dolibarr_main_restrict_os_commands='mysqldump, mysql, pg_dump, pgrestore';
$dolibarr_nocsrfcheck='0';
$dolibarr_main_cookie_cryptkey='xxxxxx';
$dolibarr_mailing_limit_sendbyweb='0';
//$dolibarr_lib_FPDF_PATH='';
//$dolibarr_lib_TCPDF_PATH='';
//$dolibarr_lib_FPDI_PATH='';
//$dolibarr_lib_TCPDI_PATH='';
//$dolibarr_lib_ADODB_PATH='';
//$dolibarr_lib_GEOIP_PATH='';
//$dolibarr_lib_NUSOAP_PATH='';
//$dolibarr_lib_PHPEXCEL_PATH='';
//$dolibarr_lib_ODTPHP_PATH='';
//$dolibarr_lib_ODTPHP_PATHTOPCLZIP='';
//$dolibarr_js_CKEDITOR='';
//$dolibarr_js_JQUERY='';
//$dolibarr_js_JQUERY_UI='';
//$dolibarr_js_JQUERY_FLOT='';
//$dolibarr_font_DOL_DEFAULT_TTF='';
//$dolibarr_font_DOL_DEFAULT_TTF_BOLD='';
Il n'y a jamais de balise de fermeture de php mais cela ne semble pas manquer.
Il n'y a pas dans public_html de répertoire "install" qu'il semble chercher !? après le transfert des bases!
Vraiment c'est improbable : comment en utilisant un dump peut-il aller chercher un nouveau répertoire alors que rien n'a changer à par les bases ?
ps : on ne transfert pas le contenu de "documents" car on n'imprime des factures en doubles et pour avoir déjà eu un serveur distant qui nous a lâché récemment, rien nous nous a manqué pour continuer la facturation.
heureusement qu'il y a du support ! sans quoi je ne vois pas comment trouver !
Merci d'avance
si en local c’est 9.0.2 et en distant c’est 9.0.3 il va forcément demander le répertoire install
ou alors il y a un problème de droit d’accès au fichier conf.php !
non,non. hier soir j’ai passé le local en 9.0.3 pour être certain que ce ne sois pas ça le souci.
(d’ailleurs j’ai eu du mal alors que nous étions passé de 3.? à 9.0.2 il y a trois mois assez simplement)
J’ai donc réexporté les bases, mais même combat au final.
et juste pour info, le répertoire « install » ne doit pas être absent car il contient des données importantes lorsqu’on utilise la comptabilité avancé, il est plutôt conseillé de le protéger en ajoutant un fichier vide nommé « install.lock » à la racine du répertoire « documents » :
chez vous dans le répertorie [code]
/home/xxxxxx/dolibarrdata[/code
Dans le répertoire dolibarrdata du serveur, j’ai bien install.lock (fichier) mais pas de répertoire « install ».
Ce qui est étonnant c’est que l’instant sur le serveur se passe parfaitement bien sans ce répertoire. Finalement
le problème n’apparaît que lorsque je charge les bases via phpmyadmin.
sinon remettez le répertoire « install » de la 9.0.3 à la racine de /home/xxxxxxx/public_html/dolibarr
renommez le fichier « install.lock » et relancer la mise à jour 8 vers 9
Là je ne comprends pas.
En local, bien que nous ayons eu quelques difficultés, le passage de 9.0.2 vers 9.0.3 fonctionne puisqu’on s’en sert
même aujourd’hui.
L’installe sur le serveur distant se fait par Softaculous et installe directement la dernière version 9.0.3, ce pourquoi nous pensions
qu’il y avait « peut-être » un problème de version que nous avons levé en passant sur le local à la même version.
Mais le problème reste entier.
Je viens de regarder dans les répertoire du serveur distant, aucun répertoire « install » et en refaisant l’installation tout fonnctionne parfaitement sans?!
Si je comprends bien en installant ce que vous dîtes sur le serveur distant, il va passer de lui-même en mode « install » mais comme il
est déjà « au taquet » des versions que se passera-t-il vraiment ?
ah, et je passe par l’outil de Dolibarr « sauvegarde » pour extraire les bases (soit ), sur l’ancien serveur distant tout c’est très bien passé. J’ai essayé les deux mysqldump et php, les deux fonctionnent aussi bien dans phpmyadmin, mais le résultat et le même par la suite.
Il y a plutôt quelque chose qui est dans la base en local, qui passe inaperçu mais qui déclenche ensuite la recherche du répertoire « install » sur le serveur distant. Étrangement, cela ne pose aucun souci en local ???!
autre point que je ne saisi pas bien.
Sur le serveur distant je constate que le fichier « install.lock » se met automatiquement dans le répertoire /home/xxxxxx/dolibarrdata (je le vois là maintenant) et pas dans /home/xxxxxx/public_html/dolibarr/ ???
Comment est-ce possible ?
Bon j’ai enfin résolu le problème (sans savoir pourquoi)
à partir de la version local, j’ai extrait un fichier sql par l’outil dolibarr (non compressé)
Via Ftp je l’ai posé sur le serveur distant dans le répertoire dolibarrdata. J’ai virer tout ce que contenait ce répertoire avant.
Puis de la version Dolibarr sur le serveur distant j’ai été voir dans l’outil de restauration le code à taper en ligne de commande
un truc du genre : "/usr/bin/mysql c1180108c_dol442 -h localhost -P 3306 -u xxxxxxxxx_dol442 -pxxxxxxxx < le-nom-du-fameux-fichier-sql.sql
Je l’ai copié en changeant avec les bons paramètres.
Puis via la console du panneau de contrôle je me suis mis dans le répertoire en tapant
cd dolibarrdata
puis vous tapez la ligne de commande « /usrbin/mysql … lefichier.sql »
et ça a marché !
Il y a donc très certainement un bug, ou du moins une incompatibilité entre des installation de phpmyadmin et la restauration en ligne de commande.
Par acquis de conscience.
J’ai tout effacer sur le serveur distant et réinstaller Dolibarr.
Mais j’ai utiliser le fichier non compresser directement .sql via phpmyadmin
Et ca marche aussi !!!
La galère, tout ça pour si peu de chose
Il doit ya voir un petit bug quelque part dans la compression ? décompression ?
Bref, voilà tout refonctionne très bien
Merci à tous
effectivement ça peut arriver sur des systèmes lents que la sauvegarde de la base de données en compressé soit tronquée !
mais ça ne vient pas de dolibarr !
il faut parfois augmenter le temps d’exécution des scripts php dans php.ini
