Don’t use environment variables for configuration • Hacker News Board

Re: Don’t use environment variables for configuration

#201

Post by sdevonoes » Thu, Apr 01, 2021, 4:42 PM UTC

bayindirh wrote: post #108

zabzonk wrote: post #99

Earlier quoted context omitted.

> These methods are being used for decades and well understood with all their advantages and disadvantages. Just because something has been used for decades does not make it good - for example, avoidable mutable state. And it certainly does not make it well-understood - as a consultant the number of brain frying environment variable configurations I've had to deal with which no permies could tell me anything about de…

> Just because something has been used for decades does not make it good. I'm not calling this is good with the persistence of the original author. I tell that it's one of the realities that we have, and instead of burning it with torches, why not build better conventions around it with better attitude and language? Maybe we can try: "Instead of burying all config under environment variables, why not try doing it lik…

> But, shunning it with anger and shouting "I'm the one who knows all right things!" sure creates backlash, like here.

I think this is relative. I did read the post as well, and I didn't find the author with such a "negative" attitude (but then again, I'm not American).

Re: Don’t use environment variables for configuration

#202

Post by klyrs » Thu, Apr 01, 2021, 4:42 PM UTC

The old guru I learned Linux from always said: "The bugs I've spent the longest time tracing down have always been caused by environment variables. It was only when I started checking them first, rather than last, that I felt competent as a sysadmin."

Truth is, you aren't going to get rid of them unless you make an operating system that doesn't have them (and good luck porting anything useful to it). This is poor advice, because it amounts to FUD -- those problems won't go away, but in telling people to avoid environment variables will quash their curiosity about them. This teaches people to only look to the environment last.

Re: Don’t use environment variables for configuration

#203

Post by merciBien » Thu, Apr 01, 2021, 4:44 PM UTC

ajarmst wrote: post #144

This attitude is how we ended up with Active Directory. One assumes that the author doesn't spend much time in a command-line environment. The option to set defaults for one's normal working environment is obviously of value, and environment variables are hardly exclusive of configuration files (~/.bashrc, makefiles, ...). The theory that complex syntax and statelessness are inherently good and cost-free is naïve to…

@ajarmst is that last related idea you quoted your own? That’s a powerful expression of how I see human culture: question everything, but remember to respect the ideas of the people who came before you. There might be a baby in the bath water you’re discarding.

Re: Don’t use environment variables for configuration

#204

Post by nikisweeting » Thu, Apr 01, 2021, 4:44 PM UTC

The title should be "don't sprinkle environment variable reads all over your codebase", not "don't use environment variables".

The problems proposed are easily fixed by:

1. read all your env vars at startup in a single function, then pass them down from there

2. don't invent your own serialization format, just use json or csv, both work fine in env vars. or use the env var to reference a file path that contains more complex values.

As a devops engineer / sysadmin for going on 10 years now, I pretty strongly disagree with this article. Environment variables are so much better than the alternative.

In the past, programs frequently invented their own configuration loading systems, but over the last few years containerization has strongly nudged most programs towards accepting env vars. The result has been a better, more consistent, and less surprising config experience for everyone, even non-container users.

Re: Don’t use environment variables for configuration

#205

Post by gnulinux » Thu, Apr 01, 2021, 4:45 PM UTC

kodah wrote: post #187

ajarmst wrote: post #144

This attitude is how we ended up with Active Directory. One assumes that the author doesn't spend much time in a command-line environment. The option to set defaults for one's normal working environment is obviously of value, and environment variables are hardly exclusive of configuration files (~/.bashrc, makefiles, ...). The theory that complex syntax and statelessness are inherently good and cost-free is naïve to…

On the facade environment variables may seem like they're orthogonal to global variables but they're not. Environment variables are scoped to the current process. This could be your shell, but it could also be a web server. This doesn't make them leak proof, but unlike global variables, environment variables have a scope. Environment variables are also used more widely as an API. Many CLIs have a command that when se…

I don't get this. From the same perspective you can argue global variables have scope too since they are "scoped to the current process". It's not like other processes can access your global variable, that's a very low bar for a scope.

Re: Don’t use environment variables for configuration

#206

Post by Communitivity » Thu, Apr 01, 2021, 4:46 PM UTC

I've always used a mix of environment variables and a set of config files for my apps. Often the vars determine which config files are loaded, which mode the app operates in (expert,normal,beginner), and debug level. I never put security information in the env variables. I also always treat vars as unvalidated user input (i.e., apply sanitization and validation).

Re: Don’t use environment variables for configuration

#207

Post by sdevonoes » Thu, Apr 01, 2021, 4:47 PM UTC

junon wrote: post #50

Oh this guy again. This guy created Meson and has a pattern of being 1) Quite toxic and 2) Entirely dogmatic when it comes to software design. He shows no interest in discussing design problems with Meson and asserts his viewpoints as truth and fact, resorting to snide comebacks instead of having thoughtful conversation. Doesn't surprise me he wrote an article like this. Completely misguided and isn't rooted in reali…

It surprises me that people put more attention to the author than to the content. I have no idea who the author is, but his post doesn't seem to me toxic at all nor dogmatic.

On the other hand, your comment sounds a bit toxic, to be honest: "because the author is X it must be that all of his articles are X as well".

Re: Don’t use environment variables for configuration

#208

Post by icedchai » Thu, Apr 01, 2021, 4:47 PM UTC

amelius wrote: post #197

Another nice one is chdir() and how it behaves between threads.

When you realize threading was added on late in the game with Unix, this is hardly surprising. Unix is process oriented.

Re: Don’t use environment variables for configuration

#209

Post by noisy_boy » Thu, Apr 01, 2021, 4:49 PM UTC

kmstout wrote: post #95

I was taught many moons ago that configuration, like ogres and onions, is best considered in layers: 1. default values: What will most users in most places find most useful/least infuriating? 2. configuration files (system-wide, then user): What will most users on this system want most of the time? What will this particular user want most of the time? 3. environment variables: How should this session (i.e., a potenti…

This is precisely how I setup my utilities. I have found following practices useful:

1. Print the path of the system and user level configurations that the utility honours in the help text (-h/-?)

2. For an option that can be set interactively or via environment variable, specify the environment variable name in the help text itself to provide maximum choice to the user.

3. Provide a -viewconfig option that prints out the final resolved configuration state so that the user can see the actual configuration that is in effect. Combined with a -dryrun option, this can provide a lot of confidence to the user to try out things without breaking anything.

Re: Don’t use environment variables for configuration

#210

Post by Someone » Thu, Apr 01, 2021, 4:49 PM UTC

PeterisP wrote: post #172

hajile wrote: post #162

Earlier quoted context omitted.

It's also easier to encrypt a config file and provide the decrypt key externally.

So then the real secret is the key, which is provided "externally" ... how? Through command line parameters, some other config file, or environment variables? :P

A file that’s protected appropriately or standard input.