Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t use environment variables for configuration

nibblestew.blogspot.com

Post reply on HN
Print view View original

131–140 of 296 posts

Re: Don’t use environment variables for configuration

#131

Post by yrro »

zajio1am wrote: post #106

Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and other tools in it (like unix shell). Yes, if your OS is some unversal JS machine, then JSON would be better, if it is Lisp machine, then you would use S-expressions, but on Unix machine, environment/args are way to go. There are two realistic alternatives - confi…

Why I don't like environment variables:

1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage...

2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems.

I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive' and 'noexport', allowing them to opt out of the default behaviour.

It would have been so say to say "variables starting with _ are not inherited and should be censored when output", but we're about 40 years too late for that to catch on...

Re: Don’t use environment variables for configuration

#132

Post by yrro »

kerny wrote: post #39
mrkeen wrote: post #37

Earlier quoted context omitted.

Any third party code in our system can just read whatever's in the environment and POST it to some remote server.

Any third party code can just read your credentials file and POST it to remote server.

Bold of you to assume my third party code runs with the same UID and SELinux label as my credentials-handling code.

(I wish, it's April 1 after all!)

Re: Don’t use environment variables for configuration

#133

Post by renewiltord »

This makes sense. You can use a config file and a cli param to point to which config file. However, env vars have worked very well for me and so there's this difference between theory and practice. I haven't found the reason but ultimately the model that the AWS CLI uses is very ergonomic (default config < env var < CLI pointer to specific config).

Re: Don’t use environment variables for configuration

#134

Post by yrro »

zokier wrote: post #90
snidane wrote: post #75

Earlier quoted context omitted.

Env vars are a built-in for key-value command line args. Why introduce some custom convoluted way into your app for kv args instead of this standardised approach. I can understand why some heavily used cli app would support a custom parameter pattern, eg. for ergonomics, but for majority of apps running as deployed services and not cli apps invoked 100 times a day, I don't see a reason to not use env args. I can run…

Environ isn't actually key-value, it's only convention that applications (/libraries) parse it in the name=value form. But the underlying mechanism is similar to cmdline: array of pointers to strings. You could parse cmdline same way if you'd want.

It's an exceedingly strong convention. I'd be genuinely curious to learn of non-malways uses for entries within the environment block that don't fit the standard name=value pattern.

Re: Don’t use environment variables for configuration

#135

Post by xorcist »

Good point, not the best arguments. But somebody needs to say this.

Configuration in environment variables are suitable for short options for commands that needs to be inherited to sub-commands. Great for things like LESS and http_proxy.

Suddenly people start shoving all kinds of configuration for a specific instance of a software in environment variables. Often with an argument about how otherwise it's not "twelve factor". That's not great. I mean, it's nice and all, but it's quite literally a blog post from a guy on the Internet, not an argument in itself.

Arguments against putting all configuration for a software instance in environment variables is that it's not suitable for non-ASCII and multiline data for a multitude of practical reasons, the storage space is limited, the actual size will vary for operating systems and overflowing this will not be obvious, and the fact that child processes will inherit this data. If there are keys and other secrets involved, child processes will receive a copy of this.

In comparison, storing configuration in a file will have a much more well defined format, it can be written and copied just like any other piece of data, and the standard tools will control access to it. Things like AppArmor can limit access further to the single process.

Configuration files has been used forever for a reason, it's a reasonable default choice. Environment variables should be used where they are suitable, for interactive tools and for globally shared settings.

Re: Don’t use environment variables for configuration

#136

Post by remram »

mrkeen wrote: post #12
tedk-42 wrote: post #7

Author doesn't know about https://12factor.net and as another commenter mentioned, probably hasn't deployed something to a 'production' environment (or rather, doesn't know about separation of such environments in the first place).

I don't know about https://12factor.net either. But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.

Linux is usually configured to not allow processes from another user to read /proc/$pid/environ. At least a production machine should be.

Configuration files are resistant to this as you note, but command-line arguments are not (--password=1234 will show up in ps for everyone).

Re: Don’t use environment variables for configuration

#137

Post by rocqua »

silisili wrote: post #13

This post seems to ramble without much substance. The best argument, perhaps only valid argument, is lack of an array type. Easy to work around. The rest seems misguided or ridiculous. >There is no way to know which one of these is the correct form What? Of course there is. The author is also calling it mutable global state, and seems to reference an application becoming confused when ENV isn't set. This reads to me,…

To be fair, environment variables are mutable global state across a single shell session.

Re: Don’t use environment variables for configuration

#138

Post by hjek »

erulabs wrote: post #6

I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…

> If the same program is behaving differently between two systems - it can -only- be the environment that’s different.

Yes, but the entire problem is that "the environment" is massive as it includes all hardware and software running on the device in question (and quite possible other devices as the network can easily be considered part of "the environment") which makes it difficult to track down differing behaviour.

"The environment" is not just environment variables. I've run into a spreadsheet bug where I got wrong results because of a CPU bug. Just because some global mutable state exists, that doesn't mean it's a good software design to have program behaviour depend on it.

Re: Don’t use environment variables for configuration

#139

Post by bopbeepboop »

yrro wrote: post #131
zajio1am wrote: post #106

Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and other tools in it (like unix shell). Yes, if your OS is some unversal JS machine, then JSON would be better, if it is Lisp machine, then you would use S-expressions, but on Unix machine, environment/args are way to go. There are two realistic alternatives - confi…

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

How do command line arguments or config files solve either problem?

Re: Don’t use environment variables for configuration

#140

Post by seedie »

darkwater wrote: post #71
junon wrote: post #51

Earlier quoted context omitted.

100% this. The developer behind Prometheus was a huge dick to people about env vars a while back, in similar fashion. Just the other day, they held another closed-doors vote after a year or so and finally decided they were OK. Doesn't surprise me the creator of Meson of all people made the same dogmatic assertion. What a circus this industry has become.

Any link about that? Are you talking about this? https://github.com/prometheus/prometheus/issues/6047#issueco...

It's fascinating how you can do this job for decades and learn about new tools daily. And I mean tools that are here for ages.

I just learned about envsubst https://www.gnu.org/software/gettext/manual/html_node/envsub...

Post reply on HN