déconnection orange avec squidGuard

[zeltron]

Depuis que j'ai installé l'add-on squidGuard de Franck78, mon serveur sur orange n'est plus accessible au bout d'un jour (après un cron de squidGuard ?) pourtant rien dans /var/log/squidGuard/log/squidGuard.log indique une erreur.

d'après les logs les mises à jours se font bien.

Pour rétablir orange quand il n'est plus accessible je dois relancer squidGuard à partir du Gui sans toucher au proxy ni à rien d'autre.

Ceci m'amène à dire que c'est bien l'installation de squidGuard la cause.

Malgrés un reboot de l'ipcop le problème est apparu le jour suivant

Quelqu'un dans une config similaire (red+green+orange+blue sur Ipcop 1.46 + Addon SquidGuard de Franck78 1.30 RC4) a t'il rencontré ce genre de problème ?

Franck78, une idée où aller chercher ?

[Franck78]

Salut,


Faudrait un peu préciser là....

Un serveur de quoi n'est plus accessible à partir d'ou/quoi et quel est le message d'erreur eventuel ou le symptome exact !

Quand une mise à jour de la blacklist est vraiment dispo, il y a arret de squid et redémarrage de celui-ci. Mais sans info précises de ta pars, rien à faire...


Bye

[zeltron]

ok désolé bon c'est un serveur web sur orange une clarkconnect 3.1 qui n'est plus accessible au bout de quelques heures depuis green (depuis l'extérieur, donc depuis red je n'ai pas pu vérifier, mais au prochain "plantage" ca sera fait.), lorsqu'on tente d'y accéder on à le droit à la page d'ipcop comme si aucun serveur n'était présent sur orange alors que bien évidement le serveur est online et opérationnel.

Le simple fait d'aller dans le gui de squidGuard et de cliquer sur "lance / Relance SquidGuard" le serveur redevient instantanément accessible depuis green (là encore je vérifierais depuis red au prochain "plantage").

Sinon la mise à jour n'à rien à voir là dedans, le "plantage" arrive au bout de quelques heures je pense au bout de 6 heures environ à moins qu'il y ait un facteur extérieur qui m'a échappé. J'ai eu le plantage ce soir avant que le cron se lance (programmé pour 4 heures du matin).

Je suis prêt à explorer tout les logs et éplucher tous les fichiers si tu as une piste pour me dire là où je dois aller...

[Franck78]

1)
Il n'y a pas de page 'standart' ipcop telle que tu dis. Il y a des pages d'erreur du proxy ou du serveur web ou de ton browser ou la page d'interdiction quand squidguard 'redirige' ....
Si tu restes toujours aussi vague, on ne pourra rien pour toi.

2)
Au prochain blocage, le fait de relancer squidguard relance avant squid.
Donc va plutôt sous la console linux, lance tcpdump sur ORANGE, essaie d'atteindre ton serveur et rend compte du log.
Regarde le log de squid (/var/log/squid/...)
Et termine par un
#>restartsquid

[zeltron]

Il a fallu plus de temps pour que ca plante...

bon voilà ce que contenait error.log de squid:

2005-08-15 20:30:30 [6598] recalculating alarm in 30 seconds
2005-08-15 20:31:00 [6595] recalculating alarm in 10740 seconds
2005-08-15 20:31:00 [6596] recalculating alarm in 10740 seconds
2005-08-15 20:31:00 [6597] recalculating alarm in 10740 seconds
2005-08-15 20:31:00 [6598] recalculating alarm in 10740 seconds
2005/08/15 22:06:38| storeAufsOpenDone: (2) No such file or directory <-le problème est apparu ici
2005/08/15 22:06:38| /var/log/cache/00/00/000000CF
2005/08/15 22:07:43| storeAufsOpenDone: (2) No such file or directory
2005/08/15 22:07:43| /var/log/cache/00/01/00000171
2005/08/15 22:17:29| WARNING: All redirector processes are busy.
2005/08/15 22:17:29| WARNING: up to 5 pending requests queued

et le acess.log de squid:

1124139099.670 105 192.168.0.100 TCP_MISS/304 171 GET http://forums.fr.ixus.net/images/ranks/amiral.gif - DIRECT/195.140.140.28 -
1124139099.697 105 192.168.0.100 TCP_MISS/304 171 GET http://forums.fr.ixus.net/images/avatar ... rs/047.gif - DIRECT/195.140.140.28 -
1124139099.724 106 192.168.0.100 TCP_MISS/304 171 GET http://forums.fr.ixus.net/templates/sub ... on_www.gif - DIRECT/195.140.140.28 -

