HELIOS EtherShare 2.6 Benutzerhandbuch


A 7: Technische Hinweise
Der folgende Abschnitt enthält verschiedene technische Informationen über EtherShare, die in erster Linie nur für erfahrene Systemadministratoren von Interesse sind.
A 7.1 EtherShare-Logdateien
Im Folgenden wird die Struktur der EtherShare Drucker Logdatei und Server Logdatei beschrieben. Bitte lesen Sie für eine Beschreibung der "System Meldungen" Ihr UNIX-Handbuch. Alle drei Dateien können in EtherShare Admin überprüft werden, indem der entsprechende Punkt aus dem Menü Listen gewählt wird.
Struktur der Drucker
Logdatei
Jeder Eintrag in der Drucker Logdatei
"$ESDIR/printer.acct" (mit den Anhängen ".0" für gestern bis ".6" für vor sieben Tagen) hat folgendes Format:
status, ptrName, "username", "JobTitle",
startTime, duration, pages, ListOfFonts

wobei gilt:
status (Dezimalwert):
3 generelle UNIX-Warnung
2 PostScript-Ausgabe
1 UNIX-Info (z.B. erweiterte Druckinformation)
0 OK
-1 Kommunikationsfehler
-2 PostScript-Fehler
-3 abgebrochener Druckauftrag (z.B. Signal "kill")
-4 UNIX-Fehler (z.B. Datei nicht gefunden)
ptrName (Zeichenfolge): logischer (UNIX)-Druckername
"username" (Zeichenfolge): aus dem PostScript-Titel des Druckauftrags
"JobTitle" (Zeichenfolge): z.B. Dokumentenname, aus dem PostScript-Titel des Druckauftrags
startTime (Dezimalwert): Startzeit, Sekunden seit 1.1.1970 (UNIX time_t-Werte)
duration (Sekunden): = endTime-startTime
pages (Dezimalwert): = endPage-startPage (festgestellt durch eine Abfrage des Druckers über den Befehl "pagecount.ps")
ListOfFonts (Liste von Zeichenfolgen): verwendete Schriften, durch Leerzeichen getrennt
Wenn beim Drucken ein Fehler aufgetreten ist (status0), dann folgt dieser Zeile die Fehler-Ausgabe des Druckers eingeschlossen von den Zeilen "Error output:" und
"End error output". Wenn keine druckbaren Daten an den Drucker geschickt werden (pages=0), dann wird für die Dauer "0" ausgegeben.
Bitte lesen Sie den Abschnitt mail in 11.6 "Manuelle Druckerkonfiguration" zu Informationen über die Arten von Meldungen, die in die Drucker Logdatei geschrieben werden. Es werden generell nur dann Meldungen in die Drucker Logdatei geschrieben, wenn Sie beim Anlegen einer Drucker-Warteschlange in EtherShare Admin die Option Abrechnungsdatei aktiviert haben.
Benutzer- und Dokumentnamen in Druckaufträgen
Der mit jedem Druckauftrag in der Drucker Logdatei "$ESDIR/printer.acct" notierte Benutzername (und der Benutzer, an den Fehlermeldungen als Nachricht per E-Mail gesendet werden) wird ermittelt, indem der PostScript-Vorspann des Druckauftrags nach dem in dem "%%For"-Kommentar enthaltenen Namen durchsucht wird.
Beginnend ab dem Betriebssystem Macintosh System 7.x wird der Name in dem "%%For"-Kommentar automatisch mit dem Benutzernamen belegt, der in dem Macintosh-Kontrollfeld File Sharing angegeben ist.
Wenn der "%%For"-Kommentar fehlt oder kein Benutzername eingetragen ist, werden alle Druckaufträge immer dem Benutzer "nobody" zugeordnet.
Wenn ein Name angegeben wurde, jedoch in der Liste der vollständigen oder kurzen Benutzernamen in der Datei "/etc/passwd" nicht gefunden wird, erscheint der angegebene (unbekannte) Benutzername trotzdem in der Drucker-Logdatei, jedoch wird jede Fehlermeldung stattdessen als Nachricht an den Benutzer "root" geschickt.

