AppleTalk-Server vom Mac aus verwalten: die Werkzeuge, die es gab — und das Frontend, das nie existierte

Die Frage kam beim Aufräumen des netatalk-Servers auf: Es gibt heute ein selbstgebautes CGI-Werkzeug, mit dem sich AppleVolumes.default aus dem Netscape Navigator 3 bearbeiten lässt — aber gab es so etwas nicht schon einmal? Irgendein Werkzeug, mit dem man einen AppleTalk-Server vom Vintage-Mac aus verwaltet?

Die kurze Antwort: für netatalk und atalkd nie. Die längere ist interessanter, weil sie zeigt, dass die Idee sehr wohl existierte — nur eben für andere Geräte.

Warum es kein Frontend gab

Zwei Gründe, die zusammenwirken.

Der erste ist kulturell. netatalk kam aus der Unix-Welt und hat immer vorausgesetzt, dass jemand mit einem Terminal an der Konfigurationsdatei sitzt. Ein Mac-Client war das, was der Server bedient — nicht das, worüber er sich bedienen lässt.

Der zweite ist protokollarisch und wiegt schwerer: AFP kennt keinen Verwaltungskanal. Das Protokoll transportiert Dateien, Verzeichnisse, Metadaten und Anmeldungen. Es gibt darin keine Anfrage der Art „lege ein Volume an" oder „lies die Konfiguration". Apples eigener AppleShare File Server hatte dafür eine Administrationsanwendung, die auf herstellereigenen Erweiterungen aufsetzte — und die hat netatalk nie nachgebaut. Ein Mac mit AppleShare Admin sieht einen netatalk-Server deshalb als ganz gewöhnlichen Fileserver und findet nichts zum Verwalten.

Wer vom Mac aus etwas ändern wollte, brauchte also einen eigenen Kanal. Genau das ist der Punkt, an dem 1993 niemand HTTP gesagt hätte — und an dem heute ein Formularserver die Lücke schließt.

Was es gab: beobachten

Lesend war der Mac erstaunlich gut ausgestattet. Das Referenzwerkzeug kam von Apple selbst: die Inter•Poll Network Administrator’s Utility. Sie bündelte Netzwerk-Kartierung, Fehlersuche, die gezielte Suche nach aktiven Geräten, Tests der Verbindungsintegrität und Versionsabfragen der Systemsoftware auf den Arbeitsplatzrechnern.

Technisch interessant ist, wie die Geräteabfrage funktioniert. Macs mit laufendem AppleTalk-Stack melden sich per NBP an und beantworten auf einem eigenen Socket — meist 252 oder 253 — ATP-Anfragen mit Binärdaten und Versionsangaben. Dieses „Responder"-Protokoll ist das SIP, und genau dort fragt Inter•Poll nach; eine Diskussion im 68kMLA-Forum hat den Weg bis in den XNU-Quelltext zurückverfolgt.

Auf einen netatalk-Server angewandt heißt das: Inter•Poll zeigt vom Mac aus dieselben NBP-Anmeldungen, die auf der Serverseite nbplkup ausgibt — im Fall dieses Projekts also ApfelNetz:AFPServer auf Node 79 im Netz 65280. Man sieht damit, ob atalkd sich korrekt registriert hat, in welcher Zone er hängt und welche Adresse er sich gegeben hat. Ändern lässt sich davon nichts.

Aus dem Drittanbieterlager kam vor allem Neon Software mit einer ganzen Serie: NetMinder Ethernet und NetMinder LocalTalk als reine Software-Protokollanalysatoren, LANsurveyor zum Kartieren von AppleTalk- und IP-Netzen, TrafficWatch II zur Verkehrsbeobachtung, dazu RouterCheck für die Router-Verwaltung und CyberGauge für Bandbreitenmessung. Eine Produktübersicht bei MacTech listet sie zusammen auf. Auch hier gilt: Sie zeichnen ein Bild des Netzes, sie schreiben keine Konfiguration auf fremde Rechner.

Was es gab: konfigurieren — aber nur Appliances

Hier wird es für dieses Projekt spannend, denn die Idee „AppleTalk-Dienst vom Mac aus einstellen" gab es sehr wohl. Sie gehörte nur der Hardware-Welt.

Das schönste Beispiel ist die Cayman GatorBox. Ihr Aufgabenprofil liest sich wie eine Zusammenfassung dieses Projekts: In erster Linie ein AppleTalk-Router, der Geräte auf LocalTalk und Ethernet zusammenbringt; dazu TCP/IP-Dienste für LocalTalk-Macs, Unix-Druck über GatorPrint und — mit GatorShare — Unix-Dateidienste, die auf dem Mac als AppleShare erscheinen. Also atalkd plus papd plus afpd, nur in einer Kiste. Eine ausführliche Konfigurationsbeschreibung und die originalen Handbücher als PDF (Setting Up Your GatorBox, User’s Guide) sind erhalten geblieben.