ici je me balade tranquillement sur ixus de green mais dès que je veux appeler mon site sur orange :

1124140698.149 601 192.168.0.100 TCP_MISS/503 1384 GET http://www.mesphotos.ath.cx/ - NONE/- text/html
1124140698.479 330 192.168.0.100 TCP_MISS/503 1384 GET http://www.mesphotos.ath.cx/ - NONE/- text/html

mon orange est sur eth2 pour le tcpdump j'ai fait tcpdump -i eth2 -v > dump.txt voici le contenu du fichier dump.txt au moment ou je fait un accès sur mon site web (192.168.1.2 c'est mon serveur Web, 192.168.1.1 c'est l'adresse d'orange) :

23:32:38.307488 IP (tos 0x0, ttl 64, id 7410, offset 0, flags [DF], length: 28) 192.168.1.2 > 192.168.1.1: icmp 8: echo request seq 7411
23:32:38.307509 IP (tos 0x0, ttl 64, id 34957, offset 0, flags [none], length: 28) 192.168.1.1 > 192.168.1.2: icmp 8: echo reply seq 7411

j'ai essayé en ligne de commande:
squid -k kill et squid -k shutdown puis squid rien à faire (faut dire je n'ai jamais bidouiller squid)
Je clique sur enregistrer dans le serveur mandataire du gui ce arrete squidGuard et hop ca refonctionne
je relance SquidGuard du gui : ca fonctionne toujours

Je t'épargne les logs comme quoi ca fonctionne... En revanche si tu veux les logs de squidGuard ou autre au moment ou j'ai relancé squidGuard fais-le moi savoir...

j'ai ce petit problème aussi qui apparait dans le log de squidGuard:
2005-08-11 09:01:06 [8644] (squidGuard): can't write to logfile /var/log/squidGuard/squidGuard.log
pourtant il semble bien archiver les anciens log dans des tarballs...

Effectivement le problème semble venir du proxy, je te confirme (que c'est l'installation de squidguard qui génère ce problème: j'ai fait de nombreux tests avant et après l'installation de squidGuard)

Voilà !!! j'espère que j'ai été suffisement exaustif quand à la page standard qui s'affiche quand orange plante je voulais parler de la page blanche qu'affiche le navigateur (type 404) mais là on voit la page d'erreur que renvoit le proxy de l'ipcop :

[Franck78]

Salut,

Pas évident ce problème. On dirait en savant mix de problèmes indépendants.

-D'abord squid et l'erreur avec son gestionnaire de cache (le store):

problème disque, cache vérolé ? : vide le cache squid et règle le tout petit petit avec taille du cache. Si il y a un pb avec ça, il sera 'contourné'. Tu peux essayer de trouver aussi dans le log ipcop une trace de problème d'écriture disque.


-2005/08/15 22:17:29| WARNING: All redirector processes are busy.

cela indique que les processus squidguard sont 'bloqués'. Leur seule fonction étant de parcourir les bases de données à la recherche de l'URL, je dirais qu'il plantent la dessus car
1)bases corrompues (-> pb lecture disque)
2)bases non compilées (-> super lent à parcourir et blocage divers de ce fait)= install avec la base _X_cul_ complète et pas la patience d'attendre.



2005-08-11 09:01:06 [8644] (squidGuard): can't write to logfile /var/log/squidGuard/squidGuard.log
celui je l'ai aussi sur mon 1.4.7 tout neuf. Pas génant comme tu dis, mais je vais voir pourquoi. Pour corriger, tu lui passe un coup de "chown squid:squid squidGuard.log"
Cela doit provenir de la mise à jour des blacklist 'sous cron/root'.

Dans le fichier /usr/local/bin/updateblacklists.pl:

Code: Tout sélectionner

    #Restore correct owner/perms
    chown squid:nobody /var/log/squidGuard/squidGuard.log       <=ajout
    chown -R squid:nobody \$f
    chmod -R 640 \$f
    chmod    150 \$f
    chmod    110 \$f/*
    #This one writable!
    chmod    660 \$f/{local,urls}{white,black}
    #This one is readable


Tu peux aussi réduire à deux le nombre de redirecteurs. Ca réduira les logs inutiles et fera remonter plus vite le pb si il faut attendre (et c'est certain) qu'ils soient tous bloqués !


Bye