Capítulo 27 Administración de zonas de Solaris (descripción general)

Este capítulo abarca los siguientes temas generales sobre administración de zonas:

• Novedades de este capítulo

• Visibilidad y acceso a la zona global

• Visibilidad de ID de proceso en zonas

• Posibilidad de observación del sistema en las zonas

• Nombre de nodo de zona no global

• Sistemas de archivos y zonas no globales

• Redes en zonas no globales de IP compartida

• Solaris 10 8/07: redes en zonas no globales de IP exclusiva

• Uso de dispositivos en zonas no globales

• Ejecución de aplicaciones en zonas no globales

• Controles de recursos utilizados en zonas no globales

• Programador de reparto justo en un sistema Solaris con zonas instaladas

• Contabilidad ampliada en un sistema Solaris con zonas instaladas

• Privilegios en una zona no global

• Uso de arquitectura de seguridad IP en zonas

• Uso de auditorías de Solaris en zonas

• Archivos principales en zonas

• Cómo realizar copias de seguridad de un sistema Solaris con zonas instaladas

• Cómo determinar qué se debe guardar en una copia de seguridad en las zonas no globales

• Comandos utilizados en un sistema Solaris con zonas instaladas

Para obtener información sobre las zonas con marca lx, consulte la Parte III, Zonas con marca Lx .

Novedades de este capítulo

Solaris 10 1/06: Se ha incorporado una nueva sección, Cómo desmontar sistemas de archivos de zonas.

Solaris 10 1/06: Se han añadido nuevas secciones sobre los procedimientos de copia de seguridad y restauración de zonas. Consulte Cómo realizar copias de seguridad de un sistema Solaris con zonas instaladas.

Solaris 10 6/06: Se ha añadido una entrada ZFS a la tabla de Cómo montar sistemas de archivos en zonas.

Solaris 10 8/07: En esta versión se ha añadido o actualizado la siguiente información.

• Con esta versión, ahora hay disponibles dos tipos de IP para las zonas no globales. Se ha añadido información sobre las funciones disponibles por tipo de IP. Consulte Redes en zonas no globales de IP compartida y Solaris 10 8/07: redes en zonas no globales de IP exclusiva.

• Ahora se puede utilizar el filtro IP de Solaris en las zonas de IP compartida. Consulte Filtro IP de Solaris en zonas de IP compartida para obtener más información.

• Se ha revisado la información relativa a la configuración de los privilegios. Consulte la Tabla 27–1.

• Se ha actualizado la información de Comandos utilizados en un sistema Solaris con zonas instaladas.

Para ver una lista completa de las nuevas funciones de Solaris 10 y una descripción de las versiones de Solaris, consulte Novedades de Oracle Solaris 10 9/10.

Visibilidad y acceso a la zona global

La zona global es tanto la zona predeterminada para el sistema como la zona que se usa para el control administrativo de todo el sistema. Esta doble función plantea algunas cuestiones administrativas. Dado que las aplicaciones de la zona tienen acceso a los procesos y otros objetos del sistema en otras zonas, el efecto de las acciones administrativas puede ser mayor del esperado. Por ejemplo, las secuencias de cierre de servicios suelen utilizar el comando pkill para indicar a los procesos de un nombre concreto que deben cerrarse. Cuando se ejecuta una secuencia de este tipo desde la zona global, se señalarán todos estos procesos en el sistema, independientemente de la zona.

Con frecuencia se necesita el ámbito de todo el sistema. Por ejemplo, para supervisar el uso de recursos en todo el sistema, debe ver las estadísticas de los procesos de todo el sistema. La visualización de sólo la actividad de la zona global pasaría por alto información relevante de otras zonas del sistema que podrían estar compartiendo algunos o todos los recursos del sistema. Dicha visualización resulta especialmente importante cuando los recursos del sistema como la CPU no se particionan estrictamente utilizando las funciones de administración de recursos.

De este modo, los procesos de la zona global pueden observar los procesos y otros objetos de las zonas no globales. Esto permite que dichos procesos puedan observarse en todo el sistema. La posibilidad de controlar o enviar señales a procesos en otras zonas está limitada por el privilegio PRIV_PROC_ZONE. El privilegio es similar a PRIV_PROC_OWNER porque permite a los procesos modificar las restricciones que tienen los procesos sin privilegios. En este caso, la limitación es que los procesos sin privilegios en la zona global no pueden señalar ni controlar los procesos de otras zonas. Esto ocurre aunque coincidan los ID de usuario de los procesos o el proceso activo tenga el privilegio PRIV_PROC_OWNER. El privilegio PRIV_PROC_ZONE se puede eliminar de procesos que tengan otros privilegios para limitar las acciones a la zona global.

Para obtener información sobre la correspondencia de procesos mediante zoneidlist, consulte las páginas del comando man pgrep(1) y pkill(1).

Visibilidad de ID de proceso en zonas

Sólo los procesos de la misma zona estarán visibles a través de interfaces de llamadas del sistema que obtienen los ID de proceso, como los comandos kill y priocntl. Si desea más información, consulte las páginas del comando man kill(1) y priocntl(1).

Posibilidad de observación del sistema en las zonas

El comando ps se ha modificado del siguiente modo:

• La opción -o se utiliza para especificar el formato del resultado. Esta opción permite imprimir el ID de zona de un proceso o el nombre de la zona en la que se ejecuta el proceso.

• La opción -z lista_zona se utiliza para enumerar sólo los procesos en las zonas especificadas. Las zonas se pueden especificar por nombre o ID de zona. Esta opción sólo es útil cuando se ejecuta el comando en la zona global.

• La opción -Z se utiliza para imprimir el nombre de la zona asociada con el proceso. El nombre se imprime bajo el encabezado de la columna ZONE.

Si desea obtener más información, consulte la página de comando man ps(1).

Se ha añadido una opción -z nombre_zona a las siguiente utilidades de Solaris. Puede utilizar esta opción para filtrar la información de modo que incluya sólo la zona o las zonas especificadas.

• ipcs (consulte la página del comando man ipcs(1))

• pgrep (consulte la página del comando man pgrep(1))

• ptree (consulte la página del comando man proc(1))

• prstat (consulte la página del comando man prstat(1M))

Consulte la Tabla 27–5 para ver una lista completa de los cambios realizados en los comandos.

Nombre de nodo de zona no global

El administrador de zona puede configurar el nombre de nodo de /etc/nodename que devuelve uname - n. Debe ser un nombre exclusivo.

Sistemas de archivos y zonas no globales

