Capítulo 27 Administração do Solaris Zones (visão geral)

Este capítulo aborda os seguintes tópicos da administração de região geral:

• O que há de novo neste capítulo?

• Visibilidade e acesso de região global

• Visibilidade de ID de processo em regiões

• Observação do sistema em regiões

• Nome do nó em região não global

• Sistemas de arquivos e regiões não globais

• Conexão à rede em regiões não globais com IP compartilhado

• Solaris 10 8/07: conexão à rede em regiões não globais com IP exclusivo

• Uso de dispositivo em regiões não globais

• Execução de aplicativos em regiões não globais

• Controles de recursos em regiões não globais

• Fair share scheduler em um sistema do Solaris com regiões instaladas

• Contabilidade estendida em um sistema do Solaris com regiões instaladas

• Privilégios em uma região não global.

• Uso da arquitetura de segurança IP em regiões

• Uso da auditoria do Solaris em regiões

• Arquivos de núcleo em regiões

• Sobre backup de um sistema do Solaris com regiões instaladas

• Determinação do que fazer backup em regiões não globais

• Comandos usados em um sistema do Solaris com regiões instaladas

Para obter informações sobre regiões com marca 1x, consulte a Parte III, 1x}Regiões com marca.

O que há de novo neste capítulo?

Solaris 10 1/06: Uma nova seção Desmontagem de sistemas de arquivos em regiões foi adicionada.

Solaris 10 1/06: Novas seções sobre backup de regiões e procedimentos de restauração foram adicionadas. Consulte Sobre backup de um sistema do Solaris com regiões instaladas

Solaris 10 6/06: Uma entrada ZFS foi adicionada à tabela em Montagem de sistemas de arquivos em regiões.

Solaris 10 8/07: As informações a seguir são novas ou foram atualizadas nesta versão.

• Com esta versão, dois tipos de IP agora estão disponíveis para regiões não globais. Foram adicionadas informações sobre recursos disponíveis por tipo de IP. Consulte Conexão à rede em regiões não globais com IP compartilhado e Solaris 10 8/07: conexão à rede em regiões não globais com IP exclusivo.

• O filtro de IP do Solaris agora pode ser usado em regiões com IP compartilhado. Para obter mais informações, consulte Filtro de IP do Solaris em regiões com IP compartilhado.

• As informações sobre configurações de privilégios em regiões foram revisadas. Consulte a Tabela 27–1.

• As informações em Comandos usados em um sistema do Solaris com regiões instaladas foram atualizadas.

Para obter uma lista completa dos novos recursos do Solaris 10 e uma descrição das versões do Solaris, consulte Novidades no Oracle Solaris 10 9/10.

Visibilidade e acesso de região global

A região global atua como a região padrão para o sistema e como uma região para o controle administrado do sistema geral. Há problemas administrativos associados a esta função dupla. Uma vez que aplicativos dentro da região têm acesso a processos e outros objetos do sistema em outras regiões, o efeito das ações administrativas pode ser mais amplos do que o esperado. Por exemplo, scripts de desligamento de serviço com freqüência usam pkill para sinalizar processos de um nome dado para sair. Quando esse script é executado a partir da região global, todos esses processos no sistema serão sinalizados, independentemente da região.

O escopo do sistema geral é com freqüência necessário. Por exemplo, para monitorar o uso de recursos do sistema geral, é necessário visualizar estatísticas de processos para todo o sistema. Uma visualização apenas da atividade da região global não identificaria informações relevantes de outras regiões no sistema que poderiam estar compartilhando alguns dos ou todos os recursos do sistema. Essa visualização é particularmente importante quando recursos do sistema, como a CPU, não têm uma partição restrita ao usarem facilidades de gerenciamento de recursos.

Assim, processos na região global podem observar processos e outros objetos em regiões não globais. Isso permite que esses processos tenham uma observação do sistema geral. A capacidade de controlar ou enviar sinais a processos em outras regiões é restrita pelo privilégio PRIV_PROC_ZONE. O privilégio é semelhante a PRIV_PROC_OWNER, porque o privilégio permite que processos sobrescrevam as restrições colocadas em processos sem privilégios. Neste caso, a restrição é que processos sem privilégio na região global não podem sinalizar ou controlar processos em outras regiões. Isto é verdadeiro quando os IDs de usuário dos processos coincidem ou o processo atuante tem o privilégio PRIV_PROC_OWNER. O privilégio PRIV_PROC_ZONE pode ser removido de outros processos privilegiados para restringir ações na região global.

Para obter informações sobre a correspondência de processos usando-se um zoneidlist, consulte as páginas do manual pgrep(1) pkill(1).

Visibilidade de ID de processo em regiões

Somente processos na mesma região serão visíveis através das interfaces de chamada do sistema que tomam IDs de processo, como os comandos kill e priocntl. Para obter informações, consulte as páginas do manual kill(1) e priocntl(1).

Observação do sistema em regiões

O comando ps tem as seguintes modificações:

• A opção -o é usada para especificar o formato de saída. Esta opção permite que você imprima o ID de região de um processo ou o nome da região na qual o processo está em execução.

• A opção -z zonelist é usada para listas somente processos em regiões especificadas. As regiões podem ser especificadas por nome de região ou ID de região. Esta opção é útil somente quando o comando é executado na região global.

• A opção -Z é usada para imprimir o nome da região associada ao processo. O nome é impresso sob o cabeçalho de coluna ZONE.

Para obter mais informações, consulte a página do manual ps(1).

Uma opção -z zonename foi adicionada para os utilitários do Solaris abaixo. Você pode usar esta opção para filtrar as informações a para incluir somente a região ou as regiões especificadas.

• ipcs (consulte a página do manual ipcs(1))

• pgrep (consulte a página do manual pgrep(1))

• ptree (consulte a página do manual proc(1))

• prstat (consulte a página do manual prstat(1M))

Para obter uma lista completa de alterações feitas em comandos, consulte a Tabela 27–5.

Nome do nó em região não global

O nome do nó em /etc/nodename retornado por uname - n pode ser definido pelo administrador da região. O nome do nó deve ser exclusivo.

Sistemas de arquivos e regiões não globais

