Changes committed to git://oss.sgi.com/pcp/pcp.git dev
GNUmakefile | 4 -
build/rpm/fedora.spec | 11 +--
build/rpm/pcp.spec.in | 2
configure | 34 ++++-------
configure.in | 29 +++-------
qa/040 | 8 +-
qa/061 | 19 +++---
qa/098 | 11 ++-
qa/100 | 11 ++-
qa/101 | 11 ++-
qa/102 | 21 +++----
qa/103 | 17 +++--
qa/104 | 19 +++---
qa/105 | 19 +++---
qa/106 | 19 +++---
qa/132 | 15 ++---
qa/133 | 45 +++++++--------
qa/133.out | 2
qa/134 | 26 +++------
qa/135 | 19 +++---
qa/136 | 13 ++--
qa/177 | 14 ++--
qa/179 | 23 +++-----
qa/182 | 16 ++---
qa/183 | 117 +++++++++++++++--------------------------
qa/184 | 18 ++----
qa/185 | 6 +-
qa/187 | 24 ++++----
qa/375 | 14 ++--
qa/381 | 12 +---
qa/389 | 16 ++---
qa/500 | 43 +++------------
qa/518 | 17 ++++-
qa/529 | 39 +++++++++++--
qa/538 | 9 ++-
qa/647 | 9 ++-
qa/648 | 9 ++-
qa/649 | 9 ++-
qa/common.check | 38 +++++++++++++
qa/common.filter | 1
qa/src/permslist | 5 +
src/include/pcp.conf.in | 8 ++
src/libpcp/src/auxconnect.c | 4 +
src/libpcp/src/logutil.c | 3 -
src/libpcp/src/util.c | 4 -
src/libpcp_mmv/src/mmv_stats.c | 3 +
src/pcp/pcp.sh | 8 ++
src/pmcd/pmdaproc.sh | 4 -
src/pmcd/rc_pmcd | 18 ++----
src/pmcd/src/client.c | 2
src/pmcd/src/config.c | 9 +--
src/pmcpp/pmcpp.c | 32 +++++++++--
src/pmdas/bash/GNUmakefile | 3 -
src/pmdas/linux/help | 3 -
src/pmdas/linux/indom.h | 9 ++-
src/pmdas/linux/pmda.c | 99 +++++++++++++++++++++++++++++-----
src/pmdas/linux/proc_cpuinfo.c | 90 +++++++++++++++++--------------
src/pmdas/linux/proc_cpuinfo.h | 23 +++-----
src/pmdas/linux/root_linux | 3 +
src/pmdas/mmv/src/GNUmakefile | 3 -
src/pmie/GNUmakefile | 1
src/pmie/pmie_check.sh | 4 -
src/pmie/pmie_daily.sh | 2
src/pmie/rc_pmie | 12 +---
src/pmie/src/pmie.c | 23 ++++----
src/pmiestatus/pmiestatus.c | 10 ++-
src/pmlogger/GNUmakefile | 4 -
src/pmlogger/pmlogger_check.sh | 24 ++++----
src/pmlogger/pmlogger_daily.sh | 6 +-
src/pmlogger/pmnewlog.sh | 2
src/pmlogger/rc_pmlogger | 4 -
src/pmlogger/src/pmlogger.c | 2
src/pmlogger/src/ports.c | 22 +++++--
src/pmns/Make.stdpmid | 12 +---
src/pmns/pmnsadd | 6 --
75 files changed, 690 insertions(+), 566 deletions(-)
commit 0cfa8763b864945f0cb1aaa9002f03e7d83935a1
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 21:18:40 2013 +1100
Split PCP_TMP_DIR setting into its two distinct use-cases
Folks have complained that we are creating world-writable-sticky
bits in somewhat unorthadox locations, and question the need for
PCP to be doing that, arguing it opens up unnecessary potential
exposure to security issues via attack from hostile local users.
Auditing all of the current uses of PCP_TMP_DIR shows that there
are two categories - PCP servers (daemons usually running as "pcp"
user, or "root" in the past) use this path to read/write files in
a way different programs can communicate (e.g. pmdammv, the status
files for pmie/pmlogger, etc) and for the creation of tmpfile(3)'s
that are short-lived.
For the former case, we do not strictly speaking need to use world
writable sticky directories - we could be using paths owned by pcp
(or just readable by pcp, in some cases). For the latter case we
do need 'em, but we could be using the regular system locations for
temporary files. There are many more cases of the former than the
latter usage.
This commit introduces a PCP_TMPFILE_DIR variable (for the latter),
usually /var/tmp - and keeps the existing PCP_TMP_DIR for the other
case (PCP daemons), usually /var/lib/pcp/tmp still. PCP_TMP_DIR is
no longer installed world-writable-sticky-bit-set, rather it is now
a regular directory that only the pcp user/group can modify.
Slightly awkward in this scheme are pmdammv and pmdabash (and likely
other PMDAs in the future) - which need to share files between "pcp"
user daemons and arbitrary other user accounts. They'll continue to
use $PCP_TMP_DIR/mmv, for example, but we do not enforce an initial
setup for this directory during the package installation anymore.
In other words, the user must decide on appropriate security setting
for their local site. Any existing installation will continue on as
before, as will a manual PMDA Install. However, the opportunity now
exists for a finer-grained scheme (e.g. specific-user-account owner,
pcp-group readable, and not world-writable-with-sticky-bit-set works
just fine).
commit 5db1ad2e029ec30a947de600e32818c1efa068fe
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 21:11:07 2013 +1100
Fix small file descriptor leak iterating over pmie status files
commit 3679732f1a2d60a3526738415ffdf04043eb1fad
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 21:08:48 2013 +1100
Fix small error path leak in pmcd config file parser
commit a4ab0ac4428bf0cb936cb06cfabad1aaca8ea616
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 21:07:40 2013 +1100
Plug a small leak in pmcd when client attribute hash table used
commit c1312d9016f95108e83bcb09e55f540dcc50367a
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 21:06:10 2013 +1100
Stricter enforcement of umask in MMV map file setup
commit 4e2bf952c65977ffbf31ec7e2601756910aabf7a
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 21:03:01 2013 +1100
Attempt to catch another ENOENT from unix domain socket setup
commit f7f1b6d6014f355b84ed8f646a04a95efd524367
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 21:01:49 2013 +1100
Filter further global desperate level host diagnostic
commit c708e0015629a22e4faba7b3989c06e59cece9e3
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 20:27:58 2013 +1100
Add /proc/cpuinfo flags and cache_alignment fields (x86)
Add new hinv.cpu.flags and hinv.cpu.cache_alignment metrics,
which exist on x86_64. Map s390 features field onto flags.
Reduce conditionals needed as we parse the cpuinfo file and
also make missing fields handles more correctly (contents
of /proc/cpuinfo is architecture specific).
commit 7301566c127dc7f5d493e1acc79bda8abfd784c2
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat Nov 23 16:16:50 2013 +1100
Create a shared-static-string dictionary for pmdalinux
Switch the cpuinfo metric values to use shared strings for
several of their values, reducing memory consumption where
large CPU counts are in play, and pave the way for further
metrics of this type.
commit c4f7f9d008eb026e0f57a939b90b06178400afcc
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Fri Nov 22 14:16:09 2013 +1100
Fix QA fallout from recent formatting change to pcp command
Test qa/518 picked up a recent regression in the pcp(1) command
with the -p option (extended pmie stats) - the new sorting code
made this option no longer make sense. Fallback to older style
of formatting when the -p option has been presented.
commit 48ba81a633c6a50a1878a630185efa364704de55
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Fri Nov 22 11:59:41 2013 +1100
Add hinv.cpu.model_name to counter the hinv.cpu.model scourge
For some time it turns out we've not had the most useful model
name being reported for each cpu in the hardware inventory. It
turns out, because the order in which model and model_name are
presented/parsed, we end up using the less useful one on x86_64
(and IA64, and probably one or two other spots). This adds in
a hinv.cpu.model_name metric to address this issue, and makes a
more coherent fallback strategy from one to the other (so we'll
always give a name if we can - /proc/cpuinfo contents are arch-
dependent and may have 0/1/2 of these fields).
commit 0cd33ab5c573015a0403fc2e0f99277012bc085d
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date: Fri Nov 22 11:48:03 2013 +1100
Ensure pmcpp does not accidentally #include directories
Whacko corner case - pmcpp parsing a namespace definition with an
include "pmns" directive. Then, found a directory named "pmns" on
its search path, opened that (fopen succeeds), successfully found
no useful content, and continued on its merry way. But, a chunk
of the namespace missing and some wierd error messages from tools!
Simply fstat descriptors we open, and only use regular files - and
if not regular, continue walking along the search path.
|