Fabien a écrit 132 commentaires

Faut dire qu'il y a les "bons" contrôleurs RAID matériel et les "mauvais" contrôleurs RAID matériel, les bons sont ceux qui ... (je m'égare)

Ton argument pour le 'contre' est pertinent mais d'un autre coté, les "bons" contrôleurs RAID matériel apportent certains avantages qui ne pourront jamais être proposés par le software, je pense à la batterie intégrée au contrôleur par exemple.

Ca dot être faisable en quelques commandes shell :
- un premier grep sur "function" et quelques awk , sort ... pour lister les fonctions déclarées
- et ensuite un deuxième grep sur chaque nom de fonction pour voir où elles sont appelées

Le jour est j'ai voulu configurer ucarp sous linux, j'ai juste eu peur et je suis vite retourné à carp et son unique ligne de conf sous openbsd.

Je complète un peu la liste des softs cités dans ton lien :
- apache2 en reverse proxy avec le bon type de worker fonctionne pas trop mal et est, pour l'instant, le seul à avoir un "outil" tel que modsecurity
- en reverse proxy / load balancer, HAproxy est pour moi supérieur à nginx
- OpenBSD/PF + relayd (avec du trunk + carp + pfsync) est incroyablement efficace comme load balancer et injustement peu cité

J'ai déjà utilisé tous ces outils + varnish dans un même stack web et j'en étais entièrement satisfait.
L'intérêt pour nginx est sûrement dû à sa capacité de s'adapter à plusieurs usages mais il serait dommage de passer à coté des autres.

Je n'ai pas poussé très loin la comparaison mais nginx+php_fastcgi est plus rapide qu'un apache+prefork+mod_php pour servir du magento sur une de mes VM de dev.

Par contre, pas de modsecurity sans apache bien qu'il soit indiqué sur le site de modsecurity : "Trustwave's SpiderLabs is currently seeking community assistance with developing a port of ModSecurity for the Nginx platform." ce qui serai une bonne chose.

J'avais la même conf quand j'étais sous lenny.
Le passage à squeeze m'en a dégouté (la conf de slapd).
Si tu n'utilises ldap que pour le stockage des comptes mail, pourquoi ne pas passer à une base de données (mysql ou postgresql).

Je te paste le lien qui m'a permis de passer très rapidement de ldap à pgsql : http://wiki1.dovecot.org/HowTo/DovecotPostgresql

Même constat pour un forfait simple.
J'apprécie aussi le fait qu'ils me laissent tranquille avec mon forfait et ne m'appellent pas tous les 3 mois pour me proposer une nouvelle offre "qui va changer ma vie".

