Chapitre 6 Procédures d'exploitation

6.1 Sauvegarde et restauration

La sauvegarde se différencie de l'archivage par le fait que la sauvegarde est une opération effectuée par le service d'exploitation système, et qu'il peut s'intégrer plus facilement dans les procédures mises en place par le service informatique.

Ce chapitre va donc présenter quels sont les éléments de Dynacase à sauvegarder sur un serveur afin de pouvoir remonter ces éléments en cas de perte totale de ce serveur.

6.1.1 Éléments à sauvegarder

Les éléments à sauvegarder sont les suivants :

  • Le répertoire de dynacase-control : il contient les méta-données des contextes ainsi que le code permettant de gérer l'installation et la mise à jour des contextes Dynacase.
  • Pour chaque contextes Dynacase :
    • Le répertoire applicatif du contexte : il contient le code PHP des applications et des familles de documents.
    • La base de données : elle contient les documents et le paramétrage Dynacase.
    • Le ou les vaults : ils contiennent les fichiers insérés dans les documents Dynacase.

6.1.2 Sauvegarde

La sauvegarde se déroulera selon les étapes suivantes:

  1. Sauvegarde de dynacase-control
  2. Mise en mode maintenance du contexte
  3. Sauvegarde de la base de données
  4. Sauvegarde du répertoire applicatif du contexte
  5. Sauvegarde du vault
  6. Sortie du mode maintenance du contexte

6.1.2.1 Sauvegarde de dynacase-control

La sauvegarde de dynacase-control permet de sauvegarder les "méta-données" du contexte (la liste des modules installés dans ce contexte avec leur version).

tar zcf /backup/dynacase-control.tar.gz /var/www/dynacase-control

Si vous avez des archives de contextes et que vous ne souhaitez pas les sauvegarder ou bien vous souhaitez réduire le temps ou la taille de la sauvegarde de dynacase-control, vous pouvez alors exclure ces archives en ne sauvegardant pas les fichiers contenus dans le sous-répertoire archived-contexts :

tar zcf /backup/dynacase-control.tar.gz --exclude archived-contexts/\* /var/www/dynacase-control

Note :

  • La sauvegarde de dynacase-control sauvegarde les méta-données de tous les contextes gérés par ce dynacase-control.

6.1.2.2 Mise en mode maintenance du contexte

Afin d'assurer l'intégrité des données, l'accès au contexte sera bloqué afin que les utilisateurs ne puissent pas modifier les données durant le déroulement de la sauvegarde.

Pour cela il faudra lancer le script ./wstop dans le contexte Dynacase qu'on sauvegarde :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wstop

6.1.2.3 Sauvegarde de la base de données

La sauvegarde de la base de données s'effectue par un dump complet à l'aide de la commande pg_dump :

PGSERVICE=dynacase pg_dump | gzip > /backup/dynacase.pg_dump.gz

6.1.2.4 Sauvegarde du répertoire applicatif du contexte

Le répertoire du contexte contient des fichiers et des répertoires qui peuvent être sauvegardés de manière standard avec des outils comme tar :

tar zcf /backup/dynacase.context.tar.gz /var/www/dynacase

Afin de réduire la durée de sauvegarde vous pouvez exclure les éléments générés dynamiquement.

Ces éléments sont :

  • le répertoire var/cache : sous-répertoire contenant des fichiers de cache.
  • le répertoire var/session : sous-répertoire contenant les sessions.
  • le répertoire var/tmp : sous-répertoire par défaut des fichiers temporaires.
  • le répertoire var/upload : sous-répertoire de stockage des archives importées.

Vous pouvez aussi effectuer une sauvegarde incrémentale des fichiers du répertoire du contexte.

6.1.2.5 Sauvegarde du vault

Si vous avez conservé le vault dans son emplacement par défaut (par défaut dans le sous-répertoire vaultfs à la racine du contexte), alors le vault sera inclut dans la sauvegarde du répertoire applicatif du contexte ci-dessus.

