[NEU] schnelles iptables / ip6tables interface für die 7270 (v.0.8.3a) + 7390 etc...

[alpha1974]

"sehr viel später" ist etwas übertrieben. rc.mod startet unmittelbar nach debug.cfg. Durch rc.mod werden -abhängig vom Startlevel- sofort die Freetz-Dienste gestartet. Wenn debug.cfg leer ist und Dein rc.nhipt einen niedrigen Startlevel hat, macht es keinen nennenswerten Unterschied, ob die rules über debug.cfg oder rc.nhipt start gesetzt werden. Allenfalls könnten sich andere "frühe" Freetz-Dienste dazwischen mogeln, was man ja über die Startlevels fest verdrahten kann.
Warum muss iptables eigentlich unbedingt so früh die Rules setzen? Ein gewisses Grundvertrauen in die Freetz-Dienste und Funktionen, die evtl. gleichzeitig oder früher starten, wird man schon haben dürfen / müssen. Und die zeitliche Verzögerung, bis iptables die Box abdichtet, beträgt selbst im ungünstigen Fall nur wenige Sekunden.

 

[Silent-Tears]

Einige Sekunden sind wohl vollkommen zu vernachlässigen ehrlich gesagt. Und merh wird es nicht werden, wie alpha schon geschriebe hat.

 

[cando]

EDIT:

Igrendwie hab ich es nun hinbekommen, dass das richtige im Image landet, trotzdem wird die Firewall aus der rc.nhipt nicht gestartet. Da war die debug.cfg zuverlässiger. Irgendwo ist noch ein Denkfehler.

________________________________________

 

[hermann72pb]

Einige Sekunden sind wohl vollkommen zu vernachlässigen ehrlich gesagt. Und merh wird es nicht werden...

Doch, doch, doch. Ich funke zwar dazwischen und leicht OT, aber ich will nur eindeuten, dass es nicht immer in ein Paar Sekunden durch ist. Momentan braucht meine 7170 in etwa 5 bis 7 Minuten, bis die FREETZ-Dienste überhaupt starten. Ich konnte mir die Gründe bis jetzt nicht erklären, aber das ist reproduzierbar und FREETZ-Version-unabhängig. Das Ding bleibt irgendwo in Tiefen von rc.S aus unerklärlichen Gründen so lange stecken.
Außerdem haben hier einige ganz mutige bereits Festplatten-Checks beim Hochlauf und diverse andere Dinge. Deswegen würde ich es nicht unbedingt so pauschal sagen.
Ich würde eher vorschlagen, dass wir uns das komplette Startlevel-Konzept überdenken und vielleicht an die Linux-Standards mit S- und K- Nummern "hochziehen". Außerdem bin ich dafür, dass wir auch die AVM-Dienste mitbetrachten und nicht außer Acht lassen. Daraus wird sich schon etwas Vernünftiges konstruiren lassen. Hier wird es aber OT. Lass uns zurück zum Thema kommen.

MfG

 

[cando]

Neuer Patch Fuer Den Trunk

Hallo Leute,

Anbei ein neuer "clean" Patch für den Trunk.

Ich hoffe, es gefällt Euch besser.

Geändert habe ich folgendes:

• freetz UI erweitert um Urlader Auswahl (freetz Service oder debug.cfg)
• Bugfix Server Root / Server Port ließen sich nicht mehr einstellen

Anbei der Patch

 

[alpha1974]

Anbei ein neuer "clean" Patch für den Trunk.

Ich hab den Code gerade mal überflogen. Wo / durch was wird eigentlich "rc.nhipt start" mal aufgerufen? Beim Booten wird von Freetz aus (via rc.mod) nur "rc.nhipt" aufgerufen, so dass nur die (""|load)-Sektion abgearbeitet wird. Wenn auch die Start-Sektion immer und ausnahmslos beim Booten abgearbeitet werden soll, muss ein "start" ans Ende des load-Abschnittes.

 

[cando]

Das Booten passiert einmalig beim Load, start ist dafür nicht nötig - sondern hinderlich, da hier nur die (nicht vorhandenen) Maskeninhalte verarbeitet werden.

Zu dem Zeitpunkt ist die iptables Infrastruktur noch nicht / nicht vollständig geladen (Timer, Warten auf USB Stick etc.) und das Skript würde Default Einstellungen setzen, da es einen "noch nicht installiert" Zustand vorfindet.

stop und start werden von Freetz jedes mal aufgerufen, wenn man über die Freetz Masken-Änderungen speichert (Freetz macht immer ein restart). Wäre schädlich für's Booten.

Ich erkläre mal die Bootlogik:

Da das Programm ja sowohl im Freetz, als auch dynamisch Freetz über USB Stick, als auch Stand-Alone funktionieren kann, und entweder von der debug.cfg oder vom Freetz Service hochgezogen wird, und die iptables Regeln und Settings entweder im Flash der Box oder extern abgelegt werden können - ist der Bootprozess etwas tricky.

