Dove mettere le variabili di ambiente quando si utilizza nginx e passeggeri su Ubuntu

Question

stavo cercando di creare un sistema simile a Heroku dove avrei memorizzare le chiavi segrete di variabili ambientali e quindi accedervi da miei rotaie app come questo:

secret = ENV['EMAIL_PASSWORD'] 

So che heroku ti permette di fare heroku config:add EMAIL_PASSWORD=secret, e volevo fare qualcosa del genere per la mia casella di Ubuntu su cui gira nginx e Passenger.

Devo aggiungere queste variabili come export s in .bashrc o .bash_login in modo che al riavvio del sistema queste variabili vengano impostate automaticamente?

non sono sicuro se ognuno di quei file Viene letto nella.

Answer 1

È necessario aggiungere le linee di esportazione nel file .profile sotto la vostra cartella home ...

Le variabili d'ambiente sono in via di al login ...

Answer 2

Ricordare che nginx potrebbe non essere in esecuzione nello stesso ambiente in cui ci si trova, e di solito (pronunciato "Apache") aggiungiamo env-vars nel file di configurazione del server tramite SetEnv. Tuttavia, nginx non ha questa caratteristica ... né ne ha bisogno, credo.

sudo -E /usr/local/sbin/nginx 

Quando si esegue nginx affinché sia ​​a conoscenza dei propri oggetti utente vars.

Oppure, controlla la env di comando (see here):

env EMAIL_PASSWORD=secret 

Per rispondere alla tua domanda, sì, è necessario utilizzare export dichiarazioni in vostri file di configurazione della shell.

Answer 3

Modificato:

Ok scusa ho letto troppo veloce, è possibile verificare come salvare le variabili ENV qui:

https://help.ubuntu.com/community/EnvironmentVariables

http://www.cyberciti.biz/faq/set-environment-variable-linux/

Se si utilizza Nginx come server su il tuo computer locale, puoi definire la tua variabile env nel tuo file di configurazione nginx.

location/{ 
... 
    fastcgi_param EMAIL_PASSWORD secret; #EMAIL_PASSWORD = secret 
... 
} 

Answer 4

Nel caso qualcuno ha avuto lo stesso tipo di domanda come ho fatto io, ecco un po 'interessante resoconto piacevole circa i diversi .bash* file: http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html

In sintesi:

Per la maggior parte: .bash_profile viene letto quando si accede al computer e .bashrc viene letto quando si avvia un nuovo terminale. Per Mac OSX .bash_profile viene letto con ogni finestra di terminale che si avvia.

Quindi, la procedura consigliata è quella di importare .bashrc da .bash_profile in modo che tutte le variabili siano impostate quando si accede al computer.Basta aggiungere questo per .bash_profile:

if [ -f ~/.bashrc ]; then 
    source ~/.bashrc 
fi 

Answer 5

(questo è probabilmente eccessivo, ma forse sarà utile)

Alcune cose da tenere a mente:

Le variabili d'ambiente sono un po 'pubblica, e può essere visto da altri processi con la stessa facilità con cui è stata aggiunta un'opzione al comando ps(1) (come ps e $$ in bash) o guardando allo /proc/*/environ, sebbene entrambi siano limitati almeno allo stesso utente (o root) sui sistemi moderni. Non fare affidamento sulla loro segretezza se hai un'altra opzione abbastanza facile disponibile.

~/.bashrc è il posto sbagliato per le variabili di ambiente, dal momento che possono essere calcolate una volta al login in ~/.bash_login, ~/.bash_profile o ~/.profile, a seconda del loro utilizzo, e superato verso il basso per tutte le shell discendenti. Al contrario, le azioni ~/.bashrc tendono a essere ricalcolate su ogni invocazione di shell (se non esplicitamente disabilitato).

Mettere codice bash nel ~/.profile può confondere altre shell sh-discendenti e gli strumenti non-shell che cercano di leggere il file, in modo da avere la ~/.bash_login o -_profile contengono le cose specifiche per bash, e usando . ~/.profile per specifici bash le cose più generali (LESS, EDITOR, VISUAL, LC_COLLATE, LS_COLORS, ecc.) sono più amichevoli con gli altri strumenti.

Le variabili di ambiente in ~/.profile devono essere nel vecchio formato di shell Bourne (VAR=value ; export VAR). Su Linux questo non è solitamente critico, anche se su Unixen questo può essere un grosso problema quando una versione precedente di "sh" cerca di leggerli.

Alcune sessioni X leggeranno solo ~/.profile, non ~/.bash_login o le altre sopra menzionate. Alcuni cercheranno un file ~/.xsession che dovrà essere modificato per avere . $HOME/.profile se non lo è già in qualche modo.

Le impostazioni a livello di sistema vengono invece inserite in qualcosa come /etc/profile.d/similar-to-heroku.sh. Si noti che ".sh" è presente solo perché il file verrà utilizzato con "." o "source" - gli script di shell dovrebbero mai avere estensioni di nome comando in qualsiasi forma di Unix/Linux.

La maggior parte delle variabili di ambiente viene interrotta quando uno sudo s esegue il root, come indicato da ybakos. Problemi simili si presentano in crontabs, lavori, ecc. In caso di dubbio, aggiungere env | sort > /tmp/envvars o uno script sospetto può davvero aiutare nel debug.

