Ce document décrit la procédure à utiliser pour installer un serveur X-Itools à partir d'une archive contenant une version officielle disponible en téléchargement sur le site web du projet X-Itools hébergé par Sourceforge (archive au format *.tar.gz).

L'installation est certifiée pour des serveurs basés sur un OS RedHat 7.2 et 7.3.
L'installation est certifiée pour des serveurs basés sur un OS RedHat 8.0 ou 9.0, qui inclut gcc 3.x et apache 2.x, à partir de la version 0.5.65 des X-Itools seulement.
L'installation est certifiée pour des serveurs basés sur un OS Fedora Core 2.

Elle est divisée en plusieurs parties:

• avant de commencer
• téléchargement du fichier archive désiré
• modification du fichier httpd.conf du serveur web Apache 1.3.X
• configuration, compilation et installation du produit
• configuration de PostgreSQL
• initialisation de la base de données X-Itools
• installation des fichiers de langue
• installation de la crontab
• mise à jour d'une base de données X-Itools existante vers un nouveau modèle de base de données
• redémarrage d'Apache
• le fichier de configuration du serveur X-Itools
• Installation du script de démarrage X-Itools
• Installation du script de démarrage X-Itools Firewall Logger daemon
• Fichiers de log X-Itools
• Devices manager et configuration de l'applet SSHTerm
• test du serveur X-Itools

Cette documentation ne décrit pas comment installer les logiciels nécessaires à un fonctionnement normal du serveur X-Itools: apache, postgresql, sendmail, SSL, OpenSSH, LDAP, SDK CheckPoint et/ou autres. Mais normalement, vous ne devriez pas avoir la possibilité de compiler le produit si l'un d'entre eux n'est pas installé. Vous obtiendrez des messages d'erreur à la place. De plus les distributions Linux récentes permettent une installation aisée avec le système de gestion de packages RPM.

AVANT DE COMMENCER:

Versions < 0.6.10:

Sur la machine destinée à devenir le serveur X-Itools, créez un utilisateur nommé xitools:

#> useradd xitools

Son répertoire d'accueil devrait ressembler à /home/xitools ou quelque chose comme ça.

Nous allons utiliser cet utilisateur non privilégié pour sauvegarder l'archive X-Itools tar.gz qui sera téléchargée ci-dessous.

Versions >= 0.6.10:

Connectez-vous juste avec votre compte habituel. Nous téléchargerons l'archive X-Itools directement dans votre répertoire utilisateur.

TELECHARGEMENT DU FICHIER ARCHIVE DESIRE:

Versions < 0.6.10:

Maintenant que l'utilisateur xitools a été ajouté, effectuez un login sous le nom de celui-ci.

#> su - xitools $>

et téléchargez le fichier de la dernière version du projet X-Itools sur sourceforge.

Versions >= 0.6.10:

Maintenant que vous êtes dans votre répertoire utilisateur, téléchargez la dernière archive du projet X-Itools à partir de sourceforge.

Toutes les versions:

Le nom du package est x-itools. Cliquez sur download sur la droite et sélectionnez l'archive que vous voulez. Au jour d'aujourd'hui, plusieurs packages sont disponibles, mais bien entendu nous vous recommandons fortement de télécharger le dernier:

x-itools-0.5.tar.gz x-itools-0.5.20.tar.gz ... ... x-itools-0.6.10.tar.gz

maintenant, décompressez l'archive:

$> tar -xzf x-itools-0.6.10.tar.gz

Si tout va bien, vous devriez maintenant obtenir un dossier nommé x-itools dans votre répertoire de base. Ce dossier contient tout ce qui est normalement nécessaire pour installer un serveur X-Itools à partir des sources.

Ci-dessous est représenté l'arbre des dossiers que vous devriez obtenir dans le répertoire x-itools:

x-itools-0.6.10     +    lib               // sources de la librairie partagée     +    pixmaps           // fichiers images     +    po                // fichiers des langues     +    src               // codes sources de chaque module     +    DB                // patches et modèle base de données     +    m4                // macros préprocesseur m4

MODIFICATION DU FICHIER HTTPD.CONF DU SERVEUR WEB APACHE 1.3.X:

Vous aurez besoin des droits root pour modifier le fichier de configuration d'apache pour les X-Itools. Normallement, ce fichier devrait être situé dans le répertoire /etc/httpd/conf, mais cela dépend de votre installation ou de votre distribution linux.

Donc, en tant qu'utilisateur xitools, tapez ce qui suit:

$> su root

