4. Operation

  1. Introduction
  2. Target audience
    1. Comments
  3. Data types
    1. Main data (JCR)
    2. Secondary data (SQL)
  4. Backup and restoration
    1. Backup
    2. Catering
  5. Update
  6. Start / Restart
  7. Cover
    1. Cover for tomcat
    2. Site cache
  8. System status check
    1. Check Tomcat
    2. DNS check
  9. Logs
    1. Application logs
    2. System logs
  10. System resources
    1. Processor
    2. Memory
    3. Disk space

 

Introduction

This manual contains information on installation and maintenance operations (backups, updates, etc.) for the CMS Ametys V4. It also contains a number of useful tips.

We recommend that you first read the previous pages of this manual, or theadministration manual for your application, to familiarize yourself with all the concepts described here. Please also read your project's supplementary installation manual, if available, to learn about its specific features: in some cases, some of the information presented here may not be applicable.

This section includes appendices documenting Environment and Data Duplication, and Modifications toURL

Target audience

This manual has been written for people who wish to administer CMS, i.e. carry out maintenance operations such as backups, updates, etc...

Comments

If you need help, or if you'd like to share your suggestions, criticisms or praise, don't hesitate to ask for help on the forums. You can also help us improve this documentation by adding your own comments.

Data types

CMS manages two types of data.

Main data (JCR)

