Skip to Content.
Sympa Menu

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

Subject: perfSONAR User Q&A and Other Discussion

List archive

[perfsonar-user] newbie problems with MaDDash


Chronological Thread 
  • From: Pete Siemsen <>
  • To: perfsonar-user <>
  • Subject: [perfsonar-user] newbie problems with MaDDash
  • Date: Tue, 2 Jul 2019 14:22:40 -0600

We are two people trying to get a new MaDDash install working. We haven't done this before. We think we're close.

We are using 4 sources of truthiness:

1. http://docs.perfsonar.net/psconfig_maddash_agent.html
2. https://gitlab.com/ucsd-prp/presentations/lajolla-2019/blob/master/maddash--ma/PRP-FIONA-Workshop-LaJolla-MaDDash-jhess-final.pdf
3. https://docs.google.com/document/d/1IJfe3WDClFDvwxMKk-NlAkSz0XLm4C9mffUbEvMW87c/edit#heading=h.1fob9te
4. Andy Lake's "psConfig Overview" dated June 5th, 2019, attached

We have one central management host and one testpoint:
The central management host is named "ntu-cp", at 50.33.113.5, running Debian 9.9.
The testpoint is named "perfsonar.ucar.edu", at 128.117.132.12, running Centos 7.6.1810.

Our json file is named ntu.json, and is attached.

We have the psconfig maddash agent running on both hosts. It runs without error on the central management host. On the testpoint, we find messages about missing Perl libraries in the psconfig-maddash-agent.log file, attached.

We noticed that on the management host, in the /var/log/perfsonar directory, these symbolic links exist:

pscheduler.log -> /var/log/pscheduler/pscheduler.log
psconfig-maddash-agent.log -> /var/log/maddash/psconfig-maddash-agent.log

Those are convenient. They don't exist on our testpoint machine. Perhaps this is because the testpoint machine is Debian, and was built using apt-get, while the management machine is Centos?

We know the ntu.json file is being received by the testpoint, because the addresses in the ntu.json file appear in the /var/log/perfsonar/psconfig-pscheduler-agent.log file. So we think we're close to having this work.

Questions:

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

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.

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.. 

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?

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.

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"?

Thanks for any suggestions!

-- Pete

Attachment: ntu.json
Description: application/json

Attachment: psconfig-maddash-agent.log
Description: Binary data

Attachment: pSUW2019-20190605-GEANT_PS_WORKSHOP-pSConfig.pdf
Description: Adobe PDF document




Archive powered by MHonArc 2.6.19.

Top of Page