What I am doing now at the OS level:

Upon initialization, change to the user that needs the variable and export the variables then also specify setting them in the profile-- or in /etc/environment (Debian) in the case of root to account for persistence

I do a lot of this via "echo >>" or "sed" to the config files directly or into a directory the main config looks into for settings.

For me:

export MYVAR=foobar echo "export MYVAR=foobar" >> /home/bradchesney79/.profile

The top one makes the environment variable available upon execution, but it will be gone when you log out. Putting the command in your .profile will create it for you when you log in.

sed -i s/export MYVAR=.*/export MYVAR=barfoo/g /home/bradchesney79/.profile

For you:

sudo -u brianchesney80 export HISVAR=something sudo -u brianchesney80 echo "HISVAR=something" >> /home/brianchesney80/.profile

For everyone:

((Not fully certain how to export globally just yet)) sudo echo "OURVAR=fffoooooobbbaaarrr" >> /etc/environment

I don't like to reboot. But, I don't see any way around it to enable the environment variables set here for everyone.

So, want to see environment variables for a different user?

sudo -u www-data printenv PATH sudo -u www-data env

A nice concise list provided by env not enough? Try:

set > /tmp/setOutput.tmp

Environment variables (Ubuntu)

Environment and Shell Variables

Making the environment variables available to PHP:

Worth noting is that the environment variables are not naturally available to services that are daemonized as they are not started traditionally as a child process that would inherit the parent's environment variables. Keep that in mind that this is a security barrier put in place for very good reason (that environment variables would be shared indiscriminately isn't necessarily a good thing.). My goal is to selectively make certain testable environment variable values available so my system behaves differently or with the right credentials set and available for the app in a variable-- all this at instantiation via a provisioning script and some of it persistent between reboots.

Apache

Example:

export PATH="/var/www:/var/www/html"

Neat snippet, you can check the validity of your envvars file with it.

sh -n /etc/apache2/envvars && echo Syntax OK || echo FAIL

There were some settings in /etc/apache2 (Debian) I think I could use in the virtualhost block...

Example:

SetEnv SPECIAL_PATH /foo/bin

The above in the server virtualhost configuration block will make a custom environment variable available via $_SERVER or similar convention somewhere as mentioned by TMR humoring me in the comments.

Apache httpd mod_env

Elsewhere in the httpd.conf file and similar or .htaccess you can set environment variables via rewrite rules.

RewriteRule someurl - [E=dbpass:swordfish]

Apache Rewrite abuse... If you gotta, you gotta I guess. I don't like .htaccess files in general though, not a fan of rewrite either.

NGINX

It appears you may be able to leverage a lua NGINX module to insert environment variables into the server. This other module also needed.

That being said, this being focused on PHP-- if you are using nginx with PHP-- maybe look at the PHP section below which may be a better solution.

env PATH; http { ... server { location /path { set_by_lua $path 'return os.getenv("PATH")'; ... } } }

NGINX mailing list thread sparking the possibility

Blog post about using lua in full

PHP

get-cfg-var() will allow you to retrieve values set by the PHP project developers-- and arbitrary values you set. It is worth bearing caution to be careful naming these variables in the global scope this way and be sure to read the user contributed notes to be aware of some automagical mangling.

Example:

php.ini

environment_type=dev environment_host=AWS

rando-script-whatever.php

get_cfg_var('environment_type') // returns 'dev' get_cfg_var('environment_host') // returns 'AWS'

In a php-fpm pool configuration file the below will make a custom environment variable available via $_SERVER or similar convention somewhere as mentioned by TMR humoring me in the comments.

Example:

my-pool.conf

env[FOO] = bar

rando-script-whatever.php

echo $_SERVER['FOO']; // returns 'bar'

Summary

What: The end result I am seeking is that I can script standing up a server. Due to weaksauce I have an ansible wrapper and run more bash scripts than I would like to admit. Regardless, I want to set certain variables at the OS User level and have them propagate down to help me more or less 'anonymize' my web application codebase.

Why: The benefit is that a lot of particulars like RSA keys for authentication (yes, they fit in an environment variable), passwords, and other "secrets" stay out of the code base-- You've moved all these "secrets" to the provisioning scripts and obviously on to the running server employing low level access controls. nothing needs changed in the code a developer touches for the web application to run. Any configurations or deviations can be checked and handled. Write once, deploy everywhere with confidence everything is very similar if not the same. The provisioning script automagically puts the right DSN user, host, and password for connecting to your database in an environment variable; those PHP variables that refer to the environment variables just pick up the right values from the get go.

How: And here is my question. What steps and technology do you employ if you already do this?

Edits:

tl;dr - removed a controversial provisioning idea distilling to one succinct question topic

I have removed mention of detecting things about the host and provisioning the server based upon the findings. It has been strongly suggested that this way of provisioning a server may be a poor strategy and that provisioning tools are designed to declare the settings instead of the target host discovering things about itself upon instantiation and reacting appropriately. --And, most importantly, it is secondary to the task at hand. I want to know more about storing particulars that might change in environment variables which is awesome.

-Specifially mentioned by AnrDaemon was breaking the principle of least surprise.