Hi Mark,
Thanks for following up; CC'ing this to the general list so others
can enjoy your success story too.
Its especially good to hear this feedback, as from time to time we
wonder if any people find value in using the local context mode of
operation - now we know, and we (devs) should endeavour to keep up
DSO support for existing & new PMDAs wherever we can.
cheers.
----- Original Message -----
> Nathan,
> I promised to let you know how it worked out w. attempting
> to keep all root/sudo references out of my programmatic use
> of PCP.
>
> Your suggestion was dead on: using PM_LOCAL_CONTEXT in
> pmNewContext eliminated the need for pmcd action and reduced
> my PCP installation from a root task to a minimal user task.
>
> I took it one step further, having seen the /lusr/lib/libpcp.a archive,
> and have statically linked in the libpcp library to my executables.
> It works like a gem in my test pgm. which no longer needs even
> the .so to be carried to the cluster of VMs. It should work identically
> in my full-up applications.
>
> I hope you'll push my email to any general archive/FAQ where
> it might be of use to others. Thanks.
>
> regards,
>
> On 07/29/2014 10:29 PM, Nathan Scott wrote:
> > Hi Mark,
> >
> > ----- Original Message -----
> >> Hi,
> >> I have a working C++/Linux application that as a side-function
> >> collects/consumes some PCP perf data using libpcp library
> >> functions.
> >>
> >> A new imposed requirement is that my application and any
> >> libraries/daemons that it uses are to be installed on a group
> >> of clustered VMs but the installer can not act as root during
> >> the installation. Is it possible to to create a stripped-down
> >> PCP version that could be installed and operated without
> >> root privileges ?
> >>
> >> If so, is the logical starting point a source distro or (preferably)
> >> a Centos-built rpm, from which I can extract components
> >> with rpm2cpio? Perhaps a minimal set that includes pmcd,
> >> libpcp, and related dependencies with a user-level pmcd startup.
> >>
> >> I'd be happy to provide feedback on my efforts, if successful;
> >> but I don't even want to begin if there is a brick wall in my
> >> path.
> > I don't think there's a brick wall, you should be able to get this
> > to work. And, yep, I'd be interested to hear how it goes.
> >
> > If the only thing you need are values/metadata for metrics, and if
> > those metrics are available from PMDAs that function in DSO form,
> > you might not even need to get pmcd up and running. You should be
> > able to use the PM_LOCAL_CONTEXT mode using just libpcp and the
> > DSO PMDA(s) - e.g. pmda_linux.so - from whence your metrics are
> > sourced. See the pmNewContext(3) man page & the -L and -K options
> > to pminfo(1).
> >
> > If you do need pmcd (clustered VMs? might be using the distributed
> > PCP protocol?), you should be able to fire it up with PCP_USER and
> > PCP_GROUP in your environment - it will attempt to change user/group
> > to these early on in its life. Usually it sources these variables
> > from /etc/pcp.conf but environment varibables can override this.
> > You might find the PCP_DIR environment variable handy too.
> >
> > Of course, if you have metrics/PMDAs that need to run in privileged
> > mode to extract their metrics data... then you're in strife :) All
> > the Linux kernel PMDA metrics can nowadays be accessed unprivileged
> > though.
> >
> > Good luck!
> >
> > --
> > Nathan
>
> --
> ***********************************
> >> Mark J. Potts, PhD
> >>
> >> HPC Applications Inc.
> >> phone: 512-228-1721 Bus
> >> 512-828-6153 Fax
> >> email: potts@xxxxxxxxxxxxxxxxxxx
> >> potts@xxxxxxxxxx
> ***********************************
>
>
|