Je n'ai pas dis ça, j'ai juste expliqué ce dont je disposais sur une dedibox.
Mon souci est que je dois louer un serveur (à l'étranger) ne disposant pas de ce type de mode de secours (à la dedibox)ou de carte type DRAC.

Ca à l'air de fonctionner :

Grub2 en MBR qui utilise par défaut le choix 0 (boot de l'OS de secours).
Je me loggue et exécute 'grub-reboot 3 && reboot' (je demande à Grub2 de charger l'entrée 3 lors du prochain démarrage, ce qui correspond au chainload).
Reboot de la machine -> démarrage de Grub2 qui exécute l'entrée 3 -> chainload vers lilo qui se charge et démarre l'OS de prod.

C'est effectivement une solution envisageable mais ça ne m'enchante pas de faire tourner les VM sur un hôte source pas mis à jour (et je ne veux pas de système virtualisé). De plus, il faudra aussi faire attention de ne jamais mettre à jour le grub2 de l'hôte source.

Je suis en train d'essayer la solution que j'ai présentée dans une VM qemu/kvm et j'expérimente un souci, il est impossible d'installer grub2 sur une partition. Donc je vais tenter un grub2 sur le MBR et un lilo sur la partition root de mon OS de prod.

Je ne peux pas du tout toucher aux paramètres du serveur.

Pour l'instant, je n'ai pas trouvé de solution adaptée mais j'ai peut être une piste : - une petite partition sur laquelle je configure une distribution minimale. - grub2 installer en mbr. - d'autres partitions pour installer la distribution cible avec un grub2 sur sa partition bootable.

L'idée est de booter sur la distribution minimale et d'utliser grub-reboot "cible" avec "cible" permettant de chainloader le premier grub vers le deuxième grub.

C'est pas terrible, je ne mettrai jamais (ou très rarement et c'est mal) la distribution minimale et le grub principal.
Il n'y aura qu'un accès ssh très restrictif.
La procédure de boot sera donc plutôt longue, mais en cas de problème de la distribution cible et de son grub, je disposerai de tous les outils nécessaires en rebootant simplement le serveur.

J'ai dû utiliser ce système d'authentification forte "Two Factor" par RSA.
J'utilise encore ce type de token mais fourni par un concurrent de RSA.
En Libre, il semble que wikid fournisse aussi un système d'auth "2 factor", si quelqu'un connaissant/utilisant cette solution pouvait nous en faire un retour, ce serait sympa.

et le sondage, tu peux l'éditer ? -> "retRour"

Peut être aussi grace à Nginx, ce qui expliquerai le chargement des images plus fluide ...

Il est très difficile de répondre pour plusieurs raisons et l'une d'elle est que tu ne donnes pas assez de détails.
Si je résume l'énoncé de ton problème j'ai seulement :
- serveur web
- 50000 users (visites ?)

Ca fait peu de paramètres et il manque une donnée importante en relation avec les 2 que tu nous donne :
- combien de visites simultanées ?

c'est 50000 visites simultanées, à la seconde ou sur une journée ?

Utiliser une Sid en prod n'est pas recommandé.

Mais php 5.3.3-6 est aussi la version php de Squeeze.

Donc avec cette seule information, on ne peut déterminer la version Debian utilisée (si s'en est une).

J'ajoute : "tant que le serveur connaît le mot de passe, root a un moyen de déchiffrer ..."

Franchement, ce n'est pas une bonne idée d'héberger gratuitement les emails de tes potes ou autres (à moins que ton idée est de pouvoir lire leurs emails :) :
- ça bouffe de la place sur tes disques
- faut faire des sauvegardes, utiliser du raid ....
- tu seras emmerdé par leurs demandes, par exemple, comment peuvent-ils modifier leur mot de passe avec le système en place ?
- ...

Effectivement, chroot n'est pas un outil de sécurité sur un système linux (qui n'est pas un système à ranger dans la catégorie 'sécurisé'). Par contre, avec un kernel patché grsecurity et contenant les bonnes configurations des 'Chroot restrictions', on doit pouvoir atteindre un niveau de sécurité acceptable.

J'ai une alix2d3 faisant office de firewall/dns secondaire pilotée par OpenBSD.
Je n'ai pas fait de mesures / tests de performance, mais j'en suis content (consommation électrique réduite et aucun bruit).

A moins d'avoir des yeux irréprochables, je trouve que tu exagères un peu sur les IRC.
La norme EN-12464-1 définit les conditions d'un bon éclairage en fonction de la pièce à éclairer. Dans de très rares cas un IRC supérieur ou égal à 90 est recommandé (les lampes au dessus du siège d'opération du dentiste ...).
Selon cette norme, un indice correct est compris entre 80 et 90.
J'ajoute que les mesures actuelles d'IRC ne sont pas des mesures exactes : c'est le meilleur moyen de chiffrer ce critère mais ça ne reste qu'un indice. J'ai vu que certaines personnes tentent de faire approuver un nouveau test qui à l'air légèrement mieux. Cependant, d'autres ont émis la possibilité que ces mesures d'IRC ne soient pas du tout adaptées aux éclairages LED ...

Concernant les éclairages LED actuellement dispo en magasin, je ne cite pas de nom mais je suis près à parier que très peu d'articles disposent d'un IRC supérieur à 80 et pire, les chiffres annoncés sur les emballages sont sur-estimés.

La technologie LED est en constant progrès. La lumière blanche étant assez récente, il est normal de voir apparaître des produits d'éclairage. Pour augmenter la quantité de lumière, les fabricants peuvent utiliser des LED de différentes puissances et/ou jouer sur leur nombre. Tu as raison de dire qu'augmenter le tension à leurs bornes permet d'augmenter la luminosité au détriment de la durée de vie (je n'ai pas de chiffre mais la durée de vie décroît très vite), mais ceci est une "solution" inacceptable et pourtant encore trop utilisée.

Merci pour cette confirmation.
j'espère avoir le temps de tester la version 3.0 et participer aux tests.

Je n'arrive pas à déterminer si son message est ironique au pas.

Dans le cas où il l'est, je vais expliquer pourquoi je pose cette question :

Utiliser ce genre d'outils oblige à un investissement de temps conséquent (surtout lorsqu'on n'est pas comptable ou gestionnaire). De plus, suivant la quantité et la nature des informations que l'outil gérera, il est facile de comprendre qu'on ne souhaite pas recommencer cette étape à la prochaine version car le SGBDR aura changé.

J'ai testé récemment Dolibarr et je l'ai momentanément adopté : accès par navigateur web, possibilité de le lier à des boutiques de vente en ligne, moins obscure que openerp, en php donc j'ai pu signaler et corriger quelques bugs ....

Mais l'une des raisons principales a été le support de postgresql. Malgré quelques bugs (comme la requête pour chiffrer les mots de passe utilisateur en base dédiée à mysql), ça fonctionne plutôt bien. Mais j'ai peur de voir ce support disparaître, il n'est pas mentionné dans ce journal (pourtant j'utilise la version 2.9). Pensez-vous continuer le support de ce sgbdr dans les futures versions ?

L'avantage de memcache sur sharedance est que le module php5-memcache (enfin sous debian) inclus directement la gestion des sessions.

Haproxy n'est pas un reverse proxy, c'est un load balancer tcp/http.
Pour faire du reverse proxy, j'aime bien nginx.

Et si tu as du temps pour tester d'autres solutions, tu peux t'intéresser à OpenBSD.
En plus de prendre très au sérieux la sécurité informatique, cet OS dispose d'outils réseau performants :
- interface trunk pour agréger tes interfaces réseau permettant de redonder les switchs
- interface carp permettant des bascules automatiques (ou manuelles) avec une configuration simple mais puissante
- interface pfsync (lié au parefeu PF) pour synchroniser les tables d'état
....

Des équivalents existent sous linux, mais je les trouve trop "compliquées" par rapport à celle-ci.

Par exemple, tu peux faire un load-balancer IP avec 2 OpenBSD, leur parefeu PF+pfsync et relayd qui surveille les backends.