Journal Pound se plaint...

Posté par . Licence CC by-sa
3
15
mai
2011

Pound est un petit outil qui peut faciliter l'avis de l'administrateur d'un serveur web. C'est un proxy inverse (reverse proxy), répartiteur de charge (load balancer) et un gestionnaire HTTPS à placer en amont de serveurs Web (HTTPS front-end server).

Si les fonctions de répartition de charge ne concerneront pas les petites installations, il peut toutefois rendre bien des services pour gérer l'accès HTTPS à des serveurs web qui par exemple ne supportent pas HTTPS. Pound est capable d'échanger en HTTPS avec le client, de décrypter les messages et de les envoyer ensuite en clair au serveur sous-jacent (donc le message ne transite en clair que dans une partie normalement sécurisée du réseau). Pour l'utilisateur distant, la connexion transite dans le canal HTTPS de manière tout à fait transparente.

Un petit outil intéressant sur lequel vous pourrez tout apprendre en vous rendant ici :
http://www.apsis.ch/pound/

Toutefois, après son installation, j'ai observé pound se plaindre dans le /var/log/syslog de mon système.

May 15 12:49:59 host pound: libgcc_s.so.1 must be installed for pthread_cancel to work                                                                         
May 15 12:49:59 host pound: MONITOR: worker exited on signal 6, restarting...

Après vérification, libgcc_s.so.1 était pourtant bien disponible sur le système... Et pound s'obstinait à ne pas le trouver.

