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.

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

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.

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).

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

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.

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.