The main data concerns content, metadata, attachments, page organization, workflow and so on. They are managed byAPI JCR 2.0 (JSR 238).
The Apache JackRabbit implementation(http://jackrabbit.apache.org) is used because physical storage can be achieved in different ways: file system, embedded database (DERBY), classic database (MySQL), ...
To find out about all the implementations and how to configure them, you can consult the site of JackRabbit.

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

Default, Ametys uses Derby and the file system, all stored in the directory configured in the data folder of the environment variable AMETYS_CMS_HOME. Ametys also offers the option of using a database to store its main data.

Secondary data (SQL)

Secondary data can be (depending on your CMS configuration):

  • the users
  • user groups
  • rights management
  • ...

They are stored in a SQL database (e.g.MySQL ). The chosen database is visible in the configuration parameters (see CMS administration manual, configuration section).

 

Backup and restoration

Backup

To save data, it is necessary to save all data types simultaneously. The following steps are required:

  • Stop the Tomcat server to ensure data consistency.
  • Dump the various databases used in your application (see application configuration).
  • Create an archive with the contents of the directory specified by the environment variable AMETYS_CMS_HOME and database dumps.
  • Delete old backups to conserve disk space.
  • Restart the server Tomcat.

It is very important that everything is saved simultaneously, otherwise application inconsistencies may arise: it is therefore advisable to perform these operations when no user is logged in and no automatic work is in progress (by switching off the Tomcat server, for example).

You can perform a nightly backup using a CRON task and a script to automate the task.

Catering

To restore data, perform the following steps:

  • Stop the server Tomcat.
  • Unzip the backup file whose name is specified in the parameter.
  • Replace the contents of the directory defined in AMETYS_CMS_HOME by the data in your archive.
  • Import database dumps.
  • Restart the server Tomcat.

It is very important that everything is restored simultaneously, otherwise application inconsistencies may arise: it is therefore advisable to carry out these operations when no user is logged in and no automatic work is in progress (by switching off the Tomcat server, for example).

It is also advisable to make a backup just before the restore, in case the restoration goes badly.

 

Update

To update CMS Ametys , follow these steps:

  • Installation of new versions of CMSSITE and Solr.
  • Stop CMS, Site and Solr services.
  • Change from current version to new version.
  • Restart services.

It may also be necessary to carry out other operations, depending on the update supplier's instructions (please refer to the Update Manual).
Installation of a new instance of CMS (without data) is immediately carried out with the most recent version, and does not require any update.

Before executing an update, it is important to check the available disk space. For a 70 MB application, for example, you need 150 MB of available space, because once the 70 MB file has been downloaded, it will be unzipped to form the application.

Downloaded zips and old versions are kept on disk: if after installing the new version you need to go back to the previous version, you need to shut down the services and switch the symbolic links back to the old directory.

It's rarely necessary to keep more than 2 old versions, so you can delete old directories (and zip files) to save disk space.

 

Start / Restart

If you have followed our installation procedure, you need to use the corresponding services (Apache Tomcat , Apache HTTPD...) for example by running the command "service tomcat start".

Otherwise, the start, stop and restart processes depend on your installation and servlet engine. For example, on Tomcatyou'll probably need to run the startup and shutdown scripts in the bin directory.

Sometimes, the shutdown call is not completed correctly. After a few seconds, check that the server has really stopped, by looking at the processes still running.

Cover

Cover for tomcat

You'll find the JavaScript and CSS files already served.

Empty the tomcat

# Effacer le répertoire work (tomcat doit être arrêté)
rm -rf /opt/tomcat/current/tomcat/work
# Effacer le contenu du répertoire temp (et non le répertoire en lui-même)
rm -rf /opt/tomcat/current/temp/*

Site cache

These are mainly pages generated by the CMS application to be served statically from the SITE application.

Clear site cache (command line)

cd $AMETYS_CMS_HOME
rm -rf cache

Cette opération peut être réalisée depuis l'espace d'administration du back-office (<url backoffice>/_admin)

System status check

Check Tomcat

ps waux | grep tomcat

Several tomcat may be running on the same machine. When the command is returned, you can see how many tomcat are running, as well as their "identity".
This command can be used to ensure that a stopped tomcat has actually stopped.

DNS check

ping <mon_dns>

Si un serveur http est configuré : wget <mon_url> et vérifier que la page a bien été écrite.
Il arrive parfois qu’un serveur ait des problèmes d’accès aux autres machines réseaux, cela permet de vérifier que les serveurs ont bien accès entre eux.

Logs

Application logs

Functional errors are generally contained in application logs. These logs are configured via the WEB-INF/log4j file .xml and stored in the $AMETYS _CMS_HOME/logs directory (see the log4j website for more details).
They can be downloaded directly from the administration area (see the dedicated page in the administration manual for more details: Application logs).

System logs

Apache Tomcat errors are stored in the Tomcat/logs directory. The catalina.out file contains console information (including startup information). Tomcat also uses log4j.
These logs must be monitored and deleted regularly, to avoid wasting disk space.

To prevent the disk from becoming full due to the regular increase in log files (tomcat, CMS...), we recommend deleting unnecessary log files. This operation is available from the cmsadministrator space.

System resources

We advise you to consult page 2. Requirements and recommendations

The CMSSITE and Solr are web applications JAVA.

Processor

Apart from special projects, the CMS doesn't need a lot of CPU, but it can be interesting to use multiple processors and multi-heart.

Memory

The CMS can become memory-hungry depending on the number of users (should be between 4G and 12G for several users).

SITE is not memory-intensive (1G to 2G).

Solr can also be memory-hungry depending on the number of users, especially at launch time when a cache is calculated to be optimal later on. The default configuration is often sufficient (1G, but it may be necessary to increase it to 6G via the environment variable SOLR_HEAP).

At startup, the -Xms and -Xmx options specify the minimum and maximum memory allocated. Sun's JVM takes the minimum space and, whenever necessary, increases the space without exceeding the maximum size; however, it never returns the memory to the system: so it's important to consider that this memory is not shareable. If you want to know how memory is actually used by the JVM, you can look in the administration area ( System status page).

In the case of an OutOfMemoryException returned by Java:

  • program memory (the one we usually talk about). In general, we use 4G to 13G. Each user who makes a request to the server needs memory (which depends on the type of request): it is therefore impossible to predict the amount of space required; only our experience allows us to estimate the size. For example, 50 small requests will certainly use less memory than 10 large ones. It is possible to modify the number of simultaneous requests allowed on Tomcat, in order to solve certain problems. Waiting users will receive a server-busy message.

Example of memory settings

-Xms2G -Xmx6G

Disk space

The disk space used by the entire system is difficult to predict. It consists of :

  • system components (Tomcat, Apache...)
  • of the application (around 250MB per version). So if you implement 5 updates, you'll use 250 * 5 * 2 (application size * number of updates * (cms + site)) + downloaded zip files. This can take up a lot of space. Older versions should be archived elsewhere.
  • the JCR database, which requires a lot of disk space. In fact, it stores all successive versions of all content, so it's constantly growing. A typical website can easily take up 1G with text only (i.e. without images and attachments) for a single version of content. After the 1st months of use (which are the most intensive), it's common to reach 3G or even much more when storing files PDF, videos.... Disk size must therefore be expandable. 
  • indexes for application Solr

 

Back to top

Installation and operation manual