Skip to content

System administration

All relevant system administration menus and dialogs can be opened via the System menu:

System menu

Initial Startup and Login#

1. Open imperia

  1. Enter the following link in the address bar of your browser for the initial start of imperia:
    http://<your production server>/imp/
    The following login mask will open:
  2. During imperia's installation the user superuser is created including the password superuser.
  3. Start imperia by logging in with “superuser” in both the Name and Password fields of the login mask.

The menu opens.

Caution

  • The superuser has access to all features and menus and can maintain the system and create new users and roles.
  • The superuser has all permissions in a system.
  • Work under this user only if you have proper knowledge about the menu items!

2. Configure imperia

Once you are logged in, complete imperia's configuration by following these steps:

  1. Change the default password for the superuser.
  2. Install a target system, if this is not already done, refer to Target Systems.
  3. Enter the license data to ensure that all functions are enabled, see next chapter.

Licensing#

The license unlocks the features you purchase with imperia. You will receive a registration key and the name of the licensee with the software. Both are entered in System->Registration Key . Pay attention to upper and lower case letters or spaces.

This data has to be replaced every time additional features or modules are purchased.

To register imperia you need:

  • The regkey.bin file

  • The name of the licensee

  • A 24-digit registration key

Procedure

1. regkey.bin file

  1. Copy the regkey.bin file to the site/config directory on your develop system. The file is located on your installation CD.
  2. Then, start imperia and log in as a user with administrative privileges, in doubt use superuser.

2. registry key

  1. Open SYSTEM -> Registry Key.
    This will take you directly to the input dialog.
  2. Enter the licensee and registration key in the corresponding fields of the dialogue.
    Pay special attention to upper and lower case letters and the exact spelling of the name of the licensee.
  3. Click OK to save your entries. Back will abort the procedure without saving.

Maintenance Modes#

For some administrative tasks, it makes sense to put the production system in a maintenance mode. In maintenance mode, users cannot access the system without having to stop the web server.

imperia offers two different maintenance modes, which restrict access to the system to varying degrees.

Maintenance Mode without Superuser Access#

