Kioob

Hello, tu cherches les "datacenters" ou bien les sociétés qui louent des serveurs dédiés ?

Justement ce n'est pas son site

Ubuntu a pas mal de points commun avec Debian oui, mais est généralement plus proche d'une Debian testing/unstable (sic...) que d'une stable ; mais je ne saurais dire quelle différence il y a entre leur version desktop et leur version serveur. Je n'en sais pas plus, désolé.

Aïe, effectivement quand on a été échaudé par un hébergeur, difficile de lui accorder à nouveau sa confiance Je comprends également ton envie de te débarrasser de Plesk : j'en ai fait des cauchemars pendant deux ans Sinon pour donner quelques pistes, en partant d'une debian "nue", dans les grandes lignes (ou pas) quelques conseils (en vrac évidement ) : - configurer la langue/charset de la machine si nécessaire : dpkg-reconfigures locales ; c'est tout bête, mais je suis déjà tombé sur des machines en allemand et ce n'était vraiment pas pratique. - s'il s'agit d'une distribution 32bits et que le processeur est au moins un Pentium II (lol...), s'assurer que le paquet libc6-i686 soit installé (ça ne mange pas de pain, et c'est toujours ça de gagné). Pour le moment on va éviter de changer le kernel, mais dans l'idée : aptitude search linux-image-2.6 pour voir la liste des Kernels pré compilés proposés par Debian. - Pour sécurisé un peu la connexion SSH il y a plusieurs écoles : 1) bloquer l'accès via root, pour forcer la connexion via un user sans privilèges particulier, et de la basculer en root (ou utiliser sudo). 2) interdire l'accès root via mot de passe (imposer l'utilisation d'une clé SSH donc). - Chacun verra ici midi à sa porte je pense, pour ma part je préfère la deuxième solution. Penser à limiter les logins autorisé et changer le port par défaut peut également être pratique : ça ne changera pas forcément grand chose d'un point de vue sécurité, mais ça peut permettre de faire la différence entre une vrai "tentative d'accès" et un simple scanneur... - Consulter régulièrement la boite mail "root" (ou bien la re-diriger vers une boite consultée, cf /etc/aliases ) - smartmontools pour surveiller la dégradation des disques... pas compliqué à mettre en service, et peut vous éviter de bien mauvaises surprises - configurer ses repository APT : il doit y avoir au moins le "security" dans la liste, ainsi que le "versatile" si vous utilisez un anti-virus. Après pour le miroir, à vous de choisir : j'aime personnellement bien ceux de Proxad, rarement en rade ; et n'aime pas ceux d'OVH (il manque toujours des paquets dessus :S) ni de Sivit (pédale très souvent). - prévoir un cron pour vérifier régulièrement les mises à jour (cf le paquet apticron par exemple). - Un outil de surveillance des logs peut être pratique : logcheck fait ça très bien par exemple ; il envoi à root (par défaut) toutes les heures (et à chaque reboot) tout ce qui lui semble suspect dans les logs systèmes (à ajuster toutefois...) - Coté firewall c'est généralement netfilter qui se charge de cela (il fait partie du noyau nunux) ; toutefois l'usage n'est pas forcément aisé, donc un "front end" pour le configurer peut être le bienvenue. Par exemple : shorewall. - Le MTA (qui gère la distribution des emails) est mine de rien très important sur la machine (ne serait ce que par le fait que la plupart des alertes sont envoyées par email). Là c'est plutôt délicat car pas évident à appréhender à mon goût. J'ai personnellement opté pour Exim (par défaut sous Debian), mais beaucoup lui préfèrent Postfix. Dans tous les cas, il faudra en prendre bien soin. - Mise à jour automatique de l'heure => aptitude install ntp-server Ça je dirais que c'est ma procédure systématique pour chaque machine "web" ; après toujours en vrac : - coté Apache : bien penser à désactiver les modules qu'on utilise pas (a2dismod / a2enmod sont tes amis) - coté PHP : deux grands mode de fonctionnement : en CGI + FastCGI + le MPM event d'Apache (robuste, monte bien en charge, mais plus lent) ; en module + eAccelerator + MPM prefork d'Apache (très rapide, mais assez sensible aux pics de trafic) - MySQL : les réglages par défaut visent le 64Mo de mémoire je crois ; je pense que votre machine en a bien plus que ça Ne pas hésiter à consulter la doc de MySQL pour comprendre le rôle de chacun. - résolution DNS : pour accélérer les résolutions DNS, un cache local est vivement conseillé ; quitte à faire en sorte de rediriger les requêtes vers le récurseur de votre hébergeur. Grosso modo ça donne déjà une relativement bonne base je pense. Le tout est ensuite de creuser pour comprendre le fonctionnement de tout cela. Le site "Debian-Administration.org" peut d'ailleurs être de bon conseil.