En esta sección se proporciona información sobre las cuestiones relativas al sistema de archivos en un sistema Solaris con zonas instaladas. Cada zona tiene su propia sección de la jerarquía del sistema de archivos, en un directorio conocido como directorio root de la zona. Los procesos de la zona sólo pueden acceder a los archivos de la parte de la jerarquía que se encuentra en la raíz de la zona. La utilidad chroot se puede utilizar en una zona, pero únicamente para limitar el proceso a una ruta raíz dentro de la zona. Para más información sobre chroot, consulte chroot(1M).

La opción -o nosuid

La opción -o nosuid de la utilidad mount tiene la siguiente funcionalidad:

• Los procesos de un binario setuid situado en un sistema de archivos que se monta utilizando la opción nosetuid no se ejecutan con los privilegios del binario setuid. Los procesos se ejecutan con los privilegios del usuario que ejecuta el binario.

  Por ejemplo, si un usuario ejecuta un binario setuid que es propiedad de root, los procesos se ejecutan con los privilegios del usuario.

• No se permite abrir entradas especiales del dispositivo en el sistema de archivos. Este comportamiento es equivalente al que se obtiene con la especificación de la opción nodevices.

Esta opción específica del sistema de archivos está disponible para todos los sistemas de archivos de Solaris que se pueden montar con las utilidades mount, tal como se describe en la página del comando man mount(1M) En esta guía, estos sistemas de archivos se enumeran en Cómo montar sistemas de archivos en zonas. Asimismo, se describen las posibilidades de montaje. Para obtener más información sobre la opción -o nosuid, consulte el apartado sobre cómo acceder a los sistemas de archivos de red (referencia) de la System Administration Guide: Network Services .

Cómo montar sistemas de archivos en zonas

Cuando los sistemas de archivos se montan desde una zona, se aplica la opción nodevices. Por ejemplo, si la zona tiene acceso a un dispositivo de bloques (/dev/dsk/c0t0d0s7) y a un dispositivo básico (/dev/rdsk/c0t0d0s7) correspondiente a un sistema de archivos UFS, el sistema de archivos se monta automáticamente con nodevices cuando se monta desde una zona. Esta regla no se aplica a los montajes especificados a través de una configuración de zonecfg.

En la tabla siguiente se describen las opciones para montar sistemas de archivos en zonas no globales. Encontrará los procedimientos para estas alternativas de montaje en Configuración, verificación y confirmación de una zona y Cómo montar los sistemas de archivos en zonas no globales en ejecución.

Cualquier tipo de sistema de archivos que no se incluya en la tabla se puede especificar en la configuración si tiene un binario de montaje en /usr/lib/tipo_sistema_archivos/mount.

Para más información, consulte Cómo configurar la zona, Cómo montar los sistemas de archivos en zonas no globales en ejecución y la página del comando man mount(1M).

Cómo desmontar sistemas de archivos de zonas

La posibilidad de desmontar un sistema de archivos depende de quién haya realizado el montaje inicial. Si se especifica un sistema de archivos como parte de la configuración de la zona utilizando el comando zonecfg, la zona global es propietaria de este montaje y el administrador de zona de la zona no global no puede desmontar el sistema de archivos. Si el sistema de archivos está montado desde la zona no global, por ejemplo, especificando el montaje en el archivo /etc/vfstab de la zona, el administrador de zona de la zona no global puede desmontar el sistema de archivos.

Limitaciones de seguridad y comportamiento del sistema de archivos

Existen limitaciones de seguridad para el montaje de determinados sistemas de archivos dentro de una zona. Otros sistemas de archivos muestran un comportamiento especial cuando se montan en una zona. A continuación se incluye la lista de los sistemas de archivos modificados.

AutoFS

Autofs es un servicio de cliente que monta automáticamente el sistema de archivos apropiado. Cuando un cliente intenta acceder a un sistema de archivos que no está montado, el sistema de archivos AutoFS intercepta la solicitud y llama a automountd para montar el directorio solicitado. Los montajes de AutoFS establecidos en una zona son locales para esa zona. No es posible acceder a los montajes desde otras zonas, incluida la zona global. Los montajes se eliminan cuando se detiene o reinicia la zona. Para más información sobre AutoFS, consulte How Autofs Works de System Administration Guide: Network Services.

Cada zona ejecuta su propia copia de automountd. El administrador de zona controla las asignaciones y los tiempos de espera automáticos. No puede activar un montaje en otra zona cruzando un punto de montaje AutoFS para una zona no global desde la zona global.

Algunos montajes AutoFS se crean en el núcleo cuando se activa otro montaje. Dichos montajes no se pueden eliminar utilizando la interfaz de umount habitual porque deben montarse o desmontarse como grupo. Esta función se proporciona para el cierre de zonas.

MNTFS

MNTFS es un sistema de archivos virtual que proporciona acceso de sólo lectura a la tabla de sistemas de archivos montados para el sistema lógico. El conjunto de sistemas de archivos visibles utilizando mnttab desde una zona no global es el conjunto de sistemas de archivos montados en la zona, más una entrada para el root (/) . Los puntos de montaje con un dispositivo especial al que no se puede acceder desde la zona, como /dev/rdsk/c0t0d0s0, tienen su dispositivo especial configurado como el punto de montaje. Todos los montajes del sistema están visibles desde la tabla /etc/mnttab de la zona global. Para más información sobre MNTFS, consulte el Capítulo 18, Mounting and Unmounting File Systems (Tasks) de System Administration Guide: Devices and File Systems.

NFS

Los montajes de NFS establecidos en una zona son locales para esa zona. No es posible acceder a los montajes desde otras zonas, incluida la zona global. Los montajes se eliminan cuando se detiene o reinicia la zona.

Tal como se explica en la página del comando man mount_nfs(1M), un servidor NFS no debe intentar montar sus propios sistemas de archivos. Por tanto, una zona no debe montar con NFS un sistema de archivos exportado por la zona global. Las zonas no pueden ser servidores NFS. Dentro de una zona, los montajes NFS se comportan como si estuvieran montados con la opción nodevices.

El resultado del comando nfsstat sólo hace referencia a la zona en la que se ejecuta el comando. Por ejemplo, si el comando se ejecuta en la zona global, sólo se registra la información de la zona global. Para obtener más información sobre el comando nfsstat, consulte nfsstat(1M).

El comando zlogin fallará si alguno de sus archivos abiertos o cualquier parte de su espacio de dirección reside en NFS. Para más información, consulte Comando zlogin.

PROCFS

El sistema de archivos /proc, o PROCFS, proporciona visibilidad del proceso y limitaciones de acceso, así como información sobre la asociación de zonas de los procesos. Sólo los procesos de la misma zona están visibles a través de /proc.

Los procesos de la zona global pueden observar los procesos y otros objetos de las zonas no globales. Esto permite que dichos procesos puedan observarse en todo el sistema.

