herodiade a écrit 808 commentaires

  • [^] # Re: Agentless, danger

    Posté par  . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 1.

    Disons que ce même problème peux survenir quel que soit l'outil de configuration management utilisé.

    Ansible rends ce phénomène plus fréquent et visible, car le mécanisme de notifications (via les handlers) est très spécialisé et pas utilisable en toutes circonstances (par opposition au notify/subscribe de puppet, qui permet de coordonner n'importes quelles actions).

    On doit souvent recourir à des enchainements register (ou set_fact+lookup, etc) sur une première task, puis "when: lavariableregistred[.something]" dans une seconde task, ce qui n'est évidement pas génial pour le --check.

    Un autre aspect qui rends Ansible un peu plus frustre pour les tests (mais je l'aime pour d'autres raisons ;), par opposition à Puppet

    Un autre aspect où Puppet se montre moins frustre pour les tests, c'est la notion de catalogue: l'état complet du système cible (tout ce qui est "à vérifier et à faire" avec Puppet) est construit avant toute connexion sur la machine cible (et avant execution par l'agent). On dispose d'un paquet d'outils permettant de se brancher sur la sortie du catalogue, pour faire du test unitaire et vérifier tout ce que Puppet compte faire, sans jamais avoir besoin de la machine cible.

    Cela dit j'aime beaucoup Ansible sur d'autres aspects que les tests.
    En particulier pour l'aspect dynamique, la souplesse et le controle qu'il offre sur le flux d'execution et les ensembles de machines: par ex. avec serial, delegate_to, local_action, group_by, add_host, les inventaires dynamiques, …

  • [^] # Re: salt-ssh

    Posté par  . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 1.

    il saura configurer un service avec la même configuration quelque soit le système d'init, ou encore installer un paquet selon la distribution)

    Ansible abstrait ça aussi, bien que le module "package" (successeur de "yum", "apt" et consorts) soit relativement récent (Ansible 2.0) :
    http://docs.ansible.com/ansible/service_module.html
    http://docs.ansible.com/ansible/package_module.html

    Il est également par défaut idempotent, ce que n'est pas forcément Ansible.

    Ansible est idempotent et encourage l'écriture de modules qui le sont aussi ; mais avec Ansible on peux facilement - plus facilement qu'avec Puppet je trouve - écrire du mauvais code qui casse cette propriété.

  • [^] # Re: plein de questions :)

    Posté par  . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 1.

    Clé et/ou phrase de passe pour le ssh (par contre faut passer l'acceptation de l'empreinte de la nouvelle clé ssh d'une manière ou d'une autre).

    On peux faire (non que ça soit recommandé, mais si l'infra est ultra dynamique et les clefs changent à chaque fois, alors ça ne réduit pas la sécurité):

    export ANSIBLE_HOST_KEY_CHECKING=False

  • [^] # Re: NginX & lighttpd

    Posté par  . En réponse à la dépêche Nginx 1.2, des progrès sur le code et les parts de marché. Évalué à 4.

    J'avais un petit serveur perso avec lighttpd qui servait des fichiers statiques. J'ai eu besoin d'y greffer une application python, avec le protocole uwsgi. Dans lighttpd, il fallait passer par un module externe, à compiler soi-même (il est maintenant en Debian testing). Dans nginx, c'était fourni d'entrée dans le paquet Debian. Du coup, j'ai migré.

    Le module uwsgi fait partie des modules nginx standard, et c'est une bonne chose(c).

    Car l'ajout d'extensions tierces est justement le principal défaut de nginx (par rapport à lighttpd) à mes yeux.

    Avec nginx, l'extension (fut-elle externe ou non) doit être compilée avec le coeur de nginx. Ajouter un module non fournis par sa distro impose donc de plus ou moins forker la version fournie (et maintenue…) par sa distribution. Les distributions tendent à lourdement patcher les versions de nginx qu'elles proposent, pour pouvoir packager et fournir les extensions tierces populaires. Malheureusement, le premier reflexe des développeurs upstream lors des rapports de bugs concernant ces versions frankenstein de nginx est de suggérer de tester un nginx nu…

    À l'inverse, chez lighttpd (comme chez Apache, via apxs), une extension peut être compilée séparément du core et il suffit de poser le .so résultant dans le bon répertoire pour pouvoir l'utiliser; le core n'a pas besoin de "connaître" les extensions disponibles au moment de la compilation.

    Je reconnais que c'est un défaut assez mineur, et je ne commencerai de nouveaux projets qu'avec nginx plutôt lighttpd ;). Car justement, des extensions disponibles, il en offre … beaucoup plus (faites une recherche github "nginx" et "lighttpd").

  • # Formats de fichiers supportés ?

    Posté par  . En réponse à la dépêche Enfin, un client EBICS java libre. Évalué à 2.

    Ça comble effectivement un manque important dans le monde du logiciel libre, et à point nommé. Merci !

    Est-ce que le logiciel permet les échanges de fichiers de formats arbitraires (sans vérification), ou uniquement des fichiers dans des formats normalisés type CFONB ou SEPA ?

  • [^] # Re: RCS, sinon quoi ?

    Posté par  . En réponse à la dépêche ack 1.96 — mieux que grep. Évalué à 4.

    Pour ton cas d'utilisation, je recommande chaudement etckeeper (http://kitenet.net/~joey/code/etckeeper/) combiné avec git.

    Très bien fichu, etckeeper s'occupe de tout les détails spécifique au versionning de /etc de façon automatique et bien pensée. Il n'oublira pas par exemple de :

    • Stocker (dans un fichier versionné aussi) et restorer (si besoin) les droits et propriétaires
    • Se hooker automatiquement sur le gestionnaire de paquets et commiter automatiquement avant et après les installes et upgrades (pratique pour repérer très préciséments les modifs liées à une upgrade).
    • Ajoute automatiquement dans un .gitignore les fichiers générés/dynamiques de /etc qui n'ont pas a être versionnés (comme /etc/mtab par ex), ce qui limite le bruit dans l'historique
    • Compenser les limitations des principaux SCM (par ex. Darcs ne gère pas les symlinks, ne conserve pas les droits d'execution, etc., mais etckeeper le fera pour lui), fait en sorte que les répertoires vides soient aussi versionnés, etc.
    • Réduire les droits du /etc/.git au mode 0700 pour des raisons de sécurité
    • ...

    Concernant ta question, la doc d'etckeeper indique par exemple :
    > "Among other chores, etckeeper init sets up a pre-commit hook that stores metadata about file owners and permissions into a /etc/.metadata file. This metadata is stored in version control along with everything else, and can be applied if the repo should need to be checked back out."

  • [^] # Re: Merci

    Posté par  . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 10.

    La vitesse de boot c'est un peu de la poudre aux yeux, les distribs' qui utilisent upstart ou sysvinit bootent deja bien vite (moins de 30s d'habitude). Je pense que c'est juste pour montrer qu'on gagne sur tous les tableaux avec systemd.

    D'autant que, et ce n'est pas mis en avant dans la dépêche, un autre avantage notable au fait de permettre le lancement de certains services "à la demande" (activation par accès fs, ou socket "à la inetd", ou appel dbus), c'est aussi (outre cette histoire de vitesse) de permettre d'alléger la consomation mémoire.

    Je ne sais pas vous, mais ça me fend le coeur d'avoir un cuspd (et modem-manager, et wpa_supplicant, et bluetoothd, ...) installés et lancés par défault par mes distros, sur mon vieux laptop avec lequel j'imprime une fois par an.

    Bravo à systemd pour offrir une solution sans perte de fonctionalité (et en laissant l'option de lancer le service systématiquement, par ex. pour un serveur d'impression d'entreprise).

  • [^] # Re: Lapin compris

    Posté par  . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 3.

    tu sais qu'il est à fond pour développer pour linux sans s'occuper de la portabilité.

    Et seulement les versions récentes de linux (celles qui supportent les cgroups).

    On ne probablement pas avoir un système pleinement fonctionel avec un systemd démarrant sur linux 2.6.18 (celui de RHEL 5, Debian Etch, Xen stable etc). J'ai pas testé cela dit ;).

  • [^] # Re: Merci

    Posté par  . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 10.

    Une "killer feature server" de systemd, c'est qu'il sait capturer les messages du kernel (early boot) et les infos de démarrage des services, et sait envoyer tout ça dans syslog (ou sur le port série si besoin).

    Avec l'init SysV, les messages affichés lors du boot ne sont visible que sur la console, pas dans les logs.

    C'est une aide bien pratique justement pour débuguer les problèmes au démarrage.

  • [^] # Re: MySQL HandlerSocket

    Posté par  . En réponse à la dépêche En vrac : Doctrine 2, MySQL 5.5 et VimGolf. Évalué à 3.

    > Mais au delà de ce troll, il y a tout de même la réponse de MySQL AB aux serveurs dictionnaires (clé-valeur) qu'est HandlerSocket.

    HandlerSocket est très chouette (de fameuses performances, un kv-store automatiquement à jour - ou presque - par rapport aux données accédées de façon SQL/relationelle, ...), mais rendons à César ce qui est à César :

    - MySQL A.B. n'est plus, désormais devenu Oracle Corporation
    - HandlerSocket n'est pas l'oeuvre d'Oracle (ou feu MySQL A.B.) mais de la société japonaise DeNA.

    On ne peux donc pas vraiment dire que ce soit "une réponse de MySQL".

    > Et le compromis entre fonctionnalité et performance fait reculer le moment à partir duquel on va s'orienter vers un foutoir tel que MongoDB ou tout autre base d'objets.

    Il semblerai qu'HandlerSocket ai déjà des perfs en lecture généralement supérieures à MongoDB (qui n'est pourtant pas lent). Mais il me semble que l'intéret d'outils comme CoucheDB, MongoDB, Riak & co réside justement plutôt dans les fonctionalités originales qu'ils offrent (mise en oeuvre de MapReduce par ex.) et dans l'aisance qu'ils apportent pour ceux qui veulent ou doivent partitionner le travail sur de nombreuses machines ("scale out" grace au partitionnement automatique, à la résolution de conflits rationelle, ce genre de choses).
  • [^] # Re: Les chinois du FBI...

    Posté par  . En réponse au journal Backdoor dans OpenBSD ?. Évalué à 2.

    > Si ca se confirme, ca va surtout remettre enormement en cause ce gros mythe pourri disant qu'avoir le code ouvert donne un code plus sur...

    Un mythe ? revenons au faits avérés alors.

    L'attitude permise par la nature libre et non lucrative du projet est pourtant ici plutot responsable, et plus "securisante" que ce que pourrait se permettre une boite commerciale faisant du proprio. TdR envoie un mail pour faire part d'une incertitude, et suggère indirectement au grand public d'auditer. Il peux réagire ainsi parce que, entre autres :

    o Il n'a pas de comptes à rendre à des actionnaires fachés par les rumeurs.
    o Alerter le public : parce que le source étant dispo, les gens peuvent participer à l'audit.
    o L'interet d'OpenBSD reste d'inciter les gens a auditer le code. Trojan ou pas, ça fera peut-être des contributions.

    Dans la même situation, Bill Gates aurait-il caché le mail sous son tapis de souris (au risque de laisser les failles non corrigées) ou alerté le grand public ?

    C'est tout ce qu'on peux dire à partir des seuls éléments factuels dont nous dispons (le mail de TdR),

    PS: celà étant, je ne suis pas optimiste :
    o OpenBSD restera entaché par le doute. On ne pourra pas prouver qu'il n'y a pas, ou plus de trojan, même si on ne trouve rien.
    o Il est à craindre que pendant quelques temps, à chaque bug corrigé, le soupçon pèse sur auteur du bug.
    o Si l'accusation était vérifiée, le plus attristant et choquant ne serait pas l'impureté du code d'OpenBSD (osef un peu au fond), mais d'avoir la preuve tangible qu'une grande institution américaine se serait permis ce genre d'intrusions (et supposer les utilisations que l'institution aurait pu faire d'une telle faille... super pour les libertés individuelles).
  • [^] # Re: Bien, et la redondance ?

    Posté par  . En réponse à la dépêche Asterisk 1.8 pour la téléphonie et VoIP. Évalué à 1.

    > 4 serveurs VoIP (en VM, ce ne sont meme plus des machines physiques) [...] et il y a meme un site qui tourne encore avec une carte Digium ISDN FXO

    Il est donc possible d'interfacer le driver DAHDI au matériel en utilisant le PCI passthrough proposé par la solution de virtualisation (KVM ? Xen) ?
    Ou bien cette machine là (celle qui a la carte FXO) n'est pas virtualisée ?
  • [^] # Re: Acronyme ...

    Posté par  . En réponse au journal fachisme des blacklists (Barracuda). Évalué à 8.

    > Je connais la signification d'ISP mais pas de MSP. Qu'entend tu par la stp ?

    Mail Service Provider.
    Par exemple Yahoo, Hotmail, Gmail ne sont pas des ISP mais envoient/recoivent beaucoup de mails.

    Ils sont importants dans ce contexte parce que :

    o Ils ont beaucoup d'abonnés et sont très utilisés (ils sont importants).
    o A la différence des ISP (qui ne rejettent généralement pas de mails à destination de leurs abonnés, spam ou pas) ce sont surtout des webmails, qui peuvent se permettre de qualifier un mail de "spam", l'accepter, mais ne pas l'afficher dans l'inbox principale des destinataires (le ranger dans la spambox et l'effacer automatiquement au bout de quelques jours). Ce qui produit pour les utilisateurs finaux à peut près le même résultat qu'un rejet silencieux.
    o Ils qualifient les mails (en spam ou ham) en s'intéressant en grande partie à l'IP de l'emeteur (est-elle censée emetre pour le domaine indiqué dans le return-path ? est-elle blacklistée ? quel est la proportion moyenne usuelle de mails acceptés/rejettés parmis ceux émis par cette IP ? quelle est la réputation de cette IP ? ...).
    o Il est donc impensable, pour un opérateur relayant/envoyant du mail, d'ignorer l'appreciation de ces gros fournisseurs de services. Ce serait bien pire (en volume de mails concernés que les utilisateurs risque de "ne pas recevoir" (ne pas voir en fait)) que d'être totalement blacklisté par Orange.
    o Ils fournissent aux opérateurs (à ceux qui envoient ou relayent) - ou bien ils recourent à des prestataires tiers qui fournissent aux opérateurs pour eux - des informations permettant de connaitre la réputation de leurs IPs
    o Ils fournissent aux emetteurs des retours (des bounces) (au format standardisé, eg. Abuse Feedback Reporting Format) permettant de jauger des raisons d'un rejet précis et d'agir en conséquence (ce qui permet d'éviter, notamement, une dégradation de la réputation des IPs).

    > Tu t'inscrit ou et surtout qu'elle sont les avantages que tu en retire ?

    http://en.wikipedia.org/wiki/Feedback_Loop_%28email%29
    http://www.returnpath.net/internetserviceprovider/feedback/

    Lorsqu'on envoie ou relaye un large volume de mails, il est donc opportun de s'attacher à traiter sérieusement les retours (bounces, click sur le bouton "ceci est un spam" ou "unsubscribe" d'un webmail par l'utilisateur final, etc.) et de surveiller la réputation de IPs qu'on utilise pour le mail sortant.

    Cela dit, de nos jours, les MSP utilisent de plus en plus le comportement de leurs utilisateurs pour évaluer finement la qualité des mails reçus pour une IP donnée, justement parce qu'en étant essentiellement des webmails, ils peuvent collecter beaucoup plus d'infos qu'un ISP qui fournit du POP3. Les mails en question sont-ils ouverts par le destinataire ? combien de temps sont-ils restés ouverts ? sont-ils immédiatement effacés ? est-ce que l'utilisateur a écrit ou répondu à l'expediteur du mail ? etc. Et, au dela de la qualification "spam" (=> mail jamais lu par l'utilisateur), on voit poindre des "classement/placement plus ou moins accessible dans l'inbox principale selon la probabilité que l'utilisateur ai envie de lire le mail".

    Ce qui fait que la règle de plus en plus prévalente à faire entendre aux as du marketing de masse, c'est "cessez d'envoyer de la merde peu ciblée à des gens qui s'en tapent, sous peine de, bientot, avoir une réputation tellement nulle que vous ne pourrez plus emettre quoi que ce soit vers les plus gros MSP, ou n'aurez plus une chance que vos mails soient ouverts par les destinataires".
  • [^] # Re: Hum

    Posté par  . En réponse au journal Sauvegarde données utilisateurs et serveurs. Évalué à 1.

    > je passe mon temps à chercher des fichiers éparpillés

    Les données importantes de l'utilisateur ne sont elles pas dans le profile stocké sur un serveur ? (si oui, peut-être le mieux serait de sauvegarder ce serveur ?).

    Peut-être que rdiff-backup ([http://rdiff-backup.nongnu.org]) conviendrait mieux étant donné tes contraintes.

    Il copie un répertoire (sur un desktop par ex.) vers un autre répertoire (sur un serveur par ex); le serveur est passif, ne se préocupe pas de savoir d'où (de quel hote) vient le fichier. Il n'a pas d'interface sympa qui permette aux utilisateurs non avertis de restorer eux-même les fichiers cependant.
  • [^] # Re: Et unison ?

    Posté par  . En réponse au journal Sauvegarde données utilisateurs et serveurs. Évalué à 1.

    Ce sont de bonne solutions de réplicatin/synchronisation, mais pas des outils de backup.

    Par exemple: tu modifie un fichier, il est synchronisé partout. 15 jours après, tu veux récupérer la version d'avant. Zut. Ou bien: par prudence, pour éviter ce problème, tu ne synchronise qu'une fois de temps en temps. Et ton disque dur tombe en panne. Tu perd plusieurs jours de travail. Zut.

    Le serveur pourrais certe avoir du LVM et faire des snapshots, mais il faudrait aussi bricoler de quoi permettre aux utilisateurs de consulter trouver le bon snapshot, le monter, le naviguer, récupérer son fichier simplement ; et gérer les saturation disques, et décider automatiquement quel snap/archive effacer ; décider de la durée de conservation et scripter de quoi l'appliquer ; alerter s'il y a un défaut ; alerter si une machine n'a pas été backupée depuis longtemps ; arbitrer les accès concurents pour éviter que tout backup en même temps et sature les i/o ou le réseau, ... ce que font déjà les logiciels de backup classiques. Bref à ce stade il faudrait réinventer la roue.
  • [^] # Re: Hum

    Posté par  . En réponse au journal Sauvegarde données utilisateurs et serveurs. Évalué à 2.

    > C'est une très bonne nouvelle, mais sur quoi ce base BackupPC pour déterminer si le fichier est identique ? Le nom ? J'espère que non car ce n'est pas très fiable, il peut très bien arriver qu'un fichier provenant de différents profil/host soit identique mais que je le fichier ne contienne pas les même données.

    BackupPC fait un checksum cryptographique (md5 si ma mémoire est bonne) pour reconnaitre les fichiers identiques (ou pas) et dédupliquer.
    Il ne se base évidement pas sur le nom (il lui serait sinon impossible de backuper des serveurs similaires au même endroit ;).

    D'ailleurs, les arborescences de hardlinks (ce que tu vois dans "dans le dépôt de BackupPC (/var/lib/BakcupPC/) j'ai un répertoire par host") ne sont utilisés par le logiciel qu'à titre de métadonnées pour retrouver, justement, le nom d'un fichier ou le contenu d'un répertoire, parcourir facilement l'arborescence, etc. Les fichiers eux-même sont stockés dans le répertoire cpool/, non pas sous leur vrais noms, mais renommés selon leurs checksums md5 (par ex. /var/lib/backuppc/cpool/0/1/d/01d0016d1a30383ccd484a8913de6927).

    Ainsi, deux fichiers (qu'ils aient un nom différéent ou pas) ayant le même checksum ne sont pas dupliqués : backuppc place le fichier une première fois dans le cpool/ en le nommant d'après son checksum md5 ; la fois suivante (backup suivant de la même machine lorsque le fichier n'a pas changé, ou autre machine ayant le même fichier identique) il constate que le fichier ayant ce checksum existe déjà dans cpool/, et ne l'écrase pas. Pour la présentation de l'arborescence, il fait des liens hards portant les "vrais" noms des fichiers et pointant sur les fichiers du répertoire cpool/.

    Lorsque le fichier disparait d'un hote, backuppc n'efface que le lien hard ("le nom du fichier") correspondant. Un autre job, indépendant, passe régulièrement et repère les fichiers du cpool/ (ceux dont le nom est un md5) qui ne sont plus référencés par des hardlinks dans les répertoires contenant les arborescences des hotes (donc: qui ne sont plus utilisés nulle part), et il les effaces.

    > je pourrais remonter d'un niveau le répertoire à sauvegarder, donc à "document and settings" mais je ne trouve pas ça très élégant.

    Pourquoi pas élégant ?
    Avec ce procédé, tu inclus aussi le nom de l'utilisateur dans le backup (enfin, dans le path des fichiers). Faute de quoi, il te serai très difficile de retrouver le outlook.pst de l'user toto (au milieu des outlook.pst des autres users) pour le restorer.

    Cela te permet aussi de savoir très aisément "qui" (quel user) pèse combien dans tes backups, et d'éventuellement affiner les filtres de tris, etc.

    > Dans quel host va il devoir aller chercher son fichier ? 01 ou 02 ?

    L'interface web de backuppc permet de naviguer/browser les sauvegardes ordinateur par ordinateur, mais pas transversalement.
    Il faut donc que l'utilisateur se souvienne de l'hote sur lequel il était connecté au moment du backup, ou qu'il parcoure l'arborescence des hotes auxquel il est susceptible de s'être connecté. Ou qu'il demande à l'admin de faire un "find /var/lib -name '*lefichier*'" pour lui indiquer l'hote intéressant au jour j. Cela étant, une interface web de recherche transversale ne serait pas très dur à développer... (ou une script référençant, sur ton serveur samba, qui se connecte depuis où à quelle date: c'est dans les logs, génerer une page web est très simple).
  • [^] # Re: Juste des rumeurs

    Posté par  . En réponse à la dépêche VP8 : nouveau codec vidéo libre ?. Évalué à 7.

    > Même si VP8 est aussi bon qu'On2 le prétendait, je suis certain qu'on trouverait encore des pisse-froids pour supporter H264 dans HTML5

    Oui,
    Je crois qu'une bonne énumération de ces "contre-arguments" (y compris sur l'aspect technique) se trouve sur le blog de Jason Garrett-Glaser, mainteneur de x.264 (donc d'un produit libre "concurrent") :
    http://x264dev.multimedia.cx/?p=292
  • [^] # Re: Répartition Géographique ?

    Posté par  . En réponse à la dépêche CirruxCache : réduire la bande passante et augmenter la connectivité. Évalué à 1.

    Hmm, de l'anycast transparent sur des protocoles connectés (on parle de HTTP là) ?

    A moins que les applis hébergées chez google apps utilisent leurs DNS (auquel cas ils peuvent faire effectivement de l'anycast sur leurs serveurs DNS, comme ils font pour d'ailleurs pour leurs 8.8.8.8 et 8.8.4.4, et dispatcher à partir de là la résolution géographiquement).

    Ce qui me fait douter de la répartition effective, c'est que le récent (et excellent) rapport de panne de Google Apps semble signifier qu'il n'y a que deux datacenters :
    https://groups.google.com/group/google-appengine/browse_thre(...)

    "The oncall engineer discusses performing a failover to our alternate datacenter"
    "the oncall engineer attempts to move all traffic into a read-only state in our alternate datacenter"
    etc

    Mais ça n'enlève pas grand chose à l'interét de l'appli : celui de pouvoir décharger le service de fichiers statiques vers un hébergeur bon marché et tout de même assez bien connecté, quand bien même il ne serait pas particulièrement physiquement proche des utilisateurs finaux.

    Aux développeurs: est-ce que le support de ESI est prévu ?
  • [^] # Re: DNSSEC et UDP

    Posté par  . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 2.

    A ce sujet, la dépêche omet de préciser que les problèmes de "perte" de certaines options TCP (MSS dans certains cas, SACK, ...) causée par les syncookies est (en gros) réglée depuis le noyau 2.6.26, grâce à un astucieux patch de Florian Westphal exploitant le tcp_timestamp pour stocker les quelques bits pertinents.

    cf. http://lwn.net/Articles/277146/ et le commit 4dfc2817025965a2fc78a18c50f540736a6b5c24 , d'avril 2008.

    L'inconvénient de cette méthode, c'est qu'elle ne suffira plus le jour où le besoin de stocker une nouvelle option tcp pertinente se fera sentir, qu'elle affecte le timestamp tcp initial, et qu'elle est un détail d'implémentation "linux only", pas une solution généralisable.

    L'alternative TCPCT est bien entendu plus propre et permet en outre de ne pas avoir à conserver un état en mémoire pour distinguer les paquets out of band après fermeture d'une connexion (période TIME_WAIT). Mais elle ne sera une protection effective et généralisable contre les floods qu'à partir du moment où on pourra considérer que tout les clients la supportent (et ou on pourra légitimement rejeter tout paquet SYN non transactionnel).

    Bref, activer les syncookies sur un noyau linux moderne est sans danger, et même plutôt prudent.
  • [^] # Re: Les adminsys en redemande

    Posté par  . En réponse à la dépêche Les technos web cools du moment. Évalué à 2.

    > Dans IMAP, il y a une commande, IDLE

    Un protocole conçu pour ça, précisément, pas Hyper Text Transport "Quand j'ai un marteau tout ressemble à un clou" Protocol ;). Bon je reconnais que j'exagère, il y a surement lieu de s'inspirer du mail pour améliorer le web (y compris, peut-être, l'IDLE d'IMAP). Mais la situation est différente et beaucoup plus facile à gérer pour le mail :

    o C'est éminemment, naturellement shardable / partitionable (à la différence d'une application appuyée sur une base de donnée relationnelle, les mailboxes sont des "data stores" très faciles à dispatcher et répartir). A l'opposé des prérequis pour la construction, par exemple, d'un graphe de réseau social. Voir à ce sujet les réflexions de James Hamilton, par exemple ici : http://perspectives.mvdirona.com/2008/06/08/ScalingLinkedIn.(...)
    Ok, rien à voir avec le sujet de ce thread, mais en écho au thème des nouveaux systèmes de stockage NoSQL.

    o Des questions de volumes et de dimensionnements (prévisibles ou pas). Le trafic (nombre de connexions) d'un serveur IMAP est généralement facile à anticiper, ou du moins suit des évolutions prédictibles; un trafic normalement limitée à l'ensemble des utilisateurs connus et enregistrés. Servis par un applicatif minimal et quasi non bloquant (hormis l'auth, presque de pures I/O). L'applicatif est en même temps directement le serveur de stockage. Naturellement asynchrone. Je ne crois pas qu'il y ai beaucoup d'environnement IMAP dans le monde qui ont l'occasion de recevoir 100 000 connexions simultanées, ni même 10k. Ca n'est pas tout à fait de même nature que les vagues de flux sur une application webtwolol (parfois très soudain, avec 2 à 6 connexions simultanées par clients, des applications faisant généralement des traitements, etc). Et puis, personne n'a encore eu le mauvais gout de distribuer un serveur IMAP en javascript (à ma connaissance) :P
  • [^] # Re: Les adminsys en redemandent

    Posté par  . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.

    > Oui, mais "100 000 connexions simultanées" nécessite de conserver un contexte en mémoire,

    Le coût système (non applicatif) mémoire de la conservation de sockets TCP established est évaluable. Je ne connais pas la surcharge spécifique de libev (utilisée par node.js), mais c'est vraisemblablement du même ordre que pour la libevent, pour laquelle les valeurs sont connues :

    Voir la seconde partie de ce test (l'implem en C avec libevent) de Richard Jones (de Last.fm, qui semble largement plus sérieux que le gars de Plurk btw) :
    1 *million* de connexions consomme moins de 2 GB (userland, RSS) + kernel, avec libevent.

    "I connected 1M clients to the httpdcnode server using the same client as above, the machine showed a total of just under 10GB or memory used. The resident memory of the server process was stable at under 2GB". "the resident memory per connection for the server process with libevent is just under 2KB. [...] the kernel/tcp stack is consuming an additional 8KB per connection".
    http://www.metabrew.com/article/a-million-user-comet-applica(...)

    Un autre test du même genre (mesure du cout de connexions http persistentes et dormantes en utilisant libevent) : "Resources now jumped to a maximum of 21MB resident (25MB virtual) for 200,000 working connections, but once again the OS was showing ~450MB extra memory used"
    http://aleccolocco.blogspot.com/2008/10/gazillion-user-comet(...)

    Un autre exemple spécialement pour toi ;) : la doc de djabberd (en Perl, utilisant epoll) affirme, dans le même ordre (ie. sans détails) que "A recent test had 300k connections in 1GB of RAM". cf. http://www.danga.com/djabberd/#perf

    Ça donne une idée du coût système des connexions.

    Reste à savoir le cout des états applicatifs node.js associés, qui dépendent évidement de ce qu'on fait (en terme "métier"/application) avec toutes ces connexions, et c'est ce qui n'est pas indiqué dans le "wow mon node.js tient 100 000 connexions simultanées"... 1KB (largement de quoi stocker un cookie et une position dans une machine à état simple) par connexion coûte dans ces conditions 100 MB au total.

    > et peut-être du keepalive.

    Du keepalive HTTP il y en a forcément ; c'est la fonctionnalité HTTP fondamentale sur laquelle repose Comet, et c'est bien pour ça que le "100 000" n'a pas trop de sens, car on ne parle pas de 100k nouvelles connexions + req GET par seconde, il s'agit de 100k connexions établies progressivement sur un laps de temps indéterminé, dormantes, et maintenues au cas où le serveur aurait quelque chose à signaler au client. Cela dit ça doit être cocasse lorsqu'ils mettent à jour l'appli ou redémarrent le serveur, et se reprennent les 100k connexions simultanément d'un seul coup dans la face.

    Si tu parle du keepalive TCP (SO_KEEPALIVE), ça ne coûte (par défaut sous Linux) rien pendant les 2 premières heures, et ensuite une paire de paquets toutes les 75s (net.ipv4.tcp_keepalive_intvl et net.ipv4.tcp_keepalive_time). Pas trop violent ;)
  • [^] # Re: Base de données réparties

    Posté par  . En réponse à la dépêche Les technos web cools du moment. Évalué à 5.

    > Donc en gros, je souhaite avoir trois bases Berkeley qui se synchronise de manière aysnchrone, au mieux... et avoir le moins de code Perl a modifier ;-)

    Tu sais que BerkeleyDB supporte nativement la replication (single master, ok)?

    Pour rétablir toute sa coulitude, on se doit d'indiquer qu'il réplique avec "Automatic failover/re-election", qu'il utilise pour ça un "Paxos-compliant election algorithm", et sait faire du "Hot standby", et permet les "Non-stop upgrades" et qu'il a une "Proven scalability to thousands of replica nodes".

    Si si,
    http://www.oracle.com/technology/products/berkeley-db/db/ind(...)
  • [^] # Re: Les adminsys en redemandent

    Posté par  . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.

    Les API de multiplexage des sockets utilisées par node.js (epoll(7) ou kqueue(2)) scalent le nombre de connexions en O(1), il est connu qu'on peux accepter un nombre quasiment infini de connexions dormantes. Aucun mérite :). Le chiffre peut impressionner parce qu'il ne correspond pas à ce qu'on compte habituellement : "100 000 connexions simultanées", ce n'est pas "100 000 connexions par seconde" et encore moins "100 000 requêtes GET par seconde".

    Mais je parlais des firewalls à état traversés pour atteindre les node.js, pas des serveurs applicatifs node.js eux-même (pour autant que ces firewalls soient aussi utilisés pour autre chose que maintenir des connexions vides, ie. router du vrais traffic).

    > 1 server (32GB of RAM, quad core), mais seulement 1 à 2 Go de RAM
    > serait utilisé avec node.js (Netty uses 10-20GB depending on the traffic
    > level. node.js uses around 10x less than that).

    En même temps, le bougre ne supporte pas les architectures 64 bits, si j'en crois la doc. Il aurait donc bien du mal à utiliser plus - même lorsqu'il serait pertinent de cacher des choses en ram...
  • # Les adminsys en redemande

    Posté par  . En réponse à la dépêche Les technos web cools du moment. Évalué à 10.

    > Node.js est LA plate-forme cool du moment

    Confrères sysadmins, vous aviez réussi à échapper aux frameworks web J2EE plébiscités par les dissaildeurs pressés ? Les confs en XML ne vous font plus peur ? et bien paf, les webkiddies ne vous épargneront pas les serveurs - http, ftp et leur config - en javascript !

    Avec ses petits copains Comet et Web Sockets, vous découvrirez aussi le bonheur de maintenir des centaines de milliers de connexions persistantes à travers votre pauvre firewall stateful sous iptables/conntrack. Yipiii :) Un plaisir à ne pas bouder, car ça ne durera pas : quelqu'un écrira bientôt le firewall enfin scalable en javascript.

    Vous découvrirez aussi, attendris, la larme à l'oeil, les charmes vintages des bases de données sans mot de passe exposées au public, lorsque vos jeunes javascripteurs réclameront l'accès REST direct du navigateur au Mongo ou à la Couche ; car après tout, ce n'est que du json, c'est cool et ça ne peux pas faire de mal hein ?

    En tout cas : merci coolitude, car nous voila enfin à l'abris des buffer overflows :)
  • [^] # Re: Comprend pas ...

    Posté par  . En réponse au journal La fin du monde. Évalué à 4.

    > Quelqu'un sait ce qui pose problème dans la licence v2 ?

    Theo en parle un brin ici :
    http://archives.neohapsis.com/archives/openbsd/2004-06/0477.(...)

    Mais d'autres raisons semblent avoir motivé (ou catalysé) le forkage assumé :
    - Ils maintenait déjà à cette époque une version largement divergente. Voir par ex:
    http://archives.neohapsis.com/archives/openbsd/2004-06/0490.(...)
    http://archives.neohapsis.com/archives/openbsd/2004-06/1739.(...)
    - Le code d'apache était considéré par certains développeurs OpenBSD comme difficile à auditer du fait des couches d'abstractions que le logiciel utilisait systématiquement pour assurer sa portabilité sur des OS exotiques (type win32, Netware, OS/2 & co).

    Les mois qui ont suivi l'annonce du point de non-retour ont d'ailleurs été l'occasion d'une simplification radicale du code d'apache dans le CVS d'OpenBSD (sous l'égide d'Henning Brauer - le mainteneur d'OpenBGPD et l'un des principaux contributeurs de pf).