Hinweis: Wenn Sie die Option Benutzer Name sichern oder Kennwort sichern in der Auswahl des Macintosh aktiviert haben, dann ist es möglich, dass der im System gesicherte Name nicht mit dem im Kontrollfeld File Sharing identisch ist. Dies liegt daran, dass in der Auswahl die Möglichkeit besteht, den angezeigten Namen vor dem Sichern zu überschreiben. Die Logdatei verwendet immer den im Kontrollfeld File Sharing gesicherten Namen.

Der Titel des Dokuments wird ermittelt, indem der PostScript-Vorspann des Druckauftrags nach dem Namen im "%%Title"-Kommentar durchsucht wird.
Sie sollten versuchen, diese PostScript-Kommentare auch für UNIX- und MS-DOS-Druckaufträge vorzugeben, damit Sie immer komplette Informationen in der Drucker Logdatei haben.
Struktur der Server
Logdatei
Jeder Eintrag in der Server Logdatei "$ESDIR/server.acct" (mit den Anhängen ".0" für gestern bis ".6" für vor sieben Tagen) hat folgendes Format:
status, svrName, ws_address, pe_status, usrname,
startTime, duration, usrTime, sysTime, rusage

wobei gilt:
status = 1 (normale Anmeldung)
svrName (Zeichenfolge): Name des Servers
ws_address (Zeichenfolge): Netzwerkadresse de Arbeitsstation (TCP/IP oder AppleTalk)
pe_status (Dezimalwert): Status beim Beenden eines UNIX-Prozess (0 = OK; 1-127 = Fehlerkondition, d.h. das Programm wurde vorzeitig beendet; 128-255 = unvorhergesehenes Programmende, fragen Sie Ihren Systemadministrator)
usrname (Zeichenfolge): Benutzername für die Anmeldung
startTime (Dezimalwert): Zeitpunkt der Anmeldung, Sekunden seit 1.1.1970 (UNIX time_t Werte)
duration, Sekunden: = endTime-startTime
usrTime (Dezimalwert): Vom Benutzerprozess verbrauchte Prozessorzeit.
sysTime (Dezimalwert): Vom Prozess während des Systemmodus verbrauchte Prozessorzeit.
rusage (Folge von Dezimalwerten): Information über die Verwendung von Ressourcen. Die Form ist abhängig vom Betriebssystem - bitte lesen Sie die Beschreibung von "getrusage" in Ihrer UNIX-Dokumentation. Einige der Ressourcen-Nutzungseinträge sind aufgeschlüsselt und werden von EtherShare Admin im "Server Logdatei"-Fenster verwendet.
Jeder Eintrag in der Server Logdatei "$ESDIR/server.acct" hat das folgende Format für eine nicht erfolgreiche Anmeldung:
status, svrName, ws_address, pid, name, time
wobei gilt:
status = 2 (fehlgeschlagene Anmeldung)
svrName (Zeichenfolge): Name des Servers
ws_address (Zeichenfolge): Netzwerkadresse der Arbeitsstation (TCP/IP oder AppleTalk)
pid: Prozess-ID
name (Zeichenfolge): Name mit dem ein Anmeldeversuch erfolgte
time (Dezimalwert): Zeitpunkt des Anmeldeversuchs, Sekunden seit 1.1.1970 (UNIX time_t-Werte)
A 7.2 PostScript-RIP-INIT in EtherShare Admin
Bei der Verwendung von Drucker-Initialisierungssequenzen (INIT) in EtherShare Admin darf der Operator "exitserver" nicht enthalten sein, da sonst der folgende Druckauftrag nicht korrekt ausgeführt wird. Das liegt daran, dass das INIT in demselben PAP-RIP-Vorgang an den Drucker geschickt wird wie der folgende Druckauftrag.
Erörterung: Das INIT muss normalerweise nicht das Server-
Funktionsverzeichnis dauerhaft verändern, da es jedem einzelnen Druckauftrag automatisch vorangestellt wird. Außerdem ist es nicht zu empfehlen, das Server-Funktionsverzeichnis über ein INIT aus EtherShare Admin abzufragen und umzusetzten, da sonst bei jedem Druckvorgang die geänderte Information in das RIP EEPROM geschrieben wird. Das EEPROM des RIPs hat aber nur eine Programmierungslebensdauer von 10.000 Zyklen.
Lösung: Vereinfachen Sie das INIT durch die Entfernung des Operators "exitserver".
Das INIT sollte nach Möglichkeit die Werte der Parameter, die verändert werden sollen, zunächst abfragen, um zu überprüfen, ob sie bereits den gewünschten Wert haben. Dieser Vorgang spart Verarbeitungszeit im RIP. Ein Beispiel:
Empfohlenes INIT aus dem Handbuch des RIPs:
serverdict begin 0 exitserver
statusdict begin 2400 setresolution end