En la zona, los montajes de procfs se comportan como si estuvieran montados con la opción nodevices. Para más información sobre procfs, consulte la página del comando man proc(4).

LOFS

El ámbito de lo que se puede montar mediante LOFS está limitado a la parte del sistema de archivos que está visible para la zona. Por tanto, no hay limitaciones en los montajes de LOFS de una zona.

UFS, UDFS, PCFS y otros sistemas de archivos basados en almacenamiento

Cuando el administrador de zona utiliza el comando zonecfg para configurar los sistemas de archivos basados en almacenamiento que tienen un binario fsck, como UFS, debe especificar el parámetro raw. El parámetro indica el dispositivo básico (carácter), como /dev/rdsk/c0t0d0s7. zoneadmd ejecuta automáticamente el comando fsck en el modo de sólo comprobación no interactivo (fsck -m) en este dispositivo antes de montar el sistema de archivos. Si fsck falla, zoneadmd no puede colocar la zona en el estado de lista. La ruta especificada por raw no puede ser una ruta relativa.

Es erróneo especificar un dispositivo para fsck para un sistema de archivos que no proporciona un binario fsck en /usr/lib/ tipo_sistema_archivos/fsck. También es un error no especificar ningún dispositivo para fsck si existe un binario fsck para ese sistema de archivos.

Para obtener más información, consulte El daemon zoneadmd y fsck(1M)

ZFS

Puede añadir un conjunto de datos ZFS a una zona no global utilizando el comando zonecfg con el recurso add dataset. El conjunto de datos estará visible y se montará en la zona no global y dejará de estar visible en la zona global. El administrador de zona puede crear y destruir sistemas de archivos dentro de ese conjunto de datos, crear y destruir clones y modificar las propiedades del conjunto de datos.

El atributo zoned de zfs indica si se ha añadido un conjunto de datos a una zona no global.

# zfs get zoned tank/sales NAME PROPERTY VALUE SOURCE tank/sales zoned on local

Si desea compartir un conjunto de datos desde la zona global, puede añadir un sistema de archivos ZFS montado con LOFS utilizando el comando zonecfg con el subcomando add fs. El administrador global se encarga de configurar y controlar las propiedades del conjunto de datos.

Para más información sobre ZFS, consulte el Capítulo 10, Temas avanzados de Oracle Solaris ZFS de Guía de administración de Oracle Solaris ZFS.

Zonas no globales como clientes NFS

Las zonas pueden ser clientes NFS. Se admiten las versiones 2, 3 y 4 de los protocolos. Para obtener información sobre estas versiones de NFS, consulte Features of the NFS Service de System Administration Guide: Network Services

La versión predeterminada es NFS versión 4. Puede habilitar otras versiones de NFS en un cliente mediante uno de los métodos siguientes:

• Puede editar /etc/default/nfs para definir NFS_CLIENT_VERSMAX=número para que la zona utilice la versión especificada de modo predeterminado. Consulte Setting Up NFS Services de System Administration Guide: Network Services. Siga el procedimiento descrito en el apartado sobre cómo seleccionar diferentes versiones de NFS en un cliente modificando el archivo /etc/default/nfs en el mapa de tareas.

• Puede crear manualmente un montaje de la versión. Este método anula el contenido de /etc/default/nfs. Consulte Setting Up NFS Services de System Administration Guide: Network Services. Siga el procedimiento descrito en el apartado sobre cómo utilizar la línea de comandos para seleccionar diferentes versiones de NFS en un cliente en el mapa de tareas.

Prohibición del uso de mknod en una zona

No se puede utilizar el comando mknod descrito en la página del comando man mknod(1M) para crear un archivo especial en una zona no global.

Recorrido de sistemas de archivos

El espacio de nombre del sistema de archivos de una zona es un subconjunto del espacio de nombre al que se puede acceder desde la zona global. Para que los procesos que no tienen privilegios en la zona global no puedan recorrer la jerarquía del sistema de archivos de una zona no global:

• Especifique que sólo el root puede ser propietario, leer, escribir y ejecutar el directorio principal del root de la zona.

• Limite el acceso a los directorios exportados por /proc

Tenga en cuenta que cualquier intento de acceder a los nodos de AutoFS montados para otra zona será fallido. El administrador global no debe tener asignaciones automáticas que desciendan a otras zonas.

Limitación del acceso a una zona no global desde la zona global

Una vez instalada una zona no global, no se podrá acceder directamente a la zona desde la zona global mediante ningún comando que no sea de las utilidades de copia de seguridad del sistema. Además, una zona no global ya no puede considerarse segura una vez se ha expuesto a un entorno desconocido. Un ejemplo sería una zona colocada en una red de acceso público, en la que sería posible poner en peligro la zona y modificar el contenido de sus sistemas de archivos. Si existe la posibilidad de que se haya puesto en peligro, el administrador debe tratar la zona como zona que no es de confianza.

No se debe utilizar ningún comando que acepte una raíz alternativa utilizando las opciones -R o -b (o equivalentes) cuando se den las siguientes condiciones:

• El comando se ejecuta en la zona global.

• La raíz alternativa hace referencia a cualquier ruta raíz de una zona no global, tanto si es relativa a la zona global del sistema en ejecución o la zona global de una raíz alternativa.

Un ejemplo es la opción -R root_path de la utilidad pkgadd que se ejecuta desde la zona global con una ruta raíz de zona no global.

La lista de los comandos, programas y utilidades que hacen uso de -R con una ruta raíz alternativa incluye:

• auditreduce

• bart

• flar

• flarcreate

• installf

• localeadm

• makeuuid

• metaroot

• patchadd

• patchrm

• pkgadd

• pkgadm

• pkgask

• pkgchk

• pkgrm

• prodreg

• removef

• routeadm

• showrev

• syseventadm

La lista de los comandos y programas que utilizan -b con una ruta raíz alternativa incluye:

• add_drv

• pprosetup

• rem_drv

• roleadd

• sysidconfig

• update_drv

• useradd

Redes en zonas no globales de IP compartida

En un sistema Solaris con zonas instaladas, las zonas se pueden comunicar entre sí por la red. Todas las zonas tienen vínculos separados, o conexiones, y pueden ejecutar sus propios daemon de servidor. Estos daemons pueden escuchar a los mismos números de puerto sin que se produzca ningún conflicto. La pila IP resuelve los conflictos considerando las direcciones IP para las conexiones entrantes. Las direcciones IP identifican la zona.

Particiones de zonas de IP compartida

La pila IP de un sistema que admite zonas implementa la separación del tráfico de red entre zonas. Las aplicaciones que reciben tráfico IP sólo pueden recibir el tráfico que se envía a la misma zona.

