I have a target system and I would like to collect a configuration file and store it in TADDM so I can run change history to see when it changes.
There are three scenarios applicable to this question;
1. You want to collect a configuration file for an application, such as Websphere or DB2 and you are discovering this application via an out of the box TADDM sensor.
2. You want to collect a configuration for a custom application for which you have created a custom server template for.
3. You want to collect a configuration file for a computer system.
Determine which scenario best meets your needs and apply the solution below;
Scenario 1 - You want to collect a configuration file for an application, such as Websphere, Apache or DB2 and you are discovering this application via an out of the box TADDM sensor.
This solution involves using a custom template to 'extend' an existing out of the box application sensor. It requires that the application sensor complete successfully AND store an object in TADDM of the class specified in the 'type' drop down of the custom server. For example, with Websphere, the WebsphereVersionSensor does not store any objects, typically the WebSphereCellSensor would have to run to store a WebSphereServer class object. If you wanted to collect WebSphere config files, a Websphere sensor must run and store a WebSphereServer object in the TADDM database before the custom server extension can store the file. Custom Server extensions like this are called and run by the parent out of the box sensor and the config files are stored as part of the sensor run.
To collect config files for this scenario you need to create a custom server using either the Data Management Portal or the Discovery Management console. In the Data Management Portal, 'Custom Servers' are listed under the 'Discovery' option.
Below is an example to extend the Apache Sensor. What is important here is that the 'type' field is the class of object that the Apache Sensor creates. This implies extending an existing sensor. You can only use sensor based classes in a custom server when you want to extend an existing 'out of the box' sensor.
It is important to set the action to discover and enable the custom server otherwise it will not run.
In the criteria, you can either limit the sensor to specific additional criteria, in the example below, the "program name is not XXXXXXXXXX" indicates this should fire for every Apache sensor that does not have a program name of XXXXXXXXXX, or essentially ALL Apaches which are discovered.
Additional criteria can also be added, for example, one could add "Environment HOSTNAME contains ABC" to only run this extension if the HOSTNAME variable contains ABC. This allows limiting of the extension to specific Apache instances. The criteria allows for very flexible options so that the user can choose specific instances to match and run the config file collection on.
Once the General Info tab is completed, select the Config Files tab. Here is where you will select the actual config file to capture. Click the Add button to create a new file capture.
Select Type "Config File"
Specify the search path for the capture file. The valid values are:
The root of the file system.
The current working directory of the running program.
The home directory of the user ID of the running program.
A directory on your local computer.
The program files directory.
The system root directory.
Specify the path and file name of the capture file in the text box, or type * (asterisk) to specify all files in the selected directory.
Capture file content
Specify if you want to capture the contents of the configuration file.
Limit size of captured file to
Specify the maximum number of bytes of the captured configuration file if desired.
Recurse directory content
Specify if you want to recurse through the directory structure.
Example to capture C:\Apache\httpd.conf file'
Click OK and OK again to save this custom server.
IMPORTANT: after you save the custom server you will be returned to the list of all custom servers. Only one custom server extension can run for a given sensor so if there are other custom servers in the list ahead of your new one that will match the same sensor, then the other custom server will be run and not the new one. Use the "Move Up" and "Move Down" buttons to re-order the list or "Delete" to remove unwanted custom sensors so that your new template will be first to match.
Now when you run the Apache Sensor for a given target, this extension should run and collect the httpd.conf file if it exists in C:\Apache
Scenario 2 - You want to collect a configuration for a custom application for which you have created a custom server template for.
This scenario is very similar to scenario 1. All the same information applies with one exception. This scenario involves capturing files for applications discovered by a custom server and not an out of the box sensor. In this case you likely already have the custom server defined, but the important differentiation here is the 'type' drop down on the Custom Server General tab. When defining custom applications you cannot use the out of the box sensor types, you must use the generic types;
- J2EE Server
- Web Server
- Database Server
Each of the four generic custom server types listed above can be used to create a template for the discovery of server types that TADDM does not automatically categorize. During discovery, any unknown server is identified as a custom server of this type if its runtime information matches the criteria you specified in the template, and no other existing enabled sensor matches this criteria. These types may also run if the matching TADDM sensor runs and fails. Also note that like the out of the box sensors, the process being discovered must be 'listening' on a port(lsof results show LISTEN) for it to be discovered unless the process name in the criteria has been added to the com.collation.platform.os.<ostype>.forcedServerList= collation.properties entry.
For more debugging tips for custom servers, see this link;
For this scenario, some customers prefer to use more specific application classes for their custom created application servers, but as noted above, the type drop down does not allow such. For example, in a situation where you do not have credentials to Oracle but want to discover some limited Oracle information, you may use a custom server to create a "database server" instance, but you would prefer "OracleInstance" instead so that the inventory is more precise. You can re-classify, but this requires custom code and knowledge of jython and the TADDM api. Below is an example for the Oracle scenario described above on how to do this.
1. Create a CST to discover the Oracle instance using the same criteria as the Oracle sensor uses. If you do not know the criteria, you can obtain it with either of the following methods;
If the sensor is pluggable it will have a directory in TADDM_HOME/dist/osgi/plugins/<sensor_version> directory containing file plugin.xml, eg;
Which will contain the match criteria.
Alternatively, you can obtain the criteria via an api find;
./api.sh -u administrator -p collation find --depth 4 "select * from com.collation.platform.model.discovery.template.AppServerTemplate where name=='Oracle'"
Map the filterlist in the above to the criteria section in the custom server template;
2. Create dist/etc/templates/commands/OracleCST command file with one line inside
3, Copy the attached Jython script to /dist/etc/templates/commands/extension-scripts
This is sample code and provided "as-is" with no warranty.
4. Create a Discovery Profile with OracleSensor disabled and discover your Oracle Server using the CST and the extension above.
Scenario 3 - You want to collect a configuration file for a computer system.
You can use the 'Custom Servers' in the Discovery Management Portal to add configuration file capture to any OS type discovered by TADDM. It is important to note, that like scenario 1, the ComputerSystem sensor that must complete successfully and store a computer system object for the file to also be stored.
The Config Files tab is exactly the same as the tab for application servers as noted in scenario 1;
Once the config files are captured, changes will be shown in change history, for example, with the collation.properties capture above, a change to the log.level settings can be noted by clicking the Show Differences link in the change history result set for the Linux computer system object;
You can also use templates to create and store configuration files, similar to the Oracle Sensor example above, this is done using directive files in the dist/etc/templates/commands directory. This feature allows a user to run commands on a target and capture the results in an attribute or config file. Please see these topics for more information;
Here is a link to another example, which shows setting and using a variable %NCHOME% to locate the config file;