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
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.
www.webcron.org www.crontab.fr
si les service de l'hebergeur fonctionnent mal, allez les prendre ailleurs .. D'autant que c'est gratuit :)
Evidemment.
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.
www.webcron.org
www.crontab.fr
si les service de l'hebergeur fonctionnent mal, allez les prendre
ailleurs .. D'autant que c'est gratuit :)
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.
www.webcron.org www.crontab.fr
si les service de l'hebergeur fonctionnent mal, allez les prendre ailleurs .. D'autant que c'est gratuit :)
Jean-François Ortolo
Spyou wrote:
Evidemment.
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.
www.webcron.org www.crontab.fr
si les service de l'hebergeur fonctionnent mal, allez les prendre ailleurs .. D'autant que c'est gratuit :)
Bonjour Monsieur
Le seul problème... C'est que les programmes que je veux déclencher, sont des scripts en Bourne Shell, et non pas des scripts PHP.
Pour déclencher un script en Shell, il faut déjà être connecté sur un compte Shell. Or, en mutualisé 240Plan sous OVH, il n'y a pas d'accès Shell. De toute manières, vous me voyez donner le login/password d'un accès Shell sur un site web ? :)
Ces scripts Shell sont dans le répertoire racine, au dessus du sous-répertoire www/
A la rigueur, je pourrais positionner des scripts en PHP sous mon arborescence www/ , pour qu'ils déclenchent chacun son script Shell correspondant.
Oui, mais... Ces scripts en PHP seraient déclenchables par n'importe qui ayant la connaissance des pathanmes de ces scripts, et mieux vaut être prudent.
Vous pensez bien que j'ai examiné cette possibilité que vous évoquez, avant de m'adresser à OVH pour celà. C'est d'ailleurs prévu dans les services qu'ils donnent pour leurs mutualisés.
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
Spyou wrote:
Evidemment.
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.
www.webcron.org
www.crontab.fr
si les service de l'hebergeur fonctionnent mal, allez les prendre
ailleurs .. D'autant que c'est gratuit :)
Bonjour Monsieur
Le seul problème...
C'est que les programmes que je veux déclencher, sont des scripts en
Bourne Shell, et non pas des scripts PHP.
Pour déclencher un script en Shell, il faut déjà être connecté sur un
compte Shell. Or, en mutualisé 240Plan sous OVH, il n'y a pas d'accès
Shell. De toute manières, vous me voyez donner le login/password d'un
accès Shell sur un site web ? :)
Ces scripts Shell sont dans le répertoire racine, au dessus du
sous-répertoire www/
A la rigueur, je pourrais positionner des scripts en PHP sous mon
arborescence www/ , pour qu'ils déclenchent chacun son script Shell
correspondant.
Oui, mais... Ces scripts en PHP seraient déclenchables par n'importe
qui ayant la connaissance des pathanmes de ces scripts, et mieux vaut
être prudent.
Vous pensez bien que j'ai examiné cette possibilité que vous évoquez,
avant de m'adresser à OVH pour celà. C'est d'ailleurs prévu dans les
services qu'ils donnent pour leurs mutualisés.
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
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.
www.webcron.org www.crontab.fr
si les service de l'hebergeur fonctionnent mal, allez les prendre ailleurs .. D'autant que c'est gratuit :)
Bonjour Monsieur
Le seul problème... C'est que les programmes que je veux déclencher, sont des scripts en Bourne Shell, et non pas des scripts PHP.
Pour déclencher un script en Shell, il faut déjà être connecté sur un compte Shell. Or, en mutualisé 240Plan sous OVH, il n'y a pas d'accès Shell. De toute manières, vous me voyez donner le login/password d'un accès Shell sur un site web ? :)
Ces scripts Shell sont dans le répertoire racine, au dessus du sous-répertoire www/
A la rigueur, je pourrais positionner des scripts en PHP sous mon arborescence www/ , pour qu'ils déclenchent chacun son script Shell correspondant.
Oui, mais... Ces scripts en PHP seraient déclenchables par n'importe qui ayant la connaissance des pathanmes de ces scripts, et mieux vaut être prudent.
Vous pensez bien que j'ai examiné cette possibilité que vous évoquez, avant de m'adresser à OVH pour celà. C'est d'ailleurs prévu dans les services qu'ils donnent pour leurs mutualisés.
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
Florent Clairambault
Alors :
1. Il a trés bien compris votre problème.
2. Vous pouvez tout à fait utiliser la solution des pages PHP, il suffit de rajouter un .htaccess et de spécifier un nom/login dans les paramêtres de wget.
3. Lorsqu'on propose de l'hébergement en mutualisé, on propose rarement la possibilité de modifier des scripts shell executables. Ca serrait comme donner un accès SSH. Le plus simple c'est de déclencher les scripts depuis une petite machine sous Linux chez vous avec la solution la solution PHP / .htacess / wget.
Florent
Alors :
1. Il a trés bien compris votre problème.
2. Vous pouvez tout à fait utiliser la solution des pages PHP, il suffit de
rajouter un .htaccess et de spécifier un nom/login dans les paramêtres de
wget.
3. Lorsqu'on propose de l'hébergement en mutualisé, on propose rarement la
possibilité de modifier des scripts shell executables. Ca serrait comme
donner un accès SSH. Le plus simple c'est de déclencher les scripts depuis
une petite machine sous Linux chez vous avec la solution la solution PHP /
.htacess / wget.
2. Vous pouvez tout à fait utiliser la solution des pages PHP, il suffit de rajouter un .htaccess et de spécifier un nom/login dans les paramêtres de wget.
3. Lorsqu'on propose de l'hébergement en mutualisé, on propose rarement la possibilité de modifier des scripts shell executables. Ca serrait comme donner un accès SSH. Le plus simple c'est de déclencher les scripts depuis une petite machine sous Linux chez vous avec la solution la solution PHP / .htacess / wget.
Florent
Christophe Baegert
Florent Clairambault wrote:
3. Lorsqu'on propose de l'hébergement en mutualisé, on propose rarement la possibilité de modifier des scripts shell executables. Ca serrait comme donner un accès SSH.
certains mutualisés donnent justement un accès SSH...
Florent Clairambault wrote:
3. Lorsqu'on propose de l'hébergement en mutualisé, on propose rarement la
possibilité de modifier des scripts shell executables. Ca serrait comme
donner un accès SSH.
certains mutualisés donnent justement un accès SSH...
3. Lorsqu'on propose de l'hébergement en mutualisé, on propose rarement la possibilité de modifier des scripts shell executables. Ca serrait comme donner un accès SSH.
certains mutualisés donnent justement un accès SSH...
Christophe Casalegno
Christophe Baegert wrote:
certains mutualisés donnent justement un accès SSH...
Certains hébergeurs le font même en standard quelle que soit l'offre... :)
dans (in) fr.reseaux.internet.hebergement, Christophe Casalegno ecrivait (wrote) :
Bonsoir,
[accès SSH en mutualisé]
Certains hébergeurs le font même en standard quelle que soit l'offre... :)
Certes, mais est-ce bien raisonnable en termes de sécurité ?
J'imagine que ça implique au minimum que les différents comptes soient en « jail » (au sens FreeBSD mais j'imagine que c'est possible aussi sous Linux), histoire que si un hébergé fait une boulette, cela n'impacte pas ses petits camarades partageant le même serveur, non ?
Je sens qu'on va bientôt causer de serveurs dédiés virtuels, là :)
En tous cas nous, pour l'instant, on n'ose pas proposer l'accès au shell pour des hébergements mutualisés, même via SSH...
Pour les dédiés, aucun problème, enfin si on ne nous a pas demandé d'infogérer la machine oeuf corse :)
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, Christophe Casalegno
<christophe.casalegno@digital-network.net> ecrivait (wrote) :
Bonsoir,
[accès SSH en mutualisé]
Certains hébergeurs le font même en standard quelle que soit l'offre... :)
Certes, mais est-ce bien raisonnable en termes de sécurité ?
J'imagine que ça implique au minimum que les différents comptes soient
en « jail » (au sens FreeBSD mais j'imagine que c'est possible aussi
sous Linux), histoire que si un hébergé fait une boulette, cela
n'impacte pas ses petits camarades partageant le même serveur, non ?
Je sens qu'on va bientôt causer de serveurs dédiés virtuels, là :)
En tous cas nous, pour l'instant, on n'ose pas proposer l'accès au shell
pour des hébergements mutualisés, même via SSH...
Pour les dédiés, aucun problème, enfin si on ne nous a pas demandé
d'infogérer la machine oeuf corse :)
dans (in) fr.reseaux.internet.hebergement, Christophe Casalegno ecrivait (wrote) :
Bonsoir,
[accès SSH en mutualisé]
Certains hébergeurs le font même en standard quelle que soit l'offre... :)
Certes, mais est-ce bien raisonnable en termes de sécurité ?
J'imagine que ça implique au minimum que les différents comptes soient en « jail » (au sens FreeBSD mais j'imagine que c'est possible aussi sous Linux), histoire que si un hébergé fait une boulette, cela n'impacte pas ses petits camarades partageant le même serveur, non ?
Je sens qu'on va bientôt causer de serveurs dédiés virtuels, là :)
En tous cas nous, pour l'instant, on n'ose pas proposer l'accès au shell pour des hébergements mutualisés, même via SSH...
Pour les dédiés, aucun problème, enfin si on ne nous a pas demandé d'infogérer la machine oeuf corse :)
-- Eric Demeester - http://www.galacsys.net
Christophe Baegert
Eric Demeester wrote:
Certes, mais est-ce bien raisonnable en termes de sécurité ?
En tout cas beaucoup plus que de proposer PHP :-))
Eric Demeester wrote:
Certes, mais est-ce bien raisonnable en termes de sécurité ?
En tout cas beaucoup plus que de proposer PHP :-))
Certes, mais est-ce bien raisonnable en termes de sécurité ?
En tout cas beaucoup plus que de proposer PHP :-))
Christophe Casalegno
Eric Demeester wrote:
Certes, mais est-ce bien raisonnable en termes de sécurité ?
Si c'est "bien fait" et que l'admin, tel une épée de damocles au dessus de la tête du client veille, cela ne pose pas de problèmes particuliers :)
J'imagine que ça implique au minimum que les différents comptes soient en « jail » (au sens FreeBSD mais j'imagine que c'est possible aussi sous Linux), histoire que si un hébergé fait une boulette, cela n'impacte pas ses petits camarades partageant le même serveur, non ?
Non c'est possible sans jail, mais on peut faire des choses correctes avec quelques patchs kernels et de bonnes permissions.
En tous cas nous, pour l'instant, on n'ose pas proposer l'accès au shell pour des hébergements mutualisés, même via SSH...
On le propose en standard depuis 1999 et on a jamais eu de problèmes notables, cela dit celui qui ferait une "grosse" boulette sait à quoi il s'expose.
Certes, mais est-ce bien raisonnable en termes de sécurité ?
Si c'est "bien fait" et que l'admin, tel une épée de damocles au dessus de
la tête du client veille, cela ne pose pas de problèmes particuliers :)
J'imagine que ça implique au minimum que les différents comptes soient
en « jail » (au sens FreeBSD mais j'imagine que c'est possible aussi
sous Linux), histoire que si un hébergé fait une boulette, cela
n'impacte pas ses petits camarades partageant le même serveur, non ?
Non c'est possible sans jail, mais on peut faire des choses correctes avec
quelques patchs kernels et de bonnes permissions.
En tous cas nous, pour l'instant, on n'ose pas proposer l'accès au shell
pour des hébergements mutualisés, même via SSH...
On le propose en standard depuis 1999 et on a jamais eu de problèmes
notables, cela dit celui qui ferait une "grosse" boulette sait à quoi il
s'expose.
Certes, mais est-ce bien raisonnable en termes de sécurité ?
Si c'est "bien fait" et que l'admin, tel une épée de damocles au dessus de la tête du client veille, cela ne pose pas de problèmes particuliers :)
J'imagine que ça implique au minimum que les différents comptes soient en « jail » (au sens FreeBSD mais j'imagine que c'est possible aussi sous Linux), histoire que si un hébergé fait une boulette, cela n'impacte pas ses petits camarades partageant le même serveur, non ?
Non c'est possible sans jail, mais on peut faire des choses correctes avec quelques patchs kernels et de bonnes permissions.
En tous cas nous, pour l'instant, on n'ose pas proposer l'accès au shell pour des hébergements mutualisés, même via SSH...
On le propose en standard depuis 1999 et on a jamais eu de problèmes notables, cela dit celui qui ferait une "grosse" boulette sait à quoi il s'expose.
dans (in) fr.reseaux.internet.hebergement, Christophe Baegert ecrivait (wrote) :
Bonsoir,
En tout cas beaucoup plus que de proposer PHP :-))
Bof. Si on suit attentivement les évolutions de PHP, qu'on applique les patches qui vont bien et qu'on n'installe pas la dernière version de la mort sans réfléchir, çà me paraît moins dangereux que de donner un accès au client à un shell qui va potentiellement lui permettre de faire plein de bétises.
Mais bon je peux me tromper, je ne suis pas technicien et encore moins compétent en termes de sécurité.
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, Christophe Baegert
<cbaegert-pas-de-spam@europeanservers.net> ecrivait (wrote) :
Bonsoir,
En tout cas beaucoup plus que de proposer PHP :-))
Bof. Si on suit attentivement les évolutions de PHP, qu'on applique les
patches qui vont bien et qu'on n'installe pas la dernière version de la
mort sans réfléchir, çà me paraît moins dangereux que de donner un accès
au client à un shell qui va potentiellement lui permettre de faire plein
de bétises.
Mais bon je peux me tromper, je ne suis pas technicien et encore moins
compétent en termes de sécurité.
dans (in) fr.reseaux.internet.hebergement, Christophe Baegert ecrivait (wrote) :
Bonsoir,
En tout cas beaucoup plus que de proposer PHP :-))
Bof. Si on suit attentivement les évolutions de PHP, qu'on applique les patches qui vont bien et qu'on n'installe pas la dernière version de la mort sans réfléchir, çà me paraît moins dangereux que de donner un accès au client à un shell qui va potentiellement lui permettre de faire plein de bétises.
Mais bon je peux me tromper, je ne suis pas technicien et encore moins compétent en termes de sécurité.
-- Eric Demeester - http://www.galacsys.net
Florent Clairambault
Certes, mais est-ce bien raisonnable en termes de sécurité ?
En tout cas beaucoup plus que de proposer PHP :-))
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. Alors qu'avec un SSH, ça peut-être sur n'importe lequel des composants du serveur qu'on peut trouver une faille. D'autre part, si les utilisateurs laissent un accès total sur certains répertoires, via PHP, les répertoires seront bloqués aux autres utilisateurs, alors que via SSH non.
Pour dédiés virtuel, on peut se le permettre.
Certes, mais est-ce bien raisonnable en termes de sécurité ?
En tout cas beaucoup plus que de proposer PHP :-))
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. Alors qu'avec un SSH, ça
peut-être sur n'importe lequel des composants du serveur qu'on peut trouver
une faille. D'autre part, si les utilisateurs laissent un accès total sur
certains répertoires, via PHP, les répertoires seront bloqués aux autres
utilisateurs, alors que via SSH non.
Certes, mais est-ce bien raisonnable en termes de sécurité ?
En tout cas beaucoup plus que de proposer PHP :-))
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. Alors qu'avec un SSH, ça peut-être sur n'importe lequel des composants du serveur qu'on peut trouver une faille. D'autre part, si les utilisateurs laissent un accès total sur certains répertoires, via PHP, les répertoires seront bloqués aux autres utilisateurs, alors que via SSH non.
