Capítulo 3 Melhorando a funcionalidade de um pacote (Tarefas)

Este capítulo descreve como criar arquivos de informação opcionais e scripts de instalação em um pacote. Enquanto o Capítulo 2Construindo um pacote aborda os requisitos mínimos para criar um pacote, este capítulo aborda a funcionalidade adicional que você pode construir em um pacote. Esta funcionalidade adicional está baseada no critério que você considerou ao planificar como criar o pacote. Para obter mais informações, consulte Considerações antes de construir um pacote.

A lista abaixo traz as informações gerais encontradas neste capítulo.

• Criando arquivos de informação e scripts de instalação (Mapa de tarefas)

• Criando arquivos de informação

• Criando scripts de instalação

• Criando pacotes assinados

Criando arquivos de informação e scripts de instalação (Mapa de tarefas)

O mapa de tarefas seguinte descreve os recursos opcionais que você pode construir em um pacote.

Criando arquivos de informação

Esta seção trata dos arquivos de informação opcionais do pacote. Com estes arquivos você pode definir as dependências do pacote, fornecer uma mensagem de copyright ou reservar espaço em um sistema de destino.

Definindo dependências do pacote

Você precisa determinar se o seu pacote tem dependências em outros pacotes e se outros pacotes dependem do seu pacote. As dependências e incompatibilidades podem ser definidas com dois arquivos de informação opcionais do pacote, compver e depend.

Entregar um arquivo compver permite nomear as versões anteriores do pacote compatíveis com o pacote que está sendo instalado.

Entregar um arquivo depend permite definir três tipos dependências associadas ao pacote. Os tipos de dependências são:

• Um pacote de pré-requisito – Seu pacote depende da existência de outro pacote

• Uma dependência inversa – Outro pacote depende da existência do seu pacote

  ---

  Observação –

  Use o tipo de dependência inversa somente quando um pacote que não puder entregar um arquivo depend dependa do seu pacote.

  ---

• Um pacote incompatível – Seu pacote é incompatível com o pacote nomeado

O arquivo depend resolve somente dependências muito básicas. Se seu pacote depende de um arquivo específico, do seu conteúdo ou do seu comportamento, o arquivo depend não oferece precisão adequada. Neste caso, um script request ou o script checkinstall deve ser usado para a verificação de dependência detalhada. O script checkinstall é também o único script capaz de interromper perfeitamente o processo de instalação do pacote.

Tenha certeza de que os arquivos depend e compver tenham entradas no arquivo prototype. O tipo de arquivo deve ser i (para arquivo de informação do pacote).

Consulte as páginas do manual depend(4) e compver(4) para obter mais informações.

Como definir as dependências do pacote

1. Torne o diretório que contém os arquivos de informação o diretório de trabalho atual.

2. Se houver versões anteriores do seu pacote e você precisar especificar que o novo pacote é compatível com tais versões, crie um arquivo nomeado compver com o seu editor de texto preferido.

   Liste as versões com as quais o pacote é compatível. Use este formato:

   string string . . .

   O valor de string é idêntico ao valor atribuído ao parâmetro VERSION no arquivo pkginfo para cada pacote compatível.

3. Salve as alterações e saia do editor.

4. Se o seu pacote depende da existência de outros pacotes, outros pacotes dependem do seu pacote ou seu pacote é incompatível com outros pacotes, crie um arquivo nomeado depend com o seu editor de texto preferido.

   Adicione uma entrada para cada dependência. Use este formato:

   type pkg-abbrev pkg-name (arch) version (arch) version . . .

   type

   Define o tipo de dependência. Deve ser um dos caracteres seguintes: P (pacote de pré-requisito), I (pacote incompatível) ou R (dependência inversa).

   pkg-abbrev

   Especifica a abreviatura do pacote, tal como SUNWcadap.

   pkg-name

   Especifica o nome completo do pacote, tal como Chip designers need CAD application software to design abc chips. Runs only on xyz hardware and is installed in the usr partition.

   (arch)

   Opcional. Especifica o tipo de hardware no qual o pacote é executado. Por exemplo, sparc ou x86. Se especificar uma arquitetura, você deve usar parênteses como delimitadores.

   version

   Opcional. Especifica o valor atribuído ao parâmetro VERSION no arquivo pkginfo.

   Para obter mais informações, consulte depend(4).

5. Salve as alterações e saia do editor.

6. Realize uma das seguintes tarefas:

   • Se você quiser criar arquivos de informação adicionais e scripts de instalação, vá para a próxima tarefa, Como escrever uma mensagem de copyright.

   • Se você não tiver criado o arquivo prototype, realize o procedimento Como criar um arquivo prototype usando o comando pkgproto. Vá para a Etapa 7.

   • Se você já criou o arquivo prototype, edite-o e adicione uma entrada para cada arquivo recém-criado.

7. Construa o pacote.

   Consulte Como construir um pacote, se necessário.

Exemplo 3–1 Arquivo compver

Neste exemplo, há quatro versões de um pacote: 1.0, 1.1, 2.0, e a nova versão 3.0. O novo pacote é compatível com todas as versões anteriores. O arquivo compver na versão mais recente deve ser semelhante a:

release 3.0
release 2.0
version 1.1
1.0

As entradas não têm que estar em ordem seqüencial. No entanto, devem corresponder exatamente à definição do parâmetro VERSION em cada arquivo pkginfo do pacote. Neste exemplo, os criadores de pacotes usaram diferentes formatos nas três primeiras versões.

Exemplo 3–2 Arquivo depend

Este exemplo pressupõe que o pacote de amostra, SUNWcadap, requer que os pacotes SUNWcsr e SUNWcsu já estejam instalados em um sistema de destino. O arquivo depend de SUNWcadap se assemelha a:

P SUNWcsr Core Solaris, (Root)
P SUNWcsu Core Solaris, (Usr)

Consulte também

Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.

Escrevendo uma mensagem de copyright

Você precisa decidir se o pacote deve exibir uma mensagem de copyright enquanto estiver sendo instalado. Se for o caso, crie o arquivo copyright.

Você deve incluir um arquivo copyright para oferecer proteção legal ao seu aplicativo de software. Confirme com o departamento jurídico da sua empresa qual o texto exato da mensagem.

Para entregar uma mensagem de copyright, você deve criar um arquivo nomeado copyright. Durante a instalação, a mensagem é exibida exatamente como aparece no arquivo (sem formato). Consulte a página do manual copyright(4) para obter mais informações.

Tenha certeza de que o arquivo copyright tem uma entrada no arquivo prototype. O tipo de arquivo deve ser i (para arquivo de informação do pacote).

Como escrever uma mensagem de copyright

1. Torne o diretório que contém os arquivos de informação no diretório de trabalho atual.

2. Crie um arquivo nomeado copyright com o seu editor de texto preferido.

   Digite o texto da mensagem de copyright exatamente como deseja que ele apareça quando seu pacote for instalado.

3. Salve as alterações e saia do editor.

4. Realize uma das seguintes tarefas:

   • Se você quiser criar arquivos de informação adicionais e scripts de instalação, vá para a próxima tarefa, Como reservar espaço adicional em um sistema de destino.

   • Se você não tiver criado o arquivo prototype, realize o procedimento Como criar um arquivo prototype usando o comando pkgproto. Vá para a Etapa 5.

   • Se você já criou o arquivo prototype, edite-o e adicione uma entrada para o arquivo de informação recém-criado.

5. Construa o pacote.

   Consulte Como construir um pacote, se necessário.

Exemplo 3–3 Arquivo copyright

Por exemplo, uma mensagem de copyright parcial pode ter a seguinte aparência:

Copyright (c) 2003 Company Name
All Rights Reserved
 
