Cómo configurar variables de entorno de todo el sistema en OS X Mavericks

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

En Darwin, y por lo tanto en Mac OS X, el lugar adecuado para configurarlos es en /etc/launchd.conf para aplicar a todos los procesos; Si se relaciona específicamente con shells de usuario, use los archivos de shell apropiados, dependiendo del shell en cuestión. Consulte las páginas de manual launchd.conf y launchctl para obtener más información.

Dicho esto ...

Si su objetivo es ver específicamente que se apliquen a las sesiones ssh, debe tener en cuenta que ssh, por razones de seguridad, no aplica las variables de entorno de esta manera. De hecho, una sesión ssh normalmente recibe un conjunto mucho más restrictivo de variables de entorno del sistema operativo, ya que no es lo que se conoce como un shell de "inicio de sesión" o "interactivo", sino que se clasifica como un shell "no interactivo". (Consulte man bash para obtener más información sobre los tipos de shell). La forma en que ssh maneja las variables de entorno está bien cubierta en los documentos ssh / sshd y las páginas del manual.

Para ssh, que es su propio shell, similar a bash, las variables de entorno para la sesión se almacenan en ~/.ssh/environment como el equivalente por usuario de configurar bash o csh, etc. en sus archivos de inicio relevantes. Probablemente aquí sea donde desee configurar sus variables de ENV para sus sesiones de usuario ssh, aunque no detalla por qué desea asignar ENV a nivel mundial en su publicación original, lo que hubiera sido útil para proporcionar una solución. Le sugeriría que los establezca explícitamente en un usuario por usuario para mantener la seguridad adecuada en función de cada cuenta respectiva siguiendo las mejores prácticas de privilegio / atributo menos restrictivas.

Si por alguna razón desea ignorar las implicaciones de seguridad de esto, entonces establezca PermitUserEnvironment en sus configuraciones ssh. Tenga en cuenta que esto está deshabilitado si UseLogin está habilitado. IMPORTANTE: tenga en cuenta que esto significa que las cuentas de usuario configuradas para usar /bin/false como su shell, el método típico para deshabilitar una cuenta de usuario, ahora pueden evitar esta restricción y ahora pueden activarse, lo que es peligroso. Muchas cuentas están configuradas para usar /bin/false como su shell como una expectativa de seguridad.

La conclusión es que no debería hacer esto globalmente y esperar que ssh propague ENV por razones de seguridad. Su pregunta es, efectivamente, a propósito, cómo derrotar a varios mecanismos que existen por razones de seguridad.

Si está utilizando bash , la configuración de las variables de entorno en /etc/profile se aplicará a todos los usuarios.

Del bash manual sobre OS X Mavericks , con mi énfasis (esto no ha cambiado desde las versiones anteriores):

  

Cuando se invoca a bash como un shell de inicio de sesión interactivo, o como un shell no interactivo con la opción --login, primero lee y ejecuta los comandos del archivo / etc / profile, si ese archivo existe. Después de leer ese archivo, busca ~ / .bash_profile, ~ / .bash_login, y ~ / .profile, en ese orden, y lee y ejecuta los comandos desde el primero que existe y es legible.   ...
Si se invoca a bash con el nombre sh, trata de imitar el comportamiento de inicio de las versiones históricas de sh lo más cerca posible, a la vez que se ajusta al estándar POSIX. Cuando se invoca como un shell de inicio de sesión activo interactivo interactivo, o un shell no interactivo con la opción --login, primero intenta leer y ejecutar comandos desde / etc / profile y ~ / .profile , en ese orden.

Lo que usted (y cualquier otra persona que encuentre esta pregunta) está buscando es la siguiente ruta:

/private/etc/paths

