DE19743324A1 - Konfigurierungsverfahren für Datenverarbeitungsanlagen - Google Patents

Description

Technisches Gebiet

Die Erfindung betrifft ein Konfigurierungsverfahren für Datenverarbeitungsanlagen.

Stand der Technik

Viele Einrichtungen und Automaten, hier insbesondere Geldausgabe-Automaten, Service- und Auskunftsstationen, Buchungsautomaten, enthalten eine Datenverarbeitungsanla­ ge zur Steuerung. Vielfach wird, entsprechend der verfüg­ baren Computertechnik und -Leistung, diese aus einer an­ sonsten verwendbaren universellen Anlage wie einem Perso­ nal-Computer oder Arbeitsgruppen-Server abgeleitet und verwendet dessen Betriebssystem. Als Bedienoberfläche stehen Bildschirme mit den heutigen graphischen Möglich­ keiten zur Verfügung, die daher von Programmen bedient werden, die mit den Werkzeugen für die Erstellung von Programmen für beispielsweise Personal Computer erstellt werden. Daneben ist eine Anzahl von Programmen aktiv, die die spezielle Peripherie des Automaten bedienen und dar­ auf angepaßt werden müssen. Alle diese Programme benöti­ gen zu ihrem Betrieb Parameter- oder Konfigurationsdaten, die in der Datenverarbeitungsanlage gespeichert sind. Auch wenn diese im Format immer mehr einen gemeinsamen Standard annehmen, so ist doch sicherzustellen, daß die für den Betrieb notwendigen Parameter richtig eingestellt sind.

Diese Einstellung von Parametern wurde früher von einem Kundendienstmitarbeiter manuell bei Installation durchge­ führt bzw. bei Bedarf vor Ort aktualisiert. Bei einer Fehlfunktion wurde auch, kontrolliert durch die Erfahrung und Kenntnis der Person, nach eventuellen Fehlern ge­ sucht. Für die Installation eines Programms ist es daher seit längerem bekannt, diese durch ein weiteres Programm durchführen zu lassen, welches die Programmdateien auf das Zielsystem kopiert und die Parameterdateien einrich­ tet.

Ein solches Verfahren ist beispielsweise in der techni­ schen Referenz für die Microsoft Windows NT Workstation 4.0, Microsoft Press Deutschland 1996, ISBN 3-86063-240-X in Kapitel 2 beschrieben, bei dem im den Abschnitten "Installation von Anwendungen" und "Uniqueness Database Files (UDFs)" beschrieben ist, daß und wie zusätzliche Anwendungen installiert und für jede einzelne Anlage auch unterschiedlich konfiguriert werden können. Dabei ist je­ doch die Kenntnis der Parameternamen der einzelnen Anwen­ dungen notwendig. Bei Änderungen nach Betriebsbeginn ist keine Unterstützung vorhanden; diese sind entweder mit dem Konfigurationsprogramm der jeweiligen Komponente oder mit generellen Werkzeugen, hier dem Registrierungs-Editor oder einem Texteditor für die .INI-Dateien, durchzufüh­ ren.

Von der Free Software Foundation wird unter dem Namen "GNU CFENGINE" ein von Mark Burgess entwickeltes System zur Administration von Datenverarbeitungsanlagen bereit­ gestellt, welches auf Betriebssysteme nach dem POSIX-Stan­ dard bezogen ist. Die Version 1.4.1 dieser Software ist u. a. erreichbar über ftp://ftp.germany.eu.net//pub/packages/gnu/cfengine-1.4.1.tar.gz und über jeden anderen Mirror der "Free Software Foundation Inc.", 59 Temple Place - Suite 330, Boston, MA 02 111, USA. "CFENGINE" ist ein System zu Verwaltung eines Netzwerks von Datenverarbeitungsanlagen. Es wird eine spezielle Scriptsprache benutzt, um die Soll-Konfiguration einer Datenverarbeitungsanlage zu beschreiben. Die zugehörige Software wird durch diese Scriptsprache dahingehend ge­ steuert, daß die dort beschriebene Sollkonfiguration ein­ gestellt wird. Hierbei ist der Abschnitt "editfiles" von besonderer Bedeutung. Mit "editfiles" kann eine Anzahl von Dateien auf einen Sollstand gebracht werden. Die in CFENGINE vorgesehenen Kommandos erlauben es, eine Konfi­ gurations- oder Parameterdatei automatisch zu inspizieren und auf einen gewünschten Sollzustand zu bringen. Dies wird durch eine Anzahl von Kommandos, z. B. "AppendIfNoSuchLine", welches eine Zeile einfügt, wenn sie nicht vorhanden ist, erreicht werden. Hierbei wird ein erfahrener Systemverwalter vorausgesetzt, wie sich aus dem letzten Absatz des o.g. Abschnitts ergibt, in dem es heißt: "It is suggested that you use these editing functions with caution.".

