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

Ziel war es zu vermeiden, verteilt an verschiedenen Stellen settings etc. zu hinterlegen, damit man es händisch ohne Aufwand entfernen kann.
Ich für meinen Teil denke, das ist vollkommen unnötig.

Es ist gut, dass du so eine schöne Lösung für iptables baust. Aber, eine so komplexe Firewall zu konfigurieren, ist nur etwas für Profis. Und die werden wohl alle freetz installiert haben, weil sie auch noch andere Dinge benötigen, die die Original-Firmware nicht bietet. Also ist dieses Paket am besten in freetz aufgehoben. Einmal eingerichtet ist es dann im Normalfall immer auf der Box vorhanden, die Konfigurationsdateien sind viel transparenter als die Sachen mit der debug.cfg, und löschen lässt sich freetz auch ganz einfach.

Ich würde also vorschlagen, das iptables-Paket genau so aufzubauen wie alle anderen freetz-Pakete. Eine Möglichkeit der Nutzung ohne freetz ist m. E. nicht erforderlich.
 
Um das mit "2 GUI's" zu machen dürfte der Aufwand eher gering sein.

Du packst dein "echtes" cgi in (d)einem Paket-Ordner in den Unterordner "files/root/etc/default.<deinpaketname>/".
In diesem Ordner legst du auch in der Datei <deinpaketname>.cfg die Parameter fest, die du einstellen und in der "Freetz-Paketgui" nutzen kannst.

Ein Versuch, das zu beschreiben ist hier im Wiki

Eine Mini-GUI in speichert dann Web-Port usw.

das .rc-Skript kopiert ggf. dein "echtes" cgi und startet was auch immer du brauchst ;-)

Jörg
 
Das sehe ich auch so (ähnlich).

Nah-Ziel: Funktion

Das Paket hat alle Funktionen, die man braucht und kann ohne make menuconfig/make /flash auf die box von interessierten Usern schnell mal auf dem Stick gepackt und begutachtet werden. Hilft mir natürlich die Bugs zu finden und erspart den Benutzern die Neu-Installation bei Updates. Es ist ja noch lange nicht fertig, es kommen ständig neue Funktionen dazu.

Fern-Ziel: Integration

Das Paket wird in svn gepackt und über make menuconfig in den Flash der Boxen geladen / verteilt und über freetz verwaltet (entweder nur der deamon wie freetz-wol, mit eigenem web-interface oder im selben httpd von freetz). Ich persönlich bevorzuge wie Silent-Tiers die erste Variante, da fw ja ein sensibleres Thema ist. Ich würde den deamon nur bei Bedarf auf dem lan interface lauschen lassen (über config einstellbar), während freetz ja auf allen interfaces läuft. Dann macht es auch Sinn die Settings mit der freetz Mimik zu sichern und die temporären Scripte gleich aus der Prozessverwaltung von freetz heraus beim Start zu erstellen.

Ich bin mir noch unsicher, inwieweit ich die Mimik für die Speicherung der Variablen und der Prozessverwaltung ohne extra Erstellen eines freetz Paketes jetzt schon definieren und nutzen / testen kann. Bisher ist es mir noch nicht so recht gelungen, mit Export irgend was über den Reboot hinaus aufzuheben. Ich muss ja unter Umständen eine recht umfangreiche Liste von iptables Rules sichern und laden. Ich komme eher aus der Windows Welt und tue mich noch recht schwer mit dem Linux shell Scripting, deshalb ist manches vielleicht auch noch zu umständlich programmiert. Mir fehlt bei der Box auch der Überblick, welche Verzeichnisse ohne Pakettierung/FW-Flash permanent wie beschreibbar sind, bislang kenne ich nur die "debug.cfg" und die "ar7.cfg". Gibt es irgendwo eine Übersicht der beschreibbaren Dateien, und gibt es vielleicht schon "leere" files, die man für Testzwecke bereits hernehmen kann?

Die debug.cfg schien mir für den Moment die einfachste Lösung zu sein, die auch ohne Stick und Firmware-Flashen funktioniert.

Welche Alternativen gibt es denn, um Daten über einen Reboot weg zu retten, ohne vorher ein passendes freetz Paket zu bauen?

Vielen Dank für Eure Tipps,
 
Alles was (auf einer Freetz-Box) unter /tmp/flash liegt, wird mit einem "modsave" gesichert und ist so "resetfest".

Jörg
 
Die Settings vorläufig auf einem angeschlossenem Stick unterbringen und dort entsprechend zu editieren.
Auch USB-Root wäre denkbar, dann kannst du die Sachen auch direkt editieren. Alternativ: mount -bind (bis zum Neustart, um Änderungen zu machen).

