Disclaimer: The examples and procedures contained within come with no support or warranty, explicit or implied. Caveat emptor!
A feature used heavily in Apache HTTPD configuration is using the "Include" directive to allow a modular approach using multiple config files. Unfortunately the current Apache discovery pattern does not ingest any files which are included from the main config file, which limits visibility into the configuration and changes to it from our Tracked Configuration Files table. Here's an example of how to augment the pattern so it pulls in all files referenced from the main file.
Pattern Behavior
The way the Apache on UNIX based OS pattern ingests the configuration file is by deriving its full path using a set of cascading pattern steps and then passing that to the pattern's "Tracked Files" tab via a variable named "config_file".
Because of this methodology, there's no inherent entry point by which to add parsing logic to how the file residing at that path is pulled in. Once I realized this, I decided on an approach of storing the parsed version of the file in an alternate path and modifying the config_file variable accordingly.
Uploaded File
The heavy lifting of parsing the main Apache config file and pulling in any included files is done using a script I found online. It can be found here: https://www.scriptinglibrary.com/languages/python/merge-all-apache-httpd-conf-with-python/. After obtaining a copy of the script, I created an Uploaded File record under Pattern Designer->Uploaded Files.
Pattern Modifications
NOTE: modifying a built-in pattern may not be the best approach for a production implementation. Creating your own copy, for example, maintains the ability to upgrade the build-in pattern.
I made the following modifications to the Apache on UNIX based OS pattern to have it ingest the combined config data:
Under Identification, select Identification for HTTP(S) entry point type(s) to load the pattern section into Pattern Designer.
In Pattern Designer, after step "check if the SERVER_CONFIG_FILE is relative or not", add a "Put File" step where the File Name value is that of the script you uploaded and the Full Path Target is assigned to an intuitively-named variable (in my case I used "$config_parser"). I named this step "Put config parser".
After the "Put config parser" step created above,add a "Parse Command Output" step which will execute the script and store the output in a net-new consolidated config file. The Set Command Details value I used is as follows:
"python3 " + $config_parser + " " + $config_file + " >/tmp/combined_httpd.conf"
Since no output from this command is expected, I selected a Define Parsing value of "None". I named this step "Run config parse script".
Immediately following the "Run config parse script" step, I added a "Set Parameter Value" step which assigns the new location of "/tmp/combined_httpd.conf" in the existing "config_file" parameter, allowing the existing "Tracked File" functionality in the pattern framework to ingest a fully-instantiated Apache config. I named this step "Update config_file var".
After putting this modification in place, I'm able to discover a full Apache configuration and see it on the Tracked Configuration File list.
Conclusion
If I were doing a full production implementation of this capability, I would add support for multiple httpd instances on a server, more error checking, etc., but the ease with which I was able to add this powerful enhancement was very encouraging.