This product is protected by copyright and distributed under
licenses restricting copying, distribution, and decompilation.

Consulte também

Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.

Reservando espaço adicional em um sistema de destino

Você precisa determinar se o seu pacote precisa espaço de disco adicional no sistema de destino. Este espaço é adicionado ao espaço requerido pelos objetos de pacote. Se for o caso, crie o arquivo de informação space. Esta tarefa é diferente da criação de arquivos e diretórios vazios no tempo de instalação, conforme tratado em Definindo objetos adicionais a serem criados no tempo de instalação.

O comando pkgadd garante que haja espaço em disco suficiente para instalar o pacote com base nas definições do objeto no arquivo pkgmap. No entanto, um pacote pode precisar de espaço adicional em disco além daquele necessário para os objetos definidos no arquivo pkgmap. Por exemplo, seu pacote pode criar um arquivo depois da instalação, o qual pode conter um banco de dados, arquivos log ou algum outro arquivo que consuma espaço em disco. Para ter certeza de que há espaço reservado para tal arquivo, você deve incluir um arquivo space que especifica os requisitos de espaço em disco. O comando pkgadd verifica o espaço adicional especificado em um arquivo space. Consulte a página do manual space(4) para obter mais informações.

Tenha certeza de que o arquivo space tem uma entrada no arquivo prototype. O tipo de arquivo deve ser i (para arquivo de informação do pacote).

Como reservar espaço adicional em um sistema de destino

1. Torne o diretório que contém os arquivos de informação no diretório de trabalho atual.

2. Crie um arquivo nomeado space com o seu editor de texto preferido.

   Especifique os requisitos de espaço em disco necessários para seu pacote. Use este formato:

   pathname blocks inodes

   pathname

   Especifica o nome de um diretório, que pode ou não ser o ponto de montagem de um sistema de arquivos.

   blocks

   Especifica o número de blocos de 512 bytes que você deseja reservar.

   inodes

   Especifica a quantidade de inodes requerida.

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

3. Salve as alterações e saia do editor.

4. Realize uma das seguintes tarefas.

   • Se quiser criar scripts de instalação, vá para a próxima etapa, Como escrever um script request.

   • Se você não tiver criado o arquivo prototype, realize o procedimento Como criar um arquivo prototype usando o comando pkgproto. Vá para a Etapa 5.

   • Se você já criou o arquivo prototype, edite-o e adicione uma entrada para o arquivo de informação recém-criado.

5. Construa o pacote.

   Consulte Como construir um pacote, se necessário.

Exemplo 3–4 Arquivo space

Este arquivo space de exemplo especifica que 1000 blocos de 512 bytes e 1 inode sejam reservados no diretório /opt no sistema de destino.

/opt   1000   1

Consulte também

Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.

Criando scripts de instalação

Esta seção trata dos scripts de instalação opcionais do pacote. O comando pkgadd realiza automaticamente todas as ações necessárias para instalar um pacote usando os arquivos de informação como entrada. Não é necessário fornecer nenhum script de instalação de pacote. No entanto, se você quiser criar procedimentos de instalação personalizados para o pacote, é possível fazê-lo com os scripts de instalação. Os scripts de instalação:

• Devem ser executáveis pelo shell Bourne (sh)

• Devem conter texto e comandos de shell Bourne

• Não precisam conter identificador de shell #!/bin/sh

• Não precisam ser um arquivo executável

Há quatro tipos de scripts de instalação com os quais é possível realizar ações personalizadas:

• O script request

  O script request solicita dados do administrador que estiver instalando um pacote para atribuição ou redefinição das variáveis de ambiente.

• O script checkinstall

  O script checkinstall examina o sistema de destino a procura dos dados necessários, pode definir ou modificar as variáveis de ambiente do pacote e determina se a instalação deve continuar.

  ---

  Observação –

  O script checkinstall está disponível a partir do Solaris 2.5 e versões compatíveis.

  ---

• Scripts de procedimento

  Os scripts de procedimento identificam um procedimento a ser invocado antes ou depois da instalação ou remoção de um pacote. Os quatro scripts de procedimento são preinstall, postinstall, preremove e postremove.

• Scripts de ação de classe

  Os scripts de ação de classe definem uma ação ou um conjunto de ações que deve ser aplicado a uma classe de arquivos durante a instalação ou remoção. Você pode definir suas próprias classes. Outra alternativa é usar uma das quatro classes padrão (sed, awk, build e preserve).

Processamento de script durante a instalação do pacote

O tipo de scripts que você usa depende de quando a ação do script é necessária durante o processo de instalação. Conforme um pacote é instalado, o comando pkgadd realiza as seguintes etapas:

1. Executa o script request.

   Esta etapa é o único ponto no qual seu pacote pode solicitar entrada do administrador que estiver instalando o pacote.

2. Executa o script checkinstall.

   O script checkinstall coleta os dados do sistema de arquivos e pode criar ou alterar as definições da variável de ambiente para controlar a instalação subseqüente. Para obter mais informações sobre as variáveis de ambiente do pacote, consulte Variáveis de ambiente do pacote.

3. Executa o script preinstall.

4. Instala objetos de pacote em cada classe a ser instalada.

   A instalação desses arquivos ocorre classe por classe e os scripts de ação de classe são executados do modo devido. A lista de classes operadas e a ordem na qual devem ser instaladas são definidas inicialmente com o parâmetro CLASSES no arquivo pkginfo. No entanto, o script request ou o script checkinstall podem alterar o valor do parâmetro CLASSES. Para obter mais informações sobre como as classes são processadas durante a instalação, consulte Como as classes são processadas durante a instalação do pacote.

   1. Cria links simbólicos, dispositivos, pipes nomeados e diretórios necessários.

   2. Instala os arquivos regulares (tipos de arquivos e, v, f), baseados em suas classes

      O script de ação de classe é passado somente a arquivos regulares para instalar. Todos os objetos de pacote são criados automaticamente das informações do arquivo pkgmap.

   3. Cria todos os links de disco rígido.

5. Executa o script postinstall.

Processamento de script durante a remoção do pacote

Quando está sendo removido, o comando pkgrm realiza as seguintes etapas:

1. Executa o script preremove.

2. Remove os objetos de pacote de cada classe

   A remoção também ocorre classe por classe. Os scripts de remoção são processados na ordem inversa da instalação, com base na seqüência definida no parâmetro CLASSES. Para obter mais informações sobre como as classes são processadas durante a instalação, consulte Como as classes são processadas durante a instalação do pacote.

   1. Remove os links de disco rígido.

   2. Remove os arquivos regulares.

   3. Remove os links simbólicos, os dispositivos e os pipes nomeados.

3. Executa o script postremove.

O script request não é processado no momento da remoção do pacote. No entanto, a saída do script é retida no pacote instalado e é disponibilizada para os scripts de remoção. A saída do script request é uma lista de variáveis de ambiente.

Variáveis de ambiente de pacote disponíveis para os scripts

Os seguintes grupos de variáveis de ambiente estão disponíveis para todos os scripts de instalação. Algumas das variáveis de ambiente podem ser modificadas por um script request ou um script checkinstall.

• O script request ou o script checkinstall podem definir ou modificar qualquer um dos parâmetros padrão no arquivo pkginfo, exceto os parâmetros necessários. Os parâmetros de instalação padrão estão descritos detalhadamente na página do manual pkginfo(4).

  ---

  Observação –

  O parâmetro BASEDIR pode ser modificado somente a partir do Solaris 2.5 e versões compatíveis.

  ---

• Você pode definir suas próprias variáveis de ambiente de instalação atribuindo valores a elas no arquivo pkginfo. Tais variáveis de ambiente devem ser alfanuméricas com letras maiúsculas iniciais. Qualquer uma dessas variáveis de ambiente pode ser modificada por um script request ou um script checkinstall.

