Seminar: Aktuelle Probleme der Netz- und Systemadministration Network File System Version 4

Größe: px
Ab Seite anzeigen:

Download "Seminar: Aktuelle Probleme der Netz- und Systemadministration Network File System Version 4"

Transkript

1 Seminar: Aktuelle Probleme der Netz- und Systemadministration Network File System Version 4 Björn Fischer Technische Fakultät Universität Bielefeld Sommersemester 2000 Zusammenfassung Mit NFSv4 gibt es zum ersten Mal einen NFS-Standard von der IETF. Dieses Dokument beschäftigt sich mit den Problemen bisheriger NFS-Spezifikationen und -Implementierungen, mit den Design- Überlegungen und -Anforderungen für NFSv4 (RFC 2624 [8]) sowie deren Umsetzung (RFC 3010 [11]). Inhaltsverzeichnis 1 Einleitung NFS Transparent für Applikationen NFSv4 ein Standard der IETF Entstehungsgeschichte Anforderungen und Designkriterien Komplexität der Spezifikation

2 3 Skalierbarkeit Hohe Latenz Synchron vs. asynchron Aggregierung von Lese- und Schreibzugriffen Reduzierung der Anzahl der RPC-Requests COMPOUND-Prozedur Niedrige Bandbreite Delegation und Callbacks Internet-Tauglichkeit (Accessibility) Firewalls und Proxies Anforderungen an den Transport Interoperabilität und Portabilität Persistente und volatile Filehandles Erweiterte Attribute Disk-Quota Migration Groß-/Kleinschreibung Attribut-Verzeichnisse Sicherheit RPC-Authentication-Flavors RPCSEC GSS File-Locking Network Lock Manager Blocking Locks Leases Internationalisierung (I18N) 23 9 Fazit 24 2

3 1 Einleitung Netzwerk-Dateisysteme 1 sind mittlerweile aus mittleren bis großen Rechnerverbunden nicht mehr wegzudenken. Zu den Hauptursachen zählen sicherlich die enormen Einsparungen im Ressourcenverbrauch in den Bereichen Massenspeicher und Administration, die sich durch den Einsatz derartiger Dateisysteme erschließen. Allein die Vereinfachungen bei der Verwaltung von Dateien auf mehreren Rechnern sind nicht zu unterschätzen: Vor allem dem Benutzer wird einiges an Infrastruktur bildenden Maßnahmen erspart, da ihm auf jedem Rechner seine Dateien sofort und transparent zur Verfügung stehen. Ferner muß der Administrator eines Rechnerverbundes nicht mehr n Kopien der Dateien auf n Rechnern pflegen; nur das Orginal auf dem NFS-Server muß ggf. aktualisiert werden. Das unter Unix TM am weitesten verbreitete Netzwerk-Dateisystem ist NFS (Network File System). Die NFS-Spezifikation liegt mittlerweile in der Version 4 vor, die von der IETF entwickelt und als RFC 3010 [11] (Request For Comments) veröffentlicht wurde. Das vorliegende Dokument soll unter anderem herausstellen, welche Probleme bei Implementierung und Nutzung von NFSv2/v3 auftreten und wie diese Probleme in NFSv4 vermieden oder entschärft werden. 1.1 NFS Transparent für Applikationen Der NFS-Client ist in der Regel ein Teil des Betriebssystem-Kerns und nicht etwa eine Applikation, die auf dem Betriebssystem läuft 2. Für Applikationen, wie z.b. einen Texteditor, ist NFS völlig transparent, d.h. die Applikation weiß nicht, ob zu bearbeitende Dateien auf einem lokalen Massenspeicher oder von einem entfernten Server per NFS zur Verfügung gestellt wird. Wie auf Abbilbung 1 schematisch dargestellt, sind aus der Sicht der Applikation alle Schreib- und Lesezugriffe lokal. Der Hauptvorteil der transparenten Integration von NFS in das Betriebssystem ist also, daß eine Applikation keine besonderen Schnittstellen oder 1 Gemeint sind nichtlokale Client-Server-Systeme, nicht etwa verteilte oder globale Dateisysteme, bei denen Dat(ei)en benutzertransparent auf vielen verschiedenen Rechnern verteilt sind. 2 Auf Ausnahmen wie WebNFS [4, 5] soll hier nicht eingegangen werden. 3

4 Client Host Applikation Local I/O Server NFS Client NFS I/O Abbildung 1: NFS-I/O und lokales I/O Fähigkeiten haben muß, um auch in Verbindung mit NFS zu funktionieren. Das bedeutet aber auch, daß es für das Betriebssystem normalerweise keine Möglichkeit gibt, die Applikation über bestimmte NFS-spezifische Fehlersituationen zu informieren, beispielsweise eine zusammengebrochene Netzwerkverbindung, die erst wieder aufgebaut werden muß, ehe der Lese- oder Schreibvorgang fortgesetzt werden kann. Ein Problem, das in diesem Zusammenhang leider viel zu häufig auftritt, ist das Resultat schlampiger Programmierung: Entwickler von Applikationen machen oft fatalerweise Annahmen, die zwar bei der Verwendung von lokalen Dateisystemen im allgemeinen zutreffen, aber im Zusammenhang mit NFS mindestens gefährlich sind. Im Laufe dieses Dokuments wird auf einige dieser Annahmen eingegangen. 4

5 2 NFSv4 ein Standard der IETF Die Entwicklung der Spezifikation von NFS Version 4 wurde erstmalig von der IETF (Internet Engineering Task Force) betreut [7]. Die IETF organisiert u.a. Entwicklung und Pflege fast aller Netzwerk-Standards, die das Internet betreffen. Auch wenn viele Referenz-Implementierungen diverser Internet- Standards auf Unix entwickelt werden, hat die IETF eher wenig mit Unix oder anderen Betriebssystemen an sich zu tun. 2.1 Entstehungsgeschichte NFS Version 2 NFSv2 [1] wurde, wie auch die erste Version, für die es nie eine veröffentlichte Spezifikation gab, von Sun Microsystems TM entwickelt. Wie auch alle neueren Versionen setzt es auf dem ebenfalls von Sun entwickelte Sun-RPC (Remote Procedure Call) auf. RPC ist ein transportunabhängiges Verfahren, das es ermöglicht, auf anderen Rechnern Prozeduren in transparenter Art und Weise so auszuführen, als seien sie lokal. Auch wenn NFSv2 von Sun entwickelt wurde, war und ist es ein offener Standard, jeder kann sich die Spezifikation beschaffen und eine eigene Implementierung entwickeln. Das war neben der eher auf Pragmatik ausgerichteten Spezifikation an sich einer der Hauptgründe, die für die enorme Verbreitung von NFS gegenüber anderen Netzwerk-Dateisystemen, wie z.b. AFS 3 von der Carnegie Mellon University, innerhalb der letzten Jahre sorgten. Da außer Sun auch andere Hersteller eine NFSv2-Implementierung in ihre Betriebssysteme integrierten, manifestierten sich recht bald Wünsche nach kleinen Erweiterungen und Verbesserungen: Der eine Hersteller wollte beispielsweise Device-Nodes mit 32 Bit auch über NFS benutzen können, ein anderer wollte asynchrone Schreibzugriffe, um noch billigere Server bauen zu können, usw. NFS Version 3 Damit nicht jeder Hersteller sein eigenes proprietäres Süppchen kocht und NFS somit seine Kompatibilität einbüßt, wurde ein informelles Hersteller- 3 5

6 Konsortium gegründet, das die Weiterentwicklung von NFS vorantreiben sollte. Das Produkt dieses Konsortiums war NFSv3 [2]. Die Mitglieder des Konsortiums waren fast ausschließlich Hersteller von Unix-Betriebssystemen. Demzufolge ist die Verwandtschaft mit typischen Unix-Dateisystemen (z.b. UFS) nicht zu übersehen. Tatsächlich genügt NFSv3 gerade den POSIX- Minimalanforderungen. Andere Betriebssysteme, die nicht auf Unix basieren, tun sich dementsprechend schwer, wenn es darum geht, eine halbwegs vollständige NFSv3-Implementierung zur Verfügung zu stellen. 2.2 Anforderungen und Designkriterien Als die IETF Mitte 1997 anfing, sich intensiver mit NFS auseinanderzusetzen, wurde eine Art Forderungskatalog für die neue Version von NFS aufgestellt. Die im Juli gegründete NFS Version 4 Working Group veröffentlichte im RFC 2624 die Anforderungen und Designkriterien für NFSv4 [8]. In den nächten Abschnitten werden die wichtigsten Kriterien sowie deren Umsetzung in der NFSv4-Spezifikation [11] genauer beschrieben: Skalierbarkeit: Hier ist neben des sinnvollen Betriebs auf schnellen wie langsamen Netzwerken auch die Unabhängigkeit vom Netzwerk-Medium und sonstiger Hard- und Software von Bedeutung. Fer- ner ist natürlich auch die Erweiterbarkeit und Bandbreite der Nutzungsmöglichkeiten gemeint. Internet-Tauglichkeit: NFSv4 soll nicht nur im lokalen Netzwerk, sondern auch im Internet ohne Schwierigkeiten einsetzbar sein. Viele Voraussetzungen dafür werden schon von den anderen Kriterien erfüllt. Es fehlen lediglich wichtige Kleinigkeiten wie Verträglichkeit mit Firewalls, Congestion Control, etc. Interoperabilität und Portabilität: NFSv4 muß auch auf anderen Plattformen als Unix ohne größere Schwierigkeiten implementierbar sein. Die Implementierungen müssen natürlich untereinander kompatibel sein. Sicherheit: Anders als bei bisherigen Versionen von NFS sollen für NFSv4 sichere Authentisierung und Verschlüsselung unter der Verwendung starker Kryptographie Pflicht sein. 6

