Fabien a écrit 136 commentaires

Pourquoi as-tu abandonné l'idée d'utiliser magento ?

Mon expérience perso (limitée) en ecommerce :

• opencart
  je crois qu'il se base sur OScommerce
  assez simple voir trop, je pourrai être amené à l'utiliser pour des boutiques simples
  je l'ai délaissé pour l'instant car j'ai besoin de créer des 'produits configurables' (par exemple une paire de chaussure disponible en plusieurs pointures) et de gérer les stocks par option

• magento
  je pense qu'il permet de faire à peu près tout, c'est juste une usine à cause des layouts xml (même en optimisant le serveur, en ajoutant du cache, de l'opcode et toute l'artillerie ...) mais d'un autre coté, ça permet de facilement étendre et personnalisé l'outil

• prestashop
  pas testé, à première vue, il me semblait que trop d'extensions sont payantes par rapport aux extensions magento

A priori, tout bon outil ecommerce génère du xhtml valide et propose toutes sortes d'optimisation censées améliorer le référencement naturel
sinon, je déplore le manque de support de postgresql de la part de tous ces outils de ecommerce

Pas d'avis sur la 3G car inutile dans mon cas, Internet étant disponible dans toutes les chambres d'hôtel que j'ai occupées.
Mais j'ai aussi constaté le problème des cartes pré-payées et c'est assez déroutant.

Tout comme Windows.

De ce que j'ai compris, OScommerce a vu sa communauté exploser en engendrant de nouveaux projets dont Magento, Opencart ...

Opencart doit être sympa pour une petite boutique je pense, peut être encore trop jeune, mais il ne gère pas les stocks d'un produit configurable (disposant d'options sélectionnables par le client, comme la pointure, ça la fout mal).
Je me suis donc tourné vers Magento, et effectivement, la comparaison avec emacs tiens la route. Sa force (et son défaut) est la possibilité de surcharger à peu près tout ce qui existe (templates, les multiples objets en php ...) le rendant relativement lent même après optimisations système.

La batterie permet d'alimenter le contrôleur et les disques durs indépendamment de l'alimentation générale.
En cas de de crash électrique, je suis certain que les données ayant été signifiées comme écrites sur disque le sont sont bien physiquement, même en cas de cache menteur sur les disques.
Suivant le type de contrôleur, tu peux régler pas mal d'options depuis leur propre 'bios' (voir même directement depuis l'OS si les outils sont disponibles). Avec les contrôleurs PERC par exemple, je forçais le sync sur disque pour les bases de données car je ne pouvais pas me permettre de perdre une seule transaction.

Dernièrement, j'ai repris l'admin d'un serveur chez ovh avec raid software et c'est pas du tout la joie quand mdadm vérifie/reconstruit périodiquement le raid1 de 1.5To. Bien que la comparaison soit biaisée avec mon expérience des contrôleurs matériels (car disques durs SAS 15ktr/min ...), je ne me souviens pas avoir enduré de telles lenteurs.

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.