Mit dem Finger-Service informieren Anwender über sich selbst, ihre Aktivitäten und ihre Termine, ohne eine komplexe Groupware-Applikation zu bedienen. Auch das Protokoll ist überraschend einfach. Somit eignet sich Finger hervorragend als Einstieg in die Welt der Serveradministration.

Manchmal sind gleitende Arbeitszeiten lästig: Sie bringen zahlreiche Konversationen mit dem Anrufbeantworter mit sich, wenn der Kollege noch beim Frühstück sitzt oder schon nach Hause gegangen ist. Viele Angestellte hängen ihren Arbeitsplan deshalb an die Bürotür. Dumm nur, wenn dies am anderen Ende des Gebäudes ist.

Spätestens dann, wenn man für eine Besprechung die Terminpläne mehrerer Leute koordinieren muss, hat Groupware ihre Daseinsberechtigung erworben. Entsprechende Produkte gibt es nicht erst seit Outlook & Co., das Finger-Protokoll wurde schon im Jahre 1977 erstmalig beschrieben[1]. Moderne Groupware-Applikationen bieten zwar wesentlich mehr, doch in vielen Fällen genügt Finger vollkommen und verrät auch viel über die ureigene Unix-Philosophie.

So funktioniert Finger

Das Finger-Konzept ist wunderbar einfach, beinahe primitiv – und damit ein perfektes Beispiel für einen klassischen Client-Server-Dienst. Die Benutzer des Systems legen Informationen über sich selbst in einfachen Textdateien ab. Ein passender Daemon nimmt Anfragen von außen entgegen und gibt Auskunft zur jeweiligen Person.

Wer Informationen mit Hilfe dieses Diensten publizieren möchte, erstellt in seinem Heimatverzeichnis eine Datei ».plan« oder ».project«. Wesentlicher Unterschied ist, dass ».project« traditionell nur eine einzige Zeile enthalten darf, während der User in ».plan« gerne etwas geschwätzig sein darf. Diese Datei ist der richtige Ort für Terminpläne oder einen öffentlichen PGP-Schlüssel. Der Finger-Daemon ergänzt die Informationen um Systemdaten wie die benutzte Shell, den letzten Login oder auch Informationen über noch ungelesene E-Mail. Listing 1 zeigt das Ergebnis der Beispielabfrage »finger Selig@localhost« auf einem Host des Autors.

Den Benutzernamen schlägt der Daemon in »/etc/passwd« nach. Von dort kommen auch der ausgeschriebene Name, ebenso die Zimmer- und die Telefonnummer. Diese drei liegen im so genannten GECOS-Feld. Dieses Akronym steht für General Electric Comprehensive Operating System, ein um 1970 verbreitetes Betriebssystem. Aus heutiger Sicht kaum noch bedeutsam, aber dieses Feld mit menschlichen Daten wurde aus GECOS in Unix übernommen und trägt immer noch den Namen seiner Eltern. Wer diese Informationen ändern will, sollte sie (selbst als Administrator) nicht direkt in »/etc/passwd« hineinschreiben, sondern den Befehl »chfn« (Change Finger) benutzen.

Endbenutzer dürfen das Fummeln nicht nur fördern und mit freundlichen Daten locken, sondern umgekehrt auch unterbinden. Wer eine Datei ».nofinger« im Heimatverzeichnis hat, dessen Existenz leugnet der unter Linux übliche BSD-Daemon, und zwar ganz ohne schlechtes Gewissen. Die Finger-Aktivitäten unterbindet auch, wer die Zugriffsrechte falsch setzt: Jeder muss ».plan« und ».project« lesen können; für das Heimatverzeichnis erwartet der Daemon mindestens Lookup-Rechte (»chmod 711 ~« und »chmod 644 ~/.plan«).

Der Daemon erwacht

Der Finger-Server ist zwar noch in den meisten Distributionen enthalten, aber er gehört üblicherweise nicht zum Standard-Installationsumfang. Ergänzen Sie also die Pakete »finger« und auch »finger-server«. Nötigenfalls liefert eine Suche nach dem Paket »bsd-finger« zügig den Quelltext zu Tage. Die Installation eines Servers aktiviert diesen normalerweise nicht automatisch. Grundsätzlich existieren unter Linux zwei verschiedene Arten Server: Die eine läuft ständig als eigener Prozess, sie ist damit bei ankommenden Verbindungen sofort reaktionsbereit und kann die Ressourcen selbst einteilen.

Finger gehört zur anderen Kategorie: Er wird über den zentralen Verteiler »inetd« (den so genannten Internet-Superserver) oder »xinetd« bei Bedarf gestartet, sobald tatsächlich eine entsprechende Anfrage vorliegt. Auch diese Methode hat Vorteile: Server lassen sich mit ihr einfacher programmieren, sind stabiler (weil für jede Anfrage neu gestartet) und belegen im Ruhefall keine Ressourcen.