7 File-Locking: Das File-Locking, das bisher über ein sogenanntes Sideband- Protokoll abgewickelt wurde, ist in NFS zu integrieren. Internationalisierung (I18N): Vor allem Pfad- und Dateinamen sollen nicht auf ASCII beschränkt sein, eine Repräsentation von beliebigen Glyphen sollte möglich sein. 2.3 Komplexität der Spezifikation NFS Version 4 ist keine Erweiterung von NFSv3, sondern ein eigenständiger Standard, der von Grund auf neu entwickelt wurde. Zwar wurden viele Konzepte, Algorithmen und Mechanismen aus früheren NFS-Versionen übernommen, aber auch andere Netzwerk-Dateisysteme wie z.b. AFS wurden in dieser Hinsicht beliehen. Um eine Implementierung zu vereinfachen, und vor allem, um die Minimalanforderungen an eine NFSv4-Implementierung klar definieren zu können, wurde auf zusätzliche Protokolle, sogenannte Sideband-Protokolle wie z.b. MOUNT oder NLM, verzichtet. Auf MOUNT und NLM wird später noch genauer eingegangen. Es wurde viel Wert darauf gelegt, insbesondere für den Bereich Netzwerksicherheit bereits bestehende Infrastrukturen zu verwenden, um eine möglichst schlanke Spezifikation zu erhalten und vor allem, um sich nicht auf neue ungetestete Sicherheitsmechanismen einlassen zu müssen. Gerade auf diesem Gebiet wurden mit NFS in der Vergangenheit schmerzhafte Erfahrungen gesammelt [9]. NFSv4 soll leicht erweiterbar sein. Neben einem funktionierenden Versionsmanagement, das auch die zukünftige Interoperabilität sicherstellt, sind Schnittstellen von Bedeutung, die Entwicklern Möglichkeiten zur Verfügung stellen, auf Basis von NFSv4 auch sehr komplexe Anwendungen zu realisieren. Konkrete Beispiele für diese Schnittstellen sind selbst definierbare Dateiattribute und ACLs (Access Control Lists). So sind mit NFSv4 ohne weiteres selbstreplizierende Dateisysteme (z.b. cachefs), Hochverfügbarkeits- Lösungen oder eine HTTP-Alternative (WebNFS) machbar, ohne eine speziell veränderte oder erweiterte also nicht-konforme NFS-Implementierung zu verwenden. NFSv4 ermöglicht diese Anwendungen ohne Verletzung oder Erweiterung der Spezifikation. 7

8 3 Skalierbarkeit NFSv4 muß auch auf weniger leistungsfähigen Netzwerken sinnvoll einsetzbar sein. Für die Betrachtung der Leistungsfähigkeit eines Netzwerks soll hier eine recht grobe Vereinfachung auf die beiden Parameter Latenz und Bandbreite genügen. Die bisherigen Versionen von NFS waren fast ausschließlich für die Nutzung auf einem LAN mit entsprechend niedrigen Latenzen und hohen Bandbreiten vorgesehen. Auf einem LAN liegen Netzwerk-Latenzen gewöhnlich unter einer Millisekunde. Die Verzögerungen, die auf dem Server entstehen, wenn eine Anforderung bearbeitet und beantwortet werden muß (z.b. Festplattenzugriffe), sind bei typischen NFS-Operationen deutlich größer. Daher wurde NFS bis zur Version 3 hauptsächlich im Hinblick auf die Server-Latenzen optimiert. Die NFSv4 zu bescheinigende Internettauglichkeit fordert vor allem eine Toleranz gegenüber hohen Netzwerk-Latenzen, die sich auf dem Internet von einigen zehn Millisekunden bis in den Sekundenbereich 4 erstrecken können. Daher betrachten wir zunächst Mechanismen, die NFS resistenter gegenüber hohen Netzwerk-Latenzen machen. 3.1 Hohe Latenz Synchron vs. asynchron Wie schon erwähnt, hatte man es bei der Entwicklung von NFSv3 vor allem auf die Server-Latenzen abgesehen. Die NFSv2-Spezifikation fordert synchrone Schreibzugriffe, d.h. bei einer Schreibanforderung darf die Rückmeldung über die erfolgreiche Verarbeitung derselben erst erfolgen, wenn der Server die Daten in nichtflüchtigem Speicher abgelegt hat. Die Computerindustrie hat sogar aufwendige 5 NFS-Server hervorgebracht, die mit nichtflüchtigem RAM (sog. NVRAM) ausgestattet waren, um NFS-Schreibzugriffe zu be- 4 Schon eine ungünstige Satellitenverbindung im Datenpfad kann eine Verzögerung von ein oder zwei Sekunden verursachen. 5 sprich: wirklich teure 8

9 schleunigen 6. NFSv3 erlaubt asynchrone Schreibzugriffe, d.h. der Server kann eine Schreibanforderung bestätigen, sobald er sie erhalten hat. Doch auch hier hat der Client mit einer sog. COMMIT -Prozedur die Möglichkeit, den Server zu zwingen, alle noch ausstehenden Schreibanforderungen abzuarbeiten. Erst wenn sich alle Daten auf nichtflüchtigem Speicher (normalerweise Festplatte) befinden, darf er die COMMIT -Prozedur bestätigen Aggregierung von Lese- und Schreibzugriffen Eine Optimierung, die viele Betriebssysteme unabhängig von NFS mitbringen, ist die Aggregierung von Lese- und Schreibzugriffen, auch bekannt als Caching, das nicht nur bei NFS sondern auch bei anderen (lokalen) Dateisystemen Anwendung findet. Grob vereinfacht kann der NFS-Client (der Betriebssystemkern) bei (linearen) Leseanforderungen der Applikation schon weitere Daten quasi im Voraus per NFS anfordern (Read Ahead) sowie häufig benötigte Daten (z.b. Verzeichnisse) lokal zwischenspeichern. Insbesondere dann, wenn die Applikation immer wieder nur wenige Bytes liest, rentiert sich diese Vorgehensweise extrem schnell. Umgekehrt kann im Schreibfall der Betriebssystemkern erst einmal ein paar Schreibzugriffe der Applikation sammeln und später als einen einzigen NFS-Schreibzugriff an den Server weiterleiten (Write Behind oder Write Clustering). Dies stellt keine Verletzung der NFSv2-Spezifikation dar, weil die Aggregierung vollständig im Client vollzogen wird und nicht im Server Reduzierung der Anzahl der RPC-Requests Bei der Implementierung eines NFS-Servers hat man zwar Einfluß auf die Server-Latenz, die Netzwerk-Latenz läßt sich innerhalb einer NFS-Implementierung aber kaum bis gar nicht beeinflußen. Das NFS-Protokoll muß also möglichst resistent gegenüber langen Netzwerk-Verzögerungen sein; die Performanz darf bei langsamen Netzwerken nicht zu stark sinken. Um dieses Ziel zu erreichen, bleibt nur die Möglichkeit offen, für typische 6 Es gibt auch eine NFSv2-Implementierung in einem aus Finnland stammenden Betriebssystem, das die Spezifikation verletzt und dem Client eine Antwort schickt, sobald die Daten im (flüchtigen) Arbeitsspeicher sind. 9

