Ignorar Links de Navegao | |
Sair do Modo de Exibio de Impresso | |
Guia do desenvolvedor de empacotamento de aplicativos Oracle Solaris 10 1/13 Information Library (Português (Brasil)) |
3. Melhorando a funcionalidade de um pacote (Tarefas)
4. Verificando e transferindo um pacote
5. Estudos de caso de criação de pacote
6. Técnicas avançadas para a criação de pacotes
Especificando o diretório base
O arquivo de padrões administrativos
Conformando-se com a incerteza
Usando diretórios base paramétricos
Exemplo -- Scripts de análise que deslocam um BASEDIR
Usando caminhos paramétricos relativos
Exemplo -- Um script request que desloca um caminho paramétrico relativo
Oferecendo suporte a relocação em um ambiente heterogêneo
Exemplo - Um pacote relocável tradicional
Exemplo - Um pacote absoluto tradicional
Exemplo - Uma solução tradicional
Outra consideração sobre os pacotes compostos
Fazendo nomes de caminho absolutos parecer relocáveis
Exemplo -- Modificando um arquivo
Exemplo -- Criando um novo arquivo
Tornando os pacotes instaláveis remotamente
Exemplo - Instalando em um sistema cliente
Exemplo - Instalando em um sistema servidor ou independente
Exemplo - Montando sistemas de arquivos compartilhados
Atualizando com patches os pacotes
Criando pacotes de arquivo de classe
Estrutura do diretório do pacote de arquivo
Palavras-chave para oferecer suporte aos pacotes de arquivo de classe
Você pode usar vários métodos para especificar onde um pacote será instalado e é importante poder alterar a base de instalação dinamicamente no tempo de instalação. Se isto for atingido satisfatoriamente, um administrador pode instalar várias versões e várias arquiteturas se complicações.
Esta seção trata primeiro dos métodos comuns, depois das abordagens que melhoram as instalações em sistemas heterogêneos.
Os administradores responsáveis pela instalação de pacotes podem usar arquivos de administração para controlar a instalação do pacote. No entanto, como criador de pacotes, você precisa conhecer os arquivos de administração e saber como um administrador pode alterar a instalação pretendida do pacote.
Um arquivo de administração diz ao comando pkgadd se ele deve realizar as verificações ou solicitações que normalmente realiza. Conseqüentemente, os administradores devem entender por completo o processo de instalação do pacote e os scripts envolvidos antes de usar os arquivos de administração.
Um arquivo de padrões administrativos é entregue com o sistema operacional SunOS em /var/sadm/install/admin/default. Trata-se do arquivo que estabelece o nível mais básico de regras administrativas com relação à instalação de produtos de software. O arquivo apresenta a seguinte aparência quando entregue:
#ident "@(#)default 1.4 92/12/23 SMI" /* SVr4.0 1.5.2.1 */ mail= instance=unique partial=ask runlevel=ask idepend=ask rdepend=ask space=ask setuid=ask conflict=ask action=ask basedir=default
O administrador pode editar este arquivo para estabelecer novos comportamentos padrões, ou criar um arquivo de administração e especificar sua existência usando a opção -a no comando pkgadd.
Podem ser definidos onze parâmetros no arquivo de administração, mas nem todos precisam ser definidos. Para obter mais informações, consulte admin(4).
O parâmetro basedir especifica como o diretório base será obtido quando um pacote for instalado. A maioria dos administradores o mantém como padrão, mas basedir pode ser definido como:
ask, que significa sempre pedir que o administrador indique um diretório base
Um nome de caminho absoluto
Um nome de caminho absoluto contendo a construção $PKGINST, que significa instalar sempre em um diretório base obtido da instância do pacote
Observação - Se o comando pkgadd for chamado com o argumento - a none, ele sempre pede que o administrador indique um diretório base. Infelizmente, isso também define todos os parâmetros do arquivo com o valor padrão quit, que pode causar problemas adicionais.
Um administrador tem controle sobre todos os pacotes que estão sendo instalados em um sistema usando o arquivo de administração. Infelizmente, um arquivo de padrões administrativos alternativo é, com freqüência, fornecido pelo criador de pacotes, ignorando os desejos do administrador.
Os criadores de pacotes incluem, às vezes, um arquivo de administração alternativo para que eles, e não o administrador, controlem a instalação de um pacote. Por substituir todos os diretórios base, a entrada basedir do arquivo de padrões administrativos proporciona um método simples para selecionar o diretório base apropriado no tempo de instalação. Em todas as versões do SO Oracle Solaris anteriores à versão Solaris 2.5, esse era considerado um método mais simples de controlar o diretório de base.
Entretanto, é necessário aceitar os desejos do administrador com relação à instalação do produto. Proporcionar um arquivo de padrões administrativos temporário para fins de controle de instalação leva a uma desconfiança por parte dos administradores. Você deve usar um script request e um script checkinstall para controlar estas instalações sob a supervisão do administrador. Se o script request envolver fielmente o administrador no processo, o empacotamento System V servirá tanto aos administradores como aos criadores de pacotes.
O arquivo pkginfo de qualquer pacote relocável deve incluir um diretório base padrão em forma de entrada como esta:
BASEDIR=absolute_path
Este é o único diretório base padrão. Ele pode ser alterado pelo administrador durante a instalação.
Enquanto alguns pacotes requerem mais de um diretório base, a vantagem de usar este parâmetro para posicionar o pacote está no fato de que garante que o diretório base esteja na sua posição e seja gravável como um diretório válido no momento em que a instalação começar. O caminho correto para o diretório base do servidor e do cliente está disponível para todos os scripts de procedimento na forma de variáveis de ambiente reservadas, e o comando pkginfo -r SUNWstuf exibe a base de instalação atual do pacote.
No script checkinstall, BASEDIR é o parâmetro exatamente conforme definido no arquivo pkginfo (ele ainda foi condicionado). A fim de inspecionar o diretório de destino base, a construção ${PKG_INSTALL_ROOT}$BASEDIR é necessária. Isso significa que o script request ou checkinstall podem alterar o valor de BASEDIR no ambiente de instalação com resultados previsíveis. Neste momento o script preinstall é chamado, o parâmetro BASEDIR é o indicador completamente condicionado do diretório base real no sistema de destino, mesmo que o sistema for um cliente.
Observação - O script request utiliza o parâmetro BASEDIR de forma diferente em diferentes versões do sistema operacional SunOS. A fim de testar um parâmetro BASEDIR em um script request, o seguinte código deve ser usado para determinar o diretório base real em uso.
# request script constructs base directory if [ ${CLIENT_BASEDIR} ]; then LOCAL_BASE=$BASEDIR else LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR fi
Se um pacote precisar de vários diretórios base, você pode estabelecê-los com nomes de caminho paramétricos. Este método tem se tornado muito popular, embora apresente as desvantagens seguintes.
Um pacote com nomes de caminho paramétricos se comporta geralmente como um pacote absoluto, mas é tratado pelo comando pkgadd como um pacote relocável. O parâmetro BASEDIR deve ser definido mesmo que não seja usado.
O administrador não pode verificar a base de instalação do pacote usando os utilitários System V (o comando pkginfo -r não funcionará).
O administrador não pode usar o método estabelecido para relocar o pacote (é denominado relocável, mas age como absoluto).
As instalações de várias arquiteturas e várias versões requerem plano de contingência para cada um dos diretórios de destino base, o que significa freqüentemente vários scripts de ação de classe complexos.
Embora os parâmetros que determinam os diretórios base sejam definidos no arquivo pkginfo, eles podem ser modificados pelo script request. Esta é uma das principais razões da popularidade desta abordagem. As desvantagens, entretanto, são crônicas e esta configuração deve ser levada em consideração em último caso.
# 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=/ EZDIR=/usr/stuf/EZstuf HRDDIR=/opt/SUNWstuf/HRDstuf VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert980707141632
: 1 1758 1 d none $EZDIR 0775 root bin 1 f none $EZDIR/dirdel 0555 bin bin 40 773 751310229 1 f none $EZDIR/usrdel 0555 bin bin 40 773 751310229 1 f none $EZDIR/filedel 0555 bin bin 40 773 751310229 1 d none $HRDDIR 0775 root bin 1 f none $HRDDIR/mksmart 0555 bin bin 40 773 751310229 1 f none $HRDDIR/mktall 0555 bin bin 40 773 751310229 1 f none $HRDDIR/mkcute 0555 bin bin 40 773 751310229 1 f none $HRDDIR/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
Os pacotes disponíveis em várias versões ou de várias arquiteturas devem ser criados para deslocar o diretório base, se necessário. Deslocar um diretório base significa que, se já existir uma versão anterior ou uma arquitetura diferente do pacote que estiver sendo instalado no diretório base, o pacote resolve este problema, criando talvez um novo diretório base com um nome levemente diferente. Os scripts request e checkinstall do Solaris 2.5 e versões compatíveis têm a capacidade de modificar a variável de ambiente BASEDIR. Isso não é válido para as versões anteriores do sistema operacional Oracle Solaris.
Mesmo em versões mais antigas do sistema operacional do Oracle Solaris, o script request tem a autoridade para redefinir os diretórios que estão na base de instalação. O script request pode fazê-lo de uma forma que ainda oferece suporte à maioria das preferências administrativas.