Dabei geschieht eine Zuordnung von Parametern unter­ schiedlicher Anwendungen bzw. ihrer Programme und Parame­ terdateien über die Kenntnis des Systemverwalters, wel­ cher dahingehend informiert und ausgebildet sein muß, die jeweiligen Namen und Bezüge der Parameter untereinander zu kennen. Wird eine geänderte Software installiert, dann muß die Steuerdatei für CFENGINE entsprechend manuell ak­ tualisiert werden.

Ein weiteres Verfahren ist in dem Installationshandbuch "S.u.S.E. Linux 4.3" von B. Bauer u. a., Fürth 1996, ISBN 3-930419-31-9, beschrieben. Im Abschnitt 11.5 ab Seite 11-5 wird dargestellt, daß eine zentrale Konfigurations­ datei /etc/rc.config verwendet wird. Programmtechnisch wird dort eine Anzahl von Umgebungsvariablen gesetzt, die u. a. durch den nachfolgenden Aufruf von /sbin/SuSEconfig in andere Parameterdatei eingetragen werden, z. B. /etc/resolv.conf. Auch wenn eine veränderte und verein­ heitlichte Namensgebung der Parameter sowie eine Mehr­ fachverwendbarkeit der Parameter erreichbar ist, so ist die Anpassung an die jeweilige Komponente durch Anpassung des jeweiligen Skripts in der . ./init.d notwendig. Dieses wird jedoch in der Regel durch den Lieferanten der Sy­ stemsoftware vorgegeben, weswegen Änderungen darin zu Problemen bei der Wartung führen.

Es ist demgegenüber erstrebenswert, bei Kundeninstalla­ tionen von Datenverarbeitungsanlagen mit einer Anzahl miteinander verbundener Programme, die sich dem Kunden als eine einzige Anwendung darstellen, dem Betreuer des Kunden eine einfache Möglichkeit zu geben, Parameter an­ zupassen oder zu korrigieren, ohne dazu Detailkenntnisse in den Parameterdateien und verschiedene Varianten von Parameterdateien kennen zu müssen.

Darstellung der Erfindung

Die Erfindung geht von der Beobachtung aus, daß häufig Parameter von den jeweiligen Anwendungen bzw. Systemkom­ ponenten unterschiedlich bezeichnet werden, obwohl sie beim Betrieb des Systems gleich sein müssen. Die Erfin­ dung verwendet daher Definitionsdatei, in der die Parame­ ter der Systemkomponenten bezeichnet und lokalisiert sind sowie einen Namen derart bekommen, daß inhaltlich gleiche Parameter, auch wenn sie von den Systemkomponenten unter­ schiedlich bezeichnet und an unterschiedlichen Stellen abgelegt sind, eine einheitliche Bezeichnung erhalten. Diese Bezeichnung kann dann in der Terminologie und bezo­ gen auf das Einsatzfeld gewählt werden. Mittels dieser auf das Anwendungsfeld bezogenen Bezeichnungen legt dann der Anwender seine speziellen Parameter für das Gesamtsy­ stem fest und speichert sie in einer einzigen Konfigura­ tionsdatei. Unabhängig von dem Start des Systems, also auch im laufenden Betrieb, aktualisiert das Verfahren die Parameter der Systemkomponenten mittels der Definitions- und der Konfigurationsdatei. Durch dieses Vorgehen ist es auch einfach möglich, einen Probelauf durchzuführen, bei dem der Parameteraktualisierer protokolliert, welche Än­ derungen durchzuführen wären, ohne diese Änderungen je­ doch bereits durchzuführen.