10 Operationen auf einem Dateisystem (z.b. lies Datei /homes/joe/bigfile oder lies das Verzeichnis /homes/joe) möglichst wenige RPC-Requests zu erzeugen, d.h. möglichst wenige Pakete hin- und herzuschicken. Denn bei hoher Netzwerk-Latenz und Bandbreite ist die Anzahl der RPC-Requests ein direkter Faktor der Gesamtdauer einer NFS-Operation: Halbiert man die Anzahl der RPC-Requests, halbiert sich auch die Gesamtdauer. Aus der Sicht von NFSv2 ist beispielsweise das Unix-Kommando ls -l. extrem teuer: Für jede Datei im Verzeichnis müssen mit den Prozeduren LOOKUP und GETATTR die Attribute (also Größe, Zeitstempel, etc.) gelesen werden. Selbst auf einem LAN entstehen da schnell je nach Anzahl der Verzeichniseinträge Verzögerungen im Sekundenbereich. Speziell für Abläufe wie ls -l. wurde in NFSv3 eine neue Prozedur entwickelt: READDIRPLUS. Sie erledigt ls -l. sozusagen in einem Rutsch. Dadurch sinkt die Laufzeit von ls -l. von O(n) auf O(1). Die Prozedur GETATTR (lesen der Datei-Attribute) ist ohnehin eine der häufigsten NFS-Operationen: Wenn der NFS-Client Daten auf der lokalen Festplatte oder im RAM zwischenspeichert (Cache), muß er in bestimmten Zeitabständen mittels GETATTR feststellen, ob die zwischengespeicherten Daten im Cache noch gültig sind. NFSv3 hat keinen speziellen Mechanismus, um Cachekohärenz zu gewährleisten. Caching ist bis NFSv3 also immer ein Kompromiß zwischen Performanz und Kohärenz. Leider enthält die NFSv3- Spezifikation nicht einmal Richtlinien, wie lange den Daten aus dem Attribut- Cache vertraut werden kann, bevor sie neu angefragt werden sollten. Es muß also damit gerechnet werden, daß sich verschiedene Implementierungen hier sehr unterschiedlich verhalten können COMPOUND-Prozedur Noch einen Schritt weiter bei der Reduzierung der Anzahl von RPCs geht NFSv4: Was in Version 3 mit READDIRPLUS für einen sehr speziellen Sonderfall entwickelt wurde, stellt Version 4 in einer mächtigeren und universelleren Art und Weise zur Verfügung: Die COMPOUND-Prozedur (Abbildung 2). Sie kann quasi beliebig viele Einzelanfragen enthalten. Dadurch werden READDIRPLUS oder die Möglichkeit, die GETATTR-Funktionalität an andere Operationen zu koppeln, überflüssig. Das Cachekonsistenz-Problem bei hoher Netzwerk-Latenz ist mit COMPOUND natürlich auch nicht vollständig 10

11 zu lösen. Jedoch ist NFSv4 dadurch bestens für zukünftige Anwendungsszenarien gerüstet. 3.2 Niedrige Bandbreite Die zweite wichtige Größe für die Performanz von Netzwerken ist die Bandbreite. Innerhalb eines LANs mit zur Zeit üblichen 100 MBit/s lassen sich per NFS Datentransferraten erreichen, die mit etwa 10 MB/s schon fast an lokale Dateisysteme auf Festplatten erinnern. In einem WAN (z.b. Internet) jedoch muß man normalerweise mit erheblich niedrigeren Datenraten auskommen. Man denke an einen reisenden Mitarbeiter, der per Laptop und Modem vom Hotel aus Verbindung zum Netz seiner Firma aufnimmt. Ohne aggressives Caching ist an eine praxisgerechte Benutzung von NFS nicht zu denken. Jedoch ist gerade die bei Caching notwendige Konsistenzprüfung bei hoher Netzwerk-Latenz extrem teuer. Für jede Leseanforderung ein GETAT- TR zu senden ist indiskutabel. Daher haben sich die Entwickler von NFSv4 etwas Neues 7 einfallen lassen: Delegation und Callbacks Delegation und Callbacks Die Idee bei diesem Verfahren ist, daß der Server auf Anfrage des Clients die Verantwortung für oft benutzte Dateien an den Client delegieren kann. Betrachten wir das folgende einfache Szenario: Der Benutzer 8 öffnet eine Textdatei mit einem Editor um diese zu verändern. Der NFS-Client (im Betriebsystemkern) besorgt sich eine Delegation für diese Datei. Solange der Client diese Delegation hat und die Datei vollständig übertragen wurde, muß für diese Datei fast kein NFS-Verkehr erzeugt werden. Alle Änderungen verbleiben zunächst auf dem Client. Der Client muß lediglich das mit der Delegation verbundene Lease 9 in festgelegten Zeitabständen erneuern, damit der Server weiß, daß der Client die Delegation noch verwendet. Wenn der Editor die Datei wieder schließt, aktualisiert der NFS-Client die Datei auf dem NFS- 7 Ganz so neu doch nicht: Andere Netzwerk-Dateisysteme, wie z.b. AFS, verwenden vergleichbare Verfahren. 8 im Hotel mit Laptop und Modem 9 zu verstehen als Gültigkeitsdauer 11

12 Server und gibt die Delegation zurück 10. Falls in der Zwischenzeit allerdings eine andere Applikation auf einem anderen NFS-Client auf die gleiche Datei zugreift sei es auch nur read-only muß der NFS-Server die Delegation vom NFS-Client mit einem sog. Callback vorzeitig wieder zurückfordern. Erst, nachdem der Client die Datei auf dem Server aktualisiert und die Delegation zurückgegeben hat, kann der Server Anfragen von dritter Seite bezüglich der Datei bearbeiten. Antwortet der NFS-Client auf ein Callback nicht innerhalb eines festgelegten Zeitrahmens, verfällt der Delegation-Status auf dem Server und mit ihm alle Änderungen an der Datei. Der Zeitrahmen ist zweckmäßigerweise so gewählt, daß beispielsweise eine zusammengebrochene Modemverbindung wieder aufgebaut und die NFS- Sitzung fortgesetzt werden kann. Obwohl die Folgen einer gecancelten Delegation im obigen Beispiel einer Editor-Sitzung einigermaßen fatal ausfallen können, funktioniert das Delegation- Konzept in der Praxis (z.b. bei AFS) gut und weitgehend ohne derartige Zwischenfälle. Das hat zwei Gründe: Zum einen gibt es separate Schreib- und Nur-Lese-Delegations, wobei die Nur-Lese-Delegations für ein und dieselbe Datei von mehreren NFS-Clients gemeinsam genutzt werden können (shareable). Ein NFS-Server muß einem Client mit einer Nur-Lese-Delegation nur dann einen Callback schicken, wenn sich Dateiinhalt oder Attribute ändern. Im Normalfall stellen Nur-Lese-Zugriffe die deutliche Mehrheit aller Dateioperationen dar. Und andererseits, wenn eine Datei zum Schreiben geöffnet wird, ist es extrem selten, daß auf einem anderen Client genau auf dieselbe Datei zugegriffen wird. Wenn mehrere Benutzer gemeinsam Dateien editieren, ist ohnehin eine andere Infrastruktur indiziert, wie sie z.b. CVS bietet. Eigentlich offenbart das Delegation-Konzept keine Schwächen, die nicht auch bei lokalen Dateisystemen, wie UFS, auftreten: Auch bei UFS können nicht zwei Benutzer (oder Applikationen) schreibend auf dieselbe Datei zugreifen, ohne daß Inkonsistenzen entstehen. Nur ein Locking-Mechanismus, der prinzipbedingt ähnliche Probleme beim Recovery hat wie Delegations, kann das verhindern. Von dieser Seite betrachtet stellen Delegations nichts anderes dar, als eine spezielle Form von Locking. 10 Spätestens hier sollte offensichtlich sein, warum die weit verbreitete Annahme close() schlägt nie fehl, daher braucht man den Rückgabewert nicht zu überprüfen fatal sein kann. Es ist nicht überraschend, daß diese Annahme oft mit der Unkenntnis von fsync() korreliert. 12

13 4 Internet-Tauglichkeit (Accessibility) In den vorhergehenden Abschnitten wurde Skalierbarkeit als eine für NFSv4 unverzichtbare Eigenschaft ausgiebig erörtert. Skalierbarkeit spielt für die Internet-Tauglichkeit eines Protokolles natürlich eine zentrale Rolle. Die Resistenz gegen niedrige Bandbreiten und/oder hohe Latenzen allein genügen aber nicht. In diesem Abschnitt werden weitere Kriterien aufgezählt, die NFSv4 internettauglich machen sollen. Viele davon wie z.b. Sicherheit und Zugriffskontrolle sind so umfangreich, daß sie gesondert behandelt werden. 4.1 Firewalls und Proxies Es gibt Protokolle, die einem Systemadministrator regelmäßig Kopfschmerzen bereiten, wenn es darum geht, einen Paketfilter oder gar eine Firewall einzurichten und zu pflegen. In der Geschichte des Internets ist das Konzept der Firewall relativ neu. Viele weit verbreitete Protokolle wurden erdacht, als es diese Art von Paketfilterung noch gar nicht gab. Heute hat sich herausgestellt, daß das eine oder andere Protokoll Schwierigkeiten beim Einsatz von Firewalls oder Paketfiltern macht. Eines der bekanntesten Problemkinder ist das unausrottbare Datei-Transfer-Protokoll FTP (File Transfer Protocol). FTP benutzt zwei separate TCP-Verbindungen, je eine für Steuerungsanweisungen und eine für die eigentlichen Daten. Von diesen Verbindungen hat nur eine einen fest zugewiesenen Port. Der Port für die Datenverbindung wird über die Steuerungsverbindung verhandelt, ist also prinzipiell nicht vorherzusehen, ohne die Steuerungsverbindung mitzulesen und das Gelesene zu verstehen. Eine Firewall, die IP-Datagramme basierend auf IP-Adressen und Port-Nummern filtert und Protokollebenen, die sich oberhalb von TCP und UDP befinden, nicht verarbeitet, kann FTP nicht sinnvoll filtern. Bei NFS gibt es ein ähnliches Problem. NFS benutzt für die Abwicklung von Datentransfer und Kommunikation das transport-unabhängige RPC- Protokoll. Auf der RPC-Schicht gibt es das Port-Konzept von TCP/IP nicht. Soll RPC in Verbindung mit UDP oder TCP als Transport benutzt werden, sucht sich der Server einen freien Port aus und registriert diesen beim sogenannten Portmapper. Der Client wendet sich an diesen Portmapper, um dann den Port für den entsprechend registrierten Dienst zu erfahren. Im Falle von NFS ist es aber noch etwas komplizierter: NFS selbst hat nämlich per 13

