On 25/08/13 12:27, Nathan Scott wrote:
* page 14: "PMCS" - is there any need for this term? How about saying that
the pcp libraries provide utility functions for PMDAs? Or just use "PCP"
instead of "the PMCS" throughout the book?
I think this is one of Ken's historical terms, I'll wait to hear if he's
particularly attached or still feels it adds explanatory value. I tend
to think its use could be replaced by a more generic "PCP" reference as
well, and fewer-is-best when it comes to acronyms.
The acronym PMCS has outlived its usefulness ... if it ever was useful
... 8^)>
* page 23: the "store" operation reminds me, we should take that permission
out of default pmcd.conf's.
Hmm, why? I tend to disagree ... that will break things and removes useful
functionality. What were you thinking it'll protect to disable that? We're
currently doing (which seems fair and good to me) ...
[access]
disallow * : store;
allow localhost : all;
There's sneaky things like pmcd.client.whoami and the event metric filters
that are hobbled without store capabilities, and no metrics I can think of
that we ship are questionable re store access in general. It's more what
other people (users/admins customising pcp) might do that the remote store
entry in the [access] section is protecting, I think.
Another important use case is turning on diagnostics and/or expensive to
collect metrics.
I think the issue here is less about pmcd access controls and more about
what the PMDA implementor chooses to expose for the store() method ...
all PMDAs to date expose only a small fraction of their metrics to store
operations.
|