Subsections

• Das richtige getty
  • Device-Handling
  • Lockfiles
• getty_ps
  • Syntax:
  • Optionen:
  • Defaults-Dateien
  • gettydefs

Seriell einloggen

   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.

Das richtige getty

 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.

Device-Handling

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.

Lockfiles

  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.

getty_ps

   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.

Syntax:

getty [-R] [-C Connect] [-D Level] [-d Defaults-Datei/] [-a] [-h] [-r Verzögerung] [ -t Timeout] [-w Waitfor] Device [Label [Typ [LineD.]]]

Optionen:

-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.

Defaults-Dateien

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.

gettydefs

  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.