OpenBSD, FreeBSD: sua filosofia de atualização?


14

Eu uso o FreeBSD há cerca de 5 anos - servidor / Desktop - e tenho a tendência de levar todos os meus hábitos apt-get / yum (eu administro as caixas Debian / RHEL / Cent também - eu sei, eu sabe ... deve ser mais exigente, independentemente da plataforma). Portanto, geralmente é um:

portsnap fetch
portsnap update
portmanager -u

Para os portos

Às vezes seguido por um:

freebsd-update fetch
freebsd-update install

Para o sistema ... etc. Depois limpe todas as bagunças depois ... se elas ocorrerem.

Percebo que essa é uma maneira não-BSD bastante excessiva de fazer as coisas. Qual é a sua filosofia para suas caixas BSD? Você executa uma portaudit / portversion - verifique a saída e atualize (faça a desinstalação ... etc) após uma cuidadosa consideração?

Eu sou bastante novo no OpenBSD, confesso. Eu me vejo fazendo o backup da árvore de portas, executando o script "desatualizado" e atualizando as portas críticas - mas deixando o kernel / binários em paz e atualizando a cada seis meses. Você corrige / recompila / reconstrói o kernel, binários - por quê?

O que é uma abordagem conservadora para serviços críticos (razoavelmente crítico - isso não é um banco ou hospital) nas caixas do BSD? Você está usando uma abordagem semelhante em suas caixas Linux? Geralmente, eu não toco o kernel em nenhum servidor, a menos que um alerta de segurança tenha causado terror em minha alma.

Sim, existem muitos documentos e livros - o que vocês realmente fazem? Supondo que sabemos o básico - qual é a sabedoria? Os casos de uso / ambientes e cenários variam, assim como as estacas / partes interessadas / usuários. Livros e páginas de manual cobrem ferramentas e usos, mas não têm aplicação prática. Recomende um livro se você souber de um que o cubra!

Obrigado pela leitura!

Bubnoff

Conclusões ~ Obrigado a todos que dedicaram um tempo para responder a esta postagem. Minha estratégia geral agora é seguir as listas de discussão para ambos os BSDs e ser mais seletiva / exigente em relação à atualização do que no passado.

FreeBSD ~ Portaudit é uma boa resposta. Com as listas de discussão e auditorias diligentes, acho que isso servirá bem aqui. É interessante a ênfase diferente nas portas entre o OpenBSD e o FreeBSD.

O OpenBSD ~ Seguirá a lista de discussão e usará as ferramentas de pacote (pkg_info e pkg_add -u) onde for considerado crítico. Atualizações: parece que você precisa atualizar pelo menos uma vez por ano. Eles suportam a versão mais recente e uma traseira - então, agora é 4.8 e 4.7.

Obrigado novamente.

Respostas:


9

Verifique suas portas instaladas em busca de pacotes vulneráveis ​​de vez em quando: portaudit -Fda


1
Este é um item obrigatório para * BSD. Eu recomendo jogar isso em um crontab noturno para lhe enviar um email todas as manhãs com portas com correções de segurança.
Andrew M.

1
Mas é uma questão de agir de acordo com o conselho da Portaudit. Ao ler as respostas aqui, a maioria das pessoas recomenda deixar as coisas em paz, a menos que seja absolutamente necessário. Eu ouvi alguns administradores alegando que tudo deve estar atualizado constantemente ... isso me parece uma boa maneira de quebrar as coisas.
Bubnoff

Vou seguir este conselho para o FreeBSD. Obrigado. O que deixa o OpenBSD
Bubnoff

4

Não tenho certeza de que exista uma "maneira BSD" específica para fazer esse tipo de coisa. Tudo se resume a saber o que está sendo atualizado e testado - coisas genéricas do administrador de sistemas. Felizmente, o freebsd-update e o portsnap tornam o "saber o quê" bastante trivial.

Mas, desde que você solicitou detalhes, quando eu agrupei um grande número de máquinas FreeBSD, eles eram todos nós em um cluster. Máquinas independentes não seriam tão diferentes disso, mas acho que você poderia fazer isso vagamente como 'devops' para seus serviços de produção. No final, é sempre uma boa idéia ter ambientes de teste e produção separados.

Na situação do cluster:

  • Cada máquina montou / usr / src , / usr / obj e / usr / ports via NFS.
  • Dependendo do seu orçamento, você pode ter uma máquina de temporariedade / construção ou designar um nó de cluster como o nó de temporariedade / construção.
  • O nó temporário tinha uma cópia diferente de / usr / ports
  • O nó de teste atualizaria src-all e ports-all via cvsup todas as noites
  • No caso de uma atualização necessária, o nó temporário será retirado da rotação e o buildworld , installworld e portupgrade serão executados.
  • O nó temporário seria testado completamente.
  • / usr / ports seriam trocados no host NFS
  • Cada nó do cluster seria girado para fora, execute installworld e portupgrade , testado e depois girado de volta para dentro.