14 Konvention schon einen fest zugewiesenen Port 11. Nur reicht das nicht aus, um als Client mit einem NFSv3-Server zu kommunizieren: Alle NFS-Prozeduren basieren auf opaken Filehandles, d.h. ein Client kann keine Annahmen über das Filehandle irgendeines Objekts machen, auch dann nicht, wenn der vollständige Dateiname des Objekts bekannt ist. Nur der NFS-Server kann zu einem gegebenen Dateinamen das entsprechende Filehandles ermitteln. Auch Verzeichnisse werden wie Dateien nur über ihr Filehandle angesprochen. Wenn der Client also mit READDIR oder READ- DIRPLUS den Inhalt eines Verzeichnisses lesen will, um die Filehandles der enthaltenen Dateien und Verzeichnisse zu erfahren, muß er das Filehandle des Verzeichnisses angegeben werden und nicht etwa den Namen. Wenn der Client am Anfang einer NFS-Session noch kein einziges Filehandle kennt, gibt es ein Problem: Wie soll der Client ohne ein Filehandle das Wurzelverzeichnis lesen, um sich die weitere Filehandles zu beschaffen, die er zum Arbeiten braucht? Dieses Bootstrapping-Problem wurde bis einschließlich NFSv3 mit dem zusätzlichen Mount-Protokoll gelöst. Dieses Protokoll hat lediglich die Aufgabe, das initiale Filehandle für ein Wurzelverzeichnis 12 an den NFS-Client zu übermitteln. Nun hat aber gerade das Mount-Protokoll, das ebenso wie NFS auf RPC aufsetzt, keinen fest zugewiesenen Port und ist damit genauso Firewall-unfreundlich wie FTP. Bei NFSv4 wurde auf Sideband-Protokolle vollständig verzichtet. So wird das Bootstrapping hier mit Hilfe spezieller Filehandles vollzogen. NFSv4 hat neben den opaken eine Klasse spezieller Filehandles mit definierter Semantik: z.b. das Root-Filehandle ROOT FH oder das Public-Filehandle PUBLIC FH. Diese Technik hat sich schon bei der NFS-Variante WebNFS [4, 5] 13 bewährt. Der Client kann mit dem Root- Filehandle jederzeit das Wurzelverzeichnis lesen, ohne auch nur ein einziges opakes Filehandle zu kennen. So elegant, wie das Bootstrapping mit dem Root-Filehandle auch ist, diese Methode bringt nicht nur Vorteile mit sich. Das Mount-Protokoll konnte für einen Server mehrere unabhängige Verzeichnisbäume per NFS exportie- 11 einen sogenannten well known port, wird von der IANA zugewiesen 12 Bis NFSv3 muß das Wurzelverzeichnis des NFS-Mounts nicht unbedingt mit dem Wurzelverzeichnis des exportierten lokalen Dateisystems übereinstimmen. Es können auch beliebige Teilbäume per NFS gemountet werden. 13 WebNFS ist eine Erweiterung von NFSv2 und NFSv3, die von Sun als Ersatz für HTTP entwickelt wurde. 14

15 ren, die auf der Client-Seite an unterschiedlichen Stellen in den Verzeichnisbaum eingehängt werden konnten. Da es bei NFSv4 aber nur ein einziges Root-Filehandle gibt, kann der Server entsprechend nur noch einen Verzeichnisbaum exportieren. Soll ein Unix-Server z.b. die Verzeichnisse /homes und /usr/local exportieren, wurde bei NFSv3 jeweils das Mount-Protokoll bemüht, um die Filehandles für die beiden Verzeichnisse zum Client zu übertragen. Bei Verwendung von NFSv4 muß eine andere Lösung gefunden werden. Würde man das Root-Filehandle für /homes benutzen, kann man es nicht gleichzeitig auch für /usr/local verwenden. Daher wird bei NFSv4 generell mit dem Root-Filehandle das tatsächliche Wurzelverzeichnis übertragen. Verzeichnisse, die nicht an die Clients exportiert werden sollen, werden serverseitig auf der NFS-Ebene ausgeblendet. Für den Client sieht es also so aus, als gäbe es nur die Verzeichnisse /homes und /usr, und in /usr wiederum nur local. Bei Implementierungen von NFSv4-Servern, deren Betriebssystem mehrere Verzeichnisbäume über Laufwerksbuchstaben oder Volume-Namen verwaltet, wird ein virtuelles Dateisystem aufgebaut, in dem alle Laufwerke und Volumes mit ihren Bezeichnern als Verzeichnisnamen zusammengefaßt sind. 4.2 Anforderungen an den Transport Wie schon beschrieben, setzt NFS nicht direkt auf TCP/IP auf, sondern benutzt den RPC-Mechanismus, wodurch NFS auf jedem Datendienst funktioniert, für den eine entsprechende Spezifikation implementiert ist. Neben der reinen RPC-Spezifikation muß auch festgelegt werden, wie NFS diese nutzen soll. Man könnte meinen, es sei egal, welcher Datendienst letztenendes benutzt wird, weil auf der RPC-Ebene von allen denkbaren Unterschieden abstrahiert wird. Das stimmt leider nicht ganz: Die überwiegende Menge an Dateitransfers im Internet wird über TCP (respektive FTP oder HTTP) abgewickelt. Das hat seinen Grund, denn TCP verfügt über sehr ausgefeilte Algorithmen, die dafür sorgen, daß jederzeit ein nahezu optimaler Datentransfer möglich ist. TCP muß nicht nur auf die typischen Übertragungsfehler 14 von IP Verlust oder Duplizierung von Paketen, Änderung der Reihenfolge reagieren, sondern mit der Anpassung einer Vielzahl von Parametern auf sich 14 Genaugenommen sind es keine Fehler, weil die Spezifikation von IP hier nichts verspricht, was nicht gehalten werden kann. Die Spezifikation erlaubt ausdrücklich diese Fehler. 15

16 ständig ändernde Größen wie Latenz, Netzwerkauslastung, Paketverlustrate, usw. antworten. Einer der einfachsten und gleichzeitig wichtigsten Algorithmen, die solche Anpassungen vornehmen ist Congestion Control. Congestion Control sorgt beim Sender dafür, daß nicht mehr Netzwerkverkehr erzeugt wird, als das schwächste Element in der Reihe bis zum Empänger zur Zeit noch bewältigen kann. Es ist für verbindungsorientierte Datentransfers im Internet ausgesprochen sinnvoll, diese z.t. relativ komplexen Algorithmen in die TCP-Schicht zu verlagern, und nicht etwa separat in jedes darauf aufbauende Protokoll, wie FTP oder HTTP. Der bei NFS verwendete RPC- Mechanismus ist nicht immer verbindungsorientiert. Die RPC-Schicht erbt die Eigenschaft, verbindungslos oder verbindungsorientiert zu sein, vom darunter liegenden Transport. Daher gibt es auf der RPC-Ebene auch keine Optimierungsalgorithmen wie bei TCP. Wird bei NFSv3 UDP als Transport benutzt, ist es nicht unwahrscheinlich, daß in keiner Protokollschicht Congestion Control stattfindet. Auf einem LAN ist das nicht allzu tragisch, wenn nicht gerade zwei verschiedene Ethernet-Geschwindigkeiten unglücklich aufeinandertreffen oder das Netz stets im Sättigungsbereich betrieben wird. Andererseits kann bei Datentransfers über das Internet auf Congestion Control nicht verzichtet werden. Daher verlangt die NFSv4-Spezifikation, daß Congestion Control auf der NFS-Schicht implementiert werden muß, wenn der Transport nicht selbst darüber verfügt. Es wird natürlich empfohlen, möglichst TCP für den Transport zu verwenden, weil in diesem Protokoll bereits ausgefeilte Algorithmen implementiert sind. Eine dauerhafte TCP- Verbindung ist vielen kurzlebigen unbedingt vorzuziehen, weil nur dann die Optimierungsalgorithmen von TCP greifen. 5 Interoperabilität und Portabilität Während sich NFSv3 noch stark an Unix orientierte, soll NFSv4 auch auf anderen Plattformen (Windows NT, MacOS, etc.) ohne größere Schwierigkeiten zu implementieren sein. Zu den Faktoren, die Einfluß auf die Interoperabilität und Portabilität von NFSv4 haben, zählen neben den hier aufgeführten auch Netzwerksicherheit und Internationalisierung (I18N), die wegen ihres Umfangs separat beschrieben werden. 16