Am Rande: Ich würde wirklich gern sehen, wenn in dem Script eine "Sicherheitsspanne" vorhanden ist, in der die Regeln noch nicht ziehen. Was weiss ich. So 1-2 Minuten nach dem Neustart, denn dann kann man evtl. bei verkrauteten Regeln immer noch schnell intervenieren und vllt. die Standardsettings" Wiederherstellen, bevor man sich sonst evtl aussperrt ;)

Aber ich denke, du solltest dort direkt sauber anfangen das zu implementieren als eigenes Paket. Immerhin muss nichts kompiliert werden oder so, deswegen ist es noch einfach. Schau dir einfach die weolSachen an. Es ist einfach ;)
 
Gute Idee, mit dem verzögerten aktivieren der Firewall nach Reboot.
Werde mir was für das boot script überlegen, vielleicht mit konfigurierbaren Timer für Einmal-cron job oder so.

Aber eigentlich kann nichts passieren, weil die Regeln ja nie automatisch persistiert werden, sondern direkt auf iptables wirken. sperrt man sich aus, ist die alte Konfig ja im Flash und ein reboot macht alles wieder gut.

Wenn das das UI noch erreicht, um den persist Knopf zu drücken, erreicht man es auch nach dem Reboot, um weiter zu konfigurieren. Das einzige Problem kann ein zerschossenes Start Script sein (z.B. durch manuelles editiern in der shell).
Nur: dagegen ist wohl kein Kraut gewachsen.

Was die freetz Integration angeht, so eine Mimik wie das wol-cgi ist schnell zusammenkopiert und angepasst, das ist kein Problem. Es macht ja eigentlich nur den Menüpunkt, und startet / stoppt den httpd. Wenn ich mit dem Rest soweit bin, baue ich den Wrapper schnell zusammen, da packe ich auch gleich allle Einstellungen für den boot-delay, server port und lan interface, admin ip, die directories Einstellungen und vielleicht noch einen Link für ein tail im Webinterface auf die aktuellen logdateien (system / firewall), sowie das Housekeping für das rollen der logs (wöchentlich, max. Anzahl...) mit rein.

Das kann aber noch ein paar Tage dauern.
 
Zuletzt bearbeitet:
Wie wäre denn das:

Die Start-Scripte und Regeln auf dem Stick ablegen und beim Booten z.B aus der debug.cfg oder einem anderen Service Script die Initialisierung vom Stick laden.

Im Notfall Stick abziehen und booten. Alle Regeln sind dann spurlos verschwunden und iptables läuft nicht (bzw. läuft mit den Default-Policies ACCEPT für alle Chains, wenn man denn den Service Manager von freetz verwendet). Das wäre doch die DAU Lösung.

Für Fortgeschrittene, kann man eine "Experten Funktion" einbauen, die die getestete Config permanent auf die Box überträgt und den Pfad neu setzt, dann geht es auch ohne Stick.

Ist der USB-Stick eigentlich schon gemountet, wenn die debug.cfg ausgeführt wird?

Für weitere Vorschläge bin ich natürlich offen.
 
Zuletzt bearbeitet:
Ist der USB-Stick eigentlich schon gemountet, wenn die debug.cfg ausgeführt wird?
Nicht unbedingt. Deswegen werden häufig Warteschleifen verwendet (mit oder ohne Timeout).

Wenn die Regeln vor Zugriffen von Außen schützen sollen, dann sollten sie schon aktiv sein, bevor die Box online geht. Notfalls bleibt einem immer noch das Recover. Und spätestens danach denkt man daran, die Konfiguration regelmäßig zu sichern.
 
Da hast Du auch wieder Recht. Die Konfig wird ja bei jedem Speichern mit Zeitstempel im Backup Verzeichnis abgelegt. Da kann man schnell einen beliebigen Stand wiederherstellen.

Natürlich ist es wegen der Sicherheit viel besser, die Box möglichst frühzeitig abzuriegeln, der Urlader sollte ja schon vor der debug.cfg fertig sein mit dem Pollen nach neuen Images.

Ich glaube, ich lasse das den User entscheiden. Ich mache mal einen "safe" mode, bei dem 2 Regeln von System für das lan / admin interface automatisch vorangestellt werden und lasse insert / delete / move erst ab der 2. Stelle zu, nach einem kompletten löschen der chain, wird die jeweilige regel neu reingeschrieben und die Config / Scripte können auf dem Stick bleiben - mit boot Delay.

Dann ist man auf der sicheren Seite und die Bedenken von Silent-Tiers wären ausgeräumt.

