Qual é a melhor prática para manter um servidor linux ubuntu atualizado (compilar pacotes, dist-upgrade, alt repos ...)


8

Estamos executando um servidor de produção baseado no Ubuntu 9.10 Karmic Koala , o kernel está quase atualizado (2.6.38.2-grsec-xxxx-grs-ipv6-64), mas o repositório de pacotes karmic agora está ridiculamente desatualizado, por exemplo. Nginx é 0.7.62 - realmente buggy - enquanto o último estável é 1.0.x !!

Além disso, Karmic acabou de chegar ao fim da vida.

Esta pergunta: Práticas recomendadas para manter os pacotes UNIX atualizados? parece semelhante, mas na verdade inclui apenas algumas sugestões sobre gerenciadores de pacotes; não é o que eu preciso!

então as opções que eu vejo são:

  1. obtenha uma nova máquina, instale-a do zero, migre
  2. atualização de distribuição
  3. use um repositório diferente ( barra de ativação / ppa / backport / pinning )
  4. Construa o seu próprio

As desvantagens do 1. são bastante óbvias.

Porém, não me atrevo a fazer um caminho de atualização dist, pois o tempo de inatividade e as possíveis consequências catastróficas são impossíveis de prever para um servidor de produção e, atualmente, estão na maioria das vezes reconstruindo meus próprios pacotes necessários. Mas tenho certeza que posso estar perdendo alguns.

Não está realmente claro para mim quais são os riscos (estabilidade / compatibilidade) do uso de backports do ubuntu, além disso, nada é oficialmente fornecido para a 9.10. A barra de ativação é uma construção semelhante, pergunta semelhante - quão melhor é isso do que compilar a sua.

Construir pacotes parece bom, mas: 1. Às vezes, tenho problemas para reproduzir as opções ./configure corretas para reutilizar meus arquivos de configuração existentes. de insetos

Finalmente ... e os pacotes 'antigos' em um distrito recente? Eu acho que não há outra maneira senão reconstruí-los eu mesmo? Uma combinação de 2. e 4. finalmente é o melhor caminho?

Existe algum consenso objetivo sobre qual é a melhor maneira de fazer isso, ou razões pelas quais algumas de minhas opções são boas / não boas?

Se realmente não houver, aceitarei que a pergunta seja encerrada antes de criar um encadeamento sem fim!


1
É por razões que você está enfrentando que apenas as versões LTS devem ser usadas para servidores. Em resposta à sua pergunta, até que você possa fazer o nº 1 ou o nº 2, ficará com o nº 4. Eu posso ver o número 3 começando a falhar com frequência à medida que o tempo passa, pois as dependências não estão disponíveis.
Daemonofchaos

de fato, @KayakJim, embora devêssemos ter descoberto na época - mas quando a carga do servidor era baixa, a manutenção seria aceitável, não pensávamos muito à frente. lição aprendida (espero).
Stefano

Respostas:


4

Manter sua própria distribuição é muito trabalhoso. Mesmo que você mantenha os backports, em breve você ficará sobrecarregado com problemas de segurança para corrigir e precisará puxar bibliotecas de baixo nível para continuar atualizando seu software, o que pode quebrar outras coisas (eu mantenho servidores executando distros de 6 anos, é não tem graça).

A atualização geralmente é uma boa solução. do-release-upgradeé bem feito e você deve poder atualizar sem problemas (especialmente se você usou apenas pacotes oficiais).

Minha solução favorita pode ser o caminho de reinstalação. Mais especificamente, seus servidores devem ser gerenciados usando um sistema de gerenciamento de configurações, como Puppet, Cfengine ou Chef. Se todas as suas necessidades de configuração / pacote forem especificadas usando essa ferramenta e seus dados estiverem seguros em uma partição separada, será muito mais fácil reinstalar rapidamente. Você acabou de instalar uma nova distribuição sem apagar as partições de dados e, em seguida, executa a ferramenta de gerenciamento de configuração para redefinir seus pacotes / configurações. Acredito que esta é a maneira mais limpa de fazer, especialmente se você tiver vários servidores para gerenciar.

Se você estiver usando pacotes não oficiais, poderá identificá-los antes de atualizar / reinstalar. maintenance-check pode ajudar a identificar os pacotes que não são oficialmente mantidos pelo Ubuntu:

$ bzr branch lp:ubuntu-maintenance-check
$ cd ubuntu-maintenance-check
$ ./maintenance-check -f n

Se você deseja reinstalar, também pode exportar a lista de pacotes instalados:

$ dpkg --get-selections > myinstall.txt

e seu banco de dados debconf:

$ debconf-get-selections > debconf.txt # from the debconf-utils package

Como uma observação, como você está atualmente usando o Karmic, pode não ser muito violento atualizar para o Lucid, que é uma versão LTS, ainda suportada até 2015 para os principais pacotes de servidores. Isso deve lhe dar tempo suficiente para configurar uma instalação automatizada viável para o futuro.

