Idea Details

ACO effective parameter clarification in logs and docs

Last activity 06-04-2019 11:52 AM
Anon Anon's profile image
01-14-2016 09:01 AM

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 BadCSSChars...you 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 enhancement....it 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.


Comments

03-01-2017 04:22 AM

Thank you for your contribution of an enhancement idea to the CA Community. CA is continually working to improve its software and services to best meet the needs of its customers. Your input is vital to that effort. The CA Single Sign-On Product Management team has reviewed your suggested enhancement. Based on current roadmap priorities and/or the limited amount of community support for this idea over the last year (please see this document describing how we are reviewing ideas: https://communities.ca.com/docs/DOC-231170123), we are not accepting this idea into the product backlog. Therefore, it is being moved to a “Not Planned” status. 

01-18-2017 04:59 PM

This is a great idea and we should consider implementing it asap. 

The scope of change is also very limited for this requirement.

01-18-2017 04:18 PM

Thank you for your contribution of an enhancement idea to the CA Community. CA is continually working to improve its software and services to best meet the needs of its customers. Your input is vital to that effort. The CA Single Sign-On Product Management team is reviewing your enhancement suggestion following the process outlined here: https://communities.ca.com/docs/DOC-231170123

The Community will continue to be able to vote on this enhancement idea.