Christophe Le Bot

Pratique de la conception numérique

Utiliser le planificateur de tâches OVH (crontab) avec PHP

Site web OVH

De nombreuses applications web ont besoin d’exécuter périodiquement des scripts pour réaliser des tâches automatiques : purge de logs, traitement de données, lancement de sauvegardes… Quand vous avez la main sur votre propre serveur, tout va bien : vous utilisez les crontabs. Mais quand vos applications sont hébergées sur un serveur mutualisé, c’est déjà moins accessible !

Heureusement certains hébergeurs proposent des solutions alternatives efficaces. C’est le cas d’OVH avec son Planificateur de tâches. Une aide officielle existe, mais sans être inexacte, elle est un peu rapide. Du coup, j’ai passé plus de temps que prévu pour que tout fonctionne à merveille. Voilà comment s’y prendre.

Préparer son script PHP

Première étape : préparer le script de traitement PHP qui sera appelé par la tâche planifiée. Pour que le serveur appelle le bon interpréteur (dans notre cas PHP), le script a besoin de le définir en première ligne. Il faut donc ajouter cette ligne à votre script PHP :

#!/usr/local/bin/php

Elle se place en tout premier. On obtient donc ceci :

#!/usr/local/bin/php
<?
// La suite de mon script PHP...

Si vous avez besoin d’appeler d’autres scripts PHP ou de manipuler des fichiers, n’oubliez pas de travailler avec des chemins absolus. Par exemple en utilisant une variable qui définit l’endroit où est placé votre script :

$path = dirname(__FILE__);

Une fois votre fichier PHP placé sur le serveur, il faut lui ajouter le droit d’exécution (avec votre outil FTP, par exemple). Par défaut, les droits des fichiers sont calés en lecture + écriture (604), vous devez obtenir les droits en lecture + écriture + exécution (705).

Planifier la tâche

Côté serveur, c’est fini. Maintenant, il faut planifier la tâche. Pour cela, nous passons par le Manager OVH (ou Espace client, depuis peu). Le Planificateur de tâches est caché derrière Mutualisé > Hébergement > Services web.

Manager OVH - Crontab

Lors de l’ajout d’une tâche, nous devons définir ses propriétés :

  • Description de la tâche
  • Script à exécuter (chemin depuis la racine FTP de votre espace mutualisé)
  • Langage de script (avec le choix très important de la version de PHP à exécuter)
  • Logs par e-mail (permet de recevoir par e-mail un log de l’exécution du script)
  • Activation
  • Périodicité

L’interface est si simple que je n’ai rien à expliquer !

Propriétés d'une tâche planifiée OVH

Une fois validée, la tâche sera exécutée comme vous l’avez prévu. Enfin presque… Deux écarts constatés avec la théorie :

  • La mise en place de la tâche planifiée est parfois longue (j’ai dû attendre plus de 24h sur un de mes sites avant de la voir tourner).
  • Elle s’exécute rarement à l’heure prévue (la pile d’exécutions doit être longue, du coup j’atteins parfois des décalages de 20 à 30 minutes).

Suivre l’exécution de la tâche

Une fois tout ça en place, ça devrait tourner tout seul… Je suppose que vous testerez bien votre script d’abord, mais on n’est pas à l’abri de surprises à l’exécution. OVH vous offre donc les logs par e-mail ! La fonctionnalité est proposée dans le Planificateur de tâches et limitée à 10 envois (on peut la réactiver à la demande si besoin).

Vous recevrez alors un message du genre :

Vous avez demandé l'envoi des logs pour la tâche :

Numéro            : 123456
Heure de début    : 2013-10-08 02:21:02
Heure de fin      : 2013-10-08 02:21:19
Commande exécutée : /usr/local/bin/php.ORIG.4 -c /usr/local/lib/php.ini /[path]/[file].php
Code de retour    : 0
[...]

-------------------------==  Début  ==-------------------------

X-Powered-By: PHP/4.4.9
Content-type: text/html

#!/usr/local/bin/php

-------------------------==   Fin   ==-------------------------

Si tout se passe bien, rien de plus. Sinon, vous aurez une trace d’erreur. Un exemple avec un script qui tente une opération interdite sur un fichier gunzip :

-------------------------==  Début  ==-------------------------

X-Powered-By: PHP/4.4.9
Content-type: text/html

#!/usr/local/bin/php
gzip: /[path]/toto.gz already exists;        not overwritten

-------------------------==   Fin   ==-------------------------

Et la sécurité ?

J’ai trouvé quelques didacticiels sur le Planificateur de tâches OVH. Certains sont très détaillés (encore plus qu’ici), mais aucun n’aborde le sujet de la sécurité. Pourtant, la question est vraiment capitale chez OVH. En effet, votre espace web sur le serveur mutualisé a pour objectif de diffuser des contenus publiquement sur le web. C’est sa fonction première ! Donc, si vous placez un script maladroitement sur votre serveur, d’autres pourront jouer avec.

