2011-12-26 30 views
295

Quando uso qualsiasi comando con sudo le variabili ambientali non ci sono. Ad esempio, dopo aver impostato HTTP_PROXY il comando wget funziona correttamente senza sudo. Tuttavia se digito sudo wget dice che non può ignorare l'impostazione del proxy.Come mantenere le variabili d'ambiente quando si utilizza SUDO

+0

http://superuser.com/questions/232231/how-do-i-make-sudo-preserve-my-environment-variables –

+1

correlati: [Perché sono variabili strada diversa quando si esegue tramite sudo e su ?] (http://unix.stackexchange.com/q/8646/21471) a Unix SE – kenorb

risposta

242

Il trucco è quello di aggiungere variabili di ambiente per sudoers file tramite sudo visudo di comando e aggiungere queste righe:

Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy" 

preso da ArchLinux wiki.

Per Ubuntu 14, è necessario specificare in linee separate in quanto restituisce gli errori per le linee a più variabili:

Defaults env_keep += "http_proxy" 
Defaults env_keep += "https_proxy" 
Defaults env_keep += "HTTP_PROXY" 
Defaults env_keep += "HTTPS_PROXY" 
+10

Questa è probabilmente l'opzione migliore, per evitare fughe di informazioni e falle di sicurezza. 'sudo -E' è il modo infallibile di ottenere lo stesso effetto per una tantum, anche se – sehe

+0

ho riscontrato il problema di un processo che è quello che chiama sudo (jhbuild) e non posso dirlo per passare il flag -E su sudo, quindi questa è la mia soluzione. – jgomo3

+42

Si noti che non si dovrebbe * mai * modificare direttamente 'etc/sudoers'. Invece, usa il comando 'visudo', che controlla le tue modifiche prima di sovrascrivere il file' sudoers'. In questo modo, non ti blocchi se commetti un errore durante la modifica. – Henning

322

Per prima cosa è necessario export HTTP_PROXY. In secondo luogo, è necessario leggere attentamente man sudo e prestare attenzione al flag -E. Questo funziona:

$ export HTTP_PROXY=foof 
$ sudo -E bash -c 'echo $HTTP_PROXY' 

Ecco la citazione dalla pagina man:

-E, --preserve-env 
      Indicates to the security policy that the user wishes to reserve their 
      existing environment variables. The security policy may eturn an error 
      if the user does not have permission to preserve the environment. 
+0

grande l'unico problema che è modificare alcuni file di configurazione, ad esempio pacman per arch per rendere -E viene passato –

+4

Per consentire -E (preservare l'ambiente) per wget, è necessario specificare il tag SETENV sulla regola sudo che consente l'esecuzione di wget - Esempio: ALL = (root) NOPASSWD: SETENV:

+30

Questo "-E" non funziona se la variabile è PATH o PYTHONPATH. – apporc

18

È inoltre possibile combinare le due env_keep dichiarazioni in risposta di Ahmed Aswani in una singola istruzione come questo:

Defaults env_keep += "http_proxy https_proxy"

Si dovrebbe anche prendere in considerazione specificando env_keep per un solo comando come questo:

Defaults!/bin/[your_command] env_keep += "http_proxy https_proxy"

34

Per le singole variabili che si desidera rendere disponibili su base singola, è possibile renderle parte del comando.

sudo http_proxy=$http_proxy wget "http://stackoverflow.com" 
+0

Ho testato questa risposta per un 'pacchetto' sotto qualche myPath aggiunto a' PATH' nel file '.bashrc' (con clausola 'export'). Quindi 'sudo PATH = $ PATH quale pacchetto' trova la risposta giusta, diversamente da' sudo quale pacchetto'. Tuttavia, 'sudo PATH = $ PATH pacchetto' non va oltre al' pacchetto sudo' (file non trovato). D'altra parte, lanciando un semplice 'pacchetto' da una shell invocata con' sudo bash' conserva il percorso esteso e fornisce i diritti sudo 'package' (due piccioni con una fava). Quindi la risposta dipende davvero da quali comandi si sta avviando la risoluzione del PERCORSO – XavierStuvw

+1

per sudo è un'altra questione: se qualcuno trova questo post in cerca di tale argomento, suggerisco di vedere http://unix.stackexchange.com/questions/83191/how-to -fare-sudo-preserve-path – jpj