Atualização automatizada do kernel

2

Estou escrevendo um script BASH que configura, constrói e instala automaticamente a imagem do kernel mais recente. O kernel gerado deve incluir o patchset grsecurity . Ele usaria a configuração anterior de /proc/config.gz , que eu criei manualmente ao compilar o primeiro kernel personalizado na máquina.

É seguro automatizar totalmente o processo? Ficaria assim:

  1. Verifique o kernel mais recente que grsecurity está disponível para
  2. Faça o download do conjunto de patch grsecurity e da árvore de origem do kernel correspondente
  3. Corrigir o kernel
  4. Copie o arquivo de configuração do kernel anterior no diretório de origem do kernel
  5. Execute make olddefconfig para configurar o kernel com base na configuração anterior
  6. Compile o kernel com fakeroot make deb-pkg
  7. Instale os pacotes resultantes e altere a prioridade do carregador de inicialização
  8. Envie-me um e-mail indicando que uma reinicialização é necessária

A questão principal: é provável que um kernel compilado com olddefconfig conterá erros que impedem o sistema de inicializar se a configuração anterior estiver funcionando corretamente? É muito importante porque é um servidor remoto acessado via SSH e um resgate manual exigiria muito esforço.

    
por psimon 20.06.2014 / 23:30

1 resposta

2

Se você não puder pagar pelo fracasso, teste.
Mesmo se você puder pagar, o teste é bom. Se possível, execute a construção em um ambiente de teste dedicado. Em muitos casos, um convidado virtual cria um sistema de teste adequado. Quando você reinicializar a cab em seu kernel atualizado e todos os testes subseqüentes forem concluídos com êxito também, copie e implante o novo pacote em seu sistema remoto.

Agora, a sua pergunta principal: o seu plano e make olddefconfig contêm erros que resultarão em falha de inicialização? Apenas um idiota acreditaria que qualquer sistema fosse completamente infalível. Quando você quiser rodar o kernel mais recente , como você disse, você terá uma vantagem e terá todas as vantagens e riscos associados a isso. Reduzir risco é selecionar uma versão de longo prazo em que um conjunto de recursos é congelado e apenas correções de bugs / segurança serão introduzidas.

Independentemente: qualquer reinicialização apresenta um pequeno risco de falha.

Em uma nota lateral: Eu gastei muitas horas no passado em datacenters reparando problemas / configurações incorretas em servidores que eu recomendo que todos sempre adicionem uma opção de gerenciamento remoto adequada (por exemplo, HP ILO, DRAC da Dell, ILOM da Oracle etc. ou um gateway KVM sobre IP) para seus servidores remotos, que permite corrigir a maioria dos problemas no conforto de sua mesa.

    
por 21.06.2014 / 00:25