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?
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.
> 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".
> would be nice to have some way to say to use the default path within
> PMCD_SOCKET. 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.
cheers.
--
Nathan
|