table of contents
RLINETD.CONF(5) | rlinetd 0.8.2 | RLINETD.CONF(5) |
NAME¶
rlinetd.conf - Rlinetd-KonfigurationsdateiBESCHREIBUNG¶
rlinetd.conf enthält Konfigurationsinformationen für rlinetd. Es gibt eine kleine Anzahl von ähnlichen Konstrukten auf höchster Ebene, die sich im wesentlichen darin unterscheiden, welche Optionen sinnvollerweise mit ihnen verwandt werden können. Alle Zeichenketten werden mit dem Zeichen " maskiert. In einigen Situationen (z.B. den Direktiven log, exec und chroot) gibt es eine Reihe von Variablen, die in der Zeichenkette ersetzt werden können....
}
Dieses Konstrukt beschreibt einen Dienst. Der
Parameter Name ist nur für die bequeme Benennung da, er dient nur
dazu, Protokollmeldungen zu unterscheiden und stellt eine Vorgabe für
Optionen dar, die logischerweise einen Namen als Argument erwarten.
enabled
log "Name" {
Dieses Konstrukt erlaubt das leichte
Aktivieren oder Deaktivieren eines Dienstes. Das Argument kann entweder
yes oder no (ja oder nein) lauten. Der Standardwert lautet
yes. Wird es auf no gesetzt, ist der Dienst deaktiviert.
Beispiel:
port
enabled no;
Die Liste der Ports, für die der Dienst
verfügbar gemacht werden soll. Die Ports können entweder als
Zeichenkette oder im numerischen Format angegeben werden. Falls nicht
angegeben, ist die Vorgabe der Name des Dienstes, solange es sich nicht um
einen RPC-Dienst handelt, in dessen Falle der Wert des Ports dynamisch vom
System zugewiesen wird.
Beispiel:
interface
port "telnet", "rcmd",
56, 99;
Dies gibt an, an welche Schnittstelle die
aufgeführten Ports gebunden werden sollen. Es erwartet eine Liste von
IP-Adressen als Argument, entsprechend der konfigurierten Adressen der
benötigten Schnittstellen. Falls nicht angegeben, ist die Vorgabe
INADDR_ANY und es wird an alle verfügbaren Schnittstellen
gebunden.
Beispiel:
exec
interface 192.168.1.1,
192.168.1.2;
Dies legt den Aufruf des Dienstes fest. Eine
Reihe von Ersetzungen können innerhalb der Zeichenkette vorgenommen
werden, bitte lesen Sie hierzu Zeichenketten-Modifikatoren unten.
Beispiel:
server
exec "/usr/sbin/in.telnetd
-d";
Dies legt das auszuführende Programm
fest, falls von exec verschieden.
Beispiel:
protocol
server
"/usr/sbin/tcpd";
Dies legt das Socket-Protokoll fest, das beim
Warten auf Verbindungen auf Ports für diesen Dienst verwandt wird. Das
Argument kann entweder tcp oder udp sein. Die Vorgabe ist
tcp.
Beispiel:
user
protocol tcp;
Dies legt die Benutzer-ID (»userid«)
fest, unter der dieser Dienst laufen soll. Es akzeptiert ein Argument entweder
in symbolischer oder numerischer Form. Falls group (siehe unten) nicht
angegeben ist, wird die Gruppen-ID (groupid) auf die primäre Gruppe des
Benutzers gesetzt.
Beispiel:
group
user "nobody";
Dies legt die Gruppen-ID (groupid) fest, unter
der dieser Dienst laufen soll. Es akzeptiert ein Argument entweder in
symbolischer oder numerischer Form.
Beispiel:
backlog
group "system";
Dies ist das »backlog«-Argument, das
an den Systemaufruf listen(2) übergeben wird.
Beispiel:
instances
backlog 30;
Dies gibt die maximale Anzahl an
Dienstinstanzen an, die gleichzeitig laufen können. Der Standardwert
für diese Variable ist 40.
Beispiel:
wait
instances 50;
Diese Direktive emuliert das
wait-Verhalten von inetd(8). Das Argument kann entweder
yes oder no (ja oder nein) lauten. Der Standardwert ist
no. Wird diese Direktive auf yes gesetzt, wird auch der Wert der
Option instances auf 1 zurückgesetzt.
Beispiel:
nice
wait yes;
Dies gibt die Prozesspriorität an, unter
der dieser Dienst laufen soll. Das Argument wird direkt an den Systemaufruf
setpriority(2) übergeben. Der Wert kann negativ sein.
Beispiel:
rpc
nice -5;
Dies gibt an, dass der Dienst im
portmap(8)-Mapper als RPC-Dienst registriert werden soll. Es akzeptiert
eine Liste von Argumenten wie folgt:
rpc {
chroot
name "Zeichenkette";
version 3,6,9-15,22;
}
Der Parameter name ist optional und wird standardmäßig auf den
Namen des Dienstes gesetzt.Dies gibt das Wurzelverzeichnis für den
Dienst an. Das Zeichenkettenargument kann Modifikatoren akzeptieren, wie dies
unten in Zeichenketten-Modifikatoren dargestellt ist.
Beispiel:
log
chroot "/tftpboot/%O";
Diese Direktive erwartet zwei Argumente. Das
erste muss entweder der symbolische Name einer vorher angegebenen
log-Direktive (siehe unten) oder das nicht maskierte Wort syslog
sein. In letzterem Fall wird eine Meldung mittels des Systemaufrufs
syslog(3) protokolliert. Das zweite Argument ist die zu
protokollierende Nachricht. Sie unterliegt den unten in
Zeichenketten-Modifikatoren beschriebenen Modifikatoren.
Beispiel:
tcpd
log syslog "Dienst von %O
abgeschlossen";
Diese Direktive führt dazu, dass die von
tcp_wrappers angegebenen Zugriffskontrollen angewandt werden. Dies hat den
gleichen Effekt, wie den Aufruf eines Dienstes mit dem Argument
/usr/sbin/tcpd (oder wo auch immer sich tcpd(8) befindet)
für server. Es spart allerdings den zusätzlichen Schritt des
Programmstarts. Es akzeptiert bis zu zwei zusätzliche Argumente. Das
erste ist der Name des Dienstes, der beim Prüfen gegen die Regeln
verwandt werden soll, und das zweite ist ein Anweisungsblock, der beim
Zutreffen von Regeln ausgeführt werden soll. Falls kein Name angegeben
wird, wird als Vorgabe der Name des Dienstes verwandt. Falls der
Anweisungsblock nicht angegeben wird, wird als Vorgabe »exit;«
verwandt.
Beispiele:
exit
tcpd "in.telnetd";
tcpd { exec "/usr/local/bin/winnuke %O"; }
tcpd "Sinnlos" { echo "Hallo Jungs, kommt rein."; }
tcpd "trotzig" { echo "500 Zugriff von %O verweigert."; exit; }
Diese Direktive ist nur in einem
Anweisungsblock für die Direktive tcpd sinnvoll. Beachten Sie:
Wenn Sie diese nicht verwenden (und keine andere beendende Direktive wie
exec angeben) dann wird der Dienst nie beendet.
Beispiel:
capability
exit;
Diese Direktive gibt die Fähigkeiten
(»capabilities«) an, über die der Dienst bei der
Ausführung verfügen sollte. Das Argument ist eine Zeichenkette, die
direkt an cap_from_text(3) weitergegeben wird. Diese Beschreibung ist
ziemlich lausig, aber diese Funktionalität nützt Ihnen sowieso nicht
viel, solange Sie die Datei »README.capabilities« noch nicht gelesen
haben.
Beispiel:
rlimit
capability
"cap_setuid=ep";
Diese Direktive erwartet zwei Argumente. Das
erste ist ein Symbol, das die Art der benötigten Begrenzung angibt. Diese
werden unten aufgeführt. Das zweite Argument wird in einem von zwei
Formaten erwartet. Es kann entweder ein einzelner numerischer Wert sein. In
diesem Fall werden sowohl die weichen als auch die harten Grenzen (»soft
and hard limits«) der besagte Ressource auf diesen Wert gesetzt.
Alternativ kann es eine Liste in der folgenden Form sein:
rlimit type {
initgroups
soft x; hard y;
}
In dem Fall werden die harten und weichen Begrenzungen entsprechend gesetzt. In
jedem Fall kann das Wort unlimited anstelle eines numerischen Wertes
angegeben werden und damit jede Begrenzung entfernt werden. Die Werte werden
direkt an den Systemaufruf setrlimit(2) übergeben und sollten aus
diesem Kontext heraus angegeben werden.
Arten:
cpu, fsize, data, stack, core, rss, nproc,
nofile, memlock
Beispiel:
rlimit cpu 15;
Das Argument kann entweder yes oder
no (ja oder nein) lauten. Diese Direktive führt zum Aufruf von
initgroups(3) beim Dienstestart, womit die zusätzlichen Gruppen
des Dienstes entsprechend der Datei /etc/group gesetzt werden.
Beispiel:
family
initgroups yes;
Diese Direktive gibt die Protokollfamilie an,
für die Rlinetd Sockets für diesen Dienst binden soll. Derzeit kann
dies entweder ipv4 oder ipv6 sein. Falls nicht angegeben, ist
die Vorgabe etwas für das System angemessenes.
Beispiel:
banner
family ipv6;
Diese Direktive erlaubt es Ihnen, eine Datei
für eine Verbindung auszugeben.
Beispiel:
echo
banner "/etc/nologin";
Diese Direktive erlaubt es, eine dynamisch
generierte Zeile für diese Verbindung hinzuzufügen.
Beispiel:
filter
echo "500 Dienst von Ihrer IP aus
verweigert (%O)";
Diese Direktive erlaubt es, ein
Linux-Socket-Filterprogramm anzugeben, das dem Socket zugeordnet wird, an dem
auf Anfragen gewartet wird. So ein Programm kann mit einem Werkzeug wie
lsfcc(1) erstellt werden.
Beispiel:
chargen
filter
"/usr/local/lib/rlinetd/filters/privport";
Diese Direktive führt eine Endlosschleife
aus, bei der Daten an jede Verbindung ausgegeben werden. Falls kein Argument
übergeben wird, wird eine Teilmenge der druckbaren Zeichen ausgegeben.
Allerdings kann ein Dateiname als Argument übergeben werden, wobei dann
der Inhalt der Datei in der Schleife ausgegeben wird.
Beispiel:
chargen
"/usr/local/lib/spam";
...
}
Dieses Konstrukt beschreibt ein
Protokollierziel. Der Parameter Name wird als Argument für die
Direktive log in service-Konfigurationen verwandt.
path
defaults {
Dies gibt den Dateinamen für diese
Protokolldatei an.
Beispiel:
mode
path
"/var/log/service.log";
Dies gibt die Dateirechte für die
Protokolldatei an. Das Argument muss numerisch sein und lautet 0640, falls
nicht angegeben.
Beispiel:
user
mode 0600;
Dies gibt die UID der Protokolldatei an. Es
kann entweder als numerische UID oder als Benutzername angegeben werden.
Beispiel:
group
user "adm";
Dies gibt die GID der Protokolldatei an. Es
kann entweder als numerische GID oder als Benutzername angegeben werden.
Beispiel:
group "adm";
...
}
Dieses Konstrukt erwartet die gleichen
Parameter wie die Deklaration von service. Anstatt allerdings einen
Dienst anzugeben, werden die Vorgaben für alle im Folgenden angegebenen
Dienste gesetzt.
directory "Pfad" "passen" "ignorieren";
Dieses Konstrukt gibt ein Verzeichnis an, das
zusätzliche auszuwertende Konfigurationsdateien enthält. Die
Auswertung dieser zusätzlichen Dateien beginnt erst, nachdem die aktuelle
Datei abgeschlossen wurde. Die Argumente match und ignore sind
optional und werden, falls angegeben, benutzt, um die Dateien im Verzeichnis
zu filtern. Dateinamen müssen auf den regulären Ausdruck
match passen (falls dieser angegeben ist) und dürfen nicht auf den
regulären Ausdruck ignore passen (falls dieser angegeben ist). In
allen Fällen werden Dateinamen, die mit einem Punkt (».«)
beginnen, übersprungen. In Verzeichnisse wird nicht rekursiv
abgestiegen.
Zeichenketten-Modifikatoren¶
Es gibt eine Reihe von Variablen, die in Argumenten für einige Direktiven ersetzt werden können. Obwohl sie alle an den gleichen Stellen verwandt werden können, sind die von einigen ermittelten Informationen in bestimmten Fällen nicht verfügbar.- %O
- die Quell-IP-Adresse dieser Verbindung
- %P
- der Quell-Port dieser Verbindung
- %C
- die gesamte verwandte CPU-Zeit
- %U
- die verwandte Benutzer-CPU-Zeit
- %S
- die System-CPU-Zeit
- %r
- maximale »resident set size«
- %m
- Größe des gemeinsam benutzten Speichers (»shared memory«)
- %d
- Größe des nicht gemeinsam benutzen Datenbereichs (»unshared data«)
- %s
- Größe des nicht gemeinsam genutzten Stapelspeichers
- %f
- Speicherseiten-Rückforderungen (»page reclaims«)
- %F
- Seitenfehler (»page faults«)
- %p
- Swaps
- %i
- Blockeingabeoperationen
- %o
- Blockausgabeoperationen
- %n
- versandte Nachrichten
- %c
- empfangene Nachrichten
- %k
- empfangene Signale
- %w
- freiwillige Kontextumschaltungen
- %w
- unfreiwillige Kontextumschaltungen
- %e
- Exit-Code
- %t
- Laufzeit
- %M
- Die aktuelle Zeit wird in Sekunden seit der Epoche 1980 dargestellt und in Netzreihenfolge als 32-Bit-Wort ausgegeben. Sie hat absolut keine andere Verwendung, als Inetd-artige Zeitfunktionalität bereitzustellen.
- %I
- aktuelles Datum und Zeit, im Schöndruck-ctime(3)-Format
SIEHE AUCH¶
rlinetd(8), hosts_access(5)AUTOR¶
Diese Handbuchseite wurde von Mikolaj J. Habryn <dichro-doc@rcpt.to> geschrieben. Geändert von Robert Luberda <robert@debian.org>.ÜBERSETZUNG¶
Diese Übersetzung wurde 2011 von Helge Kreutzmann erstellt. Sie unterliegt der GNU GPL Version 2 (oder neuer).21. Februar 2009 | Debian |