Unificar scripts personalizados em todo o sistema com rpm no Red Hat/CentOS
- 2006
- 158
- Mrs. Willie Beahan
Objetivo
Nosso objetivo é criar pacotes de RPM com conteúdo personalizado, unificando scripts em qualquer número de sistemas, incluindo versões, implantação e não -implantação.
Sistema operacional e versões de software
- Sistema operacional: Red Hat Enterprise Linux 7.5
- Programas: RPM-Build 4.11.3+
Requisitos
Acesso privilegiado ao sistema para instalação, acesso normal para construção.
Dificuldade
MÉDIO
Convenções
- # - requer que os comandos Linux sejam executados com privilégios root diretamente como usuário root ou por uso de
sudocomando - $ - dados os comandos do Linux a serem executados como um usuário não privilegiado regular
Introdução
Uma das principais características de qualquer sistema Linux é que eles são construídos para automação. Se uma tarefa pode precisar ser executada mais de uma vez - mesmo com alguma parte mudando na próxima execução - um sysadmin é fornecido com inúmeras ferramentas para automatizá -lo, de simples concha scripts executados à mão sob demanda (eliminando assim erros de erro Cron Em um horário especificado, interagindo entre si, trabalhando com o resultado de outro script, talvez controlado por um sistema de gerenciamento central etc.
Embora essa liberdade e um rico conjunto de ferramentas realmente aumentem a produtividade, há um problema: como um sysadmin, você escreve um script útil em um sistema, o que prova ser útil em outro, para que você copie o script sobre. Em um terceiro sistema, o script também é útil, mas com pequenas modificações - talvez um novo recurso útil apenas nesse sistema, acessível com um novo parâmetro. Generalização em mente, você estende o script para fornecer o novo recurso e concluir a tarefa para a qual foi escrito. Agora você tem duas versões do script, o primeiro está nos dois primeiros sistemas, o segundo no terceiro sistema.
Você tem 1024 computadores em execução no datacenter e 256 deles precisarão de parte da funcionalidade fornecida por esse script. Com o tempo, você terá 64 versões do script, todas as versões fazendo seu trabalho. Na próxima implantação do sistema, você precisa de um recurso que você se lembra que codificou em alguma versão, mas qual? E em quais sistemas eles estão?
Em sistemas baseados em RPM, como sabores de Red Hat, um sysadmin pode aproveitar o gerenciador de pacotes para criar ordem no conteúdo personalizado, incluindo scripts simples que podem não fornecer mais, mas as ferramentas que o administrador escreveu para conveniência.
Neste tutorial, criaremos um RPM personalizado para Red Hat Enterprise Linux 7.5 contendo dois Bash scripts, PARSELOGS.sh e PullNews.sh para fornecer uma maneira de todos os sistemas terem a versão mais recente desses scripts no /usr/local/sbin diretório e, portanto, no caminho de qualquer usuário que efetue login no sistema.
Distribuições, versões principais e menores
Em geral, a versão menor e principal da máquina de construção deve ser a mesma que os sistemas que o pacote deve ser implantado, bem como a distribuição para garantir a compatibilidade. Se houver várias versões de uma determinada distribuição, ou mesmo distribuições diferentes com muitas versões em seu ambiente (oh, alegria!), você deve configurar máquinas de construção para cada. Para reduzir o trabalho, você pode simplesmente configurar o ambiente de construção para cada distribuição e cada versão principal e tê -los na versão menor mais baixa existente em seu ambiente para a versão principal especificada. Por causa, eles não precisam ser máquinas físicas e só precisam estar funcionando no momento da construção, para que você possa usar máquinas ou contêineres virtuais.
Neste tutorial, nosso trabalho é muito mais fácil, implantamos apenas dois scripts que não têm dependências (exceto Bash), então vamos construir Noarch Pacotes que representam “não dependentes da arquitetura”, também não especificaremos a distribuição que o pacote é construído para. Dessa forma, podemos instalá -los e atualizá -los em qualquer distribuição que use RPM, e para qualquer versão - precisamos apenas garantir que a máquina de construção RPM-Build O pacote está na versão mais antiga do ambiente.
Configurando o ambiente de construção
Para criar pacotes de RPM personalizados, precisamos instalar o RPM-Build pacote:
# yum install rpm-build
De agora em diante nós não use raiz usuário, e por um bom motivo. Pacotes de construção não requer raiz privilégio, e você não quer quebrar sua máquina de construção.
Construindo a primeira versão do pacote
Vamos criar a estrutura de diretório necessária para a construção:
$ mkdir -p rpmbuild/especificações
Nosso pacote é chamado de admin-scripts, versão 1.0. Nós criamos um especfile que especifica os metadados, o conteúdo e as tarefas executadas pelo pacote. Este é um arquivo de texto simples que podemos criar com nosso editor de texto favorito, como vi. O instalado anteriormente rpMbuild o pacote preencherá seu especfile vazio com dados de modelo se você usar vi Para criar um vazio, mas para este tutorial, considere a especificação abaixo chamada admin-scripts-1.0.espec:
Nome: Admin-scripts Versão: 1 Liberação: 0 Resumo: Foobar Inc. Departamento. Admin Scripts Packager: John Doe Group: Aplicação/Outra Licença: GPL URL: www.Foobar.com/admin-scripts fonte0: %name- %versão.alcatrão.GZ Buildarch: Noarch %Descrição Pacote Instalando a versão mais recente Os scripts administrativos usados pelo departamento de TI. %prep %setup -q %build %install rm -rf $ rpm_build_root mkdir -p $ rpm_build_root/usr/local/sbin cp scripts/* $ rpm_build_root/usr/local/sbin/clean rm -rf $ rpm_bil (-, raiz, raiz,-) %dir/usr/local/sbin/usr/local/sbin/parselogs.sh/usr/local/sbin/pullnews.sh %doc %changelog * quarta -feira, 1 de agosto de 2018 John Doe - Release 1.0 - Lançamento inicial Coloque o especfile no rpmbuild/spec Diretório que criamos anteriormente.
Precisamos das fontes referenciadas no especfile - Nesse caso, os dois scripts de shell. Vamos criar o diretório para as fontes (chamadas como o nome do pacote anexado à versão principal):
$ mkdir -p rpmbuild/fontes/admin-scripts-1/scripts
E copie/mova os scripts para ele:
$ ls rpmbuild/fontes/admin-scripts-1/scripts/parselogs.sh pullnews.sh Como este tutorial não é sobre scripts de shell, o conteúdo desses scripts é irrelevante. Como criaremos uma nova versão do pacote, e o PullNews.sh é o script que demonstraremos, sua fonte na primeira versão está abaixo:
#!/Bin/Bash Echo "News puxado" Sair 0 Não se esqueça de adicionar os direitos apropriados aos arquivos da fonte - no nosso caso, execução correta:
chmod +x rpmbuild/fontes/admin-scripts-1/scripts/*.sh
Agora criamos um alcatrão.gz Arquivo da fonte no mesmo diretório:
CD rpMbuild/ fontes/ && tar -czf admin-scripts-1.alcatrão.GZ admin-scripts-1Estamos prontos para construir o pacote:
rpmbuild-bb rpmbuild/specs/admin-scripts-1.0.espec
Teremos alguma saída sobre a compilação e, se algo der errado, os erros serão mostrados (por exemplo, arquivo ou caminho ausente). Se tudo correr bem, nosso novo pacote aparecerá no diretório RPMS gerado por padrão rpMbuild Diretório (classificado em subdiretos por arquitetura):
$ ls rpmbuild/rpms/noarch/admin-scripts-1-0.Noarch.RPM
Criamos um pacote RPM simples, mas totalmente funcional. Podemos consultá -lo para todos os metadados que fornecemos anteriormente:
$ rpm -qpi rpmbuild/rpms/noarch/admin-scripts-1-0.Noarch.RPM Nome: Admin-scripts Versão: 1 Release: 0 Arquitetura: Noarch Data de instalação: (não instalado) Grupo: Aplicativo/Other Tamanho: 78 Licença: GPL Assinatura: (Nenhum) Fonte RPM: Admin-Scripts-1-0.src.RPM Data de construção: 2018. AUG. 1., Qua, 13.27.34 CEST Build Host: Build01.Foobar.Relocações com: (não relocável) Packager: John Doe URL: www.Foobar.Resumo com/admin-scripts: Foobar Inc. Departamento. Scripts de administrador Descrição: Pacote Instalando a versão mais recente Os scripts de administrador usados pelo departamento de TI. E por causa que podemos instalá -lo (com raiz privilégios):
Instalando scripts personalizados com RPM Enquanto instalamos os scripts em um diretório que está em todos os usuários $ Caminho, Você pode executá -los como qualquer usuário do sistema, de qualquer diretório:
$ PULLNEWS.SH News foi parado O pacote pode ser distribuído como é e pode ser empurrado para repositórios disponíveis para qualquer número de sistemas. Fazer isso está fora do escopo deste tutorial - no entanto, construir outra versão do pacote certamente não é.
Construindo outra versão do pacote
Nosso pacote e os scripts extremamente úteis se tornam populares em pouco tempo, considerando que eles estão acessíveis em qualquer lugar com um simples yum install scripts admin dentro do ambiente. Em breve haverá muitos pedidos para algumas melhorias - neste exemplo, muitos votos vêm de usuários felizes que o PullNews.sh deve imprimir outra linha sobre execução, esse recurso salvaria toda a empresa. Precisamos construir outra versão do pacote, pois não queremos instalar outro script, mas uma nova versão com o mesmo nome e caminho, pois os sysadmins em nossa organização já dependem muito disso.
Primeiro, mudamos a fonte do PullNews.sh Nas fontes para algo ainda mais complexo:
#!/Bin/Bash Echo "News puxado" Echo "Outra linha impressa" Sair 0
Precisamos recriar o alcatrão.GZ com o novo conteúdo de origem - podemos usar o mesmo nome de arquivo que a primeira vez, pois não alteramos a versão, apenas a liberação (e assim o Fonte0 referência ainda será válida). Observe que excluímos o arquivo anterior primeiro:
CD rpMbuild/ fontes/ && rm -f admin-scripts-1.alcatrão.gz && tar -czf admin-scripts-1.alcatrão.GZ admin-scripts-1Agora criamos outro especfile com um número de lançamento mais alto:
CP rpMbuild/specs/admin-scripts-1.0.Spec rpMbuild/specs/admin-scripts-1.1.especNão mudamos muito no próprio pacote, então simplesmente administramos a nova versão, como mostrado abaixo:
Nome: Admin-scripts Versão: 1 Liberação: 1 Resumo: Foobar Inc. Departamento. Admin Scripts Packager: John Doe Group: Aplicação/Outra Licença: GPL URL: www.Foobar.com/admin-scripts fonte0: %name- %versão.alcatrão.GZ Buildarch: Noarch %Descrição Pacote Instalando a versão mais recente Os scripts administrativos usados pelo departamento de TI. %prep %setup -q %build %install rm -rf $ rpm_build_root mkdir -p $ rpm_build_root/usr/local/sbin cp scripts/* $ rpm_build_root/usr/local/sbin/clean rm -rf $ rpm_bil (-, raiz, raiz,-) %dir/usr/local/sbin/usr/local/sbin/parselogs.sh/usr/local/sbin/pullnews.sh %doc %changelog * Qua 22 de agosto de 2018 John Doe - Liberação 1.1 - PullNews.sh v1.1 imprime outra linha * Qua 1 de agosto de 2018 John Doe - Release 1.0 - Lançamento inicial
Tudo feito, podemos criar outra versão do nosso pacote que contém o script atualizado. Observe que fazemos referência ao SpecFile com a versão superior como fonte da construção:
rpmbuild-bb rpmbuild/specs/admin-scripts-1.1.espec
Se a construção for bem -sucedida, agora temos duas versões do pacote no nosso diretório RPMS:
ls rpmbuild/rpms/noarch/admin-scripts-1-0.Noarch.RPM admin-scripts-1-1.Noarch.RPM E agora podemos instalar o script "avançado" ou atualizar se ele já estiver instalado.
Atualizando scripts personalizados com RPM E nossos sysadmins podem ver que a solicitação de recurso é desembarcada nesta versão:
RPM -Q --CHANGELOG admin -scripts * Qua 22 de agosto de 2018 John Doe -Release 1.1 - PullNews.sh v1.1 Imprime outra linha * Qua 01 de agosto de 2018 John Doe - Release 1.0 - Lançamento inicial
Conclusão
Envolvemos nosso conteúdo personalizado em pacotes de RPM versionados. Isso significa que nenhuma versões mais antigas deixadas espalhadas pelos sistemas, tudo está em seu lugar, na versão que instalamos ou atualizamos. O RPM oferece a capacidade de substituir coisas antigas necessárias apenas em versões anteriores, pode adicionar dependências personalizadas ou fornecer algumas ferramentas ou serviços que nossos outros pacotes dependem. Com o esforço, podemos embalar quase qualquer um de nossos conteúdos personalizados em pacotes de RPM e distribuí -lo em todo o ambiente, não apenas com facilidade, mas com consistência.
Tutoriais do Linux relacionados:
- Coisas para instalar no Ubuntu 20.04
- Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
- Arquivos de configuração do Linux: os 30 primeiros mais importantes
- Uma introdução à automação, ferramentas e técnicas do Linux
- Download do Linux
- Linux pode obter vírus? Explorando a vulnerabilidade do Linux…
- Coisas para fazer depois de instalar o Ubuntu 22.04 Jellyfish…
- Melhor distro Linux para desenvolvedores
- Ubuntu 20.04 Guia
- Como migrar de CentOS para Almalinux
- « Como alterar o tamanho da fonte do console TTY no Ubuntu 18.04 servidor
- Implantação de um exemplo de aplicativo no contêiner Apache Tomcat »