Esta seção fornece informações sobre os problemas do sistema de arquivos em um sistema do Solaris com regiões instaladas. Cada região tem sua própria seção na hierarquia do sistema de arquivos, enraizada em um diretório conhecido como a região root. Os processos na região podem acessar somente arquivos na parte da hierarquia que está localizada na raiz da região. O utilitário chroot pode ser usado em uma região, mas somente para restringir o processo a um caminho raiz dentro da região. Para obter mais informações sobre chroot, consulte chroot(1M).

A opção -o nosuid

A opção -o nosuid para o utilitário mount tem a seguinte funcionalidade:

• Os processos de um binário setuid localizado em um sistema de arquivos que é montado usando-se a opção nosetuid não é executada com privilégios do bináriosetuid. Os processos são executados com os privilégios do usuário que executa o binário.

  Por exemplo, se um usuário executa um binário setuid pertencente a root, os processos são executados com os privilégios do usuário.

• Não é permitida a abertura de entradas especiais de dispositivo no sistema de arquivos. Este comportamento é equivalente a especificar a opção nodevices.

Esta opção específica do sistema está disponível para todos os sistemas de arquivos do Solaris que podem ser montados com utilitários mount, como descrito na página do manual mount(1M) Neste guia, esses sistemas de arquivos estão listados em Montagem de sistemas de arquivos em regiões. As capacidades de montagem também são descritas. Para obter mais informações sobre a opção -o nosuid, consulte “Accessing Network File Systems (Reference)” no System Administration Guide: Network Services .

Montagem de sistemas de arquivos em regiões

Quando sistemas de arquivos são montados a partir do interior da região, a opção nodevices se aplica. Por exemplo, se uma região recebe acesso a um dispositivo de bloco (/dev/dsk/c0t0d0s7 ) e a um dispositivo básico (/dev/rdsk/c0t0d0s7) correspondentes a um sistema de arquivos UFS, o sistema de arquivos é montado automaticamente nodevices quando montado a partir do interior de uma região. Esta regra não se aplica a montagens especificadas através da configuração zonecfg.

As opções para a montagem de sistemas de arquivos em regiões não globais são descritas na tabela abaixo. Os procedimentos para essas alternativas de montagem são fornecidos em Configuração, verificação e comprometimento de uma região e Montagem de sistemas de arquivos em regiões não globais em execução.

Qualquer tipo de sistema de arquivos não listados tabela podem ser especificados na configuração se tiver um binário de montagem em /usr/lib/fstype/mount .

Para obter mais informações, consulte Como configurar a região, Montagem de sistemas de arquivos em regiões não globais em execução e a página do manual mount(1M).

Desmontagem de sistemas de arquivos em regiões

A capacidade de desmontar um sistema de arquivos depende de quem executou a montagem inicial. Se um sistema de arquivos foi especificado como parte da configuração da região usando-se o comando zonecfg, a região global é proprietária dessa montagem e o administrador da região para a região não global não pode desmontar o sistema de arquivos. Se o sistema de arquivos foi montado a partir do interior da região não global, por exemplo especificando a montagem no arquivo /etc/vfstab da região, o administrador da região na região não global pode desmontar o sistema de arquivos.

Restrições de segurança e comportamento do sistema de arquivos

Há restrições de segurança à montagem de determinados sistemas de arquivos a partir de uma região. Outros sistemas de arquivos expõem comportamento especial quando montados em uma região. Segue-se a lista de sistemas de arquivos modificados.

AutoFS

Autofs é um serviço de cliente que monta automaticamente o sistema de arquivos apropriado. Quando um cliente tenta acessar um sistema de arquivos que não está atualmente montado, o sistema de arquivos AutgoFS intercepta a solicitação e chama automountd para montar o diretório solicitado. Montagens do AutoFS estabelecidas no interior de uma região são locais para essa região. As montagens não podem ser acessadas a partir de outras regiões, inclusive a região global. As montagens são removidas quando a região é parada ou reinicializada. Para obter informações sobre AutoFS, consulte How Autofs Works no System Administration Guide: Network Services.

Cada região executa sua própria cópia de automountd. Os mapas automáticos e os tempos-limites são controlados pelo administrador da região. Não é possível acionar uma montagem em outra região atravessando-se um ponto de montagem do AutoFS para uma região não global a partir da região global.

Determinadas montagens do AutoFS são criadas no kernel quando outra montagem é acionada. Essas montagens não podem ser removidas usando-se a interface regular umount, porque devem ser montadas ou desmontadas como um grupo. Observe que esta funcionalidade é fornecida por desligamento de região.

MNTFS

MNTFS é um sistema de arquivos virtual que fornece acesso somente leitura à tabela de sistemas de arquivos montados para o sistema local. O conjunto de sistemas de arquivos visíveis usando-se mnttab a partir do interior da região não global é o conjunto de sistemas de arquivos montados na região, mais uma entrada para raiz (/) . Pontos de montagem com um dispositivo especial que não é acessível a partir do interior da região, como /dev/rdsk/c0t0d0s0, têm um conjunto de dispositivos semelhante ao do ponto de montagem. Todas as montagens no sistema são visíveis a partir da tabela /etc/mnttab da região global. Para obter mais informações sobre MNTFS, consulte o Capítulo 18, Mounting and Unmounting File Systems (Tasks), no System Administration Guide: Devices and File Systems.

NFS

Montagens do NFS estabelecidas no interior de uma região são locais para essa região. As montagens não podem ser acessadas a partir de outras regiões, inclusive a região global. As montagens são removidas quando a região é parada ou reinicializada.

Como documentado na página do manual mount_nfs(1M), um servidor de NFS não deve tentar montar seus próprios sistemas de arquivos. Assim, uma região não deve montar um sistema de arquivos NFS exportado pela região global. Regiões não podem ser servidores de NFS. A partir do interior de uma região, as montagens NFS se comportam como se montadas com a opção nodevices.

A saída do comando nfsstat somente pertence à região em que o comando é executado. Por exemplo, se o comando for executado na região global, somente informações a região global são relatadas. Para obter mais informações o comando nfsstat, consulte nfsstat(1M).

O comando zlogin falhará se qualquer um dos arquivos abertos ou qualquer parte do espaço de endereço residirem em NFS. Para obter mais informações, consulte Comando zlogin.

PROCFS

O sistema de arquivos /proc, ou PROCFS, fornece visibilidade de processos e restrições de acesso, assim como informações sobre a associação de regiões de processos. Somente processos na mesma região são visíveis através de /proc.