Normalerweise braucht man einen Festen Punkt, der "Bescheid" weiss, wie das Ganze laufen soll - das war bisher die debug.cfg.


Das booten läuft so ab:

1. debug.cfg kann die Einstellungen in die RAM-Disk kopieren und die Initialisierung starten.
   
2. rc.nhipt load wird von rc.mod / run level 40 aufgerufen und prüft, ob die Settings bereits in der RAM Disk sind (durch vorherigen boot mit debug.cfg). Sind sie es nicht, wird /tmp/flash/nhiptboot.cfg aufgerufen (die an Stelle der debug.cfg die Initialisierung übernimmt)
   
3. debug.cfg und nhiptboot.cfg sind inhaltlich identisch aufgebaut
   • sie warten bei Bedarf auf USB Stick
   • kopieren von bekannter Stelle (flash / USB) die Settings nhipt.par in die RAM Disk
   • kopieren Start Script nhipt.cfg in die RAM Disk
   • starten Firewall Start Script nhipt.cfg und schicken es in den Hintergrund.
4. nhipt.cfg:
   • dsld (wenn eingestellt) stoppen
   • Verzögeriungstimer (wenn eingestellt) abwarten
   • dsld (wenn eingestellt) starten
   • Web-Server für UI starten,
   • Interner Log Service (wenn eingestellt) starten,
   • Firewall Rules laden

Szenario 1: Standalone CGI - bootet immer von debug.cfg, Regeln im flash / stick

Szenario 2 : dynamisches freetz - bootet entweder von der debug.cfg oder verspätet über freetz rc.custom beim Integrieren der cgi in freetz (install script für freetz Integration trägt sich in die rc.custom automatisch ein für reboot Fähigkeit)

Szenario 3: Manuelle Integration in Freetz - Bootet über Patch der rc.mod entweder von debug.cfg oder über freetz service start

Szenario 4: Trunk Patch - Integration in die Runlevel von Freetz, debug.cfg auf Wunsch siehe oben.

 

[alpha1974]

Ganz schön kompliziert, weil derzeit so viele Szenarien abgedeckt werden sollen.

Scenarion 4: Trunk Patch - Integration in die Runlevel von Freetz, siehe oben.

Ich fände eine Konzentration/Beschränkung auf diese Variante am besten (ist ja hier auch das Freetz-Forum ;-)). Dann kann der Support für Debug.cfg komplett entfallen und auch auch rc.custom braucht nicht mehr beachtet zu werden, weil alles über rc.nhipt und das die dazugehörigen cfgs und cgis gemanaged werden kann. Die USB-Stick-Variante würde sich bei einer Integration in Freetz darauf beschränken, dass nur die Rules/Config auf dem USB-Stick gespeichert ist und beim Booten auf ihr Vorhandensein geprüft wird. Alles andere scheint mir jedenfalls für ein Freetz-Paket ein wenig "überfeatured" zu sein. Aber bitte nicht falsch verstehen: Ich finde das Paket derzeit schon klasse und für die Zielgruppe der erfahrenen User vollkommen ausreichend (zumal man im SoHo-Bereich sowieso nicht jeden Tag die Firewall ändert, wenn einmal alles vernünftig eingerichtet ist) . Es ist halt eine Design-Entscheidung, ob für die Integration in Freetz als statisches Paket noch Stand-Alone- und sonstige Szenarien bedient werden müssen.

 

[alpha1974]

Habe Deinen Patch jetzt mal mutig auf den Trunk losgelassen und ohne Änderungen ausprobiert:

/ # ls -la /etc/init.d/rc.nhipt 
-rw-r--r--    1 root     root         2607 Nov 15 14:33 /etc/init.d/rc.nhipt
/ # /etc/init.d/rc.nhipt 
-sh: /etc/init.d/rc.nhipt: Permission denied

Zum Glück läuft das mir unter usbroot, da ist das schnell ohne Flashen gefixt

Hmm, nachdem ich nun rc.nhipt auf x gesetzt habe, erscheint NHIPT zwar in der Freetz-Gui unter Pakete, aber es kommt

Fehler: Kein Skript für das Paket 'nhipt'.

Außerdem passiert Folgendes

/ # /etc/init.d/rc.nhipt start
/etc/init.d/rc.nhipt: line 104: /mod/etc/default.nhipt/nhipt.cfg: Permission denied
configuring nhipt gui.../var/media/ftp/uStor01/xxx
/etc/init.d/rc.nhipt: .: line 104: can't open /var/media/ftp/uStor01/xxx/cgi-bin/nhipt.cgi
/ #

 

[cando]

