Frédéric Bourgeois Rennes

Squid 3.0

Je travaille au débogage du futur Squid 3.0 (tests et reports de bugs), plus particulièrement sur les dysfonctionnements avec le protocole ICAP

Mon relevé de bugs :Squid 3.0

Je suis particulièrement admiratif du travail réalisé par Alex Rousskov qui corrige les bugs plus vite que je ne les remonte, enfin presque ;-) , ce qui augure d'une première version vraiment stable de squid 3.0.
Si vous avez une expérience avec un proxy et un antivirus ICAP sur un réseau important (+ 200 requêtes seconde sur le proxy) je suis intéressé par un retour d'expérience afin de pouvoir procéder à une comparaisons des différents logiciels.

Je vais ajouter ici mes notes, notamment une description des prochaines options ICAP du fichier squid.conf.

Oui, je sais c'est en vrac ...

Voir les commentaires pour plus de détails

Ecrit par FredB le 12/07/2007 @ 10:46

Tous les articles sur ce sujet

---

FredB a écrit le 12/07/2007 @ 11:27

Commandes et options de compilation:

Some versions of GCC (notably 2.95.1 through 2.95.3) have bugs with compiler optimization.These GCC bugs may cause NULL pointer accesses in Squid, resulting in a ``FATAL: Received Segment Violation...dying'' message and a core dump.

% make distclean
% set env CFLAGS='-g -Wall'
% ./configure ...

To check that you did it right, you can search for AC_CFLAGS in src/Makefile:

% grep AC_CFLAGS src/Makefile
AC_CFLAGS = -g -Wall

ulimit -n 32000 -> Ajout aussi de cette ligne dans /etc/init.d/squid

./configure --enable-cache-digests --enable-storeio="aufs,coss,diskd,ufs,null" --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/sbin --sbindir=/usr/sbin --sysconfdir=/etc/squid --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib/squid --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --enable-icap-support --enable-poll --enable-async-io --with-maxfd=32000 --enable-delay-pools --with-large-files --enable-icap-client --disable-dlmalloc --with-pthreads --enable-epoll

make

----------------------------

Mettre à jour 2.6 -> 3.0
cp diskd unlinkd /usr/lib/squid/
cp errors/French/ERR_ESI /usr/lib/squid/errors/French/
cp squid /usr/sbin/

----------------------------

GDB est l'acronyme de Gnu DeBugger. C'est un debugger puissant dont l'interface est totalement en ligne de commande

Pour remonter des informations à la team squid après un crash. Gdb sur le core puis taper la commande where pour afficher le résultat

gdb squid core

(gdb) where

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d1bef1 in raise () from /lib/tls/libc.so.6
#2 0xb7d1d83b in abort () from /lib/tls/libc.so.6
#3 0x08084e31 in xassert (msg=0x815d468 "e->mem_status == NOT_IN_MEMORY", file=0x815d527 "store_swapin.cc", line=47) at debug.cc:569
#4 0x080eab12 in storeSwapInStart (sc=0x365d2bc8) at store_swapin.cc:47
#5 0x080e443f in store_client::startSwapin (this=dwarf2_read_address:
Corrupted DWARF expression. ) at store_client.cc:391
#6 0x080e4676 in storeClientCopy2 (e=0xafee852c, sc=0x365d2bc8) at store_client.cc:332
#7 0x080e4a08 in store_client::copy (this=0x365d2bc8, anEntry=0xafee852c, copyRequest= {flags = {error = 0}, length = 4096, offset = 0, data = 0x30dd6294 ""},
callback_fn=0x807c900 ,
data=0x8fd2a7c) at store_client.cc:265
#8 0x0807b6b2 in clientReplyContext::doGetMoreData (this=0x8fd2a7c) at client_side_reply.cc:1605
#9 0x0807ba29 in clientReplyContext::identifyStoreObject (this=0x8fd2a7c) at client_side_reply.cc:1399
#10 0x0807ce98 in ClientHttpRequest::httpStart (this=0x32a508c0) at client_side_request.cc:917
#11 0x0807d00b in ClientHttpRequest::doCallouts (this=0x32a508c0) at client_side_request.cc:1064

---------------------

Appliquer un patch avant la compilation

Dans le répertoire source de squid

patch -p0 < alex-patch-2 [Entrée]

---------------------

Squid.conf de base (voir les options plus bas)

#############ICAP#######
icap_enable on
icap_service s1 respmod_precache 0 icap://192.x.x.x:1025/av/respmod
icap_class service1 s1
icap_access service1 allow all
icap_preview_enable off
icap_send_client_ip on

icap_service_failure_limit 100
icap_io_timeout 60 seconds
icap_service_revival_delay 20
#############ICAP#######

---------------------

L'option no atime updates, « pas de mise à jour de la date de dernier accès »

