Back Next
This page provides the basic information for installing Metadot Portal Server. You may want to print this page to have these instructions on hand during the installation.
The lastest version of this document is available at www.metadot.com.
Please go to the Metadot forum to get install advise from the community (again at www.metadot.com). The complete user, designer and programming documentation can be found at www.metadot.com.
This section includes the following topics:
This page describes the steps necessary to install Metadot. If you are starting from an existing Metadot installation, then see the upgrade instructions located somewhere else!
Linux (check README for tested distributions)
Apache 1.3.6
Perl 5.005_03
mod_perl 1.21
MySQL 3.23.xx (older versions will be incompatible with the table definitions used).
- OR -
Oracle 8.1.17 or higher
Note: The lastest open-source version of the Portal Server does support Oracle.
This version of the Metadot Portal server is not officially supported on Windows; however, if you prefer to run it on Windows, you will likely be successful. Instructions for Windows installation are included in this document.
For Windows, you will need:
Windows NT/Windows 2000 Service Pack 2
IE 5.5 Service Pack 1
IIS
Active Perl 5.6 build 633
Perl-EX v. 2.2
MySQL
- OR -
Oracle 8.1.17 or higher
perl -v
If you need to upgrade your perl installation, you can find it at http://www.perl.com/CPAN/
WARNING: There have been some reports of problems between Perl 5.6.0 and mod_perl 1.24 on Red Hat 7.0 systems. If you experience problems, download the latest relevant patches from Red Hat.
Install ActivePerl 5.6 build 633 (http://aspn.activestate.com)(As of this writing, the current version of ActivePerl is incompatible with the Metadot product, because it does not yet support the modules needed for Metadot to run).
Linux:
Apache can be downloaded from http://httpd.apache.org/.
mod_perl can be
downloaded from http://perl.apache.org/
The versions of Apache and mod_perl that ship with Red Hat 6.2 and 7.1 have been extensively tested with the Metadot product and work fine. If you are working on a Red Hat (or Red Hat-derived) Linux distribution, the RPM versions of these applications can be used without having to compile and install them by hand.
We recommend installing Apache with mod_perl as a DSO. To do this, extract Apache and mod_perl. change to the extracted mod_perl directory and do the following commands :
$bash mod_perl-x.xx > perl Makefile.PL APACHE_SRC=../apache_x.x.x/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 USE_DSO=1
$bash mod_perl-x.xx > make
$bash mod_perl-x.xx > make test
$bash mod_perl-x.xx > make install
$bash mod_perl-x.xx > cd ../apache_x.x.x
$bash mod_perl-x.xx > make install
apache_x.x.x is the extracted apache directory.
"$bash mod_perl-x.xx>" is a representation of the prompt and is not part of the command.
For more information on building mod_perl try : http://perl.apache.org/guide/install.html
Windows:
Configure IIS according to the section "How do I configure Microsoft IIS 4.0/IIS 5.0 to support ActivePerl?" which is contained under the "Web Server Config" item of the ActivePerl documentation. Make sure you add a global application mapping for .pl files that points to perl.exe.
MySQL can be found at
http://www.mysql.com/ http://www.mysql.com/downloads/index.htmlwill provide the most recent stable version. Version 3.23 or above is required.
If installing MySQL from RPM, you will need to install the MySQL client RPM and the MySQL devel RPM. If you do not have these installed, you will likely run into serious problems when trying to build the Perl Modules in step 4.
The MySQL 3.23 RPMS that ship with Red Hat 7.1 and higher have been extensively tested with the Metadot product and are known to work well.
Once the MySQL server is installed, you will need to make sure it's running. You can do this by simply trying to connect to it. If it is not running, you can start it manually with the following command (linux):
$bash > /usr/bin/safe_mysqld &
(your safe_mysqld may be in a different location)
Add the mysql directory to the windows search path, so MySql commands are available to the metadot daemon. Here's how to do this:
Right-click on "My Computer" icon. Select "Properties". Select the "Advanced" tab. Select "Environment Variables". Edit the "Path" variable in "System Variables". If you don't see an entry for mysql, append the mysql bin directory (i.e. ";c:\mysql\bin).
Create a user and schema for the Metadot database. If desired, create a tablespace as well. This user must be able to CREATE TABLE.
Set up the Metadot schema using the command:
sqlplus/ < /oracle_setup/oracle_schema.sql
Import the data contained This system will check dependencies and install them as well.
SPECIAL NOTE ON CPAN This will force CPAN to ask you if you wish to install dependent modules that
are not already on your system. Dependent modules normally need to be approved
for all of the Perl modules to work properly. The one current exception is
during the installation of Msql-Mysql-modules. It will prompt for the
installation of Data::Dumper. DO NOT APPROVE The one exception to this is the expat library. It is needed for the XML::RSS
module to install. For every platform but FreeBSD, the expat library can be
downloaded from its homepage at http://expat.sourceforge.net/ It may be
installed with the following procedure. Incidentally, this is also the procedure
you would follow if you wanted to build the perl modules yourself : For a FreeBSD installation:
Do not install expat from source or ports, and do not install the perl module
XML::Parser from source or cpan. Instead, install the perl module XML::Parser
from ports. Doing so will fetch and compile expat, and then tie expat properly
to the perl module XML::Parser.
To install the XML::Parser module from ports, change
to Once in that directory, type If you have chosen not to install the ports system with your FreeBSD
installation, XML::Parser can also be installed from the FreeBSD packages
collection. Installing via packages will also correctly fetch expat and tie
expat to the XML::Parser module.
To install XML::Parser via packages, type Once expat is installed, you should be able to install the rest of the
modules with no problems using the following commands (Many of the required
modules are installed automatically as dependencies when these commands are run)
: Notes: Install the following Perl modules using the command line PPM (PPM was
installed as part of Active State Perl).
As of this writing, it is suggested that modules should be installed from the
old ppm repository at ActiveState because the newer one apparently no longer
contains several of the required modules. To use the old repository, run the following set command: Having done this, you should be able to install the following modules: (The latter group of commands grab two ppm packages from a different site.
They may also be obtained from soulcage.net via: To run the upgrade script, you will need to install the Lingua-EN-NameParse
module, which can be found
here: When the perl modules listed have all been installed, you can do a quick
check using the PPM query command to verify that all the required modules are
installed (several modules have dependencies which cause other modules to be
installed).
We recommend that you create a user to own the metadot files. Many
distributions have their own way to add a user to the system. Refer to your
distribution's documentation for how to do this. Alternately, on most systems,
you can add a user with the following command: This document assumes you have created a user and that user will be referred
to as "metadot" for the rest of the instructions. You may name this user
anything you wish.
WARNING : Only do this next piece if you are sure of what you are doing.
Making a mistake in the /etc/passwd file can have serious negative consequences.
For extra security, you may wish to disable the ability to log in as the
metadot user. To do this, edit the /etc/passwd file. Look for the line for the
metadot user and change its default shell to /bin/false.
Create a 'metadot' user by selecting (from the windows desktop): The Metadot tarball can be found at http://www.metadot.com
In the remainder of this document, "<METADOT>"
will be used to indicate your top-level metadot directory, for both the Linux
and Windows installations.
For example, if on linux your top-level metadot directory
is: If on Windows, your top-level metadot
directory is: Extract the Metadot files into your metadot user directory. Change to the
metadot user directory and extract the tarball from there.
The tarball can be extracted with the following command : You will want to make sure that the metadot user directory has its
permissions set to allow read and execute by group and other. You can do this
with the following command. For example, if your user is named "metadot": WARNING : If your system has local users, you will need to change the
permissions to be secured from the local users. Use the following commands : This assumes that the web server is part of a group called "nobody". You can
find out what group your web server is in by looking in its httpd.conf file. We
will be editing that file in a later step.
Unpack the tarball into an appropriate directory.
Make sure that directory Make sure the 'channels' directory (under <METADOT>\metadot) grants
write permission to both 'Administrator' and 'metadot', and that all the files
within it do as well.
Make sure that the 'html' directories and files under them grant read, write
and modify permissions to the 'metadot' user.
First we need to create the database for the Metadot installation to use.
Change to the Then create the database using the following command : Create the database using the following command if using MySQL 4.x: If you have specified a password for the mysql server root user, add "-p"
before the second "mysql" and you will be prompted for the password.
You should immediately change the default password for the new database user.
Do this with the following commands : Note: it is required to define some password for
the metadot user; the system will not work without a password
defined.
Next, load the default data into the database. Metadot uses a configuration file that associates database information with
the web server that you are running. It is called:
This file can contain one or more "configuration blocks", each of which have
the following syntax: Typically a system will be configured to use just one server block. Multiple
configuration blocks can be used to enable the use of virtual servers,
and to allow one web server to run off the same perl code base. We suggest that
you do not experiment with using virtual servers until the system is running to
your satisfaction in single-server mode. More information about the 'virtual
server' feature is below.
Get your server running first in single-server mode. You only need one
configuration block. Follow the example in Next, edit the database information in The registration, user type, and authentication method are by default set to
the following values: The metadot.conf file now controls whether or not the site uses LDAP
authentication and registration. This is new in version 4.5. As indicated in the
example above, comment out the 'Default' lines and uncomment the 'LDAP' lines in
the .conf file to use LDAP for your site.
With Version 4.6.1 and higher, the Your web server must then be configured
consistently with the information in the metadot.conf file, as discussed in
the section Configure the Web Server.
E.g., in the example above, the web server must configured such that /public is
aliased to the given directory path on the server.
Remember the location of the public directory that you create. In the section
Configuring Metadot, you will need to copy some sample
data files to this directory.
Similarly, with Version 6.0 and higher, the Change the lines to the absolute path pointing to the directory you want to
use for skins. The relative URL for this path must be '/skins', in order for the
default templates to properly load their CSS and image files.
[Get your system running in single-server mode first, before configuring it
to use virtual servers. ].
The <METADOT>/etc directory contains two example configuration files,
one for Linux and one for Windows. If you use one of those example files as a
starting point, remember to rename it to The use of multiple virtual servers, all accessing different databases but
the same code base, can be enabled by using multiple configuration blocks. Each
configuration block contains its own database configuration, and a list of
server addresses to be associated with that database configuration information.
The database information must be different across multiple servers-- if
you are going to run multiple servers, they should not access the same database.
An example file is listed below with multiple configuration blocks. Note that
each block has a different database configuration. Each configuration block
contains a list of SERVERS. One of the configuration blocks must include
'localhost' in the list of servers. When a user accesses metadot via a web
browser, the system determines what configuration block to use based on the name
of the (virtual) server accessed by the user request. If a user accesses the
metadot portal via a server address not listed in the config file, the
request will default to the configuration block whose server list contains
'localhost'.
An example file is listed below with multiple configuration blocks. Note that
the 'localhost' block defines the same database configuration information as the
second block, and the third configuration block defines a different database.
Each configuration block contains one SERVER address. One of the configuration
blocks must use 'localhost' as its server address.
When a user accesses Metadot via a web browser, the system determines what
configuration block to use based on the name of the (virtual) server accessed by
the user request. If a user accesses the metadot portal via a server address
not listed in the config file, the request will default to the
configuration block whose SERVER address is 'localhost'.
Unlike Linux, on Windows the configuration blocks can contain only one
address per block. So, the block that contains 'localhost', and is the "default"
block, should contain the same database configuration information as one of the
other blocks-- and that database will then be accessed as the default. The httpd.conf file is usually in /etc/httpd/conf/httpd.conf or
/usr/local/apache/conf/httpd.conf. Edit this file with your favorite editor.
Check to make sure the following lines are in the file:
(Note that you won't need these lines if your Apache server was compiled with
a statically linked mod_perl module, which will not be the case if you follow
the above instructions on building Apache).
Sometimes modules/libperl.so won't be there, but libexec/libperl.so will be
there. This is acceptable.
Add the following lines to your httpd.conf :
Make sure PerlSendHeader is not set to On in the httpd.conf script.
Locate the section in the file that deals with DocumentRoot. Replace the
existing entry for the /apache/htdocs with one for the metadot location:
Locate the section in the file that deals with DirectoryIndex. Certain
browsers have an issue with the way that redirects are issued within the Metadot
system. As such, a redirection to /metadot/ will fail because indexing is not
allowed within the Metadot <Location>. Add 'index.pl' to the list
following DirectoryIndex and this will no longer be a problem.
If you have set up your (The /images directory may potentially be shared if you like; however, the
/public directories may not, since the users of each virtual server can modify
the /public directory contents for their server). The /skins directory can
optionally be shared, which will cause any uploaded skins to become available
across all virtual servers, and any changes to the skins will affect all
virtual servers. Each time that you edit the httpd.conf file or any of the files in the
metadot directory, you will need to restart your web server. Do this with the
following command (replacing the path below as appropriate): Go to the IIS Manager console and create the following virtual directories
under the default website. To achieve this you have to left-click on the default
website icon and run the New->Virtual Directory wizard. Metadot version 4.6.1 and higher has a new feature which allows users to
upload files to a public, web-accessible, directory as an alternative to the
access-controlled uploads directory described below.
Once you create this directory, you will need to tell the IIS web server where
it is, similarly to the line above in which the /images/ directory is
configured. For example, if you want the public directory to be reached from the
web server via Then, you will need to configure your metadot.conf
file to properly specify the 'public' directory information.
Metadot version 6.0 and higher has a new feature which allows administrative
users to manage and upload skins. Each skin will contain files that must be
publicly accessible on the web server. Once you create this directory, you will
need to tell the IIS web server where it is, similarly to the line above in which
the /public/ directory is configured.
Then, you will need to configure your metadot.conf
file to properly specify the 'skins' directory information.
Open the IIS control panel: Expand the node for the host to see the Default Web Site. Right-click and
select Properties. Select Home Directory tab. Use the Browse button to select
the directory <METADOT>/metadot (where the file index.pl resides).
Select Documents tab, select Add... and create an entry for index.pl; move it
to the top of the list if there are other entries.
Change the user under which IIS runs Metadot.
Add the following mime types to the mime.types file (if they do not already
exist). The mime.types file is usually in /etc/mime.types. Two background tasks must be enabled for the Metadot portal to run properly.
One handles cleaning tasks and the other handles channel management. We will need to add several lines to the cron table next. The crontab will be
used to run the metadot daemons, which automate cleaning tasks, updating
channels and sending notifications. The following will tell the crontab to run
the channel update every 20 minutes, and to perform cleaning once a day. To do
this, we will use the following command to edit the cron table: Add to the cron table the following lines : Then, add the line below to the cron table as well: Then, add an entry to the cron table to do cleanup: When you are done editing the cron table, you may review the table with the
following command : The metadotd job will run every 20 minutes and a cmd window will appear on
the desktop when that happens. It should take from a few seconds to a few
minutes for it to run, depending on how fast your internet connection is.
Metadot's background script has the ability to support an
"email-to-discussion" functionality, where users subscribed via email in "ASAP"
mode to discussion groups can reply to the discussion message emails and have
them incorporated into the website discussion thread. If you would like to
enable this capability, modify the line above to be instead:
Then, you will also need to create an email account that can be used to hold
discussion message replies, and configure Metadot to use this account. Read the
subsection below that describes this feature in more detail, then see the
section on Configuring Metadot.
Next, repeat the process above, but with a Run line of:
and set this invocation of the script to run once a day. This will clean old
session and event log information. If you have event
logging enabled, it is very important to run this script, so that the
event_log database table does not get too big. The -e argument in the example
above cleans the event log table of all events older than 10 days. Change this
number to suit the needs of your site. The event log cleanup interval may also
be specified in the admin's system configuration interface, under the "Manage"
--> "Config" pulldown menu. The command-line argument above will
override the value set in the configuration interface. So, if you wish to
control this interval from the web interface, do not include the "-e"
argument in the scheduler command above.
Next, again repeat the process above, but with a Run line of:
and set this invocation of the script to run once a day. This will clear any
old lock files that may have been generated.
You can check the scheduled tasks by selecting (from the Windows desktop): (you have to double-click the Scheduled Tasks item to show all tasks).
The "email-to-discussion" feature is new to Version 4.0. If a user subscribes to a discussion via email in "ASAP" mode (one of
the subscription mode choices), then they will get an email notification of
every message posted. If the "-fetch" flag is added to the metadotd.pl
invocation, and a dedicated "discussions" email account set up as described in
the Configuring Metadot section, then the email
notifications will be configured so that if the user replies to a discussion
message, the reply will be "pushed" back into the discussion next time the
metadotd.pl script runs. More specifically, the notifications will contain a "reply-to" field
configured so that if the user replies to the message, it will be sent to the
dedicated "discussions" account, with identifying information about the
discussion and message encoded as part of the "to" information in the reply.
Then, the metadotd.pl script will pop the discussions account, process the
replies according to their 'to' fields, and publish the content of the replies
as new messages in the given discussion. If a user reply contains attachments, only the first text attachment, or the
first html attachment if no text attachment exists, will be used as the content
of the new discussion message. Notes: A limitation of this feature is that the host name used in the
dedicated discussion email address must also be the server from which the
account email is popped. It is not currently possible to specify a separate pop
server for the account. To test the installation, go to the <metadot>/metadot directory. First,
make sure that all your .pl scripts are executable by the 'group' of the Apache
Server. You can do this by typing: Next, run the index.pl file on the command line : For Windows, similarly invoke 'perl.exe index.pl' from the command line. You
may need to include the full path to the perl exec.
You should see some raw html sent to STDOUT. If there are any problems with
missing Perl modules, or misconfiguration, you will see an error when you run
the script.
Now bring up the Metadot start page by accessing index.pl from your web
browser: Once you can get to the Metadot front page with a browser, there is some
Metadot configuration required.
If you are running multiple virtual servers (beta), then
you will need to go through the following configuration process for each
server-- each has its own database in which its configuration information is
stored. In particular, you will need to make sure that you create separate
'images', 'skins', 'private' and 'public' directories for each server (see below). You will also
need to create a separate "discussions" email account for each virtual server
(see below).
Again, if you are updating from a previous version of Metadot, you
will need to copy your own existing files into the private directory -- see the
"Upgrade" document. Now you may configure Metadot's look and feel. When in edit mode, click on
"Manage.." -> "Style & Color". Here you may modify the site
theme or define the headers and style sheet
for your installation.
If you wish to authenticate against an LDAP server, click on "Activate
LDAP Authentication" in "admin".
Notes:
Metadot is capable of integrating with Single-Signon (SSO) authentication systems
which insert variables into the HTTP header to identify the user. Compatible
SSO systems include RSA ClearTrust™ and Netegrity SiteMinder™.
To configure Metadot Portal Server to work with an SSO system, first protect
the portal's URLs via the SSO system's entitlement management interface. You
should test to make sure that the URL's are protected before continuing. Also,
make sure that your SSO solution is inserting a usable HTTP header variable
that can be used to identify the user. You can confirm this by
temporarily placing the file /bin/env.pl into your metadot directory,
and invoking this script from a web browser.
Once you have verified that the server is protected, you will need to make the
following modifications to metadot.conf (the default metadot.conf file
contains these entries, commented out.):
Note that you have to specify the following:
imp
Installing Perl modules
Linux:
Perl Modules can be downloaded from http://www.perl.com/CPAN/.
There are two ways to install the perl modules. You can download the tarballs
for them and build them yourself, or you can let perl do all the work for you.
We recommend letting perl do all the work for you. This is how : $bash > perl -MCPAN -e shell
cpan> install
------------------------------
There is a problem
with recent versions of CPAN that can lead to many problems during a Metadot
installation. A specific module, when being installed by CPAN, will try to
upgrade your system to Perl 5.6.1. While there is nothing wrong with this
version of Perl, it can cause serious issues if it takes place at the wrong part
of this installation process.
Metadot highly recommends that you issue the
following command in the CPAN shell before installing any modules:
o conf prerequisites_policy ask
THIS INSTALLATION.
Msql-Mysql-modules will work fine with the version that is on a Perl 5.004 or
5.6.0 system.
$bash expat_x.x > ./configure
$bash expat_x.x > make
$bash expat_x.x > make install
/usr/ports/textproc/XML-Parser
make && make install
/stand/sysinstall.
Then,
choose Configure, Packages, textproc, and then the XML::Parser package.
$bash > perl -MCPAN -e shell
cpan> install LWP
cpan> install DBI
cpan> install Bundle::Mysql
cpan> install Apache::DBI
cpan> install XML::RSS
cpan> install Storable
cpan> install Net::LDAP
cpan> install Log::Agent
cpan> install Mail::POP3Client
cpan> install IO::Stringy
cpan> install Mail::Internet
cpan> install MIME::Tools
cpan> install Unicode::String
cpan> install Spreadsheet::WriteExcel
cpan> install Date::Calc
cpan> install AppConfig
cpan> install Image::Size
cpan> install Template
cpan> install Time::HiRes
cpan> install Lingua::EN::NameParse
cpan> install Number::Format
cpan> install XML::Simple
cpan> install XML::Dumper
cpan> install Text::CSV_XS
cpan> install Archive::Zip
cpan> install Date::Manip
cpan> install XML::Dumper
cpan> install HTML::TreeBuilder
cpan> install HTML::FormatText
Lingua::EN::NameParse is needed only for the upgrade
script.
It appears that under some circumstances, using the CPAN module to
install XML::Simple will also cause the installer to attempt to install a
version of XML::Parser incompatible with mod_perl. See this page
and the links it provides for more info. To control the install, you may want to
install XML::Simple using the tar file obtained
directly from the cpan.org site, rather than utilizing the CPAN module.
Windows:
PPM> set repository old_as
http://www.activestate.com/PPMPackages/5.6 ppm
ppm> install DBI
ppm> install DBD-Mysql
ppm> install Storable
ppm> install Date-Calc
ppm> install Perl-LDAP
ppm> install XML-RSS
ppm> install Mail-POP3Client
ppm> install IO-stringy
ppm> install MIME-Tools
ppm> install Unicode-String
ppm> install Spreadsheet-WriteExcel
ppm> install Time-HiRes
ppm> install Image-Size
ppm> install XML-Simple
ppm> install Number-Format
ppm> install Text-CSV_XS
ppm> install Archive::Zip
ppm> set repository oi http://openinteract.sourceforge.net/ppmpackages
ppm> install AppConfig
ppm> set repository oi http://openinteract.sourceforge.net/ppmpackages
ppm> install Template-Toolkit
PPM> set repository
soulcage http://www.soulcage.net/ppds/).
http://ppm.activestate.com/PPMPackages/zips/6xx-builds-only/
Creating a 'metadot' user
Linux:
$bash > useradd -m metadot
$bash > passwd metadot
Windows
Start -> Settings -> Control Panel -> Users and Passwords.
Select "Add..." and the Add New User wizard will start. Fill in "metadot"
for the user name and press the "Next" button.
Accept the default "Standard user" for the level of access, then
select "Finish".
Extracting Metadot files
/home/metadot/metadot
then in the rest of the instructions, replace "<METADOT>" with
"/home/metadot/metadot".
C:\metadot
then in
the rest of the instructions, replace
"<METADOT>" with
"C:\metadot".
Linux:
$bash > tar -zxvf metadotvx.x.tar.gz
(Some variants of Unix do not support the -z arg and may require you to
gunzip the tar file first).
$bash > chmod ugo+rx /home/metadot
$bash > cd <METADOT>/etc
(where, as indicated above, <METADOT> is the top-level directory
of your Metadot installation).
$bash > chown root.nobody metadot.conf
$bash > chmod 640 metadot.conf
$bash > chown root.nobody /home/metadot
$bash > chmod 750 /home/metadot
Windows:
<METADOT>\metadot (where the
script metadotd.pl resides) grants write and modify permissions to
both 'Administrator' and 'metadot'.
Configuring the database
Linux:
default_data subdirectory using the following command
(where you replace <METADOT> with the location of your installation: $bash > cd <METADOT>/default_data
$bash > mysql -uroot mysql < createdbanduser.sql
$bash > mysql -uroot mysql < createdbanduser4x.sql
$bash > mysql -uroot mysql
mysql > update user set password = password('<newpassword>') where user = 'metadot';
mysql > flush privileges;
mysql >quit
$bash > mysql -umetadot -p<newpassword> metadotdb < sampledata.sql
Windows:
a) From the Start->run menu run the cmd command.
b) Change directory to <METADOT>\metadot.
c) Run the command:
mysql -uroot mysql < createdbanduser.sql
d) You should immediately change the default password for the
new database user. Do this with the following commands :
mysql -uroot -p
Setting up Metadot configuration file
<METADOT>/etc/metadot.conf [<blockname>]
name = dbi:mysql:<dbname>
user = <dbuser>
pass = <dbpassword>
dbtype = MySQL
# use the following to enable Default authentication
registration_type = Default
authenticator_type = UserPassAuthenticator
# use the following to enable LDAP authentication
#registration_type = LDAP
#authenticator_type = LDAPAuthenticator
(etc. for additional attribute-value pairs)
servers = <<SERVERS
localhost
[address2]
...
[addressN]
SERVERS
Single-server configuration
metadot.conf. The
SERVERS list must include "localhost" as in the metadot.conf file, and
should not include any other address. [On linux, the SERVERS list may
include other addresses to no detrimental effect, but on Windows it may not].
metadot.conf so that it
is correct for your environment. If you followed the instructions above, you
should not need to change the database name from "metadotdb", and the user
should be "metadot". Follow the example comments in the file to change the
database type to Oracle.
registration_type = FlexRegister
user_type = FlexUser
authenticator_type = UserPassAuthenticator
which you will not need to edit unless you are changing them. (You do not
need to uncomment these values in the metadot.conf file).
metadot.conf file specifies
both the absolute path and the web server path for a 'public' uploads directory.
In the metadot.conf file, you will see lines like this: # the following must be uncommented and set to the appropriate values
# to support uploads to a publicly accesible directory
public_uploads_dir = /home/metadot/metadot/sitedata/public
public_uploads_location = /public
metadot.conf file specifies
the absolute path for a 'skins' uploads directory.
In the metadot.conf file, you will see lines like this:
# Skins directory: specify the directory where template files for skins are located.
# This directory must be readable by the process running Metadot Portal Server.
skin_template_dir = /home/metadot/metadot/sitedata/skins
Virtual server configuration
metadot.conf. You might
want to back up the original version of metadot.conf first.
Linux
[metadot1]
name = dbi:mysql:metadotdb
user = metadot
pass = xxx
dbtype = MySQL
(etc..)
servers = <<SERVERS
localhost
yyy.aaa.com
SERVERS
[metadot2]
name = dbi:mysql:metadotdb_alt
user = metadot
pass = xxx
dbtype = MySQL
(etc..)
servers = <<SERVERS
NNN.NNN.NN.NNN
zzz.aaa.com
SERVERS
Windows
[metadot1]
name = dbi:mysql:metadotdb
user = metadot
pass = xxx
dbtype = MySQL
(etc..)
servers = <<SERVERS
localhost
SERVERS
[metadot2]
name = dbi:mysql:metadotdb
user = metadot
pass = xxx
dbtype = MySQL
(etc..)
servers = <<SERVERS
yyy.aaa.com
SERVERS
[metadot3]
name = dbi:mysql:metadotdb_alt
user = metadot
pass = xxx
dbtype = MySQL
(etc..)
servers = <<SERVERS
zzz.aaa.com
SERVERS
Set up 'html', 'private', 'public', and 'skins' directories for each server
If
you are running multiple servers, each with their own database, then you will
need to create different 'images', 'private', 'public', and 'skins' directories for them.
This is described in the Configuring Metadot section
below. When you get to that section, you will need to configure this information
separately for each server.
Configure the web server
Linux: Configure httpd.conf
LoadModule perl_module
modules/libperl.so
AddModule mod_perl.c Alias /images/ <METADOT>/html/images/
Alias /js/ <METADOT>/html/js/
Alias /metadot/ <METADOT>/metadot/
Alias /public/ <METADOT>/sitedata/public/
Alias /skins/ <METADOT>/sitedata/skins/
Alias /htmlarea3/ <METADOT>/html/htmlarea3/
<Location "/metadot/">
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Location>
Make sure that this directory is writable by the apache process owner,
which is typically either "nobody" or "apache".
<METADOT>/html
Then, you will need to configure your metadot.conf
file to properly specify the 'public' and 'skins' directory information for the Metadot
software.
Metadot Virtual Servers
metadot.conf file to use multiple server
blocks (virtual servers), then you will need to configure your apache httpd.conf
file to define the /public, /skins and /images aliases above
for each metadot virtual server. You can do this by using the VirtualHost
construct, or alternatively you can use mod_rewrite and rewrite rules to support
accessing distinct directories for each virtual server.Restart Apache
$bash > /usr/local/apache/bin/apachectl restart
Windows:
a) "metadot" alias: make it point to <METADOT>\metadot, and make sure
you add 'execute' permission to it in the Access Permissions page in
the wizard.
b) "images" alias: make it point to <METADOT>\html\images".
c) "js" alias: make it point to <METADOT>\html\js".
d) "htmlarea3" alias: make it point to <METADOT>\html\htmlarea3".
Create a "public" graphics directory
/public, and the actual path of the directory is
<METADOT>/sitedata/public, then you would add an alias like this: d) "public" alias: make it point to <METADOT>\sitedata\public
Create a "skins" directory
Start -> Settings -> Control Panel ->
Administrative Tools -> Internet Services Manager
Configure mime.types
application/vnd.ms-word doc
application/vnd.ms-excel xls xlt
application/vnd.ms-powerpoint ppt
application/vnd.ms-project mpp
(If you don't have a mime.types file, you can add appropriate AddType
lines to your httpd.conf file).
Set up the Metadot background tasks
Linux: Add cron entries for Metadot
$bash > crontab -e
*/20 * * * * cd /home/metadot/metadot/metadot; nice -19 perl metadotd.pl -m -s >/dev/null 2>/dev/null
Metadot's background script has the ability to support an
"email-to-discussion" functionality, where users subscribed via email in "ASAP"
mode to discussion groups can reply to the discussion message emails and have
them incorporated into the website discussion thread. If you would like to
enable this capability, modify the line above to be instead: */20 * * * * cd /home/metadot/metadot/metadot; nice -19 perl metadotd.pl -m -s -fetch >/dev/null 2>/dev/null
Then, you will also need to create an email account that can be used to
hold discussion message replies, and configure Metadot to use this account. Read
the subsection below that describes this feature in more detail, then see the
section on Configuring Metadot.
18 1 * * * cd /home/metadot/metadot/metadot; perl metadotd.pl -o >/dev/null 2>/dev/null
This last line checks once a day for any wedged metadotd invocations.
38 1 * * * cd /home/metadot/metadot/metadot; perl md_clean.pl -c -o>/dev/null 2>/dev/null
or
38 1 * * * cd /home/metadot/metadot/metadot; perl md_clean.pl -c -e 10 -o>/dev/null 2>/dev/null
The cleanup activities include removing old data from the event_log
database table. If you have event logging
enabled, it is very important to run this script, so that the event_log database
table does not get too big. The optional "-e" argument specifies to the script
to remove data over N days old from the event_log table. For
example, the line above tells the script to remove data over 10 days old. This
is only an example; adjust this number to suit the needs of your site. The event
log cleanup interval may also be specified in the admin's system configuration
interface, under the "Manage" --> "Config" pulldown menu. The command-line
argument above will override the value set in the configuration
interface. So, if you wish to control this interval from the web interface, do
not include the "-e" argument in the cron command above.
$bash > crontab -l
Windows:
Add a scheduler entry for the metadotd background job:
go to:
Start -> Settings -> Control Panel ->
Scheduled Tasks
New->Scheduled Task.
Give the new task the name "metadotd".
C:\perl\bin\Perl.exe
<METADOT>\metadot\metadotd.pl -m -s
(modify the line above if
you installed perl into a different location).
Note: It is important
to include both the full path to the Perl executable, and to the perl script, in
the above.
<METADOT>\metadot
prompted for it.C:\perl\bin\Perl.exe <METADOT>\metadot\metadotd.pl -m
-s -fetch
C:\perl\bin\Perl.exe md_clean.pl -c -e 10 -o C:\perl\bin\Perl.exe <METADOT>\metadot\metadotd.pl
-o
Start -> Settings -> Control Panel -> Scheduled tasks
The "email-to-discussion" feature of the metadotd.pl
script
In addition, it appears that there may be a problem
in using this feature from a hotmail account. The "name" as well as the actual
email address in the reply-to field of the notification message must be retained
in the user reply message. It has been reported that mail sent from hotmail
accounts does not always retain the "name" information. Testing the installation
chmod 755 *.pl
$bash > perl index.pl
http://<your host>/metadot/index.pl
Configuring Metadot Portal Server
private, public, and skins.
The
private directory is the starting version of Metadot's
access-controlled uploads directory. Make sure the private directory
is a non-web-accessible location. Change its permissions so that it is writable by the web
server process owner. For apache, this will typically be either "apache" or
"nobody".
If you are upgrading your portal data from Metadot version 4.0 or
higher, then you will need to install a copy of your pre-existing 'private'
directory rather than the default private data directory. (Upgrading from a very old
version of Metadot will require copying the contents of a different directory to
your private directory. See the Upgrade
document for more information).
The public directory
contains the starting data for Metadot's public uploads directory.
Make sure the directory is aliased
to /public in your httpd.conf file. (If you are upgrading your data from a
recent version of Metadot that supported the /public directory (version 4.6.1 or
higher), then copy the contents of your pre-existing /public directory instead
of using the default data. See the Upgrade
document for more information).
The skins directory
contains the starting data for Metadot's skin uploads directory.
Make sure the directory is aliased to /skins in your httpd.conf file.
to point to the private directory you
created as instructed above. Ensure that this directory is unreachable by the
web server, in order to maintain privacy of your data. Make sure this
directory exists before you start running the Metadot server. Make sure
also that the directory is writable by the apache process owner. This is
necessary because the server cgi processes will need to add files under this
directory.
If you don't want to use the
email-to-discussion feature, change all three parameters to be blank rather than
their example values.
Pay particular attention to the
"Root Domain Name" and "Script Basename" fields. These should
include the hostname your users should use to reach your metadot
installation.
Configuring Single-Signon (SSO) authentication
# use the following to enable single-signon (SSO) authentication
registration_type = FlexRegister
user_type = SingleSignonUser
authenticator_type = HeaderBasedAuthenticator
session_handler_type = HeaderBasedSessionHandler
sso_login_url = (specify your SSO login URL here)
sso_logout_url = (specify your SSO logout URL here)
authentication_header_variable = (specify the SSO header variable here)
disable_selecting_registration_modules_from_GUI = 1
When users enter a Metadot portal, they will be authenticated by the SSO system, and forwarded to the portal server. The portal itself will not know the user's details unless they have registered onto the site. Unregistered users will be handled anonymously. When you register a user on the site, you will notice that a password is not required, and in its place is an input field for the SSO login ID. Enter the user's login identifier here to associate a Metadot portal user with an SSO login.
At this point, the admin user will not be able to login, because the admin user record is not yet associated with an SSO ID. To resolve this, execute the following SQL against the Metadot database:
update users set ldapdn='(insert the admin SSO ID here)' where email='admin';
Because Metadot Portal Server generates its URLs dynamically, a portal must be protected in its entirety; it is not possible to reliably protect only certain portions of the site. Therefore, a portal that is integrated with SSO cannot have any truly anonymous users.
Currently, a Metadot portal integrated with an SSO system does not handle the user's custom start page. This is because this page only applies after login, and the user does not log in directly to the Metadot portal.
Back Next
© Copyright Metadot Corporation 2003. All rights reserved.