rc-Skripte, Reihenfolge

Tronar

Tronar

aus Überzeugung altmodisch
Hi, folks,
bei mir wird ein Netzwerk-Interface ng0 (NetGraph-basiert) durch ein Startup-Skript /usr/local/etc/rc.d/mpd5 erzeugt. Das Problem dabei ist, daß die Firewall /etc/rc.d/ipfw schon einige Zeit vorher hochfährt. Weil sie auch Regeln für ng0 enthält, das zu diesem Zeitpunkt noch nicht existiert, gibt es natürlich Ärger: Die Firewall wird unvollständig geladen.
Mein mpd5-Skript enthält folgende Zeilen:
Code: 
# PROVIDE: mpd
# REQUIRE: SERVERS
# BEFORE: DAEMON
# KEYWORD: shutdown
Eigentlich sollte es doch genügen, die BEFORE-Zeile abzuändern:
Code: 
# BEFORE: DAEMON ipfw
Das ändert aber nichts; er lädt ipfw immer noch zuerst. Was habe ich übersehen?
 
Keine Lösung aber evtl. ein schmutziger Workaround: Kannst du in deinem Startup-Skript (mpd5) nicht einfach ergänzen, dass ipfw reloaded wird?
 
Du scheinst da ein Henne-Ei-Problem zu haben:

% rcorder {,/usr/local}/etc/rc.d/* | egrep '(SERVERS|ipfw)'
/etc/rc.d/ipfw
/etc/rc.d/SERVERS
%

Du benötigst "SERVERS", willst aber vor "ipfw" drankommen. Das wird so nicht klappen.

Man könnte zwei Skripte daraus machen: eines, das zuerst den Netzwerkkram für mpd erledigt, und ein weiteres, das mpd dann startet.
 
worldi schrieb:
Du benötigst "SERVERS", willst aber vor "ipfw" drankommen.
Zum Vergrößern anklicken....
Wenn ich Dich richtig verstehe, ist "ipfw" einer von den "SERVERS". (Ich habe gerade kein FreeBSD-System hier; "SERVERS" ist doch so ein Sammelbegriff.) Okay, dann verstehe ich, was klemmt.
KobRheTilla, ich kann auf das REQUIRE wohl teilweise verzichten, denn mpd5 benötigt nur das einfache Ethernet-Interface, in meinem Fall xl0. Ich streiche morgen mal "SERVERS" und ersetze es durch eine genauere Auswahl.
Zur Not bleibt ja immer noch die Lösung von Columbo0815: service ipfw restart.

Danke an alle!
 
Columbo0815 schrieb:
Keine Lösung aber evtl. ein schmutziger Workaround: Kannst du in deinem Startup-Skript (mpd5) nicht einfach ergänzen, dass ipfw reloaded wird?
Zum Vergrößern anklicken....

ist nicht schmutzig, sondern funktioniert wunderbar, wenn ein mpd5 linkup script eingebunden wird.
In mpd.conf
set iface up-script /usr/local/etc/mpd5/mpd_linkup.sh

und in /wo/auch/immer/mpd_linkup.sh etwas, was ipfw(8) reaktiviert.

Dies sorgt dafür, dass bei Erscheinen von ng0 die Firewall und ihre Regeln neu geladen werden, diesmal dann auf das existierende interface.
MIt pf(4) geht das wunderbar.
Das bedeutet auch, daß für einen '*MOMENT*' keine firewall auf ng0 läuft, was aber für 9999 von 10000 in diesem Zusammenhang keine Bedrohung darstellen wird.
 
metro schrieb:
Dies sorgt dafür, dass bei Erscheinen von ng0 die Firewall und ihre Regeln neu geladen werden, diesmal dann auf das existierende interface.
MIt pf(4) geht das wunderbar.
Das bedeutet auch, daß für einen '*MOMENT*' keine firewall auf ng0 läuft, was aber für 9999 von 10000 in diesem Zusammenhang keine Bedrohung darstellen wird.
Zum Vergrößern anklicken....

Woher hast du das, dass eine Firewall "auf einem Interface" läuft und dass ein erscheinendes Interface erstmal komplett ignoriert wird, bis man die Regeln neulädt?
 
TCM schrieb:
Woher hast du das, dass eine Firewall "auf einem Interface" läuft und dass ein erscheinendes Interface erstmal komplett ignoriert wird, bis man die Regeln neulädt?
Zum Vergrößern anklicken....
A: Erfahrung, auch exakt bei Problem des OP, u.a. mit mpd5 (nicht musicplayer) Lösung s.o.
B: Wer lesen kann ... siehe OP. Sonst nochn' problemchen, oder schlecht geschlafen ?

Falls die technische Eloquenz in diesem Falle nicht ganz den Ansprüchen genügt, sorry.
 
Ist das bei ipfw wirklich so, dass neue Interfaces jeden Traffic durchlassen, oder ist es nicht eher so, dass alles blockiert wird bzw. die Default-Regel greift (die ja block sein sollte)? Beim OP bricht das Laden (wahrscheinlich) ab, weil das Interface nicht existiert. Das ist aber ein völlig anderes Problem und hat mit deiner Behauptung nichts zu tun.

Da du pf erwähntest: dort läuft Traffic auf Interfaces, für die keine Regel existiert, in die Default-Regel, weil pf nicht "auf Interfaces" separat läuft, sondern "global" den IP-Stack absichert. Es gibt dort keinen einzigen Moment, wo Traffic ungefiltert auf neu erscheinenden Interfaces durchgeht.

Also mal lieber an die Fakten halten als auf ne normale Frage den Pampigen raushängen zu lassen.
 
Sowohl ipfw2 als auch pf sind über pfil(9) in die Interrupt-Handler der Netzwerktreiber integriert, Pakete werden also grundsätzlich an den oder die Paketfilter gesendet, bevor sie in den eigentlichen Netzwerkstack hochgeladen werden. Entsprechend durchlaufen auch alle Pakete von vollwertigen Interfaces ipfw2. Allerdings gibt es durchaus Unterschiede zwischen ipfw2 und pf:
- ipfw2 ist in netgraph(4) integriert, pf nicht. Entsprechend behandelt ipfw2 aus Netgraph kommende Pakete "korrekt".
- Ein Großteil des Ruleset-Parsing wird bei ipfw2 im Userland gemacht, viele Parameter können daher gar nicht dynamisch sein.
- ipfw2 unterstützt zwar theoretisch dynamische Interfaces, praktisch ist es so lala. Gerade libalias hat so seine Probleme damit.
Oder anders gesagt, es ist definitiv eine sehr gute Idee, ipfw2 per flush abzuräumen und anschließend den Regelsatz neu zu laden, wenn sich etwas an der Netzwerkkonfiguration ändert. Und wie metro schrieb, der beste Ort dafür ist das Link-Up Script von mpd5. Damit bekommt man dann auch spätere Änderungen der externen IP-Adresse und ähnliche Spielchen zuverlässig mit.
 
So, ich hab' es jetzt doch über das rc-Skript gelöst. Mit "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" brachte ich zuerst die gegenwärtige Reihenfolge in Erfahrung, dann manipulierte ich die Angaben "REQUIRE" und "BEFORE" so, daß "mpd5" unmittelbar vor "ipfw" geladen wird. Nachdem ich noch mit "sleep 2" einen Delay ins Skript einbrachte, um dem Netzwerk-Interface etwas Zeit zu lassen ("ipfw" kam zu schnell hoch), scheint es nun zu funktionieren.
@Yamagi: Wie funktioniert denn IPFW mit dynamischen Interfaces? Finde ich das irgendwo in der länglichen Manpage?
 
Du kannst in aktuellen Versionen einfach Regeln auf nicht vorhandene Interfaces setzen. Sie greifen dann, wenn das Interface auftaucht:
Code: 
# ipfw add 10 deny tcp from any to any via test0
# ipfw show
00010  0  0 deny tcp from any to any via test0
65535 185 34367 deny ip from any to any
Aber wie gesagt, es geht nur so lala. Sobald NAT, Statefull Filtering und ähnliche nicht mehr so simple Dinge ins Spiel kommen, passieren seltsame Sachen. IP- und MAC-Adressen können auch nicht dynamisch übernommen werden. Daher würde ich immer ein Flush durchjagen und neu laden, sofern nichts dagegen spricht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben