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)
Criando arquivos de informação e scripts de instalação (Mapa de tarefas)
Criando arquivos de informação
Definindo dependências do pacote
Como definir as dependências do pacote
Escrevendo uma mensagem de copyright
Como escrever uma mensagem de copyright
Reservando espaço adicional em um sistema de destino
Como reservar espaço adicional em um sistema de destino
Processamento de script durante a instalação do pacote
Processamento de script durante a remoção do pacote
Variáveis de ambiente de pacote disponíveis para os scripts
Obtendo informações do pacote para um script
Comportamentos do script request
Regras de criação para scripts request
Como escrever um script request
Coletando dados do sistema de arquivos com o script checkinstall
Comportamentos do script checkinstall
Regras de criação para scripts checkinstall
Como coletar dados do sistema de arquivos
Escrevendo scripts de procedimento
Comportamentos do script de procedimento
Regras de criação dos scripts de procedimento
Como escrever scripts de procedimento
Escrevendo scripts de ação de classe
Como as classes são processadas durante a instalação do pacote
Como as classes são processadas durante a remoção do pacote
Comportamentos do script de ação de classe
Regras de criação para sripts de ação de classe
Adicionando certificados de confiança à chave de armazenamento de pacote
Adicionando um certificado de usuário e chave privada à chave de armazenamento de pacote
Verificando o conteúdo na chave de armazenamento de pacote
Excluindo certificados de usuário e chaves privadas da chave de armazenamento de pacote
Como criar um pacote não assinado no formato de diretório
Como importar os certificados para a chave de armazenamento de pacote
4. Verificando e transferindo um pacote
5. Estudos de caso de criação de pacote
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 solicita dados do administrador que estiver instalando um pacote para atribuição ou redefinição das variáveis de ambiente.
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.
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.
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).
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:
Executa o script request.
Esta etapa é o único ponto no qual seu pacote pode solicitar entrada do administrador que estiver instalando o pacote.
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.
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.
Cria links simbólicos, dispositivos, pipes nomeados e diretórios necessários.
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.
Cria todos os links de disco rígido.
Quando está sendo removido, o comando pkgrm realiza as seguintes etapas:
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.
Remove os links de disco rígido.
Remove os arquivos regulares.
Remove os links simbólicos, os dispositivos e os pipes nomeados.
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.
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.
|
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 4, Verificando e transferindo um pacote para obter mais informações.
Cada script deve sair com um dos códigos de saída ilustrados na tabela seguinte.
Tabela 3-2 Códigos de saída de script instalação
|
Consulte Capítulo 5, Estudos 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.
Observaçã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).
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.
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 noaccessnã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.
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.
Observação - Se os administradores que instalarão o seu pacote puderem usar o produto JumpStart, 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).
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.
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 4, Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.
O script checkinstall é executado brevemente depois do script request opcional. O script de checkinstall é executado como o usuário noaccess, se tal usuário existir. 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.
Observação - O script checkinstall está disponível a partir do Solaris 2.5 e versões compatíveis.
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 noaccess 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.
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.
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.
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 4, Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.
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.
É executado antes do início da instalação da classe. Nenhum arquivo deve ser instalado por este script.
É executado depois que todos os volumes tiverem sido instalados.
É executado antes do início da remoção da classe. Nenhum arquivo deve ser removido por este script.
É executado depois que todas as classes tiverem sido removidas.
Os scripts de procedimento são executados como uid=root e gid=other.
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 5, Estudos 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 5, Estudos 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.
Um script de procedimento deve ser nomeado com um dos nomes predefinidos: preinstall, postinstall, preremove ou postremove.
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.
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 4, Verificando e transferindo um pacote explica estas tarefas e oferece instruções detalhadas sobre como transferir o pacote verificado a um meio de distribuição.
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).
Observação - 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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 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 5, Estudos 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.
Observação - 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.
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.
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.
O sistema fornece quatro classes especiais:
Oferece um método para uso de instruções sed para editar arquivos na instalação e na remoção do pacote.
Oferece um método para uso de instruções awk para editar arquivos na instalação e na remoção do pacote.
Oferece um método para construir ou modificar dinamicamente um arquivo usando comandos de shell.
Oferece um método para preservar arquivos que não devem ser substituídos por futuras instalações de pacote.
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 .
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 5, Estudos de caso de criação de pacote.
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).
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 5, Estudos de caso de criação de pacote para obter outros exemplos que usem a classe build.
A classe preserve preserva um arquivo do objeto de pacote determinando 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.
A classe manifest instala e desinstala automaticamente os serviços SMF (Service Management Facility) associados a um manifest SMF.. Se você não conhece o SMF, consulte o Capítulo 18, Managing Services (Overview), no Oracle Solaris Administration: Basic Administration para obter informações sobre como usar o SMF para gerenciar 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 # # 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
Observação - Não inclua os arquivos i.manifest e r.manifest nos seus pacotes, pois esses scripts de ação de classe são parte do SO do Oracle Solaris e variam entre as versões. A inclusão desses arquivos tornará seus pacotes menos portáveis entre as diferentes versões do Oracle Solaris.
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
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.
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).
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.
Consulte Como construir um pacote, se necessário.
Depois de construir o pacote, instale-o para confirmar que ele é instalado corretamente e verificar sua integridade. O Capítulo 4, Verificando 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.