#328 Soft-static uid/gid allocation for Performance Co-Pilot daemons
Closed: Fixed None Opened 6 years ago by nathans.


Following the steps in the docs here:

We would like to determine whether soft-static user and group identifiers could/should be allocated for the Performance Co-Pilot (PCP) daemons. PCP is a distributed system-level performance analysis toolkit. PCP currently uses the Dynamic Allocation technique described on the page linked above.

Additional info about PCP can be found here: [http://oss.sgi.com/projects/pcp/]

PCP has several daemons, the most critical being pmcd(1) which exports live performance data from a running system. This drops privileges after starting up, and runs using the pcp:pcp user/group, created as a system account in the %post of the pcp package.

Four other, optional, daemons exist which share this account: a rule-based analysis engine - pmie(1); a local/remote host recording tool - pmlogger(1); a proxy server for pmcd - pmproxy(1); and pmwebd(1) - a JSON interface to the PCP services. One further (also optional) daemon is planned, which will respond to Avahi / Zeroconf events indicating remote pmcd(1) hosts being available for monitoring, and automatically configuring pmie and/or pmlogger in their remote-monitoring modes for these auto-detected hosts.

pmlogger(1) writes performance data to disk (usually below /var/log/pcp/pmlogger), using the pcp:pcp credentials, and this can be for both local and remote hosts. The planned, new daemon is likely to write configuration data to disk using the pcp:pcp account as well (below /etc/pcp/{pmlogger,pmie}/control.d/ directories, most likely).

pmcd(1) is able to export both sampled performance data (usually not sensitive), and also event trace information (potentially containing highly sensitive information), all of which could be logged remotely by pmlogger. Exactly which metrics are logged is at the administrators discretion, although a summary set will be chosen on their behalf covering high-level (sampled) system data. pmcd supports remote authentication (via SASL) and certificate-based encrypted/secure communication (via NSS).

So, that's basically the details of the PCP situation. Please feel free to ask for any further clarification needed. Thanks for reading!



From the sounds of it, pcp can use the dynamic allocation strategy to create its system uid. It sounds like the data being shared is being passed through one or more perfomance copilot daemons rather than being shared with the remote system via a file on disk over nfs or similar. That should mean that the two endpoints do not need to agree on the uid and gid that the remote side runs as or that the remote side saves the information to disk as.

Let us know if there's additional information that would change our perception otherwise we'll close this after next week's meeting.

Login to comment on this ticket.