Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-09 Par sujet andre_debian
On Sunday 09 June 2013 15:47:42 Bzzz wrote:
> > G-Wan est-il proprio et payant ?

G-WAN est un produit Suisse.

http://korben.info/g-wan-server-http.html  :
"Il pèse 150 KB, utilise 4 à 5 fois moins de RAM et sert 3 à 4 fois plus de 
requêtes 
que lightttpd ou Nginx."

"Le fait que les sources ne soient pas dispo est un choix des développeurs qui 
est beaucoup critiqué. Pour eux, les utilisateurs ont juste besoin que le 
travail 
soit fait et encore d'après eux, cela évite que les vendeurs de logiciel ou de 
solutions 
hardware ne s'approprient leur code (et donc des années de recherche et 
développement)
pour proposer une version modifiée à leur sauce
Même si le produit à l'air alléchant en terme de rapidité, le fait que le code 
ne soit pas 
OpenSource est un sérieux frein en terme de garantie pour les failles ou même 
les
améliorations possibles et futures par une communauté de développeurs."

C'est une sorte de "freeware" qui ne l'empêche pas d'être très performant.

> Si tu *veux vraiment* apprendre des choses, il va falloir
> te retirer les doigts et chercher par toi-même; à commencer
> par la définition de 'freeware' :

Humm, vite trouvé .

> "retirer les doigts et chercher par moi même",
c'est plutôt comment intégrer (coupler) Postfix, Mailman 
avec le serveur Web G-WAN.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201306091928.32117.andre_deb...@numericable.fr



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-09 Par sujet Bzzz
On Sun, 9 Jun 2013 15:10:27 +0200
andre_deb...@numericable.fr wrote:

> G-WAN v1.0.4 – Discontinued › Windows
> "Linux was found to be much faster. After years of development this
> gap is surely larger now because Unix leaves more room for developers
> to innovate." La version téléchargeable ne semble être que pour
> GNU/Linux 32 et 64 bits ...

Normal, vu le commentaire…
 
> G-Wan est-il proprio et payant ?
> Je serai intéressé de le tester mais si je tombe sur ce commentaire,
> je préfère le savoir avant : "you must pay before starting B-Wan ..."

Si tu *veux vraiment* apprendre des choses, il va falloir
te retirer les doigts et chercher par toi-même; à commencer
par la définition de 'freeware'.

> Elles ne suivent pas trop les évolutions.

Suivre ou pas l'évolution est conditionné à différents points:

1- évoluer pour évoluer est un tropisme introduit par m$; à partir
   du moment où l'évolution en question n'amène pas de patch(es)
   de sécurité ni de fonctionnalité(s) supplémentaire(s) absolument
   nécessaires à l'exploitation, pourquoi évoluer? (et risquer de
   se retrouver avec une conf à refaire intégralement parce que les
   primitives et la syntaxe de la conf a changée).

2- changer une pièce maîtresse d'un dispositif qui donne satisfaction
   est l'anti-thèse de 'système stable'. Règle première de
   l'informatique professionnelle: 'quand satisafaisante est ta
   configuration, n'y toucher plus tu ne feras'

3- les sites en question doivent la plupart du temps assurer un
   service à cinq 9; une migration complète peut avoir (et selon
   Murphy, aura) des retentissements sur le service proposé 
   (ralentissements dans le meilleur des cas, plantage total dans
   le moins bon) - Serais-tu prêt à prendre une telle responsabilité
   vis-à-vis des utilisateurs comme de ta direction?

4- comme les constructeurs de voiture japonais l'ont compris depuis
   longtemps (pas les français, et en tout état de cause absolument
   pas renault), la meilleur façon de faire une nouvelle voiture
   c'est de réutiliser un maximum de pièces qui ont fait leurs preuves;
   dans le but évident de minorer le plus possible les points de panne.
   Dans l'informatique, c'est pareil: quand on connaît un pgm ou une
   application sur le bout des doigts, on ne change pas pour quelque
   chose d'autre qu'on ne maîtrise pas à 100%. 
   Pour pouvoir changer, il y a un temps non négligeable d'apprentissage
   et de tests qui est incompressible (enfin, quand on est sérieux).

5- un changement, même pour obtenir des perfs extraordinaires, doit
   aussi s'appuyer sur un support certain; hors; même si la communauté
   de nginx augmente régulièrement et sensiblement, elle est
   actuellement très loin de celle d'apache (à relativiser: bcp
   d'"experts" apache sont souvent des burnes une fois sortis d'un
   contexte particulier).