Obviamente, isso ocorreu no caso de uma atualização de sistema e de portas, mas o procedimento foi semelhante o suficiente para atualizar apenas pacotes ou sistema.

Se isso for feito com duas máquinas, é possível que cada uma reveze como produção ou preparação, ou apenas atualize a produção.

Você pode acompanhar as alterações nos logs do cvs e verificar se você recebeu atualizações específicas em / usr / src / UPDATING e / usr / ports / UPDATING , ambas atualizadas automaticamente no cvsup .

Se você não usa o cvsup (e hoje em dia há menos motivos para isso), precisará encontrar outra maneira de rastrear as atualizações desejadas. Você pode enviar uma lista de alterações que o freebsd-update deseja fazer para si mesmo e ficar de olho na página de erratas de segurança.


Eu gosto da idéia de 'encenar' versos 'produção'. Com a virtualização, quase não há desculpa para não hoje em dia. Obrigado pela resposta.
quer

Sim, além disso, ele se encaixa muito bem nas coisas do tipo 'devops' (pelo que entendi), se você tiver que lidar com isso.
DF

4

Filosofia de atualização do OpenBSD

Esta é minha abordagem para atualizar o OpenBSD

Mantenha-se atualizado sobre os lançamentos / patches de segurança para:

  • BASE (ou seja, o material que a equipe de desenvolvedores do OpenBSD mantém em sua árvore de fontes)
  • Pacotes / portas (ou seja, aplicativos de software instalados na parte superior do BASE)

Procedimentos de atualização:

  • Mesma Versão do SO
  • Nova versão do sistema operacional

BASE

uma. Siga as listas de discussão relevantes - eu assisto os resumos diários do squish.net, bem como a direção geral mostrada nas listas de discussão Tech e Misc.

b. Siga sites de anúncios de segurança / listas de correspondência relacionados ao Unix.

c. Manter uma cópia local do CVS usando o cvsync

d. Crie versões STABLE a partir dos itens acima

Quando as atualizações de segurança são publicadas, avaliamos o problema de segurança real com o perfil de máquinas com essa versão do SO / vulnerabilidade. Se a vulnerabilidade for relevante, passamos pelo "procedimento de atualização da mesma versão".

Pacotes / Portas

É mais difícil acompanhar as atualizações de segurança para portas / pacotes, mas se é crítico o suficiente para estar em nossa infraestrutura, é importante o suficiente para acompanhar de maneira semelhante à BASE.

  • Entre na lista de discussão para a aplicação específica (é nossa responsabilidade manter o controle das alterações upstream, independentemente do projeto OpenBSD.)

  • Entre nas listas de distribuição de segurança, como o CERT, que publica descobertas de vulnerabilidades em aplicativos etc.

Os procedimentos de atualização

Obviamente, crie e teste seu procedimento de instalação em hardware separado (ou VM) antes de fazê-lo em suas máquinas de produção. Felizmente para nós, temos hosts redundantes para muitas coisas e, portanto, podemos implementar com um tempo de inatividade mínimo dos serviços. Como o OpenBSD suporta uma ampla gama de hardware, podemos implantar equipamentos de nível servidor para nossas máquinas principais e desktops inferiores como nossos hosts redundantes (ou apenas construímos uma caixa temporária para preencher a máquina principal durante o ciclo de atualização).

Nossos procedimentos de atualização dependem muito do uso do sistema de portas / pacotes para software não-BASE. Os dois hosts em que instalamos o software da fonte são difíceis de atualizar entre as atualizações de versão do sistema operacional.

Atualização do mesmo sistema operacional

Para o sistema operacional BASE, continuamos tendo sucesso com a instalação dos novos binários sobre os antigos. De preferência, fazemos backup de todos os arquivos de configuração / dados do SO e do aplicativo, formatamos e reinstalamos o SO corrigido e reinstalamos os pacotes (mantendo os dados originais)

Em nossos hosts OpenBSD implantados (mais de 30) e experiência, não é difícil fazer backup da configuração e dos dados. Para nossos firewalls, todos os dados estão nos arquivos de configuração e log.

Para portas / pacotes - onde as alterações são simples, modificamos nossa própria porta e construímos o pacote a partir disso. Ter uma porta atualizada simplifica o processo acima.

Nova atualização do sistema operacional

Entre as versões do sistema operacional, instalamos tudo, desde o sketch.

Tenho certeza de que existe documentação suficiente disponível para o processo, mas essencialmente construímos uma máquina de referência com a mesma configuração do sistema a ser "substituída". Passe pelos mesmos testes necessários antes de implantar o host.

Fazemos backup da configuração do host de referência e instalamos o OpenBSD no host de produção, restaurando a configuração "verificada" em cima dela (novamente executando os mesmos testes de validação posteriormente).


