Você usou o Debian unstable / testing em um servidor de produção / pessoal?

Question

Eu prefiro o Debian GNU / Linux como sistema operacional para servidores. Eu geralmente tendem a pensar que o estável é a melhor escolha. Mas eu uso instável / teste na área de trabalho.

Existem casos reais de servidores usando o Debian instável / testing?

    

Answer 1

Dois anos atrás, precisávamos do PHP5 no ambiente de produção. O Debian estável ainda não estava lá e, por algum motivo, os backports não foram considerados. Deixamos a nossa empresa de hospedagem instalar testes e funcionou bem.

No entanto, agora que precisamos atualizar para Lenny, simplesmente não podemos atualizar o sistema de produção em movimento, temos que clonar o sistema, atualizar, testar, etc., porque os números de versão de muitos aplicativos aumentaram bastante nos últimos dois anos.

Então, isso agora cria trabalho para nós (horas de trabalho internas) e também carga útil para nossa empresa de hospedagem, que temos que pagar.

Lição aprendida; ou pelo menos da próxima vez eu estou preparado para o que vem no futuro.

    

Answer 2

Se for produção, não use instável. Use stable e backports, e teste se for necessário. O teste é aceitável para uma máquina desktop que você pode gastar por um dia. Não é para produção.

Além disso, o Zoredache mencionou o apt-pinning. É um pouco confuso no começo, mas vale a pena aprender. Se você seguir essa rota, comece lendo a página man do apt_preferences. A chave para o apt-pinning é mantê-lo simples e começar pequeno.

Uma última coisa sobre a estabilidade relativa dos lançamentos. Estável é sempre sólido, e o teste é geralmente tão confiável. Quando há um lançamento iminente, o teste fica muito mais estável e instável fica um pouco estagnado. Depois de um lançamento, o teste se torna um pouco menos estável e instável torna-se novamente bugs.

    

Answer 3

Eu usei vários pacotes unstable / testing, mas não uso testing / unstable. Você pode usar coisas como Apt Pinning , backports , ou você mesmo pode retroceder os pacotes específicos necessários para o seu ambiente.

    

Answer 4

Eu já usei testes em servidores antes, mas esses backports atualmente removeram muitas das razões para isso.

    

Answer 5

stable + backports é o caminho a percorrer: até fazemos backports personalizados para pacotes selecionados, usando o mesmo tipo de esquema de versionamento que o backports.org

    

Answer 6

Backports podem causar problemas à medida que introduzem aplicativos que podem incompatibilizar bibliotecas, o que pode causar problemas mais tarde. Estável é muitas vezes desatualizado e, portanto, muitas vezes eu uso testes em máquinas internas (aquelas que não podem ser acessadas externamente).

    

Answer 7

Eu tive um problema com unstalbe uma vez e nunca mais o executarei na produção. O proftpd após o upgrade do apt-get ficou louco e era impossível de ser martelado. Ele sobreviveu a vários kill -9. Nós tentamos matá-lo e um dos meus colegas lembrou a si mesmo sobre killall5 - o mais poderoso comando kill no linux. Ele então invocou sem nenhum parâmetro para ver a ajuda "a sintaxe apropriada seria", mas a ajuda nunca veio ... A parte divertida é que tudo morreu, mas a porta do proftpd ainda estava aberta.

Você pode ter meio-estável meio instável se você configurá-lo bem, mas como já foi mencionado - os backports resolvem a maioria dos problemas muito bem. Caixas de produção não valem o risco. Geralmente funciona bem, mas às vezes você pode ter um azar.