Processos na região global podem observar processos e outros objetos em regiões não globais. Isso permite que esses processos tenham uma observação do sistema geral.

A partir do interior de uma região, as montagens de procfs se comportam como se feitas com a opção nodevices. Para obter mais informações sobre procfs, consulte a página do manual proc(4).

LOFS

O escopo do que pode ser montado através de LOFS é limitado à parte do sistema de arquivos que é visível para a região. Assim, não há restrições a montagens LOFS em uma região.

UFS, UDFS, PCFS e outros sistemas de arquivos baseados em armazenamento

Ao usar o comando zonecfg para configurar sistemas de arquivos baseados em armazenamento que têm um binária fsck, como UFS, o administrador da região deve especificar um parâmetro raw. O parâmetro indica o dispositivo (caractere) básico, como /dev/rdsk/c0t0d0s7 . zoneadmd executa automaticamente o comando fsck em modo não interativo somente de verificação (fsck -m) neste dispositivo antes de montar o sistema de arquivos. Se fsck falhar, zoneadmd não pode colocar a região no estado de preparado. O caminho especificado por raw não pode ser um caminho relativo.

É um erro especificar um dispositivo para fsck de um sistema de arquivos que não fornece um binário fsck em /usr/lib/ fstype/fsck. É também um erro não especificar um dispositivo fsck se um binário fsck existir para esse sistema de arquivos.

Para obter mais informações, consulte O daemon zoneadmd e fsck(1M)

ZFS

Você pode adicionar um conjunto de dados ZFS a uma região não global usando o comando zonecfg com o recurso add dataset. O conjunto de dados será visível e montado em uma região não global e não mais visível na região global. O administrador de região pode criar e destruir sistemas de arquivos dentro desse conjunto de dados, criar e destruir clones e modificar as propriedades do conjunto de dados.

O atributo zoned de zfs indica se um conjunto de dados foi adicionado a uma região não global.

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

Se desejar compartilhar um conjunto de dados da região global, você pode adicionar um sistema de arquivos ZFS com montagem LOFS usando o comando zonecfg com o subcomando add fs. O administrador global é responsável para definição e pelo controle das propriedades do conjunto de dados.

Para mais informações sobre ZFS, consulte o Capítulo 10, Tópicos avançados do ZFS do Oracle Solaris, no Guia de administração do ZFS Oracle Solaris.

Regiões não globais como clientes NFS

Regiões podem ser clientes NFS. Há suporte para os protocolos das versões 2, 3 e 4. Para obter mais informações sobre estas versões de NFS, consulte Features of the NFS Service no System Administration Guide: Network Services.

A versão padrão é a versão 4 do NFS. Você pode ativar outras versões de NFS em um cliente usando um dos seguintes métodos:

• Você pode editar /etc/default/nfs para definir NFS_CLIENT_VERSMAX=number para que a região use por padrão a versão especificada. Consulte Setting Up NFS Services no System Administration Guide: Network Services . Use o procedimento Como selecionar diferentes versões de NFS em um cliente modificando o arquivo /etc/default/nfs no mapa de tarefas.

• Você pode criar manualmente uma montagem de versão. Este método sobrescreve o conteúdo de /etc/default/nfs. Consulte Setting Up NFS Services no System Administration Guide: Network Services . Use o procedimento Como usar a linha de comando para selecionar diferentes versões de NFS em um cliente a partir do mapa de tarefas.

Uso de mknod proibido em uma região

Observe que não é possível usar o comando mknod documentado na página do manual mknod(1M) para criar um arquivo especial em uma região não global.

Atravessamento de sistemas de arquivos

Em espaço de nome do sistema de arquivos da região é um subconjunto do espaço de nome acessível a partir da região global. Processos não privilegiados na região global são impedidos de atravessar a hierarquia do sistema de arquivos de uma região não global através dos seguintes meios:

• Especificação de que o diretório pai da raiz da regiões é pertencente à raiz e legível e executável somente por ela

• Restrição de acesso a diretórios exportados por /proc

Observe que a tentativa de acessar nós de AutoFS montados por outra região irá falhar. O administrador global não deve ter mapas automáticos que passem para outros regiões.

Restrição de acesso a uma região não global a partir da região global

Após a instalação de uma região não global, a região não deve ser acessada diretamente da região global por quaisquer comandos que não sejam utilitários de backup do sistema. Além disso, uma região não global não pode mais ser considerada segura depois de ter sido exposta a um ambiente desconhecido. Um exemplo seria uma região colocada em uma rede acessível publicamente, em que seria possível que a região fossem comprometida e o conteúdo de seus sistemas de arquivos alterados. Se houver qualquer possibilidade da ocorrência de comprometimento, a administrador global deve tratar a região como não confiável.

Qualquer comando que aceite uma raiz alternativa com o uso das opções -R ou - b (ou o equivalente) não deve ser usado quando o seguinte for verdadeiro:

• O comando é executado na região global.

• A raiz alternativa se refere a qualquer caminho raiz dentro de uma região não global, seja o caminho relativo à região global do sistema em execução atualmente seja a região global em uma raiz alternativa.

Um exemplo é a opção -R root_path para o utilitário pkgadd executado a partir da região global com um caminho raiz de região não global.

A lista de comandos, programas e utilitários que usam -R com um caminho raiz alternativo inclui o seguinte:

• auditreduce

• bart

• flar

• flarcreate

• installf

• localeadm

• makeuuid

• metaroot

• patchadd

• patchrm

• pkgadd

• pkgadm

• pkgask

• pkgchk

• pkgrm

• prodreg

• removef

• routeadm

• showrev

• syseventadm

A lista de comandos e programas que usam -b com um caminho raiz alternativo inclui o seguinte:

• add_drv

• pprosetup

• rem_drv

• roleadd

• sysidconfig

• update_drv

• useradd

Conexão à rede em regiões não globais com IP compartilhado

Em um sistema do Solaris com regiões instaladas, as regiões pode se comunicar entre si pela rede. Todas as regiões têm vinculações separadas, ou conexões, e todas as regiões podem executar seus próprios daemons de servidor. Esses daemons podem escutar no mesmo número de portas sem qualquer conflito. A pilhas de IP resolve conflitos ao considerar endereços IP para conexões de entrada. Os endereços IP identificam a região.

Partição de região com IP compartilhado

