icadvanced.sdf

!init OPT_LOOK="icdevgroup"; OPT_STYLE="manual"
# $Id: icadvanced.sdf,v 1.17 2004-05-05 15:22:30 jon Exp $

!define DOC_NAME "Advanced Interchange Topics"
!define DOC_TYPE ""
!define DOC_CODE "icadvanced"
!define DOC_VERSION substr('$Revision: 1.17 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://www.icdevgroup.org/doc/icadvanced.html"
!build_title

H1: Advanced Interchange Topics

* Maintaining production Interchange servers
* Interchange Administration Tool Development
* Making catalog skeletons for use with makecat
* Building custom link programs
* Installation tips and troubleshooting
* Usertracking

H1: Maintaining Interchange

Some utilities are supplied in the VendRoot/bin directory:

!block example
 compile_link Compiles an Interchange vlink or tlink CGI link
 configdump   Dumps the configuration directives for a particular catalog
 dump         Dumps the session file for a particular catalog
 expire       Expires sessions for a particular catalog
 expireall    Expires all catalogs
 makecat      Make catalog
!endblock

Some example scripts for other functions are in the C<eg/> directory of the software distribution.

Some thought should be given to where the databases, error logs, and session files should be located, especially on an ISP that might have multiple users sharing an Interchange server. In particular, put all of the session files and logs in a directory that is not writable by the user. This eliminates the possibility that the catalog may crash if the directory or file is corrupted.

To test the format of user catalog configuration files before restarting the server, set (from VendRoot):

!block example
   bin/interchange -test
!endblock

This will check all configuration files for syntax errors, which might otherwise prevent a catalog from booting. Once a catalog configures properly, user reconfiguration will not crash it. It will just cause an error. But, it must come up when the server is started.

H2: Starting, Stopping, and Re-starting the Servers

The following commands need to have VENDROOT changed to the main directory where Interchange is installed. If the Interchange base directory is C</home/interchange/>, the start command would be C</home/interchange/bin/interchange>.

Do a C<perldoc VENDROOT/bin/interchange> for full documentation.

To start the server with default settings:

!block example
   VENDROOT/bin/interchange
!endblock

Assuming the server starts correctly, the names of catalogs as they are configured will be displayed, along with a message stating the process ID it is running under.

It is usually best to issue a restart instead. It doesn't hurt to do a restart if you're actually starting the first time. And, if a server is already running (from this VENDROOT), a new start attempt will fail. To restart the server:

!block example
   VENDROOT/bin/interchange -restart
!endblock

The C<-r> option is the same as C<-restart>.

This is typically done to force Interchange to re-read its configuration. A message will be displayed stating that a TERM signal has been sent to the process ID the servers are running under. This information is also sent to C<VENDROOT/error.log>. Check the error.log file for confirmation that the server has restarted properly.

To stop the server:

!block example
   VENDROOT/bin/interchange -stop
!endblock

A message will be displayed stating that a TERM signal has been sent to the process ID the server is running under. This information is also sent to C<VENDROOT/error.log>.

Because processes waiting for selection on some operating systems block signals, they may have to wait for HouseKeeping seconds to stop. The default is 60.

To terminate the Interchange server with prejudice, in the event it will not stop:

!block example
   VENDROOT/bin/interchange -kill
!endblock

H2: UNIX and INET modes

Both UNIX-domain and INET-domain sockets can be used for communication. INET domain sockets are useful when more than one web server, connected via a local-area network (LAN), is used for accessing an Interchange server.

{{B:Important note:}} When sending sensitive information like credit card numbers over a network, always ensure that the data is secured by a firewall, or that the Interchange server runs on the same machine as any SSL-based server used for encryption.

Use the C<->i and C<->u flags if you only want to use one communication method:

!block example
   # Start only in UNIX mode
   VENDROOT/bin/interchange -r -u

   # Start only in INET mode
   VENDROOT/bin/interchange -r -i
!endblock

H2: User Reconfiguration

The individual catalogs can be reconfigured by the user by running the [reconfig] support tag. This should be protected by one of the several forms of Interchange authentication, preferably by HTTP basic authorization.
See {{C[jump="icconfig.html#RemoteUser"]RemoteUser}}.

The command line can be reconfigured (as the Interchange user) with:

!block example
   VENDROOT/bin/interchange --reconfig=I<catalog>
!endblock

It is easy for the administrator to manually reconfigure a catalog. Interchange simply looks for a file C<etc/reconfig> (based in the Interchange software directory) at HouseKeeping time. If it finds a script name that matches one of the catalogs, it will reconfigure that catalog.

H2: Expiring Sessions

If Interchange is using DBM capability to store the sessions, periodically expire old sessions to keep the session database file from growing too large.

!block example
   expire -c catalog
!endblock

There is also an C<expireall> script which reads all catalog entries in C<interchange.cfg> and runs C<expire> on them. The C<expire> script accepts a C<-r> option which tells it to recover lost disk space.

On a UNIX server, add a crontab entry such as the following:

!block example
   # once a day at 4:40 am
   40 4 * * *    perl /home/interchange/bin/expireall -r
!endblock

Interchange will wait until the current transaction is finished before expiring, so this can be done at any time without disabling web access. Any search paging files for the affected session (kept in C<ScratchDir>) will be removed as well.

If not running DBM sessions, use a Perl script to delete all files not modified in the last one or two days. The following will work if given an argument of a session directory or session files:

!block example
   #!perl
   # expire_sessions.pl -- delete files 2 days old or older

   my @files;
   my $dir;
   foreach $dir (@ARGV) {
       # just push files on the list
       if (-f $dir) { push @files, $_; next; }

       next unless -d $dir;

       # get all the file names in the directory
       opendir DIR, $dir or die "opendir $dir: $!\n";
       push @files, ( map { "$dir/$_" } grep(! /^\.\.?$/, readdir DIR));
   }

   for (@files) {
       unless (-f $_) {
           warn "skipping $_, not a file.\n";
           next;
       }
       next unless -M $_ >= 2;
       unlink $_ or die "unlink $_: $!\n";
   }
!endblock

It would be run with a command invocation like:

!block example
   perl expire_sessions.pl /home/you/catalogs/simple/session
!endblock

Multiple directory names are acceptable, if there is more than one catalog.

This script can be adjusted as necessary. Refinements might include reading the file to "eval" the session reference and expire only customers who are not members.

H2: My session files change to owner root every day!

You have the expireall C<-r> entry in the root crontab, and it should either be in the Interchange user crontab or run as:

!block example
44 4 * * * su -c "/ICROOT/bin/expireall -r" ICUSERNAME
!endblock


H1: Interchange Components

Interchange components are merely portions of HTML/ITL that are included into pages within the site depending on options set in the Admin UI. The default component set includes the following:

!block example
best_horizontal
best_vertical
cart
cart_display
cart_tiny
category_vertical
cross_horizontal
cross_vertical
promo_horizontal
promo_vertical
random_horizontal
random_vertical
upsell_horizontal
upsell_vertical
!endblock

H2: Content -> Page Edit

The Interchange Admin UI offers a page editor function that allows component definitions and options to be modified for each page within the catalog.

H3: Template

The choices for the Template drop-down are read from template definition files located in the CATROOT/template directory. These files store the name and description of the template, as well as components and options for the particular template.

To create a new template for use in the admin, it is best to copy an existing template definition to a new file name and edit it's contents to suit. Once the catalog is reconfigured, the new choice will be visible within the Content Page Editor admin function.

Each template option is looped through and a scratch is set using its same name and value.
  
ITL is used near the bottom of this file to set each option to default values before the page is displayed.

!block example
[set page_title][set] 
[set page_banner][set]
[set members_only][set]
[set component_before][set]
[set component_after][set]
[set bgcolor]#FFFFFF[/set]
!endblock

H3: Page Title

Sets the title of the page which is synonymous with the html <title></title> code.

The following code within the template definition file is used to display this option within in the content editor:

page_title:
        description: Page title

This code dynamically adds the title to the page:

<title>[scratch page_title]</title>

H3: Page Banner

Sets a textual title for each page which is called by [either][scratch page_banner][or][scratch page_title][/either] This results in the Page Banner being displayed if defined. Otherwise, the Page Title is used.

H3: Members Only

The members only function is handled by the following code within each template file:

!block example
[if scratch members_only]
    [set members_only][/set]
    [if !session logged_in]
    [set mv_successpage]@@MV_PAGE@@[/set]
    [bounce page=login]
    [/if]
[/if]
!endblock

This code says if members only is set to yes and the visitor is logged in, display the page. Otherwise, redirect the visitor to the login page.

H3: Break 1

This code causes a separation in the Content Editor between the next set of options. (A blue line)

H3: Horizontal Before Component

This allows the inclusion of a defined component to be displayed before, or above, the page's content. It is called with the following code within the LEFTRIGHT_TOP template:

!block example
[if scratch component_before]
[include file="templates/components/[scratch component_before]"]
[set component_before][/set]
[/if]
!endblock

H3: Horizontal After Component

This function allows the inclusion of a defined component to be displayed after or below the page's content. It's called with the following code within the LEFTRIGHT_BOTTOM template:

!block example
[if scratch component_after]
[include file="templates/components/[scratch component_after]"]
[set component_after][/set]
[/if]
!endblock

H3: Horizontal Item Width

This setting allows you to choose how many items the horizontal components display. For example, the horizontal best sellers component uses this setting to randomly select the best sellers. Notice the default to 2 if nothing is defined.

E:random="[either][scratch component_hsize][or]2[/either]"

H3: Special Tag

This setting is only viable when a promotion is used for a horizontal component. It tells the promotional component which rows to evaluate in the merchandising table for display within the component. This setting normally correlates to the featured column of the merchandising table as follows:

!block example
        [query arrayref=main
			   sql="
				SELECT sku,timed_promotion,start_date,finish_date
				FROM merchandising
				WHERE featured = '[scratch hpromo_type]'
			   "][/query]
!endblock

H3: Before/After Banner

Allows a title for the horizontal components to be defined to displayed in a header above the component's items. It is called with the [scratch hbanner] tag.

H3: Break 2

This code causes a separation in the Content Editor between the next set of options. (A blue line)

H3: Vertical Component

Defines a component to be displayed along the right side of the LEFTRIGHT_BOTTOM template. It is called from the template with the following code:

E:[include file="templates/components/[scratch component_right]"]

H3: Vertical Items Height

Sets the number of items to display within the vertical component. Called with the following code:

E:random="[either][scratch component_vsize][or]3[/either]"

H3: Right Banner

Allows a title to be set for a vertical component which is displayed as a header above the items in the vertical component. It's called with the [scratch vbanner] tag.

H3: Special Tag

Essentially the same as the Special Tag setting described in item number 9 above.

H3: Background Color

Allows the background color of the page to be selected. The choices are stored within the page or template definition as in:

!block example
bgcolor:
        options: #FFFFFF=White,pink=Pink
        widget: select
        description: Background color
!endblock

H3: Content

Allows the page code to be downloaded, uploaded and viewed/edited. Only the code between <!-- BEGIN CONTENT --> and <!-- END CONTENT --> is displayed or can be edited here.

H3: Preview, Save, and Cancel buttons

Allows the changes to the edited page to be previewed in a pop-up browser window, or saved. Cancel returns you to the page editor selection page.

H3: Save template in page

Template settings are stored in the template definitions by default. This allows a common set of choices for template settings for all pages. If specific setting options are desired for a page, the template can be saved within the page so that it may have individual options.

The in-page template definition must be surrounded by [comment]  [/comment].

H2: Custom Admin UI Options

Other options may be added to the template by defining them in the default definition file, or using in-page definitions.

When the following lines are added to the template definition, the new option is added to the Admin UI.

!block example
option_name:
options: 1,2*,3
widget: select
description: Option Description
help: Other Details
!endblock

Each time the template is used, an option_name scratch variable is created. (Called with: [scratch option_name].) This scratch value will be equal to what's selected here in the admin tool.

The possible widgets include:

!block example
break - produces the blue line separator.
radio - produces radio button type selections.
select - standard drop-down selector.
move_combo - select drop down with options and text input for new option.
!endblock


H1: Administrative Pages

With Interchange's C<GlobalSub> capability, very complex add-on schemes can be implemented with Perl subroutines. And with the new writable database, pages that modify the catalog data can be made. See C<MasterHost>, C<RemoteUser>, and C<Password>.

In addition, any Interchange page subdirectory can be protected from access by anyone except the administrator if a file called '.access' is present and non-zero in size.

H2: Controlling Access to Certain Pages

If the directory containing the page has a file C<.access> and that file's size is zero bytes, access can be gated in one of several ways.

^If the file C<.access_gate> is present, it will be read and scanned for page-based access. The file has the form:

!block example
  page: condition
  *: condition
!endblock

.The C<page> is the file name of the file to be controlled (the .html extension is optional). The C<condition> is either a literal C<Yes/No> or Interchange tags which would produce a C<Yes> or C<No> (1/0 work just fine, as do true/false).

.The entry for C<*> sets the default action if the page name is not found. If pages will be allowed by default, set it to C<1> or C<Yes>. If pages are to be denied by default in this directory, leave blank or set to C<No>. Here is an example, for the directory C<controlled>, having the following files:

!block example
 -rw-rw-r--   1 mike     mike            0 Jan  8 14:19 .access
 -rw-rw-r--   1 mike     mike          185 Jan  8 16:00 .access_gate
 -rw-rw-r--   1 mike     mike          121 Jan  8 14:59 any.html
 -rw-rw-r--   1 mike     mike          104 Jan  8 14:19 bar.html
 -rw-rw-r--   1 mike     mike          104 Jan  8 14:19 baz.html
 -rw-rw-r--   1 mike     mike          104 Jan  8 14:19 foo.html
!endblock

.The contents of C<.access_gate>:

!block example
   foo.html: [if session username eq 'flycat']
               Yes
             [/if]
   bar:      [if session username eq 'flycat']
             [or scratch allow_bar]
               Yes
             [/if]
   baz:      yes
   *:        [data session logged_in]
!endblock

.The page C<controlled/foo> is only allowed for the logged-in user B<flycat>.

.The page C<controlled/bar> is allowed for the logged-in user B<flycat>, or if the scratch variable C<allow_bar> is set to a non-blank, non-zero value.

.The page C<controlled/baz> is always allowed for display.

.The page C<controlled/any> (or any other page in the directory not named in C<.access_gate>) will be allowed for any user logged in via I<UserDB>.

+If the Variable C<MV_USERDB_REMOTE_USER> is set (non-zero and non-blank), any user logged in via the UserDB feature will receive access to all pages in the directory. NOTE: If there is a C<.access_gate> file, it overrides this.

+If the variables C<MV_USERDB_ACL_TABLE> is set to a valid database identifier, the UserDB module can control access with simple ACL logic. See USER DATABASE. NOTE: If there is a C<.access_gate> file, it overrides this. Also, if C<MV_USERDB_REMOTE_USER> is set, this capability is not available.


H2: display tag and mv_metadata

Interchange can store meta information for selected columns of tables in a site's database. This meta information is used when the user interacts with the database. For example, the meta information for a C<Hide Item> field might specify that a checkbox be displayed when the user edits that field, since the only reasonable values are C<on> and C<off>. Or, the meta information might specify a filter on data entered for a C<Filename> field which makes sure that the characters entered are safe for use in a filename.

C<Widget type> specifies the C<HTML INPUT> tag type to use when displaying the field in, say, the item editor.

C<Width> and C<Height> only apply to some of the C<Widget type> options, for instance the C<Textarea> widget.

C<Label> is displayed instead of the internal column name. For example, the C<category> column of the C<products> table might have a label of C<Product Category>.

C<Help> is displayed below the column label, and helps describe the purpose of the field to the user.

C<Help url> can be used to link to a page giving more information on the field.

C<Lookup> can be used when a field is acting like a foreign key into another table. In that case, use some sort of select box as the widget type, and if referencing multiple rows in the destination table, use a multi select box, with C<colons_to_null> as the C<pre_filter>, and C<::> as the C<lookup_exclude>.

C<Filter> and C<pre_filter> can be used to filter data destined for that field or data read from that field, respectively.

Repeat?: The Interchange back office UI uses the mv_metadata table to discover formatting information for field, table, and view display. The information is kept in fields in the mv_metadata table, and is used to select the display, the HTML input type, the size (height and width where appropriate), label, help text, additional help URL, and default value display.

It works in conjunction with the [display ...] usertag defined in the Interchange UI as well as in specific pages in the UI. The [display] tag has this syntax:

N:[display table=tablename column=fieldname key=key arbitrary=tag filter=op ...]

In the simplest use, the formatting information for a table form field is called with:

.[display table=products column=category key="os28007"]

The mv_metadata table is scanned for the following keys:

> products::category::os28007
> products::category

If a row is found with one of those keys, then the information in the row is used to set the display widget. If no row is found, an INPUT TYPE=TEXT widget is displayed. If the data is all digits, a size of 8 is used, otherwise the size is 60.

If the following row were found (not all fields shown, would be tab-separated in the actual data):

!block example
  code                type   width height label     options
  products::category  text   20           Category
!endblock

Then this would be output:

!block example
<INPUT TYPE=text SIZE=20 VALUE="*category*">
!endblock

If the following row were found:

!block example
  code                type   width height label     options
  products::category  select              Category  =none, product=Hardware
!endblock

Then the following would be output:

!block example
	<SELECT NAME=category>
	<OPTION VALUE="">none
	<OPTION VALUE="product">Hardware
	</SELECT>
!endblock

The standard widget types are:

LI1:text

.The default. Uses the fields:

!block example
    width   size of input box
!endblock

LI1:textarea

.Format a <TEXTAREA> </TEXTAREA> pair. Uses the fields:

!block example
	width   COLS for textarea
	height  ROWS for textarea
!endblock

LI1:select

.Format a <SELECT> </SELECT> pair with appropriate options. Uses the fields:

!block example
  height          SIZE for select
  default         Default for SELECTED
  options         Options for a fixed list (or prepended to a lookup)
  lookup          signals a lookup (used as field name if "field" empty)
  field           field to look up possible values in
  db              table to look up in if not current table
  lookup_exclude  regular expression to exclude certain values from lookup
!endblock


H1: Usertag Reference

Admin Tool-specific usertags.


H1: Admin Tool Database Tables

H2:mv_metadata.asc

!block example
    code
        Table::Column to be operated on.
        Database table
    type
        Widget type (Select the basic display type for the field)
            textarea = Textarea
            text = Text Entry (default)
            select = Select Box
            yesno = Yes/No (Yes=1)
            noyes = No/Yes (No=1)
            multiple = Multiple Select
            combo = Combo Select
            reverse_combo = Reverse Combo
            move_combo = Combo move
            display = Text of option
            hidden_text = Hidden(show text)
            radio = Radio box
            radio_nbsp = Radio (nbsp)
            checkbox = Checkbox
            check_nbsp = Checkbox (nbsp)
            imagedir = Image listing
            imagehelper = Image upload
            date = Date selector
            value = Value
            option_format = Option formatter
            show = Show all options
    width
        Width (SIZE for TEXT, COLS for TEXTAREA, Label limit for SELECT)
    height
        Height (SIZE for SELECT, ROWS for TEXTAREA)
    field
        Field for lookup (can be two comma separated fields, in which
        case second is used as the label text. Both must be in the
        same table.)
    db
    name
        Variable name (normally left empty, changes variable name to
        send in form)
    outboard
        Select directory for image listing widget
    options
        options in the format <blockquote>value=label*</blockquote>
    attribute
        Column name (Do not set this.)
    label
    help
        Help (displays at top of page)
    lookup
        Lookup select (Whether lookup is performed to get options for a
        select type. If nothing is in the field, then used as the name
        of the field to lookup in. Use lookup table if you want to look
        up in a different table.
    filter
        Filters (Filters which can transform or constrain your data.
        Some widgets require filters.)
    help_url
        Help URL (links below help text)
        A URL which will provide more help
    pre_filter
    lookup_exclude
        ADVANCED: regular expression that excludes certain keys from the lookup
    prepend
    append
        Append HTML (HTML to be appended to the widget. Will substitute
        in the macros _UI_TABLE_, _UI_COLUMN_, _UI_KEY_, and _UI_VALUE_,
        and will resolve relative links with absolute links.)
    display_filter
!endblock


H1: makecat - Set Up a Catalog from a Template

After Interchange is installed, you need to set up at least one catalog. Interchange will not function properly until a catalog is created. 

The supplied C<makecat> script, which is in the Interchange program directory C<bin>, is designed to set up a catalog based on the user's server configuration. It interrogates the user for parameters like which directories to use, a URL to base the catalog in, HTTP server definitions, and file ownership. It gives relevant examples of the entries it expects to receive.

Note: A catalog can only be created once. All further configuration is done by editing the files within the catalog directory.

The C<makecat> script requires a catalog skeleton to work from. The Foundation demo is distributed with Interchange. See the icfoundation document for information on building the Foundation demo store. Other demo catalogs are available at C<http://www.icdevgroup.org/>.

It is not normally necessary for you to understand how to build catalog skeletons for use with makecat, but the following information will help you if you should ever need to.

H2: Catalog Skeletons

A catalog skeleton contains an image of a configured catalog. The best way to see what the makecat program does is to configure the simple demo and then run a recursive C<diff> on the template and configured catalog directories:

!block example
    cd /usr/local/interchange
    diff -r construct catalogs/construct
!endblock

The files are mostly identical, except that certain macro strings have been replaced with the answers given to the script. For example, if C<www.mydomain.com> was answered at the prompt for a server name, this difference would appear in the catalog.cfg file:

!block example
    # template
    Variable SERVER_NAME  __MVC_SERVERNAME__

    # configured catalog
    Variable SERVER_NAME  www.mydomain.com
!endblock

The macro string __MVC_SERVERNAME__ was substituted with the answer to the question about server name. In the same way, other variables are substituted, and include:

!block example
    MVC_BASEDIR      MVC_IMAGEDIR
    MVC_CATROOT      MVC_IMAGEURL
    MVC_CATUSER      MVC_MAILORDERTO
    MVC_CGIBASE      MVC_MINIVENDGROUP
    MVC_CGIDIR       MVC_MINIVENDUSER
    MVC_CGIURL       MVC_SAMPLEHTML
    MVC_DEMOTYPE     MVC_SAMPLEURL
    MVC_DOCUMENTROOT MVC_VENDROOT
    MVC_ENCRYPTOR
!endblock

Note: Not all of these variables are present in the "construct" template, and more may be defined. In fact, any environment variable that is set and begins with MVC_ will be substituted for by the C<makecat> script. For example, to set up a configurable parameter to customize the COMPANY variable in catalog.cfg, run a pre-qualifying script that set the environment variable MVC_COMPANY and then place in the catalog.cfg file:

Variable   COMPANY   __MVC_COMPANY__

All files within a template directory are substituted for macros, not
just the catalog.cfg file. There are two special directories named
C<html> and C<images>. These will be recursively copied to the
directories defined as SampleHTML and ImageDir.

Note: The template directory is located in the Interchange software directory,
i.e., where C<interchange.cfg> resides. Avoid editing files in the template
directory. To create a new template, it is recommended that it should be named
something besides 'construct' and a copy of the C<construct> demo directory be
used as a starting point. Templates are normally placed in the Interchange base
directory, but can be located anywhere. The script will prompt for the location
if it cannot find a template.

In addition to the standard parameters prompted for by Interchange, and
the standard catalog creation procedure, four other files in the
C<config> directory of the template may be defined:

!block example
 additional_fields -- file with more parameters for macro substitution
 additional_help   -- extended description for the additional_fields
 precopy_commands  -- commands passed to the system prior to catalog copy
 postcopy_commands -- commands passed to the system after catalog copy
!endblock

All files are paragraph-based. In other words, a blank line (with no
spaces) terminates the individual setting.

H3: Additional fields

The additional_fields file contains:

!block example
    PARAM
    The prompt. Set PARAM to?
    The default value of PARAM^IAlternate value of PARAM
!endblock

This would cause a question during makecat:

!block example
    The prompt. Set PARAM to?.....[The default value of PARAM]
!endblock

The default value line can contain alternate values, separated by tabs from
the default value. (The default value may not contain a TAB character.)
This will allow command-line editing to cycle between the different values --
usually with the UP and DOWN arrow keys.

If you wish to set the parameter to the default value in this file without a
prompt, precede the parameter with an exclamation point, i.e.:

!block example
    !PARAM
    The prompt.  Set PARAM to?
    default value^Ialternate value
!endblock

If you wish only to prompt for a value if a previous parameter was set,
put the previous parameter to set in curly brackets before the actual
parameter:

!block example
    {MYSQL}SQLDSN
    Data source name (DSN) for MySQL?
    dbi:mysql:test___MVC_CATALOGNAME__
!endblock

The above will be ignored if the MYSQL parameter was not previously
set to a true value.

Note that information collected in the main makecat run (in this case, the
catalog name) can be inserted via macro substitution.

H3: Additional help

If the additional_help file is present, additional instructions for PARAM may be provided.

!block example
    PARAM

    These are additional instructions for PARAM, and they
    may span multiple lines up to the first blank line.
!endblock

The prompt would now be:

!block example
    These are additional instructions for PARAM, and they
    may span multiple lines up to the first blank line.

    The prompt. Set PARAM to?.....[The default value of PARAM]
!endblock

H3: Command files

If the file config/precopy_commands exists, it will be read as a command followed by the prompt/help value.

!block example
    mysqladmin create __MVC_CATALOGNAME__
    We need to create an SQL database for your Interchange
    database tables.
!endblock

This will cause the prompt:

!block example
    We need to create an SQL database for your Interchange
    database tables.

    Run command "mysqladmin create simple"?
!endblock

If the response is "y" or "yes," the command will be run by passing it through the Perl system() function. As with any of the additional configuration files, MVC_PARAM macro substitution is performed on the command and help. Proper permissions for the command are required.

The file config/postcopy_commands is exactly the same as <precopy_commands>, except the prompt occurs after the catalog files are copied and macro substitution is performed on all files.

There may also be SubCatalog directives:

!block example
    SubCatalog easy simple /home/catalogs/simple /cgi-bin/easy
!endblock

easy
.The name of the subcatalog, which also controls the name of the subcatalog configuration file. In this case, it is C<easy.cfg>.

simple
.The name of the base configuration that will be the basis for the catalog. Parameters in the easy.cfg file that are different will override those in the catalog.cfg file for the base configuration.

The remaining parameters are similar to the Catalog directive.

Additional interchange.cfg parameters set up administrative parameters that are catalog wide. See the server configuration file for details on each of these.

Each catalog can be completely independent with different databases, or catalogs can share pages, databases, and session files. This means that several catalogs can share the same information, allowing "virtual malls."


H2: Manual Installation of Catalogs

An Interchange installation is complex, and requires quite a few distinct steps. Normally you will want to use the interactive catalog builder, C<makecat>, described above. It makes the process much easier. Please see the C<iccattut> document for a full tutorial on building a catalog by hand.


H1: Link Programs

Interchange requires a web server that is already installed on a system. It does have an internal server which can be used for administration, testing, and maintenance, but this will not be useful or desirable in a production environment.

As detailed previously, Interchange is always running in the background as a daemon, or resident program. It monitors either a UNIX-domain file-based socket or a series of INET-domain sockets. The small CGI link program, called in the demo C<simple>, is run to connect to one of those sockets and provide the link to a browser.

Note: Since Apache is the most popular web server, these instructions will focus on it. If using another type of web server, some translation of terms may be necessary.

A C<ScriptAlias> or other CGI execution capability is needed to use the link program. (The default C<ScriptAlias> for many web servers is C</cgi-bin>.) If C<ExecCGI> is set for all directories, then any program ending in a particular file suffix (usually C<.cgi>) will be seen as a CGI program.

Interchange, by convention, names the link program the same name as the catalog ID, though this is not required. In the distribution demo, this would yield a program name or SCRIPT_PATH of C</cgi-bin/simple> or C</simple.cgi>. This SCRIPT_PATH can be used to determine which Interchange catalog will be used when the link program is accessed.

H2: UNIX-Domain Sockets

This is a socket which is not reachable from the Internet directly, but which must come from a request on the server. The link program C<vlink> is the provided facility for such communication with Interchange. This is the most secure way to run a catalog, for there is no way for systems on the Internet to interact with Interchange except through its link program.

The most important issue with UNIX-domain sockets on Interchange is the permissions with which the CGI program and the Interchange server run. To improve security, Interchange normally runs with the socket file having 0600 permissions (rw-------), which mandates that the CGI program and the server run as the same user ID. This means that the C<vlink> program must be SUID to the same user ID as the server executes under. (Or that CGIWRAP is used on a single catalog system).

With Interchange's multiple catalog capability, the permissions situation gets a bit tricky. Interchange comes with a program, C<makecat>, which configures catalogs for a multiple catalog system. It should properly set up ownership and permissions for multiple users if run as the superuser.

H2: INET-Domain Sockets

These are sockets which are reachable from the Internet directly. The link program C<tlink> is the provided facility for such communication with Interchange. Other browsers can talk to the socket directly if mapped to a catalog with the global C<TcpMap> directive. To improve security, Interchange usually checks that the request comes from one of a limited number of systems, defined in the global C<TcpHost> directive. (This check is not made for the internal HTTP server.)

H2: Internal HTTP Server

If the socket is contacted directly (only for INET-domain sockets), Interchange will perform the HTTP server function itself, talking directly to the browser. It can monitor any number of ports and map them to a particular catalog. By default, it only maps the special catalog mv_admin, which performs administrative functions. The default port is 7786, which is the default compiled into the distribution tlink program. This port can be changed via the C<TcpMap> directive.

To prevent catalogs that do not wish access to be made in this way from being served from the internal server, Interchange has a fixed SCRIPT_PATH of C</catalogname> (/simple for the distribution demo) which needs to be placed as an alias in the Catalog directive to enable access. See C<TcpMap> for more details.

H2: Setting Up VLINK and TLINK

The C<vlink> and C<tlink> programs, compiled from C<vlink.c> and C<tlink.c>, are small C programs which contact and interface to a running Interchange daemon. The VLINK executable is normally made setuid to the user account which runs Interchange, so that the UNIX-domain socket file can be set to secure permissions (user read-write only). It is normally not necessary for the user to do anything. They will be compiled by the configuration program. If the Interchange daemon is not running, either of the programs will display a message indicating that the server is not available. The following defines in the produced C<config.h> should be set:

LI1: LINK_FILE

.Set this to the name of the socket file that will be used for configuration, usually "/usr/local/lib/interchange/etc/socket" or the "etc/socket" under the directory chosen for the VendRoot.

LI1: LINK_HOST

.Set this to the IP number of the host which should be contacted. The default of 127.0.0.1 (the local machine) is probably best for many installations.

LI1: LINK_PORT

.Set this to the TCP port number that the Interchange server will monitor. The default is 7786 (the decimal ASCII codes for 'M' and 'V') and does not normally need to be changed.

LI1: LINK_TIMEOUT

.Set this to the number of seconds C<vlink> or C<tlink> should wait before announcing that the Interchange server is not running. The default of 45 is probably a reasonable value.

H2: Compiling VLINK and TLINK

There is a C<compile_link> program which will assist with this. Do:

!block example
   perldoc VENDROOT/bin/compile_link
!endblock

for its documentation.

H2: Manually Compiling VLINK and TLINK

Change directories to the C<src> directory, then run the GNU configure script:

!block example
   cd src
   ./configure
!endblock

There will be some output displayed as the configure script checks the system. Then, compile the programs:

!block example
   perl compile.pl
!endblock

To compile manually:

!block example
   cc vlink.c -o vlink
   cc tlink.c -o tlink
!endblock

On manual compiles, ensure that the C compiler will be invoked properly with this little ditty:

!block example
   perl -e 'do "syscfg"; system("$CC $LIBS $CFLAGS $DEFS -o tlink tlink.c");'
   perl -e 'do "syscfg"; system("$CC $LIBS $CFLAGS $DEFS -o vlink vlink.c");'
!endblock

On some systems, the executable can be made smaller with the strip program, if available. It is not required.

!block example
   strip vlink
   strip tlink
!endblock

If Interchange is to run under a different user account than the individual configuring the program, make that user the owner of C<vlink>. Do not make C<vlink> owned by root, because making C<vlink> SETUID root is an huge and unnecessary security risk. It should also not normally run as the default Web user (often C<nobody> or C<http>)).

!block example
   chown interchange vlink
!endblock

Move the C<vlink> executable to the cgi-bin directory:

!block example
   mv vlink /the/cgi-bin/directory
!endblock

Make C<vlink> SETUID:

!block example
   chmod u+s /the/cgi-bin/directory/vlink
!endblock

Most systems unset the SUID bit when moving the file, so change it after moving.

The SCRIPT_NAME, as produced by the HTTP server, must match the name of the program. (As usual, let the makecat program do the work.)

H2: VLINK or TLINK Compile Problems

The latest version of C<vlink.c> and C<tlink.c> have been compiled on the following systems:

!block example
   AIX 4.1
   BSD2.0 (Pentium/x86)
   Debian GNU/Linux
   Digital Unix (OSF/Alpha)
   FreeBSD 2.x, 3.x, 4.x
   IRIX 5.3, IRIX 6.1
   OpenBSD 2.7
   Red Hat Linux 6.2, 7.0, 7.1, 7.2, 7.3, 8.0
   SCO OpenServer 5.x
   Solaris 2.x (Sun compiler and GCC)
   Solaris 7 (Sun compiler and GCC)
   SunOS 4.1.4
!endblock

Some problems may occur. In general, ignore warnings about pointers.

Make sure that you have run the configure program in the src directory. If you use Interchange's makecat program, it will try to compile an appropriate link at that time, and will substitute tlink.pl if that doesn't work.

You can compile manually with the proper settings with this series of commands:

!block example
   cd src
   ./configure
   perl -e 'do "syscfg"; system ("$CC $CFLAGS $DEFS $LIBS -o tlink tlink.c")'
   perl -e 'do "syscfg"; system ("$CC $CFLAGS $DEFS $LIBS -o vlink vlink.c")'
!endblock

There is also a C<compile_link> program which has documentation embedded and which will compile an appropriate link. If you cannot compile, try using the C<tlink.pl> script, written in Perl instead of C, which should work on most any system. Since vlink needs to have values set before compilation, a pre-compiled version will not work unless it has the exact values you need on your system. If you can use the defaults of 'localhost' and port 7786, you may be in luck.


H1: Installing Perl Modules without Root Access

Installing Interchange without root access is no problem. However, installing Perl modules without root access is a little trickier.

You must build your makefile to work in your home dir. Something like:
 
!block example
PREFIX=~/usr/local \
INSTALLPRIVLIB=~/usr/local/lib/perl5 \
INSTALLSCRIPT=~/usr/local/bin \
INSTALLSITELIB=~/usr/local/lib/perl5/site_perl \
INSTALLBIN=~/usr/local/bin \
INSTALLMAN1DIR=~/usr/local/lib/perl5/man \
INSTALLMAN3DIR=~/usr/local/lib/perl5/man/man3
!endblock
 
Put this in a file, say 'installopts', and use it for the Makefile.PL.
 
E:perl Makefile.PL `cat installopts`
 
Then, forget ./config. Just do:
 
!block example
make
make test
make install
!endblock
 
Some of the tests may fail, but that's probably ok.

Also make sure to install Bundle::Interchange, which will need the same config data as you put into 'installopts'.


H1: Installation Troubleshooting

Interchange uses the services of other complex programs, such as Perl, Web servers, and relational databases, to work. Therefore, when there is a problem, check these programs before checking Interchange. Many more basic installation problems have to do with those than with Interchange itself.

If an error message is received about not being able to find libraries, or a core dump has occurred, or a segment fault message, it is always an improperly built or configured Perl. Contact the system administrator or install a new Perl.

The C<makecat> program is intended to be used to create the starting point for the catalog. If the demo does not work the first time, keep trying. If it still does not work, try running in INET mode.

Check the two error log files: C<error.log> in the Interchange home directory (where interchange.cfg resides) and C<error.log> in the catalog directory (where catalog.cfg resides; there can be many of these). Many problems can be diagnosed quickly if these error logs are consulted.

Check the README file, the FAQ, and mail list archive at the official Interchange web site for information:

!block example
       http://www.icdevgroup.org/
!endblock

Double check the following items:

^Using UNIX sockets?

-Check that the C<vlink> program is SUID, or the appropriate changes have been made in the SocketPerms directive. Unless the files are world-writable, the vlink program and the Interchange server must run as the same user ID! If running CGI-WRAP or SUEXEC, the C<vlink> program must not be SUID.

-If having trouble with the vlink program (named C<construct> in the demo configuration), try re-running C<makecat> and using INET mode instead. (Or copy the C<tlink> INET mode link program over C<vlink>). This should work unchanged for many systems.

-If using an ISP or have a non-standard network configuration, some changes to interchange.cfg are necessary. For C<tlink> to work, the proper host name(s) must be configured into the TcpHost directive in interchange.cfg. The program selects port 7786 by default (the ASCII codes for "M" and "V", for MiniVend). If another port is used, it must be set to the same number in both the tlink program (by running C<compile_link>) and the C<interchange.cfg> file. The C<tlink> program does not need to be SUID.

+Proper file permissions?

-The Interchange server should not run as the user C<nobody>! The program files can be owned by anyone, but any databases, ASCII database source files, error logs, and the directory that holds them must be writable by the proper user ID, that is the one that is executing the Interchange program.

-The best way to operate in multi-user, multiple catalog setups is to create a special C<interch> user, then put that user in the group that contains each catalog user. If a group is defined for each individual user, this provides the best security. All associated files can be in 660 or 770 mode. There should be no problems with permissions and no problems with security.

+Is the C<vlink> program being executed on a machine that has the socket file C<etc/socket> on a directly attached disk?

-UNIX-domain sockets will not work on NFS-mounted file systems! This means that the Interchange server and the CGI program C<vlink> must be executing on the same machine.

-The C<tlink> program does not have this problem, but it must have the proper host name(s) and TCP ports set in the TcpHost and TcpMap directives in C<interchange.cfg>. Also, be careful of security if sensitive information, like customer credit card numbers, is being placed on a network wire.

H1: Usertracking

Several actions from the user are recorded by Interchange's usertracking 
facility. The usertracking data is logged at two locations, depending on 
your setup. 

The first location is the one specified by the 
{{CMD[jump="icconfig.html#TrackFile"]TrackFile}} configuration
directive, e.g. C<logs/usertrack> in the foundation demo.

The second location are the HTTP headers. You can configure Apache to
write this header into the access logs.

!block example
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \
			%T %v \"%{X-Track}o\"" track
CustomLog /var/log/apache/access.log track
!endblock

Line:

N:Copyright 2002-2004 Interchange Development Group. Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.