Cada interfaz lógica del sistema pertenece a una zona específica, que es la zona global de modo predeterminado. Las interfaces de red lógicas asignadas a las zonas mediante la utilidad zonecfg se utilizan para las comunicaciones por la red. Cada flujo y conexión pertenece a la zona del proceso con el que se ha abierto.

Los vínculos entre los flujos de capa superior y las interfaces lógicas están limitados. Un flujo sólo puede establecer vínculos con las interfaces lógicas de la misma zona. Del mismo modo, los paquetes de una interfaz lógica sólo se pueden pasar a flujos de capa superior que se encuentren en la misma zona que la interfaz lógica.

Cada zona tiene su propio conjunto de vínculos. Cada zona puede ejecutar la misma aplicación que escucha el mismo número de puerto sin que los vínculos fallen porque la dirección ya está en uso. Cada zona puede ejecutar su propia versión de los siguientes servicios:

• Daemon de servicios de Internet con un archivo de configuración completo (consulte la página del comando man inetd(1M))

• sendmail (consulte la página del comando man sendmail(1M))

• apache (consulte la página del comando man apache(1M))

Las zonas que no sean la zona global tienen acceso limitado a la red. Están disponibles las interfaces de socket TCP y UDP estándar, pero las interfaces de socket SOCK_RAW están limitadas al Protocolo de mensajes de control de Internet (ICMP). Se necesita el protocolo ICMP para detectar y registrar las condiciones de error de la red o utilizar el comando ping.

Interfaces de red de IP compartida

Cada zona no global que requiere conectividad de red tiene una o más direcciones IP dedicadas. Estas direcciones están asociadas con interfaces de red lógicas que se pueden colocar en una zona utilizando el comando ifconfig. Las interfaces de red de la zona que configure el comando zonecfg se configurarán y colocarán automáticamente en la zona cuando se inicie. El comando ifconfig se puede utilizar para añadir o eliminar interfaces lógicas cuando la zona está en ejecución. Sólo el administrador global puede modificar la configuración de la interfaz y las rutas de red.

En una zona no global, sólo las interfaces de la zona estarán visibles para ifconfig.

Si desea más información, consulte las páginas del comando man ifconfig(1M) y if_tcp(7P).

Tráfico IP entre zonas de IP compartida en el mismo equipo

Sólo se admite la entrega de paquetes entre dos zonas del mismo equipo si hay una "ruta coincidente" para el destino y la zona en la tabla que realiza el envío.

La información de coincidencia se implementa del modo siguiente:

• La dirección de origen para los paquetes se selecciona en la interfaz de salida especificada por la ruta coincidente.

• De modo predeterminado, se admite el tráfico entre dos zonas que tienen direcciones en la misma subred. La ruta coincidente en este caso es la ruta de la interfaz para la subred.

• Si hay una ruta predeterminada para una zona concreta, en la que el portal se encuentra en una de las subredes de la zona, se permite el tráfico de dicha zona a todas las demás. En este caso, la ruta coincidente es la ruta predeterminada.

• Si hay una ruta coincidente con el indicador RTF_REJECT, los paquetes activan un mensaje ICMP inaccesible. Si hay una ruta coincidente con el indicador RTF_BLACKHOLE, los paquetes se descartan. El administrador puede utilizar las opciones del comando route que se describen en la siguiente tabla para crear rutas con estos indicadores.

  Modificador	Flag	Descripción
  -reject	RTF_REJECT	Emite un mensaje ICMP inaccesible cuando hay coincidencia.
  -blackhole	RTF_BLACKHOLE	Descarta silenciosamente los paquetes durante las actualizaciones.

  Para más información, consulte route(1M)

Filtro IP de Solaris en zonas de IP compartida

El filtro IP de Solaris proporciona un filtrado de paquetes con estado y traducción de direcciones de red (NAT). Un filtro de paquetes con estado puede supervisar el estado de las conexiones activas y utilizar la información obtenida para determinar qué paquetes de red se permiten a través del cortafuegos. El filtro IP de Solaris también incluye filtrado de paquetes sin estado y la posibilidad de crear y administrar agrupaciones de direcciones. Consulte el Capítulo 25, Filtro IP de Oracle Solaris (descripción general) de Guía de administración del sistema: servicios IP para obtener información adicional.

El filtro IP de Solaris se puede activar en las zonas no globales activando el filtrado en bucle tal como se describe en el Capítulo 26, Filtro IP de Oracle Solaris (tareas) de Guía de administración del sistema: servicios IP.

El filtro IP de Solaris se deriva de software de filtro IP de código abierto.

Múltiples rutas de redes IP en zonas de IP compartida

Las múltiples rutas de redes IP (IPMP) detectan los fallos en la interfaz física y conmutan por error el acceso a la red de forma transparente para un sistema con varias interfaces en el mismo vínculo IP. IPMP también permite repartir la carga de los paquetes para los sistemas con varias interfaces.

Toda la configuración de la red se lleva a cabo en la zona global. Puede configurar IPMP en la zona global, y luego ampliar la funcionalidad a las zonas no globales. La funcionalidad se amplía colocando la dirección de la zona en un grupo IPMP cuando configura la zona. A continuación, si falla una de las interfaces de la zona global, las direcciones de la zona no global se migrarán a otra tarjeta de interfaz de red. Una zona de IP compartida puede tener varias direcciones IP, puede formar parte de varios grupos IPMP, y varias zonas de IP compartida pueden utilizar un determinado grupo IPMP.

En una zona no global determinada, a través del comando ifconfig sólo se pueden ver las interfaces asociadas con la zona.

Consulte Cómo ampliar la funcionalidad de múltiples rutas de redes IP a las zonas no globales de IP compartida. El procedimiento de configuración de las zonas se describe en Cómo configurar la zona. Para obtener información sobre los componentes, el uso y las funciones de IPMP, consulte el Capítulo 30, Introducción a IPMP (descripción general) de Guía de administración del sistema: servicios IP.

Solaris 10 8/07: redes en zonas no globales de IP exclusiva

Una zona de IP exclusiva tiene sus propias variables de configuración y su estado relativos a la IP. La zona tiene asignado su propio conjunto de vínculos de datos cuando se configura.

Para obtener información sobre las funciones que se pueden utilizar en una zona no global de IP exclusiva, consulte Solaris 10 8/07: zonas no globales de IP exclusiva. Si desea información sobre la configuración de las variables IP ndd, consulte Oracle Solaris Tunable Parameters Reference Manual .

Particiones de zonas de IP exclusiva

Las zonas de IP exclusiva tienen pilas TCP/IP separadas, de modo que la separación alcanza a la capa del vínculo de datos. El administrador global asigna uno o más nombres de vínculos de datos, que pueden ser NIC o una VLAN en NIC, a una zona de IP exclusiva. El administrador de zona puede configurar la IP en dichos vínculos de datos con las mismas opciones y flexibilidad que en la zona global.

