6 Replies Latest reply on Aug 9, 2012 7:51 AM by Bill Robinson

    Dynamic Path in Component Template

      I want to be able to use the value from an EO, Config File Entry or Registry Key Value in a component template/compliance rule.  Say for instance I want to check a file version for some application, but that application can be installed anywhere.  The install location is generally stored within the uninstall key for an application, so I can use that key to determine the path I want to search (I use this in scripts all the time instead of assuming I know where something is).  Being able to set a local property to one of these things would be extremely useful.


      However, currently there's no way I know of to get that information into the component template except through server properties (other than to use it for a compare/check).  Rather than create a slew of different server properties, I'd sure like the ability to use a value from an EO, Config File or Registry Key Value like a variable within a component template.  Being able to do this would make things a lot simpler when dealing with dynamic paths.


      If anyone knows of a way, please let me know.  Otherwise, I suppose I'll go draft an RFE...



        • 1. Re: Dynamic Path in Component Template
          Bill Robinson

          you can create local properties and instances in the template for this.  the best way is to write a nsh script to 'find' all the stuff you want, run some blcli to setup the property values / instances and then run discovery and compliance w/ the template.

          • 2. Re: Dynamic Path in Component Template

            I would love to be able to set local property values/instances on the fly.  Are you saying to update the template as part of a “component install” batch?  The only problem I foresee (other than I have no idea how to do this with blcli) is permissions.  Our users do not have modify rights to our templates…


            It’s not a huge need at the moment, I can use other things to verify an application is healthy, but there’s times when being able to check a file version in an unknown location would be extremely handy.  Like for instance when only a file version changes as part of a patch/upgrade.


            For the most part, apps are installed where they should be, but not always, so I prefer to not assume (I’ve seen some admins redirect their %ProgramFiles% and/or %ProgramFiles(x86)% paths to non-standard locations).

            • 3. Re: Dynamic Path in Component Template
              Bill Robinson

              So what you would do is something like this:


              Nsh script to find the install dir of your application.

              Blcli command in that script to add that as an instance in the CT.

              An EO that takes that path as input and runs whatever you need to get a version or use the install path as a property that points to some file or whatever

              Compliance rules that use the parameterized paths

              You run discovery to find all the instances of your apps – maybe multiple per box,maybe not

              Then run compliance, targeting the components.


              I think I have an example of this w/ oracle from a while ago if that would be helpful.

              • 4. Re: Dynamic Path in Component Template

                An example would be good...I am not dealing with "instance" applications, but whatever you've got may help.



                • 5. Re: Dynamic Path in Component Template

                  Use BLCLI help to assist you.


                  Sample create instance

                  Template createParameterInstance Apache /Applications/WebServers/Unix Dev "Development Environment Values"


                  Sample set instance property value

                  Template setParameterInstanceOverriddenValue Apache /Applications/WebServers/Unix Dev install_dir "/opt/apache/dev"

                  • 6. Re: Dynamic Path in Component Template
                    Bill Robinson

                    we had some offline discussions - so i think he just needs to create a local EO that gets the info he needs, and then target some compliance rules at that output.  the "but that application can be installed anywhere" typically triggers the "you need to use local parameter instances" thought, but in this case, since there is only a single instance per system and he can pull the install location from a know reg key, the EO can do that (w/ reg or blquery) and then run whatever needs to be run.