El Object Data Manager: por qué la configuración de dispositivos y del sistema de AIX no está en un archivo

Qué es

El Object Data Manager (ODM) es la base de datos de AIX para la configuración del sistema y de los dispositivos. Sus clases de objetos residen como archivos bajo /etc/objrepos (el directorio ODM predeterminado) y /usr/lib/objrepos, pero esos archivos son almacenes de objetos binarios, no texto para editar directamente; corromper uno puede impedir que funcionen los dispositivos, los subsistemas o el propio SMIT. Los atributos de dispositivos, la tabla de subsistemas del System Resource Controller (SRCsubsys) y muchos ajustes de nivel de núcleo (a través del pseudodispositivo sys0) son todos objetos ODM.

La interfaz admitida es un pequeño conjunto de comandos, no un editor:

• lsattr -El <device> lee los atributos actuales de un objeto (también se usa contra sys0 para ajustes de todo el sistema).
• lsdev enumera los objetos de dispositivo y su estado.
• chdev cambia un atributo y escribe el resultado de vuelta en el ODM, pasando por el método de dispositivo que también actualiza el estado del núcleo en ejecución cuando es posible.
• odmget lee directamente las clases de objetos del ODM y es seguro para inspeccionar; odmadd/odmchange/odmdelete los escriben y normalmente se reservan para procedimientos documentados o guiados por soporte, no para la administración rutinaria.

Por qué importa

Editar a mano los archivos de /etc/objrepos, o restaurarlos desde un sistema sin relación, elude las comprobaciones de coherencia que realizan chdev/mkdev y es una forma bien documentada de corromper la configuración de dispositivos. El flujo de trabajo admitido (lsattr/chdev/lsdev) es lo que mantiene concordantes el ODM y el estado en ejecución del núcleo.

Algunos atributos no pueden cambiarse en un dispositivo que está abierto u ocupado; el caso clásico es el disco que aloja rootvg. Para esos casos, chdev -P escribe el nuevo valor solo en el ODM, sin tocar el dispositivo en ejecución, y el cambio surte efecto tras el siguiente reinicio. Sin -P (el valor predeterminado), chdev intenta aplicar el cambio de inmediato además de registrarlo en el ODM.

Cómo aplicarlo

• Inspeccionar antes de cambiar: lsattr -El sys0 -a maxuproc muestra el valor actual de un único atributo.
• Cambiar de inmediato donde el atributo lo permita (como root): chdev -l sys0 -a maxuproc=4096. No todo atributo de sys0 es dinámico: enhanced_RBAC, por ejemplo, solo surte efecto tras un reinicio.
• Para un atributo de un dispositivo que no puede cerrarse (por ejemplo, un disco en un grupo de volúmenes activo), añadir -P y reiniciar en un momento planificado para aplicarlo: chdev -P -l <device> -a <attr>=<value>, y luego verificar de nuevo con lsattr.
• No restaurar nunca /etc/objrepos desde la copia de seguridad de otra máquina; si se sospecha que el ODM está corrompido, trabajar en su lugar a partir del procedimiento de recuperación documentado por IBM.

Trampas

• Olvidar que -P por sí solo no aplica el cambio: solo lo pone en cola para el siguiente arranque.
• Asumir que todo atributo admite -P/-T (temporal); no todos los dispositivos admiten todos los modos.
• Eludir chdev con un editor de texto sobre los archivos del ODM «solo esta vez»: no existe una forma admitida de editarlos a mano de manera segura.