Un exemple que j’ai vu : un dossier mysql à la racine d’un site, contenant un script backup.php qui génère un fichier dump.sql au même endroit. Autant dire qu’il y a 99% de chances qu’un hacker du dimanche récupère vos données confidentielles dans l’année ! Remarquez que ce type de didacticiels n’est pas forcément innocent… Si 2000 personnes suivent l’exemple à la lettre, c’est d’autant plus facile pour des gens mal intentionnés. Lisez les didacticiels avec un peu de recul !

Parmi les règles de protection efficaces :

  • placer votre script dans un dossier racine qui n’est pas couplé à un sous-domaine (donc inaccessible par le web)
  • si votre fichier appartient à un dossier accessible sur le web, ajouter un fichier .htaccess pour interdire sa lecture et son exécution (directive Deny from all, par exemple)

11 commentaires

Auteur
charles
Date de publication
16 octobre 2013 à 21h21

Bonsoir,

merci pour cette article. Une petite question: savez vous la limite de temps d’execution dans le cas d’un script déclenché par ce moyen? 30sec? Plus?


Auteur
Christophe
Date de publication
19 octobre 2013 à 9h39

@charles

Bonne question ! Je n’ai pas vérifié. Pour le savoir, il suffit de sortir les informations de configuration de PHP avec la fonction phpinfo() et de générer un fichier texte avec la sortie.

Il faut juste vérifier qu’on l’exécute bien par une tâche planifiée (PHP CLI), pas avec une requête HTTP. La configuration n’est pas la même.


Auteur
Khalil Tabbal
Date de publication
3 avril 2014 à 19h49

Merci pour ton article.

J’ai l’habitude d’utiliser des serveurs dédiés de façon générale, difficile de faire marche arrière et prendre en main un serveur mutualisé.

Concernant le planificateur de tâches, c’est difficile de paramétrer une tâche sans pouvoir déclencher un test. Et si la mise en place peux prendre plus de 24h c’est très chaud effectivement.

En console l’exécution de mon script fonctionne par contre il est encore dans mon dossier web je vais voir pour le sécuriser en suivant tes indications.

Un gros bémol également est qu’il est impossible de passer des paramètres au script appelé.


Auteur
Samuel
Date de publication
8 mai 2014 à 16h02

Merci


Auteur
Thibault
Date de publication
2 juin 2014 à 10h45

Bonjour j’aimerais savoir si dans la tâches il faut obligatoirement mettre un .exe ?


Auteur
Christophe
Date de publication
2 juin 2014 à 21h54

@Thibault
N’importe quel fichier peut être appelé, tant qu’il a les droits d’exécution. Évidemment, il faut qu’il soit exécuté par une application qui sache le lire (PHP, Perl, Shell, Python…) ! On peut donc avoir des fichiers .php, .pl, .sh, .py… Rarement des .exe, par contre. On ne les voit pas trop sous Linux 😉


Auteur
Aymeric
Date de publication
20 juin 2014 à 11h58

Super Tutorial! Merci.

Un petite question:
Si le script appelle d’autres scripts PHP, est ce qu’il faut aussi changer les droits CHMOD des autres fichiers aussi?

Merci


Auteur
Brahim
Date de publication
24 juin 2014 à 20h09

Bonjour,

Je cherche une âme charitable pour m’aider à mettre en place un scripte de synchronisation automatique avec le catalogue de mon fournisseur, en sachant que je suis chez ovh et que j’utilise prestashop comme CMS????


Auteur
absolument
Date de publication
19 février 2015 à 11h15

Bonjour,
Précision concernant les logs par email : (ça va faire 2 semaines que je me prend le choux à ce sujet avec le support d’ovh…)

À priori, il y aurait eu une modification. Des logs ne sont envoyé qu’en cas d’erreur au lancement de la tâche.
En clair : vous ne recevrez aucun log par email si le cron s’exécute parfaitement. Vous ne recevrez aucun log si le cron génère une erreur qui n’empêche pas l’exécution de la tâche.

Je suis assez circonspect, mais c’est la seule réponse que j’ai pu obtenir du support technique. Je n’ai trouvé aucun changelog, aucune info, aucun avertissent, aucune précision dans le manager ovh, qui explicite le cas où des logs seraient effectivement renvoyées par mail.
À mes yeux, le seul truc qui s’est justifié, c’est la très mauvaise réputation du support d’ovh et de ses services…

Conclusion, si vous avez besoin de cette fonctionnalité, fabriquez la vous-même de toute pièce en recourant à la fonction mail() de php.


Auteur
Christophe
Date de publication
23 février 2015 à 21h50

@absolument
Merci pour ces précisions. Je n’ai pas mis en place de tâches cron récemment, mais j’ai reçu quelques notifications étranges d’OVH il y a quelques semaines (de soi-disant erreurs, alors que tout était bon). J’ai supposé qu’un changement avait eu lieu !


Auteur
Max
Date de publication
21 mars 2016 à 12h54

Bonjour, comme faire pour appeler une version de PHP qui n’est plus proposée par défaut dans le manager ? J’essaie de lancer un cron avec php 5.3 mais le log affiche No such file or directory comme s’il ne trouvait pas php (quand je ne mets pas de USR et compagnie au début il me met Exec format error)… 🙁


* Informations obligatoires