home *** CD-ROM | disk | FTP | other *** search
/ Otherware / Otherware_1_SB_Development.iso / amiga / comms / network / amigauuc.lha / AmigaUUCP / man / bms.man < prev    next >
Text File  |  1992-05-05  |  18KB  |  474 lines
  1.  
  2.                   BMS
  3.                 Batch Mail Server
  4.  
  5.     The BMS system implements a full fledged mail server subsystem under
  6.     AmigaUUCP.    It provides a manual and/or automated file transfer and
  7.     update capability.
  8.  
  9.     The system is implemented with a single program called BMS through
  10.     which you can execute various functions.
  11.  
  12.                    (I)
  13.                    INSTALLATION
  14.  
  15.     In order to install BMS you must create an assignment called BMS:
  16.     then run BMS INSTALL:
  17.  
  18.     1> makedir uulib:bms
  19.     1> assign bms: uulib:bms
  20.     1> bms install
  21.  
  22.     BMS will automatically setup defaults.  Initially the file access area
  23.     is limited to UUPUB: and BMS:PUB.  BMS creates BMS:PUB and BMS:TMP, and
  24.     BMS's permanent database resides in BMS:BMS.DB
  25.  
  26.     If you have a custom mailer with USER BOUNCING then you must add two
  27.     dummy users to your PASSWD file, named 'bms_in' and 'bms_err'.
  28.  
  29.     Setup an alias for bms-manager to point to an appropriate mailbox.
  30.     This is where BMS will mail text message describing events (such
  31.     as somebody dequeueing your node or a GET you started completing)
  32.  
  33.     You must setup a DCRON entry for the BMS system.  The command 'BMS
  34.     BATCH' should be run several times between uucico calls to process
  35.     incomming requests and queue outgoing requests.  NOTE!!! Your path must
  36.     have UUCP:C at the time your startup DCron (this is a bug in BMS)
  37.  
  38.     IN GENERAL EVERY NODE HAS A BMS:PUB/FILES TEXT FILE RETRIEVABLE BY
  39.     OTHER PEOPLE.  This file should contain a description of what is
  40.     available on your system.
  41.  
  42.  
  43.                    (II)
  44.                 REGISTRATION
  45.  
  46.     Before you can make any requests you must register with the remote
  47.     BMS node you wish to make requests from.  The form of the
  48.     registration command is as follows:
  49.  
  50.     1> BMS REGISTER dest_path RETPATH ret_path ALIAS alias
  51.  
  52.     You must specify the path to the remote machine (dest_path) and the
  53.     return path from the remote machine (ret_path).  You can also specify
  54.     an optional alias (now or later) to reduce the amount of typing you
  55.     must do when you make requests.  So, for example, if my machine was
  56.     'uunet!overload' and I wanted to register with a remote site called
  57.     'uunet!able!test' then I would say:
  58.  
  59.     BMS constructs it's special user name by appending a '!bms_in' to the
  60.     path.  The path format you use must work with this!
  61.  
  62.  
  63.     1> BMS REGISTER uunet!able!test RETPATH able!uunet!overload ALIAS test
  64.  
  65.     Note that the RETPATH is RELATIVE THE REMOTE SITE.    You must specify a
  66.     return path that the remote site can use to get back to you.  You may
  67.     not request any files until the BMS system has received a response from
  68.     the remote site.
  69.  
  70.     This requirement greatly reduces the number of bounces the remote site
  71.     will suffer.  Considering that a remote site 'hub' (such as my machine)
  72.     will service several connections at once with new ones comming in every
  73.     day, reducing the number of bounces that I (and other sites) get is
  74.     very, very important.  Many sites would not be able to offer BMS
  75.     services if they had to deal with a huge number of bounces.
  76.  
  77.                 TESTING THE REGISTRATION
  78.  
  79.     1> BMS
  80.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  81.     REGISTRATION uunet!able!test ALIAS=test    STAT=1:REG-SEND to=off
  82.  
  83.     The 'STAT' field indicates the current status. 'REG-SEND' indicates
  84.     that the BMS system will send off the registration request.  When DCron
  85.     comes around and runs 'BMS BATCH' (which you can also do manually),
  86.     this will set to 'REG-SENT' and to=6d (timeout of 6 days).
  87.  
  88.     When the remote BMS system gets the request it will respond with an
  89.     acknowledgement.  You should receive this acknowledgement in a
  90.     reasonable amount of time, it all depends how often your site and the
  91.     remote site gets mail.
  92.  
  93.     If the remote BMS system responds then the status will change to:
  94.  
  95.     1> BMS
  96.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  97.     REGISTRATION uunet!able!test ALIAS=test    STAT=1:REG-CONNECTED to=29d
  98.  
  99.     This indicates that you are now 'connected' to the remote site.  The
  100.     timeout of 29 days simply means that your BMS system will send a
  101.     keepalive packet out once a month.    Theoretically once a registration
  102.     is established it will never get lost unless manually dequeued.
  103.  
  104.     Note in 'STAT=1:...', the '1' is the IDentifier for the registration.
  105.  
  106.                 LOCAL TESTING
  107.  
  108.     You can test the BMS system locally without batching to the outside
  109.     world by creating a dummy machine in your UULIB:Domain file with an
  110.     entry called 'test MD UU <your_machine_name_goes_here>'... Registering
  111.     for local tests would work as follows... my machine is called 'overload'
  112.     so I would:
  113.  
  114.     (1) modify my UULIB:Domain file adding the dummy 'test' entry given
  115.     above
  116.  
  117.     (2) BMS REGISTER test RETPATH overload ALIAS test
  118.  
  119.  
  120.             RECEIVING REMOTE REGISTRATIONS
  121.  
  122.     When you receive a remote registration.  That is, some tries to
  123.     register with you, your BMS status will show a line as follows:
  124.  
  125.     1> BMS
  126.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  127.     REGISTRATION <remote_mach>     ALIAS=<none>    STAT=2:REG-REMOTE to=179d
  128.  
  129.     The <remote_mach> is the RETPATH the other person specified when they
  130.     connected with you.  For received registrations the registration
  131.     remains valid for 179 days.   This 'timeout' is reset back to 179
  132.     whenever the remote machine sends a keepalive packet to you, which
  133.     occurs every month.
  134.  
  135.                 VARIABLES
  136.  
  137.     You can modify various BMS variables globally or for specific
  138.     registrations.
  139.  
  140.     1> BMS VARS D=default
  141.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  142.     PARAMS:
  143.         MaxRxBpd  100000        <not implemented yet>
  144.         MaxTxBpd  100000        MAXIMUM BYTES TRANSMITTED PER DAY
  145.         MaxRxBpw  400000        <not implemented yet>
  146.         MaxTxBpw  400000        MAXIMUM BYTES TRANSMITTED PER WEEK
  147.         MaxRxMail 56000        <not implemented yet>
  148.         MaxTxMail 56000        MAXIMUM OUTGOING EMAIL MESSAGE SIZE
  149.         MinMail   15000        MINIMUM OUTGOING EMAIL MESSAGE SIZE
  150.         MirRxBpd  30000        <not implemented yet> (mirroring)
  151.         MirTxBpd  50000        <not implemented yet> (mirroring)
  152.         CacBwPerc 10        <not implemented yet> (caching)
  153.         ReqSwamp  10        <not implemented yet>
  154.         MirSwamp  20        <not implemented yet>
  155.  
  156.     The variables pretty much speak for themsevles.  You may modify a
  157.     variable as shown below.  If no destination is specified then the
  158.     DEFAULTS are modified.
  159.  
  160.     1> BMS MaxTxBpd 50000
  161.  
  162.     You may modify the variable(s) relating to a specific destination by
  163.     specifying a D=<destination> where <destination> is either an alias or
  164.     a full destination path to a registered destination.
  165.  
  166.     1> BMS MaxTxBpd 50000 D=test
  167.  
  168.     You may list the variables associated with all registered nodes using
  169.     'BMS VARS'.  It may look something like the following:
  170.  
  171.     1> BMS MaxTxBpd 300000 D=test
  172.     1> BMS VARS
  173.  
  174.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  175.     PARAMS:
  176.         MaxRxBpd  100000
  177.         MaxTxBpd  100000
  178.         MaxRxBpw  400000
  179.         MaxTxBpw  400000
  180.         MaxRxMail 56000
  181.         MaxTxMail 56000
  182.         MinMail   15000
  183.         MirRxBpd  30000
  184.         MirTxBpd  50000
  185.         CacBwPerc 10
  186.         ReqSwamp  10
  187.         MirSwamp  20
  188.     REGISTRATION test         ALIAS=test    STAT=1:REG-CONNECTED to=15d
  189.     PARAMS:
  190.         MaxRxBpd  100000 (default)
  191.         MaxTxBpd  300000
  192.         MaxRxBpw  400000 (default)
  193.         MaxTxBpw  400000 (default)
  194.         MaxRxMail 56000 (default)
  195.         MaxTxMail 56000 (default)
  196.         MinMail   15000 (default)
  197.         MirRxBpd  30000 (default)
  198.         MirTxBpd  50000 (default)
  199.         CacBwPerc 10 (default)
  200.         ReqSwamp  10 (default)
  201.         MirSwamp  20 (default)
  202.  
  203.  
  204.     Note that the MaxTxBpd variable(s) refer to the maximum number of
  205.     bytes per day BMS is allowed to send GLOBALLY.  This is NOT on a
  206.     per-node basis.
  207.  
  208.     If you have 5 registrations and MaxTxBpd is set to 100000 on all of
  209.     them (i.e. the default), the BMS system will not transmit more then
  210.     100000 bytes per day overall.  If you give one registration a lower
  211.     value you effectively limit data sent to the registration to the lower
  212.     value, but it still counts as data sent overall.  If you give one
  213.     registration a limit of 200000 that allows no more then 100000 to the
  214.     other nodes overall, except 200000 to that specific node, but no more
  215.     then 200000 overall.
  216.  
  217.     A variable overide may be restored to the 'default' by setting it's
  218.     value to 0.  E.G
  219.  
  220.     1> BMS MaxTxBpd 0 D=test
  221.  
  222.     Sets MaxTxBpd for the TEST registration back to whatever the default
  223.     has been specified at.  GENERALLY YOU DO NOT WANT TO SET DEFAULTS TO 0.
  224.     This applies only to variable overides for specific registrations that
  225.     you wish to restore back to using the default values.
  226.  
  227.  
  228.                   FILE ACCESS
  229.  
  230.     You can set global file access with ADDFILE, REMFILE, and RESTRICT.
  231.     Normally file access permissions are specified for the default
  232.     node and take effect globally.  You can also specify file access
  233.     permissions for specific registrations by giving the D=name
  234.     argument:
  235.  
  236.     1> BMS ADDFILE uucp:c
  237.     1> BMS FILES
  238.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  239.     ACCESS:  UUPUB:
  240.     ACCESS:  BMS:PUB
  241.     ACCESS:  uucp:c
  242.     REGISTRATION test         ALIAS=test    STAT=1:REG-CONNECTED to=5d
  243.     REGISTRATION overload     ALIAS=<none>    STAT=2:REG-REMOTE to=154d
  244.  
  245.     1> BMS RESTRICT uucp:c/fubar D=test
  246.     1> BMS FILES
  247.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  248.     ACCESS:  UUPUB:
  249.     ACCESS:  BMS:PUB
  250.     ACCESS:  uucp:c
  251.     REGISTRATION test         ALIAS=test    STAT=1:REG-CONNECTED to=4d
  252.     ACCESS: -uucp:c/fubar
  253.     REGISTRATION overload     ALIAS=<none>    STAT=2:REG-REMOTE to=154d
  254.  
  255.     1> BMS REMFILE uucp:c
  256.     1> BMS FILES
  257.     REGISTRATION <defaults>     ALIAS=default    STAT=0:<unknown> to=off
  258.     ACCESS:  UUPUB:
  259.     ACCESS:  BMS:PUB
  260.     REGISTRATION test         ALIAS=test    STAT=1:REG-CONNECTED to=4d
  261.     ACCESS: -uucp:c/fubar
  262.     REGISTRATION overload     ALIAS=<none>    STAT=2:REG-REMOTE to=154d
  263.  
  264.  
  265.     ADDFILE adds a file to those allowed to sent to remote nodes REMFILE
  266.     removes a file from the access list RESTRICT disallows a specific file.
  267.  
  268.     THE BMS SYSTEM IS FULLY CAPABLE OF TRANSFERING DIRECTORY HIERARCHIES.
  269.     Thus, there are cases where allowing a directory but restricting one or
  270.     more subdirectories will be a useful feature to have.
  271.  
  272.                GETTING DIRECTORY LISTINGS
  273.  
  274.     Current this is not supported in an automatic manner but to allow
  275.     people to query your system as to what is supported you should create a
  276.     BMS:PUB/FILES file, a text file containing general information and a
  277.     list of available files.
  278.  
  279.     So, until I work in an automated directory thingy please use the GET
  280.     command below to obtain this file.
  281.  
  282.  
  283.             GETTING FILES AND DIRECTORIES
  284.  
  285.     You can retrieve files and/or directories with the GET command.
  286.     For example, if I wanted to retrieve something from the machine
  287.     'test' I would say:
  288.  
  289.  
  290.     1> BMS D=test GET bms:pub/files TO uupub:files.test
  291.  
  292.     D=test            - node you want to get files from
  293.     bms:pub/files        - remote file/dir to get (full path)
  294.     uupub:files.test    - local file/dir to put results in (full path)
  295.  
  296.     AS WITH ALL OTHER TRANSFER COMMANDS, YOU MUST BE 'REGISTERED' WITH THE
  297.     REMOTE NODE BEFORE YOU MAY RETRIEVE ANY DATA.
  298.  
  299.     the BMS system appends the suffix '-XXX' to all incomming
  300.     files/directories until the file or directory is completely received,
  301.     then renames it back to what it was supposed to be.
  302.  
  303.  
  304.                     COMMANDS
  305.  
  306.     BMS HELP        Help!
  307.  
  308.     Print out a quick list of available commands.  NOTE!  Not all
  309.     commands have been implemented, see below!
  310.  
  311.     BMS [STATUS] [VARS] [FILES] [STATS] [ACTIVE] [ALL] [DEBUG] [D=dest]
  312.  
  313.     Display the status of the BMS system.  This is the default
  314.     (you do not need the 'STATUS' keyword).  If not destination
  315.     is specified all destinations are displayed.
  316.  
  317.     VARS    Display the state of various parameters
  318.  
  319.     ACTIVE    Display all active communication connections and all
  320.         files transfers in progress
  321.  
  322.     FILES    Display the file access list
  323.  
  324.     ALL    Display dequeued nodes that have not timed out.  These
  325.         normally do not show up in the list.
  326.  
  327.     STATS    NOT IMPLEMENTED YET
  328.  
  329.     BMS INSTALL     Install the BMS system on your system
  330.  
  331.     Install BMS on your system.  This command will create appropriate
  332.     directories and setup BMS files, storing default information.
  333.  
  334.     You must do further installation such as, for example, running
  335.     BMS BATCH at periodic intervals.
  336.  
  337.     BMS BATCH        Run BMS Batching
  338.  
  339.     This command is normally run from your S:Crontab several times a
  340.     day.  You probably want to run it at least twice between uucico
  341.     runs.
  342.  
  343.     This command scans all incomming mail for the BMS system and
  344.     generates appropriate responses.  Incomming mail is always routed
  345.     through a dummy user called 'bms_in'.
  346.  
  347.     Responses may include lharc'ing and uuencoding various materials
  348.     and the outbound queuing of said materials.
  349.  
  350.     BMS REGISTER <destination_bms_system> [RETPATH <return_path>] [ALIAS <alias>]
  351.  
  352.     This command requests that your BMS system contact and register
  353.     itself with a remote BMS system.  If the nominal email address of
  354.     your system is not sufficient for the remote site to be able to
  355.     respond then you should specify a return path RELATIVE TO THE
  356.     REMOTE SITE.  Note that email paths do not include user names.
  357.  
  358.     BMS constructs it's special user name by appending a '!bms_in' to
  359.     the path.  The path format you use must work with this!
  360.  
  361.     If you with to associate an alias with the system you may do so at
  362.     this time with the ALIAS command.
  363.  
  364.     BMS RENAME <destination_bms_system> TO <newpath_for_dest_bms_system>
  365.  
  366.     This command instructs BMS to use a different mail path when
  367.     communicating with the specified destination.
  368.  
  369.     BMS D=<destination_bms_system> ALIAS <alias>
  370.  
  371.     This command changes the alias name used to identify the specified
  372.     destination BMS system.
  373.  
  374.     BMS DEQUEUE <id> [MESSAGE <message>]
  375.  
  376.     Dequeue a request, either locally or remotely generated. Dequeueing
  377.     a remote request results in an abort message being sent to the
  378.     remote BMS site, aborting any additional mailings that have yet to
  379.     be sent from that site.
  380.  
  381.     When Dequeuing remote requests you may specify a message to be sent
  382.     to the remote user describing why the request has been dequeued.
  383.  
  384.     BMS DESTROY <id>
  385.  
  386.     USE THIS COMMAND ONLY AS A LAST RESORT!  This command *destroys* a
  387.     communications subtree, leaving the remote end hanging.  You should
  388.     NOT destroy communications unless something goes very very wrong.
  389.     Use BMS DEQUEUE to dequeue a communication if you want to abort it.
  390.  
  391.     BMS STOP <id>
  392.     BMS START <id>
  393.  
  394.     NOT IMPLEMENTED YET
  395.  
  396.     BMS RETRY <id>
  397.  
  398.     This command should not normally be used.  This command forces a
  399.     timeout for whatever state a communication tree is in.    The
  400.     resulting action depends on the state.... generally, forcing a
  401.     timeout on DONE states remove them, while forcing a timeout
  402.     on a RECEIVER type state generates a retry request.
  403.  
  404.     BMS is pretty smart about automatically retrying, you should not
  405.     use this command unless you know what you are doing.
  406.  
  407.     BMS [D=<destination_bms_system>] MAXTXBPD <value>
  408.     BMS [D=<destination_bms_system>] MAXTXBPW <value>
  409.     BMS [D=<destination_bms_system>] MINMAIL  <value>
  410.             ....
  411.  
  412.     Currently, only transmit specifications may be given.  Variables
  413.     may be specified for the default or for specific registrations.
  414.     Setting a variable for a specific registration to 0 resumes the
  415.     default value.    Normally you do not set any defaults to 0.
  416.  
  417.     MAXTXBPD    - Maximum transmit bytes per day
  418.     MAXTXBPW    - Maximum transmit bytes per week
  419.     MINMAIL     - Minimum message size for block data under a heavy
  420.               load.  Prevents data from being broken up into
  421.               messages 10 bytes long when under a heavy load.
  422.  
  423.     BMS [D=<destination_bms_system>] ADDFILE <file/dir>
  424.  
  425.     Add a file or directory to the access list for a particular system
  426.     or to the default file access list.
  427.  
  428.     BMS [D=<destination_bms_system>] REMFILE <file/dir>
  429.  
  430.     Remove a file or directory from the access list for a particular
  431.     system or for the default file access list
  432.  
  433.     BMS [D=<destination_bms_system>] RESTRICT <file/dir>
  434.  
  435.     Specify a file or directory that is specifically DISALLOWED for a
  436.     particular system or for the default file access list.    That is, if
  437.     you generally allow PUB:BIN/ you can disallow, say PUB:BIN/FUBAR
  438.     with this command while still allowing any other file in PUB:BIN/
  439.     to be sent.
  440.  
  441.     You can also use this command to give special permissions to
  442.     someone.
  443.  
  444.     BMS [D=<destination_bms_system>] GET file/dir TO file/dir
  445.  
  446.     Request a specific file or directory from a remote BMS system. If
  447.     the file/dir is in your BMS system's databases from earlier
  448.     directory retrievals and no conflicts are found, then you need not
  449.     specify the destination system.
  450.  
  451.     If you are GETting a file your TO field may specify either a file
  452.     or directory.  If only a directory is specified then the same file
  453.     name is used.
  454.  
  455.     mail will be sent to bms-manager when the GET operation is
  456.     complete.  Files under construction have a -XXX suffix.  NOTE! Even
  457.     if the file is the correct size you should not touch it if the -XXX
  458.     suffix is still there!    BMS can fill in files out of order so there
  459.     may still be blocks of NULs in the file.
  460.  
  461.     BMS [D=<destination_bms_system>] PUT file/dir
  462.  
  463.     NOT IMPLEMENTED YET
  464.  
  465.     BMS [D=<destination_bms_system>] MIRROR file/dir TO file/dir
  466.  
  467.     NOT IMPLEMENTED YET
  468.  
  469.     BMS CLEANUP
  470.  
  471.     This command cleans up BMS's database.  You should cleanup BMS's
  472.     database about once a week.
  473.  
  474.