Joris Dedieu a écrit 1614 commentaires

Effectivement, avec les trois solutions décrites ici, tu risques d'avoir pas mal de problèmes.

1. 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.

2. Les catch all sont un nid à spam qu'il convient de ne jamais utiliser. Il faut déclarer une série d'adresses explicites.

3. 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.

Parce que je suis certain que Linux devrait figurer dans les outils utilisés.

Sans oublier OpenBSD

==============> Je sors

as ton propre nom de domaine, tu peux mettre un « catch all »

Et tu vas découvrir l'ampleur du spam. Le jour ou tu te prends une attaque au dictionnaire sur ton domaine, tu risques de pleurer.

spamd

spamd est un daemon fournie par Spamassassin.

Une distribution spamassassin est avant tout une série de modules perl (http://search.cpan.org/search?query=spamassassin&mode=all). Ainsi que divers utilitaires :

• spamassassin : un scanner en ligne de commande
• spamd : un scanner en mode daemon
• spamc : un client pour le scanner en mode daemon
• sa-update : un utilitaire pour mettre à jour les règles
• sa-learn : un utilitaire pour nourrir les filtres bayésiens
• sa-compile, spamass-milter …

Lorsqu'on évoque spamassassin directement en ligne de commande, il effectue à chaque fois l'initialisation du moteur de filtrage (chargement des modules, des règles …). C'est relativement lourd. Spamd répond à ce problème en maintenant le moteur up. Il est un peu à spamass ce que fastcgi est au web.

Certains moteurs comme amavisd-new se connectent directement à la socket fournie par spamd. D'autres appellent spamc en ligne de commande. Certains enfin comme mimedefang utilisent directement les modules Perl pour lancer leur propre daemon.

De plus les x60 en particulier et les thinkpad en général, sont des machines robustes. Je dirais a tout épreuve.

J'en ai un perso, un pour ma fille, un que j'ai perdu, un qui me sert de player audio de salon, un pour les astreintes et un de spare. Toutes achetés moins de 200€ chez un broker. Toujours dans le sac a prendre des pignes. Un sdd, une batterie neuve et ça roxe. De loin les meilleures machines que j'ai jamais eu.

c'était la première distribution à intégrer KDE

C'était aussi la première distribution correctement internationalisée

C'est aussi la préco de ceph.

c'est ca le plus fort, comment ont'il eu le bol

Optimisation de l'usinage des boîtiers ?

L'auteur s'en explique dans l'interview sur framablog.

Oui, je n’utilise pas le terme utopie dans le sens péjoratif courant, afin de dénigrer des ambitions irréalistes et un peu farfelues. Je l’emploie plutôt pour désigner des projets qui dessinent un monde social différent dont rien n’indique qu’il soit totalement hors de portée ou, du moins, qu’on ne puisse pas s’en approcher. Cet usage positif du terme a des racines historiques dans les utopies socialistes du XIXe siècle par exemple, et des racines philosophiques chez des auteurs comme Walter Benjamin, Ernst Bloch ou plus récemment Miguel Abensour.
``̀

Donc pour toi les VT sont clairement mal foutus ? C'est une vrai question, j'y connais rien.

Ça semble pas aberrant de gérer cela en espace utilisateur. Le noyau à priori n'as pas à fournir grand choses de plus que des tty. On a ceci dit du mal à imaginer comment gérer correctement les situations d'urgence. Typiquement l'usage que je vois des VT en mode noyau, c'est le lancement d'un debogueur suite à un panic.

De base avec Apache, tu peux modifier les pages et même modifier les cookies…

Pour les cookies aucun problème c'est un header comme un autre, mais pour les pages (autrement dit le html), comment fais-tu ? tu utilises mod_substitute pour réécrire tes liens ? Je ne vois pas trop l'avantage par rapport à des liens relatifs (c'est une vrai question) ?

Au delà du troll l'auteur du patch semble pointer un vrai problème qui est la présence d'une interface utilisateur complète dans le noyau Linux. C'est l'option CONFIG_VT (activée par défaut sous RedHat et Debian et sur toutes les distributions que je connais).

Cela sert au noyau à afficher divers messages, à deboguer mais aussi et surtout à ouvrir plusieurs terminaux sur la même machine (ctrl-alt-F1 …).

L'auteur point du doigt que l'affichage des messages peut se faire de façon beaucoup plus simple avec par exemple fblog et que le débogage du noyau se fait habituellement par port série. Il pointe en outre que cette console dans le noyau pose divers problèmes notamment en terme d'occupation mémoire et de sécurité.

systemd se propose donc d'offrir un système de console alternatif permettant de désactiver le support des terminaux virtuels du noyau.

Ce qui est donc en cause ici est avant tout le support des VT dans linux et l'assertion selon laquelle il devraient être gérés en espace utilisateur.

A noter que Kmscon < http://www.freedesktop.org/wiki/Software/kmscon/> fonctionne déjà sans la couche VT du noyau.

T'es au courant que Solaris a un équivalent de systemd (SMF) depuis des années ?

Non SMF sert uniquement à gérer les services. init continue d'exister. Il lance et supervise svc.configd et svc.startd. Il peut également lancer des processus définies dans /etc/inittab bien que cette façon de faire soit dépréciée.

Les logs continent d'être gérés par syslogd et les tty par ttymon (qui existe depuis solaris 2 je crois) comme précédemment.

combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?

Haproxy s'est adapté puisqu'un wrapper à été commité. On peut le lancer avec l'option -Ds qui permet de lancer un wrapper qui ne fait rien d'autre qu'un wait() afin de donner à systemd un PID stable a monitorer.

http://git.1wt.eu/web?p=haproxy.git&a=search&h=HEAD&st=commit&s=systemd

Pour quiconque l'ayant utilisé en server, c'est une plaie!

Non. La plaie vient du fait qu'on cherche à utiliser RHEL comme Debian. La plaie vient aussi du fait qu'on démarre de projets en entreprise sur des versions antédiluviennes au lieu de prendre la version actuelle.

Pour la maintenance à long terme d'un projet, RHEL c'est juste parfait :

• pas de mises à jour qui pètent tout
• un bon niveau de QA, peu de surprises.
• un support vraiment long.

RedHat te permet d'avoir une version de PHP maintenue durant plus de dix ans. Si cela ne t'intéresses pas alors tu t'es simplement trompé de distribution.

Je sais pas avec postfix, avec sendmail on peut utiliser une queue par domaine de destination.

Dans /etc/mail/access :

QGRP:orange.fr orange
QGRP:laposte.net laposte
....

Puis dans ton mc

̀
FEATURE(queuegroup')
define(QUEUE_DIR',/var/spool/mqueue')
QUEUE_GROUP(orange',P=/var/spool/mqueue/orange, I=1s, Jobs=1, recipients=1, Runners=1')dnl
QUEUE_GROUP(laposte',P=/var/spool/mqueue/laposte, I=1s, Jobs=1, recipients=1, Runners=1')dnl
̀`

Concernant le smtp, l'excellent mimedefang permet d'aller interroger un serveur distant pour valider l'utilisateur, ce qui permet de distribuer ses comptes à moindre frais.

       sub filter_recipient
       {
           my($recip, $sender, $ip, $host, $first, $helo,
              $rcpt_mailer, $rcpt_host, $rcpt_addr) = @_;
           return md_check_against_smtp_server($sender, $recip,
                                "filter.domain.tld",
                                "mail.domain.tld");
       }

Par ailleurs, de plus en plus d'applications supportent le proxy protocol (http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt) qui permet de transmettre l'IP à l'origine de la connexion. C'est le cas par exemple de postfix.

Si ce n'est pas le cas et qu'il n'existe pas d'autre mécanismes spécifique en ce sens (type mod_rpaf pour apache par exemple), la seule façon de conserver l'IP d'origine est d'utiliser la fonctionnalité de proxy transparent fournie par le noyau ( https://www.kernel.org/doc/Documentation/networking/tproxy.txt) : tproxy

Dans l'exemple que tu donnes je ne vois pas la nécessité de réécrire le HTML. Ceci dit haproxy ne le fait clairement pas. Apache de base non plus d'ailleurs.

L'approche entre mod-rewrite et haproxy n'est pas similaire. Il faut penser un peu différemment. Mais c'est également très efficace. Je conseille de regarder http://blog.exceliance.fr. il y a beaucoup de recettes intéressantes pour aborder la question

Apache n'est pas un bon choix pour un reverse proxy http / https :

• pas de gestion différencié des timeout côté client et côté serveur
• modèle un thread / proc par requête (pas de pool)
• pas de check pour vérifier la santé du backend
• pas de maximum de connexions par backend
• pas de stratégie de replie en cas de problème

Il vaut largement mieux utiliser haproxy, nginx ou varnish qui pourrons de plus vous servir à d'autres choses (mode pop / imap pour nginx, mode tcp pour haproxy, cache pour varnish).

Personnellement mon coeur me pousse vers haproxy

Petite exemple amusant :

On veux rediriger les connexions mysql adressé sur localhost vers une machine distante de façon transparente pour l'utilisateur.

Le problème est que la libmysqlclient convertie les appels vers localhost en connexion sur la socket unix par défaut. Autrement une simple règle de firewall ne suffit pas. Il faut pouvoir rediriger les connexions à la socket unix vers le port 3306 d'une machine distante.

listen  mysql /tmp/mysql.sock
        mode tcp
    timeout server 1h
    timeout client 30s
        server sql0 sqlhost:3306 maxconn 500

Et hop merki haproxy

Il ne faut pas résumer le débat à ce troll. Le message laisse entendre qu'il y a un consensus sur ce point ce qui est loin d'être le cas. C'est du lobbying, ni plus ni moins.

Même d'autres gens présent à cette réunion ne sont pas d'accord sur l'interprétation.

>>> 745 4) Requre secure underlying protocol for HTTP/2.0 (at least in web browsing)
>>> 746 
>>> 747 [ weaker for can't live with ]
>>
>> Are you saying that 4) == C), and that 4) was about using https only?
>
> In a nutshell, yes.

I'm still confused. What you say implies that http: URIs will not use 
HTTP/2. We did *not* discuss this as option 4.

Pour l'heure on peut dire que les gens qui font des navigateurs sont plutôt pour utiliser TLS systématiquement et que les gens qui font des proxys sont carrément contre.

> To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you'll need to use https:// URIs and if you want to use the newest version of HTTP.

For the record, I strongly believe that support for unencrypted HTTP/2.0 is still needed and useful, particularly when you are routing it over an already “secure" channel to a resource-constrained device.  And there will likely be practical real-life limitations of what browser vendors choose to implement, i.e., no HTTP/2.0 support for http:// URIs.  However,  I honestly don’t see how this WG can actually enforce/mandate https:// and still allow http:// URIs.  So long as unencrypted URIs are supported by HTTP/2.0, the best you can do is make security recommendations since TLS is not REQUIRED (in the RFC 2119 sense) for the open web.

I also believe that HTTP/1.x has been so successful because of its ease (and freedom) of implementation. But IMHO restricting its use to https:// will only limit its use/deployment to sites/providers that can afford to deploy it and prevent HTTP/2.0 from replacing HTTP/1.1 in the long run.

Bref s'il y a un consensus qui se dessine, il serait plutôt contre.

Bonjour, beau projet. Je te conseille de jeter un œil a libarchive et en particulier au format mtree.

Je crois que cela pourrais simplifier grandement ton code.

on est obligé d'avoir en permanence un Apache2 en root

Pas avec suexec justement. suexec + mod_fcgid + php-cgi donne à peu près le même résultat en moins propre bien sur car on passe par un binaire setuid. Mais permet par contre de conserver la syntaxe apache et le .htaccess qui sont malheureusement encore trop difficilement contournable quand on veut offrir une solution qui marche out-of-the-box avec a peu près tous les CMS du marché.

A noter que apache 2.4 introduit mod_proxy_fcgi qui permet d'utiliser php-fpm et apache ce qui semble être une solution plus acceptable si ce n'est l'absence pour l'heure d'un support des socket Unix.

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/html/$1

D'où l'art du monitoring ; ne rien rater sans se faire réveiller indûment.