CYOU -‐ Installation

Transcription

Inmediats / CYOU / Installation
Type de document :
Document technique
Auteurs
Julien BRETEAU
Stéphane ETHEVE
Installation CYOU
CYOU -‐ I nstallation Document technique d’installation et d’exploitation de CYOU 1 de 45
Version 002
CS_inmediats_CYOU_doc_techinque_2013_09_05_002.docx
TABLE DES MATIERES
1 1.1 1.1.2 1.1.3 1.2.2
1.4 1.5 2 2.1 2.2 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4 4.1 4.3 - IHM
SERVEUR
IHM
MOBILIER ACCUEIL
ARCHITECTURE
PLAN ARCHITECTURE RESEAU
2- SCHEMA DE L'INFORMATION
2.2.3 2.2.1
CAS 1 : ACCUEIL NUMERIQUE / EXPOSITION IN SITU
2.2.2
CAS 2 : MOBILE
CAS 3 : INTERNET
INSTALLATION
OS
INSTALLATION DES PAQUETS
CONFIGURER LE SYSTEME
3.3.3 3.3.4 3.3.5 3.3.6 3.3.1
HOST
3.3.2
LES SOURCES DU PROJET
APACHE
PHP
REDEMARRER APACHE
MYSQL
CONFIGURER LE PROJET
3.4.3 3.4.4 3.4.1
ACCES A LA BDD
3.4.2
PROTEGER L'API AVEC UN LOGIN/MOT DE PASSE
LES DROITS SUR LE REPERTOIRE
LES CRON
5- INITIALISATION DU PROJET
3.5.3 3.5.1
VARIABLES ENVIRONNEMENT
3.5.2
EXECUTION DES TACHES
CREATION DES REPERTOIRES VISITEUR ET INTERACTIF
TESTER LE BON FONCTIONNEMENT DU PROJET
API JS
3.7.2
INSTALLATION
TESTS FONCTIONNELS
WEBSERVICES
3.8.3 3.8.1
CONFIGURATION DU SERVEUR POUR LES NOTIFICATIONS WEBSOCKETS
3.8.2
INSTALLATION WEBSERVICES
SYNCHRONISATION DES FICHIERS
EXPLOITATION
BACK OFFICE
FONCTIONS DU BACK OFFICE
CREATION D’UN MULTIMEDIA
REGLES NOTIFICATION
4.3.1
4.3.2
2 de 45
4
CONSOMMABLES
4.1.1
4.2 4 5 5 5 6 6 7 8 8 9 9 10 11 13 13 13 13 13 13 14 15 15 16 16 16 16 17 17 18 18 19 19 19 20 20 20 21 21 23 29 30 30 30 33 33 33 33 4
- SERVEUR LOCAL
RESEAU
3.7.1
3.8 - SERVEUR GENERAL
SOFTWARE
1.2.1
1.3 4 HARDWARE
1.1.1
1.2 4 PREREQUIS
GETENTITY
SENDNOTIFICATION
Version 002
4.3.5 4.3.6 4.3.7 4.3.8 4.3.9 4.3.3
CREATEVISITEURMEDAILLE
4.3.4
SENDMAIL
4.3.11 4.3.10
4.4 4.5 4.6 4.7 5 5.1 5.2 3 de 45
35
DATE
VARDUMP
ISBESTSCOREINTERACTIF
ISVISITEURBESTSCOREINTERACTIF
NBLOGVISITEEXPOSITION
GETTOTALSCORE
GETTOTALSCOREBYTYPOLOGIEANDVISITEUR
PREPARATION DE NAVINUM PROFIL
CYOU SUR LE WEB : SSO
CONFIGURER DRUPAL POUR SE CONNECTER AU SSO
4.6.3 4.6.4 4.6.5 35 35 35 35 35 35 36 36 36 37 37 37 42 42 43 44 45 45 45 34
4.6.1
INSTALLATION DU PLUGIN DRUPAL
4.6.2
PARAMETRAGE DU PLUGIN DANS LE BO
CONFIGURER LES DROITS
OBTENIR SES CLES D'AUTHENTIFICATION (EXEMPLE DRUPAL)
FONCTIONNEMENT
AJOUT D'UN CLIENT SSO DANS LE BACKOFFICE SERVEUR
MAINTENANCE
CORRECTIVE
REMONTE ET TRAITEMENTS DES ERREURS
Version 002
1 PREREQUIS
1.1
HARDWARE
L'infrastructure CYOU est composée d’un ensemble de matériels indispensables à son bon
fonctionnement.
1.1.1
- SERVEUR GENERAL
Un serveur est requis pour exécuter l’ensemble des fonctionnalités de CYOU sur internet, ainsi que
pour stocker l’ensemble des informations des visiteurs. Ce serveur doit être accessible de l’extérieur,
afin de permettre toutes interfaçages éventuels avec d’autres outils (sites internet, système
d’informations…). Il est le coeur du dispositif, le master de la synchronisation.
Configuration minimale à prévoir :
- 2 CPU 2Ghz
- 16Go de ram
- Contrôleur RAID
- 2 x Disque Dur de 500Go (pour permettre la redondance)
A titre informatif, un serveur dédié chez OVH à configuration supérieur, coûte environ 50€ HT/mois.
1.1.2
- SERVEUR LOCAL
Un serveur “local” est requis pour exécuter l’ensemble des fonctionnalités de CYOU au travers des
différentes expositions, ainsi que pour stocker l’ensemble des informations des visiteurs. De plus, ce
serveur peut également être utilisé comme serveur DHCP/DNS, et doit avoir une connexion internet
pour permettre la synchronisation bi-directionnelle de la base de données avec le serveur général. Il
est “esclave” dans le protocole de synchronisation.
Configuration minimale à prévoir :
- 2 CPU 2Ghz
- 16Go de ram
- Contrôleur RAID
- 2 x Disque Dur de 500Go (pour permettre la redondance)
- 2 x Carte Gigabit Ethernet (Lan et Wan)
A titre informatif, un serveur rackable chez DELL à configuration supérieur, coûte environ 1400€ HT.
1.1.3
- IHM
CYou permet à ses utilisateurs, d’intéragir avec des interfaces multimédia au travers des cartes RFID.
Tous matériels reliés à CYOU doit donc être munis :
- d’un lecteur RFID (type 13,56Hz)
- d’une carte réseau (ethernet ou wifi)
4 de 45
Version 002
Cap Sciences a fait le choix d’utiliser pour ses expositions, des tablettes numériques de type Nexus
10. Cette dernière regroupe l’ensemble des prérequis pour la communication avec CYou sans ajout
de matériel/développement supplémentaire (lecteur NFC natif + wifi).
A titre informatif, une Nexus 10 coûte à ce jour, dans sa version 16Go, 399€ TTC, hors frais de
livraison, sur Google Play exclusivement.
1.2
SOFTWARE
L’ensemble des solutions software utilisées pour mettre en place CYOU est de type Open Source.
Aucun coût de licence n’est à prévoir (sauf pour Surelock, qui est un parti pris par Cap Sciences).
1.2.1
SERVEUR
Pour l'installation de CYou, deux possibilités pour le choix de l’OS des serveurs :
- Debian (noyau v3.2)
- Ubuntu (noyau v3.5)
CYOU fonctionne avec le Framework Symfony 2.
Aussi, plusieurs packets sont à installer :
apache2 mysql-server phpmyadmin php5-cli php5-curl php5-gd php5-mcrypt php5-memcache
php5-mysql memcached subversion pv ntp curl libapache2-mod-php5 php5-dev gcc patch
make diff libreadline-dev libncurses5-dev php-pear git pkg-config php5-dev php-pear make
php5-curl php5-suhosin redis-server libevent-dev openssh unison
La version php doit être en php5.3
1.2.2
IHM
Concernant les tablettes, nous utilisons actuellement l’OS Android en version 4.2. L’ensemble des
développements actuellement réalisés pour le centre est basé sur cette version stable de l’OS.
Cap Sciences à intégrer des logiciels supplémentaires afin de faciliter la maintenance du parc des
tablettes.
5 de 45
-
SSHDroid : Utilisation du protocole SSH afin de se connecter à distance aux
différents périphériques (facilitation de la maintenance) de manière sécurisée.
-
SURELOCK : Logiciel de paramétrage de la tablette permettant de donner des droits
particuliers d’utilisation (bridage de l’environnement utilisateur). Ce logiciel nécessite le root de
la tablette. A titre informatif, 50 licences coutent environ 999$.
Version 002
1.3
RESEAU
Afin de relier les différentes bornes interactives à CYOU, un LAN doit être mis en place. Ce LAN doit
être accessible via Ethernet (filaire) et wifi. En fonction de l’espace à couvrir, du nombre de bornes
interactives, et du nombre de visiteurs, le centre de culture devra adapter ou mettre en place des
bornes wifi permettant la connexion de la totalité des bornes, sur l’ensemble de l’espace disponible
au public.
A titre informatif, un point d’accès répondant aux attentes coutent entre 350€ HT et 600€ HT (à
multiplier en fonction de la couverture réseau).
Un serveur DNS, DHCP et NTP, dédié à la solution CYOU, facilitera au maximum la maintenance de
la solution et la régularisation de l’horodatage des données.
Une connexion internet est nécessaire pour la synchronisation des serveurs. La bande passante
utilisée varie en fonction de la taille de la base de données et de la fréquence des synchronisations. Il
est cependant conseillé d’avoir une connexion symétrique (SDSL) pour faciliter le transfert des dumps
par le net.
Le serveur CYOU a besoin également de cinq sous domaines :
● navinum2.yourdomain.net
● api2.yourdomain.net
● navinum-sync.yourdomain.net
● websocket.yourdomain.net
● sso.yourdomain.net
/!\ Remplacer yourdomain.net par votre nom de domaine
1.4
CONSOMMABLES
La relation entre les multimédias et les données du visiteur se fait grâce à l’utilisation de puces RFID.
Une puce est délivrée à chaque visiteur lors de sa venue. Ainsi, prévoir au minimum, une flotte de
badges correspondant à deux fois la fréquentation journalière.
Une puce RFID :
- Est la carte d'identité correspondant à un compte CYOU; elle est personnalisée et personnalisable
au compte.
- Elle donne accès ou non à certains espaces d’exposition (contrôle d’accès : portique) – pour
information, sera développé ultérieurement.
- Elle est délivrée systématiquement à chaque visiteur CYOU ou simple visiteur qui doit la restituer à
l'issue de la visite.
6 de 45
Version 002
- Elle est utilisée dans les différentes expositions d'un même lieu. (Trans-expo).
- Elle ne correspond à aucun profil ; elle peut être pré-profilée en amont par l'animateur (pour un
mode groupe par exemple).
- Délivrée à un visiteur individuel, elle est associée à un compte CYOU/anonyme. Elle est dissociée
de la visite à la fin de la journée (processus côté serveur).
A titre informatif, Cap Sciences a choisi des cartes personnalisées, qui coutent 1,70€/pièces. D’autres
modèles existent avec de variation de prix.
1.5
MOBILIER ACCUEIL
Accueil numérique : L’accueil numérique est un espace dédié à la l’identification du visiteur et de
l’association de ce dernier avec la carte. Cet espace doit pouvoir accueillir un nombre de personnes
importantes et gérer les flux correctement.
Présentoir des badges : Permettre la délivrance des badges de manière individuelle près de
l’accueil numérique afin de garder un système indépendant de la billetterie.
Module de restitution : Permettre au visiteur de restituer son badge de manière rapide. Attention ce
mobilier doit être visible auprès des public afin d’éviter les pertes importantes des badges.
7 de 45
Version 002
2 ARCHITECTURE
2.1
8 de 45
PLAN ARCHITECTURE RESEAU
Version 002
2.2
2- SCHEMA DE L'INFORMATION
2.2.1
CAS 1 : ACCUEIL NUMERIQUE / EXPOSITION IN SITU
1-Le visiteur badge à l’aide d’une carte RFID
a. Le lecteur RFID de la tablette lit l’ID de la puce
2- La couche native réceptionne l’ID du badge RFID venant du lecteur
2Bis – À partir du moment où un visiteur a badgé, la couche native est en permanence à l’écoute
du websocket Navinum.
a. Réceptions des notifications
3- Appels API
a. La couche native envoie l’ID de la puce RFID à Navinum (API)
b. L’API renvoie les informations nécessaires à l’application
i.
Eléments de profiles
ii. Scores, résultats
4- Fonctionnement de l’API
a. Requêtes SQL à la BDD Navinum
b. Formatage des résultats
5- API JS : communication entre l’intéractif et Navinum (via l’application native)
a. La couche native renvoie automatiquement les informations nécessaires à l’interactif
(HTML5)
i.
Eléments de profiles
b. L’intéractif (HTML5) utilise l’API JS
i.
Création/Modification de profiles
ii. Envoie de log_visites
1. Résultats
2. Scores
iii.
XP (typologie)
iv.
Gain de médailles
9 de 45
Version 002
2.2.2
CAS 2 : MOBILE
1-‐ Le visiteur lance l’application
a. Il est amené à s’authentifier
2-‐ La couche native permet (ou pas) d’utiliser le matériel propre au device mobile
a. APN
2Bis – À partir du moment où le visiteur est authentifié, la couche native est en permanence à l’écoute du websocket Navinum.
b. Réceptions des notifications
3-‐ Appels API
a. La couche native envoie les identifiants d’authentification à Navinum (API)
i. Authentification : true/false
ii. Eléments de profiles
iii. Scores, résultats
4-‐ Fonctionnement de l’API
5-‐ API JS : communication entre l’intéractif et Navinum (via l’application native)
a.
La couche native renvoie automatiquement les informations nécessaires à l’interactif (HTML5)
i. Eléments de profiles
b. L’intéractif (HTML5) utilise l’API JS
i. Modification de profiles
10 de 45
Version 002
ii.
1. Résultats
2. Scores
iii.
iv.
Envoie de log_visites
XP (typologie)
Gain de médailles
2.2.3
CAS 3 : INTERNET
1-‐ Le visiteur accède au site internet de Cap Sciences
a. Il est amené à s’authentifier
2-‐ Le plugin CMS permet (ou pas) d’utiliser le matériel propre aux périphériques de l’utilisateur
a. Webcam
b. Micro
c. APN
2Bis – À partir du moment où le visiteur est authentifié, le plugin CMS est en permanence à l’écoute du websocket Navinum.
d. Réceptions des notifications
3-‐ Appels API
a. Le plugin CMS envoie les identifiants d’authentification à Navinum (API)
i. Authentification : true/false
ii. Eléments de profiles
iii. Scores, résultats
4-‐ Fonctionnement de l’API
11 de 45
Version 002
5-‐ API JS : communication entre l’intéractif et Navinum (via le plugin CMS)
a. Le plugin CMS renvoie automatiquement les informations nécessaires à l’interactif (HTML5)
i. Eléments de profiles
b. L’intéractif (HTML5) utilise l’API JS du plugin CMS
i. Modification de profiles
ii. Envoie de log_visites
1. Résultats
2. Scores
iii. XP (typologie)
iv. Gain de médailles
12 de 45
Version 002
3 INSTALLATION
3.1
OS
Nous préconisons un OS Linux Debian (voir ubuntu) pour installer Navinum.
3.2
INSTALLATION DES PAQUETS
La première étape est de mettre à jour les sources des paquets, et le serveur.
apt-get update
apt-get upgrade
Puis installer les paquets suivant : apache2 mysql-server php5-cli php5-curl php5-gd php5-mcrypt
php5-memcache php5-mysql memcached subversion pv ntp curl libapache2-mod-php5
apt-get install apache2 mysql-server phpmyadmin php5-cli php5-curl php5-gd php5-mcrypt php5-memcache php5-mysql
memcached subversion pv ntp curl libapache2-mod-php5 php5-dev make php5-curl php5-suhosin redis-server libeventdev openssh unison
Tout au long de l’installation, confirmer et indiquer les mots de passes souhaités.
3.3
CONFIGURER LE SYSTEME
3.3.1
HOST
Editer le fichier hosts (/etc/hosts pour Linux) :
vi /etc/hosts
Et ajouter :
XX.XX.XX.XX websocket.yourdomain.net navinum2.yourdomain.net api2.yourdomain.net
YY.YY.YY.YY navinum-sync.yourdomain.net
/!\ XX est remplacé par l’ip du serveur local
/!\ YY est remplacé par l’ip du serveur général
3.3.2
LES SOURCES DU PROJET
Pour installer les sources de CYou, nous vous proposons 2 solutions : à distance via un dépot svn, ou
en local via une archive de type tgz. 2 types de source :
13 de 45
Version 002
○
tgz
tar -xzvf /root/navinum.tgz /srv
3.3.3
APACHE
/!\ Dans cette partie, remplacer yourdomain par votre nom de domaine.
●
Activer le mod Headers
cd /etc/apache2/mods-available
a2enmod headers
●
Ajouter le fichier navinum2.yourdomain.net dans /etc/apache2/sites-available
vi /etc/apache2/sites-available/navinum2.yourdomain.net
●
Coller la configuration suivante :
<VirtualHost *:80>
ServerName navinum2.yourdomain.net
DocumentRoot "/srv/navinum2/web"
DirectoryIndex index.php
Header set Access-Control-Allow-Origin *
Header set Access-Control-Allow-Methods 'PUT, GET, POST, DELETE, OPTIONS'
Header set Access-Control-Allow-Headers "Content-Type, X-Custom-Header"
<Directory "/srv/navinum2/web">
AllowOverride All
Allow from All
</Directory>
Alias /sf /srv/navinum2/lib/vendor/symfony/data/web/sf
<Directory "/srv/navinum2/lib/vendor/symfony/data/web/sf">
AllowOverride All
Allow from All
</Directory>
Alias /sfFormExtraPlugin /srv/navinum2/plugins/sfFormExtraPlugin/web
<Directory "/srv/navinum2/plugins/sfFormExtraPlugin/web">
AllowOverride All
Allow from All
</Directory>
Alias /sfJqueryReloadedPlugin /srv/navinum2/plugins/sfJqueryReloadedPlugin/web
<Directory "/srv/navinum2/plugins/sfJqueryReloadedPlugin/web">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
●
Ajouter le fichier api2.yourdomain.net dans /etc/apache2/sites-available
vi /etc/apache2/sites-available/api2.yourdomain.net
14 de 45
Version 002
●
<VirtualHost *:80>
ServerName api2.yourdomain.net
DocumentRoot "/srv/navinum2/web/api"
<Directory "/srv/navinum2/web/api">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
●
Rendre disponible la configuration à apache
cd /etc/apache2/sites-available
a2ensite navinum2.yourdomain.net
a2ensite api2.yourdomain.net
3.3.4
●
PHP
editer les php.ini
●
Remplacer la valeur du memory_limit du fihcier CLI par 2048M
vi /etc/php5/cli/php.ini
memory_limit = 2048M
●
Remplacer les valeurs dans le fichier php.ini comme ci dessous
vi /etc/php5/apache2/php.ini
short_open_tag = Off
memory_limit = 512M
max_execution_time = 60
3.3.5
REDEMARRER APACHE
/etc/init.d/apache2 restart
15 de 45
Version 002
3.3.6
MYSQL
Changer la configuration de mysql
●
pour la synchronisation, il est nécessaire de changer le paramètre max_allowed_packet par la
valeur 128M
vi /etc/mysql/my.cnf
max_allowed_packet = 128M
●
Créer une base de données nommée navinum_cs (utf8_general_ci pour l'interclassement)
mysql -hlocalhost -p
CREATE DATABASE `navinum_cs` CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `navinum_cs_test` CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE USER 'navinum'@'localhost' IDENTIFIED BY 'navinum';
GRANT USAGE ON * . * TO 'navinum'@'localhost' IDENTIFIED BY 'navinum' WITH MAX_QUERIES_PER_HOUR 0
MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
GRANT ALL PRIVILEGES ON `navinum_cs` . * TO 'navinum'@'localhost';
GRANT ALL PRIVILEGES ON `navinum_cs_test` . * TO 'navinum'@'localhost';
/!\ Mettre le user et le mot de passe souhaité
3.4
CONFIGURER LE PROJET
3.4.1
ACCES A LA BDD
●
Aller dans le projet
cd /srv/navinum2
●
Copier le fichier config/databases.yml.dist par config/databases.yml
cp config/databases.yml.dist config/databases.yml
●
Copier le fichier config/app.yml.dist par config/app.yml
cp config/app.yml-dist config/app.yml
●
Éditer le fichier et mettre les identifiants de connexion à la BDD
vi config/databases.yml
3.4.2
●
PROTEGER L'API AVEC UN LOGIN/MOT DE PASSE
renommer web/api/htaccess web/api/.htaccess
mv web/api/htaccess web/api/.htaccess
16 de 45
Version 002
●
Editer le fichier, et changer le path AuthUserFile? par /srv/navinum2/web/api/.htpasswd
●
puis dans le répertoire web/api
cd web/api
●
taper la commande suivante
htpasswd -c .htpasswd servervip-api
=> mettre un mot de passe
/!\ Ce mot de passe servira à l’utilisation authentifié de l'api
3.4.3
LES DROITS SUR LE REPERTOIRE
Sur les répertoires sync et backups dans /srv/navinum2
chmod 777 -R sync
chmod 777 -R backups
3.4.4
●
LES CRON
Création d'un fichier pour un ensemble de taches
vi /etc/cron.d/navinum2
●
insérer le contenu suivant :
####################### iRESET RFID ###################
0 0 * * * root /srv/navinum2/symfony servervip:reset-navinum
####################### SYNCHRO ###################
*/15 * * * * root /srv/navinum2/symfony mysql:dump && /srv/navinum2/symfony servervip:sync &&
/srv/navinum2/symfony servervip:syncCheck
17 de 45
Version 002
3.5
5- INITIALISATION DU PROJET
3.5.1
VARIABLES ENVIRONNEMENT
●
copier le fichier app.yml.dist par app.yml dans apps/backend/config et apps/sync/config et
apps/api/config
cp apps/api/config/app.yml.dist apps/api/config/app.yml
cp apps/backend/config/app.yml.dist apps/backend/config/app.yml
cp apps/sync/config/app.yml.dist apps/sync/config/app.yml
●
vérifier les identifiants .htaccess et .htpassword de l'api dans le fichier app.yml dans
apps/api/config
vi apps/api/config/app.yml
=> Vérifier les paramètres pour les envois de mail
=> Vérifier les paramètres pour l'envoi des sms
prod:
service_sms:
allowed: true
username: capsciences
password: BVSbLbOKLDDGLN
api:
3400609
message:
resetPassword: 'Nouveau password %s'
pseudoRetrieval: 'Vos pseudos %s'
dev:
service_sms:
allowed: false
●
editer le fichier app.yml dans apps/backend/config
vi apps/backend/config/app.yml
=> Vérifier que le type est intranet
● editer le fichier app.yml dans apps/sync/config
vi apps/sync/config/app.yml
●
●
18 de 45
dans all -> sync :
○ Nommer le name par le nom de la machine : ex : araignee-srv
○ Vérifier que le type est intranet
○ vérifier que le internet_url est la bonne adresse
○ vérifier que database est le bon nom de la base de données
dans test -> sync :
○ Nommer le name par le nom de la machine : ex : araignee-srv-test
○ Vérifier que le type est intranet
Version 002
○
○
3.5.2
vérifier que le internet_url est la bonne adresse ET QUE LE FICHIER PHP est
sync_test.php
vérifier que database est le bon nom de la base de données AVEC _TEST
EXECUTION DES TACHES
cd /srv/navinum2
php symfony plugin:publish-assets
php symfony project:permissions
## env prod intranet ou internet
php symfony doctrine:build --all --no-confirmation
php symfony doctrine:data-load data/fixtures/base-internet.yml
./symfony cc
3.5.3
CREATION DES REPERTOIRES VISITEUR ET INTERACTIF
./symfony servervip:create-user-media
chmod -R 777 web/interactif
3.6
●
TESTER LE BON FONCTIONNEMENT DU PROJET
Aller dans un navigateur web et taper l'adresse ci-dessous
http://user:[email protected]/api.php/visiteur?guid=abcd
/!\ Remplacer le user et mdp par les identifiants choisis dans le paragraphe “Protéger l'api avec un
login/mot de passe”
●
vérifier que le retour (json) est bien
[]
19 de 45
Version 002
3.7
API JS
3.7.1
INSTALLATION
●
aller dans le répertoire web/api/
cd web/api
●
installer les sources de l'api js
svn co https://projects.clever-age.net/capsciences/servervip/svn/api-js api-js
●
mettre à jour les données de tests
cd /srv/navinum2
php symfony doctrine:build --all --env=test
php symfony doctrine:data-load data/fixtures/test/fixtures.yml --env=test
php symfony cc
3.7.2
TESTS FONCTIONNELS
Les tests fonctionnels de l'api js sont maintenant disponibles sur le serveur via le host de l'api et
testables dans un navigateur web chrome ou firefox avec le plugin firebug
api2.yourdomain.net/api-js/test/test.html
/!\ Remplacer l’url par votre url et votre domaine
Ce répertoire est sécurisé par le htaccess, nécessite donc login et mot de passe.
Attention les fixtures doivent être relancées (remise à jour) pour faire un nouveau test
20 de 45
Version 002
3.8
WEBSERVICES
3.8.1
CONFIGURATION DU SERVEUR POUR LES NOTIFICATIONS WEBSOCKETS
Installer la librairie lua
("Lua is a powerful, fast, light-weight, embeddable scripting language.")
apt-get install gcc patch make diff libreadline-dev libncurses5-dev php-pear
●
créer un fichier dans /root/script.sh
vi /root/script.sh
●
copier le contenu suivant
#!/bin/sh
mkdir /tmp/luaCompile
cd /tmp/luaCompile
rm -Rf ./*
wget http://www.lua.org/ftp/lua-5.1.5.tar.gz
tar -xzf lua-5.1.5.tar.gz
cd lua-5.1.5
patch -p1 << "EOF"
diff -rupN test//src/Makefile lua-5.1.5//src/Makefile
--- test//src/Makefile
2012-02-13 21:41:22.000000000 +0100
+++ lua-5.1.5//src/Makefile
2012-11-01 08:39:24.440378217 +0100
@@ -8,7 +8,7 @@
PLAT= none
CC= gcc
-CFLAGS= -O2 -Wall $(MYCFLAGS)
+CFLAGS= -O2 -Wall -fPIC $(MYCFLAGS)
AR= ar rcu
RANLIB= ranlib
RM= rm -f
EOF
make linux
make install
rm /usr/lib/liblua.a
rm /usr/include/lua/include
rm /usr/include/lua
ln -s /usr/local/lib/liblua.a /usr/lib/liblua.a
ln -s /usr/local/include /usr/include/lua
ln -s /usr/include/lua /usr/include/lua/include
21 de 45
Version 002
●
mettre les droits d'exécution et exécuter
chmod +x /root/script.sh
/root/script.sh
●
Installation lua
pecl install lua
● modifier le fichier config/app.yml et saisir l'addresse du serveur websocket
note :
=> l'addresse doit commencer par tcp,
=> l'addresse doit finir par le port 8084
=> pas de / à la fin
servervip2:
notif_uri: tcp://websocket.yourdomain.net:8084
●
Créer un fichier lua.ini dans /etc/php5/conf.d
vi /etc/php5/conf.d/lua.ini
●
coller le contenu ci-dessous
extension=lua.so
●
redemarrer apache
Verification de l’installation LUA
●
Créé un fichier info.php dans /srv/navinum2/web et y saisir ceci:
<?php phpinfo() ?>
●
●
Puis aller à cette addresse via un navigateur http://navinum2.yourdomain.net/info.php
Vérifier qu'il y a bien les lignes ce-dessous
●
retirer le fichier info.php pour éviter la faille de sécurité
rm web/info.php
22 de 45
Version 002
3.8.2
INSTALLATION WEBSERVICES
Les paquets
●
Lancer l’installation des différents paquets
apt-get install git pkg-config php5-dev php-pear make php5-curl php5-suhosin
●
Installer redis-server
apt-get install redis-server
●
créer le lien symbolique /srv
cd /home
ln -s srv /srv
Configuration Apache
●
Ajouter le fichier websocket.yourdomain.net dans /etc/apache2/sites-available
vi /etc/apache2/sites-available/websocket.yourdomain.net
●
<VirtualHost *:80>
ServerName websocket.yourdomain.net
ServerAlias sso.cap-sciences.net
DocumentRoot "/srv/websocket/web/web"
DirectoryIndex index.php
<Directory "/srv/websocket/web/web">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
●
Activer le fichier apache
cd /etc/apache2/site-available
a2ensite websocket.yourdomain.net
●
Recharger la configuration apache
/etc/init.d/apache2 reload
23 de 45
Version 002
installation d'une bdd mysql
●
Créer une base de données nommée navinum_sf2_cs (utf8_general_ci pour l'interclassement)
mysql -hlocalhost -p
CREATE DATABASE `navinum_sf2_cs` CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `navinum_sf2_cs_test` CHARACTER SET utf8 COLLATE utf8_general_ci;
GRANT USAGE ON * . * TO 'navinum'@'localhost' IDENTIFIED BY 'navinum' WITH MAX_QUERIES_PER_HOUR 0
MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
GRANT ALL PRIVILEGES ON `navinum_sf2_cs` . * TO 'navinum'@'localhost';
GRANT ALL PRIVILEGES ON `navinum_sf2_cs_test` . * TO 'navinum'@'localhost';
Installation de libevent
apt-get install libevent-dev
pecl install libevent-0.0.5
echo "extension=libevent.so" > /etc/php5/cli/conf.d/libevent.ini
Installation de ZeroMq
echo "deb http://backports.debian.org/debian-backports squeeze-backports main" >> /etc/apt/sources.list
apt-get update && apt-get install libzmq-dev
pear channel-discover pear.zero.mq
pecl install pear.zero.mq/zmq-beta
echo "extension=zmq.so" > /etc/php5/cli/conf.d/zmq.ini
echo "extension=zmq.so" > /etc/php5/apache2/conf.d/zmq.ini
Installation de la plateforme
Les sources sont en Symfony2
Nous placerons ici les sources sf2 dans /srv/websocket/web
● récupérer les sources
cd /srv/websocket/web
git clone https://projects.clever-age.net/capsciences/servervip.git .
●
copier le fichier app/config/parameters.yml.dist en app/config/parameters.yml
cp app/config/parameters.yml.dist app/config/parameters.yml
●
●
éditer le fichier app/config/parameters.yml
changer les paramètres suivants (si nécessaire) :
servervip1_url:
http://user:[email protected]/api.php/
/!\ Remplacer le user et mdp par ceux choisis précédemment
Initialisation de la bdd
24 de 45
Version 002
●
changer la config du parameters.yml comme ci-dessous
parameters:
database_driver: pdo_mysql
database_host:
127.0.0.1
database_port:
~
database_name:
navinum_sf2_cs
database_user:
navinum
database_password: navinum
●
créer le fichier /etc/init.d/servervip2-daemon avec le contenu suivant
#!/bin/bash
### BEGIN INIT INFO
# Provides:
servervip2-daemon
# Required-Start: $all
# Required-Stop:
$all
# Default-Start:
2345
# Default-Stop:
016
# Short-Description: starts the servervip2-daemon daemon
# Description:
starts servervip2-daemon using start-stop-daemon
### END INIT INFO
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/srv/websocket/web/app/console
PID=/var/run/servervip2-daemon.pid
NAME="servervip2-daemon"
DESC="Servervip2 Daemon"
DAEMON_OPTS="servervip2:daemon --daemon"
test -x $DAEMON || exit 0
set -e
case "$1" in
start)
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet --pidfile $PID \
--exec $DAEMON -- $DAEMON_OPTS
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
start-stop-daemon --stop --signal INT --pidfile $PID
echo "$NAME."
rm $PID
;;
restart)
echo -n "Restarting $DESC: "
start-stop-daemon --stop --quiet --pidfile $PID
rm $PID
25 de 45
Version 002
sleep 1
start-stop-daemon --start --quiet --pidfile \
$PID --exec $DAEMON -- $DAEMON_OPTS
echo "$NAME."
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart}" >&2
exit 1
;;
esac
exit 0
●
mettre les droits exécutable
chmod +x /etc/init.d/servervip2-daemon
chmod +x /srv/websocket/web/app/console
●
Executer la commande :
update-rc.d servervip2-daemon defaults
●
vérifier le fichier /etc/php5/cli/conf.d/suhosin.ini, la ligne ci dessous doit être décommentée, et
avoir la valeur phar
suhosin.executor.include.whitelist = phar
●
installer la lib sf2
cd /srv/websocket/web
curl -sS https://getcomposer.org/installer | php
php composer.phar install
=> Un répertoire vendor doit être visible
●
Gestion des problèmes d’installation
● un erreur de ce type peut survenir : file could not be downloaded (HTTP/1.0 503
Service Unavailable)
=> relancer la commande php composer.phar install
● ou encore : Could not scan for classes inside
=> supprimer le contenu dans vendor rm -rf vendor/*
●
vider le cache
# nettoyage du cache prod
php app/console cache:clear --env=prod
# nettoyage du cache dev
php app/console cache:clear
26 de 45
Version 002
●
mettre les droits suffisants sur les répertoires suivants
chmod -R 777 /srv/websocket/web/app/cache
chmod -R 777 /srv/websocket/web/app/logs
●
vérifier que le mod_rewrite apache est activé
a2enmod rewrite
●
redémarrer apache :
●
Insérer les tables dans la bdd
php app/console doctrine:schema:update --force
●
Démarrer le service :
/etc/init.d/servervip2-daemon start
Vérifier le bon fonctionnement
●
le moniteur :
http://websocket.yourdomain.net/websockets/monitor
login : admin
mdp : capsciences
En haut à droite de l’écran, il doit être écrit : WS:Connected
Une ligne en surbrillance doit également apparaitre, avec votre IP. Cela veut dire que vous êtes
repéré par le service websocket.
Communiquer avec CYOU
Le serveur CYOU doit pouvoir communiquer avec le serveur websocket, il est nécessaire d'ajouter
des paramètres sur CYOU
● aller dans le répertoire CYOU
cd /srv/navinum2/
27 de 45
Version 002
●
éditer le fichier app.yml
vi config/app.yml
●
ajouter ou modifier les valeurs suivantes :
servervip2:
notif_uri: tcp://127.0.0.1:8084
Paramétrage insitu avec une tablette
●
l'uri websocket sur l'appli insitu :
ws://websocket.yourdomain.net:8083
●
Lorsque l'appli est connectée, une ligne dans le monitor doit apparaître avec l'adresse mac de
la tablette
○
○
copier l'adresse mac
aller dans le backoffice de vip
■ http://navinum2.yourdomain.net/backend.php
■ menu flotte : une flotte doit être déclarée
■ dans le menu périphérique : ajouter un périphérique et coller d'adresse mac
Ajouter un cron
Cette tache permet de supprimer du moniteur les périphériques qui ne sont plus connectés au
websocket de manière automatique et instantannée
● éditer le fichier de cron navinum
vi /etc/cron.d/navinum2
28 de 45
●
insérer le contenu suivant :
•
* * * * root php /srv/web/servervip2/app/console servervip2:websocket:keepalive --env=prod > /dev/null
Version 002
3.8.3
SYNCHRONISATION DES FICHIERS
L'installation de unison est requis. Unison permet une synchro bidirectionnelle. L'installation se fera
sur le serveur intranet.http://doc.ubuntu-fr.org/unison
Prérequis
●
●
avoir un client ssh sur le serveur intranet
créer une clé publique ssh sur le serveur ssh en ligne
○ il est préférable de créer un utilisateur dédié
○ documentation sur la création d'une clé publique
installer unison
apt-get install unison
paramètrage
●
créer un fichier dans le répertoire de l'utilisateur
nano ~/.unison/default.prf
●
ajouter et modifier les lignes suivantes
# Répertoire distant
root = ssh://navinum-sync.yourdomain.net/srv/navinum2/web
# Répertoire local
root = /srv/navinum2/web
#puis les sous-répertoires
path=visiteur
path=interactif
path=medaille
path=exposition
Note : nous avons à synchroniser 4 répertoires
● visiteur
● interactif
● medaille
● exposition
Cron
Commande à exécuter ou à ajouter dans le cron
##########UNISON SYNCHRO DOSSIER INTERACTIF ET VISITEUR ###############
1 * * * * root unison -force=newer -times=true -auto=true -batch=true
29 de 45
Version 002
4 EXPLOITATION
4.1
BACK OFFICE
Le back-office est l’espace permettant de configurer l’ensemble des expositions reliés à Navinum et
visualiser les activités des visiteurs.
4.1.1
FONCTIONS DU BACK OFFICE
Accéder aux écrans de gestion des informations requiert un identifiant associé à des droits
d'organisateur ou médiateur. Ces comptes spéciaux sont créés par l'administrateur lors du
déploiement d'un serveur Navinum. Il est composé de sept rubriques permettant le paramétrage et la
visualisation des données par vues.
Vip : Expositions, parcours, interactifs.
Afin de créer une exposition connectée à Navinum, l’organisateur doit créer des interactifs qui seront
intégrés à un ou plusieurs parcours qui seront eux mêmes rattachés à une exposition. Pour chacune
des actions, des vues sont exposés afin d’avoir un tableau de bord récapitulatif et permettre une
gestion simple et rapide. Les actions possibles pour chaque sous rubriques sont :
- Tri de la liste sur les champs affichés.
- Création d'un nouvel enregistrement.
- Création d'une copie d'une Exposition (même Parcours que...).
- Édition d'un enregistrement.
- Suppression d'un enregistrement (avertissement des impacts de la suppression).
Chaque nouvel enregistrement (interactifs, parcours, expositions) comporte un nombre de champs à
renseigner dont certains obligatoires. Le système de paramétrage d’un parcours et d’une exposition
s’effectue en cascade.
L'export des vues au format CSV est prévu et paramétrable afin de faciliter l’exploitation pour les
organisateurs.
30 de 45
Version 002
Visiteur : Visiteurs, besoins visiteurs
Suivre les processus d’enregistrement des visiteurs ainsi que l’ensemble des données renseignées
lors de leur inscription/modification de compte. Les actions possibles pour chaque sous rubriques
sont :
Cette rubrique permet également de définir les besoins visiteurs pour les multimédia. Par exemple, si
un multimédia à besoin de la date de naissance du visiteur pour effectuer un traitement sur cette
donnée, ce paramètre sera demandé au visiteur avant de pouvoir utiliser/manipuler le multimédia.
L'export des vues au format CSV est prévu et paramétrable afin de faciliter l’exploitation pour les
organisateurs.
Gratification : XP, Typologie, Type de médaille, Médaille, Médaille visiteurs
Paramétrer les systèmes de gratification pour les visiteurs. Cette rubrique permet de définir les règles
de gamifications. Les actions possibles pour chaque sous rubriques sont :
RFID : RFID, Groupe RFID, Groupe Visiteur RFID
Gérer la flotte des badges ainsi que leurs paramétrages (rendre actif, remise à zéro, type de badges
(admin, visiteur, animateur). Les actions possibles pour chaque sous rubriques sont :
L'import en masse des GUID des badges au format CSV est prévu.
31 de 45
Version 002
Flotte et périphérique
Gérer la flotte de périphériques. Cette rubrique permet de visualiser rapidement les tablettes
disponible pour une exposition ainsi que l’interactif embarqué sur cette dernière. Des informations
réseaux sont également disponible afin de pouvoir prendre rapidement la main à distance (cf
$software IHM et $paramétrage insitu avec une tablette). Les actions possibles pour chaque sous
rubriques sont :
Paramètres : Contexte, Organisateur, Csp, Evenements, Langue, Utilisateurs, Préférences Médias,
Log synchro, template mail, règles de notifications
Ce sont l’ensemble des données nécessaires au paramétrage d’une exposition raccordée à Navinum.
Celà comprend les besoins de paramétrages des rubriques précédentes. Les actions possibles pour
chaque sous rubriques sont :
Vues visites, log-visites
Ce sont l’ensemble des données enregistrées par Navinum liée à l’activité des visiteurs. Aucunes
actions n’est possibles, seul un mode de consultation est disponible.
32 de 45
Version 002
4.2
CREATION D’UN MULTIMEDIA
La création d’un multimédia raccordé à Navinum intègre des prérequis afin de communiquer avec la
base de données. Pour ce faire, un ensemble d’API est fournie pour améliorer la communication
entre les instances. Un multimédia doit au minimum réceptionner les données transmises en Json par
les API, nécessaire à l’attributions des données visiteurs en base. Le multimédia doit pouvoir envoyer
selon un formatage précis les données générées par le visiteur.
Pour visualiser l’ensemble des APIs disponibles, veuillez vous référer au document “API”.
4.3
REGLES NOTIFICATION
Les règles de notification, sont un peu comme des déclencheurs d’évènements systèmes, en fonction
de critères paramétrables (cf $Paramètres : règles de notifications). Elles sont à l’écoute des
différentes interactions avec CYOU.
Voici les méthodes existantes à votre disposition :
4.3.1
GETENTITY
Récupère un objet suivant un type (Model en BDD ) et son identifiant.
Arguments :
● type -> string -> Model de donnée
● guid -> string -> identifiant de l'objet recherché
Retour :
● Tableau associatif de l'objet demandé.
4.3.2
SENDNOTIFICATION
Envoi une notification.
Arguments :
● model : détermine le model associé à cette notification.
● dest : indique le(s) destinataire(s) de la notification au serveur. Ce champs n'est pas
retransmis au client. Il peut s'agir d'un tableau de destinataire ou d'une string pour un seul
destinataire. La syntaxe de chaque destinataire est de la forme <scope>:<id>.
Voici la liste des destinataires possibles :
● conn :
● visiteur :
● visite :
● exposition :
● parcours :
● flotte :
● peripherique :
33 de 45
Version 002
● interactif :
Remarque: Lorsque le visiteur est renseigné, la notification sera enregistrée en bdd pour l'historique
● type : il s'agit du type de notification. Le format à respecter est <namespace>:<type>[:soustype]. Les namespaces "core" et "general" sont pris en charge par la librairie standard. Les
autres namespaces sont libres (éventuellement un namespace par applicatif?).
● options : données de la notification. Les champs sont spécifiés par type de notification.
Structure d'une notification
Exemple :
{
"dest": "conn:1358167709",
"type": "notif:general",
"options": {
"message": "Coucou depuis l'interface de monitoring"
}
}
Les Types de notification
core:reset
●
●
Action : réinitialisation du périphérique
options : -
general:message
●
●
Action : affichage d'un message de service (Toast? Alert?)
options :
○ message : contenu du message a afficher (support html?)
general:notif
●
●
4.3.3
Action : affichage d'un message de service (Toast? Alert?)
options :
○ title : titre de la notif
○ message : contenu du message a afficher
○ [image] : optionnelle image
○ [link] : optionnel lien
CREATEVISITEURMEDAILLE
Créé une médaille
Arguments:
● visiteur_id : guid du visiteur
● medaille_id : guid de la médaille
34 de 45
Version 002
4.3.4
SENDMAIL
Envoi d'un email
Arguments:
● dest : destinataire de l'email
● subject : sujet de l'email
● message : corps de l'email
4.3.5
DATE
Format la date d'aujourd'hui suivant un pattern.
Arguments:
● format : le format de la date souhaitée
Retourne:
● Date formatée -> string
4.3.6
VARDUMP
debug method : affiche un debug
Arguments:
● data : string
4.3.7
ISBESTSCOREINTERACTIF
Est ce que le score du logVisite est le score le plus haut de l'interactif .
Arguments:
● entity : tableau de l'enregistrement actuel
Retourne:
● boolean : true ou false
4.3.8
ISVISITEURBESTSCOREINTERACTIF
Est ce que le score du logVisite est le score le plus haut du visiteur pour un interactif .
Arguments:
● entity : tableau de l'enregistrement actuel
Retourne:
● boolean : true ou false
4.3.9
NBLOGVISITEEXPOSITION
Nombre de visites sur une exposition
Arguments:
● exposition_id : identifiant de l'exposition
Retourne:
le nombre de visites
4.3.10 GETTOTALSCORE
Récupère le nombre XP total
35 de 45
Version 002
Retourne :
● le nombre xp total
4.3.11 GETTOTALSCOREBYTYPOLOGIEANDVISITEUR
Récupère le nombre total de xp sur une typologie et un visiteur
Argument :
● typologie_id : identifiant de la typologie
● visiteur_id : identifiant du visiteur
Retourne :
● Le nombre xp du visiteur pour cette typologie.
4.4
PREPARATION DE NAVINUM PROFIL
L’accueil du CCSTI, ou les animateurs de cette structure, peuvent pré-configurer les badges pour
accueillir un groupe de personnes : il faut donc configurer le badge RFID en mode “Groupe”.
Pour ce faire, deux solutions :
Une authentification avec des identifiants pré-configurés en mode groupe. On adapte simplement son
profil à l’accueil numérique en fonction des caractéristiques pertinentes des membres du groupe (âge,
langue, handicap …).
Des badges de type “groupe” (puisqu’un module de gestion de badge doit être créé).
4.5
CYOU SUR LE WEB : SSO
Cyou intègre une interface unique d’authentification : le SSO. Cela simplifie l’interfaçage de différents
outils et permet à l’utilisateur d’avoir une seule et unique authentification.
Le serveur sso est un bundle symfony2 oauth2 qui gère l'authentification et le single sign on.
/!\ Par mesure de sécurité, chaque domaine a des identifiants différents pour se connecter au SSO.
Les identifiants key/secret saisis plus bas dans cette documentation ne sont valables que pour le
domaine http://drupalcapsciences.local
Cette documentation est basée sur l’utilisation d’un CMS Drupal V7.
36 de 45
Version 002
4.6
CONFIGURER DRUPAL POUR SE CONNECTER AU SSO
4.6.1
INSTALLATION DU PLUGIN DRUPAL
Pour installer le plugin drupal, nous utiliserons la commande drush
● installer les plugins oauth oauth2 et OAuth Connector avec drush qui gérera les dépendances
qui vont avec (Connector, Http Client, Chaos tools)
drush
drush
drush
drush
4.6.2
dl oauth oauth2 oauthconnector
dl http_client
en oauthconnector
en oauth_common_providerui
PARAMETRAGE DU PLUGIN DANS LE BO
●
●
aller dans le menu structure > OAuth Connector
Vérifier que tous les champs existent (onglet Fields)
○ Ajouter les champs ci dessous s'ils n'existent pas dans la liste
●
●
Ajouter un provider (onglet "add provider")
Puis saisir les infos ci-dessous
Etape 1 : général
●
Title
capsciences
●
base Url :
http://sso.cap-sciences.net
●
●
OAuth Consumer Key :
OAuth Consumer Secret
Ces 2 clés vous sont fournis par l'hébergeur du serveur oAuth.
cf: Communiquer les urls pour obtenir les clés d'authentification
Etape 2 : option oAuth2
Une fois que vous avez les clés d'authentification, vous pouvez les saisir comme ci-dessous :
37 de 45
Version 002
Ensuite :
● Dérouler l'option OAuth Consumer Advanced Settings
● Cocher oAuth2
● Signature method
Plain Text
● Authorization endpoint
/oauth/v2/auth
●
38 de 45
Access token endpoint
Version 002
/oauth/v2/token
Etape 3 : section Mapping
User ID
● User ID : Resource :
http://sso.yourdomain.net/sso/whoami
●
guid
User ID : Field :
● User ID : Field to match on user profile
Does not match
39 de 45
Version 002
Etape 4 : EMAIL
● Email : Resources
● Email : Field :
email
● Email : Field to match on user profile
E-mail address
40 de 45
Version 002
Etape 5 : Name
● Name : Resources
● Name : Field :
pseudo_son
● Name : Field to match on user profile
Username
41 de 45
Version 002
Etape 6 : Avatar
Ne rien changer/saisir.
4.6.3
●
●
4.6.4
CONFIGURER LES DROITS
aller dans la gestion des permissions : people > onglets permissions
dans la section connecter, cocher tous les utilisateurs pour "Connect with capsciences"
OBTENIR SES CLES D'AUTHENTIFICATION (EXEMPLE DRUPAL)
L'écran ci-dessous est affiché lorsque vous avez enregistré un nouveau OAuth Connector provider
ou via le menu > Structure > OAuth Connector
42 de 45
Version 002
Pour obtenir vos identifiants (clé/secret), vous devez communiquer :
● votre host url
● le callback url (colonne 3)
Une fois que vous avez vos identifiants, vous pouvez éditer le provider et les ajouter.
4.6.5
●
●
43 de 45
FONCTIONNEMENT
aller sur le drupal
Taper l'url http://[drupalstudio]/connect/oauthconnector_capsciences
Version 002
4.7
44 de 45
AJOUT D'UN CLIENT SSO DANS LE BACKOFFICE SERVEUR
●
aller à l'url http://sso.yourdomain.net/admin/sso/auth
●
cliquer sur add
○ saisir le nom
○ saisir l'url concaténé à l'url callback que vous aura fourni le client. Ceci sera l'url de
retour qui sera interprété par drupal
Version 002
5 MAINTENANCE
5.1
CORRECTIVE
La maintenance exécutée après détection d'une panne et destinée à remettre le système dans un
état dans lequel il peut accomplir une fonction requise
5.2
REMONTE ET TRAITEMENTS DES ERREURS
Afin de garantir une traçabilité des différentes anomalies pouvant être perçues sur le système mis en
production nous disposons d’un outil de ticketing (Redmine). Cela permet entre autre de pouvoir faire
remonter l’information de manière ciblé et rapide tout en ayant une vision statistique des bugs
récurrents au système ou à une fonctionnalité.
45 de 45
Version 002

CYOU -‐ Installation

Transcription

Documents pareils

LE TERRITOIRE NATIONAL carte 1 : le territoire ultramarin : Carte 2

Un été 42

Mission d`Hommes d`Affaires Tunisiens à WUHAN /La CHINE pour

LECON ORTHOGRAPHE 1 L`alphabet phonetique

sujet : la puissance de l`union europeenne et ses limites

INDEX ELEMENTS PRECURSEURS DU PPS (1 degré)

Sur le Parvis – Accueil Visiteur

Instructions pour la collecte de presse

Avis du Conseil d`Etat

dagelijks bestuur