Cómo establecer un sistema amplio de variables de entorno en OS X Mavericks

El archivo correcto, antes de Mavericks, fue ~/.MacOSX/environment.plist. Esto ya no es compatible.

En Darwin, y por lo tanto en Mac OS X, el lugar adecuado para establecer estos es en /etc/launchd.conf a aplicar a todos los procesos; si relativas a las shells de usuario en concreto, el uso de la shell adecuada de los archivos en su lugar, dependiendo de la shell en cuestión. Ver el launchd.conf y launchctl páginas man para obtener más.

Que dijo...

Si estás objetivo es específicamente para ver las aplicadas para sesiones ssh, entonces usted necesita estar consciente de que ssh, por razones de seguridad, no se aplican las variables de entorno de esta manera. De hecho una sesión de ssh normalmente recibe mucho más restrictiva conjunto de variables de entorno del sistema operativo, como no es lo que se conoce como un "inicio de sesión" o "interactivo" shell, es clasificado como un "no interactiva" shell. (Ver man bash para más información sobre los tipos de shell.) La forma de ssh maneja las variables de entorno está bien cubierto en el ssh/sshd docs y las páginas man.

Para ssh-que es su propia concha, similar a la de bash -- variables de entorno para la sesión se almacenan en ~/.ssh/environment como la de cada usuario el equivalente de la configuración de estos para bash o csh, etc en sus correspondientes archivos de ejecución. Este es probablemente el lugar donde desea establecer su ENV variables para su usuario sesiones ssh, aunque no los detalles de por qué usted está buscando para asignar ENVs a nivel mundial en su post original, que habría sido útil disponer de una solución. Yo sugeriría que usted establezca de forma explícita en un usuario de la base por usuario para mantener la seguridad basada en la respectiva cuenta de la menos restrictiva privilegio/atributo de la mejor práctica.

Si por alguna razón usted desea omitir él implicaciones de seguridad de este, a continuación, establezca PermitUserEnvironment en su ssh configs. Tenga en cuenta que esta opción está deshabilitada si UseLogin está habilitado. IMPORTANTE: darse Cuenta de que esto significa que las cuentas de usuario configurado para utilizar /bin/false como su shell - el típico método para deshabilitar una cuenta de usuario - ahora puede potencialmente llegar alrededor de esta restricción y ahora podría convertirse en activo, que es peligroso. Muchas cuentas se establece el uso de /bin/false como su caparazón como la seguridad de la expectativa.

Línea de fondo es que usted no debería estar haciendo esto a nivel mundial y esperando ssh para propagar ENV por razones de seguridad. Su pregunta es, efectivamente, a propósito preguntando cómo derrotar a varios mecanismos que existen por razones de seguridad.

Si usted está usando bash, a continuación, establecer las variables de entorno en /etc/profile se aplicará para todos los usuarios.

De la bash manual en OS X Mavericks, con el énfasis es mío (esto no ha cambiado desde versiones anteriores):

Cuando bash se invoca como un proceso interactivo shell de inicio de sesión, o como un no-shell interactivo con la opción --opción de inicio de sesión, primero lee y ejecuta los comandos desde el archivo /etc/profile, si ese archivo existe. Después de leer el archivo, busca en ~/.bash_profile, ~/.bash_login, y ~/.de perfil, en ese orden, y lee y ejecuta los comandos de la primera, que existe y es legible.
...
Si bash es invocada con el nombre sh, intenta imitar el comportamiento de inicio de las versiones históricas de sh tan estrechamente como sea posible, mientras que conforme al estándar POSIX así. Cuando se invoca como un inter-activa interactiva active shell de inicio de sesión, o no un shell interactivo con la opción --opción de inicio de sesión, en primer lugar, intenta leer y ejecutar comandos en /etc/profile y ~/.de perfil, en ese orden.

He tenido un problema similar, específicamente ~/.bashrc no estaba siendo procedente cuando me he conectado a mi equipo a través de SSH. He encontrado que cambiar una opción de configuración de SSHd hizo el truco. Tal vez tu problema también se encuentra con el demonio SSH?