Obrigado! Essa é a direção que estou indo. Siga as listas, use hosts redundantes.
quer

3

Para o OpenBSD, pelo menos:

  • pacotes são o produto final do sistema de portas; deve haver pouco, se houver, necessidade de correr com portas.
  • -release e -stable é (na maior parte) congelado no tempo, com algumas atualizações de tempos em tempos.
  • -current é atualizado regularmente. Se você realmente precisa de pacotes atualizados, este é o caminho a percorrer.
  • permaneçam consistentes: -release / -stable systems mantêm-se com -release / -stable packages ...- current systems run -current packages

FAQ 15, tudo sobre portas e pacotes


Sim, parece que os desenvolvedores / mantenedores do OpenBSD incentivam o uso de pacotes pelas portas, pois as portas produzem o pacote antes de instalar de qualquer maneira. Mas a árvore do ports possui um script de auditoria (./out_of_date) ... qual é o análogo para pacotes? Um portaudit para o OpenBSD ... ou você apenas segue a lista de discussão e atualiza o (s) pacote (s) manualmente?
quer

Pessoalmente, com -current é "pkg_add -u -Dupdate, updatedepends" ~ mensalmente para mim. Eu admito que nunca usei completamente as portas assim; geralmente são apenas CVS; torna a atualização limpa para mim, se eu precisar fazer isso. Fiquei com a impressão de que esses outros scripts são para carregadores, mas, novamente, raramente usei o sistema de portas. Quanto à auditoria, tudo isso é feito pela equipe de portos e, é claro, por qualquer pessoa que contribua.
lonerman

@Bubnoff Se você atualizar para as versões mais recentes no -stable, terá todos os patches de segurança lançados para esse lançamento. (Diferentemente de -current, que também inclui atualizações que não são de segurança).
precisa saber é o seguinte

@Hugo - obrigado! Este é um bom ponto. Vou ter que escrever isso na documentação do meu servidor.
Bubnoff

2

Se não houver nenhum problema de segurança ou bug que atrapalhe a funcionalidade, deixe-o em paz. Verifique se há atualizações a cada 3-6 meses para não ficar muito para trás, mas deixe as coisas em paz.

Se não estiver quebrado, não conserte.


4
3-6 meses? E o Apache / lighttp ou qualquer outro aplicativo web CMS de fachada, etc? Você não se preocupa com isso? Caso contrário ... Entendo o seu ponto.
Bubnoff

@Bubnoff O OpenBSD vem com um httpd personalizado, derivado do Apache 1.x. A maioria das atualizações fornecidas pelo Apache nem se aplicam.
Benoit

Eu entendi aquilo. Mas o OpenBSD fornece atualizações para a corrente que mais tarde se tornam estáveis. E isso ainda deixa os pacotes em si ... Os aplicativos que usam o Apache possivelmente exigiriam atualizações. Ou você apenas atualiza a coisa toda a cada seis meses?
quer

Esta é a minha abordagem. Eu raramente instalo algo fora das portas nos meus sistemas de produção, então tudo o que realmente preciso é a instalação básica e os pacotes. Eu sigo as erratas ( openbsd.org/errata.html ) e a lista de discussão relevante para todos os pacotes que instalei. Se eu instalei outra coisa na parte superior, como um sistema CMS, rastreio e mantenho isso separadamente. Se eu precisar corrigir algo crítico, construo meu patch em um sistema de teste e depois o copio.

1

Prefiro usar portupgradepara atualizar portas e fazer isso somente quando absolutamente necessário , por exemplo, quando uma vulnerabilidade for encontrada na porta ou for necessária uma nova funcionalidade.

Quanto à atualização do sistema, eu costumo reconstruir a partir de fontes com make buildworld. Eu nunca tive problemas com essa abordagem.


1
Muitos parecem preferir portupgrade ao portmanager. Portupgrade é o mais maduro dos dois? Parece que o portmanager ainda não atingiu 1,0.
quer

1
Sim, o portupgrade existe há muito tempo e parece ter o desenvolvimento e suporte mais ativos. Sei que existem outras ferramentas de gerenciamento de portas, mas o portupgrade é o mencionado de maneira mais consistente nas listas. Há uma discussão entre os dois em '04 - lists.freebsd.org/pipermail/freebsd-questions/2004-December/… - que encontrei, mas não tenho certeza de quão atual é.
DF

Eu uso essa mesma abordagem e é principalmente devido ao uso do FreeBSD desde os dias 4.x em que buildworld e portupgrade eram as melhores / únicas opções. Eles ainda funcionam muito bem hoje, se você tiver tempo para executá-los e tempo para aprender o processo. Além disso, eu sempre construo com -Osotimizações, sistemas menores / mais rápidos.
Chris S
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.