• Tanto um script request quanto checkinstall pode definir novas variáveis de ambiente atribuindo valores a elas e colocando-as no ambiente de instalação.

• A tabela seguinte lista as variáveis de ambiente disponíveis a todos os scripts de instalação no ambiente. Nenhuma dessas variáveis de ambiente pode ser modificada por um script.

  Variável de ambiente	Descrição
  CLIENT_BASEDIR	O diretório base com respeito ao sistema de destino. Enquanto que BASEDIR é a variável a ser usada ao fazer referência a um objeto de pacote específico do sistema de instalação (provavelmente um servidor), CLIENT_BASEDIR é o caminho a ser incluído nos arquivos que estão no sistema do cliente. CLIENT_BASEDIR existe se BASEDIR existir e é idêntico ao BASEDIR se não houver PKG_INSTALL_ROOT.
  INST_DATADIR	O diretório no qual está o pacote que está sendo lido agora. Se o pacote estiver sendo lido de uma fita, esta variável será o local de um diretório temporário para o qual o pacote foi transferido em formato de diretório. Em outras palavras, pressupondo que o nome do pacote não apresenta nenhuma extensão (por exemplo, SUNWstuff.d), o script request do pacote atual se encontraria em $INST_DATADIR/$PKG/install.
  PATH	A lista de pesquisa usada pelo sh para encontrar comandos na chamada de script. PATH é geralmente definido como /sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin .
  PKGINST	O identificador de instância do pacote que está sendo instalado. Se outra instância do pacote ainda não estiver instalada, o valor é a abreviatura do pacote (por exemplo, SUNWcadap). Do contrário, o valor é abreviatura do pacote seguida de um sufixo, tal como SUNWcadap.4.
  PKGSAV	O diretório no qual os arquivos podem ser salvos para serem usados pelos scripts de remoção ou no qual os arquivos salvos anteriormente podem ser encontrados. Disponível somente no Solaris 2.5 e versões compatíveis.
  PKG_CLIENT_OS	O sistema operacional do cliente no qual o pacote está sendo instalado. O valor desta variável é Solaris.
  PKG_CLIENT_VERSION	A versão do Solaris em formato x.y.
  PKG_CLIENT_REVISION	A revisão da compilação do Solaris.
  PKG_INSTALL_ROOT	O sistema de arquivos raiz no sistema de destino no qual o pacote está sendo instalado. Esta variável existe somente se os comandos pkgadd e pkgrm forem invocados com a opção -R. Esta existência condicional facilita seu uso em scripts de procedimento na forma ${PKG_INSTALL_ROOT}/algum_caminho.
  PKG_NO_UNIFIED	Uma variável de ambiente que fica definida se os comandos pkgadd e pkgrm forem invocados com as opções -M e -R. Esta variável de ambiente é passada para qualquer script de instalação de pacote ou comando de pacote que faça parte do ambiente do pacote.
  UPDATE	Esta variável de ambiente não existe na maioria dos ambientes de instalação. Se esta variável não existir (com o valor yes), isso pode ter duas explicações. Ou que já existe um pacote com o mesmo nome, versão e arquitetura instalado no sistema. Ou que este pacote está substituindo um pacote instalado com o mesmo nome no diretório do administrador. Nestes casos, é sempre usado o diretório base original.

Obtendo informações do pacote para um script

Dois comandos podem ser usados para solicitar informações dos scripts sobre um pacote:

• O comando pkginfo retorna informações sobre os pacotes de software, tais como o identificador de instância e o nome do pacote.

• O pkgparam retorna valores para as variáveis de ambiente solicitadas.

  Consulte a página do manual pkginfo(1), a página do manual pkgparam(1) e o Capítulo 4Verificando e transferindo um pacote para obter mais informações.

Códigos de saída para scripts

Cada script deve sair com um dos códigos de saída ilustrados na tabela seguinte.

Consulte Capítulo 5Estudos de caso de criação de pacote para ver exemplos de códigos de saída que são retornados por scripts de instalação.

Todos os scripts de instalação entregues com o pacote devem ter uma entrada no arquivo prototype. O tipo de arquivo deve ser i (para script de instalação de pacote).

Escrevendo um script request

O script request é a única forma de que seu pacote possa interagir diretamente com o administrador que está instalando tal pacote. Este script pode ser usado, por exemplo, para perguntar ao administrador se as partes opcionais de um pacote devem ser instaladas.

A saída de um script request deve ser uma lista de variáveis de ambiente e seus valores. Esta lista pode incluir qualquer um dos parâmetros criados no arquivo pkginfo e os parâmetros CLASSES e BASEDIR. A lista também pode introduzir variáveis de ambiente que ainda não foram definidas em outro lugar. No entanto, o arquivo pkginfo deve sempre fornecer valores padrão quando for prático. Para obter mais informações sobre as variáveis de ambiente do pacote, consulte Variáveis de ambiente do pacote.

Quando o seu script request atribuir valores a uma variável de ambiente, ele deve tornar tais valores disponíveis para o comando pkgadd e para outros scripts do pacote.

Comportamentos do script request

• O script request não pode modificar nenhum arquivo. Este script interage somente com administradores que estão instalando o pacote e cria uma lista de atribuições de variáveis de ambiente baseada em tal interação. O script request é executado como o usuário install não privilegiado se tal usuário existir. Do contrário, o script é executado como usuário root.

• O comando pkgadd chama o script request com um argumento que nomeia o arquivo de resposta do script. O arquivo de resposta armazena as respostas do administrador.

• O script request não é executado durante a remoção do pacote. No entanto, as variáveis de ambiente atribuídas pelo script são salvas e estão disponíveis durante a remoção do pacote.

Regras de criação para scripts request

• Pode haver somente um script request por pacote. O script deve ser nomeado request.

• As atribuições de variável de ambiente devem ser adicionadas ao ambiente de instalação para serem usadas pelo comando pkgadd e outros scripts de empacotamento escrevendo-as no arquivo de resposta (conhecido pelo script como $1).

• As variáveis de ambiente do sistema e as variáveis de ambiente de instalação padrão, exceto para os parâmetros CLASSES e BASEDIR, não podem ser modificadas por um script request. Todas as outras variáveis de ambiente que você criou podem ser alteradas.

  ---

  Observação –

  Um script request pode modificar somente o parâmetro BASEDIR a partir do Solaris 2.5 e versões compatíveis.

  ---

• No arquivo pkginfo, a cada variável que o script request pode manipular deve ser atribuído um valor padrão.

• O formato da lista de saída deve ser PARAM=value. Por exemplo:

  CLASSES=none class1

• O terminal do administrador é definido como entrada padrão do script request.

• Não realiza nenhuma análise especial do sistema de destino em um script request. É arriscado testar o sistema em busca de determinados binários ou comportamentos, e definir variáveis de ambiente com base em tal análise. Não há garantias de que o script request seja executado no tempo de instalação. O administrador que estiver instalando o pacote pode fornecer um arquivo de resposta que inserirá as variáveis de ambiente sem nunca chamar o script request. Se o script request também estiver avaliando o sistema de arquivos de destino, tal avaliação pode não ocorrer. É melhor que a análise do sistema de destino seja realizada pelo script checkinstall para obter tratamento especial.

Se os administradores que instalarão o seu pacote puderem usar o produto JumpStart^TM, então a instalação do seu pacote não deve ser interativa. Você deve fornecer um script request com seu pacote ou deve comunicar aos administradores que eles devem usar o comando pkgask antes da instalação. O comando pkgask armazena as repostas deles no script request. Para obter mais informações sobre o comando pkgask, consulte a página do manual pkgask(1M).