Andererseits kann man aber auch den Fort-Knox Mode für eine Produktivumgebung einschalten, die Regeln wandern in den Flash der Box und werden beim Boot sofort geladen - dann wie RalfFriedel sagt: selberschuld. ;)
 
Hallo, ich bins wieder :rolleyes:

Ich habe mich mal mit dem freetz cgi's nach Anleitung beschäftigt, komme aber irgendwie nicht so recht weiter. Ich kann über die freetz mimik die Variablen setzen und alles, nur sehe ich den Webserver nicht unter den Services und weiss nicht, wie ich den dazu bringe, sich starten und stoppen zu lassen. Ich habe es mal mit gestartetem und mit gestopptem httpd probiert. Tut sich nichts. Irgendwo fehlt mir noch so der letzte Schubs. Natürlich kann ich da was hart rein codieren, aber ich wollte ja die freetz pattern so gut es geht implementieren.

PS.

in der Wiki ist glaube ich ein Fehler im code Beispiel in der Beschreibung., vor dem unload) sind da 2 mal die ;; ;; drin. Kann so, glaube ich, wohl nicht gehen, oder täusche ich mich da?;)

Wiki:
Code:
              ;;
     ""|load)
                # CGI registrieren
                modreg cgi $DAEMON Bezeichnung
                # File registrieren (wird resetfest ins flash gespeichert)
                modreg file 'hugo_file' 'HUGO: File' 0 "/mod/etc/default.hugo/hugo.def"
               
                if [ "$HUGO_ENABLED" != "yes" ]; then
                        echo "$DAEMON is disabled" 1>&2
                        exit 1
                else
                        start
                fi
                ;;

                ;;
        unload)
                stop


rc.nhipt
Code:
#!/bin/sh

export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin
export LD_LIBRARY_PATH=/mod/lib

DAEMON=nhipt
DEAMON_LONG_NAME="NHIPT IPTABLES MANAGEMENT INTERFACE"
PID_FILE=/var/run/nhipt.pid

case "$1" in
	""|load|start|restart|status)
		if [ ! -r /mod/etc/conf/nhipt.cfg ]; then
			echo "Error[$DAEMON]: not configured" 1>&2
			exit 1
		fi

		. /mod/etc/conf/nhipt.cfg
		;;
esac

config() {
	(
		if [ -x "/tmp/flash/${DAEMON}_conf" ]; then
			/tmp/flash/${DAEMON}_conf
		else
			/mod/etc/default.nhipt/${DAEMON}_conf
		fi

		if [ -r "/tmp/flash/${DAEMON}.extra" ]; then
			cat /tmp/flash/${DAEMON}.extra
		fi
	) > /mod/etc/$DAEMON.conf
}

start() {
         # HIER KOMMEN DIE VERARBEITUNGEN REIN
         echo "Starting nhipt..."
	config

	echo -n "Starting $DAEMON_LONG_NAME..."
	httpd -P "$PID_FILE" -p "$NHIPT_SERVERIP":"$NHIPT_PORT" -h "$NHIPT_ROOT"
	exitval=$?
	if [ "$exitval" -eq 0 ]; then
		echo 'done.'
	else
		echo 'failed.'
		exit $exitval
	fi

}

stop() {
         # HIER KOMMEN DIE VERARBEITUNGEN REIN
         echo "Stopping nhipt..."
	modlib_stop
}

case "$1" in

	""|load)
		modreg cgi 'nhipt' 'Iptables Firewall'

		config
		if [ "$NHIPT_HTTPD_ENABLED" != "yes" ]; then
			if [ "$NHIPT_HTTPD_ENABLED" != "inetd" ]; then
				echo "$DAEMON is disabled" 1>&2
			else
				echo "$DAEMON is started via inetd" 1>&2
			fi
			exit 1
		fi

		start
		;;
	unload)
		stop
		;;
        start)
                start
                ;;
        stop)
                stop
                ;;
        restart)
                stop
                start
                ;;
        status)
                if [ -z "$(pidof '$DAEMON')" ]; then
                        echo 'stopped'
                else
                        echo 'running'
                fi
                ;;
     ""|load)
                # CGI registrieren
                modreg cgi $DAEMON Bezeichnung
                # File registrieren (wird resetfest ins flash gespeichert)
                modreg file 'nhipt_file' 'NHIPT: File' 0 "/mod/etc/default.nhipt/nhipt.def"
               
                if [ "$NHIPT_HTTPD_ENABLED" != "yes" ]; then
                        echo "$DAEMON is disabled" 1>&2
                        exit 1
                else
                        start
                fi
		;;
        unload)
                stop
                modunreg cgi 'nhipt'
                ;;
        *)
                echo "Usage: $0 [start|stop|restart|status]" 1>&2
                exit 1
                ;;