Hello, malheureux, ce n'est pas une mince affaire tout ça. Bon procédons par étape, mais soyons clair tout de suite : ceci n'engage évidement que moi. La distribution : la Debian est effectivement "simple" et "efficace", en contrepartie c'est loin d'être la plus souple justement. Elle est au contraire plutôt stricte, claire, "propre". Ca ne veut pas dire qu'il est impossible de recompiler les paquets, ni d'ajouter des applications/extensions "compilée" par ses soins ; mais elle n'est pas vraiment orientée en ce sens. Par exemple la version "zts" de PHP n'est pas fournie sous Debian ; et en standard le seul cache d'opcode dispo est APC. Une chose aussi à vérifier : quand on choisit Debian sur un serveur, pour moi c'est parce qu'on cherche une machine stable et robuste au fil du temps ; et on accepte donc de ne pas avoir le dernier joujou à la mode. Si c'est pour installer 36 backports non officiels qui sortent les paquets aux rythmes des applis officielles sans le moindre test, autant passer en "Debian testing", avec ce que ça implique.... ou bien choisir une distribution qui mise sur la fréquence d'actualisation. Pour le prestataire, à mon avis tu devrais commencer par un VDS pour te faire la main (Sivit ?) ; tu as de grandes chances de faire pas mal de bétises au début. Et puis si tu as un soucis, autant avoir un support capable de te répondre ; et qui utilise d'ailleurs Debian depuis des années. De manière générale, je te conseillerais de commencer par lire un peu, un ouvrage du genre "Debian Etch" (Les cahiers de l'admin, chez Eyrolles) est déjà un bon départ. Sur un serveur dédié il y a tout un tas de notions à maîtriser. Ce n'est pas en faisant bêtement un copier/coller de tutos qu'on s'en sort, il faut comprendre et adapter. Sinon tôt ou tard on se retrouve avec des soucis (stabilité, sécurité, etc). Ah et aussi : le clustering, ça ne se fait pas en 2 clics. Commence par découvrir la distribution, et d'ici quelques mois/années si le coeur t'en dis toujours tu te pencheras là dessus. Bon courage en tous cas PS : un conseil en passant, préférer "aptitude" à "apt-get" : il gère beaucoup mieux les conflits et les dépendances que "apt-get" et la syntaxe est quasiment la même, donc autant ne pas se priver.

Hello, si tu fais ton dump depuis "mysqldump", il s'agit d'une simple option : --default-character-set=name Set the default character set.

Peut être qu'en commençant par regarder dans le log d'erreur Apache tu auras un début d'explication Ensuite si tu as une extension qui modifie le comportement de PHP, vire la pour le moment (eaccelerator, apc, xcache, etc).

Hello, PHP 5.2.x est quand même sorti depuis longtemps, si un script ne fonctionne pas avec j'aurais tendance à penser que le script est buggé... donc autant le corriger non ? Enfin, sans plus de détail, on ne pourra pas t'aider.

J'ai retrouvé, il s'agit de Savant ; j'ai juste survolé je ne sais pas du tout ce que cela peut donner.

Hello, les moteurs de template sont quelque chose de relativement "délicat" à développer, surtout si on veut tenir compte à la fois de la sécurité et des performances. Comme ci dessus, je te conseille vivement d'utiliser un moteur existant ; même s'il est vrai que chacun a une syntaxe particulière, ou presque. Smarty "réinvente" un second langage, très riche, et perso je n'aime pas du tout cette approche. Je préfère nettement un Flexy qui est limité a quelques commandes et s'intègre plutôt bien dans du HTML. Il y a aussi un moteur de template qui reprend exactement du code PHP : ce peut être une idée, mais j'ai oublié son nom :$ (je vais essayer de retrouver ça). Une autre serait d'utiliser le framework Symfony, qui utilise un langage très très proche de PHP, mais pour le coup utiliser le framework implique beaucoup de changements....

Dan : c'est une méthode de sécurité de plus en plus répandue ; même si pour ma part je la trouve totalement bidon. Le principe est le suivant : à chaque page l'internaute/membre change d'ID de session, il est donc plus difficile pour un pirate de voler la session courante. Sur le principe, je suis 100% d'accord, la fenêtre de "vol" passe de 30 minutes à 2 minutes environ. Sauf que : *) pour cela il faut passer le paramètre "true" à session_regenerate_id, sinon l'ancienne session n'est pas désactivée ; ce qui veut dire qu'au lieu de limiter les risques de vol de session, tu les augmentes très très fortement. *) ça ne fonctionne pas si bien que ça, la plupart des navigateurs peuvent gèrer plusieurs connexions simultanément, et lorsque la requete A reçoit le nouvel ID de session il est parfois trop tard car la requete B est déjà "partie". Cette fameuse requete B n'a donc pas le bon ID de session et l'internaute (pourtant légitime) se fait déconnecter. C'est particulièrement vrai dès lors qu'on utilise les sessions dans des fichiers "externes" à la page (images, CSS, JS, tag de stats, frames, etc) ; ou tout simplement en cas de redirection (la fameuse redirection 301/302, dont beaucoup de navigateurs ignorent le dépot de cookie). Pour ma part pour vraiment sécuriser cela j'utilise le système de "double ID", qui a au moins l'avantage de ne pas avoir ce genre d'effet de bords.

