Solaris 11.3 zonas não globais que não herdam as alterações de faceta IPS (para bloqueio de versão)

4

Eu tenho um sistema Solaris 11.3 sem (atualmente) um contrato de suporte. Portanto, estou usando o repositório IPS no link , que agora espelhei localmente usando pkgrecv .

Estou usando pkg change-facet para alterar version-lock para false em um grande número de pacotes, de modo que eu possa atualizar esses pacotes para a versão mais recente. Isso funciona bem.

O "problema" é que essas facetas alteradas não estão sendo herdadas por minhas regiões não globais. Assim, enquanto na zona global eu vejo a faceta alterada, e posso atualizar os pacotes afetados, o mesmo não é verdade em qualquer região não global que depois cria: mostra a faceta original, inalterada, e não pode atualizar os pacotes afetados. / p>

pkg(5) indica que as alterações nas facetas são herdadas por imagens filhas, como uma zona não global herdada de uma região global. Mas isso não está acontecendo comigo.

Inicialmente, pensei que isso era um problema, mas depois de uma reflexão mais profunda, percebi que, na verdade, eu provavelmente não gostaria que as mudanças facetas no global sempre herdassem os não-globais. Isso ficou provado quando, pouco depois, descobri que queria instalar zonas de teste com software básico, sem alterar essas facetas.

No entanto, eu ainda estou confuso com a documentação indicando que eles herdam, e acredito que idealmente deve haver uma maneira de configurar certas facetas para herdar.

Portanto, minhas perguntas são:

  1. Existe uma maneira de, opcionalmente, tornar certas facetas herdadas em todos não-globais - talvez criando uma nova imagem IPS?
  2. Por que a documentação do IPS indica que as facetas do herdam - está falando sobre apenas certos tipos de facetas?

Isso é o que eu estou fazendo na íntegra:

Eu tenho investigado o uso dos novos pacotes FOSS que a Oracle fornece.  Tenho acompanhado o guia aqui: Como acessar os pacotes de Avaliação FOSS selecionados para o Oracle Solaris 11.3 .

Este guia explica que é necessário alterar a faceta version-lock para false antes que os pacotes possam ser atualizados e que os pacotes FOSS atualizados possam ser encontrados em massa no repo Release com uma sequência de números de versão correspondente a \*@\*-5.12.0.0.0.122 . O documento recomenda manipular a saída de pkg list para criar comandos pkg change-facet para desbloquear todas as versões.

Eu fiz isso na minha zona global e, posteriormente, fazer pkg update --accept resulta em um grande número de pacotes atualizados.

Mas, se eu instalar uma nova região não global, o padrão será a versão base desses pacotes. Se nessa zona global eu executar pkg facet , verei as facetas inalteradas na zona. Por exemplo, aqui uma zona mostra a versão inalterada-lock = True para Bash:

root@goldenzone:~# pkg facet -a | grep version-lock.shell/bash
version-lock.shell/bash                                          True  system

Considerando que seu global mostra a versão correta e recém-modificada-lock = False:

root@magrathea:/system/zones# pkg facet -a | grep version-lock.shell/bash
version-lock.shell/bash                                          False local

Solução alternativa:

Conforme meu comentário abaixo, estou resolvendo esse problema instalando minha zona de ouro com o manifesto auto_install personalizado que inclui <facet set="false">facet.version-lock.*</facet> .

Isso funciona bem (embora ao custo de desbloquear todos bloqueios de versão, em vez de apenas aqueles que têm atualizações FOSS), mas ainda seria bom saber se há uma maneira de fazer facetas herdar entre globals e não-globais, como a documentação parece indicar que devem.

Obrigado antecipadamente.

    
por TheBloke 03.06.2017 / 13:34

1 resposta

1

Sou um dos principais autores e designers do Image Packaging System.

Eu imagino que sua confusão é devido a um mal-entendido do que a documentação diz. Em particular, observe cuidadosamente o que esta frase de pkg (5) diz:

...a non-global zone can inherit a facet from the global zone. Inherited facets are evaluated before, and take priority over, any locally set facets.

Observe que pode , não será . Portanto, a documentação descreve o que acontecerá quando as facetas forem herdadas, mas intencionalmente (acredito) não declarará quando elas serão herdadas. Isto é, ele diz a você como determinar se eles são herdados (procurando por "pai" na coluna SRC de "faceta pkg"), mas não sob quais condições eles serão herdados:

link

Agora, para a parte que falta - em geral, as facetas herdadas só costumam se aplicar às facetas facet.version-lock. * usadas em pacotes, porque alguns dos pacotes relacionados possuem dependências pai em si mesmas assim:

depend type=parent fmri=feature/package/dependency/self

Uma dependência pai, expressa como acima, simplesmente afirma que para instalar este pacote em uma região não global, o mesmo pacote deve estar presente na mesma versão na região global primeiro. Isso é usado para pacotes que devem estar em sincronia entre as zonas global e não global.

Em suma, a herança geralmente não se aplica à maioria das facetas. A lógica para determinar quais facetas serão herdadas pode ser encontrada aqui:

link

Isso foi intencional porque as zonas são uma tecnologia de contêiner destinada a permitir ambientes isolados nos quais os administradores podem configurar configurações diferentes da região global.

Agora, com isso dito, se você quiser aplicar uma operação de faceta de mudança à região global e a todas as regiões não globais, poderá fazê-lo usando o '-r' (recursivo) opção para mudar de faceta:

pkg change-facet -r ...

(Veja pkg (1), já que aparentemente não posso postar mais de dois links.)

Você pode até aplicá-lo a zonas específicas usando -z.

Ah, e finalmente, você realmente não quer definir as facetas como False para todos os bloqueios de versão. Isso não apenas tornará o sistema incrivelmente lento para a atualização, mas você perderá todos os dispositivos de segurança que garantem que você esteja realmente usando uma combinação de componentes testada.

    
por 09.06.2017 / 03:15