Next: UUCP - Das Internet der
Up: Datenreisen und reisende Daten
Previous: Kontaktaufnahme
Subsections
Mit dem gleichen technischen Equipment, das für eine Terminalsession
auf einem anderen Rechner notwendig ist, läßt sich die umgekehrte
Verbindung aufbauen. Das Modem kann so eingestellt werden, daß es
ankommende Anrufe ,,beantwortet`` (Auto-Answer-Modus). Ein
ankommender Anruf muß durch eine Loginprozedur zur
Benutzeridentifikation beantwortet werden, die schließlich eine Shell
mit den entsprechenden Rechten startet.
Zu diesem Zweck wird normalerweise von init ein getty-Prozeß für den seriellen Port gestartet.
Für Linux gibt es mindestens vier verschiedene getty-Programme.
- agetty
- von Wietse Venema aus Peter Orbaeks Utility-Sammlung.
Das ist das einfachste getty für Linux. Es erfüllt seine Aufgabe
- auf ,,seinem`` Port einen Login: Prompt auszugeben und das
login-Programm zu starten, sobald etwas auf diesem Port empfangen
wird - zuverlässig, nicht mehr und nicht weniger.
- getty_ps
- von Paul Sutcliffe (ps) in der Linux-Version von Kris
Gleason. Dieses getty benutzt eine gettydefs Datei wie das
getty von System V. Ein zusätzliches uugetty ist speziell
für die gemeinsame Benutzung einer seriellen Leitung für ein- und
ausgehende Verbindungen vorbereitet. Die über Konfigurationsdateien
und Kommandozeilenoptionen realisierbaren Variationen sind vielfältig
und decken praktisch alle denkbaren Einsatzbedingungen ab. Weil das
natürlich höhere Anforderungen an die Systemverwalterin stellt, kann
das sowohl als Vor- als auch als Nachteil gewertet werden.
- mgetty
- von Gert Doering. Neben der direkten Unterstützung ein-
und ausgehender Verbindungen bietet dieses getty die
Möglichkeit, ankommende FAX-Sendungen zu bearbeiten. mgetty ist
klein und einfach; es werden allerdings alle wesentlichen
Einstellungen in die Binärdatei eincompiliert. Das bedeutet in der
Regel, daß das mgetty speziell für das lokale System extra
übersetzt werden muß.
- modgetty
- von Walter Pelissero in der Linux-Version von Olaf
Titz (hier nur der Vollständigkeit halber erwähnt).
Dieses kann mit bestimmten Modems auch als Anrufbeantworter
arbeiten, sowie FAXe empfangen. Es ist über eine eigene
Scriptsprache programmierbar,
dadurch sehr flexibel aber etwas komplizierter in der Handhabung.
Ein wichtiger Unterschied zwischen den getty-Versionen kommt
unter dem Blickwinkel des Devicehandling zum Vorschein.
Das grundsätzliche Problem besteht darin, daß einerseits die serielle
Modemleitung ständig vom getty Überwacht werden soll, um
eingehende Modemverbindungen anzunehmen, andererseits soll mit dem
gleichen Modem eine ausgehende Verbindung aufgebaut werden können.
Die seriellen Schnittstellen werden durch die
Gerätedateien /dev/ttyS0, /dev/ttyS1,
/dev/ttyS2
usw. im Filesystem dargestellt. Diese ,,normalen`` Devices blockieren
ein Programm, das versucht, eine dieser Dateien zu öffnen, so lange,
bis das Modem auf der ,,Carrier-Detect``-Leitung eine bestehende
Verbindung signalisiert. Durch einen speziellen Parameter
beim Aufruf des open(2) Systemcall kann diese Blockierung auch
umgangen werden.
Wenn beispielsweise der UUCP-Dämon eine Modemverbindung aufbauen will
und dazu das Modem über eine Gerätedatei anspricht auf der bereits ein
getty wartet, wird die Verbindung zwar aufgebaut aber nach
wenigen Sekunden wieder unterbrochen. Das dem Modemport wartendes
getty kann nicht zwischen den Zeichen unterscheiden, die
einerseits vom Modem an den Rechner, andererseits vom UUCP-Dämon an
das Modem geschickt werden. Deshalb stört das getty die
UUCP-Verbindung durch einen Loginprompt was schließlich zu einer
Unterbrechung der Verbindung führt. Um das getty daran zu
hindern, kann es nicht einfach durch ein kill()-Signal
ausgeschaltet werden. In diesem Fall würde init sofort ein neues
getty starten. Also müßte die Datei /etc/inittab
entsprechend verändert und das init mit kill -1 von dieser
Änderung informiert werden, definitiv kein gangbarer Weg.
Die seit Kernel-Version 0.99.5 zusätzlich zu den ttyS*-Devices
vorhandenen Gerätedateien /dev/cua0, /dev/cua1 usw.
bilden die gleichen Schnittstellen nochmal ab. Beim
Öffnen dieser Dateien wird ein Programm niemals blockiert. Allein
wenn die parallele /dev/ttyS? Gerätedatei bereits geöffnet ist,
wird vom open(2) Systemcall der Fehler EBUSY zurückgeliefert.
Umgekehrt wird jeder Versuch, ein /dev/ttyS? zu öffnen, mit der
gleichen Fehlermeldung abgewiesen, sobald das entsprechende cua?-Device erfolgreich geöffnet wurde. Durch diesen Mechanismus
wird auf Kernelebene die gemeinsame Verwendung einer Modemleitung zum
Ein- und Auswählen unterstützt.
Indem das getty beispielsweise auf /dev/ttyS1
gestartet wird, kann der UUCP-Dämon auf dem parallelen Device /dev/cua1 problemlos arbeiten. Solange nämlich vom Modem kein
Carrier-Detect kommt, bleibt das getty blockiert. Wenn die
Verbindung aufgebaut ist, das Carrier-Detect Signal also anliegt, ist
die /dev/cua1 Datei bereits durch uucico geöffnet, also
bleibt das getty weiterhin blockiert.
Diese Methode stellt keine besonderen Ansprüche an das getty,
ist also besonders zusammen mit dem agetty zu empfehlen. Die
modernen Modems können so konfiguriert werden, daß sie automatisch auf
einen Wechsel des DTR-Signals vom Rechner einen Reset
ausführen. Außerdem kann in einem nichtflüchtigen Speicher mindestens
eine Reset-Konfiguration gespeichert werden. Auf diese Weise kann das
Modem vollautomatisch ankommende Verbindungen aufnehmen und nach
Beendigung irgendeiner Modemverbindung wieder in einen definierten
Zustand zurückkehren. Gegen diese Methode ist einzuwenden, daß das
Modem auch dann Anrufe entgegennimmt, wenn der Rechner - aus welchen
Gründen auch immer - nicht dazu bereit ist.
Sowohl getty_ps als auch mgetty erlauben auch ohne (man
kann sagen ``unter Umgehung der'') Kernelunterstützung die gleichzeitige
Benutzung eines Modemports in beiden Richtungen. Dazu muß das Modem
nicht im Auto-Answer-Modus sein. Um das zu erreichen, sind beide
Programme darauf angewiesen, daß die um einen Port konkurrierenden
Prozesse sogenannte Lockfiles anlegen. Dieses Verfahren wird - wenn
auch auf freiwilliger Basis und in unterschiedlicher Form - von allen
Programmen zur Datenfernübertragung eingehalten.
Die erste Voraussetzung zum Funktionieren dieses Systems ist die
Übereinkunft, wo diese Lockfiles angelegt werden. Ein nach dem
neuen File-System-Standard üblicher Ort ist das Verzeichnis /var/spool/uucp, es kann aber durchaus auch das ,,traditionelle``
Verzeichis /usr/spool/uucp oder /var/locks sein. Die
Lockfiles heißen dann beispielsweise /var/spool/uucp/LCK..cua1
oder /var/spool/uucp/LCK..ttyS0. Die Namensendung entspricht
also dem seriellen Port, der durch diese Datei ,,abgeschlossen`` werden
soll.
Wenn zwei Programme dasselbe Verzeichnis für ihre Lockfiles benutzen,
können sie vor dem Öffnen der Gerätedatei die Existenz eines solchen
Lockfiles prüfen und gegebenenfalls auf den konkurrierenden Zugriff
verzichten.
Weil diese Methode scheitert, wenn beispielsweise nach einem
Programmabsturz so ein Lockfile erhalten bleibt, wird zusätzlich in
dem Lockfile festgehalten, welcher Prozeß es angelegt hat. Allerdings
gibt es auch hier wieder in der Form, wie diese Information
abgelegt wird, verschiedene Varianten. Einige Programme hinterlassen
die Prozeßnummer als Zahl aus ASCII-Ziffern, andere als 4-Byte-Integer
im Binärformat. Wenn ein Programm auf einen seriellen Port zugreifen
will und ein Lockfile für diesen Port findet, stellt es fest, ob der
Prozeß, der dieses Lockfile angelegt, hat noch existiert. Ist das nicht
der Fall, wird der Port trotz Lockfile geöffnet.
Weil unter Linux die Quelltexte zu allen in Frage kommenden Programmen
vorhanden sind, ist die Wahrscheinlichkeit, daß sich alle Programme
einer Distribution über die Verwendung der Lockfiles einig sind,
größer, als es auf den ersten Blick den Anschein hat. Selbst wenn es
im Einzelfall zu Problemen kommt, lassen die sich durch Neuübersetzen
mit anderer Konfiguration verhältnismäßig leicht beheben.
Ein zusätzliches Problem entsteht, wenn zur ,,Vereinfachung`` ein Link
auf die Schnittstellendatei angelegt wird. Zugegeben, /dev/modem
ist aussagekräftiger als /dev/cua1. Das Lockfile LCK..modem kann aber keinesfalls verhindern, daß ein anderes Programm
/dev/cua1 öffnet.
Die dargestellten Probleme hätten längst zum völligen Aussterben von
getty_ps und mgetty geführt, hätten sie nicht einige sehr
überzeugende Features.
Der große Vorteil von mgetty liegt in seiner Fähigkeit,
automatisch FAXe der Klasse 2 zu empfangen, sofern das Modem dieses
Protokoll beherrscht. Mit dem zusätzlichen sendfax-Programm ist
damit der Linux-PC eine vollständige FAX-Station. Die Konfiguration
von mgetty wird in die Binärdatei eincompiliert. Weil Gert
Döring seinem ,,mgetty+sendfax`` Paket ein ausgezeichnetes Manual
(englisch) beigefügt hat, wird hier auf eine weitere Beschreibung
verzichtet.
Das getty von Paul Sutcliffe ist das flexibelste der hier
vorgestellten Programme. Einige interessante Features sind:
- Logins können auf bestimmte Zeiten (Tage und Stunden) beschränkt
werden.
- Durch ,,Klingelzeichen`` ist es möglich, auf einer Telefonleitung
ankommende Daten- und Voiceverbindungen zu unterscheiden.
- Es können zwei Gerätedateien überwacht werden. Nach der
Benutzung eines dieser Devices durch irgendein Programm wird das Modem
neu initialisiert.
- Für jeden Port kann eine eigene Initialisierungsdatei eingesetzt
werden.
- Die Parameter des Gerätetreibers lassen sich uneingeschränkt
variieren.
- Das Modem muß nicht im Auto-Answer-Modus betrieben werden.
getty [-R] [-C Connect] [-D Level]
[-d Defaults-Datei/] [-a] [-h] [-r
Verzögerung] [ -t Timeout] [-w Waitfor]
Device [Label [Typ [LineD.]]]
- -R
- (RINGBACK) wie RINGBACK=TRUE im Defaults-File
(Erklärung später)
- -C Connect
- wie CONNECT im
Defaults-File
- -D Level
- setzt den Debuglevel, wie DEBUG im Defaults-File
- -a Altline
- NICHT verwenden **BUG**
- -c gettydefs
- kann benutzt werden, um die
gettydefs-Datei zu testen
- -d Defaults-Datei
- veranlaßt getty, die angegebene
Defaults-Datei anstelle der Datei
/etc/default/getty.Port zu verwenden
- -h
- die gleiche Funktion wie HANGUP=NO im Defaults-File
- -r Verzögerung
- die gleiche Funktion wie DELAY=Verzögerung im Defaults-File; stellt eine
Zeitverzögerung zwischen dem Empfang des WAITCHAR-Zeichens und dem
Erscheinen des Login-Prompts ein
- -t Timeout
- die gleiche Funktion wie TIMEOUT=
Timeout im Defaults-File; getty wartet die angegebene
Anzahl Sekunden nach der Ausgabe des Prompts auf einen Loginnamen,
danach bricht es ab
- -w Waitfor
- das gleiche wie WAITFOR=Waitfor im
Defaults-File; nach der Initialisierung des Data-Sets wartet getty auf die Zeichenkette Waitfor und gibt nach der
DELAY-Verzögerung den Prompt aus
Nach den Optionen benötigt getty mindestens ein
Kommandozeilenargument. Wenn weitere Argumente angegeben sind, werden
sie in der Reihenfolge ihres Auftretens wie folgt interpretiert:
- Device
- (line) die Schnittstelle, auf der getty
arbeiten soll; getty erweitert den Namen zu /dev/Device
- Label
- die Marke des Eintrags in /etc/gettydefs, mit
dem getty die Schnittstelle initialisiert; wenn kein
Label angegeben ist, wird der erste Eintrag in gettydefs genommen
- Typ
- ein gültiger termcap-Eintrag für das (erwartete)
Terminal; der Eintrag wird benutzt, um eine Steuersequenz zum
Bildschirmlöschen zu senden, außerdem wird der Typ in die TERM-Umgebungsvariable geschrieben
- LineD.
- die Line-Discipline (beispielsweise SLIP)
Seine enorme Flexibilität erhält das getty_ps durch zwei
Initialisierungsdateien. Die eine, ,,Defaults-Datei``, enthält vor allem
Einstellungen und ,,Chat-Scripts`` zur Koordination der Zusammenarbeit
mit einem Modem oder einem Terminal, beispielsweise den String zur
Geräteinitialisierung (Reset). Die andere, /etc/gettydefs,
enthält die Daten zur Einstellung der seriellen Schnittstelle, also
die Baudrate und ähnliches.
getty_ps bietet die Möglichkeit, für verschiedene Devices
unterschiedliche Konfigurationsdateien zu benutzen. Diese
,,Defaults-Dateien`` werden alle im Verzeichnis /etc/default
erwartet. Die Namen der Konfigurationsdateien beginnen mit dem
Programmnamen (getty oder uugetty) und tragen optional den Namen der
Gerätedatei als Endung. Beispielsweise wird die Datei /etc/default/getty als Konfigurationsdatei für alle getty_ps
auf allen Ports genommen, für die keine besondere Konfigurationsdatei
existiert, /etc/default/uugetty.ttyS1 ist die
Konfigurationsdatei für ein uugetty auf dem Port /dev/ttyS1.
- SYSTEM=Name
- ist für den Systemnamen vorgesehen. Der
angegebene Name wird durch das Symbol @S in der ISSUE-Meldung
angezeigt. Wenn hier nichts angegeben wird, benutzt getty den
uname(2)-Systemaufruf, um den Nodenamen zu bestimmen.
- VERSION=Version
- setzt die Zeichenkette, die durch das
Symbol @V in der ISSUE-Meldung ausgegeben wird. Wenn die Zeichenkette
Version mit einem Slash beginnt, wird sie als Pfadname einer
Datei interpretiert (z. B. /proc/version).
- LOGIN=Kommando
- bestimmt ein Kommando als Ersatz für
/bin/login. Dieses Kommando wird dann mit dem Benutzernamen als
einzigem Argument aufgerufen, um die Benutzeridentifikation durchzuführen.
- INIT=ChatString
- bestimmt einen Chat-String zur
Initialisierung des seriellen Gerätes. Ein Chat-String besteht aus
einer Kette von expect-send-Paaren. Jedes Paar besteht aus zwei durch
Leerzeichen getrennten Zeichenketten. Das erste Auftreten eines
expect-Strings im Eingabedatenstrom führt zur Ausgabe des send-Strings
auf die serielle Schnittstelle. Im Unterschied zur UUCP-Konfiguration
werden die send-Strings nicht automatisch durch ein Newline
abgeschlossen.
Ein expect-String kann durch `expect-send-expect' Schleifen
unterbrochen werden. Diese send-Einschübe werden gesendet, wenn
innerhalb einer kurzen Frist das erwartete expect-Wort nicht
angekommen ist (typisches Beispiel aus einem anderen Bereich ist die
,,ogin:-BREAK-ogin:`` Sequenz, mit der uucico so lange
BREAK sendet, bis ein Login: Prompt empfangen wird)
Die folgenden Sonderzeichen können im INIT-String verwendet werden:
- \\
- der Backslash selbst
- \b
- Backspace (
^H)
- \c
- unterdrückt den
Zeilenvorschub am Ende einer Zeichenkette
- \f
- Seitenvorschub (
^L)
- \n
- Zeilenvorschub (
^J)
- \r
- Wagenrücklauf (
^M)
- \s
- Leerzeichen
- \t
- horizontaler Tabulator
- \nnn
- ASCII Zeichen mit
der (dezimalen) Nummer nnn; oktale und hexadezimale
Darstellungen sind mit den üblichen Präfixen erlaubt
- \p
- eine Sekunde Pause
- \d
- zwei Sekunden Pause
- \K
- 1/4 Sekunde Break
- \Tnnn
- Verändert das
allgemeine Timeout auf die in nnn angegebene Anzahl Sekunden;
der Wert kann wieder dezimal, oktal oder hexadezimal angegeben werden
- INITLINE=Device
-
Wenn uugetty auf einem blockierenden ttyS? Device arbeitet,
kann durch Angabe einer INITLINE das parallele cua? Device für
die Initialisierung und gegebenenfalls für die WAITCHAR/WAITFOR-Sequenz benutzt werden. Das uugetty vermeidet
durch Überwachung der Lockfiles für beide Devices konkurrierende
Zugriffe und initialisiert nach jeder Benutzung das Gerät neu. In
einigen Versionen von getty_ps ist die gleiche Funktion unter
dem Namen ALTLINE implementiert.
- ISSUE=Meldung|Datei
- Vor dem Loginprompt gibt getty normalerweise eine kurze Meldung aus,
die beispielsweise den Systemnamen beinhaltet. Traditionell
wird diese Meldung aus der Datei /etc/issue gelesen. getty_ps ermöglicht es, eine andere Datei zu benennen, aus der die
Meldung gelesen werden soll, oder die Meldung direkt anzugeben.
In der Meldung werden bestimmte Sonderzeichen erkannt und
ersetzt:
- \\
- der Backslash selbst
- \b
- Backspace (
^H)
- \c
- unterdrückt den
Zeilenvorschub am Ende einer Zeichenkette
- \f
- Seitenvorschub (
^L)
- \n
- Zeilenvorschub (
^J)
- \r
- Wagenrücklauf (
^M)
- \s
- Leerzeichen
- \t
- horizontaler Tabulator
- \nnn
- ASCII Zeichen mit
der (dezimalen) Nummer nnn; oktale und hexadezimale
Darstellungen sind mit den üblichen Präfixen erlaubt
Ein einzelner Backslash am Zeilenende führt dazu, daß die
Ausgabe in derselben Bildschirmzeile fortgesetzt wird.
Die folgenden Parameter werden erkannt und ersetzt:
- @B
- die aktuelle Baudrate
- @D
- das aktuelle Datum im Format MM/DD/YY
- @L
- der Port, mit dem getty verbunden ist
- @S
- der Systemname (siehe oben)
- @T
- die aktuelle Zeit im Format HH:MM:SS
- @U
- die Anzahl der aktuell eingeloggten User; diese Zahl wird
aus den Einträgen in der utmp-Datei errechnet
- @V
- die Zeichenkette aus VERSION (siehe oben)
- @@
- der Klammeraffe selbst
- CLEAR=YES
- Solange der Schalter mit YES belegt wird,
versucht getty_ps, den Bildschirm vor der Ausgabe der ISSUE
Meldung zu löschen.
- HANGUP=YES
- Solange die Einstellung HANGUP=YES
besteht, wird getty veranlaßt, eine bereits vor dem
Programmstart bestehende Verbindung durch ein HANGUP-Signal zu
unterbrechen.
- WAITCHAR=NO
- Mit WAITCHAR=YES wird getty
veranlaßt, auf ein einzelnes Zeichen zu warten und erst dann mit der
Initialisierung fortzufahren. Auf diese Weise kann beim Betrieb eines
Terminals mit dauernd anliegendem Carrier-Detect-Signal eine
Endlosschleife unterbrochen werden.
- DELAY=Sekunden
- Zusammen mit WAITCHAR wird hier
eingestellt, wie lange auf das Zeichen gewartet werden soll. Der
voreingestellte Wert 0 veranlaßt getty_ps, beliebig lange auf
ein Zeichen zu warten.
- TIMEOUT=Sekunden
- Hier kann eine Zeitspanne angegeben
werden, die von getty_ps nach der Ausgabe des Prompts auf einen
Benutzernamen gewartet wird. Wenn nichts anderes bestimmt wird, wartet
getty endlos.
- WAITFOR=Wort
- arbeitet wie WAITCHAR, nur daß auf
die Zeichenkette Wort gewartet wird.
- CONNECT=ChatString
- der Chat-String ist eine
expect/send-Sequenz, mit der getty den Aufbau einer ankommenden
Modemverbindung regeln kann. Ein typisches Beispiel ist:
WAITFOR=RING
WAITFOR=RING
CONNECT= "" ATA\r CONNECT\s\A
Zuerst wird hier mit WAITFOR zweimal auf die Zeichenkette ,,RING``
gewartet. Danach wird in dem ChatScript auf nichts weiter gewartet
(""), also sofort ein ATA zum Modem geschickt um es zum
Abheben zu veranlassen. Dann wird auf eine Zeichenkette der Form
,,CONNECT 14400`` gewartet. Die Sonderzeichen haben folgende Bedeutung:
- \A
- die Baudrate
- \s
- ein Leerzeichen
- ALTLOCK=Port
- diese Variable wird nur von uugetty
benutzt. Der angegebene Port wird wie der ,,eigene`` überwacht und
durch ein Lockfile blockiert, sobald eine Verbindung erkannt wird. Wenn
ein anderes Programm einen der überwachten Ports benutzt (durch ein
Lockfile blockiert), wird nach der Freigabe das Gerät neu initialisiert.
- ALTLINE=Port
- siehe INITLINE
- RINGBACK=NO
- Wenn RINGBACK=YES gesetzt ist,
wird der oben beschriebene WAITFOR ... CONNECT Mechanismus
unterbrochen, und ankommende Anrufe werden zuerst abgewiesen. Wenn
nach ein- bis dreimaligem Klingeln eine Pause von höchstens 60
Sekunden eingelegt wird, nimmt das Modem nach dem nächsten Klingeln
ab. Durch dieses ,,Klingelzeichen`` kann eine Telefonleitung
gleichzeitig für Gespräche und Datenverbindungen genutzt werden.
- MINRBTIME=Sekunden
- minimale Verzögerung zum zweiten
Anlauf (Voreinstellung 6 Sek.)
- MAXRBTIME=Sekunden
- maximale Verzögerung zum zweiten
Anlauf (Voreinstellung 60 Sek.)
- INTERRING=Sekunden
- die maximale Zeit zwischen zwei
Klingelphasen (Voreinstellung 4 Sek.)
- MINRINGS=Anzahl
- minimale Anzahl der Klingelphasen bei der
ersten Anwahl (Voreinstellung 1)
- MAXRINGS=Anzahl
- maximale Anzahl der Klingelphasen bei
der ersten Anwahl (Voreinstellung 3)
- SCHED=Zeitraum1 [Zeitraum2]
- In
der Variablen SCHED können Zeiträume bestimmt werden, in denen
getty_ps aktiv ist und so ein Login auf der seriellen Leitung ermöglicht. Ein Zeitraum wird in der Form
Tag:Std:Min-Tag:Std:Min eingegeben. Tag ist eine Zahl zwischen 0 (Sonntag) und 6
(Samstag). Wenn die aktuelle Zeit in einem der Zeiträume liegt, wird
das Modem initialisiert und bis zum Ende des Zeitraums auf ein Login
gewartet. Am Ende jedes Zeitraums wird der OFF ChatString zum
Modem geschickt.
- OFF=ChatString
- entspricht dem INIT ChatString,
wird aber zum Deaktivieren des Modems nach einem Scheduler Zeitraum
benutzt.
- DEBUG=Level
- setzt den Debuglevel. Der Level wird als
Oktalzahl angegeben, die Bits schalten jeweils eine Ebene hinzu:
- OPT
- (001) Interpretation der Kommandozeile (getopt(3))
- DEF
- (002) Bearbeitung des Defaults-File
- UTMP
- (004) Update der utmp/wtmp-Einträge
- INIT
- (010) Geräteinitialisierung (INIT)
- GTAB
- (020) Bearbeitung der gettytab-Datei
- GETL
- (040) Loginname einlesen
- RUN
- (100) andere Laufzeitfehler
- LOCK
- (200) Lockfile-Handling (nur uugetty)
- SCHED
- (400) Scheduling
Um alle Debugmeldungen zu erhalten, muß Level 0777 eingestellt werden.
Die Datei /etc/gettydefs wird vom getty_ps ausgewertet, das
daraus die Parameter zur Einstellung des Terminaldevices bezieht.
Jeder Eintrag besteht aus einer Zeile der Form:
Label# Startparameter # Loginparameter #Prompt# nächstes Label
Ein Hashmark `#' am Zeilenanfang leitet einen Kommentar ein.
Die Felder eines Eintrags haben folgende Bedeutung:
- Label
- gibt der Zeile einen ,,Namen``. Damit kann dem getty_ps auf der Kommandozeile der Starteintrag übergeben werden.
- Startparameter
- ist eine durch Leerzeichen getrennte Liste von
symbolischen Konstanten zur Einstellung des Gerätetreibers nach dem
ersten Öffnen durch getty_ps. Es können alle Parameter benutzt
werden, die vom ioctl(2)-Systemaufruf verstanden werden.
Die
erlaubten Symbole sind in /usr/include/linux/termios.h definiert.
Erklärt sind sie beim stty-Kommando .
Die Angabe einer Leitungsgeschwindigkeit ist notwendig, alle anderen
Parameter optional.
- Loginparameter
- ist eine durch Leerzeichen getrennte Liste von
symbolischen Konstanten zur Einstellung des Gerätetreibers vor dem
Aufruf des login-Kommandos durch getty_ps. Da getty_ps durch diesen Aufruf verdrängt wird, sind das die
Einstellungen, die beim Start der ersten Shell aktiv sind.
Für die erlaubten und notwendigen Konstanten gilt das gleiche wie für
die Startparameter.
- Prompt
- ist der Loginprompt von getty_ps. Leerzeichen und
TAB werden so ausgegeben, wie sie in diesem Feld erscheinen.
Außerdem sind alle Symbole und Sonderzeichen erlaubt, die auch in der
ISSUE-Meldung benutzt werden dürfen.
- nächstes Label
- zeigt auf ein definiertes Label (erstes Feld)
einer Zeile in /etc/gettydefs. Der durch dieses Label bezeichnete
Eintrag wird angesprungen, wenn anstelle eines Buchstabens ein BREAK
empfangen wird. Wenn ein Modem auf einer zu hohen
Leitungsgeschwindigkeit wartet, wird ein RETURN wie ein BREAK
interpretiert.
Durch Verkettung mehrerer Einträge mit (absteigend) unterschiedlichen
Baudraten kann ein langsamer ankommender Anruf das getty_ps
dazu bringen, das lokale Modem so lange schrittweise zu verlangsamen,
bis eine Verständigung möglich ist.
Die modernen Modems mit Datenkompression handeln mit ihrer Gegenstelle
automatisch die höchste mögliche Geschwindigkeit aus und werden
deshalb zur Computerseite mit einer festen Baudrate betrieben, die
höher sein sollte als jede real auf der Telefonleitung auftretende.
In diesem Fall zeigt der Eintrag für das nächste Label auf das der
aktuellen Zeile.
Next: UUCP - Das Internet der
Up: Datenreisen und reisende Daten
Previous: Kontaktaufnahme
Das Linux Anwenderhandbuch
(C) 1997
LunetIX