Exact : ça fait des années qu'on le dit, mais les gens sont tétus Utiliser un mécanisme avec "grain de sel" n'est pas tellement plus compliqué, et évite ce genre de soucis (cf la fonction crypt() ).

Hello, en tous cas ton "key_buffer_size" est très petit... j'aurais tablé sur du 1Go vu ta mémoire et la taille de la base. pour t'aider à ajuster ce genre de trucs, phpMyAdmin affiche un récapitulatif relativement intéressant dans "Etat du serveur".

Hello, si tu as un serveur dédié, en activant le paramètre "log-queries-not-using-indexes" de MySQL te permettra justement de tracer ces requetes (elles seront intégrées au log des "slow_queries"). En gros il faudrait ces 3 paramètres : log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 1 log-queries-not-using-indexes Le chemin du fichier de log est évidement à adapter selon ton système.

Hello, c'est une solution oui... attention toutefois aux pannes temporaires, et éventuelles redirections. A mon avis, à n'utiliser que pour prévenir l'admin mais certainement pas pour une suppression automatique.

Sinon : les deux La base de données en "back end" pour sa souplesse de maintenance, et un/des fichier(s) de cache contenant le tableau qui t'intéresse (serialize/unserialize) pour les performances.

Hello, une petite suggestion éventuelle : de toutes façons utiliser un cookie contenant un ID (MD5, voir SHA1 ?), et seulement si celui ci n'existe pas recalculer un nouvel ID à partir de : l'IP, le USER_AGENT, la résolution d'écran si tu peux l'obtenir. Mais c'est loin d'etre parfait : - il y a toujours possibilité de doublon (AOL...) - le USER_AGENT peut être changé par le proxy, et donc changé à chaque page ; certains plugin changent aussi le user agent à chaque page et/ou démarrage - la résolution d'écran n'est chopable qu'en JS, et peu également varier pour un même internaute - si une personne parano efface ses cookies régulièrement et n'a pas d'IP fixe, tu perdras quand meme sa trace - si une personne n'accepte pas les cookies et utilise un proxy changeant d'IP à chaque page, tu n'arriveras jamais à le tracker Dans le cas d'un cyber café ou d'une entreprise avec proxy, tu auras quand même de très très grandes chances de considérer tout le monde comme un seul "internaute". Mais impossible à différencier, si ce n'est via les cookies justement.

