POST-INSTALL CONFIGURATION: mvmda

If not created automatically by the configure/install process, you may
need to explicitly create the directories and files mentioned here.
Make sure they are accessible by whomever needs them.

You can find sample files and more information for most of these things
in the "files" directory of this package.


==== mvmf_libdir area ====

This is the 'datadir/mvmf' directory (e.g. /usr/local/share/mvmf).

Files and directories in this area should be readable by all mvmda users.

System-wide rc file:

   mvmda requires a system-wide script that controls its execution (removing
   hardwired-logic from the program itself and placing it in a script under
   the system administrator's control).  The script is read from a file which,
   if you haven't changed it during configure/build, is in the 'mvmda'
   subdirectory and is called 'mvmda-rc.mfl' .  If this file is not found,
   mvmda will refuse to run (unless you configured with
   --enable-mvmda-builtin-sysrc, in which case a compiled-in skeletal script
   is used).  The construction and flow of your control script is important.
   Refer to the example(s) provided, and to the mvmda-sysrc man page for
   more detail.


Namespaces:

   Before mvmda can write to a folder (or to "INBOX" or any other default
   name), a namespace must exist that contains the folder.  Refer to the
   NAMESPACES document, and to the example system-wide mvmda-rc.mfl files
   for more information.


Controls:

  If the user shell looks like an interactive shell, mvmda sets
  "pipe_allow" to TRUE when it starts, before the system-wide mvmda-rc
  file is executed.  The theory is that anybody who has an interactive
  shell probably ought to be able to create pipes.  Your system-wide
  rc script can revoke this if you think it's too much, e.g.:
      $admin_int_set( "pipe_allow", 0 );   // disable
      $admin_int_set( "pipe_allow", 1 );   // enable
  or you can change the code in mvmda.c if you don't like it.

  Some other controls you might want to set in the system rc file:

  data_directory : the directory where run-time data files are stored.
     At present this includes the database files used by the vacation
     facility, and any .cdb files that are referenced.  This may be
     an absolute path (if it starts with '/') or relative to the home
     directory.  Default is ".mvmda" (relative to the running user's
     home directory.)

    email_address_primary: Primary email address for this user.  This is
       used, for example, to supply the From address used in vacation
       messages if no :from parameter is given.  There is no default.  

    log_private_name: The name of a private log file.  If the value of
       this control begins with a "/" it is taken to be an absolute path;
       otherwise it is relative to the current directory (or absolute if
       you start it with "/");

    log_program_name: The name of the program when reporting to log files.



Hooks:

   mvmda and mfl make use of hooks, which are specifically-named MFL
   functions that are called at certain points in application execution to
   affect the execution in user-defined ways.  You (the system
   administrator, and potentially the end user) can define these hook
   functions.  Hook functions all have names beginning with '$hook_' .

   You can provide hook functions in many ways.  One way is simply to define
   them in-line in a script file (like, for example, the system-wide rc
   script).  This is reasonable for hooks that are expected to be used every
   time the application runs.  Another way is to let MFL search for them at
   the time they might be needed.  This is not the place to document hooks,
   but briefly: there is a hook search path, which is a list of directories
   in which hook functions might be defined.  This path initially starts out
   empty; it's expected that something (like the system-wide rc script) will
   set it up.  Whenever an application such as mvmda wants to invoke a hook,
   say '$hook_exitcode', as long as that hook is not yet defined the
   application will look for and run (as MFL) a corresponding file in each
   directory in the hook path.  The file is named after the hook, minus the
   $hook_ prefix, and is expected to have MFL code that defines the hook
   function.

   The logical and recommended place for system-defined hooks is
   in the 'mvmda/hooks' subdirectory in 'mvmf_libdir'.  But note that your
   system-wide rc script must add this directory to the hook search path.



==== mvmf_sysdir ====

This is the 'sysconfdir/mvmf' directory (e.g. /usr/local/sys/mvmf).

Files and directories in this area should be readable by system
processes that need it.

OTOH, mvmda uses nothing here.  (mvmtr and mvmcas do.)


-mm-			20040101/20070108		mem@geezer.org
						or	mem@mvmf.org