6- Obi Wan Kenobee.

> Et SkySQL ? : est-il du niveau de PostgreSQL ?

C'est quoi ça, ça existe?

La page de garde indique de l'hébergement spécialisé et de la
compétence mysql, une autre page indique une fusion des devs
avec le team de mariadb, qui n'est autre qu'un fork de mysql.
Peut-être dans qq années finiront-ils par sortir qq chose qui
tienne la route…

-- 
@guillaume: Hier j'ai appelé mon réseau wifi "Hack me if you can".
Aujourd'hui il s'appelle "Challenge accepted"

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130609154742.266ae49f@anubis.defcon1



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-09 Par sujet andre_debian
On Saturday 08 June 2013 23:18:57 Bzzz wrote:

> andre_deb...@numericable.fr wrote:
> > C'est bien "G-Wan" qui arrive largement en tête, mais proprio ... :

> Vi, MAIS quand on a un très gros site avec une énorme
> fréquentation, la différence avec l'open-source est
> tellement gigantesque (coeff. 4 quand même) qu'entre
> rajouter des serveurs et utiliser G-Wan le choix
> est vite vu :

Merci pour ce long et intéressant commentaire.

http://gwan.com/  :
G-WAN v1.0.4 – Discontinued.
› Windows
"Linux was found to be much faster. After years of development this gap is 
surely 
 larger now because Unix leaves more room for developers to innovate."
La version téléchargeable ne semble être que pour GNU/Linux 32 et 64 bits ...

G-Wan est-il proprio et payant ?
Je serai intéressé de le tester mais si je tombe sur ce commentaire,
je préfère le savoir avant : "you must pay before starting B-Wan ..."

> > "Nginx" est quand même bien placé et Libre :

> Il est non seulement très bien placé, mais en plus il
> ne bouffe pas la RAM et ses plugins permettent toutes
> sortes de fantaisies; par ailleurs, il intègre nativement
> la notion de cache à plusieurs étages, d'où l'inutilité
> d'un couplage avec varnish (pour gagner 5 à 10% de traffic,
> ça ne vaut pas le coup de surcharger les confs) :

Combien d'entreprises utilisent "varnish" pour améliorer les performances
de leur serveur Web (=> haute disponibilité). 
Ce n'est pas du tout le meilleir outil.

> > Côté Apache, il y a plusieurs Modules multi-processus "MPM" :
> > "Prefork" , "Worker"  et "Event".
> > Lequel choisir pour avoir un serveur à forte disponibilité ?
>
> Aucun, l'architecture et les perfs d'apache sont maintenant
> dépassées, ce qui explique sans doute la très forte croissance
> de nginx qui est de plus en plus utilisé pour le remplacer
> complètement.
>
> Là où apache va ramer et surtout bouffer de la RAM, la
> consommation de nginx va être ridicule en comparaison
> pour des perfs supérieures.
>
> Après, tout dépend de ce qu'on entend par "forte disponibilité",
> est-on dans le HA (High Availibility) ou dans des centaines ou
> des milliers de connexions simultanées ? :

Ici aussi, bien des entreprises, dont de gros hébergeurs ou data centers, 
font confiance à ces modules d'Apache "prefork" ou "worker" pour améliorer 
les connexions simultanées de leurs serveurs Web.
Elles ne suivent pas trop les évolutions.

> Le svr utilise-t-il une DB, et laquelle? (prévoir un pool de
> connexion si c'est le cas; faire faire une révision de la
> structure de la DB et de ses éventuelles procédures stockées
> par un pro qui connaît le moteur de DB par cœur, etc, etc).
>
> Tout en sachant que mysql est un tas de merde qui ne tient
> pas la route quand veut une DB ACID et surtout conforme aux
> standards SQL (un exemple parmi tant d'autres: ne pas tronquer
> en silence une string trop longue au lieu d'émettre une erreur
> fatale).
> Il existe un site allemand très bien fait (en anglais) sur les
> erreurs de conception/fonctionnement de mysql (pas bookmarqué).
>
> Postgresql, qui lorsqu'on lui indique des parms de procédures
> sous la forme "$1,$2,$3,…" sécurise automatiquement les
> variables contre l'injection SQL et est maintenant comparé
> à oracle (et fourni ce qu'il faut pour transformer directement
> du code oracle en code plPG/sql).
>
> Et on peut continuer longtemps, notamment avec les sites tellement
> mal écrits qu'ils laissent le controle de la DB à PHP, alors
> qu'il ne devrait se contenter que d'appeler des procs stockées…
> Le matériel, le nosql (qui ne devrait servir qu'à des cas bien
> particuliers)…
> Le langage PHP, quand LUA est des tas de fois plus rapide et Erlang
> directement distribuable sur de nouveaux nœuds (scalability) en
> quelques secondes… :

