Comment dois-je configurer Ubuntu / Upstart pour une configuration réseau inhabituelle?
J'ai récemment installé Ubuntu Utopic 14.04 LTS sur un nouveau serveur que j'ai spécialement construit pour héberger des machines virtuelles. La configuration réseau de cette boîte, qui contient deux cartes réseau, expose les deux cartes uniquement par le biais de ponts virtuels: l’un vers un réseau privé, l’autre vers l’Internet public. Un invité VM accédera aux deux ponts via des taps, servant de pare-feu et de passerelle pour l'hôte en particulier et le réseau privé en général. L'autre VM sera simplement un serveur invité distinct sur le réseau privé. L'hôte ne participera directement au réseau privé que via le pont privé correspondant.
En conséquence, ni eth0 ni eth1 ne seront uniquement "actifs" autres que le contexte de leurs ponts virtuels correspondants. Cependant, lorsque Ubuntu démarre, je pense que la sécurité intégrée de upstart suppose à tort (insister?) Qu’au moins eth0 soit activé indépendamment avant de permettre au système de dépasser les retards de 20/40/60 secondes imposés par la sécurité intégrée. Pourtant, les retards n'ont presque aucun espoir d'être résolus jusqu'à la fin du démarrage et les machines virtuelles invitées sont autorisées à démarrer sans entrave! Voir le paradoxe? Pour être honnête, je ne suis pas sûr que ni eth0 ni eth1 jamais atteindra l’état de sécurité, c’est exigeant.
À un niveau brut et réactionnaire, mon côté frustré et non-Ubuntu veut supprimer le système, car chaque redémarrage pour un changement de configuration me force à attendre jusqu'à deux minutes pour un changement d'état que je suis sûr à 99,9% n'arrive jamais par conception. En bout de ligne - pas de dépendance à sécurité intégrée. Je voudrais juste faire les cerceaux supplémentaires que je réalise que la sécurité intrinsèque est forcer tout simplement disparaître.
De même, j'essaie d'être au moins un peu ouvert d'esprit quant à ce que Upstart tente de faire avec la sécurité intégrée, car c'est ma première exposition à ce sujet. J'ai vu quelques informations (très vagues) selon lesquelles une approche consiste à changer la manière dont/etc/network/interfaces est configurée, en déplaçant les configurations de mon pont dans leurs propres tâches Upstart, mais je préférerais vraiment laisser mes définitions d'interface , heureux et travaillant.
Alors, quels sont mes choix? Puis-je simplement éliminer la tâche à sécurité intégrée ou la modifier pour en modifier les conditions? Si c'est le cas, comment? Dois-je pirater mon fichier d'interface?
Tout d'abord, permettez-moi de m'excuser d'avoir répondu à ma propre question.
Deuxièmement, j’ai en fait surmonté le problème du délai de démarrage de failafeafe.conf. Bien que je me rende compte qu'il n'y a pas eu de flot d'activité sur cette question, j'ai également vu suffisamment d'activités sur divers problèmes liés aux mêmes problèmes de délai de démarrage/sécurité que je publie mes recherches et solutions au profit des autres utilisateurs du même état.
Vue d'ensemble
Comme indiqué dans le post initial, le problème, tel que je l'ai constaté, réside dans le fait que la tâche amont intégrée à la sécurité intrinsèque imposait une contrainte indésirable au démarrage de mon système. J'ai ensuite étudié la question plus en profondeur, j'ai découvert pourquoi le système de sécurité intégrée se comportait tel qu'il était.
Analyse
Failafe.conf définit par défaut une condition de démarrage qui la déclenche effectivement au démarrage (dès que le système de fichiers et l'interface de bouclage sont disponibles), et définit l'une des deux conditions d'arrêt possibles:
start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit
L'insistance de Failsafe sur les retards est née du fait qu'aucun des deux camps ne s'est déclenché. La deuxième condition, rc-sysinit, est l’une des tâches d’initialisation finale du système, qui a sa propre condition de démarrage.
start on (filesystem and static-network-up) or failsafe-boot
Si la sécurité intrinsèque n'arrête pas , il est évident que rc-sysinit ne démarre pas . Failsafe émettra l'événement failafe-boot à l'expiration du délai imparti. . Étant donné que la sécurité intrinsèque a démarré, le terme "système de fichiers" est impliqué, laissant ainsi la seule condition restante commune aux deux événements étant "statique-réseau". Failsafe est en cours d'exécution car il ne pense pas que les interfaces réseau soient "actives".
La cause
En travaillant en arrière dans /etc/network/if-up.d, un script de démarrage est défini pour effectuer une itération de toutes les interfaces réseau définies dans/etc/network/interfaces définies avec un qualificatif "auto", ce qui signifie que cette interface doit être affichée. au moment du démarrage. La définition de la manière dont une interface est considérée comme "up" devient un problème sémantique important que je décrirai plus tard.
Si et seulement si toutes les interfaces configurées "automatiquement" sont "actives", le script de démarrage (upstart) émettra le célèbre événement "static-network-up". Cela permettrait, à son tour, à rc-sysinit de se déclencher et de mettre fin à la sécurité intrinsèque - d’où la cause fondamentale de mon problème. Aucune de mes interfaces réseau n'a d'adresse IP au démarrage - de par sa conception. Mais 'static-network-up' ne résiste pas à l'idée qu'une interface soit 'up' sans adresse IP, par conséquent, la sécurité intrinsèque est bloquée jusqu'à l'expiration du délai.
Dans ma situation, j'asservis les deux cartes réseau physiques de la boîte aux ponts et les expose via des prises à deux machines virtuelles différentes. Un VM sert DHCP via un robinet, l'autre est juste un serveur sur le même réseau. Pour que les ponts fonctionnent correctement, tels qu'ils sont exploités par les ordinateurs virtuels, les cartes d'interface réseau doivent au moins être "UP", laissant passivement les paquets passer. Par conséquent, "auto" semble approprié dans/etc/network/interfaces. Il était non cependant, aux yeux de la sécurité intégrée, par conséquent, la seule solution devait être celle qui respectait la sémantique de la sécurité intrinsèque.
La solution à mon problème était donc double:
- Supprimez la déclaration 'auto' de chaque interface réseau que j'avais définie (autre que le bouclage).
- Créez des travaux par défaut pour faire apparaître manuellement les interfaces "auto" antérieures. "
J'ai défini un travail pour quatre périphériques sur quatre - deux taps et deux ponts virtuels - en imitant une solution fournie ici .
Dans cette configuration, sans interface 'auto', le script de réseau doit maintenant immédiatement émettre 'static-network-up', forçant ainsi la sécurité à la fermeture. Une dernière modification m'a obligé à ajouter une clause "post-up" à la définition d'interface de chaque tap pour appeler "brctl" et créer le pont virtuel correspondant, effectué auparavant dans le cadre de la configuration "auto".
Ainsi, mon/etc/network/interfaces (en partie) ressemble maintenant à:
#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
Le test de l'acide
Le test acide? Redémarrez le serveur. Et lorsque je l'ai fait, , le délai d'expiration de la sécurité intrinsèque était écoulé et mon réseau est apparu dans une configuration fonctionnellement identique. ÇA MARCHE!! Je souhaite juste que nous ayons une meilleure compréhension de la sémantique d'une interface réseau "UP" !!