A pilha de IP em um sistema que oferece suporte a regiões implementa a separação do tráfego de rede entre regiões. Os aplicativos que recebem o tráfego IP podem somente receber tráfego enviado para a mesma região.

Cada interface lógica no sistema pertence a uma região específica, a região global por padrão. As interfaces lógicas de rede atribuídas a regiões através do utilitário zonecfg são usadas para a comunicação pela rede. Cada fluxo e cada conexão pertencem à região do processo que a abriu.

Vinculações entre fluxos de camada superior e interfaces lógicas são restritas. Um fluxo pode somente estabelecer vinculações a interfaces lógicas na mesma região. Da mesma forma, pacotes de uma interface lógica podem somente ser passados para grupos de camada superior na mesma região que a interface lógica.

Cada região tem seu próprio conjunto de vínculos. Cada região pode executar o mesmo aplicativo que escuta no mesmo número de portas sem falha de vínculos, porque o endereço já está em uso. Cada região pode executar sua própria versão dos seguintes serviços:

• Daemon de serviços da Internet com um arquivo de configuração completo (consulte a página do manual inetd(1M))

• sendmail (consulte a página do manual sendmail(1M))

• apache (consulte a página do manual apache(1M))

Regiões que não sejam a região global têm acesso restrito à rede. As interfaces de soquete TCP e UDP padrão estão disponíveis, mas as interfaces de soquete SOCK_RAW são restritas ao Internet Control Message Protocol (ICMP). ICMP é necessário para detectar e relatar condições de erro de rede ou usar o comando ping.

Interfaces de rede com IP compartilhado

Cada região que requer conectividade de rede tem um ou mais endereços IP dedicados. Esses endereços são associados às interfaces lógicas de rede que podem ser colocadas em uma região usando-se o comando ifconfig. Interfaces de rede de região configuradas pelo comando zonecfg serão automaticamente definidas e colocadas na região quando esta for inicializada. O comando ifconfig pode ser usado para adicionar ou remover interfaces lógicas quando a região está em execução. Somente o administrador global pode modificar a configuração da interface e as rotas de rede.

Dentro de uma região global, somente as interfaces de região estarão visíveis para ifconfig.

Para obter mais informações, consulte as páginas do manual ifconfig(1M) e if_tcp(7P).

Tráfego IP entre regiões com IP compartilhado na mesma máquina

Entre duas regiões na mesma máquina, a entrega de pacote é somente permitida se houver uma “rota correspondente”para o destino e a região na tabela de reenvio.

As informações correspondentes são implementadas como a seguir:

• O endereço de origem para os pacotes é selecionado na interface de saída especificada pela rota correspondente.

• Por padrão, o tráfego é permitido entre duas regiões que têm endereços na mesma sub-rede. A rota correspondente neste caso é a rota de interface para a sub-rede.

• Se houver uma rota padrão para uma dada região, em que o gateway está em uma das sub-redes da região, o tráfego desse região para outras regiões será permitido. A rota correspondente neste caso é a rota padrão.

• Se houver uma rota correspondente com o sinalizador RTF_REJECT, os pacotes acionam uma mensagem de ICMP inatingível. Se houver uma rota correspondente com o sinalizador RTF_BLACKHOLE, os pacotes serão descartados. O administrador global pode usar as opções do comando route descritas na tabela abaixo para criar rotas com estes sinalizadores.

  Modificador	Sinalizador	Descrição
  -reject	RTF_REJECT	Emite uma mensagem de ICMP inatingível quando não correspondente.
  -blackhole	RTF_BLACKHOLE	Descarta pacotes silenciosamente durante atualizações.

  Para obter mais informações, consulte route(1M)

Filtro de IP do Solaris em regiões com IP compartilhado

O filtro de IP do Solaris fornece filtragem de pacotes e conversão de endereços de rede (NAT). Um filtro de pacote com informações de estado pode monitorar o estado de conexões ativas e usar as informações obtidas para determinar quais pacotes de rede terão permissão através do firewall. O filtro de IP do Solaris também inclui filtragem de pacotes sem informações de estado e a capacidade de criar e gerenciar grupos de endereços. Para mais informações adicionais, consulte o Capítulo 25, Oracle Solaris IP Filter (Overview), no System Administration Guide: IP Services.

O filtro de IP do Solaris pode ser ativado em regiões não globais através da ativação da filtragem de autorretornos, como descrito no Capítulo 26, Oracle Solaris IP Filter (Tasks), no System Administration Guide: IP Services.

O filtro de IP do Solaris é derivado do software de filtro de IP de código aberto.

Vários caminhos de rede IP em regiões com IP compartilhado

O recurso de vários caminhos de rede IP (IPMP) oferece detecção de falha de interface física e falha de acesso de rede transparente para um sistema com várias interfaces no mesmo link de IP. IPMP também oferece propagação de carga de pacotes para sistemas com várias interfaces.

Toda a configuração de rede é feita na região global. Você pode configurar IPMP na região global e, em seguida, estender a funcionalidade para regiões não globais. A funcionalidade é estendida colocando-se o endereço da região em um grupo IPMP ao configurar a região. Em seguida, se uma das interfaces na região global falhar, os endereços da região não global migrarão para outra placa de interface de rede. Uma região de IP compartilhado pode possuir vários endereços IP, que podem ser parte de vários grupos IPMP e um determinado grupo IPMP pode ser utilizado por várias zonas de IP compartilhado.

Em uma dada região não global, somente as interfaces associadas à região são visíveis através do comando ifconfig.

Consulte Como estender a funcionalidade de vários caminhos de rede IP para regiões não globais com IP compartilhado. O procedimento de configuração de regiões é tratado em Como configurar a região. Para obter informações sobre recursos, componentes e uso de IPMP, consulte Capítulo 30, Introducing IPMP (Overview), no System Administration Guide: IP Services .

Solaris 10 8/07: conexão à rede em regiões não globais com IP exclusivo

Uma região de região com IP exclusivo tem seu próprio estado relacionado a IP e variáveis de ajuste. À região é atribuída seu próprio conjunto de links de dados quando a região é configurada.

Para obter informações sobre recursos que podem ser usados em uma região não global com IP exclusivo, consulte Solaris 10 8/07: regiões não globais com IP exclusivo. Para obter informações sobre o ajuste de variáveis IP ndd, consulte o Oracle Solaris Tunable Parameters Reference Manual.

