(file) Return to README CVS log (file) (dir) Up to [venge] / src / wagon

File: [venge] / src / wagon / README (download)
Revision: 1.9, Wed Aug 16 23:54:37 2000 UTC (10 years ago) by graydon
Branch: MAIN
CVS Tags: HEAD
Changes since 1.8: +4 -4 lines
fixups.

Wagon is a simple, portable, lightweight, pull-model work distribution system
designed to farm out large scientific jobs over HTTP to a number of volunteer
computers participating in a large task.

it currently has built on FreeBSD 4.0 and Red Hat Linux 6.2.

***** IMPORTANT IMPORTANT IMPORTANT IMPORTANT *****
***** IMPORTANT IMPORTANT IMPORTANT IMPORTANT *****

if you install a wagon server, you MUST select one of the following three
options or else it will silently not work, do nothing, and annoy you
greatly. and you will email me and say "wagon does not work" and I will simply
ask you if you read the README file in the section marked with rediculous
IMPORTANT markings. and you will feel stupid and low and go throw yourself under
a truck, and your important scientific work will never get done. so choose one
of these, convince yourself that you know how to do it, read the associated man
pages, and do NOT complain if your server doesn't run because you were silly
enough to not read this and pay attention to it:

(1) apache runs CGIs as user "nobody" (or something), so you must make the
directory structure under the wagon CGIs writeable by user "nobody" (or whoever
apache runs CGIs as)

(2) apache runs CGIs as _you_, using some sort of nice setuid-cgi wrapper, so
you can just leave the directories as owned by you.

(3) apache runs CGIs as nobody, and you're not the sysadmin, so you must install
the wagon CGIs as setuid _you_ (4755), in order to give them access to the
directories you own. the usual warnings about setuid apply: it causes testicular
cancer and tax audits and whatnot, your life will end if you use it, but it will
get you around this problem.

***** IMPORTANT IMPORTANT IMPORTANT IMPORTANT *****
***** IMPORTANT IMPORTANT IMPORTANT IMPORTANT *****





USER PROGRAMS
~~~~~~~~~~~~~

wagon-build <name> <type> <filename> [key val]+

	builds a job named <name> of type <type> out of <filename>, optionally
	annotating the job with any extra key/val pairs provided. returns the
	name of the newly constructed job file.

	example:

	kat-moda:~ $ wagon-build 'water SCF test' g94 water.com
	398a5a86-kat-moda-474-1


wagon-push <url> <filename>+

	submits one or more files via HTTP upload to the specified URL.

	example:
	kat-moda:~ $ wagon-build 'water SCF test' g94 water.com
	398a5a86-kat-moda-474-1
	kat-moda:~ $ wagon-push http://jobhost/job-post 398a5a86-kat-moda-474-1


wagon-pull <url>

	fetches a job from <url>, reading first the filename, then a newline,
	then the contents of the job. writes out to the named file (if it's a
	safe name) in the current working directory.


wagon-client

	repeatedly runs "wagon-pull <url>/wagon-dispatch" in directory todo/,
	where <url> is loaded from cfg/url, pausing <pause> seconds between
	requests, where <pause> is read in from cfg/pause. if a job of type
	<type> appears in todo/, makes a unique directory <guid> in scr/ and
	runs "prx/<type>-proxy scr/<guid>/in scr/<guid>/out" in directory
	scr/<guid>, such that prx/<type>-proxy only needs to transform its
	first command line argument into its second. if scr/<guid>/out is
	produced, it is linked to fin/<jobname>, otherwise an error message is
	written to fin/<jobname>. any files found in fin/ cause wagon-client to
	run "wagon-push <url>/wagon-collect fin/<jobname>". all scratch
	directories in src/ are cleaned after each job terminates, and all todo/
	and fin/ files are unlinked (somewhat aggressively, to avoid infinite
	loops).

	example:

	$ mkdir todo scr cfg fin prx
	$ echo -n "http://jobhost" >cfg/url
	$ echo -n "10" >cfg/pause
	$ cat >prx/g94-proxy
	#!/bin/sh
	~/jobs/cdbget job <$1 >job.com
	nice -20 g94 job.com
	cp job.log $2
	^D
	$ ./wagon-client &



CGI PROGRAMS
~~~~~~~~~~~~

wagon-accept

	a CGI program which accepts incoming jobs, writing them to a new unique
	name in the tmp/ directory, then inspecting the job, determining its
	type, running jv/<type>-job-verify tmp/<job>. if the verification
	succeeds atomically linking <job> into the new/ directory. if a job
	makes it into new/, the job is queued for dispatch to the first
	available client.


wagon-dispatch

	a CGI program which links a job from the new/ directory to the run/
	directory, then feeds the job name followed by a newline and the job
	contents to the client, unlinking the entry in new/.


wagon-collect
	
	a CGI program which accepts incoming results to tmp/, inspects the
	corresponding entry in run/, determines the job type, and runs
	rv/<type>-result-verify tmp/<result> run/<job> on the uploaded
	results. if the results verify, it then proceeds to link the
	corresponding job from run/ to end/, and the results from tmp/ to
	res/. the job is then considered "complete".


wagon-view
	
	a CGI program which gives an HTML listing of the contents of a work
	distribution server, with links to view the job data and any existing
	results, as well as delete jobs.


wagon-delete
	
	a CGI program which erases jobs from a work distribution server. don't
	give out access to this CGI unless you want people nuking your jobs.



SUPPORTING PROGRAMS
~~~~~~~~~~~~~~~~~~~

cdbget <key> < <job>

	reads the value of the key <key> from the job file <job>. used to
	extract particular keys from a job, when writing verification scripts or
	work proxies.

	example:

	kat-moda:~ $ wagon-build g94 water.com
	398a5a86-kat-moda-474-1
	kat-moda:~ $ cdbget type <398a5a86-kat-moda-474-1
	g94

	
	

graydon hoare
Powered by
ViewCVS 0.9.2