You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

Introduction

Originally (prior to June 2018), the gathering of data from the MAs was initiated by the SLAC end.

  • However, access to a web server at the Beijing MA run by Guangzhou was not allowed. 
  • Also since the MAs from the PingER Android project did not want to have to run a web server, they needed a proxy to copy their data to. This proxy, in turn, has to be accessible from SLAC.Solution

Since we could not initiate the gathering from the SLAC end, we chose to use the anonymous ftp service at SLAC (see https://www.slac.stanford.edu/comp/unix/ftp.html).

  • Be aware data is only kept for 4 days in anonymous incoming FTP and then is removed.  The directories are preserved.  One can delete files and directories by using rm and rmdir on /afs/slac/public/incoming from the  unix command line (one cannot delete files and directories within ftp).

1. In this case, the MA (e.g. a script initiated at the Beijing MA and run at Beijing by say user Ann who does not have an account at SLAC)  daily runs a script (as a cronjob) to use the incoming anonymous FTP at SLAC to store the day's data at SLAC. An example of an FTP session to copy a file is seen at the Proxy FTP script document.

  1. At most MAs (with the exception of SLAC), the data is stored in /usr/local/share/pinger/data, e.g.

    file: /usr/local/share/pinger/data found on dxmon3.cern.ch 
    total 66756
    -rw-r--r-- 1 root root 12244303 Jun  7 18:56 ping-2018-06.txt
    -rw-r--r-- 1 root root 56049692 Jun  1 01:55 ping-2018-05.txt
  2. The data from the MA is copied to a directory associated with the MA  and read-write permissions set for group sf. We chose to use the FTP anonymous incoming directory path /afs/slac/public/incoming/pinger/proxy/ and this was set up. The PingER MA then copies the data to the above directory with the PingER MA host name subdirectory, e.g.

    169cottrell@pinger:~$ls -l /afs/slac/public/incoming/pinger/proxy/2001:da8:270:2018:f816:3eff:fef3:bd3/
    total 23277
    -rw-rw-r-- 1 saqibali sf  9360738 Jun  6 20:20 ping-2018-04.txt
    -rw-rw-r-- 1 saqibali sf 12394002 Jun  6 20:20 ping-2018-05.txt
    -rw-rw-r-- 1 saqibali sf  2079565 Jun  6 20:01 ping-2018-06.txt

    Since the user Ann does not have a SLAC user account this is done via anonymous ftp to ftp://ftp.slac.stanford.edu/incoming.  The first time Ann will need to create the directory for her site (e.g. as seen above 2001:da8:270:2018:f816:3eff:fef3:bd3).

2. Due  to security concerns*, we cannot access anonymous incoming FTP space from a web CGI script such as ping_data.pl (that is used by getdata.pl) thus we first move the data from the FTP anonymous space via a local (non-web job) to a space accessible via the web

  • This is done by the script proxy.pl which moves the files from  /afs/slac.stanford.edu/public/incoming/pinger/proxy/2001:da8:270:2018:f816:3eff:fef3:bd3/ to /nfs/slac/g/net/pinger/pingerdata/hep/data/proxy/2001:da8:270:2018:f816:3eff:fef3:bd3/
    • the node name (in this case 2001:da8:270:2018:f816:3eff:fef3:bd3) is derived from NODEDETAILS.
    • we use a move since one cannot replace an existing file via the anonymous FTP server (one gets a message 'Overwrite permission denied').
  • Then the getdata.pl script runs nightly at SLAC and calls ping_data.pl via wget to gather the data for all the active MAs (including the proxies). Getdata.pl saves the gathered data in:

    /nfs/slac/g/net/pinger/pingerdata/hep/data/<host>/ping-<YYYY>-<MM>.txt
    /nfs/slac/g/net/pinger/pingerdata/hep/data/2001:da8:270:2018:f816:3eff:fef3:bd3/ping-2018-06.txt

    If this is done manually the SLAC account will need permissions to create a directory in /nfs/slac/g/net/pinger/pingerdata/hep/data/. This directory has permissions for user pinger and group iepm

    176cottrell@pinger:~$ls -ld /nfs/slac/g/net/pinger/pingerdata/hep/data
    drwxrwsr-x 220 pinger iepm 32768 May 16 00:45 /nfs/slac/g/net/pinger/pingerdata/hep/data/
  • To add the user to the iepm group

    178cottrell@pinger:~$ypgroup adduser -group iepm -u saqibali
    Jun  7 10:30:33 2018 User(s) 'saqibali' added to group 'iepm'
    Jun  7 10:30:33 2018 User(s) must logout/login for this to take effect.
    Jun  7 10:30:33 2018 Starting NIS post actions.
    Jun  7 10:30:33 2018 [/usr/ccs/bin/make group]
    copied group to /afs/slac/service/admin/NIS
    updated group
    pushed group
    179cottrell@pinger:~$ypgroup exam -group iepm
    Group 'iepm':
            GID:     2087
            Comment:
            Last modified at Jun  7 10:30:32 2018 by cottrell
            Owners:  cottrell
            Members: cottrell, iepm, pinger, saqibali, ytl
            This is a secondary group.

Automating

The steps are automated with synchronized cronjobs.

  • A job at Beijing is required to do the anonymous ftp of the recent data from the Beijing MA to the incoming FTP server at SLAC. It runs at 14:01 Beijing time or 12:01am California standard (winter) time and 1:01am California summer time.

  • The data then needs to be copied (by proxy.pl which takes a couple of seconds to run) from the anonymous FTP incoming space (/afs/slac/public/incoming/) to a directory accessible (see above) for reading from the ping_data.pl web CGI script that is called by wget from getdata.pl.
  • getdata.pl is then scheduled to run at SLAC to copy the selected data from the accessible directory /nfs/slac/g/net/pinger/pingerdata/hep/data/proxy/2001:da8:270:2018:f816:3eff:fef3:bd3/ 

  • We want to standardize the time of the various cronjobs. 1:01am SLAC summer localtime is 4:01pm in China, and 12:01 midnight SLAC standard (winter) localtime is also 4:01pm in China.  Thus to catch the Chinese data both winter and summer time California, we schedule the cron jobs at SLAC to run at just past 1:00am.

The various jobs have to be synchronized:

  • The copying of data to the anonymous FTP server and moving from there to the PingER raw data archive needs to complete before getdata.pl starts at 32 minutes past midnight local time each night at SLAC
  • The data is copied from the MA to anonymous FTP incoming space at  then proxy.pl, needs to be scheduled to copy the data from anonymous FTP directory to the directory accessible by the ping_data.pl CGI script.
    • This also has to complete before getdata.pl is scheduled, 
    • proxy.pl takes < 5 seconds to execute. 
    • proxy.pl is therefore currently scheduled to run at 20 minutes past 12:00am California standard time
  • Once the move is completed by proxy.pl then getdata.pl can be scheduled to gather and save the selected data from the MAs in the PingER raw data archive at:
    /nfs/slac/g/net/pinger/pingerdata/hep/data/<host>/ping-<YYYY>-<MM>-<DD>.txt.gz
    • This (getdata.pl) takes about 15 minutes.
    • getdata.pl is scheduled to run at 32 minutes past 1:00am localtime.
  • The analysis of the hourly data by analyze-all.pl needs to start after getdata.pl has completed. Currently analyze-all.pl starts as a cron job at 55 minutes past 2 am local time at SLAC each morning. the schedling of the jobs at SLAC is shown below;

    20 1 * * * /afs/slac/package/pinger/proxy.pl
    32 1 * * * /afs/slac/package/pinger/getdata.pl > /afs/slac/g/www/www-iepm/pinger/slaconly/getdata.err
    55 2 * * * /afs/slac/package/pinger/analysis/analyze-all.pl --date 1days #Takes 25:14 10/20/2011 (55 mins 9/21/2011, 70 minutes 5/11/2018)

    The analyzed data from analyze-all.pl is saved in files of the form below, the contents are described in PingER data flow at SLAC:

    /nfs/slac/g/net/pinger/pingerreports/hep/<metric>/<metric>-<len>-<by>-<year>-<month>-<day>.txt.gz#len=100|1000, by=by-node|by-site.
    /nfs/slac/g/net/pinger/pingerreports/hep/minimum_rtt/minimum_rtt-100-by-node-2011-05-01.txt.gz

See https://confluence.slac.stanford.edu/display/IEPM/PingER+data+flow+at+SLAC for the data flow. The use of the proxy is triggered by the  NODEDETAIL Data Server entry (e.g. proxy=1) to tell ping_data.pl to gather the data from the SLAC anonymous ftp server (via the copy)that is basically acting as a proxy. 

This whole mechanism is also interesting since it could be extended and a step to providing support for the Android PingER project at Amity in Delhi, India which also needs a proxy.


  • If an anonymous ftp server allows anonymous upload, and also world read access, it quickly becomes a haven for stolen software distribution.

 

  • No labels