On 06/04/2013 04:03 AM, Nathan Scott wrote:
Hi Dave,
----- Original Message -----
Hi,
I've been looking into the ins and outs of adding the capability of
listening on unix domain sockets to pmcd (and presumably pmproxy, and
perhaps other components) via extensions to the API in
src/libpcp/src/auxserver.c. I've written most of the code but, at this
point, several user interface decisions must be made:
1) The default for pmcd (and pmproxy) is to listen on all available
network interfaces, unless the -i option has been specified. It it not
clear (to me) what the default should be for the unix domain. It is
clear that a new option (-s or -u perhaps?) is in order for the
specification of paths to these sockets. Let's assume -s for now.
I think the point we want to get to is to default to unix domain sockets
on hosts that support them (so, everywhere except Windows) as this allows
authentication information to be made available to pmcd without having to
authenticate via SASL. This is a Big Win (tm) for agents like pmdaproc,
so lets plan accordingly...
One possibility is to listen to none by default. One or more -s options
could then be used to specify one or more unix domain sockets. A -s
option with no argument could mean to use the default
(/var/run/pcp/pmcd.socket perhaps?). This would be used in conjunction
I don't foresee any situation where more than one unix domain socket
makes sense - is there a subtlety or situation I'm not seeing?
No, there's nothing subtle going on in my thinking. I just always lean
toward flexibility when designing user interfaces. Since these are for
local connections only, the only possible reason I can see for having
more than one would be for access control, but even that is perhaps a
stretch. The situation would be something like the ability to restrict a
given unix domain socket to some subset of users or groups and then
attaching the usual access controls to that socket.
If that's right, I think we should default to having pmcd create a local
socket file (the suggested location above sounds good to me) and clients
should default to using it (within pmNewContext) whenever possible - so
instead of using an inet/ipv6 localhost/loopback socket as they do now.
Certainly if a client tool (like pminfo) specifies no -h option it would
be good to have it default to a unix domain socket connection.
with an environment variable (PMCD_SOCKET perhaps?) which would specify
additional socket paths, similar to how -p and PMCD_PORT work together.
Another possibility is to listen on /var/run/pcp/pmcd.socket by default
and to use -s and PMCD_SOCKET to override this.
That sounds more like what I was thinking. The most likely users of -s
and/or PMCD_SOCKET would be pcp/qa tests.
OK. So with the single unix domain socket assumption, then this becomes
easy. We would use the path specified on -s. If none specified, then we
use the path specified in PMCD_SOCKET. If that's not defined, then we
use the default, /var/run/pcp/pmcd.socket.
Once again an empty -s
could be used to add the default path to the list. In either case it
Not a fan of "empty" -s. I'd suggest the behaviour be: "use the default
/var/run/pcp/pmcd.socket unless -s present, if it is use that instead".
Yes. With the single socket assumption, this is no longer needed.
would be nice to have some way to say to use the default path within
PMCD_SOCKET.
This is no longer needed as well.
Comments and suggestions please. It is interesting that
there appears to be no support for specifying request socket addresses
and ports in the pmcd config file.
pmcd.conf is more specifying complicated things that change at run-time
(i.e. agents and access control) - for things that are simpler and set
in stone for the life of pmcd, pmcd.options is used (which equates to
command line arguments).
2) Does the pmcd access control mechanism need to be extended to include
a way to control access from unix domain sockets? If so, we would need
some kind of syntax in order to distinguish a socket pathname from an
ordinary host name. Once again comments and suggestions please.
Yeah, good question. Not sure yet. Since we will only have 1 unix socket
path at a time (if my assumptions above hold), and the unix domain sockets
will always pass in a userid/groupid (via SO_PASSCRED), the new user/group
permissions model I've been hacking away at might be sufficient.
But, as mentioned above, could create the need for more than one unix
domain socket, each with its own userid/groupid+access controls.
Dave
|