Como escrever um script request

1. Torne o diretório que contém os arquivos de informação no diretório de trabalho atual.

2. Crie um arquivo nomeado request com o seu editor de texto preferido.

3. Salve as alterações e saia do editor quando acabar.

4. Realize uma das seguintes tarefas.

   • Se quiser criar scripts de instalação, vá para a próxima etapa, Como coletar dados do sistema de arquivos.

   • Se você não tiver criado o arquivo prototype, realize o procedimento Como criar um arquivo prototype usando o comando pkgproto. Vá para a Etapa 5.

   • Se você já criou o arquivo prototype, edite-o e adicione uma entrada para cada script de instalação recém-criado.

5. Construa o pacote.

   Consulte Como construir um pacote, se necessário.

Exemplo 3–5 Escrevendo um script request

Quando um script request atribui valor a variáveis de ambiente, ele deve disponibilizar tais valores para o comando pkgadd. Este exemplo mostra um segmento do script request que realiza esta tarefa em quatro variáveis de ambiente: CLASSES, NCMPBIN, EMACS e NCMPMAN. Suponha que estas variáveis tenham sido definidas em uma sessão interativa com o administrador anteriormente no script.

# make environment variables available to installation
# service and any other packaging script we might have
 
cat >$1 <<!
CLASSES=$CLASSES
NCMPBIN=$NCMPBIN
EMACS=$EMACS
NCMPMAN=$NCMPMAN
!

Consulte também

Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.

Coletando dados do sistema de arquivos com o script checkinstall

O script checkinstall é executado brevemente depois do script request opcional. O script checkinstall é executado como usuário install, se tal usuário existir, ou como usuário nobody. O script checkinstall não tem autoridade para alterar os dados do sistema de arquivos. No entanto, com base nas informações que o script coleta, ele pode criar ou modificar as variáveis de ambiente a fim de controlar o curso da instalação resultante. O script também pode deter perfeitamente o processo de instalação.

O script checkinstall está programado para realizar verificações básicas em um sistema de arquivos que não é normal para o comando pkgadd. Por exemplo, este script pode ser usado para verificar arquivos adiante a fim de determinar se tais arquivos do pacote atual substituirão arquivos existentes, ou gerenciar as dependências gerais do software. O arquivo depend gerencia somente dependências no nível do pacote.

Diferente do script request, o script checkinstall é executado se um arquivo de resposta for ou não fornecido. A presença do script não marca pacote como interativo. O script checkinstall pode ser usado quando um script request for esquecido ou quando a interação do administrador não for útil.

O script checkinstall está disponível a partir do Solaris 2.5 e versões compatíveis.

Comportamentos do script checkinstall

• O script checkinstall não pode modificar nenhum arquivo. Este script analisa somente o estado do sistema e cria uma lista de atribuições de variáveis de ambiente com base em tal interação. Para fazer cumprir esta limitação, o script checkinstall é executado como o usuário install não privilegiado se tal usuário existir. Do contrário, este script é executado como usuário nobody não privilegiado. O script checkinstall não tem autoridade de superusuário.

• O comando pkgadd chama o script checkinstall com um argumento que nomeia o arquivo de resposta do script. O arquivo de resposta do script é o arquivo que armazena as respostas do administrador.

• O script checkinstall não é executado durante a remoção do pacote. No entanto, as variáveis de ambiente atribuídas pelo script são salvas e estão disponíveis durante a remoção do pacote.

Regras de criação para scripts checkinstall

• Pode haver somente um script checkinstall por pacote. O script deve ser nomeado checkinstall.

• As atribuições de variável de ambiente devem ser adicionadas ao ambiente de instalação para serem usadas pelo comando pkgadd e outros scripts de empacotamento escrevendo-as no arquivo de resposta (conhecido pelo script como $1).

• As variáveis de ambiente do sistema e as variáveis de ambiente de instalação padrão, exceto para os parâmetros CLASSES e BASEDIR, não podem ser modificadas por um script checkinstall. Todas as outras variáveis de ambiente que você criou podem ser alteradas.

• No arquivo pkginfo, a cada variável que o script checkinstall pode manipular deve ser atribuído um valor padrão.

• O formato da lista de saída deve ser PARAM=value. Por exemplo:

  CLASSES=none class1

• A interação do administrador não é permitida durante a execução de um script checkinstall. Todas as interações do administrador estão limitadas ao script request.

Como coletar dados do sistema de arquivos

1. Torne o diretório que contém os arquivos de informação no diretório de trabalho atual.

2. Crie um arquivo nomeado checkinstall com o seu editor de texto preferido.

3. Salve as alterações e saia do editor quando acabar.

4. Realize uma das seguintes tarefas.

   • Se quiser criar scripts de instalação adicionais, vá para a próxima etapa, Como escrever scripts de procedimento.

   • Se você não tiver criado o arquivo prototype, realize o procedimento Como criar um arquivo prototype usando o comando pkgproto. Vá para a Etapa 5.

   • Se você já criou o arquivo prototype, edite-o e adicione uma entrada para cada script de instalação recém-criado.

5. Construa o pacote.

   Consulte Como construir um pacote, se necessário.

Exemplo 3–6 Escrevendo um script checkinstall

Este exemplo do script checkinstall realiza uma verificação para ver se o software de banco de dados que o pacote SUNWcadap precisa está instalado.

# checkinstall script for SUNWcadap
#
# This confirms the existence of the required specU database
 
# First find which database package has been installed.
pkginfo -q SUNWspcdA	# try the older one
 
if [ $? -ne 0 ]; then
   pkginfo -q SUNWspcdB	# now the latest
 
	  if [ $? -ne 0 ]; then	# oops
		    echo "No database package can be found. Please install the"
		    echo "SpecU database package and try this installation again."
		    exit 3		# Suspend
	  else
		    DBBASE="`pkgparam SUNWsbcdB BASEDIR`/db"	# new DB software
	  fi
else
	  DBBASE="`pkgparam SUNWspcdA BASEDIR`/db"	# old DB software
fi
 
# Now look for the database file we will need for this installation
if [ $DBBASE/specUlatte ]; then
	  exit 0		# all OK
else
	  echo "No database file can be found. Please create the database"
	  echo "using your installed specU software and try this"
	  echo "installation again."
	  exit 3		# Suspend
fi
 

Consulte também

Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.

Escrevendo scripts de procedimento

Os scripts de procedimento oferecem um conjunto de instruções para serem realizadas em determinados pontos da instalação ou remoção do pacote. Os quatro scripts de procedimento devem ser nomeados com um dos nomes predefinidos, dependendo de quando as instruções serão executadas. Os scripts são executados sem argumentos.

• O script preinstall

  É executado antes do início da instalação da classe. Nenhum arquivo deve ser instalado por este script.

• O script postinstall

  É executado depois que todos os volumes tiverem sido instalados.

• O script preremove

  É executado antes do início da remoção da classe. Nenhum arquivo deve ser removido por este script.

• O script postremove

  É executado depois que todas as classes tiverem sido removidas.

Comportamentos do script de procedimento

Os scripts de procedimento são executados como uid=root e gid=other.

Regras de criação dos scripts de procedimento

• Cada script deve poder ser executado mais de uma vez porque ele é executado uma vez em cada volume de um pacote. Isso significa que executar um script várias vezes com a mesma entrada produz os mesmos resultados que executar o script somente uma vez.

• Cada script de procedimento que não instalar um objeto de pacote no arquivo pkgmap deve usar o comando installf para notificar o banco de dados do pacote que ele está adicionando ou modificando um nome de caminho. Depois que todas as adições e modificações forem concluídas, este comando deve ser chamado com a opção -f. Somente os scripts postinstall e postremove podem instalar objetos de pacote desta forma. Consulte a página do manual installf(1M) e o Capítulo 5Estudos de caso de criação de pacote para obter mais informações.

