Forum Programmation.web squid, apache, hebergement de fichier.

Posté par .
1
27
déc.
2011

Bonjour et Joyeuse fêtes avant tout !

Voici mon problème :

J'aimerais pouvoir configurer un squid et un apache sur le même serveur, de façon à ce que squid écoute sur le port 8080 et le serveur apache aussi. En fait le serveur apache ne doit servir qu'une page, c'est un fichier de configuration de proxy.

J'aimerais donc pouvoir configurer comme proxy dans les navigateurs 10.0.80.254:8080 et pouvoir servir un truc en http à 10.0.80.254:8080/script.pac

Comme il n'est pas possible de binder deux process sur le même port, en fouillant sur le web, j'ai trouvé une truc : on fait ecouter apache sur un autre port en 127.0.0.1. J'ai dans ma conf apache :

Listen 127.0.0.1:8181

Et ensuite on redirige toute les connexions du squid qui ecoute en 8080 vers apache. J'ai dans mon squid.conf :

http_port 10.0.80.254:8080 accel defaultsite=proxysquid
cache_peer 127.0.0.1 parent 8181 0 no-query originserver

Le problème c'est que TOUT les flux sont redirigé vers le serveur apache. Il n'est pas possible de ne rediriger que pour l'URL 10.0.80.254:8080/script.pac ?

Je sais que c'est tordu comme architecture, mais ça m'est imposé...

Merci d'avoir pris le temps de me lire !

  • # Commentaire supprimé

    Posté par . Évalué à 4.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

      Posté par . Évalué à 1.

      je me demande aussi pourquoi déballer tout un apache pour juste servir un unique fichier PAC, mais il manque une partie des données sur l'infrastructure, à priori.
      donc, allez savoir?

      • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

        Posté par . Évalué à 3.

        J'ai mis un apache parce qu'il n'y a qu'un apache, c'est une maquette, mais je ne pense pas que la solution réside dans un changement de serveur web. Je pense utiliser lighttpd ensuite, mais bon, j'utiliserais le serveur web qui résoudra mon problème si un changement est possible coté serveur web.

        Je ne cache rien sur l'infrastructure ! C'est simple (pas tant que ça apparemment, je n'y arrive pas :)) , j'aimerais avoir un squid qui fait son boulot de proxy sur le port 10.0.80.254:8080 et qui sert un fichier script.pac avec un mime de application/x-ns-proxy-autoconfig

        Pourquoi ?

        Parce que j'ai un nombre incalculable de machine configurées avec un fichier de config proxy à l'adresse : 10.0.80.254:8080/script.pac et que ce fichier pac retourne comme proxy 10.0.80.254:8080 dans certaine situation.
        La plateforme de proxy actuelle (proprio) a ce mode de fonctionne.

        J'ai planché et j'ai trouvé une demi-solution, mais elle est non applicable dans mon cas (je la mets si ça peut interesser): faire une acl dans squid, et retourner un fichier d'erreur qui est fait le script de configuration.
        Problème, il faut recompiler squid. C'est un problème car la solution doit être simple.
        Problème 2, le mime type envoyé n'est pas le bon. C'est le point bloquant, au dela du fait que c'est du bricolage cette solution.

        Voila ou j'en suis de l'état de mes recherches :)

        • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

          Posté par (page perso) . Évalué à 3. Dernière modification le 27/12/11 à 19:49.

          Parce que j'ai un nombre incalculable de machine configurées avec un fichier de config proxy à l'adresse : 10.0.80.254:8080/script.pac et
          que ce fichier pac retourne comme proxy 10.0.80.254:8080 dans certaine situation.

          Et pourquoi ne pas simplement modifier le proxy.pac pour renvoyer sur le bon port de la bonne machine vu qu'il est fait pour ça ?

          Modifie ton proxy.pac pour renvoye sur 10.0.80.254:3128 par exemple et place un simple apache/lighttpd/whatever sur le port 8080 qui sert uniquement ton proxy.pac.

          Ou alors il manque un element et ceraines machines on une configuration de proxy en dur ?

          • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

            Posté par . Évalué à 2.

            Ou alors il manque un élément et certaines machines on une configuration de proxy en dur ?

            Oui je le soupçonne. Et je ne peux pas prendre le risque. Le parc est constituer de tout (du linux :)) et de n'importe quoi (de l'ipad :)).
            Et bien sur, si un commercial n'a pas accès à internet pendant plus de 28 secondes d'affilé, je suis emmuré vivant :)

            Non mais je pense que je vais être obligé de modifier un des deux ports (proxy ou http), mais je voulais juste être sur, voila tout. ça va va générer du boulot c'est tout...

            En même temps, je m'en fou, ce sera pour les gars du système ! je plaisante évidemment :)

        • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

          Posté par . Évalué à 1.

          c'est quoi l'obligation d'avoir le fichier PAC servi par un serveur sur le port 8080 ?

          le principe de la config automatique d'un proxy sur un poste client c'est justement de prendre ses infos dans un fichier de configuration pour les appliquer.

          pourquoi ne pas alors faire :
          - le fichier PAC sur le port 80 (port standard web)
          - le proxy sur le port 8080 (ou 3128 qui est son port habituel)

          le fichier PAC indiquant qu'il faut utiliser la machine 10.0.80.254:8080 comme proxy.

          sinon tu peux aussi faire un proxy squid transparent en redirigeant le port 80 vers le port 3128 sur cette machine (en supposant que la machine soit la passerelle par defaut et le proxy en meme temps)

          • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

            Posté par . Évalué à 2.

            c'est quoi l'obligation d'avoir le fichier PAC servi par un serveur sur le port 8080 ?

            C'est parce que c'est comme ça aujourd'hui... C'est une archi proprio que je migre vers du squid. Pour limiter la boulot coté poste, le plus simple aurait été de reproduire à l'identique.

            pourquoi ne pas alors faire :
            - le fichier PAC sur le port 80 (port standard web)
            - le proxy sur le port 8080 (ou 3128 qui est son port habituel)

            C'est ce que je fais normalement pour le proxy (je n'ai jamais deployé de pac, mais c'est juste un pauvre fichier javascript, rien de bien compliqué) et c'est ce que je vais faire si je ne trouve pas comment reproduire à l'identique.

        • [^] # Commentaire supprimé

          Posté par . Évalué à 3.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

            Posté par . Évalué à 2.

            Je vais regarder ça attentivement demain matin !

            Merci

          • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

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

            J'y avais pensé mais le soucis est que squid en mode proxy ne comprend pas la requete http vers le proxy.pac (sinon la solution aurait été de mettre un simple serveur web sur le port 80, et squid aurait requeté dessus).

            Pour qu'il accepte la requete il faut le passer en reverse proxy mais la il ne permet plus un acces internet.

            Je dirais a priori que l'operation doit être faisable en chainant dans l'autre sens:
            Apache+mod_proxy qui ecoute sur le port 8080 configuré en reverse proxy sur le squid sur le port 3128,
            et une regle pour toutes les URLs differentes de "/proxy.pac" qui renvoie vers le squid.

            Ou juste apache en mode forward proxy d'ailleurs + la regle qui va bien

            • [^] # Re: Pourquoi ne pas mettre apache sur le port 80 ?

              Posté par . Évalué à 3.

              Apache+mod_proxy qui ecoute sur le port 8080 configuré en reverse proxy sur le squid sur le port 3128, et une regle pour toutes les URLs differentes de "/proxy.pac" qui renvoie vers le squid.

              J'avais pensé à ça, mais j'ai peur qu'ensuite la plateforme ne tienne pas la charge.

Suivre le flux des commentaires

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