He usado FreeBSD durante aproximadamente 5 años, servidor / escritorio, y tendí a llevar mi apt-get / yum a actualizar todos los hábitos junto con mí (también administro las cajas Debian / RHEL / Cent, lo sé, yo saber ... debería ser más exigente, independientemente de la plataforma). Por lo general, es un:

portsnap fetch
portsnap update
portmanager -u

Para los puertos

A veces seguido de un:

freebsd-update fetch
freebsd-update install

Para el sistema ... etc. Luego simplemente limpia cualquier desorden después ... si ocurre.

Esto, me doy cuenta, es una forma bastante excesiva de hacer cosas sin BSD. ¿Cuál es su filosofía para sus cajas BSD? ¿Ejecutas un portaudit / portversion - comprueba la salida y luego actualiza (realiza la desinstalación ... etc.) después de una cuidadosa consideración?

Soy bastante nuevo en OpenBSD, lo confieso. Me veo cargando el árbol de puertos, ejecutando el script "desactualizado", luego actualizando los puertos críticos, pero dejando solo el núcleo / binarios y actualizando cada seis meses. ¿Parcheas / recompilas / reconstruyes kernel, binarios --- por qué?

¿Qué es un enfoque conservador para los servicios críticos (razonablemente crítico, esto no es un banco ni un hospital) en cajas BSD? ¿Está utilizando un enfoque similar en sus cajas de Linux? Generalmente no toco el kernel en ningún servidor a menos que una alerta de seguridad haya aterrorizado mi alma.

Sí, hay muchos documentos y libros, ¿qué hacen ustedes realmente? Asumiendo que sabemos lo básico, ¿cuál es la sabiduría? Los casos de uso / entornos y escenarios varían, al igual que las apuestas / partes interesadas / usuarios. Los libros y las páginas de manual cubren herramientas y usos, pero carecen de aplicación práctica. ¡Recomiende un libro si conoce uno que lo cubra!

¡Gracias por leer!

Bubnoff

Conclusiones ~ Gracias a todos los que se tomaron el tiempo para responder esta publicación. Mi estrategia general ahora es seguir las listas de correo para ambos BSD y ser más selectivo / exigente con las actualizaciones de lo que he sido en el pasado.

FreeBSD ~ Portaudit es una buena respuesta. Con las listas de correo y las auditorías diligentes, creo que esto servirá bien aquí. Es interesante el énfasis diferente en los puertos entre OpenBSD y FreeBSD.

OpenBSD ~ seguirá la lista de correo y utilizará las herramientas del paquete (pkg_info y pkg_add -u) cuando se considere crítico. Actualizaciones: Parece que necesita actualizar al menos una vez al año. Admiten la versión más reciente y una posterior, por lo que ahora son 4.8 y 4.7.

Gracias de nuevo.

Asegúrese de revisar los puertos instalados en busca de paquetes vulnerables cada cierto tiempo: portaudit -Fda

No estoy seguro de que haya una "forma BSD" específica para hacer este tipo de cosas. Todo se reduce a saber qué se está actualizando y probando: cosas genéricas de administrador de sistemas. Afortunadamente, freebsd-update y portsnap hacen que el "saber qué" sea bastante trivial.

Pero, dado que usted solicitó detalles, cuando acumulé una gran cantidad de máquinas FreeBSD, todos eran nodos en un clúster. Las máquinas independientes no serían tan diferentes de esto, pero supongo que podría hacer que esto sea vagamente 'devops' para sus servicios de producción. Al final, siempre es una buena idea tener entornos de prueba y producción separados.

En la situación del clúster:

• Cada máquina montó / usr / src , / usr / obj y / usr / ports a través de NFS.
• Dependiendo de su presupuesto, puede tener una máquina de preparación / compilación o designar un nodo de clúster como nodo de preparación / compilación.
• El nodo de preparación tenía una copia diferente de / usr / ports
• El nodo de preparación actualizaría src-all y ports-all a través de cvsup todas las noches
• En caso de una actualización necesaria, el nodo de preparación se eliminaría de la rotación y se ejecutarían buildworld , installworld y portupgrade .
• El nodo de ensayo se probaría a fondo.
• / usr / ports se intercambiarían en el host NFS
• Cada nodo del clúster se rotará, ejecute installworld y portupgrade , se probará y luego se rotará nuevamente.

Obviamente, esto fue en el caso de un sistema y una actualización de puertos, pero el procedimiento fue lo suficientemente similar como para actualizar solo paquetes o sistema.

Si esto se hace con dos máquinas, puede hacer que cada uno tome turnos como producción o preparación, o simplemente actualice la producción desde la preparación.

Puede realizar un seguimiento de los cambios desde los registros de cvs y verificar si ha recibido actualizaciones específicas en / usr / src / UPDATING y / usr / ports / UPDATING , que se actualizan automáticamente desde cvsup .

Si no usa cvsup (y en estos días hay menos razones para hacerlo), solo tendrá que encontrar otra forma de rastrear qué actualizaciones desea. Puede enviar por correo una lista de los cambios que freebsd-update desea hacerse y vigilar la página de erratas de seguridad.