Ob Ihre Distribution das klassische »inetd« oder das modernere »xinetd« verwendet, erkennen Sie an den Konfigurationsdateien: »/etc/inetd.conf« oder »/etc/xinetd.d/*«. Der Eintrag für Finger in »/etc/inetd.conf« (Listing 2) existiert oft schon. Am Anfang der Zeile steht jedoch ein Hash-Zeichen »#«, es deaktiviert den Finger-Dienst. Löschen Sie es, um den Server zu aktivieren.

Der Inhalt von »inetd.conf« ist als Tabelle zu lesen. Jede Zeile steht für einen bestimmten Service, der über den Internet-Superserver angeboten wird. Die einzelnen Spalten beschreiben den Dienst genauer.

Dienst mit Verbindung

Erster Eintrag ist der Name des Dienstes. Für den Inetd entscheidend ist, dass dieser Name auch den IP-Port eindeutig definiert. Das Betriebssystem schlägt in »/etc/services« nach, welcher Port diesem symbolischen Namen zugeordnet ist. Die zweite Spalte enthält den Typ des benutzten Sockets: »stream« (Strom) steht für verbindungsorientierte Dienste, »dgram« (Datagramm) für verbindungslose. Erstere tauschen mit ihrem Partner einen Datenstrom aus, bei dem das Protokoll für die zuverlässige Übertragung sorgt. Verbindungslose Dienste schicken nur einzelne Pakete, die auch verloren gehen oder in der falschen Reihenfolge eintreffen können.

Der übliche Vergleich ist der zwischen einem Telefongespräch und einer Postkarte: Bei einer Telefonverbindung erwartet der Anrufer selbstverständlich, dass die Konversation vollständig und fehlerlos übertragen wird. Eine Postkarte hingegen wirft der Absender irgendwo in einen Briefkasten und hofft, dass sie irgendwann ankommt. Geht sie auf der Reise verloren, wundert er sich darüber nicht übermäßig.

Die dritte Spalte aus »/etc/inetd.conf« beschreibt das Protokoll. Sinnvolle Einträge sind »tcp« für TCP/IP (verbindungsorientiert) und »udp« für UDP/IP (verbindungslos). Damit scheint diese Spalte auf den ersten Blick redundant zu sein – aber Vorsicht: Es existieren noch weit mehr Protokolle im Netz. Wie beim Namen des Dienstes handelt es sich auch hier um eine symbolische Angabe, die Linux in eine Zahl übersetzt. Dieses Mal verwendet das System die Datei »/etc/protocols«.

In der vierten Spalte entscheidet es sich, ob »inetd« auf das Ende des aufgerufenen Serverprogramms wartet (»wait«) oder nicht (»nowait«). Im zweiten Fall startet Inetd sofort einen neuen Serverprozess, wenn die nächste Anfrage für diesen Dienst ankommt.

Warten oder nicht

Diese Unterscheidung mag zunächst etwas verwirren, sie ist aber wichtig. Der Finger-Service ist als »nowait« eingetragen: Eine Anfrage kommt an, Inetd startet einen Finger-Server, der antwortet und beendet sich selbst. Erhält Inetd während dieser Zeit eine zweite Anfrage, ruft er sofort und parallel zum ersten einen zweiten Finger-Server auf. Anders wäre es bei einem verbindungslosen Dienst. Inetd kann hier nicht wissen, ob ein weiteres ankommendes Paket noch zu der ersten Anfrage gehört oder ob es einen neuen Server benötigt. Verbindungslose Dienste sind daher meist als »wait« einzutragen.

In der fünften Spalte von »inetd.conf« steht der Unix-Benutzer, in dessen Namen Inetd den Dienst aufruft. Der Super-Daemon startet nicht automatisch jeden Server als Root, sondern Sie können als Admin die Rechte des gestarteten Programms selbst festlegen.

In der sechsten Spalte befindet sich der Pfad zum ausführbaren Serverprogramm. Die übrigen Datenfelder enthalten die Kommandozeilen-Argumente für den Server, wobei an erster Stelle (Argumentnummer null) noch einmal der Name des Programms übergeben wird.

01 Login: mas                      Name: Marc Andre Selig
02 Directory: /home/mas            Shell: /bin/bash
03 On since Mon Sep  8 11:20 (CEST) on pts/0 from :0
04    50 seconds idle
05 On since Mon Sep  8 16:49 (CEST) on pts/1 from :0
06 No mail.
07 Project:
08 Im Moment arbeite ich an einem Artikel für das  Linux-Magazin.
09 Plan:
10 Das
11 ist
12 mein
13 .plan
14 und er darf mehr als nur eine Zeile enthalten.

01 finger  stream  tcp  nowait  nobody  /usr/sbin/in.fingerd  in.fingerd

01 service finger
02 {
03         socket_type     = stream
04         wait            = no
05         user            = nobody
06         server          = /usr/sbin/in.fingerd
07         disable         = no
08 }

Konfiguration lesen

Bei Xinetd erhält Finger eine eigene Konfigurationsdatei »/etc/xinetd.d/finger« (siehe Listing 3). Inhaltlich sind hier zwar keine großen Unterschiede zu finden, die Einträge sind allerdings für Uneingeweihte etwas besser lesbar. Änderungen an »/etc/inetd.conf« oder »/etc /xinetd.d« werden normalerweise erst nach einem Neustart des Superservers aktiv. Ein »kill -HUP Prozessnummer« bringt den Daemon dazu, die Neuerungen sofort einzulesen.

Um zu sehen, wie Finger auf dem Netzwerk arbeitet, ist kein Protokoll-Analysator nötig, Sie müssen nicht einmal das gleichnamige Clientprogramm »finger« benutzen. Stattdessen können Sie mit dem Finger-Protokoll selbst sprechen, ein einfacher Telnet-Client genügt. Wer lieber die Spezifikation liest: RFC 1288[2] ist die aktuelle Fassung.

Abbildung 1: Wer in seine Homepage eine Finger-Abfrage integrieren will, kann dazu ein Webinterface nutzen. Da das Protokoll sehr einfach ist, sind solche Frontends schnell entwickelt.

Das Finger-Protokoll

Der Server läuft auf dem Port 79, gleich unter dem HTTP-Port 80. Er benutzt als verbindungsorientiertes Protokoll TCP/IP zur Übertragung, nicht UDP/IP, das für verbindungslose Dienste wie DNS, NTP oder Syslog zum Einsatz kommt. Dieser Port ist damit für Firewall- und Paketfilterzwecke freizuschalten. Ob der Server bereit ist, lässt sich mit »netstat -tan | grep :79« schnell herausfinden – hier sollte mindestens eine Zeile entfallen, die dem TCP-Dienst auf Port 79 den Zustand »LISTEN« bescheinigt.

Um den Daemon anzusprechen, geben Sie folgendes Kommando ein:

telnet localhost 79

Der Telnet-Client gibt dann drei Zeilen an Information aus:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Er hat sich erfolgreich mit 127.0.0.1 verbunden (das ist der lokale Host); das Escape-Zeichen gilt nur für den Telnet-Client. Der Daemon wartet nun auf eine einzelne Befehlszeile. Hier genügt bereits ein schlichtes »mas«; der Server interpretiert den Suchbegriff sowohl als User-Kennung als auch als realen Namen. Die Treffer zu beiden gibt er über die bestehende TCP-Verbindung zurück (siehe Listing 1), die er danach sogleich beendet.

Bleibt die Befehlszeile leer (nur [Return] drücken), liefert der Finger-Daemon eine Liste aller angemeldeten Benutzer. Zusätzlich sind rekursive Anfragen erlaubt, bei denen der Finger-Server seinerseits eine Verbindung zu einem anderen Server öffnet und die Daten von dort abholt. Nützlich ist das etwa bei einer Firewall. Das Format einer entsprechenden Anfrage ist » User @Hostname«. Diese Technik klappt sogar rekursiv über mehrere Finger-Server hinweg, zusätzliche Hostnamen in der Anfrage, ebenfalls durch »@«-Zeichen getrennt, genügen.

Jede Finger-Befehlszeile endet mit der Zeichenfolge CRLF (Carriage Return plus Line Feed). Das ist bei TCP-Verbindungen so üblich: Obwohl Unix und Linux Textzeilen durch ein einzelnes Line Feed voneinander trennen, verwenden praktisch alle TCP-basierten Protokolle die Zeichenfolge CRLF. So ist sichergestellt, dass Systeme aller Architekturen miteinander sprechen können. Beispielsweise Windows-Rechner, die CRLF der Einfachheit halber bereits nativ verwenden, oder Apple-Macintosh-Maschinen, die ihre Zeilen durch CR trennen.

Diese Zeilenendezeichen tragen in Manpages und vielen Anleitungen unterschiedliche Namen. Da sich ein Line Feed per Default mit [Control]+[J] eingeben lässt, heißt er oft »^J«; in C und verwandten Sprachen »n«. Im Ascii-Code hat er die hexadezimale Nummer 0x0a, dezimal 10. Bei Carriage Return lauten die Namen »^M« und »r«, die Nummer ist 0x0d oder dezimal 13.

Kein Angst vor Finger

Bevor Sie den Finger-Server jetzt gleich in Ihrem Netz tatsächlich einsetzen, sollten Sie auf jeden Fall den Kasten “Sicherheit des Finger-Dienstes” lesen und bedenken. Wer Finger kennt, muss den Dienst aber nicht fürchten – er hat viele gute Seiten. (fjl)