jcaron

Comme "-" désigne une "range" (comme A-Z), "_-." désigne "les caractères dont le code ASCII est compris entre _ et .". Or "." a un code ASCII inférieur à "_", donc ça couine. Et de toutes façons ce n'est pas ce que tu veux. La bonne solution: dans une classe (quelque chose entre []), si tu veux inclure "-", il faut toujours le mettre au début. Tant qu'on y est: - le ^ et le $ impliquent que $data2 commence effectivement par onmouseover et finisse par UnTip()">, je ne suis pas sûr que ce soit effectivement ce que tu veux - "{1,}" peut s'écrire "+", c'est quand même plus simple - si tu utilises ' comme délimiteur pour ta chaîne, tu n'auras pas besoin d'escaper les ", ça fait trois \ de moins, c'est toujours ça de pris en lisibilité - ta classe n'acceptera pas les caractères accentués. Tu peux avoir envie d'utiliser \w à la place de a-zA-Z0-9, c'est plus large. Ou carrément [^']+ pour tout prendre jusqu'au ' qui suit - il te manque des choses avant le onmouseout, ta regex ne matchera jamais Jacques.

Non, c'est complètement normal. Si tu fais un select de plusieurs tables, par défaut tu as un produit cartésien (toutes les lignes de A x toutes les lignes de , qui est ensuite "réduit" par les conditions que tu donnes (ou pas, si tu n'en donnes pas). Dans ton cas, tu ne qualifies ou sélectionnes peut-être aucun champ de b, mais tu lui demandes des lignes de b (sinon pourquoi tu le mettrais dans ta liste des tables?). C'est un peu comme si tu nous disais que si tu fais un "select * from table", vu que tu ne qualifies aucun champ, il ne devrait rien renvoyer... Si tu n'es intéressé que par les colonnes de a (et que b ne sert qu'à qualifier dans certains cas), plusieurs solutions: select a.colonnes from a,b where (a.col=b.col and conditions_sur_ union all select a.colonnes from a where conditions_sur_a select a.colonnes from a where (a.col in (select col from b where conditions_sur_ or conditions_sur_a) Ca peut être utile de faire appel à des jointures explicites (select ... from a join b on (condition_de_jointure) where autres_conditions) si ça t'aide à mieux formaliser ce que tu veux. Jacques.

Euh... Tu as relu ta requête? Je ne crois pas que ça fasse ce que tu veux, et il est assez normal que ça prenne trois plombes. Tu lui dis que tu veux: - les combinaisons de lignes de a et b où b.champ=a.champ et quelques conditions sur b - les combinaisons de lignes de a et b avec une condition sur a En supposant qu'il y ait un lien 1-1 entre a et b avec la première condition, cette partie-là est relativement simple. La deuxième par contre signifie que pour chaque ligne de a qui correspond à la condition, tu veux toutes les lignes de b (jointure non qualifiée). Bref, c'est un peu du même niveau que select * from a,b sans aucune condition, ça renvoie forcément beaucoup de lignes et ça prend tout plein de temps, de mémoire, tout ça. Bref, sauf cas très particulier, il est vraisemblable que ta requête soit fausse. Soit il manque là aussi un a.champ=b.champ, soit dans ce cas-là tu ne veux que les valeurs de a et tu ignores celles de b et dans ce cas il vaut effectivement probablement mieux faire deux requêtes séparées (tu dois pouvoir t'en tirer avec un UNION, mais ça va compliquer la requête). Jacques.

Si c'est un problème de place, tu peux avoir un fs qui se remplit puis se vide un peu, puis se remplit, etc, et tu pourrais avoir tiré des conclusions incorrectes sur pourquoi tel ou tel mail passe ou pas. Il y a aussi la possibilité que suivant ta config exacte, différents mails passent à différents endroits (queue d'entrée de scanner anti-virus/anti-spam pour les mails externes mais pas les mails internes par exemple). Voire même que tous les mails ne passent pas par les mêmes serveurs suivant les cas. Comme on n'a aucune idée des domaines, du ou des serveur(s) impliqués, du serveur de mail (sendmail, postfix, qmail... a priori le petit extrait donné précédemment indique postfix, mais on ne sait toujours pas si c'est ton serveur qui dit ça), de sa version, de sa config, ou quoi que ce soit d'autre, c'est quand même assez difficile de t'aider. Tu as regardé les logs (dmesg, /var/log/messages, /var/log/maillog) et l'espace libre (df)? Pour les mails qui "mettent beaucoup de temps", qu'indiquent les headers "Received"? Jacques.