Partição de região com IP exclusivo

Regiões com IP exclusivo têm pilhas do TCP/IP separadas, de modo que a separação alcança a camada de link de dados. Um ou mais nomes de link de dados, que podem ser um NIC ou um VLAN em um NIC, são atribuídos a uma região com IP exclusivo pelo administrador global. O administrador de região pode configurar IP nesses links de dados com a mesma flexibilidade e as opções que na região global.

Interfaces de link de dados com IP exclusivo

Um nome de link de dados pode ser atribuído exclusivamente a uma única região.

O comando dladm show-link pode ser usado para exibir links de dados atribuídos a regiões em execução.

Para obter mais informações, consulte dladm(1M)

Tráfego IP entre regiões com IP exclusivo na mesma máquina

Não há auto-retorno interno de pacotes IP entre regiões com IP exclusivo. Todos os pacotes são enviados para o link de dados. Normalmente, isso significa que os pacotes são enviados em uma interface de rede. Em seguida, dispositivos como Ethernet são ativados ou roteadores IP podem enviar os pacotes para o destino, que pode ser uma região diferente na mesma máquina que o remetente.

O filtro de IP do Solaris em regiões com IP exclusivo

Há a mesma funcionalidade de filtro de IP que há na região global em uma região com IP exclusivo. O filtro de IP é também configurado da mesma maneira em regiões com IP exclusivo e na região global.

Vários caminhos de rede IP em regiões com IP exclusivo

O recurso de vários caminhos de rede IP (IPMP) oferece detecção de falha de interface física e falha de acesso de rede transparente para um sistema com várias interfaces no mesmo link de IP. Além da tolerância a falhas, o IPMP também oferece propagação de carga de pacotes para sistemas com várias interfaces.

Toda a configuração de rede é feita na região global. Primeiro, várias interfaces de link de dados são atribuídas a uma região que usa zonecfg. As interfaces de link de dados devem estar anexadas à mesma sub-rede IP. IPMP pode então ser configurado a partir do interior da região de IP exclusivo pelo administrador de região. Vários grupos IPMP podem ser atribuídos a uma determinada região de IP exclusivo, mas esses grupos IPMP não podem ser compartilhados com outras regiões.

Uso de dispositivo em regiões não globais

O conjunto de dispositivos disponíveis dentro de uma região é restrito para impedir que um processo em uma região interfira nos processos em execução em outras regiões. Por exemplo, um processo em uma região não pode modificar a memória do kernel ou o conteúdo do disco raiz. Assim, por padrão, somente determinados pseudodispositivos considerados seguros para uso em uma região estão disponíveis. Dispositivos adicionais podem ser disponibilizados dentro de regiões específicas usando-se o utilitário zonecfg.

/dev e o espaço de nome /devices

O sistema de arquivos devfs descrito na página do manual devfs(7FS) é usado pelo sistema do Solaris para gerenciar /devices. Cada elemento neste espaço de nome representa o caminho físico para um dispositivo de hardware, pseudodispositivo ou dispositivo de conexão. O espaço de nome é um reflexo da árvore de dispositivos. Assim sendo, o sistema de arquivos é usado por uma hierarquia de diretórios e arquivos especiais de dispositivo.

O arquivo de hierarquia /dev, que é hoje parte do sistema de arquivos (raiz) /, consiste em links simbólicos, ou caminhos lógicos, para os caminhos físicos presentes em /devices. Aplicativos fazem referência ao caminho lógico para um dispositivo presente em /dev. O sistema de arquivos /dev é montado com auto-retorno na região usando uma montagem somente leitura.

A hierarquia de arquivos /dev é gerenciada por um sistema composto dos componentes na seguintes lista:

• devfsadm (consulte a página do manual devfsadm(1M))

• syseventd (consulte a página do manual syseventd(1M))

• Biblioteca de informações do dispositivo libdevinfo (consulte a página do manual libdevinfo(3LIB))

• Driver devinfo (consulte a página do manual devinfo(7D))

• Gerenciador de coordenação de configuração (RCM) (consulte Reconfiguration Coordination Manager (RCM) Script Overview no System Administration Guide: Devices and File Systems)

Subsistemas que dependem de nomes de caminho de /devices não podem ser executados em regiões não globais até nomes de caminho de /dev serem estabelecidos.

Dispositivos de uso exclusivo

Pode haver dispositivos que você deseja atribuir a regiões específicas. Permitir que usuários não privilegiados acessem dispositivos de bloco pode permitir que esses dispositivos sejam usados para causar pane no sistema, reinicialização de barramento ou outros efeitos adversos. Antes de fazer tais atribuições, leve em consideração os seguintes questões:

• Antes de atribuir um serviço de fita SCSI a uma região específica, consulte a página do manual sgen(7D).

• Colocar um dispositivo físico em mais de uma região pode criar um canal oculto entre regiões. Aplicativos de região global que usam tal dispositivo podem ensejar a possibilidade de dados comprometidos ou corrupção de dados por uma região não global.

Administração de driver de dispositivo

Em uma região não global, você pode usar o comando modinfo descrito na página do manual modinfo(1M) para examinar a lista de módulos do kernel carregados.

A maioria das operações relacionadas ao gerenciamento do kernel, dispositivo e da plataforma não funcionará no interior de uma região não global, porque a modificação das configurações de hardware da plataforma viola o modelo de segurança da região. Essas operações incluem o seguinte:

• Adição e remoção de drivers

• Carregamento e descarregamento explícitos de módulos do kernel

• Operações de inicialização de configuração dinâmica (DR)

• Uso de facilidades que afetam o estado da plataforma física

Utilitários que não funcionam ou são modificados em regiões não globais

Utilitários que não funcionam em regiões não globais

Os seguintes utilitários não funcionam em uma região porque dependem de dispositivos que normalmente não estão disponíveis:

• cdrecord (Consulte a página do manual no diretório /usr/share/man/man1 . )

• cdrw (consulte a página do manual cdrw(1))

• rmformat (consulte a página do manual rmformat(1))

• add_drv (consulte a página do manual add_drv(1M))

• disks (consulte a página do manual disks(1M))

• prtconf (consulte a página do manual prtconf(1M))

• prtdiag (consulte a página do manual prtdiag(1M))