• Não é permitida a interação com o administrador durante a execução de um script de procedimento. Todas as interações do administrador estão limitadas ao script request.

• Cada script de procedimento que remove arquivos não instalados do arquivo pkgmap deve usar o comando removef para notificar o banco de dados que ele está removendo um nome de caminho. Depois que a remoção tiver sido concluída, este comando deve ser chamado com a opção -f. Consulte a página do manual removef(1M) e o Capítulo 5Estudos de caso de criação de pacote para obter detalhes e exemplos.

  ---

  Observação –

  Os comandos installf e removef devem ser usados porque os scripts de procedimentos não estão associados automaticamente a nenhum nome de caminho listado no arquivo pkgmap.

  ---

Como escrever scripts de procedimento

1. Torne o diretório que contém os arquivos de informação no diretório de trabalho atual.

2. Crie um ou mais scripts de procedimento com o editor de texto de sua preferência.

   Um script de procedimento deve ser nomeado com um dos nomes predefinidos: preinstall, postinstall, preremove ou postremove.

3. Salve as alterações e saia do editor.

4. Realize uma das seguintes tarefas.

   • Se quiser criar scripts de ação de classe, vá para a próxima etapa, Como escrever scripts de ação de classe.

   • Se você não tiver criado o arquivo prototype, realize o procedimento Como criar um arquivo prototype usando o comando pkgproto. Vá para a Etapa 5.

   • Se você já criou o arquivo prototype, edite-o e adicione uma entrada para cada script de instalação recém-criado.

5. Construa o pacote.

   Consulte Como construir um pacote, se necessário.

Consulte também

Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.

Escrevendo scripts de ação de classe

Definindo classes de objeto

As classes de objeto possibilitam uma série de ações a serem realizadas em grupo de objetos de pacote na instalação ou remoção. Você atribui objetos a uma classe no arquivo prototype. A todos os objetos de pacote deve ser fornecida uma classe, embora a classe none seja usada por padrão em objetos que não requerem nenhuma ação especial.

O parâmetro de instalação CLASSES, definido no arquivo pkginfo, é uma lista de classes a ser instalada (incluindo a classe none).

Os objetos definidos no arquivo pkgmap que pertencem a uma classe não listada neste parâmetro do arquivo pkginfo não serão instalados.

A lista de CLASSES determina a ordem de instalação. A classe none é sempre instalada primeiro, se estiver presente, e é removida por último. Visto que os diretórios são a estrutura de suporte fundamental de todos os outros objetos do sistema de arquivos, todos eles devem ser atribuídos à classe none. Pode haver exceções, mas, como regra geral, a classe none é a mais segura. Esta estratégia garante que os diretórios sejam criados antes dos objetos que irão conter. Além disso, nenhuma tentativa de excluir um diretório é feita antes que este esteja vazio.

Como as classes são processadas durante a instalação do pacote

Abaixo estão descritas as ações de sistema que ocorrem quando uma classe é instalada. As ações são repetidas uma vez para cada volume de um pacote, conforme tal volume está sendo instalado.

1. O comando pkgadd cria uma lista de nomes de caminho.

   O comando pkgadd cria uma lista de nomes de caminho sobre a qual o script de ação opera. Cada linha desta lista contém os nomes de caminho de origem e de destino, separados por um espaço. O nome de caminho de origem indica onde o objeto a ser instalado se localiza no volume de instalação. O nome de caminho de destino indica o local no sistema de destino onde o objeto deve ser instalado. O conteúdo da lista está limitado pelos seguintes critérios:

   • A lista contém somente nomes de caminho que pertencem à classe associada.

   • Se a tentativa de criar o objeto de pacote falhar, então os diretórios, os pipes nomeados, os dispositivos de caractere, os dispositivos de bloco e os links simbólicos são incluídos na lista com o nome de caminho de origem definido como /dev/null. Normalmente, estes itens são criados automaticamente pelo comando pkgadd (se ainda não existirem) e a eles são dados atributos apropriados (modo, proprietário, grupo) conforme definido no arquivo pkgmap.

   • Os arquivos vinculados em que o tipo de arquivo for l não são incluídos na lista sob nenhuma circunstância. Os links de disco rígido de uma determinada classe são criados no item 4.

2. Se nenhum script de ação de classe for fornecido para a instalação de uma determinada classe, os nomes de caminho da lista gerada são copiados do volume no local de destino apropriado.

3. Se houver um script de ação de classe, este é executado.

   O script de ação de classe é chamado com a entrada padrão que contém a lista gerada no item 1. Se este volume for o último volume do pacote, ou se não houver mais objetos nesta classe, o script é executado com o único argumento ENDOFCLASS.

   ---

   Observação –

   Mesmo se não houver nenhum arquivo regular desta classe no pacote, o script de ação de classe é chamado pelo menos uma vez com uma lista vazia e o argumento ENDOFCLASS.

   ---

4. O comando pkgadd realiza uma auditoria de conteúdo e atributo, e cria links de disco rígido.

   Após a execução bem-sucedida dos itens 2 ou 3, o comando pkgadd realiza a auditoria das informações de conteúdo e de atributo da lista de nomes de caminho. O comando pkgadd cria automaticamente os links associados à classe. As incoerências de atributo detectadas são corrigidas em todos os nomes de caminho da lista gerada.

Como as classes são processadas durante a remoção do pacote

Os objetos são removidos classe por classe. As classes que existem em um pacote, mas que não estão listadas no parâmetro CLASSES, são removidas primeiro (por exemplo, um objeto instalado com o comando installf). As classes listadas no parâmetro CLASSES são removidas na ordem inversa. A classe none é removida sempre por último. Abaixo estão descritas as ações de sistema que ocorrem quando uma classe é removida:

1. O comando pkgrm cria uma lista de nomes de caminho.

   O comando pkgrm cria uma lista de nomes de caminho instalados que pertencem à classe indicada. Os nomes de caminho com referência de outro pacote são excluídos da lista, a menos que o tipo de arquivo deles seja e. O tipo de arquivo e significa que o arquivo deve ser editado na instalação ou na remoção.

   Se o pacote que estiver sendo removido tiver modificado algum arquivo de tipo e durante a instalação, ele deve remover apenas as linhas que foram adicionadas. Não exclua um arquivo editável que não estiver vazio. Remova as linhas que o pacote adicionou.

2. Se não houver nenhum script de ação de classe, os nomes de caminho são excluídos.

   Se o seu pacote não tiver nenhum script de ação de classe na classe, todos os nomes de caminho da lista gerada pelo comando pkgrm são excluídos.

   ---

   Observação –

   Os arquivos com um tipo de arquivo e (editável) não são atribuídos a uma classe nem a um script de ação de classe associado. Estes arquivos são removidos neste ponto, mesmo se o nome de caminho for compartilhado com outros pacotes.

   ---

3. Se houver um script de ação de classe, o script é executado.

   O comando pkgrm chama o script de ação de classe com a entrada padrão do script que contém a lista gerada no item 1.

4. O comando pkgrm realiza uma auditoria.

   Após a execução bem-sucedida do script de ação de classe, o comando pkgrm remove as referências aos nomes de caminho do banco de dados do pacote, a menos que outro pacote faça referência a um nome de caminho.

O script de ação de classe

O script de ação de classe define um conjunto de ações a serem executadas durante a instalação e a remoção de um pacote. As ações são realizadas em um grupo de nomes de caminho com base na definição de classe. Consulte Capítulo 5Estudos de caso de criação de pacote para obter exemplos de scripts de ação de classe.