17 5.1 Persistente und volatile Filehandles Wie schon erwähnt, spielen Filehandles bei NFS eine zentrale Rolle. Filehandles stellen für alle Objekte eines Filesystems jeweils eindeutige Identifikatoren dar. Sie werden als Integer repräsentiert. Filehandles sind gewöhnlich opak, d.h. clientseitig können und dürfen keine Vermutungen darüber angestellt werden, welches Filehandle zu welchem Objekt gehört. Jedes Filehandle muß explizit beim Server erfragt werden. Serverseitig wird also die Operation, Filehandles und Filesystem-Objekte einander zuzuordnen, relativ häufig angewendet. Daher sollte diese Operation möglichst schnell und einfach durchzuführen sein. Bei unixbasierten NFS-Servern wird daher fast immer auf die Inode-Nummern und ggf. Device-IDs der lokalen Filesysteme zurückgegriffen. Diese sind bereits eindeutig und es kann schnell darauf zugegriffen werden. Allerdings kann es durchaus möglich sein, daß bei bestimmten Dateisystemen insbesondere bei anderen Betriebssystemen als Unix keine so bequeme Möglichkeit besteht, jedem Objekt im Dateisystem ein eindeutiges Filehandle zuzuordnen. Für diese Fälle hält die Spezifikation von NFSv4 sogenannte volatile Filehandles bereit. Normalerweise sind Filehandles persistent, d.h. sie ändern sich auch über mehrere NFS-Sessions oder Reboot-Zyklen des NFS- Servers hinweg nicht. Der Client kann sicher sein, daß eine Datei, die einem bestimmten Filehandle zugeordnet ist, auch weiterhin mit diesem Filehandle angesprochen werden kann. Was aber passiert, wenn der NFS-Server nicht nur rebootet wird, sondern auch das Dateisystem, das er exportiert, aus einem Backup zurückgespielt werden muß? Hierbei können sich, je nach Backup- Verfahren, die Inode-Nummern, und damit die NFS-Filehandles, durchaus ändern. Bis NFSv3 konnten die Clients dann oft nur nach einem Reboot oder zumindest einem Remount wieder arbeiten. NFSv4-Clients dagegen müssen explizit auch mit volatilen Filehandles zurechtkommen, d.h. er muß sich ggf. ein neues Filehandle beschaffen, wenn das entsprechende alte ungültig wird. 5.2 Erweiterte Attribute Verschiedene Betriebssysteme unterstützen oft auch unterschiedliche Dateiattribute. So werden unter Windows NT zum Beispiel ACLs (Access Control Lists) anstelle von POSIX-üblichen Benutzer-, Gruppen- und Welt-Rechten verwendet. Der eine Mechanismus ist auch nicht verlustfrei auf den anderen 17

18 abbildbar, wobei ACLs den eindeutig flexibleren Ansatz darstellen. Wenn verschiedene Sätze von Dateiattributen schon nicht kompatibel zueinander sind, sollten sie wenigstens vollständig per NFS übertragen werden können. Während NFSv3 in bezug auf Dateiattribute noch gerade die minimalen POSIX-Anforderungen erfüllte, legt sich NFSv4 gar nicht erst auf einen vorbestimmten Satz von Attributen fest. An eine NFSv4-Implementierung wird lediglich eine Minimalanforderung in Form von wenigen elementaren Attributen (wie z.b. Zeitstempel) gestellt. Weitere Attribute, wie ACLs oder in POSIX oder im Win32-API beschriebene, werden lediglich empfohlen. Das liegt unter anderem daran, daß in vielen Situationen, in denen ein per NFS exportiertes Dateisystem über den Bereich einer administrativen Domain hinausgeht, einigen Attributen keine sinnvolle Semantik mehr zugeordnet werden kann (z.b. UID und GID). In die Kategorie der von der NFSv4-Spezifikation empfohlenen Attribute fallen auch Disk-Quota und Migration Disk-Quota Während Disk-Quota auf lokalen Dateisystemen bereits ein etabliertes Mittel zur administrativen Begrenzung des Massenspeicherverbrauchs pro Benutzer ist, kann es zu Problemen kommen, wenn ein Benutzer per NFS auf ein Dateisystem zugreift und sein Quota nahezu ausgeschöpft ist, weil der Quota- Status bis einschließlich Version 3 nicht per NFS übertragen werden kann. Erst wenn eine Schreibanforderung wegen einer Quotaüberschreitung nicht mehr ausgeführt werden kann, bemerkt das Betriebssystem des Clients das Problem. Die NFSv4-Spezifikation empfiehlt daher die Implementierung des Quota-Attributs Migration Das Migrations-Attribut soll es ermöglichen, sog. Hochverfügbarkeitslösungen zu entwickeln, ohne daß in die NFS-Clients irgendwelche speziellen Mechanismen integriert werden müssen. Mit Hilfe des Migrations-Attributs kann der Client sich automatisch an einen Backup-Server wenden, falls der eigentliche NFS-Server nicht zur Verfügung steht. Auch generelle Umzüge von Dateisystemen auf einen neuen Fileserver sind auf diese Weise ohne Ausfallzeiten 18

19 durchführbar Groß-/Kleinschreibung Nicht jedes lokale Dateisystem kann bei Pfadnamen zwischen Groß- und Kleinschreibung unterscheiden. Daher empfiehlt die NFSv4-Spezifikation die Attribute case insensitive und case preserving, um dem Client zu vermitteln, welche Fähigkeiten das Server-Filesystem in bezug auf Groß- /Kleinschreibung hat Attribut-Verzeichnisse Bis NFSv3 war es nicht möglich, ohne Erweiterung der Spezifikation neue Dateiattribute einzuführen. NFSv4 stellt universelle Attribut-Verzeichnisse zur Verfügung, die beliebige selbst definierbare Attribute aufnehmen. Wenn ein Hersteller für ein auf NFSv4 basierendes Produkt auf bestimmte Datei-Attribute angewiesen ist, kann er auf eine existierende NFSv4- Implementierungen zurückgreifen und muß lediglich das Generieren und Behandeln der neuen Attribute neu implementieren. 6 Sicherheit Sowohl bei NFS bis Version 3 als auch bei NFSv4 sind die Sicherheitsfunktionen, die eine unbefugte Nutzung von NFS-Diensten unterbinden sollen, nicht direkt Bestandteil von NFS. Sie werden vielmehr von der darunterliegenden RPC-Schicht zur Verfügung gestellt. 6.1 RPC-Authentication-Flavors RPC stellt verschiedene Authentication-Flavors zur Verfügung: AUTH NONE, AUTH SYS, AUTH DH, AUTH KERB und ein neues Flavor, auf das später genauer eingegangen wird. Die ersten vier Flavors beschränken sich lediglich auf eine der drei heute üblichen Sicherheitsfunktionen: Authentisierung. Datenintegrität und Verschlüsselung können damit nicht realisiert werden. 19

