Re: Patch-Bug oder Error 42 (Change Operator)

[Betreff geändert, da es nichts mehr mit patch zu tun hat]
> Auf was für einem FreeBSD machst Du das?
3.4-stable von Mitte Januar...

> Ebenfalls keine Probleme mit Abstürzen oder sowas, im Gegenteil, alles
> ziemlich zufriedenstellend.
Och, netatalk an sich führt auch nicht zum Absturz, aber wenn man versucht,
in einem ansonsten leeren Netzwerk einen seed-router aufzusetzen, mit
nbplkup (grr) nachsieht, die Netatalk-Daemons ein paar Mal killt und mit
neuer Konfigurartion neu startet, dann scheppert es schon mal. Leider
habe ich z.Zt. weder eine Konsole noch eine serielles Terminal an der
Kiste, daher habe ich keine genauere Fehlerbeschreibung.

> CAP und seine Säcke von Patches haben mich 1998 davon abgehalten, es zu
> verwenden. Du bestätigst meinen Eindruck, daß dabei nichts besser geworden
> ist :-(
Tja, bis auf den Fehler in patches sind die Patches zu CAP kein Problem und
auch automatisierbar eingespielt. Und wenn man das ein Mal gemacht hat, ist
CAP eine *sehr* gute Alternative zu netatalk. Aus dem ganz einfachen Grund,
daß ein ernsthafter CAP-Fehler (so es denn noch welche gibt) immer nur zum
Absturz der Userland-Binaries führt - und nicht zur Kernel Panic wie bei
netatalk. Ich habe unter SunOS/Solaris rund 15 Maschinenjahre CAP hinter
mir und habe nicht eine einzige Kernel Panic durch CAP erlebt.

Das ist eigentlich der Hauptgrund, warum hier CAP läuft: Ich kenne es ganz
gut von der Administrationsseite und auch die Fallstricke, die man so
erleben kann; bei Netatalk müßte ich wieder von vorne anfangen. Da ich
aber noch andere Dinge zu tun habe und die ganze Geschichte eh nur dazu
dient, einen Laserwriter IINT über einen als Ethertalk/Localtalk-Bridge
mißbrauchten Mac IIcx zum fliegen zu kriegen, ist auch nicht der Druck
da, sich mit dem Thema Netatalk zu beschäftigen.

Das wird sich definitiv ändern, wenn die Samba/Netatalk-Integration ein
Stadium erreicht, in der sie auch beim Locking mit einem NT Server mit SFM
mithalten kann. Aber dann werde ich das auf einer der zur Zeit ungenutzten
Sparc 2 in der Firma testen und nicht auf dem FreeBSD-Rechner, den ich hier
brauche.

> Ich habe aber Netatalk auch nicht zum Routen verwendet
Ich route hier eigentlich auch nicht (CAP kriegt genau ed1 und mehr nicht),
aber seeding geht halt nur mit einem Appletalk-Router. Oder, um genau zu
sein, ich habe noch kein Programm gesehen, daß seeding beherrscht und nicht
auch gleichzeitig routen kann.

> Kannst Du das eventuell mit dem Ethernet bridging von FreeBSD erschlagen?
Mit dem Begriff "seed-router" bezeichnet man einen Element in einem Netz,
das u.a. die Liste der Appletalk-Zonen zur Verfügung stellt. Das ist mit
den Workgroups unter Winsucks vergleichbar, jedes Device gehört halt zu
einer Zone und wenn man auf eine Resource im Netz zugreifen will, kriegt
man zunächst mal nur die Resourcen der eigenen Zone angezeigt.

Der große Unterschied zu den Winsucks-Workgroups ist, daß es dedizierte
Verwalter dieser Zonelists gibt und alle anderen Netzwerkteilnehmer nur aus
den angebotenen Zonen auswählen dürfen. Unter Winsucks kann ja jeder Client
eine Workgroups erzeugen (auch als "Wie stelle ich sicher, daß alle meine
Tippfehler sehen"-Funktion bekannt).

Das ist jetzt definitiv nicht vollständig, für alles weitere verweise
ich mal auf die Mac/Apple/Appletalk/Ethertalk/CAP-Dokus.

Diese Funktion wird in "richtigen" Netzen meistens von den dedizierten
Routern nebenbei erledigt, im Homenetz tut es dann halt ein UAR-Prozeß.
Und in einem solchen Netz ist ist die UAR-Konfig trivial, die Integration
von CAP und UAR beschränkt sich auf ein "yes" auf die Frage "Do you want to
use UAR?" im Configure-Script von CAP...

/s/Udo
PS: Achja, der Drucker druckt inzwischen. Von Windows 95 aus per
M$-Protokoll (DLC/LLC?) zum Samba-Server, von dem ins Unix Drucksystem, da
via CAP wieder raus und per PAP-over-Ethertalk zum Mac, dort durch die
Laserwriter Bridge und dann per PAP-over-Localtalk zum Drucker. Pervers,
aber geht -- und zwar schneller als ein serieller Link mit 9600 bps.

-- 
Ich bin root, ich darf das
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message