Kioob

Et bien à vue de nez les champs de formulaires ne sont pas du tout protégés, donc oui, ton site servira à spammer à tout va... et l'IP de la machine sera donc très très vite blacklistée.

Et bien commence à faire un "phpinfo();" pour voir s'il est actuellement activé (dans la colonne "Local", pas "Master"). S'il est activé, pour le désactiver tu as plusieurs méthodes, dépendantes de ton hébergeur... La plus simple étant de mettre "php_flag register_globals off" dans un fichier ".htaccess" à la racine du site. (mais comme expliqué dans un autre sujet, selon les hébergeurs cette méthode ne fonctionnera pas forcément : tu peux toujours demander au support de ton hébergeur, il sert aussi à ça )

Hello, déjà : est ce sur un hébergeur mutualisé ou un serveur dédié ? Es tu certain que ton code est suffisamment protégé contre toute exploitation malveillante ? (typiquement, injection d'entêtes SMTP). Yahoo a une politique anti spam très stricte (c'est meme certainement un des plus stricts), et il y a donc pas mal de choses à mettre en place afin d'acheminer correctement les mails vers leurs serveurs. Eventuellement, peux tu faire un copier/coller d'un des mails en question, y compris les entêtes du mail ?

Hello, une première chose à faire serait de désactiver "register_globals", si ce n'est pas déjà fait. Après, à moins que tu veuilles toi même corriger ce code mal fichu, je te conseille d'attendre la mise à jour officielle.

Il faudrait commencer par voir si PHP est installé en tant que module Apache ou non... Ces fameuses options php_value et php_flag ne sont disponibles que dans ce mode. Or s'il s'agit d'un hébergement mutualisé, c'est loin d'être le mode le plus sécurisé. Du coup l'hébergeur opte souvent pour du (Fast)CGI, ce qui permet pour le coup de mettre en place un fichier "php.ini" différent pour chaque client. Donc rien d'anormal à tout ceci, au contraire même

Béh... sur le serveur d'un client on a été obligé d'augmenter le memory_limit, rien que le script d'installation dépassait les 16Mo de consommation, sans le moindre module supplémentaire

