Há algum motivo para NÃO executar um servidor Ubuntu?


12

Em breve, montarei uma rede para um pequeno escritório. A rede consistirá em cerca de 5 estações de trabalho (em breve haverá mais) e 2-3 servidores (um servidor "real" e duas estações de trabalho que se tornaram servidores para aliviar a carga da máquina principal).

Eu tenho perguntado por aí para ver quais servidores Linux as distros preferem, e parece que todo mundo está inclinado a usar as distribuições tradicionais de servidores semelhantes ao RedHat. Toda vez que eu menciono a execução de um servidor Ubuntu, todo mundo diz que eu deveria executar o Red Hat, mas ainda tenho que ouvir alguns motivos para não executar os servidores Ubuntu.

Estou mais familiarizado com o uso de servidores Ubuntu / Debian. Existem razões significativas para executar outra distribuição de servidor que supere estar familiarizado com um sistema operacional?


Para que você poderia precisar de três servidores em um escritório pequeno com cinco estações de trabalho?
JJ01

8
Existem muitas razões para usar tantos servidores. Nem todos precisam estar lá para apoiar as estações de trabalho.
21720 David Pashley

1
Absolutamente! Eu tenho algo em torno de 75 servidores e 15 usuários e quase 30 TB de dados. É incrível como muitas infraestruturas não são padrão #
Matt Simmons

Respostas:


31

Não há motivo real para não fazê-lo, desde que você não esteja usando nenhum software que não seja suportado no Ubuntu Server.

Executamos o CentOS porque ele tem compatibilidade binária com o RedHat Enterprise, para o qual muitos softwares comerciais lançam pacotes. Isso facilita minha vida e é realmente muito estável (não que o Ubuntu não seja).

Se você conhece o Ubuntu, vá com o Ubuntu.


13

Eu deveria começar dizendo que estou envolvido na comunidade Debian desde 2002, então isso é claramente tendencioso.

Usamos o Ubuntu exclusivamente em nossos servidores. Usamos o Dapper ou Hardy, principalmente pelos 6 anos de suporte de segurança que obtemos no sistema operacional base. Descobrimos que o ano de suporte de segurança do Debian para versões antigas não foi suficiente para reconstruir todos os nossos servidores. A confiabilidade dos lançamentos é uma coisa agradável de se ter.

Não encontramos uma diferença significativa entre a execução do Debian e do Ubuntu. Eu tenho 8 ou 9 anos de experiência na criação de pacotes Debian, então estou confortável em reconstruir pacotes Debian para Ubuntu nos raros casos em que algo está no Debian, mas não no Ubuntu. Em alguns casos, você pode até instalar os pacotes binários diretamente.

Eu sempre me assustei com as distribuições baseadas em RPM, simplesmente porque há uma divergência entre distribuições que os pacotes de um não funcionam em outro na maioria dos casos. O Debian possui um guia de políticas abrangente, que descreve como os pacotes devem interagir. Esta é possivelmente a maior força do Debian. Redhat e amigos também tendem a não ter a grande variedade de pacotes que o Debian possui. É muito raro encontrar algo que eu queira que não esteja disponível no apt. Yum não é comparável ao apt-get.


2
O Yum (com seus plugins e ferramentas associadas, como repoquery) é uma substituição muito melhor do que eu esperava quando comecei a usá-lo. Eu concordo que a seleção de pacotes seja escassa, mas o fedoraproject.org/wiki/EPEL ajuda muito.
sciurus

9

Eu usaria o RedHat se alguma das seguintes situações fosse verdadeira:

  • Você possui um software suportado apenas no RedHat
  • Você precisa rodar em arquiteturas que o Ubuntu não suporta, só consigo pensar em mainframes da IBM
  • Você precisa de confiabilidade 24 horas por dia, 7 dias por semana e os custos de suporte que a acompanham. Eu sei que você pode comprar suporte para o servidor Ubuntu, mas se eu estivesse disposto a pagar milhares por contratos de suporte, iria com o RedHat devido à reputação estabelecida no mercado de servidores.

7

Software comercial e de código fechado (como agentes de backup) tradicionalmente têm mais suporte no Red Hat (Enterprise).

Se você não tem nenhuma necessidade específica de executar esse tipo de software, eu recomendo o debian ou o ubuntu para você, se você é novo no linux.


6

As questões reais são:

  • Os pacotes que você vai instalar são suportados pela Canonical?

Isso tem mais a ver com evitar quebras do que com obter suporte técnico. Pacotes "oficiais" tendem a ser melhor avaliados e, como resultado, não quebram (com a mesma frequência) ao atualizar para uma versão mais recente.

  • Você está planejando usar uma versão LTS do Ubuntu?

O suporte a longo prazo também aumenta o fator "estabilidade", pois a Canonical tem um grande interesse em tornar as versões LTS o mais estáveis ​​possível.

