Page suivante - Page précédente - Table des matières

12. Configurer Linux pour accepter les connexions

Linux est un système d'exploitation puissant qui présente beaucoup de flexibilité dans sa configuration. Le coût de cette flexibilité se retrouve dans la mise au point de la configuration souhaitée. Avant d'être en mesure d'accepter les connexions AX.25, NetRom ou Rose, vous devez vous poser un certain nombre de questions. La plus importante : "Que vais-je laisser de visible aux utilisateurs une fois connectés ?" Des gens ont mis au point de sympathiques petites applications qui fournissent des services aux appelants tels pms ou, plus évolué, node (tous deux sont compris dans le paquetage des utilitaires AX.25). Vous pouvez également souhaiter offrir une invite d'identification afin que les utilisateurs disposent d'un shell ou même écrire vos propres programmes tels une base de données maison ou un jeu. Quoi que vous fassiez, il faut spécifier à AX.25 le programme à exécuter quand une connexion s'établit.

Le démon ax25d joue un rôle similaire à celui rempli par inetd pour les connexion TCP/IP entre machines UNIX. Il se met à l'écoute des connexions entrantes et lorsqu'il en détecte une, il examine par l'intermédiaire d'un fichier de configuration le programme à lancer auquel il transmet la connexion. Puisqu'il s'agit d'un outil standard de gestion des appels AX.25, NetRom et Rose, je vais à présent décrire les étapes de sa configuration.

12.1 Le fichier /etc/ax25/ax25d.conf

Ce fichier contient la configuration du démon ax25d en charge des connexions AX.25, NetRom et Rose.

Bien que le fichier paraisse un peu cryptique au premier abord, il s'avère rapidement des plus simples à l'usage, avec quelques pièges à éviter.

Le format général du fichier est le suivant :

# Je suis un commentaire qu'ax25d ignorera
[nom de port] || <nom de port> || {nom de port}
<interlocuteur1> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args>
<interlocuteur2> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args>
parametres window T1 T2 T3 idle N2 <mode>
<interlocuteur3> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args> ...
default    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <commande> <args>

Avec :

#

en début de ligne pour indiquer un commentaire ignoré du programme ax25d

<port_name>

nom du port AX.25, NetRom ou Rose tel que spécifié dans un des fichiers /etc/ax25/axports, /etc/ax25/nrports ou /etc/ax25/rsports. Le nom du port est entouré par `[]' s'il s'agit d'un port AX.25, `<>' si c'est un port NetRom ou `{}' pour un port Rose. Ce champ admet une variante qui précède le nom du port par `callsign/ssid via' pour indiquer que vous voulez accepter les appels vers l'identificateur cité par l'intermédiaire de cette interface. Un exemple l'illustrera.

<peer>

est l'identifiant du noeud auquel la configuration s'applique. Si vous ne spécifiez pas de ssid, tous seront considérés comme valables.

window

paramètre de fenêtre AX.25 (K) ou valeur de MAXFRAMDE pour cette configuration.

T1

délai de retransmission de trame (T1) exprimé en demi-secondes.

T2

délai d'attente par le logiciel AX.25 d'une seconde trame avant de préparer une réponse. S'exprime en secondes.

T3

délai d'inactivité avant qu'une connexion inactive ne soit coupée. S'exprime en secondes.

idle

période d'inactivité en secondes.

N2

nombre d'essais de retransmission avant qu'une connexion ne soit coupée.

<mode>

procure un mécanisme d'établissement de certains types de permissions. Les modes sont activés ou inhibés grâce à une combinaison de caractères représentant chacun un droit. L'accentuation ne joue pas et les caractères doivent former un bloc ininterrompu.

u/U

UTMP - non-supporté

v/V

Validate call - non-supporté

q/Q

Quiet - pas d'enregistrement des connexions

n/N

check NetRom Neighbour - non-supporté

d/D

Disallow Digipeaters - les connexions doivent être directes

l/L

Lockout - connexion interdite

*/0

marker - marqueur, pas de mode spécifique

<uid>

userid sous laquelle le programme maintenant la connexion sera exécuté.

<cmd>

nom complet de la commande à lancer, sans arguments.

<cmd-name>

texte qui apparaîtra à l'invocation de ps comme commande du programme (en général la même chose que <cmd> mais sans le chemin d'accès).

<arguments>

arguments de ligne de commande passés à <:cmd> lorsqu'il est lancé. Les éléments suivants permettent de passer des informations utilisées :

%d

nom du port recevant la connexion

%U

identificateur AX.25 de l'extrémité connectée, sans ssid, en majuscules

%u

identificateur AX.25 de l'extrémité connectée, sans ssid, en minuscules

%S

identificateur AX.25 de l'extrémité connectée, avec ssid, en majuscules

%s

identificateur AX.25 de l'extrémité connectée, avec ssid, en minuscules

%P

identificateur AX.25 du noeud distant initiateur de la connexion, sans ssid, en majuscules

%p

identificateur AX.25 du noeud distant initiateur de la connexion, sans ssid, en minuscules

%R

identificateur AX.25 du noeud distant initiateur de la connexion, avec ssid, en majuscules

%r

identificateur AX.25 du noeud distant initiateur de la connexion, avec ssid, en minuscules