Es handelt sich also um ein Verfahren zum Betrieb einer Datenverarbeitungsanlage mit einem Parameterabgleicher, der Sätze von Parametern von Systemkomponenten dadurch einstellt, daß eine Definitionsdatei die Parameter be­ zeichnet und eine Konfigurationsdatei die Parameter mit­ tels der Bezeichnung aus der Definitionsdatei bestimmt.

Kurzbeschreibung der Zeichnungen

Es zeigen

Fig. 1 die Anordnung der an dem Verfahren beteiligten Komponenten,

Fig. 2 die Verknüpfungen der Datenfelder.

Beschreibung eines Ausführungsbeispiels

In Fig. 1 ist schematisch einen Parameterabgleicher 10, der eine Definitionsdatei 12 und eine Konfigurationsdatei 14 bearbeitet. Aus den dort gespeicherten Daten werden eine oder mehrere Parameterdateien (16) erstellt.

Eine Parameterdatei ist eine Datei, in der mittels eines assoziativen Verfahrens, d. h. über Schlüssel adressiert, eine Anzahl von Werten gespeichert wird. Diese Werte die­ nen einem die Parameterdatei benutzenden Programm dazu, Ablaufparameter festzulegen. Eine solche Parameterdatei 16 ist in Fig. 2 schematisch als Tabelle dargestellt, bei der in der ersten Spalte ein Schlüssel A aufgeführt und in der zweiten Spalte die dazu gehörigen Werte E enthal­ ten sind. Es sind eine Anzahl verschiedener Arten be­ kannt, nach denen diese Parameter gespeichert werden. Dies sind in POSIX-Betriebssystemen die auch als .rc-Dateien bezeichneten Dateien, deren Dateinamen mit einem Punkt beginnt. In der graphischen Oberfläche Windows 3.x der Firma Microsoft werden dazu Dateien mit der Erweite­ rung ".INI" verwendet. Diese enthalten Abschnittsbezeich­ ner in eckigen Klammern und ansonsten, abgesehen von Kom­ mentar- oder Leerzeilen, je Zeile einen Parameter, wobei die Zeile mit einem Schlüsselwert beginnt, auf den ein Gleichheitszeichen und der gesetzte Wert folgt. Logisch liegt eine Baumstruktur vor, bei der der Dateiname die Wurzel darstellt, der Abschnitt einen nachfolgenden Kno­ ten bezeichnet, die Schlüssel die untersten Knoten und die Werte die Blätter darstellen. Entsprechend werden Pa­ rameter in dem Betriebssystem Windows NT auch in einer zentralen Datenbank gespeichert, wobei die Baumstruktur über die Syntax eines Schlüssels durch einen Punkt als Trenner dargestellt wird.

Die Strukturierung der Parameter als Baum ist zwar für den menschlichen Leser sehr hilfreich, aber für den tech­ nischen Gehalt der Erfindung von geringer Bedeutung. Da­ her wird in der Darstellung in Fig. 2 von einem lineari­ sierten Baum ausgegangen, bei dem im Schlüssel z. B. der absolute Name des Parameters vorhanden ist. Die Art der Speicherung, ob als Binärdatei oder in lesbarer Form, ob linerarisiert oder mit den Zugriff beschleunigenden Maß­ nahmen, kann entsprechend den jeweiligen Randbedingungen nach den sonstigen Anforderungen frei von dem die Erfin­ dung anwendenden Fachmann gewählt werden. Ob alle Parame­ ter in einer einzigen Datenbank gespeichert oder die obersten Blätter Dateinamen darstellen, ist von neben­ sächlicher Bedeutung für die Erfindung. Der Schlüssel A steht also symbolisch ggf. für die Bezeichnung des Para­ meters, sein Format und den Ort sowie die Art der Spei­ cherung.

