Collector¶
Konfiguration¶
Die Konfiguration des Collector Services basiert auf unserem Konfigurationssystem. Im einfachsten Fall schreibst du deine Konfiguration in eine Datei configuration.xml welche du im Verzeichnis der Anwendung platzierst. Die genauen Details zum Konfigurationssystem findest du im Kapitel Konfigurationssystem.
Schema der Konfiguration¶
Das folgende Schema zeigt die Struktur der Konfiguration:
Module
Application
Must be an existing file.
List
Complex list definition
Minimum length:
1Maximum length:
8Must match this regular expression:
[a-z]{1,8}
Must be one of this:
PowerShellNative,PowerShellWMI,Agent
Must be an existing file.
Complex list definition
Must not be empty.
Must be one of this:
Message,HTTP
Must not be empty.
List
Complex list definition
Must not be empty.
Must not be empty.
Must not be empty.
Must be one of this:
ReadProcessListMust not have duplicates.
Must be one of this:
Any,Message,HTTP
Default Value:
Any
Default Value:
Yes
Die Liste profiles¶
Mit der Liste profiles definierst du eines oder mehrere Profile um Prozessinformationen von Servern und Clients abzufragen. Jeder Eintrag in der Liste hat dabei einen eindeutigen Bezeichner den du in der Datei mit den Server und Computer Namen verwenden kannst.
Der Wert identifier¶
Mit dem Wert identifier definierst du den eindeutigen Bezeichner für das Profil. Am besten verwendest du hier einen möglichst kurzen Bezeichner wie a, b oder ps. Die Länge darf dabei zwischen einem und acht Zeichen sein und es sind nur Buchstaben erlaubt.
Der Wert retrieveMethod¶
Der Wert retrieveMethod konfiguriert die Abfragemethode für die Prozesse für das Profil. Dabei hast du die Wahl zwischen den folgenden Abfragemethoden:
Bezeichner |
Beschreibung |
|---|---|
|
Bei dieser Methode werden die Prozessdaten von dem installierten Process Monitor Agent service abgefragt. Das ist die beste Wahl und unsere empfohlene Abfragemethode. |
|
Hier wird das PowerShell |
|
Hier werden die Prozesse über die PowerShell mit der WMI Schnittstelle abgefragt. |
Die Agent Methode ist unsere empfohlene Abfragemethode. Dabei muss auf allen Computern den Agent service installiert werden. Diese Methode hat jedoch die beste Performance und ist im Vergleich mit den PowerShell methoden die zuverlässigste und Ressourcenschonendste. Die CPU Auslastung kann nur mit dieser Methode ermittelt werden.
Mit der Methode PowerShellNative werden PowerShell Remote Verbindungen zu den Computern aufgebaut und dort das Kommando Get-Process aufgerufen. Die Systeme müssen dabei bereits so konfiguriert sein, dass solche Remote-Aufrufe möglich sind. Zudem muss jeder Computer die Option -IncludeUserName des Get-Process Kommandos unterstützen. Die vielen Remote-Aufrufe verbrauchen sehr viele Ressourcen, daher ist diese Methode nur für sehr wenige abgefragte Computer geeignet.
Die PowerShellWMI Methode verwendet die WMI Schnittstelle über PowerShell um die Prozessdaten abzufragen. Sie funktioniert mit allen Windows Versionen, belastet die Ressourcen jedoch noch stärker als PowerShellNative.
Du kannst die Prozessdaten mit verschiedenen Methoden für verschiedene Server und Clients abfragen.
Der Wert authenticationUsername¶
Konfigurierst du den Optionalen Wert authenticationUsername, wird dieser Benutzername für die Anmeldung der Remote Verbindung verwendet. Dieser Benutzername wird nur für die Abfragemethoden PowerShellNative und PowerShellWMI verwendet.
Der Wert authenticationPassword¶
Wenn du einen Benutzernamen mit authenticationUsername konfiguriert hast, setzt du das dazugehörige Passwort mit dem Wert authenticationPassword.
Warnung
Speichere nie Passwörter in Klartext in der Konfiguration. Kodiere die Passwörter wie im Kapitel Kodieren von Passwörtern beschrieben.
Der Wert hostFile¶
Mit dem Wert hostFile definierst du den absoluten Pfad zu der Datei mit der Liste aller abgefragten Computern. Du findest alle Details zu der Datei im Kapitel Die Computer Datei.
Der Wert minimumPause¶
Der Wert minimumPause definiert die minimale Pause in Sekunden zwischen zwei Prozessabfragen. Diese Pause stellt sicher, dass die Prozessorbelastung auf den abgefragten Geräten gering bleibt. Gültige Werte sind eine bis 3600 Sekunden.
Der Wert retrieveInterval¶
Mit dem Wert retrieveInterval definierst du die Abstände in denen die Prozessliste von den Geräten abgefragt wird. Die Angabe ist in Sekunden.
Kleinere Werte erlauben eine präzisere Aufzeichnung der Prozessdaten, erhöhen aber die Belastung des Netzwerks und des Prozessors von jedem Abgefragten Gerät. Grössere Werte reduzieren die Gesamtbelastung, jedoch wird die Aufzeichnung weniger genau. Der default Wert von 30 Sekunden ist ein guter Richtwert, und du solltest ihn nur dann verändern, falls du gleichzeitig auch die Belastung des Netzwerks überwachst.
Der Wert minimumPause hat dabei immer die Priorität. Falls das Interval beispielsweise auf 30 Sekunden gesetzt ist, die minimale Pause auf 10 Sekunden. Dauert jetzt die abfrage aller Prozesse 25 Sekunden, ist das Interval effektiv 35 Sekunden, da in jedem Fall die 10 Sekunden Pause eingehalten werden.
Der Wert psServicePort¶
Mit diesem optionalen Wert kannst du den Port für den PowerShell Service ändern.
Der Wert historyDatabase¶
Mit dem Wert historyDatabase aktivierst du die Prozessaufzeichnung. Konfiguriere einen absoluten Pfad zu der Datenbankdatei. Diese Datei muss nicht existieren, sie wird automatisch erstellt.
Bemerkung
Die Datei für die Prozessaufzeichnung muss auf dem lokalen Dateisystem des Servers liegen.
Bei einem Update des Prozess Monitor Collectors, wird eine existierende Datenbank automatisch aktualisiert. Sicherheitshalber solltest du jedoch vor jedem Update ein Backup dieser Datenbank machen.
Der Wert filter¶
Mit dem optionalen Wert filter entfernst du Prozesseinträge von dem System und der Prozessaufzeichnung. Dabei muss dieser Wert entweder einen Pfad zu einer Filterdatei, oder den Filterausdruck selbst enthalten.
Alle details zu dem Format der Filterdatei, oder des Filterausdrucks findest du im Kapitel Filterausdrücke.
Die folgende Tabelle zeigt dir alle gültige Werte welche du in einem Filterausdruck verwenden kannst.
Name |
Typ |
Beschreibung |
|---|---|---|
|
Text |
Der Name des Computers auf dem der Prozess läuft. |
|
Zahl |
Die ID des Prozesses (PID). |
|
Text |
Der Name des Prozesses. Je nach Quelle kann dieser Name das Suffix |
|
Text |
Der absolute Pfad zum Prozess. |
|
Text |
Der Besitzer des Prozesses mit der Domäne. |
|
Zahl |
Die gesamt CPU Zeit in Millisekunden. |
|
Zahl |
Die Benutzer CPU Zeit in Millisekunden. |
|
Zahl |
Die aktuelle Grösse des Working Sets in bytes. |
|
Zahl |
Die aktuelle virtuelle Grösse in bytes. |
|
Zahl |
Die aktuelle relative Prozessorauslastung als Wert zwischen 0.0 und 1.0. Falls dieser Wert nicht verfügbar ist, wird er auf -1.0 gesetzt. |
Eingebetteter Filter¶
Das folgende vereinfachte Beispiel zeigt wie du einen Filter direkt in die Konfiguration einbetten kannst. Wichtig ist dabei, dass du die XML Beschreibung des Filters in die <![CDATA[ und ]]> Klammern einschliesst, sonst werden die Tags des Filters als Teil der Konfiguration angesehen.
<?xml version="1.0" encoding="UTF-8" ?>
<Configuration>
<Module name="Application">
...
<Value name="filter"><![CDATA[
<Value name="owner">
<Or>
<Contains caseSensitivity="CaseInsensitive">NT AUTHORITY</Contains>
<Contains caseSensitivity="CaseInsensitive">Window Manager</Contains>
<Contains caseSensitivity="CaseInsensitive">IIS APPPOOL</Contains>
<MatchesRegularExpression>^\\?$</MatchesRegularExpression>
</Or>
</Value>
]]></Value>
...
</Module>
...
</Configuration>
Filter in einer separaten Datei¶
Bei grossen Filtern lohnt es sich, diese in einer separaten Filterdatei zu definieren. Das folgende Beispiel zeigt dir, wie eine solche Filterdatei aufgebaut ist:
c:\Test\ProcessMonitorFilter.xml¶<?xml version="1.0" encoding="utf-8" ?>
<Filter
version="1"
xmlns="http://educateit.ch/software/FilterLanguage/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<And>
<Value name="owner">
<Or>
<Contains caseSensitivity="CaseInsensitive">NT AUTHORITY</Contains>
<Contains caseSensitivity="CaseInsensitive">Window Manager</Contains>
<Contains caseSensitivity="CaseInsensitive">IIS APPPOOL</Contains>
<MatchesRegularExpression>^\\?$</MatchesRegularExpression>
</Or>
</Value>
</And>
</Filter>
In der Konfiguration bindest du diesen Filter dann folgendermassen ein:
<?xml version="1.0" encoding="UTF-8" ?>
<Configuration>
<Module name="Application">
...
<Value name="filter">c:\Test\ProcessMonitorFilter.xml</Value>
...
</Module>
...
</Configuration>
Alle Details zu den Filtern findest du im Kapitel Filterausdrücke.
Der Wert applicationMap¶
Mit dem optionalen Wert applicationMap gibst du einen absoluten Pfad zu einer Datei mit einer Anwendungszuordnung an. Eine solche Datei enthält die Verbindung zwischen Prozesseigenschaften und einem Logischen Anwendungsnamen und Gruppe.
Einzelne Anwendungen können viele verschiedene Prozesse starten. Mit einer Anwendungszuordnung ordnest du diese Prozesse einer einzelnen logischen Anwendung zu. Mehrere Anwendungen kannst du zudem in Gruppen zusammenfassen.
In dem Process Monitor Client siehst du diese so zugeordneten Namen und Gruppen. Das macht es einem Administrator einfacher Prozesse korrekt zuzuordnen.
Das Format dieser Datei wird im Kapitel Filterausdrücke als Objektzuordnung erklärt. Siehe dazu Objektzuordnungen.
Falls kein Eintrag in der Anwendungszuordnung auf einen Prozess zutrifft, bleibt der Anwendungsname und die Gruppe leer. Du kannst dies verhindern, indem du ganz am Schluss einen Eintrag hinzufügst der auf jeden Prozess passt. Das folgende Beispiel zeigt einen solchen Eintrag:
<ObjectGroup name="Unknown">
<Object name="Unknown">
<Value name="name">
<MatchesRegularExpression>.*</MatchesRegularExpression>
</Value>
</Object>
</ObjectGroup>
Das folgende Beispiel zeigt eine komplette Objektzuordnung welche die Gruppe Common und zwei Applikationen definiert.
<?xml version="1.0" encoding="utf-8" ?>
<ObjectMap
version="1"
xmlns="http://educateit.ch/software/FilterObjectMap/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ObjectGroup name="Common">
<Object name="Explorer">
<Value name="name">
<Or>
<Matches caseSensitivity="CaseInsensitive">explorer.exe</Matches>
<Matches caseSensitivity="CaseInsensitive">explorer</Matches>
</Or>
</Value>
</Object>
<Object name="Citrix Receiver">
<Value name="path">
<Contains caseSensitivity="CaseInsensitive">\Citrix\Receiver\</Contains>
</Value>
</Object>
</ObjectGroup>
</ObjectMap>
Die Liste network¶
In der Liste network definierst du welche Netzwerkprotokolle unterstützt werden sollen. Jeder Eintrag in dieser Liste definiert ein einzelnes Protokoll.
Wenn ein Protokoll nicht in dieser Liste definiert ist, wird es deaktiviert. Das entspricht der Einstellung, wenn du den Wert scope auf None setzt.
Der Wert protocol¶
Mit dem Wert protocol wählst du das Protokoll das dieser Eintrag definiert. Die beiden folgenden Werte sind dabei möglich:
MessageHTTP
Das Protokoll Message ist das kompakte und schnelle, welches von dem Process Monitor Client und von anderen unserer Anwendungen verwendet wird.
Das Protokoll HTTP ist die offene HTTPS/JSON Schnittstelle, welche du für deine eigenen Skripte und externe Anwendungen verwenden kannst.
Der Wert port¶
Mit dem optionalen Wert port änderst du den default Port für ein Protokoll. Wenn du diesen Wert weglässt, werden die folgenden Ports für die Protokolle verwendet:
MessageProtokoll:17692HTTPProtokoll:17694
Der Wert scope¶
Mit dem Wert scope definierst du, woher Verbindungen für das Protokoll akzeptiert werden. Dabei kannst du einen der folgenden drei Einstellungen wählen:
|
Das Protokoll ist deaktiviert. |
|
Es werden nur Verbindungen von Localhost also vom eigenen Computer aus akzeptiert. |
|
Es werden Verbindungen von Überall akzeptiert. |
Mit dem Wert authorizedNetworks in der secrets Liste kannst du die Adressbereiche der akzeptierten Verbindungen weiter limitieren. Siehe dazu Der Wert authorizedNetworks.
Das folgende Beispiel zeigt wie die network Liste aussehen könnte:
<List name="network">
<ListEntry>
<Value name="protocol">HTTP</Value>
<Value name="scope">Any</Value>
</ListEntry>
<ListEntry>
<Value name="protocol">Message</Value>
<Value name="scope">Any</Value>
</ListEntry>
</List>
Der Wert sslProfile¶
Mit dem Wert sslProfile wählst du das Profil für die SSL Verbindung. Dabei gibst du den namen des Bezeichners an, den du im Modul SSL definierst. Alle Details dazu findest du im Kapitel Eigene SSL Zertifikate verwenden.
Um die eingebauten Zertifikate der alten Versionen zu verwenden, kannst du hier den Wert legacy angeben.
Die Liste secrets¶
Die Liste secrets konfiguriert wer auf die Prozessliste zugreifen kann. Dabei generierst du mit dem EducateIT Secret Generator Schlüsselpaare, welche für den Zugriff auf eine Schnittstelle oder Funktion benötigt werden.
Das Schlüsselpaar wird mit dem Secret Generator erstellt. Siehe dazu Das Secret System.
Der Client ist dabei immer die Software welche auf die Daten zugreifen möchte, beispielweise der Process Monitor Client. Der Server ist die Software welche die Daten anbietet, also der Process Monitor Collector.
Erstelle für jede Anwendung welche auf Daten des Process Monitor Collectors zugreift ein eigenes Schlüsselpaar. Zudem macht es Sinn auf der Client Seite das Secret zusätzlich zu kodieren, dieser Wert ist wie ein Passwort, daher solltest du ihn wie ein solches schützen. Siehe dazu Kapitel Kodieren von Passwörtern.
Zusätzlich zu dem Schlüsselpaar, kannst du den Zugriff mit einer Netzwerkliste einschänken. Wenn du also weist, dass ein Client sich immer aus dem Netzwerk 10.0.0.0/24 mit dem Server verbindet, kannst du diese Einschränkung mit dem Wert authorizedNetworks Konfigurieren. Wir empfehlen solche Einschränkungen falls möglich zu definieren.
Weiter kannst du für jeden individuellen Zugriff einen individuellen Prozessfilter definieren. Dieser wird zusätzlich zu allen bestehenden Filtern angewendet. So kannst du beispielsweise Supportmitarbeitern aus einem bestimmten Bereich nur zugang zu ihren eigenen Daten geben, auch wenn der Process Monitor Collector die Prozessdaten des gesamten Netzwerks sammelt.
Das folgenden Beispiel zeigt, wie eine solche secrets Liste aussehen kann. Die dabei verwendeten Werte bei key und secret sind bewusst fiktive Werte und funktionieren nicht.
<List name="secrets">
<ListEntry>
<Value name="label">Raptor Server</Value>
<Value name="key">fMAtR;8Gq_@pPai/7P827;ripX1ymYBx3Es;KZ;B.!X+oJsdv3PYVIv-Fupu]f}~</Value>
<Value name="secret">cx(5:K5(9siRU?+I:)6#5oK{Sc)GWiiSt/1/lWVY*k#H{Kx4g@I2qvOGR]xA08{2 O...</Value>
<Value name="authorizedNetworks">10.0.0.0/16 127.0.0.1/24</Value>
<Value name="authorizedServices">ReadProcessList</Value>
<Value name="authorizedProtocols">Message</Value>
</ListEntry>
<ListEntry>
<Value name="label">Client</Value>
<Value name="key">?1.RAf"|#:ZQj:Z62l-W_BjdoKh6KmF{35EU=_Q{N|qyaliRd+vU/-X97l!Q6,A9</Value>
<Value name="secret">_k:([%pW3IY@D_/vE$WvuT*w^FKT,t!:({/mQUf,%hEo1efkB@/JM07_C8tMiX9V d...</Value>
<Value name="authorizedServices">ReadProcessList</Value>
<Value name="authorizedProtocols">Message</Value>
</ListEntry>
<ListEntry>
<Value name="label">HttpApiAccess</Value>
<Value name="key">Ht-uu58NTP.sa}fMVB1sygNQ!azRJH1Ht7Vb-]QEI6rvsu!hT0zjZL{R!.!kmw2H</Value>
<Value name="secret">?tDC~p#+1[SD3MS:cpm/IH-rd@#krVnvbxS/ysPg1@8XfO+U'G#MX4^nw%=Wj$9p...</Value>
<Value name="authorizedServices">ReadProcessList</Value>
<Value name="authorizedProtocols">Http</Value>
<Value name="processFilter"><![CDATA[
<Value name="name">
<StartsWith>svc</StartsWith>
</Value>
]]></Value>
</ListEntry>
</List>
Der Wert label¶
Mit dem Wert label gibst du einem Eintrag einen Namen. Dieser taucht in den Logdateien auf, so dass du Fehlermeldungen oder Zugriffe einem Eintrag zuordnen kannst. Funktional hat dieser Wert keine Bedeutung.
Siehe dazu auch Kapitel Das Secret System.
Der Wert key¶
Der Wert key ist ein Teil des Schlüsselpaars, welches du mit dem EducateIT Secret Generator erstellst. Dieser Wert bildet der Schlüssel, welcher einen Zugang eindeutig identifiziert. Der Wert ist vergleichbar mit einem Benutzernamen.
Siehe dazu auch Kapitel Das Secret System.
Der Wert secret¶
Der Wert secret ist der zweite Teil des Schlüsselpaars, welches du mit dem EducateIT Secret Generator erstellst. Dieser Wert ist eine Prüfsumme („Hash“) des eigentlichen Werts welches du im Client konfigurierst. Es ist nicht ohne weiteres möglich von dem Server Secret auf das Client Secret zu schliessen. Trotzdem solltest du den Zugriff auf die Konfiguration so gut wie möglich limitieren.
Siehe dazu auch Kapitel Das Secret System.
Der Wert processFilter¶
Der optionale Wert processFilter schränkt die Prozesse ein, welche über diesen Eintrag abgefragt werden können. Lässt du diesen Wert weg, wird die Prozessliste nicht eingeschränkt.
Es handelt sich bei dem Wert um einen Filterausdruck. Du definierst den Filter genau wie unter Der Wert filter beschrieben. Dort findest du auch die Liste aller möglichen Werte welche im Filterausdruck verwendet werden können.
Der Wert removeProcessNameExtension¶
Mit dem optionalen Wert removeProcessNameExtension definierst du, ob Erweiterungen des Prozessnamens, wie .exe oder .com entfernt werden sollen. Lässt du diesen Wert weg, wird der default Yes verwendet, welcher die Erweiterungen entfernt.
Einzelne Quellen liefern den Prozessnamen mit der Erweiterung: Beispielsweise der Agent und PowerShell WMI Quelle. Falls du mehrere verschiedene Quellen verwendest, sind die Prozessnamen konsistenter.
Falls du nur Quellen verwendest, welche die Erweiterung zum Prozessnamen liefern, kannst du den Wert auf No setzen um diese Zusatzinformation zu verwenden.
Wir empfehlen diesen Wert wegzulassen oder auf Yes zu setzen.
Der Wert agentApiKey¶
Mit dem Wert agentApiKey setzt du den Schlüssel der für die Verbindung mit einem Agent auf einem Computer oder Server verwendet wird.
Um die Prozessliste bei einem Agent abzufragen, verbindet sich der Process Monitor Collector mit dem Agent. In dieser Situation ist der Process Monitor Collector der Client und der Agent ist der Server.
Erstelle für jeden Process Monitor Collector das auf Agents zugreift ein eigenes Schlüsselpaar und trage alle Schlüssel in der Agent Konfiguration ein.
Das Schlüsselpaar wird mit dem Secret Generator erstellt. Siehe dazu Das Secret System.
Der Wert agentApiSecret¶
Der Wert agentApiSecret konfiguriert das passende Secret zum Schlüssel für die Verbindung zu dem Agent. Kodiere dieses Secret wie im Kapitel Kodieren von Passwörtern beschrieben.
Das Schlüsselpaar wird mit dem Secret Generator erstellt. Siehe dazu Das Secret System.
Der Wert agentApiPort¶
Der optionale Wert agentApiPort ändert den Port, der für die Verbindung mit dem Agent verwendet wird. Lässt du diesen Wert weg, wird der default Port 17697 verwendet.
Probleme Finden¶
Im Kapitel Fehler Finden findest du einen kurzen Überblick, wie du Probleme lokalisieren kannst. Das Process Monitor Collector System unterstützt die folgenden Trace Sections:
|
Zeigt dir details bei Änderungen an der Computerdatei an. |
|
Zeigt zusätzliche Details zu Änderungen bei der Prozessaufzeichnung. |
|
Schreibt alle SQL Kommandos welche die Datenbank für die Prozessaufzeichnung modifizieren. |
|
Schreibt zusätzliche informationen zu die Kommunikation zwischen den Clients und dem Server. |
|
Zeigt zusätzliche Details zu dem empfangenen Prozessdaten an. |
|
Zeigt zusätzliche Details über die Prozessdaten welche im Speicher gehalten werden. |
Die Computer Datei¶
Die Computerdatei enthält alle Computernamen bei denen die Prozessliste abgefragt wird.
Grundlegendes Format¶
Es handelt sich dabei um eine einfache Textdatei, kodiert in UTF-8. Jede Zeile enthält dabei genau einen einzelnen Computernamen. Als Zeilenumbruch wird ein einzelnen Linefeed-Zeichen, aber auch die CR/LF Kombination von Microsoft Windows unterstützt.
Das folgende Beispiel zeigt eine einfache Computerdatei:
#
# This is an example file
#
example1
example2;b
example3;b
example4;a
Kommentare und Leerzeilen¶
Leere Zeilen sowie Zeilen welche mit dem #-Zeichen starten werden in dieser Datei komplett ignoriert. Damit kannst du Kommentare, wie Zeitstempel oder andere Diagnoseinformationen in die Datei schreiben.
Whitespace wird beim einlesen jeder Zeile entfernt. Eine Zeile ist daher eine Leerzeile, auch wenn sie Leerzeichen oder Tabulator-Zeichen enthält. Es spielt auch keine Rolle ob die Computereinträge oder Kommentare mit Leerzeichen starten oder enden.
example1
host2.example.com
192.168.100.90
Computereinträge¶
Jede Zeile welche nicht als Leerzeile oder Kommentar interpretiert wird ist ein Computereintrag. In der einfachsten Form ist dies eine IP-Adresse oder DNS Name eines Computers im Netzwerk. Whitespace am Anfang oder Ende der Zeile werden dabei entfernt.
Mit einem Semikolon ; hinter dem Computernamen kannst du ein anderes Profil, mit dessen Bezeichner wählen. Wichtig dabei, es darf kein Leerzeichen vor und nach dem Semikolon stehen.
Das folgende Beispiel zeigt einige Einträge mit verschiedenen Profil-Bezeichnern.
example1
example2;b
example3;b
example4;a
Der Eintrag example1 in der ersten Zeile enthält kein Profilbezeichner. In diesem Fall wird automatisch des erste definierte Profil verwendet.
In der zweiten und dritten Zeile wird für die Abfrage der Computer example2 und example3 das Profil b verwendet. Zum Schluss, in der vierten Zeile, wird für die Abfrage von Computer example4 das Profil a verwendet.
Automatische Aktualisierung¶
Wenn sich die Computerdatei ändert, wird sie automatisch neu geladen. Dazu überprüft das System die Zeit der letzten Modifikation der Datei. Ändert sich diese, wird die Datei neu geladen.
Bemerkung
Es ist wichtig, dass du die Datei nicht einfach überschreibst, sondern eine atomare Dateioperation verwendest. Sonst kann es passieren, dass nur die halbe Datei neu gelesen wird.
Eine atomare Dateioperation für die Datei hosts.txt könnte unter Windows folgendermassen ablaufen:
Erstelle die neue Computerliste als temporäre Datei
hosts.txt.tmp.Schreibe alle Computereinträge in diese neue Datei.
Benenne die existierende Datei
hosts.txtinhosts.txt.oldum.Benenne die temporäre Datei
hosts.txt.tmpinhosts.txtum.Lösche die alte Datei
hosts.txt.old.
