Tipps & Tricks
Aktuelle Patches und Updates zu Novell-Produkten
Welche neuen Patches und Updates stehen für Novell-Produkte zur Verfügung, und wo lassen sie sich downloaden?
Nachfolgend eine Auswahl aktueller Produkt-Updates von Novell. Alle Dateien sind über support.novell.com/filefinder/ verfügbar. Mit einem aktuellen "Security Alert" versehen sind diesmal zwei Dateien, auf die LANline bereits in Ausgabe 1/2005 hingewiesen hatte: die TCP-Updates für Netware 6 beziehungsweise 6.5 ("tcp610jb.exe" und "tcp657jb.exe").
Aktualisiert hat der Hersteller ferner die so genannte Minimum Patch List: Sie führt jetzt die bereits besprochenen neuen Support-Packs auf, die auch im "Consolidated Support-Pack 12" enthalten sind (siehe LANline 4/2005). Hinzu kommt folgende Datei:
iman202mu5.tgz: "Imanager 2.0.2 Maintenance Update 5" (TID 2970946).
Unter den zahlreichen weiteren Updates und Patches erscheinen noch folgende erwähnenswert:
sl351sp2.exe: "Support-Pack 2 for Novell Secure Login v 3.51" (TID 2971137)
sowie eine Einzeldatei mit diversen Bug-Fixes für den aktuellen Novell-Client:
491_nwfs_1.exe: "Novell Client 4.91 NWFS.SYS" (TID 2971139).
Windows-Server: Unnötig hohe FRS-Replikation
Der "File Replication Service" (FSR) von Windows-Servern repliziert gelegentlich alle Dateien statt nur die geänderten, was zu erheblichen Problemen führen kann. Worin liegt die Ursache dieses Phänomens und was lässt sich dagegen tun?
Der FRS (File Replication Service) ist ein Dienst auf Windows-Servern (Windows 2000 Server und Windows Server 2003), den unter anderem das DFS (Distributed File System) nutzt, um geänderte Dateien zwischen Servern zu replizieren. Normalerweise hält sich die dabei entstehende Last in Grenzen. In einigen Fällen kommt es aber vor, dass alle Dateien repliziert werden. Dies kann wiederum dazu führen, dass die so genannte Staging Area, also der Bereich, in dem die Änderungen zwischengespeichert werden, nicht ausreicht, und Replikationsfehler auftreten - von der Last auf den beteiligten Servern und im Netzwerk ganz abgesehen.
Die typische Ursache für diese Probleme sind Viren-Scanner. Diese schreiben oft Sicherheitsdeskriptoren neu. Solche Änderungen werden vom FRS erkannt und führen zur Replikation. Ein entsprechendes Phänomen lässt sich teilweise auch dann beobachten, wenn Viren-Scanner von einem Client aus Dateien auf dem Server prüfen, die wiederum als Offline-Dateien auf Clients synchronisiert werden. In Folge eines Viren-Scans kann es also durchaus zu einer Vollsynchronisation kommen. Falls dieses Problem auftritt, empfiehlt es sich, den Viren-Scanner zu wechseln oder gegebenenfalls zu aktualisieren.
Lotus Domino: Träge Aktualisierung von Richtlinien auf Notes-Clients
Die zentrale Verwaltung von Richtlinien scheint manchmal nicht - beziehungsweise nicht sofort - auf den Notes-Clients zu wirken. Was ist die Ursache dieses Problems und wann kann die Administration sicher sein, dass die Regeln auf den Clients greifen?
Mit dem Release 6 von Domino hat Lotus die richtlinienbasierende Administration eingeführt, mit der sich Notes-Clients über zentrale Richtlinien verwalten lassen. Zu Irritationen führt dabei immer wieder, dass Richtlinien nicht sofort angewandt werden. Dabei ist zu beachten, dass eine Richtlinie erst auf den Client geladen wird, wenn ein Zugriff auf einen Domino-Server erfolgt, was nicht unbedingt direkt nach dem Start des Notes-Clients der Fall ist. Darüber hinaus aktivieren sich einige Richtlinieneinstellungen erst nach dem zweiten Start des Notes-Clients, weil sie beim ersten Zugriff zwar gelesen, von den Notes-Komponenten aber noch nicht verarbeitet werden.
Erschöpfter Festplattenplatz auf Exchange-Servern
Mangelnder Festplattenspeicherplatz führt zum Betriebsausfall von Exchange-Servern. Vermeiden lässt sich eine solche Situation zwar nicht immer, die damit verbundenen Probleme und die Ausfallzeit können aber deutlich reduziert werden. Wie lässt sich entsprechend vorsorgen?
Eine der unangenehmeren Situationen, die beim Betrieb eines Exchange-Servers eintreten können, ist erschöpfter Festplattenplatz auf denjenigen Laufwerken, auf denen sich die Exchange-Datenbanken oder -Transaktionsprotokolle befinden. Der Exchange-Informationsspeicher beendet sich in diesen Fällen kontrolliert selbst und lässt sich erst wieder starten, wenn ausreichend freier Festplattenplatz vorhanden ist. Nur kann man diesen oft nicht auf einfache Weise wiedergewinnen. Bei den Datenbanken kommt meist nur eine Offline-Defragmentierung infrage - die aber ihrerseits - lokal oder im Netz - zirka 110 Prozent des aktuell von der Datenbank belegten Platzes benötigt. Bei den Transaktionsprotokollen gerät der Administrator schnell in Versuchung, einfach die ältesten dieser 5 MByte großen Dateien zu löschen - was aber ohne vorherige genaue Recherche die Integrität der Datenbanken beschädigen kann und damit das Problem nur noch vergrößert.
Aus diesen Gründen empfiehlt es sich, auf den Laufwerken, die die Exchange-Datenbanken und/oder -Transaktionsprotokolle beherbergen, einfach 500 MByte bis 1 GByte Platzhalterdateien anzulegen (zum Beispiel eine Kopie der Exchange-Installations-CD oder einige Service-Packs). Diese kann man in der beschriebenen Situation einfach löschen, und der wiedergewonnene Platz reicht dann aus für einen Neustart des Informationsspeichers und einen Notbetrieb bis zum nächsten Wartungsfenster oder entsprechende Maßnahmen - zum Beispiel ein umgehendes Online-Backup zur Sicherung und Entsorgung der Transaktionsprotokolle.
Zurücksetzen der Passwörter unter dem Nokia IPSO Operating System
Lassen sich bei Nokia-Appliances, die mit dem "IP Security Operation System" (IPSO) arbeiten, die Passwörter zurücksetzen? Falls ja, wie funktioniert das, und was bedeutet das für den sicheren Betrieb der Appliance?
Unter dem Nokia-Betriebssystem IPSO lassen sich zwei unterschiedliche Passwörter vergeben. Zum Zurücksetzen dieser Passwörter müssen Sie über die serielle Konsole verbunden sein. Die Kommunikationseinstellungen dazu lauten: 8N1, 9600 Baud, kein Handshake.
Zum einen existiert ein Bootmanager-Passwort. Es wird abgefragt, sobald der Anwender im Bootmanager eine Aktion wie zum Beispiel "boot -s" oder "install" durchführt. Um dieses Passwort zurückzusetzen, müssen Sie folgende Prozedur in der angegebenen Reihenfolge durchführen:
Ganz normal booten und dann auf der Shell als Admin einloggen.
"mount -uw /" durchführen, um das Root-Filesystem "read/ write" zu mounten.
Die Datei "nkipflash-XX.bin" in das "/etc"-Verzeichnis kopieren (zum Beispiel mit FTP). (Bei dieser Datei handelt es sich um den Bootmanager, der auf der Nokia-Website erhältlich ist. "XX" steht für Ihre Betriebssystemversion, also zum Beispiel "38" für IPSO 3.8)
"reboot" durchführen.
Bei der Auswahl "1 für Bootmanager oder 2 für IPSO" hier "2" auswählen.
Beim Boot-Prompt schnell "-s" eingeben.
Einfach nur Return für die Shell drücken.
Nach "/etc" wechseln.
Jetzt den Befehl "upgrade_bootmgr wd0 nkipflash-XX.bin" ausführen. Dabei werden der vorhandene Bootmanager und dessen Einstellungen überschrieben.
"reboot" durchführen.
Das zweite Passwort ist das Admin-Passwort. Es lässt sich wie folgt (ohne Kenntnis des vorhandenen Admin-Passworts) durch ein anderes ersetzen:
Bei der Auswahl "1 für Bootmanager oder 2 für IPSO" in diesem Fall "1" auswählen.
Wenn "press any key for Bootmanager" erscheint, eine Taste drücken.
Auf dem Boot-Prompt "boot -s" ausführen.
Einfach nur Return für die Shell drücken.
Mit "cd /etc" in dieses Verzeichnis wechseln.
"./overpw" ausführen.
Anschließen das neue Passwort eingeben, wenn Sie danach gefragt werden.
"reboot" durchführen.
Wie sich aus beiden Abläufen erkennen lässt, ist es unbedingt notwendig, dass kein unautorisierter physikalischer Zugriff zu der Nokia-Appliance möglich ist. Das heißt, es muss Teil der Sicherheitspolitik des Unternehmens sein, dass sich diese Firewall in einem abgesperrten Raum befindet.
Lesen Sie mehr zum Thema