Filosofía de actualización de OpenBSD

Este es mi enfoque para actualizar OpenBSD

Manténgase actualizado sobre lanzamientos / parches de seguridad para:

• BASE (es decir, las cosas que el equipo de desarrollo de OpenBSD mantiene en su árbol fuente)
• Paquetes / Puertos (es decir, aplicaciones de software instaladas sobre BASE)

Procedimientos de actualización:

• Misma versión del sistema operativo
• Nueva versión del sistema operativo

BASE

a. Siga las listas de correo relevantes : veo los resúmenes diarios de squish.net, así como la dirección general que se muestra en las listas de correo Tech y Misc.

si. Siga los sitios web / listas de correo de anuncios de seguridad relacionados con Unix.

C. Mantener una copia CVS local del uso de cvsync

re. Cree versiones ESTABLES de lo anterior

Cuando se publican actualizaciones de seguridad, evaluamos el problema de seguridad real con el perfil de las máquinas con esa versión del sistema operativo / vulnerabilidad. Si la vulnerabilidad es relevante, pasamos por el "mismo procedimiento de actualización de versión".

Paquetes / Puertos

Es más difícil hacer un seguimiento de las actualizaciones de seguridad para puertos / paquetes, pero si es lo suficientemente crítico como para estar en nuestra infraestructura, entonces es lo suficientemente importante como para mantener un seguimiento de manera similar a BASE.

• Ingrese a la lista de correo para la aplicación específica (es nuestra responsabilidad mantener pestañas de los cambios ascendentes, independientemente del proyecto OpenBSD).

• Entrar en las listas de distribución de seguridad se sienta como CERT que publica hallazgos de vulnerabilidades en aplicaciones, etc.

Los procedimientos de actualización

Obviamente, compile y pruebe su procedimiento de instalación en hardware separado (o VM) antes de hacerlo en sus máquinas de producción. Afortunadamente para nosotros, tenemos hosts redundantes para muchas cosas y, por lo tanto, podemos implementar con un tiempo de inactividad mínimo de los servicios. Debido a que OpenBSD admite una amplia gama de hardware, podemos implementar equipos de nivel de servidor para nuestras máquinas principales y equipos de escritorio de gama baja como nuestros hosts redundantes (o simplemente construimos un cuadro temporal para llenar la máquina principal durante el ciclo de actualización).

Nuestros procedimientos de actualización dependen en gran medida del uso del sistema de puertos / paquetes para software que no sea BASE. Los dos hosts donde instalamos el software desde la fuente son difíciles de actualizar entre las actualizaciones de versión del sistema operativo.

La misma actualización del sistema operativo

Para el SO BASE, continuamos teniendo éxito con solo instalar los nuevos binarios sobre los antiguos. Preferiblemente, hacemos una copia de seguridad de todos los archivos de configuración / datos del SO y de la aplicación, formateamos y reinstalamos el SO parcheado y reinstalamos los paquetes (conservando los datos originales)

En nuestros hosts OpenBSD implementados (más de 30) y experiencia, hacer copias de seguridad de la configuración y los datos no es difícil. Para nuestros firewalls, todos los datos están en la configuración y en los archivos de registro.

Para puertos / paquetes: donde los cambios son simples, modificamos nuestro propio puerto y construimos el paquete a partir de eso. Tener un puerto actualizado simplifica el proceso anterior.

Nueva actualización del sistema operativo

Entre las versiones del sistema operativo, instalamos todo, desde el boceto.

Estoy seguro de que hay suficiente documentación para el proceso, pero esencialmente construimos una máquina de referencia con la misma configuración que el sistema para ser "reemplazado". Realice las mismas pruebas necesarias antes de implementar el host.

Hacemos una copia de seguridad de la configuración desde el host de referencia e instalamos OpenBSD en el host de producción, restaurando la configuración "verificada" encima (ejecutando nuevamente las mismas pruebas de validación después).

Para OpenBSD, al menos:

• los paquetes son el producto final del sistema de puertos; debería haber poco, si es necesario, correr con puertos.
• -release and -stable está (en su mayoría) congelado en el tiempo, con algunas actualizaciones de vez en cuando.
• -corriente se actualiza regularmente. Si realmente necesita paquetes actualizados, este es el camino a seguir.
• permanecen consistentes: -release / -stable systems se adhieren a -release / -stable paquetes ...- los sistemas actuales se ejecutan -paquetes actuales

Faq 15, todo sobre puertos y paquetes

Si no hay un problema de seguridad o un error que obstruya la funcionalidad, déjelo en paz. Verifique las actualizaciones tal vez cada 3-6 meses para no retrasarse demasiado, pero de lo contrario deje las cosas en paz.

Si no está roto, no lo arregles.

Prefiero usar portupgradepara actualizar puertos, y hago esto solo cuando es absolutamente necesario , por ejemplo, cuando se encuentra una vulnerabilidad en el puerto o se requiere una nueva funcionalidad.

En cuanto a la actualización del sistema, generalmente reconstruyo desde las fuentes con make buildworld. Nunca tuve ningún problema con este enfoque.