EP1027646A1

EP1027646A1 - Konfigurierungsverfahren für datenverarbeitungsanlagen

Info

Publication number: EP1027646A1
Application number: EP98948814A
Authority: EP
Inventors: Ralph Rinschen
Original assignee: Wincor Nixdorf International GmbH
Current assignee: Wincor Nixdorf International GmbH
Priority date: 1997-09-30
Filing date: 1998-08-20
Publication date: 2000-08-16
Also published as: AU9531298A; DE19743324A1; WO1999017192A1; CN1272927A; JP2001518659A

Abstract

Verfahren zum Betrieb einer Datenverarbeitungsanlage mit einem Parameterabgleicher, der Sätze von Parametern von Systemkomponenten dadurch einstellt, dass eine Definitionsdatei die Parameter bezeichnet und eine Konfigurationsdatei die Parameter mittels der Bezeichnung aus der Definitionsdatei bestimmt.

Description

Konfigurierungsverfahren für Datenverarbeitungsanlagen

Techn-i sπhfis G hi et

Die Erfindung betrifft ein Konfigurierungsverfahren für Datenverarbeitungsanlagen .

S an der Technik

Viele Einrichtungen und Automaten, hier insbesondere Geldausgabe-Automaten, Service- und Auskunftsstationen, Buchungsautomaten, enthalten eine Datenverarbeitungsanlage zur Steuerung. Vielfach wird, entsprechend der verfüg- baren Computertechnik und -Leistung, diese aus einer ansonsten verwendbaren universellen Anlage wie einem Personal-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ötigen 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 durchgeführt bzw. bei Bedarf vor Ort aktualisiert. Bei einer Fehlfunktion wurde auch, kontrolliert durch die Erfahrung und Kenntnis der Person, nach eventuellen Fehlern gesucht. 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 einrichtet.

Ein solches Verfahren ist beispielsweise in der technischen 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 jedoch die Kenntnis der Parameternamen der einzelnen Anwendungen 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ühren.

Von der Free Software Foundation wird unter dem Namen "GNU CFENGINE" ein von Mark Burgess entwickeltes System zur Administration von Datenverarbeitungsanlagen bereitgestellt, welches auf Betriebsysteme nach dem POSIX- Standard 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 02111, 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 gesteuert, daß die dort beschriebene Sollkonfiguration eingestellt 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. "AppendlfNoSuchLine" , 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 unterschiedlicher Anwendungen bzw. ihrer Programme und Parameterdateien über die Kenntnis des Systemverwalters, welcher 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 aktualisiert 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 vereinheitlichte Namensgebung der Parameter sowie eine Mehrfachverwendbarkeit 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 .Systemsoftware vorgegeben, weswegen Änderungen darin zu Problemen bei der Wartung führen.

Es ist demgegenüber erstrebenswert, bei Kundeninstallationen 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. Systemkomponenten unterschiedlich bezeichnet werden, obwohl sie beim Betrieb des Systems gleich sein müssen. Die Erfindung verwendet daher Definitionsdatei, in der die Parameter der Systemkomponenten bezeichnet und lokalisiert sind sowie einen Namen derart bekommen, daß inhaltlich gleiche Parameter, auch wenn sie von den Systemkomponenten unterschiedlich 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 Gesamtsystem fest und speichert sie in einer einzigen Konfigurationsdatei. Unabhängig von dem Start des Systems, also auch im laufenden Betrieb, aktualisiert das Verfahren die Parameter der Systemkomponenten mittels der Definitionsund der Konfigurationsdatei. Durch dieses Vorgehen ist es auch einfach möglich, einen Probelauf durchzuführen, bei dem der Parameteraktualisierer protokolliert, welche Änderungen durchzuführen wären, ohne diese Änderungen jedoch 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 bezeichnet und eine Konfigurationsdatei die Parameter mittels 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.

Beschrel bυng eines Aus ϋhrungsbel spl l s

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 dienen 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 enthalten sind. Es sind eine Anzahl verschiedener Arten be- kannt, nach denen diese Parameter gespeichert werden. Dies sind in POSIX-Betriebssystemen die auch als .reDateien bezeichneten Dateien, deren Dateinamen mit einem Punkt beginnt. In der graphischen Oberfläche Windows 3.x der Firma Microsoft werden dazu Dateien mit der Erweiterung '.INI' verwendet. Diese enthalten Abschnittsbezeich- ner in eckigen Klammern und ansonsten, abgesehen von Kommentar- 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 Knoten 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 technischen Gehalt der Erfindung von geringer Bedeutung. Daher 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 Erfindung anwendenden Fachmann gewählt werden. Ob alle Parame- ter in einer einzigen Datenbank gespeichert oder die obersten Blätter Dateinamen darstellen, ist von nebensächlicher Bedeutung für die Erfindung. Der Schlüssel A steht also symbolisch ggf. für die Bezeichnung des Parameters, sein Format und den Ort sowie die Art der Spei- cherung. In Fig. 2 sind die beteiligten Tabellen vereinfacht dargestellt. 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 einen Schlüssel A, eine Bezeichnung B und einen Standardwert C. Die Schlüssel sind dieselben wie in der Parameterdatei 16 verwendeten und daher in beiden mit A bezeichnet. 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 derselben Gesamtheit wie die Spalten A der Parameterdatei 16 und der Definitionsdatei 12. Dem zugeordnet ist ein Sollwert D des jeweiligen durch den Schlüssel bezeichneten Parameters .

