6 Replies Latest reply on Jul 8, 2015 2:21 PM by Yanick Girouard

    BLpacakge inheriting an env. variable

    Mike Reider

      BSA 8.5.01 patch 4


      Hello all, is there any way to pass a general env variable or a list of variables to a BLPackage without using local Properties?


      the reason im asking, we have a client who has tons of ksh scripts that they adding to a blpkg and then executing.



      their scripts look for common env variable, lets say INSTALL_PATH (but there are hundreds of vars). It would be an extremely hard task to open up each individual script, figure out what the env.var its looking for, and add it as a Local Property to the blpkg. Is there any way to create a large list of env vars and then have the script natively read a env.var value.


      so for example, on Blade somewhere have a list





      and each script would automatically pick up the env var value. Im pretty sure we cant do this sort of thing unless we specifically pass a Local Property value, but wanted to see if anyone ran into something like this before.


      Heres what the blpkg currently looks like, we add a ksh script as an object, and then run the install CMD. The ksh script contains references to env.variables like INSTALL_LOCATION that doesnt exist in the shell. Unless we open up each script and add the env var explicitly, it doesnt know the value. (and there are hundreds of these scripts). The reason the scripts dont have the env value set is because they were previous deployed using Opsware automation tool that has this feature to pass a list of env vars to its scripts.



        • 1. Re: BLpacakge inheriting an env. variable
          Bill Robinson

          "like INSTALL_LOCATION that doesn't exist in the shell." -> do you mean doesn't exist in the shell the blpackage creates for the external commands, or doesn't exist in a login shell.  if the later, what is setting the env var if you are not driving the scripts w/ an automation system?

          • 2. Re: BLpacakge inheriting an env. variable
            Mike Reider

            Hi Bill, if you have a Blpakg with 2 ext commands, if the 1st command sets an env. variable (export LOCATION=/tmp), the 2nd ext command has no access to that variable (echo $LOCATION, null), I tested this, it returns a null value.

            The scripts that we are pacakging are expecting some sort of a env var to be set, like LOCATION=/tmp for example


            Before running the script I wanted to have 1 single ext cmd to set any possible env vars that these scripts are looking for (lets say its 10 vars), so I can reuse this blpkg for every script, so I would have something like this:


            1st ext command declares all the necessary env var and then I just replace the actual script object in the blpkg for each script that I need to automate..


            and then have the install cmd execute. For any additional scripts, all I have to do is replace the .ksh file in the blpkg but the rest of the items are the same. This wont work because anything following the 1st ext.cmd. has no access to these variables.


            The only way this will work is if I move all these env vars to the 'install' ext.cmd at the bottom, and then run everything in the same step. Its very messy way to pass variables because if I have more than 1 install ext.cmd (like Pre-Install or Post-Install), every step needs to have these variables re-initialized.

            • 3. Re: BLpacakge inheriting an env. variable
              Bill Robinson

              So how do you normally set these env vars w/o an automation tool ?

              • 4. Re: BLpacakge inheriting an env. variable
                Mike Reider

                the customer is migrating from another automation tool that sets has the ability to set these vars globally before running any packaged scripts. Each subsequent script thats run can see these vars, I think the way it executes the whole thing is in 1 shell session.  With a  BLPkg each step or ext.cmd. needs to have its vars/properties re-initialized.


                We came up w a workaround by basically adding all these env vars into the 'install' step so the script 'sees' the variables when it runs since its part of 1 single ext.cmd. But again, its abit messy.

                • 5. Re: BLpacakge inheriting an env. variable
                  Bill Robinson

                  It’s a good ‘idea’ to create..


                  You could have 1 ext cmd that dumps the vars to a file and then source the file in each ext cmd before calling the scripts.

                  • 6. Re: BLpacakge inheriting an env. variable
                    Yanick Girouard

                    You should use Type 3 NSH Scripts to run the ksh scripts, instead of using BLPackages. That's what this type is made for. That way you can pass parameters, and it's executed with nexec under the covers, so it will be just as if your script was called locally by root.


                    All you need to do, is add the ksh to the depot as a NSH Script, and select the 3rd bullet from the type selection.


                    EDIT: Sorry I skimmed your question too fast, I see why you need this. What you could do then is to dump the variables to export to a .ksh file, and to source it from the next command. Example:


                    Ext command 1:


                    echo "export VAR1=val1" > /tmp/PACKAGE_NAME.exports

                    export VAR2=val2 >> /tmp/PACKAGE_NAME.exports


                    Ext command 2:


                    source /tmp/PACKAGE_NAME.exports

                    ...do whatever you want next

                    ..and if you can't edit some of the scripts requiring those variables, then just call all your steps from the same external command so they are all spawned by the same shell...