Operation

Operational Concept

imperia has a staging architecture. The develop system is mainly used by editors to manage the content. The other imperia system, usually physically separated from the develop one, is the Live system where the documents are published.

Above all it must be decided if and what kind of access would providers, partners and pirobase imperia gmbh have to the system in order to provide technical support.

It can be very helpful, if in projects or questions to the support, pirobase imperia gmbh has access to the command line (e.g. ssh under Unix or RDesktop/vnc under Windows) and websites of the develop and live systems. In this way questions and problems can be dealt with faster.

The following sections describe the possible production system environments. Test systems can, but need not have a complex structure.

The develop system is adjusted according to the needs of the publication ( Internet or Intranet). In production systems, usually two servers are used - one for the develop system and another for the target system(s).

The develop system is part of imperia which enables authors to create and edit documents. What document actions can be performed by authors depends mainly on roles and workflows, defined in the develop system.

When the work on a document is finished, it is transferred, manually or automatically, from a develop system to one or more target systems. This process is called publishing. The publishing is done by publish plug-ins which generate different target formats on the target system. If you use the publish plug-in, imperia copies the already rendered documents, stored on a develop system ,to the file system of the respective target system. The target system can automatically generate site maps from these published documents, ensuring that they always give a current overview of the website topics. This is done by the SiteActives, the background daemon Hermes and the notification plug-in. This notification plug-in copies the entire document in binary format to a target system. The background daemon Hermes processes this notification file and stores it on imperia's target system. In addition, the notification file triggers the so called system services, which manage the above mentioned SiteActive functions.

Server Backend

Apache mod_perl

The Apache mod_perl module is embedded in the Apache web server Perl interpreter. This means the Perl interpreter should not be restarted on every invocation, as is the case with CGI. All requests are routed to the appropriate controller and deliver the corresponding pages via a handler.

Additional Apache2 web server configuration (e.g. vhost):

PerlOptions +Parent

PerlModule Apache2::RequestRec
PerlModule Apache2::compat

<Perl>
   unshift @INC, '/var/www/imperia/site/modules/core';
   unshift @INC, '/var/www/imperia/site/modules/collection';
   push @INC, '/var/www/imperia/site/modules/fallback';
</Perl>
<Location /imp/>
   SetHandler modperl
   PerlResponseHandler Imperia::Core::Backends::ModPerl20
</Location>

Note

Please note that when using multiple virtual hosts the entry

   PerlOptions +Parent

can be set only in one virtual host. This is sufficient, however, because the switch applies to all virtual hosts.

Replace /var/www/imperia/site with the absolute path to your imperia system.

If the prefix "/imp" has to be changed with something else, then the system.conf variable URI_PREFIX also has to be adjusted. This variable cannot contain slashes.

Note

When using an Oracle database, the Oracle environment variables are entered in the startup script of the Apache web server, if you want to use mod_perl.

 export NLS_LANG="AMERICAN_AMERICA.WE8ISO8859P15"
 export NLS_NCHAR_CHARACTERSET="WE8ISO8859P15"

Only in this way will these variables be loaded before mod_perl. In any other position, the execution is late and mod_perl is already loaded. Environment variables have no effect on mod_perl and imperia. The consequence: the database cannot be accessed. In a CGI backend, entering the following in default.conf is enough:

 env_NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P15
 env_NLS_NCHAR_CHARACTERSET = WE8ISO8859P15

FastCGI

Example configurations for FastCGI:

Apache mod_fcgid module

ScriptAlias /cgi-bin /srv/www/imperia/cgi-bin
<Location /cgi-bin/imperia-fcgi.pl>
    SetHandler fcgid-script
    Options ExecCGI
    Order allow,deny
    Allow from all
</Location>

Apache mod_fcgid module

ScriptAlias /fcgi-bin /srv/www/imperia/fcgi-bin
<Location /fcgi-bin>
    SetHandler fcgid-script
    Options ExecCGI
    Order allow,deny
    Allow from all
</Location>

Apache mod_fastcgi module

AppClass /srv/www/imperia/dev/cgi-bin/imperia-fcgi.pl
Alias /cgi-bin /srv/www/imperia/cgi-bin
<Location /imp/>
    SetHandler fastcgi-script
</Location>

Apache mod_fastcgi module

ScriptAlias /cgi-bin /srv/www/imperia/cgi-bin
<Location /cgi-bin/imperia-fcgi.pl>
    SetHandler fastcgi-script
    Options ExecCGI
    Order allow,deny
    Allow from all
</Location>

Internal Web Server

The internal web server site/bin/site_imperia.pl may be used for development purposes; especially while debugging.

Use the --help option to view all the available options.

Performance

Hardware

When talking about web applications, such as a CMS, Intel architectures are preferred to Sparc architectures.

File System

If the system is a Linux one, XFS, ext4, or ReiserFS file system should be used.

Browser

In imperia 10, only browsers that support the current web technologies will be supported. Older browsers cannot be used (see also Browser).

Data Structure

The directories, subdirectories and category structure should be planned very carefully. The more documents there are in a directory, the slower it is accessed. The goal is to have less documents under one category.