O nome de um script de ação de classe é baseado na classe na qual ele deve operar e se tais operações devem ocorrer durante a instalação ou remoção do pacote. Os dois formatos de nome são mostrados na tabela seguinte:

Por exemplo, o nome do script de instalação de uma classe denominada manpage seria i.manpage. O script de remoção seria denominado r.manpage.

Este formato de nome de arquivo não é usado em arquivos que pertencem às classes de sistema sed, awk ou build. Para obter mais informações sobre estas classes especiais, consulte As classes de sistema especiais.

Comportamentos do script de ação de classe

• Os scripts de ação de classe são executados como uid=root e gid=other.

• Um script é executado em todos os arquivos de uma determinada classe no volume atual.

• Os comandos pkgadd e pkgrm criam uma lista de todos os objetos listados no arquivo pkgmap que pertencem à classe. Como conseqüência, um script de ação de classe pode agir somente sobre nomes de caminho definidos no pkgmap que pertencem a uma determinada classe.

• Quando um script de ação de classe for executado pela última vez (isto é, não há mais nenhum arquivo que perteça a tal classe), o script de ação de classe é executado uma vez com o argumento de palavra-chave ENDOFCLASS.

• Não é permitida a interação com o administrador durante a execução de um script de ação de classe.

Regras de criação para sripts de ação de classe

• Se um pacote abranger mais de um volume, o script de ação de classe é executado uma vez para cada volume que contém pelo menos um arquivo que pertença a uma classe. Conseqüentemente, cada script deve poder ser executado mais de uma vez. Isso significa que executar um script várias vezes com a mesma entrada deve produzir os mesmos resultados que executar o script somente uma vez.

• Quando um arquivo fizer parte de uma classe que tem um script de ação de classe, o script deve instalar o arquivo. O comando pkgadd não instala os arquivos em cada classe que tenha um script de ação de classe, embora ele verifique a instalação.

• Um script de ação de classe nunca adiciona, remove ou modifica um nome de caminho ou um atributo de sistema que não apareça na lista gerada pelo comando pkgadd. Para obter mais informações sobre esta lista, consulte o item 1 em Como as classes são processadas durante a instalação do pacote.

• Quando o seu script interpretar o argumento ENDOFCLASS, coloque as ações de pós-processamento, tal como limpeza, no seu script.

• Todas as interações do administrador estão limitadas ao script request. Não tente obter informações do administrador usando um script de ação de classe.

As classes de sistema especiais

O sistema fornece quatro classes especiais:

• A classe sed

  Fornece um método para o uso das instruções sed para editar arquivos na instalação e remoção do pacote.

• A classe awk

  Fornece um método para o uso das instruções awk para editar arquivos na instalação e remoção do pacote.

• A classe build

  Fornece um método para construir e modificar dinamicamente um arquivo usando os comandos do shell Bourne.

• A classe preserve

  Fornece um método para preservar os arquivos que não devem ser substituídos por futuras instalações de pacote.

• A classe manifest

  Oferece instalação e desinstalação automática dos serviços SMF (Service Management Facility) associados a um manifest. A classe manifest deve ser usada em todos os manifests SMF de um pacote.

Se vários arquivos de um pacote precisarem de processamento especial que possa ser definido completamente através dos comandos sed, awk ou sh, a instalação é mais rápida usando as classes de sistema em vez de usar várias classes e os scripts de ação de classes correspondentes .

O script de classe sed

A classe sed oferece um método para modificar um objeto existente em um sistema de destino. O script de ação de classe sed é executado automaticamente na instalação se houver um arquivo que pertença à classe sed. O nome do script de ação de classe sed deve ser igual ao nome do arquivo no qual as instruções são executadas.

Um script de ação de classe sed entrega as instruções de sed no formato seguinte:

Dois comandos indicam quando as instruções devem ser executadas. As instruções de sed que vêm depois do comando !install são executadas durante a instalação do pacote. As instruções de sed que vêm depois do comando !remove são executadas durante a remoção do pacote. Não importa a ordem na qual estes comandos sejam usados no arquivo.

Para obter mais informações sobre as instruções de sed consulte a página do manual sed(1) Para obter exemplos dos scripts de ação de classe sed, consulte o Capítulo 5Estudos de caso de criação de pacote.

O script de classe awk

A classe awk oferece um método para modificar um objeto existente em um sistema de destino. As modificações são entregues como instruções awk em um script de ação de classe awk.

O script de ação de classe awk é executado automaticamente na instalação se houver um arquivo que pertença à classe awk. Tal arquivo contém instruções para o script de classe awk no seguinte formato:

Dois comandos indicam quando as instruções devem ser executadas. As instruções de awk que vêm depois do comando !install são executadas durante a instalação do pacote. As instruções que vêm após o comando !remove são executadas durante a remoção do pacote. Estes comandos podem ser usados em qualquer ordem.

O nome do script de ação de classe awk deve ser igual ao nome do arquivo no qual as instruções são executadas.

O arquivo que será modificado é usado como entrada no comando awk e a saída do script substitui o objeto original. As variáveis de ambiente talvez não sejam passadas para o comando awk com esta sintaxe.

Para obter mais informações sobre as instruções de awk consulte a página do manual awk(1).

O script de classe build

A classe build cria ou modifica um arquivo de objeto de pacote executando as instruções do shell Bourne. Estas instruções são entregues como o objeto de pacote. As instruções são executadas automaticamente na instalação se houver um arquivo que pertença á classe build.

O nome do script de ação de classe build deve ser igual ao nome do arquivo no qual as instruções são executadas. O nome também deve ser executável pelo comando sh. A saída do script se torna a nova versão do arquivo à medida que ele é construído e modificado. Se o script não produzir saída, o arquivo não é criado nem modificado. Portanto, o script pode modificar ou criar o arquivo por si mesmo.

Por exemplo, se um pacote entrega um arquivo padrão, /etc/randomtable, e se o arquivo ainda não existir no sistema de destino, a entrada do arquivo prototype pode ser a seguinte:

e build /etc/randomtable ? ? ?

O objeto de pacote, /etc/randomtable, pode ser semelhante ao seguinte:

!install
# randomtable builder
if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then
		echo "/etc/randomtable is already in place.";
	    else
		echo "# /etc/randomtable" > $PKG_INSTALL_ROOT/etc/randomtable
		echo "1121554	# first random number" >> $PKG_INSTALL_ROOT/etc/randomtable
fi
 
!remove
# randomtable deconstructor
if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then
		# the file can be removed if it's unchanged
		if [ egrep "first random number" $PKG_INSTALL_ROOT/etc/randomtable ]; then
			rm $PKG_INSTALL_ROOT/etc/randomtable;
		fi
fi
 

Consulte o Capítulo 5Estudos de caso de criação de pacote para obter outros exemplos que usem a classe build.

O script de classe preserve

A classe preserve preserva um arquivo de objeto do pacote ao determinar se um arquivo existente deve ou não ser substituído quando o pacote é instalado. Duas situações possíveis que podem ocorrer ao usar um script de classe preserve são:

• Se o arquivo que será instalado ainda não existir no diretório de destino, o arquivo será instalado normalmente.

• Se o arquivo que será instalado existir no diretório de destino, é exibida uma mensagem descrevendo que o arquivo existe e este não será instalado.

Ambos os resultados das situações são considerados satisfatórios pelo script preserve. Ocorre uma falha somente na segunda situação quando o arquivo não pode ser copiado no diretório de destino.

A partir do Solaris 7, o script i.preserve e uma cópia deste script, i.CONFIG.prsv, podem ser encontrados no diretório /usr/sadm/install/scripts com outros scripts de ação de classe.

Modifique o script para incluir o nome ou os nomes de arquivo que você gostaria de conservar.