INIT für die Verwendung in EtherShare Admin empfohlen:
statusdict begin
resolution 2400 eq not {2400 setresolution} if
end

EtherShare Admin kann mit den üblichen PostScript-Kalibrierungswerkzeugen erweitert werden, die automatisch als Untermenü im Listeneintrag Initialisierung bearbeiten im Menü Drucker erscheinen. HELIOS stellt Herstellern von Satzmaschinen auf Anfrage Programmierungsanleitungen für die Entwicklung solcher Werkzeuge zur Verfügung.

Hinweis: INITs können keinen PostScript-Code zur Abfrage des RIPs enthalten, da es zurzeit keine Möglichkeit gibt, die Antwort an EtherShare Admin zurückzusenden.

Wichtig: Bitte kontaktieren Sie Ihren RIP-Lieferanten und nicht HELIOS, wenn Sie Probleme und/oder Fragen bezüglich RIP-INITs oder RIP-Konfigurationen haben.

A 7.3 Verwendung der ISO-8859-1-Zeichentabelle unter IBM AIX 4
Beginnend mit AIX Version 3.2 unterstützt IBM für jeden von Programmen und Systemwerkzeugen dargestellten Text zwei Zeichensätze. Die beiden unterstützten Zeichensätze sind IBM-850 (IBM-PC-Variante) und ISO 8859-1 (DEC VT200-Variante). AIX 3.1 unterstützte nur den Zeichensatz IBM-850.
HELIOS Terminal ist ein DEC VT320-Emulator und verwendet somit den Zeichensatz ISO-8859-1. AIX verwendet standardmäßig die IBM-850-Kodierung und daher werden alle länderspezifischen Zeichen wie beispielsweise deutsche Umlaute nicht korrekt dargestellt. Die Umgebungsvariable "LANG" bestimmt die verwendete Kodierung. Wenn der erste Buchstabe der Variablen "LANG" ein Großbuchstabe ist, wird die IBM-850 Verschlüsselung verwendet. Ist der erste Buchstabe ein Kleinbuchstabe, wird ISO 8859-1 verwendet. Für Deutschland bedeutet das:
LANG=de_DE für ISO-8859-1
LANG=De_DE für IBM-850
Die Umgebungsvariable "LANG" kann lokal in Ihrer ".profile"- oder ".login"-Datei eingestellt werden oder als Voreinstellung global für das gesamte System über das folgende SMIT-Untermenü gesetzt werden:
System Environments
-> Manage Language Environment
-> Change Language Environment

Allerdings sind nicht alle Kataloge mit Meldungen in beiden Zeichenkodierungen vorhanden. Glücklicherweise hat SMIT eine Menüoption, um Kataloge mit Meldungen von einer Zeichenkodierung in eine andere umzuwandeln. Verwenden Sie dafür das folgende SMIT-Untermenü:
System Environments
-> Manage Language Environment
-> Convert Files
-> Convert System Messages

Dann nehmen Sie Einträge ähnlich dem Folgenden vor
(das Beispiel konvertiert die deutschen Kataloge):
* CURRENT DIRECTORY name [/usr/lib/nls/msg/De_DE] +
NEW DIRECTORY name [/usr/lib/nls/msg/de_DE]
CURRENT CODE set [IBM-850] +
NEW CODE set [ISO8859-1] +