Once this maintenance mode is activated, all users (including the superusers) are redirected to the login screen where they can log in again when the maintenance mode is turned off.

  1. To enable this maintenance mode, set the following variable in the site/config/system.conf file:
    "AUTH_PLUGIN" = "MaintenanceNoLogin"

    Note

    • You must add this variable in the site/config/system.conf manually, because it is not automatically created during the installation.
    • The double quotation marks in the site/config/system.conf file are no longer necessary, but are retained in this documentation for compatibility reasons.

  2. To exit the maintenance mode, either enter the default value of this variable to Password, comment it out (with a # sign) or delete it.

This mode is useful, for example, if you want to create a database backup in an SQL data storage and want to prevent changes to the content during the backup.

Maintenance Mode with Superuser Access#

Unlike the above mentioned maintenance mode, in this mode only the superuser can log in the system.

Note

Only the actual superuser can log in in this mode; not users that have adopted the superuser role.

  1. The activation can be made either in the General Settings dialog (see Superuser Authentication Plug-in) or by editing the system.conf file:
    "AUTH_PLUGIN" = "Superuser"
  2. To put the system back to normal operation, proceed as with the maintenance mode without superuser access or disable the corresponding option in General Settings.

SQL Export#

Data export from an SQL database does not work through a target system in imperia 11, as the publisher in imperia 11 has to track for transparency with the target system.

Since imperia 11, publishing in an SQL database is done in two steps through the MessageCheck plug-in:

  1. In the first step, the metadata is converted by a template (imperia or view) in XML.
  2. In the second, the XML data is compared with the database.

Note

If errors occur during the data processing, the processing is canceled. Notifications about this record are retained and can be further processed.

Configuration#

  1. Add the following line to the site/config/system.conf file:
    EXPORTS = sample
    In this way, the attached export “sample” is activated.
  2. Next, edit the configuration file for this export - the one called site/config/export/sample.conf:
    Search for the DSN; that is the db_connect variable.
    The path must be changed so that the attached sample database site/sample.sqlite is found.
  3. To have the sample run, restart the Hermes.

Test#

Once a document is closed, published or deleted, the database is updated. The sample database has the following structure:

CREATE TABLE uris ( uri TEXT PRIMARY KEY,
                    directory TEXT,
                    filename TEXT,
                    template TEXT);

CREATE TABLE summaries ( node_id TEXT PRIMARY KEY,
                         title TEXT,
                         summary TEXT);

Use /usr/bin/sqlite3 to test if everything works.

In the site/exports/view/export.xml file define how metadata is mapped to the database.

Adjustments#

  • To rename your export from “sample”, change the EXPORTS variable defined in site/config/system.conf and rename the configuration file site/config/exports/sample.conf.
    Additional information can be found in the Perl documentation:

    perldoc site/modules/core/Dynamic/MessageCheck/Export.pm
perldoc site/modules/core/Dynamic/Hermes/Export.pm

  • The template file site/export/view/export.xml uses the new imperia View language.
    If you prefer to use the conventional imperia template language with XX syntax instead of imperia View language rename site/export/view/export.xml to site/export/view/export.html and change the variable “renderer” in site/config/exports/*.conf.

    Note

    Pease remember that in this case variables in templates should be interpolated with XX-TEXT, so that the resulting XML is well formed. With the View language that is the default escape.

Error Handling#

Errors are recorded in the site/export directory. These are usually repaired or deleted. Deletion is mostly harmless because errors are generated again during the next run (after correcting the templates).

Annotations#

If you want to manage exports in your MySQL, you have to change the DSN in the db_connect variable to site/config/export/*.conf. Find the exact syntax with the command “perldoc DBD::mysql” or at

http://search.cpan.org/~capttofu/DBD-mysql/lib/DBD/mysql.pm#DESCRIPTION

Normally, it looks like this:

db_connect = dbi:mysql:database=NAME_DER_DB;host=IP_ODER_NAME

The username and password are configured in the same file.

For more details, please see the Chapter Move Sites in this documentation.

System Services#

System services are automatically started by imperia at specific times to perform SiteActives and generate overview pages.

The execution of system services can be carried out either on the basis of fixed a) times or b) events.
The SiteActive uses the variables that you have set for the system service to generate the overview pages, for example, when a specific day has started (time-based system service) or or whenever a new post is generated (event-based system service) or.
From these posts the header image, title, teaser and date are read out and used to generate an overview page by the SiteActive.

a) Time-based system services
This service takes place at certain intervals, e.g. hourly, daily, monthly, in certain periods (in minutes or hours), on certain days or at a certain time.

b) Event-based system service
This service is performed by defining one or more directories to be monitored by the Hermes daemon. Once a document is added, deleted, or edited in one of the monitored directories, the Hermes daemon performs the SiteActive.

The Hermes daemon reads out from the configuration of the system services, which template is used for the execution of the SiteActivity and where the generated file is to be stored under which name. The Hermes daemon then transfers these parameters to the CGI script, which can also be called manually.

Both services can be set independently or combined. But in both cases you should take into consideration that the Hermes Daemon doesn't run the SiteActives too seldom or too often:
Example:
If a SiteActive is performed with both of these options, but with a large time interval (e.g. monthly), the SiteActive is more likely to be triggered by the event-based system service because, for example, dead links caused by deleted items can occur during this interval.
However, if changes occur very often in the monitored directory together with a time-based system service with a short interval (e.g. 5 minutes), it may happen that the Hermes daemon performs the SiteActive several times within a run.

The configuration of the system services that run on your imperia are taken from the menu System > System Services dialog. imperia stores the system services configurations in the site/config/imperia.schedule file on your develop system. This file has to be present on all target systems you want to run the system services on. To transfer the configuration file go to the System > Synchronize System Files menu.

Prerequisites

  • The Hermes daemon has to be running both on the development and target systems in order to perform the System Services.
  • In order to configure the already running system services in imperia, go to the System > System Services menu.
  • imperia stores the configuration of the system services in the file site/config/imperia.schedule of your development system.
    • This file has to be stored in every target system.
    • Therefore, you have to synchronize the schedule files. To do so, go to the System > Synchronize System Files menu.

Using schedule files for a better overview of the system services#

In order to keep an overview of your different system services you can create different lists - so called "schedule files" - where you can store them.

For example: Create a basis list for overviews and another one for certain subpages, e.g. blogs; i.e. you create a schedule file for all 'normal overview pages' and a schedule file for the blog's tags and its archive.

Note

  • By default, all system services are saved in the standard system file 'imperia.schedule' which is stored in site/config/imperia.schedule.
  • Newly created files are saved as for example: 'newfile.schedule'
  • There are also two system.conf variables that indicate which file is to be considered:
    • SCHEDULE variable = "blog.schedule:overview.schedule:neueliste.schedule" (files are separated by :)
    • SCHEDULE_ALWAYS-Variable = 1 ensures that the files are executed.
  • Like System Services, Schedule Files also have to be synchronized, see Synchronize Files.

Creating a new schedule file

  1. Open the system services settings via the System > System Services menu.
    In the top line the schedule file is displayed, for which the system services are listed below.

  2. Execute the New schedule file option.

    New schedule file

  3. In the details area below, give the new schedule file a name.

    New schedule file

  4. Click Create.
    The new schedule file is created.

  5. Then you have to add the newly created schedule file to 'system.conf'. Add the schedule file manually to 'system.conf' under the 'SCHEDULE' variable.
    You can edit the 'system.conf' on the user interface of your imperia system, see System configuration via the User Interface.

Deleting a schedule file

  • Select the desired schedule file from the drop-down list in the top line of the System Services Settings and click on the Delete symbol behind the entry:

    Delete schedule file

    Warning

    When you delete the schedule file, you also delete all added system services.

Creating a system service#

In this chapter you will learn how to create time- or event-based system services. The process contains 2 steps:

  1. Create new system service and set the parameters.

  2. Synchronize system service to target systems.

Warning

Executing a system service at short intervals or executing a lot of system services can lead to significant load on the server.

PREREQUISITES

  1. In order to execute time driven system services, you need to set the SCHEDULE_ALWAYS system variable.

  2. In case you have more than one Schedule File, select the desired one before you create the new System Service, see chapter before.

1. Create new system service and set the parameters

  1. Call the System > System Services menu.
    You will find the already created system services, sorted by their interval.

    System services dialog

  2. Click New system service to create a new system service.

    New system service dialog

  3. Configure the new system service:

    • The service number, which is automatically assigned as the unique ID of the system service (automatically incremented), is read out read-only.
    • Description: This field is used for a brief description of the service that appears in the list of system services as a service heading.
    • Interval: Use the drop down menu to specify the execution interval of time-dependant system services.
    • Execution time: The two drop down menus are used to set a specific time for the service to start and run regularly.
    • ActiveList base directory: Specify the directory on which the system service should operate. Example 'blog': In this case it would be /posts, meaning that the ActiveList using this variable in order to find all documents (or 'all posts') under /posts.
    • ActiveList generation: Enter the parameters needed for the execution of the SiteActive.
      • The different parameters are separated by colons :.
      • Mandatory parameters are:
        • Indication of a template: TEMPLATE=/directory/file/name
        • SAVEPAGE: SAVEPAGE=/directory/file/name
      • Optionally, other variables may be defined as key-value pairs. These variables may be referenced as FF-variables when working with the SiteActive's code.
      • Example for an entry in the ActiveList generation field: imp TEMPLATE=/movies/index.html:SAVEPAGE=/index.html:foo=bar:myvar=myvalue

    • Alert directory: Set the directory that has to be watched by the Hermes for this system service.
      In most cases, the alert directory is the same as the base directory (here /posts) as the overview pages normally update as soon as a new post is entered.
      But you can also enter a superordinated directoy here (e.g. /), meaning that ActiveList is executed with every change.

      • IMPORTANT:
        The system always interprets the path to TEMPLATE, SAVEPAGE and alert directory, starting from the document root of your imperia system.
      • If you want to monitor multiple directories, enter them as a comma-separated list in the field:
        /dir1,/dir2,/dir3,/dir4/news/
      • If certain files or directories have to be excluded from the monitoring, use an exclamation mark:
        /dir1,!/dir1/print.html,/dir2/news,!/dir2/news/archive
      • The driving force for the system services in this case are the notification files in /site/incoming. The Hermes runs trough this directory and checks if there are suitable system services in the path data. If there is a match, the Hermes runs the system service and deletes the notification file.

    • Alarm category: Here you may enter the Node-ID of a category. Any change to the content in the category specified here triggers the system service - regardless of the time interval specified. Specify the degree of recursion in brackets after node_id: e.g. '/1/3(2)`

    • Alarm tag: Use this input field to specify a list of tags, which will always start the system service when a document having these tags is changed, regardless of the specified time interval. Use the format 'domain|tag' and specify multiple tags comma separated. Use 'domain|*' to trigger all tags of a domain. If the domain is not specified, the default domain is used.
    • Alarm realm: If you specify a list of realms here, any change to a document having tags in any of these realms will trigger the system service regardless of the specified time interval for this service. Multiple domains are specified comma separated. Note, that if both Alert tag and Alert realm are set, Alert realm is ignored.
    • Click Save to save the changes or Cancel to exit without saving.

2. Synchronize system service to target systems

  • To make the system service available in the target systems, the settings must be transferred.
  • Go to the System > Synchronize system files menu. For more information, refer to the section Synchronize files. A new system service is now created in the selected schedule file, which runs automatically in the development and all target systems at the set times or events.

Changing system services#

You can also customize existing system services.

  1. Call the system services dialog from the System > System Services menu.

    Systemdienst bearbeiten

  2. Make sure to be in the desired schedule file. You select the schedule file in the top line of the system services settings.

  3. Click in the line of the system service you want to change.
    The detail area now shows the settings for the system service.
  4. Make the desired changes. Proceed as described under Creating a system service.
  5. Click Save to save the changes.

As for new system services any changes or deleting of existing ones have to be synchronized, too. Proceed as described in Synchronize Files to do so.

Deleting a system service#

  • From the drop-down list behind a system service, select Delete.

    Deleting system service

    Warning

    When deleting a system service, no previous security prompt appears. Deleted system services are removed directly!

Document Storage#

Apart from document storage in a file system, imperia supports different SQL databases (RDBMS):

  • Oracle 8i (or higher)
  • MS-SQL (2005 version or higher)
  • PostgreSQL 8.2 (or higher)
  • MySQL (from 5.X version)

Other databases as Informix or SyBase may be used after enquiry. The necessary changes to the settings of a document storage can be done for a fee.

Prerequisites

For the next chapter, we assume that both the installation of the RDBMS server and the client have already been successfully completed.

Differences and Restrictions to the File System#

Analytics View

The feature Analytics View works at the moment only with File65.

Note

  • In order to use Analytics View you have to activiate the Hermes plug-in "Analyzer" in the Hermes-config.
  • This plug-in triggers the specific Analyzer, e.g. the Analyzer Piwik.pm that you will find in site/modules/core/Dynamic/Analyzer/Piwik.pm (reads out the data from Piwik).
  • Please ensure that you have entered a start date for the first import. This is written in the config under data_start.
  • In the file Piwik.pm you will also find a configuration example.

1. Configura Analytics View

  1. Configure the access to your Web Analyses Tool in the file site/config/analyzers.conf (you will find an example with comments under site/config/analyzers.conf.sample).
  2. For each webpage you want to import the Analytics View, create the a section <site>.
    You will find all configuration variables described under perldoc Dynamic::Analyzer::Piwik and perldoc Dynamic::URIMapper::Default.

2. Add Analytics View to the Menu

  1. Add the menu item "Analytics View" via the Menu Configuration.
  2. Set the access rights for the Controller: document/performanceview.

Prerequisites for the configuration of the RDBMS document storage#

The prerequisite for the configuration of the RDBMS document storage in a data base is the installation of the following modules that are not part of the standard perl distribution:

  • DBI: The DBI is the standard database interface module for Perl. It defines a set of methods, variables and conventions that provide a consistent database interface independent of the actual database being used

  • DBD::: Represents the specific database driver. That means, another specific database driver is required - depending on the database to be used.

(Source: http://dbi.perl.org/).

Note

  • For many Linux distributions, you can install those perl modules via the package management.
  • For Windows system you can install the perl environment 'Strawberry-Perl' that already includes the above mentioned drivers. Alternatively, you can download the modules via CPAN and compile it by yourself.

Configuration of the RDBMS document storage#

After installation, the document storage is set to the File65 plug-in. This may be changed from the System > Document Storage menu. The different types of document storage are realized by different plug-ins.

The following plugins are available:

  • File65

  • MySQL

  • PostgreSQL

  • ODBC_MSSQL

  • Oracle

In the following you will find the documentation of how to change the plug-in, e.g. to MySQL:

  1. Open the page PLUG-INS from the System > Document Storage menu

    PLUG-IN

  2. Choose the desired plug-in from the drop down menu.
    The page will change to the corresponding configuration dialog (in the following example the plug-in "MySQL" was chosen):

  3. Make the settings for the plug-in:

    PLUG-IN

    Note

    The following parameters are permanently written in the file /site/config/repositories/default.conf

    • Database User (required): Name of the user who is allowed to use the database. This user must be created manually and have the appropriate permissions to the specified in “Database Name” database.

    • Database Name (required): Name of the database. The database must be created manually.

    • (Re)set password (required): Password for the database user.

    • Database Hostname (required, if no DBI connect string is defined):
      Name of the host on which the database is installed. If necessary, the corresponding domain must also be filled.
    • Database Server Port: Specify this port only if it is different from the default port of the different RDBMSs.
    • Maximum size for type ‘TEXT’: Maximum possible input into a column of ANSI SQL type "TEXT" or VARCHAR for MSSQL server.

    PLUG-IN

    • DBI Connect String: This input field is optional. Use this field only if the given fields are not sufficient to compose the connecet string. This field will then override, among other things, the database hostname and many other inputs.
    • DBI Tracing Level: This is the degree of the information content of the DBI trace. The higher the number entered here, the more information stored in the trace log file. The default setting should be 0 (no trace). For the development of new database plug-ins, we recommend 3, because settings 1 and 2 do not work correctly due to an internal problem of the DBI module.
    • DBI Tracing Filename: These are the absolute path to and the filename of the trace log file.
    • LongTruncOk: Should not be set, as in a case of an error, very long strings are displayed without showing the actual error message.
    • LongReadLen: This is the maximum length of a string, which can be read. Default value is 2 million.
    • Max. number of executed statements before re-connect:
      This item specifies the maximum number of SQL statements before the connection to the database is closed.
    • Add New User field: With the help of the empty inputs at the end, you may set your own parameters.

  4. Click Save to save your settings.

    Important

    The "WARNING" dialog box contains important information. Please read the instructions carefully in order to complete the configuration.

  5. Click OK in order to close the warning dialog.

Informations on other plug-ins:

  • PostgreSQL:
    The PostgreSQL plug-in provides the interface to the PostgreSQL database. Prerequisite is the version 8.x (and higher) for imperia.
  • ODBC_MSSQL:
    The ODBC_MSSQL plug-in provides the interface to the MSSQL database via ODBC.
  • Oracle:
    The Oracle plug-in provides the interface to the Oracle database.

Controller Permissions#

Permissions management in imperia is based on controller permissions. By that, you also define group access rights.

Add-on documentation (german)>.

For more information on controller, read the chapter Model-View-Controller.

To open controller permissions:

  • To access the Permissions dialog use the System > Permissions menu.

    Permissions

The controllers are sorted in a tree structure. Every controller is displayed with different (or no) icons that represent different permission levels:

  • : All permissions are taken over from the parent controller.
  • : Allow everybody logged in.
  • No Icon: No configuration of the permissions. That means, that the access is forbidden.

Changing the controller permissions#

  • To change the permissions for a given controller, click on the name of the desired controller (e.g. “dashboard”).
    The permissions for the controller are now displayed below the tree structure:

    Controller permissions dialog

  • Now make the desired settings:

    • Inherit permissions from parent controller: Activate the switch to apply the permissions of the parent controller for the selected controller. This also applies to future changes.
      Deactivate the switch if you want to set specific permissions for the current and all inheriting controllers.
      This setting is later displayed in the structure tree with .

      note

      The root controller is an exception, since it cannot inherit any permissions.

  • Under Set User privileges define who is allowed to execute the selected controller.

    • Select everyone if all users should be allowed to execute the controller.

    • Activate the specific groups option if you want to grant rights to selected groups only. Then select the desired groups that should be able to run the controller from the drop-down list that appears.

      Permissions for the controller

  • Select only superuser if you want only the superuser to run the controller.

  • Under Set Administrator privileges define who is allowed to edit the permissions of the selected controller.

  • Click Save to save your settings.

Permissions tree (Controller tree)

The labels of the nodes correspond to URIs. The URIs start after the leading /imp or after the defined in the system configuration variable DYNAMIC_URI_PREFIX prefix. All this paths correspond to a Perl module (a controller) in the file system. The mapping is as follows:

  • The base directory for all controllers is the site/modules/core/Imperia/Controller directory. The first character of each part of a controller's path is converted to uppercase, underscores are removed and the subsequent character is capitalized.
    For example, the path /document/foo_bar is converted to /Document/FooBar. This represents the part of the path, valid for all files, relevant to a controller.

  • Files associated with the permissions tree /System/Permissions, correspond to predefined rules in modules/core/Imperia/Controller/System/Permissions.*.
    The following files can be found in the permissions tree for each controller:

    • Permissions.pm - the Perl module with the controller's code.
    • Permissions.icon - an icon identifier (icons can be found in the /imperia/images/icons directory).
    • Permissions.docref - an identifier for the documentation, located under /imperia/documentation/imperia.
    • Permissons.description - a short description of the controller.
    • Permissions.acl - the Access-Control-List (ACL) for the controller.

  • If there is no Perl module, but a directory (e.g. /document/media) as a node in the permissions tree, that means that files can be further added to this directory.

ACL of an Controller

The Access-Control-List (ACL) of a controller (or site area, etc.) can be accessed by clicking on the name in the permissions tree.

  • The most important privilege is the right to execute a controller, simply called access.
  • Write permissions allow you to edit permissions for this node in the tree.
  • Read permissions are not safety related, they are relevant for the visibility of a node in the tree. The system enforces read access to everyone with write privileges.

Unlike other trees in imperia (especially the category tree), the permissions tree uses “true” inheritance for its privileges system. If a node has a parent node in the tree, its permissions can simply be inherited by selecting the appropriate checkbox. “True” inheritance because this relationship is permanent. In the category tree, for example, permissions of a parent category can be “inherited”, however subsequent permissions changes to the parent category are not adopted by the child node. The internal “inheritance” is achieved by deleting the ACL file associated with the controller.

Another new feature of the permissions tree are the so-called “free rides”. You can allow access to certain areas of the system for each logged in user via the appropriate checkboxes. Although it is theoretically possible, the user interface denies public “write” access to the permissions section. Internally, public access is implemented through the invalid “*” role id.

It is interesting that the main class of all controllers in imperia (Imperia::Controller) does not carry out authentication or authorization. Therefore, all imperia controllers should be derived from the Imperia::Lib::Controller class, which in turn inherits Imperia::Controller. Imperia::Lib::Controller implements the _auto() method, which is always called before the go() or dispatch() methods. If the _auto() method returns undef the request processing is stopped. This method also carries out the authentication and authorization:

  1. First, a user is authenticated - the password or another configured token is checked though the cookie.
  2. Then, the user's authorization is checked to make sure he or she has access permissions to the requested field.

  3. The authorization request is carried out by the _allowed() method, implemented in Imperia::Controller. This method is a class method, so that it is not necessary to instantiate the controller in order to check the authorization. There are three optional arguments that can be passed to the _allowed() method:

    • The default path of the controller (e.g. /system/permissions)
    • The access type. By default, it is set to “X”, for execution, in case no write (“W”) or read (“V”) permissions are required.
    • The user ID, which generally corresponds to the current user. Strictly speaking, this argument is a role ID, either a (negative) group ID or a (positive) user ID.

General Settings#

To access the General Settings dialog go to the System > General Settings menu.

General settings dialog

Here you can make the system-wide settings in imperia.

To save the changes made to the sections use the Save button on the bottom. To exit without saving use Back.

Enter the validity of the cookie in seconds. The default value is 7200 seconds. If users are idle for a period that is longer than this setting, they have to login to the system again.

Document History#

In this section you can define who can see Dates/Times in the document history:

  • everybody: all groups.
  • nobody: the display of date and time is turned off generally.
  • superuser: only users who have access to the superuser group can see the date and time.

JavaVM#

The Java virtual machine is configured in this section. The following settings are available:

  • Java Executable:
    In this field, enter the path to the Java interpreter or the Java wrapper script (e.g. /usr/lib/java/bin/java).

  • Classpath:
    In this field, enter the classpath settings for the Java virtual machine on imperia's server. Leave this field blank if unsure.

This section configures the link check for external links.

General settings dialog

  • Activate the checkbox Enable checking of links with HTTP-Requests to activate the function.
  • If your network uses a proxy server, make the appropriate adjustments in the various input fields.

Mail Configuration#

In this section you can make settings for forwarding internal e-mails to external e-mail addresses.

General settings

  • Under SMTP_SERVER, enter the name or IP address of the mail server used to send the e-mail.
  • Under FORWARED_INTERNAL_MESSAGES_PREFIX, set a prefix for messages forwarded by e-mail.
  • Specify a sender name for the forwarded messages in the SMTP_MAIL_FORM input field.

Progressive Web App#

Make settings for the Progressive Web App.

General settings

  • Enter a name for the app in the App name input field. This name will appear on the home screen or desktop after the app has been installed.
  • In case there is not enough space to display the full name, you can enter a Short name which will be displayed instead.
  • Enter a general Description of the app.
  • Enter a Background color for the loading display of the app in hexadecimal values.

Superuser Authentication Plug-in#

System Config#

General settings

  • Privileges for resetting a user password: Select the groups that are allowed to change the user password.

    Note

    Per default, everybody can change the password without knowing the old one.

    Read also the corresponding System Configuration Variable

  • Disable Category Search for given groups: Select groups who aren't allowed to use the category search.

    Warning

    The groups then won't be able to use neither the Document Browser nor the MAM.

  • Default theme selection:
    Here you can set the theme for imperia.

    Note

    Each user can set the theme individually under Look and Feel.

    As the administrator you can set the theme for the entire systems, if the user didn't set an individually one.

  • Default header text:
    In diesem Abschnitt wird ein Header-Text eingefügt.

    Note

    Each user can set additional text individually under Look and Feel.

  • Default imperia logo:
    Here you can set the logo for the login-screen.

  • Standard imperia login logo:
    Here you can set the logo for user interface in the upper left corner in imperia.

System Language#

This section sets the system language and the system charset.

General settings

The default language is English. Use the drop down menu to select a different language.

Regardless of the language, all data is stored and delivered in UTF-8. This applies to any screen output as well as all data entered by users.

Note

Please note that when changing the system language, some parts of the UI may still be in English.

Template Processor#

By default scripts, layers, frames, iframes and forms in PREVIEW and EDIT modes are not supported. This behavior can be changed in this section. Select the corresponding checkboxes.
For more information, read System configuration variable.

Login Message#

As the imperia system admin you have the possibility to create messages on the login screen that are displayed for all users.
This can be useful for delivering organizational news, e.g. on planned system breakdowns, or to describes procedures, e.g. how to reset passwords.

Create new Login Message

  1. Open the System > Login Message menu.

    site login message

  2. Select a template from the Examples drop-down menu that will be inserted into the editor.

  3. Edit the message in the text editor.
  4. Save your changes.

As soon as you the message is stored, it will be displayed to all users when they login into imperia*, for example:

Login-Screen

Delete Login Message

  1. To remove the login message, delete the content in the editor.
  2. Save your changes.

The Login Message will be deleted automatically on the login screen.

Look and Feel#

As a user you can also individually set the look and feel of your imperia. For more information read the chapter Look and feel of the user manual.

System Configuration#

This chapter shows you how you can edit configuration files directly via the user interface.

Also, following important system configuration files will be introduced:e Konfiguration des Systems wichtig sind:

System Configuration via the User Interface#

imperia offers a user interface to change all configuration files.
In this way it is not necessary to access the file system to change system settings that are not directly accessible from the user interface.

Prerequisite

This feature is only available to users with superuser privileges.

1. Configuration of the interface

Important

Create the file site/config/config.conf, unless it is not done yet. This file is used to control which files can be edited through the interface.
You will find an example under site/config/config.conf.sample.

By default, all configuration files are editable. This may be limited by editing the config.conf file. This file contains a list of configuration files that can be edited via the user interface:

  • To remove a file from this list, comment it with # or delete it completely.
  • Conversely, to make a file editable, add it to the list or remove the comment characters in front of it.These are then indicated by .
  • To control, which files can only be read through the interface, add a * in front of the desired configuration file. These are then indicated by .

2. Editing the configuration files

  1. To access the files, go to the System > Configuration menu.

    configuration files

  2. Click Show in the line of the desired file.
    The editor appears in a separate area to the right of the list.

    Note

    • Only if you have edit rights, you will be able to edit the file in the editor.
    • If you only have read rights, only the content of the file will be shown when clicking on it; editing is not possible.
    • In case you dont have any read or write rights, the files won't be opened at all.

  3. Save the changes.

Dynamic Modules#

Dynamic modules that are configured in the dynamic.conf file are described in detail in the chapter Dynamic Modules in the programming documentation.

The internal editor can also be used to edit the dynamic.conf file, located under site/config. Proceed as follows:

  1. Go to the System > Dynamic Modules menu.

    Dynamic Modules

  2. You can insert or upload the code in the text box.
    If you upload a file, it is saved then as dynamic.conf and the existing file is overwritten.

  3. Save the changes by clicking on Save.

Tip

You can find a sample configuration in site/config/linkmanager.conf.sample.

1. Location of the linkmanager

The link consistency check configuration is done in the linkmanager.conf file, located in the site/config directory.

  • Links on multiple systems can be checked.

  • The settings are always done within a block enclosed in tags:

    <SERVER myServer>

[Settings for the system]

</SERVER>

  • Replace the field myServer, enter a unique name within the configuration file for that system.

  • Settings are always listed in the following scheme:

    Directive = "value"

2. Setting of the linkmanager

The following is a description of the individual directives for the configuration:

  • SERVERNAME
    Enter a name for the system. This name is displayed in the title bar of the report with the results of the link consistency check for that particular system.

    SERVERNAME = "Livesystem"

  • SERVER_URL
    Enter the URL of the system on which the LCC is to perform HTTP-requests to check the links.

    `SERVER_URL = "http://www.myserver.com"`

  • SETTYPE_HTML
    This directive contains a list of files that are to be treated as HTML files. Enter the appropriate file extensions as a regular expression. The alternative file extensions are separated by the pipe character ("|").

    SETTYPE_HTML = "\..?htm.?|\..?php"

  • SETTYPE_CSS
    This directive contains a list of files that are to be treated as cascading style sheet files. Enter the appropriate file extensions as a regular expression. The alternative file extensions are separated by the pipe character ("|").

    SETTYPE_CSS = "\.css/i"

  • EXCLUDE_FILE
    Enter a regular expression for files that should not be controlled by the link consistency check. Files whose names match the pattern will be skipped.

    EXCLUDE_FILE = "^print"

  • EXCLUDE_DIR
    Enter a regular expression for directories that should not be checked by the link consistency check. Directories whose names match the pattern will be skipped.

    EXCLUDE_DIR = "test"

  • EXCLUDE_FULL_DIR
    This directive allows you to specify full paths to be left out of the link consistency check. Only paths that match the entered value will be skipped.

    EXCLUDE_FULL_DIR = "/site"

  • AUTHBASIC_login
    When you have secured a target system with basic authentication, the authentication data has to be entered in the link consistency check configuration. This data is used by the LCC to check the access links to a certain system. If the authentication data is not entered, all the references will be classified as defective in the report. The “401 Authorization required” error message will be displayed in the HTTP errors column.

    AUTHBASIC_login = "login"

  • AUTHBASIC_password
    Enter the login password for protected areas of ​​the system to be tested.

    AUTHBASIC_password = "password"

  • ROOT_PAGES
    This directive defines the starting pages for the LCC. A link consistency check is done on all the references of the pages, entered here. This directive corresponds to “Referenced objects” in the report.
    List several pages in a space separated list:

    ROOT_PAGES = "/index.html.de /index.html.en"

  • HTTP_PROXY
    If access to the system is done via a proxy server, the URL must be entered in this directive.

    HTTP_PROXY = "http://proxy:3128"

    Important

    The LCC evaluates the following directives only if an HTTP proxy is defined.

    • HTTPS_PROXY
      Sets the proxy for encrypted data transfer with SSL.

      HTTPS_PROXY = "http://proxy:3128"

    • FTP_PROXY
      With this directive the proxy for the FTP protocol is set up.

      FTP_PROXY = "http://proxy:3128"

    • NO_PROXY
      The URLs to be accessed directly are specified here.

      NO_PROXY = "http://www.mynoproxy.de"

Synchronize Files#

This feature allows you to transfer modified system files to various target systems.
Example: This is necessary if system services (SiteActives) that relate to the Hermes daemon on a target system were amended. Those and other configuration files need to be transferred to the various target systems.

To make a transfer, proceed as follows:

1. Prerequisites

  1. Create the file /site/config/system_files.conf.
  2. Put in it the paths to the files that have to be copied, starting with the SITE directory.
    By default, there is also a /config/imperia.schedule file, in which the system services are stored.

2. Sychronize Files

  1. Go to the System > Synchronize System Files menu.
    It opens the Transmit System Files dialog.
  2. Select the target systems on which to transfer the modified system files from the Configured target systems list.
  3. Click Copy.

The transfer is carried out and a log is diplayed.

Desktop Views#

As an administrator, you can also define system-wide desktop views and make them available for all users or only certain groups.

You will find a detailed description on how to create desktop views in the user manual.

Note

  • The changes you make on Perl modules will be saved on the system update securely.
    The system configuration variables are to be found in the Configuration Glossary.
  • All user-defined desktop views can also be deleted.
    The system side delivered Desktop views cannot be deleted.

In order to make new desktop views available, proceed as follows

  1. Use the Document > Desktop menu.

  2. Click the Manage Views option in the View drop-down list in the upper right corner.

    Desktop Views

  3. Assign the groups to which the view should be made available. Click Provide in the drop-down list behind the view.

    Desktop View Manager

  4. There you can either allow everybody logged in to use this view, select specific groups or only allow the superuser to use it.

    Desktop View Manager

  5. Click Provide to make the view available.

The desktop view is now available to all assigned groups.

Tracking Changes#

The administrative settings for tracking changes are limited to the determination of the colors with which the changes are outlined. These colors can be defined in a separate style sheet.

The following changes can be displayed:

  • added text (default - green and underlined)

  • deleted text (default - red)

  • added tables, table cells, and anchor (default - light green).

  • deleted tables, table cells, and anchor (default - orange).

  • changed images (default - in an orange frame).

  • inserted line breaks (default - text in the new line is shown in gray).

  • references to an IFrame (default - IFrames are represented in an orange frame).

There are two ways to change the colors that are used for the representation of the changes:

Within the template

Within the stylesheet

If the default colors for tracking changes are changed in the style sheet, this applies to all documents on the entire production system.
The stylesheet is located in the docroot_of_the_production_sys/imperia/skin/html/css/diff.css file.

The following CSS styles are available:

  • imperiaPlusSpan: Determines the appearance of added text.
  • imperiaMinusSpan: Determines the appearance of deleted text.
  • imperiaPlusSpan table, td, a: Determines the appearance of added tables, table cells, and anchors.
  • imperiaMinusSpan table, td, a: Determines the appearance of deleted tables, table cells, and anchors.
  • imperiaPlusSpan img iframe: Determines the appearance of added images and iframes.
  • imperiaMinusSpan img iframe: Determines the appearance of deleted images and iframes.
  • imperiaNewlineChangesSpan: Determines the appearance of wrapped text.
  • imperiaImageChanged: Determines the appearance of altered images.
  • imperiaIFrameChanged: Determines the appearance of changed IFrames.

Request Logging#

imperia normally logs HTTP requests to the site/logs/access.log file.

Example:

[Fri Sep 14 12:52:19 2012] [1347616339.25099] [UFL@U38AAAEAABx3lhAAAAAE] [info] 
Query params: __imperia_node_id: /51000/58585/59497
[Fri Sep 14 12:52:19 2012] [1347616339.25178] [UFL@U38AAAEAABx3lhAAAAAE] [info] 
Path uri: /imp/document/info
[Fri Sep 14 12:52:19 2012] [1347616339.25178] [UFL@U38AAAEAABx3lhAAAAAE] [info] 
Method: GET
[Fri Sep 14 12:52:19 2012] [1347616339.25632] [UFL@U38AAAEAABx3lhAAAAAE] [info] 
Login: john_doe

  • Each log entry consists of the date and time, a high resolution timestamp, a unique identifier for the request and the log level (here: info).

  • The first line gives the request parameters (if any).

  • The second line shows the controller path.

  • The third line gives the type of request (GET or POST).

  • The fourth line gives the login of the user who initiated the request.

You can change the default behavior using system variables. The following system variables are supported:

  • IMPERIA_LOG_TARGET — either “stderr” for standard error (normally the web server error log), or “internal” for the default location, or an absolute path to a custom file.

  • IMPERIA_LOG_LEVEL — “none” (alias “error” ) for no request logging, “info” (the default setting), or “debug” for verbose output.

Alternatively, instead of system variables you can set environment variables with the same name.