esac

exit 0

nhipt.cgi:

Code:
#!/bin/sh

PATH=/bin:/usr/bin:/sbin:/usr/sbin
. /usr/lib/libmodcgi.sh

auto_chk=''; man_chk='';
if [ "$NHIPT_ENABLED" = "yes" ]; then auto_chk=' checked'; else man_chk=' checked'; fi


sec_begin 'Activation'
cat << EOF
<div style="float: right;"><font size="1">Version 0.0.88</font></div>
<p>
<input id="e1" type="radio" name="enabled" value="yes" $auto_chk><label for="e1"> Active</label>
<input id="e2" type="radio" name="enabled" value="no" $man_chk><label for="e2"> Inactive</label>
</p>
EOF
sec_end


sec_begin 'NHIPT interface'
cat << EOF
...
<table border=0 cellpadding=0 cellspacing=0>
<tr><td>SERVER IP:</td><td><input type="text" name="serverip" value="$(html "$NHIPT_SERVERIP")"></td><td rowspan=6 width=30px>&nbsp;</td><td rowspan=6><A HREF=http://fritz.box:$(html "$NHIPT_PORT")/cgi-bin/nhipt.cgi>CONFIGURE NOW THE WALL</A></td></tr>
<tr><td>SERVER PORT: </td><td><input type="text" name="port" value="$(html "$NHIPT_PORT")"></td></tr>
<tr><td>WWW ROOT: </td><td><input type="text" name="root" value="$(html "$NHIPT_ROOT")"></td></tr>
<tr><td>ADMIN IP: </td><td><input type="text" name="adminip" value="$(html "$NHIPT_ADMINIP")"></td></tr>
<tr><td>LOG DIRECTORY: </td><td><input type="text" name="logd" value="$(html "$NHIPT_LOGD")"></td></tr>
<tr><td>SAVE DIRECTORY: </td><td><input type="text" name="save" value="$(html "$NHIPT_SAVE")"></td></tr>
<tr><td>USE DEAMON: </td><td><input type="text" name="httpd_enabled" value="$(html "$NHIPT_HTTPD_ENABLED")"></td></tr>
<tr><td> </td><td></td></tr>
</table>...
EOF
sec_end

nhipt.cfg

Code:
export NHIPT_SAVE='/var/media/ftp/uStor01/ipt'
export NHIPT_LOGD='/var/media/ftp/uStor01/log'
export NHIPT_PORT='82'
export NHIPT_ROOT='/var/media/ftp/uStor01/ipt'
export NHIPT_CHANGED='0'
export NHIPT_SERVERIP='192.168.0.254'
export NHIPT_ADMINIP='192.168.0.23'
export NHIPT_ACTION='ACCEPT'
export NHIPT_HTTPD_ENABLED='httpd'
 

Anhänge

  • nhipt.jpg
    nhipt.jpg
    61.9 KB · Aufrufe: 30
  • services.jpg
    services.jpg
    80.1 KB · Aufrufe: 29
@cando: Ich glaube, du hast dich mit der FREETZ-Struktur noch gar nicht auseinander gesetzt, sonst würdest du auf deinem debug.cfg und USB-Stick nicht mehr so weiter reiten. Mach das bitte umgehend, es ist mein Rat an dich. Du kannst mit FREETZ-Mitteln viel mehr machen, als nur einen zusätzlichen httpd-Server starten. Du könntest z.B. deine kompletten Regeln als fertige Config-Dateien (über FREETZ-WebIF editierbar) anlegen. Die Variablen kannst du ebenfalls mit FREETZ behandeln. Also alles rumherum, damit dein eigenes WebIF sich nur mit den iptables selbst beschäftigt und nicht damit, wo man was und wie speichert und startet. Auch die Delay-Funktion könnte man unter FREETZ untermauern. Somit hättest du wenigstens eine Hintertür über FREETZ die Sachen zu steuern.
Zu debug-Zwecken. Ich will nur alle hier daran erinnern, dass man Pakete/cgis unter freetz hervorragend ohne diverse "mount -o bind" oder USB-Klimzüge testen kann, indem man die cgi-s ins RAM an die entsprechende Stelle hinterlegt. Binarys (Shell-Skripte) kann man auch unter /mod/usr/bin packen. Anschließend kann man cgi-s "life" unter FREETZ registrieren und schon tauchen sie im WebIF auf.
Diese Geschichte war damals vermutlich von Daniel für dynamische Pakete angedacht, die bis jetzt noch keiner realisiert hat. Sie kann aber gut für debug-Zwecke gebraucht werden.