Ue section au format précédent est requise pour chaque interface AX.25, NetRom ou Rose que vous voulez voir accepter des connexions.

Le paragraphe comprend deux lignes particulières, l'une commençant par la chaîne `parameters' et l'autre par la chaîne `default' (il y a une différence).

`default' couvre tous les cas qui ne sont pas spécifiés ailleurs. Ainsi, tous les appels sur l'interface <interface_call> ne disposant pas d'une règle spécifique se retrouvent dans la rubrique `default'. En l'absence d'une telle section, toutes les connexions hors règle sont immédiatement interrompues sans autre forme de procès.

`parameters' est plus subtil et dissimule le piège mentionné précédemment. Si le caractère `*' est présent dans un champ, une valeur par défaut issue de la section `parameters' est employée. Le noyau possède d'ailleurs une liste de valeurs utilisées en l'absence de `parameters'. Le danger réside en ce que les entrées spécifiées via `parameters' ne s'appliquent qu'aux règles qui les suivent. Une même interface peut comporter plusieurs entrées `parameters'. Notez que les règles `parameters' ne permettent pas de positionner les champs `uid' et `command'.

12.2 Un exemple de fichier ax25d.conf

# ax25d.conf pour VK2KTJ - 02/03/97
# Ce fichier de configuration utilise le port AX.25 défini plus haut.
# <peer> Win T1  T2  T3  idl N2 <mode> <uid> <exec> <argv[0]>[<args....>]
[VK2KTJ-0 via radio]
parameters 1    10  *  *  *   *   *
VK2XLZ     *     *  *  *  *   *   *    root  /usr/sbin/axspawn axspawn %u +
VK2DAY     *     *  *  *  *   *   *    root  /usr/sbin/axspawn axspawn %u +
NOCALL     *     *  *  *  *   *   L
default    1    10  5 100 180 5   *    root  /usr/sbin/pms pms -a -o vk2ktj
[VK2KTJ-1 via radio]
default    *     *    *   *   *   0    root /usr/sbin/node node
<netrom>
parameters 1    10  *  *  *   *   *
NOCALL     *     *  *  *  *   *   L
default    *     *  *  *  *   *   0        root /usr/sbin/node node
{VK2KTJ-0 via rose}
parameters 1    10  *  *  *   *   *
VK2XLZ     *     *  *  *  *   *   *    root  /usr/sbin/axspawn axspawn %u +
VK2DAY     *     *  *  *  *   *   *    root  /usr/sbin/axspawn axspawn %u +
NOCALL     *     *  *  *  *   *   L
default    1    10  5 100 180 5   *    root  /usr/sbin/pms pms -a -o vk2ktj
{VK2KTJ-1 via rose}
default    *     *    *   *   *   0    root /usr/sbin/node node radio

Dans cet exemple, toute personne réclamant une connexion via l'identificateur `VK2KTJ-0' du port AX.25 `radio' se verra appliquer les règles suivantes :

Tout appel depuis un identifiant `NOCALL' se verra rejeté. Notez l'emploi du mode `L'.

La ligne parameters modifie deux paramètres par défaut du noyau (Window et T1) et exécutera /usr/sbin/axspawn. Les instances de /usr/sbin/axspawn appelées ainsi apparaîtront en tant que axspawn dans un affichage issu de ps. Les deux lignes qui suivent définissent deux stations auxquelles s'appliqueront les permissions.

La dernière ligne de la section est la règle fourre-tout appliquée au reste des connexions (VK2XLZ et VK2DAY inclus dès lors qu'ils ont recours à un ssid différent de -1). Tous les paramètres prennent leurs valeurs par défaut et le programme pms sera lancé avec un argument de ligne de commande spécifiant une connexion AX.25 d'identifiant VK2KTJ (reportez-vous à la partie `Configuration du PMS' pour davantage de détails).

La configuration suivante accepte les appels à VK2KTJ-1 via le port radio. Le programme node est exécuté à chaque connexion.

Vient ensuite une spécification de connexions NetRom (notez l'emploi des signes inférieur et supérieur à la place des crochets). Toute personne se connectant via le port `netrom' déclenche le programme node si son identifiant est différent de `NOCALL'. Dans le cas contraire, tout accès est refusé.

Les deux dernières configurations concernent des connexions entrantes Rose, la première pour ceux qui appellent le `VK2KTJ-0' sur notre noeud Rose et la seconde pour ceux qui emploient le `VK2KTJ-1'. Elles fonctionnent de la même façon. Notez l'emploi des accolades qui indiquent des ports Rose.

L'exemple manque un peu de naturel mais je crois qu'il illustre clairement les propriétés importantes de la syntaxe du fichier de configuration. La page de man explique dans son intégralité le contenu du fichier ax25d.conf. Le paquetage ax25-utils inclut un exemple plus détaillé qui pourrait également vous être utile.

12.3 Lancer ax25d

Une fois les deux fichiers de configuration mis au point, lancez la commande : 

# /usr/sbin/ax25d
À présent, les gens devraient pouvoir se connecter en AX.25 à votre machine. N'oubliez pas de modifier les fichiers de commande de démarrage du système de façon que ax25d soit invoqué automatiquement à chaque réinitialisation de la station.

Page suivante - Page précédente - Table des matières