Verwaltet wurde das Gerät mit GatorKeeper, einer Mac-Anwendung, die auf der Konfigurationsdiskette des Softwarepakets mitkam. Sie stellte über das Netz ein, was sonst in Konfigurationsdateien stünde: Zonenlisten, AppleTalk-Tunnel, Paketfilter, KIP-Optionen. Ein Detail mit Charme steht in einer Cayman-Netzwerkreferenz: Zum Konfigurieren verlangt die GatorBox ein System vor Open Transport, also etwa System 7 oder 7.1 — mit 7.6.1 wird es bereits eng.

Dieselbe Bauart gab es bei Kinetics und später Shiva mit dem FastPath und bei Farallon mit dem StarRouter. Wer 1991 einen AppleTalk-Dienst grafisch vom Mac aus einstellen wollte, kaufte also eine Appliance. Wer stattdessen einen Unix-Rechner nahm, bekam Quelltext und eine Manpage.

Was es gab: der Umweg über den Unix-Rechner

Bleibt die dritte Kategorie — nicht den Dienst verwalten, sondern den Rechner, auf dem er läuft.

Terminalprogramme sind der offensichtliche Weg und im Projektlog zu diesem Server schon abgehandelt: NCSA Telnet und BetterTelnet laufen auf 68k, SSH scheidet praktisch aus, weil NiftyTelnet nur SSH-1 spricht.

Der interessantere Weg ist X11. Apple hat mit MacX einen eigenen X-Display-Server gebaut — anfangs intern für die 68000er-Macs entwickelt, die Fassungen für X11R4 und X11R5 dann von AGE Logic. Damit ließ sich ein grafisches Konfigurationswerkzeug vom Unix-Host auf den Mac holen, neben den gewohnten Mac-Programmen. Die Anforderungen waren happig: mindestens System 7, ein 68030, 8 MB RAM und MacTCP.

Die Alternative kam von White Pine: eXodus. Für dieses Projekt bemerkenswert ist die Notiz zur letzten 68k-fähigen Fassung eXodusII 7.0 — sie unterstützt X11R6.3, XDM sowie Rooted- und Rootless-Darstellung, verlangt mindestens einen 68020 und läuft laut Beschreibung auch unter Basilisk II. Der Emulator dieses Projekts könnte den Weg also tatsächlich gehen. Eine deutschsprachige Übersicht der 68k-Netzwerkprogramme sammelt die Anforderungen der einzelnen Titel.

Am anderen Ende der Skala steht Apples eigener Versuch, Unix-Administration mit AppleTalk zu versöhnen: Auf dem Apple Network Server unter AIX gab es eigene SMIT-Menüs für AppleTalk, damit AIX-Administratoren das Netz in der gewohnten Oberfläche verwalten konnten. Nur eben auf der Serverkonsole, nicht vom Mac aus.

Übersicht

Was daraus folgt

Die Lücke, die das Werkzeug in diesem Projekt füllt, ist echt und war es immer. Für atalkd gab es nie ein Mac-Frontend, weil AFP keinen Verwaltungskanal kennt und niemand einen eigenen dafür erfunden hat. Vom 68k aus ließ sich ein AppleTalk-Netz hervorragend beobachten und ein Router-Kästchen bequem einstellen — der Unix-Rechner dazwischen blieb eine Blackbox mit Terminalzugang.

Dass ausgerechnet HTTP die Antwort ist, wäre 1993 keine naheliegende Idee gewesen. 1996, mit einem Netscape auf jedem Schreibtisch, dann schon.

Nachtrag: Juni 2026

Während dieser Text entstand, ist die Grundlage des Ganzen ein Stück weit weggebrochen. Die Linux-Entwickler haben AppleTalk aus dem Kernel entfernt — knapp 4000 Zeilen, wirksam ab Version 7.2. Auslöser war laut Phoronix eine Welle KI-generierter Patches für ein Protokoll, das niemand mehr reviewen wollte; AppleTalk folgt damit AX.25 und den Amateurfunk-Treibern aus dem Baum.

Ganz verschwunden ist der Code nicht: Er wird künftig außerhalb des Kernels unter linux-netdev/mod-orphan gepflegt, ein Bau als externes Modul bleibt also möglich. In der Diskussion im 68kMLA taucht außerdem TailTalk auf, ein Versuch, den AppleTalk-Stack im Userspace neu zu bauen.

Für den ODROID dieses Projekts mit seinem uralten Kernel ändert sich vorerst nichts. Für alles, was danach kommt, ist es die relevanteste Nachricht des Jahres — und ein guter Grund, den Aufbau zu dokumentieren, solange er noch läuft.

Passend dazu die beiden anderen Texte dieser Rubrik: der Projektlog zum Admin-Werkzeug und die Referenz zur netatalk-Administration.