Je débarque un peu après la bataille, mais je voulais donner un peu mon avis sur tout ça Je suis passé en Debian 64bits il y a quelques années (été 2005 à priori) et gère maintenant plus d'une vingtaine de machines en 64bits. Comme le dit Dan généralement ça fonctionne très bien, c'est très performant, tout ça tout ça. Le seul hic rencontré, c'est pour les quelques applications non opensource qui ne sont distribuées qu'en binaire... dans 90% des cas seule la version 32bits est fournie, et pour le coup la compatibilité est loin d'être assurée. C'est notamment le cas de certains outils de gestion RAID hardware signé Adaptec il me semble. Sur toutes mes machines je n'en ai qu'une concernée, mais c'est assez génant. Pour ce qui est de la compatibilité avec les scripts PHP, mis à part la tentative de cluster mixant du 32bits et du 64bits, je n'ai jamais rencontré le moindre soucis. Pour ce qui est de la différence de performances avec une Gentoo, je pense qu'elle est nettement moindre en 64bits justement : une Debian 32bits est effectivement compilée de manière à fonctionner sur du vieux matos, et n'utilise donc pas les "instructions récentes" ; mais ça n'a évidement pas lieu d'être en 64bits la machine "minimale" compatible étant l'Athlon64. Et pour les fanas de la recompilation, il reste la solution "apt-build". En tous cas très peu pour moi, et ce n'est franchement pas là dessus que tu gagneras sensiblement en performances. Niveau applicatif, y a pas de miracle : n'installer que ce qu'on utilise, point barre. En vrac, et non exhaustif : SSH, Apache, PHP, mySQL, et un MTA (serveur de mail en gros), sans oublier quelques outils d'administration que tu peux vouloir utiliser, du genre smartmontools, logcheck, et autres outils du genre. Mais déjà ça laisse pas mal de choix : rien que choisir le MPM d'Apache (ou lighttpd ?), les modules qu'on lui colle derrière, le mode de fonctionnement de PHP, un éventuel cache d'opcode, ça fait pas mal de choix que personne d'autre que toi pourra faire. C'est souvent affaire de gouts, habitudes et compromis. Coté "matos conçu pour serveur", il suffit de regarder ce qu'utilisent les hébergeurs low cost : il s'agit souvent de matériel commun (dont des cartes mères Asus/Gigabyte/Intel d'entrée de gamme) comme on trouve dans un PC à Carrefour En tous cas bon courage

Le plus simple à mon avis pour connaitre ces limitations est de demander à MySQL directement : mysql> show variables like 'max%connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | max_connections | 200 | | max_user_connections | 50 | +----------------------+-------+ 2 rows in set (0.00 sec) Le max_connections est la limite globale, pour tout le serveur, et le max_user_connections la limite pour ton login en particulier. Nota : je précise que les limites indiquées ici sont celles sur l'un de mes serveurs, pas 1and1

Hello, à ta place je commencerais par tester depuis un shell directement (via SSH quoi). Tu auras peut etre des erreurs un peu plus parlantes...

Bonsoir, plusieurs hébergeurs utilisent OTRS, mais voici une petite liste (non exaustive) : http://en.wikipedia.org/wiki/Comparison_of...racking_systems

Hello, pourquoi cette contrainte "ridicule" de 3 lignes, en dehors d'un exercice scolaire ? Et le but c'est : 1) de détecter ce cas rapidement : et donc de partir d'une chute, sans vérifier avec le "futur" puisqu'il n'existe pas encore 2) de démontrer cette probabilité : de détecter tous les cas "historiques", afin d'établir une probabilité plus "fiable" ? EDIT : ça pourrait donner, à vue de nez quelque chose comme ça : select h.action, h.date, h.valeur, avg( p.valeur ) valeur_moyenne, max( f.valeur ) as valeur_futur from historique h join historique p on h.action = p.action and h.date > p.date join historique f on h.action = f.action and h.date < f.date where f.date < h.date + INTERVAL 2 YEAR group by h.action, h.date, h.valeur having h.valeur <= valeur_moyenne * 0.4; Je n'ai absolument pas testé, mais en gros ici la requete te sort tous les cas représentant une baisse en dessous de 40% de la moyenne des X années précédentes... et t'indique la plus haute valeur rencontrée durant les 2 années suivantes. A mon avis il faudrait également filtrer la moyenne : sur 10 ans elle n'est pas forcément hyper fiable... si c'est une action qui se gasse la gueule en permanence depuis 10 ans, l'interet est très limité non ? Enfin bref... à toi de voir.

Heureusement que non Dadou La solution de l'upgrade à la place de la réflexion, ce n'est que du court terme... coté SQL il vaut toujours mieux régler le soucis de performance que de tenter de le cacher en optant pour un serveur 4 fois plus cher... J'ai vu des traitements SQL passés de 8 heures à 2 minutes après le travail d'un "vrai" développeur... et ce n'est certainement pas un changement de machine qui aurait réglé ça. J'imagine bien un player DVD qui chercherait à charger les 4.7Go de la galette en mémoire pour lire le film : vaut il mieux corriger le code ou bien imposer 5Go de mémoire pour faire tourner le truc ? Coté SGBD, heureusement qu'on a pas attendu les "octos xeon avec 12go de mémoire" pour traiter les tables de quelques millions d'enregistrements

Hello, mysql_query() a la facheuse habitude de stocker en mémoire tout le résultat de la requete avant de poursuivre l'exécution du script... d'où cette forte consommation mémoire. mysql_unbuffered_query() ne fait pas ça, mais en contrepartie tu ne peux pas executer d'autre requete tant que tu n'as pas fini de lire le contenu du dernier SELECT. Bref, vu ton code actuel, ça ne collerait pas non plus. Visiblement, tu n'utilises que 2 des champs du select, donc tu peux déjà commencer par les lister dans ton select, plutot que de faire un "SELECT *" à la méthode "bourrin" Reste la solution de scinder la requete en plusieurs étapes : 1) chargement de la table via : insert into tatable ( ... ) select a, b from .... 2) puis tu complète les champs manquants par "petit paquet" : "select id from tatable where champacompleter is null limit 0, 1000" 3) boucle là dessus, à coup de "update tatable set champacompleter = XXX where id = N" Ce n'est pas forcément l'idéal non plus, mais sans plus d'indications sur ton traitement, je ne vois que ça. De manière générale, l'idée est d'en faire le plus possible via MySQL.... si tu peux faire tout le traitement sans avoir à balancer un seul "SELECT" coté PHP, ça ira certainement beaucoup plus vite, et sans consommer de mémoire.