Dies wandelt alle Kataloge mit Meldungen im Verzeichnis "/usr/lib/nls/msg/De_DE" vom IBM-850- in das
ISO-8859-1-Format um. Die original IBM-850-kodierten Dateien bleiben erhalten, damit Sie dann alle Meldungen in beiden Formaten verfügbar haben.
A 7.4 Zugriff auf Warteschlangen von einem logischen IBM-Drucker
Um eine EtherShare-Druckerkonfiguration aus dem IBM-Drucksystem heraus zu verwenden, können Sie eine neue IBM-Warteschlange definieren, über die alle an diese Warteschlange geschickten Druckaufträge automatisch an das EtherShare-Drucksystem weitergeleitet werden. Angenommen Sie haben in EtherShare Admin einen UNIX-Drucker mit Namen "lw" angelegt " dann sollten Sie die folgenden Zeilen in der Datei "/usr/lpd/qconfig" hinzufügen:
lw:
device = lwdev
discipline = fcfs
lwdev:
backend = /usr/local/es/lpr -Plw

Hierdurch wird eine AIX-Warteschlange mit Namen "lw" erstellt, die die EtherShare-Warteschlange "lw" verwendet.
Sie können dann keine Druckaufträge mehr in der IBM-Warteschlange sehen, da diese alle automatisch weitergeleitet werden. Sie können sie stattdessen in der Anzeige der EtherShare-Warteschlange sehen.
Alternativ erhalten Sie die gleiche Funktionalität, wenn Sie bei der Verwendung des Programms "lpr" immer daran denken, den vollen Pfad ("/usr/local/es/lpr") anzugeben.
Sie können auch eine Warteschlange anlegen, die automatisch Text in PostScript umwandelt. Zum Beispiel:
pstext:
device = textdev
discipline = fcfs
textdev:
backend = /usr/local/es/pstext -Plw

A 7.5 Zugriff vom Druckserver auf den System V "lpr"-Prozess
Der EtherShare-Druckserver basiert auf dem BSD-Drucksystem. Wenn Ihr Host das System V-Drucksystem verwendet (beispielsweise Sun Solaris 2.x), setzt der Druckserver normalerweise sein eigenes "lpr"-Programm ein. Dieses ist für solche Fälle im Verzeichnis "$ESDIR" vorhanden. Man-Pages für die BSD-Variante des Programms "lpr" sind auf der CD-ROM im Verzeichnis "manuals" zu finden.
Um vom EtherShare-Druckserver auf das System V-Programm "lpr" zuzugreifen, benötigen Sie eine Konfiguration, die der einer "In-Datei-drucken"-Warteschlange sehr ähnlich ist:
papsrv: name="xxxx", printer=xPrinter,
lpr=/bin/lpr, resolve

