perfSONAR User Q&A and Other Discussion

[Michael Johnson <>]

Hi Debbie,

That's a lot all at once, I will try to answer all your questions, but let me 
know if I've missed anything. Answers inline below:


> On Mar 5, 2019, at 8:00 AM, Fligor, Debbie <> wrote:
> 
> Hi everyone,
> 
> First thing I figured out was that even though the button for auto update 
> was set, it hadn’t done any updates on either system. So I did by-hand yum 
> update and it got everything up to the current versions as best I can tell 
> (psconfig is 4.1.6-1el7).  So that’s my first ask - what else do I need to 
> do for auto update to work?
> 

Setting auto-updates via the GUI should work; does it show that auto-updates 
are enabled ("green" switch)? 

Regardless, you can enable/disable auto updates from the commandline. This is 
handled by a service called yum-cron

To view the current status of auto-updates:
$ sudo systemctl status yum-cron


To enable auto-updates
$ sudo systemctl enable yum-cron

Docs here:
http://docs.perfsonar.net/manage_update.html#managing-automatic-updates-from-the-command-line

> 
> Then I added some ping tests so that I should start seeing results sooner. 
> I started getting errors when I changed tests, and would hit cancel, and 
> try again, and fairly soon on that host clicking on the tests tab got me a 
> spinning load circle that never resolved.  So I thought I’d corrupted a 
> database or something on one of the two servers.  

FWIW, there is no database backend for the test configs.

> Still no test results on either.  I couldn’t find any errors in any of the 
> logs you can see on the web page, so I tried some things that had helped 
> others with similar errors who had posted their fixes, like cassandara 
> cleanup, and nothing helped. plent of reboots as well. Convinced I had 
> corrupted something I tried "yum erase perfsonar-toolkit” then “yum clean 
> all” then “yum install perfsonar-toolkit”.  That didn’t fix my test configs 
> not saving.  I got to the FAQ page and worked my way through all the log 
> files in the list, and found this error repeating in 
> /var/log/httpd/ssl_error_log:
> 
> 
> [Mon Mar 04 21:58:42.441962 2019] [cgi:error] [pid 53339] [client 
> 107.152.10.165:19568] AH01215: [Mon Mar  4 21:58:42 2019] 
> regular_testing.cgi: Config::General: Cannot create hashref from <target> 
> because there is, referer: 
> https://res-dtn.techservices.illinois.edu/toolkit/auth/admin/tests.cgi
> [Mon Mar 04 21:58:42.442069 2019] [cgi:error] [pid 53339] [client 
> 107.152.10.165:19568] AH01215: [Mon Mar  4 21:58:42 2019] 
> regular_testing.cgi: already a scalar option 'target' with value 
> 'psb-bw-100g.ncsa.illinois.edu', referer: 
> https://res-dtn.techservices.illinois.edu/toolkit/auth/admin/tests.cgi
> [Mon Mar 04 21:58:42.442156 2019] [cgi:error] [pid 53339] [client 
> 107.152.10.165:19568] AH01215: [Mon Mar  4 21:58:42 2019] 
> regular_testing.cgi:  at 
> /usr/lib/perfsonar/web-ng/root/admin/services/regular_testing.cgi line 38., 
> referer: 
> https://res-dtn.techservices.illinois.edu/toolkit/auth/admin/tests.cgi
> 
> [snipped some details] 

> I would like to be able to save tests from the web interface without having 
> to edit gui-tasks.conf (not to mention I don’t actually know what I’m doing 
> when I edit it).  What do I need to do?  There is less than a day’s data, 
> so blowing everything away and starting again is fine, if that fixes this, 
> but I ran out of steam for finding ideas on how to do that.  


Indeed, you should not need to hand-edit gui-tasks.conf. I think two things 
are happening. First, there might be something invalid in that config file. 
The easiest way to fix this is probably to just delete it (don't forget to 
back it up first), and then re-create it, as an empty file.

$ sudo rm -f /var/lib/perfsonar/toolkit/gui-tasks.conf
$ sudo touch /var/lib/perfsonar/toolkit/gui-tasks.conf


And, when you edited the file it may have gotten saved with the wrong 
permissions, at which point the web backend can't edit it. On my system, it 
looks like this:

$ ls -l /var/lib/perfsonar/toolkit/gui-tasks.conf
-rw-r--r-- 1 perfsonar perfsonar 6867 Sep 28 15:02 
/var/lib/perfsonar/toolkit/gui-tasks.conf

Its owner and group are "perfsonar", and it's rw for user, and read-only for 
everyone else. You could restore those permissions like this:
$ sudo chmod 0644  /var/lib/perfsonar/toolkit/gui-tasks.conf
$ sudo chown perfsonar:perfsonar /var/lib/perfsonar/toolkit/gui-tasks.conf


At that point, hopefully you will be able to create a configuration, and save 
it. 

> 
> And once I had that solved, the host that I had deleted and re-installed 
> perfsonar-toolkit on started showing test results (on the dashboard and the 
> esmond archive), but the other host did not. Rebooting didn’t make the 
> tests show up.  So on that host I also uninstalled and reinstalled 
> perfsonar-toolkit and now the tests results show up.  On this one I’m 
> curios as to why this worked, but since it’s working and continued to 
> update all night, I’m not looking for a better way to do it.  

My guess is that maybe you didn't wait long enough for the test results to 
show up, and reinstalling/rebooting most likely was just a coincidence. Hard 
to say.

> Now I’m moving on to system tuning.
> 
> One last minor question for anyone that got this far. How do I set the 
> primary (default) interface so it’s what I want? one system is picking the 
> 100G, the other the 1 G copper port.  on both systems the 100G has the 
> default route for v4 and v6.


You can set the primary interface in 
/usr/lib/perfsonar/web-ng/etc/web_admin.conf by setting the 
"primary_interface" directive.

Hope this helps.

Thanks,
Michael

Michael Johnson
GlobalNOC DevOps Engineer

Attachment: smime.p7s
Description: S/MIME cryptographic signature