Entrez votre mot de passe root et éditez le fichier httpd.conf avec votre éditeur favori (je suis sûr que c'est vi):

#> vi /etc/httpd/conf/httpd.conf

Ce fichier de configuration est très bien documenté. Rendez-vous à la section 3 de ce fichier: c'est là que nous allons créer et configurer les sites virtuels.
Pour ce faire, recherchez le mot NameVirtualHost dans le fichier: il devrait exister. Nous devons activer cette directive si ce n'est pas le cas. Pour ça, enlevez le # si il y en a un. Le NameVirtualHost doit contenir votre adresse ip: en fait l'adresse IP de votre serveur apache, où seront installés les fichiers binaires X-Itools. Par exemple:

NameVirtualHost 10.10.10.1

Maintenant, nous allons créer un VirtualHost sur le port usuel http 80 spécifique au serveur X-Itools. Si vous voulez, vous pouvez modifier le virtualhost par défaut pour le port 443, et dans ce cas le serveur X-Itools sera accessible par SSL. Si vous êtes une société, je sus sûr que vous pensez que la sécurité est une donnée importante.

Donc, si vous voulez activer SSL pour X-Itools, modifiez le bloc <VirtualHost _default_:443> comme suit dans le fichier httpd.conf:

<VirtualHost _default_:443> # General setup for the virtual host DocumentRoot "/var/www/x-itools" #ServerName new.host.name ServerAdmin xitools ErrorLog logs/x-itools.ssl.error_log TransferLog logs/x-itools.sll.access_log # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A test # certificate can be generated with `make certificate' under # built time. Keep in mind that if you've both a RSA and a DSA # certificate you can configure both in parallel (to also allow # the use of DSA ciphers, etc.) SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt #SSLCertificateFile /etc/httpd/conf/ssl.crt/server-dsa.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key #SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server-dsa.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/httpd/conf/ssl.crt/ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/httpd/conf/ssl.crt #SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/httpd/conf/ssl.crl #SSLCARevocationFile /etc/httpd/conf/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details. #<Location /> #SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ #</Location> # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o CompatEnvVars: # This exports obsolete environment variables for backward compatibility # to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this # to provide compatibility to existing CGI scripts. # o StrictRequire: # This denies access when "SSLRequireSSL" or "SSLRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire <Files ~ "\.(cgi|shtml|phtml|php3?)$"> SSLOptions +StdEnvVars </Files> #<Directory "/var/www/cgi-bin"> # SSLOptions +StdEnvVars #</Directory> <Directory /var/www/x-itools> AddHandler cgi-script .cgi Options +ExecCGI SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # Per-Server Logging: # The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis. CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" </VirtualHost>

Comme vous pouvez le voir, nous avons décidé que DocumentRoot pour les fichiers du serveur X-Itools sera /var/www/x-itools, et que ServerAdmin sera l'utilisateur xitools que nous avons créé précédemment. Vous pouvez changer cela si vous voulez.

Cela signifie que tous les fichiers que nous allons compiler devront être installés dans le dossier /var/www/x-itools.

De plus, n'oubliez pas d'activer quelques options pour le dossier /var/www/x-itools, options concernant l'exécution des scripts. C'est dans la sous-section <Directory /var/www/x-itools> de l'hôte virtuel.

A partir de là, tout est fait pour la configuration d'un serveur X-Itools au travers d'ssl.
Maintenant, nous allons créer un autre virtualhost pour le serveur X-Itools sur le port habituel http 80.

A la fin du fichier httpd.conf, ajoutez juste cette section VirtualHost:

<VirtualHost 62.50.65.20>     ServerName x-itools.mondomaine.com     ServerAdmin xitools     ErrorLog logs/x-itools.error_log     TransferLog logs/x-itools.access_log     DocumentRoot /var/www/x-itools     <Directory /var/www/x-itools>         AddHandler cgi-script .cgi         Options +ExecCGI     </Directory> </VirtualHost>

Dans ce cas, l'hôte virtuel X-Itools peut être joint à l'aide d'un browser avec l'URL suivante seulement:

http://x-itools.mondomaine.com

Comme d'habitude, vous pouvez modifier les répertoires DocumentRoot et ServerAdmin. Mais si vous avez activé X-Itools sur SSL, le dossier DocumentRoot doit être exactement le même dans le VirtualHost SSL et dans le VirtualHost normal.

Une dernière petite chose doit être configurée: il est nécessaire d'indiquer à Apache qu'il doit faire attention au fichier index.cgi car en standard, il est seulement configuré avec beaucoup de fichiers d'index, mais pas avec un fichier d'index CGI. Pour ce faire, recherchez la directive DirectoryIndex et ajoutez à la fin de ce paramètre, le fichier index.cgi. Vous devriez obtenir au final quelque chose comme cela:

DirectoryIndex index.html index.htm index.shtml index.php index.php4 index.php3 index.phtml index.cgi

Une fois que vous avez fait tout ça, vous pouvez sauvegarder les changements dans le fichier httpd.conf et quitter vi.

Nous n'allons pas redémarrer le serveur web maintenant, parce qu'avant, tous les binaires X-Itools doivent être installés dans le dossier correct.

CONFIGURATION, COMPILATION ET INSTALLATION DU PRODUIT:

Pour compiler le serveur X-Itools vous avez besoin de gcc 2.96.x au minimum sur des systèmes basés sur RedHat 7.x, ou gc 3.x sur des systèmes basés sur RedHat 8.0 ou 9.0. Cependant, seul un serveur X-Itools basés sur les versions 0.5.65 ou supérieures sont conçus pour être compilés à la fois par gcc 2.96.x et 3.x.

En tant que root, effectuez les opérations suivantes dans le répertoire du projet X-Itools:

#> ./configure #> make #> make install

C'est tout !!!

Comme d'habitude, le script configure va contrôler si toutes les dépendances sont installées sur votre système dans le but de compiler les codes sources X-Itools. Vous ne devriez pas voir apparaître de messages d'erreur ici. Si c'est le cas, essayez d'installer les packages manquants ou de résoudre les autres problèmes potentiels.

La commande make compile tous les sources.

La commande make install installe les binaires et les autres fichiers dans /usr/local par défaut, ce qui n'est pas le chemin recommandé. Par exemple, le dossier du serveur virtuel X-Itools sera créé en tant que /usr/local/var/www/x-itools, les fichiers de base de donnée seront installés dans /usr/local/var/lib/pgsql, et ainsi de suite.

Dans le but d'installer tous les fichiers dans les bons répertoires, le dossier de base devant être / et pas /usr/local, tapez la commande configure suivante avant de faire les makes:

#> ./configure --prefix=/

Après ça, les bons fichiers seront installés dans les bons dossiers, c'est à dire /var/www/x-itools pour les fichiers exécutables, /var/lib/pgsql pour les fichiers de base de donnée, etc. /var/www est le dossier de base qui devrait orrespondre au standard Apache (qui est /var/www sur une RedHat 7.3). Le fichier de configuration devra être installé dans /etc, et le modèle de base de donnée sera installé sous /var/lib/pgsql, ce qui est standard pour PostgreSQL 7.2.x. De plus, la table crontab des X-Itools sera installée dans les entrées cron de votre système, et les fichiers de localisation (langues) seront installés dans les répertoires corrects.

Notez qu'au lieu de configurer le prefix pour la commande configure, vous pourriez le laisser comme il est par défaut, et vous pouvez après les commandes make, copier les bons fichiers dans les bons dossiers vous-même avec la commande cp.

Bien entendu, il est nécessaire d'initialiser la base de données, et de modifier le fichier httpd.conf dans le but de créer le serveur virtuel nécessaire pour les fichiers X-Itools (voir l'étape précédente).