In Fig. 2 sind die beteiligten Tabellen vereinfacht dar­ gestellt. Eine Parameterdatei 16 enthält eine Anzahl von, als Zeilen dargestellten, Parametern mit einem Schlüssel A und einem Wert E. Ferner ist eine Definitionsdatei 12 vorhanden, die logisch drei Spalten aufweist, nämlich ei­ nen Schlüssel A, eine Bezeichnung B und einen Standard­ wert C. Die Schlüssel sind dieselben wie in der Parame­ terdatei 16 verwendeten und daher in beiden mit A be­ zeichnet. Ferner ist eine Konfigurationsdatei 14 vorhan­ den, die konzeptionell zwei Spalten A und D aufweist. Die erste Spalte A enthält wieder einen Schlüssel aus dersel­ ben Gesamtheit wie die Spalten A der Parameterdatei 16 und der Definitionsdatei 12. Dem zugeordnet ist ein Soll­ wert D des jeweiligen durch den Schlüssel bezeichneten Parameters.

Das durch den Parameterabgleicher 10 realisierte Verfah­ ren geht von der Definitionsdatei aus. Diese wird zeilen­ weise bearbeitet und das Tripel aus Name A, Bezeichnung B und Standardwert C gelesen. Mittels des Namens A wird in der Parameterdatei 16 der Schlüssel A gesucht, durch den Pfeil 22 angedeutet, und der Wert E gelesen. Ist kein Eintrag mit dem Schlüssel A vorhanden, wird der Standard­ wert C als Wert E gesetzt und ansonsten mit dem jetzt ge­ setzten Wert E fortgefahren. Weiter wird die Bezeichnung B in der Konfigurationsdatei 14 gesucht, in Fig. 2 durch die Verbindung 21 symbolisiert. Wird die Bezeichnung B nicht gefunden, so wird in den weiteren Schritten der Wert C anstelle des Wertes D verwendet. Es kann programm­ technisch sinnvoll sein, Kopien der Dateien im Speicher zu halten und dort dann den nicht gefundenen Schlüssel B mit dem Wert D gleich dem Wert C nachzutragen. Es sei je­ doch darauf hingewiesen, daß der Parameterabgleicher we­ der die Definitionsdatei noch die Konfigurationsdatei verändert; lediglich die Parameterdatei 16 wird verän­ dert, gefunden, wird der Wert D mit dem Wert E vergli­ chen.

Dabei hat der Wert D Vorrang vor dem gespeicherten Wert E; d. h., es wird der Wert D in der Parameterdatei 16 ein­ getragen, wenn er von dem Wert E abweicht.

Man kann das Verhalten des Parameterabgleichers 10 auch so beschreiben: Setze den Wert E unter dem Schlüssel A in der Parameterdatei 16, wenn der Bezeichner B auch in der Konfigurationsdatei 14 gefunden wird. Sonst setze den Wert C unter dem Schlüssel A in die Parameterdatei.

Durch den Umweg über den Bezeichner B wird erreicht, daß die Schlüssel in der Konfigurationsdatei 14 frei und un­ abhängig von den Schlüsseln in der Parameterdatei 16 ge­ wählt werden können. Denn die letzteren werden von den Herstellern der Produkte, die die Parameterdatei 16 ver­ wenden, bestimmt. Die Definitionsdatei 12 wird von einem Fachmann erstellt, der die Produkte zusammenstellt und genaue Kenntnis der benötigten Parameter A hat. Die Kon­ figurationsdatei kann dann durch einen Anwender gewartet werden, der nun die veränderten, auf seine Terminologie angepaßten Bezeichner findet und nicht berücksichtigen muß, für welche Komponente der Wert D bestimmt ist.

Ferner ist es damit möglich, denselben Wert D, durch den Bezeichner B bestimmt, verschiedenen Parametern, durch den Schlüssel A bestimmt, zuzuordnen. Dies wird erreicht, indem die Bezeichnung B in der zweiten Spalte der Defini­ tionsdatei mehrfach auftaucht. Damit ist es möglich, wenn mehrere Komponenten denselben Parameter benötigen, aber unterschiedlich bezeichnen, dieselben in der Konfigurati­ onsdatei nur einmal aufzuführen.