Por exemplo, recentemente tentei instalar o cliente e servidor OpenERP, versão 5. Acontece que o instalador está completamente quebrado e, enquanto o pacote é instalado, ele se recusa a iniciar o servidor. Observe que isso está no 9.04 e os pacotes não são "oficialmente suportados". Portanto, sua milhagem pode variar.

Caso contrário, deve ser bom usar o servidor Ubuntu.

Claro, se você está procurando mais estabilidade e uso a longo prazo, você considerou o Debian em vez do Ubuntu ?

Se você está apenas procurando algo com suporte comercial, o RedHat pode ser mais do seu agrado. Use o CentOS se tiver pouco dinheiro, mas ainda desejar a "compatibilidade com RPM" que ela traz ao tentar instalar aplicativos de terceiros.


5

Os derivados RedHat tendem a ser muito mais bem suportados pelos fornecedores de software e hardware.


4

Eu diria que a familiaridade seria o principal recurso na escolha do sistema operacional para o servidor que você planeja administrar. A menos que você esteja planejando usar o servidor para algo muito específico que o RH faz melhor que o Ubuntu, não faz muito sentido aprender uma nova distribuição e correr o risco de cometer erros no processo.


3

Vá com o que você está familiarizado, afinal é você quem está configurando o servidor. Como outros disseram, a menos que você esteja planejando executar software de código fechado no Linux, você deve seguir o Red Hat.


Eu acho que deveria ser "Se você está planejando ..."
Liam

2

Posso perguntar então por que o Ubuntu, mas não o Debian? Se este é um servidor, você não precisa de todo o material sofisticado da área de trabalho que o Ubuntu fornece. Qual seria o benefício adicional de usar o Ubuntu?

O Debian IMHO é muito mais fácil de entender e manter do que o Ubuntu.

Além disso, o CentOS / RH ou o OpenSuse (ou SLES) têm muito mais suporte de fornecedores comerciais de software de terceiros, portanto, se você for usar esse software, use-o melhor.

E no RHEL / SLES, nada supera o YaST da Suse para gerenciamento de serviços - fácil para configurações básicas de DNS e Apache, etc.


7
RE: Coisas sofisticadas da área de trabalho O Ubuntu Server é um sistema operacional básico e não possui ambiente de área de trabalho nem mesmo o X instalado. É mais uma instalação mínima do que a instalação RH ou Suse padrão.
3dinfluence

1
O Debian é ainda mais Barato que o Ubuntu para instalação de servidores.
Zan Lynx

E o debian-minimal / ubuntu-minimal é ainda menor. O melhor ponto aqui são as correções de segurança suportadas por tempo suficiente para atualizar o sistema operacional.
jldugger

Ao contrário Debian, Ubuntu tem um ciclo de vida previsível - o lançamento apoio a longo prazo é bastante adequado para a maioria das lojas - assim você pode planejar para atualizações do site ...
Lester Cheung

2

Quando quis construir meu primeiro computador, perguntei a alguns amigos sobre hardware. Todo mundo me disse para ir Intel. "Fique longe da AMD", disseram eles. "Por quê?" Eu perguntei.

Eu nunca recebi uma resposta. Quase sempre se resumia a um fato simples: eles estavam acostumados à Intel e não queriam tentar algo novo, se não precisassem.

Eu suspeito que o que você está encontrando com sistemas operacionais de servidor é a mesma coisa.


FWIW, os primeiros chips da AMD eram mais propensos a falhar durante eventos de superaquecimento, do que os Intels. Essa reputação só foi agravada quando a Intel começou a dificultar ativamente o overclocking, o que significava que todos os responsáveis ​​pela entrega de envelopes acabavam executando chips da AMD e, portanto, tinham desproporcionalmente mais falhas relacionadas à temperatura.
David Mackintosh

Ok, então houve uma razão para isso. É bom saber, obrigado.
Nilamo 19/06/09


2

Utilizamos alguns servidores Ubuntu por vários anos (desde a versão 6.10 (Edgy Eft)) em uma rede predominantemente Windows, atualmente 9.04 (Jaunty Jackalope) com Likewise / Samba para integração com o AD e NTLMAPS aptpara atualizar corretamente através do ISA proxy.

Era fácil de configurar, fácil (cron-apt e apenas repositórios de segurança habilitados) para se manter atualizado e realmente "simplesmente funciona". Se você gosta do Ubuntu, não consigo encontrar razões para usar outra coisa, a menos que haja um aplicativo ou recurso obrigatório em outra distribuição de servidor que você ache atraente.


1

Não é realmente baseado no que você forneceu. O Ubuntu Server é fácil de configurar e manter, a comunidade é muito grande e as versões LTS são suportadas por um bom tempo.

Pessoalmente, acho o gerenciamento de pacotes muito superior no mundo Debian / apt do que no mundo RedHat / rpm ... mas isso pode ser apenas eu.

