![[Sommaire CICT]](/icones/cict.gif)
![[Logo CICT]](../images/LogoCICT-bleu.gif)
Ce document est destiné aux responsables techniques de services web hébergés au CICT.
Les services WWW du CICT sont fournis par le logiciel apache 1.3.26 (dérivé de NCSA httpd).
Lors de la création du service, les catalogues suivants sont créés sur le compte du gestionnaire :
web/docsweb/docs/statweb/cgi-binweb/logsEn fait web/logs et web/docs/stat
sont non pas des répertoires, mais des liens symboliques vers
des répertoires dans l'espace disque propre au serveur.
Effacer ces liens ne perturbe pas le serveur, mais vous
empêche de consulter les journaux ou les statistiques.
Le CICT a créé une liste de diffusion destinée aux webmasters
des services qu'il héberge. Cette liste est essentiellement
destinée à la diffusion de messages d'annonces concernant les
nouveautés et évolutions du service (nouvelles versions par
exemple), suivies éventuellement de discussions. Son trafic est
généralement faible. Ne posez pas vos questions sur cette liste,
sauf si elles sont d'intérêt général. Les questions doivent plutôt
m'être envoyées directement, et je ferai une réponse à la liste si
elle est d'intérêt général. L'adresse de la liste est la
suivante : webmasters@cict.fr
La liste est gérée par le logiciel sympa, qui propose une interface web pour s'abonner, consulter les archives, etc. On peut s'abonner (et consulter les archives, ...) ici.
L'abonnement est libre. Je recommande chaudement à chaque webmaster de s'abonner pour être tenu au courant des évolutions des services Web au CICT.
La conception des services se fait généralement sur un PC ou un
Macintosh. Pour écrire les documents HTML, utiliser soit un éditeur de
textes si vous êtes informaticien, soit un éditeur HTML spécifique
comme AOLpress, soit un outil avec extensions HTML (Netscape gold,
Word, Claris Works, etc). Structurer les fichiers à votre convenance.
Généralement on crée des catalogues images,
icones, ... Voici de l'aide sur la
réalisation des documents WWW.
Faire attention aux noms des fichiers : le serveur tourne
sous système Unix, et contrairement aux systèmes de Microsoft
ou Apple, les noms de répertoires et de fichiers distinguent
minuscules et majuscules. Si on fait un lien vers
FICH.HTM et que le fichier s'appelle
fich.htm, ça marche sur PC, ça ne marchera pas
sur Unix. Le plus simple est de n'utiliser que des minuscules
(et dans le cas des PC, de s'assurer que les fichiers auront
bien un nom en minuscules après transfert sur le serveur)
Utiliser des liens relatifs entre les documents pour faciliter la
mise au point en local (c-à-d <a href="xyz.html">, pour
référencer un fichier xyz.html, dans le même catalogue, ou
<img src="images/i1.gif"> pour référencer une image
dans le catalogue images).
Lorsque le service est prêt, il faut charger tous les fichiers sur le serveur, au moyen d'un programme client FTP (Fetch 3.0 sur MacOS, WS-FTP sur Windows, ou Netscape). Les programmes spécialisés cités sont plus pratiques que Netscape, mais s'ils ne sont pas installés sur le PC ou Mac, et qu'il y a peu de transferts à effectuer, Netscape convient (je ne sais pas si Internet Explorer a les mêmes fonctions). Pour installer un programme FTP : Fetch (Mac), WS_FTP (Windows 3.1), WS_FTP (Windows 95).
Les fichiers HTML, les images, etc, doivent être installés sous
web/docs (se placer sous ce répertoire avec le client
FTP). Les structurer de la même manière que sur le PC ou Mac, en créant
les répertoires de même nom. On peut créer des répertoires avec le
programme client FTP, mais pas Netscape.
Avec un vrai client FTP, se connecter sur le serveur
www.cict.fr avec le nom d'utilisateur et le mot de passe
que le CICT a donnés. On voit alors apparaître les répertoires
mentionnés plus haut, et on peut changer de répertoire.
Pour utiliser Netscape à la place d'un programme FTP,
demander l'URL suivant
ftp://nom@www.cict.fr (sans barre finale, car
Netscape interprète de manière erronée ce type d'URL). Netscape
demande le mot de passe. Changer de répertoire comme ci-dessus, et
mettre ce répertoire dans le bookmark, pour y revenir facilement par la
suite.
Pour envoyer un (ou plusieurs) fichier(s), sur Mac, on peut le(s) prendre depuis le Finder et le(s) déposer sur la fenêtre de Netscape ou Fetch (sous Windows, je n'ai pas essayé). On peut aussi utiliser la commande Put du menu File (Netscape), ou le bouton Send ou Envoyer de Fetch.
Attention, on ne peut pas utiliser les fonctions de mise à jour du serveur de FrontPage de Microsoft,(elles ne marchent qu'avec le serveur de Microsoft, ou un serveur avec des extensions spécifiques). On peut en revanche composer avec lui des documents HTML.
Les fichiers HTML et les programmes source doivent être transmis sous forme de texte, tous les autres fichiers (images, sons, etc.) sous forme binaire. Penser à régler les options du client FTP pour que les fichiers binaires soient transmis en « binaire brut ».
Les URL correspondant à des répertoires reçoivent un
traitement particulier. Le serveur cherche un fichier nommé
index.html, index.htm,
default.htm, Default.htm,
default.html, ou index.php. C'est en
particulier le cas du répertoire principal du service, dans
lequel il est recommandé de placer un tel fichier (la page
d'accueil du service).
Faire attention aux droits d'accès des fichiers. Le
programme serveur Web n'est pas privilégié, il ne peut accéder
aux fichiers que vous voulez diffuser que si les droits
d'accès sont suffisants. Le serveur est considéré comme un
utilisateur quelconque, il faut donc que les fichiers aient le
droit o=r, et tous les répertoires pour les
atteindre doivent avoir au moins le droit o=x. Il
n'est pas conseillé, sauf cas spéciaux, de mettre
o=rx à un répertoire, car si un fichier
index.htm ou équivalent n'est pas trouvé, le
serveur diffuse la liste des fichiers du répertoire. Dans la
plupart des cas, les fichiers et répertoires envoyés par un
programme FTP ont les accès correct, mais il est parfois utile
de vérifier.
http://www.cict.fr/icons/image1.gif
<map name="map1"> <area shape="rect" href="lien1.html" coords="455,98,509,173"> <area shape="rect" href="lien2.html" coords="507,84,600,175"> <area shape="rect" nohref coords="0,0 600,600"> </map> <img src="images/image1.gif" usemap="#map1">
imagemap intégré au serveur apache. Créer un fichier
xyz.map. Si le fichier est dans le même répertoire que
l'image, coder
<a href="xyz.map"><img src="xyz.gif" ismap ></a>
Il existe des utilitaires pour produire les fichiers « map » ou les éléments « <map> ». Info à venir.
Les scripts CGI permettent d'exécuter sur le serveur une action (un programme), ayant comme résultat un document ou morceau de document HTML (ou autre). Ces scripts permettent de traiter les réponses à un formulaire de saisie par exemple, ou d'inclure des données dynamiques dans un document.
PHP a le même but, mais est réalisé différemment, voir ce document.
Le cas particulier des compteurs est expliqué dans ce document. Il n'y a pas besoin de s'occuper de scripts pour cela.
Le serveur permet aussi d'utiliser les inclusions de données (server side include) dans les documents HTML. Me demander les détails.
Il existe des archives de scripts CGI ou PHP, qu'on peut
récupérer et adapter. Les scripts CGI en shell Unix sont
interdits. Utiliser des scripts en Perl (perl5.004 est
installé) ou en langage compilé (cette dernière méthode nécessite une
petite connaissance d'Unix pour compiler, etc., et n'est pas décrite
par la suite). Les librairies Perl nécessaires aux scripts CGI sont
installées. Mettre avec un client FTP les programmes CGI en Perl
(/usr/local/bin/perl) dans web/cgi-bin, en
les transférant en mode texte. Leur mettre le droit d'accès
rx pour other. Vous pouvez mettre ce droit
directement depuis certains clients FTP comme Fetch (sur Mac). Sinon
il faut se connecter par telnet sur
www.cict.fr, et faire les commandes suivantes :
cwd web/cgi-bin chmod o=rx nom-du-programmeOn doit référencer les URL des CGI avec un lien comme ceci :
/cgi-bin/service/prog/cgi-bin/progLes scripts CGI ou les pages PHP permettent l'envoi de messages, qui sont généralement composés dans un formulaire HTML. Il faut être vigilant avec ces scripts (ou pages). Ils ne doivent pas permettre d'envoyer du courrier anonyme. Si un script permet le choix du destinataire à l'utilisateur du formulaire, il doit être sécurisé (à accès réservé). Le script lui-même doit être sécurisé de façon à ce qu'on ne puisse pas l'appeler en court-circuitant le formulaire.
Les applets Java, et les scripts en Javascript sont destinés à s'exécuter sur le navigateur. Ils peuvent être créés sur n'importe quelle machine, et pour le serveur WWW, ils sont traités comme de simples fichiers au même titre que les fichiers HTML ou les images.
Il existe des solutions à base d'ASP pour les serveurs Apache sous Unix, l'une en logiciel libre, les autres commerciales. La première (Apache::ASP) implante l'interface de programmation (API) des ASP de MS, mais le langage de programmation est Perl, et l'accès aux technologies MS n'est bien sûr pas assuré. Il n'y a donc pas de compatibilité directe entre Apache::ASP et les ASP de MS. Une des solutions commerciales est plus complète, car elle implante sur serveur Unix les technologies COM de MS. Aucune de ces solutions n'est installée sur le serveur du CICT.
L'implantation des servlets et JSP a changé plusieurs fois. Depuis les dernières spécifications, les servlets, JSP, et les autres ressources sont regroupés dans une structure de fichiers hiérarchique constituant une application Web. La structure est imposée.
Tomcat est le serveur délivrant ces applications Web aux clients. La version installée est 4.0.1. Voir la documentation sur tomcat et tout spécialement le document développement d'applications Web. Voir les exemples de JSP et de servlet. Tomcat n'est plus utilisé en complément d'Apache, mais est indépendant.
Une application Web peut être écrite et testée sur une machine de
développement sous Windows, Linux ou Solaris, en installant Tomcat. Il
ne nécessite pas l'installation d'un serveur web. Une fois
l'application testée, elle est installée sur le serveur, en
transférant le répertoire et ses fichiers ou un seul fichier sous
forme d'archive (fichier .war). Contrairement au serveur
WWW où une nouvelle version d'un fichier HTML ou PHP est
automatiquement prise en compte, Tomcat ne prend pas systématiquement
en compte une nouvelle version d'une application Web. Pour cette
raison, il est préférable dans la mesure du possible de ne charger sur
le serveur que des applications au point.
Si vous souhaitez créer une application Web, il faut m'en faire la demande, en précisant le compte utilisateur du gestionnaire du service, pour que Tomcat la prenne en compte. Des instructions vous seront données à ce moment.
logs ou web/logs du
compte sur le serveur, on trouve les fichiers standards produits par le
serveur. On peut les récupérer (ou les voir) par FTP :
Le serveur produit des fichiers en continu qui deviennent
rapidement volumineux. Ils sont donc soumis chaque semaine à
une rotation (changement de nom où chacun prend le nom du
précédent, le plus vieux fichier -d'un mois- étant effacé) et
compressés. Les renseignements obtenus dans
access_log sont exploités automatiquement par le
logiciel créant les statistiques. Il peut être intéressant de
consulter ces fichiers à l'occasion pour enquêter sur un
problème particulier.
access_logups-tlse.fr ou
cict.fr, ce fichier n'existe pas (il y a
un seul fichier global qui est découpé chaque
nuit).access_log.hiererror_log et error_log.hieridem.0idem.1.gz, idem.2.gz, etcerror_log : les gestionnaires de
services sous dans les domaines ups-tlse.fr et
cict.fr peuvent voir les messages d'erreurs
récents, ce qui est utile quand on met au point des scripts,
dans le fichier
/usr/local/www/logs/www-sv/error_log.
Note importante :
On ne voit pas tous les accès au service, ni dans les
fichiers de log, ni dans les statistiques. En effet, entre le client
qui demande un document, et le serveur, il y a des
caches, dont le rôle est d'optimiser le fonctionnement, à la fois pour
le client (ça va plus vite pour lui), et pour le réseau (il y a moins
de transferts). Voir plus de détails.
Avec le système des caches, un document WWW peut être stocké temporairement dans un cache utilisé par le client. Si un autre client se servant du même cache demande ce document, c'est le cache qui le lui donne, et le serveur ne voit même pas de connexion.
On a évidemment la possibilité de dire aux caches qu'il ne doivent pas garder un document particulier, et c'est le cas des documents dynamiques (en php par exemple). Alors toute demande sera adressée au serveur qui comptabilisera la connexion. Mais cela contrarie l'objectif des caches, justement faits pour améliorer les transferts. Et le client, s'il est lointain (au sens Internet), risque de devoir attendre la page, alors qu'il est habitué à des chargements relativement rapides grâce aux caches. Il risque donc de se décourager, et de passer à autre chose avant de l'avoir lue. C'est donc à éviter sur une page d'accueil.
Par défaut, elles sont inaccessibles. On peut demander à les rendre accessibles sans restriction, ou au gestionnaire seul. Bien préciser ce point dans la demande. « Accessible sans restriction » ne veut pas dire qu'il y aura un lien quelque part vers ces statistiques, mais que quelqu'un connaissant l'URL pourra les consulter (cet URL vous sera envoyé). Dans le cas d'un accès réservé, l'accès se fera avec un nom et un mot de passe. Le nom sera le même que le compte Unix. Préciser le mot de passe souhaité (différent du mot de passe du compte Unix).
Voir ce document sur les statistiques.
Les noms et mots de passe sont totalement indépendants des noms et mots de passe Unix, et indépendants d'un site à un autre, ou même d'un répertoire à l'autre. Les noms et mots de passe sont enregistrés dans un fichier (les mots de passe sont évidemment cryptés et non lisibles). Une commande à appeler par telnet permet de créer ou modifier ce fichier et de définir les utilisateurs (voir ci-dessous). Ce fichier doit être dans l'espace disque du concepteur du site, mais pas parmi les fichiers du site Web. Le plus simple est de le mettre dans le catalogue "web". Le nom peut être choisi quelconque, on a pris "users-pw" dans l'exemple suivant.
On protège un répertoire en y installant un fichier de
paramétrage appelé .htaccess (ce
nom est obligatoire). Ce fichier doit référencer le fichier
des utilisateurs créé par ailleurs. Le fichier
.htaccess peut être comme suit
(ce qui est en italique doit être adapté) :
Note 1 : "Utilisateurs enregistrés" est un intitulé qui apparaîtra dans la fenêtre de saisie du nom et du mot de passe par le navigateur. Il faut choisir un intitulé permettant à l'utilisateur du service de savoir quel nom et mot de passe on lui demande. Mettre obligatoirement les apostrophes si l'intitulé contient un ou des espaces.
Note 2 : AuthUserFile donne le nom absolu
(avec chemin d'accès) du fichier des utilisateurs qu'on a
défini. user est le nom du compte utilisé pour gérer le
site, projet est le projet de ce compte. Si vous ne le
connaissez pas, regarder le chemin chemin d'accès au
répertoire principal qui est affiché par les logiciels FTP
lors d'une connexion.
Note 3 : Ce fichier .htaccess
peut être écrit avec un éditeur de textes quelconque et envoyé
sur le serveur par FTP. Attention à ne pas utiliser un éditeur
HTML, mais un éditeur de texte simple comme Wordpad sur
Windows, ou SimpleText sur Mac.
On peut restreindre l'accès à certains des utilisateurs seulement, en mettant :
Pour définir les utilisateurs, se connecter au serveur
www.cict.fr par telnet,
et faire la commande htpasswd, pour chaque
utilisateur. Il faut donner en argument le nom du fichier des
utilisateurs et le nom de l'utilisateur créé ou modifié. La
première fois (et une fois seulement), il faut de plus donner
l'argument -c devant le nom du fichier pour le
créer. Cette commande demande (deux fois) le mot de passe à
créer ou modifier.
Faire attention que les fichiers des utilisateurs et
.htaccess soient lisibles par tous
(other).
On peut protéger plusieurs répertoires du même service par le même fichier de mots de passe, ou en faire plusieurs, selon les besoins.
WebDAV nécessite un serveur HTTP-WebDAV et également des clients compatibles. Il ne suffit pas d'un navigateur. Netscape Composer permet de publier un fichier sur un serveur WebDAV, mais n'offre pas les autres fonctions. Certains outils de composition de pages HTML sont compatibles avec WebDAV, comme Dreamweaver 4. Un logiciel compatible avec WebDAV permet de lire et écrire les fichiers directement sur le serveur. C'est le cas également de nombreux logiciels de Microsoft, l'explorateur Windows et Office 2000. Sur l'explorateur Windows, on voit donc l'espace disque du serveur comme un répertoire, appelé dossier Web, sur lequel on peut appliquer toutes les opérations habituelles de gestion de fichiers (copier/coller/déplacer, supprimer, lire les informations, changer le nom, ...). Sur MacOS, si on ne possède pas de logiciel compatible avec WebDAV, il faut installer un logiciel comme Goliath pour transférer des fichiers avec le serveur WebDAV.
WebDAV permet un certain nombre de choses, mais la plus intéressante est de déléguer la création et mise à jour d'une partie d'un serveur Web à une ou plusieurs personnes qui n'ont pas de compte Unix sur la machine (elles auront seulement un compte pour ce répertoire). Si vous souhaitez utiliser cette possibilité, me le demander.
robots.txt existe sous la racine, et dans ce cas, ils le
lisent. On peut créer un tel fichier et y placer des
instructions pour leur interdire certaines parties du service.
Seuls sont concernés les gestionnaires de service ayant leur
propre nom de domaine, pas les services hébergés par un autre, comme
www.univ-tlse2.fr
Lire ici les détails.
Une extension parfois demandée est l'extension Frontpage. Elle permet de gérer son site à distance à partir du logiciel Frontpage de MS, en évitant de faire les transferts par FTP. Cette extension est intéressante, mais n'est pas installée, et ne peut pas l'être pour diverses raisons, sur le serveur actuel du CICT.
http://www-sv.cict.fr/abc/ sont en cours de migration sous de
nouveaux URL comme http://www.abc.cict.fr/ ou
http://www.abc.ups-tlse.fr/. Les gestionnaires de ces services
ont en principe reçu un message détaillant l'opération.
CICT
Vos commentaires sur ce serveur :
www@cict.fr