wobei:
xxxx der benötigte AppleTalk-Druckername,
xPrinter der logische Druckername (s. Eintrag in der
Datei (printcap) und
lpr das System V-Programm "lpr" und nicht das
EtherShare-Programm "lpr" im Verzeichnis
"/usr/local/es".
Um das benötigte Spool Verzeichnis und den symbolischen Link anzulegen sowie den Eintrag in die Datei "/etc/printcap" und eine "FONTS"-Datei automatisch zu erstellen, empfehlen wir Ihnen, zunächst einen Drucker mit einer "Remote LPR"-Verbindung anzulegen. Anschließend können sie den entsprechenden Eintrag in der Datei "atalk.conf" und die zugehörige "FONTS"-Datei manuell editieren.
Ein BSD-"lpq"-Befehl ist in der RS/6000-Version von EtherShare enthalten, da er nicht im Standardumfang des Betriebssystems AIX enthalten ist. Sie können ihn verwenden, um den Status eines Druckauftrags aus einer UNIX-Shell heraus wie folgt zu prüfen:
/usr/local/es/lpq -P<printername>.
Oder Sie benutzen stattdessen eine Warteschlange vom Typ "diskif" und ein nachgeschaltetes Skript (Lesen Sie dazu bitte notifyprog in 11.6 "Manuelle Druckerkonfiguration").
A 7.6 Zugriff über "Remote LPR" auf den Druckserver
Wenn Ihr Host das System V-Drucksystem verwendet (beispielsweise Sun Solaris 2.x) und Sie möchten für eine spezielle Konstellation Druckaufträge über den "Remote LPR"-Mechanismus im "BSD"-Drucksystem von EtherShare empfangen, dann müssen Sie zunächst die lokale System V-Netzwerkdruck-Funktionalität deaktivieren. Die Installationsroutine von EtherShare kommentiert nämlich die Zeile mit dem Eintrag "printer" in der Datei "/etc/inetd.conf" aus.
A 7.7 Kernel-Konfiguration für AppleTalk-Nutzung
EtherShare benötigt die Unterstützung vom Betriebssystem, um mit Hilfe des AppleTalk-Protokolls kommunizieren zu können. Üblicherweise liefern UNIX-Anbieter in den Standardversionen ihrer Betriebssysteme nur die TCP/IP-Netzwerkprotokolle jedoch nicht die AppleTalk-Protokolle aus. Daher enthält EtherShare Treiber, die das AppleTalk-Protokoll in einer Ethernet-Umgebung implementieren. Auf einigen Maschinen unterstützt EtherShare auch andere Netzwerk-Technologien wie beispielsweise Token Ring. Alle für den UNIX-Kernel relevanten Dateien des EtherShare-Systems liegen im Verzeichnis "$ESDIR/kernel". Das Folgende ist eine detaillierte Beschreibung darüber, was im Betriebssystem durch die EtherShare-Installation verändert wird. Dies ist wahrscheinlich nur für fortgeschrittene UNIX-Benutzer von Interesse, da die Shell-Skripte der EtherShare-Konfiguration die meisten der für den Start der AppleTalk-Treiber notwendigen Details gar nicht anzeigen.
Die Kernelmodule gibt es abhängig von der Architektur des Host-Betriebssystems in zwei Varianten. System V.4-basierende Systeme verwenden eine Datenstrom-basierende Architektur. Hier wird jeder AppleTalk-Kommunikationsendpunkt durch einen Zeiger auf eine Datei repräsentiert, der über den Datenstrom-Multiplexor "/dev/ddp" geöffnet wird. Berkely-basierende Systeme verwenden einen Zeiger auf eine Datei, der über den Socket-Mechanismus geöffnet wird.
A 7.7.1 Zuladbare Treiber
Solaris 2.x-, SGI IRIX-, HP-UX 11- und IBM RS/6000-Systeme unterstützen ein Konzept von zuladbaren Treibern, die je nach Bedarf während des Betriebs in das Betriebssystem geladen werden können. In solchen Fällen ist es nicht nötig, den UNIX-Kernel mit den neuen Modulen dauerhaft zu verknüpfen. Das Shell-Skript "start-atalk" kümmert sich automatisch um das Laden des Treibers, wenn AppleTalk gestartet werden soll und der Treiber noch nicht vorhanden ist.
Solaris 2.x
Systeme
EtherShare verwendet zwei Kernelmodule auf Solaris 2 Systemen. Das Programm "aarp" enthält das "AppleTalk Address Resolution Protocol"-Datenstrom-Modul und
das Programm "ddp" den "Datagram Delivery Protocol"-Datenstrom-Multiplexor. Die Datei "aarp" liegt im Verzeichnis "/kernel/strmod" und die Datei "ddp" im Verzeichnis "/kernel/drv". Beim Installationsvorgang werden die Dateien aus dem Verzeichnis "$ESDIR/kernel" in das Verzeichnis "/kernel" kopiert. Zusätzlich trägt das Installationsskript eine Zeile in die Dateien "/etc/minor_perm" und "/etc/devlink.tab" ein und fügt entsprechende Dateien hinzu, um die korrekte Verknüpfung mit den passenden Rechten vom Eintrag "/devices/pseudo/clone:ddp" zu der Datei "/dev/ddp" zu erhalten. Die Treiber werden von Solaris 2.x automatisch geladen und wieder entladen, so dass kein manuelles Laden und Entladen nötig sein sollte.
Eine lange Liste aller geladenen Module kann unter Verwendung des Befehls "modinfo" angezeigt werden.
Der Befehl "modunload" kann zum Entladen von Treibern verwendet werden, wenn diese nicht gerade verwendet werden.
IBM RS/6000 Systeme
Auf IBM-Systemen wird vom Skript "start-atalk" nur ein Treiber ("$ESDIR/kernel/atalk") geladen. Dieser Treiber ist von der AIX-Version abhängig. Beim Installationsvorgang wird eine Verknüpfung von der entsprechenden und geeigneten Datei zu der Datei "/usr/lib/drivers" erstellt.
Zusätzlich werden Einträge zur ODM-Datenbank hinzugefügt, um das Laden des Treibers durch den Befehl "mkdev" zu ermöglichen. Der logische Name für das Kernelmodul ist "atalk0". Verwenden Sie den folgenden Befehl, um das Modul zu laden:
mkdev -t atalk
Der Befehl "lsdev" kann verwendet werden, um zu überprüfen, ob das Kernelmodul geladen ist:
lsdev -C -l atalk0

Hinweis: Unter AIX wird das Entladen des Netzwerk-Protokolls nicht unterstützt.

SGI IRIX
In SGI IRIX-Systemen liegen die zuladbaren Treiber in dem Verzeichnis "/usr/local/es/kernel" und werden automatisch von dem Skript "start-atalk" mit dem Befehl "ml" geladen. Mit dem Befehl "ml list" kann eine Liste aller zuladbaren Treiber dargestellt werden. Mit "ml unld" und der entsprechenden ID-Nummer (welche Sie aus der Treiberliste erhalten) kann das Modul wieder entladen werden.
HP-UX 11
Die Treiber "aarp" und "ddp" werden mit dem Befehl "kminstall" in das Systemverzeichnis eines HP-UX 11-
Betriebssystems kopiert. Verwenden Sie den Befehl
"kmupdate", um die Module automatisch in den Kernel zu laden.
Um Treiber wieder zu löschen, verwenden Sie die folgenden Befehle:
kminstall -d aarp
kminstall -d ddp
A 7.7.2 Neuerstellung des Kernels
Für Data General AViiON Systeme wird der AppleTalk-Treiber in verknüpfbarer Form geliefert. Das Skript "install" kümmert sich um die Installation der notwendigen Dateien in das Systemverzeichnis und den erneuten Aufbau des Kernel. Alle vom Skript veränderten oder ersetzten Dateien werden mit dem Anhang ".noatalk" gespeichert.
DG AViiON
Auf AViiON-Systemen verwendet der Installationsvorgang die "sysadm"-Menüs, um den größten Teil des komplizierten Verfahrens zur Neuerstellung des Kernels zu erledigen. Beim Installationsvorgang werden Vorlagen- und Bibliotheken-Dateien aus dem Verzeichnis
"$ESDIR/kernel" in die Verzeichnisse "/etc/master.d" und "/usr/src/uts/aviion" kopiert. Der Kernel wird unter Verwendung des folgenden Befehls neu erstellt:
asysadm -m system:kernel -o auto
Die Option auto veranlasst das Programm "sysadm", alle Vorlagen in eine neue Systembeschreibung zusammen zu sammeln und dementsprechend einen neuen Kernel aufzubauen. Wenn dieser Vorgang erfolgreich ist, wird der neue Kernel im Verzeichnis "/" installiert. Bei jedem Neustart des Systems erstellt der Multiplexor-Treiber "ddp" einen "/dev/ddp"-Eintrag für die Benutzerprogramme.
A 7.8 UNIX-Kerneloptimierung
Dieser Abschnitt beschreibt mögliche Optimierungsvorgänge, für die eine umfangreiche UNIX-Erfahrung erforderlich ist. Mit Ausnahme von Weitere Tipps zur Optimierung (siehe unten) sollten sie nicht von Anfängern ausprobiert werden.
Wenn der EtherShare-Host über viel Speicherplatz verfügt, lohnt es sich eventuell, einige Datenstrukturen im Betriebssystem größer als üblich anzulegen. Dadurch werden dann mehr Informationen im Speicher gehalten, die sonst immer wieder von der Festplatte gelesen werden müssten. Moderne Betriebssysteme passen die Werte der Datenstruktur entsprechend dem verfügbaren Speicherplatz automatisch an. Bitte lesen Sie Ihre UNIX-Dokumentation für weitere Informationen.
Solaris 2.x
Optimierung
Das Betriebssystem Solaris 2.x bietet keine Möglichkeit, den Kernel neu aufzubauen. Daher werden neue Parameter nicht durch Modifizieren der in der Programmiersprache C geschriebenen Quelldateien und eines entsprechenden Neuaufbaus des Kernel gesetzt sondern einfach durch Editieren einer Textdatei. Die Datei "/etc/system" kann zum Setzen von Systemparametern einfache Kommentare der Form "set variable=value" enthalten. Die beiden für EtherShare besonders interessanten Parameter sind "ufs_ninode" und "ncsize". Der Parameter "ncsize" hat kein "ufs_"-Präfix, da er sich auf alle Dateisysteme und nicht nur auf das normale UNIX-Dateisystem bezieht. Um diese beiden Werte auf 20000 zu setzen, würde man die folgenden Anweisungen in die Datei "/etc/system" einfügen:
set ufs_ninode=20000
set ncsize=20000
Die Erhöhung der Anzahl der Inodes, die im Arbeitsspeicher gehalten werden können, verbessert die Leistung bei Macintosh Finder-Arbeitsvorgängen oder wiederholtem Öffnen und Schließen von Dateien beträchtlich. Jede Datei, auf die zugegriffen wird (Verzeichnisse sind auch Dateien), belegt einen Inode-Eintrag. Der Inode wird nach dem Schließen einer Datei oder eines Verzeichnisses weiter im Speicher gehalten für den Fall, dass wieder auf die Daten zugegriffen wird. Wenn das System jedoch keine freien Inodes mehr hat, dann funktioniert dieser Mechanismus nicht mehr. In diesem Fall wird der Inode für einen anderen Eintrag benutzt, der wieder von der Festplatte geladen werden muss. Wenn Sie einige Megabytes Speicherplatz zur Verfügung haben, können Sie daher die Anzahl der Inode-Einträge auf beispielsweise 20000 erhöhen, was ungefähr 4 MB RAM erfordert.
Wenn der Kernel aufgrund falscher Parameter in der Datei "/etc/system" nicht gestartet werden kann, können Sie das System unter Verwendung der Option -a hochfahren. Sie werden dann gefragt, welche Dateien und Partitionen verwendet werden sollen. Wenn Sie nach der Datei "/etc/system" gefragt werden, antworten Sie stattdessen einfach "/dev/null".
Weitere Tipps zur Optimierung
EtherShare enthält hocheffiziente AppleTalk-Router-Module, die auch bei starkem Routing-Verkehr keine große Last für die CPU des Hosts darstellen. Sie können häufig das Antwortverhalten des Netzwerks durch die Installation von zwei oder mehr Netzwerkkarten in Ihrem Host und einer Anordnung verbessern, bei der die Last auf zwei separate Segmente aufgeteilt wird.
Diese Methode ist besonders nützlich, wenn Sie die Software EtherShare OPI installiert haben. In solchen Fällen empfehlen wir die Installation einer zweiten Netzwerkkarte eigens für den Drucker/RIP-Verkehr, damit dieser von der von den Arbeitsstationen erzeugten Netzwerklast getrennt wird. Es gibt keine theoretische Begrenzung für die Anzahl von Netzwerkkarten, die vom EtherShare-Router unterstützt werden. Generell bietet es jedoch - außer in den schnellsten Hosts - keine Vorteile, mehr als drei Karten zu installieren.
Andere UNIX-Architekturen
Um andere UNIX-Architekturen zu optimieren, lesen Sie bitte die entsprechende UNIX-Dokumentation. Generell sollten die Abschnitte über "Leistungssteigerung/Optimierung" in den entsprechenden Handbüchern sorgfältig durchgelesen werden.

© 2002 HELIOS Software GmbH