I noted in one of these comments:

"This tool is being obsoleted as we move away from non-container installations."

Is this, in fact, the direction of HPCC?  To no longer support non-container installations?

And, is configmgr no longer supported?

@Kanghua Wang  Ok, so, the solution I described is the real fix for the problem, but it's a chunk of work in bare metal and we aren't really focused on major improvements to bare metal right now.  @Ken Rowland should probably go ahead with his suggestion if it gives operations what they need.

@Kevin - if you go with Tony's suggestion, make sure the file is part of the installation.  It will also need to be merged into the version of the platform where this feature was first introduced and users will have to upgrade to the latest point release.  There will need to be testing done since we don't normally have bare metal components read multiple configuration files.  This implementation will mean that there are no configmgr changes needed and this Jira should be assigned to you

@Kanghua Wang the default settings can be loaded from "opt/HPCCSystems/componentfiles/applications/*/ldap_authorization_map.yaml"... that's how I do it in the cloud.  Then we can be sure everything stays in sync.

The code for loading these are in application_config.cpp, but that loads a lot of stuff, we should make sure this security tags part is in a shared function.

So just like in the cloud... 1. load defaults from application yaml files.  2. merge user settings. 

Then you end up with defaults for anything the user doesn't provide.

(In this case "the user" is environment.xml/esp.xml)

Note that the files are specific for the application for example eclwatch, or eclqueries (ws_ecl).  The files are also named based on the security manager.  So we just need to load the right ones based on those two things.

A modification template will be written that adds the sections outlined by @Kanghua Wang in a previous comment. The template will be made available so that the environment can be updates. It will be the responsibility of the DevOps team to run the envmod command line utility using the modification template to update any required environment files. The changed environment file will need to be pushed to each node in the cluster.