Estratégia de atualização para alguns pacotes do CentOS

Question

Somos um projeto de código aberto / gratuito. Alugamos uma VM CentOS 7 x86_64 para um site e wiki. Mantemos a VM totalmente corrigida. Uma vez por semana, fazemos login e executamos yum update para garantir que temos o equipamento mais recente.

Alguns pacotes estão começando a nos causar problemas conforme a distribuição. Por exemplo, a versão do PHP é 5.4, que foi Fim de vida em 2015 :

$ php --version
PHP 5.4.16 (cli) (built: Nov 15 2017 16:33:54)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
    with XCache v3.1.1, Copyright (c) 2005-2014, by mOo
    with XCache Optimizer v3.1.1, Copyright (c) 2005-2014, by mOo
    with XCache Cacher v3.1.1, Copyright (c) 2005-2014, by mOo
    with XCache Coverager v3.1.1, Copyright (c) 2005-2014, by mOo

O PHP de nível inferior significa que nosso software correspondente do MediaWiki não é mais mantido. Estamos presos no MediaWiki 1,26.

De acordo com a mais alta versão do PHP suportada no CentOS 7 , uma das possibilidades é permitir um terceiro repo festa. Estou bem com a ativação de repos adicionais; mas eu não gosto de ativar um estrangeiro.

De acordo com a FAQ do CentOS , o CentOS é a plataforma de desenvolvimento da comunidade para a Red Hat. construído a partir de fontes da Red Hat. Eu duvido seriamente que o RHEL esteja apenas fornecendo software abandonado para seus clientes.

De acordo com o wiki do CentOS em Recursos Adicionais | Repositórios existe um repositório CentOS-Plus que pode ser ativado. Eu verifiquei o repo e não há nenhum PHP atualizado disponível.

Minha primeira pergunta é, por que o CentOS não fornece um PHP atualizado?

Minha segunda pergunta é: sempre precisamos confiar < alguma fonte aleatória > ao usar o CentOS?

A minha terceira pergunta é: existe uma estratégia viável para administradores de sistema de meio período que evite a repo de terceiros?

A questão (1) é o problema da instância no nosso caso. Eu suponho que outros tiveram o mesmo problema com outro software CentOS.

A pergunta (2) é para planejamento a longo prazo. Se o CentOS sempre causar esse problema com o tempo, precisaremos avaliar se devemos procurar outra distro.

A questão (3) está principalmente relacionada com (a) software atualizado e (b) fontes e repositórios confiáveis. Estamos bem com o esforço de configuração extra, mas gostaríamos de minimizá-lo. Nós realmente queremos evitar fontes não confiáveis.

Na foto maior eu meio que sinto que há algo [óbvio] que estou perdendo. Mas eu não sei o que é isso no momento.

Obrigado antecipadamente.

    

Answer 1

My first question is, why does CentOS not provide an updated PHP?

Esta é uma decisão da Red Hat. Isso é mais do que provável por causa de algo que eles fornecem que depende de uma versão antiga - mas não consigo encontrar evidências disso.

Se você precisa de um PHP mais atualizado, você tem muitos recursos, como IUS ou até mesmo o SCL que o CentOS fornece. IUS não irá substituir os pacotes existentes, mas eles vão exigir que você remova o que está lá primeiro, php sábio. Eu uso o IUS para o python 2.7 para o CentOS 6 para poder instalar o sal corretamente.

Nota: Red Hat é quem decide quais pacotes e quais versões entram em sua distribuição, do ponto de vista da estabilidade. O CentOS apenas pega as fontes e as reconstrói no CentOS.

Do we always need to trust some random source when using CentOS?

Não necessariamente. Há muitas recompensas boas e ruins por aí. Na verdade, algumas pessoas podem facilmente viver apenas nos repositórios de base.

Isso realmente depende das suas necessidades. Vá para esta página aqui para ver quais repositórios são aprovados pela comunidade. Esteja certo de que qualquer repo listado nessa página é aprovado e pode ser confiável .

is there a workable strategy for part-time system admins that avoids third party repos?

A melhor estratégia depende do caso de uso de um usuário ou empresa. Para o seu caso de uso específico, você precisará de repositórios de terceiros. Você realmente não tem escolha, especialmente se não conseguir que o MediaWiki vá para uma versão superior. Como observado na resposta anterior, algumas pessoas podem viver apenas com os repositórios de base. Algumas pessoas simplesmente chegam a usar o EPEL. Novamente, isso depende do seu caso de uso e do que você está executando ou mantendo. Tenha certeza, que qualquer coisa que saia do EPEL ou do IUS (por exemplo) é tipicamente tão mantida, estável e segura quanto o que sai da base da distribuição.

Eu ainda recomendo ir em aqui para repositórios aprovados pela comunidade.

    

Answer 2

Some packages are starting to give us trouble as the distro ages. For example, PHP version is 5.4, which went End-of-Life in 2015

Sim, mas os patches de segurança são backported . A única razão real para atualizar para uma versão mais nova do PHP é para os recursos de idioma ou se um aplicativo precisar, mas você perderá patches de segurança (ou outros específicos de distração) dessa maneira.

We are a free/open source project. We rent a CentOS 7 x86_64 VM for a website and wiki. We keep the VM fully patched.

Isso é realmente necessário? A solução barata seria hospedar um site usando as Páginas do Github e usar o Github para o wiki ou usar um gerador de página da web estático como o Sphinx. Se você quiser ir um passo além, você pode usar o Cloudflare e apontá-lo para o seu site de páginas do GH. Veja as respostas para Solução de hospedagem resistente a hackers para organizações sem fins lucrativos para obter informações adicionais sobre isso.

Vantagens:

• Completamente grátis

• Linguagem mais simples (texto markdown / reestruturado) em vez da sintaxe do MediaWiki

• Manutenção mais simples, já que você não precisa lidar com nenhum material do lado do servidor

• Menor barreira de entrada, já que esta é uma solução já usada por muitos projetos de código aberto, por exemplo, readthedocs.org e navegue pelo Github por muitos exemplos

• Não executar tecnologias do lado do servidor reduz drasticamente a superfície de ataque. Os invasores precisariam explorar as páginas do Github e o Cloudflare oferece muita proteção, enquanto você precisaria fazer todo o trabalho duro para proteger sua VM se você fizesse um bricolage