Tu n'es pas le premier qui dit cela :
Apache, MySQL, PHP ... ne sont pas ou plus au top.

Et SkySQL ? : est-il du niveau de PostgreSQL ?

andré

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201306091510.27826.andre_deb...@numericable.fr



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-08 Par sujet Bzzz
On Sat, 8 Jun 2013 22:33:38 +0200
andre_deb...@numericable.fr wrote:

> C'est bien "G-Wan" qui arrive largement en tête, mais proprio ...

Vi, MAIS quand on a un très gros site avec une énorme
fréquentation, la différence avec l'open-source est 
tellement gigantesque (coeff. 4 quand même) qu'entre 
rajouter des serveurs et utiliser G-Wan le choix
est vite vu.

> "Nginx" est quand même bien placé et Libre.

Il est non seulement très bien placé, mais en plus il
ne bouffe pas la RAM et ses plugins permettent toutes
sortes de fantaisies; par ailleurs, il intègre nativement
la notion de cache à plusieurs étages, d'où l'inutilité 
d'un couplage avec varnish (pour gagner 5 à 10% de traffic,
ça ne vaut pas le coup de surcharger les confs).

> J'ose à peine poser la question vu le dernier (long) fil sur Nginx :
> est-il un serveur Web à part entière ou un complément à Apache ?

Il _peut_ être (et est) utilisé comme reverse-proxy, ce 
qu'il fait très bien, mais c'est d'abord un serveur http
à part entière. Et il n'a pas connu plus de failles qu'apache
(je dirais même moins).

La différence de perfs vient de la façon de traiter les
requêtes; d° G-Wan, sauf qu'avec lui on ne sait pas comment
il fait exactement.

D'après le laïus sur la non dispo du source, il semble que
le C avec lequel il a été écrit ait été plus vu comme de 
l'assembleur que du pur C; donc le type qui le développe
a du passer un monceau de temps à 'gader quel code C 
produisait des routines en assembleur les plus efficaces
possibles + une façon de traiter les requêtes différente.

> Côté Apache, il y a plusieurs Modules multi-processus "MPM" : 
> "Prefork" , "Worker"  et "Event".
> Lequel choisir pour avoir un serveur à forte disponibilité ?

Aucun, l'architecture et les perfs d'apache sont maintenant
dépassées, ce qui explique sans doute la très forte croissance
de nginx qui est de plus en plus utilisé pour le remplacer
complètement.

Là où apache va ramer et surtout bouffer de la RAM, la 
consommation de nginx va être ridicule en comparaison
pour des perfs supérieures.

Après, tout dépend de ce qu'on entend par "forte disponibilité",
est-on dans le HA (High Availibility) ou dans des centaines ou
des milliers de connexions simultanées?
Le svr utilise-t-il une DB, et laquelle? (prévoir un pool de
connexion si c'est le cas; faire faire une révision de la 
structure de la DB et de ses éventuelles procédures stockées
par un pro qui connaît le moteur de DB par cœur, etc, etc).

Tout en sachant que mysql est un tas de merde qui ne tient
pas la route quand veut une DB ACID et surtout conforme aux
standards SQL (un exemple parmi tant d'autres: ne pas tronquer
en silence une string trop longue au lieu d'émettre une erreur
fatale).
Il existe un site allemand très bien fait (en anglais) sur les
erreurs de conception/fonctionnement de mysql (pas bookmarqué).

Postgresql, qui lorsqu'on lui indique des parms de procédures
sous la forme "$1,$2,$3,…" sécurise automatiquement les
variables contre l'injection SQL et est maintenant comparé
à oracle (et fourni ce qu'il faut pour transformer directement
du code oracle en code plPG/sql).

Et on peut continuer longtemps, notamment avec les sites tellement
mal écrits qu'ils laissent le controle de la DB à PHP, alors 
qu'il ne devrait se contenter que d'appeler des procs stockées…
Le matériel, le nosql (qui ne devrait servir qu'à des cas bien
particuliers)…
Le langage PHP, quand LUA est des tas de fois plus rapide et Erlang
directement distribuable sur de nouveaux nœuds (scalability) en
quelques secondes…

