L'Object Data Manager : pourquoi la configuration des périphériques et du système AIX ne se trouve pas dans un fichier

Ce que c'est

L'Object Data Manager (ODM) est la base de données d'AIX pour la configuration du système et des périphériques. Ses classes d'objets sont stockées sous forme de fichiers dans /etc/objrepos (le répertoire ODM par défaut) et /usr/lib/objrepos, mais ces fichiers sont des magasins d'objets binaires, pas du texte à modifier directement : en corrompre un peut empêcher le fonctionnement de périphériques, de sous-systèmes, voire de SMIT lui-même. Les attributs des périphériques, la table des sous-systèmes du System Resource Controller (SRCsubsys) et de nombreux paramètres de niveau noyau (via le pseudo-périphérique sys0) sont tous des objets ODM.

L'interface prise en charge est un petit ensemble de commandes, et non un éditeur :

• lsattr -El <device> lit les attributs actuels d'un objet (également utilisée avec sys0 pour les paramètres valables pour tout le système).
• lsdev liste les objets périphériques et leur état.
• chdev modifie un attribut et réécrit le résultat dans l'ODM, en passant par la méthode du périphérique, qui met aussi à jour l'état du noyau en cours d'exécution lorsque c'est possible.
• odmget lit directement les classes d'objets de l'ODM et peut être utilisée sans risque pour l'inspection ; odmadd/odmchange/odmdelete les modifient et sont normalement réservées à des procédures documentées ou guidées par le support, pas à l'administration courante.

Pourquoi c'est important

Modifier à la main les fichiers de /etc/objrepos, ou les restaurer depuis un système sans rapport, contourne les contrôles de cohérence effectués par chdev/mkdev ; c'est une manière bien documentée de corrompre la configuration des périphériques. C'est le flux de travail pris en charge (lsattr/chdev/lsdev) qui garantit la cohérence entre l'ODM et l'état du noyau en cours d'exécution.

Certains attributs ne peuvent pas être modifiés sur un périphérique ouvert ou occupé — le cas classique étant le disque contenant rootvg. Pour ceux-ci, chdev -P écrit la nouvelle valeur uniquement dans l'ODM, sans toucher au périphérique en cours d'exécution, et la modification prend effet après le prochain redémarrage. Sans -P (comportement par défaut), chdev essaie d'appliquer la modification immédiatement en plus de l'enregistrer dans l'ODM.

Comment l'appliquer

• Inspecter avant de modifier : lsattr -El sys0 -a maxuproc affiche la valeur actuelle d'un seul attribut.
• Modifier immédiatement lorsque l'attribut le permet (en tant que root) : chdev -l sys0 -a maxuproc=4096. Tous les attributs de sys0 ne sont pas dynamiques — enhanced_RBAC, par exemple, ne prend effet qu'après un redémarrage.
• Pour un attribut d'un périphérique qui ne peut pas être fermé (par exemple un disque d'un groupe de volumes actif), ajouter -P et redémarrer à un moment planifié pour l'appliquer : chdev -P -l <device> -a <attr>=<value>, puis vérifier de nouveau avec lsattr une fois le redémarrage effectué.
• Ne jamais restaurer /etc/objrepos à partir de la sauvegarde d'une autre machine ; si l'on soupçonne une corruption de l'ODM, suivre plutôt la procédure de récupération documentée par IBM.

Pièges

• Oublier que -P seul n'applique pas la modification : il la met seulement en attente pour le prochain démarrage.
• Supposer que tous les attributs acceptent -P/-T (temporaire) ; tous les périphériques ne prennent pas en charge tous les modes.
• Contourner chdev avec un éditeur de texte sur les fichiers de l'ODM « juste cette fois » — il n'existe aucun moyen pris en charge de les modifier à la main sans risque.