• rem_drv (consulte a página do manual rem_drv(1M))

SPARC: Utilitário modificado para uso em uma região não global

O utilitário eeprom pode ser usado em uma região para visualizar configurações. O utilitário não pode ser usado para alterar configurações. Para obter mais informações, consulte as páginas do manual eeprom(1M) e openprom(7D).

Execução de aplicativos em regiões não globais

Em geral, todos os aplicativos podem ser executados em uma região não global. No entanto, os seguintes tipos de aplicativos podem não ser adequados para este ambiente:

• Aplicativos que usam operações privilegiadas que afetam o sistema como um todo. Exemplos incluem operações que definem o relógio do sistema global ou bloqueiam a memória física.

• Os poucos aplicativos dependentes de determinados dispositivos que não existem em uma região não global, como /dev/kmem.

• Aplicativos que esperam estar capacitados para gravar em /usr, no tempo de execução ou quando estão sendo instalados, atualizados ou recebendo correções. Isto porque, por padrão, /usr é somente leitura para uma região não global. Às vezes os problemas associados a este tipo de aplicativo podem ser mitigados sem alterar o próprio aplicativo.

• Em uma região com IP compartilhado, aplicativos dependentes de dispositivos em /dev/ip.

Controles de recursos em regiões não globais

Para obter informações adicionais sobre o uso da facilidade de gerenciamento de recurso em uma região, consulte também o capítulo que descreve a facilidade na Parte 1 deste guia.

Qualquer controle de recurso e atributo descritos nos capítulos sobre gerenciamento de recurso podem ser definidos no arquivo da região global e não global /etc/project , mapa de NIS ou no serviço de diretório LDAP. As configurações para uma dada região afetam somente essa região. Os controles de um projeto executado autonomamente em diferentes regiões pode ser definido individualmente em cada região. Por exemplo, o Projeto A na região global pode ser definido como project.cpu-shares=10, enquanto o Projeto A na região não global pode ser definido como project.cpu-shares=5. Pode haver diversas instâncias de rcapd em execução no sistema, com cada instância operando somente em sua própria região.

Os controles de recursos e os atributos usados em uma região para controlar projetos, tarefas e processos no interior dessa região estão sujeitos aos requisitos adicionados no que respeita a grupos e controles de recursos de região geral.

Uma regra “uma região, um grupo” se aplica a regiões não globais. Várias regiões não globais podem compartilhar os recursos de um grupo. Processos na região global, no entanto, podem ser vinculados a qualquer grupo por um processo suficientemente privilegiado. O controlador de recursos poold é executado somente na região global, em que há mais de um grupo sobre os quais eles podem operar. O utilitário poolstat executado em uma região não global exibe somente informações sobre o grupo associado à região. O comando pooladm executado sem argumentos em uma região não global exibe somente informações o grupo associado à região.

Controles de recursos de região geral não têm efeito quando estão definidos no arquivo project. O controle de recursos de região geral é definido através do utilitário zonecfg.

Fair share scheduler em um sistema do Solaris com regiões instaladas

Esta seção descreve como usar o fair share scheduler (FSS) com regiões.

Divisão de compartilhamento do FSS em uma região não global

Os compartilhamentos de CPU do FSS para uma região são hierárquicos. Os compartilhamentos para as regiões globais e não globais são definidos pelo administrador global através do controle de recurso de região geral zone.cpu-shares. O controle de recursos project.cpu-shares pode então ser definido para cada projeto no interior dessa região para subdividir mais compartilhamentos definidos através do controle de região geral.

Para atribuir compartilhamentos de região usando-se o comando zonecfg, consulte Como definir zone.cpu-shares na região global. Para obter mais informações sobre project.cpu-shares, consulte Controles de recursos disponíveis. Consulte também Uso do fair share scheduler em um sistema do Solaris com regiões instaladas para obter procedimentos de exemplo que mostram como definir compartilhamentos em base temporária.

Equilíbrio de compartilhamento entre regiões

Você pode usar zone.cpu-shares para atribuir compartilhamentos do FSS na região global e em regiões não globais. Se o FSS for o agendador padrão no sistema e os compartilhamentos não estiverem atribuídos, cada região, incluindo a região global, receberá um compartilhamento por padrão. Se houver uma região não global no sistema e você der a essa região dois compartilhamentos através de zone.cpu-shares, isto definirá a proporção de CPU que a região global receberá em relação à região global. A taxa de CPU entre as duas regiões é 2:1.

Contabilidade estendida em um sistema do Solaris com regiões instaladas

O subsistema da contabilidade estendida coleta e relata informações para todo o sistema (inclusive regiões não globais) quando executado na região global. O administrador global pode também determinar o consumo de recursos com base em cada região.

O subsistema de contabilidade estendida permite diferentes configurações de contabilidade e arquivos em uma base por região para contabilidade baseada em processo e tarefa. Os registros exacct podem ser identificados com o nome de região EXD PROC ZONENAME para processos e o nome de região EXD TASK ZONENAME para tarefas. Registros de contabilidade são gravados nos arquivos de contabilidade da região global, assim como nos arquivos de contabilidade por região. Os registros EXD TASK HOSTNAME, EXD PROC HOSTNAME e EXD HOSTNAME contêm o valor uname -n para a região na qual o processo ou a tarefa foram executados, em vez do nome do nó da região global.

Para obter informações sobre a contabilidade do fluxo IPQoS, consulte o Capítulo 36, Using Flow Accounting and Statistics Gathering (Tasks), no System Administration Guide: IP Services .

Privilégios em uma região não global

Processos são restritos a um subconjunto de privilégios. A restrição de privilégios impede que uma região execute operações que possam afetar outras regiões. O conjunto de privilégios limita as capacidades de usuários privilegiados dentro da região. Para exibir a lista de privilégios disponíveis dentro de uma região, use o utilitário ppriv.

A tabela abaixo lista todos os privilégios do Solaris e o status de cada privilégio com relação às regiões. Privilégios opcionais não fazem parte do conjunto padrão de privilégios, mas podem ser especificados através da propriedade limitpriv . Privilégios necessários devem ser incluídos no conjunto de privilégios resultante. Privilégios proibidos não podem ser incluídos no conjunto de privilégios resultante.

A propriedade limitpriv está disponível a partir da versão Solaris 10 11/06.