Versions >= 0.6.10:

La compilation d'une version X-Itools supérieure ou égale à 0.6.10 est particulière. En effet, à partir de cette version est inclu un nouveau démon utilisant le SDK Checkpoint. Ce démon est le X-Itools Firewall logger daemon.

Le SDK de CheckPoint doit être téléchargé sur le site CheckPoint puis utilisé de la façon décrite ci-dessous pour réussir la compilation des X-Itools. Malheureusement, ChekPoint a programmé son SDK sur RedHat 7.3, avec gcc 2.96.x.

Deux choix se présentent alors à vous: soit vous n'avez pas besoin du démon X-Itools CPLog et vous pouvez procéder à la compilation et à l'installation comme décrit juste ci-dessus, ou alors vous souhaitez l'utiliser et vous devrez compiler tous les modules X-Itools avec un gcc 2.96.x, en utilisant les instructions ci-dessous.

Pour commencer, vous devez télécharger le SDK CheckPoint directement depuis le site web de CheckPoint. Après avoir décompressé l'archive dans votre répertoire utilisateur, vous devrez juste ajouter l'option --with-opsec-dir=/CheckPoint/SDK/Directory à la commande ./configure, comme montré ci-dessous:

#> ./configure --with-opsec-dir=/home/directory/OPSEC --prefix=/

Ensuite, continuez comme décrit au-dessus.

CONFIGURATION DE POSTGRESQL:

Pour que le serveur X-Itools puisse se connecter à la base de données sans problèmes, PostgreSQL doit être configuré pour autoriser les connections TCP/IP à travers le réseau. Même si la base de données et le serveur X-Itools sont installés sur la même machine.

Donc, nous avons 2 fichiers de configuration PostgreSQL à modifier. Pour commencer, modifiez /var/lib/pgsql/data/postgresql.conf et activez les lignes suivantes pour activer le client réseau de PostgreSQL:

# # Connection Parameters # tcpip_socket = true                  # we have enabled and modified this line #ssl = false #max_connections = 32 port = 5432                            # we have enabled and modified this line #hostname_lookup = false #show_source_port = false

host all 0.0.0.0 0.0.0.0 trust

La ligne ci-dessus signifie que toutes les connections sur toutes les bases de données en provenance de n'importe quel client sont autorisées. Nous pouvons être plus restrictifs que cela. Premièrement, limitez les connections sur la base de données xitools seulement, puis deuxièmement depuis vos différents réseaux seulement (si le serveur X-Itools est utilisé en interne seulement, pour un intranet par exemple). Dans ce cas, nous pouvons avoir quelque chose comme cela:

host xitools 10.0.0.0 255.0.0.0 trust host xitools 192.168.16.0 255.255.255.0 trust

Notez que si vous avez seulement un seul serveur X-Itools sur la même machine que la base de données xitools, vous pouvez configurer PostgreSQL comme ceci:

host xitools 127.0.0.1 255.255.255.255 trust

Si par contre vous avez plusieurs serveurs X-Itools connectés sur un serveur de base de données X-Itools, enregistrez juste les adresses IPs de ceux-ci comme montré ci-dessous. Une telle configuration peut être utilisée pour introduire la redondance et la tolérance de panne:

host xitools 193.212.7.9 255.255.255.255 trust host xitools 193.212.7.10 255.255.255.255 trust host xitools 89.12.69.254 255.255.255.255 trust

Maintenant que les fichiers de configuration de PostgreSQL ont été modifiés, le démon PostgreSQL doit être redémarré comme ceci, sous l'utilisateur root:

#> /etc/rc.d/init.d/postgresql restart

Faites très attention à ce que PostgreSQL démarre automatiquement au lancement de la machine. Pour ce faire, et tout comme Apache, des scripts de démarrage dans /etc/rc.d/init.d doivent exister. Pour le vérifier pour PostgreSQL, tapez la commande suivante:

#> chkconfig --list postgresql

Si vous n'avez pas une liste de runlevels où vous apercevez 'on' ou 'off', mais au lieu de cela un message affiché sur l'écran indiquant que malgré le fait que PostgreSQL peut utiliser chkconfig, il n'est pas enregistré pour ceci pour le moment, tapez la commande suivante pour activer PostgreSQL au démarrage:

#> chkconfig --add postgresql

Dans un autre cas, si vous avez la liste des runlevels où vous pouvez voir 'on' ou 'off' mais si vous voyez que pour les runlevels 3, 4 et 5 il est à 'off', tapez la commande ci-dessous:

#> chkconfig postgresql on

Nous en avons terminé pour la configuration de PostgreSQL.

INSTALLATION ET INITIALISATION DE LA BASE DE DONNEES:

La seule base de données utilisable pour le moment est PostgreSQL 7.x.

Vous devez avoir postgresql installé et démarré sur le serveur X-Itools ou sur un autre serveur distant. PostgreSQL doit être configuré pour autoriser les connexions sur une base de données nomée xitools en provenance du serveur web X-Itools, même si le serveur SQL est le même que le serveur web.

Vous devrez modifier ou mettre à jour le fichier pg_hba.conf pour autoriser ces connexions. Et postgresql devra être démarré avec l'option lui indiquant d'accepter les connexions à travers le réseau. Pour ceci, lisez la section précédente.

Si le modèle de base de donnée n'est pas dans le répertoire propre à postgresql (qui est normalement /var/lib/pgsql), copiez le comme ci-dessous:

#> cp /home/xitools/20010715_01/xitools_template.out /var/lib/pgsql

et fixez lui les bonnes permissions:

#> chown postgres:postgres /var/lib/pgsql/xitools_template.out

Connectez-vous en tant qu'utilisateur de votre base de données (postgres pour postgresql):

#> su - postgres $>

créez la base de données xitools (postgresql doit être démarré):

$> createdb xitools

lancez l'interface pgsql pour créer les utilisateurs postgresql xitools:

$> psql xitools xitools=#

maintenant, créez l'utilisateur xitools:

xitools=# create user xitools with password 'xitools';

et créez l'utilisateur nobody:

xitools=# create user nobody with password 'xitools';

puis quittez l'interface pgsql:

xitools=# \q

maintenant, initialisez la base de données xitools:

$> psql -e xitools < xitools_template.out

La base de données xitools est maintenant prête à être utilisée.

N'oubliez pas d'éditer le fichier XItool_Biblio.H dans l'arborescence des fichiers sources pour mettre à jour certains paramètres #define en fonction de l'adresse ip de votre serveur de base de données. Pour le moment, ces paramètres sont codés en dur directement dans les sources. Dans le futur, de tels paramètres seront déplacés dans un fichier de configuration qui sera lu par les binaires X-Itools.

INSTALLATION DES FICHIERS DE LANGUE:

Si vous voulez utiliser les X-Itools en français par exemple ou avec d'autres langues, vous devrez installer les fichiers de localisations. La commande ci-dessous, qui installe le fichier de localisation pour le français, doit être utilisée après avoir installé un serveur X-Itools pour la première fois, et à chaque fois que vous réalisez une mise à jour, dans le but d'installer la mise à jour des fichiers de localisation aussi.

