Procédure d'installation de CapInfo 2.5.1 sur RedHat Enterprise v4

1) Avertissement

LES ÉLÉMENTS CITES SONT FOURNIS « EN L’ÉTAT », SANS GARANTIE D’AUCUNE SORTE, EXPRESSE OU IMPLICITE, ET NOTAMMENT, SANS GARANTIE QU’ILS SOIENT COMMERCIALISABLES, QU’ILS NE CONTREVIENNENT PAS A DES DROITS DE PROPRIÉTÉ INTELLECTUELLE, NI GARANTIE D’ADÉQUATION A UN USAGE PARTICULIER QUEL QU’IL SOIT. EN AUCUN CAS LES AUTEURS OU LEURS FOURNISSEURS NE POURRONT ÊTRE TENUS RESPONSABLES DES DOMMAGES QUELS QU’ILS SOIENT QUI POURRAIENT RÉSULTER DE L’UTILISATION OU DE L’IMPOSSIBILITÉ D’UTILISER LES ÉLÉMENTS CITES (NOTAMMENT, ET SANS QUE CETTE LISTE SOIT LIMITATIVE, MANQUE A GAGNER, INTERRUPTION DE L’ACTIVITÉ ET PERTES DE DONNÉES), ET CECI ALORS MÊME QU’ILS AURAIENT ÉTÉ INFORMES DE LA POSSIBILITÉ DE CES DOMMAGES. En outre, les auteurs et leurs fournisseurs ne garantissent pas l’exactitude ni l’exhaustivité des informations, textes, dessins, liens ou tout autre document contenu dans les éléments cités. Les auteurs se réservent par ailleurs le droit, à tout moment et sans préavis, d’apporter des modifications aux produits qui y sont décrits.

Cette documentation est fournie à titre d’exemple et ne garantit pas des risques liés à la connexion d’une machine sur le réseau Internet. Il est du ressort de l’administrateur de mettre en oeuvre toutes les procédures et démarches nécessaires à la protection de son serveur.

Objet : Ce document a pour but de donner la marche à suivre pour faire une installation de WebCT95 sur un environnement RedHat? Entreprise ES 4. Cette documentation vous permettra d'obtenir une plate-forme WebCT95 que vous pourrez mettre en production.

Cette documentation s'adresse à tous les techniciens informatique ayant les bases de l'administration d'un système GNU/Linux.

Table des matières

• Avertissement
• Notes

Architecture matérielle et logique Rôles des serveurs Les points de montage NFS

• Pré-requis et conseils pour l'installation du système

Pré-requis Partitionnement Nommage des serveurs RedHat? Network

• Configuration post-install & Installation des services

Partie Commune à tous le serveurs Configuration de up2date Openssh Serveur Front Mysql Apache Php4 Squid Mod_jk Serveur Applicatif Configuration de Yum pour Java Installation de Java Installation de Tomcat5 Serveur Back Postgresql 8.0.9 Bind Création du squelette des répertoires Montages NFS

• Configuration des services

Serveur Front Mysql Apache Mod_jk Php4 Squid Serveur Applicatif Tomcat Serveur Back Postgresql Bind

• Déploiement de CapInfo?

Décompression de l'archive Création de l’architecture SQL pour WebCT95 Configuration de WebCT95 Redémarrage des services Paramétrage du sitemanager

• Ajustements du système pour Sitemanager

Installation de « xmlstarlet » Création d'une clef SSH pour le sitemanager

• Création du 1er site
• Maintenance du système

Outils de redémarrage du serveur Tomcat Dumps journaliers des bases

Notes

La documentation ci-dessous a été qualifiée pour une installation sur une distribution GNLU/Linux RedHat? Enterprise ES v3. Pour toute autre distribution les chemins et les noms des fichiers systèmes devront être adaptés en conséquence.

WebCT95 a été testé sur * Debian Sarge * Fedora Core 3 * Fedora Core 4 * RedHat? Enterprise ES 3 * RedHat? Enterprise ES 4

Pour l’installation de Debian SARGE : http://www.debian.org

Pour l’installation de Fedora Core 3 : http://fedoralegacy.org

Architecture matérielle et logique

L'architecture de base se compose de 3 serveurs : * Un frontal qui supporte le serveur Web. Appelé FRONT * Un applicatif qui supporte Tomcat. Appelé APPLI * Un serveur de bases de données, Appelé BACK

Un quatrième serveur peut être ajouté pour gérer la géolocalisation.

Afin de mieux appréhender la solution CapInfo?, il est préférable d'en avoir une bonne vision globale.

Préconisations matérielles :

	Front	Appli	Back
Mémoire	1 Go	2 Go	2 Go
Disque	18 Go	18 Go	36 Go
Recommandation		Disques durs rapides

Rôles des serveurs

La machine Back contient les données, c'est à dire le contenu des sites en base, et les fichiers statiques de chaque site (fichiers qu'elle partage via NFS).

La machine Appli fait tourner le produit java WebCT95 et répond donc aux sollicitations de la machine Front. La machine Appli utilise un montage NFS pour accéder aux fichiers et des connexions à la base de données pour traiter les requêtes.