A tabela abaixo lista todos os privilégios do Solaris Trusted Extensions e o status de cada privilégio com relação às regiões. Privilégios opcionais não fazem parte do conjunto padrão de privilégios, mas podem ser especificados através da propriedade limitpriv .

Esses privilégios são interpretados somente se o sistema está configurado com Solaris Trusted Extensions.

Para alterar privilégios em uma região não global, consulte Configuração, verificação e comprometimento de uma região.

Para inspecionar conjuntos de privilégios, consulte Uso do utilitário ppriv. Para obter mais informações sobre privilégios, consulte a página do manual ppriv(1) e System Administration Guide: Security Services.

Uso da arquitetura de segurança IP em regiões

O Internet Protocol Security Architecture (IPsec), que fornece proteção de diagrama IP, é descrito no Capítulo 19, IP Security Architecture (Overview), no System Administration Guide: IP Services . O protocolo Internet Key Exchange (IKE) é usado para gerenciar o material de entrada para autenticação e criptografia automáticas.

Para obter mais informações, consulte as páginas do manual ipsecconf(1M) e ipseckey(1M).

Arquitetura de segurança IP em regiões com IP compartilhado

IPsec pode ser usado na região global. No entanto, IPsec em uma região não global não pode usar IKE. Assim, é necessário gerenciar as chaves e a diretiva de IPsec para regiões não globais usando o protocolo Internet Key Exchange (IKE) na região global. Use o endereço de origem que corresponde à região não global que você está configurando.

Solaris 10 8/07: arquitetura de segurança IP em regiões com IP exclusivo

IPsec pode ser usado em regiões com IP exclusivo.

Uso da auditoria do Solaris em regiões

A auditoria do Solaris é descrita no Capítulo 28, Oracle Solaris Auditing (Overview), no System Administration Guide: Security Services. Para considerações de regiões associadas a auditoria, consulte as seguintes seções:

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

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

Um registro de auditoria descreve um evento, como login em um sistema ou gravação em um arquivo. O registro é composto de símbolos, que são conjuntos de dados de auditoria. Com o uso do símbolo zonename, você pode configurar a auditoria do Solaris para identificar eventos de auditoria por região. O uso do símbolo zonename permite que você produza as seguintes informações:

• Registros de auditoria que são marcados com o nome da região que gerou o registro

• Um log de auditoria para uma região específica que o administrador global pode disponibilizar para o administrador de região.

Configuração de auditoria na região global

As faixas de auditoria do Solaris são configuradas na região global. A política de auditoria é definida na região global e se aplica a processos em todas as regiões. Os registros de auditoria podem ser marcados com o nome da região em que ocorreu o evento. Para incluir nomes de região em registros de auditoria, é necessário editar o arquivo /etc/security/audit_startup antes de instalar qualquer região não global. A seleção de nome de região diferencia maiúsculas de minúsculas.

Para configurar auditoria na região global para incluir todos os registros de auditoria da região, adicione esta linha ao arquivo /etc/security/audit_startup:

/usr/sbin/auditconfig -setpolicy +zonename

Como administrador global na região global, executar o utilitário auditconfig :

global# auditconfig -setpolicy +zonename

Para obter informações adicionais, consulte as páginas do manual audit_startup(1M) e auditconfig(1M), e “Configuring Audit Files (Task Map)” in System Administration Guide: Security Services.

Configuração de características de auditoria de usuário em uma região não global

Quando uma região não global é instalada, o arquivo audit_control e o arquivo audit_user na região global são copiados para o diretório /etc/security da região. Estes arquivos podem requerer modificação para refletir as necessidade de auditoria da região.

Por exemplo, cada região pode ser configurada para fazer a auditoria de alguns usuários de maneira diferente da de outros. Para aplicar diferentes critérios de pré-seleção por usuário, os arquivos audit_control e audit_user devem ser editados. O arquivo audit_user na região não global também pode requerer revisões para refletir a base de usuário para a região, se necessário. Uma vez que cada região pode ser configurada de maneira diferente com relação a usuários de auditoria, é possível que o arquivo audit_user seja vazio.

Para obter informações adicionais, consulte as páginas do manual audit_control(4) e audit_user(4).

Fornecimento de registros de auditoria para uma região não global específica

Por incluir o símbolo zonename como descrito em Configuração de auditoria na região global, os registros de auditoria do Solaris podem ser categorizados por região. Registros de diferentes regiões podem em seguida ser reunidos usando-se o comando auditreduce para criar logs para uma região específica.

Para obter mais informações, consulte as páginas do manual audit_startup(1M) e auditreduce(1M).

Arquivos de núcleo em regiões

O comando coreadm é usado para especificar o nome e o local de arquivos de núcleo produzidos por processos que terminam anormalmente. Caminhos de arquivos de núcleo que incluem o zonename da região em que o processo é executado podem ser produzidos especificando-se a variável %z. O nome do caminho é relativo ao diretório raiz de uma região.

Para obter mais informações, consulte as páginas do manual coreadm(1M) e core(4).

Execução do DTrace em uma região não global

Programas DTrace que somente requerem os privilégios dtrace_proc e dtrace_user podem ser executados em uma região não global. Para adicionar esses privilégios ao conjunto de privilégios disponíveis na região não global, use a propriedade zonecfg limitpriv . Para instruções, consulte Como usar DTrace.

Os provedores com suporte através de dtrace_proc são fasttrap e pid. Os provedores com suporte através de dtrace_user são profile e syscall. As ações e os provedores de DTrace estão limitados ao âmbito da região.

Para obter mais informações, consulte também Privilégios em uma região não global.

Sobre backup de um sistema do Solaris com regiões instaladas

Você fazer backups em regiões não globais individuais, ou fazer backup do sistema inteiro a partir da região global.

Backup de diretórios de sistema de arquivos de auto-retorno

Uma vez que várias regiões não globais compartilham arquivos com a região global através do uso de montagens somente leitura do sistema de arquivos de auto-retorno (geralmente /usr, /lib, /sbin e /platform), é necessário usar um método de backup da região global para fazer o backup dos diretórios lofs.

Não faça backup dos sistemas de arquivos lofs compartilhados com a região global em regiões não globais. Uma tentativa do administrador não global de restaurar sistemas de arquivos lofs de uma região não global pode causar um problema grave.

Backup do sistema a partir da região global

