Any environment variable prefixed with "FACTER_" is automatically added to the facter collection. I've successfully added a "FACTER_" environment variable it is indeed showing up in the facter -p list, so it should be able to be used by puppet...
The problem, though, is in my .pp file the variable name that should be set to the FACTER_ value is empty (or non existant)
Is there something else I need to do to get FACTER_ variables into puppet variables?
Cheers
You are most likely setting up the system so that the FACTER_ variables are available in interactive shells. This is not sensible if you want your background agent to respect them.
I can see two direct approaches:
Modify your initscript or its configuration to set the appropriate environment variables.
Forego the approach entirely and use /etc/facter/facts.d instead.
I would advise towards the latter.
Related
I am using the Config crate in Rust, and would like to use environment variables to set keys inside a section of the config. The end goal is to override application settings from a docker compose file, or docker command line, using the environment.
If my config was the following, could I use a specifically crafted environment variable to set database.echo ?
(code blurb below is taken from this example)
debug = true
[database]
echo = true
The example code to configure this using the environment variables illustrates only to set keys at the top level. Wondering how to extend this. The .set() takes a hierarchical key, so I'm hopeful that there's a way to encode the path in the env variable name.
Answering my own question.
I just noticed that the Environment code accepts a custom separator which will get replaced with . (dot).
So one can set the separator to something like _XX_ and that would get mapped to a ".". Setting DATABASE_XX_ECHO=true, for instance would then change the database.echo key.
I need to use a variable between node modules folder and src folder.Is there a way to use a variable to be used within the whole project?
Thanks.
Typically this is done with process environment variables. Any project can look for a common environment variable and handle that case accordingly, as well as the node modules of said project. As long as they agree on the name, they all share the same environment. Have a good default, don't force people to set this environment variable.
The environment can be set using an environment file (do not check this into source control!), on your container or cloud configuration, or even right on the command line itself.
TLOG=info npm test
That is an example that I use frequently. My project runs logging for the test cases only at alert level - there are a lot of tests so it makes the output less verbose. However, sometimes while developing I want to see all the logs, so my project is looking for an environment variable TLOG (short for "test logging") and I can set it just for that run! Also no code change is needed, which is nicer than JavaScript variables that need to be set back to original values, forget to be turned off, etc.
I have installed Java through some cookbook and have set some default variables, now I want to add some more variables (Application specific) through my cookbook. How can I do that through Recipes in Chef. I tried to pass some variables in setenv.sh but it is overriding the default values instead I want to merge the variables and override existing variable values.
My code in setenv.sh:
export JAVA_OPTS="$JAVA_OPTS -Xmx2048m"
where $JAVA_OPTS - default variables
First way to do it would be to update the attribute defining the bases values in your application cookbook, as the attributes are read before the recipes are evaluated your file would end up with the correct values.
You're not saying with which cookbook you're using so I'll base the example on the tomcat cookbook
This cookbook define an attribute default['tomcat']['java_options'] = '-Xmx128M -Djava.awt.headless=true'
The easiest way it to complement this by using something like
default['tomcat']['java_options'] = "#{default['tomcat']['java_options']} -Xmx2048m"
The obvious problem is that you end up with 2 -Xmx values, usually the JVM will take the latest but it become hard to find what options is at which value when there's a lot of overwriting.
Second option is to take advantage of jvmargs cookbook wich gives helpers functions to deine the java options and use in your setenv.sh template at end.
I'm trying to use the sshrc to execute fish with my own defined functions at the remote server.
I know there is a $fish_function_path variable that I can modify to prepend my custom path with my functions, but this variable seems global and I don't want to affect other fish users.
Is there any way to change this variable only for my single fish session or any other ways to use my fish functions only for a single session?
I have also tried setting and environment variable from the outer shell: fish_functions_path="$MY_FUNCTIONS_PATH" fish but it seems environment variables don't affect those inner variables of fish.
Used this docs.
Thanks!
Global variables, including $fish_function_path, are per-session. You might be thinking of universal variables, which are shared across sessions for a given user.
It should be fine to modify $fish_function_path for a given instance of fish - it won't affect any others.
What is the typical use-case for adding --prefix support to a scons build?
Currently I use Variables to persist user options from the command-line, but that requires I use the name PREFIX to be recognized as a variable. The docs show a way to specify the preifx using AddOption but then this option must be specified everytime scons is run: it isn't persisted like the variables.
What is the typical way to handle this?
You will need to use Add/GetOption to create an option the user can provide on the command line.
After, yous users will need to set the environment variable SCONSFLAGS with options they want to provide to SCons everytime. SCons will read this variable everytime.
http://www.scons.org/doc/2.0.1/HTML/scons-user/c2076.html
It's not a good idea to have many environment variable on the user machine because you lost the documentation and which variable you really need to compile.