6 Replies Latest reply on Jul 16, 2014 8:28 AM by David Muench

    Using Component Property Set Instance across multiple servers

      We are deploying BSA compliance for tcServer.   We have key design decision on how to deploy manage discovered instances of tcServer.  Ideally we want to deploy a standard architecture for all servers.

       

      One approach we are investigating is using with the BSA Consultant is to have PSI(Property Set Instances) to contain all instances for all servers of tcServer across the organization. 

       

      TC-Server Compliance Template

      Under Local Properties:

      - Property Set Instances(instance names):

      • Server1-PROD-APP1
      • Server1-PROD-APP2
      • Server2-QA-APP1
      • Server2-QA-APP3
      • Server3-Dev-APP1
      • Server4-PROD-APP6
      • ..up to 1000+

       

      I am fine with this suggested approach; though reading docs.bmc.com it states to use local instances for a single server.  The main issue I've seen is duplicate instance names when deleting and re-adding.  What is the benefits/pitfalls of this design?  Is this something that can scale to 1000+ property set instances?  Will it be manageable? 

       

       

      From docs.bmc.com

      • Local Properties — Specify properties you can assign directly to a component template. Local properties let you discover multiple instances of the same component on the same server. For example, on a single machine you may want to create two versions of the same component --- one for development and one for QA. In such a case, you can use two instances of a local property, with each instance defined to the values you need. A Component Discovery Job automatically discovers a component for each of those local property instances.
        • 1. Re: Using Component Property Set Instance across multiple servers
          Bill Robinson

          Where is this on the docs site?

           

          What would make sense to me would be to create the psis in a custom class in the property dictionary, then create a local property in the template (and/or blpackage) w/ the type of the custom class you created to hold the PSIs.

           

          How different are the configurations on each server?

           

          are the differences something that can be derived based on something on the server?

           

          why would you have duplicate instance names ?

          • 2. Re: Using Component Property Set Instance across multiple servers

            location of psi documentation:

            'https://docs.bmc.com/docs/display/public/bsa83/Component+design

             

            How different are the configurations on each server?

            • For tcServer, the majority of the population is pretty standardized.

            are the differences something that can be derived based on something on the server?

            • The differences can all be retrieved from the server.   We've create a configuration xml to do our compliance rules

             

            It sounds like duplicates come from poor cleanup of deprecated psi's.  Because we are using component instance name for each server, we had to make a unique key of server-path-to-app.  While testing, i have been recreating these with different local properties; that's where i am having issues.

             

            I have many multi-instance database and middleware and am looking for some common way to manage them.   I will look at property dictionaries.    If we leverage property dictionaries with the psis for all servers/all instances, how do we report on findings for each ind. instance.


            • 3. Re: Using Component Property Set Instance across multiple servers
              Bill Robinson

              yeah - so normally you would create a custom property class in the property dictionary.  the class would contain the properties your application needs. you would create an instance for each environment or some other logical grouping and then in your template you would point to that class and reference the properties like LOCAL_PROP.CUSTOM_PROP.

               

              so the wiki page was still correct, it just didn't mention the common practice about creating a custom class vs keeping it all local.

               

              so i'm still not clear why you are creating a psi per server.  so if you have an application from 2002 i might make a custom class like:

              My_APP

              \ Database

                   | connect_string

                   | user

                   | pass

              \ appserver

                  | maxheap

                  | somejavaarg

              \ webserver

                 | port

                 | htdocs

               

              then i would have a few PSIs in each class that would have the custom values for that psi, and the psis would be like dev, test, prod.  then if it's a prod appserver, you can associate that PSI w/ the template, blpackage, etc.

               

              when you say 'report on findings' what do you mean ?

              • 4. Re: Using Component Property Set Instance across multiple servers

                Great stuff... Did some research today.  We are using templates for security(PCI) and configuration compliance.   So in this context we want to report on security findings by server and instance.     Having separate psis was one way of accomplishing this.

                • 5. Re: Using Component Property Set Instance across multiple servers
                  Bill Robinson

                  right - so for any kind of compliance check, your PCI template would need to be 'app instance' aware.  so as an example, let's say i have some web app that's installed in /myapps/<app1|app2|app3>/blah.  you would have a property like 'APP_PATH' w/ values of 'app1', 'app2', 'app3' set in three different PSIs (along w/ other per-app config), then your discovery condition for the template would be /myapps/??APP_PATH?? exists.  so that would create the multiple instances of your application, then you would target your compliance job to each component.  your rules would need to include the parameterized path too - so if the check was that some properties file has certain permissions the rule would be like /myapps/??APP_PATH??/blah/file.properties perms = xxx

                  • 6. Re: Using Component Property Set Instance across multiple servers

                    Just wanted to thank you guys for explaining this, I was able to follow along and now have a script that creates PSIs to find my app that is installed in various places. I was then tripped up on deploying a blpackage to these components using the APP_PATH property, but found this which solved it:

                     

                    How to deploy a package relatively to a component

                     

                    Thanks again.