I'm trying to export factor system variable using Mcollective shell agent. But once check the factor list new variable is not set properly. What could be the reason here ?
Setting this variable though puppet is not possible as puppet catalog run lookup for this custom factor and then resolve the node. So the facter variable must be set before puppet run.
Is there any other Mcollective agents which could use for this purpose.
mco shell run "export FACTER_deployment_pattern='pattern2'"; factor
[ ============================================================> ] 2 / 2
puppetagent:
qaa-node-5:
Finished processing 2 / 2 hosts in 146.06 ms
The exported environment variable would only be available to processes spawned by the shell spawned by this command. In other words, it doesn't really do anything because it spawns a shell, sets an environment variable, then the shell exits.
In order to create a Facter external fact that is actually available to other processes you can create a file in a path dependent on your installation.
Related
I would need clarification on jmeter.sh and jmeter file without ext ,which are in bin folder.
With example:
1.If i setup different HEAP size in jmeter and jmeter.sh file,which one will be considered.?
2.Does the above depend on how i run the test?(for ex: jmeter -n -t or jmeter.sh -n -t)
3.If the test started with jmeter command instead of jmeter.sh ,will intern jmeter.sh be called and hence heap in jmeter.sh be used or vice-versa?
related question to the difference b/w jmeter.bat and jmeter-
difference between jmeter.bat/jmeter.sh And jmeter.file
jmeter.sh is a wrapper for jmeter script (without extension) which does some pre-requisite validations like getting current working dir, getting Java version, constructing arguments depending on Java version, etc. so you'd better use this file for running JMeter under Unix and derivatives
jmeter is a wrapper for ApacheJMeter.jar binary, it sets default JVM arguments and overrides and adds more Java arguments depending on your operating system
The sequence is the following:
jmeter.sh calls jmeter
jmeter calls ApacheJMeter.jar
If you want to change HEAP or whatever - set the appropriate environment variable like:
HEAP=4G && export HEAP && ./jmeter.sh -n -t /path/to/test.jmx ...
More information: How to Get Started With JMeter: Installation & Test Plans
jmeter.sh calls jmeter, both unix scripts , jmeter is the main/default script
jmeter
run JMeter (in GUI mode by default). Defines some JVM settings which may not work for all JVMs.
jmeter.sh
very basic JMeter script (You may need to adapt JVM options like memory settings).
You can set before running both the JVM_ARGS
It may be necessary to set a few environment variables to configure the JVM used by JMeter. Those variables can be either set directly in the shell starting the jmeter script. For example setting the variable JVM_ARGS will override most pre-defined settings, for example
JVM_ARGS="-Xms1024m -Xmx1024m" jmeter -t test.jmx [etc.]
will override the HEAP settings in the script.
I am trying to create some new env variables in the rhel machine using chef.
The block executes successfully but on trying to echo the value, i am getting black result.
Script-1:
execute 'JAVA_HOME' do
command 'export JAVA_HOME='+node['java']['home']
end
Script-2:
bash 'env_test' do
code <<-EOF
echo $chef
EOF
environment ({ 'chef' => 'chef' })
end
Also gave this a shot as it was mentioned in the documentation:
ENV['LIBRARY_PATH'] = node['my']['lib']
Please let me know where am i going wrong here..
So the thing you need to know about environment variables is they only work in one direction (parent process to children) so an export in a subcommand does nothing after that execute resource finishes. The second and third examples both work though, with the second setting it for just that bash resource and the third for both the Chef process and everything it spawns. Remember that you need to run with with -l debug to see the output from subcommands Chef runs.
Above explanation is pretty helpful. Updating the /etc/environments file using chef to make sure that env variables are present from the next session. Also using the 3rd approach to make the env variables available for the current session.
I have a node process that uses an environment variable in the form SECRET_KEY=1234.5678.910112.
This works fine if set using export in my bash_profile and the process is run directly in the shell.
But when running it using supervisor the script only picks up the part before the first period. This is the case either when reading env vars set in bash_profile or set using environment= in the conf file.
Turns out all I needed to do was to add single quotes around my variable. I did do this before but didn't run supervisorctl reread to get the new config.
I am using Go server for continuous integration of our code. For my environment-deploy-template, I wish to set certain environment variables on the stage and then echo those in the property files for the application. What would be the Linux command that I could give in my job to do so?
For example, it could be some thing like :
echo "propName=#{env variable}\n">>prop files location
Could someone please confirm this?
The syntax to get go.cd env variable is ${ENV_VAR} and a full command is:
echo propName=${ENV_VAR} >> props.txt
More details on environment variables: Using Environment Variables in Go
When I run
sudo puppet agent -t
after a long phase of catalog loading, I get a message:
info: Applying configuration version '1403590182'
What is that number 1403590182 referring to?
In fact I have noticed that if I run twice in a row sudo puppet agent -t, I get different configuration version numbers even if the modules have not changed!
How can I determine which version of each module is being applied to the node?
from the documentation config_version
How to determine the configuration version. By default, it will be the
time that the configuration is parsed, but you can provide a shell
script to override how the version is determined. The output of this
script will be added to every log message in the reports, allowing you
to correlate changes on your hosts to the source version on the
server.
Setting a global value for config_version in puppet.conf is not
allowed (but it can be overridden from the commandline). Please set a
per-environment value in environment.conf instead. For more info, see
https://puppet.com/docs/puppet/latest/environments_about.html
The time is represented as a unix time stamp as such yours indicates "06/24/2014 # 6:09am" (and i just realised how old this Q was)
If the manifests are git controlled the administrator can let the Puppet master know how to describe the version with the statement below in /etc/puppet/puppet.conf (on the Puppet master). One such statement goes in each environment section with the path adjusted to where the environment looks for manifests.
config_version = git --git-dir $confdir/modules/production/.git describe --all --long
If you use some other version control system i'm sure there's some equivalent command to get an indication of the revision.