Squid का सत्र सहायक कहाँ गया?
प्रमाणीकरण सेटिंग बदलने से पहले स्थापित पैकेज, प्रलेखित फ़ाइल नाम और बिल्ड विकल्पों में गुम Squid सहायक का पता लगाएँ।
किसी दूसरे सर्वर से कॉपी किया गया कॉन्फ़िगरेशन ext_session_acl का नाम लेता है। आपके Squid पैकेज में उस पथ पर कोई फ़ाइल नहीं है। यह टूटे उपयोगकर्ता सत्र के बजाय पैकेजिंग असंगति हो सकती है।
Squid बाहरी ACL निर्णय सहायक प्रोग्रामों को सौंप सकता है, लेकिन external_acl_type में किसी प्रोग्राम का नाम लिखने से वह स्थापित नहीं होता। बाइनरी तैनात परिवेश में मौजूद होनी चाहिए।
तीन चीज़ों की तुलना करें:
- आप जिस Squid संस्करण का उपयोग कर रहे हैं, उसके लिए सहायक का प्रलेखित नाम।
- आपके वितरण का पैकेज वास्तव में जो फ़ाइलें देता है।
- Squid द्वारा लोड किए गए कॉन्फ़िगरेशन में निरपेक्ष निष्पादन योग्य पथ।
Debian ext_session_acl के लिए मैनुअल प्रकाशित करता है, पर मैनुअल शीर्षक का मेल खाना इस बात का प्रमाण नहीं कि आपके सर्वर पर कॉपी किए गए पथ पर बाइनरी मौजूद है। उसी इंस्टॉलेशन की पैकेज जानकारी और सहायक निर्देशिका जाँचें।
यदि उसका पैकेज आवश्यक सहायक नहीं देता, तो वितरण के समर्थित पैकेज विभाजन और बिल्ड जानकारी देखें। स्रोत-ट्री में उपनिर्देशिका का नाम इस बात का प्रमाण नहीं कि बनी बाइनरी हर बिल्ड में मौजूद है।
“फ़ाइल अनुपस्थित” को “फ़ाइल मौजूद है पर शुरू नहीं होती” से अलग रखें। दूसरे में उसका इंटरप्रेटर, साझा लाइब्रेरी, अनुमतियाँ या सेवा प्रतिबंध शामिल हो सकते हैं। उस विफलता के लिए Squid के सहायक प्रारंभ संदेश देखें। इन दोनों में से कोई भी लक्षण प्रमाण नहीं है कि प्रॉक्सी उपयोगकर्ता का पासवर्ड गलत है।
असंबद्ध पुराने सर्वर का सहायक केवल इसलिए बदला नहीं जा सकता कि उसका फ़ाइल नाम कॉन्फ़िगरेशन से मेल खाता है।