Comment sécuriser une tâche CRON ?

[lefabdu51]

le soucis que j ai en te lisant, c est que tu pense que la CLI joomla ne sert à rien..
Alors que justement elle as été crée pour les besoins comme celui de lendrevi.

Et la premiere apparition de la CLI date de Joomla 2.5 (ouh la la préhistoire )...

Et ca ca me gènes, car c est la base de lancement pour les scripts J4 qui vont utiliser le com_api. Et la tu va pouvoir manager Joomla comme on peut manager wordpress via la cli.
La cli n'est pas assez évoluée et c est un gros reproche fait à joomla.

Avec J4, ta manière de faire risque de devenir obsolète.

Vu qu il va y avoir des endpoints qui vont te donner accès a toute l architecture d'un site. Tu pourras faire des mises à jour de contenu sans passer par le site par exemple.

Quand au scripts qui sont dedans, juste un exemple avec le script finder_indexer. Ce script permet via une tache cron d'indexer le contenu d'un site sans avoir a t en occuper et sans aucune intervention, ce qui soulages l'admin d'une tâche routinière et evites de demander trop de ressources au serveur.
C'est le principe des taches CRON.. tu les crées, tu les teste, tu les met en place et enfin tu les oublies et elles font leur taf sans jamais s arrêter.
Sous Windows, CRON existe.C est ce que l'on appelles le planificateur de tâches

PS: SSHn' as rien de commun avec telnet, surtout depuis la version 2. C'est un protocole et aussi une commande à part entière qui n'a rien à voir avec Telnet. Telnet over ssh est une ancienne manière de faire qui date des débuts de SSH. SSH embarques un client sftp (secure ftp) pour le transfert des fichiers binaires.

SSH a été crée pour remplacer telnet... car telnet n'offre aucune sécurité et est un protocole texte. Essaye de récupérer un binaire genre une archive zip d'une sauvegarde via telnet... Si tu y arrives, tu est fort. Tu est obligé de passer par ftp si tu utilise telnet.

Personnelement, j utilise telnet comme un outil de test pour les possibilités de connexion qu il offre sur differents ports.Je m en sert pour tester la connexion, les ehlo et les possibilités d envoi de mail de mes serveurs smtp (ports 587 et 465) et qu'ils forcent l autentification avant la connexion pour éviter d'avoir des relais ouvert (et le spam qui va avec....).

[roland_d_alsace]

le soucis que j ai en te lisant, c est que tu pense que la CLI joomla ne sert à rien..
Alors que justement elle as été crée pour les besoins comme celui de lendrevi.

Et la premiere apparition de la CLI date de Joomla 2.5 (ouh la la préhistoire )...

pour toi peut-être, pas pour moi, moi j'ai connu les matrices mémoire à tores de ferrite, à l'époque où l'on programmais au bit près.
J'ai aussi percé des trous dans des bandes et des cartes pour programmer (faillait pas laisser tomber le carton avant de le faire avaler dans le lecteur...)...

Et ca ca me gènes, car c est la base de lancement pour les scripts J4 qui vont utiliser le com_api. Et la tu va pouvoir manager Joomla comme on peut manager wordpress via la cli.

Je pense que la partie "cli" qui est prévue pour être utilisée par PHP-Cli donc via commandes shell ou directement depuis la console ne peut effectivement servir que pour les webmasters les plus aguerris, ce qui n'est pas forcement la "clientèle de base" de Joomla.

