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

Die Botschaft hör ich wohl, allein mir fehlt der Glaube...

Ich bin nun nicht der große Linux Kenner. Ich habe mal gehört, dass es S-Level gibt, aber wo genau kann / soll / muss ich was ändern?

Ich möchte meine Box nicht komplett abschießen...
 
Fehler: Das Paket 'nhipt' ist nicht konfigurierbar.
Könnte die Meldung hiervon erzeugt werden?

Zum Thema Startlevel: Wenn ich es richtig verstanden habe, wird die Start-Reihenfolge der im Image enthaltenen Dienste unter Freetz beim Bauen des Images festverdrahtet und müssen deshalb in der *.mk-Datei des jeweiligen Pakets definiert werden, siehe hier. Auf der Box steht die Startreihenfolge der Dienste in /etc/static.pkg (nach meinem Wissen sind dort alle Dienste in der Reihenfolge aufgeführt, in der sie gestartet würden, wenn alle auf automatischen Start gesetzt wären und ein rc-Script vorhanden ist).
 
Zuletzt bearbeitet:
Code:
if [ -r "/mod/etc/default.$package/$package.cfg" -o -r "/mod/etc/default.$package/$package.save" ]; then

Was macht diese Zeile eigentlich?


-r prüft, ob die Datei vorhanden und lesbar ist
-o tru if shell optionname is enabled ???
-r prüft, ob die Datei vorhanden und lesbar ist???
 
"-o" = "oder". Somit "wenn eine der beiden Files lesbar ist.
 
Verstehe.

Mir ist der Initialisierungsprozess komplett unklar.

Da sind meine Dateien:

Code:
./root/usr/lib/cgi-bin/nhipt.cgi           # freetz cgi
./root/etc/init.d/rc.nhipt                 # post-back dazu
./root/etc/default.nhipt/nhipt.cfg         # die ganzen EXPORTS für Freetz

./root/usr/ipt/index.html                  # default frame für die Web Root
./root/usr/ipt/cgi-bin/nhipt.cgi           # die eigentliche Firewall Config CGI

Die Dateien / Verzeichnisse /mod/etc/default.$package/$package.cfg
existieren zur Design-Zeit gar nicht. Also müssen sie irgendwie erzeugt werden, dafür muss man aber irgendwo ein Script haben, das sie erstellt oder kopiert.

Dann muss man auch noch die

Code:
modconf load nhipt
modreg cgi nhipt NHIPT
module dem Freetz bekanngeben.

Ich habe sie mal Spaßeshalber mit der Hand kopiert, und mit modreg cgi nhipt NHIPT Mein Menu erzeugt.
Dann fehlte noch ein symlink auf die nhipt.cgi und die rc.nhipt und dann ging es.

Ich schwimme total.

Die Datei static.pkg ist nicht editierbar und zur Design-Zeit nicht vorhanden.
Ich lasse es wohl mit der richtigen Integration. Vielleicht erbarmt sich ja jemand und schreibt die paar Zeilen Freetz - Wrapper um das CGI oder gibt mir mal ein HowTo....

EDIT:

Ich habe jetzt eine Quick&Dirty Lösung gebaut, die funktioniert:
Ich habe das Kopieren und das Setzen der Symlinks in die rc.mod gleich nach der initialisierung der Standardpakete eingebrannt, nun funktioniert es auch nach einem Reboot und ich brauche keinen Stick mehr für das CGI.

Code:
#!/bin/sh

cd /
export TERM=xterm

. /etc/init.d/modlibrc