Si c'est bien un message de ton serveur, tu as un problème: soit tu n'as plus de place (ou plus d'inodes disponibles) sur la partition utilisée pour stocker le mail, soit tu as un problème de droits, a priori. Jacques.

Il y a un certain % d'espace disque qui est réservé au super-utilisateur (root). Ca permet de faire que même si les utilisateurs remplissent tout ce qu'ils peuvent, root peut encore travailler. df t'indique l'espace libre pour le commun des mortels. Tu peux configurer le % réservé (c'est clair qu'avec les tailles des disques de nos jours, même 1% ça peut faire un paquet d'espace...) à la création (mkfs) ou par la suite (tune2fs a priori) avec le flag -m. man tune2fs est ton ami. Jacques.

Elle m'a l'air un peu bugguée cette classe, mais j'ai pas regardé de si près que ça. Et tu l'appelles comment? Jacques.

Comme on n'a aucune idée de ce que tu utilises pour envoyer ton mail, ça va être dur dur de t'aider. Mais clairement tu as un problème d'UTF-8 qui est considéré comme de l'ISO et donc converti en UTF-8 (deux fois!). Les headers doivent être en "ASCII pur" aka "7 bits", donc tout "ce qui dépasse" doit être encodé, avec indication du charset, du mode d'encodage (B pour base64, Q pour quoted-printable). Dans ton exemple, le texte est encodé en base64 avec un charset UTF-8. Jacques.

Qu'il y a beaucoup de processus httpd (Apache), ce qui est normal (cf MaxClients dans ton httpd.conf) et qu'on savait déjà. Jacques.

Ben timestamp+hash via un paramètre de l'URL ou un cookie, généré par la page principale et vérifié par les pages de fiches. Mais ça ne va pas compliquer grand chose pour quelqu'un qui serait un minimum motivé. La seule façon d'éviter les robots à coup sûr c'est un captcha ou équivalent. Jacques.

Quoi qu'il arrive, à partir du moment où n'importe quel utilisateur peut lire le contenu avec un browser, c'est reproductible avec un robot (à moins de mettre un captcha juste pour lire les pages...). Tout ce que tu peux faire c'est compliquer le boulot de ceux qui veulent le lire avec un robot, mais ça ne va pas beaucoup plus loin. Et certaines mesures que tu peux prendre peuvent avoir des effets secondaires désagréables: outre le fait que les moteurs de recherche ne pourront pas indexer ton contenu comme déjà évoqué (mais il semblerait que ça ne te gêne pas), le blocage par referer est non seulement facilement à contourner, mais en plus peut bloquer des utilisateurs légitimes: il y a pas mal d'outils (firewalls, anti-virus, "outils de protection de la vie privée"...) qui les suppriment, les transforment, etc. Ne pas oublier non plus de permettre aux gens d'utiliser des bookmarks ou leur historique pour revenir directement à la bonne page. Un truc que tu peux faire (mais qui, comme toutes les autres solutions, ne va pas bloquer tout le monde, et qui n'est utilisable que dans certains cas de figure), c'est d'utiliser des cookies. Tu mets le cookie (qui pourrait contenir un timestamp et un hash basé sur ce timestamp et une clef) sur certaines pages, et tu vérifies sur d'autres avant d'afficher. Surtout utilisable pour protéger des images plutôt que des pages entières, mais c'est utilisable si tu sépares page et contenu via Ajax. Jacques.

Donc ta machine ne glande rien ou presque l'essentiel du temps, et puis tout d'un coup il se passe un truc qui fait que tout plein de processus httpd se mettent à consommer du CPU à tour de bras. Comme ça concerne tout plein de processus, deux solutions: - il y a quelqu'un qui te balance tout d'un coup énormément de requêtes "lourdes" (une DoS ou DDoS volontaire ou involontaire) - il y a un bug dans IPB qui fait qu'il part en vrille quand il se produit un événement précis (et ça affecte tout plein de processus). Le premier cas de figure ne me paraît pas spécialement vraisemblable au vu des server-status, mais on ne sait jamais. Le deuxième serait dans un bout de code qui fait appel à un "état" commun, par exemple l'affichage de la liste des connectés ou des derniers messages ou un truc du genre (je ne connais pas assez IPB pour savoir s'il y a d'autres choses comme ça). Que s'est-il passé entre 21:37:01 et 21:37:02? La liste des requêtes dynamiques vers cette heure-là pourrait aider à trouver le coupable, mais je pense qu'il faut vraiment rentrer dans le code IPB et l'instrumenter (mesurer le CPU consommé par les différentes parties du code) pour trouver le problème exact. Et comme le source n'est pas dispo librement, pfff... Jacques.

Les données collectées précédemment montrent clairement que le problème vient des processus Apache qui exécutent les requêtes dynamiques (pages php). Mysql consomme peut-être, mais ce n'est pas lui le fautif (en tous cas dans les cas de figure que tu nous a montrés). Je ne connais pas prm, et j'ai quand même l'impression qu'il réagit "un peu vite", et pas forcément de façon justifiée... C'est quoi ses paramètres de déclenchement? Dans les enregistrements de top, je ne vois aucune raison valable qu'il se déclenche, tu n'aurais pas un truc genre "si httpd a plus de 300 process, kill" alors que tu as un MaxClients beaucoup plus élevé? Sur tes top, on voit bien que l'essentiel du temps ça consomme très peu de CPU (d'ailleurs tu devrais taper "i" pour n'afficher que les processus actifs et "s" puis 1 et return pour avoir un affichage plus "rapide"). Si c'est comme ça tout le temps et soudainement ça part en flèche (plutôt que d'être pas loin de saturer les CPU, puis de les saturer), c'est qu'il doit y avoir un problème dans le code IPB qui fait que soudainement les requêtes mettent beaucoup plus de temps à s'exécuter (temps CPU, donc php, pas mysql), ou alors un problème de nombre de requêtes/seconde qui explose (soit parce que quelqu'un t'en balance soudainement beaucoup plus, soit parce qu'il y aurait par exemple une boucle de redirections ou un truc du genre). Jacques.

Perso, ça me paraît douteux. Le changement de MaxRequestsPerChild doit avoir un effet vraiment très très négligeable (genre 0.02% de CPU en moins). Pour le .htaccess je suis dubitatif, mais ça dépend vraiment de la sauce interne de IPB. Le problème c'est vraiment que tu satures en CPU. Ce qui est bizarre c'est que ça semble passer de très calme à super saturé en peu de temps, ce qui veut probablement dire qu'il y a un bug quelque part dans IPB qui se déclenche dans certaines circonstances. Moi je serais toi, la première chose à faire c'est superviser (grapher) l'utilisation CPU. Histoire de voir si c'est tout calme et que ça monte d'un coup, si c'est souvent à la limite de la saturation, si ça augmente progressivement... Jacques.

Les comms Paypal baissent avec le volume... Et si tu as peu de volume, ils ont l'avantage par rapport à beaucoup d'autres solutions qu'il n'y a pas de frais fixes. Jacques.

J'ai testé depuis plusieurs serveurs et smtp.live.com accepte bien les connexions sur le port 25 sans problème. Donc soit ils t'en veulent à toi particulièrement, soit c'est ton hébergeur qui bloque (mais dans ce cas-là tu aurais en général plutôt du "Connection timed out" que du "Connection refused", et j'ai testé depuis des machines chez OVH et Dedibox sans souci), soit via le load-balancing qu'ils doivent avoir, tu tombes sur un serveur particulier qui a un problème, et en attendant un peu tu devrais tomber sur un autre qui fonctionne. Je suppose que tu n'as le problème qu'avec live et que les autres fonctionnent? Jacques.