Nicht in Fig. 2 gezeigt, kann die Definitionsdatei auch Angaben über die erlaubten Parameterwerte E aus der Kon­ figurationsdatei enthalten. Hier sind die üblichen Anga­ ben, wie sie in Plausibilitätsprüfungen verwendet werden, möglich, z. B. Wertebereiche für numerische Werte und der­ gleichen. Ist ein Sollwert D nicht unter den erlaubten Werten, dann wird an seiner Stelle der Standardwert C eingetragen. Gleiches gilt, wenn der eingetragene Wert E nicht zulässig ist. Dies kann geschehen, wenn der Anwen­ der mit anderen Mitteln den Parameterwert E verändert hat. Dabei kann eine Nachricht an einen Administrator mit den in dem jeweiligen Betriebssystem verfügbaren Mitteln, z. B. Mail oder "syslog", erfolgen. Auch die im folgenden beschriebene Protokolldatei kann diese Nachricht aufneh­ men.

Jede Änderung einer Parameterdatei 16 wird in der Proto­ kolldatei 20 vermerkt. Hier wird auch der bisherige Wert eingetragen. Damit ist es nicht nur möglich, die Änderun­ gen nachzuvollziehen. Wird in der, durch den Anwender ja veränderbaren, Konfigurationsdatei ein unzulässiger Wert gefunden, so wird im Falle einer Protokolldatei der bis­ herige Wert aus der Protokolldatei genommen, der wahr­ scheinlich bessere Ergebnisse als der Standardwert C aus der Definitionsdatei 12 liefert.

Da es recht aufwendig ist, aus der Protokolldatei den letzten erzeugten Stand zu rekonstruieren, ist in einer Weiterbildung der Erfindung eine Statusdatei 19 vorgese­ hen. In diese werden jeweils alle geänderten oder geprüf­ ten Werte aller betroffenen Parameterdateien 16 abgespei­ chert. Es werden also nicht sämtliche Parameter gesi­ chert, wie es z. B. bei der Registry in Windows NT vorge­ sehen ist, sondern nur diejenigen, die von dem Parameter­ abgleicher behandelt werden. Das läßt eine Sicherung auch auf Systemen wie "Windows for Workgroups" zu, bei denen eine Sicherung der Parameterdateien nicht vorgesehen ist. Ferner ist darin der letzte gesetzte bzw. geprüfte Wert vorhanden, so daß Änderungen durch den Benutzer mit Edi­ toren direkt in den Parameterdateien leicht rückgängig gemacht werden können.

In einer anderen Weiterbildung ist eine Steuerdatei 18 vorgesehen. In dieser wird die Abbildung des Schlüssels A aus der Definitionsdatei 12 auf die Parameterdatei 16 festgelegt. Je nach Betriebssystem sind alle Parameter in einer einzigen ("registry") Datenbank oder in mehreren Textdateien (".ini") gespeichert. Die Steuerungsdatei 18 benutzt einen weiteren indirekten Schritt, indem der Schlüssel A in der Definitionsdatei 12 in zwei Teile zer­ legt wird, von denen der erste über die Steuerdatei 18 behandelt und der zweite der letztendlich Schlüssel in der jeweiligen Parameterdatei 16 ist. Beispielsweise lau­ tet der Schlüssel A in der Definitionsdatei 12 "X25.CALL"; sein Wert, eine Zahl, ist hier ohne Bedeu­ tung. Mit dem Schlüssel "X25" wird in der Steuerdatei 18 gesucht und als Ergebnis, abhängig vom jeweiligen System, gefunden, daß entweder eine Datei "C:windowsx25.ini" im Windows-Textformat, oder eine ".ini" im OS/2 Binärformat, oder ein Abschnitt "HKEY/LOCAL_SYSTEM/SOFTWARE/NETWORK/PACKET/X25" in einer Registrierungs-Datenbank "registry" verwendet werden soll. Damit kann die Definitionsdatei 12 unabhängig vom jeweiligen System erstellt und gewartet werden. Das sich die Konfigurationsdatei 14 weiterhin auf die Schlüssel in der Definitionsdatei 12 bezieht, muß bei einem Wechsel des Betriebssystems lediglich die Steuerda­ tei mit ausgetauscht werden.

