Showing posts with label scripting. Show all posts
Showing posts with label scripting. Show all posts

Sunday, April 13, 2014

Reading Environment Variables in Puppet

Puppet uses a tool called Facter to discover facts about the system it is going to provision. Some examples of these facts are: $operatingsystem, $hostname, $processorcount, etc. These facts are available as variables in puppet to use in manifests. You can see the full list here: Factor 2.0 Core Facts.

If you want an environment variable, or a bash script parameter to be available to puppet, you need to make it available as a Facter fact. You can do that by simply setting a variable whose name is prefixed with the "FACTER_" string.

So for instance, if you wanted to make a variable called say $my_module_name available within puppet, and wanted its value to be equal to environment variable PRODUCT_MODULE_NAME, you could do the following in a bash script that invokes puppet:

export FACTER_my_module_name=$PRODUCT_MODULE_NAME

Now, $my_module_name variable will be available within your puppet manifests.


Setting a Default if Environment Variable is not set


To take this further, if you wanted your puppet variable to have a default value, if no environment variable was set, you could specify it in puppet manifest (.pp) file like this:

$module_name = $my_module_name ? {
      undef => "Admin_Module",
      default               => $my_module_name 
}

Note that the above code uses a different variable name called "module_name", whose value will be set to "Admin_Module" if $my_module_name is un-defined, else it will be set to value of "my_module_name" variable.
Now you can use $module_name in all your puppet manifests (instead of using $my_module_name).

To see a sample code where I did this in Bahmni Hospital Management System provisioning scripts, check out this Github commit: Example.

Tip: If you wish to debug what facts are being set in your system, you can use this snippet to print all facts to a file: Printing all puppet facts.

Tip: If your puppet script is running with "sudo", then the environment variables set in current environment won't be passed to the sudo environment. If you want that, then use "-E" switch with sudo to pass environment variables forward.


Saturday, March 1, 2014

Autojump: A neat command line utility that saves me tons of time

Autojump is a really neat utility that complements the cd command very nicely. For instance if I have a folder called "my_project", I can just say "j project", and the auto jump command will directly jump to this directory (wherever it is in my filesystem).

How does it work?

Autojump tracks how much time you spend in your command line on a specific folder. And builds a weight chart. So, if you have spent enough some time in your my_project directory on command line, and you say "j project", it will check its registry and jump to the highest match. And, the best thing is you don't even need to specify the full name. Partial names work!

Autojump in action

Install zsh. And install autojump. You will see a super productivity increase on command line.

Platforms Supported: Linux and Mac.

To install on Mac:
brew install autojump
And then copy the single line printed by brew install into your .bashrc or .zshrc file. After that go to command line, cd into a directory. Then cd to some other directory. And type "j ". You will see it work! 

Thanks to my colleague Ankit Dhingra for introducing me to auto jump. Goodbye to cd aliases.

Related Links:
https://github.com/robbyrussell/oh-my-zsh
https://github.com/joelthelion/autojump




Wednesday, May 26, 2010

Pausing an ANT Build on error

Quite a few projects have multiple interlinked build scripts for creating a product build. For instance a complete build might involve compilation of the code, packaging the properties/config files, UTF-8 conversions, documentation generation, installer generation, etc. Each of these might be separate ant scripts or commands. If a build fails anywhere in-between it would be great if the build process is PAUSED so that one can easily see the exact failure point.

One way to achieve this if you are using ANT, is to modify the ant.bat file that ships with ant in the bin folder.

Just below this line:

:runAntWithClasspath
"%_JAVACMD%" %ANT_OPTS% -classpath "%ANT_HOME%\lib\ant-launcher.jar" "-Dant.home=%ANT_HOME%" org.apache.tools.ant.launch.Launcher %ANT_ARGS% -cp "%CLASSPATH%" %ANT_CMD_LINE_ARGS%

Add the following lines:

if %ERRORLEVEL% == 1 (
ECHO =============================
echo. Ant Build Error
Echo Return Code = %ERRORLEVEL%
ECHO ==============================
PAUSE
)