perfSONAR User Q&A and Other Discussion

[Andrew Lake <>]

See comments inline:

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

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.

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. 

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. 

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. 

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.

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. 

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. 

Thanks for any suggestions!

-- Pete

-- 
To unsubscribe from this list: https://lists.internet2.edu/sympa/signoff/perfsonar-user