Joris Dedieu a écrit 1610 commentaires

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.

Il me semble pourtant que la section "4.1.4. Order of Commands" précise :

An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.

Mais peut-être fais-je un contre-sens ?

Quand au fait que cette vérification soit contestable, je n'en disconviens pas et ce n'est pas mon propos. Elle est appliqué parfois en violation totale du protocole par des fournisseurs d'antispam. C'est aussi la règle RDNS_NONE de spamassassin.

C'est à dire? (oui, des chiffres!)

Bonne question. Ça dépend des providers. Orange par exemple ça semble être 3 mails par secondes avant de te faire greylister

J'ai personnellement jamais eu de problème pour envoyer une centaine de courriel en une seconde à un destinataire chez gmail

Essaye la même chez Orange.

1 - reverse DNS

Le RFC 5321 précise qu'un serveur SMTP peut vérifier que le nom de domaine donné dans la commande EHLO correspond à l'adresse IP du client. Même si ce n'est pas un critère suffisant pour refuser les mails.

Dans la pratique cela signifie qu'une machine bien configurée dit :

• bonjour je suis $HOSTNAME
• dig $HOSTNAME donne IP de la machine
• dig -x $IP donne $HOSTNAME

Sans cela votre score comme spammer risque d'être incrémenté, voire vos mails refusés par certains fournisseurs d'antispam (postfix : smtpd_helo_restrictions).

2 - Envoyer doucement.

Beaucoup de fournisseurs (yahoo, orange, hotmail) n'aiment pas trop qu'on envoie des mails trop rapidement vers chez eux. Et ils ont souvent raison de le faire. Il est donc important, sans tomber dans le travers des spameursrouteurs qui ont une politique différente par provider, d'ajuster les paramètres :

default_destination_recipient_limit
default_destination_rate_delay

Afin que les emails soient envoyés doucement.
Surtout si on héberge des mailling-list.

3 - Si possible utilisez STARTTLS (voir par exemple http://www.bortzmeyer.org/postfix-tls.html)

4 - Ne jamais accepter un mail qu'on est pas sûr de pouvoir délivrer.

Dès qu'un mail est rentré dans vos spools, vous êtes susceptible de générer un bounce et donc un spam.

Le cas typique est un MX secondaires qui ne possède pas la liste des adresses valides. Il reçoit les mails et les forwarde sans plus de contrôle ou juste en contrôlant le domaine au MX principal. Ainsi, en envoyant des mails au MX secondaire pour une adresse qui n'existe pas sur votre domaine, je pourrais l'utiliser pour spamer l'adresse d'expéditeur.