start() {
	echo "rc.mod version $(cat /etc/.freetz-version)"

	# Basic Packages
	for pkg in crond swap telnetd webcfg websrv; do
		rc="/etc/init.d/rc.$pkg"
		[ -e "/mod$rc" ] || ln -s "$rc" "/mod$rc"
	done

[COLOR="Red"][B]	mkdir /var/mod/etc/default.nhipt
	cp /etc/default.nhipt/*.* /var/mod/etc/default.nhipt
	ln -s /usr/lib/cgi-bin/nhipt.cgi /mod/usr/lib/cgi-bin/nhipt.cgi
	ln -s /etc/init.d/rc.nhipt /mod/etc/init.d/rc.nhipt
	modconf load nhipt
	modreg cgi nhipt NHIPT
[/B][/COLOR]

	[ -d /tmp/flash ] || /usr/bin/modload

	[ -r /tmp/flash/mod/resolv.conf ] || cat /var/tmp/resolv.conf>/tmp/flash/mod/resolv.conf

	/etc/init.d/rc.crond
	/etc/init.d/rc.telnetd
	/etc/init.d/rc.webcfg

	# Static Packages
	if [ -e /etc/static.pkg ]; then
		for pkg in $(cat /etc/static.pkg); do
			[ -x "/etc/init.d/rc.$pkg" ] && "/etc/init.d/rc.$pkg"
		done
	fi

	# AVM-Plugins
	plugins="`ls /var/plugin-*/control 2>/dev/null`"
	if [ -n "$plugins" ]; then
		echo -n "Starting AVM-Plugins"
		for plugin in $plugins; do
			echo -n "...`echo $plugin|sed 's/.*plugin-//;s/\/.*//'`"
			$plugin start 2>&1 >/dev/null
			[ $? -ne 0 ] && echo -n "(failed)"
		done
		echo "...done."
	fi
	
	[ -r /tmp/flash/rc.custom ] && mv /tmp/flash/rc.custom /tmp/flash/mod/rc.custom
	[ -r /tmp/flash/mod/rc.custom ] && . /tmp/flash/mod/rc.custom

	/etc/init.d/rc.swap
}

case "$1" in
	"")

		deffile='/etc/default.mod/_profile.def'
		[ -r /tmp/flash/mod/_profile.def ] && deffile='/tmp/flash/mod/_profile.def'
		modreg file 'Freetz___profile' 'Freetz: .profile' 0 "$deffile"

		deffile='/etc/default.mod/hosts.def'
		[ -r /tmp/flash/mod/hosts.def ] && deffile='/tmp/flash/mod/hosts.def'
		modreg file 'Freetz__hosts' 'Freetz: hosts' 1 "$deffile"

		deffile='/etc/default.mod/modules.def'
		[ -r /tmp/flash/mod/modules.def ] && deffile='/tmp/flash/mod/modules.def'
		modreg file 'Freetz__modules' 'Freetz: modules' 0 "$deffile"

		deffile='/etc/default.mod/resolv_conf.def'
		[ -r /tmp/flash/mod/resolv_conf.def ] && deffile='/tmp/flash/mod/resolv_conf.def'
		modreg file 'Freetz__resolv_conf' 'Freetz: resolv.conf' 0 "$deffile"

		deffile='/etc/default.mod/rc_custom.def'
		[ -r /tmp/flash/mod/rc_custom.def ] && deffile='/tmp/flash/mod/rc_custom.def'
		modreg file 'Freetz__rc_custom' 'Freetz: rc.custom' 0 "$deffile"

		[ -r "/mod/etc/conf/mod.cfg" ] && . /mod/etc/conf/mod.cfg
		modreg status mod '$(lang de:"Logdateien" en:"Logfiles")' mod/logs
		[ "$MOD_MOUNTED_SUB" = yes ] && modreg status mod '$(lang de:"Partitionen" en:"Partitions")' mod/mounted
		[ "$MOD_SHOW_BOX_INFO" = yes -a -r "/usr/lib/cgi-bin/mod/box_info.cgi" ] && modreg status BOXinfo 'BOX$(lang de:"-Info" en:" info")' mod/box_info
		[ "$MOD_SHOW_FREETZ_INFO" = yes -a -r "/usr/lib/cgi-bin/mod/info.cgi" ] && modreg status FREETZinfo 'FREETZ$(lang de:"-Info" en:" info")' mod/info

		start
		;;
	start)
		start
		;;
	*)
		echo "Usage: $0 [start]" 1>&2
		exit 1
		;;
esac

Es ist wahrscheinlich keine saubere Lösung, wie man es in die menuconfig reinbekommt ist mir auch noch ein Rätsel.

Ich habe mal alle benötigten Files als Archiv auf der 1.Seite gepostet. Es funktioniert soweit wie gehabt,
nun aber ohne die rc.custom zu bemühen.

Jetzt müsste man es noch ein wenig schleifen, damit man die debug.cfg auch noch irgendwie los wird, andererseits ist mit der debug.cfg als Urlader der Firewall die Box sehr frühzeitig geschützt, noch bevor der dsld eine Verbindung zum Internet aufbauen kann. Insofern ist die Lösung gar nicht so übel.
 
Zuletzt bearbeitet:
Die Dateien / Verzeichnisse /mod/etc/default.$package/$package.cfg
existieren zur Design-Zeit gar nicht. Also müssen sie irgendwie erzeugt werden, dafür muss man aber irgendwo ein Script haben, das sie erstellt oder kopiert.
Vieles wird bereits beim Build-Prozess des Freetz-Images erzeugt und dann fertig auf die Box geflasht. Sieh Dir doch mal die Dateien der einzelnen Pakete im Trunk unterhalb von /trunk/make/ an. Der richtige Ansatz für eine Freetz-Integration dürfte sein, im Source-Code lokal unterhalb von make/nhipt die erforderliche Dateistruktur anzulegen, dann mit make das Freetz-Image komplett neu bauen und testen... (entweder neu flashen oder via usbroot).
Im Endeffekt sollte für Dein Paket doch im laufenden Betrieb eine einzige veränderbare *.cfg-Datei ausreichend sein, die beim Booten über das rc-Script gehandled wird und über Deine GUI geändert werden kann. Viel mehr Dynamik haben die anderen Pakete auch nicht.
Die Datei static.pkg ist nicht editierbar und zur Design-Zeit nicht vorhanden.
Die Datei wird beim Erstellen des Freetz-Images "automatisch" erzeugt und muss nicht vom jeweiligen Paket editierbar sein. Wann Dein Dienst gestartet werden soll, legst Du vor dem Image-Bauen fest, indem Du eine passende Datei make/nhipt/nhipt.mk erzeugst und dort einen frühen Startlevel entsprechend dem o.g. Link angibst. Wenn dann das Freetz-Image neu gebaut und geflasht wird, wird Dein Paket an entsprechender Stelle in der beim Make-Prozess erzeugten static.pkg eingefügt.

Ich habe zum Testen ganz gute Erfahrungen mit usbroot gemacht, weil man dann nicht immer neu flashen muss, sondern im laufenden Betrieb einzelne Dateien im Root-System mit den Dateien überschreiben kann, die nach einem erneuten make auf dem Host erzeugt werden (usbroot kann man mit mount -o remount,rw / im laufenden Betrieb schreibbar machen).
Ich habe das Kopieren und das Setzen der Symlinks in die rc.mod gleich nach der initialisierung der Standardpakete eingebrannt,
Hmm... ich könnte mir vorstellen, dass die Freetz-Meister das nicht so gut finden, da es den abstrakten Ansatz von rc.mod aushebelt. Nach meinem Verständnis soll das, was Du jetzt fest in rc.mod eingefügt hast, vom eigenen init-Script des jeweiligen Pakets gemacht werden.

Ich fände es übrigens sehr schade, wenn Du frühzeitig aufgeben würdest! Es stimmt schon, dass die Dokumentationen nicht alles erläutern, aber wenn man sich die anderen Pakete im Trunk-Source mal anschaut, kann man sich doch da vieles abkupfern.
 
Leute, ich glaube wir müssen unsere Diskussion hier unbedingt ins WIKI einpflegen! Vor allem den letzten Posting von alpha1974. Denn, wie cando schon zurecht bemängelt, es ist nirgendswo durchgehend dokumentiert. Jeder kämpft sich da durch.
@alpha1974: Kannst du es bitte einpflegen? Wir schauen nachher drüber und ergänzen es zu Not. Aus dem letzten Posting kann man z.B. wunderbar 3 FAQ Fragen/Antworten erstellen.

Edit: @Moderatoren: Etwas offtopic hier, aber so am Rande und allgemein. Ich hatte gestern/heute nachts auf cando's Posting #145 geantwortet. Jetzt sehe ich meine Antwort irgendwie nicht mehr. Wer bzw. was hat meine Antwort gelöscht? Sowas passiert mir letztens ab und zu mal. Anfangs hatte ich gedacht: Ok, man wird ja älter, vergesslicher. Aber es ist wohl nicht so. Ich bin mir ganz sicher, dass ich Posting #145 bereits beantwortet hatte! Kann sein, dass ihr eine Datenspiegelung nachts am Laufen habt?

MfG
 
Zuletzt bearbeitet:
... Die Nacht war spät und der Frust war gros...

Hi,

Ich komme der Sache schon langsam irgendwie näher. Zumindest funktioniert das Paket schon mal nach dem Flashen und man kann (für weitere Entwicklungsarbeiten / "ServicePacks") die Root für den zusätzlichen Web-Dienst per freetz UI aus dem ROM auf den Stick verlegen.

Die gesamte toolchain / build Umgebung ist für mich noch ein schwarzes Loch. Ich werde mich aber bemühen, da was zustande zu bringen.

Im Grunde habe ich ja nichts zu Compilieren.

Ich muss nur folgendes erreichen:

  • Die Dateien müssen (aus einer Reposiitory == trunk) heruntergeladen und in das root Verzeichnis eingespielt werden
  • Das Paket muss als solches erkannt und initialisiert werden. Dazu gehört:
    • Erstellen Unterverzeichnis für das Paket in die RAM-Disk (damit freetz nicht meckert)
    • Kopieren der cfg in die RAM-Disk (damit freetz nicht meckert)
    • Erstellen des symlink für die freetz cgi
    • Erstellen des Symlink für die rc.nhipt für freetz
    • Aufruf der Registrierungsroutine des Pakets
  • Logik für make menuconfig
    • iptables müssen im paket sein
    • option für automatisches laden der module (Einschalten kernel Funktion)

Zur Bootzeit
  • Konfigurationspunkt finden und in Bootprozess eintragen als Ersatz für die debug.cfg (Im Flash, beschreibbar) - nice to have

EDIT: Ich habe mal das root Verzeichnis mit meiner bereits funktionsfähigen Modifikation hochgeladen.
 
Zuletzt bearbeitet:
Erfordert dann auch "replace kernel", wenn ich das grad so sehe.

Bau dein CGI am bestne im menuconfig unter Webinterface ein, nur sichtbar, wenn "replace kernel" aktiviert (wegen automatischem modulladen) (der "depends on" part im menuconfig).

Zusätzlich benötigst du einen Config-Punkt für die benötigten zusätzlichen kernel-Symbole, die du dann bei aktivierung deines CGIs aktivieren kannst (select ...).

Auch benötigst du eine Struktur bei deinem Paket "make/$pkg/files/root/<all das was du brauchst in den korrekten unterordnern mit den korrekten rechten>".
 
Ich sehe das etwas entspannter.

  • Einzige Abhängigkeit, die ich sehe ist die zu iptables
  • Wenn man iptables ohne replace kernel bauen kann, dann ist das für das GUI nicht zwingend. Man kann das GUI auch so nutzen.
  • Wenn man replaced kernel aktiviert, sollte die Option zum Autoload sichtbar werden, weil höherer Nutzen.
  • Optional kann man den COMMENT Patch hier auch noch auswählen (Diskussion weiter oben).
  • Die Struktur für $paket/files/root ist ja schon fertig (Siehe 1. Post im Forum paket root(ver).tar.gz
 
Zuletzt bearbeitet:
Ah, ich ging davon aus, dass die autoload-features für deine implementierung zwangsläufig notwendig sind.
 
EDIT:

Ich habe mein erstes freetz paket hinbekommen:

  • in make verzeichnis alles eingetragen (Paket erstellt und Config angepasst)
  • in der make root Config.in um den menupunkt für Web Interface ergänzt
  • meine Änderungen in der rc.mod wieder Rückgängig gemacht, geht nun ohne

Ich kann mit make menuconfig mein paket auswählen und mit make bauen. Und das Beste: es funktioniert sogar nach dem flashen. Das war die Pflicht.

Danke!

Nun kommt die Kür:

Wie baut man weitere Schalter ein, wenn replaced kernel ausgewählt wurde, um autoload modules und den Zusatzpatch für COMMENT sichtbar zu machen?

Was muss ich tun, um Euch das Paket für den Trunk zu übergeben?

Viele Grüße

cando

------------------
  • Nein, die wichtigsten Module werden für ipv4 automatisch erkannt und nachgeladen, bei Exoten und ipv6 habe ich es nicht weiter verfolgt, da es größere Änderungen in den Kernel-Versionen gibt.
  • Man kann jedes Modul von hand über die Expertenzeile oder der Shell laden.
  • Beim Speichern der Regeln wird mit lsmod alles, was nach iptables aussieht ausgelesen und in das Bootscript mit modprobe eingetragen, damit beim Reboot alle geladenen iptables / ip6tables Module wieder zur Verfügung stehen.

Insofern geht es auch ohne Automatik. Mit ist natürlich komfortabler.
 
Hewi, cool :)

Deine Fragen:

Um Module abhängig vom "replaced kernel" anzeigen zu lassen fügst du sie am besten zu kernel/Config.in hinzu. Abhängig von "FREETZ_REPLACE_KERNEL_AVAILABLE", dann sind sie nur nutzbar, wenn der kernel ersetzt werden _kann_. Dazu dann ein "select FREETZ_REPLACE_KERNEL", und dann wird "replace kernel" auch aktiviert, wenn man eine der optionen nutzt.
Um ein Paket zum Einchecken vorzuberieten, checkst du am bestne einmal den trunk komplett neu aus, fügst alle deine Files hinzu (svn add $path/to/file" und machst deine änderungen, wo auch imemr du sie gemacht hast.
Anschliessend machst du mit "svn diff > file.poatch" einen Patch fertig, hängst ihn an und wir schauen, dass es anch ein wenig testne im trunk landet.
 
OK, mach ich.

Die Option heisst im Kernel CONFIG_KMOD

Ich kann bei iptables CGI schon ein Untermenu mit einer eigenen Option anzeigen in Abhängigkeit, ob replace kernel selektiert ist.
Code:
config FREETZ_PACKAGE_NHIPT_KMOD
	bool "Enable kernel autoload modules"
	depends on FREETZ_PACKAGE_NHIPT
	requires FREETZ_REPLACE_KERNEL
	default n
	help
		Requires replaced kernel
		Enables iptables to automatically load necessary modules

Soweit so gut. Nun muss doch aber der Compiler wissen, dass er die Option im Kernel setzen soll. Wo muss ich das eintragen?
 
Ich bin ein Depp.

Ich habs hinbekommen, war im falschen Verzeichnis. Sorry.

Anbei der 1. Patch zur Begutachtung (Kernel Config ist noch nicht funktionsfähig)

Viele Grüße

cando
 

Anhänge

  • nhipt.patch.tar.gz
    17.1 KB · Aufrufe: 1
Super! Cando can do ;-)

Jetzt kommt die weitere Kür: Ich fände es charmanter, wenn das gesamte Paket ohne Änderungen an der debug.cfg auskäme. Dazu könntest Du alles, was jetzt in die debug.cfg geschrieben wird, in nhipt.cfg schreiben und via rc.nhipt start laufen lassen (im Grunde geht es ja beim Booten nur um ein evtl. Delay und das anschließende Setzen der Rules). Damit das ganze früh genug passiert, kannst Du in make/nhipt/nhipt.mk den Startlevel niedriger setzen (z.B. 15, müsste ggfs. mit den anderen frühen Diensten, v.a. usbroot, abgestimmt werden...).
 
Zuletzt bearbeitet:
Ja, das ist das nächste, wobei ich es weiterhin 2-geteilt machen würde.

Der Sinn dahinter ist, dass das Startscript immer auf der Box im Flash verbleibt (webgen der Booterei und evtl Warten auf Mount vom Stick) und die nhipt.cfg entweder aus dam Flash oder vom Stick nachzieht ("Aussperr-Zündschlüssel").

Die rc.nhipt start ist nicht der richtige Ort, da sie bei jeder änderung (stop / start) immer wieder aufgerufen wird. das hätte zur Folge, dass immer mehr regeln in iptables landen, oder ich jedes mal die Firewall herunter und wieder hochfahren muss.
 
Nicht, wenn man z.B. die Uptime einfach überprüft, oder ein Flag in /tmp setzt oder so etwas.
Dennoch halte ich schlicht gar nichts von der debug.cfg, und es gibt schon mindestens ein Paket, was ich ebne wegen Änderungen an der debug.cfg nicht mehr nutze.
 
Der Sinn dahinter ist, dass das Startscript immer auf der Box im Flash verbleibt (webgen der Booterei und evtl Warten auf Mount vom Stick) und die nhipt.cfg entweder aus dam Flash oder vom Stick nachzieht ("Aussperr-Zündschlüssel").
Das geht auch gar nicht anders, weil rc.nhipt nach dem Flashen nicht mehr verändert werden kann und deshalb "nur" in der Lage ist, die editier- und veränderbaren Rules etc. aus nhipt.cfg auszulesen und dann entsprechend zu verarbeiten oder auch nicht (wenn nhipt.cfg nicht vorhanden ist).

Du müsstest also "nur" rc.nhipt so anpassen, dass die in nhipt.cfg gespeicherten rules beim Booten gesetzt werden (ggfs. nach einem dort hinterlegten Delay-Wert). Außerdem muss sichergestellt sein, dass rc.nhipt start auch jedesmal beim Booten ausgeführt wird.

Ich habe mir Deinen Code noch nicht näher angeschaut, aber die anderen Pakete verwalten ihre Autostart-Einstellung beim Booten wie folgt selbst: Über die jeweilige GUI kann man zwischen Manuell und Autostart wählen, ob in der dazugehörigen .cfg-Datei eine enabled-Variable gesetzt wird (i.d.R. $paketname_ENDABLED). Das rc-Script wertet diese Variable in der load()-Sektion aus und veranlasst dort dann den Aufruf von start():
Code:
case "$1" in
	""|load)
		modreg cgi 'openntpd' 'Openntpd'

		deffile='/mod/etc/default.openntpd/openntpd_conf.def'
		[ -r '/tmp/flash/openntpd_conf.def' ] && deffile='/tmp/flash/openntpd_conf.def'
		[ "$CONFIG_FILE" != '/etc/ntpd.conf' ] && modreg file 'openntpd_conf' 'Openntpd config' 0 "$deffile"
		
		if [ "$OPENNTPD_ENABLED" != "yes" ]; then
			echo "$DAEMON is disabled" 1>&2
			exit 1;
		fi

		start
		;;

Bei Dir würde es vermutlich reichen, in der load-Sektion die start-Funktion aufzurufen und dort dann nhipt.cfg zu verarbeiten. Beim Booten ruft rc.mod Dein rc.nhipt ohne Parameter auf und überlässt es seinem weiteren Schicksal (= load wird in jedem Fall ausgeführt und kann dann selbst entscheiden, ob auch start ausgeführt wird).

Die rc.nhipt start ist nicht der richtige Ort, da sie bei jeder änderung (stop / start) immer wieder aufgerufen wird. das hätte zur Folge, dass immer mehr regeln in iptables landen, oder ich jedes mal die Firewall herunter und wieder hochfahren muss.
rc.nhipt start muss nur beim Booten ausgeführt werden (im Grunde nix anderes als debug.cfg, nur mit dem Unterschied, dass die veränderbaren Daten aus nhipt.cfg gelesen werden müssen). Wenn im laufenden Betrieb rules zu ändern sind, muss das Dein cgi machen und -für den nächsten Boot- in nhipt.cfg speichern.
 
Zuletzt bearbeitet:
Ich überlege mir was dazu... Ich werde mir mal die rc.S genauer ansehen und schauen, was AVM da wie startet. Vielleicht kann man sich was abgucken.

Die freetz Dienste starten sehr viel später, was eher ungünstig ist. Selbst wenn man einen Startlevel einstellt.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.