Fetching contributors…
Cannot retrieve contributors at this time
1054 lines (711 sloc) 45.7 KB
!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 ""
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
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
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
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
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
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
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
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>
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
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
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
# -- 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 unless -M $_ >= 2;
unlink $_ or die "unlink $_: $!\n";
It would be run with a command invocation like:
!block example
perl /home/you/catalogs/simple/session
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
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
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]
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:
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]
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]
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]
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
SELECT sku,timed_promotion,start_date,finish_date
FROM merchandising
WHERE featured = '[scratch hpromo_type]'
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
options: #FFFFFF=White,pink=Pink
widget: select
description: Background color
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
options: 1,2*,3
widget: select
description: Option Description
help: Other Details
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.
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
.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
.The contents of C<.access_gate>:
!block example
foo.html: [if session username eq 'flycat']
bar: [if session username eq 'flycat']
[or scratch allow_bar]
baz: yes
*: [data session logged_in]
.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
Then this would be output:
!block example
<INPUT TYPE=text SIZE=20 VALUE="*category*">
If the following row were found:
!block example
code type width height label options
products::category select Category =none, product=Hardware
Then the following would be output:
!block example
<SELECT NAME=category>
<OPTION VALUE="product">Hardware
The standard widget types are:
.The default. Uses the fields:
!block example
width size of input box
.Format a <TEXTAREA> </TEXTAREA> pair. Uses the fields:
!block example
width COLS for textarea
height ROWS for textarea
.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
H1: Usertag Reference
Admin Tool-specific usertags.
H1: Admin Tool Database Tables
!block example
Table::Column to be operated on.
Database table
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 (SIZE for TEXT, COLS for TEXTAREA, Label limit for SELECT)
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.)
Variable name (normally left empty, changes variable name to
send in form)
Select directory for image listing widget
options in the format <blockquote>value=label*</blockquote>
Column name (Do not set this.)
Help (displays at top of page)
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.
Filters (Filters which can transform or constrain your data.
Some widgets require filters.)
Help URL (links below help text)
A URL which will provide more help
ADVANCED: regular expression that excludes certain keys from the lookup
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.)
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<>.
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
The files are mostly identical, except that certain macro strings have been replaced with the answers given to the script. For example, if C<> was answered at the prompt for a server name, this difference would appear in the catalog.cfg file:
!block example
# template
# configured catalog
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
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:
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
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
The prompt. Set PARAM to?
The default value of PARAM^IAlternate value of PARAM
This would cause a question during makecat:
!block example
The prompt. Set PARAM to?.....[The default value of PARAM]
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
The prompt. Set PARAM to?
default value^Ialternate value
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
!block example
Data source name (DSN) for MySQL?
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
These are additional instructions for PARAM, and they
may span multiple lines up to the first blank line.
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]
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.
This will cause the prompt:
!block example
We need to create an SQL database for your Interchange
database tables.
Run command "mysqladmin create simple"?
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
.The name of the subcatalog, which also controls the name of the subcatalog configuration file. In this case, it is C<easy.cfg>.
.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:
.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.
.Set this to the IP number of the host which should be contacted. The default of (the local machine) is probably best for many installations.
.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.
.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
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
There will be some output displayed as the configure script checks the system. Then, compile the programs:
!block example
To compile manually:
!block example
cc vlink.c -o vlink
cc tlink.c -o tlink
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");'
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
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
Move the C<vlink> executable to the cgi-bin directory:
!block example
mv vlink /the/cgi-bin/directory
Make C<vlink> SETUID:
!block example
chmod u+s /the/cgi-bin/directory/vlink
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
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 if that doesn't work.
You can compile manually with the proper settings with this series of commands:
!block example
cd src
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")'
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<> 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 \
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 test
make install
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
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
N:Copyright 2002-2004 Interchange Development Group. Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.