From 7cdb17ac6528ec7f5c62f147ebc250cc33929cc0 Mon Sep 17 00:00:00 2001 From: cvs2svn Date: Fri, 14 Oct 2005 17:51:33 +0000 Subject: [PATCH] This commit was manufactured by cvs2svn to create branch 'glite-jp- client_branch_1_0_0_pre_cares'. Sprout from glite-jp-client_branch_1_0_0_RC15 2005-10-14 17:51:31 UTC cvs2svn 'This commit was manufactured by cvs2svn to create branch 'glite-jp-' Delete: org.glite.jp.client/doc/README.jpimporter --- org.glite.jp.client/doc/README.jpimporter | 114 ------------------------------ 1 file changed, 114 deletions(-) delete mode 100644 org.glite.jp.client/doc/README.jpimporter diff --git a/org.glite.jp.client/doc/README.jpimporter b/org.glite.jp.client/doc/README.jpimporter deleted file mode 100644 index a5629db..0000000 --- a/org.glite.jp.client/doc/README.jpimporter +++ /dev/null @@ -1,114 +0,0 @@ -jpimporter is a daemon which take care of all job registration from particular -LB server, forwarding them to the JP primary service and also file uploads, which -means sending LB dumps, sendbox files etc. to ftp server dedicated by JP PS. - -The daemon runs two proceses, one for registrations and another for file uploads. -Both processes reads the local directory which has a given structure and are -handled by glite-lb-maildir library calls. - - - -Namely for the registrations, LB server creates the message describing job, its -owner and JP primary server address and stores it into given maildir location -(i.e. /tmp/lb_server_jpreg/). The jpimporter daemon which is running on the same -host is periodicaly scanning this directory and whenever new messages appears, -attempts to register this described job to JP PS. - -For the file upload is the jpimporter behavior almost the same except the -message has different structure and a file to deliver must be placed in the -filesystem. - -For LB dumps, there is another utility, which parses common LB dump files -(created when purging the LB server), creates one file per every job and stores -message describing the location, destination etc. to local directory. This -message directory should be obviously monitored by the jpimporter again. - -lb_dump_exporter utility usage: lt-lb_dump_exporter [option] - -h, --help Shows this screen. - -d, --dump Dump file location. - File generated by the glite-lb-purge - -s, --store New dump files storage. - Directory, where to store all dump files - -j, --jpps Target JPPS. - jpps where should the file be uploaded - -m, --lbmaildir LB maildir path. - Directory, where should be stored the message - describing the file upload (read by jpimporter) - -jpimporter daemon usage: glite-jp-importer [option] - -h, --help displays this screen - -k, --key private key file - -c, --cert certificate file - -C, --CAdir trusted certificates directory - -g, --debug don't run as daemon, additional diagnostics - -p, --jpps JP primary service server - this JPPS server is used by default, when user/lb/... - does not specifies one - -r, --reg-mdir path to the 'LB maildir' subtree for registrations - This directory is scanned for the job registration - messages. - -d, --dump-mdir path to the 'LB maildir' subtree for LB dumps - This directory is scanned for the file upload msgs. - -i, --pidfile file to store master pid - -t, --poll maildir polling interval (in seconds) - Specifies the time interval for which the process - JobRegistration/FileUpload sleeps after the unsuccessful - scan (find no new messages) -Examples: - -So, for the job registration and dump upload from the LB server, you should run the -LB server like this: -./glite_lb_bkserverd -c -k -S /var/tmp/purge -D /var/tmp/dump -J /tmp/lb_server_jpreg - -(Whenever the job is registered to the LB server, the message for jpimporter -is stored in the /tmp/lb_server_jpreg directory.) - -Then you should run the jpimporter daemon on the same host: -./glite-jp-importer -k -k -p jpps.server.address:8900 -r /tmp/lb_server_jpreg -d /tmp/lb_server_jpdump - -(Every job registration anounced in /tmp/lb_server_jpreg directory will be sent -to the JP PS at the address jpps.server.address:8900.) - -According the dump files - on the same host should be periodicaly ran the -glite-lb-purge utility. (Usually started by cron) Let say, that it stores the -LB dump file /var/tmp/purge/dump_file. - -Then you should run (most likely in the same cron job) -./lb_dump_exporter -d /var/tmp/purge/dump_file -s /var/tmp/dumps_per_job -j jpps.server.address:8900 -m /tmp/lb_server_jpdump - -(Then there is created a set of LB dump file - one per job - and according to them -lb_dump_exporter will also notify the glite-jp-importer) - - - - -For the sandbox files, you should use the JP client API to create messages for -jpimporter. The function glite_jpimporter_upload_files() do the job. It takes -one ore more files and create one tarball. Then everything works like with -LB dumps. - -There is an example utility in org.glite.jp.client/examples/jpps_upload_files.c -(staged as glite-jp-primary-upload_files). - -The glite_jpimporter_upload_files funftion prototype: - -int glite_jpimporter_upload_files( - /* JP client context. - * stores the error code/description - * user can set default JP PS address there and - * LB directory for jpimporter announcements - */ - glite_jpcl_context_t ctx, - - /* JobId - */ - const char *jobid, - /* File list. Stored in the array of string. - * Last item has to be NULL - */ - const char **files, - /* Location of the user proxy file - */ - const char *proxy); - - -- 1.8.2.3