La machine Front reçoit les requêtes http des visiteurs, les passe à Squid qui délivre la page si il l'a dans le cache. Dans le cas contraire Squid repasse la main à Apache, qui demande la page à Tomcat.

Les points de montage NFS

On peut voir sur le schéma deux répertoires de la machine Back montés sur les autres serveur via NFS : * /data/webct Qui est le répertoire dans lequel on trouvera les « assets » (fichier html, images, css, etc..) de chaque site, les scripts d'administrations, phpbb, etc... * /data/archives-phpbb Dans ce répertoire on trouvera les archives des fichiers déposés dans phpbb.

Les répertoires sont exportés avec les droits qu'il faut suivant qu'on ait besoin d'écrire dedans ou pas à partir du serveur qui monte les répertoires.

Pré-requis et conseils pour l'installation du système

Pré-requis

Une RedHat? ES 4 installée de base est requise pour la suite des opérations. Vous trouverez juste après ce paragraphe une liste de conseils et d'impératifs (comme le nom des serveurs). Partitionnement * Serveur Front

La partition qui doit être la plus importante est /var a cause des logs de Apache et du spool de Squid.

* Serveur Applicatif

La partition qui doit être la plus importante est /var a cause des logs de Tomcat

* Serveur Back

sur la machine Back une partition spéciale doit être crée : /data Cette partition doit être la plus grosse du système très loin devant /var (qui ne contiendra que les logs de Postgresql et ceux du système).

/data contiendra, entre autre, l'intégralité des données statiques des sites, les bases de données Postgresql, ainsi que les dumps journaliers de bases de données.

Pour le reste du partitionnement, faites comme à vos habitudes.

Nommage des serveurs

Vous pouvez nommer les 3 serveurs comme vous le désirez, mais bien sûr chacun doit être unique.

Ces noms de serveurs devront être solvable dans les serveurs DNS qui seront configurés sur ces machines, si vous n'avez pas de serveur DNS sur votre réseau, dans celui de la machine Back.

Vos pouvez notez les noms de vos serveurs dans les cases ci-dessous. Nomination des serveurs suivant la plate-forme installée :

	Frontal	Applicatif	Back	Géolocalisation
Nom

Cette documentation ne couvre pas l'installation de la géolocalisation et du module PhpBB, Elle ne couvre pas non plus les statistiques. Ce point étant souvent propre à chaque hébergeur, je vous laisse le soin de mettre en place votre système de statistiques.

Notez bien que le domaine des machines reste libre, afin de mieux les intégrer dans votre réseau local.

RedHat? Network

Des licences valides pour l'accès au RedHat? Network sont indispensables. Pour les machines Appli et Front, vous devez abonnez les serveurs au canal supplémentaire : Red Hat Application Server v. 2 Pour avoir accès aux logiciels en rapport avec Java.

Configuration post-install & Installation des services

Recopier l'intégralité du répertoire de livraison dans /root sur le serveur Back et le serveur Appli.

Partie Commune à tous le serveurs

Configuration de up2date