Pour installer le fichier de localisation pour le français, tapez la commande ci-dessous (vous devez être dans le répertoire de base des X-Itools, c'est à dire 20010715_01, en tant que root):

#> msgfmt -o /usr/share/locale/fr/LC_MESSAGES/X-Itools.mo po/fr.po

Normalement, vous êtes maintenant compètement paré pour tester le serveur X-Itools.

INSTALLATION DE LA CRONTAB:

Si la crontab n'a pas été installée, il est nécessaire de le faire. Ici, trois cas se présentent: soit vous avez une version du serveur X-Itools inférieur à 0.5.65, soit vous avez une version entre 0.5.65 et 0.5.96, ou alors vous avez une version supérieur à 0.5.97.

Versions < 0.5.65:

La crontab est une pièce très importante du serveur X-Itools: grâce à elle, la base de données est optimisée automatiquement chaque nuit, et le script Check est lancé chaque minute. Ce script est responsable de l'accomplissement de beaucoup d'opérations comme envoyer les notifications de l'agenda partagé, réaliser les contrôles nécessaires sur les machines de votre réseau (pour le module ping) afin de déterminer si elles répondent toujours, réaliser des opérations sur les comptes vacance de vos utilisateurs, etc...

Pour vérifier si la crontab est présente ou pas, tapez en tant qu'utilisateur root la commade suivante:

#> crontab -l

Si rien n'apparait, cela signifie juste que la crontab doit être installée. Le fichier de la crontab du projet X-Itools est localisé à la base du dossier X-Itools. Il s'agit du fichier crontab.root. Installez-le comme suit:

#> crontab crontab.root

Et contrôlez de nouveau. Vous devriez avoir le résultat suivant:

#> crontab -l * * * * * /var/www/x-itools/XItool_Check.cgi 0 0 * * 0 psql -c "vacuum analyze;" -q -U postgres -d xitools 0 0 * * 1-6 psql -c "vacuum;" -q -U postgres -d xitools

Versions 0.5.65 <= V <= 0.5.96:

Ici, la crontab est seulement en charge des opérations relatives à la maintenance de la base de données, dans le but de l'optimiser et de vous donner la garantie qu'elle tournera le plus rapidement possible.

Pour vérifier si la crontab est présente ou pas, tapez en tant qu'utilisateur root la commade suivante:

#> crontab -l

Si rien n'apparait, cela signifie juste que la crontab doit être installée. Le fichier de la crontab du projet X-Itools est localisé à la base du dossier X-Itools. Il s'agit du fichier crontab.root. Installez-le comme suit:

#> crontab crontab.root

Et contrôlez de nouveau. Vous devriez avoir le résultat suivant:

#> crontab -l 0 0 * * 0 psql -c "vacuum analyze;" -q -U postgres -d xitools 0 0 * * 1-6 psql -c "vacuum;" -q -U postgres -d xitools

Le script Check n'est plus exécuté par la crontab: ce script doit être démarré manuellement après que votre serveur X-Itools ait booté, puis il restera résidant, tournant en tâche de fond pour exécuter ses tâches chaque minute. Cette solution est temporaire, elle est utilisée durant le temps nécessaire à la programmation d'une version démonisée de ce module X-Itools très spécifique.

Versions >= 0.5.97:

Dans ce dernier cas, la crontab est seulement en charge des opérations relatives à la maintenance de la base de données, dans le but de l'optimiser et de vous donner la garantie qu'elle tournera le plus rapidement possible.

Pour vérifier si la crontab est présente ou pas, tapez en tant qu'utilisateur root la commade suivante:

#> crontab -l

Si rien n'apparait, cela signifie juste que la crontab doit être installée. Le fichier de la crontab du projet X-Itools est localisé à la base du dossier X-Itools. Il s'agit du fichier crontab.root. Installez-le comme suit:

#> crontab crontab.root

Et contrôlez de nouveau. Vous devriez avoir le résultat suivant:

#> crontab -l 0 0 * * 0 psql -c "vacuum analyze;" -q -U postgres -d xitools 0 0 * * 1-6 psql -c "vacuum;" -q -U postgres -d xitools

Il n'est plus nécessaire ici de démarrer le script une fois que le serveur a booté. Le script Check est maintenant un démon, qui est lancé et stoppé comme n'importe quel autre démon, par un script de démarrage dans /etc/rc.d/init.d path.

ATTENTION !!! Faites très attention à ne pas effacer une crontab existante: vous pourriez causer d'importants domages à votre système.

METTRE A JOUR UNE BASE DE DONNEES X-ITOOLS EXISTANTE VERS UN NOUVEAU MODELE DE BASE DE DONNEES:

Le contenu de cette section doit être lu et éxécuté si un serveur X-Itools est déjà installé et si vous voulez migrer vers une nouvelle version. Cela concerne les version X-Itools 0.5.40 et plus seulement. Ne faites pas les actions décrites dans cette partie si vous avez un serveur X-Itools avec un numéro de version en-dessous de 0.5.40.

Pour migrer votre base de données X-Itools existante vers un nouveau schéma (ou modèle), vous pouvez constater que vous avez des fichiers nommés 0.5.40_to_0.5.41, 0.5.42_to_0.5.43 et ainsi de suite.

Ces fichiers sont des scripts de base de données qui doivent être éxécutés par postgresql pour migrer la base de données X-Itools d'une version à une autre.

Par exemple, si vous aviez précédemment une version des X-Itools 0.5.40 et que vous venez juste de compiler la version 0.5.41, vous devrez exécuter ces commandes en tant qu'utilisateur de postgresql pour mettre à jour votre base de données sans la perdre ou sans installer un modèle de base de données vierge:

$> psql -e xitools < 0.5.40_to_0.5.41

et faites le seulement une fois !!!

Le cas est légèrement différent si vous voulez migrer d'une version 0.5.40 à une version 0.5.43 par exemple. Vous devrez éxécuter chaque script jusqu'à atteindre votre nouveau numéro de version. Il est très important de ne pas oublier un des scripts, et de les appliquer dans le bon ordre (ordre des numéros de version). Si un script n'existe pas pour une version spécifique des X-Itools, cela signifie juste qu'il n'y a pas besoin de migrer la base de données, parce que son schéma n'a pas été modifié.

Par exemple, pour aller d'une version 0.5.40 à une version 0.5.43, exécutez ces commandes en tant qu'utilisateur de postgresql:

$> psql -e xitools < 0.5.40_to_0.5.41 $> psql -e xitools < 0.5.42_to_0.5.43

Notez qu'il n'y a pas de script pour aller de 0.5.41 à 0.5.42.

Normalement, vous êtes complètement paré pour démarrer votre nouvelle version du serveur X-Itools.

REDEMARRER APACHE:

Avant d'utiliser le serveur X-Itools pour la première fois, apache doit être redémarré. En tant que root sur une RedHat:

#> /etc/rc.d/init.d/httpd restart

Vous pouvez vérifier que tous les serveurs virtuels sont correctement configurés et reconnus par Apache en tapant:

#> httpd -S

ce qui devrait vous donner la liste de tous les VirtualHosts configurés et fonctionnels. Les VirtualHosts X-Itools doivent être dans cette liste.

N'oubliez pas de mettre à jour votre DNS ou votre fichier hosts avec le FQDN X-Itools (x-itools.mondomaine.com ici).

LE FICHIER DE CONFIGURATION DU SERVEUR X-ITOOLS:

ATTENTION : les versions du produit X-Itools à partir de 0.5.97 incluse seulement prendront le fichier de configuration /etc/x-itools.conf en compte. Avant cela, les différents paramètres présents dans ce fichier de configuration sont à configurer directement dans le code, dans le fichier XItool_Biblio.H.

Il reste juste une dernière chose à faire avant de tester les produits X-Itools: nous devons configurer le fichier de configuration X-Itools, comme ci-dessous:

Versions 0.5.97 <= V <= 0.6.00:

# SQLTYPE: in the futur, maybe X-Itools will use other databases than # postgres, but for now this field must only contain postgres. # # possible values: postgres SQLTYPE=postgres # SQLSERVER: address of the SQL server. It can be either an IP address or # the fully qualified domain name. SQLSERVER=127.0.0.1 # SQLPORT: port on which the SQL server listen. SQLPORT=5432 # DBUSER is the name of the user used to connect to the database DBUSER=xitools # DBNAME is the name of the X-Itools database DBNAME=xitools # UNIXACCOUNTS must be set to one if xitools user authentication must be # done according the UNIX user accounts database (/etc/passwd) AND the # xitools user database. # # by default it is set to 0 UNIXACCOUNTS=0 # DEBUG must be set to 1 if you want that extensive information be # written in the /var/log/XItools.log file # # by default it is set to 0 DEBUG=0

Versions >= 0.6.05:

# SQLTYPE: in the futur, maybe X-Itools will use other databases than # postgres, but for now this field must only contain postgres. # # possible values: postgres SQLTYPE=postgres # SQLSERVER: address of the SQL server. It can be either an IP address or # the fully qualified domain name. SQLSERVER=127.0.0.1 # SQLPORT: port on which the SQL server listen. SQLPORT=5432 # DBUSER is the name of the user used to connect to the database DBUSER=nobody # DBNAME is the name of the X-Itools database DBNAME=xitools # UNIXACCOUNTS must be set to one if xitools user authentication must be # done according the UNIX user accounts database (/etc/passwd) AND the # xitools user database. # # by default it is set to 0 UNIXACCOUNTS=0 # DEBUG must be set to 1 if you want that extensive information be # written in the /var/log/XItools.log file # # by default it is set to 0 DEBUG=0 # PASSWORD_HTTPS must usually be set to 1. In this case, the X-Itools # password module can only be used accross an SSL session (HTTPS), # which seems to be logic for a password manager. So, if you try to # use this module accross a normal HTTP session, the module will only # display an error message, and no action will be possible. Set it to # 0 to cancel this security. PASSWORD_HTTPS=0

C'est très simple. Le fichier doit être créé dans le dossier /etc de votre serveur X-Itools. Son nom doit être x-itools.conf. Vous pouvez copier celui qui est fourni avec l'archive.

Basiquement, il devrait juste être nécessaire de configurer la variable SQLSERVER correctement. Si la base de données du serveur X-Itools tourne sur un serveur distant (pas le même que le serveur Apache), remplacez l'adresse IP par l'adresse IP de ce serveur SQL. Si le serveurX-Itools et le serveur SQL sont en fait la même machine, mettez 127.0.0.1 en tant qu'adresse IP.

Maintenant, vous pouvez ouvrir votre browser et vous rendre à l'URL X-Itools que vous avez défini dans le fichier httpd.conf, qui devrait ressembler à quelque chose comme ça: http://x-itools.mondomaine.com

INSTALLATION DU SCRIPT DE DEMARRAGE X-ITOOLS:

ATTENTION: cette partie est applicable pour X-Itools version 0.5.97 ou suivantes. Puisque c'est seulement à partir de cette version que le module Check X-Itools est maintenant un démon, qui doit être démarré au moment du boot par un script de démarrage. Vous trouverez ci-dessous des explications relatives à l'installation du script de démarrage.

Pour commencer, vous devez savoir que le module Check X-Itools est responsable de l'exécution d'opérations variées et importantes.

Ce module est responsable de beaucoup d'opérations comme l'envoi des notifications de l'agenda partagé, le contrôle de machines à travers le réseau (pour le module de monitoring) afin de savoir si elles sont toujours actives, effectuer les opérations sur les comptes vacance des utilisateurs, et ainsi de suite...

Vous devriez voir dans l'archive X-Itools que vous avez décompressé, un fichier nommé XItools. Ce fichier est le script de démarrage: il doit être copié (ou déplacé) dans le répertoire /etc/rc.d/init.d. Après cela, nous devons positionner les permissions x sur ce script, ce qui signifie qu'il pourra être exécuté au boot. Enfin, nous utiliserons chkconfig pour configurer le système correctement, afin que ce script puisse être démarré et arrêté automatiquement dans les run levels adéquats.

Vous devez juste entrer les commandes ci-dessous, pour accomplir toutes ces étapes:

#> cp XItools /etc/rc.d/init.d #> chmod a+x /etc/rc.d/init.d/XItools #> chkconfig XItools on

Et la prochaine fois que vous booterez votre système, le module XItools Check sera démarré automatiquement.

Pour vérifier que ce module fonctionne sans problèmes, nous vous encourageons à positionner la variable DEBUG du fichier de configuration X-Itools à 1. En faisant cela, vous aurez la possibilité de jeter un oeil au fichier de log X-itools, qui devrait être dans le répertoire /var/log. Mais n'oubliez pas de désactiver ce mode DEBUG après quelques temps, dans le cas contraire votre disque dur pourrait se révéler bien vide plein (beaucoup de logs sont générés, chaque minute).

Il doit être clair que le module Check doit être exécuté tant que votre serveur tourne.

Vous pouvez utiliser les commandes suivantes pour démarrer, stopper, ou re-démarrer le module Check (ce qu'il est nécessaire de faire si vous modifiez la variable DEBUG du fichier de configuration):

#> /etc/rc.d/init.d/XItools stop #> /etc/rc.d/init.d/XItools start #> /etc/rc.d/init.d/XItools restart

Et vous pouvez obtenir des informations de la façon suivante:

#> /etc/rc.d/init.d/XItools status

Versions >= 0.6.10:

Depuis la version 0.6.10 du serveur X-Itools, le script de démarrage crée automatiquement le compte de l'utilisateur xitools si il n'existe pas, tout comme les clés ssh privée et publique qui seront nécessaires par le module X-Itools devices and passwords manager, si elles n'existent pas. Donc, avant d'utiliser les X-Itools pour la première fois, ce script de démarrage devra être lancé.

INSTALLATION DU SCRIPT DE DEMARRAGE X-ITOOLS FIREWALL LOGGER DAEMON:

ATTENTION: cette partie est applicable pour X-Itools version 0.6.10 ou suivantes. Puisque c'est seulement à partir de cette version que le démon X-Itools Firewall Logger existe, qui doit être démarré au moment du boot par un script de démarrage. Vous trouverez ci-dessous des explications relatives à l'installation du script de démarrage.

Pour commencer, vous devez savoir que le démon X-Itools Firewall Logger est responsable de la gestion des connections CheckPoint. Ce démon est nécessaire si vous désirez le module X-Itools Firewall Logger correspondant. Sinon, vous n'avez pas besoin de l'installer.

Ce démon a besoin des librairies du SDK de CheckPoint pour pouvoir fonctionner correctement. Il établi les connections configurées dans le module firewall logger et recoit puis réalise des opérations sur les logs envoyées par les stations de management CheckPoint et les stocke dans la base de données X-Itools. Ensuite, il est de la responsabilité du module X-Itools firewall logger (ce qui n'a rien à voir avec le démon) de réaliser des opérations variées sur les logs, et de les afficher.

Vous devriez voir dans l'archive X-Itools que vous avez décompressé, un fichier nommé XItools_CPLog. Ce fichier est le script de démarrage: il doit être copié (ou déplacé) dans le répertoire /etc/rc.d/init.d. Après cela, nous devons positionner les permissions x sur ce script, ce qui signifie qu'il pourra être exécuté au boot. Enfin, nous utiliserons chkconfig pour configurer le système correctement, afin que ce script puisse être démarré et arrêté automatiquement dans les run levels adéquats.

Vous devez juste entrer les commandes ci-dessous, pour accomplir toutes ces étapes:

#> cp XItools_CPLog /etc/rc.d/init.d #> chmod a+x /etc/rc.d/init.d/XItools_CPLog #> chkconfig XItools_CPLog on

Et la prochaine fois que vous booterez votre système, le démon XItools Firewall Logger sera démarré automatiquement.

Pour vérifier que ce module fonctionne sans problèmes, nous vous encourageons à positionner la variable DEBUG du fichier de configuration X-Itools à 1. En faisant cela, vous aurez la possibilité de jeter un oeil au fichier de log X-itools, qui devrait être dans le répertoire /var/log. Mais n'oubliez pas de désactiver ce mode DEBUG après quelques temps, dans le cas contraire votre disque dur pourrait se révéler bien vide plein (beaucoup de logs sont générés, chaque minute).

Vous pouvez utiliser les commandes suivantes pour démarrer, stopper, ou re-démarrer le démon (ce qu'il est nécessaire de faire si vous modifiez la variable DEBUG du fichier de configuration):

#> /etc/rc.d/init.d/XItools_CPLog stop #> /etc/rc.d/init.d/XItools_CPLog start #> /etc/rc.d/init.d/XItools_CPLog restart

Et vous pouvez obtenir des informations de la façon suivante:

#> /etc/rc.d/init.d/XItools_CPLog status

FICHIERS DE LOG X-ITOOLS:

Vous pouvez bénéficier de ces fichiers de log pour les versions du serveur X-Itools server > 0.5.99.

Pour des raisons de debugging, vous pouvez jeter un oeil aux fichiers de log X-Itools. Pour ceci, vous devez activer les logs dans le fichier de configuration X-Itools, et les fichiers de log doivent exister dans le dossier /var/log.

Pour les créer, tapez juste ce qui suit:

#> touch /var/log/XItools.log #> touch /var/log/XItools_DB.log #> chmod a+w /var/log/XItools*

Les logs concernant la base de données peuvent être activés uniquement dans chaque script, et en modifiant une ligne de code dans le source de chaque script, en l'état actuel des choses. Donc si vous les voulez, il sera nécessaire de tout recompiler.

Faites très attention car les fichiers de log de la base de données peuvent atteindre plus de 10 Mo en moins d'une minute !!!

DEVICES MANAGER ET CONFIGURATION DE L'APPLET SSHTerm:

Cette partie ne s'applique qu'aux versions >=0.6.00 du serveur X-Itools.

Le module X-Itools devices manager (précédemment nommé Password manager) peut vous aider à vous connecter sur les différents périphériques stockés dans sa base de données avec le protocole SSH version 2 seulement, en utilisant l'applet SSHTerm. Si vous voulez bénéficier de cette nouveauté, il y a une configuration additionnelle à faire, comme expliqué ci-dessous.

Notez que l'applet SSHTem est une partie d'un autre projet hébergé par Sourceforge nommé SSHTools, principalement programmé par Lee David Painter et Richard Pernavas, sous GPL.

Afin d'utiliser cette applet, vous devrez la télécharger en cliquant sur les liens ci-dessus, l'installer en suivant les instructions données ci-dessous, et vous devez avoir installé une machine virtuelle JRE 1.4.0 au minimum pour l'utiliser. Elle ne foncitonnera pas avec une version précédente du JRE ou du JDK.

Notez que d'après nos tests, cette applet (version 0.1.4 au moment où cette documentation a été écrite) fonctionne réellement bien sous IE ou Netscape sur Windows, mais nous avons relevé pas mal de probèmes avec plusieurs versions de la RedHat (8.0 et 9.0) avec leur version correspondante de mozilla, que ce soit avec le dernier JRE d'IBM ou de SUN. Bien entendu, il n'est pas de notre responsabilité de développer cette applet, donc, contactez le groupe de développement correspondant pour toutes questions relatives à cette applet.

Afin d'installer l'applet SSHTerm, téléchargez l'archive *.tar.gz et décompressez-la dans un répertoire temporaire. Après ceci, déplacez tous les fichiers *.jar dans le dossier où les fichiers X-Itools sont installés (là où les fichiers X-Itools *.cgi sont installés). Enfin, exécutez les commandes suivantes en tant que root, dans le dossier du serveur X-Itools:

#> chown nobody:nobody *.jar #> mkdir SSHTerm #> chown apache:apache SSHTerm

Le répertoire SSHTerm est utilisé par le serveur X-Itools pour stocker les fichiers temporaires nécessaires à chaque fois que l'applet SSHTerm est utilisée, à chaque fois que vous voulez vous connecter à un périphérique.

Notez que avec la version 0.6.00 du serveur X-Itools, les fichiers stockés dans ce dossier ne sont pas effacés. Donc si vous vous connectez souvent sur des périphériques, il sera peut être nécessaire que vous effaciez le contenu de ce répertoire de temps à autre (utilisez crontab pour cela). Ce très petit inconvénient sera résolu dans la version à venir du serveur X-itools.

La première fois que vous utiliserez l'applet SSHTerm, celle-ci vous demandera de se faire enregistrer, car seules les applets signées peuvent se connecter sur des machines externes, excepté votre ordinateur local (l'ordinateur sur lequel vous utilisez l'applet SSHTerm). Afin que cet enregistrement puisse être réalisé sans problèmes, acceptez l'enregistrement pour toujours, et vous ne serez pas dérangé par ce type de boite de dialogue d'enregistrement la prochaine fois.

TEST DU SERVEUR X-ITOOLS:

Si tout va bien, la page de login X-Itools est chargée dans votre browser. Mais puisque c'est la première fois que vous l'utilisez, aucun utilisateur existe dans la base de données X-Itools, excepté un: l'utilisateur système xitools.

Donc, connectez-vous avec l'utilisateur xitools, et le mot de passe xitools.

Si votre connexion est un succès (ce qui devrait être le cas), vous avez maintenant la barre de menu X-Itools sur votre écran, dans une fenêtre séparée. Vous pouvez vous rendre dans le module d'administration pour ajouter et gérer les utilisateurs X-Itools et le serveur X-Itools.

Lorsque vous vous connectez pour la première fois dans le serveur X-Itools, un domaine par défaut existe, ainsi qu'un autre utilisateur, qui est nommé 'me (rename me)'. Pour commencer, nous vous recommandons très fortement de modifier le nom du domaine par défaut, et de modifier le nom de l'utilisateur par défaut 'me'. L'utilisateur 'me' est un autre administrateur.

Il y a trois niveaux d'utilisateurs dans le serveur X-Itools: L'utilisateur Super Administrateur (utilisateur xitools), les utilisateurs administrateurs, et les utilisateurs non privilégiés. Il ne peut exister qu'un utilisateur Super Administrateur. Vous ne devriez jamais utiliser le compte super administrateur xitools, excepté pour les opérations spécifiques comme la création des domaines, et l'assignation d'un utilisateur administrateur pour les domaines.

Versions >= 0.6.00:

L'utilisateur 'me' est un administrateur pour le premier domaine existant du serveur X-itools. Vous devriez le renommer avec votre nom ou le nom de l'administrateur réel du domaine X-Itools. Au moins un administrateur est nécessaire pour chaque domaine, dans le but de l'administrer. Puis, le serveur X-Itools a besoin d'un administrateur pour fonctionner normalement, car la première fois que vous démarrez les X-Itools, n'importe quelle requête de compte faite par vos utilisateurs ne serait pas interpétée correctement sans un administrateur au moins. De plus, l'administrateur est paramétré par défaut en tant que manager vacances du domaine.

Après avoir configuré correctement le compte administrateur 'me', vous pouvez maintenant laisser vos utilisateurs se rendre sur la page web de login du serveur X-Itools, et demander un compte X-Itools. Tout ce que vous aurez à faire sera d'accepter (ou de refuser) ces requêtes, et d'assigner un profil utilisateur X-Itools à vos utilisateurs.

Versions <= 0.5.99:

Dans les versions précédentes à la 0.6.00 du serveur X-Itools, un domaine par défaut existait, mais pas de compte administrateur 'me' par défaut. Il est un peu compliqué de le créer correctement, et le serveur X-Itools ne fonctionnera pas correctement tant qu'un administrateur ne sera pas créé pour chaque domaine. (à compléter...)

Après avoir créé correctement un compte administrateur, vous pouvez maintenant laisser vos utilisateurs se rendre sur la page web de login du serveur X-Itools, et demander un compte X-Itools. Tout ce que vous aurez à faire sera d'accepter (ou de refuser) ces requêtes, et d'assigner un profil utilisateur X-Itools à vos utilisateurs.

Référez-vous à la documentation utilisateur pour plus de détails. (lorsqu'elle existera ;-)
Enjoy ;-)