Tâche #34750
Mis à jour par Laurent Gourvenec il y a plus d'un an
Nous sommes désormais sûr que le problème du test jenkins https://dev-eole.ac-dijon.fr/jenkins/job/2.9.0/job/test-etb1-scribe-joineole-linuxmint-2.9.0-amd64/41/console vient de freshclam qui n'arrive pas mettre à jour ses bases. Ce problème est "aléatoire", la première machine utilisant freshclam arrivera à télécharger ses bases mais les suivantes se verront l'accès refusé par les serveurs de clam. Il faut donc faire en sorte que ce problème ne se reproduise plus.
Proposition 1
-------------
1/ Au démarrage d'un serveur avec clam activé, eole-ci-tests récupère les fichiers de signatures clamav depuis le disque partagé s'il existe.
2/ A la fin du processus, eole-ci-tests vérifie que les fichiers signatures n'ont pas été modifié, si oui les recopier sur le disque partagé.
Proposition 2
-------------
1/ Un freshclam centralisé par EOLE récupère les fichiers signatures clamav dès qu'une nouvelle version des définitions est diffusé et les mets à disposition sur un miroir http.
2/ Le serveur est configuré pour utiliser ce miroir clam local.
Conclusion de Cadoles
---------------------
1/ Les deux approches sont simples à mettre en place.
2/ La proposition 1 ne nécessite pas de modifier les configurations serveurs.
3/ La proposition 1 est un bidouillage.
4/ La proposition 2 teste le fonctionnement de freshclam alors que la proposition 1 ne le permet pas.
En effet, à partir du moment où freshclam arrive une fois à se synchroniser, il n'est plus possible de savoir si celui-ci fonctionne. Donc, à partir du moment où une version est copier du disque partagé, c'est celle-ci qui permettra à clam de fonctionner. Si freshclam n'est plus fonctionnel, clamd, lui, démarrera avec une version obsolète, mais ce ne sera pas possible de le détecter.
Dans la proposition 2 si freshclam ne démarre pas, clamd ne démarrera pas.
5/ La proposition 2 peut être cible utilisateurs. Elle pourra servir de base à la rédaction d'une documentation à destination des utilisateurs pour qu'il puisse l'utiliser s'ils ont également des problèmes de quota (Scribe centralisé par exemple). Cette solution étant testée dans l'environnement de test.
C'est pour cela que Cadoles préconise la proposition 2.
Proposition 1
-------------
1/ Au démarrage d'un serveur avec clam activé, eole-ci-tests récupère les fichiers de signatures clamav depuis le disque partagé s'il existe.
2/ A la fin du processus, eole-ci-tests vérifie que les fichiers signatures n'ont pas été modifié, si oui les recopier sur le disque partagé.
Proposition 2
-------------
1/ Un freshclam centralisé par EOLE récupère les fichiers signatures clamav dès qu'une nouvelle version des définitions est diffusé et les mets à disposition sur un miroir http.
2/ Le serveur est configuré pour utiliser ce miroir clam local.
Conclusion de Cadoles
---------------------
1/ Les deux approches sont simples à mettre en place.
2/ La proposition 1 ne nécessite pas de modifier les configurations serveurs.
3/ La proposition 1 est un bidouillage.
4/ La proposition 2 teste le fonctionnement de freshclam alors que la proposition 1 ne le permet pas.
En effet, à partir du moment où freshclam arrive une fois à se synchroniser, il n'est plus possible de savoir si celui-ci fonctionne. Donc, à partir du moment où une version est copier du disque partagé, c'est celle-ci qui permettra à clam de fonctionner. Si freshclam n'est plus fonctionnel, clamd, lui, démarrera avec une version obsolète, mais ce ne sera pas possible de le détecter.
Dans la proposition 2 si freshclam ne démarre pas, clamd ne démarrera pas.
5/ La proposition 2 peut être cible utilisateurs. Elle pourra servir de base à la rédaction d'une documentation à destination des utilisateurs pour qu'il puisse l'utiliser s'ils ont également des problèmes de quota (Scribe centralisé par exemple). Cette solution étant testée dans l'environnement de test.
C'est pour cela que Cadoles préconise la proposition 2.