Oferecendo suporte a relocação em um ambiente heterogêneo
O conceito original do empacotamento System V pressupõe uma arquitetura por sistema. O conceito de um servidor não tinha um papel importante na criação. Agora, é claro, um único servidor pode oferecer suporte a várias arquiteturas, o que significa que pode haver várias cópias de um mesmo software em um servidor, cada uma de uma arquitetura diferente. Embora os pacotes do Solaris estejam isolados dentro dos limites do sistema de arquivos recomendado (por exemplo, / e /usr), com os bancos de dados do produto no servidor, bem como em cada cliente, nem todas as instalações oferecem necessariamente suporte a esta divisão. Determinadas implementações oferecem suporte a uma estrutura completamente diferente e abrangem um banco de dados comum do produto. Embora seja simples indicar aos clientes diferentes versões, instalar pacotes System V em diferentes diretórios base pode realmente causar complicações ao administrador.
Ao criar seu pacote, você deve também levar em consideração os métodos comuns usados pelos administradores para introduzir novas versões de software. Os administradores procuram freqüentemente instalar e testar a última versão lado-a-lado com a versão atualmente instalada. O procedimento envolve a instalação da nova versão em um diretório base diferente do diretório da versão atual e o envio de uma nova versão a um grupo de clientes não-críticos como teste. Assim como as construções de confiança, o administrador reenvia a mais e mais clientes a nova versão. Eventualmente, o administrador retém a versão antiga somente para emergências e, em seguida, finalmente a exclui.
Isso significa que os pacotes destinados a sistemas heterogêneos modernos devem oferecer suporte a relocações verdadeiras, o quer dizer que o administrador pode colocá-los em qualquer lugar razoável do sistema de arquivos e ainda obter total funcionalidade. O Solaris 2.5 e versões compatíveis oferecem várias ferramentas úteis que permitem a instalação perfeita de várias arquiteturas e versões no mesmo sistema. O Solaris 2.4 e versões compatíveis também oferecem suporte à relocação verdadeira, mas a conclusão das tarefas não é tão evidente.
Abordagem tradicional
Pacotes relocáveis
A ABI do System V dá a entender que a intenção original do pacote relocável era tornar a instalação do pacote mais fácil para o administrador. Agora, a necessidade em ter pacotes relocáveis vai mais além. A facilidade não é o único fim, é mais apropriado dizer que é bem possível que, durante a instalação, um produto de software ativo já esteja instalado no diretório padrão. Um pacote que não está desenhado para lidar com este tipo de situação, ou substitui o produto existente ou falha ao instalar. Entretanto, um pacote desenhado para manipular várias arquiteturas e versões pode ser instalado tranqüilamente e oferece ao administrador uma grande variedade de opções totalmente compatíveis com as tradições administrativas existentes.
De alguma forma, o problema das arquiteturas e versões múltiplas é o mesmo. Deve ser possível instalar uma variante do pacote existente lado-a-lado com outras variantes, e conduzir os clientes e os consumidores independentes de sistemas de arquivos exportados a qualquer uma destas variantes sem perda de funcionalidade. Embora a Sun tenha estabelecido métodos para lidar com várias arquiteturas em um servidor, o administrador pode não se ater a tais recomendações. Todos os pacotes precisam ser capazes de satisfazer os desejos sensatos dos administradores em relação à instalação.
Exemplo - Um pacote relocável tradicional
Este exemplo mostra a aparência de um pacote relocável tradicional. O pacote será colocado em /opt/SUNWstuf, e os arquivos pkginfo e pkgmap podem ter a seguinte aparência.
O arquivo pkginfo
# pkginfo file PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/opt VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert990707141632 |
O arquivo pkgmap
: 1 1758 1 d none SUNWstuf 0775 root bin 1 d none SUNWstuf/EZstuf 0775 root bin 1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none SUNWstuf/HRDstuf 0775 root bin 1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
A isso se refere como método tradicional porque cada objeto de pacote é instalado no diretório base definido pelo parâmetro BASEDIR do arquivo pkginfo. Por exemplo, o primeiro objeto do arquivo pkgmap é instalado como o diretório /opt/SUNWstuf.
Pacotes absolutos
Um pacote absoluto é aquele que é instalado em um determinado sistema de arquivos raiz (/). É difícil lidar com estes pacotes do ponto de vista de arquiteturas e versões múltiplas. Como regra geral, todos os pacotes devem ser relocáveis. Há, no entanto, razões muito boas para incluir elementos absolutos em um pacote relocável.
Exemplo - Um pacote absoluto tradicional
Se o pacote SUNWstuf fosse um pacote absoluto, o parâmetro BASEDIR não deveria estar no arquivo pkginfo e o arquivo pkgmap teria a seguinte aparência.
O arquivo pkgmap
: 1 1758 1 d none /opt ? ? ? 1 d none /opt/SUNWstuf 0775 root bin 1 d none /opt/SUNWstuf/EZstuf 0775 root bin 1 f none /opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none /opt/SUNWstuf/HRDstuf 0775 root bin 1 f none /opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
Neste exemplo, se o administrador tivesse especificado um diretório base alternativo durante a instalação, ele seria ignorado pelo comando pkgadd. Este pacote é instalado sempre no /opt/SUNWstuf do sistema de destino.
O argumento -R do comando pkgadd funciona conforme o previsto. Por exemplo,
pkgadd -d . -R /export/opt/client3 SUNWstuf |
instala os objetos em /export/opt/client3/opt/SUNWstuf. Porém, isso é o mais perto que este pacote chega de ser um pacote relocável.
Observe o uso do ponto de interrogação (?) no diretório /opt do arquivo pkgmap. Isso indica que os atributos existentes não devem ser alterados. Não significa “criar o diretório com atributos padrão”, embora sob certas circunstâncias isso possa ocorrer. Qualquer diretório específico de um novo pacote deve especificar todos os atributos explicitamente.
Pacotes compostos
Qualquer pacote que contenha objetos relocáveis é denominado de pacote relocável. Isso pode induzir a erros porque um pacote relocável pode conter caminhos absolutos em seu arquivo pkgmap. O uso de uma entrada raiz (/) em um arquivo pkgmap pode melhorar os aspectos relocáveis do pacote. Os pacotes que possuem entradas raiz e relocáveis são denominados pacotes compostos.
Exemplo - Uma solução tradicional
Suponha que um objeto do pacote SUNWstuf seja um script de início executado no nível de execução 2. O arquivo /etc/rc2.d/S70dostuf precisa ser instalado como parte do pacote, mas não pode ser colocado no diretório base. Pressupondo que um pacote relocável seja a única solução, os arquivos pkginfo e pkgmap podem ter a seguinte aparência.
O arquivo pkginfo
# pkginfo file PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/ VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert990707141632 |
O arquivo pkgmap
: 1 1758 1 d none opt/SUNWstuf/EZstuf 0775 root bin 1 f none opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none opt/SUNWstuf/HRDstuf 0775 root bin 1 f none opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none etc ? ? ? 1 d none etc/rc2.d ? ? ? 1 f none etc/rc2.d/S70dostuf 0744 root sys 450 223443 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
Não há muita diferença entre esta abordagem e a abordagem do pacote absoluto. De fato, estaria melhor como um pacote absoluto — se o administrador fornecesse um diretório base alternativo a este pacote, ele não funcionaria!
Na verdade, somente um arquivo deste pacote precisa estar relacionado à raiz, o restante pode ser movido para qualquer lugar. Como resolver este problema através do uso de um pacote composto é um tema tratado no restante desta seção.
Não tradicional
A abordagem descrita nesta seção não se aplica a todos os pacotes, mas tem como resultado melhor desempenho durante a instalação em um ambiente heterogêneo. Uma pequena parte se aplica a pacotes entregues como parte do sistema operacional Solaris (pacotes incorporados). Entretanto, os pacotes avulsos podem praticar empacotamento não tradicional.
A razão pela qual se encoraja o uso de pacotes relocáveis é oferecer suporte a este requisito:
Quando um pacote é adicionado ou removido, os comportamentos desejáveis existentes dos produtos de software instalados não serão alterados.
Os pacotes avulsos devem estar em /opt de modo a garantir que o novo pacote não interfira nos produtos existentes.
Outra consideração sobre os pacotes compostos
Há duas regras a seguir ao construir um pacote composto funcional:
-
Estabelecer o diretório base baseado em aonde vai a grande maioria dos objetos de pacote.
-
Se um objeto de pacote for para um diretório comum que não é o diretório base (por exemplo, /etc), especifique-o como nome de caminho absoluto no arquivo prototype.
Em outras palavras, visto que “relocável” significa que o objeto pode ser instalado em qualquer parte e ainda funcionar, nenhum script de início executado por init no tempo de inicialização pode ser considerado relocável! Embora não exista nada de errado em especificar /etc/passwd como um caminho relativo no pacote entregue, há somente um lugar para o qual ele pode ir.
Fazendo nomes de caminho absolutos parecer relocáveis
Se for construir um pacote composto, os caminhos absolutos devem operar de modo que não interfiram no software instalado. Um pacote que pode estar totalmente contido em /opt contorna este problema, já que não há arquivos existentes no meio do caminho. Quando um arquivo em /etc estiver incluído no pacote, você deve garantir que nomes de caminho absolutos se comportem da mesma forma que os nomes de caminho relativos. Leve em consideração os dois exemplos seguintes.
Exemplo — Modificando um arquivo
Descrição
Uma entrada está sendo adicionada a uma tabela, ou o objeto é uma nova tabela que será provavelmente modificada por outros programas ou pacotes.
Implementação
Defina o objeto como tipo de arquivo e e pertencente à classe build, awk ou sed. O script que realiza esta tarefa deve remover a si mesmo de maneira tão eficaz como quando se adiciona.
Exemplo
Uma entrada precisa ser adicionada a /etc/vfstab em apoio ao novo disco rígido de estado sólido.
A entrada no arquivo pkgmap pode ser
1 e sed /etc/vfstab ? ? ? |
O script request pergunta ao operador se /etc/vfstab deve ser modificado pelo pacote. Se o operador responder “não”, então o script request imprimirá as instruções sobre como realizar o trabalho manualmente e executará
echo "CLASSES=none" >> $1 |
Se o operador responder “sim”, então ele executa
echo "CLASSES=none sed" >> $1 |
que ativa o script de ação de classe que fará as modificações necessárias. A classe sed significa que o arquivo de pacote /etc/vfstab é um programa sed que contém as operações de instalação e remoção do arquivo com o mesmo nome no sistema de destino.
Exemplo — Criando um novo arquivo
Descrição
O objeto é um arquivo totalmente novo que provavelmente não será editado mais adiante ou está substituindo um arquivo de outro pacote.
Implementação
Defina o objeto de pacote como tipo de arquivo f e o instale usando um script de ação de classe capaz de desfazer alterações.
Exemplo
Um novo arquivo de marca é requerido em /etc para proporcionar as informações necessárias para suportar o disco rígido de estado sólido, denominado /etc/shdisk.conf . A entrada no arquivo pkgmap pode ter esta aparência:
. . . 1 f newetc /etc/shdisk.conf . . . |
O script de ação de classe i.newetc é responsável pela instalação e por qualquer outro arquivo que precise ir para /etc. Ele faz a verificação para se certificar de que não exista outro arquivo lá. Se não existir, ele simplesmente copia o novo arquivo no local. Se já existir um arquivo no local, ele fará o backup do arquivo existente antes de instalar o novo arquivo. O script r.newetc remove estes arquivos e restaura os originais, se requerido Abaixo se encontra o fragmento principal do script de instalação.
# i.newetc
while read src dst; do
if [ -f $dst ]; then
dstfile=`basename $dst`
cp $dst $PKGSAV/$dstfile
fi
cp $src $dst
done
if [ "${1}" = "ENDOFCLASS" ]; then
cd $PKGSAV
tar cf SAVE.newetc .
$INST_DATADIR/$PKG/install/squish SAVE.newetc
fi
|
Observe que este usa a variável de ambiente PKGSAV para armazenar o backup do arquivo que será substituído. Quando o argumento ENDOFCLASS é passado para o script, isso quer dizer que o comando pkgadd informa o script que estas são as últimas entradas desta classe, momento em que o script arquiva e compacta os arquivos salvos usando um programa privado de compactação armazenado no diretório de instalação do pacote.
Embora o uso da variável de ambiente PKGSAV não seja confiável durante a atualização de um pacote, se o pacote não for atualizado (através de um patch, por exemplo), o arquivo de backup é seguro. O seguinte script de remoção inclui o código para lidar com outros problemas — o fato de que as versões antigas do comando pkgrm não passem para os scripts o caminho correto da variável de ambiente PKGSAV.
O script de remoção pode ter esta aparência.
# r.newetc
# make sure we have the correct PKGSAV
if [ -d $PKG_INSTALL_ROOT$PKGSAV ]; then
PKGSAV="$PKG_INSTALL_ROOT$PKGSAV"
fi
# find the unsquish program
UNSQUISH_CMD=`dirname $0`/unsquish
while read file; do
rm $file
done
if [ "${1}" = ENDOFCLASS ]; then
if [ -f $PKGSAV/SAVE.newetc.sq ]; then
$UNSQUISH_CMD $PKGSAV/SAVE.newetc
fi
if [ -f $PKGSAV/SAVE.newetc ]; then
targetdir=dirname $file # get the right directory
cd $targetdir
tar xf $PKGSAV/SAVE.newetc
rm $PKGSAV/SAVE.newetc
fi
fi
|
Este script usa um algoritmo privado desinstalado (unsquish) que está no diretório de instalação do banco de dados do pacote. Isso é feito automaticamente pelo comando pkgadd no tempo de instalação. Todos os scripts não reconhecidos especificamente como somente de instalação pelo comando pkgadd são deixados neste diretório para serem usados pelo comando pkgrm. Você não pode saber onde tal diretório está, mas pode ter certeza de que está fixo e contém todos os arquivos de informação e scripts de instalação necessários do pacote. O script encontra o diretório devido ao fato de que o script de ação de classe está com certeza sendo executado a partir do diretório que contém o programa unsquish.
Observe, também, que este script não apenas supõe que o diretório de destino é /etc. Ele pode realmente estar em /export/root/client2/etc . O diretório correto pode ser construído de duas formas.
-
Use a construção ${PKG_INSTALL_ROOT}/etc, ou.
-
Tome o nome do diretório de um arquivo passado pelo comando pkgadd (que é o que esse script faz).
Usando esta abordagem para cada objeto absoluto do pacote, você pode ter certeza de que o comportamento atual desejável é inalterado ou, pelo menos, recuperável.
Exemplo — Um pacote composto
Abaixo se encontra um exemplo dos arquivos pkginfo e pkgmap de um pacote composto.
O arquivo pkginfo
PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/opt VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none daemon PSTAMP=hubert990707141632 |
O arquivo pkgmap
: 1 1758 1 d none SUNWstuf/EZstuf 0775 root bin 1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none SUNWstuf/HRDstuf 0775 root bin 1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none /etc ? ? ? 1 d none /etc/rc2.d ? ? ? 1 e daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443 1 i i.daemon 509 39560 752978103 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 1 i r.daemon 320 24573 742152591 |
Enquanto S70dostuf pertence à classe daemon, os diretórios que lidam com ele (que já estão no local no tempo de instalação) pertencem à classe none. Mesmo se os diretórios forem exclusivos deste pacote, você deve deixá-los na classe none. A razão disso é que os diretórios precisam ser criados primeiro e excluídos por último, e tal ação é sempre válida para a classe none. O comando pkgadd cria diretórios. Eles não são copiados do pacote e não são passados a um script de ação de classe a ser criado. Em vez disso, eles são criados pelo comando pkgadd antes que ele chame o script de ação de classe de instalação, e o comando pkgrm exclui os diretórios após a conclusão do script de ação de classe de remoção.
Isso significa que, se um diretório de uma classe especial contiver objetos na classe none, quando o comando pkgrm tenta remover o diretório, ele falha porque o diretório não estará vazio a tempo. Se um objeto de classe none estiver para ser inserido em um diretório de alguma classe especial, tal diretório não existirá a tempo para aceitar o objeto. O comando pkgadd não criará o diretório instantaneamente durante a instalação do objeto e pode não ser capaz de sincronizar os atributos de tal diretório quando exibir finalmente a definição de pkgmap.
Observação –
Ao atribuir um diretório a uma classe, lembre-se sempre da ordem de criação e exclusão.
- © 2010, Oracle Corporation and/or its affiliates