-- 
Naptat : Si je devais ne plus exister dans les 5 secondes, tu me dirais quoi ?
Letz : 5
Letz : 4
Letz : 3
Letz : ...
Naptat : Connard...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130608231857.1f4a7074@anubis.defcon1



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-08 Par sujet andre_debian
On Saturday 08 June 2013 17:54:51 Bzzz wrote:
> andre_deb...@numericable.fr wrote:
> > "apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
> > (hébergé) avec d'autres services (MySQL, Postfix, Mailman etc ...)
> > en termes d'accélération, de gain ...

> Au vu de l'intro de la doc d'apt-cacher-ng, nan.

> > Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
> Pas que pour Apache, pour la plupart des svrs http.

> Il existe aussi php-apc, qui marche uniquement en RAM, et qui
> n'est pômal du tout pour un site petit à moyen.
> Ce comparatif n'est pas trop mal fait (on n'ergote pas sur la
> méthodologie SVP, puisque chacun considère que la sienne est
> la meilleure!):
> http://francois.aichelbaum.com/comparatif-caching-nginxvarnishsquidapache/
> et si varnish cohabite mal avec nginx, nginx tout seul se débrouille
> pratiquement aussi bien que les confs "accélérées" avec moins
> de besoins en RAM et de soucis de conf…

> > Quelle est la différence entre "apt-cacher-ng" et "varnish" ? :
> L'un est un proxy spécifiquement orienté vers les _packages_ Debian,
> l'autre est un proxy exclusivement HTTP (et d'ailleurs, plus un cache
> qu'un proxy, si mes souvenirs de ses docs sont bons).

> Ceci est également intéressant (NB: le test ne porte QUE sur du statique):
> http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/
> comme quoi les proxies et les caches ne sont pas forcément la meilleure 
> solution pour les grosses
> charges.
> Malheureusement, G-Wan est un Freeware non open-source.
> Celui-ci explique pourquoi il ne s'emm... même pas avec varnish:
> http://rtcamp.com/tutorials/why-we-never-use-varnish-with-nginx/
> normal, en dehors de G-Wan, et vu que Cherokee semble mortibus,
> nginx est le plus performant; de plus il est aussi excellent en
> temps que reverse-proxy & load balancer.

Merci pour les explications et liens instructifs :
très bonne synthèse des "accélérateurs" de serveurs Web.
C'est bien "G-Wan" qui arrive largement en tête, mais proprio ...
"Nginx" est quand même bien placé et Libre.

J'ose à peine poser la question vu le dernier (long) fil sur Nginx :
est-il un serveur Web à part entière ou un complément à Apache ?

Côté Apache, il y a plusieurs Modules multi-processus "MPM" : 
"Prefork" , "Worker"  et "Event".
Lequel choisir pour avoir un serveur à forte disponibilité ?

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201306082233.38340.andre_deb...@numericable.fr



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-08 Par sujet Bzzz
On Sat, 8 Jun 2013 17:35:22 +0200
andre_deb...@numericable.fr wrote:

Ceci est également intéressant (NB: le test ne porte QUE
sur du statique):
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/
comme quoi les proxies et les caches ne sont pas
forcément la meilleure solution pour les grosses
charges.
Malheureusement, G-Wan est un Freeware non open-source.

Celui-ci explique pourquoi il ne s'emm... même pas
avec varnish:
http://rtcamp.com/tutorials/why-we-never-use-varnish-with-nginx/
normal, en dehors de G-Wan, et vu que Cherokee semble mortibus,
nginx est le plus performant; de plus il est aussi excellent en
temps que reverse-proxy & load balancer.

-- 
Pangwai : alors sur yahoo, c'est de très mauvais goût, l'affichage
  aléatoire des niouz
Pangwai : "un père soupçonné d'avoir tué son fils de trois ans en
  le mettant au lave linge"
Pangwai : suivi de
Pangwai : "que mettre au micro-ondes ?"

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130608181301.4ea385cc@anubis.defcon1



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-08 Par sujet Bzzz
On Sat, 8 Jun 2013 17:35:22 +0200
andre_deb...@numericable.fr wrote:

> "apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
> (hébergé) avec d'autres services (MySQL, Postfix, Mailman etc ...)
> en termes d'accélération, de gain ...

Au vu de l'intro de la doc d'apt-cacher-ng, nan.

> Pour les serveurs Web sous Apache, il y a l'outil "varnish" :

Pas que pour Apache, pour la plupart des svrs http.