Edit: Du warst doch schneller, als ich dachte. Es geht schon in die richtige Richtung! Jetzt nur weiter und mehr FREETZ-Internalien nutzen!

MfG
 
Genau so habe ich das ja gemacht, wie in der wiki beschrieben, die conf dateien in das ram der box und 2 symlinks für die nicht beschreibbaren Bereiche. Die Doku ist aber ein wenig mager, was die möglichen Parameter angeht und wie sich was wo im UI auswirkt. Am Liebsten würde ich mir eine eigene Datei im Flash sichern, die ich mit dem Script für den Lader der Regeln beim Start befüllen kann und die Konfigurationen des UI's (Pfade, Ports, Schalter, Logausgabe etc.) in der freetz Oberfläche setzen.

Für das Interface zum Regelwerk tendiere ich immer noch eher zu einem eigenständigen gekapselten script, wegen besserer Performance, Kontrolle und Nutzung der Bildschirmfläche. ich möchte den ganzen Kram ungern in die rc.modulname packen.

Die Internalien würde ich gern erst mal irgendwie kennenlernen, damit ich sie auch nutzen kann. Wo finde ich denn eine Referenz für die Kommandos und der möglichen Parameter?
 
Diese WIKI-Seite mit dem HUGO-Beispiel ist schon Gold-Wert. Wenigstens fängst du nicht bei Null an. Klar, funktioniert da nicht alles auf einmal und es können auch in HUGO-Beispiel Fehler existieren. Aber das alles sollte dich nicht vom Lernen abhalten. Als ich meinen downloader programmiert hatte, hatte ich es alles durch das Abschauen bei den anderen Paketen gelernt. War nicht optimal und hat mächtig Zeit gekostet, danach war ich aber deutlich schlauer.

Konkret zu deinen Sachen. Ich sehe bei dir da noch andere Fehler, die auf dich eventuell noch zukommen. Das ist das Abspeichern der Variablen und Auslesen von Variablen. Das ist ein Zusammenspiel zwischen Javaskript, dynamischen html und shell-cgi, die ich bis jetzt nicht richtig verstanden hatte. Man muss da eine passende Benennung der Variablen zwischen dem Shell und der html-Welt haben. Ich meine, die Namen müssen gleich sein. Einer davon ist nicht case-sensitiv. Oder etwas in der Art. Irgendwann mal kriegst du es hin, wird dir aber sicherlich anfangs viel Ärger kosten.

Zum Vorhandensein vom Dienst im WebIF. Da habe ich leider keine Ahnung, warum, wieso usw. Findest du denn deinen rc-Skript unter /etc/init.d auf der Box? Lassen sich einzelne Sektionen (start, stop, etc.) per Kommandozeile aufrufen? Was meldet die Konsole?

MfG
 
Hallo Hermann,

Danke für Deine Anteilnahme.

Wie Du schon schreibst, muss man stets ein Reverse-Engeneering von allen guten und nicht so guten Beispielen machen, um zu erahnen, was denn das freetz ist und wie das cgi arbeitet. Du schwärmst einerseits von der tollen Möglichkeiten, andereseits kennst Du sie nur an der "Oberfläche". Das hällt mich schon ein wenig davon ab, sensible Dinge ins Interface zu packen.

Bis jetzt habe ich folgendes verstanden (bitte korigiert mich):

Das Framework besteht aus 2 Teilen: dem

module.cgi - erzeugt die Eingabefelder im FREETZ Formular
rc.module - ist das Hintergrund - "postback" cgi zu dem Formular, wobei die Felder nicht aus QUERY_STRING oder STDIN geparsed werden müssen, sondern über die SHELL Variablen zugänglich sind.

rc.module ist aber auch so was wie ein "pseudo-deamon"

welche Funktionen die modlibrc liefert ist mir unklar.

modreg scheint einer der Zauberstäbe zu sein, mit dem man das Interface gestalten kann. Da gibt es wohl:
modreg cgi pkg title, was einen Eintrag im Bereich Pakete bewirkt.
modreg extra pkg title sec-level cgi-name erzeugt wohl auch einen Menu Eintrag, wo weiss ich noch nicht.
modreg file id title sec-level desc-file klingt nach der alternativen Datensammler Datei für das extra script, was es mit der id auf sich hat und wozu das desc file gut ist, kann man nur erahnen.
modreg status pkg title cgi-name[/B] ist mir unklar, vermutlich liefert es den status zurück vom rc.mod oder so?