Moi je l'utilise, quand j'ai des truc particulier à faire, mais de façon vraiment très occasionnelle (scripts de reprise d'autres cms vers Joomla par exemple).
L’énorme avantage, c'est que dans la config de php-cli on n'a pas besoin d'avoir les même niveau de sécurité qu'avec Fast-CGI, Mod-PHP ou PHP-FPM, vu qu'on est chez soi.
On peu donc lancer des procédures beaucoup plus lourdes et gourmandes.

Avec ma méthode je suis obligé de fractionner les traitements pour ne pas dépasser les memory-limit et les max-time des appli web.

Peut-être qu'effectivement php-cli n'est pas suffisamment utilisé, mais à priori actuellement ce n'est pas vraiment fait pour cela.
Il faudrait être dans les secrets de la coreteam pour en savoir plus.
Mais moi je n'y suis pas favorable, car je pense que cela rend la mise ne œuvre plus difficile pour quelqu'un qui n'a pas les connaissances.

Par contre pour donner de l'eau à ton moulin, en regardant de plus près, j'ai constaté que Nicholas le proposait ses applications (akeeba pro).
Mais bon, malgré toute le sympathie que j'ai pour Nicholas, il n'est un secret pour personne qu'il n'a pas toujours été en accord total avec le coreteam de Joomla.

Concernant com_api, du peu que j'ai déjà découvert de Joomla 4, com_api est le composant de mise en oeuvre de la couche webservices REST qui manque cruellement à Joomla et que perso j’attends depuis longtemps.
Manquement qui m'a obligé à développer mes propres outils pour échanger avec des applications Windows ou Android. (J'avais questionné le coreteam lors des derniers JDays sur le sujet).

Mais dans le cadre de cet échange, je ne vois pas trop le rapport que tu fais entre REST qui est bien du service Web et Cli qui n'est pas "web" du tout.

La cli n'est pas assez évoluée et c est un gros reproche fait à joomla.

Moi je n'ai jamais entendu ce type de remarque, mais je suis dans la communauté que depuis J1.5...
Et je pense qu'au contraire si on peu se passer de la ligne de commande, c'est un plus et pas un manquement...

De plus le framework est séparé du CMS depuis assez longtemps.
Rien n'empêche de faire de scripts hors CMS.
Alors ce reproche ne me parait vraiment pas fondé (ne viendrait-il pas de la communauté WP par hasard ?).
Certainement que WP a besoin de plus de maintenance et de correctifs régulier pour fonctionner correctement.

Combien de sites Joomla ne fonctionnent pas correctement sans jamais lancer les scripts en /cli (même des gros) ?

Que dans /cli il y ait des script de maintenance du framework, cela me parait normal, mais pas des scripts dépendants d'extensions tierces.

Avec J4, ta manière de faire risque de devenir obsolète.

C'est ton avis, mais de loin pas le mien, car nous ne répondons pas au même besoin de facilité de mise en œuvre.

Ce que je pense tu n'arrives pas à comprendre, pour moi, les tâches CRON de mes composants dépendent de mes composants et sont totalement intégrées à ces composants.

Dans la logique MVC de Joomla c'est le contrôleur qui reparti les tâches.

Rien ne l'oblige à instancier une vue, ni donc à faire de l'affichage.

Quand il y a des mises à jour dans la DB, il le fait.
Pour preuve, les boutons du ruban lancent une tâche via la variable task.
Toutes les vue du framework utilisent cette technique, je n'ai rien inventé.

C'est le contrôleur qui décide ensuite de faire d’instancier la vue et de faire un affichage, ou alors par le biais d'une redirection vers l'url de la vue list ou item.

Si le contrôleur ne le fait pas les plugins de contenu (les onContent....) que tu évoques (à tord je pense, ou alors je n'ai pas compris) dans une précédente réponse ne sont donc pas appelés.

C'est bien le contrôleur le chef et c'est bien au développeur de lui dire ce qu'il faut faire (tâches avec affichage ou pas).

Joomla CMS gère donc très bien et tout à fait les tâches qui ne font que du traitement et pas d'affichage dans le corps des composants (pas besoin donc de placer dans un dossier cli).

De surcroit, rien n’empêche de lancer un contrôleur et une tâche donné d'un composant particulier par un shell ou une commande php en mode cli.
Pour cette raison aussi je ne vois pas la raison de placer le script dans le dossier cli de joomla.

Avec J4, ta manière de faire risque de devenir obsolète.

Il n'y a pas que moi que moi qui fait ainsi, et j'ai déjà donné le nom de nombreux développeurs d’extensions font ainsi.
Depuis ma réponse de hier j'ai regardé dans mes panels d'admin et j'en ai encore trouvée encre 2 autres qui font aussi référence dans le mode Joomla (Thomas d' AdsManager, HWDmediashare,...)

Comme dit si l'on veut distribuer des extensions à la communauté et les rendre indépendantes du type d’hébergement et accessibles a tout webmaster lambda, il n'y a pas d'autre formule pour faire du cron que par le biais d'un url.