Il existe aussi php-apc, qui marche uniquement en RAM, et qui
n'est pômal du tout pour un site petit à moyen.

Ce comparatif n'est pas trop mal fait (on n'ergote pas sur la
méthodologie SVP, puisque chacun considère que la sienne est 
la meilleure!):
http://francois.aichelbaum.com/comparatif-caching-nginxvarnishsquidapache/
et si varnish cohabite mal avec nginx, nginx tout seul se débrouille
pratiquement aussi bien que les confs "accélérées" avec moins
de besoins en RAM et de soucis de conf…

> 
> Quelle est la différence entre "apt-cacher-ng" et "varnish" ?

L'un est un proxy spécifiquement orienté vers les _packages_ Debian,
l'autre est un proxy exclusivement HTTP (et d'ailleurs, plus un cache
qu'un proxy, si mes souvenirs de ses docs sont bons).

-- 
 J'ai le bras dans le plâtre ...
 Comment t'as fait ? Tu sors jamais de ta chambre ?
 ...
 Je suis tombé de ma chaise ...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130608175451.54b39933@anubis.defcon1



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-08 Par sujet Erwan David

Le 08/06/2013 17:35, andre_deb...@numericable.fr a écrit :

On Friday 07 June 2013 21:13:57 Christophe wrote:

Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
Une simple config de base , et préciser l'adresse du proxy dans les
machines clientes, ça fait des miracles .

Ensuite tu peux définir des chemins sur le proxy pour attaquer des
dépots externes en fonction des besoins , toujours en conservant la
fonction de cache , et donc installer et mettre à jour les machines à la
vitesse du réseau local ;) .  @+ Christophe.

Bonjour,

"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web (hébergé)
avec d'autres services (MySQL, Postfix, Mailman etc ...)
en termes d'accélération, de gain ...

Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
reverse-proxy HTTP "accélérateur" libre (licence BSD) permettant de soulager 
les serveurs web.
Lien :
www.unixgarden.com/index.php/gnu-linux-magazine/varnish-un-proxy-qui-vous-veut-du-bien

Quelle est la différence entre "apt-cacher-ng" et "varnish" ?

Merci.

André



Ça n'a strictement rien à voir.

varnish est un reverse proxy qui (en gros) va réorienter des requêtes 
web sur différents serveurs, il est du côté des serveurs web


apt-cacher-ng ets un proxy côté client spécialisé pour apt. Deux tâches 
qui n'ont rien à voir


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/51b35335.80...@rail.eu.org



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-08 Par sujet andre_debian
On Friday 07 June 2013 21:13:57 Christophe wrote:
> Je confirme, qu'apt-cacher-ng est bigrement efficace.
> Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
> cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
> Une simple config de base , et préciser l'adresse du proxy dans les
> machines clientes, ça fait des miracles .
>
> Ensuite tu peux définir des chemins sur le proxy pour attaquer des
> dépots externes en fonction des besoins , toujours en conservant la
> fonction de cache , et donc installer et mettre à jour les machines à la
> vitesse du réseau local ;) .  @+ Christophe.

Bonjour,

"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web (hébergé) 
avec d'autres services (MySQL, Postfix, Mailman etc ...)
en termes d'accélération, de gain ...

Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
reverse-proxy HTTP "accélérateur" libre (licence BSD) permettant de soulager 
les serveurs web.
Lien :
www.unixgarden.com/index.php/gnu-linux-magazine/varnish-un-proxy-qui-vous-veut-du-bien

Quelle est la différence entre "apt-cacher-ng" et "varnish" ?

Merci.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201306081735.22565.andre_deb...@numericable.fr



Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-07 Par sujet Christophe

Olivier a écrit :


> B. Quels outils utiliser (j'imagine 2 outils spécialisés : un
pour wget
> (Squid ?) et un pour apt (lequel ?) ?

Pour wget, en effet, un proxy généraliste devrait faire l'affaire.
Pour APT, il
y en a plusieurs, je n'en ai jamais utilisé aucun :
approx - serveur mandataire et cache pour les fichiers
d'archive Debian
apt-cacher - proxy cache pour les paquets Debian et les
fichiers source
apt-cacher-ng - serveur mandataire de cache pour les dépôts
logiciel


Ce dernier a l'air intéressant ...



Hello,

Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon 
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...


Une simple config de base , et préciser l'adresse du proxy dans les 
machines clientes, ça fait des miracles .


Ensuite tu peux définir des chemins sur le proxy pour attaquer des 
dépots externes en fonction des besoins , toujours en conservant la 
fonction de cache , et donc installer et mettre à jour les machines à la 
vitesse du réseau local ;) .


