----------------------------------------------------------------------------
3.2.1. Affichage
Si les codes de controle console de LINUX sont utilises,
a l'affichage les
codes de caracteres IBM sont utilises. Aucune conversion
des umlaut ne sera
faite. Si un termcap est utilise un umlaut IBM sera converti
suivant le
parametre UMLAUT.
Si UMLAUT est ON, l'umlaut IBM est converti en umlaut
Latin-1 8-bit.
Si UMLAUT est OFF, il est converti en une representation
a deux caracteres
("ae").
----------------------------------------------------------------------------
3.2.2. Envoi d'un texte
Si UMLAUT est OFF, tous les umlauts entres seront convertis
en une
representation a deux caracteres ("ae"). Si UMLAUT est
ON, les umlauts ne
seront pas convertis et seront envoyes comme un umlaut
IBM.
----------------------------------------------------------------------------
3.2.3. Reception de fichiers
Seuls les fichiers log (LOGREC, LOGSND, LOGQSO, LOGMON
et LOGXMON) sont
affectes par la conversion des umlaut. Si UMLAUT est
ON, l'umlaut IBM est
converti en un umlaut Latin-1 8-bit. Si UMLAUT est OFF,
il est converti en
une representation a deux caracteres ("ae").
----------------------------------------------------------------------------
3.2.4. Envoi de fichiers
Seuls les fichiers log (SENDLOG) sont affectes par la
conversion des umlaut.
Si UMLAUT est ON, l'umlaut Latin-1 8-bit est converti
en un umlaut IBM.
Si UMLAUT est OFF, il est converti en une representation
a deux caracteres
("ae").
----------------------------------------------------------------------------
3.3. Utilisation des fonctions UNIX
----------------------------------------------------------------------------
3.3.1. Shell login
TNT permet aux utilisateurs distants de se loguer sous
UNIX comme un
utilisateur normal. Toute reception de donnee est traitee
comme un entree
dans le shell, toute donnee venant du shell est transmise
a la station
distante.
Pour utiliser le login shell, il est necessaire de demander
la permission au
superutilisateur root de TNT.
Sinon, le login shell est desactive.
Le shell peut etre demande par l'operateur en utilisant
la commande SHELL
et TSHELL ou par la station distante en utilisant la
commande distante
//SHELL et //TSHELL.
Il est possible d'executer tous les programmes qui sont
autorises a
l'utilisation depuis un shell.
Au moment du login, il est recherche si l'indicatif de
la station distante
a un identificateur-utilisateur valide. Si il n'existe
pas, dependant du
parametre 'unix_new_user' dans le fichier init, un nouvel
identificateur-
utilisateur est cree ou le user-ID specifie par 'remote_user'
est utilise.
Dans tous les cas, l'indicatif est sauve dans la variable
d'environnement
'CALLSIGN'.
Pour certaine configuration, il peut etre interressant
de lancer un shell
avec des permissions root. Cela peut etre fait avec les
commandes ROOTSH
ou, a distance //ROTTSH ou alors TROOSH et //TROOTSH
pour une conversion
CR/LF. Donner un acces super utilisateur au systeme est
tres dangereux,
a utilser donc avec beaucoup de precautions.
Pour augmenter les performances, pour le shell et la redirection,
toute
donnee venant du shell ou de la console redirigee sera
bufferisee.
Cela signifie que les donnees ne sont pas renvoyees directement,
mais si le
buffer contient 256 Octets (la longueur maximum des paquets
en AX25) ou que
pendant un temps specifique aucune donnee n'a ete recue.
Ce temps peut etre
configure dans le fichier d'init.
----------------------------------------------------------------------------
3.3.2. Redirection
L'ecran de connexion de TNT accepte aucun des caracteres
de controle
standards utilise par les programmes orientes ecran.
Si vous utilisez une
connexion Ax25 pour travailler avec un programme tel
(par exemple utilisant
TSHELL sur une autre station TNT) vous pouvez utiliser
la redirection
(commande REDIR) vers une des consoles virtuelles. A
partir de la, les
codes de controle sont interpretes correctement et vous
pouvez travailler
avec le programme comme si vous etiez directement connecte
sur le systeme
distant.
REDIR permet de rediriger toutes les donnees d'un canal
Ax25 vers tous les
devices connus par le systeme comme mes consoles virtuelles
Linux /dev/ttyX
ou une des deux parties de tty/pty.
Il n'y a pas de conversion de caracteres, toutes les donnees
sont envoyees
au device de maniere tranparente et vice versa. Comme
pour le login-shell
toutes les donnees sont bufferisees avant transmission.
----------------------------------------------------------------------------
3.3.3. Programmes run
Pour les utilisateurs qui ne sont pas a l'aise avec UNIX,
l'utilisation d'un
shell est assez compliquee. Pour cela, des commandes
run sont implementees,
qui executent un programme specifique utilisant un shell.
Si vous n'aimez pas faire tourner TNT en permission root
et que le login
shell est desactive, les commandes run permettent d'executer
un programme
specifique par la station distante.
Un repertoire specifique 'run_dir' contient tous les
programmes
executables. Les programmes dans les autres repertoires
ne pourront pas etre
executes grace a cette commande.
Comme aucun login n'est etabli, le programme est execute
en utilisant
l'utilisateur par defaut specifie par 'remote_user'.
Si TNT n'a pas ete lance par le superutilisateur root,
l'utilisateur ne
pourra pas etre change.
Dans ce cas, le programme est sous la permission de l'identificateur-
utilisateur avec lequel TNT a ete lance.
L'indicatif de l'utilisateur est enregistre dans les
variables d'environnement
'CALLSIGN' et 'LOGNAME'. L'indicatif avec SSID est disponnible
avec la
variable d'environement 'CALLSSID'.
Dans la plupart des cas, il est demande de convertir les
LF UNIX en CR Packet
Radio et vice versa. Si aucune conversion de caracteres
a l'envoi ou a la
reception n'est faite, la commande RUNT doit etre utilisee.
Comme pour le
login-shell, les donnees sont bufferisees avant transmission.
----------------------------------------------------------------------------
Si votre systeme est utilise par plusieurs personnes ou
fait partie d'un
reseau, vous voulez peut etre donner acces au packet
radio a ces utilisateurs.
Ou si vous voulez utiliser des programmes sur votre systeme
il faut creer
une connexion Ax25 exterieure. Pour permettre ca, la
fonction serveur
socket (commande SOCKET) est implementee.
Il y a trois types de serveurs, AXSERV, AXSPEC et NETCMD.
AXSERV et AXSPEC
sont similaires, il representent tous les deux un serveur
Ax25.
AXSPEC n'utilise pas la methode normale de bufferisation
des donnees utilisee
pour le login-shell, mais envoie directement les donnees
lors d'un
caractere LF ou CR.
NETCMD est compatible avec un serveur Wampes et autorise
l'utilisation
de programmes ecrits pour Wampes (comme conversd) avec
TNT.
Tous les serveurs nescessitent une adresse socket, elle
peut etre de deux
formats differents:
a. Unix-sockets
Le format pour un socket-Unix
est 'unix:<chemin_nomdusocket>' ou
'local:<chemin_nomdusocket>'.
Le chemin peut etre complet, debutant
par un '/' ou un chemin
relatif a 'tnt_dir'.
Exemple:
unix:/tcp/socket/convers
b. INET-sockets
Le format pour un socket-INET
est 'adresse_IP:port'. 'adresse_IP' peut
correspondre a un nom
de host (hostname), une adresse IP ou un '*'
pour toutes les adresses
IP. Port peut etre n'importe quel numero
de port valide ou nom
de service.
Exemple:
*:3600
199.199.10.10:ftp
foo.bar.com:2000
3.3.4.1. Serveur Ax25
Un utilisateur local peut se connecter a ce serveur avec
la commande
'telnet localhost:numero_de_port'. Alors le login avec
indicatif et
mot de passe est execute. Apres s'etre logue avec succes,
l'utilisateur
est connecte au serveur Ax25 et utilise un canal du TNC
pour des connexions
packet radio. Les commandes sont assez simples, une aide
utilisateur est
disponible. Les informations de login sont stockees dans
le fichier
'tnt_passfile' et sont independantes du ficher de mots
de passe.
3.3.4.2. Serveur Netcmd
Le serveur Netcmd fonctionne de maniere compatible avec
Wampes. Apres
connexion sur le socket, le serveur est en mode commande
et accepte
trois commandes : ASCII, BINARY et CONNECT. Toutes les
autres entrees
ou mauvais parametres entraine un arret de la procedure.
ASCII entraine une conversion LF vers CR avant les transmission
vers le
cote Ax25 et vice versa. C'est le mode par defaut.
BINARY entraine une liaison transparente sans modification des caracteres.
CONNECT lance une connexion Ax25 sur un canal libre. Elle
demande des
parametres supplementaires , le syntaxe est :
CONNECT <mode_de_transport> <indicatif_destination> [indicatif_source]
La seule valeur valide pour 'mode_de_transport' est AX25,
les autres modes
entrainent la fermeture de la connexion. L'indicatif
de destination ne
comporte pas de repeteurs. TNT utilise la fonction x-connect
pour generer
la connexion, par consequent le chemin est defini dans
la base de donnees
de routage. Par defaut l'indicatif specifie avec la commande
SOCKET est
utilise mais un indicatif source different est declare
avec la commande
CONNECT, celui-ci sera utilise. Une mise a jour des SSID
est effectuee
automatiquement pour autoriser plusieurs connexions avec
la meme destination.
Apres l'aboutissement de la connexion, le serveur passe
en mode data et
toutes les donnees recues sont transmises vers le socket,
toutes les donnees
recues sur le socket sont transmises cote Ax25.
Lorsque la procedure de connexion n'aboutit pas, le serveur
est deconnecte
sans aucune explication suplementaire.
----------------------------------------------------------------------------
3.3.5. Serveurs sockets
Vous devez avoir quelques serveurs socket installes sur
votre systeme.
Pour donner un acces utilisateur packet radio a ceux-ci,
la fonction
connect-socket est disponible. Le seul parametre nescessaire
est
l'adresse socket que vous voulez connecter. L'adresse
socket utilise
la meme syntaxe que pour le serveur socket.
Comme pour les autres fonctions Unix, il y a une option
pour transformer
CR en LF et inversement (cmd SOCKCON, remote //SOCKCON)
ou la possibilite
pour une connexion transparente (cmd TSOCKCON, remote
//TSOCKCON).
Du fait qu'il n'y a pas de restrictions d'acces sur le
socket, vous devez
faire attention avec cette commande. L'acces total aux
sockets doit etre
reserve au sysop. Les users ne doivent acceder qu'au
sockets specifiques
definis par de commandes a distance etendues ('tnt_extremotefile')
----------------------------------------------------------------------------
3.4. Methodes de transferts de fichiers
----------------------------------------------------------------------------
3.4.1. Transfert de fichier AutoBIN
Pour transferer facilement des fichiers binaires sans
trop d'entetes mais
avec un controle de securite, le protocole AUTOBIN a
ete cree.
Il est implemente dans beaucoup de programmes packet
radio. C'est pour cela
qu'il l'est aussi dans TNT. Pour utiliser l'autobin,,
les commandes
SENDABIN, READABIN et LOGABIN sont disponibles pour l'operateur
et //WPRG et
//RPRG pour l'utilisateur distant. De plus, le protocole
AUTOBIN demarre
automatiquement apres une reception valide des entetes
AUTOBIN.
A la fin d'un transfert reussi, le temps passe et le
Baudrate effectif sont
affiches. Si un fichier a ete recu, le checksum recu
et le checksum calcule
seront aussi affiches. Normalement ces informations statistiques
sont aussi
envoyees a la station distante. Dans le cas ou LOGABIN
ou AUTOBIN sont actives
les informations statistiques seront uniquement affiches
(pour eviter toute
confusion sur des BBSs).
Si le transfert est interrompu, la connexion perdu ou
que le calcul
du checksum n'est pas egal au checksum recu, le fichier
recu sera place dans
un repertoire special : 'abin_dir'. De plus, le nom est
change en un nom unique.
Il est utile de nettoyer le repertoire de temps en temps.
La plupart du temps, ces fichiers corrompus n'ont aucun
interet, dans les
rares cas ou ils sont utiles, ils sont conserves dans
ce repertoire.
----------------------------------------------------------------------------
3.4.2. Tranfert de fichier Yapp
Le transfert AutoBIN est utilise generalement en allemagne.
Le reste du
monde utilise plutotle transfert Yapp. D'un point de
vue technique, Yapp
et son extension Yapp-C est la meilleure solution pour
transferer des
fichiers binaires et doit etre doit etre privilegie.
Dans TNT, les commandes READYAPP et SENDYAPP sont disponnibles,
les
commandes pour les utilisateurs distants //READYAPP et
SENDYAPP.
Pour valider la reception automatique de fichiers Yapp,
il est possible
de mettre AUTOYAPP a "ON". Tous les fichiers recus automatiquement
sont
enregistres dans le repertoire 'yapp_dir', defini dans
le fichier tnt.ini.
----------------------------------------------------------------------------
3.4.3. Reception de fichiers 7plus
Si vous recevez beaucoup de fichiers 7plus, vous voulez
les enregistrer
directement dans un repertoire special. Cela peut etre
fait en mettant
la fonction AUTO7PL a "ON". A partir de ce moment, tous
les fichiers
recus sont enregistres dans 'tnt_7plus_dir', defini dans
tnt.ini.