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

Verteilte Systeme. Verteilte Systeme. 9 Verteilte Dateisysteme SS 2015

Verteilte Systeme. Verteilte Systeme. 9 Verteilte Dateisysteme SS 2015 Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

1 Network File System ( NFS )

1 Network File System ( NFS ) Network File System 1 Network File System ( NFS ) 1.1 Motivation für die Entwicklung Mit Hilfe von ftp können komplette reguläre Dateien von einem Rechner über das Netzwerk zu einem anderen Rechner transferiert

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

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

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

Einfu hrung in Subversion mit TortoiseSVN

Einfu hrung in Subversion mit TortoiseSVN Einfu hrung in Subversion mit TortoiseSVN Inhalt Konzept... 1 Begriffe... 1 Werkzeuge... 2 Arbeiten mit TortoiseSVN... 2 Vorbereitung... 2 Erster Checkout... 2 Hinzufügen eines neuen Verzeichnisses...

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

2.3 Applikationen. Protokolle: TCP/IP. Telnet, FTP, Rlogin. Carsten Köhn

2.3 Applikationen. Protokolle: TCP/IP. Telnet, FTP, Rlogin. Carsten Köhn 2.3 Applikationen Telnet, FTP, Rlogin Carsten Köhn Protokolle: TCP/IP Application umfasst Dienste, die als Prozesse des Betriebssystems ausgeführt werden SMTP, FTP, HTTP, MIME Transport regelt die Kommunikation

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

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

Übung 6 Lösungsskizze Kryptographie, Sicherheit in verteilten Dateisystemen

Übung 6 Lösungsskizze Kryptographie, Sicherheit in verteilten Dateisystemen Übung zu Verteilte Betriebssysteme (WS 2003) Übung 6 Lösungsskizze Kryptographie, Sicherheit in verteilten Dateisystemen Andreas I. Schmied Verteilte Systeme Universität Ulm Mail zur Übung an vbs@vs.informatik.uni-ulm.de

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

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

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

Dropbox Verschlüsselung mit TrueCrypt

Dropbox Verschlüsselung mit TrueCrypt 1 von 8 19.04.2013 15:17 Datenbank Dropbox Verschlüsselung mit TrueCrypt http://www.hpier.de/wb» Software» Dropbox Verschlüsselung mit TrueCrypt Daten in der Dropbox Cloud mit TrueCrypt sicher verschlüsseln

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

Übersicht. UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32

Übersicht. UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32 Übersicht UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32 Die in diesem Teil vorgestellten Informationen stellen lediglich das Prinzip dar - im Detail ist alles etwas komplizierter...

Mehr

Software-gestützte Pufferung: Verteilte Dateisysteme. BP 2 Software-gestützte Pufferung: Verteilte Dateisysteme BP 2 BP 2 BP 2

Software-gestützte Pufferung: Verteilte Dateisysteme. BP 2 Software-gestützte Pufferung: Verteilte Dateisysteme BP 2 BP 2 BP 2 3.3 Verteilte Dateisysteme Architektur Dateidienst-Interface Verlagerungsmodell (upload/download model) Ganze Dateien werden vom zum transferiert lund dort bearbeitet Typisch für Massenspeichersysteme,

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

Kodierungsalgorithmen

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

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

Internetprotokoll TCP / IP

Internetprotokoll TCP / IP Internetprotokoll TCP / IP Inhaltsverzeichnis TCP / IP - ALLGEMEIN... 2 TRANSPORTPROTOKOLLE IM VERGLEICH... 2 TCP / IP EIGENSCHAFTEN... 2 DARPA MODELL... 3 DIE AUFGABEN DER EINZELNEN DIENSTE / PROTOKOLLE...

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

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

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

Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface.

Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface. Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface. Inhaltsverzeichnis Erste Schritte Anmelden 2 Startseite 3 Dateimanager 4 CargoLink 5 Freigaben 6

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

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

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

Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte.

Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte. 4 Domänenkonzepte Ziele des Kapitels: Sie verstehen den Begriff Domäne. Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte. Sie verstehen die Besonderheiten der Vertrauensstellungen

Mehr

How-to: VPN mit IPSec und Gateway to Gateway. Securepoint Security System Version 2007nx

How-to: VPN mit IPSec und Gateway to Gateway. Securepoint Security System Version 2007nx Securepoint Security System Version 2007nx Inhaltsverzeichnis VPN mit IPSec und Gateway to Gateway... 3 1 Konfiguration der Appliance... 4 1.1 Erstellen von Netzwerkobjekten im Securepoint Security Manager...

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

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

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

Kurzanleitung zu. von Daniel Jettka 18.11.2008

Kurzanleitung zu. von Daniel Jettka 18.11.2008 Kurzanleitung zu Tigris.org Open Source Software Engineering Tools von Daniel Jettka 18.11.2008 Inhaltsverzeichnis 1.Einführung...1 2.Das Projektarchivs...3 2.1.Anlegen des Projektarchivs...3 2.2.Organisation

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

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

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

