Next: Seriell einloggen Up: Datenreisen und reisende Daten Previous: Technische Voraussetzungen
Next: Seriell einloggen
Up: Datenreisen und reisende Daten
Previous: Technische Voraussetzungen
Rechner, die solche Accounts anbieten, findet man in Mailboxlisten, wie sie in manchen Computermagazinen abgedruckt sind. Die in einigen der folgenden Beispiele aufgeführten Telefonlisten können ebenfalls als Einstieg dienen.
Für eine Datenreise ,,per Anhalter`` benutzt man Programme, die ein einfaches, serielles Terminal emulieren (nachahmen).
Bereits im frühen Unix wurden die zentralen Rechner über externe Geräte bedient. Zuerst waren das elektrische Schreibmaschinen (Teletypes oder tty's), später Bildschirmterminals. Diese Geräte werden seit jeher über eine serielle Schnittstelle mit dem Zentralrechner verbunden.
Noch heute gibt es solche ASCII-Terminals, mit denen sehr günstig aus einem Linux-PC ein System mit mehreren Arbeitsplätzen gemacht werden kann. Die Arbeitsweise der Terminals ist primitiv. Im Prinzip schicken sie jedes auf der Tastatur eingegebene Zeichen unverändert an den Rechner und stellen alle vom Rechner geschickten Zeichen auf dem Bildschirm dar. Die meisten Terminals, z. B. das vt100 von DEC, verstehen bestimmte Sonderzeichen, die sie als Befehle interpretieren und damit z. B. den Cursor positionieren, den Bildschirm löschen, zwischen Einfüge- und Überschreibmodus umschalten und sonst noch allerlei nützliche Sachen machen können.
Die Aufgabe eines ``dummen'' Terminals kann auch von einem Computer übernommen werden. Dazu muß ein Programm gestartet werden, das die Funktionen eines Terminals nachbildet. Außer den Funktionen eines seriellen Terminals bieten die meisten Terminalemulationen noch eine Reihe weiterer Features wie Telefonlisten, Scriptprogramme und Dateitransfer, mit denen den erweiterten Möglichkeiten/Anforderungen dieser Nutzung entsprochen wird.
Die Installation und Konfiguration von minicom ist Sache der
Systemverwalterin.
Das fertig angepaßte Programm wird weitgehend
interaktiv durch Tastaturkommandos bedient. Alle minicom Befehle
werden durch CONTROL-A (^A) eingeleitet![[*]](./icons/foot_motif.gif){kind=icon}
, den Hilfsbildschirm erhält man mit dem
Kommando ^A-Z.
+===================================================================+
| Minicom Command Summary |
| |
| Commands can be called by CTRL-A <key> |
| |
| Main Functions Other Functions |
| |
| Dialing directory..D run script (Go)....G | Clear Screen.......C |
| Send files.........S Receive files......R | cOnfigure Minicom..O |
| comm Parameters....P Add linefeed.......A | Jump to a shell....J |
| Capture on/off.....L Hangup.............H | eXit and reset.....X |
| send break.........F initialize Modem...M | Quit with no reset.Q |
| Terminal emulation.T run Kermit.........K | Cursor key mode....I |
| lineWrap on/off....W local Echo on/off..E | Help screen........Z |
| | scroll Back........B |
| |
| Select function or press Enter for none. |
| |
| Written by Miquel van Smoorenburg 1992/1993 |
+===================================================================+
Die ausführbare minicom Datei sollte in einem Verzeichnis des Suchpfades liegen, der in der PATH Umgebungsvariablen eingetragen ist. minicom muß SUID-root laufen. Ein zusätzliches Programm zur Interpretation von Scriptdateien (runscript) und bei Version 1.4x und früher das Programm keyserv werden im Verzeichnis /etc erwartet. (Die Lokalisierung dieser Dateien wird vor dem Übersetzen der Quelltexte festgelegt und kann in verschiedenen Distributionen variieren.)
In die Datei /etc/termcap sollte ein spezieller Eintrag zur Terminalinitialisierung unter minicom eingefügt werden, mit dem die Darstellung der IBM-Grafikzeichen auf der Console möglich wird:
mc|minicom|mc80x25|termcap entry for minicom on the console:\
:is=\E(U\E[m\E>\E[4;20l:\E[?8;25h\E[?1;5;6;7l:\
:rs=\E(B\E[m\E>\E[4;20l:\E[?7;8;25h\E[?1;5;6l:\
:bc=:as=:ae=:am=:vb=\E(B\007\E(U:\
:tc=console:
Die Verwendung dieses Eintrags kann mit der
Kommandozeilenoption
`-t mc' erreicht werden. Um die Verwendung dieser und anderer
Kommandozeilenoptionen für alle Anwender vorzubestimmen, kann die
Umgebungsvariable MINICOM beispielsweise in der /etc/profile
Datei mit einer entsprechenden Zeichenkette belegt werden.
Der erste Aufruf von minicom muß durch die Systemverwalterin
erfolgen. Dabei ist die Option `-s' (setup) zu verwenden. Auf diese
Weise kommt sie sofort in das Konfigurationsmenü und kann die für alle
Benutzer gültige Grundeinstellung vornehmen.
+=====[configuration]======+
| Filenames and paths |
| File transfer protocols |
| Serial port setup |
| Modem and dialing |
| Screen and keyboard |
| Save setup as dfl |
| Save setup as.. |
| Exit |
+==========================+
Die einzelnen Menüpunkte können mit den Cursortasten oder mit den vom
vi bekannten Tasten j und k angewählt werden, ESC verläßt das Menü. Der letzte Menüpunkt erscheint nur der
Systemverwalterin beim Setup, um das Programm direkt zu verlassen.
+=======================================================================+
| A - Download directory : . |
| B - Upload directory : . |
| C - Script directory : /usr/lib/minicom |
| D - Script program : /etc/runscript |
| E - Kermit program : /usr/bin/kermit -l %l -b %b |
| |
| Change which setting? |
+=======================================================================+
Die Verzeichnisse für Up- und Download müssen vorhanden sein bzw. angelegt werden. Angaben ohne absoluten Pfad werden vom Heimatverzeichnis des aufrufenden Benutzers aus gesucht. Diese Verzeichnisse werden von den Dateitransferprotokollen benutzt, die daraus Dateien lesen, um sie auf einen anderen Rechner zu kopieren (Upload) oder dorthin Dateien schreiben, die sie von einem anderen Rechner erhalten (Download).
Das Scriptverzeichnis enthält die minicom Scriptdateien, beispielsweise für das automatische Einloggen. Loginname und Paßwort brauchen nicht im Script gespeichert werden, deshalb ist es kein Sicherheitsrisiko, hier ein zentrales Verzeichnis auch für die Loginscripts anzugeben.
Das runscript-Programm wird von minicom zur Ausführung der Scripts aufgerufen. Hier kann auch ein beliebiger andere Interpreter eingetragen werden. Die Syntax der Scriptdateien ändert sich natürlich entsprechend. Die Kanäle für Standardeingabe und Standardausgabe sind während der Bearbeitung des Scripts mit dem Modem verbunden, die Fehlerausgabe landet auf dem Monitor.
Mit ^A K kann kermit lokal als Client gestartet werden, nachdem auf der Gegenseite ein kermit-Server die Kontrolle über die serielle Schnittstelle übernommen hat. kermit ist ein klassisches Terminalprogramm mit integriertem Protokoll zum Dateitransfer.
Im File tansfer protocols Menü werden die Programme zur
protokollierten Datenübertragung für den direkten Aufruf aus minicom konfiguriert.
Neben den Bekannten X- Y- Z-Modem Programmen, die unter Unix als Freie Software unter dem Namen rz/sz erhältlich sind, ist in dem Beispiel oben noch kermit als Client zur Datenübertragung aufgeführt.
+==============================================================================+ | Name Program Need name Up/Down FullScr IO-Red. | | A zmodem /usr/bin/sz -vv Y U N Y | | B ymodem /usr/bin/sb -vv Y U N Y | | C xmodem /usr/bin/sx -vv Y U N Y | | D zmodem /usr/bin/rz -vv N D N Y | | E ymodem /usr/bin/rb -vv N D N Y | | F xmodem /usr/bin/rx -vv Y D N Y | | G kermit /usr/bin/kermit -i -l %l -s Y U Y N | | H kermit /usr/bin/kermit -i -l %l -r N D Y N | | I - | | J - | | K - | | L - | | | | Change which setting? (SPACE to delete) | +==============================================================================
Die Gerätedatei, über die minicom das Modem anspricht, sollte immer ein cua? Device sein. Die ttyS? Devices sind für ankommende Verbindungen vorgesehen. Gelegentlich wird wegen der größeren Aussagekraft ein (symbolischer) Link mit dem Namen /dev/modem angelegt, der auf das cua? Device zeigt, an dem das Modem angeschlossen ist. Diese Praxis birgt die Gefahr, den Mechanismus des Device-Locking durcheinanderzubringen, indem einige Kommunikationsprogramme für /dev/cua? konfiguriert sind, andere für /dev/modem. Hier liegt es allein in der Verantwortung der Systemverwalterin, für konsistente Nomenklatur zu sorgen.
+=======================================================================+
| A - Serial Device : /dev/modem |
| B - Lockfile Location: /usr/spool/uucp |
| C - Callin Program : |
| D - Callout Program : |
| E - Baud/Par/Bits : 38400 8N1 |
| |
| Change which setting? |
+=======================================================================+
Das Verzeichnis, in dem die Lockfiles angelegt werden, muß ebenso wie
das Format, in dem diese Dateien vorliegen für alle
Kommunikationsprogramme konsistent gehandhabt werden. minicom
legt seine Prozeß-ID im ASCII Format ab.
Mit Callin/Callout können Programme bestimmt werden, die den Modemport zum Ein- bzw. Auswählen vorbereiten (beispielsweise ein uugetty beenden). Unter Linux sollten solche Methoden zum Device-Sharing nicht verwendet werden.
Weitere Informationen über das Device-Handling finden Sie im Abschnitt über getty.
Die Leitungsparameter können über ein weiteres Menü eingestellt werden.Die Übertragungsgeschwindigkeit ist vom angeschlossenen Modem abhängig. Moderne Geräte mit Datenkompression (MNP5 oder V42bis) werden auf der Modem-Rechner-Verbindung mit einer festen Baudrate angesteuert, die höher sein sollte als der höchste anzunehmende Durchsatz der eigentlichen Modemverbindung. Bei 2400-Baud-Modems reichen 9600 bps in der Regel aus.
+===========[Comm Parameters]============+
| |
| Current: 38400 8N1 |
| |
| Speed Parity Data |
| |
| A: 300 H: None M: 5 |
| B: 1200 I: Even N: 6 |
| C: 2400 J: Odd O: 7 |
| D: 4800 P: 8 |
| E: 9600 |
| F: 19200 K: 8-N-1 |
| G: 38400 L: 7-E-1 |
| |
| Choice, or <Enter> to exit? |
+========================================+
Die maximale Übertragungsrate kann
mit dem setserial-Programm von 38400 bps auf 57600 bps gesetzt werden.
Ältere Modems ohne automatische Baudratenerkennung senden (und empfangen) die Daten mit genau der Übertragungsrate, mit der sie mit dem Rechner verbunden sind. Hier muß also die Einstellung der realen Modemverbindung angepaßt werden.
Die Einstellungen für Bytelänge, Parität und Stopbits sind fast immer 8-N-1 (8 Bit/Byte, keine Parität, ein Stopbit).
Weitere Einstellungen können zur Laufzeit nicht vorgenommen werden. Das RTS/CTS Hardware-Handshaking wird immer automatisch eingeschaltet.
+====================[Modem and dialing parameter setup]=====================+ | | | A - Init string ......... ^MATZ^M | | B - Reset string ........ ^M~ATZ^M~ | | C - Dialing prefix #1.... ATDP | | D - Dialing suffix #1.... ^M | | E - Dialing prefix #2.... ATDP | | F - Dialing suffix #2.... ^M | | G - Dialing prefix #3.... ATX1DP | | H - Dialing suffix #3.... ;X4D^M | | I - Connect string ...... CONNECT | | J - No connect strings .. NO CARRIER BUSY | | NO DIALTONE VOICE | | K - Hang-up string ...... ~~+++~~ATH^M | | L - Dial cancel string .. ^M | | | | M - Dial time ........... 45 P - Auto baud detect .... Yes | | N - Delay before redial . 60 Q - Drop DTR to hangup .. Yes | | O - Number of tries ..... 10 R - Modem has DCD line .. Yes | | | | Change which setting? (Return or Esc to exit) | +============================================================================+
Bei den Hayes-kompatiblen Modems sind die hier dargestellten
Steuerbefehle normalerweise ausreichend. In Spezialfällen müssen die
entsprechenden Sequenzen dem Modemhandbuch entnommen werden.
Wenn das Modem im Auto-Answer-Mode betrieben wird, um die Einwahl in das System zu erlauben, ist es sinnvoll, die DTR-Leitung beim Auflegen ,,Low`` zu setzen (Drop DTR to hangup.. YES), um sicherzustellen, daß das Modem erst Anrufe entgegennimmt, wenn das getty wieder ein DTR-Signal gibt.
+===============[Screen and keyboard]===============+
| |
| A - Command key is : ^A |
| B - Backspace key sends : DEL |
| C - Status line is : enabled |
| |
| Change which setting? (Esc to exit) |
| |
+===================================================+
Von der in diesem Menü angebotenen Möglichkeit, die Tastenkombination
für die minicom-Kommandos von CONTROL-A auf die ALT-Taste zu legen, sollte bei der deutschen Tastatur kein Gebrauch
gemacht werden. Der Tastaturtreiber produziert hier Codes, die von
MINICOM nicht unbedingt korrekt interpretiert werden. Das kann
zu einer Situation führen, aus der nur ein kill(1) wieder
herausführt.
Um den normalen Benutzern den Aufruf von minicom zu erlauben, müssen Sie die Benutzernamen in der Datei /etc/minicom.users eintragen.
+---------------------------[Dialing Directory]----------------------------+ | Name Number Line Format Terminal Script | | 1 LunetIX 030 6235097 38400 8N1 VT100 unixlogin | | 2 INTERW. 030 2513771 38400 8N1 VT100 unixlogin | | 3 Access 030 2513771 38400 8N1 VT100 unixlogin | | | | | | | | | | | | | | | | | | | | | | | | | | | | ( Press Escape to exit.. ) | +--------------------------------------------------------------------------+
Mit den Cursortasten oder den vom vi Editor bekannten Tasten
h, j, k, und l kann im oberen Fenster ein
Eintrag in der Telefonliste ausgewählt (hoch/runter) und im unteren
Fenster eine Aktion für diese Telefonnummer bestimmt werden
(links/rechts). Die Aktion wird ausgeführt, sobald die Wahl mit RETURN bestätigt ist.
Mit Add wird ein leerer Eintrag unter dem aktuellen angelegt. Mit Edit kann der aktuelle Eintrag verändert werden. Dazu erscheint die folgende Maske:
+=======================================================================+
| A - Name : LunetIX |
| B - Number : 030 6235097 |
| C - Dial string # : 1 |
| D - Local echo : No |
| E - Script : unixlogin |
| F - Username : she |
| G - Password : <Passwort> |
| H - Terminal Emulation : VT100 |
| I - Line Settings : 38400 8N1 |
| |
| Change which setting? |
+=======================================================================+
Die meisten Einträge dieser Maske haben aussagekräftige Namen.
Der Dial string wird im ,,Modems and dialing`` Setup-Menü festgelegt. Die Systemverwalterin sollte die Grundeinstellung von minicom so durchgeführt haben, daß Sie hier immer mit dem `` Dial String #1'' auskommen dürften. Local echo ist eine Einstellung für Halb-Duplex-Verbindungen (ein Relikt aus dem Mittelalter der Datenfernübertragung).
Das Script wird unmittelbar nach erfolgreichem Verbindungsaufbau abgearbeitet (Login-Script). Die Einträge Username und Password können im Login-Script verwendet werden.
Wenn Sie einen Eintrag des Wählmenüs mit Dial bestätigen, wählt das Modem automatisch die Telefonnummer und versucht eine Datenverbindung herzustellen. Ist dieser Versuch erfolgreich, wird die login: Meldung der gegenstelle an die lokale minicom-Terminalemulation gesendet. In der Beispielkonfiguration oben wird diese Meldung automatisch durch das unixlogin Script beantwortet. Sie können diese Prozedur natürlich auch von Hand erledigen.Nachdem Sie sich in dem fremden Rechner eingeloggt haben, können Sie dort so arbeiten wie an Ihrem Linux-Rechner.
In einer Scriptdatei für runscript können folgende Befehle verwendet werden:
Das Muster ist eine Zeichenkette wie bei send. Im Muster können keine regulären Ausdrücke verwendet werden.
Das folgende Beispiel ist nicht nur geeignet, die Benutzung
von runscript zu veranschaulichen, es ist überhaupt das
Standardscript zum Einloggen in alle Linux-Systeme.
# Standard UNIX Loginscript.
# Mit diesem Script von Miquel van Smoorenburg kann das Einloggen
# in (fast) alle Linux{\bindestrich} und UNIX{\bindestrich}Boxen automatisiert werden.
#
# Einige Variable
set a 0
set b a
print Trying to Login..
# Irgendjemand hat wohl festgestellt, daß das erste send
# manchmal besser übersprungen wird.
goto skip
loop1:
# Der Loginname wird höchstens dreimal gesendet.
send ""
inc a
skip:
if a > 3 goto failed1
expect {
"ogin:"
"ssword:" send ""
"NO CARRIER" exit
timeout 2 goto loop1
}
loop2:
send "$(LOGIN)"
# Das Passwort wird auch nicht mehr als dreimal gesendet.
inc b
if b > 3 goto failed1
expect {
"ssword:"
"ogin:" goto loop2
timeout 2 goto loop2
}
send "$(PASS)"
# Wenn nicht innerhalb von 3 Sekunden ein "incorrect" ankommt,
# war das Passwort wohl OK. Wenn nach dem Terminal gefragt
# wird, stellen wir vt100 ein.
expect {
"TERM=" send "vt100"
"incorrect" goto loop1
timeout 3 break
}
exit
failed1:
print \nLogin fehlgeschlagen (Falsches Passwort?)
exit
Allerdings können alle Arbeitsresultate, die als Dateien vorliegen, nicht ohne weiteres auf dem lokalen Rechner weiterverarbeitet werden. Bei einem echten vt100-Terminal macht das auch keinen Sinn, weil so ein Terminal eben nur Daten auf dem Bildschirm anzeigen bzw. von der Tastatur lesen kann. Bei einem Linux-Rechner, der ein vt100-Terminal emuliert, ist das eine ernste Einschränkung.
Dateien, die nur druckbare Zeichen enthalten, können theoretisch durch einfache Ausgabeumlenkung in einer Datei gespeichert werden. Der Capture Buffer bietet die Möglichkeit, eine Mitschrift einer kompletten Terminalsitzung abzuspeichern. So eine Mitschrift kann dann anschließend bearbeitet werden, indem beispielsweise einzelne Teile in neue Textdateien kopiert werden.
Viele Dateien enthalten aber nichtdruckbare Zeichen. Um solche Dateien übertragen zu können, werden spezielle Programme benötigt, die für die Dauer der Übertragung den Datenstrom umlenken.
Um auch bei alten Modems ohne automatische Fehlerkorrektur einen zuverlässigen Dateitransfer zu gewährleisten, benutzen die Übertragungsprogramme Protokolle mit Fehlererkennung. Die Datei wird nicht als Ganzes übertragen, sondern in kleinen Stücken. Jedes Stück wird gemeinsam mit einer Checksumme (Cyclic Redundancy Check, CRC) gesendet, so daß der Empfänger die korrekte Übertragung nachprüfen kann. Im Fehlerfall wird das Paket noch einmal angefordert.
Ein beliebtes Transferprotokoll ist mittlerweile in der dritten Generation verbreitet. Die Protokolle sind als X- Y- und Z-Modem bekannt. Die Kommandos rx, rb und rz für den Empfang bzw. sx, sb und sz für das Senden implementieren diese Protokolle unter Linux.
Die Y- und Z-Modem-Protokolle übertragen den Dateinamen gemeinsam mit der eigentlichen Datei. Von den Empfangsprogrammen benötigt deshalb nur rx (X-Modem) einen Dateinamen auf der Kommandozeile. Das Z-Modem-Protokoll verringert die Paketgröße bei hoher Fehlerrate, um den Overhead durch mehrfach angeforderte Pakete zu minimieren. Außerdem werden ununterbrochen Pakete ohne Bestätigung des Empfängers (Acknowledgement, ACK) übertragen. Erst wenn ein Fehler erkannt wird, unterbricht das empfangende Programm den Datenfluß und fordert das fehlerhafte Paket nochmal an. Das Z-Modem-Protokoll zeigt die höchste Übertragungsrate aller Protokolle.
Das kermit-Kommunikationsprogramm benutzt ein eigenes Protokoll zum Dateitransfer. In der hier dargestellten Form wird das Programm so aufgerufen, daß es nur den Dateitransfer durchführt. Auch hier ist wie beim Aufruf des interaktiven Programms darauf zu achten, daß eine .kermrc-Datei im Heimatverzeichnis die korrekten Startparameter setzt.
Die rzsz-Programme unter Linux lesen aus der Umgebungsvariable RZSZLINE den Port, auf dem die Übertragung laufen soll (beispielsweise /dev/cua1). Um eine Dateiübertragung vom Remote- zum Localhost zu starten, wird zuerst auf dem anderen Rechner ein Befehl wie der folgende eingegeben:
$ sz foo.bar.tgz **B00000000000000Dadurch wird das sz (send z-modem) Programm für die Datei foo.bar.tgz gestartet. Die ,,Antwort`` **B00000000000000 kann von anderen Terminalemulationen für den automatischen Start eines Z.Modem Empfangs genutzt werden. Im Fall von minicom muß der Dateitransfer auch auf dem lokalen Rechner manuell gestartet werden. Dazu wird nach dem Tastaturkommando
^A r (receive) das
Z-Modem-Protokoll ausgewählt. Der Fortschritt der Übertragung kann
dann in einem kleinen Bildschirmfenster beobachtet werden. Die
empfangene Datei wird im Downloadverzeichnis abgelegt.
An jedem Ende übernimmt jeweils ein term-Server die vollständige Kontrolle über den Datenfluß auf der seriellen Verbindung. Die lokalen Clients verbinden sich über ein Unix-Domain-Socket mit dem lokalen term-Server. Die beiden Server tauschen Datenpakete aus und bedienen so die Clients auf beiden Seiten. Die beiden Server arbeiten gleichberechtigt, es können von beiden Seiten mehrere Benutzer die Verbindung nutzen.
Der term-Server ist nicht in der Lage, selbst eine Verbindung zu einem anderen Rechner aufzubauen. Um eine term-Session zu starten, muß zuerst eine normale Terminalverbindung hergestellt werden. Dann wird der term-Server auf dem Remote-Host (dem anderen Rechner) im Vordergrund gestartet, indem auf der Kommandozeile das term-Programm aufgerufen wird. Daraufhin übernimmt term die Kontrolle über ,,seinen`` Port. Der Shellprompt wird nicht wieder ausgegeben.
Ohne das Terminalprogramm zu beenden, muß daraufhin auf dem lokalen Rechner der zweite term-Server gestartet werden. Hierbei müssen die Standardkanäle mit dem Modemdevice verbunden werden. Die meisten Terminalprogramme bieten auf die eine oder andere Weise die Möglichkeit, lokale Kommandos mit dieser Umleitung aufzurufen. Hierbei muß aber darauf geachtet werden, daß das Terminalprogramm tatsächlich die Schnittstelle transparent macht, also alle Zeichen aus beiden Richtungen unverändert weiterleitet.
Es ist aber möglich, von einer anderen Shell aus das term-Programm im Hintergrund zu starten, indem beispielsweise die folgende Kommandozeile eingegeben wird:
$ term -v /dev/cua1 2> /dev/null & [1] 12396 $
Wenn beide Server gestartet sind, kann von jeder Shell mit den geeigneten Benutzerrechten ein term-Client gestartet werden.
Mit dem trsh-Client kann eine interaktive Shell auf dem Remote-Host gestartet werden (wie rlogin). Ebensogut kann auch ein einzelnes Kommando remote ausgeführt werden.
Mit tredir können beliebige IP-Ports des lokalen Systems auf Ports des Remote-Host umgelenkt werden. Auf diese Weise können Internetdienste des Remote-Host auch auf dem lokalen Rechner benutzt werden.
Mit tupload können Dateien über die serielle Verbindung kopiert werden.
Der txconn-Client wird auf dem Remote-Host gestartet und richtet ein logisches X11-Display ein. Alle X11-Clients die dieses Display benutzen, werden mit dem lokalen X11-Server verbunden.
Die fertigen Programme müssen in einem Verzeichnis des Suchpfades (PATH) installiert werden. Das kann beispielsweise /usr/local/bin sein. Das Verzeichnis ~/bin geht ebenfalls. Außerdem braucht term das Verzeichnis ~/.term im Heimatverzeichnis des Benutzers. Wenn es nicht existiert, wird es beim ersten Aufruf automatisch erzeugt.
Um die einwandfreie Funktion des Servers zu erreichen, sollte in diesem Verzeichnis eine Konfigurationsdatei namens termrc angelegt werden. In dieser Datei können die folgenden Einstellungen vorgenommen werden (zwischen Option und Argument muß immer genau ein Leerzeichen stehen; leere Zeilen und solche, die mit einem # beginnen, werden ignoriert):
# Beispiel einer ~/.term/termrc-Datei compress off # Für ein Modem mit Datenkompression brauchen die Daten von term # nicht komprimiert zu werden. escape 0-31 escape 128-159 # Diese Einstellung wird für die ersten Versuche empfohlen. # Für eine Linux<->Linux-Verbindung brauchen normalerweise keine # Zeichen ausgeschlossen zu werden baudrate 38400 # Diese Übertragungsrate wird nur bei Textdateien erreicht. # Vorkomprimierte Daten können zu Problemen führen, wenn das timeout # nicht entsprechend hoch eingestellt ist. timeout 100 # (100/20 = 5 Sekunden) ist für Modems ohne Kompression und Korrektur # besser mit 50 anzusetzen. # Bei komprimierenden Modems muß das timeout die Verzögerung zwischen # senden der Daten in den Modempuffer und Übertragung der Daten mit # anschließender Bestätigung überbrücken. window 5 # Es werden bis zu fünf Pakete ohne Bestätigung vorausgeschickt. # Sinnvolle Werte liegen zwischen 2 und 6, bei sehr schnellen # Modems auch höher. #shift 224 # Die ersten 32 Zeichen werden mit dem Bereich über 224 # vertauscht, die anderen werden ein wenig durcheinandergewürfelt. #flowcontrol 500 # Alle 500 Zeichen wird ein Control-Q gesendet, damit ein # versehentlich durch Control-S angehaltener Datenstrom wieder # in Fluß kommt. noise on # Alle Daten (Pakete), deren Checksumme nicht stimmt, werden in den # Standardfehlerkanal geschrieben. #sevenbit # Für den Fall, daß linecheck eine 7-Bit-Leitung feststellt. #seven_in # Wenn nur eine Richtung mit 7-Bit arbeitet, kann dem mit seven_in/ # seven_out Rechnung getragen werden. #seven_out # Die symmetrische Einstellung für die "andere Seite" #ignore 7 # Ein ankommendes Klingelzeichen (ASCII 7) wird ignoriert. #breakout 24 # Fünfmal ^X (Control-X) veranlaßt den term-Server, zu terminieren. # chdir /home/she # Alle trsh-Programme werden in meinem Heimatverzeichnis gestartet. # remote # Mit dieser Einstellung wird einer der beiden Server zum SlaveDie folgenden Umgebungsvariablen können benutzt werden:
Folgende Kommandozeilenoptionen werden erkannt:
Die Überprüfung der Leitungstransparenz kann nicht von term selbst durchgeführt werden. Die notwendigen Informationen müssen vom Anwender in der termrc-Datei abgelegt werden.
Um eine Verbindung zu prüfen, ist im term-Paket das linecheck-Programm enthalten. Dieses Programm muß auf beiden Seiten der Leitung mit der gleichen Umlenkung der Standardkanäle gestartet werden wie der term-Server. Die Fehlerausgabe muß in einer Datei gesichert werden. Das geschieht indem auf dem Remote-Host das folgende Kommando eingegeben wird:
$ linecheck 2> /tmp/lineckeck.log
auf dem lokalen Rechner wird anschließend das folgende Kommando eingegeben (darauf achten, daß das Terminalprogramm nicht nebenherläuft):
$ linecheck </dev/cua1 >/dev/cua1 2> /tmp/lineckeck.log
Wenn beide Programme korrekt gestartet wurden, nehmen sie in einer ersten ,,Handshaking``-Phase Kontakt miteinander auf und senden sich dann gegenseitig in einer festgelegten Reihenfolge alle 256 möglichen Bytes zu bzw. bestätigen deren Empfang. Das dauert ziemlich lange, weil nur ein Zeichen pro Sekunde gesendet wird. Wenn die Übertragungssequenz abgeschlossen ist, geben die beiden Programme jeweils eine Zusammenfassung der gefundenen Übertragungsfehler. Mit dieser Information lassen sich dann die entsprechenden escape Bereiche für die andere termrc-Datei bestimmen.
Ohne weitere Argumente startet trsh eine Shell auf dem Remote-Host, ähnlich wie rlogin. Der Remote-term-Server belegt dazu ein Pseudoterminal (pty).
Wenn ein Kommando angegeben ist, wird dieses Kommando remote ausgeführt. Durch die zusätzliche Option -s wird der Remote-Server veranlaßt, für die Kommandoausführung kein Pseudoterminal zu belegen.
Im Unterschied zu rsh wird die Fehlerausgabe bei trsh mit der Standardausgabe zusammengelegt. Außerdem wird die Verbindung zum Server und damit zum Remote-Kommando sofort unterbrochen, wenn trsh ein EOF (CONTROL-D) in der Standardeingabe findet.
tupload kopiert eine oder mehrere Dateien von dem System, auf dem es aufgerufen wird, auf das andere. Wenn als letztes Argument ein Verzeichnis auf dem Zielrechner benannt ist, werden die Dateien dorthin kopiert.
Wenn eine Datei bereits auf dem Zielrechner existiert, wird automatisch getestet, ob sie kleiner ist als die lokale Datei. In diesem Fall wird davon ausgegangen, daß ein früherer Upload fehlgeschlagen ist, und die Datei wird vervollständigt.
tupload erlaubt folgende Kommandozeilenoptionen:
tredir verbindet lokale TCP-Ports mit Ports auf dem Remote-Host oder auf einem weiteren Internetrechner. Beispielsweise verbindet das Kommando
$ tredir 2000 soho.lunetix.de:23 Redirecting 2000 to soho.lunetix.de:23 $den (unbenutzten) lokalen IP-Port Nummer 2000 mit dem Port Nummer 23 (telnet) auf soho.lunetix.de (das ist nicht unbedingt der Remote-Host). Wenn diese Verbindung hergestellt ist, kann mit dem Kommando
$ telnet localhost 2000 Trying 127.0.0.1... Connected to atlantis. Escape character is '^]'. Linux 0.99.12 (soho) (ttyp0) soho login: _eine ,,umgeleitete`` telnet-Verbindung zu soho.lunetix.de hergestellt werden. (Die Ausgabe von telnet zeigt deutlich, daß die ,,echte`` telnet-Verbindung zum Localhost atlantis besteht. Erst durch die Umleitung wird daraus eine Verbindung mit soho. Auf soho erscheint die Verbindung wiederum so, als sei sie von cicero.lunetix.de (dem Remote-Host) aus hergestellt worden.
Die Portnummern für die well known services sind in der Datei /etc/services aufgeführt. Durch Verbindung eines unbenutzten lokalen Ports mit einem Serviceport auf einem anderen Rechner können die entsprechenden Services vom lokalen Rechner aus benutzt werden.
Um die Ports 1:1 umlenken zu können, dürfen auf dem lokalen Rechner keine Anwendungen die entsprechenden Ports benutzen. Das bedeutet insbesondere, daß der inetd diese Ports nicht überwachen darf. Außerdem dürfen Ports mit Nummern bis 1024 nur mit Rootprivilegien geöffnet werden.
txconn wird typischerweise einmal zu Anfang einer Session auf dem Remote-Host gestartet. Das Programm setzt sich automatisch in den Hintergrund. Dort stellt es ein logisches Display für alle X11-Clients zur Verfügung, das durch den term-Server auf den lokalen X11-Server umgeleitet wird. Normalerweise erhält das logische Display die Nummer 9. Der ,,echte`` X11-Server hat meistens die Nummer 0.
Um die X11-Clients auf dem Remote-Host zu veranlassen, mit dem logischen Display von txconn zu arbeiten, kann das Display auf der Kommandozeile angegeben werden:
$ xterm -title 'xterm auf cicero' -display cicero.lunetix.de:9 & $ _oder das Display wird für alle Clients gemeinsam in der Umgebungsvariablen DISPLAY gesetzt.
$ export DISPLAY=cicero.lunetix.de:9 $ _
tmon fragt in regelmäßigen Abständen vom lokalen term-Server die Anzahl der Clients und den Datendurchsatz ab und gibt die Werte auf dem Bildschirm aus.
Das Linux Anwenderhandbuch