Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] newbie problems with MaDDash

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] newbie problems with MaDDash


Chronological Thread 
  • From: Pete Siemsen <>
  • To: Andrew Lake <>
  • Cc: perfsonar-user <>
  • Subject: Re: [perfsonar-user] newbie problems with MaDDash
  • Date: Tue, 9 Jul 2019 12:46:41 -0600

Answers to answers inline:
On Wed, Jul 3, 2019 at 6:56 AM Andrew Lake <> wrote:
See comments inline:

On July 2, 2019 at 4:24:02 PM, Pete Siemsen () wrote:

Questions:
1. Are those 4 sources of truthiness all current enough? We're sick of finding obsolete documentation on the web.

The information on docs.perfsonar.net is up to date unless a section indicates otherwise. The PRP document is not, but is not something the core perfSONAR development team created nor maintains. The google doc is in #3 is actually something that will be linked from the docs.perfsonar.net as part of the next release and is probably the best of the resources to walk you through step-by-step to get started. The other stuff on docs.perfsonar.net is more of an in depth resource that gives you more details about specific components.

Thanks! We'll use #3 as the primary doc.
2. Is esmond supposed to be running on the testpoints? We ask because truthiness source #3 mentions running /usr/sbin/esmond_manage, which we don't think we need to do, and haven't done.

The section in #3 that mentions the esmond_manage command is referring to the MaDDash install which only happens on the central-management host. Everything under the “MaDDash Initial Install” happens on your central-management host. Everything in “pS Node Configuration” only happens on your testpoint.

Ok, here's where we have some confusion. In a running maddash, the testpoints download a JSON file from the central management host. We thought that the testpoints need to convert that JSON file into a maddash.yaml file. Hence, we thought the testpoints would need to have maddash-agent installed. From this thread, we now understand that the testpoints don't need maddash-agent. So... when a testpoint downloads the JSON file, the testpoint loads the JSON into the testpoint's pscheduler?
3. Related to #2, we deleted the "archive" object, and the references to it, from the our JSON file, because truthiness source #1 seemed to say we could.. 

Truthiness source #1 highlights a number of ways to define archives and it is accurate that you can remove if you are specifying the archive definition on the local filesystem...which I am guessing you are not. I would highly recommend walking through #3 from start to finish and ignoring everything else since it has everything you need. The other items aren’t inaccurate, but I think they are highlighting features that are just complicating matters for you.

 Ok, we'll try that. 
4. Our testpoint was initially built with "apt-get install perfsonar-toolkit". Later, we did "apt-get install perfsonar-testpoint", to get the maddash agent. Is there any problem with that? Like, perhaps if we'd installed the central management bundle, might we have gotten the Perl modules that are missing?

Installing perfsonar-testpoint a) won’t give you the maddash-agent and b) you don’t want the maddash-agent on your testpoint. Given you are saying apt and you said above that your central-management host is Debian I am going to assume you meant perfsonar-centralmanagement instead of personal-testpoint in this question. Under that assumption, it is perfectly fine to install perfsonar-centralmanagement on a host that already has a toolkit.

We had an existing, working toolkit machine, and we wanted to use it as a testpoint. We did "apt-get install perfsonar-testpoint" on it, because we mistakenly thought we needed maddash-agent. We've since abandoned that machine, and are using fresh machines, and we've done "apt-get install perfsonar-testpoint", and we don't have missing-library Perl errors any more.
5. Truthiness source #3 says to run the "psconfig publish" command. We did, and it seemed to work, and it printed out the "psconfig remote" command to use on the testpoint machine. As far as we can tell, this is the only occurrence of the "publish" command in all 4 documents, yet it seems to be essential to make a working system, because it's the only clue as to the correct URL to use in the "psconfig remote" commands on testpoints.

docs.perfsonar.net has a whole section called “Managing Multiple Hosts with pSConfig” (http://docs.perfsonar.net/#managing-multiple-hosts-with-psconfig) of which #1 is just one page. There is also http://docs.perfsonar.net/psconfig_quickstart.html and http://docs.perfsonar.net/psconfig_publish.html which discuss the publish command, the latter in pretty good detail.

Thank you. This is some high-quality documentation. We should done more RTFM.
6. On the testpoint, our /var/log/maddash/maddash-server.log file complains about check programs it can't find. Might this also be because we installed with "apt-get install perfsonar-testpoint" instead of "apt-get install perfsonar-centralmanagement"?

Is it the nagios commands it is complaining about? Those are a dependency of the maddash-server package, so if you have that installed, I am surprised you don’t have it. Quite possible you ran into a bug with the Debian MaDDash package but hard to say as I am a little unclear about what is installed where in your setup.

We don't have this problem any more, now that we installed fresh testpoint machines. We have some new problems, for another thread.
Thanks very much!

-- Pete




Archive powered by MHonArc 2.6.19.

Top of Page