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