Tenere presente che alcune distribuzioni hanno script di avvio della shell così contorti che finiscono per sfidare effettivamente l'ordine indicato nella pagina di manuale di bash (1). Ogni volta che trovi un utente predefinito con controllo ~/.profile per $ BASH o $ BASH_VERSION, potresti trovarti in uno di questi, um ..., ambienti "interessanti" e potrebbe doverli leggere per capire dove va il flusso di controllo (essi dovrebbe usare uno specifico bash ~/.bash_profile o ~/.bash_login, che include il più generico ~/.profile come riferimento, facendo in modo che l'eseguibile bash faccia il lavoro invece di dover scrivere i controlli $ BASH nel codice della shell).

~/.bash_profile (o ~/.bash_login) può certamente comprendere . ~/.bashrc, ma le variabili di ambiente appartengono nel ~/.bash_profile (se specifici bash) o il ~/.profile incluso da esso (se si sta utilizzando questo meccanismo e hanno envvars per tutto il resto in là) come dice DeWitt, ricorda di mettere il . ~/.bashrc DOPO il.bash_profile's . ~/.profile e altre variabili di ambiente, in modo che sia il login che tutte le altre chiamate di ~/.bashrc possono fare affidamento sugli envar già impostati. Un esempio ~/.bash_profile:

# .bash_profile 
[ -r ~/.profile ] && . ~/.profile # envvars 
[ -r ~/.bashrc ] && . ~/.bashrc # functions, per-tty settings, etc. 
#---eof 

I [ -r ... ] && ... opere in qualsiasi shell Bourne discendente e non causa errori/interrompe se .profile manca (personalmente ho un setup ~/.profile.d/*.sh pure, ma questo viene lasciata come interamente esercizio facoltativo).

Si noti che bash legge solo il primo file di questi tre che trova:

~/.bash_profile 
~/.bash_login 
~/.profile 

... così una volta che avete che uno, l'uso degli altri due è interamente sotto il controllo dell'utente, dalla prospettiva di bash.

Answer 6

This is documented in nginx. Rimuove tutte le variabili di ambiente eccettoTZ durante l'esecuzione degli operatori. Se si desidera aggiungere una variabile di ambiente, aggiungere il seguente alla superiore della configurazione nginx:

# The top of the configuration usually has things like: 
user user-name; 
pid pid-file-name; 

# Add to this: 
env VAR1=value1; 
env VAR2=value2; 

# OR simply add: 
env VAR1; 
# To inherit the VAR1 from whatever you set in bash 

Il normale export o qualsiasi cosa si fa in bash non ha alcuna garanzia di ottenere trasmesso a nginx, a causa di il modo in cui sono scritti gli script di init (non sappiamo se stanno usando sudo con un ambiente pulito, ecc.). Quindi preferirei metterli nel file di configurazione di nginx stesso, piuttosto che dipendere dalla shell per farlo.

Edit: collegamento Fix

Answer 7

Si consiglia di leggere questa risposta a un'altra domanda, che vi aiuterà:

https://stackoverflow.com/a/11765775/1217298

Answer 8

È possibile utilizzare dotenv gem che carica il file .env come variabili ambientali. È possibile generare il file .env per ambienti diversi, e non è necessario essere piuttosto non dovrebbe essere controllato nel repository.

Answer 9

Ho uno script nella cartella /usr/local/bin che imposta alcuni oggetti vv e quindi esegue Ruby. Definisco il percorso di Ruby nel mio file di configurazione (Apache, not Nginx) in quel file in /usr/local/bin.

esempio:

#!/bin/sh 

# setup env vars here 
export FOO=bar 
export PATH_TO_FOO=/bar/bin 
export PATH=$PATH:PATH_TO_FOO 

# and execute Ruby with any arguments passed to this script 
exec "/usr/bin/ruby" "$@" 

Answer 10

sto usando rbenv come manager di versione. Una buona soluzione per archiviare le variabili di ambiente per il progetto era installare il plugin rbenv-vars e inserirli nel file .rbenv-vars.

Ecco un post utile:
Deploying app ENV variables with Rbenv, Passenger and Capistrano

Answer 11

li ho messi nel mio nginx config, in particolare nella definizione del server per l'applicazione utilizzando il comando passenger_env_var:

 
server { 
    server_name www.foo.com; 
    root /webapps/foo/public; 
    passenger_enabled on; 

    passenger_env_var DATABASE_USERNAME foo_db; 
    passenger_env_var DATABASE_PASSWORD secret; 
    passenger_env_var SECRET_KEY_BASE the_secret_keybase; 
} 

Questo funziona per me. Vedi il passeggero di phishing docs per maggiori informazioni.

Answer 12

Per coloro che stanno combattendo contro ciò che sta utilizzando RVM. Assicurati che il file degli ambienti di default includa il tuo .bashrc e.file di profilo

file: $rvm_path/environments/default 

per trovare il percorso di eseguire questo comando:

ls -lah `whereis rvm`/environments/default 

Aggiungere queste due righe prima della prima riga nel file:

source $HOME/.bashrc 
source $HOME/.profile