Respuestas:
Puede ser seguro o, más exactamente, el nivel de riesgo puede estar dentro de su rango de comodidad. El nivel de riesgo aceptable dependerá de varios factores.
¿Tiene un buen sistema de respaldo que le permitirá revertir rápidamente si algo se rompe?
¿Está reenviando los registros del servidor a un sistema remoto para que si la caja se desploma todavía sabrá lo que sucedió?
¿Está dispuesto a aceptar la posibilidad de que algo se rompa y deba hacer una restauración / restauración rápida en el sistema si algo falla?
¿Has compilado manualmente algo por tu cuenta, o absolutamente todo lo instalado en tu sistema proviene de los repositorios oficiales? Si instaló algo localmente, existe la posibilidad de que un cambio ascendente pueda romper su software local mantenido / instalado.
¿Cuál es el papel de este sistema? Es algo que apenas se perdería si muriera (por ejemplo, un servidor DNS secundario) o es la pieza central de su infraestructura (por ejemplo, el servidor LDAP o el servidor de archivos primario).
¿Desea configurar esto porque nadie responsable del servidor tiene tiempo para mantener los parches de seguridad? El riesgo potencial de verse comprometido por una vulnerabilidad sin parchear puede ser mayor que el potencial de una mala actualización.
Si realmente crees que quieres hacer esto, te sugiero que uses una de las herramientas que ya están disponibles para este propósito cron-apt. Tienen cierta lógica para estar más seguros que solo un ciego apt-get -y update.
apt-get upgrade, no apt-get update, ¿verdad?
apt-get update, es bastante difícil romper algo.
Generalmente es seguro, pero no lo recomendaría por una simple razón:
En el entorno de producción, debe saber exactamente qué contiene, o qué se supone que debe contener, y poder reproducir ese estado con facilidad.
Cualquier cambio debe hacerse a través del proceso de Gestión del Cambio, donde la empresa es plenamente consciente de lo que se está metiendo, para que luego puedan analizar lo que salió mal, etc.
Las actualizaciones nocturnas hacen que este tipo de análisis sea imposible o más difícil de hacer.
Podría hacerlo en estable, o en Ubuntu, pero no en una rama inestable, o incluso en la rama de prueba.
Sin embargo, cuando me pongo el sombrero de administrador del sistema, creo que debería aplicar manualmente todas las actualizaciones, para poder mantener la coherencia entre los servidores, y también para que, si algún día se rompe un servicio, sé cuándo actualicé por última vez Servicio. Eso es algo que quizás no verifique si las actualizaciones se realizan automáticamente.
Utilizamos la actualización estable y programada de apt-get para el martes por la noche en la mayoría de nuestros sistemas Debian (coincide con nuestras actualizaciones de Microsoft "parche martes"). Funciona bien También tenemos todos los eventos de actualización registrados en Nagios, por lo que podemos ver un historial de cuándo se realizaron las actualizaciones por última vez en cualquier servidor.
Cuando especifica que este es un servidor de "producción", ¿eso significa que también hay servidores de desarrollo y de prueba? Si es así, los parches deben probarse en esos sistemas antes de instalarse en la caja de producción.
Yo no lo haría Hay parches malos y no quisiera que un sistema fallara en medio de la noche o mientras no estuviera disponible. Deben insertarse en una ventana de mantenimiento cuando un administrador está disponible para monitorear la actualización.
Recuerdo haber hecho eso en un trabajo anterior; Terminé con problemas en el servidor de producción porque una actualización reescribió un archivo de configuración automáticamente.
Por lo tanto, le aconsejaría que supervise las actualizaciones.
Si la alternativa es la aplicación irregular de actualizaciones, no sigue activamente las actualizaciones de seguridad, y está ejecutando un Lenny estable, entonces la actualización automática probablemente aumente la seguridad de su máquina, ya que actualizará los agujeros de seguridad conocidos más rápido.
Ubuntu Server tiene un paquete que le permitirá actualizar automáticamente las actualizaciones de seguridad. También le permite poner en la lista negra ciertas aplicaciones. También habla sobre apticron que le enviará un correo electrónico cuando haya actualizaciones disponibles para su servidor.
Puede obtener más información al respecto en las siguientes páginas, según la versión de Ubuntu Server que esté ejecutando.
EDITAR: suponiendo que esté ejecutando Ubuntu. Aunque apostaría a que los mismos paquetes y soluciones están disponibles en Debian.
Esto depende de su infraestructura. Si tengo una sola máquina, generalmente reviso las actualizaciones y veo qué necesito o qué puedo evitar. Si estoy usando un clúster, a veces despliego los cambios en una máquina, veo cómo funcionan y luego lo despliego a las otras máquinas si todo parece estar bien.
Actualizaciones de la base de datos que siempre vigilo de cerca.
Si tiene un sistema de archivos que admite instantáneas, puede ser realmente útil para tomar una instantánea del sistema, aplicar actualizaciones y luego tener la opción de revertir los cambios si algo sale terriblemente mal.
¿Intenta averiguar por qué se está actualizando un paquete? ¿Es corrección de errores? arreglo de seguridad? ¿Es un comando local o un servicio de red remoto? ¿Se ha probado el software con las nuevas actualizaciones?
Las actualizaciones del kernel deben abordarse con más precaución. ¿Intenta descubrir por qué se está actualizando el kernel? ¿Realmente necesitas esos cambios? afectará su solicitud? ¿Necesito aplicar esto por seguridad?
9 de cada 10 actualizaciones de software se realizarán sin problemas, pero es en esas raras ocasiones que deja su máquina como un montón de basura, tiene un plan de recuperación o recuperación del sistema.
apt-get upgrade -ylugar deupdate? ¿Hay alguna-ybandera paraupdate?