20 AUTH NONE authentisiert, wie der Name schon sagt, überhaupt nicht. Bei NFS wird AUTH NONE nur für die NULL-Prozedur verwendet. Dieser RPC wird vom Server lediglich bestätigt, löst aber keine Aktion aus. Mit der NULL-Prozedur kann der Client feststellen, ob der Server (noch) erreichbar ist. AUTH SYS verwendet zur Authentisierung die unter Unix üblichen Userund Group-IDs. Der NFS-Server hat allerdings keine Möglichkeit, die Angaben des Clients zu überprüfen und muß dem Client vertrauen. Von einer rudimentären Authentisierung kann also nur ausgegangen werden, wenn Server und Client derselben administrativen Kontrolle unterliegen und der Server nur NFS-Anfragen von sicheren Ports akzeptiert. All dies ist stark an Unix orientiert, und bereitet bei Implementierungen auf anderen Betriebssystemen Schwierigkeiten. AUTH DH war der Versuch, einen Authentication-Flavor zu schaffen, der nicht auf blindem Vertrauen basiert. Mit dem Diffie-Hellman-Verfahren einigen sich Server und Client auf einen gemeinsamen Schlüssel (Conversation Key), ohne den Schlüssel selbst auf dem Netzwerkmedium übertragen zu müssen. Der NFS-Client schickt mit jedem RPC die aktuelle Uhrzeit, die mit diesem Schlüssel verschlüsselt wurde, zum Server. Der Server entschlüsselt die Uhrzeit wieder und akzeptiert den RPC, wenn die Uhrzeit ungefähr mit der Systemzeit übereinstimmt. Leider wurde ein Parameter von AUTH DH zu klein dimensioniert, und so hat sich später herausgestellt, daß die von AUTH DH gebotene Sicherheit völlig unzureichend ist [9]. AUTH KERB benutzt Tickets von Kerberos 4 zur Authentisierung. Auch, wenn sich AUTH KERB sehr viel besser bewährt hat als AUTH DH, gilt Kerberos 4 heute als überholt und wurde durch Kerberos 5 abgelöst. 6.2 RPCSEC GSS Aus dieser Bedarfslage heraus boten die bisherigen Authentication-Flavors doch lediglich eine eher fragliche Authentisierung, wurde ein neuer Authentication-Flavor entwickelt: RPCSEC GSS. Da RPCSEC GSS neben Authentisierung auch Datenintegrität und Verschüsselung bietet, wur- 20

Verteilte Dateisysteme

Verteilte Dateisysteme Verteilte Dateisysteme Proseminar: Speicher und Dateisysteme Hauke Holstein Gliederung 1/23 - Einleitung - NFS - AFS - SMB Einleitung Was sind Verteilte Dateisysteme? 2/23 - Zugriff über ein Netzwerk -

Mehr

Seminarvortrag Secure NFS

Seminarvortrag Secure NFS Seminarvortrag Secure NFS Michael Stilkerich michael.stilkerich@informatik.stud.uni-erlangen.de am 12. Mai 2003 Einleitung Das Network File System ist ein sehr eleganter Weg, gemeinsam genutzte Dateisysteme

Mehr

Kerberos und NFSv4. Alexander Kaiser. 27. November 2012. AG Technische Informatik

Kerberos und NFSv4. Alexander Kaiser. 27. November 2012. AG Technische Informatik Kerberos und NFSv4 Alexander Kaiser AG Technische Informatik 27. November 2012 Einleitung 2 / 23 Übersicht 1 Einleitung 2 Kerberos 3 NFSv4 4 Ausblick Einleitung 3 / 23 Geschichte Kerberos verteilter Authentifizierungsdienst

Mehr

4 NFS Verzeichnisse exportieren und einbinden

4 NFS Verzeichnisse exportieren und einbinden 4 NFS Verzeichnisse exportieren und einbinden In diesem Kapitel lernen Sie: Einen NFS-Server zu konfigurieren, d. h. Verzeichnisse freizugeben. (LPI Lernziel 1.113.4) Einen NFS-Client zu konfigurieren,

Mehr

FS NetFile System. NFS Net File System. Vortrag INTRT MM99 WS 2002/03. C. Eigenstetter Fachbereich Elektrotechnik & Informatik HS Wismar

FS NetFile System. NFS Net File System. Vortrag INTRT MM99 WS 2002/03. C. Eigenstetter Fachbereich Elektrotechnik & Informatik HS Wismar NFS Net File System Vortrag INTRT MM99 WS 2002/03 1 Übersicht 1 Übersicht / Gliederung 2 Was ist NFS 3 Remote Procedure Calls 4 NFS Prozeduren 5 Mounten von Dateisystemen 6 Sicherheit 7 NFS Server 8 NFS

Mehr

AFS / OpenAFS. Bastian Steinert. Robert Schuppenies. Präsentiert von. Und

AFS / OpenAFS. Bastian Steinert. Robert Schuppenies. Präsentiert von. Und AFS / OpenAFS Präsentiert von Bastian Steinert Und obert Schuppenies Agenda AFS Verteilte Dateisysteme, allg. Aufbau Sicherheit und Zugriffsrechte Installation Demo Vergleich zu anderen DFs Diskussion

Mehr

Seminar Grid-Computing. Oktay Tugan, WS 2006/07 SICHERHEIT

Seminar Grid-Computing. Oktay Tugan, WS 2006/07 SICHERHEIT Seminar Grid-Computing Oktay Tugan, WS 2006/07 SICHERHEIT Überblick Motivation Sicherheitsfunktionen und Schwierigkeiten Anforderungen Beispiel GSI Weitere Sicherheitsmechanismen Gesellschaftliche Probleme

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft Lösungen zu ---- Informations- und Telekommunikationstechnik - Arbeitsheft Handlungsschritt Aufgabe a) Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP- Adressen), die eine

Mehr

Fileserver mit OSL Storage Cluster Hochverfügbare NFS und Samba Server in heterogenen Netzwerkumgebungen. 11.10.2007 Christian Schmidt

Fileserver mit OSL Storage Cluster Hochverfügbare NFS und Samba Server in heterogenen Netzwerkumgebungen. 11.10.2007 Christian Schmidt Fileserver mit OSL Storage Cluster Hochverfügbare NFS und Samba Server in heterogenen Netzwerkumgebungen 11.10.2007 Christian Schmidt Agenda Ausgangssituation am Beispiel der IBB Einführung in NFS und

Mehr

Kodierungsalgorithmen

Kodierungsalgorithmen Kodierungsalgorithmen Komprimierung Verschlüsselung Komprimierung Zielsetzung: Reduktion der Speicherkapazität Schnellere Übertragung Prinzipien: Wiederholungen in den Eingabedaten kompakter speichern

Mehr

VPN mit Windows Server 2003

VPN mit Windows Server 2003 VPN mit Windows Server 2003 Virtuelle private Netzwerke einzurichten, kann eine sehr aufwendige Prozedur werden. Mit ein wenig Hintergrundwissen und dem Server- Konfigurationsassistenten von Windows Server

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr

DriveLock in Terminalserver Umgebungen

DriveLock in Terminalserver Umgebungen DriveLock in Terminalserver Umgebungen Technischer Artikel CenterTools Software GmbH 2011 Copyright Die in diesen Unterlagen enthaltenen Angaben und Daten, einschließlich URLs und anderen Verweisen auf

Mehr

TCP/IP-Protokollfamilie

TCP/IP-Protokollfamilie TCP/IP-Protokollfamilie Internet-Protokolle Mit den Internet-Protokollen kann man via LAN- oder WAN kommunizieren. Die bekanntesten Internet-Protokolle sind das Transmission Control Protokoll (TCP) und

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 20.06.2003 Internet Security:

Mehr

Heterogenes Speichermanagement mit V:DRIVE

Heterogenes Speichermanagement mit V:DRIVE Heterogenes Speichermanagement mit V:DRIVE V:DRIVE - Grundlage eines effizienten Speichermanagements Die Datenexplosion verlangt nach innovativem Speichermanagement Moderne Businessprozesse verlangen auf

Mehr

Lehrveranstaltung Speichersysteme Sommersemester 2009

Lehrveranstaltung Speichersysteme Sommersemester 2009 Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 12: Network File Systems André Brinkmann Beispiel: SUN NFS NFS (Network File System) ist ein offenes Protokoll für den Austausch von Dateien

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

CFS und TCFS. Proseminar Konzepte von Betriebssystem-Komponenten Schwerpunkt Sicherheit. 1. Ziele eines verschlüsselten Dateisystems

CFS und TCFS. Proseminar Konzepte von Betriebssystem-Komponenten Schwerpunkt Sicherheit. 1. Ziele eines verschlüsselten Dateisystems Proseminar Konzepte von Betriebssystem-Komponenten Schwerpunkt Sicherheit CFS und TCFS Franz Hirschbeck franz@hirschbeck.net 1. Ziele eines verschlüsselten Dateisystems Seine Dateien vor ungewollten Einblicken

Mehr

R e m o t e A c c e s s. Cyrus Massoumi

R e m o t e A c c e s s. Cyrus Massoumi R e m o t e A c c e s s Präsentation im Seminar Internet-Technologie im Sommersemester 2008 von Cyrus Massoumi I n h a l t Was versteht man unter Remote Access Unsichere Remotezugriffe TELNET Remote Shell

Mehr

6.2 FAT32 Dateisystem

6.2 FAT32 Dateisystem 6.2 FAT32 Dateisystem Dateisystem für Windows 98 einige Unterschiede zum Linux-Dateisystem EXT2: keine Benutzeridentifikation für Dateien und Verzeichnisse! Partitionen werden durch Laufwerke repräsentiert,

Mehr

Single-Sign-On mit Kerberos V