Installationsanleitung Volksbank Office Banking Mehrplatzinstallation

Installationsanleitung Volksbank Office Banking Mehrplatzinstallation Installationsanleitung Volksbank Office Banking Mehrplatzinstallation Inhalt Systemvoraussetzungen... 1 Hintergrund zur Installation... 1 Installation des DBMS auf einem Server... 2 Mehrplatz Installationsvarianten

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

3 Entwerfen von Identitäts- und

3 Entwerfen von Identitäts- und 3 Entwerfen von Identitäts- und Zugriffsmanagementkomponenten Prüfungsanforderungen von Microsoft: Designing Support Identity and Access Management Components o Plan for domain or forest migration, upgrade,

Mehr

dsmisi Storage Lars Henningsen General Storage

dsmisi Storage Lars Henningsen General Storage dsmisi Storage dsmisi MAGS Lars Henningsen General Storage dsmisi Storage Netzwerk Zugang C Zugang B Zugang A Scale-Out File System dsmisi Storage Netzwerk Zugang C Zugang B Zugang A benötigt NFS oder

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

Marketing Update. Enabler / ENABLER aqua / Maestro II

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

Mehr

Kryptographische Dateisysteme

Kryptographische Dateisysteme 1 Proseminar: Konzepte von Betriebssystemkomponenten 1 Kryptographische Dateisysteme 2 Übersicht über den Vortrag 2 Braucht man überhaupt Verschlüsslung von Dateisystemen? Konkrete Zielsetzung Cryptographic

Mehr

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

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

Port-Weiterleitung einrichten

Port-Weiterleitung einrichten Port-Weiterleitung einrichten Dokument-ID Port-Weiterleitung einrichten Version 1.5 Status Endfassung Ausgabedatum 13.03.2015 Centro Business Inhalt 1.1 Bedürfnis 3 1.2 Beschreibung 3 1.3 Voraussetzungen/Einschränkungen

Mehr

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

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

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

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

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com Verfügbarkeit von Applikationen und Failover Szenarien Winfried Wojtenek wojtenek@mac.com Verfügbarkeit % Tage Stunden Minuten 99.000 3 16 36 99.500 1 20 48 99.900 0 9 46 99.990 0 0 53 99.999 0 0 5 Tabelle

Mehr

DHCP. DHCP Theorie. Inhalt. Allgemein. Allgemein (cont.) Aufgabe

DHCP. DHCP Theorie. Inhalt. Allgemein. Allgemein (cont.) Aufgabe 23. DECUS München e.v. Symposium 2000 Bonn Norbert Wörle COMPAQ Customer Support Center Inhalt Theorie Allgemein Aufgabe von Vorteile / Nachteile Wie bekommt seine IP Adresse? Wie wird Lease verlängert?

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

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

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Client-Server-Prinzip

Client-Server-Prinzip Client-Server-Prinzip Kommunikation im Internet erfolgt nach dem Client-Server-Prinzip: Client sendet eine Anfrage (fordert eine Dienstleistung an) Server sendet die Antwort (bietet eine Dienstleistung

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP)

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP) Enterprise Applikation Integration und Service-orientierte Architekturen 09 Simple Object Access Protocol (SOAP) Anwendungsintegration ein Beispiel Messages Warenwirtschaftssystem Auktionssystem thats

Mehr

Powermanager Server- Client- Installation

Powermanager Server- Client- Installation Client A Server Client B Die Server- Client- Funktion ermöglicht es ein zentrales Powermanager Projekt von verschiedenen Client Rechnern aus zu bedienen. 1.0 Benötigte Voraussetzungen 1.1 Sowohl am Server

Mehr

Enterprise User Security mit Active Directory

Enterprise User Security mit Active Directory Enterprise User Security mit Active Directory Jürgen Kühn Trivadis GmbH Düsseldorf Schlüsselworte: Enterprise User Security, Active Directory, Directory Integration and Provisioning, Active Directory Passwort

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

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

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

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

Wiederholung: Realisierung von Dateien

Wiederholung: Realisierung von Dateien Wiederholung: Realisierung von Dateien Zusammenhängende Belegung Datei A Datei C Datei E Datei G Datei B Datei D Datei F Belegung durch verkettete Listen (z.b. FAT) Dateiblock 0 Dateiblock 1 Dateiblock

Mehr

Netzwerksicherheit mit Hilfe von IPSec

Netzwerksicherheit mit Hilfe von IPSec Unterrichtseinheit 6: Netzwerksicherheit mit Hilfe von IPSec Bei IPSec (Internet Protocol Security) handelt es sich um ein Gerüst offener Standards, um eine sichere, private Kommunikation über IP-Netzwerke

Mehr

Das NT Domänen-Konzept

Das NT Domänen-Konzept Das NT Domänen-Konzept Einführung Was ist eine Domäne? Was ist eine Gruppe? Was ist ein Trust? Domänen Das Single Domain Model Das Single Master Domain Model Das Multiple Master Domain Model Das Complete

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

