Pour infos, j'ai deux scripts en Bourne Shell, qui sont déclenchés
habituellement automatiquement par cron, le premier à 16h45 tous les
jours, le deuxième à 17h00, 17h30, et 18h00 tous les jours. Si mes
souvenirs sont bons, les heures sont théoriquement correctes.
Hier, aucune déclenchement par cron.
J'ai eu le même problème lors d'un transfert précédent de mes données
vers un autre serveur, il y a de celà quelques mois.
Je suis en hébergement mutualisé 240Plan, nom de domaine chez Gandi.
D'autres personnes ont-elles eu des nouvelles de migrations de
serveurs 240Plan récemment ?
Merci beaucoup de vos réponses.
Je vous prie de m'excuser d'être un peu hors charte, mais quand je
veux m'adresser au forum d'OVH, je n'obtiens aucune réponse
habituellement. Miracle si mon message passe.
Bien à vous.
Jean-François Ortolo
--
Mon site donne des Statistiques
et des Historiques Graphiques gratuits
sur les Courses de Chevaux du PMU.
http://www.ortolojf-courses.com
Il faudra prendre soin de vérifier que l'horloge du serveur web en question est correctement synchronisée...
Finalement... Il sera possible pour moi d'utiliser les services de www.webcron.org , à deux conditions:
- Si mon hébergeur OVH, accepte qu'un script PHP puisse lancer un script Shell en background, avec l'instruction system();
En effet, mon deuxième script Shell, dure un peu moins de deux minutes ce qui excède la durée maximale d'exécution d'un script PHP en mode CGI, qui est de 30 secondes. Il est donc nécéssaire que ce script Shell soit déclenchés en background ( & à la fin de la ligne de commande ), pour que le script PHP qui le lance, se termine immédiatement.
- Il me suffira, pour la sécurité, de mettre ce script dans une arborescence de répertoires ayant des noms compliqués équivalents à des mots de passe, et de lui donner un nom également compliqué. Il sera donc impossible à qui que ce soit de deviner les noms des sous-répertoires et du script, car les sous-répertoires contiendront chacun un fichier index.html , ce qui interdira la visualisation du contenu du sous-répertoire.
Pas besoin donc, d'aucune autre mesure de protection.
Je vais de ce pas m'informer auprès de OVH de la faisabilité de mon projet.
Bien à vous.
Jean-François Ortolo
-- Mon site donne des Statistiques et des Historiques Graphiques gratuits sur les Courses de Chevaux du PMU. http://www.ortolojf-courses.com
Patrick Mevzek wrote:
Il faudra prendre soin de vérifier que l'horloge du serveur web en
question est correctement synchronisée...
Finalement...
Il sera possible pour moi d'utiliser les services de www.webcron.org
, à deux conditions:
- Si mon hébergeur OVH, accepte qu'un script PHP puisse lancer un
script Shell en background, avec l'instruction system();
En effet, mon deuxième script Shell, dure un peu moins de deux
minutes ce qui excède la durée maximale d'exécution d'un script PHP en
mode CGI, qui est de 30 secondes. Il est donc nécéssaire que ce script
Shell soit déclenchés en background ( & à la fin de la ligne de commande
), pour que le script PHP qui le lance, se termine immédiatement.
- Il me suffira, pour la sécurité, de mettre ce script dans une
arborescence de répertoires ayant des noms compliqués équivalents à des
mots de passe, et de lui donner un nom également compliqué. Il sera donc
impossible à qui que ce soit de deviner les noms des sous-répertoires et
du script, car les sous-répertoires contiendront chacun un fichier
index.html , ce qui interdira la visualisation du contenu du
sous-répertoire.
Pas besoin donc, d'aucune autre mesure de protection.
Je vais de ce pas m'informer auprès de OVH de la faisabilité de mon
projet.
Bien à vous.
Jean-François Ortolo
--
Mon site donne des Statistiques
et des Historiques Graphiques gratuits
sur les Courses de Chevaux du PMU.
http://www.ortolojf-courses.com
Il faudra prendre soin de vérifier que l'horloge du serveur web en question est correctement synchronisée...
Finalement... Il sera possible pour moi d'utiliser les services de www.webcron.org , à deux conditions:
- Si mon hébergeur OVH, accepte qu'un script PHP puisse lancer un script Shell en background, avec l'instruction system();
En effet, mon deuxième script Shell, dure un peu moins de deux minutes ce qui excède la durée maximale d'exécution d'un script PHP en mode CGI, qui est de 30 secondes. Il est donc nécéssaire que ce script Shell soit déclenchés en background ( & à la fin de la ligne de commande ), pour que le script PHP qui le lance, se termine immédiatement.
- Il me suffira, pour la sécurité, de mettre ce script dans une arborescence de répertoires ayant des noms compliqués équivalents à des mots de passe, et de lui donner un nom également compliqué. Il sera donc impossible à qui que ce soit de deviner les noms des sous-répertoires et du script, car les sous-répertoires contiendront chacun un fichier index.html , ce qui interdira la visualisation du contenu du sous-répertoire.
Pas besoin donc, d'aucune autre mesure de protection.
Je vais de ce pas m'informer auprès de OVH de la faisabilité de mon projet.
Bien à vous.
Jean-François Ortolo
-- Mon site donne des Statistiques et des Historiques Graphiques gratuits sur les Courses de Chevaux du PMU. http://www.ortolojf-courses.com
Christophe Baegert
Florent Clairambault wrote:
Justement non, PHP cause rarement des dégâts sur le serveur, il suffit qu'on le mette bien à jour et c'est sans soucis.
Il suffit il suffit, c'est vite dit. Mettre à jour php sur un mutualisé sans risquer de casser les scripts de tous les clients, c'est pas "il suffit"...
Non, quand reste à la même version majeure mais mise à jour, il n'y a pas de problème en général (on peut jouer sur le "en général", mais bon, c'est 99% des cas).
ça dépend de la longueur du phpinfo... s'il est très long, l'upgrade de chaque version mineure pose pas mal de problème (d'installation surtout).
Au niveau de l'utilisateur, ça pose moins de problèmes, mais infiniment plus qu'un upgrade de perl...
Florent Clairambault wrote:
Justement non, PHP cause rarement des dégâts sur le serveur, il suffit
qu'on le mette bien à jour et c'est sans soucis.
Il suffit il suffit, c'est vite dit. Mettre à jour php sur un mutualisé
sans risquer de casser les scripts de tous les clients, c'est pas "il
suffit"...
Non, quand reste à la même version majeure mais mise à jour, il n'y a pas
de problème en général (on peut jouer sur le "en général", mais bon, c'est
99% des cas).
ça dépend de la longueur du phpinfo... s'il est très long, l'upgrade de
chaque version mineure pose pas mal de problème (d'installation surtout).
Au niveau de l'utilisateur, ça pose moins de problèmes, mais infiniment plus
qu'un upgrade de perl...
Justement non, PHP cause rarement des dégâts sur le serveur, il suffit qu'on le mette bien à jour et c'est sans soucis.
Il suffit il suffit, c'est vite dit. Mettre à jour php sur un mutualisé sans risquer de casser les scripts de tous les clients, c'est pas "il suffit"...
Non, quand reste à la même version majeure mais mise à jour, il n'y a pas de problème en général (on peut jouer sur le "en général", mais bon, c'est 99% des cas).
ça dépend de la longueur du phpinfo... s'il est très long, l'upgrade de chaque version mineure pose pas mal de problème (d'installation surtout).
Au niveau de l'utilisateur, ça pose moins de problèmes, mais infiniment plus qu'un upgrade de perl...
oles
Jean-François Ortolo a écrit:
Bonjour,
http://travaux.ovh.com/?doÞtails&id94
Octave
-- Simplifiez la gestion de votre hebergement et telechargez MoM: http://www.ovh.com/fr/download pour Windows, Mac ou Linux. C'est gratuit !
Jean-François Ortolo <ortolo.jeanfrancois_no.reply@free.fr> a écrit:
Bonjour,
http://travaux.ovh.com/?doÞtails&id94
Octave
--
Simplifiez la gestion de votre hebergement et
telechargez MoM: http://www.ovh.com/fr/download
pour Windows, Mac ou Linux. C'est gratuit !
