Cine tot pune acel proxy înapoi în Bash?

Dacă http_proxy reapare în următorul terminal, aflați cine l-a setat. Un alt unset la sfârșitul fișierului .bashrc poate ascunde valoarea pentru o lansare, lăsând sursa activă în altă parte.

1. Identificați lansarea care eșuează. Este un shell de login interactiv, un terminal fără login sau o sarcină neinteractivă? Bash apelat ca sh urmează și el alte reguli.
2. Urmați acea cale de pornire. Un shell de login interactiv citește /etc/profile și apoi primul fișier de utilizator disponibil dintre ~/.bash_profile, ~/.bash_login și ~/.profile. Un shell interactiv fără login citește de obicei ~/.bashrc. Un fișier de login îl poate sourcea explicit. Pentru Bash neinteractiv, țineți cont de BASH_ENV unde se aplică.
3. Găsiți atribuirea. Căutați în acele fișiere și în fișierele pe care le fac source numele variabilei și numele vechi de gazdă al proxy-ului. Includeți fragmentele relevante din /etc/profile.d și numele cu majuscule, cât și cu minuscule.
4. Dacă pornirea nu l-a atribuit, urmăriți părintele. Shell-ul moștenește un mediu de la terminalul său, de la sesiunea de login, de la managerul de servicii sau de la instrumentul de dezvoltare. Un părinte de lungă durată poate păstra valoarea veche după ce editați un fișier de shell.

Pentru autentificările bazate pe PAM, verificați și /etc/environment. Corectați sursa proprietară și reporniți calea afectată, reîmprospătând configurația părintelui când e nevoie. Păstrați căutările locale: fișierele de pornire și dump-urile de mediu pot conține credențiale. Rezultatul de verificat este valoarea moștenită de comanda dorită, nu ultimul fișier care a reușit să o unseteze.