I would prefer to build a snapshot of the file in a known good state. Then you can use audit /
sync with master to dynamically factor the BL Package for each variation you come across.
Since that doesn't necessarily auto-remediate without human interaction you might need to write some BLCLI to get it all done.
I was also thinking if the file must be exactly the same on all servers you can just push out the file without using the grammar engine.
No point in using the grammar engine unless you want to be surgical. From your example is seems as though all ntp.conf files need to be identical so why not just blindly overwrite them all.
I have in the very recent past with other Component Templates been doing exactly that, however...
1) I have started using Compliance Jobs with Auto-Remediate, and I REALLY like that route!
2) All the BLPackages and Deploy Jobs created by Sync to Master (I run my job against several thousand systems at a time) causes a pollution of BLPackages and Deploy Jobs I really don't want to keep that need to be cleaned up.
3) Auto Remediation jobs can be cleaned up using the Retention Policy as they are flagged as auto created runs!
On Sync to Master we had been dropping the BLPackage and Deploy jobs in a folder for each Component called "TMP" or something to keep them from polluting our normal job workspace, but it seems cleaning them up with the CM GUI is ugly. I have to say OK for each of the job run dependencies to clean them up. And I might have 500+ in the Sync to Master run!
So, I would REALLY like to figure this out for a BLPackage that I can deploy when the Compliance Rules have failed. I have the Compliance Rules working with the multiple Configuration File Entries thanks to help from these forums. I just need to figure out how to get the BLPackage to handle them to "fix" them!
Assuming that's possible!
We have been considering that approach.
Assuming we "own" the contents of that file 100% and there would be no possible configuration variants with other options that would block a wholesale replacement of the file.
So, I was trying to get the fancy Compliance with the records we require to be set and change them if needed, while leaving the rest of the options as they were found on a given server.
Plus, I am teaching myself all about this Compliance Rules stuff and this more complicated requirement seemed like a good way to get in over my head! And we might need to adapt a similar Compliance Rule flow to meet other requirements.
Just wanted to provide a update on this...
I talked to support on this, after a bit of research I was told that No, BLPackage does not support using a CONFIGFILE entry using wildcards to select multiple instances of the same CFE in a Delete object. So, I have added a external command script fragment to edit the file and make the required changed to multiple CFE instances.
Not sure if maybe the CONFIGFILE delete object in a BLPackage SHOULD support this and this needs to be a RFE or not...
You should make an rfe, you've got a use case.