A chaque fois qu'on accède à un fichier, la date du dernier accès est modifiée. Dans un système de fichiers dans lequel existent de nombreux fichiers auxquels on accède souvent (c'est le cas pour les serveurs de caches), ces modifications peuvent ralentir le système.
Donner à un fichier l'attribut no atime updates permet d'éviter ce problème. Noter que la même option existe lorsque l'on monte une partition dans l'arborescence globale (mount -o noatime), option que l'on peut inscrire comme ceci dans le fichier /etc/fstab.

/dev/sdb1 /cache1 ext3 defaults,noatime 1 2
/dev/sdc1 /cache2 ext3 defaults,noatime 1 2

ATTENTION ! Appliquer uniquement ceci sur le (les) partition(s) de cache

----------------------------------------------------

# Utiliser squid en mode debug pendant 60 secondes

squid -k debug; sleep 60; squid -k debug

---

FredB a écrit le 12/07/2007 @ 11:43

Options ICAP squid.conf

icap_service_failure_limit 80

Stop le service ICAP si la valeur est atteinte, ce paramètre réduit au minimum le nombre de transactions affectées lors d'une panne (dans notre exemple 80), mais le nombre réel de transactions bloquées peut être plus grand que la limite configurée, car beaucoup de transactions peuvent avoir débutées avant que la limite ait été atteinte et se bloquer alors.
Attention un petit chiffre augmente la probabilité que la totalité du service ICAP soit suspendu juste en raison d'un faible nombre de connexions bloquées.

icap_connect_timeout 40 seconds

Utiliser un petit timeout pour un service ICAP optionnel. Les échecs de connexions devraient être 100% bypassable. Cependant ils augmentent le compteur d'échec du service (icap_service_failure_limit).
Garder cette limite au-dessus de 2 secondes en raison des limitations internes de Squid.
Particulièrement utile dans le cas ou l'AV à atteindre est dans un réseau différent car les TIMEOUT de connexion peuvent être très longs (Pour le vérifier faite un test avec simple telnet sur le port de l'AV éteint) et augmentent d autant le passage en state down du service ICAP

icap_io_timeout 60 seconds

Temps de réponse de l'analyse d une requête HTTP par l'AV, utiliser une grande valeur pour un serveur chargé, une petit valeur terminera les transactions ICAP plus tôt en cas de problème, mais risque de provoquer des fausses alertes en cas de serveur ICAP occupé

icap_service_revival_delay 20

Utiliser ici un petit délai aura comme conséquence l'augmentation du nombre de pages HTTP inspectées par votre serveur ICAP (moins de temps de coupure ICAP), mais également augmente aussi les délais si votre serveur ICAP ne récupère pas dans le temps indiqué après avoir été marqué DOWN

icap_preview_enable off

Ce mécanisme permet au client ICAP de n’envoyer que le début du message à analyser par le serveur ICAP puis, si le serveur envoie un message avec le code d’état :
- 100, alors le client enverra la suite du message
- 204, cela signifie qu’il estime qu’aucune modification n'est nécessaire et donc, le client ne transmettra pas la suite du message

Cette fonctionnalité peut permettre, suivant les cas, une amélioration de performance importante.

Par exemple, dans le cas d'un serveur ICAP proposant un service d'anti-virus, le serveur pourra déclarer comme sain une grande partie des fichiers en inspectant uniquement leurs types et donc, uniquement les premiers octets du fichiers.

Malheureusement je manque d'information concernant les critères d'attribution du code 204, pour cela il me faudrait des informations plus précises des éditeurs AV

---

FredB a écrit le 19/07/2007 @ 15:41

# ICAP OPTIONS
# -----------------------------------------------------------------------------

# TAG: icap_enable on|off
# If you want to enable the ICAP module support, set this to on.
#
#Default:
# icap_enable off

# TAG: icap_connect_timeout
# This parameter specifies how long to wait for the TCP connect to
# the requested ICAP server to complete before giving up and either
# terminating the HTTP transaction or bypassing the failure.
#
# The default for optional services is peer_connect_timeout.
# The default for essential services is connect_timeout.
# If this option is explicitly set, its value applies to all services.
#
#Default:
# none

# TAG: icap_io_timeout time-units
# This parameter specifies how long to wait for an I/O activity on
# an established, active ICAP connection before giving up and
# either terminating the HTTP transaction or bypassing the
# failure.
#
# The default is read_timeout.
#
#Default:
# none

# TAG: icap_service_failure_limit
# The limit specifies the number of failures that Squid tolerates
# when establishing a new TCP connection with an ICAP service. If
# the number of failures exceeds the limit, the ICAP service is
# not used for new ICAP requests until it is time to refresh its
# OPTIONS. The per-service failure counter is reset to zero each
# time Squid fetches new service OPTIONS.
#
# A negative value disables the limit. Without the limit, an ICAP
# service will not be considered down due to connectivity failures
# between ICAP OPTIONS requests.
#
#Default:
# icap_service_failure_limit 10

# TAG: icap_service_revival_delay
# The delay specifies the number of seconds to wait after an ICAP
# OPTIONS request failure before requesting the options again. The
# failed ICAP service is considered "down" until fresh OPTIONS are
# fetched.
#
# The actual delay cannot be smaller than the hardcoded minimum
# delay of 30 seconds.
#
#Default:
# icap_service_revival_delay 180

