Gdzie zniknął pomocnik sesji Squida?
Prześledź brakującego pomocnika Squida w zainstalowanym pakiecie, udokumentowanej nazwie pliku i opcjach kompilacji, zanim zmienisz ustawienia uwierzytelniania.
Konfiguracja skopiowana z innego serwera wymienia ext_session_acl. Twój pakiet Squida nie ma pliku pod tą ścieżką. To może być niezgodność pakowania, a nie zepsuta sesja użytkownika.
Squid może przekazywać decyzje zewnętrznych ACL do programów pomocniczych, ale samo nazwanie programu w external_acl_type go nie instaluje. Plik binarny musi istnieć we wdrożonym środowisku.
Porównaj trzy rzeczy:
- Udokumentowaną nazwę pomocnika dla używanej wersji Squida.
- Pliki faktycznie dostarczane przez pakiet Twojej dystrybucji.
- Bezwzględną ścieżkę pliku wykonywalnego w konfiguracji wczytanej przez Squida.
Debian publikuje podręcznik dla ext_session_acl, ale zgodny tytuł podręcznika nie dowodzi, że pod skopiowaną ścieżką na Twoim serwerze istnieje plik binarny. Sprawdź informacje o pakiecie tej instalacji i katalog pomocników.
Jeśli jej pakiet nie zapewnia wymaganego pomocnika, sprawdź obsługiwany podział pakietów dystrybucji i informacje o kompilacji. Nazwa podkatalogu w drzewie źródeł nie dowodzi, że wynikowy plik binarny jest obecny w każdej kompilacji.
Rozróżniaj „brak pliku” od „plik istnieje, ale nie startuje”. W drugim przypadku mogą być zaangażowane interpreter, biblioteki współdzielone, uprawnienia lub ograniczenia usługi. Dla tego błędu sprawdź komunikaty startowe pomocnika Squida. Żaden z tych objawów nie dowodzi, że hasło użytkownika proxy jest nieprawidłowe.
Pomocnik ze starego, niepowiązanego serwera nie jest wymienny tylko dlatego, że jego nazwa pliku pasuje do konfiguracji.