L'assistant de Squid voit le module. Mais peut-il le lire ?

Avant d'ajouter le compte Squid à un autre groupe, vérifiez cache_effective_group. Dans Squid 5–7, la valeur par défaut utilise les groupes principal et supplémentaires de l'utilisateur effectif. Une substitution explicite fait ignorer à Squid les privilèges des autres groupes, si bien que l'appartenance que vous venez d'ajouter n'atteindra peut-être jamais son assistant.

C'est une façon dont un module Perl peut exister sur le disque sans parvenir à se charger. Distinguez trois causes dans l'erreur réelle du chargeur : la dépendance est absente, elle se trouve hors du chemin de recherche de l'interpréteur, ou le service ne peut pas la lire.

Comparez le module et chaque répertoire parent sous l'identité d'exécution de l'assistant. L'interpréteur a besoin de traverser les répertoires et de lire les fichiers, pas seulement d'un nom de fichier final lisible. Après une mise à jour, la propriété du fournisseur ou les modes par défaut peuvent différer de l'agencement qui fonctionnait auparavant.

Choisissez une attribution de droits étroite, cohérente avec le compte de service visé et le réglage du groupe effectif. Lire une dépendance n'exige pas de rendre toute l'arborescence de l'application inscriptible par le proxy. Recréez les processus concernés via le cycle de vie pris en charge du service après les changements de groupe ; ceux qui existent déjà peuvent conserver leurs anciennes appartenances.

Si les chemins de recherche et les permissions ordinaires concordent, inspectez la vue du système de fichiers du service et les preuves de contrôle d'accès obligatoire. Qu'un shell root charge le module avec succès n'établit aucune de ces conditions pour l'assistant.