É importante reiniciar o Linux após uma atualização do kernel?


19

Eu tenho alguns servidores Web de produção do Fedora e Debian que hospedam nossos sites, bem como contas de shell de usuário (usadas para o trabalho do git vcs, algumas sessões screen + irssi, etc.).

Ocasionalmente, uma nova atualização do kernel será lançada em yum/ apt-get, e eu queria saber se a maioria das correções é grave o suficiente para garantir uma reinicialização ou se posso aplicar as correções sem a reinicialização.

Atualmente, nosso servidor de desenvolvimento principal possui 213 dias de atividade, e eu não tinha certeza se era inseguro executar um kernel tão antigo.


Você realmente deve separar a hospedagem de produção (razoavelmente exposta e crítica à segurança, deve receber atualizações imediatamente) da execução de repositórios git (provavelmente apenas usuários confiáveis, mas deve ser seguro) e sessões de tela geral. VMs são baratas!
poolie 27/05

Respostas:


24

Não há nada realmente especial em ter um longo tempo de atividade. Geralmente é melhor ter um sistema seguro. Todos os sistemas precisam de atualizações em algum momento. Você provavelmente já está aplicando atualizações. Você programa interrupções quando as aplica? Você provavelmente deveria apenas no caso de algo dar errado. Uma reinicialização não deve demorar muito.

Se o seu sistema é tão sensível a interrupções, você provavelmente deve estar pensando em algum tipo de configuração de cluster, para atualizar um único membro do cluster sem reduzir tudo.

Se você não tiver certeza sobre uma atualização específica, provavelmente é mais seguro agendar uma reinicialização e aplicá-la (de preferência após testá-la em outro sistema similar).

Se você estiver interessado em saber se a atualização é importante, leia o aviso de segurança e siga os links de volta para o CVE ou as postagens / listas / blogs que descrevem o problema. Isso deve ajudá-lo a decidir se a atualização se aplica diretamente ao seu caso.

Mesmo que você não pense que isso se aplica, você ainda deve considerar atualizar seu sistema eventualmente. A segurança é uma abordagem em camadas. Você deve assumir que em algum momento essas outras camadas podem falhar. Além disso, você pode esquecer que possui um sistema vulnerável porque pulou uma atualização quando alterou a configuração em algum momento posterior.

De qualquer forma, se você quiser ignorar ou esperar um pouco para atualizar os sistemas baseados no Debian, poderá colocar o pacote em espera. Pessoalmente, gosto de colocar em todos os pacotes do kernel por precaução.

Método CLI para definir uma retenção em um pacote em sistemas baseados em Debian.

dpkg --get-selections | grep 'linux-image' | sed -e 's/install/hold/' | sudo dpkg --set-selections

11
Não é que precisamos estar sempre ativos, mas sim que alguns de nossos usuários tenham sessões abertas (ou seja, IRC) que podem ser irritantes (da perspectiva do usuário) para reiniciar.
Lfaraone 19/05/09

12

A maioria das atualizações não requer reinicialização, mas as atualizações do kernel exigem (você realmente não pode substituir o kernel em execução sem reiniciar).

Uma coisa que eu descobri é que, se o servidor estiver em execução por um longo tempo sem uma reinicialização, é mais provável que você queira fazer verificações de disco (fsck) quando reiniciar, e isso pode aumentar significativamente o tempo necessário para voltar. instalado e funcionando novamente. Melhor antecipar isso e planejar.

Eu também descobri que as alterações na configuração às vezes podem ser perdidas e não serão notadas até uma reinicialização (como adicionar novas regras de endereços IP / tabelas de ip etc.) Isso também aumenta o "risco de tempo de inatividade" ao reiniciar com pouca frequência.

É melhor planejar algum tempo de inatividade ao fazer uma reinicialização - ou, se essa não for uma opção desejável, configure seus servidores em clusters para que as reinicializações possam ser realizadas, se necessário.


8

Se você só precisa de atualizações de segurança e não de um kernel completamente novo, pode estar interessado no Ksplice - ele permite corrigir certas atualizações do kernel em um kernel em execução.


Somente Oracle Linux: |
rogerdpack

3

Não há uma resposta simples para isso, algumas atualizações do kernel não são realmente relacionadas à segurança e algumas podem corrigir problemas de segurança que não afetam você, enquanto outros podem afetá-lo.

A melhor abordagem imo é se inscrever nas listas de discussão de segurança relevantes, como o security-Announcer do ubuntu, para que você possa ver quando os patches de segurança estão sendo lançados e como eles podem afetá-lo.

Eu também consideraria apticron ou similar para obter os detalhes e os registros de alterações de qualquer outra atualização de pacote.


2

Essa é uma função da atualização - se ela corrigir um priv. escalada que resulta em acesso root, convém aplicá-lo.


2

No caso de você não reiniciar, verifique se o novo kernel não é o padrão para iniciar na inicialização.

A última coisa que você deseja é que um kernel não testado esteja sendo usado para produção após uma reinicialização não planejada.


1

Como o mibus mencionou, se você instalar o kernel e não reiniciar, verifique se não é o padrão. Você não sabe se ou em que estado o servidor voltará, portanto, verifique se ele foi testado.

Dito isto, acho bom adotar o hábito de reiniciar máquinas regularmente, sempre que possível. Muitas falhas de hardware e software se manifestam apenas em uma reinicialização e é melhor descobrir isso quando você está planejando uma reinicialização, e não durante uma interrupção não planejada.


0

Observe que algumas das atualizações do kernel da debian requerem (bem, recomendo) que você reinicie o mais rápido possível depois de aplicá-las.

Este é o caso em que a diferença não é suficiente para garantir uma alteração no diretório dos módulos, mas os módulos podem ser diferentes.

Você será avisado pelo Debian quando instalar esses pacotes de kernel.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.