Client-Server mit Socket und API von Berkeley

Client-Server mit Socket und API von Berkeley Client-Server mit Socket und API von Berkeley L A TEX Projektbereich Deutsche Sprache Klasse 3F Schuljahr 2015/2016 Copyleft 3F Inhaltsverzeichnis 1 NETZWERKPROTOKOLLE 3 1.1 TCP/IP..................................................

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

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

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

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

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

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

ISO INTERCOM School Office

ISO INTERCOM School Office ISO INTERCOM School Office Zusammenfassung der Systemvoraussetzungen und Systemkonfiguration Alle Rechte vorbehalten! 2011 INTERCOM GmbH (se) Das nachfolgende Dokument behandelt einige der häufigsten Support-Anfragen

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

CFS und TCFS. 2 kryptografische Dateisysteme für Unix von der Idee zur Anwendung

CFS und TCFS. 2 kryptografische Dateisysteme für Unix von der Idee zur Anwendung CFS und TCFS 2 kryptografische Dateisysteme für Unix von der Idee zur Anwendung CFS und TCFS 1. Ziele des Dateisystems 2. CFS als Lösung 3. CFS in der Anwendung 4. Verbesserungen bei TCFS 5. Anwendung

Mehr

X5 unter Windows Vista / 7 und Windows 2008 Server

X5 unter Windows Vista / 7 und Windows 2008 Server X5 unter Windows Vista / 7 und Windows 2008 Server Die Benutzerkontensteuerung (später UAC) ist ein Sicherheitsfeature welches Microsoft ab Windows Vista innerhalb Ihrer Betriebssysteme einsetzt. Die UAC

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

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg.

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg. VRRP Virtual Router Redundancy Protocol Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3824540662 Netzwerke auf Basis des Internet Protocol (IP)

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Folgende Einstellungen sind notwendig, damit die Kommunikation zwischen Server und Client funktioniert:

Folgende Einstellungen sind notwendig, damit die Kommunikation zwischen Server und Client funktioniert: Firewall für Lexware professional konfigurieren Inhaltsverzeichnis: 1. Allgemein... 1 2. Einstellungen... 1 3. Windows XP SP2 und Windows 2003 Server SP1 Firewall...1 4. Bitdefender 9... 5 5. Norton Personal

Mehr

38 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional)

38 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional) 38 Netzwerk- und Mehrbenutzerfähigkeit (Version Professional) Mit easy2000 haben Sie ein, im Vergleich zu anderen Anbietern, sehr preiswertes System für Ihr Business erworben. easy2000 ist auch im Netzwerkbetrieb

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

3 Das verbindungslose Vermittlungsprotokoll IP

3 Das verbindungslose Vermittlungsprotokoll IP Das verbindungslose Vermittlungsprotokoll IP 27 3 Das verbindungslose Vermittlungsprotokoll IP In diesem Kapitel lernen Sie das verbindungslose Vermittlungsprotokoll IP näher kennen. Nach dem Durcharbeiten

Mehr

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003 Subnetting Einleitung Thema dieser Ausarbeitung ist Subnetting Ganz zu Beginn werden die zum Verständnis der Ausführung notwendigen Fachbegriffe

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

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel

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

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

Formular»Fragenkatalog BIM-Server«

Formular»Fragenkatalog BIM-Server« Formular»Fragenkatalog BIM-Server«Um Ihnen so schnell wie möglich zu helfen, benötigen wir Ihre Mithilfe. Nur Sie vor Ort kennen Ihr Problem, und Ihre Installationsumgebung. Bitte füllen Sie dieses Dokument

Mehr

ND.Zip & Notes/Domino 6

ND.Zip & Notes/Domino 6 ND.Zip for Notes Version 1.1 ND.Zip & Notes/Domino 6 Stand: 9.5.2003 Inhaltsverzeichnis 1 Inhaltsverzeichnis 2 ND.Zip: ein Muss auch für Notes/Domino 6! 3 LZ1 erzielt keinen Mehrwert, 4 Sofortiger und

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

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

Bei Truecrypt handelt es sich um ein Open-Source Verschlüsselungs-Programm, das unter folgendem Link für verschiedene Plattformen verfügbar ist:

Bei Truecrypt handelt es sich um ein Open-Source Verschlüsselungs-Programm, das unter folgendem Link für verschiedene Plattformen verfügbar ist: Selbstdatenschutz Dropbox & Co. sicher nutzen "MEO - My Eyes Only" Um Unbefugten (inklusive dem Betreiber des Dienstes) die Einsicht in Dateien in Clouddiensten zu verwehren, sollte man diese verschlüsseln.

Mehr

Protected User-Level DMA in SCI Shared Memory Umgebungen

Protected User-Level DMA in SCI Shared Memory Umgebungen Protected User-Level DMA in SCI Shared Memory Umgebungen Mario Trams University of Technology Chemnitz, Chair of Computer Architecture 6. Halle Chemnitz Seminar zu Parallelverarbeitung und Programmiersprachen

Mehr