O script de classe manifest

A classe manifest instala e desinstala automaticamente os serviços SMF (Service Management Facility) associados a um manifest SMF.. Se não estiver familiarizado com o SMF, consulte o Capítulo 17, Managing Services (Overview), no System Administration Guide: Basic Administration para obter informações sobre como usar o SMF para gerenciar os serviços.

Todos os manifests de serviço dentro dos pacotes devem ser identificados com a classe manifest. Os scripts de ação de classe que instalam e removem os manifests de serviço estão incluídos no subsistema de empacotamento. Quando pkgadd(1M) é chamado, o manifest de serviço é importado. Quando o pkgrm(1M) é chamado, as instâncias desativadas do manifest de serviço são excluídas. Os serviços no manifest que não têm instâncias restantes também são excluídos. Se a opção -R é fornecida a pkgadd(1M) ou pkgrm(1M), essas ações do manifest de serviço serão realizadas na próxima vez que os sistema for reinicializado com tal caminho de raiz alternativa.

A seguinte parte de código do arquivo de informações de um pacote mostra o uso da classe manifest.

# packaging files
i pkginfo
i copyright
i depend
i preinstall
i postinstall
i i.manifest
i r.manifest
#
# source locations relative to the prototype file
#
d none var 0755 root sys
d none var/svc 0755 root sys
d none var/svc/manifest 0755 root sys
d none var/svc/manifest/network 0755 root sys
d none var/svc/manifest/network/rpc 0755 root sys
f manifest var/svc/manifest/network/rpc/smserver.xml 0444 root sys

Como escrever scripts de ação de classe

1. Torne o diretório que contém os arquivos de informação no diretório de trabalho atual.

2. Atribua aos objetos de pacote do arquivo prototype os nomes de classe desejados.

   Por exemplo, a atribuição de objetos a uma classe application e manpage poderia ser semelhante a:

   f manpage /usr/share/man/manl/myappl.1l f application /usr/bin/myappl

3. Modifique o parâmetro CLASSES no arquivo pkginfo para que contenha os nomes de classe que você deseja usar no seu pacote.

   Por exemplo, as entradas da classe application e manpage poderiam ser semelhantes a:

   CLASSES=manpage application none

   ---

   Observação –

   A classe none é instalada sempre primeiro e removida por último, independente de onde ela aparece na definição do parâmetro CLASSES.

   ---

4. Se estiver criando um script de ação de classe para um arquivo que pertença à classe sed, awk ou build, torne o diretório que contém o objeto de pacote seu diretório de trabalho atual.

5. Crie os scripts de ação de classe ou objetos de pacote (em arquivos que pertençam à classe sed, awk ou build).

   Por exemplo, o script de instalação de uma classe denominada application seria denominado i.application e o script de remoção seria denominado r.application.

   Lembre-se, quando um arquivo fizer parte de uma classe que tem um script de ação de classe, o script deve instalar o arquivo. O comando pkgadd não instala os arquivos em cada classe que tenha um script de ação de classe, embora ele verifique a instalação. E, se você definir uma classe, mas não entregar um script de ação de classe, a única ação assumida por tal classe é copiar os componentes do meio de instalação no sistema de destino (o comportamento padrão de pkgadd).

6. Realize uma das seguintes tarefas:

   • Se não tiver criado o arquivo prototype, realize o procedimento Como criar um arquivo prototype usando o comando pkgproto, e vá para a Etapa 7.

   • Se você já criou o arquivo prototype, edite-o e adicione uma entrada para cada script de instalação recém-criado.

7. Construa o pacote.

   Consulte Como construir um pacote, se necessário.

Próximo passo

Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4Verificando e transferindo um pacote explica como fazê-lo e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.

Criando pacotes assinados

O processo de criação de pacotes assinados abrange várias etapas e requer um pouco de compreensão sobre novos conceitos e terminologias. Esta seção oferece informações sobre pacotes assinados, sua terminologia e sobre o gerenciamento de certificados. Esta seção oferece também procedimentos detalhados sobre como criar um pacote assinado.

Pacotes assinados

Um pacote assinado é um pacote com formato de fluxo normal que possui uma assinatura digital (assinatura digital PKCS7 codificada em PEM definida abaixo) que verifica o seguinte:

• O pacote vem da entidade que o assinou

• A entidade o assinou realmente

• O pacote não foi modificado depois que a entidade o assinou

• A entidade que o assinou é de confiança

Um pacote assinado é idêntico a um pacote não assinado, exceto pela assinatura. Um pacote assinado é compatível em binário com um pacote não assinado. Portanto, um pacote assinado pode ser usado com as versões mais antigas das ferramentas de empacotamento. No entanto, a assinatura é ignorada nesse caso.

A tecnologia de empacotamento assinado introduz algumas novas terminologias e abreviações, que estão descritas na tabela seguinte.

Gerenciamento de certificado

Antes de criar um pacote assinado, você deve ter uma chave de armazenamento de pacote. Esta chave de armazenamento de pacote contém certificados na forma de objetos. Existem dois tipos de objetos em uma chave de armazenamento de pacote:

Certificados de confiança

Um certificado de confiança que contém um certificado único de chave pública que pertence a outra entidade. O certificado de confiança tem essa denominação porque o proprietário da chave de armazenamento confia realmente que a chave pública do certificado pertence à identidade indicada pelo “sujeito” (proprietário) do certificado. O emissor do certificado se responsabiliza por esta confiança assinando o certificado.

Os certificados de confiança são usados na verificação de assinaturas e ao iniciar uma conexão a um servidor seguro (SSL).

Chave de usuário

Uma chave de usuário conserva informações criptográficas importantes que diferenciam maiúsculas e minúsculas. Esta informação é armazenada em um formato protegido para evitar acesso não autorizado. Uma chave de usuário está formada pela chave privada do usuário e pelo certificado de chave pública que corresponde à chave privada.

As chaves de usuário são usadas ao criar um pacote assinado.

Por padrão, a chave de armazenamento de pacote é armazenada no diretório /var/sadm/security. Os usuários individuais também podem ter suas próprias chaves de armazenamento armazenadas por padrão no diretório $HOME/.pkg/security.

No disco, uma chave de armazenamento de pacote pode se apresentar em dois formatos: formato de vários arquivos e formato de arquivo único. O formato de vários arquivos armazena seus objetos em vários arquivos. Cada tipo de objeto é armazenado em um arquivo diferente. Todos os arquivos devem ser criptografados usando a mesma frase-senha. Uma chave de armazenamento de arquivo único armazena todos os seus objetos em um único arquivo no sistema de arquivos.

O principal utilitário usado para gerenciar os certificados e a chave de armazenamento de pacote é o comando pkgadm. As subseções seguintes descrevem as tarefas mais comuns usadas para gerenciamento de chaves de armazenamento de pacote.

Adicionando certificados de confiança à chave de armazenamento de pacote

Um certificado de confiança pode ser adicionado à chave de armazenamento de pacote usando o comando pkgadm. O certificado pode estar no formato PEM ou DER. Por exemplo:

$ pkgadm addcert -t /tmp/mytrustedcert.pem

Neste exemplo, o certificado em formato PEM denominado mytrustedcert.pem é adicionado à chave de armazenamento de pacote.

Adicionando um certificado de usuário e chave privada à chave de armazenamento de pacote

O comando pkgadm não gera certificados de usuário nem chaves privadas. Os certificados de usuário e chaves privadas são obtidos normalmente de uma Autoridade de certificado, tal como Verisign. Ou, são gerados localmente tal como um certificado auto-assinado. Uma vez a chave e o certificado tenham sido obtidos, eles podem ser importados para a chave de armazenamento de pacote usando o comando pkgadm. Por exemplo:

pkgadm addcert -n myname -e /tmp/myprivkey.pem /tmp/mypubcert.pem

Neste exemplo, são usadas as seguintes opções:

Verificando o conteúdo na chave de armazenamento de pacote

O comando pkgadm também é usado para visualizar o conteúdo da chave de armazenamento de pacote. Por exemplo:

$ pkgadm listcert

Este comando exibe os certificados de confiança e as chaves privadas da chave de armazenamento de pacote.

Excluindo certificados de usuário e chaves privadas da chave de armazenamento de pacote

O comando pkgadm pode ser usado para excluir certificados de confiança e chaves privadas da chave de armazenamento de pacote.

Ao excluir os certificados de usuários, o alias do par certificado/chave deve ser especificado. Por exemplo:

$ pkgadm removecert -n myname

O alias do certificado é o nome comum do certificado, que pode ser identificado usando o comando pkgadm listcert. Por exemplo, este comando exclui um certificado de confiança intitulado Trusted CA Cert 1:

$ pkgadm removecert -n "Trusted CA Cert 1"

Se você possuir tanto um certificado de confiança quanto um certificado de usuário armazenado usando o mesmo alias, ambos são excluídos quando a opção -n for especificada.

Criação de pacotes assinados

O processo de criação de pacotes assinados apresenta três etapas básicas:

1. A criação de um pacote não assinado no formato de diretório.

2. A importação do certificado assinado, certificados CA, e da chave privada para a chave de armazenamento de pacote.

3. A assinatura do pacote da Etapa 1 com os certificados da Etapa 2.

As ferramentas de empacotamento não criam certificados. Estes certificados devem ser obtidos de uma Autoridade de certificado, tal como Verisign ou Thawte.

Cada etapa da criação de pacotes assinados está descrita nos procedimentos seguintes.

Como criar um pacote não assinado no formato de diretório

O procedimento para a criação de um pacote não assinado no formato de diretório é igual ao procedimento para a criação de um pacote normal, conforme descrito previamente neste manual. O procedimento seguinte descreve o processo de criação do pacote não assinado no formato de diretório. Se você precisar de mais informações, consulte as seções anteriores sobre a construção de pacotes.

1. Crie o arquivo pkginfo.

   O arquivo pkginfo deve ter o seguinte conteúdo básico:

   PKG=SUNWfoo BASEDIR=/ NAME=My Test Package ARCH=sparc VERSION=1.0.0 CATEGORY=application

2. Crie um arquivo prototype.

   O arquivo prototype deve ter o seguinte conteúdo básico:

   $cat prototype i pkginfo d none usr 0755 root sys d none usr/bin 0755 root bin f none usr/bin/myapp=/tmp/myroot/usr/bin/myapp 0644 root bin

3. Liste o conteúdo do diretório de origem do objeto.

   Por exemplo:

   $ ls -lR /tmp/myroot

   A saída seria semelhante à seguinte:

   /tmp/myroot: total 16 drwxr-xr-x 3 abc other 177 Jun 2 16:19 usr /tmp/myroot/usr: total 16 drwxr-xr-x 2 abc other 179 Jun 2 16:19 bin /tmp/myroot/usr/bin: total 16 -rw------- 1 abc other 1024 Jun 2 16:19 myapp

4. Crie o pacote não assinado.

   pkgmk -d `pwd`

   A saída seria semelhante à seguinte:

   ## Building pkgmap from package prototype file. ## Processing pkginfo file. WARNING: parameter <PSTAMP> set to "syrinx20030605115507" WARNING: parameter <CLASSES> set to "none" ## Attempting to volumize 3 entries in pkgmap. part 1 -- 84 blocks, 7 entries ## Packaging one part. /tmp/SUNWfoo/pkgmap /tmp/SUNWfoo/pkginfo /tmp/SUNWfoo/reloc/usr/bin/myapp ## Validating control scripts. ## Packaging complete.

   O pacote existe agora no diretório atual.

Como importar os certificados para a chave de armazenamento de pacote

O certificado e a chave privada que serão importados devem existir como chave privada e certificado X.509 codificado em DER ou PEM. Além disso, o intermediário ou a “cadeia” de certificados que unem seu certificado assinado à Autoridade de certificado devem ser importados para a chave de armazenamento de pacote antes que um pacote seja assinado.

Cada Autoridade de certificado pode emitir certificados em vários formatos. Para extrair os certificados e a chave privada do arquivo PKCS12 e colocar no arquivo X.509 codificado em PEM (apropriado para a importação à chave de armazenamento de pacote), use um utilitário de conversão de software gratuito como o OpenSSL.

Se a sua chave privada estiver criptografada (que deveria ser geralmente o caso), você é solicitado a introduzir uma frase-senha. Você também será solicitado a introduzir uma senha para proteger a chave de armazenamento de pacote resultante. Você tem a opção de não fornecer a senha, mas como conseqüência a chave de armazenamento de pacote não será criptografada.

O procedimento seguinte descreve como importar os certificados usando o comando pkgadm uma vez o certificado esteja no formato apropriado.

1. Importe todos os certificados de Autoridade de certificado encontrados no seu arquivo de certificado X.509 codificado em DER ou PEM.

   Por exemplo, para importar todos os certificados de Autoridade de certificado encontrados no arquivo ca.pem, você deve digitar o seguinte:

   $ pkgadm addcert -k ~/mykeystore -ty ca.pem

   A saída seria semelhante à seguinte:

   Trusting certificate <VeriSign Class 1 CA Individual \ Subscriber-Persona Not Validated> Trusting certificate </C=US/O=VeriSign, Inc./OU=Class 1 Public \ Primary Certification Authority Type a Keystore protection Password. Press ENTER for no protection password (not recommended): For Verification: Type a Keystore protection Password. Press ENTER for no protection password (not recommended): Certificate(s) from <ca.pem> are now trusted

   A fim de importar sua chave assinada para a chave de armazenamento de pacote, você deve fornecer um alias que será usado mais tarde ao assinar o pacote. Este alias também pode ser usado se quiser excluir a chave da chave de armazenamento de pacote.

   Por exemplo, para importar sua chave assinada do arquivo sign.pem, você deve digitar o seguinte:

   $ pkgadm addcert -k ~/mykeystore -n mycert sign.pem

   A saída seria semelhante à seguinte:

   Enter PEM passphrase: Enter Keystore Password: Successfully added Certificate <sign.pem> with alias <mycert>

2. Verifique se os certificados estão na chave de armazenamento de pacote.

   Por exemplo, para visualizar os certificados na chave de armazenamento criada na etapa anterior, você deve digitar o seguinte:

   $ pkgadm listcert -k ~/mykeystore

Como assinar o pacote

Uma vez os certificados tenham sido importados para a chave de armazenamento de pacote, você pode assinar o pacote. A assinatura real do pacote é realizada com o comando pkgtrans.

1. Assine o pacote usando o comando pkgtrans. Forneça o local do pacote não assinado e o alias da chave para assinar o pacote.

   Por exemplo, usando os exemplos dos procedimentos anteriores, você deve digitar o seguinte para criar um pacote assinado denominado SUNWfoo.signed:

   $ pkgtrans -g -k ~/mykeystore -n mycert . ./SUNWfoo.signed SUNWfoo

   A saída deste comando seria semelhante à seguinte:

   Retrieving signing certificates from keystore </home/user/mykeystore> Enter keystore password: Generating digital signature for signer <Test User> Transferring <SUNWfoot> package instance

   O pacote assinado é criado no arquivo SUNWfoo.signed e está no formato de fluxo de pacote. Este pacote assinado é apropriado para copiar em um site da Web e ser instalado usando o comando pkgadd e um URL.