4 ms·

> It would have been much better to utilize environment variables so the only thing that changed between environments was those variables. I strongly prefer co

> It would have been much better to utilize environment variables so the only thing that changed between environments was those variables. I strongly prefer commandline arguments to environment variables: They're more transparent, easier to reason about ("what's running on this server? `ps`... oh, that process there is running in the staging configuration instead of production"), and it saves useless sudos (/proc/<pid>/environ has mod bits 0400, so if the processes you're investigating are running as separate users (and they probably should be), you can't inspect the actual environment that the process has, so you end up sudo'ing to check the environment out when you should have all the information you need in the process list). If the environment variables are just interpolated into the run script by the deploy and then all passed to the process as arguments, that works too.

Someone1234 12y ago
I strongly agree. Often times environmental variables are used inappropriately and make tracking down issues harder due to loss of transparency. Plus environmental variables are context specific (e.g. user 1 and user 2 might have different ones, or server 1 and server 2 might, or this specific script may have re-defined one(!)). A good o' fashioned script with the constants defined at the top, commented, and passed into executables on the command line (so tools like ps or taskman can "see" them) is really easy to debug/alter/monitor. Java and or Oracle's obsession with environmental variables causes more problems than it solves.
- realusername 12y ago
  I also agree, the only way I would use environment variables is for global configuration like HTTP_PROXY for example, otherwise I still prefer arguments, at least there is no surprises.
  - philsnow 12y ago
    I was sad when I learned about this http_proxy environment variable and that things were actually starting to use it. An http proxy setting is no more suited for an environment variable than anything else. I think it should just be a string in a file in $XDG_CONFIG_DIR/http_proxy.conf or something like that.
  - mitchty 12y ago
    I agree but I also use DEBUG in my scripts to allow for on the fly debugging to occur. I consider it a degenerate case and its only there for my own use and abuse. All it really does is redefines certain functions to be more verbose or print out debug level information. I had one script that let you do DEBUG=somefunc and it would instrument just that one function. But to be honest it was overkill.
rdtsc 12y ago
Also depending on how those processes are started (as root, from initd, or by hand from shell etc) environment variables might be stripped or incomplete. Environment variables are kind of like global variables a bit. They are easy to set but feel a little dirty. And of course if you use libraries or third party package that rely on them, then you don't have a choice.
- deleted 12y ago
  [deleted]
bkeroack 12y ago
Environment variables make perfect sense for constants that only, you know, vary with the environment. It's very nice to run the same exact code/artifacts on dev, qa, testing and production. See also: http://12factor.net/ http://12factor.net/
- sliverstorm 12y ago
  The way I see it, basically variables that are implicit to the machine/network that everyone should be able to infer. TZ, HOST, that kind of thing. Including, of course, similarly implicit custom variables like bkeroack describes.
j_baker 12y ago
Environment variables are useful in their own situations. For instance, OpenShift signals the open IP and Port number as environment variables. Which is useful when you have a program with an unknown set of command-line parameters. Either that or when you only need a subset of the available command-line parameters.
curun1r 12y ago
On the other hand, environment variables are useful for things you specifically don't want showing up in ps. If you've got to supply credentials (passwords, tokens, certificates, etc) or anything else that requires a modicum of security, it's much better to pass those in as environment variables rather than command line arguments.
- mercurial 12y ago
  It's a lot better to read them from a secure location.
