Tu as le même ordre de différence entre deux contrôleurs de la même marque. Si tu compares par exemple une areca 1212 et un areca 1882 tu dois être dans le même ordre d'idée.
C'est au passage la même chose pour les contrôleurs réseau.
J'imagine que tu parles d'un test type détection de "collage",
Non, je parle du zpool scrub qui vérifie et corrige l'intégrité des données sur les disques. Des erreurs relevées à ce niveau, relèvent souvent d'un problème matériel sous-jacent et la nécessité d'un diagnostic hardware approfondie.
L'article gagnerait (et ferait moins parti pris) à comparer les solutions.
Clairement, ce n'était pas mon but ici. Je voulais mettre un coup de projecteur sue OpenZFS, ZFS On Linux ainsi que l'aspect portable de cette solution. Cela ne signifie en rien que je dénigre md, geom ou lvm mais simplement qu'il n'entraient pas dans le scope de cet article qui est de présenter ZFS comme une alternative viable et portable au RAID proprio.
A mon sens ZFS n'est pas comparable à une carte RAID matérielle ni même aux autres systèmes de fichiers.
On est bien d'accord. Il faut donner à ZFS des disques autrement dit ni des partitions, ni des volumes raid. Par contre tu peux très bien utiliser tes zvol comme des périphériques de bloc quelconque pour faire ce que tu veux y compris les formater en UFS ou autre.
Limite le système y consacre toutes ses ressources.
C'est a nuancer suivant l'usage. ZFS n'utilise que les ressources que tu lui donne. Les recommandations visent des performances optimales. C'est une histoire de compromis et de choix.
indique un pré requis important : de la mémoire ECC. Ce n'est pas une recommandation, c'est un pré requis
Le risque que les erreurs de RAM corrompent les données n'est pas spécifique à ZFS. C'est le cas sur tous les systèmes d'écriture asynchrone y compris sur des logiciels comme des SGBD. Sur du hardware non professionnel tu dois lancer des scrub réguliers pour détecter rapidement ce type de comportements.
part du principe que le serveur ne peut pas tomber en panne
Non. Tu dois par contre gérer les options de synchro et de cache en fonction de ce risque.
c'est totalement transparent, et facile à gérer.
Ce que tu décris des cartes raid proprio correspond au meilleurs des cas. Quand tu dois te battre avec la cli proprio et identifier un disque qui a disparu c'est une autre paire de manche. Le remplacement d'un disque sous ZFS peut également être totalement automatisé.
zpool tank set autoreplace=on
Sinon excellent article,
Merci
Mais il faut voir que ZFS lui-même c'est presque comme un serveur, il faut le maîtriser, le surveiller, et le faire tourner sur du matériel
Je dirais une carte raid à construire sois même. Il faut choisir les composants en connaissance de cause et bien maîtriser le soft. C'est parfois un investissement plus humain couteux que du matériel proprio avec son support. Par contre si le stockage est au cœur de tes préoccupations tu t'y retrouves rapidement.
Tu as peut être raison. J'avais compris que l'écriture sur flash était systématique. Je peux me tromper, je ne connais pas ce produit. J'ai un peu de mal a concevoir l'aspect "si nécessaire".
A confirmer, mais il semble que chez LSI CacheVault pallie au problème des batterie en remplaçant la chose par une copie sur mémoire Flash lors de la coupure avec le reste d'éléctricité qu'il a en stock.
J'utilise largement ZFS en production sur tout types de serveurs (BDD, NFS, backup, MAIL, SAN iscsi). Tout ce que j'ai décrit dans l'article est validé en prod.
Les seuls problèmes que j'ai eu depuis 2 ans sont lié à une conception foireuse de l'architecture de stockage sous-jacente. En respectant deux règles :
1) ZFS a besoin que les données soient redondées sur plusieurs disques
2) Ne jamais empiler ZFS avec du raid matériel
Je rappelle aussi que RAID1, c'est une perte de 50% de l'espace, donc le coût est énorme.
Cela dépend à quoi tu rapportes ce coût. La perte d'espace lié au raid a un cout négligeable par rapport aux heures sysadmin passées à remonter des données à partir d'un environnement dégradé. Voir aux indemnités à payer au client en cas de perte.
Le niveau de raid dépend avant tout du besoin en IO rapporté au volume à stocker. Pour un SGDB par exemple le choix est déterminant, pour des backups aussi si tu veux pouvoir paralléliser un maximum. Par contre pour de l'échange de fichiers ou encore pour un applicatif résident en RAM, tu veux juste éviter les indisponibilités.
Le reste c'est de la manut. Une politique de stockage, ce n'est pas seulement le RAID. C'est avant tout le choix des disques qu'il faut avoir en stock sans pour autant les laisser dormir trop longtemps, stresser, surveiller, remplacer à la moindre erreur, diagnostiquer, effacer et remettre en stock ou détruire. C'est aussi le choix des contrôleurs, des alimentations, des backplanes et du soft (système de fichier, gestionnaire de volumes, soft raid …). Enfin c'est de la procédure. Être alerté, savoir quel disque est dans quel tiroir, avoir une procédure de remplacement et de reconstruction solide.
Si effectivement, tu as besoin de deux jours pour intervenir sur un problème de disque, le raid (quelque soit son niveau) ne peut rien pour toi. Ce qu'il te faut alors c'est des backups.
En gros, il y est dit que 77% des enfants sont placés chez la mère.
Ce qui n'est pas dis c'est combien de parents ne veulent pas de leurs enfants. Combien de fois la garde est donnée a la mère par défaut, parce qu'aucun des deux ne veut vraiment se coltiner les devoirs, trouver des solutions de garde et sacrifier ses loisirs a l'éducation des enfants.
Le choix de la mère est un choix par défaut. Et c'est un choix profondément sexiste partant du postula que l'enfant c'est le domaine des femmes et qu'elle se débrouillera bien.
Autrement dit dans la majorité des cas la mère est désignée d'une façon ou d'une autre et il n'y a pas de combat mais soulagement côté père et résignation côté mère.
Il me semble que se retrouver seul avec les mômes fait flipper tout le monde. Et c'est bien normal. C'est un bouleversement profond du mode de vie.
Il me faut quand même pas oublier qu'on doit la garde alternée, la garde par les pères et plus généralement la reconnaissance de la capacité des hommes a s'occuper des enfants au combat des féministes. C'est parce qu'elles ont collés a leur types un paquet de couche sous le nez qu'aujourd'hui ce combat pour la reconnaissance du droit des pères peut exister.
L'institution est rétrograde. A la crèche, on parle de l'heure des mamans, la justice familiale considère encore la mère comme un être trop faible pour subvenir a ses besoins, les gens regardent de travers quand un père est seul en vacance avec un petit enfant …
Les féministes combattent pour le droit des femmes a faire autre chose que de pouponner, voir a ne pas pouponner du tout. La reconnaissance de la capacité des pères a s'occuper des enfants entre juste dans ce cadre la.
De nombreuses féministes considèrent que le choix de la mère par défaut est une profonde injustice.
Non, il y a eu un consensus autour du fait qu'un serveur autoritaire n'avait pas sa place dans le système de base (pas plus qu'un serveur imap ou http …).
On parle de la grande utilité de BSD, mais en fait, est-ce si utile que ça? Est-ce vital?
des BSD sans doute veux tu dire ?
Prends un exemple. Si tu souhaites mettre en place une architecture DNS robuste, il te faut :
plusieurs réseaux
plusieurs OS
plusieurs service DNS
Cela te permet de conserver un service UP même lorsqu'une partie de ton infra est devenu vulnérable ou sous le feu d'une attaque.
La diversité permet de diluer les risques, c'est pourquoi, il est essentiel de pouvoir disposer d'un écosystème de logiciels vaste pour produire des services réseau viables.
Ce qui est important, ce n'est pas tant OpenBSD, que la possibilité pour les administrateurs système de pouvoir déployer une certaine variété de solutions. Une diminution du nombre de solutions disponibles entrainerai un retour vers des solutions propriétaires et serait pour le libre en général une mauvaise affaire.
Cette variété d'implémentations est également essentielle pour les développeurs à qui elle permet de confronter leurs idées à celles des autres.
Enfin pour ce qui est du cas spécifique d'OpenBSD, c'est une communauté qui a fait grandement avancer le libre entre autre sur les pilotes Wifi, sur l'implémentation des protocoles réseau, sur la gestion des chaines de caractères et sur un tas d'autres sujet.
Elle produit aussi un certain nombre de logiciels comme OpenSSH, OpenBGPD, OpenSMTPD, Mandoc … qui sont utilisés sous Linux comme sous tout un tas d'autres OS.
une entreprise qui dépendrait fortement des logiciels fait par les gens d'OpenBSD
Reste à savoir si une telle entreprise existe. Qu'il y ait des entreprises utilisant OpenBSD, ne fait aucun doute. Qu'il y ait des entreprises utilisant du code issue d'OpenBSD également. Qu'il y ait des entreprises dépendant fortement d'OpenBSD au même titre que Canonical dépend de Debian ou Netasq de FreeBSD c'est moins certain.
Le fait d'utiliser OpenBSD sur un parc de serveur, ou encore d'avoir piqué du code a un instant t pour répondre à un problème particulier ne fait pas la dépendance.
50% c'est la proportion de connexions sur les MX qui n'aboutissent pas à un mail :
IP blacklisté (mauvaise réputation, taux d'erreur trop important)
destinataire inexistant
destinataire ayant sa boite pleine ou inactive
erreurs de protocole
C'est à 95% du spam.
Sur les 50% effectivement accepté, c'est dur à dire. A la louche :
5% sont sans conteste du spam
5% sont limite
25 à 30% sont du spam institutionnel (publicité bien envoyé, bien formé, avec lien de désinscription …).
En étant un peu strict en entrée, la plus grosse partie du spam traditionnel ne rentre jamais dans les spools, le reste est correctement filtré.
J'utilise moi même cette infra. J'ai rarement un spam dans ma inbox.
Par contre les pubs sont un vrai problème car les filtres ne marchent pas et surtout ce qui est du spam pour les uns ne l'est pas pour les autres. Il faut donc avoir une politique de filtres individuels, ce qui n'est pas évident à mettre en place sur une grosse infra.
Je m'en sers depuis près de 20 ans, sans avoir plus de spams que sur un compte gmail par exemple. Un catch-all c'est très pratique.
Le fait que tu n'ai jamais rencontré le problème ne signifie pas qu'il n'existe pas. Le jour ou ton domaine est attaqué via un dictionnaire de préfixe, tu risques de souffrir.
je donne l'adresse que je veux à mes correspondants et je peux filtrer en fonction
Et pour les préfixes que tu n'as pas donné tu fais quoi ? Parce que si tu les refuses ce n'est pas exactement un catch all. C'est juste que tu déclares tes adresses dans ton procmailrc au lieu de ton virtusertable. Ce qui permet au passage aux spammers de générer du backscatter ou qui t'obliges à droper des mails .
N'importe quoi.
Je gère une infrastructure d'environ 1 million de mails/jour. Les adresses inexistantes représentent entre 15 et 20 % des tentatives de mail entrant. La dedans, il y a peut être 1% d'erreurs pour 99% de spam. Avec un catch all tout est accepté, filtré, délivré, stocké et l'expéditeur (dans les cas légitimes) ne sais même pas qu'il a fait une erreur. Donc oui les catch all sont un vrai problème et une vrai plaie.
Effectivement, avec les trois solutions décrites ici, tu risques d'avoir pas mal de problèmes.
Ce n'est pas une solution. Le back scatter provient toujours d'une erreur de configuration. Un serveur ne doit pas accepter de messages sur la foi d'une adresse d'expéditeur mais sur celle de l'adresse de destinataire ou d'une authentification.
Les catch all sont un nid à spam qu'il convient de ne jamais utiliser. Il faut déclarer une série d'adresses explicites.
Il ne faut jamais droper de messages. Soit on l'accepte, soit on le rejette avec un message d'erreur explicite. En cas de faux positif, ni l'expéditeur, ni le destinataire ne sont prévenus.
La solution consiste à délivrer les spam dans une boite dédié (Dossier spam) qu'on videra automatiquement des messages les plus anciens et de paramétrer un filtre bayésien permettant de prendre en compte dans le trie effectué par les utilisateurs (déplacement vers spam, deplacement depuis spam.
L'autre solution est de paramétrer une quarantaine pour obliger l'utilisateur à trier les messages douteux et ainsi encore une fois éduquer un filtre bayésien.
Le vrai problème du spam aujourd'hui, c'est les abonnements abusifs à des newsletters qui sont beaucoup plus difficiles à trier car il y a derrière des moyens et de méthodes légitimes d'envoi.
Pour prendre un exemple simple, si tu compiles subversion sur un système ayant un support de kerberos, le script de construction (./configure) va détecter sa présence et ajouter automatiquement le support de kerberos à svn. Même si tu n'as rien de tel dans ton SPEC, tu peux donc avoir des dépendances qui se sont crées simplement au build. Dans cet exemple c'est relativement trivial mais cela peut être beaucoup plus subtil. Tu peux par exemple avoir des différences simplement lié à l'ordre de build quand tu bootstrape ta distro.
Or, si tu vises la compatibilité binaire, il ne s'agit pas simplement d'éviter ce type de phénomènes mais de reproduire exactement ce qui s'est passé chez RedHAT. Centos doit donc imaginer comment RedHat construit sa distribution et vérifier qu'aucune différence n'a été induite par le processus de build.
Knot apporte la rapidité de nsd, tout en ayant certaines des fonctionnalités "avancées" de bind.
Il me semble qu'historiquement NSD a été conçu pour introduire de la diversité dans les serveurs de premier et de second niveau (racines, TLD).
Jusqu'à présent il n'était pas vraiment utilisable sur un grand nombre de zones et avec beaucoup de changements. Du moins c'est ce que j'ai pu en conclure la dernière fois que j'ai fais des tests soit il y a environ deux ans. Il est pourtant essentiel pour avoir une architecture autoritaire solide d'introduire de la diversité à tous les niveaux (réseau, système d'exploitation, service). C'est pourquoi Knot me semble aujourd'hui important.
[^] # Re: soucis...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 2.
C'est quoi ton message exactement ? Ci c'est des truc comme "ad0 … timeout …", il s'agit d'un problème hardware remonté par le driver.
Faire marcher du ZFS sur FreeBSD i386 n'est pas une mince affaire. ce n'est clairement pas prévu pour. Tu peux suivre https://wiki.freebsd.org/ZFSTuningGuide#i386
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 3.
Tu as le même ordre de différence entre deux contrôleurs de la même marque. Si tu compares par exemple une areca 1212 et un areca 1882 tu dois être dans le même ordre d'idée.
C'est au passage la même chose pour les contrôleurs réseau.
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 3.
Et dans ce cas, tu arrêtes tout et tu testes ta mémoire
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 5. Dernière modification le 10 février 2014 à 15:56.
Non, je parle du zpool scrub qui vérifie et corrige l'intégrité des données sur les disques. Des erreurs relevées à ce niveau, relèvent souvent d'un problème matériel sous-jacent et la nécessité d'un diagnostic hardware approfondie.
[^] # Re: Utilisation en production ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 9.
Clairement, ce n'était pas mon but ici. Je voulais mettre un coup de projecteur sue OpenZFS, ZFS On Linux ainsi que l'aspect portable de cette solution. Cela ne signifie en rien que je dénigre md, geom ou lvm mais simplement qu'il n'entraient pas dans le scope de cet article qui est de présenter ZFS comme une alternative viable et portable au RAID proprio.
[^] # Re: ZFS est réservé au stockage
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 10.
On est bien d'accord. Il faut donner à ZFS des disques autrement dit ni des partitions, ni des volumes raid. Par contre tu peux très bien utiliser tes zvol comme des périphériques de bloc quelconque pour faire ce que tu veux y compris les formater en UFS ou autre.
C'est a nuancer suivant l'usage. ZFS n'utilise que les ressources que tu lui donne. Les recommandations visent des performances optimales. C'est une histoire de compromis et de choix.
Le risque que les erreurs de RAM corrompent les données n'est pas spécifique à ZFS. C'est le cas sur tous les systèmes d'écriture asynchrone y compris sur des logiciels comme des SGBD. Sur du hardware non professionnel tu dois lancer des scrub réguliers pour détecter rapidement ce type de comportements.
Non. Tu dois par contre gérer les options de synchro et de cache en fonction de ce risque.
Ce que tu décris des cartes raid proprio correspond au meilleurs des cas. Quand tu dois te battre avec la cli proprio et identifier un disque qui a disparu c'est une autre paire de manche. Le remplacement d'un disque sous ZFS peut également être totalement automatisé.
zpool tank set autoreplace=on
Merci
Je dirais une carte raid à construire sois même. Il faut choisir les composants en connaissance de cause et bien maîtriser le soft. C'est parfois un investissement plus humain couteux que du matériel proprio avec son support. Par contre si le stockage est au cœur de tes préoccupations tu t'y retrouves rapidement.
[^] # Re: Et la config matériel nécessaire pour ZFS ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 6.
ZFS n'utilise pas spécialement de RAM en soit. Il gère par contre du cache en lecture et des écritures asynchrones.
Si tu ne veux pas utiliser de ram.
Du coup, tu as un FS naïf limité par la vitesse des disques
Merki
[^] # Re: BBU
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 2.
Tu as peut être raison. J'avais compris que l'écriture sur flash était systématique. Je peux me tromper, je ne connais pas ce produit. J'ai un peu de mal a concevoir l'aspect "si nécessaire".
[^] # Re: Une limitation de ZFS embêtante pour l'utilisateur amateur que je suis
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 6.
Pour l'instant, il existe deux façons d'étendre un zpool.
1) Remplacer des disques par des disques plus grands.
2) Rajouter un second volume RAID stripé avec le premier
[^] # Re: BBU
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 3.
C'est d'ailleurs exactement le principe du ZIL.
[^] # Re: Utilisation en production ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 10.
J'utilise largement ZFS en production sur tout types de serveurs (BDD, NFS, backup, MAIL, SAN iscsi). Tout ce que j'ai décrit dans l'article est validé en prod.
Les seuls problèmes que j'ai eu depuis 2 ans sont lié à une conception foireuse de l'architecture de stockage sous-jacente. En respectant deux règles :
1) ZFS a besoin que les données soient redondées sur plusieurs disques
2) Ne jamais empiler ZFS avec du raid matériel
je n'ai plus aucun problème.
# Sacré johnny !
Posté par Joris Dedieu (site web personnel) . En réponse au journal Pourquoi les jeux vidéos devraient entrer dans le domaine public. Évalué à 1.
Bon, il fallait bien que quelqu'un la fasse. J'ai du karma …
[^] # Re: Il est toujours la lui?
Posté par Joris Dedieu (site web personnel) . En réponse au journal Quel age ont vos disques ?. Évalué à 3.
Cela dépend à quoi tu rapportes ce coût. La perte d'espace lié au raid a un cout négligeable par rapport aux heures sysadmin passées à remonter des données à partir d'un environnement dégradé. Voir aux indemnités à payer au client en cas de perte.
Le niveau de raid dépend avant tout du besoin en IO rapporté au volume à stocker. Pour un SGDB par exemple le choix est déterminant, pour des backups aussi si tu veux pouvoir paralléliser un maximum. Par contre pour de l'échange de fichiers ou encore pour un applicatif résident en RAM, tu veux juste éviter les indisponibilités.
Le reste c'est de la manut. Une politique de stockage, ce n'est pas seulement le RAID. C'est avant tout le choix des disques qu'il faut avoir en stock sans pour autant les laisser dormir trop longtemps, stresser, surveiller, remplacer à la moindre erreur, diagnostiquer, effacer et remettre en stock ou détruire. C'est aussi le choix des contrôleurs, des alimentations, des backplanes et du soft (système de fichier, gestionnaire de volumes, soft raid …). Enfin c'est de la procédure. Être alerté, savoir quel disque est dans quel tiroir, avoir une procédure de remplacement et de reconstruction solide.
Si effectivement, tu as besoin de deux jours pour intervenir sur un problème de disque, le raid (quelque soit son niveau) ne peut rien pour toi. Ce qu'il te faut alors c'est des backups.
[^] # Re: Que dire de plus ?
Posté par Joris Dedieu (site web personnel) . En réponse au journal Le féminisme me gonfle. Évalué à 7.
Ce qui n'est pas dis c'est combien de parents ne veulent pas de leurs enfants. Combien de fois la garde est donnée a la mère par défaut, parce qu'aucun des deux ne veut vraiment se coltiner les devoirs, trouver des solutions de garde et sacrifier ses loisirs a l'éducation des enfants.
Le choix de la mère est un choix par défaut. Et c'est un choix profondément sexiste partant du postula que l'enfant c'est le domaine des femmes et qu'elle se débrouillera bien.
Autrement dit dans la majorité des cas la mère est désignée d'une façon ou d'une autre et il n'y a pas de combat mais soulagement côté père et résignation côté mère.
Il me semble que se retrouver seul avec les mômes fait flipper tout le monde. Et c'est bien normal. C'est un bouleversement profond du mode de vie.
Il me faut quand même pas oublier qu'on doit la garde alternée, la garde par les pères et plus généralement la reconnaissance de la capacité des hommes a s'occuper des enfants au combat des féministes. C'est parce qu'elles ont collés a leur types un paquet de couche sous le nez qu'aujourd'hui ce combat pour la reconnaissance du droit des pères peut exister.
L'institution est rétrograde. A la crèche, on parle de l'heure des mamans, la justice familiale considère encore la mère comme un être trop faible pour subvenir a ses besoins, les gens regardent de travers quand un père est seul en vacance avec un petit enfant …
Les féministes combattent pour le droit des femmes a faire autre chose que de pouponner, voir a ne pas pouponner du tout. La reconnaissance de la capacité des pères a s'occuper des enfants entre juste dans ce cadre la.
De nombreuses féministes considèrent que le choix de la mère par défaut est une profonde injustice.
[^] # Re: image FreeBSD pour Raspberry Pi ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche FreeBSD 10. Évalué à 5.
C'est documenté sur https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi
On trouve des images sur http://www.db.net/downloads/ mais il n'y a effectivement pas d'image binaire officielle.
[^] # Re: Quelques autres changements
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche FreeBSD 10. Évalué à 5.
Non, il y a eu un consensus autour du fait qu'un serveur autoritaire n'avait pas sa place dans le système de base (pas plus qu'un serveur imap ou http …).
[^] # Re: par définition
Posté par Joris Dedieu (site web personnel) . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 4.
OpenSSH est loin de représenter OpenBSD dans son ensemble. C'est un projet qui pourrait très bien survivre à OpenBSD ou être forker.
[^] # Re: Oui
Posté par Joris Dedieu (site web personnel) . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 10.
des BSD sans doute veux tu dire ?
Prends un exemple. Si tu souhaites mettre en place une architecture DNS robuste, il te faut :
Cela te permet de conserver un service UP même lorsqu'une partie de ton infra est devenu vulnérable ou sous le feu d'une attaque.
La diversité permet de diluer les risques, c'est pourquoi, il est essentiel de pouvoir disposer d'un écosystème de logiciels vaste pour produire des services réseau viables.
Ce qui est important, ce n'est pas tant OpenBSD, que la possibilité pour les administrateurs système de pouvoir déployer une certaine variété de solutions. Une diminution du nombre de solutions disponibles entrainerai un retour vers des solutions propriétaires et serait pour le libre en général une mauvaise affaire.
Cette variété d'implémentations est également essentielle pour les développeurs à qui elle permet de confronter leurs idées à celles des autres.
Enfin pour ce qui est du cas spécifique d'OpenBSD, c'est une communauté qui a fait grandement avancer le libre entre autre sur les pilotes Wifi, sur l'implémentation des protocoles réseau, sur la gestion des chaines de caractères et sur un tas d'autres sujet.
Elle produit aussi un certain nombre de logiciels comme OpenSSH, OpenBGPD, OpenSMTPD, Mandoc … qui sont utilisés sous Linux comme sous tout un tas d'autres OS.
[^] # Re: par définition
Posté par Joris Dedieu (site web personnel) . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 6.
Reste à savoir si une telle entreprise existe. Qu'il y ait des entreprises utilisant OpenBSD, ne fait aucun doute. Qu'il y ait des entreprises utilisant du code issue d'OpenBSD également. Qu'il y ait des entreprises dépendant fortement d'OpenBSD au même titre que Canonical dépend de Debian ou Netasq de FreeBSD c'est moins certain.
Le fait d'utiliser OpenBSD sur un parc de serveur, ou encore d'avoir piqué du code a un instant t pour répondre à un problème particulier ne fait pas la dépendance.
[^] # Re: plop
Posté par Joris Dedieu (site web personnel) . En réponse au journal Suppression des spams. Évalué à 2.
50% c'est la proportion de connexions sur les MX qui n'aboutissent pas à un mail :
C'est à 95% du spam.
Sur les 50% effectivement accepté, c'est dur à dire. A la louche :
En étant un peu strict en entrée, la plus grosse partie du spam traditionnel ne rentre jamais dans les spools, le reste est correctement filtré.
J'utilise moi même cette infra. J'ai rarement un spam dans ma inbox.
Par contre les pubs sont un vrai problème car les filtres ne marchent pas et surtout ce qui est du spam pour les uns ne l'est pas pour les autres. Il faut donc avoir une politique de filtres individuels, ce qui n'est pas évident à mettre en place sur une grosse infra.
[^] # Re: plop
Posté par Joris Dedieu (site web personnel) . En réponse au journal Suppression des spams. Évalué à 5.
Le fait que tu n'ai jamais rencontré le problème ne signifie pas qu'il n'existe pas. Le jour ou ton domaine est attaqué via un dictionnaire de préfixe, tu risques de souffrir.
Et pour les préfixes que tu n'as pas donné tu fais quoi ? Parce que si tu les refuses ce n'est pas exactement un catch all. C'est juste que tu déclares tes adresses dans ton procmailrc au lieu de ton virtusertable. Ce qui permet au passage aux spammers de générer du backscatter ou qui t'obliges à droper des mails .
Je gère une infrastructure d'environ 1 million de mails/jour. Les adresses inexistantes représentent entre 15 et 20 % des tentatives de mail entrant. La dedans, il y a peut être 1% d'erreurs pour 99% de spam. Avec un catch all tout est accepté, filtré, délivré, stocké et l'expéditeur (dans les cas légitimes) ne sais même pas qu'il a fait une erreur. Donc oui les catch all sont un vrai problème et une vrai plaie.
# plop
Posté par Joris Dedieu (site web personnel) . En réponse au journal Suppression des spams. Évalué à 9.
Effectivement, avec les trois solutions décrites ici, tu risques d'avoir pas mal de problèmes.
Ce n'est pas une solution. Le back scatter provient toujours d'une erreur de configuration. Un serveur ne doit pas accepter de messages sur la foi d'une adresse d'expéditeur mais sur celle de l'adresse de destinataire ou d'une authentification.
Les catch all sont un nid à spam qu'il convient de ne jamais utiliser. Il faut déclarer une série d'adresses explicites.
Il ne faut jamais droper de messages. Soit on l'accepte, soit on le rejette avec un message d'erreur explicite. En cas de faux positif, ni l'expéditeur, ni le destinataire ne sont prévenus.
La solution consiste à délivrer les spam dans une boite dédié (Dossier spam) qu'on videra automatiquement des messages les plus anciens et de paramétrer un filtre bayésien permettant de prendre en compte dans le trie effectué par les utilisateurs (déplacement vers spam, deplacement depuis spam.
L'autre solution est de paramétrer une quarantaine pour obliger l'utilisateur à trier les messages douteux et ainsi encore une fois éduquer un filtre bayésien.
Le vrai problème du spam aujourd'hui, c'est les abonnements abusifs à des newsletters qui sont beaucoup plus difficiles à trier car il y a derrière des moyens et de méthodes légitimes d'envoi.
[^] # Re: Choix ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche CentOS et Red Hat unissent leurs forces pour une plateforme communautaire stable. Évalué à 6. Dernière modification le 09 janvier 2014 à 12:44.
Pour prendre un exemple simple, si tu compiles subversion sur un système ayant un support de kerberos, le script de construction (./configure) va détecter sa présence et ajouter automatiquement le support de kerberos à svn. Même si tu n'as rien de tel dans ton SPEC, tu peux donc avoir des dépendances qui se sont crées simplement au build. Dans cet exemple c'est relativement trivial mais cela peut être beaucoup plus subtil. Tu peux par exemple avoir des différences simplement lié à l'ordre de build quand tu bootstrape ta distro.
Or, si tu vises la compatibilité binaire, il ne s'agit pas simplement d'éviter ce type de phénomènes mais de reproduire exactement ce qui s'est passé chez RedHAT. Centos doit donc imaginer comment RedHat construit sa distribution et vérifier qu'aucune différence n'a été induite par le processus de build.
[^] # Re: Plus de fonctions ????
Posté par Joris Dedieu (site web personnel) . En réponse au journal Le serveur DNS Knot. Évalué à 3.
Il me semble qu'historiquement NSD a été conçu pour introduire de la diversité dans les serveurs de premier et de second niveau (racines, TLD).
Jusqu'à présent il n'était pas vraiment utilisable sur un grand nombre de zones et avec beaucoup de changements. Du moins c'est ce que j'ai pu en conclure la dernière fois que j'ai fais des tests soit il y a environ deux ans. Il est pourtant essentiel pour avoir une architecture autoritaire solide d'introduire de la diversité à tous les niveaux (réseau, système d'exploitation, service). C'est pourquoi Knot me semble aujourd'hui important.
[^] # Re: Lapin compris...
Posté par Joris Dedieu (site web personnel) . En réponse au journal Liste des outils de la NSA. Évalué à 8. Dernière modification le 03 janvier 2014 à 19:00.
Sans oublier OpenBSD
==============> Je sors