Hello, en tous cas les 13 serveurs DNS gérant le ".com" sont unanimes : les DNS sont ns6.oleane.net et ns7.oleane.net . Et d'ailleurs, le whois répond la même chose. Bref : aucun changement de DNS n'a été fait. Edit : ahhh je viens de comprendre, le domaine est toujours chez Oleane, mais il pointe chez OVH Dsl, donc oui ça, ça fonctionne

En fait MySQL est très "tolérant" sur ce point, ce qui peut amener à des incohérences Par contre lui au moins il continue à utiliser les indexes avec les vues.... comme Oracle d'ailleurs. Je n'ai jamais testé les vues sur SQL Server en fait. D'un point de vue "performances", le champ "id" a beaucoup plus de chance d'être indexé que le champ "nom" ; donc j'aurais bien laissé comme ça

Petites remarques sur la première requete : ne faites des "LEFT JOIN" que lorsque c'est necessaire, de plus ici un count(e.id_ville) sera surement plus efficace. SELECT v.Nom, COUNT( e.id_ville ) AS Nombre FROM villes v JOIN etablissements e ON e.id_ville = v.id_ville GROUP BY v.id_ville HAVING Nombre > 10 Reste à vérifier le résultat avec un EXPLAIN, mais sur ce genre de requete je suppose que la différence doit être assez importante ; enfin en supposant qu'il y ai un minimum d'indexes sur ces tables. Et si ton nouvel employeur a poussé le luxe jusqu'à MySQL 5, tu peux aussi tenter les vues (avec modération évidement)

En meme temps rien ne dit qu'il ait bloqué vraiment "tout OVH" : il suffit de bloquer les 4/5 IP servant aux clusters mutualisés, et ça touche déjà énormément de sites.

Pour le coup j'ai du mal à voir pourquoi une version bloque le script, si le formulaire est considéré comme identique. Sur la debian, il n'y aurait pas l'extension suhoshin d'installée ? Pour ce qui est de ton script, en gros tu essayes de recopier à l'arrache le contenu de $_POST dans l'environnement global non ? Si c'est bien le cas, quel est l'intérêt, mis à part les soucis de sécurité ?

La requete SQL en question, tu peux la lancer depuis phpMyAdmin par exemple, voir depuis un script PHP... mais dans tous les cas il faudra bien à un moment ou un autre se connecter à MySQL oui

Hello, comme tu l'as dit toi même, cron est l'idéal, et sert justement à ça Si tu n'y as pas accès (selon l'hébergeur...), tu peux toujours utiliser le service Webcron, qui est un excellent palliatif. Enfin une autre solution est de configurer le MTA pour mettre les emails en queue directement plutôt que de chercher à les envoyer aussitôt ; mais si tu n'as pas accès aux crons tu n'as certainement pas accès à ça non plus

Hello, la première chose à faire à mon avis est : var_dump( $_POST ); Il s'agit là de la base du débugage Ainsi tu verras quelle "tête" ont tes données sur l'un et l'autre des serveurs.