Dan

Oui parce que le ^ à l'endroit où tu le mettais représentait une négation donc [^a-zA-Z] signifie tout sauf les lettres de a à z. Pour info, tu pourrais écrire ta règle : RewriteRule ^ville-([a-z]+)-([0-9]+)\.php$ /ville.php?ville=$1&cp=$2 [NC,L] en utilisant le flag NC (pour No Case) rendant l'expression insensible à la casse.

Alors je ne vois pas... mais comme je te le disais dans mon premier post, quelques mois plus tard, il est difficile de faire une analyse post-mortem

Effectivement, si tu avais mis une mauvaise IP comme cible pour un host, c'est cette IP qui recevait le trafic. Donc ce n'est pas une erreur d'OVH, mais une erreur de ta part ! Je réponds donc à ta première question... Comment est ce possible et est ce seulement possible sans réelle intention de nuire ? Ce n'est possible que si le propriétaire du domaine fait une erreur dans la zone, ou en cas de DNS spooofing (qui devrait disparaître ce mois-ci : http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010 )

Tu trouves cela bizarre... et tu as raison. Là où tu as tort, c'est d'avoir attendu plusieurs mois pour venir poser la question. De plus tu ne sais même plus quel paramètre OVH t'a demandé de changer... et le fait que cela soit revenu à la normale est une démonstration que l'erreur était dans ton compte. Probablement une redirection que tu avais mal paramétrée, ou un truc du même genre. Difficile de t'en dire plus, ma boule de cristal ne fonctionne pas avec le passé

L'exécutable php se trouve sur ton serveur Debian dans /usr/local/bin/php ... remplace donc le "php" de ton crontab par le chemin complet. /usr/local/bin/php /home/user/domains/nom-de-domaine/extracter.php Dan

Lorsque j'installais un serveur dédié, j'installais unzip parce qu'il était nécessaire pour les archives de DirectAdmin qui sont dans ce format (du moins certaines)... et je ne pensais pas forcément à installer zip étant plutôt un afficionado du "tar gnu" beaucoup plus souple à mon sens. Depuis je l'installe tout de même parce qu'il m'a été demandé à quelques reprises. Pour ceux qui sont sous Debian et qui ne l'ont pas, une installation est aussi simple que "apt-get install zip"

Bonjour et bienvenue à bord du Hub ! Je ne sais pas pour quelle raison ton message s'est trouvé en modération, alors qu'il n'y avait rien qui aurait pu entrainer cela. C'est en ligne maintenant. Dan

Le ? est tout à fait légitime et marque l'élément qui précède comme facultatif. Dans ce cas le / J'en ai une bonne dizaine dans le .htaccess du Hub Si cela ne fonctionne pas chez toi, c'est que ton hébergeur a bidouillé mod_rewrite (je sais qu'OVH l'a fait sur ses mutualisés mais dans leur cas c'est fait correctement). C'est à ton hébergeur qu'il faut poser la question !

Accéder au port 3306 local Ou au port 3306 d'un autre serveur ? Que veux-tu faire ? Permettre une connexion à mysql d'un hôte distant ?

Ca m'étonnerait que ce soit cette règle ! Cela ne réécrit que index.php précédé ou non d'un slash Ou alors c'est que tu as vraiment un hébergement "en carton" !

Essaie avec la règle RewriteRule ^/?index\.php$ http://www.monsite.tld/ [L,R=301] Selon la config, le / est peut-être présent devant index.php et donc ^index.php ne pourra pas matcher /index.php

C'est quoi ça comme règle ? RewriteRule ^(.*)index. php /$1 [R=301,L] Là on est certain d'avoir une erreur 500 ! Même sans l'espace devant "php" ... je ne vois pas ce que tu cherches à faire

Bonjour, Tout simplement en y mettant un fichier .htaccess avec cette ligne : Options +Indexes

A mon avis c'est dans le script de démarrage de qmail (normalement /etc/init.d/qmail) que tu dois lancer le smtp. En tout cas sur les distribs Redhat et Gentoo OVH c'est le cas.

Il faut appliquer le patch 2.19 si tu es en Release 2 pour avoir la mise à jour... sinon clamd bloque les mails. Pour les autres distributions, il doit y avoir une mise à jour de clamav Voici le mail d'Octave à ce sujet

A tout hasard... vous n'utilisez pas clamd ? Parce que la dernière mise à jour pose des soucis à pas mal de monde, en tout cas sur Release 2 OVH (gentoo)

Salut Sylvain, Lorsque je lance un "dig dev-nom_de_domaine" au départ du serveur du Hub ... je remarque que le serveur qui gère ce domaine n'est pas le bon. C'est ton serveur de prod et non ton serveur de développement. Dan

J'ai supprimé le lien vers un template qui à mon avis n'est pas prévu pour être laissé en libre téléchargement.

Si, alors lance cela directement, sans la ligne "echo...." La 1.83 met bind à jour ! cd /root sh patch-all.sh Si cela ne fonctionne pas après passage à la 1.83, tu referas une seconde fois la commande, avec le echo cette fois ! Il ne fallait pas que ton serveur soit dans une release plus ancienne, par exemple 1.80 ou 1.81 .... mais 1.82 c'est OK.

Tomcat n'est pas trop ma tasse de thé ... Tu peux activer le RewriteLog pour voir ce que fait ta règle ?

Je pense que c'est un problème connu lors de l'installation de bind sur les release 1. Tu peux faire ceci, qui devrait résoudre ton problème, pour autant que tu sois bien en release 1.83 (regarde le fichier /etc/ovhrelease): echo 1.82 > /etc/ovhrelease cd /root sh patch-all.sh Cela réinstallera la release 1.83 et réinstallera bind.

Ton répertoire "machin" se trouve à la racine du serveur ? Cela m'étonnerait Essaie avec : RewriteRule ^/$ machin/HomeServlet [L]

Sauf que là ce n'est pas du spam. Ils te disent seulement qu'une personne souhaite prendre le même nom de domaine que ton .com (.net ou .org) en .cn ou .com.cn et te posaient la question pour savoir si cela n'entrainerait pas de conflit à cause du nommage du domaine ou de ta marque commerciale. Sans réponse de ta part sous 5 jours, ils autoriseraient cette personne à prendre le .com.cn (ou .cn) .... rien d'autre !

<hors sujet> En regardant les annonces thématiques en haut du post je me dis que Google n'a pas bien dû percevoir la thématique du Hub </hors sujet>

<kidding>Moi j'en conclurais que tu ne comprends pas grand-chose aux valeurs reportées par "top".</kidding> Les chiffres en regard de %ni, %us et %sy sont les pourcentages pour les process en mode NIce, en mode USer et en mode SYstème Il te manque "IDle", "WAit (attente d'I/O)", "Hardware Interrupts", "Software Interrupts", "STolen (temps 'volé' par l'hyperviseur pour d'autres tâches)" ... Donc on peut dire que de 2 à 17% de tes processus tournent en mode "Nice" (ont une priorité changée en + ou - par rapport au défaut) ... que ton cpu ne sert pas à grand-chose pour les process Utilisateurs vu le % affiché, et que le système ne mouline pas dans le noyau. Une valeur qu'il m'aurait intéressé de voir est "WA" ... cela aurait permis de voir si ton serveur ramait au niveau des disques. Le reste on s'en fiche un peu PS: pour info, une charge de 4 n'est pas une surcharge pour un serveur HG. Tant que ça reste inférieur au nombre de coeurs c'est bon. Dans ton cas c'est 8 !