Operations

Table Of Contents

About

Icons used in this guide

Some icons are used to alert you about additional informations.

"Important", showed by an exclamation mark, alerts you about important informations about the administration area of Ametys Runtime.

"Remark", showed by an i, alerts you about additional informations, for example it gives you others methods to reach your goal.

"Tips", showed by a tick, alerts you about tips to work with more efficiency.

Targeted public

This document is a system operational guide of the CMS open source Ametys. It has been written for a technical public like system administrators.

Comments

If you need some help, do not hesitate to ask mailing-lists users-fr@ametys.org or dev-fr@ametys.org, and to add your comments and informations to this documentation.

Introduction

This document contains the informations for the operations of an installed CMS Ametys V3.

Please read the installation guide of your application to know the components before proceed.

Please read, if exists, the extension of the operation guide provided to know the specificities of your project: some informations of this document may not be applicable in every cases.

Data

The CMS store 2 types of data.

Main data (JCR)

The main data are the contents, their meta-data, their attachments, the organization of the pages, the workflow...

These data are stored with the JCR API 1.0.

The implementation used is Apache JackRabbit (http://jackrabbit.apache.org) where the physical storage can be done in many ways: file system, embedded database (DERBY), classical database (MySQL)...

To know the list of existing implementations and how to configure them, check JackRabbit website.

The Jackrabbit configuration file is WEB-INF/param/repository.xml.

By default, the implementation used Derby and the file system, the whole thing is stored into the directory configured (see the manual of the Administrator Area CMS).

Secondary data (SQL)

The secondary data (depends on the configuration of your CMS) may be:

• the users;
• the group of users;
• the rights management;
• ...

The secondary data are stored into a SQL database (like MySQL). The chosen database is visible in the configuration parameters (see the manual of the Administrator Area CMS).

Backup

To perform a backup of the data it is necessary to backup all types of data simultaneously.

The operations to perform depends on the configuration but are by default:

• copy the directory 'data' containing the main data;
• dump of the database.

It is important to backup everything simultaneously, otherwise you may introduce some incoherences. It is recommended to perform these operations when no user is connected and when no automatic job is in progress.

To restore the backup, you need to import the dump and to relocate the directory 'data'. You should perform the whole thing when the application is shutdown.

Update

Explanation

The update of an Ametys CMS is done by the following main steps:

• Install the CMS and SITE applications in the new version
• Copy the previous configuration files and data embedded into the new applications

It may be necessary to perform some additional instructions communicated by the provider to update your application: SQL scripts for example. The set-up of a new instance of the CMS (without data) is done immediately with the most recent version and does not required to perform every updates.

Start/ restart

The start/stop and restart processes depends on your installation and your servlet engine.
For example on tomcat call the startup and shutdown scripts in the bin directory.

Some times Tomcat does not shutdown correctly. Please ensure after a few seconds that the tomcat is really stopped by watching processes.

Logs

Applicative logs

The functional errors are generally contained into the applicative logs.

These logs are configured through the file WEB-INF/log4j.xml and stored into the directory WEB-INF/logs (see the website of log4j for more details).

These logs can be downloaded directly on the administrator area (see the manual of the Administrator Area CMS).

System logs

The errors of Apache Tomcat are stored into the logs directory of Tomcat/logs. The file catalina.out contains the informations of the console (particularly the startup informations. Tomcat use log4j).

These logs should be monitored and deleted frequently to avoid space disk problems.

System resources

The CMS and the SITE are some JAVA web applications.

Processor

Excepted on particular projects, the CMS does not require a lot of CPU but it will gain to used multiple processors and multi-heart.

Memory

The CMS is memory greedy depending on the number of users (should be between 512MB and 1GB for many users).

The SITE is not greedy when it is mainly static: in this case Tomcat is used only for the search engine or others dynamic pages.

The Java memory usage in specific.
During the launch with the options -Xms and -Xmx you are specifying the minimal and maximal memory allocated. The SUN JVM takes the minimal space then each time it is necessary it increases the space with a limitation to the maximal size, nevertheless it will never gives back the memory to the system: so it is important to consider this memory not sharable. If you want to know the memory really used by the JVM, you can get it in the Administrator area.

If you get an OutOfMemory Exception provided by Java, note that it can comes from 2 types of memory:

• Internal memory for loading allocated classes with the option maxPermSize. It depends on the number of libraries (jar files) and java classes loaded. More you use applications in a Tomcat, more you would need to increase this memory. It is common to use 128 to 192 Mo.
• Program memory (the one that we usually discuss). It is common to use 512Mo to 2Go. Java does not know how to manage more than 3Go on 32 bits machines. Check the SUN documentation for more details. Each user doing a request to the server requires memory (depending on the kind of requests): so it is impossible to predicate the amount needed, only empiric experiences allow you to estimate the size. For example, 50 small requests may use less memory than 10 big ones. It is possible to modify the number of requests allowed simultaneously on Tomcat to avoid any problems; the others coming users would get a message like : "Server busy".

Disk space

The disk space used by the whole system is difficult to forecast. It is made by:

• The components of the system (Tomcat, Apache...);
• The applications (about 70Mo) by versions. Thus if you perform 5 updates you are going to use 70*5*2 (size of the application * number of updates * (CMS + SITE)) plus the downloaded zip files. This can takes some spaces. The old versions may be archived on another location;
• The JCR content database is greedy in space. It stores every successive versions of every content so it will always grow. A regular website can easily take 100Mo only with the texts (so without the pictures and the attachments) for only one version of the content. After the first months of usage (that are the most intensive) it is easy to reach 500Mo. The size of the disk should be extensible. If the project manage also videos, it should be taken into account to forecast the space.