Si vous avez déplacé le vault dans un répertoire distinct (ou que vous l'avez exclu de la sauvegarde du contexte ci-dessus), alors il vous faudra le sauvegarder de manière distincte.

Le vault, comme le répertoire du contexte, peut être sauvegardé avec des outils standards comme tar :

tar zcf /backup/dynacase.vault.tar.gz /data/vault

Une sauvegarde incrémentale est aussi possible pour ce répertoire.

6.1.2.6 Sortie du mode maintenance du contexte

Une fois les éléments sauvegardés, l'accès au contexte peut-être réouvert à l'aide du script wstart -m :

/var/www/dynacase-control/wiff wstart <nomDuContexte>

6.1.3 Restauration

L'ordre de restauration des éléments s'effectue de manière inverse à leur sauvegarde :

  1. Restauration du vault
  2. Restauration du répertoire applicatif du contexte
  3. Restauration de la base de données
  4. Sortie du mode maintenance du contexte
  5. Restauration de dynacase-control

6.1.3.1 Restauration du vault

Restauration des fichiers précédemment archivés :

tar -C / -zxf /backup/dynacase.vault.tar.gz

6.1.3.2 Restauration du répertoire applicatif du contexte

Restauration des fichiers du contexte :

tar -C / -zxf /backup/dynacase.context.tar.gz

6.1.3.3 Restauration de la base de données

Re-créer la base de données avec les paramètres PostgreSQL adéquats :

  • standard_conforming_strings positionné à off
  • DateStyle positionné à ISO, DMY 
ALTER DATABASE dynacase SET standard_conforming_strings = off;
ALTER DATABASE dynacase SET DateStyle = 'ISO, DMY';

Restaurer le dump de la base :

gzip -dc /backup/dynacase.pg_dump.gz | PGSERVICE=dynacase psql

Note : Pour accélerer le chargement des données, vous pouvez consulter la section Bulk data loading pour un exemple de paramétrage de Postgresql.

6.1.3.4 Ré-enregistrement des crontabs

Réenregistrer la crontab de Dynacase :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh.php --api=crontab --cmd=register --file=FREEDOM/freedom.cron

Si votre application possède ses propres crontab, il faudra alors réenregistrer ses crontabs :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh.php --api=crontab --cmd=register --file=MON_APP/ma_crontab.cron

6.1.3.5 Sortie du mode maintenance du contexte

Comme la sauvegarde a été effectué en mode maintenance (wstop), il faut à la fin réouvrir l'accès avec ./wstart -m :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wstart -m

6.1.3.6 Restauration de dynacase-control

tar -C / -zxf /backup/dynacase-control.tar.gz

6.1.4 Ajustement des références à la machine Nouveau

Si la restauration s'effectue sur une machine différente de celle sauvegardée, c'est-à-dire que les chemins d'accès aux fichiers ou que le service de base de données sont différents, il faudra alors modifier les éléments restaurés pour refléter ces changements.

Les éléments qui référencent des chemins ou service de base de données dépendant de la machine sont décrits ci-dessous.

6.1.4.1 Chemin racine du contexte

Le chemin d'accès à la racine du contexte est référencé dans les fichiers suivants :

  • 3.2 R15 Si le contexte utilise dynacase-core >= 3.2.21 :
supervisor/.htaccess
Modifier la directive AuthUserFile "/path/to/context/supervisor/.htpasswd" avec la nouvelle racine du contexte.
.htaccess
Modifier la directive php_value session.save_path "/path/to/context/var/session" avec la nouvelle racine du contexte.
  • 3.2 R14 Si le contexte utilise dynacase-core < 3.2.21 :
supervisor/.htaccess
Modifier la directive AuthUserFile "/path/to/context/supervisor/.htpasswd" avec la nouvelle racine du contexte.
.htaccess
Modifier la directive php_value session.save_path "/path/to/context/var/session" avec la nouvelle racine du contexte.
WHAT/Lib.Prefix.php
Modifier la variable $pubdir = '/path/to/context'; avec la nouvelle racine du contexte.
Paramv CORE_PUBDIR

Modifier la valeur du paramv CORE_PUBDIR avec la nouvelle racine du contexte.

UPDATE paramv SET val ='/path/to/context' WHERE name = 'CORE_PUBDIR'

6.1.4.2 Chemin d'accès au vault

Le chemin d'accès à la racine du vault est référencé en base de données :

Table vaultdiskfsstorage, colonne r_path

Modifier le chemin r_path de la table vaultdiskfsstorage avec le nouvel emplacement du vault.

UPDATE vaultdiskfsstorage SET r_path = '/new/path/to/vaultfs' WHERE r_path = '/old/path/to/vaultfs';

6.1.4.3 Service de la base de donnée

Le nom du service de la base de donnée est référencée dans les fichiers suivants :

  • 3.2 R15 Si le contexte utilise dynacase-core >= 3.2.21 :
config/dbaccess.php
Modifier les variables $pgservice_core = 'pgServiceName'; et $pgservice_freedom = 'pgServiceName'; avec le nouveau nom du service de base de données.
  • 3.2 R14 Si le contexte utilise dynacase-core < 3.2.21 :
config/dbaccess.php
Modifier les variables $pgservice_core = 'pgServiceName'; et $pgservice_freedom = 'pgServiceName'; avec le nouveau nom du service de base de données.

Le nom du service de base de données est aussi référencée dans la base de données elle même :

Paramv CORE_DB, FREEDOM_DB et WEBDAV_DB

Modifier la valeur des paramv CORE_DB, FREEDOM_DB et WEBDAV_DB avec le nouveau nom du service de base de données.

UPDATE paramv SET val = 'service=''' || 'newPgServiceName' || '''' WHERE name IN ('CORE_DB', 'FREEDOM_DB', 'WEBDAV_DB');

6.1.4.4 Nom d'hôte et URL

Le nom d'hôte de la machine peut être référencé dans la base de données :

Paramv CORE_URLINDEX

Si ce paramètre est renseigné, modifier la valeur avec la nouvelle URL.

UPDATE paramv SET val = 'http://newURL/xxx' WHERE name = 'CORE_URLINDEX';
Paramv CORE_OPENURL

Si ce paramètre est renseigné, modifier la valeur avec la nouvelle URL.

UPDATE paramv SET val = 'http://newOpenURL/xxx' WHERE name = 'CORE_OPENURL';
Paramv TE_INDEXURL

Si ce paramètre est renseigné, modifier la valeur avec la nouvelle URL.

UPDATE paramv SET val = 'http://newTeCallbackURL/xxx' WHERE name = 'TE_INDEXURL';

6.2 Check base documentaire

Une liste de vérification de problèmes pouvant se produire sur une installation Dynacase est disponible dans le sous-répertoire supervisor/ du contexte et accessible par l'URL : http://<nomDuServeur>/supervisor/, rubrique DB consistency.

L'interface présente alors une liste de vérification avec un statut :

  •   (vert) si aucune erreur ou incohérence n'a été detecté ;
  •   (rouge) ou   (orange) si des erreurs ou des incohérences ont été detectés.

Liste des vérifications :

main connection db
Vérifie que Postgresql est bien lancé.
dateStyle
Indique le dateStyle utilisé par la base courante.
unreferenced user in group

Vérifie les inconsistances de la table groups vis à vis des utilisateurs. La table groups contient les liens entre les utilisateurs et les groupes, dans certains cas des utilisateurs supprimés peuvent persister dans cette table.

Solution : Supprimer les références erronées

DELETE FROM groups WHERE iduser NOT IN (SELECT id FROM users);
user as group

Par exemple user as group1 users detected as group 25. Peut arriver par un import SQL qui écraserait les utilisateurs. Peut aussi provenir de groupes supprimés qui n'existe plus dans la table users.

Solution : Soit mettre les utilisateurs comme groupe (mettre l'attribut isgroup à Y dans la table users) ou supprimer la référence dans la table groups, puis rafraîchir la table users :

dynacase=# BEGIN;
dynacase=# DELETE FROM groups WHERE idgroup NOT IN (SELECT id FROM users WHERE isgroup='Y');
DELETE 110
dynacase=# COMMIT;
COMMIT

puis :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh --api=freedom_groups
unreference actions

peut arriver lors de la suppression d'applications.

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

unreference parameters

peut arriver lors de la suppression d'applications

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

unreference acl

peut arriver lors de la suppression d'applications

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

unreference permission

peut arriver lors de la suppression d'applications

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

double doc id

Plusieurs documents ont le même identifiant numérique. Peut arriver lors d'importation avec des identificateurs fixe ou lors d'importation avec des familles inexistantes.

Exemple :

1 double id detected  
Array  
(  
    [1178] => 2  
)

Solution : Supprimer l'un des doublons (ou les deux)

Obtenir la liste des identifiants posant problème :

dynacase=# SELECT id,COUNT(*) FROM doc GROUP BY id HAVING COUNT(*) > 1;
  id  | COUNT
------+-------
 1178 |     2

Obtenir le détail des enregistrements posant problème :

dynacase=# SELECT id, title, fromid, locked FROM doc WHERE id = 1178;
  id  |      title      | fromid | locked
------+-----------------+--------+--------
 1178 | Fiche de suivi  |      0 |      0
 1178 | Dossier EI auto |   1169 |      0

Suppression de l'enregistrement incorrect :

dynacase=# DELETE FROM doc WHERE id = 1178 AND fromid = 0;
DELETE 1
double doc name

plusieurs documents ont le même identifiant logique (propriété name)

Solution : Supprimer l'un des doublons (ou les deux)

family inheritance

L'héritage déclaré par la famille ne correspond pas à celle défini dans postgresql. Peut arriver si on change l'héritage d'une famille ou si une famille est créée avant sa famille père.

Exemple :

Family [44232]: fromid = 0, pg inherit=  
Family [44237]: fromid = 0, pg inherit=  
Family [44241]: fromid = 0, pg inherit=  
…

Solution : restaurer l'héritage

Identifier les enregistrement posant problème :

dynacase=# SELECT id, title, fromid, locked, doctype FROM doc WHERE fromid = 0 AND doctype IS NULL;
  id   | title | fromid | locked | doctype
-------+-------+--------+--------+---------
 44232 |       |      0 |      0 |
 44237 |       |      0 |      0 |
 44241 |       |      0 |      0 |
…

Supprimer les enregistrements :

dynacase=# DELETE FROM doc WHERE fromid = 0 AND doctype IS NULL;
DELETE 14

Ou supprimer la table correspondante et lancer :

# /var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh --api=fdl_adoc --docid=<N°famille>
multiple alive revision

Plusieurs révisions sont vivantes pour un même document. Cela peut arriver sur d'ancienne version (< 2.14) lorsque deux tentatives de révisions simultanées sont créés ou si par programmation on force des restauration.

Exemple :

2 multiple alive  
Array (  
    [73780] => jean-raymond.durand@example.net  
    [85480] => Restauration groupe test  
)

Solution : utiliser l'API fixMultipleAliveRevision

Obtenir le détail des enregistrements posant problème :

dynacase=# SELECT id, title FROM docread WHERE id IN (SELECT m AS id FROM (SELECT MIN(id) AS m, initid, COUNT(initid) AS c FROM docread WHERE locked != -1 AND doctype != 'T' GROUP BY docread.initid) AS z WHERE z.c > 1);
  id   |                        title
-------+-----------------------------------------------------
 73780 | jean-raymond.durand@example.net
 85480 | Restauration groupe test
(2 lignes)

API fixMultipleAliveRevision :

# /var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh.php --api=fixMultipleAliveRevision
Fixing mutiple alive revision for (initid='35198', id='85480')
Fixing mutiple alive revision for (initid='56405', id='73780')
attribute type
Vérifie la cohérence entre le type Dynacase d'un attribut et le type SQL de la colonne associée à cet attribut.
attribute orphan

Vérifie la cohérence entre la liste des attributs logiques Dynacase déclarés pour une famille et les colonnes physiques de la table docXXX pour cette famille.

Cette vérification détecte donc les colonnes de la table docXXX d'une famille qui ne correspondent pas, ou plus, à un attribut de cette famille (table docattr).

Solution : appliquer les requêtes SQL données en résultat pour supprimer les colonnes physiques des tables docXXX des familles ayant cette incohérence.

cleanContext cron job execution

Vérifie que la crontab de Dynacase est correctement exécutée en vérifiant qu'il n'existe pas de documents temporaires plus vieux de 1 jour. La présence de documents temporaires plus vieux de 1 jour peut indiquer que la crontab n'est soit pas bien enregistrée, soit que le mécanisme cron général est défaillant.

Solution : vérifier les points indiquer dans le résultat de la vérification.

missing documents in docread

Vérifie s'il y a des documents dans la table doc qui ne sont pas présents dans la table de "cache" docread.

Solution : mettre à jour les documents pour qu'ils soient insérés dans la table de "cache" docread.

dynacase=# UPDATE doc SET id = id WHERE id < 1e9 AND NOT EXISTS (SELECT 1 FROM docread WHERE docread.id = doc.id);
spurious documents in docread

Vérifie s'il y a des documents dans la table de "cache" docread qui n'existent plus dans la table doc.

Solution : supprimer les documents qui n'existent plus dans la table de "cache" docread.

dynacase=# DELETE FROM docread WHERE id < 1e9 AND NOT EXISTS (SELECT 1 FROM doc WHERE docread.id = doc.id);
missing family name

Vérifie s'il existe des familles dont le nom logique n'existe pas dans la table docfam ou qui est mal référencé dans les tables docname et docread.

Exemple :

• 1 unnamed family in docfam:
{17087}

Solution :

Mettre à jour le nom de la famille :

dynacase=# UPDATE docfam SET name = 'NOM_DE_LA_FAMILLE' WHERE id = <id-famille-sans-nom>;

Puis, lancer un cleanContext :

$ ./wsh.php --api=cleanContext

Si dynacase-workspace est installé, les vérifications additionnelles suivantes sont faites :

connection db webdav
Vérifie la disponibilité de la table webdav (si le module WORKSPACE est installé)

Si dynacase-networkuser est installé, les vérifications additionnelles suivantes sont faites :

connection USER LDAP
Vérifie le lien avec le LDAP (si le module NETWORKUSER est installé)

6.3 Miroir local des paquets

Si la machine sur laquelle est installé Dynacase n'a pas accès à Internet, vous pouvez créer un miroir local HTTP/FTP du dépôt de paquets en ligne.

$ mkdir /var/www/mirror
$ cd /var/www/mirror
$ wget --mirror --level=1 --no-parent "http://dynacase.anakeen.com/control/?F=0"                                    # dynacase-control
$ wget --mirror --level=1 --no-parent --http-user=${EEC_USERNAME} --http-password=${EEC_PASSWD} "${EEC_REPO_URL}/?F=0" # Votre dépôt EEC Dynacase
$ wget --mirror --level=1 --no-parent "http://ftp.dynacase.org/third-party/?F=0"                                      # third-party elements

Les paquets du dépôt EEC font référence à des éléments additionnels téléchargés sur http://ftp.dynacase.org (dépôt third-party elements). Pour pouvoir être installés depuis le miroir il faut donc modifier ces paquets pour y inscrire la nouvelle racine pour le téléchargement de ces éléments additionnels.

Pour cela, dynacase-control fournit l'outils sedwebinst.php dans le sous-répertoire utils du répertoire d'installation de dynacase-control.

Cet outils prend 3 arguments qui sont :

  1. l'URL à modifier ;
  2. la nouvelle URL d'accès aux éléments de third-party sur votre miroir ;
  3. et enfin le répertoire d'accès au dépôt des paquets de Dynacase qui contient les fichiers webinst.
$ php /var/www/dynacase-control/utils/sedwebinst.php \
    http://ftp.dynacase.org/third-party \
    http://localhost/mirror/ftp.dynacase.org/third-party \
    /var/www/mirror/eec.anakeen.com/$EEC_USERNAME/

Configurer ensuite votre serveur Web pour servir ce répertoire mirror, et configurer un dépôt pointant sur ce répertoire (voir la gestion des dépôts).

Ajuster ensuite les paramètres wiff-update-host et wiff-update-path de l'installeur Dynacase-control pour chercher les mises-à-jour de l'installeur sur ce nouveau dépôt (voir la configuration des mises-à-jour de Dynacase Control).

6.4 Exploitation des logs

Les logs de Dynacase sont gérés au moyen de syslog.

Dynacase logue par défaut tous ses messages avec la facilité LOG_LOCAL6, à l'exception des erreurs d'authentification, qui sont journalisées avec la facilité LOG_AUTH (à moins que vous ayiez changé cette valeur au moyen du paramètre applicatif AUTH_LOGFACILITY).

Le formatage des logs suit la règle suivante: [<code>] Dynacase <application> <fonction> <message>, avec :

code
Le code de log, correspondant à la priorité :
  • D pour la priorité DEBUG
  • O pour les appels de fonction deprecated (priorité INFO)
  • I pour la priorité INFO
  • W pour la priorité WARNING
  • E pour la priorité ERROR
  • F pour la priorité ALERT
application
l'application, si définie, sous la forme :application
fonction
la fonction, si définie, sous la forme :fonction

Après chaque exécution de procédures automatiques (cron), des logs sont enregistrés dans le syslog. Ils contiennent le titre et l'id du processus exécuté, ainsi que le statut de l'exécution (0 en cas de succès) et le temps d'exécution de la procédure:

Aug 30 10:18:15 pc-de-test [I] Dynacase:CORE:WELCOME: []  Default Master [1] - : Process FDL IMPCARD [3355] executed in 1.005 seconds

Le même système est en place à chaque exécution de timer (minuteur).

L'api dynacaseDbCleaner produit, elle aussi, des logs. Ces logs sont de la forme:

Aug 27 09:25:55 ubuntu1004server dynacaseDbCleaner(CORE_CLIENT): DELETE 0
Aug 27 09:25:55 ubuntu1004server dynacaseDbCleaner(CORE_CLIENT): Temps : 3,868 ms

Chaque commande sql lancée par le dynacasDbCleaner est enregistrée. Le nom du client (paramétré à la configuration) est affiché à la place de CORE_CLIENT.

6.5 Suppression dépôts de paquets freedom-ecm.org

Les premières versions de Freedom et Dynacase étaient hébergés sur des serveurs du domaine freedom-ecm.org.

Suite au changement de nom, ce domaine n'est plus valide et vous ne devez plus utiliser de dépôts de paquets qui font référence à ce domaine.

Pour supprimer les références à ces anciens dépôts de paquets, vous pouvez soit les supprimer manuellement, soit utiliser le script utils/remove_freedom_ecm_repos.php fourni avec les dernières versions de dynacase-control pour supprimer automatiquement ces dépôts.

Le script fonctionne en mode notification (pour vous informer de la présence de dépôts invalides) ou en mode suppression (pour supprimer les dépôts invalides rencontrés).

Mode notification (mode par défaut) :

# cd /var/www/dynacase-control
# php utils/remove_freedom_ecm_repos.php
* Inspecting repository list...
Found invalid repository 'invalid1' with host 'ftp.freedom-ecm.org'.
Found invalid repository 'invalid2' with host 'ftp.freedom-ecm.org'.
Re-run with '--remove' argument to remove the invalid repositories.

Mode suppression (option --remove) :

# cd /var/www/dynacase-control
# php utils/remove_freedom_ecm_repos.php --remove
* Inspecting repository list...
Found invalid repository 'invalid1' with host 'ftp.freedom-ecm.org'.
Found invalid repository 'invalid2' with host 'ftp.freedom-ecm.org'.
* Deactivating repository 'invalid1' on context 'c1'.
Done.
* Deactivating repository 'invalid1' on context 'c2'.
Done.
* Deactivating repository 'invalid2' on context 'c2'.
Done.
* Deleting repository 'invalid1'.
Done.
* Deleting repository 'invalid2'.
Done.

6.6 Répertoires de fichiers de cache et de fichiers temporaires

Les répertoires de cache et de fichiers temporaires sont localisés dans le sous-répertoire var du contexte Dynacase.

Le sous-répertoire var contient les répertoires suivants :

cache/file/
cache de fichiers générés par les applications Dynacase ;
cache/image/
cache d'images redimensionnées dynamiquement par Dynacase ;
session/
fichiers de session PHP ;
tmp/
fichiers temporaires (valeur par défaut ./var/tmp du paramètre applicatif CORE CORE_TMPDIR et FREEDOM_UPLOADDIR) ;
upload/
répertoire de stockage pour la fonction d'import d'archives.
Source : exploitation.md Dynacase Platform 3.2 | Dynacase Platform Installation & Exploitation, version 3.2 édition 14, © Anakeen Labs <labs@anakeen.com>
×
Publié sous licence CC (http://creativecommons.org/licenses/by-nc-sa/2.0/fr/) par Anakeen [www.anakeen.com]
Attribution Vous devez créditer l'Oeuvre, intégrer un lien vers la licence et indiquer si des modifications ont été effectuées à l'Oeuvre. Vous devez indiquer ces informations par tous les moyens possibles mais vous ne pouvez pas suggérer que l'Offrant vous soutient ou soutient la façon dont vous avez utilisé son Oeuvre.
Pas d’Utilisation Commerciale Vous n'êtes pas autoriser à faire un usage commercial de cette Oeuvre, tout ou partie du matériel la composant.
Partage dans les Mêmes Conditions Dans le cas où vous effectuez un remix, que vous transformez, ou créez à partir du matériel composant l'Oeuvre originale, vous devez diffuser l'Oeuvre modifiée dans les même conditions, c'est à dire avec la même licence avec laquelle l'Oeuvre originale a été diffusée.