# TAG: icap_preview_enable on|off
# Set this to 'on' if you want to enable the ICAP preview
# feature in Squid.
#
#Default:
# icap_preview_enable off

# TAG: icap_preview_size
# The default size of preview data to be sent to the ICAP server.
# -1 means no preview. This value might be overwritten on a per server
# basis by OPTIONS requests.
#
#Default:
# icap_preview_size -1

# TAG: icap_default_options_ttl
# The default TTL value for ICAP OPTIONS responses that don't have
# an Options-TTL header.
#
#Default:
# icap_default_options_ttl 60

# TAG: icap_persistent_connections on|off
# Whether or not Squid should use persistent connections to
# an ICAP server.
#
#Default:
# icap_persistent_connections on

# TAG: icap_send_client_ip on|off
# This adds the header "X-Client-IP" to ICAP requests.
#
#Default:
# icap_send_client_ip off

# TAG: icap_send_client_username on|off
# This sends authenticated HTTP client username (if available) to
# the ICAP service. The username value is encoded based on the
# icap_client_username_encode option and is sent using the header
# specified by the icap_client_username_header option.
#
#Default:
# icap_send_client_username off

# TAG: icap_client_username_header
# ICAP request header name to use for send_client_username.
#
#Default:
# icap_client_username_header X-Client-Username

# TAG: icap_client_username_encode on|off
# Whether to base64 encode the authenticated client username.
#
#Default:
# icap_client_username_encode off

# TAG: icap_service
# Defines a single ICAP service
#
# icap_service servicename vectoring_point bypass service_url
#
# vectoring_point = reqmod_precache|reqmod_postcache|respmod_precache|respmod_postcache
# This specifies at which point of request processing the ICAP
# service should be plugged in.
# bypass = 1|0
# If set to 1 and the ICAP server cannot be reached, the request will go
# through without being processed by an ICAP server
# service_url = icap://servername:port/service
#
# Note: reqmod_precache and respmod_postcache is not yet implemented
#
#Example:
#icap_service service_1 reqmod_precache 0 icap://icap1.mydomain.net:1344/reqmod
#icap_service service_2 respmod_precache 0 icap://icap2.mydomain.net:1344/respmod
#
#Default:
# none

# TAG: icap_class
# Defines an ICAP service chain. If there are multiple services per
# vectoring point, they are processed in the specified order.
#
# icap_class classname servicename...
#
#Example:
#icap_class class_1 service_1 service_2
#icap class class_2 service_1 service_3
#
#Default:
# none

# TAG: icap_access
# Redirects a request through an ICAP service class, depending
# on given acls
#
# icap_access classname allow|deny [!]aclname...
#
# The icap_access statements are processed in the order they appear in
# this configuration file. If an access list matches, the processing stops.
# For an "allow" rule, the specified class is used for the request. A "deny"
# rule simply stops processing without using the class. You can also use the
# special classname "None".
#
# For backward compatibility, it is also possible to use services
# directly here.
#Example:
#icap_access class_1 allow all
#
#Default:
# none

---

Fredb a écrit le 02/10/2007 @ 15:36

Fonctionnement du tag ISTAG (en-tête obligatoire dans toute réponse d'un serveur ICAP)

L'utilisateur demande un objet sur Internet il est donc récupéré par le proxy qui l'envoie au serveur ICAP, l'antivirus analyse et retourne l'objet au cache avec un TAG contenant la version de mises à jours des bases AV. Pour finir le proxy retourne l'objet au client.

Ensuite il y a deux situations possibles :

1.L'objet change sur le serveur WEB, le proxy récupère le nouveau fichier et le retourne à l'antivirus ICAP
2.L'objet ne change pas, il pourrait être directement envoyé depuis le cache.

Dans la situation numéro deux imaginons que suite à une mise à jour de la base antiviral sur le serveur ICAP, mise à jour du serveur = nouveau TAG (ITAG), et qu'un utilisateur demande le fichier qui est maintenant stocké DANS le cache.

Si l'ITAG de l'objet est différent de celui du serveur ICAP, le proxy envoie le fichier au serveur ICAP qui l'analyse de nouveau et le retourne avec un ITAG différend

Par contre quand le fichier n'est pas modifié sur le serveur web distant ET si le serveur ICAP a la même MAJ (donc ITAG identique) l'objet est envoyé directement à l'utilisateur depuis le cache.

Exemple : ISTag:KAVICAP -1872007..Date: Wed, 18 Jul 2007 08:53:12 GMT..Server: KAV-ICAP- Sever/5.5..Encapsulated:res-hdr =0, res-body=75

Ce cheminement évite d'avoir un objet infecté par un programme malicieux trop récent pour la base Kav4proxy, qui pourrait ensuite être diffusé pendant des semaines aux utilisateurs, en effet à chaque nouvelle version de la base l'objet serra de nouveau analysé.

---

Ajouter un commentaire

---