Quando você pergunta sobre pacotes do Launchpad, suponho que você queira dizer PPAs. Existem toneladas de diferentes CAE. Alguns são experimentais, alguns são estáveis. Alguns são mantidos por desenvolvedores oficiais do Ubuntu, outros são mantidos por pessoas que mal sabem como fazer um pacote corretamente. É difícil dizer em geral se os pacotes encontrados nos PPAs são bons, não há regra geral. A melhor dica nesse caso pode ser procurar o proprietário dos PPAs para ter uma idéia da possível qualidade de seus pacotes.


é claro que não pensamos em fantoches e companhia. no momento. Mas, na verdade, você está convencido de que, se seguirmos o caminho de reinstalação, é melhor preparar adequadamente uma instalação fácil de replicar. PS. "especialmente se você usou apenas pacotes oficiais", é claro que não, infelizmente!
Stefano

Em seguida, o primeiro passo que você pode dar é identificar os pacotes não oficiais. maintenance-checkpode ajudá-lo com isso (veja minha edição).
ℝaphink

Resposta selecionada para dicas adicionais, incluindo o uso de sistemas de gerenciamento de conf e verificação de manutenção e sobre PPAs. Acabei de perceber, depois de examinar os repositórios mais recentes, que os pacotes nem sempre estão atualizados, por exemplo. mesmo na versão 11.04 do nginx é OLD (0.8.54-4) e eles nunca passarão para 1.0.x nesse distrito. Algum conselho para essas situações?
Stefano

1
@Stefano: O Ubuntu usa o mesmo tipo de política que o Debian, ou seja, o software não é atualizado nos principais repositórios após o lançamento (após o congelamento de recursos para ser mais preciso). Isso pode realmente levar a versões antigas do software em uma versão ainda mantida (especialmente se o software for lançado rapidamente). Você pode usar backports para obter novas versões, mas provavelmente perderá atualizações de estabilidade e segurança. Não existe uma solução perfeita para isso, a menos que você esteja disposto a manter seus próprios backports, o que, como afirmei antes, é bastante caro.
26411

2

Se o servidor não estiver exposto ao mundo e você confiar totalmente em seus usuários (geralmente isso não é uma boa ideia), se estiver funcionando, você pode simplesmente deixar como está.

Se ele estiver exposto de alguma forma ao mundo exterior e / ou você tiver a ideia de um usuário legítimo jogando com ele de maneira ilegítima, precisará absolutamente de correções e correções no software instalado.

Nesse caso, você tem duas opções:

  1. Execute uma distribuição suportada e obtenha atualizações para o seu software ou

  2. Faça o backport de todas as correções para sua distribuição não suportada, o que, francamente falando, não parece viável.

Como não sou usuário do Ubuntu, não posso comentar sobre a integridade dos patches que você obteria com a opção 3, mas se tiver alguma dúvida, presumo que você não terá cobertura completa.

A melhor solução é mudar para uma versão LTS do Ubuntu, que fornecerá suporte para as versões de pacotes especificadas por algum tempo. Com o tempo, alguns dos pacotes ficarão desatualizados, mas seu ambiente terá patches de segurança e permanecerá estável (sem problemas de versão do pacote). Pela minha experiência, a estabilidade de um ambiente de trabalho conhecido geralmente é mais valiosa do que novos recursos.

Parece que sua posição atual não é sustentável e você precisa se mudar. A única maneira segura é obter uma segunda máquina (ou uma máquina virtual) e testar as migrações até que você tenha um procedimento repetitivo e bem-sucedido, depois aplicá-lo à máquina de produção. Se você usar seus backups para fazer migrações de teste, também terá uma boa oportunidade de testar seus procedimentos de backup.


obrigado @ Pawel-Brodacki. O servidor está definitivamente exposto! Entendo o seu ponto de vista da estabilidade sobre os recursos. O problema é que muitas vezes a estabilidade vem com as principais etapas da versão. Por exemplo. A série nginx 1.0. * é mais estável do que a série 0.8 incluída mesmo na versão mais recente. Alguma sugestão sobre isso?
Stefano

1
Se atualmente é bom o suficiente, aplica-se a regra "se não estiver quebrada, não conserte". Depois disso, é o cálculo dos negócios: a estabilidade adicionada economiza mais do que o custo de manter um conjunto de pacotes sozinho. Se for apenas o nginx, ou o nginx e várias bibliotecas, compilando sozinho, teste e implantação é algo que pode ser feito. Nesse caso, no entanto, seria prudente acompanhar de perto o desenvolvimento dos pacotes para fechar rapidamente quaisquer bugs descobertos.
Paweł Brodacki 26/05

2

O único caminho real a seguir é uma atualização de distribuição. Eu posso entender que você está nervoso com isso, já que agora você estará pulando vários lançamentos à frente (11.04 acaba de ser lançado).

Eu recomendaria fazer um clone das unidades nesta máquina e, em seguida, usar um computador separado para executar com os clones e usá-lo para fazer uma série de atualizações de teste. Faça anotações de todos os problemas encontrados e repita até que você tenha um procedimento claro para todos eles. Em seguida, aplique isso ao seu servidor ativo.

Se você não puder pagar nenhum tempo de inatividade, a migração é sua única saída. Esqueça as fixações e backports, que só o manterão vivo por um período limitado de tempo. E a opção "role o seu próprio" nem vale a pena considerar. Apenas meus 2 centavos.

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.