Considere un servidor sin cabeza como este: una caja x86 típica en una ubicación remota, que puede inicializar de forma remota con una imagen común de Ubuntu. Una vez inicializado, solo puede iniciar sesión a través de ssh, o restablecerlo de forma remota, es decir, no puede acceder al BIOS o al indicador del administrador de arranque (por ejemplo, Grub 1).
Quizás haya algún tipo de KVM disponible, pero el uso de KVM es muy caro y hay que reservarlo por horas.
Dado este escenario, uno puede volverse paranoico con los problemas de arranque. Por ejemplo:
- ¿Qué pasa si falla una actualización del kernel?
- ¿Qué pasa con un símbolo del sistema fsck en el proceso de arranque inicial? Probablemente, ssh aún no esté disponible …
¿Hay ¿Hay otras trampas a tener en cuenta?
Para las actualizaciones del kernel, configuro grub (el heredado) de modo que el menu.lst contenga
default saved fallback 2 # counts from 0 y la primera entrada termina con:
savedefault fallback La primera entrada de grub es el kernel actualizado, y la tercera es uno conocido que funciona. Consulte también la sección del manual de grub sobre el arranque alternativo .
Cambié el script de inicio /etc/rc.local (en un sistema similar a Debian) en el sentido de que la configuración de entrada predeterminada se restablece en caso de un arranque exitoso:
grub-set-default 0 Esta configuración de grub funciona, pero por ejemplo en Ubuntu esto no es el predeterminado y uno tiene que ajustar manualmente el menu.lst después de cada actualización del kernel.
Proporciono
panic=60 como parámetro del kernel, por ejemplo, en caso de un parámetro root= incorrecto o kernel roto, el sistema se reinicia automáticamente en caso de error.
Acerca del problema de fsck, no estoy seguro de cuál es la mejor camino es. En sistemas similares a Debian puede configurar
FSCKFIX=yes en /etc/default/rcS, que le dice a fsck que se repare automáticamente de forma predeterminada .
Pero si la reparación automática falla, ¿quizás todavía recibo un mensaje al que no puedo acceder de forma remota?
Alternativamente, podría deshabilitar la verificación de fsck mediante un cero en el sexto columna de /etc/fstab – en caso de un error de fs, entonces reinicializaría el sistema y restauraría las copias de seguridad, evitando así todos los problemas de fsck?
Comentarios
- Muy buena pregunta. Un servidor bare metal sin una consola remota o uno caro es un gran problema.
Respuesta
En serio, si su proveedor no ofrece asistencia manual gratuita (o al menos barata) para casos extremos, es hora de cambiar. De lo contrario, creo que está bastante bien con su configuración.
Cuando su sistema está tan dañado que fsck no puede arreglarlo, no hay mucho más que hacer, aparte de una reinstalación completa. De hecho, no he visto que esto suceda a menos que haya una falla fatal de hardware.
Una cosa a tener en cuenta. Para una máquina como esta, elija una distribución estable (Debian, RHEL, SLES) y definitivamente actualice solo después de un período suficientemente largo (la nueva versión se estabilizó durante al menos 6 meses).
Respuesta
Debería estar buscando un alojamiento proveedor que proporcionará acceso serial sobre ssh y configurará su instalación de Linux para usar el puerto serial (relevante) como la consola (cómo lo haga depende de si el sistema utiliza inicialización de tipo upstart o sysV). Tenga en cuenta que hay BIOS disponibles que se comunicarán con un puerto serie en lugar del dispositivo de pantalla integrado. Pero normalmente solo vienen con hardware costoso.
También debe decirle a grub que use el puerto serie si desea controlarlo a través de un DTE .
Responder
Algo que podría considerar es hacer un initrd personalizado que incluirá dropbear (que se ejecuta en otro puerto, por supuesto), suficiente lógica para poner en funcionamiento su red y tal vez una forma de cargar algunas herramientas de recuperación si es necesario. En base a esto, podría hacer una configuración del kernel de recuperación que se cargará con capacidad de red y le permitirá ingresar, lo que le permitirá volver al sistema e intentar una recuperación.
Comentarios
- Sí, suena como un gran proyecto. Incluso podría imaginar la creación de un pequeño sistema Linux que siempre se inicia primero y actúa como un administrador de inicio (mientras proporciona
ssh-access yscreen) – luego podría arrancar el núcleo real mediante técnicas como en.wikipedia.org/wiki/Kexec . O uno puede buscar servidores que vienen con coreboot.org en lugar de algunos BIOS de mierda de los años 80. Pero claro, todo esto no es nada que pueda configurar y mantener de manera confiable en unas pocas horas, en este momento con una distribución estable. - Parece que ' podrá escatimar algo del esfuerzo mirando esta página