Interfaces de vínculos de datos de IP exclusiva

Debe asignarse un nombre de vínculo de datos a una única zona de forma exclusiva.

El comando dladm show-link puede utilizarse para visualizar los vínculos de datos asignados a las zonas en ejecución.

Para mas información, consulte dladm(1M)

Tráfico IP entre zonas de IP exclusiva en el mismo equipo

No hay bucles internos de paquetes IP entre las zonas de IP exclusiva. Todos los paquetes se envían al vínculo de datos. Normalmente, esto significa que los paquetes se envían en una interfaz de red. A continuación, los dispositivos como los conmutadores Ethernet o enrutadores IP pueden enviar paquetes a su destino, que podría ser una zona diferente del mismo equipo que el remitente.

Filtro IP de Solaris en zonas de IP exclusiva

La funcionalidad del filtro IP es la misma que en la zona global de una zona de IP exclusiva. El filtro IP también se configura del mismo modo en las zonas de IP exclusiva y en la zona global.

Múltiples rutas de redes IP en zonas de IP exclusiva

Las múltiples rutas de redes IP (IPMP) detectan los fallos en la interfaz física y conmutan por error el acceso a la red de forma transparente para un sistema con varias interfaces en el mismo vínculo IP. Además de la tolerancia a fallos, IPMP también proporciona propagación de carga de paquetes para los sistemas con varias interfaces.

La configuración de vínculos de datos se lleva a cabo en la zona global. En primer lugar, se asignan varias interfaces de vínculos de datos a una zona utilizando zonecfg. Las diferentes interfaces de vínculos de datos deben conectarse a la misma subred IP. A continuación, el administrador de zona puede configurar IPMP desde una zona de IP exclusiva. Es posible asignar varios grupos IPMP a una determinada zona de IP exclusiva, pero estos grupos IPMP no se pueden compartir con otras zonas.

Uso de dispositivos en zonas no globales

El conjunto de dispositivos disponible en la zona está limitado para evitar que un proceso de una zona interfiera con la ejecución de procesos en otras zonas. Por ejemplo, un proceso de una zona no puede modificar la memoria del núcleo o el contenido del disco raíz. Por tanto, sólo hay disponibles algunos pseudodispositivos que se consideran seguros para utilizar en una zona de modo predeterminado. Pueden ponerse a disposición dispositivos adicionales en zonas específicas utilizando el comando zonecfg.

/dev y el espacio de nombres /devices

El sistema Solaris utiliza el sistema de archivos devfs que se describe en la página del comando man devfs(7FS) para administrar /devices. Cada elemento de este espacio de nombres representa la ruta física a un dispositivo de hardware, pseudodispositivo o dispositivo de nexo. El espacio de nombres es un reflejo del árbol de dispositivos. Como tal, el sistema de archivos se completa mediante una jerarquía de directorios y archivos de dispositivos especiales.

La jerarquía de archivos /dev, que actualmente forma parte del sistema de archivos / (raíz), se compone de vínculos simbólicos, o rutas lógicas, a las rutas físicas que hay en /devices. Las aplicaciones hacen referencia a la ruta lógica de un dispositivo presentado en /dev. El sistema de archivos /dev se monta en bucle en la zona utilizando un montaje de sólo lectura.

La jerarquía de archivos /dev se administra mediante un sistema que se compone de:

• devfsadm (consulte la página del comando man devfsadm(1M))

• syseventd (consulte la página del comando man syseventd(1M))

• Biblioteca de información de dispositivos libdevinfo (consulte la página del comando man libdevinfo(3LIB))

• Controlador devinfo (consulte la página del comando man devinfo(7D))

• Gestor de coordinación de reconfiguración (RCM) (consulte Reconfiguration Coordination Manager (RCM) Script Overview de System Administration Guide: Devices and File Systems)

Los subsistemas que dependen de nombres de ruta /devices no pueden ejecutarse en zonas no globales hasta que se establezcan los nombres de ruta /dev.

Dispositivos de uso exclusivo

Quizá tenga dispositivos que desee asignar a zonas específicas. Si se permite a los usuarios sin privilegios acceder a los dispositivos de bloques, éstos se podrían utilizar para crear una situación crítica del sistema, reiniciar el bus u otras acciones malintencionadas. Antes de realizar tales asignaciones, tenga en cuenta lo siguiente:

• Antes de asignar un dispositivo de cintas SCSI a una zona específica, consulte la página del comando man sgen(7D).

• Si se coloca un dispositivo físico en más de una zona, puede crearse un canal oculto entre las zonas. Las aplicaciones de zonas globales que utilizan dichos dispositivos pueden provocar que una zona no global dañe los datos o los ponga en peligro.

Administración de controladores de dispositivos

En una zona no global, puede utilizar el comando modinfo que se describe en la página del comando man modinfo(1M) para examinar la lista de módulos de núcleo cargados.

La mayoría de las operaciones relativas a la administración del núcleo, los dispositivos y las plataformas no funcionan dentro de una zona no global porque la modificación de las configuraciones del hardware de la plataforma va en contra del modelo de seguridad de la zona. Estas operaciones incluyen:

• Añadir y eliminar controladores

• Cargar y descargar módulos de núcleo de forma explícita

• Iniciar operaciones de reconfiguración dinámica (DR)

• Utilizar funciones que afectan al estado de la plataforma física

Utilidades que no funcionan o se han modificado en las zonas no globales

Utilidades que no funcionan en zonas no globales

Las utilidades siguientes no funcionan en una zona porque dependen de dispositivos que normalmente no están disponibles:

• Cdrecord (consulte la página de comando man en el directorio /usr/share/man/man1. )

• cdrw (consulte la página de comando man cdrw(1))

• rmformat (consulte la página de comando man rmformat(1))

• add_drv (consulte la página de comando man add_drv(1M))

• disks (consulte la página de comando man disks(1M))

• prtconf (consulte la página del comando man prtconf(1M))

• prtdiag (consulte la página del comando man prtdiag(1M))

• rem_drv (consulte la página de comando man rem_drv(1M))

SPARC: utilidad modificada para utilizar en una zona no global

La utilidad eeprom permite ver la configuración en una zona. No obstante, no puede utilizarse para cambiar la configuración. Si desea más información, consulte las páginas del comando man eeprom(1M) y openprom(7D).

Ejecución de aplicaciones en zonas no globales

En general, todas las aplicaciones pueden ejecutarse en una zona no global. Sin embargo, es posible que los siguientes tipos de aplicaciones no sean adecuados para este entorno:

• Aplicaciones que utilizan operaciones con privilegios que afectan al sistema en general. Algunos ejemplos incluyen operaciones que configuran el reloj del sistema global o bloquean la memoria física.

• Las pocas aplicaciones que dependen de ciertos dispositivos que no existen en una zona no global, como /dev/kmem.

• Aplicaciones que esperan poder escribir en /usr, durante la ejecución o mientras se instalan, actualizan o se les aplica un parche. Esto se debe a que, de modo predeterminado, /usr es de sólo lectura para una zona no global. En ocasiones, los problemas asociados con este tipo de aplicación se pueden mitigar sin necesidad de cambiar la aplicación.

• En una zona de IP compartida, las aplicaciones que dependen de dispositivos de /dev/ip.

Controles de recursos utilizados en zonas no globales

Para obtener información adicional sobre el uso de una función de administración de recursos en una zona, consulte también el capítulo en el que se describe la función en la parte 1 de esta guía.

Todos los atributos y controles de recursos que se describen los capítulos relativos a la administración de recursos se pueden configurar en el servicio de directorios LDAP, la asignación NIS y el archivo /etc/project de la global y la zona no global. Esta configuración para una zona concreta sólo afecta a dicha zona. Un proyecto que se ejecuta de forma autónoma en diferentes zonas puede tener los controles configurados de forma individual para cada zona. Por ejemplo, el proyecto A de la zona global se puede configurar como project.cpu-shares=10 mientras que el proyecto A de una zona no global se puede configurar como project.cpu-shares=5. Es posible ejecutar varias instancias de rcapd en el sistema; cada una de ellas funciona sólo en su zona.

Los atributos y controles de recursos que se utilizan en una zona para controlar los proyectos, tareas y procesos de esa zona están sujetos a los requisitos adicionales sobre las agrupaciones y los controles de recursos de la zona.

En todas las zonas no globales se aplica una regla de "una agrupación por zona". Varias zonas no globales pueden compartir los recursos de una agrupación. No obstante, los procesos de la zona global pueden estar vinculados por un proceso con suficientes privilegios a cualquier agrupación. El controlador de recursos poold sólo se ejecuta en la zona global, en la que hay más de una agrupación en la que puede funcionar. Si la utilidad poolstat se ejecuta en una zona no global muestra sólo información sobre la agrupación asociada con la zona. El comando pooladm ejecutado sin argumentos en una zona no global muestra sólo información sobre la agrupación asociada con la zona.

Los controles de recursos de la zona no surten efecto si se configuran en el archivo project. Los controles de recursos de la zona se configuran mediante la utilidad zonecfg.

Programador de reparto justo en un sistema Solaris con zonas instaladas

En esta sección se describe cómo utilizar el programador de reparto justo (FSS) con zonas.

División de recursos compartidos de FSS en una zona no global

Los recursos compartidos de la CPU de FSS de una zona son jerárquicos. El administrador global configura los recursos compartidos de la zona global y las zonas no globales mediante el control de recursos de la zona zone.cpu-shares. El control de recursos project.cpu-shares se puede definir para cada proyecto en la zona para subdividir aún más los recursos compartidos configurados con el control de la zona.

Para asignar recursos compartidos de la zona utilizando el comando zonecfg, consulte Cómo configurar zone.cpu-shares en la zona global. Para mas información sobre project.cpu-shares, consulte Controles de recursos disponibles. Consulte también Uso del programador de reparto justo en un sistema Solaris con zonas instaladas para ver algunos procedimientos de ejemplo que muestran cómo configurar temporalmente los recursos compartidos.

Equilibrio compartido entre zonas

Puede utilizar zone.cpu-shares para asignar recursos compartidos de FSS en la zona global y las zonas no globales. Si FSS es el programador predeterminado en el sistema y no hay recursos compartidos asignados, de modo predeterminado se asigna un recurso compartido a cada zona, incluida la zona global. Si tiene una zona no global en el sistema y le asigna dos recursos compartidos mediante zone.cpu-shares, se define la proporción de CPU que recibirá la zona no global en relación con la zona global. La proporción de la CPU entre dos zonas es de 2:1.

Contabilidad ampliada en un sistema Solaris con zonas instaladas

El subsistema de contabilidad ampliada recopila y registra la información para todo el sistema (incluidas las zonas no globales) cuando se ejecuta en la zona global. El administrador global también puede determinar el consumo de recursos por zonas.

El subsistema de contabilidad ampliada permite diferentes archivos y configuraciones de cuentas por zona para las cuentas basadas en procesos y tareas. Los registros de exacct se pueden etiquetar con el nombre de zona EXD PROC ZONENAME para los procesos y el nombre de zona EXD TASK ZONENAME para las tareas. Los registros de cuentas se realizan en los archivos de cuentas de la zona global, así como en los archivos de cuentas de cada zona. Los registros de EXD TASK HOSTNAME, EXD PROC HOSTNAME y EXD HOSTNAME contienen el valor uname -n para la zona en la que se ha ejecutado el proceso o la tarea, en lugar del nombre de nodo de la zona global.

Para obtener información sobre las cuentas de flujo IPQoS, consulte el Capítulo 36, Uso de control de flujo y recopilación de estadísticas (Tareas) de Guía de administración del sistema: servicios IP.

Privilegios en una zona no global

Los procesos se limitan a un subconjunto de privilegios. La limitación de privilegios impide que una zona lleve a cabo operaciones que podrían afectar a otras zonas. El conjunto de privilegios limita las funciones de los usuarios con privilegios en la zona. La utilidad ppriv permite ver la lista de los privilegios disponibles en una zona.

La tabla siguiente enumera todos los privilegios de Solaris y el estado de cada privilegio con respecto a las zonas. Los privilegios opcionales no forman parte del conjunto de privilegios predeterminado, pero se pueden especificar con la propiedad limitpriv. Los privilegios necesarios deben incluirse en el conjunto de privilegios resultante. Los privilegios prohibidos no se pueden incluir en el conjunto de privilegios resultante.

La propiedad limitpriv está disponible a partir de Solaris 10 11/06.

En la tabla siguiente se enumeran todos los privilegios de Solaris Trusted Extensions y el estado de cada privilegio con respecto a las zonas. Los privilegios opcionales no forman parte del conjunto de privilegios predeterminado, pero se pueden especificar con la propiedad limitpriv.

Estos privilegios sólo se interpretan si el sistema está configurado con Solaris Trusted Extensions.

Para modificar los privilegios de una configuración de zona no global, consulte Configuración, verificación y confirmación de una zona.

Para examinar los conjuntos de privilegios, consulte Uso de la utilidad ppriv. Para obtener más información acerca de los privilegios, consulte la página del comando man ppriv(1) y System Administration Guide: Security Services.

