Man kann bis zu vier (E)IDE Platten oder ATAPI CD-Roms in einen Server einbauen, indem man zusätzlich zu einen Standard-AT-BUS-IDE-Controller (INT 15, Base 1f0) einen weiteren nimmt, den man auf Base 170 und IRQ 14 jumpern kann.
Die meisten neueren Boards sind aber schon mit zwei IDE-Ports bestückt bzw. aktuelle VLB oder PCI-Controller haben auch 2 IDE-Ports.
Man sollte aber beachten, EIDE-Platten und IDE-Platten bzw. CDROM-Laufwerke nicht am gleichen Port zu verwenden, da die Geschwindigkeitsvorteile der EIDE-Platte somit verloren gehen.
Darüber hinaus sollten (wenn vorhanden) die spezifischen Netware-Treiber dieser Karten/Boards verwendet werden und nur im Notfall IDE.DSK, auf keinen Fall aber ISADISK.DSK eingesetzt werden. Der IDE.DSK benötigt nicht das BIOS des Rechners, das unter Umständen die Plattenparameter für DOS ummappt, der Treiber ISADISK.DSK dagegen schon.
Man muß bei zwei Ports den Treiber natürlich auch zweimal laden!
"User", die sich direkt im Fileserver anmelden (sprich: NLMs wie PSERVER oder ARCserve), zählen nicht zu den normalen Usern, die Lizenzen verbrauchen. Das sieht man auch, wenn man die "Connection Information" am Server betrachtet. Dort bekommen solche Benutzer Verbindungsnummern jenseits der Maximalzahl der erlaubten User (also bei einer Zehnerlizenz z.B. von 11 an aufwärts).
PSERVER.EXE oder andere externe Printserver verbrauchen dagegen eine Connection innerhalb der Lizenz.
Die (zugegeben lästige) Broadcastmeldung "Volume out of Disk-Space" kann mit Set volume low warn all users = OFF abgestellt werden, das ist aber nicht zu empfehlen. Wenn nur noch 10 MB auf dem Volume frei sind, kommt diese (Broadcast-) Meldung.
Gefahr bei dem Ausschalten ist, wenn Du z.B. eine recht große Datei druckst und die Queue damit gefüllt wird, daß eben dann temporär Speicherplatz auf dem Volume benötigt wird. Ein weiteres Beispiel sind LOG-Dateien, die bei vollen Platten nicht mehr geschrieben und so aufgetretene Fehler nicht mehr protokolliert werden können.
Ich hoffe, du hast die Internal Net Nummern nicht auch gleich, die müssen bei zwei Servern unterschiedlich sein.
Problematisch ist es auch, wenn die Segmentadresse (d.h. die Adresse des Netzes) nicht stimmt, die muß bei allen Servern in diesem Strang gleich sein. Das kann man aber an einem auftretenden "Router Configuration Error" feststellen.
Außerdem kann es sein, daß die Server und die Workstations verschiedene Frames benutzen und sich deshalb nicht "sehen".
An der Console würde ich zum Eingrenzen des Problems TRACK ON (Ausschalten mit TRACK OFF) ausprobieren, das gibt Aufschluß über die Router Konfiguration.
Mit SYSCON kann der Supervisor festlegen, daß ein bestimmter User sich nur zu einer bestimmten Zeit (ACCOUNT TIME RESTRICTIONS), nur an x Stationen gleichzeitig (LIMIT CONCURRENT CONNECTIONS) oder nur von (einer) bestimmten Station(en) (ACCOUNT STATION RESTRICTION ) anmelden darf.
Dabei wird die Station über die Netzwerkkartenadresse identifiziert, die man unter anderem über USERLIST /A herausbekommt.
Man kann eine 5 User Version durch eine größere Version ersetzen, ohne den Server komplett neu einzurichten, indem man einfach die SERVER.EXE austauscht.
Server runterfahren, mit EXIT ins DOS zurück und dann die SERVER.EXE von der SYSTEM_1 Diskette der größeren Version über die SERVER.EXE der 5er Version darüberkopieren, anschließend den Server neu starten.
Das funktioniert natürlich nur innerhalb der gleichen Netwareversion, d.h. nicht von 5-User 3.11 auf 10-User 3.12 !!
Zu beachten ist auch, daß es Patches gibt, die die SERVER.EXE dauerhaft verändern, z.B. um den Speicher über 16 MB direkt zu erkennen. Diese Patches müssen auch bei der neuen Version erst wieder ausgeführt werden!
NEU!
Das kann z.B. passieren, wenn du das bei NW 3.11 mitgelieferte Syscon verwendest und ein Trustee zu sys:login vergeben wolltest und beim Verzeichnisnamen "SYS:\LOGIN" eingetippt hast. (Mit \ nach dem Doppelpunkt) Nach einer etwas komischen Warnung wird das Verzeichnis inklusive aller Dateien einfach gelöscht. Diese lassen sich auch mit SALVAGE nicht mehr zurückholen. Dieser Bug ist seit dem SYSCON Version 3.68 (aus der NW 3.12) beseitigt.
Man kann das SYS:LOGIN Verzeichnis dann einfach wieder per Hand neu einrichten. Danach muß der Server neu gebootet werden. Eventuell reicht es sogar, das Volume SYS: zu dismounten und wieder neu zu mounten, damit Netware das manuell erstellte LOGIN Verzeichnis erkennt.
Hier ein netter Parameter für Packet Burst, der nirgendwo dokumentiert ist:
SET ENABLE PACKET BURST STATISTICS SCREEN = ON
Diese Schalter zeigt dann die Stationen an, die "Burst Mode" Verbindungen haben:
VerbindungNr. BurstGapTime | +----------| #001 00FF 000000 00000000 0000000 000000 0000 etc.... .
Mit folgenden Parametern für die SERVER.EXE kann man die Abarbeitung der AUTOEXEC.NCF unterdrücken:
| -S [pfad][datei] | übergeht die Startup.ncf und verwendet die in [Datei] angegebene Startdatei. |
| -NA | übergeht die Autoexec.ncf |
| -NS | übergeht die Startup.ncf und Autoexec.ncf |
| -C Cache-Puffer | (kann 4,8 oder 16 KB sein) Wenn du 2kb Blocks auf dem Server fährst, kannst du keine 4 KB Cacheblöcke angeben, da das Device dann nicht gemounted wird... |
You exceeded your outstandind NCP Directory Search Limit
Maximum Outstanding NCP Suchläufe
DOS erlaubt höchstens 32K an Verzeichniseinträgen pro Datenträger. Dies gilt auch für Netware 2.x. Der Grund dafür ist der verwendete 16-Bit File Handle (16 Bits mit Vorzeichen ergeben nur 32K). Netware v3.x bietet jedoch eine Höchstzahl von 2 Millionen Verzeichniseinträgen pro Datenträger.
Es ist deshalb erforderlich, daß das v3.x Betriebssystem die 16-Bit DOS-Anforderungen in einer Tabelle den Netware v3.x 32-Bit Verzeichniseinträgen zuordnet. Diese Tabelle wird bei "Find First's", "Find Next's", "File Open's" und bei Verzeichnissuchläufen nach Dateiinformationen verwendet.
Wenn einer dieser Suchvorgänge von einem Programm der Arbeitssstation gestartet wird, erscheint der entsprechende Eintrag in dieser Tabelle. Dieser Eintrag wird nur dann freigegeben, wenn der Dateiname genau angegeben wird, wenn die Arbeitsstation eine Meldung "End of Job" ausgibt oder wenn die "Find Next's" Suchvorgänge am Ende des Verzeichnisses beendet.
Wenn eine Arbeitsstation einen "Find First" einleitet, wird der entsprechende Eintrag in diese Netware-Tabelle eingefügt.
Standardmäßig kann diese Tabelle bis zu 51 Einträge enthalten. Ihre Anzahl kann mit Hilfe des einstellbaren Parameters "Maximum Outstanding NCP Searches" erhöht werden.
Diese Erweiterung beansprucht den Serverspeicher, da jeder Eintrag 24 Byte beträgt und es eine Tabelle für jeden Anschluß gibt. Wenn demnach die Tabellengröße auf 100 eingestellt ist und 250 Arbeitsstationen angemeldet sind, muß der Server einen Speicherplatz von 600K für die NCP-Suchtabellen bereitstellen.
DOS-Anwendungen, die Dateisuchvorgänge ungenau durchführen, können diese Tabelle füllen und zur folgenden Warnrundspruchmeldung des Servers führen: "You exceeded your outstanding NCP directory search limit". In diesem Fall sind Daten über einen oder mehrere eingeleitete (jedoch nicht abgeschloßene) Dateisuchvorgänge verloren gegangen. In der Regel gibt der Server in diesem Fall die Meldung "File Not Found" zurück, obwohl die Datei existiert.
Wenn es nicht klappen sollte, Dateien mit Umlauten zu löschen, kann man es mit einem "?" statt dem Umlaut versuchen, das heißt statt DEL HÄUSER.TXT einfach mal DEL H?USER.TXT probieren.
Außerdem sollte man versuchen, die Dateien mit unterschiedlichen Clients anzusprechen: DOS mit NETX, VLMs oder Client32, OS/2 Requester oder die diversen Windows Clients haben unterschiedliche Möglichkeiten. Die sicherste Methode ist es, per MacIntosh (und MAC Namepsace auf dem Volume) auf die Datei zuzugreifen.
Etherrpl.nlm und rpl.nlm und alle diese ganzen zusätzlichen *.rpl Files werden nur für IBM Bootroms (für PS/2 Rechner) gebraucht oder für 'neue' Bootroms, die etwa ab 1992 hergestellt werden. Die 'alten' unterscheiden sich von den 'neuen' dadurch, daß die alten einen IPX Treiberkern im ROM haben, während die neuen einen ODI Treiberkern haben, und die ODI Bootroms können anscheinend 'mehr': Bei deren Einsatz reicht es nämlich in einer Multiserverumgebung die Bootimagefiles auf _einem_ Server allein zu installieren (ohne Klimmzüge über "set reply to get nearest server = off"). Bei den 'alten' Bootroms mußte man auf allen Servern im Loginverzeichnis alle Bootimagefiles haben, da man sich nicht immer sicher sein konnte, auf welchem Server sich das Bootrom nun als erstes attacht.
Wer in SYSCON einer Gruppe oder einem User in einem Unterverzeichnis alle Rechte nimmt [ ], sieht dieses Trustee nicht mehr, es sei denn, er vergibt Rechte auf ein andere Verzeichnis in der gleichen Ebene wie das erste Verzeichnis.
Das Trustee ist vorhanden wie mit TLIST ohne weiteres zu sehen ist, kann aber eben mit SYSCON nicht betrachtet oder geändert werden.
[Quelle: Trustee Assignments Disappearing In Syscon DOCUMENT ID#: FYI.P.9962]
Netware 3.1x kann 64 Volumes je Server verwalten.
Maximale Größe eines Volumes: 32TB (1 TB = 1024 GB) Ein Volume kann aus 32 Volume Segmenten bestehen (also aus max. 32 HDs!). Eine Platte kann bis zu 8 Segmenten beeinhalten.
Theoretisch kann man also 64x32=2048 Platten mit zusammen 32 Terabyte am Server betreiben, was momentan am Speicherausbau und diversen Platzproblemen scheitert.
auf der Console oder Rconsole:
load monitor
Disk Information
Platte auswählen
rechte Spalte, vorletzte Zeile "redirected blocks"
Starten des Debuggers:
Nach dem Absturz <CTRL>+<ALT>+<RSHIFT>+<LSHIFT>+<ESC> drücken (gleichzeitig).
Man sollte dann im Debugger von Netware sein. Wenn nicht, gib mal 386debug ein (muß man blind schreiben, aber nach dem g ist man auch im Debugger).
Bist Du nicht im Debugger drin, dann ist der Server komplett abgestürzt. Wenn Du aber drin bist, so probier doch mal die Kommandos:
? <ENTER> .a <ENTER>
Wenn es gut geht, dann erhält man das NLM genannt, das beim Crash aktiv war. Mit .h und h bekommt man Hilfe zu den möglichen Befehlen.
Ich habe das Problem, daß der Server ohne Tastaur nicht die
Netware lädt. Er bleibt während des Hochfahrens stehen (noch vor
dem Mounten von SYS).
Der Tastatur-Treiber (LOAD KEYB GERMANY) wartet relativ lange auf die
angeschlossene Tastatur. Er macht zwar (meistens) irgendwann weiter, aber im
Zweifelsfall sollte man ihn deaktivieren.
Bei einem Systemwechsel von Netware 3.11 nach 3.12 ist mir aufgefallen, daß ohne die USERNAMEN zu ändern ein LOGIN mit z.B. dem Namen Müller nicht mehr möglich war, wenn er nicht groß oder direkt hinter LOGIN eingegeben wurde.
Es gibt seit einiger Zeit eine LOG376.EXE, die ein neues LOGIN.EXE enthält, bei dem dieser Fehler behoben ist.
Auf der Fileserverkonsole den Monitor, falls geladen, mit EXIT beenden.
Dann
:load Monitor /P
startet den Monitor mit einem neuen Menuepunkt
Processor Utilization
Wenn man diesen Punkt anspricht und dann F3 drückt, kann man mit den Cursor Tasten nach Belieben die IRQs prüfen. Dies ist vor allem dann sinnvoll, wenn der Server eine sehr große Auslastung hat, aber vordergründig nichts auf der Server passiert.
Ich habe nach dem Update von 3.11 auf 3.12 BINDFIX laufen lassen. Und
schon hatte ich keine User mehr. Es gab nur noch den SUPERVISOR und den GAST.
Mit BINDREST konnte ich alles wieder retten, aber woran lag es?
Wenn man alle Dateien in sys:/system mit flag +ros auf Read-Only gesetzt
hat, sind auch die alten Bindery-Dateien (NET$*.OLD) auf Read-Only und er
kann die Bindery nicht dorthin wegsichern. Dabei wird eine ganz neue Bindery
eingerichtet, die eben nur aus Supervisor und Guest ohne Paßwörter
besteht.
Man kann eine Netware 3.1x statt von den Disketten auch von einem anderen Server aus installieren, egal, ob es sich um einen Netware 2.x, 3.x, 4.x oder sogar PNW Server handelt.
Innerhalb eines gemeinsamen Verzeichnisses muß jede Diskette in ein
Unterverzeichnis des bestehenden Fileservers, wobei der LABELname der
Diskette auch der Verzeichnisname sein sollte. Dann lässt man den
zukünftigen Server unter DOS ins Netz einloggen und die INSTALL.BAT von
..\INSTALL starten.
Anfangs muß man das richtige Verzeichnis ein paar Mal manuell
eingeben, beim COPY SYSTEM AND PUBLIC FILES macht er aber alles automatisch.
Nach ca. 4-5 Stunden kommt manchmal folgendes auf der Serverkonsole:
Abend: Kernel detected process going to sleep when it was not allowed
Schau mal im Setup des Servers, da sind sicherlich irgendwelche Stromsparfunktionen aktiviert, die muß man auf jeden Fall deaktivieren.
REMOTE.NLM erlaubt zusammen mit RSPX.NLM das Fernwarten des Servers über RCONSOLE. Dazu muß man bei Netware 3.12 beim Laden von REMOTE immer ein Paßwort eingeben, wenn man das nicht bei jedem Starten des Servers manuell machen will. Bei RCONSOLE kann dann in Zukunft entweder dieses Paßwort oder das Supervisorpaßwort verwendet werden.
Auch folgende (und ähnliche) "Tricks"
load remote ;
load remote /s
die bewirken sollen, daß nur noch das Supervisorpaßwort erlaubt ist, setzen eben diese Kombination, das heißt ";" bzw. "/s" als Paßwort.
Novell Netware 3.12 ist sehr sicher, wenn kein physikalischer Zugriff auf den Server möglich ist. An der Server-Konsole selbst gibt es allerdings einige Tools und Möglichkeiten, den Server zu knacken. Es gibt einige Novell HACK Texte, in denen genau darauf eingegangen wird.
Bei der Netware 3.11 ist das Security Patchkit zu empfehlen, da hier ein Programm im Umlauf ist, mit dem man das Supervisorpaßwort von einem beliebigen Rechner im Netz knacken kann.
Ansonsten einige Tips zum Sichern des Netzes aus einer Hack-FAQ:
Starte den Befehl SECURE CONSOLE an der Server Console
danach startet die Netware NLMs nur noch aus SYS:SYSTEM, verhindert den
Zugriff auf den Netware Debugger per Tastatur und macht automatisch ein
REMOVE DOS
Lock File Server Console im NetWare v3.x MONITOR.NLM Hauptmenue auswählen
Andere Sicherheitsmechanismen wie intruder detection, forced password changes, limited grace logins, usw. einsetzen
Server Hardware Sicherungen einsetzen soweit verfügbar
Das A3112.NLM vom 10.10.95 aus LIBUPx.EXE, das als Zusatzmodul zur AFTER311.NLM arbeitet und dem Netware 3.12 Server Routinen zur Verfügung stellt, die eigentlich erst ab NW 4.x unterstützt werden, bringt beim Laden diverser NLMs (z.B. bei ARCserve) folgende Meldungen:
1.1.38 Cache memory allocator exceeded minimum cache buffer left
limit
1.1.131 Semi-permanent memory allocator is out of memory. <xx>
semi-permanent memory allocation requests failed.
(<xx> = irgendeine Anzahl von Requests)
Es gibt ein neues Patchkit der CLIB.NLM namens LIB312.EXE, das nur noch die Patches für die Netware 3.1x enthält und außerdem eine aktualisierte A3112.NLM enthält, bei der das obige Problem nicht mehr auftritt.
Es gibt bei Netware 3.1x das Phänomen, daß der File Server bei defekten Queues abstürzen kann, und zwar ohne Abend-Meldung.
Dazu muß man diese Queue erst herausfinden und dann löschen. Davor sollte man alle Programme, die darauf zugreifen, (PCONSOLE, ARCserve, LANspool) deaktivieren und dann das zugehörige Verzeichnis (notfalls per Filer(.NLM)) löschen.
Copyright © by Stefan Braunstein (sbraunst@POBoxes.com)
Letzte Aktualisierung am 1. Dezember 1997