- philsnow 12y ago
  Please keep in mind this point called out by wereHamster elsewhere ( https://news.ycombinator.com/item?id=8695887 https://news.ycombinator.com/item?id=8695887 ): > env variables are inherited by children, which may be relevant if the app forks If your app forks (or any of the multitude of libraries that it may depend on, check and _pin_ your sources (so they don't add un-audited behaviors)), whatever process it execs probably will get a copy of the environment of your process. Yes, it's possible to clean the environment between the fork and the exec/execve. Do all / most frameworks do so or make it easy to do so? I'm not sure, but would check before making any assumptions about it. I was about to suggest that sensitive information like credentials would better be kept in files that are referred to by name in command line arguments, but... unprivileged users cannot fork/exec a process as a different user, so children could read all the same files as the parent. I can hardly believe it, but a plug for my masters work [0] is actually relevant here. I was interested at the time in the intersection of HCI and security, so I made up this thing called sub-identities that let unprivileged unix users create sub-users. It's a really watered-down version of some actual research that's been around for a while, but the point was, it was easy(ish) for the average unix user to use. I don't pretend that it was anything but a toy, though. All that said, it seems that passing sensitive information in environment variables, squirreling them away in the process space somewhere, then cleaning the environment (all right away, during initialization) would be a smart thing to do. edit: see `man 3 unsetenv` for how to do this [0] http://ccl.cse.nd.edu/research/pubs/snowberger-thesis.pdf http://ccl.cse.nd.edu/research/pubs/snowberger-thesis.pdf
deleted 12y ago
[deleted]
wereHamster 12y ago
Container runtimes like docker make it much easier to inspect the application environment and arguments. A short `docker inspect <id>` will show you everything that is relevant to the app (environment, arguments, and much more). One thing not to forget is that env variables are inherited by children, which may be relevant if the app forks.

Someone1234 12y ago

I strongly agree. Often times environmental variables are used inappropriately and make tracking down issues harder due to loss of transparency. Plus environmental variables are context specific (e.g. user 1 and user 2 might have different ones, or server 1 and server 2 might, or this specific script may have re-defined one(!)). A good o' fashioned script with the constants defined at the top, commented, and passed into executables on the command line (so tools like ps or taskman can "see" them) is really easy to debug/alter/monitor. Java and or Oracle's obsession with environmental variables causes more problems than it solves.

realusername 12y ago
I also agree, the only way I would use environment variables is for global configuration like HTTP_PROXY for example, otherwise I still prefer arguments, at least there is no surprises.
- philsnow 12y ago
  I was sad when I learned about this http_proxy environment variable and that things were actually starting to use it. An http proxy setting is no more suited for an environment variable than anything else. I think it should just be a string in a file in $XDG_CONFIG_DIR/http_proxy.conf or something like that.
- mitchty 12y ago
  I agree but I also use DEBUG in my scripts to allow for on the fly debugging to occur. I consider it a degenerate case and its only there for my own use and abuse. All it really does is redefines certain functions to be more verbose or print out debug level information. I had one script that let you do DEBUG=somefunc and it would instrument just that one function. But to be honest it was overkill.

rdtsc 12y ago

Also depending on how those processes are started (as root, from initd, or by hand from shell etc) environment variables might be stripped or incomplete. Environment variables are kind of like global variables a bit. They are easy to set but feel a little dirty. And of course if you use libraries or third party package that rely on them, then you don't have a choice.

deleted 12y ago
[deleted]

bkeroack 12y ago

Environment variables make perfect sense for constants that only, you know, vary with the environment. It's very nice to run the same exact code/artifacts on dev, qa, testing and production. See also: http://12factor.net/ http://12factor.net/

sliverstorm 12y ago
The way I see it, basically variables that are implicit to the machine/network that everyone should be able to infer. TZ, HOST, that kind of thing. Including, of course, similarly implicit custom variables like bkeroack describes.

j_baker 12y ago

Environment variables are useful in their own situations. For instance, OpenShift signals the open IP and Port number as environment variables. Which is useful when you have a program with an unknown set of command-line parameters. Either that or when you only need a subset of the available command-line parameters.

curun1r 12y ago

On the other hand, environment variables are useful for things you specifically don't want showing up in ps. If you've got to supply credentials (passwords, tokens, certificates, etc) or anything else that requires a modicum of security, it's much better to pass those in as environment variables rather than command line arguments.

mercurial 12y ago
It's a lot better to read them from a secure location.
philsnow 12y ago
Please keep in mind this point called out by wereHamster elsewhere ( https://news.ycombinator.com/item?id=8695887 https://news.ycombinator.com/item?id=8695887 ): > env variables are inherited by children, which may be relevant if the app forks If your app forks (or any of the multitude of libraries that it may depend on, check and _pin_ your sources (so they don't add un-audited behaviors)), whatever process it execs probably will get a copy of the environment of your process. Yes, it's possible to clean the environment between the fork and the exec/execve. Do all / most frameworks do so or make it easy to do so? I'm not sure, but would check before making any assumptions about it. I was about to suggest that sensitive information like credentials would better be kept in files that are referred to by name in command line arguments, but... unprivileged users cannot fork/exec a process as a different user, so children could read all the same files as the parent. I can hardly believe it, but a plug for my masters work [0] is actually relevant here. I was interested at the time in the intersection of HCI and security, so I made up this thing called sub-identities that let unprivileged unix users create sub-users. It's a really watered-down version of some actual research that's been around for a while, but the point was, it was easy(ish) for the average unix user to use. I don't pretend that it was anything but a toy, though. All that said, it seems that passing sensitive information in environment variables, squirreling them away in the process space somewhere, then cleaning the environment (all right away, during initialization) would be a smart thing to do. edit: see `man 3 unsetenv` for how to do this [0] http://ccl.cse.nd.edu/research/pubs/snowberger-thesis.pdf http://ccl.cse.nd.edu/research/pubs/snowberger-thesis.pdf

deleted 12y ago

[deleted]

wereHamster 12y ago

Container runtimes like docker make it much easier to inspect the application environment and arguments. A short `docker inspect <id>` will show you everything that is relevant to the app (environment, arguments, and much more). One thing not to forget is that env variables are inherited by children, which may be relevant if the app forks.