Das durch den Parameterabgleicher 10 realisierte Verfahren geht von der Definitionsdatei aus. Diese wird zeilenweise 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 Standardwert C als Wert E gesetzt und ansonsten mit dem jetzt gesetzten 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 programmtechnisch 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 jedoch darauf hingewiesen, daß der Parameterabgleicher weder die Definitionsdatei noch die Konfigurationsdatei verändert; lediglich die Parameterdatei 16 wird verän- dert . gefunden, wird der Wert D mit dem Wert E verglichen.

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 unabhängig von den Schlüsseln in der Parameterdatei 16 gewählt werden können. Denn die letzteren werden von den Herstellern der Produkte, die die Parameterdatei 16 verwenden, bestimmt. Die Definitionεdatei 12 wird von einem Fachmann erstellt, der die Produkte zusammenstellt und genaue Kenntnis der benötigten Parameter A hat. Die Konfigurationsdatei 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 Definitionsdatei 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 Konfigurationsdatei 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 dergleichen. 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 Anwender mit anderen Mitteln den Parameterwert E verändert hat. Dabei kann eine Nachricht an einen Administrator mit den in dem jeweiligen Betriebssytem verfügbaren Mitteln, z.B. Mail oder 'syslog', erfolgen. Auch die im folgenden beschriebene Protokolldatei kann diese Nachricht aufnehmen.

Jede Änderung einer Parameterdatei 16 wird in der Protokolldatei 20 vermerkt. Hier wird auch der bisherige Wert eingetragen. Damit ist es nicht nur möglich, die Änderungen nachzuvollziehen. Wird in der, durch den Anwender ja veränderbaren, Konfigurationsdatei ein unzulässiger Wert gefunden, so wird im Falle einer Protokolldatei der bisherige 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üften Werte aller betroffenen Parameterdateien 16 abgespeichert. Es werden also nicht sämtliche Parameter gesichert, wie es z.B. bei der Registry in Windows NT vorgesehen 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 zerlegt wird, von denen der erste über die Steuerdatei 18 behandelt und der zweite der letztendlich Schlüssel in der jeweiligen Parameterdatei 16 ist. Beispielsweise lautet der Schlüssel A in der Definitionsdatei 12 'X25.CALL'; sein Wert, eine Zahl, ist hier ohne Bedeutung. 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:\windows\x25.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 Steuerdatei mit ausgetauscht werden.

Bei einer Variante der Erfindung werden die Werte in folgender Reihenfolge verprobt: Wert aus der Konfigurations- datei; ursprünglicher Wert; Standardwert aus der Definitionsdatei; Mittelwert oder Mediän bei einer geordneten Menge bzw. erster Wert bei einer nicht geordneten Menge der erlaubten Werte .

Claims

Patentansprüche

1. Verfahren zum Betrieb einer Datenverarbeitungsanlage mit einer Anzahl von in der Regel miteinander verbundenen Systemkomponeten, die einen jeweiligen Satz von Parametern (16) , die über ein oder mehrere dazu bestimmte 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 Systemkomponente,

- 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 Definitionsdatei , - Sollwert (D) des Parameters;

* wobei der Parameterabgleicher (10)

- einen Parameter einer Systemkomponente mittels der ersten Komponente (A) eines Tripeis der Definitionsdatei (12) lokalisiert und ihn mit den dazu bestimmten Mitteln liest,

- den Parameter bei Vorhandensein eines Paares in der Konfigurationsdatei (14), dessen Bezeichnung (A) mit der Bezeichnung (A) in der Definitionsdatei (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 Systemkomponente die Bezeichnung des Parameters, sein Format 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 angegeben sind und, sofern ein Wert nicht im erlaubten Wertebereich liegt, ein erlaubter Wert eingesetzt wird und optional eine Nachricht an einen Adminstrator erzeugt 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 Mediän 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 unzulä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üften 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 ergänzt bzw. umgesetzt wird, daß Lage, Art und ggf. ei- ne Umbenennung der Schlüssel in Parameterdateien (16) bestimmt wird.