Dann die .def dateien:

CAPTION="Überschrift"
DESCRIPTION="Noch eine Überschrift"
CONFIG_FILE="/tmp/flash/hufo_file" - das ist wohl die eigentliche Datei
CONFIG_SAVE="modsave flash" - das soll den ganzen flash flashen
CONFIG_TYPE="text" - was gibt es außer text, welche auswirkungen hat der Eintrag, werden damit auch execute flags gesetzt gesetzt?

Ich muss ja nicht nur Parameter ablegen, sondern auch extra scripte, kann ich die auch damit in das flash schreiben? Man könnte ja reine CGI pakete ohne die Firmware zu flashen damit in die Box einbauen, sogar ganz extern vom stick, wenn man denn die Funktionen verstehen würde.

modconf load|save|default|set|vars pkg macht bitte was genau?
modconf merge|diff conf-file erzeugt wohl die diff datei zwischen defaults und usereingaben. Ich vermute mal, man muss danach mit modconf save paket damit irgendwas anstellen? und mit modsave flash alles tatsächlich schreiben.

modsave speichert den ganzen flash inklusive user & passwd
modsave flash speichert nur das flash verzeichnis

Was gibt es eigentlich außer das flash verzeichnis, was modsave noch flashen kann? Bei mir bewirken beide Befehle scheinbar das gleiche, wenn man den Bytes saved traut, es werden 32k Daten geschrieben:

Code:
/var/mod/root # modsave
Saving users, groups and passwords...done.
Saving config...done.
Writing /var/flash/freetz...done.
32768 bytes written.
/var/mod/root # modsave flash
Writing /var/flash/freetz...done.
32768 bytes written.

Nun weiter: wie kann man Daten, Pakete etc wieder deregistrieren / löschen?
durch Probieren habe ich folgendes gefunden:

Code:
modunreg
Usage: /usr/bin/modunreg cgi <pkg>
       /usr/bin/modunreg extra <pkg> [<cgi-name>]
       /usr/bin/modunreg file <id>
       /usr/bin/modunreg status <pkg> [<cgi-name>]

Sind das alle Kommandos, die für die UI bereitgestellt werden?

- Wie erzeuge ich einen Eintrag unter Status - um z.B. ein firewall log oder system log zu listen?
- Was ist nötig, damit ein Dienst unter Dienste Basispakete / Statische Pakete erscheint?
- Wie bekomme ich Einträge unter Einstellungen rein?
- Eintrag unter Pakete funktioniert wohl mit modreg paket
- Wie bekomme ich einträge unter Extras (modreg extras?)
- Wie kann ich einen Section Top Link oder External Link in das Menu einfügen (z.B. für ein Popup a la Rudi-Shell)
- Wie bekomme ich Einträge in das Status Formular rein? (z.B. um anzuzeigen, ob die Firewalls aktiv sind, ob das Logging eingeschaltet ist, ob die Einstellungen gesichert wurden)
- Wie gebe ich Listen einheitlich aus (jeder macht es anders siehe syslog, logdateien etc)

Eine Style Guide wäre super. Wenn man sich das freetz ansieht, schaut es recht chaotisch aus, da stets das Muster kopiert wird, ohne es zu verstehen.
Da sind Labels und Eingabefelder so ausgefranst angeordnet, einige wenige tabellen tags in den Masken würden das ganze professioneller wirken lassen.

Wie sieht es mit der Integration von Unter-Forularen in der selben Maske und eigene post-back routinen / Sektionen aus, man muss ja nicht immer jedes mal alles flashen, was man eingibt. Was ist mit style-sheets?

Wenn ich mir das UI ansehe, und wie die Module integriert wurden, habe ich schon das Gefühl, dass etwas mehr Infos und Anleitung den Entwicklern helfen würde, eine gute Integration hinzubekommen.

Was soll denn wo am besten konfiguriert werden?

Beispiel:

-Wenn ich auf Status klicke erwarte ich einen Status der Box, finde aber ein Formular, das das Brannding einstellt und die USB mountet inklusive der Buttons für Backup, Restore, Reboot, etc. (braucht man ja auch oft)

- Darunter wieder halbwegs sauber boxinfo, freetzinfo, logdateien, partitionen (mit config Funktion) RRDStatus, Syslog

- Einstellungen (Hauptformular ) was gehört hierher und wie? Es sieht so aus, als wäre das hauptsächlich für das freie Editieren von config-Dateien gedacht.

