Encore un sujet sauvegarde auto via tache planifiée (Debian 11)

Utiliser mon Dolibarr Autres modules natifs
, ,
1

Hello et meilleurs vœux à tous,

Comme beaucoup de gens je galère pour la mise en place de la sauvegarde automatique de base avec les travaux planifiés. J’ai lu plein de sujets différents y compris sur le wiki anglais mais décidément ça ne veut pas chez moi. En fait j’ai jamais réussi du coup j’ai toujours reporté ce paramétrage (comme celui de l’antivirus d’ailleurs, mais je vais faire un sujet à part).

Je suis sous debian 11 et dernier dolibarr en date (18.0.4), php8.1, j’ai créé mon entrée dans la crontab que voici :

*/5 * * * * /usr/bin/php8.1 /var/www/mondolibarr/scripts/cron/cron_run_jobs.php xxhashxx xxutilisateurxx > /var/www/mondolibarr/documents/cron_run_jobs.php.log

J’ai vérifié, et cron est bien activé :

cron.service - Regular background program processing daemon
     Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2024-01-04 16:10:33 CET; 1h 32min ago

Bref, cron est activé, et si la syntaxe est bonne pour mon cronjob je veux bien une petite piste pour savoir comment fonctionnent les taches planifiées de sauvegarde.

Je sais pas trop si je dois garder les paramètres de base du module taches planifiées concernant la methode « dumpDatabase » ou bien s’il est préférable de passer par la « commande terminal » dans le même module.

Je sèche là ! :grin:

2

Bonjour et meilleurs voeux à tous.

La commande crontab comporte au moins une erreur : il manque l’id du job défini dans les taches planifiées dans dolibarr.

Donc en 1 définir une tache planifiée puis en 2 définir un crontab du style sur debian : /var/www/… chemin vers dolibarr…/scripts/cron/cron_run_jobs.php password user id

Avec ces éléments tout fonctionne.

Francis

3

Hello!

Merci @Le_Reparateur, ça m’a bien aidé, effectivement j’ai zappé l’ID!

Bon… Pa contre… ça a fonctionné, une fois! :crazy_face:

Je suis sérieux, j’ai juste rajouté l’ID du cronjob que j’avais effectivement zappé. Juste ça et c’était bon.

Ensuite je me suis intéressé aux configs de sécurité et là bim… et à partir de je ne sais quelle manip : erreur mysql injection…

Access refused to xxxipxxx by SQL or Script injection protection in main.inc.php - GETPOST type=1 paramkey=0 paramvalue=id=2&action=execute&securitykey=xxxxx ................

j’ai pas réussi à trouver la solution et du coup je me suis reparti sur un dolibarr de test, install propre et

sudo chmod -R 755 /var/www/mondolibarrdetest
sudo chown -R www-data:www-data /var/www/mondolibarrdetest

A part ça j’en suis juste a avoir rempli les paramètres de l’entreprise et activé le module travaux planifiés, vraiment rien de plus.

Sous cette nouvelle install je bloque sur « Failed to write in directory » pourtant:

  • Je suis en 775 sur documents, ce qui me semble être la valeur recommandée.
  • J’ai tenté 775 sur le dossier documents/backup…
  • je suis en 755 sur /var/www/mon dolibarr

Du coup, je me pose la question: quel dossier?

autrement j’ai toujours suivi la recommandation suivante :

find /var/www/my-dolibarr/htdocs/ \! -perm 555 -type d -exec chmod 0555 {} \;
find /var/www/my-dolibarr/htdocs/ \! -perm 444 -type f -exec chmod 0444 {} \;

vue ici : V15 bonne pratique - Permissions fichiers/dossiers (chmod) - #6 par pascal_z

La bonne nouvelle c’est que ça a réellement fonctionné…
La mauvaise c’est que ça a fonctionné pour deux sauvegardes à 5 min d’intervalle seulement! …

Et je sèche encore! :grin: (mais j’apprends plein de choses, merci pour ça!)

4

Hello,

Je récapitule, autant pour contextualiser une éventuelle aide que pour me faire une référence à l’avenir.

J’ai tout repris à zéro, nouvelle base, et envoi de l’archive zip sur le serveur, dézippée dans /var/www/