Uso de arquitectura de seguridad IP en zonas

La arquitectura de seguridad de protocolo de Internet (IPsec), que protege los datagramas IP, se describe en el Capítulo 19, Arquitectura de seguridad IP (descripción general) de Guía de administración del sistema: servicios IP. El protocolo de intercambio de claves de Internet (IKE) se utiliza para administrar automáticamente el material de claves necesario para la autenticación y el cifrado.

Para obtener más información, consulte las páginas de comando man ipsecconf(1M) y ipseckey(1M).

Arquitectura de seguridad IP en zonas de IP compartida

IPsec se puede utilizar en la zona global. Sin embargo, IPsec en una zona no global no puede utilizar IKE. Por lo tanto, debe administrar las directivas y claves IPsec para las zonas no globales mediante el protocolo de intercambio de claves de Internet (IKE) en la zona global. Utilice la dirección de origen que corresponda a la zona no global que esté configurando.

Solaris 10 8/07: arquitectura de seguridad IP en zonas de IP exclusiva

IPsec se puede utilizar en zonas de IP exclusiva.

Uso de auditorías de Solaris en zonas

Las auditorías de Solaris se describen en el Capítulo 28, Oracle Solaris Auditing (Overview) de System Administration Guide: Security Services. Para conocer las consideraciones de zonas relativas a la auditoría, consulte las secciones siguientes:

• Capítulo 29, Planning for Oracle Solaris Auditing de System Administration Guide: Security Services

• Auditing and Solaris Zones de System Administration Guide: Security Services

Un registro de auditoría describe un evento, como el inicio de sesión en un sistema o la escritura en un archivo. El registro se compone de símbolos, que son conjuntos de datos de auditoría. El símbolo zonename permite configurar la auditoría de Solaris para identificar los eventos de auditoría por zona. Asimismo, zonename permite crear la información siguiente:

• Registros de auditoría marcados con el nombre de la zona que ha generado el registro

• Un registro de auditoría para una zona específica que el administrador global puede poner a disposición del administrador de zona

Configuración de auditorías en la zona global

Los finales de auditoría de Solaris se configuran en la zona global. La política de auditoría se configura en la zona global y se aplica a los procesos de todas las zonas. Los registros de auditoría se pueden marcar con el nombre de la zona en la que ha tenido lugar el evento. Para incluir los nombres de zonas en los registros de auditoría, debe editar el archivo /etc/security/audit_startup antes de instalar zonas no globales. La selección del nombre de zona distingue entre mayúsculas y minúsculas.

Para configurar la auditoría en la zona global para que incluya todos los registros de auditoría de la zona, añada esta línea al archivo /etc/security/audit_startup:

/usr/sbin/auditconfig -setpolicy +zonename

Como administrador global de la zona global, ejecute la utilidad auditconfig:

global# auditconfig -setpolicy +zonename

Si desea información adicional, consulte las páginas del comando man audit_startup(1M) y auditconfig(1M), así como la sección sobre cómo configurar archivos de auditoría (mapa de tareas) de la System Administration Guide: Security Services.

Configuración de las características de auditoría del usuario en una zona no global

Cuando se instala una zona no global, los archivos audit_control y audit_user de la zona global se copian en el directorio /etc/security de la zona. Es posible que tenga que modificar estos archivos para que reflejen las necesidades de auditoría de la zona.

Por ejemplo, cada zona se puede configurar para que audite algunos usuarios de un modo distinto a los demás. Para aplicar un criterio de selección previa distinto por usuario, debe editarse tanto el archivo audit_control como el archivo audit_user. Es posible que el archivo audit_user de la zona no global también deba revisarse para que refleje la base de usuarios para la zona, si es preciso. Dado que cada zona se puede configurar de un modo distinto en lo que se refiere a los usuarios de la auditoría, es posible que el archivo audit_user esté vacío.

Para obtener información adicional, consulte las páginas del comando man audit_control(4) y audit_user(4).

Registros de auditoría para una zona no global específica

Al incluir el símbolo zonename tal como se describe en Configuración de auditorías en la zona global, los registros de auditoría de Solaris se pueden categorizar por zona. A continuación, los registros de diferentes zonas se pueden recopilar utilizando el comando auditreduce para crear registros para una zona específica.

Para obtener más información, consulte las páginas del comando man audit_startup(1M) y auditreduce(1M).

Archivos principales en zonas

El comando coreadm se utiliza para especificar el nombre y la ubicación de los archivos principales producidos por procesos que finalizan de forma anómala. Las rutas de los archivos principales que incluyen el nombre_zona de la zona en la que se ejecuta el proceso se pueden producir mediante la especificación de la variable %z. El nombre de ruta es relativo al directorio raíz de la zona.

Si desea más información, consulte las páginas del comando man coreadm(1M) y core(4).

Ejecución de DTrace en una zona no global

Los programas de DTrace que sólo requieren los privilegios dtrace_proc y dtrace_user se pueden ejecutar en una zona no global. Para añadir estos privilegios al conjunto de privilegios disponibles en la zona no global, utilice la propiedad zonecfg limitpriv. Para obtener instrucciones, consulte Cómo utilizar DTrace.

Los proveedores que se admiten mediante dtrace_proc son fasttrap y pid. Los proveedores que se admiten mediante dtrace_user son profile y syscall. El ámbito de los proveedores y las acciones de DTrace se limita a la zona.

Consulte también Privilegios en una zona no global para obtener información adicional.

Cómo realizar copias de seguridad de un sistema Solaris con zonas instaladas

Puede realizar copias de seguridad en zonas no globales individuales, o realizar una copia de seguridad de todo el sistema desde la zona global.

Cómo realizar copias de seguridad de los directorios del sistema de archivos en bucle

Dado que muchas zonas no globales comparten archivos con la zona global mediante el uso de montajes de sólo lectura del sistema de archivos en bucle (normalmente /usr, /lib, /sbin y /platform), debe utilizar un método de copia de seguridad de la zona global para llevar a cabo la copia de seguridad de los directorios lofs.

No realice una copia de seguridad de los sistemas de archivos lofs compartidos con la zona global en zonas no globales. Si el administrador de zona no global intenta restaurar un sistema de archivos lofs desde una zona no global, puede producirse un error grave.

Copia de seguridad del sistema desde la zona global

Puede realizar copias de seguridad desde la zona global en los siguientes casos:

• Si desea crear una copia de seguridad de las configuraciones de las zonas no globales, así como de los datos de aplicación.

• Si su principal objetivo es poder recuperarse en caso de desastre. En caso de que necesite restaurar todo el sistema o casi todo, incluidos los sistemas de archivos raíz de las zonas y sus datos de configuración, así como los datos de la zona global, las copias de seguridad deben realizarse en la zona global.

