webmaster@smeserver.fr
| Présentation |
| Accueil |
| Historique |
| Généralités |
| Matériel nécessaire |
| Traduction |
| FAQ aef |
| Installation |
| Première phase |
| Console du serveur |
| Administration |
| Gestionnaire de mots de passe |
| Gestionnaire du serveur (v6) |
| Templates |
| Astuces et howtos |
| Communication |
| Forum Ixus.net |
| Newsgroups |
| IRC |
| Divers |
| Recherche |
| Liens utiles |
| Informations serveur |
| À propos du site |
 |
UtilitéVous avez besoin de modifier manuellement la configuration de votre serveur, d'installer une nouvelle application ou, mieux, de créer un RPM spécifique qui s'intégrera parfaitement dans le système ? Vous allez donc sûrement avoir besoin de maîtriser les templates propres à SME. Cette page va donc vous permettre de comprendre le fonctionnement des templates pour une utilisation simple. Cependant, si vous avez des besoins poussés dans ce domaine, je ne saurais trop vous conseiller d'étudier l'excellente documentation développeur (en anglais). |
Kesako da templates ?Les templates, que l'on pourrait traduire par gabarit (pour les mécaniciens) ou patron (pour les couturières) consistent en fait en un découpage structuré des fichiers de configuration basé sur le module PERL Text::Template. Ce qui signifie donc qu'un fichier tel que smb.conf (fichier de configuration de Samba) se trouve en deux exemplaires sur le disque :
En fait, comme nous le verrons par la suite, les fichiers de configuration sont générés à partir de tous les fragments constituant les templates. |
Intérêt des templatesÇa, c'est la question que tout le monde se pose au début : pourquoi aller s'embêter à modifier ou créer des templates alors que la seule modification du fichier de configuration pourrait suffire ? Un élément important est que les templates peuvent soit contenir le texte à intégrer dans le fichier de configuration, soit un programme développé en PERL, soit une combinaison des deux. D'autre part, les templates peuvent regénérer les fichiers de configuration en fonction de certains événements, afin que ces-dits événements soient pris en compte en temps réel par les différents services. Allez, zou, un p'tit café, le temps que vous digériez ça, parce qu'au début, ce n'est pas forcément évident à assimiler. Mais une fois que l'on voit de quoi il retourne, on imagine plus facilement la puissance potentielle que cela apporte et les nombreuses possibilités que cela ajoute au système. En bref, on comprend mieux pourquoi "s'embêter" à devoir passer par eux pour la configuration. Un autre élément majeur est l'existence de quelques fichiers qui regroupent l'ensemble des informations de
configuration. Pour faire une mauvaise analogie, on pourrait voir cela comme la base de registre de SME. |
Etude de casPrenons par exemple le fichier /etc/dhcpd.conf qui a le mérite d'être assez simple et complet. Pour rappel, il s'agit du fichier de configuration du serveur DHCP qui permet d'affecter les paramètres IP aux machines clientes de votre réseau (en fait, sa fonction importe peu ici) : cat /etc/dhcpd.conf
#------------------------------------------------------------
# !!DO NOT MODIFY THIS FILE!!
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at http://www.contribs.org/development/
#
# Copyright (C) 1999-2006 Mitel Networks Corporation
#------------------------------------------------------------
authoritative;
ddns-update-style none;
subnet 192.168.134.0 netmask 255.255.255.0
{
option broadcast-address 192.168.134.255;
deny bootp;
option domain-name "smeserver.fr";
option domain-name-servers 192.168.134.1;
default-lease-time 86400;
max-lease-time 604800;
option subnet-mask 255.255.255.0;
range 192.168.134.65 192.168.134.250;
option routers 192.168.134.1;
}
Et voici la liste des fichiers qui ont permis de créer ce fichier : cd /etc/e-smith/templates/etc/dhcpd.conf/ ll total 80 -rw-r--r-- 1 root root 144 nov 21 05:28 02setupRange -rw-r--r-- 1 root root 54 nov 21 05:28 02setupWinsServer -rw-r--r-- 1 root root 724 mar 1 06:53 04TakePPTPDAddresses -rw-r--r-- 1 root root 15 nov 21 05:28 10Authoritative -rw-r--r-- 1 root root 24 nov 21 05:28 10DDNS-Update-Style -rw-r--r-- 1 root root 272 nov 21 05:28 20BeginLocalSubnet -rw-r--r-- 1 root root 276 nov 21 05:28 25Broadcast -rw-r--r-- 1 root root 77 fév 17 04:41 25DenyBootp -rw-r--r-- 1 root root 59 nov 21 05:28 25DomainName -rw-r--r-- 1 root root 45 nov 21 05:28 25DomainNameServers -rw-r--r-- 1 root root 43 nov 21 05:28 25LeaseTimeDefault -rw-r--r-- 1 root root 45 nov 21 05:28 25LeaseTimeMax -rw-r--r-- 1 root root 108 nov 21 05:28 25NetbiosDDServer -rw-r--r-- 1 root root 108 nov 21 05:28 25NetbiosNameServers -rw-r--r-- 1 root root 153 nov 21 05:28 25NetbiosNodeType -rw-r--r-- 1 root root 51 nov 21 05:28 25Netmask -rw-r--r-- 1 root root 73 nov 21 05:28 25Range -rw-r--r-- 1 root root 230 nov 21 05:28 25Routers -rw-r--r-- 1 root root 3 nov 21 05:28 29EndLocalSubnet -rw-r--r-- 1 root root 834 jui 19 2005 60StaticEntries On y voit un certain nombre de fichiers dont le nom commence par un numéro à 2 chiffres (ce n'est pas obligatoire, mais cela permet de bien structurer le fichier résultant), suivi d'un terme mnémotechnique permettant de deviner aisément son contenu. Certains de ces fragments ne contiennent que quelques lignes qui seront directement intégrées au fichier final sans le moindre traitement. C'est le cas par exemple du fragment 10Authoritative qui n'introduit qu'une seule ligne dans le fichier final : cat 10Authoritative authoritative; D'autres fichiers, en revanche, contiennent des instructions en PERL que l'on distingue aisément puisqu'elles sont situées entre accolades {} ; ce sont d'ailleurs les seuls éléments interprétés en PERL dans les templates. Notez que si vous devez obtenir des accolades dans le fichier final, vous devrez les "échapper" dans le fragment de template : \{ et \}. Intéressons-nous maintenant à la dernière ligne de notre fichier de configuration : option routers 192.168.134.1; Cette ligne est générée par le fichier 25Routers dont voici le contenu : cat 25Routers
{
my $router = (defined $SystemMode && $SystemMode =~ /servergateway/)
? $LocalIP :
defined $GatewayIP ? $GatewayIP : undef;
$OUT = "";
if ($router)
{
$OUT .= " option routers $router;";
}
}
Les amateurs de PERL reconnaîtront des éléments qui leurs sont familiers. Pour les autres, voici une description simplifiée de ce que fait ce script :
A ce niveau, on est en droit de s'interroger sur l'existence et le contenu des variables $SystemMode,
$LocalIP et $GatewayIP qui semblent ne venir de nulle part... Si, dans ce fichier, on recherche les lignes contenant le nom de nos variables et on découvre ceci : grep SystemMode /home/e-smith/db/configuration SystemMode=servergateway grep LocalIP /home/e-smith/db/configuration LocalIP=192.168.134.1 grep GatewayIP /home/e-smith/db/configuration On voit donc que la valeur de SystemMode est égale à servergateway (en effet, mon serveur est configuré en serveur et passerelle), que LocalIP vaut 192.168.134.1 (c'est bien l'adresse IP locale de mon serveur) et que GatewayIP n'est pas défini dans le fichier (il n'y a pas de passerelle externe définie). Tout ceci est donc parfaitement cohérent puisque le script 25Routers nous a bien renvoyé la valeur de l'adresse IP locale du serveur. Enfin, pour réaliser l'opération d'assemblage des fragments de template, on utilise un petit programme prévu à cet effet : expand-template, en indiquant le fichier de configuration à régénérer. Pour notre exemple avec /etc/dhcpd.conf, il suffirait donc de taper : expand-template /etc/dhcpd.conf Ainsi, à chaque changement de la configuration de dhcpd (ie. modification des valeurs dans /home/e-smith/db/configuration), il suffira d'un appel à expand-template et un redémarrage du service dhcpd pour que les nouveaux paramètres soient pris en compte. Ce genre de mécanisme est mis en oeuvre de façon totalement transparente pour l'utilisateur à chaque modification faite à partir des interfaces de configuration de SME (la console ou le gestionnaire du serveur). Sympa, hein ? |
Personnalisation des fichiers existants (cas N°1)Imaginons que pour une raison ou pour une autre, vous ayez besoin de modifier un élément dans un fichier de configuration. Nous allons étudier ici un cas très simple : Modification de la valeur de HostnameLookups dans le fichier de configuration
/etc/httpd/conf/httpd.conf afin de connaître le nom canonique des machines accédant au service Apache, plutôt
que leur adresse IP (valeur par défaut).
Une rapide étude du fichier de configuration /etc/httpd/conf/httpd.conf permet d'identifier la valeur que l'on souhaite modifier : grep HostnameLookups /etc/httpd/conf/httpd.conf # HostnameLookups: Log the names of clients or just their IP numbers HostnameLookups off Sachant que ce fichier de configuration est "templatisé", il nous faut connaître le fragment de template correspondant à cette option afin de savoir comment modifier la valeur de l'option HostnameLookups : cd /etc/e-smith/templates/etc/httpd/conf/httpd.conf
grep HostnameLookups *
05NoHostLookups:# HostnameLookups: Log the names of clients or just their IP numbers
05NoHostLookups:HostnameLookups { ${'httpd-e-smith'}{HostnameLookups} || 'off'; }
Nous voyons donc que c'est dans le fichier 05NoHostLookups que se gère la valeur qui nous intéresse. Vous pouvez visualiser ce fichier pour en connaître l'intégralité, mais seule la dernière ligne est importante. Nous voyons qu'en fait cette valeur dépend de la propriété HostnameLookups de la variable httpd-e-smith. Si cette propriété n'existe pas, elle prend par défaut la valeur off, ce qui est cohérent avec la configuration initiale de SME. Vous comprenez que nous allons devoir initialiser la valeur de cette propriété à on. Nous allons donc devoir modifier la base de donnée de configuration de SME. Fort heureusement, les développeurs nous ont fournit quelques outils d'administration fort pratiques, avec notamment le script db qui permet de modifier tous les éléments de la configuration propre à SME. Si vous souhaitez avoir plus d'informations à ce sujet, vous pouvez consulter cette page décrivant les options de la commande db. Notez, en plus, que la commande config est un alias de db configuration qui permet de travailler directement sur le fichier /home/e-smith/db/configuration. Mais revenons à nos moutons... Nous voulons donc (re)définir la propriété 05NoHostLookups de la clé httpd-e-smith. S'agissant d'un service de base, cette clé se trouve dans /home/e-smith/db/configuration. Par simple curiosité, regardons les propriétés attachées à cette clé : config show httpd-e-smith
httpd-e-smith=service
TCPPort=80
access=public
status=enabled
Nous allons maintenant définir la nouvelle propriété et nous assurer qu'elle a bien été prise en compte (cette dernière opération n'est pas utile dans un cas réel) : config setprop httpd-e-smith HostnameLookups on
config show httpd-e-smith
httpd-e-smith=service
HostnameLookups=on
TCPPort=80
access=public
status=enabled
Nous pouvons maintenant régénérer le fichier /etc/httpd/conf/httpd.conf et vérifier que notre modification a bien été prise en compte : expand-template /etc/httpd/conf/httpd.conf grep HostnameLookups /etc/httpd/conf/httpd.conf # HostnameLookups: Log the names of clients or just their IP numbers HostnameLookups on Il ne reste plus alors qu'à relancer le service httpd-e-smith pour qu'il prenne en compte ce nouveau paramètre : /etc/rc7.d/S*httpd-e-smith sigusr1 Sending USR1 signal to httpd-e-smith [ OK ] Vous pourrez constater dans /var/log/httpd/access_log que, maintenant, ce sont bien les noms canoniques des postes clients qui apparaissent au lieu de leurs adresses IP. |
Personnalisation des fichiers existants (cas N°2)Autre cas très simple où nous allons modifier la configuration du service dhcpd : Ajout d'un serveur DNS dans l'option domain-name-servers du fichier de configuration
/etc/dhcpd.conf.
La chose la plus simple à faire serait de modifier directement le fichier
/etc/e-smith/templates/etc/dhcpd.conf/25DomainNameServers. Sa base existe déjà : il s'agit du répertoire /etc/e-smith/templates-custom/ que l'on architecturera exactement de la même façon que /etc/e-smith/templates/ en fonction de nos besoins. Ainsi, pour notre modification, il va falloir :
On peut alors constater dans le fichier /etc/dhcpd.conf que notre option domain-name-servers
possède bien la valeur que nous lui avons indiqué et que le fichier que l'on vient de créer a bien été pris en
compte à la place de son original dans le processus de régénération. On peut même envisager que ce serveur supplémentaire soit configuré par l'intermédiaire de la propriété d'une clé. Notre fichier /etc/e-smith/templates-custom/etc/dhcpd.conf/25DomainNameServers pourrait alors ressembler à ceci : option domain-name-servers { $LocalIP }{ ${ma_cle}{ma_propriete} && ", ".${ma_cle}{ma_propriete} };
|
Mise en place d'un nouveau service (cas N°3)Attention, il ne s'agit ici que d'un aperçu de ce qu'il est possible de faire : ce n'est en aucun cas un exemple
à suivre car il est largement incomplet. Mise en place d'un service de news (NNTP).
Avant toute chose, je suppose que les RPM de inn et de inews sont déjà installés. config set innd service access public status enabled TCPPort 119 Cette commande nous crée une nouvelle entrée dans /home/e-smith/db/configuration de la forme : innd=service|TCPPort|119|access|public|status|enabled Ce qui signifie qu'il existe un service innd dont l'accès est public, qu'il est autorisé à être exécuté et dont
l'accès depuis l'extérieur sera ouvert via le port TCP 119. Dans l'absolu, on peut même imaginer la création d'une page de configuration de ce service dans le gestionnaire du serveur qui permettrait de gérer plusieurs autres paramètres propres à ce service (mais on sort un peu trop de notre sujet, là)... Puisque nous procédons à une installation spécifique à SME, il va falloir templatiser les fichiers de configuration utiles à ce service selon nos besoins. La plupart de ces fichiers se trouvant dans /etc/news/, nous devons créer l'arborescence des templates de chaque fichier à "templatiser". Par exemple, si nous ne nous intéressons qu'aux deux fichiers inn.conf (paramètres de base du service) et subscriptions (liste des newsgroups gérés par le service) : mkdir -p /etc/e-smith/templates/etc/news/inn.conf /etc/e-smith/templates/etc/news/subscriptions On peut imaginer une découpe par "chapitres" ou par ligne du premier fichier et, pour le deuxième, un script PERL
qui récupérerait la liste des différents newsgroups dans /home/e-smith/db/configuration et les mettrait en
forme, conformément à la structure du fichier résultant. A suivre... Nous voyons bien dans cet exemple l'interaction qu'il peut exister entre les différents services et l'intérêt d'une base de donnée centralisée pour la configuration globale du serveur : l'information n'existe qu'en un seul exemplaire (on limite les risques d'erreurs) et est exploitable par tous les services imaginables. |
PERLComme nous l'avons vu, les templates reposent entièrement sur le langage PERL. La maintenant célèbre commande expand-template n'est d'ailleurs en fait qu'une interface utilisateur de la fonction processTemplate inclue dans le module PERL esmith::templates. En fait, plusieurs modules sont particulièrement exploités par SME, dont :
Comme je ne maîtrise pratiquement pas ce langage, je vous recommande la lecture de bons ouvrages sur le sujet si
vous souhaitez vous lancer dans l'intégration d'applications sous SME. |
FinalitéComme je l'ai vaguement évoqué, l'intérêt réel des templates, c'est de déployer et de configurer facilement un service sur un système SME. On voit donc que ces templates s'inscrivent dans un ensemble homogène constitué de :
Pour en revenir à notre exemple avec le serveur NNTP, on peut tout à fait imaginer la possibilité de démarrer, redémarrer ou arrêter le service nntpd et le service masq par l'intermédiaire d'une page spécifique dans le gestionnaire de serveur. C'est d'autant plus facilement imaginable que c'est ce qui se passe déjà lorsque l'on configure les accès par SSH, PPTP, et FTP dans la page "Accès à distance", par exemple. Sinon, comme vous pouvez vous en douter, ce mécanisme est d'une redoutable efficacité lorsqu'il s'agit d'avoir des éléments répétitifs dans les fichiers de configuration. Le cas des fichiers de configuration de Apache, ProFTPd ou Samba en sont d'ailleurs de remarquables exemples. |
RecommandationsQuelques petits conseils pour la route :
Voilà, j'espère que cette introduction aux templates vous aidera dans la configuration "évoluée" de votre serveur et qu'il a su vous convaincre qu'il s'agit là d'un système qui vaille la peine de s'y investir au moins un peu... Pour la suite de votre formation sur ce système, je vous recommande d'étudier les différents templates existants,
la commande db et enfin les fichiers composant le gestionnaire de serveur situés dans
/etc/e-smith/web/. |
|
smeserver.fr Site consacré à la distribution Linux SME Server Site sous licence Creative Commons (by, nc, sa) |