Etape à effectuer après avoir enregistré vos distributions et vos serveurs auprès du RedHat? Network (voir sur le site de RedHat? : http://www.redhat.com/rhn/) Pour pouvoir faire les mises à jour des kernels via l'interface du RedHat? Network ou même via « up2date -u », éditer le fichier suivant : /etc/sysconfig/rhn/up2date

et remplacez : #pkgSkipList=kernel*;

par : pkgSkipList=

Puis lancez une mise à jour du système via la commande : up2date -u

Openssh

Installer Openssh, via la commande : up2date openssh

Serveur Front

Mysql

Pour installer MySql?, utilisez up2date :

up2date mysql-server

Et lancer le serveur MySql? via la commande : /etc/init.d/mysqld start

Apache

Pour installer Apache, utilisez up2date :

up2date httpd

Php4

Pour installer Php, utilisez up2date :

up2date php php-mysql

Squid

Pour installer Squid, utilisez up2date :

up2date squid

Mod_jk

Installer le connecteur Apache->Tomcat, alias mod_jk, via la commande suivante : up2date mod_jk-ap20

Serveur Applicatif

Partie à ignorer car à ce jour le repository « Jpackage.org » n’est plus actif. Nous gardons le paragraphe car il est possible que Jpackage refasse surface.

Configuration de Yum pour Java

Sur le serveur Front Front et Applicatif, nous avons besoin de divers paquets pour java non-fournis par RedHat?. Pour une installation facile de ces paquets sans se soucier des problèmes de dépendances nous allons utiliser YUM. Vous pouvez télecharger YUM pour RedHat? ES 4 à l’url suivante : http://www.linux.duke.edu/projects/yum/download.ptml

La version validée est la 2.6.x.

Le « repository » à utiliser pour les paquets Java est celui de Jpackage.org

Tout d’abord il faut installer les dépendances nécessaire à YUM. Utiliser up2date pour les installer, en utilisant cette commande : up2date libxml2-python urlgrabber python-sqlite python-elementtree

Une fois le RPM de YUM téléchargé sur les serveurs Front et Applicatif, installez le sur ces 2 serveurs en remplaçant <nom du paquet> par le nom complet du RPM de YUM que vous venez de télécharger : rpm -ivh <nom du paquet>

Éditer le fichier de configuration de Yum « /etc/yum.repos.d/jpackages.repo »

Et ajouter les les paragraphes suivants : [jpackage16-generic] name=JPackage 1.6, generic baseurl=http://sunsite.rediris.es/mirror/jpackage/1.6/generic/free/

[jpackage16-rhel40] name=JPackage 1.6 for Red Hat Enterprise Linux 4 baseurl=http://sunsite.rediris.es/mirror/jpackage/1.6/redhat-el-4.0/free/

Installation de Java

Aller télécharger le RPM du Java JDK 1.5.x de Sun, à l’url suivante : https://sdlc2d.sun.com/ECom/EComActionServlet;jsessionid=E31C712A9488B7FC3A2E8EDD72162027 Et prendre la version : Linux RPM in self-extracting file Installer le programmer « rpmbuild » via la commande : up2date rpmbuild

Installer le package « jpackage-utils » via la commande : yum install jpackage-utils

Pour pouvoir utiliser les dépôts de Jpackage il faut pour cela créer un paquet RPM de Java selon la méthode de Jpackage.

Pour cela, télécharger le SRC.RPM de java sur le site de Jpackage à l’adresse suivante : http://www.jpackage.org/rpm.php?id=3557 (à l’heure ou j’écris ces lignes le paquet s’appelle « java-1.5.0-sun-1.5.0.07-1jpp.nosrc.rpm ») Prendre le fichier du champ « RPM file »

Installer ce fichier via la commande : rpm -ivh java-1...

Télécharger le J2SDK 5.0 sur le site de Sun à l’adresse suivante : http://java.sun.com/javase/downloads/index.jsp Prendre la version : « self-extracting file »

Copier ce fichier dans le répertoire : « /usr/src/redhat/SOURCES »

Et lancer la création des RPMs via la commande : rpmbuild -ba /usr/src/redhat/SPECS/java-1.5.0-sun.spec

Installer les paquets requis pour l’installation du SDK via la commande : up2date unixODBC-devel ttmkfdir chkfontpath XFree86-font-utils Xfree86-xfs

Entrer dans le répertoire où ont été crées les RPMs : cd /usr/src/redhat/RPMS/i586

Enfin, installer les paquets du J2SDK via la commande : rpm -ivh java-1.5.0-sun-*.rpm java-1.5.0-sun-devel-*.rpm java-1.5.0-sun-fonts-*.rpm java-1.5.0-sun-jdbc-*.rpm java-1.5.0-sun-plugin-*.rpm

Puis lancer l’installation en tappant : bash <NOM DU FICHIER>

Et répondre au questions.

En fin d’installation, configurer la variable d’environnement JAVA_HOME en lui donnant pour valeur le chemin d’accès au répertoire contenant le J2SDK. Bien sûr, adapter le chemin suivant la version que vous avez installé. Par exemple, ajouter la ligne suivante à la fin du fichier /etc/profile

export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun-1.5.0.07/

De même dans /root/.bash_profile, compléter la valeur de la variable d’environnement PATH avec le chemin de l’exécutable java, par exemple :

export PATH=$PATH:/usr/lib/jvm/java-1.5.0-sun-1.5.0.07/bin

Faite relire ce fichier par votre Shell via cette commande : source /root/.bash_profile

Installation de Tomcat 5

Utiliser up2date, en tapant la commande suivante : up2date tomcat5

Avant d’installer Tomcat 5 il faut installer « JTA », qu’il faudra mettre en paquet de la même manière que le J2SDK.

Pour cela, télécharger le SRC.RPM de JTA sur le site de Jpackage à l’adresse suivante : http://www.jpackage.org/rpm.php?id=1482 (à l’heure ou j’écris ces lignes le paquet s’appelle « jta-1.0.1-0.b.4jpp.nosrc.rpm ») Prendre le fichier du champ « RPM file »

Installer ce fichier via la commande : rpm -ivh jta-1...

Télécharger le JTA sur le site de Sun à l’adresse suivante : http://java.sun.com/products/jta/ Il faut prendre les 2 fichiers suivants :
=> Class Files
=> JavaDocs

Attention : Bien prendre la même version que votre paquet SRC.RPM de JTA. Exemple, si votre paquet s’appelle « jta-1.0.1-0.b.4jpp.nosrc.rpm », alors prendre la version 1.0.1 B de ces 2 fichiers.

Copier ces 2 fichiers dans le répertoire : « /usr/src/redhat/SOURCES »

Et lancer la création du RPM via la commande : rpmbuild -ba /usr/src/redhat/SPECS/jta.spec

Entrer dans le répertoire où ont été crée les RPMs : cd /usr/src/redhat/RPMS/noarch/

Installer le paquet de JTA via la commande : rpm -ivh jta-*.rpm

Enfin, installer Tomcat 4 via la commande : yum -y install tomcat5 tomcat5-webapps tomcat5-admin-webapps

Serveur Back

Postgresql 8.0.9

Liste des paquets : postgresql, postgresql-server, postgresql-libs, postgersql-jdbc ATTENTION : Ne pas utiliser le Postgresql livré par RedHat? avec la RH ES 4, c’est une version beaucoup trop récente. Pour obtenir une version 8.0.9 de Postgresql pour RH ES 4, allez à l’adresse suivante : http://ftp.uoi.gr/pub/databases/postgresql/binary/v8.0.9/linux/rpms/redhat/rhel-es-4/

Une fois les 4 paquets téléchargés, installez les :

rpm -ivh <paquet 1> <paquet 2> <paquet 3> <paquet 4>

Et lancer le serveur Postgresql via la commande :

/etc/init.d/postgresql start

Bind

Pour installer Bind, utilisez up2date :

up2date bind

A cet instant, on devrait avoir une plate-forme prête avec tous les services. Passons maintenant à la configuration.

Création du squelette des répertoires

Liste des répertoires à créer :

Serveur Front

* Répertoires : ** /wct95 ** /var/cache/backup_mysql

Serveur Applicatif

Répertoires : * /wct95 * /webct95

Serveur Back

Répertoires : * /data/archives-phpbb * /data/backup * /data/backup-dujour * /data/webct * /data/webct/archives-phpbb * /data/webct/conf * /data/webct/conf/httpd * /data/webct/assets/

Liens symbolique à créer : * source : /wct95, destination : /data/webct/

Pour créer un répertoire Utiliser la commande suivante en remplaçant <chemin_du_repertoire> par le répertoire que vous voulez créer : mkdir -p <chemin_du_repertoire>

Pour créer un lien symbolique Utiliser la commande suivante en remplaçant <source> par le répertoire original et <destination> par le nom/emplacement du lien à créer : ln -s <source> <destination>

Montages NFS

Manipulations à effectuer sur le serveur Back Il faut exporter sur les autres serveurs les répertoires qui contiennent des données. Pour cela éditer le fichier « /etc/exports » Et le remplir de la façon suivante, en remplaçant : <IP_FRONT> par l’ip du serveur Front <IP_APPLI> par l’ip du serveur Applicatif <IP_GEOLOC> par l’ip du serveur de Géolocalisation si il y en un.

/data/webct <IP_APPLI>(rw,async,no_root_squash,anonuid=0,anongid=0) /data/webct <IP_FRONT>(ro,async,no_root_squash,anonuid=0,anongid=0) ## ligne suivante uniquement si vous avez un serveur de Geolocalisation ## /data/webct <IP_GEOLOC>(ro,async,no_root_squash,anonuid=0,anongid=0) ########################################################################## /data/archives-phpbb ╗ <IP_FRONT>(rw,async,no_root_squash,anonuid=0,anongid=0)╗ <IP_APPLI>(rw,async,no_root_squash,anonuid=0,anongid=0)

Puis recharger la configuration de NFS, via la commande : exportfs -r

Manipulations à effectuer sur le serveur Front Editer le fichier /etc/fstab Et le remplir de la façon suivante, en remplaçant les <IP_BACK> par l'ip associée au serveur Back. <IP_BACK>:/data/webct /wct95 nfs ro <IP_BACK>:/data/archives-phpbb /wct95/archives-phpbb nfs rw

Puis monter les répertoires en exécutant la commande suivante : mount -a

Manipulations à effectuer sur le serveur Applicatif Editer le fichier « /etc/fstab » Et le remplir de la façon suivante, en remplaçant les <IP_BACK> par l'ip associée au serveur Back. <IP_BACK>:/data/webct /wct95 nfs rw <IP_BACK>:/data/archives-phpbb /wct95/archives-phpbb nfs rw

Puis monter les répertoires en exécutant la commande suivante : mount -a

Configuration des services

Serveur Front

Mysql

Ajouter un mot de passe au compte administrateur « root », mot de passe qu'il faudra donner au script d'administration de webct95 : Sitemanager. Se connecter au serveur mysql via la commande : mysql -u root mysql

Puis ajouter un mot de passe au compte « root » en utilisant la commande suivante tout en remplaçant <MotDePasse> par le mot de passe que vous aurez choisit : update user set Password=PASSWORD('<MotDePasse>') where user='root'; exit;

Apache

Vérifier que le fichier « /etc/httpd/conf/httpd.conf » contient une déclaration « NameVirtualHost » identique à celle ci, si elle n’y est pas, la rajouter :
NameVirtualHost *:80
Et rajouter à la fin de ce même fichier les 2 lignes suivantes :
# Include VirtualHosts
Include /wct95/conf/httpd/*.conf

Nous devons modifier le « charset » par défaut, pour l'adapter aux accents. Dans, le même fichier que précédemment, supprimer la ligne suivante : AddDefaultCharset UTF-8

Et la remplacer par celle ci : AddDefaultCharset ISO-8859-1

Mod_jk

Copier les fichiers d’exemple qui seront modifiés par la suite, via les commandes suivantes (remplacer le numéro de version indiqué dans les lignes de commandes par celui du mod_jk-ap20 que vous avez du installer, vous pouvez l’obtenir en tapant dans un shell : « rpm -q mod_jk-ap20 »): cp /usr/share/doc/mod_jk-ap20-1.2.6/mod_jk.conf.sample /etc/httpd/conf.d/mod_jk.conf cp /usr/share/doc/mod_jk-ap20-1.2.6/workers.properties.sample /etc/httpd/conf.d/workers.properties

Vérifier que le fichier « /etc/httpd/conf.d/mod_jk.conf » contient la ligne suivante :
JkWorkersFile /etc/httpd/conf.d/workers.properties

Dans le fichier « /etc/httpd/conf.d/workers.properties » Vérifier que la variable « workers.tomcat_home » soit bien égale à « /usr/share/tomcat5/ »

A chaque serveur Tomcat est associé un « worker », il est donc nécessaire de déclarer autant de workers que de serveurs Tomcat utilisés sur la plate-forme.

Pour ajouter un worker : Insérer, toujours dans le même fichier, un bloc de définition par serveur Tomcat en faisant un copier/coller du bloc ci-dessous. Remplacer <IP_APPLI> par l’adresse IP de votre serveur Applicatif. Dans le bloc ci-dessous, le nom du worker est : tomcat1

#------ DEFAULT tomcat1 WORKER DEFINITION --------- # # Defining a worker named tomcat and of type ajp13 # Note that the name and the type do not have to match. # worker.tomcat1.port=8009 worker.tomcat1.host=<IP_APPLI> worker.tomcat1.type=ajp13 worker.tomcat1.sticky_session=1 # # Specifies the load balance factor when used with # a load balancing worker. # Note: # ----> lbfactor must be > 0 # ----> Low lbfactor means less work done by the worker. worker.tomcat1.lbfactor=100

Déclarer maintenant le worker qui vient d’être défini dans la liste des worker, en ajoutant « tomcat1 » dans la déclaration « worker.list », comme ci-dessous : worker.list=tomcat1,loadbalancer

Dans la section « loadbalancer » ajouter « tomcat1 » dans la déclaration « worker.loadbalancer.balanced_workers » comme ci-dessous : worker.loadbalancer.balanced_workers=tomcat1

Dans le cas où vous voulez plusieurs serveurs Tomcat, alors il faut répéter cette étape de configuration autant de fois que vous avez de serveurs à rajouter en remplaçant « tomcat1 » par le nom du worker que vous voulez ajouter et <IP_APPLI> par l’adresse IP de cet autre serveur.

Php4

Positionnez les valeurs suivantes dans le fichier /etc/php.ini :

short_open_tag = Off register_globals = On

Squid

Manipulations à effectuer sur le serveur Front Editer le fichier de configuration de Squid « /etc/squid/squid.conf « :

Commentez les lignes suivantes pour tout mettre en cache : acl QUERY urlpath_regex cgi-bin \? no_cache deny QUERY

Ajuster les valeurs suivantes pour mettre le maximum d'objets en mémoire et augmenter la taille maximum des objets mis en mémoire pour augmenter les performances : cache_mem 256 MB maximum_object_size_in_memory 250 KB

Ajuster les valeurs suivantes pour obtenir une méthode de cache plus adaptée : cache_replacement_policy heap GDSF memory_replacement_policy heap GDSF

Ajuster les valeurs suivantes pour augmenter le taille du cache sur le disque, et choisir un meilleur l'algorithme de stockage. cache_dir aufs /var/spool/squid 500 20 256

Pour ne jamais laisser squid dé-cacher une page dans ordre explicite, ajouter la ligne suivante dans le bloc des « refresh_pattern » (AVANT toutes les autres) : refresh_pattern ^{http 144000 75% 144000}

Créer votre access list pour autoriser votre plage d'adresses à se connecter à Squid en ajoutant ce bloc dans la configuration de Squid. Remplacer <RESEAU> par la plage de votre réseau. acl wct95 src <RESEAU>/255.255.255.0 acl PURGE method PURGE http_access allow wct95 http_access allow PURGE wct95

Pour positionner Squid en reverse proxy, ajuster les variables suivantes : httpd_accel_port 80 httpd_accel_host virtual httpd_accel_with_proxy on httpd_accel_uses_host_header on

Passer cette variable à « off », pour ne pas retirer les paramètres des requêtes : strip_query_terms off

Une fois cette configuration finie, relancer Squid via le script d’init : /etc/init.d/squid restart

Serveur Applicatif

Tomcat

_Manipulations à effectuer sur le serveur Applicatif_ Rajouter un contexte pour WebCT95 Dans le fichier « /etc/tomcat5/server.xml », dans la section <Host> du service Tomcat-Standalone, juste au dessus de la ligne : <!-- Tomcat Examples Context --> ajouter le bloc suivant : <Context displayName="WebCT95" path="" docBase="/webct95/" debug="0" reloadable="true" allowLinking="true">

<Logger className="org.apache.catalina.logger.FileLogger" prefix="webct95." suffix=".log" timestamp="true"/>

</Context>

Modifier les tailles mémoire allouées à la machine virtuelle Dans le fichier « /etc/tomcat5/tomcat5.conf », ajouter la ligne : CATALINA_OPTS="-Xms1024m -Xmx1536m -Djava.awt.headless=true" pour définir la mémoire initiale (1 Go) et maximale (1,5 Go) allouée à la JVM. Remplacer également le paramètre LANG : LANG=fr_FR

Serveur Back

Postgresql

Déplacer les données Postresql de « /var/lib/pgsql » dans « /data/pgsql » Pour cela arrêter Postgresql via la commande : /etc/init.d/postgresql stop

Puis exécuter les commandes suivantes : mv /var/lib/pgsql /data/ ln -s /data/pgsql /var/lib/pgsql

Ajuster les paramètres du kernel pour augmenter la « shared memory » que pourra utiliser Postgresql à 256 Mo en entrant les ligne suivante dans /etc/sysctl.conf : kernel.shmall=268435456 kernel.shmmax=268435456

Pour que ces paramètres soient pris en compte immédiatement taper les commandes suivantes : sysctl -w kernel.shmall=268435456 sysctl -w kernel.shmmax=268435456

Ajuster les droits sur les bases Postgresql dans « /var/lib/pgsql/data/pg_hba.conf » : * commenter les ligne déjà présentes ; * intégrer les lignes suivantes et remplacer les <IP_APPLI> par l'ip associée au serveur Applicatif.

local all postgres ident sameuser local all webct95 ident sameuser

host webct95 webct95 <IP_APPLI> 255.255.255.255 md5 host webct95ext webct95 <IP_APPLI> 255.255.255.255 md5

Modifier /var/lib/pgsql/data/postgresql.conf en positionnant les paramètres : listen_addresses = '*' max_connections = 420 shared_buffers = 15000 wal_buffers = 64 #sort_mem = 32000 #vacuum_mem = 32000 checkpoint_segments = 8 effective_cache_size = 1503238553 random_page_cost = 3 log_connections = true log_line_prefix = '%t' log_destination = 'syslog' syslog = 2 # range 0-2 syslog_facility = 'LOCAL0' syslog_ident = 'postgres' stats_start_collector = true stats_reset_on_server_start = true stats_command_string = true stats_row_level = true stats_block_level = true LC_MESSAGES = 'fr_FR.UTF-8' LC_MONETARY = 'fr_FR.UTF-8' LC_NUMERIC = 'fr_FR.UTF-8' LC_TIME = 'fr_FR.UTF-8'

Pour obtenir des logs de Postgresql, il faut modifier la configuration de syslog, éditer le fichier /etc/syslog.conf et ajouter les 2 lignes suivantes : # Postgres local0.* /var/log/postgresql.log

Ensuite recharger la configuration de syslog via : /etc/init.d/syslog reload

puis relancer postgresql via : /etc/init.d/postgresql restart

Bind

Si il y a un serveur DNS sur votre réseau local, alors il n'y a rien à configurer sur le serveur BIND, et vous pouvez même le dé installer. Par contre, avant, il faut vérifier que les noms d'hôtes cours et longs peuvent être résolus sur votre serveur DNS. Si ce n'est pas le cas il faut les définir.

Si il n'y a pas de serveur DNS alors il faudra en déclarer une zone et la remplir.

Tout d'abord, éditer le fichier « /etc/named.conf » et rajouter, si elle n'est pas déjà présente, la ligne suivante : include "/var/named/named.zones";

Éditer le fichier qui répertorie les fichiers de zones : « /var/named/named.zones » Et ajouter le bloc suivant, en changeant « VOTRE_NOM_DE_DOMAINE » par le nom de domaine que vous avez choisi pour votre serveur.

zone "VOTRE_NOM_DE_DOMAINE" {

type master; file "/var/named/zones/VOTRE_NOM_DE_DOMAINE.db";

};

Ensuite, éditer le fichier « /var/named/zones/VOTRE_NOM_DE_DOMAINE.db » Copier/coller le bloc suivant dans le fichier, et remplacer les valeurs en gras comme indiqué ci-dessous : VOTRE_NOM_DE_DOMAINE = le nom de domaine choisi pour votre plate-forme. NOM_MACHINE_BACK = nom cours choisi pour la machine Back IP_MACHINE_BACK = l'adresse ip choisie pour la machine Back NOM_MACHINE_FRONT = nom cours choisi pour la machine Front IP_MACHINE_FRONT = l'adresse ip choisie pour la machine Front ETC..

$TTL 86400

@ IN SOA 172.18.8.207. postmaster.nowhere.org. (

2004092708 ; serial number YYMMDDNN 28800 ; Refresh 7200 ; Retry 864000 ; Expire 86400 ; Min TTL )

NS IP_MACHINE_BACK.

MX 10 IP_MACHINE_BACK.

$ORIGIN VOTRE_NOM_DE_DOMAINE. NOM_MACHINE_FRONT IN A IP_MACHINE_FRONT NOM_MACHINE_APPLI IN A IP_MACHINE_APPLI NOM_MACHINE_BACK IN A IP_MACHINE_BACK NOM_MACHINE_GEOLOC IN A IP_MACHINE_GEOLOC

Ensuite démarrer le serveur de nom via la commande : service named start

Une fois le serveur lancé, il va falloir modifier la configuration de tous les serveurs pour qu'ils interrogent ce serveur DNS à chaque requête. Pour cela, sur chaque serveur, éditer le fichier « /etc/resolv.conf », et remplacer sont contenu par le suivant : search VOTRE_NOM_DE_DOMAINE nameserver IP_MACHINE_BACK En remplaçant VOTRE_NOM_DE_DOMAINE par le nom de domaine choisi et IP_MACHINE_BACK par l'adresse ip de la machine Back.

Maintenant il faut vérifier que tous les noms sont bien ré solvables sur leur forme courte et longue. Pour cela, il faut utiliser la commande « host » suivie du nom d'hôte que l'on veut tester.

Exemple pour un nom long : host serveur_front.mon_domaine.fr Exemple pour un nom court : host serveur_front

Comme résultat on doit obtenir l'adresse ip que l'on a fournie pour chaque machine. Si ce n'est pas le cas, alors il faut vérifier votre configuration de votre zone DNS.

Déploiement de CapInfo

Avant de continuer, vérifier que tous les services tournent, et qu'ils ont bien pris en compte les dernières modifications des configurations.

Décompression de l'archive

Manipulations à effectuer sur le serveur Applicatif Dans le répertoire de la livraison (que vous avez déjà recopié et décompressé dans /root), Éditer le fichier « maj_webct95.sh » et vérifier les chemins d'accès qui sont dans des variables.

Enfin, taper la commande suivante en adaptant <NOM WAR> par le nom du fichier .WAR présent dans le répertoire de livraison.

chmod +x maj_webct95.sh ./maj_webct95.sh <NOM WAR>

Création de l’architecture SQL pour CapInfo

Manipulations à effectuer sur le serveur Back Redémarrer Postgresql via la commande : /etc/init.d/postgresql restart

En tant que root, créer l’utilisateur système de WebCT95 via la commande : useradd webct95

Pour créer l’utilisateur dans Postgresql il faut tout d’abord devenir l’utilisateur « postgres » via la commande : su – postgres

Ensuite, il faut ajouter l’utilisateur dans le système de base donnée via la commande : createuser -a -d -P webct95

Le système va demander le mot de passe pour cet utilisateur 2 fois de suite. Le mot de passe à indiquer est : webct95 Entrez le mot de passe pour le nouvel utilisateur : Entrez-le de nouveau :

La commande doit se solder par la ligne suivante : CREATE USER

Rajouter le langage ’plpgsql’ à la liste des langages procéduraux utilisables dans cette installation de PostgreSQL via la commande : createlang plpgsql template1

Configuration de CapInfo

Manipulations à effectuer sur le serveur Applicatif Editer le fichier « /webct95/WEB-INF/resources/enterprise.init » et passer la variable « updateTemplates » à « true » : updateTemplates = true;

Editer le fichier « /webct95/WEB-INF/classes/fr/cg95/webct/external/database.xml » Et ajuster le nom du serveur dans la ligne suivante en indiquant le nom (si il existe) ou l’ip de votre serveur Back. <driver class-name="org.postgresql.Driver" url="jdbc:postgresql://wct95b01/webct95ext?compatible=7.2">

Editer le fichier « /webct95/WEB-INF/conf/webct.properties » et indiquer dans la variable « squid_servers » le nom de votre serveur Front, suivit de « : » et du numéro de port sur lequel il écoute. Exemple : squid_servers=wct95f01:3128

Redémarrage des services

Manipulations à effectuer sur le serveur Front Relancez Squid, Apache /etc/init.d/squid restart /etc/init.d/httpd restart

Manipulations à effectuer sur le serveur Applicatif

Entrer dans le répertoire des librairies approuvées des webapps via la commande : cd /var/lib/tomcat5/common/endorsed/

Effacer un lien via la commande : rm \[jaxp_parser_impl\].jar

Créer à nouveau le lien, mais d’une manière différente, via la commande : ln -s /webct95/WEB-INF/lib/xercesImpl.jar xercesImpl.jar

Puis relancer Tomcat, via la commande : /etc/init.d/tomcat5 restart

Paramétrage du sitemanager

_Manipulations à effectuer sur le serveur Applicatif_ Éditer le fichier « /wct95/bin/init_env.dat » pour l'adapter à votre plate-forme. C'est dans ce fichier que l'on active ou l'on désactives la gestion des services avec Sitemanager.

Il faut renseigner dans ce fichier le nom du serveur pour chaque service. Le nom du serveur est à indiquer dans la variable écrite sous la forme : <SERVICE>_SERV Exemple pour le serveur Tomcat : TOMCAT_SERV=nom_du_serveur

Si pour un service, le serveur à déclarer est LOCAL à la machine Applicative, alors indiquer « localhost » comme nom de serveur, dans la variable. Sans cela Sitemanager essayera de se connecter sur un serveur distant à a la place de considérer le service comme local.

Pour tous les services optionnels : La variable contenant le nom du serveur est précédée par une variable qui n'a que le nom de la fonction, et qui est un booléen. Ces variables servent à activer ou désactiver la gestion d'un service par Sitemanager. Chaque variable booléenne doit être positionnée à « false » si on ne veut pas activer la gestion de la fonction par Sitemanager; et à « true » si l'on veut l'activer

Exemple, pour activer la gestion des DNS par Sitemanager : DNS=true;

Adapter aussi, le mot de passe du compte « root » de MySql dans la variable suivante : PASSWD_MYSQL

Ajustements du système pour Sitemanager

Sitemanager est l'outil que vous utiliserez pour gérer votre plate-forme WebCT95. Ce script shell simplifie largement les opérations classiques sur WebCT95, comme la création d’un site, le listing des sites, l’ajout d’un compte admin, etc..

===Installation de « xmlstarlet » === Les fichiers de configuration des sites et des bases pour sitemanager étant des fichiers XML, il faut installer un parser XML en ligne de commande pour que sitemanager fonctionne. L’URL du site de « xmlstarlet » est le suivant : http://xmlstar.sourceforge.net/ Sur le site vous trouverez dans la section « download » un fichier RPM. La version testé pour sitemanager est la 1.0.1. Une fois le fichier téléchargé sur le serveur il faut l’installer via la commande : rpm -ivh <nom du fichier RPM>

Création d'une clef SSH pour le sitemanager

Les clefs SSH qui vont être crées, seront utilisée par « sitemanager » pour se connecter aux autres serveurs automatiquement afin d’effectuer les taches de gestion.

Manipulations à effectuer sur le serveur Applicatif Pour générer la clef, utiliser la commande « ssh-keygen ». Une fois connecté en tant que « root », taper la commande suivante : ssh-keygen -t rsa

La commande va vous poser 3 questions, à chacune ne répondez rien, et appuyez simplement sur la touche « Entrée ».

Voici un aperçu de l'ensemble de l'opération : ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 5a:a1:36:b0:d8:bb:23:b6:9f:a8:20:10:cd:67:61:e5

Ensuite transférer la clef publique SSH sur les autres serveurs. A chaque transfert, SSH vous posera une question si vous ne vous êtes jamais connecté sur ces serveurs via SSH. A cette question répondez bien « yes ».

Utiliser les commandes suivantes en remplaçant <SERVEUR_FRONT> par le nom du votre serveur Front et <SERVEUR_BACK> par le nom de votre serveur Applicatif (suivant si ils existent où pas bien sûr) : scp /root/.ssh/id_rsa.pub root@<SERVEUR_FRONT>:/root/ scp /root/.ssh/id_rsa.pub root@<SERVEUR_BACK>:/root/

Manipulations à effectuer sur les serveurs Front et Back cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys; chmod 600 /root/.ssh/authorized_keys;

Création du 1er site

Manipulations à effectuer sur le serveur Applicatif Pour créer son premier site, il suffit d’utiliser « sitemanager ». Pour créer un site, il faut tout d’abord déterminer : le nom de la base de donnée à utiliser, (si elle n'existe pas, elle sera créée) identifié par <base_alias> le nom du répertoire qui contient le site de la ville (qui sera dans /wct95/assets), identifié par <home_dir> le nom d’hôte du site, identifié par <host_name> (exemple : www.prune.com) le nom du compte administrateur, identifié par <admin_login> le mot de passe du compte administrateur, identifié par <admin_passworrd> le mot de passe du compte mysql pour phpbb, identifié par <mysql_password> l’adresse ip du serveur Front, identifié par <local_ip>

Une fois ces paramètres déterminés, lancer la commande suivante en remplaçant les arguments :

/wct95/bin/serveurApp/sitemanager.sh create <base_alias> <home_dir> <host_name> <admin_login> <admin_password> <mysql_password> <local_ip>

Une fois la création du site effectuée, il faut redémarrer Apache

Manipulations à effectuer sur le serveur Front /etc/init.d/httpd restart

Maintenant vous pouvez accéder à votre Back Office à l’adresse suivante : http://<host_name>/struts/bo-login.do En utilisant vos identifiant du compte admin.

Maintenance du système

Outils de redémarrage du serveur Tomcat

Manipulations à effectuer sur le serveur Applicatif Le redémarrage de la plate-forme étant délicat, nous avons écrit un script appelé « relance_tomcat.sh » et situé dans « /wct95/bin/serveur_App/ ». Utiliser le chaque fois que vous voulez redémarrer CapInfo (nécessite l'étape « Création d'une clef SSH pour le sitemanager » avant de pouvoir fonctionner).

Il est possible de faire une relance de la plate-forme toutes les nuits en utilisant ce script, via crontab.

Dumps journaliers des bases

Afin de sauvegarder efficacement les bases de données, il faut faire un dump des bases. Par souci de cohérence et de facilité de restauration, nous gardons aussi des archives des assets des sites.

Manipulations à effectuer sur le serveur Back

« /data/backup_dujour » contiendra uniquement les sauvegardes du jour.

Le script à mettre dans la crontab est « /wct95/bin/serveurBD/sauvegarde.sh » Ce script fait les dumps des bases Postgresql, et le tar compressé des assets.

Note : un script pour les géolocalisation est aussi disponible dans le répertoire « /wct95/bin/serveurGeo/sauvegarde.sh »

Manipulations à effectuer sur le serveur Front Le script à mettre dans la crontab est « /wct95/bin/serveurFront/backup_databases.sh » Ce script fait les dumps des bases MySql. Il ne garde que 7 jours d'arriéré. Le répertoire qui accueille les dump Mysql est : « /var/cache/backup_mysql »