Hi Nathan,
Thanks for the constructive feedback. Responses to your comments below ...
On 06/22/2012 01:10 AM, Nathan Scott wrote:
While the pmcd/client channel I can definitely see needing encryption
at times, I'm not sure there is any case where pmcd/pmda channels
would ever need it. The pmdas are all (most always) children of pmcd,
always on the same host.
I suspected that this might be the case, and my initial attempt at this
focussed exclusively on the client<-->pmcd connections. As I think we
all agree, any use of an encrypted connection would be at the option of
the client or the agent.
All of the work described below can be found on the brolley/nss branch in
our pcp repository at git://sourceware.org/git/pcpfans.git
Had a quick look,& will look deeper when I get some time. I was trying (but
failed) to see how a client tool chooses to enable an encrypted channel, and
I didn't really follow from the rest of your mail whether thats been considered
yet?
Sorry. I was not clear that this part of the work has not been started
yet. At this time, I'm still working on simply using NSS/NSPR for the
connections using the exsting protocols/handshakes.
Assuming we are going to keep the option for clients to establish non-secure
channels (which I really think we have to), then we'll need a mechanism at
several points to say what type of connection its to be. I suspect this means,
for example, that pmNewContext(3) would need to acquire a new "type" -
PM_CONTEXT_SECURE? - as an alternative to PM_CONTEXT_HOST. This
new type would need to be exposed to the user then, depending on the tool.
For command line tools, __pmParseHostSpec could perhaps be extended to
allow for a connection-type prefix - eg. "pcp://host.name.com" vs a secure
variant "pcps://host.name.com". The pmHostSpec structure would have to
acquire a flag field, and that flag would then be used in the client
tool code to
set the appropriate pmNewContext type. pmParseMetricSpec(3) would need
similar treatment.
For graphical tools like pmchart, the New Host dialog could have a lock radio
button or something similar, and the user could select which way to establish
the connection directly through the UI.
Well, that might be one way to go anyway, is that the kind of thing you were
imagining would be needed or is none of this necessary somehow?
I had not yet considered the user interface for the various tools. I had
only considered that a tool or client might, for whatever reason,
request a secure connection. The model we (Red Hat Tools Team) had in
mind was something like STARTTLS, where once the connection has been
made, the client requests an upgrade to a secure connection.
.... In this way
existing pmcd clients and agents can still connect to pmcd without change
and future clients and agents can still use insecure connections if they
choose.
(good stuff, I think we have to consider that as a non-negotiable requirement)
Agreed.
Testing:
--------------
Once I have both sides of the abstraction implemented, testing will be the
next area of focus. I understand that there is a test harness at
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=pcp/pcpqa.git;a=summary
I will likely need help in getting things set up on my available platforms
and will certainly need assistance in testing on platforms that are not
available to me.
I can help with that when you get to that point. Grab me on IRC (#pcp
on freenode) or ping me via mail when you're ready to start that and I'll
take you through it.
Thanks, I definitely will.
I would appreciate feedback on the approach and on the abstractions that
have been made so far. Have I placed the abstraction at the correct level
and place within the system? Is the work headed in the right direction for
acceptance?
I haven't gone through the code in great detail yet, but from your description
it sounds unavoidably invasive - abstracting does seem like the best way to
deal with that and minimise risk of regression. I'll dig deeper when I get a
bit more time, and provide some more useful feedback. OOC, there is an
"ssl" branch in pcpfans too - does that need to be reviewed in tandem with
this "nss" branch? thanks.
The brolley/ssl branch was my first pmcd-centric attempt at this, which
focussed on client connections only. The abstraction for this attempt
was in the pmcd mainline and I ran into a dead end with calls like
__pmSendPDU which are used to send data to client as well as agents.
This in turn lead me to look into implementing the abstraction within
libpcp.
Dave
|