Single-Sign-On mit Kerberos V Single-Sign-On mit Kerberos V Jörg Rödel 21. Oktober 2005 Jörg Rödel Was ist Single-Sign-On? oft nur verstanden als ein Nutzer/Passwort-Paar für alle Dienste eines Netzwerkes so wird es

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

peer-to-peer Dateisystem Synchronisation

peer-to-peer Dateisystem Synchronisation Ziel Realisierungen Coda Ideen Fazit Literatur peer-to-peer Dateisystem Synchronisation Studiendepartment Informatik Hochschule für Angewandte Wissenschaften Hamburg 30. November 2007 Ziel Realisierungen

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage. RAM empfohlen. RAM maximal

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage. RAM empfohlen. RAM maximal 1. HANDLUNGSSCHRITT Aufgabe 13 Betriebssystem Prozessortakt RAM empfohlen RAM maximal Installationsgröße SMP Anzahl Prozessoren Windows 7 Ultimate 2008 Web 2008 Standard 2008 Enterprise 2008 Datacenter

Mehr

KN 20.04.2015. Das Internet

KN 20.04.2015. Das Internet Das Internet Internet = Weltweiter Verbund von Rechnernetzen Das " Netz der Netze " Prinzipien des Internet: Jeder Rechner kann Information bereitstellen. Client / Server Architektur: Server bietet Dienste

Mehr

VPN Tunnel Konfiguration. VPN Tunnel Konfiguration IACBOX.COM. Version 2.0.2 Deutsch 11.02.2015

VPN Tunnel Konfiguration. VPN Tunnel Konfiguration IACBOX.COM. Version 2.0.2 Deutsch 11.02.2015 VPN Tunnel Konfiguration Version 2.0.2 Deutsch 11.02.2015 Dieses HOWTO beschreibt die Konfiguration eines VPN Tunnels zu einem (zentralisierten) OpenVPN Server. VPN Tunnel Konfiguration TITEL Inhaltsverzeichnis

Mehr

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

Mehr

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Zusammenfassung Kapitel 4 Dateiverwaltung 1 Datei logisch zusammengehörende Daten i.d.r. permanent

Mehr

Domain Name Service (DNS)

Domain Name Service (DNS) Domain Name Service (DNS) Aufgabe: den numerischen IP-Adressen werden symbolische Namen zugeordnet Beispiel: 194.94.127.196 = www.w-hs.de Spezielle Server (Name-Server, DNS) für Listen mit IP-Adressen

Mehr

7 TCP/IP-Dienste konfigurieren

7 TCP/IP-Dienste konfigurieren 7 TCP/IP-Dienste konfigurieren In diesem Kapitel lernen Sie die Begriffe Ports,Sockets und Connections kennen (LPI 1: 109.1). den Zusammenhang der Ports von TCP/IP-Diensten mit der Datei /etc/services

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel VS7 Slide 1 Verteilte Systeme Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

SSH. Die Secure Shell am Beispiel von OpenSSH. Dirk Geschke. Linux User Group Erding. 26. Oktober 2011

SSH. Die Secure Shell am Beispiel von OpenSSH. Dirk Geschke. Linux User Group Erding. 26. Oktober 2011 SSH Die Secure Shell am Beispiel von OpenSSH Dirk Geschke Linux User Group Erding 26. Oktober 2011 Dirk Geschke (LUG-Erding) SSH 26. Oktober 2011 1 / 18 Gliederung 1 Historisches 2 Details 3 Keys 4 SSH-Optionen

Mehr

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH von Dominick Baier (dbaier@ernw.de) und Jens Franke (jfranke@ernw.de) 1 Einleitung Dieses Dokument behandelt die flexible

Mehr

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576 ein verteiltes und repliziertes Dateisystem is funded by the European Commission XtreemOS IPunder project contract IST-FP6-033576 1 Das XtreemOS Projekt Europäisches Forschungsprojekt gefördert von der

Mehr

Collax Web Application

Collax Web Application Collax Web Application Howto In diesem Howto wird die Einrichtung des Collax Moduls Web Application auf einem Collax Platform Server anhand der LAMP Anwendung Joomla beschrieben. LAMP steht als Akronym

Mehr

4 Netzwerkzugriff. 4.1 Einführung. Netzwerkzugriff

4 Netzwerkzugriff. 4.1 Einführung. Netzwerkzugriff 4 Netzwerkzugriff Prüfungsanforderungen von Microsoft: Configuring Network Access o Configure remote access o Configure Network Access Protection (NAP) o Configure network authentication o Configure wireless

Mehr

Dynamische Web-Anwendung

Dynamische Web-Anwendung Dynamische Web-Anwendung Christiane Lacmago Seminar Betriebssysteme und Sicherheit Universität Dortmund WS 02/03 Gliederung Einleitung Definition und Erläuterung Probleme der Sicherheit Ziele des Computersysteme

Mehr

Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe. Dokumentversion: 1.0.2

Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe. Dokumentversion: 1.0.2 Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe Dokumentversion: 1.0.2 Inhaltsverzeichnis 1. System Überblick 4 2. Windows Firewall Konfiguration 5 2.1. Erlauben von DCOM Kommunikation

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) Verbindungsorientiertes Protokoll, zuverlässig, paketvermittelt stream-orientiert bidirektional gehört zur Transportschicht, OSI-Layer 4 spezifiziert in RFC 793 Mobile

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

FTP Server unter Windows XP einrichten

FTP Server unter Windows XP einrichten Seite 1 von 6 FTP Server unter Windows XP einrichten Es gibt eine Unmenge an komerziellen und Open Source Software die auf dem File Transfer Protocol aufsetze Sicherlich ist das in Windows enthaltene Softwarepaket

Mehr

PVFS (Parallel Virtual File System)

PVFS (Parallel Virtual File System) Management grosser Datenmengen PVFS (Parallel Virtual File System) Thorsten Schütt thorsten.schuett@zib.de Management grosser Datenmengen p.1/?? Inhalt Einführung in verteilte Dateisysteme Architektur

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

8 Network File System einrichten

8 Network File System einrichten 155 8 Network File System einrichten Um Clients ganze Verzeichnisse von Servern zum Lesen oder Lesen und Schreiben zur Verfügung zu stellen, benutzt man im Unix-Umfeld und generell in heterogenen Umgebungen

Mehr

Jeder Datenträger besitzt einen I-Node-Array. Jede Datei auf dem Datenträger hat einen I-Node-Eintrag.

Jeder Datenträger besitzt einen I-Node-Array. Jede Datei auf dem Datenträger hat einen I-Node-Eintrag. Einführung in die Betriebssysteme Fallstudien zu Dateisystemen Seite 1 Unix-Dateisystem Der Adreßraum einer Datei wird in gleichlange Blöcke aufgeteilt. Ein Block hat die Länge von 1 oder mehreren Sektoren

Mehr

Netzwerkadministration unter SuSE Linux. Daniel Willmann. Stefan Schmidt. Begrüßung. Inhalt. Zeitplan 2005-04-28

Netzwerkadministration unter SuSE Linux. Daniel Willmann. Stefan Schmidt. Begrüßung. Inhalt. Zeitplan 2005-04-28 Begrüßung Inhalt Zeitplan Willmann 2005-04-28 Begrüßung Begrüßung Inhalt Zeitplan Wer sind wir? Studenten der TU Braunschweig, Diplom Informatik Wissenschaftliche Hilfskräfte im Rechenzentrum der TU Wer

Mehr

Authentication Header: Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen

Authentication Header: Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen IP Security Zwei Mechanismen: Authentication : Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen Encapsulating Security Payloads (ESP): Verschl., Datenauth. Internet Key Exchange Protokoll:

Mehr

Kooperativer Speicher: Schwächen und Gegenmaßnahmen

Kooperativer Speicher: Schwächen und Gegenmaßnahmen Kooperativer Speicher: Schwächen und Gegenmaßnahmen Cooperative storage: weaknesses and countermeasures Lutz Behnke 2. Dezember 2005 2005 Lutz Behnke 1 /home/sage/texte/haw/master/seminar/coop_storage_failure.sxi

Mehr

ICMP Internet Control Message Protocol. Michael Ziegler

ICMP Internet Control Message Protocol. Michael Ziegler ICMP Situation: Komplexe Rechnernetze (Internet, Firmennetze) Netze sind fehlerbehaftet Viele verschiedene Fehlerursachen Administrator müsste zu viele Fehlerquellen prüfen Lösung: (ICMP) Teil des Internet

Mehr

DATEIÜBERTRAGUNGS- PROTOKOLLE

DATEIÜBERTRAGUNGS- PROTOKOLLE DATEIÜBERTRAGUNGS- PROTOKOLLE KV Sicherheit in Applikationsprotokollen Florian Ströbitzer 11 Inhalt 1. TFTP Trivial File Transfer Protocol... 2 1.1. Übertragungsmodi... 2 1.2. Das Protokoll... 3 2. FTP

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

