Como definir variável de ambiente para todos no meu sistema linux?

Posso ter certas configurações universais para todos os meus usuários?

Assim como /etc/profileoutros já mencionaram, alguns sistemas Linux agora usam um diretório /etc/profile.d/; todos os .sharquivos serão fornecidos por /etc/profile. É um pouco mais organizado manter essas coisas de ambiente personalizadas nesses arquivos do que apenas editar /etc/profile.

Se o seu LinuxOS possui este arquivo:

/etc/environment

Você pode usá-lo para definir permanentemente variáveis ​​ambientais para todos os usuários.

Extraído de: http://www.sysadmit.com/2016/04/linux-variables-de-entorno-permanentes.html

man 8 pam_env

man 5 pam_env.conf

Se todos os serviços de login usarem o PAM , e todos os serviços de login tiverem session required pam_env.soseus respectivos /etc/pam.d/*arquivos de configuração, todas as sessões de login terão algumas variáveis ​​de ambiente definidas conforme especificado no pam_envarquivo de configuração.

Na maioria das distribuições modernas de Linux, tudo está disponível por padrão - basta adicionar as variáveis ​​de ambiente global desejadas /etc/security/pam_env.conf.

Isso funciona independentemente do shell do usuário e também funciona para logins gráficos (se xdm / kdm / gdm / entrance /… estiver configurado assim).

Surpreendentemente, Unix e Linux não têm realmente um lugar para definir variáveis ​​de ambiente global. O melhor que você pode fazer é organizar para que qualquer shell específico tenha uma inicialização específica do site.

Se você o colocar /etc/profile, isso cuidará das coisas para a maioria dos usuários de shell compatíveis com posix. Isso provavelmente é "bom o suficiente" para fins não críticos.

Mas qualquer pessoa com um shell cshou tcshnão o verá, e não acredito que cshtenha um arquivo de inicialização global.

Alguns trechos interessantes da página de manual do bash:

Quando o bash é chamado como um shell de logon interativo ou como um shell não interativo com a --loginopção, ele primeiro lê e executa comandos do arquivo /etc/profile, se esse arquivo existir. Depois de ler esse arquivo, ele procura ~/.bash_profile, ~/.bash_logine ~/.profile, nessa ordem, e lê e executa os comandos do primeiro que existe e é legível. A --noprofileopção pode ser usada quando o shell é iniciado para inibir esse comportamento.
...
Quando um shell interativo que não é um shell de login é iniciado, o bash lê e executa comandos de /etc/bash.bashrce ~/.bashrc, se esses arquivos existirem. Isso pode ser inibido usando a --norcopção o--rcfileA opção file forçará o bash a ler e executar comandos do arquivo em vez de /etc/bash.bashrce ~/.bashrc.

Portanto, dê uma olhada /etc/profileou /etc/bash.bashrc, esses arquivos são os locais certos para configurações globais. Coloque algo assim neles para configurar uma variável de ambiente:

export MY_VAR=xxx

Usar o PAM é excelente.

# modify the display PAM
$ cat /etc/security/pam_env.conf 
# BEFORE: $ export DISPLAY=:0.0 && python /var/tmp/myproject/click.py &
# AFTER : $ python $abc/click.py &
DISPLAY  DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
abc   DEFAULT=/var/tmp/myproject

Todo processo em execução no kernel do Linux recebe seu próprio ambiente exclusivo, herdado de seu pai. Nesse caso, o pai será um próprio shell (gerando um sub shell) ou o programa 'login' (em um sistema típico).

Como o ambiente de cada processo é protegido, não há como injetar uma variável de ambiente em todos os processos em execução; portanto, mesmo se você modificar o shell .rc / profile padrão, ele não entrará em vigor até que cada processo saia e recarregue suas configurações de inicialização.

Procure em / etc / para modificar as variáveis ​​de inicialização padrão para qualquer shell em particular. Apenas perceba que os usuários podem (e costumam fazer) alterá-los em suas configurações individuais.

O Unix foi projetado para obedecer ao usuário, dentro de limites.

NB : O Bash não é o único shell no seu sistema. Preste muita atenção ao que o link simbólico / bin / sh realmente aponta. Em muitos sistemas, isso pode realmente ser um traço que está (por padrão, sem invocação especial) POSIXLY correto. Portanto, você deve modificar os padrões, ou os scripts que começam com / bin / sh não herdarão seus padrões globais. Da mesma forma, tome cuidado para evitar a sintaxe que apenas o bash entende ao editar os dois, também conhecido como avoiding bashisms.