De qualquer forma, onde pode valer a pena usar uma das grandes distribuições suportadas como RedHat é o suporte de hardware. Você pode comprar um servidor com RedHat ou Suse pré-instalado, por exemplo, e funcionará ... incluindo todas as ferramentas de gerenciamento. Se você usa o Ubuntu Server, pode ter que se esforçar um pouco para executá-lo, e pode ser necessário reembalar manualmente ou encontrar um pacote de terceiros para qualquer ferramenta de gerenciamento de hardware. Por exemplo, eu tenho o Ubuntu Server rodando em uma máquina Dell PowerEdge e tive que pegar um pacote de terceiros para o OMSA da Dell (que ajuda a configurar e gerenciar o hardware da Dell). Demorou um pouco para se configurar, mas está funcionando bem desde então.


1

Mais um fator a ser lembrado é que o SELinux é relativamente bem suportado no Fedora / Red Hat como padrão.


0

Do meu ponto de vista, dê uma olhada em / etc / passwd yes. Na boa tradição WTF, parece que o Ubuntu decidiu conceder a todos os usuários do sistema shell de LOGIN. Então é possível pegar usuários como game ou avahi, ou klog etc etc etc.


0

O bom do Ubuntu Server é o suporte da comunidade ... parece que mais pessoas conhecem o Ubuntu do que outros sabores e geralmente estão dispostas a ajudar se você tiver problemas.


0

Você precisa do Oracle? Você está preocupado que a certificação seja a única maneira de saber quem está qualificado para administrar seus servidores?

Porque esses são os principais recursos que o Red Hat Enterprise Linux (RHEL) traz para a mesa. Foi uma grande notícia quando a Oracle anunciou o Unbreakable Linux, porque é um ataque direto à lucratividade do RHAT.

Se você é capaz de usar o PostgreSQL e pode entrevistar os administradores do sistema por conta própria / administrá-lo, não há muito o que olhar. A Red Hat Network (RHN) é interessante, mas não é necessária, e a Canonical oferece um serviço semelhante chamado Paisagem. Especialmente no seu inventário atual, o RHN é completamente inútil.


-1

Eu diria que no seu cenário, o Ubuntu ficaria bem. Em cenários maiores em que você está gerenciando / implantando muitas caixas, acho que o redhat tem melhores ferramentas para ajudá-lo.


-1

O Ubuntu é bom na maioria dos casos. Se você estiver usando um pacote particularmente estranho ou em uma arquitetura ímpar, vale a pena examinar o quão bem ele é suportado por eles. Costumávamos executar o Dapper em uma máquina Sun_4v e descobríamos que as vunerabilidades costumavam levar grandes quantidades de tempo para serem corrigidas, e os bugs importantes em áreas como o NSS nem sempre eram corrigidos. No entanto, isso não foi um problema no ia32 / amd64


-1

Em relação ao Debian versus Ubuntu: Eu pessoalmente estou usando o Debian stable em todos os servidores. Existem várias razões, mas há as mais significativas:

  • O Ubuntu obtém a maioria dos pacotes do Debian de qualquer maneira
  • A principal vantagem do Ubuntu é sua excelente pré-configuração nas estações de trabalho (eu o rodo em um laptop aqui onde o Debian é uma porcaria) - ele não tem essas vantagens na instalação do servidor
  • O Ubuntu tem uma atualização estável a cada meio ano. Pessoalmente, eu me afogaria no trabalho se tivesse que atualizar todos os servidores duas vezes por ano. Isso é apenas impraticável. Dois anos são suficientes hoje em dia.
  • O Ubuntu apresenta algumas peculiaridades que são muito mais fáceis no Debian (tente "dpkg-reconfigure locales" no Ubuntu)
  • O conhecimento técnico geral dos usuários do Ubuntu parece ser pior do que no Debian. O número de respostas erradas ou não qualificadas "eu também" em fóruns e listas de discussão é muito alto.

Outras distribuições são facilmente uma dor no ... erro ... lombar para mim. Exemplos:

  • SUSE: O YAST mata configurações manuais com facilidade e é mais difícil de personalizar. É uma abordagem "leve como está" que eu não gosto.
  • Redhat: Seus instaladores de pacotes "yum" ou "up2date" não podem competir com o sistema APT do Debian / Ubuntu.
  • Gentoo: Além da necessidade de compilar a maioria dos pacotes que levam a uma instalação mais lenta, você não terá um sistema exatamente como o outro. Para implantar aplicativos em um servidor, isso pode se tornar rapidamente um problema. Talvez não muito para estações de trabalho atualizadas.

Nos servidores, espero uma grande variedade de pacotes comuns. Um bom sistema de gerenciamento de pacotes / software. Uma grande base de usuários. Um sistema que atualiza normalmente. Eu tentei o Debian há 8 anos e nunca olhei para trás.

A única razão para não usar o Debian para mim é se você possui um software que não é suportado pelo fornecedor no Debian e precisa desesperadamente de suporte. Quase nunca acontece comigo.

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.