Setting up PingER servers at Amity

They followed the instructions at Installation Overview.They were able to download and install the files.

The cgi-bin directory appears as:

It would be good to get an ls -l to ensure the files are executable.

and /usr/local/share/pinger appears as:

They then remotely logged in to test traceroute.pl file using http://202.12.103.71/cgi-bin/traceroute.pl which gives a webpage.  This page looks correct, just tap yes to get it to make the traceroute. It also works if I VPN into SLAC from my home in the Bay Area. After pressing Yes I get:

It appears that though the request is being made to 202.12.103.71 when traceroute.pl at Amity tries to get the IP address of the traceroute server at Amity it gets 127.0.1.1. I suggest adding some debugging statements to traceroute.pl around line 84 (or you can use the perl -dT option (see the lines following line 2 in traceroute.pl)) which reads:

use Net::Domain qw(hostname hostfqdn hostdomain);
my $hostname = hostfqdn();
my $ipv="4";#set default used by gethostbyname6 to decide if to force IPv6
my $ipaddr=gethostbyname6($hostname);

to trace what is happening and see if it is fixable (possibly hardcode the $ipaddr).

I would sort this out before going onto ping_data.pl. Once ping_data.pl works (puts up its form) then debugging will be simpler.

Update 2/3/2016

pinger2.pl has been made executable

After making this change they see:

Pinger2.pl is making measurements.  It appears for reason I do not currently understand (our install package probably needs updating) they have an old version of pinger2.pl. So next steps: 

1. Pick up the current version of pinger2.pl at http://www.slac.stanford.edu/comp/net/mon/tool/ping_data.pl and just replace. No need to go through the install process.
2. Traceroute.pl does not work, as reported in http://202.12.103.71/cgi-bin/traceroute.pl  I would next see if you can get that to work.

3. ping_data.pl does not work. I am suspicious that it is for the same reason as traceroute.pl. It gives a 200 but nothing is returned:

   215cottrell@pinger:~$wget 'http://202.12.103.71/cgi-bin/ping_data.pl'
   --2016-02-03 12:58:12--  http://202.12.103.71/cgi-bin/ping_data.pl
   Connecting to 202.12.103.71:80... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 0 [text/html]
   Saving to: "ping_data.pl.3"
       [ <=>                                   ] 0           --.-K/s   in 0s
   2016-02-03 12:58:13 (0.00 B/s) - "ping_data.pl.3" saved [0/0]
   216cottrell@pinger:~$head ping_data.pl.3 
   217cottrell@pinger:~$

   Can you try executing it from the command line. It should create to STDOUT the html for a form.

    

Update 2/5/2016

Traceroute works as a traceroute server and a ping server

Looking at the function=ping output, you will notice that the requesting host (in this case at SLAC) is given a private IP address (10.0.253.1) which is going to cause some failures, e.g. a host at SLAC requesting a ping from 202.12.103.71 to the requesting host. The requesting host being identified as a private address 10.0.253.1 will not be able to be pinged.  See below:

Update 2/17/2016

Question:

We have also been debugging the ping_data.pl which was giving us some problems. It seems that the script is unable to locate the pinger2.pl file at /afs/slac/package/pinger/pinger2/share/pinger/pinger2.pl. In our machine the script is placed in the directory /usr/local/share/pinger/pinger2.pl. Do we have to change the file path in ping_data.pl?

Response:

The easiest would be to simply comment out line 323 of ping_data.pl to remove the need to try and grep the /afs file:

my @cmds=('date',

          '/bin/uname -a',     '/usr/bin/uptime',

          '/bin/grep "version" /usr/local/share/pinger/pinger2.pl',

          #'/bin/grep "version" /afs/slac/package/pinger/pinger2/share/pinger/pinger2.pl',#line 323

          '/bin/ps -efl | grep pinger2',

          '/bin/cat /etc/hosts',  '/bin/cat /etc/resolv.conf',

          '/usr/bin/whoami',      '/usr/ucb/whoami',      '/bin/pwd',

          '/usr/sbin/sestatus',   '/bin/ps -efl | grep httpd',

          #"/bin/ls -lt $stats_dir",

          '/usr/bin/crontab -l',  '/bin/crontab -l',

          '/bin/hostname',        '/bin/domainname',

         );

Update 2/23/2016

Having problems with ping_data.pl can't find timelocal.pl and ctime.pl.

The timelocal.pl comes from perl4 and has been superseded by Time::local, see http://perldoc.perl.org/Time/Local.html. The script timelocal.pl provides the function timegm which is used in ping_data.pl

The ctime.pl is a simple Perl emulation for the well known ctime(3C) function. # # This library is no longer being maintained, and is included for backward  ... see http://cpansearch.perl.org/src/JHI/perl-5.8.1/lib/ctime.pl. It appears ping_data.pl does not use ctime.pl.

Fix:

Change lines 410-412 from
##########################################################
require "timelocal.pl";
require "ctime.pl";

to 
##########################################################
use Time::Local; #require "timelocal.pl";
use POSIX;       #require "ctime.pl";

Note ping_data_plot.pl and frequency.pl use timelocal and ctime.

Update 3/9/2016

The above fix has been made both at Amity and at SLAC. The output from ping_data.pl is here.  Accessing http://202.12.103.71/cgi-bin/ping_data.pl gives:

Internal Server Error 
The server encountered an internal error or misconfiguration and was unable to complete your request. 
Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error. 
More information about this error may be available in the server error log.

The server is pingable and the web server is responding. I suspect the 5th line of the output " no crontab for pingeramity"  is causing the problem. Not sure why the output is coming out so soon.   You could comment out  the line   (around 329)

          '/usr/bin/crontab -l',  '/bin/crontab -l',

Update 4/9/2016

They have added a public DNS name pingeramity.in.