Euuuuuuhhh... Ce script, tu le fais tourner sur quelle machine? Un serveur hébergé quelque part? Et l'adresse du From n'est pas une adresse Live.com? Si les deux sont exacts, pourquoi est-ce-que tu utilises un serveur live.com, qui visiblement ne veut pas entendre parler de toi? Pour envoyer du mail, tu dois normalement utiliser le serveur SMTP de ton FAI (ton hébergeur, a priori, dans ce cas), qui relaiera à destination. Tu peux éventuellement dans certains cas utiliser le serveur SMTP associé à ton adresse d'expéditeur, mais il faut que tu t'authentifies pour ça, et dans certains cas il peut y avoir des filtres qui t'en empêchent. L'autre alternative (et probablement la meilleure) dans le cas d'un serveur, c'est d'utiliser ton propre serveur SMTP, soit en te connectant en local, soit, et c'est la meilleure solution, en utilisant le client sendmail sur ta machine. Jacques.

Utilise plutôt JW Player: http://www.longtailvideo.com/players/jw-flv-player/ il te permettra d'utiliser des playlists (et beaucoup, beaucoup d'autres choses). Jacques.

Je pense que c'est plutôt un truc à la recherche universelle de Google, et ils affichent des résultats "locaux" issus de sites de critiques, avec note, distance, prix moyen, etc. Sur Google par ici c'est plus "intelligent", il y a l'adresse, le numéro de téléphone et la carte :-) Sur Google JP tu vois d'ailleurs qu'avec la même requête, le résultat en question apparaît avec les petites étoiles de la note, mais pas d'image ou quoi ce que soit d'autre, le snippet est "standard". Après je ne sais pas si les sites en question sont reconnus automatiquement par l'un ou l'autre ou s'il s'agit de sites particuliers avec qui Yahoo ou Google ont passé des accords? Jacques.