sudo cp -r dolibarr-18.0.4 mondolibarr
sudo chmod -R 755 /var/www/mondolibarr
sudo chown -R www-data:www-data /var/www/mondolibarr
sudo mkdir documents
sudo chmod 777 documents
sudo htdocs/conf/conf.php
sudo chmod 666 htdocs/conf/conf.php

Puis install, paramétrage des infos de base, puis activation du module tâches planifiées en générant la clé qui va bien. Aucun problème jusque là.

Dans les tâches planifiées la sauvegarde est avec id = 2. Je ne change rien sauf le execute job each, avec la valeur 5 minutes. J’enregistre, j’active la tâche et je passe au cronjob :

crontab -e

J’indique :

*/5 * * * * /usr/bin/php8.1 /var/www/mondolibarr/scripts/cron/cron_run_jobs.php xxxxxxxxCLExxxxxxxxx xxxxUSERxxxx xxxxIDxxxx > /var/www/mondolibarr/documents/cron_run_jobs.php.log

Le fichier « cron_run_jobs.php.log » est bien créé sous :

/var/www/mondolibarr/documents/

Il m’indique :

**** cron_run_jobs.php (18.0.4) pid=93623 - userlogin=xxxxUSERxxxx - 2024-01-06T11:40:01Z - capable *****
cron_run_jobs.php cronjobid: 2 priority=90 entity=0 label=MakeLocalDatabaseDumpShort - qualified - Error cronjobid: 2 cronjob->run_job: Failed to write in directory
At least one job failed. Go on menu Home-Setup-Admin tools to see result for each job.
You can also enable module Log if not yet enabled, run again and take a look into dolibarr.log file
 - run_jobs KO result = -1 - reprogrammed

Voilà, je ne peux faire plus factuel. Un grand merci à tous ceux qui sauront me dire quel dossier n’a pas les bons droits en écriture et c’est pas documents actuellement à chmod 777 pour le test. (et qui contient bien le fichier « cron_run_jobs.php.log » avec le log ci-dessus.

5

:scream: :scream: :scream:

Cette commande va rendre executable tous les fichiers contenus dans /var/www/dolibarr
C’est le truc à NE PAS FAIRE.

6

C’est la tâche cron qui doit être executée avec le user correct, pas les droits des répertoires qui doivent être modifiés.

https://man7.org/linux/man-pages/man1/runuser.1.html

7

Hello @hop,

Merci beaucoup pour ton implication sur le forum, j’ai bien conscience que le 755 n’a pas vocation à rester tel quel, en tout cas c’est ce qu’indique la doc pour l’étape ou je suis, je cite :

Gestion des droits

Modifiez les permissions et propriétaires du répertoire ‹ dolibarr › pour être sur que tous les fichiers soient en lecture pour l’utilisateur sur lequel tourne le serveur (on supposera qu’il s’agit de l’utilisateur ‹ www-data › pour debian ou ubuntu, ‹ apache › pour Redhat, Mandriva, Mageia, Fedora)

$ chmod -R 755 /var/www/dolibarr
$ chown -R www-data:www-data /var/www/dolibarr

Source : Installation - Mise à jour - Dolibarr ERP CRM Wiki

Comme je dis plus haut, je sécurise toujours mon install par :

C’est volontairement que je détaille les étapes de base, suivant une install toute neuve, du coup je réponds un peu à chaud, pour bien préciser que oui oui oui, je suis bien conscient que 755 n’est pas bon du tout.

Je reponds plus en détail dans deux petites heures max.

8

Si on fait un chown -R www-data: /var/www/dolibarr tous les fichiers vont appartenir à l’utilisateur sous lequel tourne le serveur. Le 55 du chmod -R 755 n’a alors aucun intérêt :roll_eyes:

11

Voilà! C’est bon! En espérant que cela serve à d’autres!

En se penchant un peu sur l’usage de crontab sur debian (et n’importe quel autre système linux) par une petite recherche, il ne faut pas oublier qu’en faisant un sudo chown -R www-data: on change de propriétaire.

J’étais bêtement à m’acharner sur un crontab -e

mais la crontab doit également être celle du nouveau propriétaire www-data donc :

sudo crontab -u www-data -e

Et tout fonctionne!

Merci @Le_Reparateur pour avoir pointé un oubli!

Merci @hop pour les pistes en m’ayant laissé chercher par moi-même, c’est comme ça qu’on apprends!