Bonsoir, En tous cas pour ma part j'y réfléchirais à deux fois avant de désactiver cette "sécurité" : oui ce n'est pas une sécurité fiable à 100%, et oui on peut faire beaucoup plus sécurisé sans cette option. Toutefois la désactiver et ne pas la remplacer par autre chose c'est vraiment jouer avec le feu. En gros, avec le safe_mode activé, s'il y a une faille dans votre phpBB par exemple, le "pirate" pourra vraissemblablement effacer tout ce site ainsi que la base de données correspondante. C'est pénible, mais avec quelques sauvegardes c'est gérable. Sans le safe_mode, il aura accès à tous les sites et toutes les bases de données du serveur... et pour peu que le serveur ait lui meme une erreur de configuration, le dit pirate pourrait se retrouver avec l'accès complet à la machine. Pour un débutant je conseille plutot d'utiliser l'option "safe_mode_exec_dir", et d'y placer les quelques programmes qu'on veut autoriser (en plus souvent un simple lien symbolique suffira). Sinon l'idéal serait sans doute d'installer PHP en CGI, avec Fastcgi + mod_exec derrière... mais bon courage. (ça va être rigolo quand PHP 6 sortira tiens...)

Bonsoir, quel fonction ou librairie utilises tu pour envoyer ton email ? En théorie il ne devrait pas y avoir la moindre différence, donc j'aurais tendance à penser à une erreur coté "script". Pour ce qui est de la configuration de PHP, elle est plutot rudimentaire : sous Windows on indique un serveur SMTP à utiliser (car il n'y a généralement pas de serveur "local"), et sous Linux on indique le chemin d'accès au programme d'envoi de mail (directive sendmail_path). Difficile d'avoir une erreur de configuration là dedans.

Pour du HTML, je vois deux solutions : - readfile(), quitte à gérer un petit cache en local pour limiter la casse - rsync en cron, si toutefois tu y accès

Hello, comme le suggère allbizznet, un blocage coté firewall (iptables) aidera déjà bien. Ensuite, coté MySQL dans la gestion des utilisateurs tu as le champ "host" qui indique la provenance de l'utilisateur (son IP, ou bien son "hostname" selon le parametre skip-resolve). Tu peux donc facilement filtrer là dessus.

sarc : de manière générale si tu fais plusieurs deco/reco dans une meme "page", c'est que ton code a un sérieux soucis également Sinon pour le problème principal, il y a souvent plusieurs solutions : - les transactions : l'idéal, mais pas toujours évident à mettre en place - mieux gèrer l'ordre des requetes : selon la complexité du code, en replaçant le code dans un ordre différent on peut parfois éviter les problèmes d'accès concurrents. Mais, garde à ne pas se louper... - le lock : pour moi c'est la méthode "bourrine" par excellence, mais qui a au moins le mérite d'etre simple à mettre en place

Hello, en théorie oui, ça ralenti légèrement la machine : le kernel est plus "réactif" pour répondre aux besoins du serveur de jeu, mais du coup le kernel en lui même consomme un peu plus de "temps CPU" que sur un serveur classique (qui est généralement à 250Hz). Maintenant est ce que tu verras vraiment la différence ? Absolument pas. Par contre comme le sous entend Dan (enfin, je crois ), il y a des chances pour que ce ne soit pas la seule différence entre ces deux kernels OVH. Par exemple pour un serveur de jeu on active souvent la "préemption" comme pour un poste de bureau ; alors qu'au contraire pour un serveur elle est généralement désactivée. Dans tous les cas je pense qu'il vaut mieux avoir un kernel "optimisé jeu" et y faire tourner un apache, plutot qu'un kernel "serveur pur" et y faire tourner un jeu.

Pas à ma connaissance non : pour faire un "ini_set", il faut que ton script ait débuté, et si c'est le cas c'est "trop tard", les variables d'entrée sont déjà modifiées. Note : je viens de vérifier dans la doc, il était possible de modifier "ini_set" dans un script avant la version 4.3 de PHP. Mais ce n'est plus le cas désormais. Il reste néanmoins la solution du fichier .htaccess

