Par Chris Gibbs chrisgibbs@geocities.com
Il a été récemment publié un article dans la Linux Gazette intitulé Conception de Pages Web sous Linux. Cet article a provoqué certaines critiques dans les numéros suivants. La principale critique semble être la préférence de l'auteur pour le codage manuel HTML plutôt que l'utilisation d'un éditeur HTML comme l'éditeur HotDog de Windows. C'est une polémique dans laquelle je ne souhaite certainement pas prendre parti. Je ne veux pas non plus gaspiller beaucoup de temps sur le style. Alors que dans la plupart des cas, les utilisateurs veulent simplement un chargement rapide, des pages claires, il y aura toujours une place pour du visuel coloré, d'immenses graphiques et toutes sortes de détails complexes qui demandent une éternité à télécharger sur un modem 28k. Je veux mettre l'accent sur les fonctionnalités passionnnantes que propose Linux. Des fonctionnalités qui sont gratuites et qui coûteraient une fortune à mettre en oeuvre sur d'autres systèmes d'exploitation. En particulier, j'expliquerai comment faire pour que votre ordinateur Linux soit votre propre serveur intranet et ainsi profiter pleinement des possibilités qu'offre Linux pour la conception d'applications destinées au Web.
Je pense qu'un point mérite une explication, qui n'entre pas dans le cadre de cet article, je veux parler de l'extension de Netscape Navigator, Plugger. Dans le passé, de nombreuses personnes se sont plaintes que les extensions de Netscape ne sont en général pas disponibles pour Linux. Le Plugger à l'adresse http://frederik.hubbe.net/plugger.html tente de combler cette lacune en fournissant un support pour de nombreux types audio/vidéo/image.
En guise d'introduction, j'accorderai deux sous d'attention à "l'argument éditeur". Je n'ai encore jamais trouvé un éditeur HTML qui me plaise ! J'écris cet article avec StarOffice 5.0. Je ne l'ai jamais utilisé pour écrire du HTML, c'est donc en quelque sorte un test. Je pense devoir éditer le source lorsque j'aurai fini d'écrire. Un autre éditeur qui semble aussi bon que ceux que j'ai essayés, est la partie Composer de Netscape Communicator. Je trouve cela énervant, très très énervant. Pourquoi ? Parce que j'aime que mon texte soit entièrement justifié. D'accord, je sais que certaines personnes pensent que les justifications complètes `vont à l'encontre de l'esprit HTML', mais personnellement je préfère lire un texte entièrement justifié qu'un texte qui ne l'est pas. Je ne pense pas être le seul à avoir cette préférence.
Ce qui se passe avec Netscape, c'est qu'après avoir passé deux heures à concevoir des pages jusqu'à obtenir satisfaction, je les charge toutes dans vi et je modifie chaque occurrence de <P> en <P align=justify>, ce qui peut prendre un certain temps si j'ai écrit une grande quantité de texte. Maintenant, si un peu plus tard, je veux effectuer certains changements, je charge les pages dans Netscape Composer et je fais mes modifications. Mais alors que Netscape Communicator comprend <P align=justify>, Composer lui, non. En fait, Composer ne permet pas <P align=justify> et modifie chaque occurrence en <P>... La poisse... Je dois rééditer à nouveau toutes les sources à la main. Si je pensais qu'il y avait un quelconque avantage à utiliser Composer, plutôt que d'écrire à la main mon code HTML, j'imagine que je devrais écrire un petit programme pour rechercher <P> dans les fichiers HTML et les remplacer par <P align=justify>. Mais ce n'est pas le seul défaut des éditeurs wysiwyg HTML. Ils ne semblent pas capables de faire exactement ce que je veux, comme je le veux.
Sincèrement, je suis à présent impressionné par StarOffice ! Bien qu'il n'y ait pas de bouton pour obtenir une justification complète, il est facile d'éditer le Style du Corps du Texte de telle sorte que cette justification complète soit automatique. Il est également facile d'indenter automatiquement la première ligne d'un paragraphe, de créer une double ligne d'espacement, etc. Peut-être me convertirai-je après tout, à l'utilisation d'un éditeur wysiwyg pour mon HTML.
Il semble que StarOffice 5.0 n'ait pas la possibilité de définir facilement des listes. Les tableaux sont correctement pris en charge, mais pas les listes. J'imagine qu'il serait possible de définir quelques nouveaux styles pour permettre l'utilisation de différents types de listes, mais on aurait pu penser qu'un bouton serait disponible à cet effet. Aussi, étant donnés les différents types de listes disponibles en HTML, on pourrait trouver que le menu des styles devient encombrant et plus compliqué qu'il n'est nécessaire.
D'accord, des présentations simples sont plus rapidement réalisées avec un éditeur HTML, mais si vous voulez un contrôle complet, vous devez effectuer une édition manuelle, à un moment ou à un autre. A mon avis, si vous voulez écrire du HTML de bonne qualité, vous devez apprendre HTML. C'est une très mauvaise idée de penser que vous pouvez vous dispenser d'apprendre HTML en ayant un éditeur qui fonctionne comme un traitement de texte. Vous n'aurez pas les compétences nécessaires pour produire des pages web de bonne qualité. HTML est très facile à apprendre. Une fois que vous le connaîtrez, vous constaterez que Netscape ou StarOffice fournissent des outils utiles pour vous aider. Mais, de grâce, ne pensez pas que de tels outils suppriment la nécessité de pouvoir écrire du code HTML manuellement.
Il y a un document essentiel à lire si vous voulez produire beaucoup de Pages Web efficacement, il s'agit de HTML 4.0 (W3C:HTML Specification), c'est la Définition du Type de Document complète pour HTML et SGML. Pour une fois, j'ai suivi mon propre conseil et je l'ai lu ! Les problèmes que je mentionne ci-dessus au sujet du formatage de texte ont tous été résolus en ce qui me concerne ! Je consulte le source HTML que StarOffice a donné et bien que je sois impressionné, je ne suis pas satisfait. A nouveau, je pense qu'utiliser un éditeur comme vi ou emacs est en fait meilleur et plus efficace que d'utiliser un éditeur wysiwyg.
La raison en est que HTML 4.0 permet l'utilisation de feuilles de style. Cet article a été créé à l'aide d'une feuille de style, special.css. C'est un document qui explique comment un navigateur devrait interpréter ma page. Tous les navigateurs peuvent accéder à cette page de la manière dont je l'entends. Dans le passé, des auteurs ont été contraints d'utiliser des techniques pour formater leurs pages qui ne pouvaient pas être affichées correctement sur tous les navigateurs. A propos des extensions HTML, la conversion de texte en graphique, l'utilisation d'images pour contrôler les espace vides, l'utilisation de tableaux pour la présentation, et même l'utilisation de programmes, ont toutes été employées pour formater du texte, et toutes ces méthodes causent des difficultés aux utilisateurs et du travail supplémentaire aux développeurs. L'utilisation correcte des feuilles de style évite ces problèmes.
Une fois que vous vous êtes familiarisé avec l'utilisation des feuilles de style
vous vous moquerez du mauvais fonctionnement de Netscape Composer, ou de votre
manque de connaissance de StarOffice, l'utilisation d'un éditeur comme
vi, peut tout à fait être plus simple que l'utilisation d'un programme comme
Hotdog. Chargez ma
feuille de style dans votre éditeur
favori et voyez par vous-même comme il est facile de modifier l'apparence et le
comportement de ce document (ce lien et celui au-dessus sont identiques et sont
appelés special.txt, pour que vous puissiez voir le source sans que le
navigateur l'interprète).
Au moment où j'écris ce document, j'ai réussi à trouver encore un autre navigateur internet pour Linux ! Celui-ci mérite une certaine attention puisqu'il est produit par le consortium W3 (W3C), la même équipe qui a défini les spécifications HTML. En fait, c'est le navigateur qu'ils utilisent pour tester leurs spécifications. Le texte suivant est affiché lorsque vous le démarrez pour la première fois :
est un client Web qui opère à la fois comme navigateur et comme outil de création. Il a été conçu dans le but principal de présenter les nouvelles technologies dans un environnement WYSIWYG. La version actuelle exécute HTML, MathML, CSS et HTTP.
Avec Amaya, vous pouvez manipuler des pages Web riches contenant des formulaires, des tableaux et les caractéristiques les plus avancées de HTML. Vous pouvez créer et éditer des expressions mathématiques complexes à l'intérieur de pages Web. Vous pouvez donner un style à vos documents en utilisant les Feuilles de Style en Cascade. Vous pouvez publier des documents sur des serveurs locaux ou distants avec la méthode Put HTTP. La navigation et l'édition sont intégrées au même niveau. Vous pouvez naviguer et éditer des pages Web en même temps. Pour ce faire, un simple clic déplace simplement le curseur pour permettre d'éditer du texte ; pour suivre un lien vous devez double-cliquer.
Un manuel de l'utilisateur est disponible en ligne. Vous pouvez l'explorer avec le menu Aide (Help), qui affiche chaque section séparément. Vous pouvez aussi l'imprimer : suivez simplement le lien Manuel en Ligne (Online Manual) ci-dessous. Vous obtiendrez la page d'accueil. Construisez ensuite le livre entier avec l'entrée "Créer livre" ("Make book") depuis le menu Spécial et imprimez le résultat.
Il est clair que ce navigateur a certains avantages. La version que j'ai est encore une beta (1.3b), il y a donc quelques imperfections. J'ai remarqué que la boîte de dialogue Fichier - Ouvrir Document (File - Open Document) peut redimensionner sa boîte de fichiers jusqu'à ce qu'elle devienne inutilisable. Il y a aussi que, pour je ne sais quelle raison, tous les répertoires n'apparaissent pas dans la boîte des répertoires. Au moins, on peut spécifier le fichier demandé dans la boite URL ! Le fait que le manuel ne soit pas inclus dans le paquetage est un inconvénient évident pour moi.
Ce navigateur a un côté agréable dans sa manière sympathique d'afficher les pages. Cette page, par exemple, utilise la justification complète du texte, Amaya peut tout à fait fractionner des mots de façon normale si besoin est.
La chose vraiment agréable à propos de ce navigateur est le fait que vous puissiez éditer des fichiers pendant que vous les explorez. Donc, si vous créez un document contenant de nombreuses pages, il est facile de passer de l'un à l'autre. L'inconvénient est qu'il semble n'y avoir aucun moyen d'éditer ou de voir le source du document. Ce que j'aimerais voir dans d'autres navigateurs, c'est la possibilité de créer une "Table des Matières" ; avec Amaya vous pouvez en créer une basée sur les éléments <H...> de votre document. Cela provoquera l'affichage d'une fenêtre séparée et vous permettra de naviguer aisément à travers un document qui n'a pas proprement de liens.
A environ 4,5 Méga octets, c'est probablement une très bonne alternative à StarOffice si vous n'avez pas l'espace disque nécessaire pour ce dernier. Je m'intéresserai certainement au développement futur de ce navigateur. Si vous voulez l'essayer, vous pouvez l'obtenir sur la page d'accueil d'Amaya. De plus, il existe une analyse d'une précédente version d'Amaya parue dans la Linux Gazette il y a quelques années (voir numéro 15). Tout ce que j'ai à ajouter à cette analyse, c'est qu'il y a eu des améliorations. Il semble le même en apparence comme le montrent les photos d'écran. Amaya affiche plutôt bien l'ancien style des pages de Sommaire de Linux Gazette, mais le nouveau style des trois ou quatre derniers numéros est totalement déformé. Lorsque Amaya démarre, il ne cherche plus une page sur son site personnel, et je ne l'ai pas vu planter comme il était décrit. Globalement, il fait du bon travail.
Maintenant que j'ai retiré tout ça de mon système, j'en reviendrai à mon sujet principal. Roulez tambour s'il vous plaît..... Avec Linux, il est facile de construire un système auquel vous pouvez accéder via http. Sonnez trompettes s'il vous plaît.
Même si, comme moi, vous avez une machine seule dans son coin, sans aucun type de réseau, il est facile de démarrer votre navigateur favori et de vous explorer vous-même via http://. Cela signifie que vous pouvez pénétrer dans l'univers passionnant des scripts cgi, des applications client serveur, java, etc... Sans le besoin d'accéder à un réseau "réel", vous pouvez tester n'importe quelle application réseau que vous aimeriez développer pour l'internet. Vous pouvez tester tous les aspects de votre conception web sans vous ruiner en téléphone. Vous pouvez tester des applications en toute sécurité, sachant que vous n'aurez pas à vous soucier des éventuelles erreurs dans votre code, seule la machine que vous utilisez sera en situation de risque, le réseau réel ne sera pas touché, jusqu'à ce que vous décidiez que votre code fonctionne correctement.
La conception de pages web ne consiste pas seulement à mettre du texte/des graphiques et des liens sur l'internet. Il s'agit de plus en plus de fournir des interfaces utilisateur de bonne qualité aux applications réseau, et un moyen de communication efficace. Dans le passé, seules les plus grandes firmes pouvaient s'offrir la mise en oeuvre d'un WAN (réseau étendu). Aujourd'hui n'importe qui possédant un modem et un pc peut se connecter à l'internet, ou configurer son propre intranet (réseau privé qui opère de la même façon que l'internet).
Pour illustrer mes propos, considérons le scénario suivant. Vous possédez un petit bureau de tabac et vous vivez dans un village appelé Minuscule. Le village étant petit, vous n'avez pas beaucoup de clients et vous ne vendez donc pas vos produits en grande quantité. Cela signifie que vous n'achetez pas de grandes quantités à vos fournisseurs et ne pouvez obtenir le type de remises accordées aux commerces plus importants. Mais vous avez beaucoup de relations et d'amis dans d'autres villages similaires qui possèdent aussi leur petit bureau de tabac. Si vous vous réunissiez tous ensemble et que vous commandiez vos marchandises en une seule commande groupée, vous pourriez obtenir de vos fournisseurs les avantages des achats en gros. Le seul problème est de savoir quelle boutique a besoin de quoi à un moment précis. Vous savez que les remises que vous obtiendrez vous permettront d'employer un livreur pour desservir toutes les boutiques tout en permettant à chaque magasin de faire des économies non négligeables.
Comment la conception web sous Linux peut-elle vous aider à résoudre ce problème ?
Le "livreur" a besoin d'informations, quoi acheter, quelle quantité et où livrer. On peut penser à une application de base de données classique. Linux offre de nombreuses solutions de bases de données SQL. Nous voulons garder les coûts les plus bas possible, nous voulons aussi le maximum de sécurité et de fiabilité. Ingres ou PostgreSQL seront donc un très bon choix. Si nous considérons ces systèmes de gestion de bases de données, nous constatons que PostgreSQL propose une interface java. Disons donc que nous concevons une base de données adéquate avec PostgreSQL. Cette base de données sera gérée par une machine qui sera notre serveur.
Ce dont nous avons besoin, c'est la possibilité pour chaque boutique de communiquer avec le serveur pour lui indiquer quel stock nous avons besoin de faire rentrer. Les commerçants n'ont pas besoin de s'y connaître en informatique. Ils ne veulent pas non plus dépenser beaucoup d'argent pour des systèmes informatiques. Du moins, à ce moment, il est peu probable qu'on arrive à les convaincre d'apprendre un système d'exploitation UNIX comme Linux. Les ordinateurs bon marché possèdent déjà Windows. La solution idéale serait celle où chaque boutique pourrait appeler le serveur, le ou la patronne pouvant démarrer son navigateur favori et l'utiliser pour entrer les informations dans le serveur. Le système d'exploitation utilisé par chaque boutique importe peu.
Que doit faire votre serveur ?
La première chose est d'obtenir Apache, de l'installer et de le faire tourner. Apache est un serveur web qui est fourni en standard dans beaucoup de distributions Linux, si ce n'est pas dans toutes. En revanche, il n'est pas toujours évident de l'installer correctement. Il n'existe pas de programme d'installation et il faut donc l'installer à la main. C'est Apache qui permet d'accéder à nous-mêmes via http. Evidemment, nous aurons également besoin de permettre aux machines l'accès distant pour communiquer avec notre serveur, mais ce n'est pas l'objet de ce document.
Une fois qu'Apache tourne, nous pouvons concevoir une application java pour agir comme une interface utilisateur à notre base de données.
Nous pouvons tester à la fois les parties serveur et client de notre application sur notre serveur jusqu'à ce que soyons sûrs de son bon fonctionnement.
Ensuite, tout ce dont nous avons besoin est de permettre aux commerçants de pouvoir appeler le serveur et de bénéficier d'un accès à l'interface java de la base de données par l'intermédiaire de leur navigateur.
L'aspect très intéressant est qu'au stade du test, nous n'avons besoin d'utiliser qu'un seul ordinateur Linux qui agit en même temps comme client et comme serveur.
Si vous ne le saviez déjà, Apache est l'un des serveurs http les plus connus. Un très grand nombre de Fournisseurs d'Accès Internet utilisent Apache pour donner à leurs clients (c'est-à-dire Vous) l'accès à la toile mondiale.
Ce document ne cherche pas à satisfaire aux besoins d'un véritable serveur internet ou intranet. Ce qui m'intéresse ici, c'est d'installer et de faire tourner Apache sur une machine autonome pour que les logiciels client/serveur puissent être testés. Je ne suis pas spécialement intéressé ici par les questions de sécurité. Si vous n'avez pas l'intention d'avoir une connexion réseau permanente alors ça devrait aller. Si vous voulez que d'autres machines puissent avoir accès à votre serveur http, vous devez alors lire toute la documentation appropriée. Une configuration complète d'Apache peut être une opération très compliquée qui n'est pas l'objectif de ce document.
Les distributions Linux actuelles, comme S.u.S.E., ont des exigences particulières pour installer Apache correctement. Pour éviter des confusions, veuillez lire la documentation fournie à la fois avec votre distribution Linux et votre programme Apache. Les étapes suivantes conviendront pour n'importe quelle distribution, mais attention, si votre distribution a des exigences particulières, je ne peux pas être tenu responsable du fait que les fichiers de démarrage de votre système soient devenus inutilisables.
Par exemple je décrirai comment lancer Apache automatiquement au démarrage en ajoutant une ligne à votre fichier /etc/inittab. Alors que certains utilisateurs de Slackware appliqueront cette méthode, ceux de S.u.S.E. trouveront qu'il est préférable d'éditer leur fichier /etc/rc.config de façon appropriée.
Ces étapes prépareront votre machine à l'installation d'Apache. Vous trouverez peut-être Apache déjà installé, les étapes suivantes ne causeront pas de dommages à de telles configurations.
127.0.0.1 localhost
127.0.0.2 Hawklord.Varteg Hawklord
ALL: 127.0.0.1
ALL: 0.0.0.0.
ALL: localhost
ALL: Hawklord.Varteg
Si Apache n'est pas encore installé, trouvez une version pré-compilée et installez-la en suivant les instructions. Vous trouverez les fichiers de configuration localisés dans /etc/httpd et d'autres fichiers installés dans /usr/local/httpd.
Le répertoire /usr/local/httpd/htdocs devrait contenir le manuel de l'utilisateur d'Apache au format html. En fait, ce répertoire deviendra le répertoire racine de votre site http, vous pourrez donc éventuellement déplacer cette documentation ailleurs, par exemple dans /usr/doc/Apache.
Lorsque vous vous connectez sur un site http, par exemple http://linux.org vous vous trouvez à la racine de ce qui peut être une hierarchie très complexe de répertoires. Vous pouvez penser qu'un site http est simplement un système de fichiers tout comme votre propre système racine. Alors qu'il est vrai que pour un utilisateur le site http ressemblera à un système de fichiers classique, la réalité sur le(s) disque(e) dur(s) des serveurs, peut être très différente. Il est important de comprendre les différences et de les utiliser à votre profit.
Sur mon système, le document principal est dans /usr/local/httpd/htdocs, et c'est le répertoire dans lequel tout utilisateur arrive lorsqu'il accède à http://Hawklord.Varteg. Mais il n'y a qu'un seul fichier et pas de sous-répertoires sur mon disque dur. Je ne garde que le fichier index.html dans l'emplacement physique /usr/local/httpd/htdocs. Toute la documentation à laquelle les utilisateurs peuvent accéder est située dans d'autres emplacements sur mes disques durs.
En regardant de nouveau dans /usr/local/httpd vous devriez trouver d'autres sous-répertoires, en particulier cgi-bin et icons. Ces répertoires sembleront être situés à la racine de votre document car ils contiendront des fichiers qui devraient être disponibles pour tout fichier html sur votre site, susceptible de les demander. Pourtant, un utilisateur ne devrait pas pouvoir accéder directement à ces répertoires. Une grande partie de ma documentation est située dans /usr/doc, et je fais apparaitre ce répertoire comme étant /doc sur le serveur http.
Cela signifie que vous pouvez stocker toute votre documentation sur le serveur à des endroits qui vous semblent logiques, vous n'avez pas besoin de copier des fichiers ni même de créer des liens symboliques vers /usr/local/httpd/htdocs. A la place, organisez la manière dont vous voulez faire apparaître votre documentation aux utilisateurs. Vous pouvez aussi avoir des répertoires auxquels les utilisateurs ne pourront pas accéder directement, mais auxquels des documents html peuvent accéder.
Par exemple, le répertoire /usr/doc/ contient
Linux_gazette Howto Ldp java-documentation
Je veux également un accès aux fichiers dans /usr/hobbies/literature et dans /usr/src/java/applets
Je veux que mon site ait la structure suivante :
/ ---> cgi-bin
docs ---> Linux gazette
Howto
Ldp
java-documentation
literature
icons
java_applets
Une telle organisation de votre site http vous évitera bien des maux de tête dans le futur.
/etc/httpd/httpd.conf est le principal fichier de configuration pour Apache. Certaines versions d'Apache et/ou distributions Linux suggèrent que toute information de configuration soit stockée dans ce fichier. D'autres versions suggèrent que vous utilisiez les trois fichiers que je mentionnerai plus loin. Si vous voulez stocker toute l'information dans un fichier, mettez simplement toute l'information dans un fichier, il n'y a pas vraiment de différence entre les deux méthodes. Vous constaterez que les fichiers exemples contiennent des commentaires suffisants pour vous permettre de faire les meilleurs choix pour votre système. Je vais simplement décrire les modifications que vous devez apporter dans le but de rendre Apache opérationnel pour vous. Une lecture attentive des fichiers vous permettra de configurer Apache au mieux pour vos besoins.
Je sais qu'il existe pour Apache un utilitaire de configuration TCL appelé Comanche. Cependant, il est encore dans une étape préliminaire de son développement ; je ne le recommande donc pas aux débutants. Cependant il pourrait se révéler utile pour expérimenter différentes configurations.
Pour chaque ligne des fichiers de configuration, vous pouvez supposer que votre fichier exemple a un contenu correct ou sensé, à moins que je ne le mentionne spécialement. Sauvegardez les exemples avant d'effectuer une quelconque modification !
Veuillez utiliser standalone à moins que vous ne sachiez exactement ce que vous faites.
A moins que vous n'ayez modifié quelque chose, tout est correct, ne changez donc rien.
A nouveau, c'est probablement une erreur que de faire un changement à moins que vous sachiez ce que vous faites.
Cette saisie devrait se rapporter à l'utilisateur que nous avons déclaré plus haut être l'administrateur httpd.
Cette saisie devrait se rapporter au groupe principal que vous avez défini pour l'administrateur httpd.
C'est l'adresse qu'Apache utilisera pour envoyer des e-mails avec des détails concernant les problèmes sur le serveur. L'utilisation de localhost plutôt que Hawklord.Varteg semble être plus fiable.
usr/local/httpd/ devrait pointer sur l'emplacement où vous avez installé les fichiers principaux d'Apache. Il s'agit par défaut de /usr/local/httpd.
Devrait être le nom de domaine pleinement qualifié du serveur, le même que la saisie créée dans /etc/hosts.allow et etc/hosts ci-dessus.
Vous ne devriez pas modifier les saisies concernant les fichiers de log jusqu'à ce que vous vous sentiez capable de les modifier ; cependant, vous pourrez éventuellement jouer avec l'entrée loglevel si vous rencontrez des difficultés.
Ce fichier contient l'information spécifique du site. C'est ici que nous définissons la manière dont votre site apparaîtra à l'utilisateur.
devrait désigner le répertoire sur notre disque dur qui sera le répertoire racine de notre site. Pour notre exemple il s'agit de /usr/local/httpd/htdocs
est le nom du fichier qui devrait être chargé par un navigateur lorsqu'un utilisateur accède à un répertoire sans spécifier de nom de fichier, par exemple http://Hawklord.Varteg/ ou http://Hawklord.Varteg/docs/. index.html est un nom par défaut raisonnable.
Chaque ligne commençant par Alias définira un répertoire virtuel sur notre système. Pour l'exemple ci-dessus, celui-ci devrait comprendre :
Alias /cgi-bin/ /usr/local/httpd/cgi-bin/
Alias /docs/ /usr/doc/
Alias /docs/Linux_gazette/ /usr/doc/Linux_gazette/
Alias /docs/Howto/ /usr/doc/Howto/
Alias /docs/LDP/ /usr/doc/LDP/
Alias /docs/java-documentation/ /usr/doc/java-documentation/
Alias /docs/literature/ /usr/hobbies/literature/
Alias /icons/ /usr/local/httpd/icons/
Alias /java_applets/ /usr/src/java/compiled/
Les documents de rapports d'erreurs sont la réponse que le serveur donne lorsque l'utilisateur tape une URL erronée, ou qu'il essaie d'accéder à un fichier ou à un répertoire d'accès restreint, etc... Apache donne de bons fichiers d'erreurs par défaut, mais vous pouvez outrepasser cette fonction et fournir vos propres réponses. Je conserve mes documents de rapport d'erreurs dans le répertoire /usr/local/httpd/error.
Ce fichier contient les permissions pour les répertoires de notre site. Si, lorsque vous testez votre configuration en démarrant httpd et en faisant pointer votre navigateur sur http://Hawklord par exemple, ou http://localhost (les deux fonctionneront pour l'exemple ci-dessus), vous obtenez une erreur d'accès fichier, alors vous devrez modifier ce fichier. Chaque répertoire de votre site devrait avoir sa propre entrée.
Par défaut, Apache a un jeu de permissions pour le répertoire racine très restreint, et j'ai constaté que les modifications suivantes :
<Directory />
Options All
Order allow,deny
Allow from all
Options FollowSymLinks
</Directory>
ont résolu certains de mes problèmes. Il est important de réaliser qu'un répertoire hérite ses permissions de son répertoire parent. Donc, si vous voulez permettre un accès extérieur à votre site, vous devrez faire très attention lorsque vous définirez les permissions de vos répertoires.
Une fois que vous êtes satisfait de l'installation et de la configuration d'Apache, vous voudrez le tester ! Connectez-vous à votre machine en tant que root. Au prompt tapez :
#: httpd &
Vous pouvez maintenant vous connecter à votre machine en tant qu'utilisateur normal, démarrez votre navigateur préféré et entrez l'URL http://localhost. Si tout fonctionne bien, vous devriez charger le fichier du site Apache index.html. Ceci à moins que vous n'ayez déplacé la documentation d'Apache et fourni votre propre index.html dans /usr/local/httpd/htdocs.
Lorsque vous serez satisfait du bon fonctionnement du tout, vous voudrez sûrement que httpd démarre au lancement du système. Quelques distributions Linux, comme Red Hat ou S.u.S.E. peuvent présenter un script pour lancer Apache dans leur répertoire init.d. Si c'est le cas, vous n'aurez alors qu'à activer le script pour sys V init de la manière habituelle.
Une alternative est d'ajouter la ligne suivante à votre /etc/inittab
ap:45:once:/bin/su --command=/usr/sbin/httpd
`ap' doit être un identifiant unique. `45' se rapporte aux niveaux d'exécution auxquels la commande sera exécutée. `once' est certainement plus sûr à utiliser que `respawn' puisque, s'il y a une erreur dans cette ligne, vous verrez de nombreux messages d'erreurs ;-(
La dernière partie de la ligne '/bin/su --command=/usr/sbin/httpd', a pour but de démarrer Apache comme un processus appartenant à wwwrun. Il serait sage de tester cette commande avant de la mettre dans votre /etc/inittab.
Si Apache fonctionne, et que vous avez une installation de Linux volumineuse, vous voudrez sans doute envisager la mise en oeuvre d'un moteur de recherche. S.u.S.E. Linux fournit htdig, et en fait pour bénéficier pleinement du Système d'Aide de S.u.S.E., vous aurez besoin d'un programme comme htdig. Le seul problème est l'espace disque dont vous aurez besoin. J'ai une partition de 1 Giga réservée à la documentation, ce qui peut sembler énorme à beaucoup d'utilisateurs ! J'ai une importante documentation personnelle, la documentation des programmes (de plus en plus en HTML), tous les numéros de Linux Gazette, la documentation de Gimp, la documentation java, etc... Cela occupe environ 500 Mega. La base de données que htdig utilise occupe entre 200 et 300 Mega sur mon système. Pour actualiser la base de données, j'ai besoin de 200 à 300 Mega de libres dans /tmp. En fait, lorsque je mets à jour la base de données, je modifie l'emplacement de /tmp puisque je n'ai pas assez d'espace sur ma partition racine. Maintenant, puisque j'ai organisé toute la documentation pour la rendre disponible sous Apache, elle est entièrement référencée dans la base de données de htdig. Si j'ai une question à propos d'un aspect quelconque de Linux, ou de sujets personnels, tout ce que j'ai à faire est de formuler un modèle de recherche adéquat. Je ne peux décrire exactement les gains de temps que j'en ai retiré ! Dans le passé, j'aurais eu besoin d'accéder à des newsgroups pour trouver des réponses à mes problèmes. Avec htdig, je peux éviter cela 99,9 % du temps ! Etant donné le coût très bas des disques durs, le fait que la documentation des programmes actuels soit habituellement proposée en html, et que la plus grande partie de la documentation en général soit disponible en html, il est intéressant d'utiliser Apache conjointement à un moteur de recherche afin d'avoir un système de récupération d'informations efficace.
Htdig peut être imparfait, si vous êtes habitué à Infoseek ou à Lycos, c'est un peu ennuyeux car vous ne pouvez pas rechercher une phrase comme par exemple "démarrage du serveur x". A la place, il recherche un document qui contiendrait tous les mots que vous avez entrés. Un avantage est que les mots qui s'y rapportent sont également recherchés, par exemple si vous cherchez `auto', vous pourrez aussi obtenir les résultats `autos' et `automobile'. Une fois que vous êtes habitué(e) à utiliser htdig, il devient un outil indispensable. Le temps qu'il vous fait gagner pour la recherche d'information vaut bien le coût de l'espace disque (sur mon système, le coût réel est d'environ 250 Méga, bien que j'ai besoin temporairement de 250 Méga supplémentaires pour la reconstruction de la base de données).
Pour terminer, je mentionnerai le fait que Linux supporte le SGML (Standard Generalized Markup Language, NdT: Langage Normalisé de Balisage Généralisé), qui n'est en général pas considéré comme une partie de la conception de pages web, puisque la plupart des utilisateurs chez eux, voudront simplement pouvoir créer leurs propres pages d'accueil HTML et n'ont pas d'autre utilisation de tels documents.
Cependant, un très grand nombre de personnes voudront produire des documents dans différents formats. Le même document devrait être disponible à la publication aussi bien comme un livre, comme une page d'info ou comme des pages web. Le Projet de Documentation Linux (LDP) contient de nombreux documents qui sont disponibles dans différents formats selon les besoins des utilisateurs.
SGML permet à une source unique de produire de nombreuses sortes de formats de texte. Les descriptions suivantes de paquetages sont tirées directement de la distribution S.u.S.E. 6.0., cependant elles devraient être disponibles pour d'autres distributions :
SGML-Tools est un paquetage de formatage de texte basé sur SMGL (Standard Generalized Markup Language), qui permet de produire du LaTeX, de l'HTML, du GNU info, du LyX, du RTF, et de l'ASCII (par l'intermédiaire de groff) depuis une source unique.
Ce système est conçu pour l'écriture de documentations de logiciels techniques, par exemple les documents Linux HOWTO. Il serait utile pour toutes sortes de documentation imprimée et en ligne.
SGML-Tools n'est pas capable de traiter des documents SGML de façon arbitraire ; dans un tel cas, faites un essai avec jade_dsl et écrivez vos propres scripts DSSSL (prenez le paquetage docbk30 comme exemple).
Jade est une implémentation de DSSSL (Document Style, Semantics and Specification Language) ; prononcez-le "disseul".
Il sait traiter les formats SGML, RTF, MIF, TeX, et HTML.
L'analyseur "nsgmls" et les outils d'aide comme "sgmlnorm", "spam", "spent", et "sx", sont maintenant inclus dans le paquetage séparé "sp".
Vous trouverez la documentation dans /usr/doc/packages/jade_dsl/.
Les outils de ce paquetage fournissent la possibilité de gérer des documents SGML et XML.
Il contient l'analyseur `nsgmls' et les programmes de support `sgmlnorm', `spam', `spent', et `sx'. `sx' est un outil utile de conversion de SGML à XML, la nouvelle norme WWW. Vous trouverez la documentation pour tous les programmes dans /usr/doc/packages/sp/.
`gf' de Gary Houston est une abréviation pour "general formatter" ("formateur général"), c'est-à-dire qu'il peut fonctionner sur des documents qui utilisent la définition de type de document "générale" ISO (DTD). Il peut convertir des documents SGML conformément à un petit nombre de DTD dans des formats de sortie variés : LaTeX, ASCII, RTF et Texinfo. Cependant tous les formats de sortie ne peuvent être générés pour chaque DTD.
En dehors de la DTD générale, gf supporte la DTD HTML utilisée dans le projet WWW et la DTD Snafu de Gary. `gf' n'est pas prévu pour être un système flexible pour le développement d'un formateur pour une DTD aléatoire, mais comme un système de production de documents utilisable pour quelques DTD.
Avec le paquetage de macros de Sébastien Rahtz `jadetex', il est possible de traiter la sortie du générateur Tex de Jade (jade_dsl). Il en résulte des fichiers DVI affichables, par exemple avec `xdvi' ou imprimables comme tout autre fichier DVI.
Je n'ai pas d'expérience particulière avec SGML et je laisserai donc au lecteur l'appréciation de ces paquetages. Pour certaines personnes, ils s'avéreront être des outils indispensables à la production de pages HTML.
Copyright ©1999, Chris Gibbs. Paru dans le numéro 43 de la Linux Gazette de Juillet 1999
Traduction française de Joëlle Cornavin