crontab

[stevebrush]

j'aurais aimé pouvoir utiliser la crontab pour que le petit moteur de recherche du site réindexe celui-ci toutes les semaines. j'ai accès à un pseudo shell en cgi et j'arrive sans problème à rentrer une commande dans la crontab, mais apparemment, elle est effacée automatiquement au bout de quelques jours :( ...

qu'est-ce qu'on a le droit d'utiliser sur ces machines? (cron, librairies diverses, qu'est-ce qui est installé...)

sinon, y'a pas moyen d'avoir un shell telnet ou ssh sur les mutualisés?
merci.

le site en question : www.technorisque.org

[OVH]

Crontab est possible sur les plan/pack (pas sur les gp).
Voici un faq qui peut vous aider:
http://www.ovh.com/fr/support/faq/specifique/index.cgi?do=showq&qid=75

[stevebrush]

ok, et les librairies (netpbm, imagemagik...) on a le droit de les utiliser?

[L.Boggio]

Si elles sont présentes, ou que tu peux les installer toi-même, bien sur.

Ce qu'il ne faut pas oublier, c'est que, en mutualisé, tu fais ce que tu veux, tant que tu ne déranges pas les autres... Si ImageMagick te sert, et qu'il ne bouffe pas 80% de CPU et de RAM, utilises-le ;-)

Ca vaut aussi pour le MySQL, ce qui explique que les bases trop grosses ou mal optimisées soient coupées par OVH.

[Jérémie]

L.Boggio écrivait :
Ca vaut aussi pour le MySQL, ce qui explique que les bases trop grosses ou mal optimisées soient coupées par OVH.
Nope, "trop gros" n'est pas un critère, la taille de la base MySQL est illimitée (et "mal optimisée" est curieux comme critère).

Par contre, que le moindre accès à une telle base fasse ramer le serveur et que la requête soit killée avant même d'être finie, c'est très possible ;)

[L.Boggio]

Jérémie écrivait :
Nope, "trop gros" n'est pas un critère, la taille de la base MySQL est illimitée (et "mal optimisée" est curieux comme critère).
Je n'ai pas dit que MySQL n'était pas illimité, j'ai dit que OVH avait décidé que les bases qui dépassaient une certaine taille devait aller sur un autre serveur dédié.
Quand à l'optimisation des tables, il semblerait que tu ne maitrises pas ce que cela implique :
imaginons que tu crées une table avec un champ text mais sans index, que tu stoques dans ce champ des infos de type 124, 254, 354, 8547 et que tu fasses des requêtes en utilisant ce champ dans un where : Ca, c'est une table TRES mal optimisée. Multiplies ça par 1000 enregistrements, et tu plantes un serveur MySQL.

Par contre, que le moindre accès à une telle base fasse ramer le serveur et que la requête soit killée avant même d'être finie, c'est très possible ;)

Et en attendant que le robot la détecte et la kille (plus celles des autres visiteurs du site qui lance cette requête), il aura fait ramer le serveur, au minimum, et les autres utilisateurs de ce serveur auront postés sur le Bar@ pour raler que ça rame...

Le maître mot de cette explication est mutualisé ...