ACO effective parameter clarification in logs and docs

Idea created by spinneyj on Jan 14, 2016
    Not planned
    • CBertagnolli
    • James_Atchley
    • Ujwol Shrestha

    a spin off from a case i recently had open, 00282979, the current version(s) of the webagent family attempt to show the 'effective' config in their log during startup for debugging purposes, a very useful thing for most admins/support.  This effective config is made up from the ACO and any local config (if applicable). 
    there are some config items, the absence of which are terminal to the agent and it wont start.,   agentname/defaultagentname for example.    those are not an issue, as if those happen to be 'missing' then the agent fails to start and you start the  debugging process.
    What most people dont know is that there are a few cases where there is actually a hard coded default even if not specified in the aco/local config. This set of parameters that are non-terminal and if missing, can change the behavior of the agent in a n unexpected manner.    If missing, they do not print out in the log file and leaves you wondering what the effective configuration of the running production system is. 
    my proposal is to have the agent log ALL operating params and also signify the category that they fall into by a simple notation prepended onto the entry.    (preface hard coded setting with an asterisk e.g. *BadCSSChars = X, Y, Z)
    so....even if you didn't set would realize, there is a set of chars in place  due to a hardcoded default (*)  and then the  ACO coudl be used to override that setting.
    the above would/should also require an associated doc update  to reflect the fact that 'default' in the ACO params section of the doc really refers to the initial setting of the agent templates (e.g. ApacheDefaultSettings)
    once you instantiate a new agent, you are effectively copying that default and after that, any changes to the template  are no longer used in the config of that agent you just created.  This is a common misconception and over the years has confused people during in place upgrades as well.  (e.g. existing agent didnt get newly introduced params without admin adding them even though templates are updated)
    there are some hardening scripts that are run against the policy store, this also updates the templates.  not the instantiated agent aco configs.
    in the case of LimitCookieProvider ...current docs acknowledge that the (template) 'default' changes.   however, to bring this full circle back to the above makes no mention of the fact that if this param is ABSENT there is also a default setting, which is equiv to 'NO'.    in looking at the docs, you cannot determine what the effective config should be, and it further confuses things because , in this case, there seems to be 2 defaults which just puzzles the average user.