> On peut séparer les deux : tcpdump pour sniffer le trafic (tourne en root) et wireshark pour parser les paquets (tourne sous un utilisateur non privilégié, voir dans un bac à sable).
Selon les besoins, on peux se passer complètement de wireshark pour la dissection des paquets, et utiliser des outils comme tcpflows, tcpextract et foremost (en ligne de commande, donc scriptables, etc). Par exemple on peux extraire des dumps pcap "bruts" les fichiers transférés sur le réseau sans problème.
ngrep couvre aussi (en cli) certains cas d'utilisation de wireshark.
> Pour l'instant il y a une gueguerre devs spice/kvm_qemu.
Il faut dire (pour avoir suivi l'échange sur la m-l) que la première annonce sur la m-l qemu semble avoir été faite par un des devs de l'ex qumranet, venant visiblement du monde du dev windows & proprio, donc pas avec le tact et le sens des us et coutumes des m-l du libre nécessaire. Par ex. il en est rapidement venu à lancer une grosse attaque perso contre Antony Liguori (qui lead le dev Qemu désormais). Heureusement un dev spice moins "extraterrestre" à pris le relai dans la discussion.
Je crois qu'il y a eu comme un petit "choc des cultures", que les devs parviendront certainement à surmonter.
Voir sur le même sujet les réactions diverses à l'annonce du Red Hat Enterprise Virtualization Manager, adapté d'un produit dont RH a hérité en achetant Qumranet, et qui, pour cette raison, ne tourne pour le moment que sous Windows 2003 (classe, non ? mais RH dit avoir un port vers Linux en cours de dev).
J'au aussi l'impression que la foultitude de forks peu coopératifs qu'à subit Qemu ces dernières années (KVM, qui est un fork amical mais devenu difficile à merger, une partie de Xen, une partie de virtualbox, le nouveau machin de novell dont j'ai oublié le nom, ...) semble rendre les devs Qemu un peu circonspects lorsqu'on leur présente comme la dernière merveille du monde - à merger illico et par leur soin - un gros code-dump monolithique forkant lourdement une version antédéluvienne de Qemu.
Et puis effectivement des devs Qemu ont demandé des mesures montrant si spice était rellement plus performant que l'outil existant et standard (vnc), et si oui pourquoi (savoir pquoi c'est plus performant permet de ne pas endommager par erreur une condition nécessaire à l'obtention de ces bonnes perfs, et/ou d'envisager de merger la bonne idée dans le proto canonique vnc).
> Concernant Xen, rien à l'horizon pour la version 4.0 qui va sortir sous peu. Seul deux threads en parlent et aucun ne fait encore allusion à un commencement d'inclusion.
C'est en fait dans ce cadre (toujours pour du Nagios) que je posais ma question ; à savoir : la possibilité de réutiliser un composant pour faire quelque chose d'autres (mais toujours relatif à nagios/shinken). Par ex. re-utiliser le parseur de conf, indépendamment du reste, pour faire un petit outil cli qui valide un changement, ou qui génère un hostexinfo.cfg automatiquement, ou qui fait un diagramme de gantt à partir des timeperiod, ce genre de choses quoi... Depuis j'ai regardé ton code et j'ai ma réponse (qui est: oui, c'est super modulaire, kewl :).
- [...] Donc tu as tout de même une limite sur le nombre que tu peux lancer en parallèle. Ce nombre est complexe a déterminer suivant le tyype de sonde [...]
C'est là que le multiplexage et le modèle évènementiel rendent service, justement. Il n'y a rien à déterminer à l'avance, le parallélisme est mis en œuvre par le noyau.
On peux donner autant de socket qu'on veut à un seul processus (même des centaines de milliers, si on utilise quelque chose de plus scalable que select(2), cf. haproxy par ex.), et ce processus travaille dès que l'une d'elles a des données dispos à lire. Au plus fort de la charge, le processus passe tout son temps (il utilise un cœur de cpu à plein) à faire les vrais traitements des données utiles en transit, aussi vite qu'il peut. Lorsqu'il n'y a rien à lire ou écrire, le processus dort. Dans tout les cas, et quelque soit le nombre de sockets dont il est responsable, le processus ne consomme que les ressources (ram et cpu) nécessaires au vrais traitements qu'il doit faire.
Un exemple : c'est pour ces raisons (une mainloop événementielle coté lighttpd et nginx vs. des pools de workers, threads ou forks, un pour chaque requète simultanée coté apache) que nginx et lighttpd ne sont pas affectés par le récent "slowloris", alors qu'apache s'écroule
Pour les mêmes raisons, lorsque plusieurs hôtes ne répondent pas aux requêtes, les plugins classique mais parallélisés vont sans doute occuper des ressources (x poller en attente + x * le plugin lui-même) jusqu'aux timeouts, et donc ralentir les autres traitements (si on essaie de maintenir un nombre constant/max de checks en cours) ou mettre le serveur de monitoring à genoux (si on ne limite pas), au moment ou justement on a besoin de monitoring précis et réactif parce qu'il y a des soucis sur le réseau.
De même, un processus dédié peut certainement gérer sans charge aucune quelques milliers de raw sockets pour envoyer/recevoir des pings en natif (sans "popen('/bin/ping'...)", mais il faut que le processus soit root ou la capabilty CAP_NET_RAW...) et avoir un résultat de check_host_alive à la seconde près sur un large parc. Dans le genre de http://gitorious.org/poe-component-client-ping .
- Je n'ia pas encore trouvé de méthode facile çà utiliser pour l'utilisateur (il "décrit" le plugin à utilsier dans la conf de sa commande? On se base sur une reconnaissance de la commande en expression régulière?)
C'est vrais, je ne vois pas non plus de moyen élégant pour substituer l'exécution des plugins connus/réimplémentés par une version ad hoc...
- Soit, comme tu dit, faire la substitution lorsqu'on reconnait un nom de plugin en arg d'une check_command... mais le parsing, berk
- Soit de façon déclarative (eg. "check_command check_tcp_shinken"). Moindre suprise, mais divergence avec une conf nagios brute.
- Soit de façon déclarative, dans un fichier de conf distinct et propre à shinken (genre shinken-specific.cfg), surchargeant la définition des plugins classiques. La aussi, ca fait une nouvelle divergence avec la conf nagios brute.
- Soit en fournissant un exécutable effectif (/usr/bin/check_tcp), qui au lieu d'effectuer le check lui-même, se contente de donner l'ordre de le faire au poller en charge des sockets, et retourne un code "maison" (qui signifierai : je n'ai pas le résultat, attends que le poller te le donne) (et/ou effectuerai le check lui même si et seulement si il n'a pas réussi à déléguer le check à un poller). Mais on ne s'affranchit alors pas de la surcharge inutile des fork()/exec()/popen() & reap, et puis c'est tarabiscoté ;)
Rien de totalement naturel et clean, effectivement.
- Le fait de dédier des pollers je ne suis pas sûr, car un poller pourrait avoir plusieurs types de workers
Effectivement, j'avais cru que les pollers se chargeaient de lancer les actions (pas vu le worker.py).
Désolé d'amener la discussion sur ces petits détails ; shinken semble déjà un super progrès par rapport à l'architecture de nagios :). La possibilité de faire tourner plein de checks classiques légers (tcp, http, udp, icmp) a intervalles très fréquents sans saturer le serveur de monitoring est peut-être un besoin plus perso qu'autre chose (mon serveur de monitoring fait tourner plein de trucs gourmands en plus de nagios, j'ai très peu de checks lourds en perl ou autre, et j'aimerai être avertis des problèmes plus vite qu'actuellement ...).
Merci beaucoup,
c'est un joli projet et j'espère que les autres devs seront receptifs.
J'ai quelques questions.
- Est-ce que les composants sont réutilisables sortis de l'ensemble?
par ex. peut-on réutiliser le parsing de conf pour faire autre chose? est-ce qu'ils ont une api "publique" ou seulement interne? (par ex. pour attaquer directement les scheduler et leur demander où ils en sont, changer leurs priorités, etc).
- En parlant de montée en charge ("scalability")...
comme le fait remarquer quelqu'un en réponse sur la m-l, l'essentiel de la durée d'execution d'un plugin type semble être passé à attendre (attente pour pouvoir écrire sur une socket, attente d'une réponse...) (plus le temps du exec() et envois du retour à nagios, bien sûr).
J'ai l'impression que l'execution des plugins en tant que commandes externes impose une limite au nombres de tests/seconde possibles : outre la surcharge de l'execution externe, en lancer un trop grand nombre simultanément (et même s'ils ne font pour ainsi dire rien d'autre qu'attendre, et quand bien même l'architecture à mutiple poller + NDX permettrai d'en lancer 10000 à la fois) signifirait saturer le/les système de processus sleeping.
Est-ce que des plugins très couramment utilisés comme check_tcp, check_http, et check_smtp pourraient être re-implementés en interne, et executés simultanément par multiplexage asynchrone et evenementiel de sockets ? par ex. en les regroupants quand c'est possible sur un seul (ou, disons, une poignée de) processus gerant x "checks classiques sur tcp ou udp ou raw (icmp)" et multiplexant via epoll()/kqueue() etc à la façon nginx/haproxy. Il existe plusieurs libs python pour faire ce genre de choses (twisted, mais il ne supporte pas IPv6, PyEvents, libevent-python...).
Le modèle des multiples pollers de shinken semble permettre ceci, au sens où avoir un couple de poller spécialisés/dédié aux checks de bases reposants sur tcp ne devrait pas empecher l'execution d'autres plugins en parralele (?).
- Quel est le niveau de compatibilité visé avec un nagios3 ?
seulement compatible au sens de pouvoir réutilise l'ancienne conf et certains plugins à condition d'y adjoindre des confs spécifiques à shinken ? générer un status.dat ? etc
L'outil est-il réellement limité à la collecte et présentation de NetFlows émis par des équipements Cisco ? Linux, par exemple, peut être paramétré pour émettre du NetFlow (par ex. avec fprobe-ulog ou les flow-tools, ou directement depuis iptables avec ipt-netflow, ...).
> Zarafa avait deux inconvénients majeurs [...]
> un découplage restreint (quoique meilleur que - disons - Zimbra) : il est son propre serveur de stockage
Je suis d'accord avec ça. Pour avoir subit Zarafa en production, stocker les mails en bdd
- est vraiment une fausse bonne idée, il faut des énormes serveurs pour tenir la charge qu'un simple imap sur maildir peux encaisser sans efforts, c'est frappant. peut-être à cause du maintient des indexes, des contraintes d'intégrité, des méthodes d'accès (passer par un intérpreteur et query planner sql), ou de la concurence/des verroux ...
- rends les migrations/changements/adaptations/réparations à chaud difficiles ; ça fait perdre énormement de souplesse et de possibilité de rattraper les boulettes, par rapport à un format de stockage de mail classique où l'on peux manipuler les mails directement avec des outils courants ou quelques lignes de script, déplacer/répartir quelques mailboxes sur un autre serveur, faire des backups incrémentaux et restaurer mail par mail, remplacer un deamon IMAP ou LDA qui ne convient pas/plus, etc.
- Situation dans leur cas aggravée par le choix d'une structure de bdd collant au plus près (sans trop d'abstraction quoi) aux contraintes de MAPI, ce qui la rends assez imbitables (avec des colonnes contenant des champs de bits, les mails décomposés en "properties" et splittés sur x rows, etc). Schéma non documenté, bien sûr.
Cette différence d'approche (Zarafa monolithique et SOGo "intégrable") est aussi sensible en ce qui concerne les choix de protocoles d'accès privilégiés.
Dans le cas de Zarafa, on a pour protocole principal (celui de l'extension Outlook avec laquelle ils font leur beurre) une popotte maison (des requètes MAPI encapsulées dans du SOAP), et en guise de complément du pauvre un peu délaissé,des backends IMAP et iCal-over-http (oui oui, même pas du CalDAV) très frustres et probablement très peu utilisés (c'est ce que je déduit du fait qu'elles sont archi buggués). Ok, et de l'ActiveSync via Z-Push (j'ai pas testé, ça marche bien ?). Le filtrage/tris coté serveur n'est accessible que par le proto de leur client Outlook lourd (inaccessible depuis les autres clients, bye bye thunderbird), idem pour les carnets d'adresse. Pensez-y : si vous migrez hors de Zarafa, vous perdez les règles de tris et les contacts (et quelques mails si vous subissez autant de bugs que moi avec leur passerelle IMAP)...
A l'opposé, SOGo semble avoir un parti pris sans concession pour les protocoles standards, ce qui rejoint ton constat au sujet de sa capacité d'"intégration" (avec d'autres softs). Le support CalDAV est impec, les tris sont en Sieve (tout frais, mes platres), les contacts accessibles en CardDAV (déjà !) et/ou GroupDAV, le mail est délégué au serveur IMAP de son choix (qui saura surement gérer ça mieux q'un group/bloat-ware) sans réinvention d'un proto de mail-over-la-roue... sans parler des contributions à Thunderbird/Lightning (justement en vue d'améliorer le support des protocoles standards, et aussi de donner acces aux infos de disponibilité/freebusy, etc...). L'extension Outlook suggérée (Zideone, en béta qui fait peur) se contente elle-même d'ajouter à l'infâme le support des standards qu'il aurait toujours du avoir, ce qui peut aussi le rendre utile pour communiquer avec les groupware concurents. C'est l'opposé du vendor lock-in.
Par contre, un avantage à mes yeux en faveur de Zarafa, c'est qu'il ne fait pas tout pour faire peur à l'admin : les dépendances sont limités, c'est tout en C++ pas trop jojo mais "devinable" sinon lisible, les fichiers de conf sont dans /etc (et ont une syntaxe bateau), les logs dans syslog, les libs dans /usr/lib, les données statiques dans /usr/share, ça se compile bien (./configure ; make ; make install), ils fournissent des packages très propres en i386 & amd64 pour beaucoup de distros (et c'est facile de les refaire soi même). Bref, si vous avez installé quasi n'importe quel logiciel serveur du monde libre récement, d'apache à postfix ou exim en passant par postgresql ou mysql ou dovecot ou bind ou openldap..., vous ne serez pas dépaysés.
Tandis que coté SOGo, tout semble fait la façon la plus gratuitement originale possible (par rapport à ce avec quoi les admins sont généralement habitués à travailler). Tellement bizarre pour moi que j'ai renoncé de ce fait à l'utiliser en prod (à la place de l'autre zouave) de peur de ne pouvoir le comprendre, diagnostiquer, réparer, maintenir, reconfigurer ou upgrader, et malgré ses indéniables charmes (fonctionalités, souplesse et standards surtout). Codé en Objective-C (cool, mais du coup je crains qu'il n'y ai pas bcp de monde qui envoi des patchs, et donc que les bugs restent là), reposant sur une large tripotée de libs obscures et interdépendantes (et pas présentes sous debian, centos, fedora ni ubuntu) qui viennent d'un projet semblant à l'abandon (opengroupware), et qui sont stockées dans des dépots mercurial (yo, encore un truc à apprendre), et qu'il faut patcher (les libs, vous suivez ?) spécialement pour le SOGo ; dépendance forte à GNUstep (t'a déjà mis ça sur un serveur non Apple ou NeXT cher confrère ?), y compris pour le stockage de la conf (à mort la Linux Standard Base) et aussi pour son format. Quand tu a réussi à le compiler une fois (et make-installé des trucs qui vont se coller dans les coins les plus improbable du système, fait des ldconfigs à tour de bras pour que ça passe), puis mis en prod, je pense que tu espère ne jamais avoir à l'upgrader. Dommage. Quelqu'un a-t-il osé l'utiliser en prod parmis vous ?
> Si Sparse n'est actuellement utilisé que par le noyau Linux,
En fait il est déjà utilisé par quelques projets en espace utilisateur. A ma connaissance, qemu et xfsprogs intègrent des vérifications basées sur sparse. Le fait que ces deux projets soient fréquentés par des devs kernel n'est peut-être pas fortuit : pour avoir essayé sans succès d'utiliser sparse à partir de la "documentation" disponible, j'ai supposé qu'il fallait être soit super doué, soit déjà introduit par la connaissance de cas d'utilisations concrets (comme on en trouve dans le noyau). D'autre part les en-têtes de la glibc (et en pratique tout le /usr/include) produisent de copieux warnings, ce qui rends l'utilisation en espace utilisateur laborieuse. Bref, avec un peu plus de doc et d'exemples, et un solide système de filtres, sparse serait plus simple d'accès pour les "non kernel-hackers".
Je profite de ce poste pour signaler Coccinelle, un analyseur statique mignon tout plein et oublié dans l'inventaire de la dépêche. Il est très facile à utiliser (il suffit généralement d'écrire des "patches sémantiques" de quelques lignes adaptés à ses besoins, cf. les exemples plus bas), et il ne nécessite pas d'annotations spécifiques dans le code cible.
Deux obstacles au succès de Coccinelle cependant : il est écrit en Objective Caml (sans jugement sur la pertinence technique de ce choix de langage, mais les utilisateurs de l'outil sont des développeurs C), et il incorpore son propre parseur C (ce qui l'expose à des problèmes de compatibilité en traitant des sources prévues pour gcc), à la différence de sparse, qui se branche facilement sur gcc ou llvm.
p.s.: en ce qui concerne la question de la licence de sparse :
- Linus Torvalds donne une motivations spécifique sur le choix d'une licence incompatible avec la GPL, dans la FAQ de sparse. Il y explique qu'il souhaite (souhaitait) ainsi prendre le contrepied du parti prix monolithique de gcc (« I like the GPL, but as rms says, "Linus is just an engineer". I refuse to use a license if that license causes bad engineering decisions. I want the front-end to be considered a separate project ».
cf. http://git.kernel.org/?p=linux/kernel/git/torvalds/sparse.gi(...)
- Mais il reconnait que l'OSL n'est pas le meilleur choix : http://www.mail-archive.com/linux-sparse@vger.kernel.org/msg(...)
- De toutes façons, Novafora (qui a hérité de la propriété intellectuelle de Transmeta) a accepté de re-licencer sous MIT il y a quelques mois : http://markmail.org/message/qijmu2cu4gbi74te
Il faut utiliser les Volume Shadow Copy (une sorte de système de snapshots à la LVM si on veux) pour pouvoir lire/backuper des fichiers ouverts et verrouillés sous windows.
Pour ceux qui se demandent de quoi parle ce journal : Grand Central Dispatch (combiné avec les "blocks") est une solution mise en place par Apple dans le tout récent Mac OS X 10.6 "Snow Leopard" pour rendre la programmation threadée/concurente/asynchrone/parallèle hyper simple.
L'article d'Ars Technica sur les nouveautés de Snow Leopart décrit les choses de façon synthétique mais agréable à lire :
En gros, l'adaptation d'un bout de code pour en faire une "worker thread" devient tellement simple et naturelle (pour ainsi dire, deux ou trois lignes claires à ajouter) que les développeurs vont le faire, et qu'on vas peut-être enfin exploiter partie de nos cpus multicores ;).
Voila ce qu'en disait Thomas Vander Stichele, un core dev de GStreamer / Fludo (et accessoirement sympathisant des ambitions de PA) pas plus tard que la semaine dernière : http://thomas.apestaart.org/log/?p=1012
C'est aussi ce que je reproche le plus à PA. Il est affreusement buggué, certes.
Mais le problème n'est pas là ; comme tout logiciel très utilisés, il pourrait se bonifier rapidement et ne pas (trop) taper sur le système de ses utilisateurs s'il n'était pas si opaque, automagique et uber-complexe, tout ce qui fait que peu de gens rapportent les bugs qu'ils rencontrent, et peu de gens peuvent aussi les contourner ou trouver des workarounds. Aussi, la personnalité de Lennart Poettering n'aide pas forcément (à faire des rapports de bugs, à faire reconnaitre qu'un comportement donné est un bug, à faire admettre des workarounds pour avoir le son qui marche dans la vraie vie, celle des users de desktops)...
Un logiciel libre très utilisé qui donne à ses utilisateurs les moyens de faire des bons rapports de bugs, sinon de le fixer eux-même (doc interne, doc des interactions, messages d'erreurs clairs, aux bons endroits et bien formulés, modes verbose efficaces, etc) est promis à une stabilité irréprochable en un rien de temps. Après 5 ans d'existence PA ne devrait pas en être encore au stade du "je pers le controle de la carte son et je ne loggue rien".
Merde, même le noyau - et c'est pourtant pas facile à ce niveau du système - est incroyablement plus débugguable que PA (printk très pertinents, docs riches, myriades d'outils de traçage, profiling, débogguage des verroux, des problèmes mémoire, netconsole, autodocumentation des états internes via /proc et /sys ...) ! Résultat, les bugs sont corrigés. Et les développeurs kernel ne t'envoient pas chier parce que tu rencontre un bug en utilisant un logiciel proprio sur leur système, ou rejettent une solution réduisant drastiquement les problèmes parce qu'elle serait "moins pure" (voyez la récente aventure d'Alan Cox et des standards posix relatifs aux ttys).
Vous faites quoi, vous, quand PA décide, sur votre système, de ne plus sortir de son, ou crash silencieusement ? vous arrivez à trouver de quoi faire un rapport de bug ? perso je lance un strace en desespoir de cause (mais ça ne sert à rienà, puis le le "/etc/init.d/pulseaudio restart" (inutile aussi, visiblement PA ne doit pas être lancé ainsi), puis je reboot. Classe.
> Quel est l'intérêt de sieve par rapport au bon vieux procmail?
Procmail est un vénérable outil unix capable de faire un peu tout (et n'importe quoi, y compris exécuter des commande arbitraires). Son langage n'est pas normalisé autrement que par son implémentation, et je ne crois pas qu'il y ai beaucoup d'autres outils que procmail lui-même qui soient capables d'éditer visuellement un .procmailrc arbitraire (je ne parle pas d'outils capables d'éditer une petite partie de sa syntaxe, typoquement : uniquement des fichiers qu'ils ont généré eux même). Le dépot de script .procmailrc sur le serveur nécessite un accès au système de fichier (ou une bidouille "site spécifique" pour récupérer/déposer au bon endroit : la mise à jour du jeux de règles n'est pas prise en charge par procmail lui même).
Bref, procmail est puissant, souple, non standard et potentiellement dangereux.
Sieve est un langage de description de filtrage (tris, bounce, vacation/notification d'absence, forwards, ...) de mails coté serveur standardisé (décrit dans une foultitude de RFC en fait, à commencer par la RFC 5228), et conçu pour permet de déployer des jeux de règles écrits par des gens pas forcément de confiance sur un des serveurs qu'on ne veux pas compromettre (il ne permet pas l'exécution de commandes externes, évite les boucles infinies, ...), et pour permettre l'interopérabilité et l'édition/génération de jeux de règles à partir de clients divers (éventuellement graphiques : webmails...).
Le standard sieve a un petit frère nommé managesieve, pas encore majeur (c'est un draft de RFC, bien qu'il soit déjà implémenté dans plein d'outils libres), qui décrit un protocole de téléchargement/upload des jeux de règles sur les serveurs, assez insipré de l'IMAP (simplifié), sans que le client n'ai a accéder au système de fichier ni même à savoir où le serveur place ces fichiers.
Le support sieve et/ou managesive est implémentés dans divers clients (par exemples des plugins pour les webmails Squirrelmail, Horde, Roundcube, l'extension sieve pour Thunderbird, un support natif dans Kmail et Mullbery, dans divers LDA tels que celui fournis avec Dovecot, avec Cyrus, avec DBmail, avec Courrier, Exim ...), et normalement les jeux de rêgles uploadés par l'un sont téléchargeables et éditables tels quels par l'autre (c'est interopérable quoi).
Bref :
Procmail est très adapté sur une machine dont les utilisateurs sont de confiance, ou lorsque son utilisation et la mise à jour des ses rulesets est restreinte, limitée et sous contrôle (par ex. avec le subset de langage procmail implémenté par Horde IMP), ou écrit par l'admin pour faire de puissant traitements sur des mails transitant sur un serveur / sur une boite automatisée, ou lorsqu'on a besoin de brancher des filtres (par ex. antispam ou antivirus) au moment de la distribution du mail.
Sieve est plus adapté pour un serveur mail hébergeant une bonne brouette d'utilisateurs pas forcément "de confiance", et lorsqu'on apprécie les bénéfice d'une solution standardisé interopérable (pouvoir changer de client/webmail/LDA/etc... et continuer de pouvoir manipuler graphiquement ses règles de tris). Le fait d'être souvent implémenté par les LDA fournis par les divers serveurs IMAP le rends aussi plus adapté que procmail à l'hébergement virtuel de masse à mes yeux (le path des scripts, le path et le format des mailboxes/mh/maildirs, le séparateur IMAP, l'uid/gid de destination du mail, etc. lui sont alors directement indiqué par le serveur IMAP qui de toutes façons doit connaitre ces infos), alors que l'utilisation de procmail impose de forte contraintes sur l'hébergement virtuel.
>> Faudrait que des professionnels engagés par des boites pour coder sur le noyau. -aka on est pas chez les clochards ici-
> Ben tu devrais pourtant savoir que l'essentiel des gros contributeurs sont pourtant payes pour bosser sur le noyau.
Oui bon et il faudrait surtout indiquer que ce thread dérive à partir d'une fausse information.
La raison que Linux a donné concernant son choix de CFS de Molnar plutôt que le SD de Kolivas est exactement la même que celle pour laquelle il a passé un savon à Alan Cox dans les mails évoqués ici (plus précisément celui-ci [http://lkml.org/lkml/2009/7/28/373]) : parce qu'au lieu de corriger les problèmes relevés dans son propre code - et à l'inverse de l'attitude de Molnar - Kolivas refusait d'admettre la moindre critique, de considérer que le moindre bug touchait son code (comme ici, Cox vis à vis de son patch et d'Emacs et KDEsu).
Moralité : je pense que votre mémoire vous joue des tours. Il a certes été éliminé parce que Linus a jugé qu'il risquait de mal assurer la maintenance, mais ce jugement était extrapolé de son attitude pendant les débats, et non de son job.
Trust me, I know what matters. And a person who can actually be bothered to follow up on problem reports is a *hell* of a lot more important than one who just argues with reporters. (Torvalds).
En outre, contrairement à ce qui est dit plus haut, dans son l'explication de son départ final ([http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.ht(...)]), Con Kolivas ne prétends pas que son problème tient à ce que les développeurs professionnels sont privilégiés, mais à ce que, dans les choix qui sont fait, les besoins du noyau en environnement pro/serveur aient préséance sur les besoins de linux en environnement desktop.
Un peu de contexte ne devrait pas nuire à la compréhension de ses réponses, notamment en ce qui concerne ses remarques sur les autres OS : l'objet principal (exclusif ?) du travail de Spender est la sécurité du noyau, ou les mécanismes de sécurité offerts par le noyau (et éventuellement des outils bas niveaux liés, comme le ld par exemple), pas la sécurité d'un OS complet, dans son ensemble.
Voyez sa réponse concernant la sécurisation de Windows : elle concerne les mécanismes mis en place par le kernel et la façon dont sont chargées les bibliothèques. N'entrent pas en considération dans ses réponses - et c'est normal - les aspects sécurité relatif aux logiciels en espace utilisateur pur (les choix de MS concernant l'ActiveX dans MSIE et Outlook, l'authentification système, les fonctions "sûres" offertes par la libc, ce genre de choses). Même chose au sujet de ses réponses sur OpenBSD : il faut comprendre qu'il parle du noyau. Aussi lorsqu'il dit que le projet est sans intérêt, je ne pense pas que sa remarque concerne OpenSSH (qu'il trouve peut-être utile, mais ça n'est pas dans son radar en tant qu'expert de la sécurité noyau).
Lorsqu'il indique que les développeur du noyau Linux font aussi des recherches systématiques par classes de failles (c'est la vérité : voyez par exemple le joli travail de l'équipe qui développe Coccinelle, l'utilisation de certains flags gcc, le développement de Sparse...), il ne s'intéresse pas aux différences pratique de méthode au delà du noyau (le code source de tout l'OS d'OpenBSD - serveurs web, mail, libc, xorg, etc. compris - est dans un seul et même dépôt, et les recherches de classes de failles se font sur l'ensemble de la base de code de l'OS, ce qui serait beaucoup plus difficile avec le code inclus dans une distribution Linux).
Une précision intéressante au sujet de la question des audits automatisés / systématiques : le problème de déreferencement de pointeur noyau utilisé par son exploit a été identifié et relevé par l'outil d'analyse statique et propriétaire Coverty avant qu'il soit découvert et corrigé par les développeurs noyaux, et avant la diffusion de l'exploit de Spender. Il semblerait (selon Coverty) que les développeurs noyaux Linux ne se donnent plus trop la peine de consulter les analyses de code générées par leur outil, ou du moins de corriger les erreurs relevées, comme ils le faisaient à une époque. A contrario les développeurs de Cocinnelle envoyant directement des patchs sur LKML, les bugs relevés par cet outils sont corrigés. Ce qui me fait prendre sa réponse au sujet de la pertinence de développeurs "responsables de la sécurité du noyau" avec des pincettes : il semble qu'il faille que quelqu'un se colle spécifiquement à la lecture des rapports d'analyses appareillées et à l'écriture de patchs pour que certains problèmes soient corrigés (de même que les régressions ne sont vraiment suivies que depuis que qu'un développeur dédié se donne la peine de faire le suivi global _et_ de poster des comptes rendus sur LKML).
Je trouve enfin que ses remarques sur l'utilité, la complexité, et la taille du noyau d'OpenBSD sont assez justes : c'est un noyau très rudimentaire par rapport à Linux, évoluant lentement, et offrant bien moins de fonctionnalités et des performances assez limitées. Il est donc normal que ce noyau soit moins exposé aux problèmes de sécurité. Précisons tout de même que c'est un choix intentionnel de la part des développeur de cet OS (des gros patchs, par exemple implémentant un support des ACL et RBAC, sont régulièrement rejetés au motif que leur complexité risque de fragiliser le système et/ou de rendre la lecture et les audits plus difficiles; c'est aussi pour ça que des fonctionnalités faciles à porter à partir du code de NetBSD ne sont pourtant pas reprises). La contrepartie, c'est que, comme la réponse de Spender le laisse entendre, OpenBSD n'est pas le choix idéal - est "inutile" - pour de nombreux cas d'utilisation (par ex. si besoin de système de fichier performant, de drivers rares, de LVM, ...).
Et c'est où je voulais en venir : dommage qu'aucune question n'ait été posée sur la façon dont Spender établit les limites diverses, accepterai de céder sur certaines exigences, quelle marge de compromis acceptera-t-il entre performances/fonctionnalités d'une part et sécurité d'autre part. Et en corollaire : quels sont les coûts actuels, hors sécu, de ses jeux de patchs grsecurity (que perds-on au profit de la sécurité). Parce que c'est (pour ce dont je me souviens, ça date) précisément son incapacité à faire coïncider ses exigences (sécurité) avec celles des autres (performances, mémoire disponible, ...) qui avait provoqué le rejet net de grsecurity lorsqu'il l'avait initialement proposé pour inclusion dans Linux. Pour ce que j'en comprends, il semble que Spender trouve qu'OpenBSD ne lâche pas assez de lest et manque de perfs ou fonctionnalité, et trouve qu'à l'inverse le noyau Linux accepte trop de changements, trop vite, ne prends pas assez de temps pour analyser ce qui est une faille ou pas, etc. Quoiqu'il en soit, c'est toujours un compromis difficile, mouvant, dynamique, et reflétant l'"état des forces" en rapport à un instant t dans la communauté des développeurs et des sociétés en présence.
Hormis ce petit regret, l'interview reste utile, agréable et bienvenue bien entendu ;)
Ce que tu dis est certainement valable pour les branches stables (quatrième composant dans le numéro de version pour le noyau linux, mises à jour des distributions, ...), où les patchs sont peu nombreux, déjà identifiés comme critiques (sans quoi ils ne sont pas rétro-portés dans les branches stables), et où les patchs sont sujet à une attention particulière, plutôt pour éviter des régressions par effet de bord que pour évaluer les conséquences en terme de sécurité (et c'est dommage puisqu'une bonne partie du travail est déjà faite).
Mais est-ce applicable pour le lot commun des patchs concernant un OS ? Pour les trois que je connais, la tâche semble ardue : ce qui est reproché aujourd'hui à Linux l'est régulièrement à Microsoft. Et OpenBSD ne prétends par faire mieux : les devs anticipent la question en martelant : "nous préférons passer du temps à prévenir et corriger plein de choses qu'à évaluer la possibilité qu'un de nos patch répare une faille de sécurité" ; il leur arrive effectivement de découvrir avoir corrigé une faille longtemps après l'application d'un patch (par ex. sur leur version d'apache).
Autrement dit, tout les fournisseurs OS sont régulièrement accusés de cacher intentionnellement la poussière sous le tapis ; et le fait que ça touche tout les OS permet justement de douter du qualificatif "intentionnellement".
Détaillons le cas de la démarche dite "proactive" (= le principe de "mieux vaut prévenir que guérir") d'OpenBSD. L'équipe de développeur est assez réduite ; à chaque nouvelle faille, et à chaque découverte de paradigmes de programmation sécurisée, ils ont pour habitude de passer tout leur CVS (contenant un OS complet hein, pas seulement le noyau) à la moulinette du rechercher/remplacer. C'était le cas lorsqu'ils ont remplacé tout les srt[n]cat/cpy par des strlcat/cpy, la plupart des atoll/atoi par des strtonum, trouvé une méthodologie plus robuste pour prévenir les débordement d'entiers, activé tel ou tel warning supplémentaire du compilateur et corrigé tout ce qui bronche, etc. : un travail de titan, et des dizaines de milliers de patchs à chaque fois. Si, pour chacun de ces patchs, il avait fallu passer plusieurs heures à chercher s'il corrigeait une faille effective, ils n'auraient jamais pu mener ces chantiers à terme, loin s'en faut.
Moralité : dans ce cas, l'effort de transparence (catégorisation des modifications appliquées dans les branches de développement de l'OS) est antithétique et préjudiciable à la sécurité effective du système. Tout simplement parce que les ressources humaines ne sont pas illimitées (peut-être qu'elle le sont chez Microsoft, mais ce n'est pas le cas pour les OS libres que je connais). Et si le "armchair security expert" était, justement, celui qui juge le résultat de haut et de loin, sans mettre les mains dans le cambouis ?
Ah bah il a bien essayé, mais Theo de Raadt de n'est pas laissé troller (s'est abstenu d'entrer dans le débat) et l'a illico et publiquement jeté en pâture aux hordes de bdistes revêches de ma m-l misc@ (« I would be more than happy if you guys in the community convinced him to leave me alone »), ce qui l'a calmé :
> Est-ce que Phenix Agenda ne répondrait pas à tes besoins ?
Je suis justement en train de le tester (pour avoir vu ton lien ci-dessous ;). Merci !
Je m'aperçois que mon poste ci-dessus ressemble à une (non méritée) critique du logiciel. Aussi je tient à préciser pourquoi je l'avait quand même sélectionné et ai essayé de le tester, malgré une réticence devant l'inconnu (ObjC/GNUstep/...), et parmis une foultitude d'outils existants et parfois plus connus :
o L'utilisation de protocoles standards et ouverts.
o Il est libre (et il est soutenu par une entreprise, en cas de besoin de correctifs importants ou pressants...)
o SOGo a un superbe score sur https://wiki.mozilla.org/Calendar:QA_CalDAV_Support (j'en déduis que le support des standards y est excellent).
o La contribution de correctifs à Thunderbird/Lightening. Bon esprit, et très bon signe pour la qualité de l'intégration.
o En langage compilé. C'est pas une nécessité impérieuse pour moi (du php, perl ou python ne me dérangent pas), mais il doit pouvoir être très performant, et je trouve ça assez classe ;)
o Le développement semble super actif, et dans le pur esprit "release early, release often".
o C'est un calendrier, et il ne semble pas (trop) essayer de tout faire et le café avec (contre la ribambelle de groupwares bien connue ici), ou d'imposer logiciels pour les autres services concomitants (certains groupwares imposent d'avoir un IMAP sous Cyrus, ou un Postfix, etc.), ou de ramener un gros stack J2EE...
o D'après les démos et les exemples de fichiers de conf, il semble assez complet au niveau fonctionnalités (il semble qu'on puisse le caler sur son ldap, par ex., mais je n'ai pas réussi à aller si loin), dispose d'une interface web fonctionnelle, ...
> J'envisage sérieusement d'installer SoGo dans mon entreprise pour deux raisons : 1. il s'appuie
> exclusivement sur des standards ouverts et 2. il prend en charge l'interface utilisateur
> uniquement et ne cherche pas à prendre en charge toute la partie serveur de messagerie
Pareil, pour moi (enfin, "ai envisagé").
Mais un rapide essai (echec) d'installation m'a fait peur ; plus précisément le fait qu'il n'y a ni doc ni paquets laissant supposer que ça a été testé sous Debian le rends un peu "risqué" pour moi, vu le peu de chances que j'ai de m'en sortir tout seul en cas de pépin avec ces technos "originales" (je ne suis pas habitué à utiliser GNUStep (ses confs, etc) pour des serveurs, les dépendances au reste de d'OGO semblent énormes et complexes et aussi à installer soi-même par les sources, je connais pas le langage objective C donc je ne peux rien relire pour comprendre un aspect opaque ou corriger un problème, l'outil (ou plutôt sa communauté) semble assez jeune etc...). Sans mettre en cause l'outil, ça fait beaucoup d'inconnues, avec le risque de planter (et ne pas savoir réparer) tout les agendas de mon entreprise à la clef.
J'ai l'impression que ce sera un superbe outil (je veux dire : même pour les bras cassés comme moi) d'ici quelque temps, lorsqu'il sera intégré dans les distros, qu'on trouvera des tutoriaux ou des réponses aux questions de bases déjà sur les archives de la m-l, que les divers paths, rôles et syntaxes des fichiers (binaires, confs, etc) et des dépendances seront documentés, etc.
En attendant je cherche encore un serveur de calendrier qui soit :
- Un peu plus ancien (ou au moins que des gens aient déjà utilisé en prod sous Debian)
- Synchronisable avec Outlook 2007 et Thunderbird + Lightning (donc iCal c'est ça ?)
- Ayant une interface web qui permet aussi l'édition (donc pas phpicalendar)
- Qui gère les freebusy, qui permette d'envoyer des meeting requests
- Standalone, pas une suite tout en un (donc pas Zimbra, Kolab et compagnie)
> Depuis, il n'y a pas photo, avec 4 fois moins de RAM consommée par le SGBD, j'obtiens les même perfs sans tuning particulier.
En même temps, c'est assez normal : MySQL alloue explicitement de la RAM pour gérer lui-même son cache (du moins avec InnoDB, et à hauteur de ce que l'admin à configuré), tandis que PostgreSQL laisse l'OS gérer ce cache, (Linux utilisera la RAM libre dispo pour cacher les données utilisées par PG, mais cette utilisation ne sera pas "imputée" à PG, pas comptabilisée dans top/ps/...). Autrement dit : si tu utilisais la RAM ainsi "libérée" pour d'autres applis, ou enlevait les barrettes "superflues", les performances chuteraient vraisemblablement (sauf si application peu sensible à la qté de ram).
> Mais quel différence entre mettre la barrière de synchro au niveau de l'OS ou de tricher au niveau disque ?
Je ne sais pas... mais il faut dire que je n'ai pas compris la question ;)
> J'ai l'impression que l'OS voyant des fsync() partout se sent obliger des les honorer rapidement, alors qu'il y en aurait pas besoin avec un APS.
Je réitère la remarque ci-dessus : s'il ne les honore pas, il perds des données qu'il a prétendu écrire en cas de crash système ou de cable d'alim (UPS ou pas). La panne électrique n'est pas le seul malheur qui peux frapper un serveur écrivant en asynchrone.
Avec ext3, l'intervalle par défaut de commit des dirty pages est de 5 secondes : ça peux représenter un bon paquet de transactions perdues...
Un autre aspect à évoquer : les SGBDS s'efforcent de garantir la persistance de toutes les données commitées (le D de ACID) via fsync() (et c'est bien ce qui les rends gourmands en IOPS). Mais en pratique, pour une application donnée, il n'est pas rare que ce besoin de garantie de persistance ne soit vraiment impérieux que pour une toute petite fraction des écritures. Par ex. sur une appli web de commerce, c'est souvent une garantie nécessaire lorsqu'un utilisateur valide un achat en ligne, souvent moins nécessaire lorsqu'il met à jour des infos sur son profile, poste un commentaire, lorsqu'on stocke les stats de visites par page, etc. (moins impérieux = au sens où on la perte de quelques minutes de données tout les un ou deux ans (interval de crash système) n'est pas un drame si elle permet en contrepartie de multiplier les perfs du système par 10). La tradition et les applications classiques utilisant un SGBD tendent à tout stocker de façon synchrone, sans distinction, ce qui est souvent un gros gaspillage de ressources les plus précieuses (les I/O), bien sûr.
D'où l'émergence de solutions mixtes (SGBD relationnel + stockage asynchrone), ou l'utilisation d'extensions comme le "insert delayed" de mysql (mais n'a pas d'équivalent pour update et delete)... Je rejoint donc ta remarque sur l'utilité d'une marge de tricherie en disant qu'il serait bien utile de pouvoir, transaction par transaction, indiquer à l'OS s'il doit vraiment honorer une écriture de façon synchrone ou pas. Les besoins d'une appli de type "web social" à fort traffic ne sont généralement pas exactement ceux d'un système bancaire.
> A choisir de mettre 500€ de matos en plus, je pencherais pour de la ram plutot qu'une carte raid avec BBU. Même si les prix sont tombés par rapport à une autre époque. (d'ailleurs, cela ne coute pas moins chère de mettre un petit APS à coté du serveur qui provoque un fsync clean avant que la batterie sois complètement vide ?)
Pour rester sur ma ligne "à cette heure il n'y a pas une solution qui les écrase toutes" ;) :
je crois que c'est vraiment un choix (sur quel type de matos flamber le budtet) qui doit se faire au cas par cas, selon les besoins de l'appli.
Par exemple pour reprendre tes suggestions citées juste au dessus (qui peuvent être bien pertinentes dans certains cas) :
* La RAM (dans l'OS) est principalement mise à profit pour réduire les lectures (ok, et les écritures si elles sont asynchrones, généralement pas le cas des SGBD). Donc très profitable pour une appli faisant beaucoup de lecture.
* Il y a des cas où augmenter la RAM n'apporte rien de significatif (par ex. si on a déjà 32 GB de RAM pour une bdd de 20 GB)
* Le couple cache_controlleur+BBU n'est pas tout à fait équivalent/remplaçable par une UPS :
- Il termine ses écritures même en cas de crash et arrets de l'OS, pas seulement en cas de pannes electriques. Ca signifie que même avec du writecache une transaction validée sera vraiment stockée, ce qui peux être - ou pas - une nécessité, selon le type d'appli. Dans le cas d'un système avec UPS : soit on écrit de façon synchrone (mauvaises perfs en écritures random), soit on prends le risque de valider des écritures non persistées (écritures async => utilisation du page cache de l'os => pertes en cas de crash). Ca protège aussi des problèmes de cables qui "se débranchent" (que le premier qui a bossé en salle serveur me jette la pière ;).
- La BBU permet d'activer le mode writeback du cache en écriture du controlleur (ces derniers le désactivent en général automatiquement en l'absence de BBU, pour ne pas perdre les données sales en cache en attente d'aggregation et d'envois vers les disques)
- Les controlleurs connaissent bien le layout physiques des disques, et s'ils sont dotés d'un cache (et qu'ils peuvent l'exploiter, donc d'une BBU), ils savent (plus ou moins) balancer les écritures de façon optimales sur les pools de disques disponibles. C'est aussi le cas du MD logiciel de Linux, mais n'est plus le cas s'il y a une couche LVM sur le MD.
* Tout ces questions ne sont pertinentes que pour une appli nécessitant beaucoup d'écritures random et synchrones ; il est clair qu'un logiciel dont le besoin premier est d'écrire, de façon asynchrone, de gros volumes de données a plutôt besoin d'une grosse bande passante.
Voila, exactement. Les deux noms cités sont des exemples parmi une térafloppée de google bigtable-like (ou amazon simpledb-like) libres qui émergent comme les fleurs au printemps ! L'avenir est radieux :)
> Tu es en train de me raconter que la RAM, c'est bien pour faire du cache. Ben, c'est évident. Mais il est encore difficile d'imaginer des PC avec plus de 64 go de RAM, et cela coute d'ailleurs une véritable fortune.
De fait, une solution de stockage de masse ultra rapide de plus de 64 GB coute une fortune, qu'il s'agisse de SSD pro, d'un IOdrive, ou de solution persistante "ram based" (= où il faut de toutes façons, là aussi, payer pour la quantité de ram).
En revanche l'OS (ou l'applicatif, s'il est bien fait) cachera les pages "chaudes", réellement utilisées/accédées et beaucoup moins les données "mortes", ce qui permet parfois d'avoir de bonnes performances avec une quantité de ram largement inférieure aux jeux de données complètes sur disque dur (tandis qu'une solution de stockage totalement en ram sans autre forme de persistance doit pouvoir stocker tout le jeux de données).
Mais tu as raison d'amener cette question dans la discussion : c'est vraiment le prix, en terme de rentabilité par IOPS, en ne négligeant pas l'état de l'art des matériels classiques (controlleurs raid, chipsets de CM, RAM), et en prenant en compte les couts indirects (dont la conso électrique) qui fera la différence. Certains ce sont amusés à calculer les rapports performances/prix SSD vs. raid matériel sous diverses charges de benchmarks SQL typiques, et à l'heure actuelle les résultats ne sont pas encore univoques.
> De plus comparer des disques dur avec un fusio-io (pas un SSD!), je crois que l'on ne parle pas vraiment de la même chose.
> Le fusion IO propose presque 100 000 IO en écriture 4k, ce qui représente le pire cas. Ce n'est pas le même monde.
Oui pardon, je répondais au « pourquoi "ce genre de jouets" n'existe pas plus » en extrapolant aux solutions SSD et RAM+BBU (I-RAM, RAMSAN & co) en général (et non aux résultats épatants* de l'IOdrive).
Cela étant : je comparais les solutions classiques en général vs. les solutions alternatives modernes "en général", mais je ne compare pas "un SSD" ou juste "des disques durs" au FusioIO, j'indiquais justement que dans ce type de comparatifs qu'il ne faut pas négliger le write-cache des controlleurs RAID modernes, et la qté de ram qu'on peux coller pour pas cher. Ces derniers permettent d'élever considérablement les IOPS sur les données chaudes, et on (nous autres les geeks technophiles ;) a souvent tendance à oublier de les prendre en compte dans les comparaisons avec les nouveaux produits exitants comme l'IOdrive de FusionIO.
Le iodrive coute la bagatelle de 3000$ pour 80 GB (et 14 000$ pour le 320 GB) : pour ce prix, on peux mettre en place un _gros_ système RAID encaissant un bon paquet d'I/O ! Une machine avec controlleur RAID récent (par ex. avec 1 GB de RAM + BBU, qui permet d'aggréger un bon paquet d'I/O de lui même), et 10 disques 15 krpm en RAID 10 derrière (pour se répartir le reste des I/O non agrégées) offre de bonnes performances, un bon volume de stockage - et de la redondance/résistance aux pannes.
Bref, les produits FusioIO sont surement idéals pour certains types d'utilisation, mais pas encore la solution miracle.
Autrement ce joli joujou ment à l'OS et ne synchronise pas réellement les données lorsqu'on lui demande, ce qui est dangereux parce qu'il n'est pas protégé par une BBU (à la différence d'un controlleur RAID correct). Il fournis néanmoins un mode de configuration permettant de forcer les sync() à être honnorés, et dans ces conditions les performances sont considérablement réduites. (et puis les 100 kIOPS, c'est les données constructeur hein ;).
> De façon générale il faut préférer Postgres à MySQL en cas de forte charge [...] (sans compter qu'il n'y a pas de méthode pour mettre en cluster simplement)
ENORME ! :)
+1 point de mauvaise foi postgrefanboyiste, bien mérité dans ce cas :)
La fameuse capacité de montée en charge et de mise en cluster/répartition horizontale de pg, qui fait qu'il est utilisé sur tout les gros LAMP connus comme wikipedia, youtube, yahoo, digg, livejournal, flickr, facebook, ...). heu,...
> En plus, dans 2 ans, si cela rame, il suffit de rajouter un serveur (et de virer la machine la plus ancienne).
Certes, mais attention, la réplic va permettre sans effort :
1- La haute disponibilité tout les accès (lectures et écritures) (le service ne s'interrompt pas si un serveur est en carafe ou en maintenance).
2- La "scalabilité" horizontale des lectures (on ajoute un serveur et hop, le système encaisse plus de selects).
En revanche il ne suffit pas d'ajouter des serveurs pour "scaler" les écritures, car tout les serveurs d'un même cluster doivent recevoir et appliquer toutes les requêtes en écriture (par opposition à la lecture qui peut-être dispatchée entre les machines), que ce soit directement depuis l'applicatif ou depuis un autre serveur du cluster via la réplication.
Pour pouvoir répartir horizontalement les écritures, il faut faire des modifications généralement complexes et couteuses dans le code applicatif afin d'implémenter une forme de partitionnement horizontal/sharding (découper les tables et les assigner à des groupes/clusters de SGBD distincts, et se passer des jointures entre ces données distinctes, gérer les accès aux divers clusters selon le type de données ou les clefs de partitionnement, etc).
Arrivé à ce point, et tant qu'à faire, il peut devenir plus intéressant d'envisager une solution plus moderne (et hype ;) de key-value store ou similaire, naturellement distribué (à la CoucheDB, Tokyo Cabinet et consorts).
[^] # Re: sécurité...
Posté par herodiade . En réponse au journal WireShark la capture réseau. Évalué à 2.
Selon les besoins, on peux se passer complètement de wireshark pour la dissection des paquets, et utiliser des outils comme tcpflows, tcpextract et foremost (en ligne de commande, donc scriptables, etc). Par exemple on peux extraire des dumps pcap "bruts" les fichiers transférés sur le réseau sans problème.
ngrep couvre aussi (en cli) certains cas d'utilisation de wireshark.
[^] # Re: En effet
Posté par herodiade . En réponse au journal Spice est enfin libéré. Évalué à 6.
Il faut dire (pour avoir suivi l'échange sur la m-l) que la première annonce sur la m-l qemu semble avoir été faite par un des devs de l'ex qumranet, venant visiblement du monde du dev windows & proprio, donc pas avec le tact et le sens des us et coutumes des m-l du libre nécessaire. Par ex. il en est rapidement venu à lancer une grosse attaque perso contre Antony Liguori (qui lead le dev Qemu désormais). Heureusement un dev spice moins "extraterrestre" à pris le relai dans la discussion.
Je crois qu'il y a eu comme un petit "choc des cultures", que les devs parviendront certainement à surmonter.
Voir sur le même sujet les réactions diverses à l'annonce du Red Hat Enterprise Virtualization Manager, adapté d'un produit dont RH a hérité en achetant Qumranet, et qui, pour cette raison, ne tourne pour le moment que sous Windows 2003 (classe, non ? mais RH dit avoir un port vers Linux en cours de dev).
J'au aussi l'impression que la foultitude de forks peu coopératifs qu'à subit Qemu ces dernières années (KVM, qui est un fork amical mais devenu difficile à merger, une partie de Xen, une partie de virtualbox, le nouveau machin de novell dont j'ai oublié le nom, ...) semble rendre les devs Qemu un peu circonspects lorsqu'on leur présente comme la dernière merveille du monde - à merger illico et par leur soin - un gros code-dump monolithique forkant lourdement une version antédéluvienne de Qemu.
Et puis effectivement des devs Qemu ont demandé des mesures montrant si spice était rellement plus performant que l'outil existant et standard (vnc), et si oui pourquoi (savoir pquoi c'est plus performant permet de ne pas endommager par erreur une condition nécessaire à l'obtention de ces bonnes perfs, et/ou d'envisager de merger la bonne idée dans le proto canonique vnc).
> Concernant Xen, rien à l'horizon pour la version 4.0 qui va sortir sous peu. Seul deux threads en parlent et aucun ne fait encore allusion à un commencement d'inclusion.
Ca semble au moins être en projet ; Ian Darwin lui-même dit : "We're planning to do this, hopefully into qemu 0.13 which is planned for the middle of this year" :
http://lists.gnu.org/archive/html/qemu-devel/2010-01/msg0081(...)
http://lists.gnu.org/archive/html/qemu-devel/2010-01/msg0081(...)
http://lists.xensource.com/archives/html/xen-devel/2010-01/m(...)
[^] # Re: questions (réutilisations, multiplexage, compatibilité)
Posté par herodiade . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 2.
C'est en fait dans ce cadre (toujours pour du Nagios) que je posais ma question ; à savoir : la possibilité de réutiliser un composant pour faire quelque chose d'autres (mais toujours relatif à nagios/shinken). Par ex. re-utiliser le parseur de conf, indépendamment du reste, pour faire un petit outil cli qui valide un changement, ou qui génère un hostexinfo.cfg automatiquement, ou qui fait un diagramme de gantt à partir des timeperiod, ce genre de choses quoi... Depuis j'ai regardé ton code et j'ai ma réponse (qui est: oui, c'est super modulaire, kewl :).
- [...] Donc tu as tout de même une limite sur le nombre que tu peux lancer en parallèle. Ce nombre est complexe a déterminer suivant le tyype de sonde [...]
C'est là que le multiplexage et le modèle évènementiel rendent service, justement. Il n'y a rien à déterminer à l'avance, le parallélisme est mis en œuvre par le noyau.
On peux donner autant de socket qu'on veut à un seul processus (même des centaines de milliers, si on utilise quelque chose de plus scalable que select(2), cf. haproxy par ex.), et ce processus travaille dès que l'une d'elles a des données dispos à lire. Au plus fort de la charge, le processus passe tout son temps (il utilise un cœur de cpu à plein) à faire les vrais traitements des données utiles en transit, aussi vite qu'il peut. Lorsqu'il n'y a rien à lire ou écrire, le processus dort. Dans tout les cas, et quelque soit le nombre de sockets dont il est responsable, le processus ne consomme que les ressources (ram et cpu) nécessaires au vrais traitements qu'il doit faire.
Un exemple : c'est pour ces raisons (une mainloop événementielle coté lighttpd et nginx vs. des pools de workers, threads ou forks, un pour chaque requète simultanée coté apache) que nginx et lighttpd ne sont pas affectés par le récent "slowloris", alors qu'apache s'écroule
Pour les mêmes raisons, lorsque plusieurs hôtes ne répondent pas aux requêtes, les plugins classique mais parallélisés vont sans doute occuper des ressources (x poller en attente + x * le plugin lui-même) jusqu'aux timeouts, et donc ralentir les autres traitements (si on essaie de maintenir un nombre constant/max de checks en cours) ou mettre le serveur de monitoring à genoux (si on ne limite pas), au moment ou justement on a besoin de monitoring précis et réactif parce qu'il y a des soucis sur le réseau.
De même, un processus dédié peut certainement gérer sans charge aucune quelques milliers de raw sockets pour envoyer/recevoir des pings en natif (sans "popen('/bin/ping'...)", mais il faut que le processus soit root ou la capabilty CAP_NET_RAW...) et avoir un résultat de check_host_alive à la seconde près sur un large parc. Dans le genre de http://gitorious.org/poe-component-client-ping .
Des docs pythoniques sur le sujet:
http://squirl.nightmare.com/medusa/async_sockets.html
http://docs.python.org/library/asyncore.html
http://docs.python.org/library/asynchat.html
- Je n'ia pas encore trouvé de méthode facile çà utiliser pour l'utilisateur (il "décrit" le plugin à utilsier dans la conf de sa commande? On se base sur une reconnaissance de la commande en expression régulière?)
C'est vrais, je ne vois pas non plus de moyen élégant pour substituer l'exécution des plugins connus/réimplémentés par une version ad hoc...
- Soit, comme tu dit, faire la substitution lorsqu'on reconnait un nom de plugin en arg d'une check_command... mais le parsing, berk
- Soit de façon déclarative (eg. "check_command check_tcp_shinken"). Moindre suprise, mais divergence avec une conf nagios brute.
- Soit de façon déclarative, dans un fichier de conf distinct et propre à shinken (genre shinken-specific.cfg), surchargeant la définition des plugins classiques. La aussi, ca fait une nouvelle divergence avec la conf nagios brute.
- Soit en fournissant un exécutable effectif (/usr/bin/check_tcp), qui au lieu d'effectuer le check lui-même, se contente de donner l'ordre de le faire au poller en charge des sockets, et retourne un code "maison" (qui signifierai : je n'ai pas le résultat, attends que le poller te le donne) (et/ou effectuerai le check lui même si et seulement si il n'a pas réussi à déléguer le check à un poller). Mais on ne s'affranchit alors pas de la surcharge inutile des fork()/exec()/popen() & reap, et puis c'est tarabiscoté ;)
Rien de totalement naturel et clean, effectivement.
- Le fait de dédier des pollers je ne suis pas sûr, car un poller pourrait avoir plusieurs types de workers
Effectivement, j'avais cru que les pollers se chargeaient de lancer les actions (pas vu le worker.py).
Désolé d'amener la discussion sur ces petits détails ; shinken semble déjà un super progrès par rapport à l'architecture de nagios :). La possibilité de faire tourner plein de checks classiques légers (tcp, http, udp, icmp) a intervalles très fréquents sans saturer le serveur de monitoring est peut-être un besoin plus perso qu'autre chose (mon serveur de monitoring fait tourner plein de trucs gourmands en plus de nagios, j'ai très peu de checks lourds en perl ou autre, et j'aimerai être avertis des problèmes plus vite qu'actuellement ...).
# questions (réutilisations, multiplexage, compatibilité)
Posté par herodiade . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 5.
c'est un joli projet et j'espère que les autres devs seront receptifs.
J'ai quelques questions.
- Est-ce que les composants sont réutilisables sortis de l'ensemble?
par ex. peut-on réutiliser le parsing de conf pour faire autre chose? est-ce qu'ils ont une api "publique" ou seulement interne? (par ex. pour attaquer directement les scheduler et leur demander où ils en sont, changer leurs priorités, etc).
- En parlant de montée en charge ("scalability")...
comme le fait remarquer quelqu'un en réponse sur la m-l, l'essentiel de la durée d'execution d'un plugin type semble être passé à attendre (attente pour pouvoir écrire sur une socket, attente d'une réponse...) (plus le temps du exec() et envois du retour à nagios, bien sûr).
J'ai l'impression que l'execution des plugins en tant que commandes externes impose une limite au nombres de tests/seconde possibles : outre la surcharge de l'execution externe, en lancer un trop grand nombre simultanément (et même s'ils ne font pour ainsi dire rien d'autre qu'attendre, et quand bien même l'architecture à mutiple poller + NDX permettrai d'en lancer 10000 à la fois) signifirait saturer le/les système de processus sleeping.
Est-ce que des plugins très couramment utilisés comme check_tcp, check_http, et check_smtp pourraient être re-implementés en interne, et executés simultanément par multiplexage asynchrone et evenementiel de sockets ? par ex. en les regroupants quand c'est possible sur un seul (ou, disons, une poignée de) processus gerant x "checks classiques sur tcp ou udp ou raw (icmp)" et multiplexant via epoll()/kqueue() etc à la façon nginx/haproxy. Il existe plusieurs libs python pour faire ce genre de choses (twisted, mais il ne supporte pas IPv6, PyEvents, libevent-python...).
Le modèle des multiples pollers de shinken semble permettre ceci, au sens où avoir un couple de poller spécialisés/dédié aux checks de bases reposants sur tcp ne devrait pas empecher l'execution d'autres plugins en parralele (?).
- Quel est le niveau de compatibilité visé avec un nagios3 ?
seulement compatible au sens de pouvoir réutilise l'ancienne conf et certains plugins à condition d'y adjoindre des confs spécifiques à shinken ? générer un status.dat ? etc
# NetFlows != Cisco
Posté par herodiade . En réponse à la dépêche netMET devient netMAT, passe sous CeCILL et s'offre un site web !. Évalué à 2.
[^] # Re: SoGo ou l'ouverture et les standards ouverts
Posté par herodiade . En réponse à la dépêche Nouvelle version de Mozilla Lightning et SOGo. Évalué à 2.
> un découplage restreint (quoique meilleur que - disons - Zimbra) : il est son propre serveur de stockage
Je suis d'accord avec ça. Pour avoir subit Zarafa en production, stocker les mails en bdd
- est vraiment une fausse bonne idée, il faut des énormes serveurs pour tenir la charge qu'un simple imap sur maildir peux encaisser sans efforts, c'est frappant. peut-être à cause du maintient des indexes, des contraintes d'intégrité, des méthodes d'accès (passer par un intérpreteur et query planner sql), ou de la concurence/des verroux ...
- rends les migrations/changements/adaptations/réparations à chaud difficiles ; ça fait perdre énormement de souplesse et de possibilité de rattraper les boulettes, par rapport à un format de stockage de mail classique où l'on peux manipuler les mails directement avec des outils courants ou quelques lignes de script, déplacer/répartir quelques mailboxes sur un autre serveur, faire des backups incrémentaux et restaurer mail par mail, remplacer un deamon IMAP ou LDA qui ne convient pas/plus, etc.
- Situation dans leur cas aggravée par le choix d'une structure de bdd collant au plus près (sans trop d'abstraction quoi) aux contraintes de MAPI, ce qui la rends assez imbitables (avec des colonnes contenant des champs de bits, les mails décomposés en "properties" et splittés sur x rows, etc). Schéma non documenté, bien sûr.
Cette différence d'approche (Zarafa monolithique et SOGo "intégrable") est aussi sensible en ce qui concerne les choix de protocoles d'accès privilégiés.
Dans le cas de Zarafa, on a pour protocole principal (celui de l'extension Outlook avec laquelle ils font leur beurre) une popotte maison (des requètes MAPI encapsulées dans du SOAP), et en guise de complément du pauvre un peu délaissé,des backends IMAP et iCal-over-http (oui oui, même pas du CalDAV) très frustres et probablement très peu utilisés (c'est ce que je déduit du fait qu'elles sont archi buggués). Ok, et de l'ActiveSync via Z-Push (j'ai pas testé, ça marche bien ?). Le filtrage/tris coté serveur n'est accessible que par le proto de leur client Outlook lourd (inaccessible depuis les autres clients, bye bye thunderbird), idem pour les carnets d'adresse. Pensez-y : si vous migrez hors de Zarafa, vous perdez les règles de tris et les contacts (et quelques mails si vous subissez autant de bugs que moi avec leur passerelle IMAP)...
A l'opposé, SOGo semble avoir un parti pris sans concession pour les protocoles standards, ce qui rejoint ton constat au sujet de sa capacité d'"intégration" (avec d'autres softs). Le support CalDAV est impec, les tris sont en Sieve (tout frais, mes platres), les contacts accessibles en CardDAV (déjà !) et/ou GroupDAV, le mail est délégué au serveur IMAP de son choix (qui saura surement gérer ça mieux q'un group/bloat-ware) sans réinvention d'un proto de mail-over-la-roue... sans parler des contributions à Thunderbird/Lightning (justement en vue d'améliorer le support des protocoles standards, et aussi de donner acces aux infos de disponibilité/freebusy, etc...). L'extension Outlook suggérée (Zideone, en béta qui fait peur) se contente elle-même d'ajouter à l'infâme le support des standards qu'il aurait toujours du avoir, ce qui peut aussi le rendre utile pour communiquer avec les groupware concurents. C'est l'opposé du vendor lock-in.
Par contre, un avantage à mes yeux en faveur de Zarafa, c'est qu'il ne fait pas tout pour faire peur à l'admin : les dépendances sont limités, c'est tout en C++ pas trop jojo mais "devinable" sinon lisible, les fichiers de conf sont dans /etc (et ont une syntaxe bateau), les logs dans syslog, les libs dans /usr/lib, les données statiques dans /usr/share, ça se compile bien (./configure ; make ; make install), ils fournissent des packages très propres en i386 & amd64 pour beaucoup de distros (et c'est facile de les refaire soi même). Bref, si vous avez installé quasi n'importe quel logiciel serveur du monde libre récement, d'apache à postfix ou exim en passant par postgresql ou mysql ou dovecot ou bind ou openldap..., vous ne serez pas dépaysés.
Tandis que coté SOGo, tout semble fait la façon la plus gratuitement originale possible (par rapport à ce avec quoi les admins sont généralement habitués à travailler). Tellement bizarre pour moi que j'ai renoncé de ce fait à l'utiliser en prod (à la place de l'autre zouave) de peur de ne pouvoir le comprendre, diagnostiquer, réparer, maintenir, reconfigurer ou upgrader, et malgré ses indéniables charmes (fonctionalités, souplesse et standards surtout). Codé en Objective-C (cool, mais du coup je crains qu'il n'y ai pas bcp de monde qui envoi des patchs, et donc que les bugs restent là), reposant sur une large tripotée de libs obscures et interdépendantes (et pas présentes sous debian, centos, fedora ni ubuntu) qui viennent d'un projet semblant à l'abandon (opengroupware), et qui sont stockées dans des dépots mercurial (yo, encore un truc à apprendre), et qu'il faut patcher (les libs, vous suivez ?) spécialement pour le SOGo ; dépendance forte à GNUstep (t'a déjà mis ça sur un serveur non Apple ou NeXT cher confrère ?), y compris pour le stockage de la conf (à mort la Linux Standard Base) et aussi pour son format. Quand tu a réussi à le compiler une fois (et make-installé des trucs qui vont se coller dans les coins les plus improbable du système, fait des ldconfigs à tour de bras pour que ça passe), puis mis en prod, je pense que tu espère ne jamais avoir à l'upgrader. Dommage. Quelqu'un a-t-il osé l'utiliser en prod parmis vous ?
# Coccinelle, userland
Posté par herodiade . En réponse à la dépêche Sparse repasse à l'attaque. Évalué à 2.
En fait il est déjà utilisé par quelques projets en espace utilisateur. A ma connaissance, qemu et xfsprogs intègrent des vérifications basées sur sparse. Le fait que ces deux projets soient fréquentés par des devs kernel n'est peut-être pas fortuit : pour avoir essayé sans succès d'utiliser sparse à partir de la "documentation" disponible, j'ai supposé qu'il fallait être soit super doué, soit déjà introduit par la connaissance de cas d'utilisations concrets (comme on en trouve dans le noyau). D'autre part les en-têtes de la glibc (et en pratique tout le /usr/include) produisent de copieux warnings, ce qui rends l'utilisation en espace utilisateur laborieuse. Bref, avec un peu plus de doc et d'exemples, et un solide système de filtres, sparse serait plus simple d'accès pour les "non kernel-hackers".
Je profite de ce poste pour signaler Coccinelle, un analyseur statique mignon tout plein et oublié dans l'inventaire de la dépêche. Il est très facile à utiliser (il suffit généralement d'écrire des "patches sémantiques" de quelques lignes adaptés à ses besoins, cf. les exemples plus bas), et il ne nécessite pas d'annotations spécifiques dans le code cible.
Coccinelle est un projet universitaire (franco-suédois), mais il a déjà donné des résultats très concrets, sous la forme idéale de nombreux patchs envoyés sur LKML corrigeant de vrais bugs (exemples : http://lkml.indiana.edu/hypermail/linux/kernel/0806.3/0094.h(...) , http://lkml.org/lkml/2009/9/22/198 , ...).
Deux obstacles au succès de Coccinelle cependant : il est écrit en Objective Caml (sans jugement sur la pertinence technique de ce choix de langage, mais les utilisateurs de l'outil sont des développeurs C), et il incorpore son propre parseur C (ce qui l'expose à des problèmes de compatibilité en traitant des sources prévues pour gcc), à la différence de sparse, qui se branche facilement sur gcc ou llvm.
# le site de Coccinelle
http://coccinelle.lip6.fr
# une introduction à Coccinelle par Val Aurora (anciennement Valerie Henson)
http://lwn.net/Articles/315686/
p.s.: en ce qui concerne la question de la licence de sparse :
- Linus Torvalds donne une motivations spécifique sur le choix d'une licence incompatible avec la GPL, dans la FAQ de sparse. Il y explique qu'il souhaite (souhaitait) ainsi prendre le contrepied du parti prix monolithique de gcc (« I like the GPL, but as rms says, "Linus is just an engineer". I refuse to use a license if that license causes bad engineering decisions. I want the front-end to be considered a separate project ».
cf.
http://git.kernel.org/?p=linux/kernel/git/torvalds/sparse.gi(...)
- Mais il reconnait que l'OSL n'est pas le meilleur choix :
http://www.mail-archive.com/linux-sparse@vger.kernel.org/msg(...)
- De toutes façons, Novafora (qui a hérité de la propriété intellectuelle de Transmeta) a accepté de re-licencer sous MIT il y a quelques mois :
http://markmail.org/message/qijmu2cu4gbi74te
[^] # Re: Mon problème avec Outlook
Posté par herodiade . En réponse au journal Microsoft va documenter le format de fichier .pst de Outlook. Évalué à 1.
# Ce dont il s'agit (les workers threads sans effort)
Posté par herodiade . En réponse au journal Grand Central sous licence apache. Évalué à 7.
L'article d'Ars Technica sur les nouveautés de Snow Leopart décrit les choses de façon synthétique mais agréable à lire :
# Les "blocks" (ajout du support des closures/fonctions anonymes aux langages C, C++ et Objective-C)
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a(...)
# Grand Central Dispatch
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a(...)
# Adapter du code existant pour en tirer partis
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a(...)
En gros, l'adaptation d'un bout de code pour en faire une "worker thread" devient tellement simple et naturelle (pour ainsi dire, deux ou trois lignes claires à ajouter) que les développeurs vont le faire, et qu'on vas peut-être enfin exploiter partie de nos cpus multicores ;).
[^] # Re: Phonon était pas prêt
Posté par herodiade . En réponse au journal Qt/Phonon bientôt mort et remplacé. Évalué à 10.
Voila ce qu'en disait Thomas Vander Stichele, un core dev de GStreamer / Fludo (et accessoirement sympathisant des ambitions de PA) pas plus tard que la semaine dernière :
http://thomas.apestaart.org/log/?p=1012
C'est aussi ce que je reproche le plus à PA. Il est affreusement buggué, certes.
Mais le problème n'est pas là ; comme tout logiciel très utilisés, il pourrait se bonifier rapidement et ne pas (trop) taper sur le système de ses utilisateurs s'il n'était pas si opaque, automagique et uber-complexe, tout ce qui fait que peu de gens rapportent les bugs qu'ils rencontrent, et peu de gens peuvent aussi les contourner ou trouver des workarounds. Aussi, la personnalité de Lennart Poettering n'aide pas forcément (à faire des rapports de bugs, à faire reconnaitre qu'un comportement donné est un bug, à faire admettre des workarounds pour avoir le son qui marche dans la vraie vie, celle des users de desktops)...
Un logiciel libre très utilisé qui donne à ses utilisateurs les moyens de faire des bons rapports de bugs, sinon de le fixer eux-même (doc interne, doc des interactions, messages d'erreurs clairs, aux bons endroits et bien formulés, modes verbose efficaces, etc) est promis à une stabilité irréprochable en un rien de temps. Après 5 ans d'existence PA ne devrait pas en être encore au stade du "je pers le controle de la carte son et je ne loggue rien".
Merde, même le noyau - et c'est pourtant pas facile à ce niveau du système - est incroyablement plus débugguable que PA (printk très pertinents, docs riches, myriades d'outils de traçage, profiling, débogguage des verroux, des problèmes mémoire, netconsole, autodocumentation des états internes via /proc et /sys ...) ! Résultat, les bugs sont corrigés. Et les développeurs kernel ne t'envoient pas chier parce que tu rencontre un bug en utilisant un logiciel proprio sur leur système, ou rejettent une solution réduisant drastiquement les problèmes parce qu'elle serait "moins pure" (voyez la récente aventure d'Alan Cox et des standards posix relatifs aux ttys).
Vous faites quoi, vous, quand PA décide, sur votre système, de ne plus sortir de son, ou crash silencieusement ? vous arrivez à trouver de quoi faire un rapport de bug ? perso je lance un strace en desespoir de cause (mais ça ne sert à rienà, puis le le "/etc/init.d/pulseaudio restart" (inutile aussi, visiblement PA ne doit pas être lancé ainsi), puis je reboot. Classe.
[^] # Re: Sieve
Posté par herodiade . En réponse au journal Roundcube, simple mais super efficace !. Évalué à 10.
Procmail est un vénérable outil unix capable de faire un peu tout (et n'importe quoi, y compris exécuter des commande arbitraires). Son langage n'est pas normalisé autrement que par son implémentation, et je ne crois pas qu'il y ai beaucoup d'autres outils que procmail lui-même qui soient capables d'éditer visuellement un .procmailrc arbitraire (je ne parle pas d'outils capables d'éditer une petite partie de sa syntaxe, typoquement : uniquement des fichiers qu'ils ont généré eux même). Le dépot de script .procmailrc sur le serveur nécessite un accès au système de fichier (ou une bidouille "site spécifique" pour récupérer/déposer au bon endroit : la mise à jour du jeux de règles n'est pas prise en charge par procmail lui même).
Bref, procmail est puissant, souple, non standard et potentiellement dangereux.
Sieve est un langage de description de filtrage (tris, bounce, vacation/notification d'absence, forwards, ...) de mails coté serveur standardisé (décrit dans une foultitude de RFC en fait, à commencer par la RFC 5228), et conçu pour permet de déployer des jeux de règles écrits par des gens pas forcément de confiance sur un des serveurs qu'on ne veux pas compromettre (il ne permet pas l'exécution de commandes externes, évite les boucles infinies, ...), et pour permettre l'interopérabilité et l'édition/génération de jeux de règles à partir de clients divers (éventuellement graphiques : webmails...).
Le standard sieve a un petit frère nommé managesieve, pas encore majeur (c'est un draft de RFC, bien qu'il soit déjà implémenté dans plein d'outils libres), qui décrit un protocole de téléchargement/upload des jeux de règles sur les serveurs, assez insipré de l'IMAP (simplifié), sans que le client n'ai a accéder au système de fichier ni même à savoir où le serveur place ces fichiers.
Le support sieve et/ou managesive est implémentés dans divers clients (par exemples des plugins pour les webmails Squirrelmail, Horde, Roundcube, l'extension sieve pour Thunderbird, un support natif dans Kmail et Mullbery, dans divers LDA tels que celui fournis avec Dovecot, avec Cyrus, avec DBmail, avec Courrier, Exim ...), et normalement les jeux de rêgles uploadés par l'un sont téléchargeables et éditables tels quels par l'autre (c'est interopérable quoi).
Bref :
Procmail est très adapté sur une machine dont les utilisateurs sont de confiance, ou lorsque son utilisation et la mise à jour des ses rulesets est restreinte, limitée et sous contrôle (par ex. avec le subset de langage procmail implémenté par Horde IMP), ou écrit par l'admin pour faire de puissant traitements sur des mails transitant sur un serveur / sur une boite automatisée, ou lorsqu'on a besoin de brancher des filtres (par ex. antispam ou antivirus) au moment de la distribution du mail.
Sieve est plus adapté pour un serveur mail hébergeant une bonne brouette d'utilisateurs pas forcément "de confiance", et lorsqu'on apprécie les bénéfice d'une solution standardisé interopérable (pouvoir changer de client/webmail/LDA/etc... et continuer de pouvoir manipuler graphiquement ses règles de tris). Le fait d'être souvent implémenté par les LDA fournis par les divers serveurs IMAP le rends aussi plus adapté que procmail à l'hébergement virtuel de masse à mes yeux (le path des scripts, le path et le format des mailboxes/mh/maildirs, le séparateur IMAP, l'uid/gid de destination du mail, etc. lui sont alors directement indiqué par le serveur IMAP qui de toutes façons doit connaitre ces infos), alors que l'utilisation de procmail impose de forte contraintes sur l'hébergement virtuel.
[^] # Re: un titre à scandale
Posté par herodiade . En réponse au journal Alan Cox jette l'éponge. Évalué à 6.
> Ben tu devrais pourtant savoir que l'essentiel des gros contributeurs sont pourtant payes pour bosser sur le noyau.
Oui bon et il faudrait surtout indiquer que ce thread dérive à partir d'une fausse information.
La raison que Linux a donné concernant son choix de CFS de Molnar plutôt que le SD de Kolivas est exactement la même que celle pour laquelle il a passé un savon à Alan Cox dans les mails évoqués ici (plus précisément celui-ci [http://lkml.org/lkml/2009/7/28/373]) : parce qu'au lieu de corriger les problèmes relevés dans son propre code - et à l'inverse de l'attitude de Molnar - Kolivas refusait d'admettre la moindre critique, de considérer que le moindre bug touchait son code (comme ici, Cox vis à vis de son patch et d'Emacs et KDEsu).
Moralité : je pense que votre mémoire vous joue des tours. Il a certes été éliminé parce que Linus a jugé qu'il risquait de mal assurer la maintenance, mais ce jugement était extrapolé de son attitude pendant les débats, et non de son job.
Voir pour mémoire :
http://kerneltrap.org/node/14008
Trust me, I know what matters. And a person who can actually be bothered to follow up on problem reports is a *hell* of a lot more important than one who just argues with reporters. (Torvalds).
En outre, contrairement à ce qui est dit plus haut, dans son l'explication de son départ final ([http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.ht(...)]), Con Kolivas ne prétends pas que son problème tient à ce que les développeurs professionnels sont privilégiés, mais à ce que, dans les choix qui sont fait, les besoins du noyau en environnement pro/serveur aient préséance sur les besoins de linux en environnement desktop.
[^] # Re: ssh comme OpenSSH ?
Posté par herodiade . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 7.
Voici un papier détaillé sur le sujet :
http://www.usenix.org/events/usenix09/tech/full_papers/guo/g(...)
[^] # Re: ssh comme OpenSSH ?
Posté par herodiade . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 10.
Voyez sa réponse concernant la sécurisation de Windows : elle concerne les mécanismes mis en place par le kernel et la façon dont sont chargées les bibliothèques. N'entrent pas en considération dans ses réponses - et c'est normal - les aspects sécurité relatif aux logiciels en espace utilisateur pur (les choix de MS concernant l'ActiveX dans MSIE et Outlook, l'authentification système, les fonctions "sûres" offertes par la libc, ce genre de choses). Même chose au sujet de ses réponses sur OpenBSD : il faut comprendre qu'il parle du noyau. Aussi lorsqu'il dit que le projet est sans intérêt, je ne pense pas que sa remarque concerne OpenSSH (qu'il trouve peut-être utile, mais ça n'est pas dans son radar en tant qu'expert de la sécurité noyau).
Lorsqu'il indique que les développeur du noyau Linux font aussi des recherches systématiques par classes de failles (c'est la vérité : voyez par exemple le joli travail de l'équipe qui développe Coccinelle, l'utilisation de certains flags gcc, le développement de Sparse...), il ne s'intéresse pas aux différences pratique de méthode au delà du noyau (le code source de tout l'OS d'OpenBSD - serveurs web, mail, libc, xorg, etc. compris - est dans un seul et même dépôt, et les recherches de classes de failles se font sur l'ensemble de la base de code de l'OS, ce qui serait beaucoup plus difficile avec le code inclus dans une distribution Linux).
Une précision intéressante au sujet de la question des audits automatisés / systématiques : le problème de déreferencement de pointeur noyau utilisé par son exploit a été identifié et relevé par l'outil d'analyse statique et propriétaire Coverty avant qu'il soit découvert et corrigé par les développeurs noyaux, et avant la diffusion de l'exploit de Spender. Il semblerait (selon Coverty) que les développeurs noyaux Linux ne se donnent plus trop la peine de consulter les analyses de code générées par leur outil, ou du moins de corriger les erreurs relevées, comme ils le faisaient à une époque. A contrario les développeurs de Cocinnelle envoyant directement des patchs sur LKML, les bugs relevés par cet outils sont corrigés. Ce qui me fait prendre sa réponse au sujet de la pertinence de développeurs "responsables de la sécurité du noyau" avec des pincettes : il semble qu'il faille que quelqu'un se colle spécifiquement à la lecture des rapports d'analyses appareillées et à l'écriture de patchs pour que certains problèmes soient corrigés (de même que les régressions ne sont vraiment suivies que depuis que qu'un développeur dédié se donne la peine de faire le suivi global _et_ de poster des comptes rendus sur LKML).
Je trouve enfin que ses remarques sur l'utilité, la complexité, et la taille du noyau d'OpenBSD sont assez justes : c'est un noyau très rudimentaire par rapport à Linux, évoluant lentement, et offrant bien moins de fonctionnalités et des performances assez limitées. Il est donc normal que ce noyau soit moins exposé aux problèmes de sécurité. Précisons tout de même que c'est un choix intentionnel de la part des développeur de cet OS (des gros patchs, par exemple implémentant un support des ACL et RBAC, sont régulièrement rejetés au motif que leur complexité risque de fragiliser le système et/ou de rendre la lecture et les audits plus difficiles; c'est aussi pour ça que des fonctionnalités faciles à porter à partir du code de NetBSD ne sont pourtant pas reprises). La contrepartie, c'est que, comme la réponse de Spender le laisse entendre, OpenBSD n'est pas le choix idéal - est "inutile" - pour de nombreux cas d'utilisation (par ex. si besoin de système de fichier performant, de drivers rares, de LVM, ...).
Et c'est où je voulais en venir : dommage qu'aucune question n'ait été posée sur la façon dont Spender établit les limites diverses, accepterai de céder sur certaines exigences, quelle marge de compromis acceptera-t-il entre performances/fonctionnalités d'une part et sécurité d'autre part. Et en corollaire : quels sont les coûts actuels, hors sécu, de ses jeux de patchs grsecurity (que perds-on au profit de la sécurité). Parce que c'est (pour ce dont je me souviens, ça date) précisément son incapacité à faire coïncider ses exigences (sécurité) avec celles des autres (performances, mémoire disponible, ...) qui avait provoqué le rejet net de grsecurity lorsqu'il l'avait initialement proposé pour inclusion dans Linux. Pour ce que j'en comprends, il semble que Spender trouve qu'OpenBSD ne lâche pas assez de lest et manque de perfs ou fonctionnalité, et trouve qu'à l'inverse le noyau Linux accepte trop de changements, trop vite, ne prends pas assez de temps pour analyser ce qui est une faille ou pas, etc. Quoiqu'il en soit, c'est toujours un compromis difficile, mouvant, dynamique, et reflétant l'"état des forces" en rapport à un instant t dans la communauté des développeurs et des sociétés en présence.
Hormis ce petit regret, l'interview reste utile, agréable et bienvenue bien entendu ;)
[^] # Re: Quelques commentaires
Posté par herodiade . En réponse à la dépêche Exploit local dans le noyau Linux 2.6.30. Évalué à 7.
Mais est-ce applicable pour le lot commun des patchs concernant un OS ? Pour les trois que je connais, la tâche semble ardue : ce qui est reproché aujourd'hui à Linux l'est régulièrement à Microsoft. Et OpenBSD ne prétends par faire mieux : les devs anticipent la question en martelant : "nous préférons passer du temps à prévenir et corriger plein de choses qu'à évaluer la possibilité qu'un de nos patch répare une faille de sécurité" ; il leur arrive effectivement de découvrir avoir corrigé une faille longtemps après l'application d'un patch (par ex. sur leur version d'apache).
Autrement dit, tout les fournisseurs OS sont régulièrement accusés de cacher intentionnellement la poussière sous le tapis ; et le fait que ça touche tout les OS permet justement de douter du qualificatif "intentionnellement".
Détaillons le cas de la démarche dite "proactive" (= le principe de "mieux vaut prévenir que guérir") d'OpenBSD. L'équipe de développeur est assez réduite ; à chaque nouvelle faille, et à chaque découverte de paradigmes de programmation sécurisée, ils ont pour habitude de passer tout leur CVS (contenant un OS complet hein, pas seulement le noyau) à la moulinette du rechercher/remplacer. C'était le cas lorsqu'ils ont remplacé tout les srt[n]cat/cpy par des strlcat/cpy, la plupart des atoll/atoi par des strtonum, trouvé une méthodologie plus robuste pour prévenir les débordement d'entiers, activé tel ou tel warning supplémentaire du compilateur et corrigé tout ce qui bronche, etc. : un travail de titan, et des dizaines de milliers de patchs à chaque fois. Si, pour chacun de ces patchs, il avait fallu passer plusieurs heures à chercher s'il corrigeait une faille effective, ils n'auraient jamais pu mener ces chantiers à terme, loin s'en faut.
Moralité : dans ce cas, l'effort de transparence (catégorisation des modifications appliquées dans les branches de développement de l'OS) est antithétique et préjudiciable à la sécurité effective du système. Tout simplement parce que les ressources humaines ne sont pas illimitées (peut-être qu'elle le sont chez Microsoft, mais ce n'est pas le cas pour les OS libres que je connais). Et si le "armchair security expert" était, justement, celui qui juge le résultat de haut et de loin, sans mettre les mains dans le cambouis ?
[^] # Re: Quelques commentaires
Posté par herodiade . En réponse à la dépêche Exploit local dans le noyau Linux 2.6.30. Évalué à 5.
http://archives.neohapsis.com/archives/openbsd/2003-04/1678.(...)
Tout le thread (avec des « Yup, it is incredible. Liar liar, pants on fire. ») :
http://archives.neohapsis.com/archives/openbsd/2003-04/threa(...)
[^] # Re: Drag'n drop pas encore partout
Posté par herodiade . En réponse à la dépêche Nouvelle version de Mozilla Lightning et SOGo. Évalué à 5.
Je suis justement en train de le tester (pour avoir vu ton lien ci-dessous ;). Merci !
Je m'aperçois que mon poste ci-dessus ressemble à une (non méritée) critique du logiciel. Aussi je tient à préciser pourquoi je l'avait quand même sélectionné et ai essayé de le tester, malgré une réticence devant l'inconnu (ObjC/GNUstep/...), et parmis une foultitude d'outils existants et parfois plus connus :
o L'utilisation de protocoles standards et ouverts.
o Il est libre (et il est soutenu par une entreprise, en cas de besoin de correctifs importants ou pressants...)
o SOGo a un superbe score sur https://wiki.mozilla.org/Calendar:QA_CalDAV_Support (j'en déduis que le support des standards y est excellent).
o La contribution de correctifs à Thunderbird/Lightening. Bon esprit, et très bon signe pour la qualité de l'intégration.
o En langage compilé. C'est pas une nécessité impérieuse pour moi (du php, perl ou python ne me dérangent pas), mais il doit pouvoir être très performant, et je trouve ça assez classe ;)
o Le développement semble super actif, et dans le pur esprit "release early, release often".
o C'est un calendrier, et il ne semble pas (trop) essayer de tout faire et le café avec (contre la ribambelle de groupwares bien connue ici), ou d'imposer logiciels pour les autres services concomitants (certains groupwares imposent d'avoir un IMAP sous Cyrus, ou un Postfix, etc.), ou de ramener un gros stack J2EE...
o D'après les démos et les exemples de fichiers de conf, il semble assez complet au niveau fonctionnalités (il semble qu'on puisse le caler sur son ldap, par ex., mais je n'ai pas réussi à aller si loin), dispose d'une interface web fonctionnelle, ...
[^] # Re: Drag'n drop pas encore partout
Posté par herodiade . En réponse à la dépêche Nouvelle version de Mozilla Lightning et SOGo. Évalué à 2.
> exclusivement sur des standards ouverts et 2. il prend en charge l'interface utilisateur
> uniquement et ne cherche pas à prendre en charge toute la partie serveur de messagerie
Pareil, pour moi (enfin, "ai envisagé").
Mais un rapide essai (echec) d'installation m'a fait peur ; plus précisément le fait qu'il n'y a ni doc ni paquets laissant supposer que ça a été testé sous Debian le rends un peu "risqué" pour moi, vu le peu de chances que j'ai de m'en sortir tout seul en cas de pépin avec ces technos "originales" (je ne suis pas habitué à utiliser GNUStep (ses confs, etc) pour des serveurs, les dépendances au reste de d'OGO semblent énormes et complexes et aussi à installer soi-même par les sources, je connais pas le langage objective C donc je ne peux rien relire pour comprendre un aspect opaque ou corriger un problème, l'outil (ou plutôt sa communauté) semble assez jeune etc...). Sans mettre en cause l'outil, ça fait beaucoup d'inconnues, avec le risque de planter (et ne pas savoir réparer) tout les agendas de mon entreprise à la clef.
J'ai l'impression que ce sera un superbe outil (je veux dire : même pour les bras cassés comme moi) d'ici quelque temps, lorsqu'il sera intégré dans les distros, qu'on trouvera des tutoriaux ou des réponses aux questions de bases déjà sur les archives de la m-l, que les divers paths, rôles et syntaxes des fichiers (binaires, confs, etc) et des dépendances seront documentés, etc.
En attendant je cherche encore un serveur de calendrier qui soit :
- Un peu plus ancien (ou au moins que des gens aient déjà utilisé en prod sous Debian)
- Synchronisable avec Outlook 2007 et Thunderbird + Lightning (donc iCal c'est ça ?)
- Ayant une interface web qui permet aussi l'édition (donc pas phpicalendar)
- Qui gère les freebusy, qui permette d'envoyer des meeting requests
- Standalone, pas une suite tout en un (donc pas Zimbra, Kolab et compagnie)
Quelqu'un connait la perle rare ?
[^] # Re: RAM limite ?
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 2.
En même temps, c'est assez normal : MySQL alloue explicitement de la RAM pour gérer lui-même son cache (du moins avec InnoDB, et à hauteur de ce que l'admin à configuré), tandis que PostgreSQL laisse l'OS gérer ce cache, (Linux utilisera la RAM libre dispo pour cacher les données utilisées par PG, mais cette utilisation ne sera pas "imputée" à PG, pas comptabilisée dans top/ps/...). Autrement dit : si tu utilisais la RAM ainsi "libérée" pour d'autres applis, ou enlevait les barrettes "superflues", les performances chuteraient vraisemblablement (sauf si application peu sensible à la qté de ram).
[^] # Re: Stockage en RAM
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 3.
Je ne sais pas... mais il faut dire que je n'ai pas compris la question ;)
> J'ai l'impression que l'OS voyant des fsync() partout se sent obliger des les honorer rapidement, alors qu'il y en aurait pas besoin avec un APS.
Je réitère la remarque ci-dessus : s'il ne les honore pas, il perds des données qu'il a prétendu écrire en cas de crash système ou de cable d'alim (UPS ou pas). La panne électrique n'est pas le seul malheur qui peux frapper un serveur écrivant en asynchrone.
Avec ext3, l'intervalle par défaut de commit des dirty pages est de 5 secondes : ça peux représenter un bon paquet de transactions perdues...
Un autre aspect à évoquer : les SGBDS s'efforcent de garantir la persistance de toutes les données commitées (le D de ACID) via fsync() (et c'est bien ce qui les rends gourmands en IOPS). Mais en pratique, pour une application donnée, il n'est pas rare que ce besoin de garantie de persistance ne soit vraiment impérieux que pour une toute petite fraction des écritures. Par ex. sur une appli web de commerce, c'est souvent une garantie nécessaire lorsqu'un utilisateur valide un achat en ligne, souvent moins nécessaire lorsqu'il met à jour des infos sur son profile, poste un commentaire, lorsqu'on stocke les stats de visites par page, etc. (moins impérieux = au sens où on la perte de quelques minutes de données tout les un ou deux ans (interval de crash système) n'est pas un drame si elle permet en contrepartie de multiplier les perfs du système par 10). La tradition et les applications classiques utilisant un SGBD tendent à tout stocker de façon synchrone, sans distinction, ce qui est souvent un gros gaspillage de ressources les plus précieuses (les I/O), bien sûr.
D'où l'émergence de solutions mixtes (SGBD relationnel + stockage asynchrone), ou l'utilisation d'extensions comme le "insert delayed" de mysql (mais n'a pas d'équivalent pour update et delete)... Je rejoint donc ta remarque sur l'utilité d'une marge de tricherie en disant qu'il serait bien utile de pouvoir, transaction par transaction, indiquer à l'OS s'il doit vraiment honorer une écriture de façon synchrone ou pas. Les besoins d'une appli de type "web social" à fort traffic ne sont généralement pas exactement ceux d'un système bancaire.
[^] # Re: Stockage en RAM
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 2.
Pour rester sur ma ligne "à cette heure il n'y a pas une solution qui les écrase toutes" ;) :
je crois que c'est vraiment un choix (sur quel type de matos flamber le budtet) qui doit se faire au cas par cas, selon les besoins de l'appli.
Par exemple pour reprendre tes suggestions citées juste au dessus (qui peuvent être bien pertinentes dans certains cas) :
* La RAM (dans l'OS) est principalement mise à profit pour réduire les lectures (ok, et les écritures si elles sont asynchrones, généralement pas le cas des SGBD). Donc très profitable pour une appli faisant beaucoup de lecture.
* Il y a des cas où augmenter la RAM n'apporte rien de significatif (par ex. si on a déjà 32 GB de RAM pour une bdd de 20 GB)
* Le couple cache_controlleur+BBU n'est pas tout à fait équivalent/remplaçable par une UPS :
- Il termine ses écritures même en cas de crash et arrets de l'OS, pas seulement en cas de pannes electriques. Ca signifie que même avec du writecache une transaction validée sera vraiment stockée, ce qui peux être - ou pas - une nécessité, selon le type d'appli. Dans le cas d'un système avec UPS : soit on écrit de façon synchrone (mauvaises perfs en écritures random), soit on prends le risque de valider des écritures non persistées (écritures async => utilisation du page cache de l'os => pertes en cas de crash). Ca protège aussi des problèmes de cables qui "se débranchent" (que le premier qui a bossé en salle serveur me jette la pière ;).
- La BBU permet d'activer le mode writeback du cache en écriture du controlleur (ces derniers le désactivent en général automatiquement en l'absence de BBU, pour ne pas perdre les données sales en cache en attente d'aggregation et d'envois vers les disques)
- Les controlleurs connaissent bien le layout physiques des disques, et s'ils sont dotés d'un cache (et qu'ils peuvent l'exploiter, donc d'une BBU), ils savent (plus ou moins) balancer les écritures de façon optimales sur les pools de disques disponibles. C'est aussi le cas du MD logiciel de Linux, mais n'est plus le cas s'il y a une couche LVM sur le MD.
* Tout ces questions ne sont pertinentes que pour une appli nécessitant beaucoup d'écritures random et synchrones ; il est clair qu'un logiciel dont le besoin premier est d'écrire, de façon asynchrone, de gros volumes de données a plutôt besoin d'une grosse bande passante.
[^] # Re: réplication master/master
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 2.
Voila, exactement. Les deux noms cités sont des exemples parmi une térafloppée de google bigtable-like (ou amazon simpledb-like) libres qui émergent comme les fleurs au printemps ! L'avenir est radieux :)
Btw, re-poste (déjà cités il y a peu sur dflp) de deux liens comparatifs/inventaires sur ce sujet :
http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib(...)
http://00f.net/2009/an-overview-of-modern-sql-free-databases
[^] # Re: Stockage en RAM
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 2.
De fait, une solution de stockage de masse ultra rapide de plus de 64 GB coute une fortune, qu'il s'agisse de SSD pro, d'un IOdrive, ou de solution persistante "ram based" (= où il faut de toutes façons, là aussi, payer pour la quantité de ram).
En revanche l'OS (ou l'applicatif, s'il est bien fait) cachera les pages "chaudes", réellement utilisées/accédées et beaucoup moins les données "mortes", ce qui permet parfois d'avoir de bonnes performances avec une quantité de ram largement inférieure aux jeux de données complètes sur disque dur (tandis qu'une solution de stockage totalement en ram sans autre forme de persistance doit pouvoir stocker tout le jeux de données).
Mais tu as raison d'amener cette question dans la discussion : c'est vraiment le prix, en terme de rentabilité par IOPS, en ne négligeant pas l'état de l'art des matériels classiques (controlleurs raid, chipsets de CM, RAM), et en prenant en compte les couts indirects (dont la conso électrique) qui fera la différence. Certains ce sont amusés à calculer les rapports performances/prix SSD vs. raid matériel sous diverses charges de benchmarks SQL typiques, et à l'heure actuelle les résultats ne sont pas encore univoques.
> De plus comparer des disques dur avec un fusio-io (pas un SSD!), je crois que l'on ne parle pas vraiment de la même chose.
> Le fusion IO propose presque 100 000 IO en écriture 4k, ce qui représente le pire cas. Ce n'est pas le même monde.
Oui pardon, je répondais au « pourquoi "ce genre de jouets" n'existe pas plus » en extrapolant aux solutions SSD et RAM+BBU (I-RAM, RAMSAN & co) en général (et non aux résultats épatants* de l'IOdrive).
Cela étant : je comparais les solutions classiques en général vs. les solutions alternatives modernes "en général", mais je ne compare pas "un SSD" ou juste "des disques durs" au FusioIO, j'indiquais justement que dans ce type de comparatifs qu'il ne faut pas négliger le write-cache des controlleurs RAID modernes, et la qté de ram qu'on peux coller pour pas cher. Ces derniers permettent d'élever considérablement les IOPS sur les données chaudes, et on (nous autres les geeks technophiles ;) a souvent tendance à oublier de les prendre en compte dans les comparaisons avec les nouveaux produits exitants comme l'IOdrive de FusionIO.
Le iodrive coute la bagatelle de 3000$ pour 80 GB (et 14 000$ pour le 320 GB) : pour ce prix, on peux mettre en place un _gros_ système RAID encaissant un bon paquet d'I/O ! Une machine avec controlleur RAID récent (par ex. avec 1 GB de RAM + BBU, qui permet d'aggréger un bon paquet d'I/O de lui même), et 10 disques 15 krpm en RAID 10 derrière (pour se répartir le reste des I/O non agrégées) offre de bonnes performances, un bon volume de stockage - et de la redondance/résistance aux pannes.
Bref, les produits FusioIO sont surement idéals pour certains types d'utilisation, mais pas encore la solution miracle.
* FusionIO au sujet duquel j'aimerai pointer ceci :
http://www.mysqlperformanceblog.com/2009/06/15/testing-fusio(...)
Autrement ce joli joujou ment à l'OS et ne synchronise pas réellement les données lorsqu'on lui demande, ce qui est dangereux parce qu'il n'est pas protégé par une BBU (à la différence d'un controlleur RAID correct). Il fournis néanmoins un mode de configuration permettant de forcer les sync() à être honnorés, et dans ces conditions les performances sont considérablement réduites. (et puis les 100 kIOPS, c'est les données constructeur hein ;).
[^] # fanboyisme
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 3.
ENORME ! :)
+1 point de mauvaise foi postgrefanboyiste, bien mérité dans ce cas :)
La fameuse capacité de montée en charge et de mise en cluster/répartition horizontale de pg, qui fait qu'il est utilisé sur tout les gros LAMP connus comme wikipedia, youtube, yahoo, digg, livejournal, flickr, facebook, ...). heu,...
[^] # Re: réplication master/master
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 1.
Certes, mais attention, la réplic va permettre sans effort :
1- La haute disponibilité tout les accès (lectures et écritures) (le service ne s'interrompt pas si un serveur est en carafe ou en maintenance).
2- La "scalabilité" horizontale des lectures (on ajoute un serveur et hop, le système encaisse plus de selects).
En revanche il ne suffit pas d'ajouter des serveurs pour "scaler" les écritures, car tout les serveurs d'un même cluster doivent recevoir et appliquer toutes les requêtes en écriture (par opposition à la lecture qui peut-être dispatchée entre les machines), que ce soit directement depuis l'applicatif ou depuis un autre serveur du cluster via la réplication.
Pour pouvoir répartir horizontalement les écritures, il faut faire des modifications généralement complexes et couteuses dans le code applicatif afin d'implémenter une forme de partitionnement horizontal/sharding (découper les tables et les assigner à des groupes/clusters de SGBD distincts, et se passer des jointures entre ces données distinctes, gérer les accès aux divers clusters selon le type de données ou les clefs de partitionnement, etc).
Arrivé à ce point, et tant qu'à faire, il peut devenir plus intéressant d'envisager une solution plus moderne (et hype ;) de key-value store ou similaire, naturellement distribué (à la CoucheDB, Tokyo Cabinet et consorts).