7 Transportprotokolle

7 Transportprotokolle 7 Transportprotokolle 7.1 Transmission Control Protocol (TCP) 7.2 User Datagram Protocol (UDP) 7.3 Ports 7.1 TCP (1) IP-Pakete (Datagramme) von A nach B transportieren reicht nicht interaktive Verbindungen

Mehr

Herzlich Willkommen. Zum Vortrag zu Netzwerk und Linux im Rahmen der Linux Installations Party 2007

Herzlich Willkommen. Zum Vortrag zu Netzwerk und Linux im Rahmen der Linux Installations Party 2007 Herzlich Willkommen Zum Vortrag zu Netzwerk und Linux im Rahmen der Linux Installations Party 2007 Einführung Konnektivität Protokolle Lokale Netze - Samba (SMB/CIFS) - Network File System (NFS) Internet

Mehr

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

2 Datei- und Druckdienste

2 Datei- und Druckdienste Datei- und Druckdienste 2 Datei- und Druckdienste Lernziele: Verteiltes Dateisystem (DFS) Dateiserver Ressourcen Manager (FSRM) Verschlüsseln Erweiterte Überwachung Prüfungsanforderungen von Microsoft:

Mehr

Aktive Schnittstellenkontrolle

Aktive Schnittstellenkontrolle Aktive Schnittstellenkontrolle Version 1.0 Ausgabedatum 05.03.2013 Status in Bearbeitung in Abstimmung Freigegeben Ansprechpartner Angelika Martin 0431/988-1280 uld34@datenschutzzentrum.de Inhalt 1 Problematik...2

Mehr

Server: Vice nach Tanenbaum, van Steen

Server: Vice nach Tanenbaum, van Steen 3 Fallbeispiel: Coda Nachfolger des Andrew File Systems (AFS) Carnegie Mellon University, 1990 (CMU) Zielsetzung hohe Verfügbarkeit bei mehreren 10.000 Client-Rechnern Fehlertoleranz abgesetzter Betrieb

Mehr

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Version 2.1 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Stand: 28.10.2014 ads-tec GmbH 2014 Big-LinX 2 Inhaltsverzeichnis 1 Einführung... 3 1.1 NAT

Mehr

4D v11 SQL Release 6 (11.6) ADDENDUM

4D v11 SQL Release 6 (11.6) ADDENDUM ADDENDUM Willkommen zu Release 6 von 4D v11 SQL. Dieses Dokument beschreibt die neuen Funktionalitäten und Änderungen der Version. Erweiterte Verschlüsselungsmöglichkeiten Release 6 von 4D v11 SQL erweitert

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

M@School - Zugriff von zuhause auf die Tauschlaufwerke

M@School - Zugriff von zuhause auf die Tauschlaufwerke Bildung und Sport M@School - Zugriff von zuhause auf die Tauschlaufwerke Inhaltsverzeichnis 1.Einige Infos zum Thema WebDAV...2 1.1 Was steckt hinter WebDAV?...2 1.2 Erweiterung des HTTP-Protokolls...2

Mehr

Erstellen sicherer ASP.NET- Anwendungen

Erstellen sicherer ASP.NET- Anwendungen Erstellen sicherer ASP.NET- Anwendungen Authentifizierung, Autorisierung und sichere Kommunikation Auf der Orientierungsseite finden Sie einen Ausgangspunkt und eine vollständige Übersicht zum Erstellen

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Filesystem in Userspace. Jens Spiekermann

Filesystem in Userspace. Jens Spiekermann Filesystem in Userspace Jens Spiekermann Aufbau Was ist FUSE? Grundlagen Wie funktioniert FUSE? Eigenschaften Vorteile Nachteile Wofür kann man FUSE nutzen? Wie wird FUSE benutzt? Abschluss Quellen 2/23

Mehr

Nutzung der WebDAV-Ressourcen des RRZN mittels Windows 7

Nutzung der WebDAV-Ressourcen des RRZN mittels Windows 7 Nutzung der WebDAV-Ressourcen des RRZN mittels Windows 7 10. Juni 2011 Diese Anleitung bezieht sich auf Windows 7 mit allen Updates bis zum Erstellungsdatum dieser Dokumentation. WebDAV (Web-based Distributed

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

Einführung. zum Thema. Firewalls

Einführung. zum Thema. Firewalls Einführung zum Thema Firewalls 1. Einführung 2. Firewall-Typen 3. Praktischer Einsatz 4. Linux-Firewall 5. Grenzen 6. Trends 7. Fazit 1. Einführung 1.Einführung Die Nutzung des Internets bringt viele neue

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Microsoft ISA Server 2006

Microsoft ISA Server 2006 Microsoft ISA Server 2006 Leitfaden für Installation, Einrichtung und Wartung ISBN 3-446-40963-7 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40963-7 sowie im Buchhandel

Mehr

Linux & Security. Andreas Haumer xs+s. Einsatz von Linux in sicherheitsrelevanten Umgebungen

Linux & Security. Andreas Haumer xs+s. Einsatz von Linux in sicherheitsrelevanten Umgebungen Linux & Security Andreas Haumer xs+s Einsatz von Linux in sicherheitsrelevanten Umgebungen Einführung Netzwerksicherheit wichtiger denn je Unternehmenskritische IT Infrastruktur Abhängigkeit von E Services

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

Michael Flachsel. Das SAN an der TUB. Aufbau und Funktion. 15. November 2007

Michael Flachsel. Das SAN an der TUB. Aufbau und Funktion. 15. November 2007 Michael Flachsel Das SAN an der TUB Aufbau und Funktion 15. November 2007 Struktur Produktion Backup 2 (c) 2007 Michael Flachsel TUB-SAN" Hardware 3 (c) 2007 Michael Flachsel TUB-SAN" Komponenten 8x IBM

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Matthias Hofherr. WLAN-Sicherheit. Professionelle Absicherung von 802.11-Netzen. Heise

Matthias Hofherr. WLAN-Sicherheit. Professionelle Absicherung von 802.11-Netzen. Heise Matthias Hofherr WLAN-Sicherheit Professionelle Absicherung von 802.11-Netzen Heise 5 Bevor man einen genaueren Blick auf die Sicherheitsmechanismen von Netzwerken auf Basis des Standards 802.11 wirft,

Mehr

OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE

OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE Tobias Jähnel und Peter Trommler Fakultät Informatik Georg-Simon-Ohm-Hochschule Nürnberg http://offlinefs.sourceforge.net Übersicht Hintergrund

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

AltaVista Internet Software - Internet Security

AltaVista Internet Software - Internet Security AltaVista Software - Security sichere Anbindung an das vertrauliche Kommunikation über das Mathias Schmitz AltaVista Software mathias.schmitz@altavista.digital.com Die Risiken des sind real! Jede 5. Anschluß

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

bintec Secure IPSec Client - für professionellen Einsatz bintec IPSec Client

bintec Secure IPSec Client - für professionellen Einsatz bintec IPSec Client bintec Secure IPSec Client - für professionellen Einsatz Unterstützt 32- und 64-Bit Betriebssysteme Windows 7, Vista, Windows XP Integrierte Personal Firewall Einfache Installation über Wizard und Assistent

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 6: 14.11.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-, Unterstützungs-,

Mehr

WLAN,Netzwerk Monitoring & Filtering. SS 2011 Betreuer: Dr.Oliver Dippel Teilnehmer:Constant Mabou Bopda

WLAN,Netzwerk Monitoring & Filtering. SS 2011 Betreuer: Dr.Oliver Dippel Teilnehmer:Constant Mabou Bopda WLAN,Netzwerk Monitoring & Filtering SS 2011 Betreuer: Dr.Oliver Dippel Teilnehmer:Constant Mabou Bopda Überblick Wireless und Netzwerk Protokoll Was ist Netzwerk Monitoring? Was ist Netzwerk Filtering?

Mehr

Teldat Secure IPSec Client - für professionellen Einsatz Teldat IPSec Client

Teldat Secure IPSec Client - für professionellen Einsatz Teldat IPSec Client Teldat Secure IPSec Client - für professionellen Einsatz Unterstützt Windows 8 Beta, 7, XP (32-/64-Bit) und Vista IKEv1, IKEv2, IKE Config Mode, XAuth, Zertifikate (X.509) Integrierte Personal Firewall

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

Fujitsu Siemens Computer FlexFrame-Technologie und der REALTECH theguard! ApplicationManager. Status: 12.11.08

Fujitsu Siemens Computer FlexFrame-Technologie und der REALTECH theguard! ApplicationManager. Status: 12.11.08 Fujitsu Siemens Computer FlexFrame-Technologie und der REALTECH theguard! ApplicationManager Status: 12.11.08 Inhalt Einführung in FlexFrame... 3 Überwachung und Analyse von FlexFrame mit theguard! ApplicationManager...

Mehr