Für 7270 Besitzer mit wenig Paketen ist das optimal, allerdings gibt es ja auch Leute, die sehr geizen müssen mit ihrem Speicher.

Die dynamische Integration ist für diese wieder optimal, da (bis auf ein paar Bytes in debug.cfg und rc.custom) und die benötigten iptables Module nichts auf der Box belegt wird.

Für die ernsthaft Schutzsuchenden ist die debug.cfg Lösung die Beste, es ist der früheste Zeitpunkt, um die Box dicht zu machen - der Einwand von hermann72pb in Bezug auf Bootzeit und Speicher-Reparieren vor Freetz Start ist sehr ernst zu nehmen.

Für Gelegenheits-Admins, die gar kein Freetz-GUI für die Firewall brauchen ist das nackte Script auf einem Admin - Stick optimal.

Das Tolle ist ja, dass es immer der gleiche Code ist, man muss nicht 4 Lösungen pflegen.

Zusätzlich sind überall alle hier diskutierten - Anti-Aussperrmechanismen integriert.

Szenario 3 sehe ich als Übergang, bis das Paket im Trunk ist, bis auf dem Patch der rc.mod wegen fehlendem Runlevel beim Rüberkopieren sind sie identisch.

Die Version kann man wahrscheinlich weglassen und mit dem Patch für den trunk, der nun verfügbar ist, ersetzen. Ich weiß aber nicht, ob der Patch gegen Stable & den anderen Versionen einsetzbar ist. Mit der brutalen Rüberbügelmethode könnte man auch diese freetz Versionen beglücken.

:silly:

 

[cando]

Das mit den Rechten ist sehr merkwürdig. Die Sourcen, bei denen ich den svn diff gemacht habe, haben die richtigen Rechte. Muss da noch was in die Config-Dateien eingetragen werden, damit beim Make alles richtig läuft?

Ich kann die Version, so wie sie ist direkt compilieren und lauffähig flashen. Scheinbar ist beim diff irgend was "optimierungsbedurftig"

Ich vermute mal, dass alle Execute Rechte fehlen.

Du kannst in /var/tmp/nhipt.par die Verzeichnisse auch händisch eintragen, eigentlich sollten die Default Werte Passen, zumindest um das GUI aufzurufen und sie zu setzen.

Das Problem ist aber, dass freetz die Module nur initialisiert, wenn die Rechte gesetzt sind und die Dateien vorhanden, und das nur einmalig. Dann werden die symlinks in der RAM Disk für rc.module, modul.cfg, modul.cgi gesetzt und das modul geladen. Fehlen die rechte bei der Initialisierung, geht alles in die Hose. Man kann es aber händisch nachziehen.
Am besten wäre es, wenn Du die Rechte im Build-System überprüfst und ein neues image machst. Dann sollte es gleich gehen.

BACK=/var/media/ftp/uStor01/save
CHANGED=0
DELAY=0
LOGTARGET=internal
DSLDOFF=0
ADMINIP=
LOGD=/var/media/ftp/uStor01/log
AIRBAG=0
MYIP=
BOOTSTRAP=freetz
PORT=82
BOOT=flash
BOOTDIR=/tmp/flash
ROOT=/usr/ipt

 

[hermann72pb]

Das Problem mit den Rechten und svn diff ist ein generelles Problem. Die Rechte müssen nach dem patchen manuell gesetzt werden. Genau so läuft es auch im trunk, wenn eure Patches da eingecheckt werden. Deswegen lohnt es sich neben den Patches noch 2-3 Sätze in Prosa dazu zu schreiben, welche Dateien, wo und welche Rechte brauchen.
Wenn alles einmal im trunk ist, oder auf dem Buildsystem, kann es weiterhin normal aktualisiert werden. Das ist nur das erstmalige Problem.

MfG

 

[Silent-Tears]

Da hat herman Recht. Diese patch/diff können mit Rechten nicht umgehen. Das machen wir immer manuell, bis es im Trunk ist.

 

[alpha1974]

Klar. Mit den manuell gefixten Rechten läuft es schon ganz ordentlich.
Im Flash/Freetz-Only-Modus mault die GUI -zu Recht- darüber, dass das Backup-Directory read-only ist:

sh: can't create /usr/ipt/2009-11-15-15-51-52-nhipt.cfg: Read-only file system

Am besten wäre, wenn man überhaupt kein Backup-Directory angeben könnte und das cgi dann auch nicht versucht, Backups anzulegen.
Im Freetz "NHIPT interface" liest man u.a. Folgendes:

BOOT PROCEDURE SETTINGS syslog

?

 

[Silent-Tears]

Man könnte die Backups optional machen und das Verzeichnis änderbar...

 

[cando]

OK, ich mach's mal einfach:

Die Rechte:

/root/etc/default.nhipt/nhipt.cfg       [B]rwxrwxrwx[/B]
/root/etc/init.d/rc.nhipt               [B]r-xr-xr-x[/B]
/root/usr/ipt/index.html                [B]r--r--r--[/B]
/root/usr/ipt/cgi-bin/nhipt.cgi         [B]r-xr-xr-x[/B]
/root/lib/cgi-bin/nhipt.cgi             [B]r-xr-xr-x[/B]

Die /root/etc/default.nhipt/nhipt.cfg könnte man wie folgt vorbelegen (hatte ich mir nie Gedanken darüber gemacht, da sie ja nur beim allerersten Start relevant ist, sonst zieht die gespeicherte Config.

export NHIPT_BACK='/var/media/ftp/uStor01/backup'
export NHIPT_LOGD='/var/media/ftp/uStor01/log'
export NHIPT_PORT='83'
export NHIPT_ROOT='/usr/ipt'
export NHIPT_SERVERIP=''
export NHIPT_ADMINIP=''
export NHIPT_LOGTARGET='syslog'
export NHIPT_START_LOG=''
export NHIPT_START_CGI=''
export NHIPT_BOOT='flash'
export NHIPT_DELAY=''
export NHIPT_DSLDOFF=''
export NHIPT_BOOTDIR='/tmp/flash'
export NHIPT_BOOTSTRAP='freetz'

Wenn keine Verzeichnisse eingetragen sind, versucht das cgi das Root Verzeichnis für Backup und Log herzunehmen, was im ROM natürlich keinen Sinn macht. Wenn Parameter fehlen (beim aller ersten Start), werden die Parameter vom CGI "erraten":

- Die Script - Root Directory wird default Verzeichnis für alle fehlenden Verzeichnisse
- Das Server Port wird aus der aktuellen Laufzeitumgebung ermittelt
- Die Server IP wird aus der aktuellen Laufzeitumgebung ermittelt
- Boot default ist flash
- Bootstrap default ist die debug.cfg
- Logtarget ist intern
- Admin IP ist, wenn nicht gesetzt, die IP Adresse des aufrufenden Terminals.
- fehlende Verzeichnisse werden beim Speichern angelegt (1 Ebene).

Im Moment wird immer ein Backup von der Config beim Speichern erzeugt (Last-Known-Good; noch nicht abschaltbar).
Verzeichnisse sind alle änderbar, inklusive ROOT und BOOTDIR.

BOOT PROCEDURE SETTINGS syslog

Schon gefunden - Debug Ausgabe. Werde ich für den nächsten Upload entfernen.

 

[cando]

Neuer Patch gegen Trunk

Ich habe die BackUp Funktion optional gemacht, mann kann den Foldernamen Löschen, dann wird auch kein BackUp mehr gemacht,

Außerdem habe ich die Ausgabe im freetz UI gefixed. (BOOT PROCEDURE SETTINGS syslog )

und die Defaults-Datei, wie vorgeschlagen abgeändert.

Für weitere Wünsche und Hinweise bin ich natürlich dankbar, wenn man selber programmiert, wird man blind für die Details.

viele Grüße

Cando

 

[alpha1974]

Besten Dank an cando für die neue Version! Ich habe ja schon die Vorgängerfassung eingepatcht. Kann mir zufällig jemand auf die Schnelle verraten, wie ich den neuen Patch möglichst sauber einspiele (alten Patch vorher wie rückgängig machen?).
Danke!

 

[Silent-Tears]

Alter PAtch geht per "patch -R < patchfile" wieder rückgäng. Oder entsprechend neue Files löschen, und veränderte im trunk mit svn revert $filename" wieder rückgängig machen.

 

[alpha1974]

Für die ernsthaft Schutzsuchenden ist die debug.cfg Lösung die Beste, es ist der früheste Zeitpunkt, um die Box dicht zu machen - der Einwand von hermann72pb in Bezug auf Bootzeit und Speicher-Reparieren vor Freetz Start ist sehr ernst zu nehmen.

Mit Deinem Patch wird auf meiner 7170 zwischen debug.cfg und nhipt.cfg nur usbroot und syslogd gestartet (mit Startlevel 20 für Dein Script). Ein Verschieben in debug.cfg würde iptables nur vor die beiden vorgenannten Dienste schieben (wobei rc.usbroot nicht das Booten selbst beeinflusst). Diejenigen, die beim Booten ein e2fsck über einen externen Datenträger laufen lassen, haben ein Zeitproblem nur dann, wenn das vor nhipt.cfg in der debug.cfg oder -noch früher- über eine gepatche rc.S passiert. In letzterem Fall würde ein Start von iptables in debug.cfg aber auch nichts bringen, sondern müsste in rc.S hineingepatcht werden. hermann72pb hat insoweit vollkommen Recht, dass die über rc.S gestarteten AVM-Dienste beim Gesamtkonzept mitberücksichtigt werden müssen.