Recientemente instalé Ubuntu Utopic 14.04 LTS en un nuevo servidor que construí específicamente para alojar algunas máquinas virtuales. La configuración de red para esta caja, que contiene dos NIC, expone las dos NIC sólo a través de puentes virtuales: uno a una red privada y otro a Internet pública. Una máquina virtual invitada accederá a ambos puentes a través de grifos, sirviendo como firewall y puerta de enlace para el host en particular y la red privada en general. La otra VM será simplemente un servidor invitado independiente en la red privada. El anfitrión sólo participará directamente en la red privada a través del puente privado correspondiente.
Como resultado, ni eth0 ni eth1 estarán "arriba" únicamente fuera del contexto de sus correspondientes puentes virtuales. Sin embargo, cuando se inicia Ubuntu, creo que el sistema de seguridad de upstart asume incorrectamente (¿insiste?) que al menos eth0 esté activo de forma independiente antes de permitir que el sistema supere los retrasos de 20/40/60 segundos que impone el sistema de seguridad. Sin embargo, los retrasos casi no tienen esperanzas de resolverse hasta que finalice el arranque y las máquinas virtuales invitadas puedan iniciarse sin restricciones. ¿Ves la paradoja? Para ser honesto, no estoy seguro de que eth0 ni eth1 lo hagan.alguna vezLlegar al estado de seguridad es exigente.
En un nivel crudo y reaccionario, mi lado frustrado, que no es Ubuntu, quiere eliminar el sistema de seguridad, porque cada reinicio para un cambio de configuración me obliga a esperar hasta dos minutos para un cambio de estado que estoy 99,9% seguro que sucederá. nunca sucederápor diseño. En pocas palabras: no hay dependencia a prueba de fallos. Simplemente me gustaría hacer que los obstáculos adicionales que me doy cuenta de que la seguridad obliga a desaparecer simplemente desaparezcan.
De la misma manera, estoy tratando de tener al menos un poco de mente abierta sobre lo que Upstart está tratando de hacer con el sistema de seguridad, ya que esta es mi primera exposición a él. He visto información (muy vaga) de que un enfoque para esto implica cambiar la forma en que /etc/network/interfaces está configurado, moviendo mis configuraciones de puente a sus propias tareas Upstart, pero realmente preferiría dejar las definiciones de mi interfaz en paz. , feliz y trabajando.
Entonces, ¿cuáles son mis opciones? ¿Puedo simplemente eliminar la tarea a prueba de fallos o modificarla para cambiar sus condiciones? ¿Si es así, cómo? ¿Debo piratear mi archivo de interfaces?
Respuesta1
Primero, permítanme disculparme por responder mi propia pregunta.
En segundo lugar, de hecho, he superado el problema del retraso en el inicio de failsafe.conf. Si bien me doy cuenta de que no ha habido un torrente de actividad sobre esta pregunta, he visto suficiente actividad en varios otros hilos sobre problemas similares de seguridad contra fallas/retraso de arranque que estoy publicando mi investigación y solución para el beneficio de otros en un aprieto similar.
Descripción general
Como se señaló en la publicación inicial, el problema, tal como lo vi, era que el trabajo inicial a prueba de fallas imponía una restricción no deseada en el arranque de mi sistema. Luego investigué más a fondo el problema y descubrí por qué el sistema de seguridad se comportaba como estaba.
Análisis
De forma predeterminada, failsafe.conf define una condición de inicio que lo activa efectivamente en el momento del arranque (tan pronto como el sistema de archivos y la interfaz loopback estén disponibles) y define una de dos posibles condiciones de parada:
start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit
La insistencia de Failsafe en los retrasos surgió en virtud de que ninguno de los eventos de "detención" se disparó. La segunda condición, rc-sysinit, es una de las tareas finales de inicialización del sistema que ejecuta el advenedizo, que tiene su propia condición de inicio.
start on (filesystem and static-network-up) or failsafe-boot
Con seguridad noparada, es evidente que rc-sysinit no lo esa partir de.Failsafe emitirá el evento de arranque a prueba de fallos una vez que expiren los tiempos de espera. Dado que se ha iniciado la seguridad contra fallas, se implica "sistema de archivos", por lo que la única condición restante común a ambos eventos es "red estática activa". Failsafe se está ejecutando porque no cree que ninguna interfaz de red esté "activa".
La causa
Trabajando hacia atrás a través de /etc/network/if-up.d, se define un script de inicio que itera a través de todas las interfaces de red definidas en /etc/network/interfaces definidas con un calificador "auto", lo que significa que se debe abrir esa interfaz. en el momento del arranque. La definición de cómo una interfaz se considera "activa" se convierte en una cuestión semántica importante que describiré más adelante.
Si y sólo si todas las interfaces configuradas "automáticamente" están "activas", el script advenedizo emitirá el famoso evento "red estática activa". Eso, a su vez, permitiría que rc-sysinit se active y finalice el modo de seguridad, de ahí la causa raíz de mi problema. Ninguna de mis interfaces de red tiene una dirección IP en el momento del arranque, por diseño. Pero "red estática activa" no respeta la idea de que una interfaz esté "activa"sinuna dirección IP, por lo tanto, la seguridad se bloquea hasta que expiran los tiempos de espera.
Para mi situación, conecto las dos NIC físicas de la caja a puentes y las expongo mediante grifos a dos máquinas virtuales diferentes. Una máquina virtual ofrece DHCP con un solo toque, la otra es solo un servidor en la misma red. Para que los puentes funcionen correctamente según lo aprovechan las VM, las NIC deben al menos estar "ARRIBA", permitiendo pasivamente el paso de los paquetes. Por lo tanto, 'auto' parecía apropiado en /etc/network/interfaces. Fuenoapropiado, sin embargo, a los ojos de la seguridad, por lo tanto, la única solución tenía que ser una que respetara la semántica de la seguridad.
La solución a mi problema, entonces, fue doble:
- Elimine la declaración 'automática' de cada interfaz de red que haya definido (aparte del loopback).
- Cree trabajos iniciales para abrir "manualmente" las interfaces que antes eran "automáticas".
Definí un trabajo, cuatro de cada uno de los cuatro dispositivos (dos grifos y dos puentes virtuales) imitando una solución proporcionada.aquí.
En esta configuración, sin interfaces 'automáticas', el script de red ahora debería emitir inmediatamente 'red estática-activa', lo que obligaría a finalizar la seguridad contra fallas. Una modificación final requirió que agregara una cláusula "post-up" a la definición de la interfaz de cada grifo para llamar a 'brctl' y crear el puente virtual correspondiente, lo que anteriormente se hacía como parte de la configuración 'automática'.
Entonces, mi /etc/network/interfaces (en parte) ahora se ve así:
#auto tpRED (commented out)
iface tpRED inet manual
pre-up /usr/sbin/tunctl -t tpRED
post-up /sbin/brctl addbr brRED
#auto brRED
iface brRED inet manual
bridge_ports eth1 tpRED
bridge_hw xx:yy:aa:bb:cc:dd
La prueba de fuego
¿La prueba de fuego? Reinicie el servidor. Y cuando lo hice,el tiempo de espera de seguridad se acabó, y mi red apareció en una configuración funcionalmente idéntica. ¡¡FUNCIONA!! ¡¡Solo desearía que tuviéramos un mejor manejo de la semántica de una interfaz de red "UP"!!