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
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.
Et si c'est involontaire ?
J'ai déja vu un serveur surlequel j'ai pu via un script PHP non protégé installer un autre script PHP d'exploration, aller dans les fichiers de config du webmail et pouf trouver les MDP root. [c'est le plus pire des cas graves]
Dans ce cas la, il s'expose à quoi le mec STP ? J'aimerai bien savoir ? Je dirai à rien du tout...
Si maintenant c'est un utilisateur non root et que vous avez une faille, qu'il se fout sur le serveur et que y'a genre un mot de passe root en clair, qu'il arrive à le pécho et que les autres machines ont le même mot de passe root et qu'il massacre tout, vous avez l'air bien malin.
Bref, c'est vrai que humainement, y'a peu de risque. D'abord parce qu'il faut que y'ai une faille, et ensuite parce qu'il faut que le mot de passe d'un utilisateur soit récupéré. Mais si un méchant hacker passe par la, à mon avis il peu faire des dégâts.
Florent
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.
Et si c'est involontaire ?
J'ai déja vu un serveur surlequel j'ai pu via un script PHP non protégé
installer un autre script PHP d'exploration, aller dans les fichiers de
config du webmail et pouf trouver les MDP root. [c'est le plus pire des cas
graves]
Dans ce cas la, il s'expose à quoi le mec STP ? J'aimerai bien savoir ? Je
dirai à rien du tout...
Si maintenant c'est un utilisateur non root et que vous avez une faille,
qu'il se fout sur le serveur et que y'a genre un mot de passe root en clair,
qu'il arrive à le pécho et que les autres machines ont le même mot de passe
root et qu'il massacre tout, vous avez l'air bien malin.
Bref, c'est vrai que humainement, y'a peu de risque. D'abord parce qu'il
faut que y'ai une faille, et ensuite parce qu'il faut que le mot de passe
d'un utilisateur soit récupéré. Mais si un méchant hacker passe par la, à
mon avis il peu faire des dégâts.
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.
Et si c'est involontaire ?
J'ai déja vu un serveur surlequel j'ai pu via un script PHP non protégé installer un autre script PHP d'exploration, aller dans les fichiers de config du webmail et pouf trouver les MDP root. [c'est le plus pire des cas graves]
Dans ce cas la, il s'expose à quoi le mec STP ? J'aimerai bien savoir ? Je dirai à rien du tout...
Si maintenant c'est un utilisateur non root et que vous avez une faille, qu'il se fout sur le serveur et que y'a genre un mot de passe root en clair, qu'il arrive à le pécho et que les autres machines ont le même mot de passe root et qu'il massacre tout, vous avez l'air bien malin.
Bref, c'est vrai que humainement, y'a peu de risque. D'abord parce qu'il faut que y'ai une faille, et ensuite parce qu'il faut que le mot de passe d'un utilisateur soit récupéré. Mais si un méchant hacker passe par la, à mon avis il peu faire des dégâts.
Florent
Jean-François Ortolo
Bonjour Monsieur Voir mes réponses ci-dessous.
Florent Clairambault wrote:
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.
Je vais sous peu étudier la solution .htaccess pour protéger l'exécution des deux scripts PHP envisagés ( un par script Shell ), mais puis-je me permettre de vous demander si vous pouviez me donner un exemple de configuration .htaccess idoine ?
Je connais assez peu la syntaxe de .htaccess , et surtout je ne vois pas comment spécifier que le script PHP ne puisse être lancé qu'à partir du site webcron.org par exemple, et dans des conditions telles que je sois le seul à pouvoir le déclencher.
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
Bon, le problème c'est que celà nécéssiterait que ma machine chez moi, soit allumée tous les jours aux heures où ces scripts doivent être lancés, ce qui n'est pas praticable.
Les solutions indiquées précédemment me semble praticables, à condition qu'un .htaccess filtre la possibilité d'exécution de ces scripts d'une façon efficace, et j'avoue que je n'ai pas entièrement compris le type de filtrage que vous proposez.
Si vous pouviez me donner un exemple, qu'est-ce que je serais content et reconnaissant. :)
Merci beaucoup de vos réponses.
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
Bonjour Monsieur
Voir mes réponses ci-dessous.
Florent Clairambault wrote:
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.
Je vais sous peu étudier la solution .htaccess pour protéger
l'exécution des deux scripts PHP envisagés ( un par script Shell ), mais
puis-je me permettre de vous demander si vous pouviez me donner un
exemple de configuration .htaccess idoine ?
Je connais assez peu la syntaxe de .htaccess , et surtout je ne vois
pas comment spécifier que le script PHP ne puisse être lancé qu'à partir
du site webcron.org par exemple, et dans des conditions telles que je
sois le seul à pouvoir le déclencher.
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
Bon, le problème c'est que celà nécéssiterait que ma machine chez moi,
soit allumée tous les jours aux heures où ces scripts doivent être
lancés, ce qui n'est pas praticable.
Les solutions indiquées précédemment me semble praticables, à
condition qu'un .htaccess filtre la possibilité d'exécution de ces
scripts d'une façon efficace, et j'avoue que je n'ai pas entièrement
compris le type de filtrage que vous proposez.
Si vous pouviez me donner un exemple, qu'est-ce que je serais content
et reconnaissant. :)
Merci beaucoup de vos réponses.
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
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.
Je vais sous peu étudier la solution .htaccess pour protéger l'exécution des deux scripts PHP envisagés ( un par script Shell ), mais puis-je me permettre de vous demander si vous pouviez me donner un exemple de configuration .htaccess idoine ?
Je connais assez peu la syntaxe de .htaccess , et surtout je ne vois pas comment spécifier que le script PHP ne puisse être lancé qu'à partir du site webcron.org par exemple, et dans des conditions telles que je sois le seul à pouvoir le déclencher.
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
Bon, le problème c'est que celà nécéssiterait que ma machine chez moi, soit allumée tous les jours aux heures où ces scripts doivent être lancés, ce qui n'est pas praticable.
Les solutions indiquées précédemment me semble praticables, à condition qu'un .htaccess filtre la possibilité d'exécution de ces scripts d'une façon efficace, et j'avoue que je n'ai pas entièrement compris le type de filtrage que vous proposez.
Si vous pouviez me donner un exemple, qu'est-ce que je serais content et reconnaissant. :)
Merci beaucoup de vos réponses.
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
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"...
Alors qu'avec un SSH, ça peut-être sur n'importe lequel des composants du serveur qu'on peut trouver une faille.
Pas compris la phrase...
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,
Ben non. Si laissent accès total, ils laissent accès total. Ils ne laissent pas accès total en bloquant.
alors que via SSH non.
On peut imposer les restrictions qu'il faut, quel que soit le moyen d'accès utilisé. Tout dépend aussi des gens qui utilisent ces accès.
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
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"...
Alors qu'avec un SSH,
ça peut-être sur n'importe lequel des composants du serveur qu'on peut
trouver une faille.
Pas compris la phrase...
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,
Ben non. Si laissent accès total, ils laissent accès total. Ils ne
laissent pas accès total en bloquant.
alors que via SSH non.
On peut imposer les restrictions qu'il faut, quel que soit le moyen
d'accès utilisé. Tout dépend aussi des gens qui utilisent ces accès.
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
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"...
Alors qu'avec un SSH, ça peut-être sur n'importe lequel des composants du serveur qu'on peut trouver une faille.
Pas compris la phrase...
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,
Ben non. Si laissent accès total, ils laissent accès total. Ils ne laissent pas accès total en bloquant.
alors que via SSH non.
On peut imposer les restrictions qu'il faut, quel que soit le moyen d'accès utilisé. Tout dépend aussi des gens qui utilisent ces accès.
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
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"...
Ah bon ? Et qu'y a t-il de complexe là dedans ?
Cdlt,
-- JUL, JUL _at_ julnav _dot_ com GPG Key ID : 0xDC51DE6E
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"...
Ah bon ? Et qu'y a t-il de complexe là dedans ?
Cdlt,
--
JUL, JUL _at_ julnav _dot_ com
GPG Key ID : 0xDC51DE6E
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"...
Ah bon ? Et qu'y a t-il de complexe là dedans ?
Cdlt,
-- JUL, JUL _at_ julnav _dot_ com GPG Key ID : 0xDC51DE6E
Christophe Casalegno
Florent Clairambault wrote:
J'ai déja vu un serveur surlequel j'ai pu via un script PHP non protégé installer un autre script PHP d'exploration, aller dans les fichiers de config du webmail et pouf trouver les MDP root. [c'est le plus pire des cas graves]
Là il s'agit d'un serveur mal sécurisé,il faut changer d'hébergeur en courant...
Cela dit d'un point de vue juridique c'estune intrusion et un maintient dans un système d'information et il s'expose (entre autre) à de la prison et une forte amende.
Dans ce cas la, il s'expose à quoi le mec STP ? J'aimerai bien savoir ? Je dirai à rien du tout...
Si si voir plus haut, je ne vois pas en quoi cette manipulation révèle du hasard, mais encore une fois un hébergeur aussi mal sécurisé est à éviter d'emblée.
Si maintenant c'est un utilisateur non root et que vous avez une faille, qu'il se fout sur le serveur et que y'a genre un mot de passe root en clair, qu'il arrive à le pécho et que les autres machines ont le même mot de passe root et qu'il massacre tout, vous avez l'air bien malin.
On apelle cela être *totalement* incompétent, dans ce cas là il faut changer de métier (et rapidement)
Bref, c'est vrai que humainement, y'a peu de risque. D'abord parce qu'il faut que y'ai une faille, et ensuite parce qu'il faut que le mot de passe d'un utilisateur soit récupéré. Mais si un méchant hacker passe par la, à mon avis il peu faire des dégâts.
Les hackers ne sont pas méchants et ne détruisement pas les systèmes d'informations df [PUB] http://www.dnsi.info/IMG/pdf/lemondedelasecurite.pdf
J'ai déja vu un serveur surlequel j'ai pu via un script PHP non protégé
installer un autre script PHP d'exploration, aller dans les fichiers de
config du webmail et pouf trouver les MDP root. [c'est le plus pire des
cas graves]
Là il s'agit d'un serveur mal sécurisé,il faut changer d'hébergeur en
courant...
Cela dit d'un point de vue juridique c'estune intrusion et un maintient dans
un système d'information et il s'expose (entre autre) à de la prison et une
forte amende.
Dans ce cas la, il s'expose à quoi le mec STP ? J'aimerai bien savoir ? Je
dirai à rien du tout...
Si si voir plus haut, je ne vois pas en quoi cette manipulation révèle du
hasard, mais encore une fois un hébergeur aussi mal sécurisé est à éviter
d'emblée.
Si maintenant c'est un utilisateur non root et que vous avez une faille,
qu'il se fout sur le serveur et que y'a genre un mot de passe root en
clair, qu'il arrive à le pécho et que les autres machines ont le même mot
de passe root et qu'il massacre tout, vous avez l'air bien malin.
On apelle cela être *totalement* incompétent, dans ce cas là il faut changer
de métier (et rapidement)
Bref, c'est vrai que humainement, y'a peu de risque. D'abord parce qu'il
faut que y'ai une faille, et ensuite parce qu'il faut que le mot de passe
d'un utilisateur soit récupéré. Mais si un méchant hacker passe par la, à
mon avis il peu faire des dégâts.
Les hackers ne sont pas méchants et ne détruisement pas les systèmes
d'informations df [PUB]
http://www.dnsi.info/IMG/pdf/lemondedelasecurite.pdf
J'ai déja vu un serveur surlequel j'ai pu via un script PHP non protégé installer un autre script PHP d'exploration, aller dans les fichiers de config du webmail et pouf trouver les MDP root. [c'est le plus pire des cas graves]
Là il s'agit d'un serveur mal sécurisé,il faut changer d'hébergeur en courant...
Cela dit d'un point de vue juridique c'estune intrusion et un maintient dans un système d'information et il s'expose (entre autre) à de la prison et une forte amende.
Dans ce cas la, il s'expose à quoi le mec STP ? J'aimerai bien savoir ? Je dirai à rien du tout...
Si si voir plus haut, je ne vois pas en quoi cette manipulation révèle du hasard, mais encore une fois un hébergeur aussi mal sécurisé est à éviter d'emblée.
Si maintenant c'est un utilisateur non root et que vous avez une faille, qu'il se fout sur le serveur et que y'a genre un mot de passe root en clair, qu'il arrive à le pécho et que les autres machines ont le même mot de passe root et qu'il massacre tout, vous avez l'air bien malin.
On apelle cela être *totalement* incompétent, dans ce cas là il faut changer de métier (et rapidement)
Bref, c'est vrai que humainement, y'a peu de risque. D'abord parce qu'il faut que y'ai une faille, et ensuite parce qu'il faut que le mot de passe d'un utilisateur soit récupéré. Mais si un méchant hacker passe par la, à mon avis il peu faire des dégâts.
Les hackers ne sont pas méchants et ne détruisement pas les systèmes d'informations df [PUB] http://www.dnsi.info/IMG/pdf/lemondedelasecurite.pdf
C'est complexe dans le sens ou tu trouvera toujours des gars qui utilise une fonctionalité qui n'était présente que dans une version (presque) obsolète et qui n'est plus reconduite dansles versions actuelles. Non? Pour moi c'est un "facteur de compléxité" qui ne se règle pas à coup de "il suffit". Mais peut-etre pas pour les autres.
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Sun, 24 Apr 2005 22:59:36 +0200 ) JUL :
Ah bon ? Et qu'y a t-il de complexe là dedans ?
Bonsoir JUL...
C'est complexe dans le sens ou tu trouvera toujours des gars qui utilise
une fonctionalité qui n'était présente que dans une version (presque)
obsolète et qui n'est plus reconduite dansles versions actuelles. Non?
Pour moi c'est un "facteur de compléxité" qui ne se règle pas à coup de
"il suffit". Mais peut-etre pas pour les autres.
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
C'est complexe dans le sens ou tu trouvera toujours des gars qui utilise une fonctionalité qui n'était présente que dans une version (presque) obsolète et qui n'est plus reconduite dansles versions actuelles. Non? Pour moi c'est un "facteur de compléxité" qui ne se règle pas à coup de "il suffit". Mais peut-etre pas pour les autres.
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
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"...
D'un autre coté (pour moi, en tout cas) la sécurité et la stabilité d'un systeme mutu priment sur l'eventuelle flemardise des webmasters qui l'utilisent.
Donc quand il s'agit de corriger des failles de sécu, les gens qui utilisent des fonctions dépréciées ou revues et corrigées, il vont se faire voir
(ce qui n'empeche pas de faire un mails aux webmasters concernés par une upgrade au moment ou elle est faite, ou un peu avant si elle est planifiée, afin qu'ils vérifient que tout va bien après)
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"...
D'un autre coté (pour moi, en tout cas) la sécurité et la stabilité d'un
systeme mutu priment sur l'eventuelle flemardise des webmasters qui
l'utilisent.
Donc quand il s'agit de corriger des failles de sécu, les gens qui
utilisent des fonctions dépréciées ou revues et corrigées, il vont se
faire voir
(ce qui n'empeche pas de faire un mails aux webmasters concernés par une
upgrade au moment ou elle est faite, ou un peu avant si elle est
planifiée, afin qu'ils vérifient que tout va bien après)
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"...
D'un autre coté (pour moi, en tout cas) la sécurité et la stabilité d'un systeme mutu priment sur l'eventuelle flemardise des webmasters qui l'utilisent.
Donc quand il s'agit de corriger des failles de sécu, les gens qui utilisent des fonctions dépréciées ou revues et corrigées, il vont se faire voir
(ce qui n'empeche pas de faire un mails aux webmasters concernés par une upgrade au moment ou elle est faite, ou un peu avant si elle est planifiée, afin qu'ils vérifient que tout va bien après)
Jean-François Ortolo
Bonjour Sur le forum www.webrankinfo.com , j'ai reçu le conseil de faire une vérification dans le script PHP, sur l'heure actuelle de l'exécution du script.
Le problème me paraît donc réglé.
Bien à vous.
Merci beaucoup pour vos réponses.
Jean Francois Ortolo
-- Mon site donne des Statistiques et des Historiques Graphiques gratuits sur les Courses de Chevaux du PMU. http://www.ortolojf-courses.com
Bonjour
Sur le forum www.webrankinfo.com , j'ai reçu le conseil de faire une
vérification dans le script PHP, sur l'heure actuelle de l'exécution du
script.
Le problème me paraît donc réglé.
Bien à vous.
Merci beaucoup pour vos réponses.
Jean Francois Ortolo
--
Mon site donne des Statistiques
et des Historiques Graphiques gratuits
sur les Courses de Chevaux du PMU.
http://www.ortolojf-courses.com
Bonjour Sur le forum www.webrankinfo.com , j'ai reçu le conseil de faire une vérification dans le script PHP, sur l'heure actuelle de l'exécution du script.
Le problème me paraît donc réglé.
Bien à vous.
Merci beaucoup pour vos réponses.
Jean Francois 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
Sur le forum www.webrankinfo.com , j'ai reçu le conseil de faire une vérification dans le script PHP, sur l'heure actuelle de l'exécution du script.
Il faudra prendre soin de vérifier que l'horloge du serveur web en question est correctement synchronisée...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Sur le forum www.webrankinfo.com , j'ai reçu le conseil de faire une
vérification dans le script PHP, sur l'heure actuelle de l'exécution du
script.
Il faudra prendre soin de vérifier que l'horloge du serveur web en
question est correctement synchronisée...
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Sur le forum www.webrankinfo.com , j'ai reçu le conseil de faire une vérification dans le script PHP, sur l'heure actuelle de l'exécution du script.
Il faudra prendre soin de vérifier que l'horloge du serveur web en question est correctement synchronisée...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Florent Clairambault
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).
Alors qu'avec un SSH, ça peut-être sur n'importe lequel des composants du serveur qu'on peut trouver une faille.
Pas compris la phrase...
Bah, si on a un accès SSH, on peut essayer de bousiller les accès en local, comme compiler des applis en C qui balancent de la merde à MySQL.
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,
Ben non. Si laissent accès total, ils laissent accès total. Ils ne laissent pas accès total en bloquant.
On peut imposer les restrictions qu'il faut, quel que soit le moyen d'accès utilisé. Tout dépend aussi des gens qui utilisent ces accès.
C'est plus dur avec SSH.
Florent
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).
Alors qu'avec un SSH,
ça peut-être sur n'importe lequel des composants du serveur qu'on peut
trouver une faille.
Pas compris la phrase...
Bah, si on a un accès SSH, on peut essayer de bousiller les accès en local,
comme compiler des applis en C qui balancent de la merde à MySQL.
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,
Ben non. Si laissent accès total, ils laissent accès total. Ils ne
laissent pas accès total en bloquant.
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).
Alors qu'avec un SSH, ça peut-être sur n'importe lequel des composants du serveur qu'on peut trouver une faille.
Pas compris la phrase...
Bah, si on a un accès SSH, on peut essayer de bousiller les accès en local, comme compiler des applis en C qui balancent de la merde à MySQL.
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,
Ben non. Si laissent accès total, ils laissent accès total. Ils ne laissent pas accès total en bloquant.