• Si desea utilizar el comando ufsdump para efectuar la copia de seguridad de los datos. Dado que la importación de un dispositivo de disco físico en una zona no global cambiaría el perfil de seguridad de la zona, ufsdump sólo debe utilizarse desde la zona global.

• Si tiene software de copia de seguridad de red comercial.

  ---

  Nota –

  Debe configurar el software de copia de seguridad de red para que omita todos los sistemas de archivos lofs heredados si es posible. La operación de copia de seguridad debe llevarse a cabo cuando la zona y sus aplicaciones han desactivado los datos que se deben copiar.

  ---

Copia de seguridad de zonas no globales individuales en el sistema

Puede llevar a cabo copias de seguridad en las zonas no globales en los siguientes supuestos:

• El administrador de zona no global necesita llevar a cabo recuperaciones en caso de errores menos graves o restaurar datos de aplicaciones o usuarios específicos de una zona.

• Desea utilizar programas que realicen la copia de seguridad archivo por archivo, como tar o cpio. Consulte las páginas del comando man tar(1) y cpio(1).

• Utiliza el software de copia de seguridad de un servicio o una aplicación concreta que se ejecuta en una zona. Puede resultar difícil ejecutar el software de copia de seguridad desde la zona global porque los entornos de aplicación, como la ruta de directorios y el software instalado, serían diferentes en la zona global y la zona no global.

  Si la aplicación puede tomar una instantánea de su propia planificación de copia de seguridad en cada zona no global y almacenar dichas copias de seguridad en un directorio grabable exportado desde la zona global, el administrador de la zona global puede seleccionar dichas copias de seguridad individuales como parte de la estrategia de copia de seguridad de la zona global.

Cómo determinar qué se debe guardar en una copia de seguridad en las zonas no globales

Puede realizar una copia de seguridad de todo lo que incluye la zona no global. Dado que la configuración de una zona no cambia con mucha frecuencia, también puede realizar la copia de seguridad sólo de los datos de la aplicación.

Copia de seguridad sólo de los datos de la aplicación

Si los datos de la aplicación se guardan en una parte específica del sistema de archivos, puede realizar copias de seguridad regulares sólo de estos datos. No es necesario realizar una copia de seguridad del sistema de archivos raíz de la zona tan a menudo, ya que cambia con menos frecuencia.

Es necesario especificar dónde colocará la aplicación sus archivos. Las ubicaciones donde se pueden guardar los archivos incluyen:

• Directorios de inicio de los usuarios

• /etc para los archivos de datos de configuración

• /var

Si el administrador de la aplicación conoce dónde se guardan los datos, puede crear un sistema en el que haya disponible para cada zona un directorio en el que se pueda escribir. En tal caso, cada zona puede guardar sus propias copias de seguridad, y el administrador global puede utilizar esta ubicación como uno de los lugares del sistema en los que realizar las copias de seguridad.

Operaciones de copia de seguridad de bases de datos generales

Si los datos de aplicación de las bases de datos no se encuentran en su propio directorio, se aplican las reglas siguientes:

• En primer lugar, asegúrese de que las bases de datos tengan un estado coherente.

  Las bases de datos deben estar inactivas porque tienen búferes internos para descargar en el disco. Asegúrese de que las bases de datos de las zonas no globales estén inactivas antes de iniciar la copia de seguridad desde la zona global.

• En cada zona, utilice las funciones del sistema de archivos para realizar una instantánea de los datos y, a continuación, realice una copia de seguridad de las instantáneas directamente desde la zona global.

  Este proceso minimiza el tiempo que transcurre para la ventana de copia de seguridad y acaba con la necesidad de realizar copias de seguridad de los clientes y módulos en todas las zonas.

Copias de seguridad de cintas

Cada zona no global puede realizar una instantánea de sus sistemas de archivos privados cuando se considere oportuno para dicha zona y la aplicación lleve un momento desactivada. Más tarde, la zona global puede realizar una copia de seguridad de cada una de las instantáneas y colocarlas en cintas una vez que la aplicación vuelve a estar operativa.

Este método presenta las ventajas siguientes:

• Se necesitan menos dispositivos de cinta.

• No es necesario que haya coordinación entre las zonas no globales.

• No es necesario asignar dispositivos directamente a las zonas, por lo que la seguridad es mayor.

• Por norma general, este método mantiene la administración del sistema en la zona global, lo cual es recomendable.

Restauración de zonas no globales

En el caso de una restauración en la que las copias de seguridad se llevan a cabo desde la zona global, el administrador global puede volver a instalar las zonas afectadas y luego restaurar los archivos de la zona. Se da por sentado que:

• La zona que se está restaurando tiene la misma configuración que la que tenía cuando se realizó la copia de seguridad.

• La zona global no se ha actualizado ni se le ha aplicado ningún parche entre el momento en que se realizó la copia de seguridad y el momento en que se restaura la zona.

De lo contrario, la restauración podría sobrescribir algunos archivos que deberían fusionarse manualmente.

Por ejemplo, podría necesitar fusionar los archivos manualmente si se ha aplicado un parche a una zona global después de la copia de seguridad, pero antes de la restauración de la zona no global. En ese caso, debe tener cuidado al restaurar los archivos de una zona de los que se realizó una copia de seguridad, dado que el archivo de la copia de seguridad podría no ser compatible con la zona que se acaba de instalar, que se creó después de aplicar los parches a la zona global. De ser así, debe examinar los archivos uno a uno y compararlos con las copias de la zona que se acaba de instalar. En la mayoría de los casos, podrá copiar directamente el archivo, pero en ocasiones es necesario fusionar los cambios que se hicieron originalmente en el archivo en la copia que acaba de instalar o a la que acaba de aplicar un parche en la zona.

Si se pierden todos los sistemas de archivos de la zona global y se restaura toda la zona global, se restauran también las zonas no globales, ya que los sistemas de archivos raíz respectivos de las zonas no globales se incluyeron en la copia de seguridad.

Comandos utilizados en un sistema Solaris con zonas instaladas

Los comandos que se identifican en la Tabla 27–3 proporcionan la interfaz administrativa principal para las funciones de zonas.

El daemon zoneadmd es el proceso principal para administrar la plataforma virtual de la zona. La página del comando man para el daemon zoneadmd es zoneadmd(1M). El daemon no constituye una interfaz de programación.

Los comandos de la tabla siguiente se utilizan con el daemon de límite de recursos.

Los comandos identificados en la siguiente tabla se han modificado para utilizar en un sistema Solaris con zonas instaladas. Estos comandos tienen opciones que son específicas de zonas o presentan la información de un modo distinto. Los comandos se enumeran por sección de la página del comando man.