Les services disponibles que j'ai évoqué dans une réponse précédente sont là pour cela.
Je ne pense pas qu'il y en aurait autant (et payant), s'il ne servaient à rien.

Vu qu il va y avoir des endpoints qui vont te donner accès a toute l architecture d'un site. Tu pourras faire des mises à jour de contenu sans passer par le site par exemple.

Là tu as des infos que je ne possède pas.
Ni aux Jdays on en a parlé, ni dans sur les groupes Google Dev de Joomla.
Cela m’intéresse et je pense que je ne suis pas le seul ici.
Peux-tu nous donner tes sources ?

Mais des mises à jour de contenu en mode cli, sans passer par un webservice, j'ai un peu de mal à comprendre l’intérêt...

Quand au scripts qui sont dedans, juste un exemple avec le script finder_indexer. Ce script permet via une tache cron d'indexer le contenu d'un site sans avoir a t en occuper et sans aucune intervention, ce qui soulages l'admin d'une tâche routinière et evites de demander trop de ressources au serveur.

Oui c'est bien fait pour cela, entièrement d'accord mais pour la maintenance de Joomla (framework et CMS) et que de Joomla.

C'est le principe des taches CRON.. tu les crées, tu les teste, tu les met en place et enfin tu les oublies et elles font leur taf sans jamais s arrêter.
Sous Windows, CRON existe.C est ce que l'on appelles le planificateur de tâches

Off course, c'est la base sinon on ne le ferait pas...
...sauf qu'un jour cela ne passe plus, où quelqu'un à fait quelque chose qui nécessite que tu doives lancer à une période pas prévue.

Je suis surpris que cela ne soit jamais arrivé à tes clients, où alors ils n'ont que peu de contraintes ou font peut de mises à jour sur leurs serveurs centraux.

Au niveau de l'accès console, je pensais à tty utilisé par telnet et ssh, merci de m'avoir repris.
Cela fait tellement longtemps que je ne suis pas rentré dans ce type de code.

Bon dev.

[Visiteur]

Bonjour,

Je pense avoir suivi correctement les consignes de lefabdu51, en utilisant le dossier "cli" dans lequel j'ai placé les 2 scripts php relatifs à mes 2 tâches CRON : PlanningPlusEtMoinsUnjour.php et MailingDeNuit.php.
Ces 2 tâches ne fonctionnement pas : je reçois chaque matin les messages d'erreurs :

---> wget: URL manquante

Leur structure est :

---> wget -q -O "https://www.mon_site.com/cli/PlanningPlusEtMoinsUnjour.php"
et
---> wget -q -O "https://www.mon_site.com/cli/MailingDeNuit.php"

J'ai tenté l'écriture sans les guillemets, mais le résultat est tout aussi mauvais.
Et j'ai bien lu les conseils d'écriture relatifs à la commande "wget" ... mais sans succès.

Pourriez-vous me dire ce qui ne va pas dans ces 2 commandes ?
Cordialement, et merci pour votre aide.

[pmleconte]

Bonjour,

Je m'immisce discrètement : il s'agit d'un lien direct sur votre hébergement tel que vous le voyez par FTP (donc, sans le lien vers votre site, puisque CRON s'exécute sur votre site).

Essayez d'entrer wget -q -O /cli/PlanningPlusEtMoinsUnjour.php

Pascal

[Visiteur]

Bonjour,

Je m'immisce discrètement : il s'agit d'un lien direct sur votre hébergement tel que vous le voyez par FTP (donc, sans le lien vers votre site, puisque CRON s'exécute sur votre site).

Essayez d'entrer wget -q -O /cli/PlanningPlusEtMoinsUnjour.php

Pascal

Bonjour,

Merci pascal.
Attention : je suis chez O2switch avec plusieurs sites différents à la racine de mon espace client, et placés dans dans des dossiers portant chacun sur un site donné. Et dans la déclaration des tâches CRON du Cpanel, toutes les tâches portant sut tout site de mon espace se retrouvent dans un seul dossier CRON. Moralité : si chaque tâche ne précisait pas clairement à quel site elle se rattache, il y aurait un problème !

Je vais tenter l'écriture :