- Pakete ist auch wieder etwas durcheinander. Mal sind es die Einstellungen für den Dienst, wie manueller oder Autostart, Ports, Verzeichnisse etc. dann wieder die UI selbst, die der Dienst bereitstellt wie z.B. AVM Firewall oder das CGI für iptables. Dann gibts noch die Mimik mit dem wol-cgi, und rrd cgi etc, die eigene Webservices definieren und zum Teil sogar aus der normalen AVM Oberfläche verlinkt werden.

Was gehört nach Extras rein?

Wie Du siehst, sind hier mehr Fragen offen, als einer allein beantworten kann.
Deshalb tue ich mich auch schwer da was zu integrieren, an was soll ich mich denn orientieren?. :noidea:

Deshalb auch meine Idee, freetz nur freetz like zu nutzen, um den httpd mit interface, port und root Verzeichnis zu registrieren / starten / stoppen oder vielleich einen symlink ins freetz cgi-bin zu setzen, damit das UI registriert wird, die "Dienste" Mimik von freetz zu emuliern um diese Settings zu sichern, die modsave / modsave flash zu verstehen um die eine eigene Config / startscript für die Firewall mit Hilfe der Routinen zu speichern.
Dann vielleicht ins Freetz Menu einen Top Link einfügen mit target "neues Fenster" und dort in voller Geschwindigkeit die Eingaben direkt verarbeiten, ohne sinnlos die Systemvariablen mit iptables rules Fragmenten vollzuschreiben.

Bitte korrigiert mich, wenn ich falsch liege.
 
... dass Freetz "etwas chaotisch" ;-) ist, wird sich nach meiner Meinung nach jetzigem Stand nicht vermeiden lassen. Es gibt keine "absolut strikten" Vorgaben, sondern das ganze Projekt basiert natürlich auf vielen Teilnehmern, von denen jeder seine Vorstellungen davon hat, wie eine GUI aussehen sollte/könnte...

Da wären vielleicht stärkere Vorgaben besser, könnten sich aber auch als kontraproduktiv erweisen, denn ein "Deine GUI passt nicht zu 100%, die kommt nicht rein" könnte bedeuten, dass weniger Beiträge kommen, was ich sehr schade fände, da lebe ich lieber mit etwas weniger "Vorgaben" (just my 2 cents).
Dass z.B. die "Pakete" für die FW-GUIs anders sind, ist klar, es geht ja dabei auch um anderes, als für die Konfig von Diensten. Momentan gibt es aber eben nur "Pakete".

Im Resultat: Sicher kein optimales Konzept, aber "so schlecht", wie man das nach deinen Schilderungen sehen könnte, finde ich es nicht ;-).

Zur "mangelhaften Dokumentation" kann man eigentlich immer nur das gleiche sagen: Jeder ist aufgefordert, unzureichende oder falsche Teile zu ergänzen oder korrigieren. Deine "Zusammenfassung" könntest du ja dort netterweise mal mit einbringen.

Einige Infos schonmal:
Die Dienste, die auf der Statusseite stehen, werden in "usr/mww/cgi-bin/daemons.cgi" mit dieser Schleife generiert:
Code:
[...]
if [ -e /etc/static.pkg ]; then
   for pkg in $(cat /etc/static.pkg); do
[...]
diese Datei müsstes du ergänzen und "Übermounten". Dasmit es geht, muss das rc-File (wie schon in der verfügbaren Doku beschrieben ;-)) "status" können ;-)

Extras bekommst du da rein mit "/usr/bin/modreg extra <pkg> <title> <sec-level> <cgi-name>". Genaueres muss ich gestehen, weiß ich auch nicht, das wirst du ggf. direkt aus "usr/mww/cgi-bin/extras.cgi" herauslesen....

Jörg
 
Danke, werde mal weiter suchen. War ja nicht böse gemeint, ich habe großen Respekt vor allen, die hier mit viel Einsatz und Ehrgeiz bei der Sache sind, man könnte denen ja das Leben und den Einstieg etwas mehr erleichtern. Ich werde meine Erkenntnisse, sobald diese gesichert erscheinen, in die Wiki einfliessen lasssen. Übrigens, mir ist aufgefallen, dass sich die Strukturen / Links der wiki wieder mal verändert haben, ältere Links aus dem Forum gehen ins leere.

Ich wollte einfach mal anregen, die Kommandos kurz und knackig zu dokumentieren, damit man sie gleich versteht und nicht erst reverse-engeneeren muss.