Bei einer Variante der Erfindung werden die Werte in fol­ gender Reihenfolge verprobt: Wert aus der Konfigurations­ datei; ursprünglicher Wert; Standardwert aus der Defini­ tionsdatei; Mittelwert oder Median bei einer geordneten Menge bzw. erster Wert bei einer nicht geordneten Menge der erlaubten Werte.

Claims (7)

1. Verfahren zum Betrieb einer Datenverarbeitungsanlage mit einer Anzahl von in der Regel miteinander verbun­ denen Systemkomponenten, die einen jeweiligen Satz von Parametern (16), die über ein oder mehrere dazu be­ stimmte Mittel in der Datenverarbeitungsanlage lesbar und schreibbar gespeichert sind, verwenden, mit den Merkmalen

• - ein Parameterabgleicher (10) aktualisiert Sätze von Parametern (16) von Systemkomponenten wie folgt:
  • - eine Definitionsdatei (12) enthält Tripel aus:
    • - Verweis (A) auf einen Parameter einer System­ komponente,
    • - Bezeichnung (B) des Parameters unabhängig von der Systemkomponente,
    • - Standardwert (C) des Parameters;
  • - eine Konfigurationsdatei (14) enthält Paare aus
    • - Bezeichnung (B) eines Parameters wie in der De­ finitionsdatei,
    • - Sollwert (D) des Parameters;
  • - wobei der Parameterabgleicher (10)
    • - einen Parameter einer Systemkomponente mittels der ersten Komponente (A) eines Tripels der De­ finitionsdatei (12) lokalisiert und ihn mit den dazu bestimmten Mitteln liest,
    • - den Parameter bei Vorhandensein eines Paares in der Konfigurationsdatei (14), dessen Bezeich­ nung (A) mit der Bezeichnung (A) in der Defini­ tionsdatei (12) übereinstimmt, auf den Sollwert (D) aus der Konfigurationsdatei (14), sonst auf den Standardwert (C) aus der Definitionsdatei (12) setzt,
    • - und den Parameter durch die dazu bestimmten Mittel schreibt, wenn der Wert nicht gleich dem gelesenen Wert ist.

2. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Verweis auf einen Parameter einer System­ komponente die Bezeichnung des Parameters, sein For­ mat und den Ort sowie die Art der Speicherung angibt.

3. Verfahren nach einem der vorhergehenden Ansprüche, wobei zusätzlich zum Standardwert ein Menge erlaubter Werte des Parameters in der Definitionsdatei angege­ ben sind und, sofern ein Wert nicht im erlaubten Wer­ tebereich liegt, ein erlaubter Wert eingesetzt wird und optional eine Nachricht an einen Adminstrator er­ zeugt wird.

4. Verfahren nach Anspruch 3, wobei die erlaubten Werte in folgender Reihenfolge verprobt werden: Wert aus der Konfigurationsdatei; ursprünglicher Wert; Stan­ dardwert aus der Definitionsdatei; Mittelwert oder Median bei einer geordneten Menge bzw. erster Wert bei einer nicht geordneten Menge der erlaubten Werte.

5. Verfahren nach einem der vorhergehenden Ansprüche, wobei jede Veränderung eines Parameters in einer Hi­ storiendatei (20) gespeichert wird und bei einem un­ zulässigen Parameter in der Konfigurationsdatei der früherer Wert aus der Historiendatei ermittelt und sodann verwendet wird.

6. Verfahren nach einem der vorhergehenden Ansprüche, wobei der jeweilige Stand der geänderten oder geprüf­ ten Parameter in einer Statusdatei 19 gespeichert wird und diese Werte anstelle einer Rekonstruktion mittels der Historiendatei (20) verwendet werden.

7. Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Steuerdatei vorgesehen ist, mit der der Verweis (A) der Definitionsdatei (21) dahingehend er­ gänzt bzw. umgesetzt wird, daß Lage, Art und ggf. ei­ ne Umbenennung der Schlüssel in Parameterdateien (16) bestimmt wird.