L'explication était en fait toute simple - j'avais activé le chroot dans la configuration de pound (afin de durcir l'installation) :

RootJail        "mon-dossier-chroot/pound"

et c'est donc dans ce dossier que pound cherchait la librairie libgcc !

Pour contenter pound, il m'a alors suffi de copier (ou lier) la librairie libgcc dans "mon-dossier-chroot/pound/lib/libgcc_s.so.1" et voilà Pound satisfait qui ne s'est plus plaint.

  • # LE journal se plaint ....

    Posté par . Évalué à 10.

    ... d'un contenu qui aurait sa place dans le forum, rubrique "astuces" (Ca c'est fait).

  • # Mon à vie

    Posté par (page perso) . Évalué à 4.

    Faciliter l'avis -> faciliter la vie
    Je suppose.

  • # Ré-écriture

    Posté par (page perso) . Évalué à 2.

    Sais-t'il ré-écrire à la volée les pages HTML ? Apache2 sais le faire mais je n'en connais pas d'autres.

    Par exemple, j'ai un intranet accessible en interne

    http://intranet.monlab.fr

    En externe, il est accessible sous

    https://www.monlab.fr/intranet/

    Dans ces pages web, je fais référence à des services internes, par exemple

    http://forge.monlab.fr

    Bien sur, dans la version https, je ré-écris à la volée dans Apache2 le code HTML pour avoir

    https://www.monlab.fr/forge/

    C'est basique mais très pratique, tant pour les utilisateurs en interne (pas de https en interne pour la consultation) qu'en externe (marche partout, pas de VPN...) ainsi qu'au niveau administration.

    Le seul hic est que je ne sais pas si un autre ReverseProxy qu'Apache fait cela aussi bien et pour un service aussi sensible, c'est bien d'avoir deux solutions sous la main.

    • [^] # Re: Ré-écriture

      Posté par (page perso) . Évalué à 3.

      Nginx.

      • [^] # Re: Ré-écriture

        Posté par . Évalué à 3.

        C'est ça le problème… Aujourd'hui, tout le monde utilise le bloatware d'Apache2 alors que Nginx fait tout pareil, en mieux, en plus simple, en plus rapide et avec beaucoup moins de ressources.

        Knowing the syntax of Java does not make someone a software engineer.

        • [^] # Re: Ré-écriture

          Posté par . Évalué à 6.

          On en reparle dans 5 ans, lorsque nginx fera tout ce que fait Apache, et sera aussi lourd.

        • [^] # Re: Ré-écriture

          Posté par . Évalué à 0.

          Bah, je ne t'en veux pas, personnellement, ça ne me gène pas. juste que c'est une espèce de coutume sur linuxfr dans ce genre de cas.

          • [^] # Re: Ré-écriture

            Posté par . Évalué à 0.

            Oups, désolé je me suis gouré .... Pas au bon endroit.

            Moinssez-moi.

  • # Voilà quelque chose qui m'intéresse

    Posté par (page perso) . Évalué à 2.

    Même si je suis d'accord avec le fait qu'il s'agisse plus d'une astuce (donc d'un billet de forum) que d'un journal, je tiens à te remercier de m'avoir fait découvrir Pound.

    Même si apache2 avec mod_proxy se configure en quelques lignes... c'est parfois/souvent sur-dimensionné.

    Alexandre COLLIGNON

    • [^] # Re: Voilà quelque chose qui m'intéresse

      Posté par (page perso) . Évalué à 2.

      Nginx permet de remplacer Pound.

      • [^] # Re: Voilà quelque chose qui m'intéresse

        Posté par . Évalué à 3.

        Nginx permet de remplacer Pound.

        Et en mieu :

        I currently have nginx doing reverse proxy of over tens of millions of HTTP requests per day (thats a few hundred per second) on a single server. At peak load it uses about 15MB RAM and 10% CPU on my particular configuration (FreeBSD 6).
        Under the same kind of load, apache falls over (after using 1000 or so processes and god knows how much RAM), pound falls over (too many threads, and using 400MB+ of RAM for all the thread stacks), and lighty leaks more than 20MB per hour (and uses more CPU, but not significantly more).

        Ne vous inquiétez pas, depuis ce message, la documentation de nginx a été entièrement traduite en Anglais.

        Knowing the syntax of Java does not make someone a software engineer.

        • [^] # Re: Voilà quelque chose qui m'intéresse

          Posté par . Évalué à 1.

          On en parle aussi ici

          Knowing the syntax of Java does not make someone a software engineer.

          • [^] # Re: Voilà quelque chose qui m'intéresse

            Posté par (page perso) . Évalué à 3.

            Je complète un peu la liste des softs cités dans ton lien :
            - apache2 en reverse proxy avec le bon type de worker fonctionne pas trop mal et est, pour l'instant, le seul à avoir un "outil" tel que modsecurity
            - en reverse proxy / load balancer, HAproxy est pour moi supérieur à nginx
            - OpenBSD/PF + relayd (avec du trunk + carp + pfsync) est incroyablement efficace comme load balancer et injustement peu cité

            J'ai déjà utilisé tous ces outils + varnish dans un même stack web et j'en étais entièrement satisfait.
            L'intérêt pour nginx est sûrement dû à sa capacité de s'adapter à plusieurs usages mais il serait dommage de passer à coté des autres.

      • [^] # Re: Voilà quelque chose qui m'intéresse

        Posté par . Évalué à 1.

        nginx permet de remplacer pound ....
        certes, certes...
        mais les fans de nginx nous le vendent parce que c'est plus léger, alors ce n'est peut-être pas la peine de remplacer pound par quelque chose de plus lourd, non ?
        pound est super léger, ne fait que reverse proxy (pas de serveur web) et le fait bien.

  • # LD_PRELOAD

    Posté par (page perso) . Évalué à 1.

    Pour contenter pound, il m'a alors suffi de copier

    export LD_PRELOAD=/usr/lib/libgcc_s.so.1 ne marche pas ?

    • [^] # Re: LD_PRELOAD

      Posté par (page perso) . Évalué à 2.

      En chroot, /usr/lib/libgcc_s.so.1 n'est probablement pas accessible.

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

      • [^] # Re: LD_PRELOAD

        Posté par (page perso) . Évalué à 2.

        C'est un des problèmes de faire du chroot, souvent, il n'y a plus de mise à jour ensuite si on fait cela à l'arrache ;-)

      • [^] # Re: LD_PRELOAD

        Posté par (page perso) . Évalué à 1.

        En chroot, /usr/lib/libgcc_s.so.1 n'est probablement pas accessible.

        C'est tout l’intérêt de LD_PRELOAD. Au moment du chroot ta lib est déja chargé donc plus besoin d’accéder au système de fichier.

        • [^] # Re: LD_PRELOAD

          Posté par (page perso) . Évalué à 2.

          Par exemple chez moi named :

          #named est linké avec quelques lib
           ldd /usr/sbin/named
          /usr/sbin/named:
                  libcrypto.so.6 => /lib/libcrypto.so.6 (0x800806000)
                  libthr.so.3 => /lib/libthr.so.3 (0x800aa6000)
                  libc.so.7 => /lib/libc.so.7 (0x800bbf000)
          
          #named est chrooté dans /var/named
          grep named /etc/defaults/rc.conf 
          ...
          named_chrootdir="/var/named"
          ...
          
          find /var/named/ -name "*.so*"
          #rien
          #et pourtant elle tourne
          ps www `cat /var/named/var/run/named/named.pid`
            PID  TT  STAT      TIME COMMAND
          12867  ??  Is     0:00.02 /usr/local/sbin/named -u bind -c /etc/namedb/named.conf -t /var/named -u bind
          

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.