--> wget -q -O nom du site/cli/PlanningPlusEtMoinsUnjour.php

[roland_d_alsace]

Je ne suis pas chez O2switch, mais si tu veux lancer php en mode cli, je ne vois pas pourquoi tu utilises wget.

cli = command line interface, donc tu demandes l’exécution d'un script php sur ton serveur depuis ton serveur, comme tu lances filezilla sur ton pc par exemple, ou comme tu lances un script .bat sous windows.

Il faut donc lancer php et lui dire d’exécuter le bon fichier de script PlanningPlusEtMoinsUnjour.php en lui donnant son chemin sur le disque dur du serveur hébergeant ton site.

Ensuite c'est bien à ton script de savoir ce qu'il doit faire (donc quel site, quelle base de données, quels chemins utiliser).

regarde la doc de o2switch : https://faq.o2switch.fr/hebergement-...el/taches-cron

Tu peux essayer ceci :

php -q ~/public_html/cli/PlanningPlusEtMoinsUnjour.php
ou
php /home/..../cli/PlanningPlusEtMoinsUnjour.php <--- ici il faut mettre le chemin du script php en url absolue depuis la racine du serveur

Chemin depuis la racine du serveur que tu trouveras dans les info système onglet paramètres php par exemple, sinon par un petit script php à la racine du site avec un echo __dir__;

Ou que tu trouveras aussi dans ton panel à priori d'après la doc o2switch.

Dans la doc de o2switch tu as 3 options.

La 1ere option :
wget -O /dev/null 'http://mon-site.fr//cli/PlanningPlusEtMoinsUnjour.php?...&param2=valeur' est celle que moi j'utilise (sans placer les script en /cli), et que je trouve plus facile à mettre en oeuvre, et avec les limites de php version "web", mais tu l'auras compris si tu as eu la patience de tout lire ci dessus (de plus elle permet de passer des paramètres plus facilement).

Le -O /dev/null indique juste que la sortie éventuelle est redirigée vers rien (poubelle)
Attention à bien encadrer l'url avec des quotes.

La 2ème option étant celle que t'a indiqué lefabdu51, il faut donc lancer php au préalable et lui dire d’exécuter ton fichier comme je l'ai déjà expliqué ci-dessus.

La 3ème ne te concerne pas, c'est pour lancer un script de lignes de commande shell ou bash (fichier .sh).
Mais la logique est la même que la 1ere, sauf que l’exécuteur de commande (sh) qui va exécuter le fichier .sh sera trouvé automatiquement alors que linux est rarement configuré pour lancer automatiquement php sur la base d'un fichier en terminaison .php.

[lefabdu51]

normal, tu as mis des chemins relatifs..... et non des chemins absolus.

chez os2witch, https://faq.o2switch.fr/offres-heber...nger-hebergeur
si j en crois ce qui est écrit ici ton chemin doit être le suivant:
/home/loginCpanel/public_html/cli/monscript.php
et ta commande:
php /home/loginCpanel/public_html/cli/monscript.php avec logincpanel = le login utilisé pour acceder au cpanel.

[roland_d_alsace]

normal, tu as mis des chemins relatifs..... et non des chemins absolus.

chez os2witch, https://faq.o2switch.fr/offres-heber...nger-hebergeur
si j en crois ce qui est écrit ici ton chemin doit être le suivant:
/home/loginCpanel/public_html/cli/monscript.php
et ta commande:
php /home/loginCpanel/public_html/cli/monscript.php avec logincpanel = le login utilisé pour acceder au cpanel.

A priori d'après la doc de o2switch le tilte fonctionnerait :

php -q ~/public_html/cli/PlanningPlusEtMoinsUnjour.php

[lefabdu51]

Donc c est a tester....

[Visiteur]

Je vais tenter cette commande la nuit prochaine ! Et je vous tiens au courant des résultats.

[lefabdu51]

tu peux deja tester le chemin avec un fichier php vide. Si tu as une erreur, c est que ce n est pas le bon. si tu n'as aucun retour d erreur c est qu il est ok.

[roland_d_alsace]

Je ne comprends pas qu'il n'y a pas un bouton dans le panel pour lancer manuellement la commande !