Normal qu'il n'y ait rien de suspect côté mysql, c'est vraiment dans l'exécution des scripts php que le problème se situe a priori. Les deux bouts de scripts donnés ci-dessus devraient être utilisables tels quels, mais je ne les ai pas testés, et je ne programme même jamais en php en fait. Ceci dit, à part une coquille de syntaxe qui pourrait empêcher l'exécution du script, ils ne devraient pas avoir d'effet retors. Teste-les sur une copie d'un des fichiers php IPB d'abord avant de mettre en ligne... Par contre si tu n'as pas l'habitude grep, sed, awk, sort ou perl, tu risques d'avoir du mal à extraire quoi que ce soit de bien intéressant des logs que ça va générer... Jacques.

Moi je comprends plus grand chose... Tu es root, mais ton hébergeur te fixe des limites? C'est quoi comme hébergement? Pour moi il n'y a des limites que sur un mutualisé, et si tu es root, tu es forcément soit sur un dédié soit sur un virtuel, et ça devrait être pareil: pas de limites. Ensuite, comment est-ce-que tu mets ton processus en cron? Comme déjà dit, la bonne idée c'est de le mettre dans le crontab d'un utilisateur lambda via crontab -e, plutôt que dans le crontab système. Aussi, tu n'as pas dit si le script exécuté directement en ligne de commande (avec le même utilisateur que celui utilisé pour le cron) fonctionne ou pas. Jacques.

Ach... Brick and mortar, donc. Dans ce cas c'est vraiment comme le propriétaire des murs de n'importe quel comme commerce, ou même le propriétaire de l'appartement de quelqu'un: tant qu'il n'a pas de raison évidente de soupçonner/savoir qu'il se passe quelque chose de manifestement illégal, je vois difficilement comment il pourrait être impliqué. Evidemment le contrat de bail se fera un devoir de préciser que le locataire n'a pas le droit d'utiliser les locaux pour des activités illégales, même si c'est probablement redondant. Jacques.

Euuuuh... C'est quoi une boutique IRL? Jacques.

Normalement avec ce nombre de pages vues, même en comptant un trafic très concentré (genre en comptant tout ton trafic de mardi en une heure), ça devrait largement tenir, à moins qu'il y ait des requêtes qui prennent réellement beaucoup plus de CPU que les autres. Bref, il s'agit de tracer qui bouffe du CPU et pourquoi, un sale boulot... Tu peux commencer par mettre dans chaque script (éventuellement via un include) un truc du genre: - au début: $save_getrusage = getrusage(); - à la fin: $final_getrusage = getrusage(); error_log("CPU for ".$_SERVER['REQUEST_URI'].": ". ($final_getrusage['ru_utime.tv_sec']*1000000+ $final_getrusage['ru_utme.tv_usec']- ($save_getrusage['ru_utime.tv_sec']*1000000+ $save_getrusage['ru_utme.tv_usec']))); Tu devrais alors te retrouver avec une ligne pour chaque requête qui te dit le CPU utilisé. A partir de là tu peux commencer à chercher les pages/scripts qui bouffent le plus. Une fois que tu les as trouvés, tu peux ajouter des traces comme celles ci-dessus autour de différentes parties du script pour voir combien chacune consomme. On trouve quelquefois des choses toutes bêtes qui bouffent beaucoup pour pas grand chose. Tu n'utilises pas bbclone au moins j'espère? C'est un CPU-hog assez sauvage dès que tu as un petit peu de trafic... Jacques.

La bonne solution pour un formulaire, c'est d'utiliser le même script pour l'affichage et le traitement. Le script a alors une structure de ce genre: si (formulaire_a_ete_soumis) { verifier formulaire, stocker les erreurs éventuelles pour chaque champ si (pas d'erreurs) { traitement redirect vers autre page } } afficher formulaire avec valeurs déjà soumises ou valeurs par défaut et erreurs éventuelles (formulaire doit contenir un input hidden qui va permettre de faire le test formulaire_a_ete_soumis) Ca évite de stocker tout plein d'infos dans des sessions (ce qui va faire des choses bizarres quand l'utilisateur va remplir le même formulaire par la suite, voire une autre si tu as des noms de variables communs), ça élimine les problèmes de fenêtres multiples, ca te permet d'avoir le formulaire et les erreurs à corriger sur la même page (et même de mettre l'erreur à côté du champ saisi)... NB: après un POST (ou un GET qui ne serait pas idempotent, i.e. qui a un effet plutôt que juste un affichage), il est toujours utile de faire un redirect vers une page idempotente, ça évite les problèmes avec les reloads éventuels (qui vont remettre des choses en base, renvoyer un nouveau mail, que sais-je...). Jacques.