Ich bin gerade dabei die modsave mal reverse zu engeneeren, denn es wird entgegen der landläufigen Meinung nicht alles, was im flash Verzeichnis ist, mit gesichert, scheinbar werden nur die diff dateien weggeschrieben, eigene Files nicht, zumindest sind sie nicht im /flash/freetz eingepackt. Auch selbst angelegte "extra" dateien sind nach reboot nicht zu finden.

Was das Interface angeht, ich werde das so handhaben, dass ich den httpd und die Verzeichnisse mit freetz mitteln setze und den Rest selbst in die Hand nehme. Für die Speicherei und Loaderei beim Reboot suche ich noch nach einer minimalinvasiven Lösung, solange lasse ich es bei der debug.cgi.

Viele Grüße

cando
 
... ist auch nicht böse angekommen ;-)

Ich stand ja selbst davor (und stehe es noch oft) manche Dinge nicht ganz verstanden zu haben und habe dann (mit anderen zusammen) versucht, die "Ergebnisse und Erkenntnisse" dann zu Dokumentierten, so gut es eben ging.

Das modsave ruft übrigens auf jeden fall "save()" auf, was per tar den gesamten Ortner /tmp/flash in ein tempfile schreibt ("tar -cf $TMPFILE flash -C /tmp/") und "wegsichert" (sofern er unterhalb der festgelegten Maximalgröße liegt).

Jörg
 
Zuletzt bearbeitet:
Hi cando,
Danke für die vielen Fragen. Ich werde, soweit mein Wissen reicht, über das Wochenende versuchen die Doku zu erweitern.

MfG Oliver
 
...
Das modsave ruft übrigens auf jeden fall "save()" auf, was per tar den gesamten Ortner /tmp/flash in ein tempfile schreibt ("tar -cf $TMPFILE flash -C /tmp/") und "wegsichert" (sofern er unterhalb der festgelegten Maximalgröße liegt).
Jörg

Habe ich in der source und in der Doku auch so gelesen, tut es aber nicht, nach dem Reboot ist das file weg.

Beispiel:
Code:
/var/flash # echo "ABCDEFGH" > /var/flash/myfile.txt
/var/flash # cat /var/flash/myfile.txt
ABCDEFGH
/var/flash # modsave
Saving users, groups and passwords...done.
Saving config...done.
Writing /var/flash/freetz...done.
32768 bytes written.
Soweit sogut

schaue ich im im Paket rein (die Dateinamen sind im Klartext Lesbar)
Code:
/var/flash # cat /var/flash/freetz | grep myfile
/var/flash # cat /var/flash/freetz | grep ABCDE
/var/flash #

... nichts drin !

die diffs aber schon:

/var/flash # cat /var/flash/freetz | grep .diff     
flash/wol.diff
flash/dnsmasq.diff
flash/avm-firewall.diff
flash/samba.diff
flash/mod.diff
flash/syslogd.diff
flash/rrdstats.diff
flash/virtualip.diff
flash/callmonitor.diff
flash/nhipt.diff
/var/flash #

Nach dem Reboot ist das file auch wirklich nicht mehr da.

Ist aber nicht mehr so wild. Ich mache das jetzt anders.
ich suche mir eine leere Node und mache mir ein eigenes charakter device mit mknode:

Zunächst ermittle ich die major Nummer, dann suche ich in einem Bereich zwischen 145 und 149
(liegt weit weg von allem) nach einem passenden device (prüfe, ob nicht bereits gemounted,
dann mache ich ein Probe-Mount und wenn es leer ist, benutze ich es für meine Regeln und
merke mir die ID in den Settings / debug.cfg, beim reboot mounte ich es und schaue nach,
ob iptables drin sind, wenn ja ist alles OK und ich kann es nutzen. Hat es jemand Platt gemacht,
(durch Flashen von Firmware), dann ist es halt so und lasse es dann sein (keine iptables / fresh install).

Ausserdem mache ich in der Config eine Auswahl

- starten aus der debug.cfg (Safe)
- Eigenes Device im Flash (nur eine kleine statische Mount-Sektion, ca 5 Zeilen in der debug.cfg)
- Auf Usb Stick (kurzes script in der debug.cfg, das einen cron job 5 Minuten in die crontab einträgt, den cron startet, settings dem Stick aufruft)

Damit ist eigentlich für jeden was dabei. Ach ja, wenn das mal als freetz Paket im svn ist, schmeisse ich den bootloader einfach weg und nutze die diff Dateien, es kann aber eng werden, da alle Settings von allen Paketen in nur 1 File gepresst werden.
 

Anhänge

  • settings.jpg
    settings.jpg
    26.7 KB · Aufrufe: 18
Zuletzt bearbeitet:
modsave hat Optionen. Vielleicht sollte man die nutzen...
 
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.