Apêndice B Requisitos de embalagem SVR4 adicionais (Referência)

Este apêndice é para os administradores de sistema que instalam ou removem pacotes, especialmente pacotes de terceiros. Seguir esses requisitos de empacotagem permite o seguinte:

• Evita alterar o atual sistema em execução para que você possa atualizar com o Solaris Live Upgrade e criar e manter as regiõs não-globais e clientes sem discos.

• Impede que um pacote seja interativo para automatizar as instalações ao utilizar programas de instalação tais como o JumpStart personalizável.

Este capítulo contém os seguintes tópicos.

• Impedir Alteração do sistema operacional atual..

• Impedindo interação de usuário ao instalar ou atualizar.

• Definindo parâmetros de pacote para regiões

Impedir Alteração do sistema operacional atual.

Seguir os requisitos nesta seção mantém inalterado o sistema operacional atualmente em execução.

Utilizando caminhos absolutos

Para a instalação de um sistema operacional ser bem sucedida, os pacotes devem reconhecer e respeitar corretamente os sistemas de arquivos da raiz alternativa (/), tais como o Solaris Live Upgrade um ambiente de inicialização inativo.

Os pacotes podem incluir caminhos absolutos em seus arquivos pkgmap (mapa de pacotes). Se estes arquivos existirem, eles são gravados em relação à opção-Rdo comandopkgadd. Os pacotes que contenham ambos os caminhos absolutos e relativos (relocalizável) também podem ser instalados em uma sistema de arquivos de raiz alternativa (/). $PKG_INSTALL_ROOT é incluído no início de arquivos absolutos e relocalizáveis para que todos os caminhos sejam resolvidos apropriadamente ao estiverem sendo instalados por pkgadd.

Utilizando o comando pkgadd -R

Os pacotes que estão sendo instalados utilizando a opção pkgadd -R ou que estão sendo excluídos utilizando a opção pkgrm -R não devem alterar o atual sistema em execução. Esse recurso é utilizado por JumpStart personalizado, Solaris Live Upgrade, regiões não-globais e um cliente sem disco.

Quaisquer scripts de procedimento que estão incluídos nos pacotes sendo instalados com o comando pkgadd opção -R ou que estão sendo excluídos utilizando o comando pkgrm opção -R não devem alterar o atual sistema em execução. Quaisquer scripts de instalação fornecidos devem fazer referência a qualquer diretório ou arquivo que é prefixado com a variável $PKG_INSTALL_ROOT. O pacote deve gravar todos os diretórios e arquivos com o prefixo $PKG_INSTALL_ROOT. O pacote não deve excluir diretórios sem o prefixo $PKG_INSTALL_ROOT.

Tabela B–1 fornece exemplos de sintaxe de script.

if [ -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf ] ; then

if [ -f /etc/myproduct.conf ] ; \
 then

/bin/rm -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf

/bin/rm -f /etc/myproduct.conf 

echo "test=no" > ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf

echo "test=no" > \
/etc/myproduct.conf

Diferenças entre $PKG_INSTALL_ROOT e vista geral $BASEDIR

$PKG_INSTALL_ROOT é a localização do sistema de arquivos raiz(/) da máquina à qual o pacote está sendo adicionado. O local é configurado para o argumento -R do comando pkgadd. Por exemplo, se o seguinte comando for invocado, então $PKG_INSTALL_ROOT torna-se /a durante a instalação do pacote.

# pkgadd -R /a SUNWvxvm

$BASEDIR aponta para o diretório base relocalizável no qual os objetos de pacote relocalizáveis estão instalados. Apenas objetos relocalizáveis são instalados aqui. Objetos não-relocalizáveis (aqueles que possuem caminhos absolutos no arquivo pkgmap) são sempre instalados em relação ao ambiente de inicialização inativo, mas não em relação ao $BASEDIR em vigor. Se um pacote não possui objetos relocalizáveis, então diz-se que o pacote é um pacote absoluto (ou não-relocalizável) e $BASEDIR é indefinido e não está disponível para empacotar scripts de procedimento.

Por exemplo, suponha que o arquivo do pacote pkgmap possua duas entradas:

1 f none sbin/ls 0555 root sys 3541 12322 1002918510
1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332

O arquivo pkginfo possui uma especificação para $BASEDIR :

BASEDIR=/opt

Se este pacote está instalado com o seguinte comando, então, ls está instalado em /a/opt/sbin/ls, mas ls2 está instalado como /a/sbin/ls2.

# pkgadd -R /a SUNWtest

Diretrizes para escrever scripts

Seu pacote de scripts de procedimento deve ser independente do sistema operacional atualmente em execução para impedir a modificação do mesmo. Os scripts de procedimento definem as ações que ocorrem em determinados pontos durante a instalação e remoção do pacote. Quatro scripts de procedimento podem ser criados com esses nomes pré-definidos:preinstall, postinstall, preremove, e postremove.

Mantendo a compatibilidade do cliente sem disco

Os pacotes não devem executar comandos emitidos pelo próprio pacote. Isto é para manter a compatibilidade do cliente sem disco e evitar comandos em execução que possam exigir as bibliotecas compartilhadas que ainda não estão instaladas.

Verificando pacotes

Todos os comandos devem passar a validação pkgchk. Após um pacote ser criado e antes de ser instalado, ele deve ser verificado com o seguinte comando.

# pkgchk -d dir_name pkg_name

dir_name

Especifica o nome do diretório onde reside o pacote

pkg_name

Especifica o nome do pacote

Exemplo B–1 Testando um pacote

Depois de um pacote ser criado, ele deve ser testado ao instalá-lo em um local de sistema de arquivos raiz alternativo (/) utilizando a opção - R dir_name para pkgadd. Depois que o pacote for instalado, ele deve ser verificado quanto à correção, utilizando pkgchk, como neste exemplo.

# pkgadd -d . -R /a SUNWvxvm
# pkgchk -R /a SUNWvxvm

Nenhum erro deve ser exibido.

Exemplo B–2 Testando um pacote em /export/SUNWvxvm

Se um pacote existe em /export/SUNWvxvm, então é necessário emitir o seguinte comando.

# pkgchk -d /export SUNWvxvm

Nenhum erro deve ser exibido.

Outros comandos podem verificar o pacote quando você criar, modificar e excluir arquivos. Os comandos a seguir são alguns exemplos.

• Por exemplo, os comandos dircmp ou fssnap podem ser utilizados para verificar se os pacotes se comportam corretamente.

• Além disso, o comando ps pode ser utilizado para testar a conformidade daemon, assegurando-se daemons não são interrompidos ou iniciados pelo pacote.

• Os comandos truss, pkgadd -v epkgrm podem testar a conformidade da instalação do pacote em tempo de execução, mas pode não funcionar em todas as situações. No exemplo a seguir, o comando truss retira todos os acessos de somente leitura, não-$TEMPDIR e mostra apenas acessos que não são somente leitura a caminhos que não estão situados dentro do ambiente de inicialização inativo especificado.

# TEMPDIR=/a; export TEMPDIR
# truss -t open /usr/sbin/pkgadd -R ${TEMPDIR} SUNWvxvm \
2>&1 > /dev/null | grep -v O_RDONLY | grep -v \
'open("'${TEMPDIR}

Impedindo interação de usuário ao instalar ou atualizar

Os pacotes devem ser adicionados ou removidos sem que o usuário seja solicitado a fornecer informações ao utilizar os utilitários padrão do Solaris a seguir.

• O programa personalizado JumpStart

• Solaris Live Upgrade

• programa Instalação do Solaris

• Solaris Zones

Para testar um pacote para assegurar-se de que ele irá instalar, sem interação do usuário, um novo arquivo de administração pode ser configurado com o comando pkgadd opção - a. A opção -a define um arquivo de administração de instalação a ser utilizado no lugar do arquivo de administração padrão. Utilizar o arquivo padrão pode resultar no usuário sendo solicitado a fornecer mais informações. É possivel criar um arquivo de administração, que indica para pkgadd que deveria ignorar essas verificações e instalar o pacote sem a confirmação do usuário. Para obter detalhes, consulte a página do manual admin(4) ou pkgadd(1M).

Os exemplos a seguir mostram como o comando pkgadd utiliza o arquivo de administração.

• Se nenhum arquivo de administração for fornecidopkgadd utiliza /var/sadm/install/admin/default. Utilizar este arquivo pode resultar na interação de usuário.

  # pkgadd

• Se um arquivo de administração relativo é fornecido na linha de comando,pkgadd procura no/var/sadm/install/admin pelo nome do arquivo e o utiliza. Neste exemplo, o arquivo de administração relativo é nomeado nocheck e pkgadd procura por/var/sadm/install/admin/nocheck.

  # pkgadd -a nocheck

• Se um arquivo absoluto é fornecido, o pkgadd o utiliza. Neste exemplo, pkgadd procura no /tmp pelo arquivo de administração nocheck.

  # pkgadd -a /tmp/nocheck

Exemplo B–3 Arquivo de administração de instalação

A seguir temos um exemplo de um arquivo de administração de instalação que exige uma pequena interação do usuário com o utilitáriopkgadd. A menos que o pacote necessite de mais espaço do que está disponível no sistema, o utilitário pkgadd utiliza esse arquivo e instala o pacote sem solicitar mais informações do usuário.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
space=ask
setuid=nocheck
confiict=nocheck
action=nocheck
basedir=default

Definindo parâmetros de pacote para regiões

Pacotes têm parâmetros que controlam como seu conteúdo é distribuído e tornado visível em um sistema com regiões não globais instaladas. Os parâmetros de pacote SUNW_PKG_ALLZONES , SUNW_PKG_HOLLOW e SUNW_PKG_THISZONE definem as características de pacotes em um sistema com regiões instaladas. Estes parâmetros devem ser definidos para que os pacotes possam ser administrados em um sistema com regiões não-globais.

A tabela abaixo lista as quatro combinações válidas para definir parâmetros de pacote. Se escolher definir combinações que não estejam listadas na tabela abaixo, essas configurações serão inválidas e resultará na falha ao instalar o pacote.

Assegure-se de ter definido todos os três parâmetros de pacote. Você pode deixar em branco todos os três parâmetros de pacote. As ferramentas de pacote interpretam um parâmetro faltante do pacote de região como se a configuração fosse "falsa", mas não é recomendável não definir os parâmetros. Ao definir todos os três parâmetros de pacote, você especifica o comportamento exato que as ferramentas de pacote devem exibir ao instalar ou remover o pacote.

Para obter informações em segundo plano

As referências a seguir fornecem informações em segundo plano sobre os requisitos de empacotamento e sintaxe de comando específico.