Der Object Data Manager: warum die Geräte- und Systemkonfiguration unter AIX nicht in einer Datei liegt

Worum es geht

Der Object Data Manager (ODM) ist die Datenbank von AIX für die System- und Gerätekonfiguration. Seine Objektklassen liegen als Dateien unter /etc/objrepos (dem Standardverzeichnis des ODM) und /usr/lib/objrepos. Diese Dateien sind jedoch binäre Objektspeicher und kein Text, der direkt bearbeitet werden soll; wird eine davon beschädigt, können Geräte, Subsysteme oder sogar SMIT selbst ausfallen. Geräteattribute, die Subsystemtabelle des System Resource Controllers (SRCsubsys) und viele Einstellungen auf Kernel-Ebene (über das Pseudogerät sys0) sind allesamt ODM-Objekte.

Unterstützte Schnittstelle ist eine kleine Gruppe von Befehlen, kein Editor:

• lsattr -El <device> liest die aktuellen Attribute eines Objekts (auch für sys0 zur Abfrage systemweiter Einstellungen).
• lsdev listet Geräteobjekte und ihren Zustand auf.
• chdev ändert ein Attribut und schreibt das Ergebnis in den ODM zurück. Dabei läuft der Aufruf über die Gerätemethode, die nach Möglichkeit auch den Zustand des laufenden Kernels aktualisiert.
• odmget liest ODM-Objektklassen direkt und ist für die Inspektion unbedenklich; odmadd/odmchange/odmdelete schreiben in diese Objektklassen und sind normalerweise dokumentierten oder vom Support begleiteten Verfahren vorbehalten, nicht der Routineadministration.

Warum es wichtig ist

Dateien unter /etc/objrepos von Hand zu bearbeiten oder von einem fremden System wiederherzustellen, umgeht die Konsistenzprüfungen von chdev/mkdev und ist ein gut dokumentierter Weg, die Gerätekonfiguration zu beschädigen. Der unterstützte Ablauf (lsattr/chdev/lsdev) hält ODM und laufenden Kernelzustand im Einklang.

Manche Attribute lassen sich bei einem geöffneten oder belegten Gerät nicht ändern; der klassische Fall ist die Platte mit rootvg. In solchen Fällen schreibt chdev -P den neuen Wert nur in den ODM, ohne das laufende Gerät anzutasten, und die Änderung greift nach dem nächsten Neustart. Ohne -P (Standardverhalten) versucht chdev, die Änderung sofort anzuwenden und zusätzlich im ODM festzuhalten.

So wird es angewendet

• Vor einer Änderung prüfen: lsattr -El sys0 -a maxuproc zeigt den aktuellen Wert eines einzelnen Attributs.
• Sofort ändern, sofern das Attribut es zulässt (als root): chdev -l sys0 -a maxuproc=4096. Nicht jedes sys0-Attribut ist dynamisch; enhanced_RBAC etwa wirkt erst nach einem Neustart.
• Bei einem Attribut eines Geräts, das sich nicht schliessen lässt (zum Beispiel eine Platte in einer aktiven Volume Group), -P ergänzen und die Änderung bei einem geplanten Neustart wirksam werden lassen: chdev -P -l <device> -a <attr>=<value>; anschliessend erneut mit lsattr verifizieren.
• /etc/objrepos nie aus dem Backup eines anderen Rechners wiederherstellen; bei Verdacht auf einen beschädigten ODM stattdessen nach dem dokumentierten Wiederherstellungsverfahren von IBM vorgehen.

Stolpersteine

• Vergessen, dass -P allein die Änderung nicht anwendet, sondern sie nur für den nächsten Systemstart vormerkt.
• Annehmen, jedes Attribut akzeptiere -P/-T (temporär); nicht alle Geräte unterstützen jeden Modus.
• chdev mit einem Texteditor auf ODM-Dateien «nur dieses eine Mal» umgehen; es gibt keinen unterstützten Weg, sie sicher von Hand zu bearbeiten.