Modificar el servicio SSH configuración del archivo de la siguiente manera:

# /etc/sshd_config
PermitUserEnvironment yes

A continuación, reinicie el servicio de acceso Remoto en Preferencias del Sistema > Compartir.

De la sshd_config manual:

 PermitUserEnvironment
         Specifies whether ~/.ssh/environment and environment= options in
         ~/.ssh/authorized_keys are processed by sshd(8).  The default is
         ``no''.  Enabling environment processing may enable users to
         bypass access restrictions in some configurations using mecha-
         nisms such as LD_PRELOAD.

(En caso de que ayuda, he escrito cómo he probado esto en mi wiki personal)

Si otros la búsqueda de cómo configurar las variables de entorno para los procesos iniciados a partir de una gráfica normal de inicio de sesión, puede utilizar /etc/launchd.conf. Por ejemplo, agregar /usr/local/bin a la ruta de acceso predeterminada, ejecutar

echo setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin|sudo tee -a /etc/launchd.conf

y en reiniciar para aplicar los cambios. Otra forma de aplicar los cambios es ejecutar launchctl</etc/launchd.conf;sudo launchctl</etc/launchd.conf y el relanzamiento de los procesos.

Hmm... Como de Mac OS X 10.10.5 y probablemente desde antes, man -s5 launchd.conf nos dice: "launchd.conf is no longer respected by the system." tengo demasiadas cosas que están sucediendo ahora mismo a poner una variable ficticia en el archivo y reinicie para ver si realmente funciona o no, después de todo, pero la documentación dice que no deben trabajar.

Estoy bastante seguro de que no. Hacer man launchctl y verás: "The /etc/launchd.conf file is no longer consulted for subcommands to run during early boot time; this functionality was removed for security considerations."

Lo que usted puede hacer es poner todas las variables de entorno que desea ser global-ish en algunos archivos, tal vez llamado environment , en consonancia con Linux, o (en el caso de Apple se decide a hacer algo con eso más tarde – nunca se sabe) environment.conf, como yo lo hice, entonces el origen de esta via /etc/profile:

if [ -f /etc/environment.conf ]; then
   source /etc/environment.conf
fi

o, si usted prefiere el formato compacto:

if [ -f /etc/environment.conf ]; then . /etc/environment.conf; fi

Si utiliza algún otro shell de bash, y se utiliza la misma variable de ajuste de la sintaxis de bash (como lo hace zsh, creo), necesitará también la fuente de este archivo de que shell en todo el sistema de archivo rc (por ejemplo /etc/zshrc). Si utiliza un shell que utiliza una sintaxis diferente, por ejemplo, tcsh, deberá mantener un archivo similar para que la shell y la fuente de la shell en todo el sistema de archivo rc (por ejemplo /etc/csh.cshrc para tcsh), o mejor aún, crear una secuencia de comandos que se auto-genera, por lo que usted sólo tiene que editar un archivo para agregar/cambiar variables. Este no es el lugar para un tutorial; un par de segundos en Google se presentó cómo convertir [t]csh variable de las exportaciones a la sintaxis de bash, en http://stackoverflow.com/questions/2710790/how-to-source-a-csh-script-in-bash-to-set-the-enviroment, así que probablemente hay algo disponible para ir en otra dirección.

Mi experiencia me dice que Mac OS X está moviendo más y más lejos de predicción archivo rc comportamiento. Como de, al menos, 10.8, parece que ha dejado de carga /etc/rc.common, /etc/rc.conf o /etc/rc.<anything>, ni (por lo menos desde 10.9) carga /etc/bash.bashrc interactivo nonlogin conchas (que sin duda debe estar haciendo, así como carga ~/.bashrc de ellos, todavía, a partir de las 10.10). Luego otra vez tengo Fink, MacPorts, y Homebrew todos los instalando cosas, así que tal vez uno de ellos interfiere con la configuración predeterminada del dotfile comportamiento. YMMV.