Où est passé l'auxiliaire de session de Squid ?
Traquez un auxiliaire Squid manquant dans le paquet installé, le nom de fichier documenté et les options de compilation avant de modifier les réglages d'authentification.
Une configuration copiée depuis un autre serveur mentionne ext_session_acl. Votre paquet Squid ne contient aucun fichier à ce chemin. Il peut s'agir d'une incohérence de paquetage plutôt que d'une session utilisateur cassée.
Squid peut déléguer les décisions d'ACL externes à des programmes auxiliaires, mais nommer un programme dans external_acl_type ne l'installe pas. Le binaire doit exister dans l'environnement déployé.
Comparez trois éléments :
- Le nom documenté de l'auxiliaire pour la version de Squid que vous utilisez.
- Les fichiers réellement fournis par le paquet de votre distribution.
- Le chemin absolu de l'exécutable dans la configuration chargée par Squid.
Debian publie une page de manuel pour ext_session_acl, mais un titre de manuel identique ne prouve pas qu'un binaire existe au chemin copié sur votre serveur. Vérifiez les informations de paquet de cette installation et son répertoire d'auxiliaires.
Si son paquet ne fournit pas l'auxiliaire requis, examinez le découpage de paquets pris en charge par la distribution et les informations de compilation. Le nom d'un sous-répertoire de l'arborescence source ne prouve pas que le binaire produit est présent dans chaque compilation.
Distinguez « fichier absent » de « fichier présent mais qui ne démarre pas ». Le second cas peut concerner son interpréteur, des bibliothèques partagées, des permissions ou le confinement du service. Consultez les messages de démarrage de l'auxiliaire de Squid pour cette panne. Aucun des deux symptômes ne prouve que le mot de passe d'un utilisateur du proxy est faux.
Un auxiliaire provenant d'un ancien serveur sans rapport n'est pas interchangeable simplement parce que son nom de fichier correspond à la configuration.