@+
Christophe.



Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-requ...@lists.debian.org

En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Archive:
http://lists.debian.org/20130607102431.gj13...@sebian.nob900.homeip.net






Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-07 Par sujet Olivier
Le 7 juin 2013 12:24, Sébastien NOBILI  a écrit :

> Le vendredi 07 juin 2013 à 11:48, Olivier a écrit :
> > Bonjour,
>
> Bonjour,
>
> > Les scripts s'exécutent sur des machines installées dans un environnement
> > de développement. Une fois que ces machines ont correctement testées,
> elles
> > sont ensuite déplacées dans un environnement de production, avec le
> minimum
> > de modifications dans leur configuration.
> >
> > Je m'interroge s'il est possible/préférable :
> > 1. soit de modifier l'environnement de développement (proxy transparent
> ?)
> > de telle sorte que les machines cibles ne soient pas modifiées quand
> elles
> > passent dans l'environnement de production,
> > 2. soit d'accepter de modifier la configuration d'une machine quand elle
> > passe en production avec le bénéfice de simplifier la configuration de
> > l'environnement de développement car les machines qu'il servira
> coopéreront
> > avec lui pour atteindre l'objectif fixé.
> >
> > Mes questions sont:
> > A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt pour
> la
> > 2) ?
>
> Pourquoi cette préférence pour la 2 ? Pour éviter le passage par un proxy
> sur
> une machine de prod ? Si c'est ça, personnellement ça ne me dérangerait
> pas,
> d'autant plus qu'une fois en prod, la machine ne devrait plus (ou du moins
> beaucoup moins qu'avant) solliciter le proxy…
>

J'ai l'impression que s'imposer de ne pas modifier la configuration sur la
machine cible lors de son déplacement en prod (option 1) est très difficile.
À la réflexion, ça me parait assez naturel de modifier les paramètres des
proxy sur une machine qui change d'environnement.


>
> > B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
> > (Squid ?) et un pour apt (lequel ?) ?
>
> Pour wget, en effet, un proxy généraliste devrait faire l'affaire. Pour
> APT, il
> y en a plusieurs, je n'en ai jamais utilisé aucun :
> approx - serveur mandataire et cache pour les fichiers d'archive Debian
> apt-cacher - proxy cache pour les paquets Debian et les fichiers source
> apt-cacher-ng - serveur mandataire de cache pour les dépôts logiciel
>

Ce dernier a l'air intéressant ...


>
> Seb
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.org/fr/FrenchLists
>
> Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
> vers debian-user-french-requ...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20130607102431.gj13...@sebian.nob900.homeip.net
>
>


Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

2013-06-07 Par sujet Sébastien NOBILI
Le vendredi 07 juin 2013 à 11:48, Olivier a écrit :
> Bonjour,

Bonjour,

> Les scripts s'exécutent sur des machines installées dans un environnement
> de développement. Une fois que ces machines ont correctement testées, elles
> sont ensuite déplacées dans un environnement de production, avec le minimum
> de modifications dans leur configuration.
> 
> Je m'interroge s'il est possible/préférable :
> 1. soit de modifier l'environnement de développement (proxy transparent ?)
> de telle sorte que les machines cibles ne soient pas modifiées quand elles
> passent dans l'environnement de production,
> 2. soit d'accepter de modifier la configuration d'une machine quand elle
> passe en production avec le bénéfice de simplifier la configuration de
> l'environnement de développement car les machines qu'il servira coopéreront
> avec lui pour atteindre l'objectif fixé.
> 
> Mes questions sont:
> A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt pour la
> 2) ?

Pourquoi cette préférence pour la 2 ? Pour éviter le passage par un proxy sur
une machine de prod ? Si c'est ça, personnellement ça ne me dérangerait pas,
d'autant plus qu'une fois en prod, la machine ne devrait plus (ou du moins
beaucoup moins qu'avant) solliciter le proxy…

> B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
> (Squid ?) et un pour apt (lequel ?) ?

Pour wget, en effet, un proxy généraliste devrait faire l'affaire. Pour APT, il
y en a plusieurs, je n'en ai jamais utilisé aucun :
approx - serveur mandataire et cache pour les fichiers d'archive Debian
apt-cacher - proxy cache pour les paquets Debian et les fichiers source
apt-cacher-ng - serveur mandataire de cache pour les dépôts logiciel

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607102431.gj13...@sebian.nob900.homeip.net