Dans ces conditions pourquoi ne pas programmer l’exécution dans le panel provisoirement à une heure plus proche plutôt que d’attendre à chaque fois et de perdre 1 jour.

Sinon comme te le propose lefabdu51 lance un autre script plus simple, un truc qui écrit dans les log de Joomla ou qui t'envoie un mail et programme le pour qu'il s’exécute de suite, car là tu buttes sur un truc qui reporte à chaque fois la réponse de 24H.

[lefabdu51]

j ai fait une erreur dans le chemin: /home/loginCpanel/public_html/cli/monscript.php devrais être /home/loginCpanel/public_html/[sous repertoire ou est stocké mon site]/cli/monscript.php.

je fait juste cette réflexion car tu as ecrit avoir plusieurs sites sur cet hébergement, chacun dans un répertoire dédié.et le sous répertoire doit se trouver après public_html....

[Visiteur]

j ai fait une erreur dans le chemin: /home/loginCpanel/public_html/cli/monscript.php devrais être /home/loginCpanel/public_html/[sous repertoire ou est stocké mon site]/cli/monscript.php.

je fait juste cette réflexion car tu as ecrit avoir plusieurs sites sur cet hébergement, chacun dans un répertoire dédié.et le sous répertoire doit se trouver après public_html....

Bonjour,
Ta dernière réflexion est exacte, compte-tenu de la présence de plusieurs sites dans mon espace client chez O2switch.
Mais comme il s'agit de sites totalement différents (cf. noms d'exécution dans le navigateur), chaque site est logé à la racine de mon hébergement dans un dossier portant le nom de lancement du site.
ex: site "mon-site1.com" aurait un dossier nommé "mon-site1.com" contenant tous les dossiers de ce site ... et notamment le dossier "cli".
Pour en revenir à la tâche cron, je l'écris donc :

--> php -q ~/nom du dossier du site/cli/nom du fichier php à exécuter logé dans le dossier "cli"

Je viens cette nuit de faire un test de fonctionnement.
Résultats :
1. je n'ai plus d'erreur envoyée dans ma boîte mail (donc la commande serait désormais correcte),
2. mais aucun résultat tangible d'exécution de mon script php (aucune màj dans ma table de BDD). Exactement comme si mon script php était VIDE !

J'imagine avoir commis un bug dans l'écriture. Voici le script tel qu'écrit dans mon dossier cli :

<?php
// script CRON
// nom du script : PlanningPlusEtMoinsUnjour.php
// Initialize Joomla framework
const _JEXEC = 1;

// Load system defines
if (file_exists(dirname(__DIR__) . '/defines.php'))
{
require_once dirname(__DIR__) . '/defines.php';
}

if (!defined('_JDEFINES'))
{
define('JPATH_BASE', dirname(__DIR__));
require_once JPATH_BASE . '/includes/defines.php';
}

// Get the framework.
require_once JPATH_LIBRARIES . '/import.legacy.php';

// Bootstrap the CMS libraries.
require_once JPATH_LIBRARIES . '/cms.php';

class PlanningPlusEtMoinsUnjour extends JApplicationCli
{

// =================== MON SCRIPT en PHP ============================

public function doExecute()
{
$cache = JFactory::getCache();
$cache->gc();
}
}

JApplicationCli::getInstance('PlanningPlusEtMoinsUnjour')->execute();
?>

IMPORTANT
N'y aurait-il pas une erreur dans la commande de lancement (cf: "JApplicationCli:: ... etc, tout en bas du script) ? La fonction est nommée "doExecute()", mais son lancement est fait par "execute()" !

[roland_d_alsace]

Hello.

Ton code parait correct à première vue.

Ajoute ceci à ton script :

// Configure error reporting to maximum for CLI output.
error_reporting(E_ALL);
ini_set('display_errors', 1);

après le

require_once JPATH_LIBRARIES . '/cms.php';

Et lance le manuellement dans ton navigateur à partir de l'url correspondante.

Il te faudras probablement désactiver ton SEO et .htaccess provisoirement (en le renommant), selon le règles de sécurité que tu y a placées (type aesecure par exemple) pour pouvoir exécuter les scripts qui sont en /cli

Ceci pour voir si tu as une erreur.

Mais je croyais que tu l'avais déjà testé.