Dov'è finito l'ausiliario di sessione di Squid?

Una configurazione copiata da un altro server menziona ext_session_acl. Il tuo pacchetto Squid non ha alcun file su quel percorso. Può essere un disallineamento di pacchettizzazione e non una sessione utente rotta.

Squid può delegare le decisioni ACL esterne a programmi ausiliari, ma nominare un programma in external_acl_type non lo installa. Il binario deve esistere nell'ambiente distribuito.

Confronta tre cose:

• Il nome documentato dell'ausiliario per la versione di Squid che usi.
• I file che il pacchetto della tua distribuzione fornisce davvero.
• Il percorso assoluto dell'eseguibile nella configurazione caricata da Squid.

Debian pubblica un manuale per ext_session_acl, ma un titolo di manuale corrispondente non prova che esista un binario sul percorso copiato nel tuo server. Controlla le informazioni di pacchetto di quell'installazione e la directory degli ausiliari.

Se il suo pacchetto non fornisce l'ausiliario richiesto, esamina la suddivisione dei pacchetti supportata dalla distribuzione e le informazioni di compilazione. Il nome di una sottodirectory nell'albero dei sorgenti non prova che il binario risultante sia presente in ogni compilazione.

Tieni distinto «file assente» da «file presente ma che non si avvia». Il secondo caso può coinvolgere l'interprete, le librerie condivise, i permessi o il confinamento del servizio. Per quel guasto consulta i messaggi di avvio dell'ausiliario di Squid. Nessuno dei due sintomi prova che la password di un utente del proxy sia sbagliata.

Un ausiliario proveniente da un vecchio server non correlato non è intercambiabile solo perché il suo nome file corrisponde alla configurazione.