Hello, je vais tenter d'éclaircir un peu tout ça vu que cela semble encore flou. Pour commencer prenons une requete SQL classique, faite au sein de PHP : $requete = "select nom, prenom, email from utilisateur where login = '$login' and password = '$password' "; Rien d'extraordinaire jusque là. Maintenant imaginons qu'un vilain visiteur ne saisisse pas un mot de passe classique mais quelque chose contenant des apostrophes... par exemple : toto' OR '1' ='1 On obtiendra donc la requete : select nom, prenom, email from utilisateur where login = 'bidule' and password = 'toto' OR '1' ='1' Et là aïe, ça coince : peu importe le mot de passe, la requête retournera un résultat. Et évidement, il y a bien d'autres possibilités. L'idée de départ des "magic_quotes_gpc" était donc de se protéger de cela. Sauf que cela pose deux soucis : premièrement, magic_quotes_gpc se contente de faire un bête un addslashes() sur toutes les données, ce qui est loin d'être suffisant pour se protéger des injections SQL. Et secondement, magic_quotes_gpc est bête et méchant : il fait un addslashes() sur toutes les données entrantes, alors qu'il est rare qu'elles ne servent qu'à produire des requetes SQL. Au final, pour vraiment se protéger d'une injection SQL on est donc obligés de faire un "stripslashes" (pour récupèrer la variable d'origine) suivi d'un mysql_real_escape_string (qui est la seule fonction échappant correctement les données pour MySQL). Galère non ? Sans oublier que si vous voulez utiliser votre variable pour autre chose qu'une requete SQL, il faudra également y aller à coup de stripslashes... Voilà pourquoi c'est supprimé de PHP 6 : les développeurs se croient à l'abri en utilisant cette "fausse sécurité" alors qu'il n'en est rien. Un comble non ? La solution ? Désactiver magic_quotes_gpc, et toujours penser à utiliser mysql_real_escape_string quand c'est nécessaire. Pour ce qui est de la portabilité du code, j'ai donc opté pour le contraire de la solution ci dessus : je fais des stripslashes sur toutes les données en entrée si magic_quotes_gpc était actif. Ainsi cela implique un traitement supplémentaire (le stripslashes) que sur les serveurs "mal" configurés (1). Cela donne par exemple : <?php if( get_magic_quotes_gpc() ) { gpc_walk( $_GET, 'stripslashes' ); gpc_walk( $_POST, 'stripslashes' ); gpc_walk( $_COOKIE, 'stripslashes' ); gpc_walk( $_REQUEST, 'stripslashes' ); } function gpc_walk( & $array, $fct ) { foreach( $array as $key => $item ) { if( is_array( $item ) ) { gpc_walk( $array[$key], $fct ); } else { $array[$key] = $fct( $item ); } } } ?> Voilou (1) dans le cas d'un hébergement mutualisé, où l'on ne contrôle pas les scripts utilisés par le client, activer magic_quotes_gpc reste malgré tout le meilleur choix à mon avis : - de toutes façons les scripts "bien fait" gèrent ça correctement - si le script n'en tient pas compte, il vaut toujours mieux avoir une sécurité relative (addslashes) qu'aucune.

en exagérant un poil : un "mono Xeon classique", est un P4 (il n'y a que la taille du cache qui change il me semble). un "P4 dual core" est censé être "presque" un Bi-P4, c'est à dire un Bi-Xeon donc... La différence ? les "communications" entre les deux coeurs du P4 sont relativement mal fichues, au contraire du Bi-Xeon. Mais je peux me tromper, ça fait un moment que je n'ai pas suivi l'actu de ce coté... (en tous cas un "bi opteron dual core", ça, ça tourne très bien )

D'un autre coté tu as plus de chances d'avoir un problème matériel sur un petit Celeron Low Cost que sur un vrai serveur quadri processeur avec raid hardware, mémoire ECC, alim redondante et autres joyeusetées. En tous cas, il ne me semble pas prudent de mélanger des forums publiques avec une régie publicitaire, que ce soit pour des raisons de performances (va expliquer aux sites pros affiliés que l'affichage des pubs est trop lent à cause du phpBB...) que pour des raisons de sécurités (intérêt à bien sécuriser le serveur pour être quasi sûr que si un forum se fait hacker la régie continue à tourner).... Et dans ce cas, si c'est une question de budget, prendre 2 VDS distinct peut être interessant

Hello, si tu prends un serveur dédié, tu y mets ce que tu veux... y compris PHP 5 et PostGre.

Je ne sais pas quel MTA tu utilises, mais sous Exim il faut déclarer "www-data" parmis les "trusted users". :/