Siempre puede colocar sus ediciones en el /private/etc/paths.d si desea evitar cambiar el documento de configuración de "rutas" predeterminadas del sistema principal, pero luego se agregarán al final de su variable $PATH , así que si lo desea para agregar directorios al principio de $PATH (para anular las utilidades predeterminadas del sistema, por ejemplo), solo tendrá que editar el archivo principal /private/etc/paths y agregarlo a la parte superior de la lista. Por ejemplo, hago esto para una carpeta en la que almaceno unos cuantos scripts que hice, junto con algunas utilidades clave, como mozjpeg , que quiero que el sistema use siempre en lugar de los valores predeterminados con los que viene ( de esa manera, todos los archivos jpeg guardados por casi cualquier programa se comprimen automáticamente hasta en un 10% más de lo que la utilidad cjpeg del sistema normal los comprimiría. He leído que la razón por la que no está predeterminada en la mayoría de los sistemas es porque más lento, pero cuando hablas algo así como 0,14 segundos en lugar de 0,02 segundos, "más lento por un factor de 7" no significa mucho de nada ... suponiendo que esto no sea un servidor, por supuesto). Sé que mucha gente probablemente advertirá sobre el "peligro" potencial de realizar ediciones tan profundas en el sistema, pero diría que si está buscando una respuesta como esta, probablemente sepa lo suficiente como para tratar cualquier denominación de utilidad. conflictos que pueden surgir en el futuro, y simplemente hacer que sus cambios en /private/etc/paths realmente los propaguen a todos los usuarios / inicios de sesión / instancias posibles: todos los programas, shells, etc. usarán las rutas en ese archivo para construir la base de su $PATH variable.

Para ser honesto, estoy bastante sorprendido de que nadie más haya mencionado esto todavía. Todo lo que hace falta con Launchd y las distracciones sobre los usos específicos de SSH ... esta es la solución que todos los que buscan para este problema básico realmente están buscando: la solución limpia, directa a la fuente, que siempre funciona.

Por cierto, en caso de que te lo preguntes, en OS X /etc es simplemente un enlace simbólico a /private/etc , así que puedes hacer sudo nano /etc/paths y llegar al mismo lugar con la misma facilidad. La ruta anterior es solo la ruta real completa del archivo.

Tuve un problema similar, específicamente el ~/.bashrc no se originó cuando me conecté a mi máquina a través de SSH. Encontré que cambiar un ajuste de configuración para SSHd hizo el truco. Quizás su problema también esté en el demonio SSH?

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

# /etc/sshd_config
PermitUserEnvironment yes

Luego reinicie el servicio de inicio de sesión remoto en Preferencias del sistema > Compartir.

Desde la página de manual de sshd_config :

 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 ayude, he escrito cómo probé esto en mi wiki personal )

Si otros buscan cómo establecer variables de entorno para procesos iniciados desde una sesión de inicio de sesión gráfica normal, puede usar /etc/launchd.conf . Por ejemplo, para agregar /usr/local/bin a la ruta predeterminada, ejecute

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

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

Hmm ... A partir de Mac OS X 10.10.5 y probablemente antes, man -s5 launchd.conf nos dice: " launchd.conf is no longer respected by the system. " Tengo demasiadas cosas en marcha ahora mismo para poner una variable ficticia en el archivo y reiniciar a ver si realmente funciona o no después de todo, pero la documentación dice que no debería funcionar.

Estoy bastante seguro de que no lo hará. Haz 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 puede hacer es poner todas las variables de entorno que desea que sean globales en algún archivo, tal vez llamado environment en relación con Linux, o (en caso de que Apple decida hacer algo) con eso más tarde, nunca se sabe) environment.conf , como hice yo, luego obtenga esto a través de /etc/profile :

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

o, si prefieres el formato compacto:

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

Si usas un shell diferente a bash, y usa la misma sintaxis de configuración de variables como bash (como lo hace zsh, creo), también necesitarás obtener este archivo desde esa fuente. el archivo rc de todo el sistema de la shell (por ejemplo, /etc/zshrc ). Si usa un shell que usa una sintaxis diferente, p. Ej. tcsh, deberás mantener un archivo similar para ese shell y obtenerlo del archivo rc del sistema (por ejemplo, /etc/csh.cshrc for tcsh), o mejor aún crear un script que lo genere automáticamente, por lo que solo Hay que editar un archivo para agregar / cambiar variables. Este no es el lugar para tal tutorial; unos pocos segundos en Google descubrieron cómo convertir las exportaciones de variables [t] csh a la sintaxis de bash, en enlace , así que probablemente haya algo disponible para ir en la otra dirección.

Según mi experiencia, Mac OS X se está alejando cada vez más del comportamiento predecible de los archivos rc. A partir de al menos 10.8, ya no parece cargar /etc/rc.common , /etc/rc.conf o /etc/rc.<anything> , ni tampoco (desde al menos 10.9) cargará /etc/bash.bashrc para shells interactivos que no están en línea, lo cual debería estar haciendo, solo Me gusta carga ~/.bashrc para ellos, aún, a partir de 10.10). Luego, de nuevo tengo todas las cosas de instalación de Fink, MacPorts y Homebrew, así que tal vez uno de ellos esté interfiriendo con el comportamiento predeterminado de los archivos de puntos. YMMV.