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

On Sat, Jan 29, 2000 at 06:39:54PM +0100, Udo Erdelhoff wrote:

> 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

Hmja, das war das, was mit irgendwelchem grmblprz immer meine xterms
verwirrt hat - vermutlich auch daraus, daß irgendwelche Geräte gnadenlosen
Datenmüll in ihre Namenseinträge schreiben.

> neuer Konfigurartion neu startet, dann scheppert es schon mal. Leider

Aha. Na gut, daß man den Kernel nach zu häufigem Neustart des afpd usw. mal
durch einen reboot wieder zu klaglosem Funktionieren bringen muß, habe ich
auch erlebt.

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

Der Server war anfänglich nur ein PII/200 mit 100-MBit/s-Netzwerkadapter
und ungefähr ein halbes Dutzend Macs, und ich empfand CAP als zäh und dabei
ressourcenlastig, weil es über Berkeley packet filters geht. Die nicht vor-
handene Stabilität habe ich nicht erlebt, und der von mir betreut gewesene
Rechner lief schon als ernstzunehmend genutzter File-Server, der praktisch
ständig von mindestens 3-4 Plätzen genutzt wurde.

> 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

Jaja, das ungefähr wie sendmail, der ohne Leidensdruck nicht einfach aus
Jux ersetzt wird.

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

Danke für die Erläuterung. Ich habe mir über Zonen-Verteilungen nie
großartig Gedanken machen müssen, weil das Netz eher klein war und
kurzerhand auf switched hubs verteilt wurde. Das hat an der Stelle
auch Sinn ergeben. Ich habe TCP/IP auf den Macs über BOOTP konfiguriert
(das wurde eigentlich erst schlimm, als ich bei einigen PCI-Macs neue
(100-MBit/s-) Netzwerkkarten eingebaut habe und sich somit die Mac-
Adressen veränderten und ich Teile davon kürzlich noch rückgängig machen
mußte...) und AppleTalk bzw. EtherTalk ansonsten sich selber überlassen.

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

Ach, Du kannst auch mal in de.alt.folklore.computer fragen, ob noch jemand
eine LocalTalk-Adapterkarte für einen ISA-Slot für Dich hat. Sowas muß es
gegeben haben, ich habe sowas nicht gesehen (ich habe mich auch - von der
reinen Benutzung in der Berufsschule abgesehen - erst ab 1997 intensiver
mit Macs beschäftigen müssen), aber irgendwas habe ich da auch noch mit
Treibern für NetBSD in Erinnerung... :-)

Gruß,
     Martin

-- 
,,You know, there's a lot of opportunities, if you're knowing to take them,
        you know, there's a lot of opportunities, if there aren't
         you can make them, make or break them!'' (Tennant/Lowe)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message