Msaidizi wa kikao wa Squid alikwenda wapi?
Fuatilia msaidizi wa Squid anayekosekana kupitia kifurushi kilichosakinishwa, jina la faili lililoandikwa na chaguo za ujenzi kabla ya kubadilisha mipangilio ya uthibitishaji.
Usanidi ulionakiliwa kutoka kwa seva nyingine unataja ext_session_acl. Kifurushi chako cha Squid hakina faili kwenye njia hiyo. Hii inaweza kuwa kutolingana kwa ufungashaji badala ya kikao cha mtumiaji kilichovunjika.
Squid inaweza kukabidhi maamuzi ya ACL za nje kwa programu saidizi, lakini kutaja programu katika external_acl_type hakisakinishi. Faili ya binary lazima iwepo katika mazingira yaliyowekwa.
Linganisha mambo matatu:
- Jina lililoandikwa la msaidizi kwa toleo la Squid unalotumia.
- Faili ambazo kifurushi cha usambazaji wako hutoa kwa kweli.
- Njia kamili ya faili inayotekelezeka katika usanidi ambao Squid ilipakia.
Debian huchapisha mwongozo kwa ext_session_acl, lakini kichwa cha mwongozo kinacholingana si uthibitisho kwamba binary ipo kwenye njia iliyonakiliwa kwenye seva yako. Angalia taarifa za kifurushi za usakinishaji huo wenyewe na saraka ya wasaidizi.
Ikiwa kifurushi chake hakitoi msaidizi anayehitajika, angalia mgawanyo wa vifurushi unaoungwa mkono na usambazaji na taarifa za ujenzi. Jina la saraka ndogo katika mti wa chanzo si uthibitisho kwamba binary inayotokana ipo katika kila ujenzi.
Tenganisha «faili haipo» na «faili ipo lakini haiwezi kuanza». La pili linaweza kuhusisha kitafsiri chake, maktaba zinazoshirikiwa, ruhusa au uwekaji mipaka wa huduma. Kwa hitilafu hiyo angalia ujumbe wa kuanza wa msaidizi wa Squid. Hakuna dalili yoyote kati ya hizo mbili inayothibitisha kwamba nenosiri la mtumiaji wa proksi si sahihi.
Msaidizi kutoka seva ya zamani isiyohusiana hawezi kubadilishwa kwa sababu tu jina la faili yake linalingana na usanidi.