Você pode escolher fazer os backups a partir da região global nos seguintes casos:

• Você deseja fazer o backup de configurações das regiões não globais e de dados de aplicativos.

• Sua principal preocupação é a capacidade de recuperar em situação de desastre. Se precisar restaurar tudo ou quase tudo no sistema, inclusive os sistemas de arquivos raiz das regiões e os dados de configuração correspondentes, assim como os dados da região global, os backups devem se dar na região global.

• Você deseja usar o comando ufsdump para fazer um backup de dados. Uma vez que a importação de um dispositivo de disco físico para uma região não global alteraria o perfil de segurança da região, ufsdump deve ser usado somente a partir da região global.

• Você tem um software comercial de backup de rede.

  ---

  Observação –

  O software de backup de rede deve ser configurado para ignorar todos os sistemas de arquivos lofsherdados, se possível. O backup deve ser feito quando a região e seus aplicativos tornaram os dados inativos para o backup.

  ---

Backup de regiões não globais individuais no sistema

Você pode resolver fazer backups dentro de regiões não globais nos seguintes casos:

• O administrador de região não global precisa da capacidade de recuperar a partir de falhas menos graves ou restaurar aplicativo ou dados de usuário específicos de uma região.

• Você deseja usar programas que fazem backup de arquivo por arquivo, como tar ou cpio. Consulte as páginas do manual tar(1) e cpio(1).

• Você usa o software de backup de um determinado aplicativo ou serviço em execução em uma região. Pode ser difícil executar o software de backup a partir da região global, porque os ambientes de aplicativos, como caminho de diretório e software instalado, seriam diferentes entre a região global e a região não global.

  Se o aplicativo puder efetuar um instantâneo em sua própria agenda de backup em cada região não global e armazenar esse backup em um diretório gravável exportado da região global, o administrador da região global poderá pegar cada backup individual como parte da estratégia de backup a partir da região global.

Determinação do que fazer backup em regiões não globais

Você pode fazer backup de tudo na região não global, ou, porque a configuração de uma região se altera com menor freqüência, pode fazer backup somente de dados de aplicativos.

Backup somente de dados de aplicativos

Se os dados de aplicativos forem mantidos em uma determinada parte do sistema de arquivos, você pode decidir fazer backups regulares somente desses dados. O backup do sistema de arquivos raiz da região pode não ter sido feito com a mesma freqüência, porque ele se altera com menor freqüência.

Você terá de determinar onde o aplicativo colocará seus arquivos. Os arquivos podem ser armazenados nos seguintes locais:

• Pastas base de usuários

• /etc para configuração de arquivos de dados

• /var

Supondo-se que o administrador de aplicativos sabe onde os dados estão armazenados, pode ser possível criar um sistema em que um diretório gravável por região seja disponibilizado para cada região. Cada região pode então armazenar seus próprios backups, e o administrador global pode tornar esse local um dos locais no sistema para backup.

Operações de backup de banco de dados geral

Se os dados do aplicativo do banco de dados não estiver em seu próprio diretório, as seguintes regras serão aplicadas:

• Primeiro se certifique de que o banco de dados esteja em um estado consistente.

  Os bancos de dados devem ficar inativos, porque possuem buffers internos para liberar para disco. Certifique-se de os bancos de dados de regiões não globais tenham baixado antes de iniciar o backup a partir da região global.

• Dentro de cada região, use recursos do sistema de arquivos para fazer um instantâneo dos dados, em seguida faça o backup de instantâneos diretamente a partir da região global.

  Este processo irá minimizar o tempo transcorrido para a janela de backup e remover a necessidade de backup de clientes/módulos em todas as regiões.

Backups de fita

Cada região não global pode tirar um instantâneo dos sistemas de arquivos privados quando é conveniente para essa região e o aplicativo foi brevemente desativado. Posteriormente, a região global poderá fazer o backup de cada instantâneo e colocá-lo em fita após o aplicativo voltar a estar disponível.

Este método tem as seguintes vantagens:

• Menos dispositivos de fita são necessários.

• Não há necessidade de coordenação entre regiões não globais.

• Não há necessidade de atribuir dispositivos diretamente a regiões, o que melhora a segurança.

• Geralmente, este método mantém o gerenciamento do sistema na região global, o que é preferível.

Sobre restauração de regiões não globais

No caso de uma restauração em que os backups foram feitos a partir da região global, o administrador global pode reinstalar as regiões afetadas e, em seguida, restaurar arquivos dessa região. Observe que isto pressupõe o seguinte:

• A região que está sendo restaurada tem a mesma configuração de quando o backup foi feito.

• A região global não foi atualizada nem corrigida entre o momento em que o backup foi feito e o momento em que a região foi restaurada.

Do contrário, a restauração poderia sobrescrever alguns arquivos que deveriam mesclados manualmente.

Por exemplo, você poderia precisar de mesclar arquivos manualmente se a região global tivessem recebido correção após o backup, mas antes da restauração da região não global. Neste caso, você teria de tomar cuidado ao restaurar arquivos da região cujo backup foi feito, uma vez que o backup de um arquivo poderia não ser compatível com a região recém-instalada que foi criada depois dos taches terem sido aplicados à região global. Neste caso, você teria de examinar os arquivos individualmente e compará-los com as cópias na região recém-instalada. Na maioria dos casos, você verificará que o arquivo pode ser copiado diretamente, mas, em alguns casos, você deve mesclar as alterações feitas originalmente no arquivo na cópia recém-instalada ou corrigida.

Se todos os sistemas de arquivos na região global se perderem, a restauração de tudo na região global restaura também as regiões não globais, desde que os sistemas de arquivos raiz respectivos da região não global tenham sido incluídos no backup.

Comandos usados em um sistema do Solaris com regiões instaladas

Os comandos identificados na Tabela 27–3 fornecem a interface administrativa principal para a facilidade de regiões.

O daemon zoneadmd é o processo primário para gerenciar a plataforma virtual da região. A página do manual para o daemon zoneadmd é zoneadmd(1M). O daemon não constitui uma interface de programação.

Os comandos nas próxima tabela são usados com o daemon do resource capping.

Os comandos identificados na tabela abaixo foram modificados para uso em um sistema do Solaris com regiões instaladas. Esses comandos têm opções específicas de regiões ou apresentam informações de maneira diferente. Os comando estão listados por seção de página do manual.