freetz-devel-5489: WebGUI weg, wenn per inet

ao

Aktives Mitglied
Mitglied seit
15 Aug 2005
Beiträge
2,158
Punkte für Reaktionen
2
Punkte
38
Hallo,

habe eben das Freetz WebGUI von automatisch auf inetd umgestellt. Danach ist das WebGUI nicht mehr erreichbar. Auf der Konsole sieht es so aus:
Code:
root@fb1 /etc/init.d $ ./rc.websrv
Usage: ./rc.websrv [start|stop|kill|restart|status|pid]
root@fb1 /etc/init.d $ ./rc.websrv status
stopped
root@fb1 /etc/init.d $ ./rc.websrv start
Starting websrv AVM web UI...httpd: bind: Address already in use
failed.
root@fb1 /etc/init.d $ ./rc.webcfg status
inetd
root@fb1 /etc/init.d $ ./rc.webcfg
Freetz webinterface is started via inetd.
root@fb1 /etc/init.d $ ./rc.webcfg ?
Usage: ./rc.webcfg [load|unload|start|stop|restart|status]
Wie kann ich das WebGUI von inetd wieder auf automatisch umstellen (über die Konsole, die ja funktioniert)?
Mit rc.webcfg und rc.websrv habe ich das nicht hinbekommen (s.o.).

EDIT:
Nach einem Reboot ist das WebGUI (webcfg) wieder da (immer noch mittels inetd gestartet).
Hatte sonst noch jemand dieses (vorübergehende) Problem?
 
Zuletzt bearbeitet:
Da scheint mir ein restart des Inetd zu fehlen. Das könnte auch auf andere Dienste zutreffen.

MfG Oliver
 
Ja, hatte ich auch. Zum Glück ist ssh per default gestartet, da ich telnetd auch auf inetd eingestellt hatte. (Nach nem Reboot alles OK)
 
Macht jemand ein Ticket dazu, oder gibt es noch etwas, das ich tun kann?

PS:
Das inet-Problem ist evtl. auch hierfür verantwortlich ("address already in use").
 
Zuletzt bearbeitet:
Nachdem cuma die ganzen Sachen streng auf modlibrc umgestellt hat gibt es an diversen Ecken Probleme mit inetd. Ob man sie alle jetzt ausmerzen sollte, weiß ich nicht. Denn ich hatte mal vor einigen Monaten eine andere "dynamische" Lösung für inetd vorgeschlagen gehabt. Leider passierte es noch vor der großen Veränderung an der modlibrc, sodass meine damaligen Ideen heutzutage viel Anpassung bedürfen. Und dafür fehlt mir momentan leider Zeit. Bei meiner Implementierung würde z.B. erstmal generell geschaut, ob der Port frei ist und nach Möglichkeit eine passende Meldung herausgegeben, von welchem binary dieser Port belegt ist.
Momentan sind diese Ideen in dem AVM-ftpd realisiert und sollten langfristig nach modlibrc wandern, wenn ich denn endlich Zeit dafür finde.

MfG
 
Da scheint mir ein restart des Inetd zu fehlen. Das könnte auch auf andere Dienste zutreffen.
Stimmt, ich konnte das so reproduzieren. Immer, wenn ich rrdstats und digitemp auf inetd umstelle, muss ich anschließend inetd manuell restarten.
Eben wieder beim Versuch, rrdstats und digitemp von inetd auf automatisch umzustellen (mit frischer freetz-devel-5504 FW nach Reboot):
Code:
Stopping rrdstats...done.

Saving settings...done.
Saving rrdstats.cfg...done.

httpd: bind: Address already in use
Starting rrdstats...done.

Writing /var/flash/freetz...done.
43008 bytes written.
D.h., ich bekomme sogar nach einem neuen FW-Flash und Reboot rrdstats und digitemp (bzw. deren WebGUIs) nicht mehr zum Laufen).

Hat jemand eine Idee, wie ich das wieder zum Laufen bekomme? Danke!
 
Zuletzt bearbeitet:
Gibt es dazu eigentlich schon ein separates Ticket im trac? Und bitte nicht auf diese mittlerweile ziemlich ausgeblasene Geschichte vom "mehrfachen starten..." schieben. Ich würde vorschlagen diese inetd-restart-Problematik in einem separaten Ticket zu behandeln (falls es nicht bereits geschehen ist).

MfG
 
PS:
Auch mit anderen Paketen wie z.B. dropbear und wol, lässt sich das Problem mit inet nachvollziehen: Wenn man diese von inetd auf automatisch umstellt, failed der restart. Erst nach einem restart von inetd laufen dann die auf automatisch gesetzten Dienste. Ich verstehe zwar nicht, weshalb inetd einen Restart benötigt, damit eh auf automatisch gesetzte Dienste richtig starten, aber die Gurus hier kennen die Hintergründe wahrscheinlich. Wenn Ihr noch ein paar Tests meinerseits benötigt, sagt bitte Bescheid.

PPS:
Digitemp ist bei mir auch nach weiteren Verrenkungen (Neustarts diverser Dienste inkl. inetd und Umstellung auf automatisch) über Port 85 nicht erreichbar, d.h. wenn ich fritz.box:85 aufrufe, kommt stattdessen rrdstats, das aber auf Port 86 eingestellt ist.
Und jetzt der Knüller: Wenn ich digitemp auf Port 87 stelle und fritz.box:87 aufrufe, kommt das hier:
Fehler: Port aus Sicherheitsgründen blockiert
Die aufgerufene Adresse fordert einen Port, der normalerweise nicht zum Browsen im Web verwendet wird. Die Anfrage wurde zu Ihrem Schutz abgebrochen.
Das Problem besteht natürlich nicht, wenn ich den digitemp-Output über Status/ DigiTemp aufrufe, nur beim eigenen Fenster mit eigenem Port klappt es nicht.
Nebenbei ist da ein kleiner Typo (2x):
Webserver aktiveren auf Port
 
Ich denke, dass cuma in r5264 ein Fehler eingebaut hat. Der Rückgabewert 1 existiert für modlib_check_running nicht.

@Hermann
Ich hab da irgendwann mal eine "modlib_reload_inetd"-Funktion eingecheckt. Ich glaube die war aus einem deiner Patche. Gibts einen bestimmten Grund warum man da nicht die normale modlib_reload Funktion nutzen kann? Evtl. gab es die Funktion zu dem Zeitpunkt auch noch nicht.

MfG Oliver
 
Genau, und im Trac hatte ich zu dem Fix gefragt, ob der immer noch als temporär zu betrachten ist. Es war offenbar auch vsftpd betroffen.
 
@Oliver: modlib_reload_inetd ist noch zu dem Zeitpunkt entstanden, bevor cuma sich sich modlib vorgenommen hatte. Damals waren alle Funktionen in modlib (und darunter auch die modlib_reload) darauf ausgerichtet Operationen in einem konkreten Paket durchzuführen. Es lief so, dass am Anfang von modlib die Variablen zum jeweiligen Paket geladen wurden und die globalen Variablen (wie z.B. $DAEMON und ähnliches) wurden mit den paketspezifischen Informationen belegt. Nehmen wir als Beispiel vsftpd. Dann hieße z.B. $DAEMON=vsftpd.
modlib_reload_inetd war aber von mir noch zu diesen Anfangszeiten dazu angedacht inetd reloaden zu lassen, wenn sich etwas innerhalb des jeweiligen Paketes (z.B. vsftpd in unserem Beispiel) tut. Die Standardfunktion modlib_reload konnte/wollte ich dafür nicht nutzen, weil man sie ziemlich stark "umbiegen" müsste. So ist diese modlib_reload_inetd damals entstanden.
Es ist sicherlich möglich modlib_reload_inetd in die normale modlib_reload irgendwie integrieren zu lassen, man muss nur schauen, ob es denn Sinn macht.
Ich weiß auch leider nicht mehr, wo modlib_reload_inetd momentan benutzt wird. Bei meinen damaligen Experimenten war lediglich diese dynamische inetd-Geschichte betroffen. Und die wiederum war nur bei dem AVM-ftpd experimental realisiert.

Ich wollte mich gestern schon an den inetd ran machen, allerdings streikt meine Kompilierung von MC4.6.2, wie ihr mitbekommen habt. Und ohne MC auf der Box fühle ich mich bei solchen Experimenten auf der Box irgendwie so, als ob ich blind und taub durch den Wald irre. Deswegen steht bei mir zunächst MC auf dem Programm.

MfG
 
Ah, ja. Jetzt sehe ich was du meinst. Da rc.ftpd auch ohne das inetd-Package im Image sein kann muss auf Existenz der rc.inetd geprüft werden.

MfG Oliver
 
Ich habe an meiner erweiterten modlibrc weiter gebastelt. Jetzt habe ich eine bei mir halbwegs funktionierende Version mit erweiterten Rückgaben, wie ich es vorher schon mal hatte. Ich würde es aber gerne noch intern testen, bevor ich es poste. cuma hat da leider in modlibrc sehr viel geändert und mein Konzept passt da jetzt nicht mehr so glatt, wie es Ende Mai noch mit dem damaligen trunk-Status war. cuma hat wohl die gleichen Probleme entdeckt, die ich damals in meiner erweiterten Version bereits zum Teil realisiert hatte, und auf seine Art gelöst. Leider sind unsere Denkweisen und Vorlieben zur Benennung der Variablen etwas unterschiedlich, sodass ich noch Einiges gerne anpassen würde. Gebt mir bitte noch etwas Zeit dafür.
Ich hatte dennoch in meinem Anpassungstrieb einige Fehler von cuma entdeckt, die ich gerne schon jetzt posten würde, damit jemand von den devs sie vielleicht schon jetzt einpflegt. Es geht -wie Oliver bereits richtig gemerkt hat- um modlib_reload:
Code:
# modlib_reload
#   reloads the daemon with SIGHUP
#   if available runs "config" of rc.$DAEMON
#	reloads daemon with "reload" of rc.$DAEMON if available
modlib_reload()
{
	local fn=$PID_FILE
	echo -n "Reloading ${DAEMON_LONG_NAME} ... "
	modlib_check_running
	case $? in
		[COLOR="Red"][B]1[/B][/COLOR])[COLOR="DarkGreen"][B] # hier sollte 0 stehen[/B][/COLOR]
			config

			reload 1
			local status=$?
			if [ $status -ne 127 ]; then
				sleep 1
			else
				kill -HUP $(cat "$fn") 2> /dev/null
				local status=$?
			fi

			if [ $status -eq 0 ]; then
				echo 'done.'
				return 0
			else
				rm -f "$fn"
				echo 'failed.'
				return 1
			fi
			;;
		3)
			echo 'not running.'
			return 0
			;;
		5)
			config
			reload 5
			[ $? -eq 127 ] && killall -HUP $DAEMON_BIN 2>/dev/null 1>&2
			echo 'inetd.'
			return 0
			;;
		esac
}
Wenn man in case-Wahl die nicht existierende 1 gegen 0 tauscht, dann dürfte es erstmal mit dem reloaden von inetd wieder laufen. Ich habe allerdings hier cuma nicht ganz verstanden, was er mit "reload 1" oder "reload 5" will und warum im Falle inetd (Status 5) Daemon-Binary geHUPt wird. Wenn man hier schon etwas HUPt dann inetd, sinnvolerweise. In meiner Variante hatte ich gerade an dieser Stelle die vorher diskutierte modlib_reload_inetd eingebaut.
Allerdings würde die reload-Funktion von inetd in meinem Fall nicht vernünftig funktionieren, denn ich rufe aus der internen "reload"-Funktion von inetd modlib_reload. Und dies ist nach der Umstellung von cuma fatal, weil es zur endlosen Schleife führt (modlib_reload->reload->modlib_reload...). Um auch dies sauber zu lösen, muss man die Funktion "reload" in rc.inetd löschen und deren Inhalt vorher nach reload)-Sektion im Haupt-case bringen.
Was cuma da mit diesen Rückgabewerten von 127 gedacht hat, wenn die Funktionen "start", "stop", "reload" nicht existieren, muss ich mir auch noch genau anschauen.

Aber wie gesagt, auf die Schnelle sollte erstmal reichen 1 gegen 0 zu tauschen.

MfG
 
Außer dass es zu der von dir besagten Endlosschleife führt behebt es den gefundenen Fehler. cuma hat da auch schon was fertig und wird es in den nächsten Stunden wahrscheinlich einchecken...

Die 127 dient zur Erkennung, ob die Funktion im rc-Skript überschrieben wurde oder nicht. Abhängig davon müssen unterschiedliche Befehle ausgeführt werden.

MfG Oliver
 
cuma hat da auch schon was fertig und wird es in den nächsten Stunden wahrscheinlich einchecken...

Das ist schlecht... Dann darf ich mit dem Abgleich meiner modlibrc und der von cuma geänderten wieder anfangen. Aber so ist das Leben eben. Bleibt nichts übrig, als auf die Änderungen von cuma zu warten. Ich muss ja sowieso meine Variablen auf den neusten Stand bringen und überlegen, wie ich es mit dem "dynamischen" inetd am besten realisiere. Bis jetzt war die Idee, dass die rc-Skripte an die modlibrc den Startstring sowohl für daemon-Modus als auch für inetd in Form eines Stringes (jeweils) in einer globalen Variable übergeben.

Und bevor ihr nachher wieder meckert, das meine Sachen zum erweiterten Status (Überwachung der Portbelegung, Meldungen etc.) das WebIF (status.cgi) ausbremsen will ich jetzt schon melden, dass die neuen Sachen von Andreas es anscheinend schon jetzt bei meiner 7170 sehr bemerkbar tun. Die status.cgi (und auch andere Sachen) brauchen auch ohne meinen erweiterten Status zum Teil mehrere Sekunden zum Laden. Deswegen betrachtet es bitte nachher nicht so kritisch und schreit nicht gleich rum: Der erweiterte Status bringt höchstens einige Millisekunden der Abbremsung bei. Und auch die kann man nachher durch Optimierung des Codes etwas schrumpfen. Der Gewinn wäre dagegen, dass man beim Starten/Stoppen der Dienste als Benutzer deutlich mehr mitbekommt und kann leichter Fehler verfolgen.

MfG
 
Ich nehme an, dass das mit dem Startstring so wie in der rc.ftpd laufen soll. Du willst also den gesamten inetd Modus umkrempeln? Momentan bringt ja jedes Paket eine $package.inetd mit und daraus wird die /etc/inetd.conf zusammengesetzt. Geht es nicht auch mit dem derzeitigen Modus?

Ich denke nicht, dass sich durch die Änderungen von Andreas die Ladezeiten der Seiten geändert haben. Die Erweiterungen an der modlibrc haben sicher die Ladezeit erhöht. Aber wenn der Aufwand zur korrekten Darstellung nötig ist, dann muss es halt sein. Wie kommst du auf die status.cgi? Die zeigt doch gar nicht mehr an als vorher? Das können doch nur die mountpoints sein? Oder meinst du die Seite mit den Diensten?

Außerdem meckert hier niemand!!! Ich hab bei der Erweiterung der modlibrc auch mit cuma diskutiert, ob man da noch was einsparen könnte. Doch wir hatten keine Idee.

MfG Oliver
 
Das jetzige Mechanismus vom inetd gefällt mir nicht, daher hatten wir damals hier diese "dynamische" Variante diskutiert. Seitens inetd sind alle notwendigen Änderungen doch bereits im trunk, sodass inetd in der jetzigen Variante (bis auf diese reload-Schleife, die noch korrigiert werden sollte) sowohl die alte Methode beherrscht, als auch die neue kann und zusätzlich noch die AVM-Sachen abarbeiten könnte, wenn man sich darum kümmert. Für ftpd hatten wir es auch getan.
Der jetzige Status von rc.ftpd ist so, dass die ganzen Sachen zu diesem "dynamischen" inetd noch direkt in rc.ftpd stehen und nicht in modlibrc. Meine Idee ist sie nach modlibrc zu portieren und somit auch anderen Paketen ermöglichen neue inetd-Methode zu verwenden.
In der neuen Methode will ich nicht mehr mehrere Dateien mit für inetd-Behandlung pro Paket haben und sie von inetd mühsam "einzusammeln", wie es jetzt der Fall ist, sondern alle Startoptionen (und auch für inetd-Modus) in den rc.-Skripten speichern. Sie sind jetzt dank Bemühungen von cuma deutlich schlanker und übersichtlicher geworden und würden dies vertragen. Die dynamischen $package.inetd-Dateien werden dann nach Bedarf von rc-Skripten angelegt. Durch das reload und HUPen von inetd wird bewirkt, dass daraus eine aktualisierte inetd.conf entsteht. Der Unterschied zu vorher besteht darin, dass alle $package.conf in einem Verzeichnis liegen und es deutlich schneller als jetzt geht sie "einzusammeln". Auch separate "Eintragungen" und "Austragungen" in/von inetd.conf sind somit möglich (separates starten/stoppen der per inetd-laufenden Pakete).


Edit: Wie ich gerade sehe, wird meine Idee vom dynamsichen inetd sowieso begraben. Dann erkläre ich das Projekt "dynamisches inetd" somit als beendet.

MfG
 
Zuletzt bearbeitet:
Falls die Änderungen der letzten Tage nicht mit deiner Idee vereinbar sind, dann tut es mir leid. Ich hatte dann wohl nicht verstanden was du mit dem "dynamischen inetd" vorhast. Deine Änderungen waren für mich sehr schwer verständlich, so dass ich es daraus auch nicht erkennen konnte. Sorry...

MfG Oliver
 
So ist das Leben eben, Oliver.
cuma fällt da jetzt mit seinen Änderungen genau deswegen auf die Nase, weil er die alte Methode bevorzugt. Das Ganze "mal in Flash speichern" oder "mal eben nicht" und die ganzen "start-force" und Co. könnte man vermeiden, wenn ihr dem befolgt hätte, was wir mit Ralf hier schon vor einiger Zeit ausgiebig diskutiert hatten und was in rc.ftpd testweise und erfolgreich bereits implementiert war, nämlich die neue dynamische Methode für die Behandlung von Paketen mit inetd.
Außerdem hatte ich deutlich aussagekräftigere Fehlermeldungen und erweiterte Statusmeldungen beim start/stop für modlibrc vorgeschlagen, die z.B. beim Lösen von solchen Problemen wie hier von ao (und nicht nur) ziemlich hilfreich wären. Diese Vorschläge waren aber euch zu kompliziert und versanken vor einigen Monaten in den Tiefen der Trac-Tickets.
Ich hatte mich zum Thema inetd und modlibrc vor ein Paar Tagen im Trac gemeldet und gesagt, dass ich noch 2-3 Wochen brauche. In #13 hier hatte ich sogar gemeldet, dass ich mit meiner ersten Testversion fast fertig bin, woraus man vermuten könnte, dass ich in den nächsten Tagen hier bestimmt etwas poste.
Jetzt nachdem meine Grundsätze und Ideen aus der modlibrc rausgeflogen sind, habe ich keine Lust mehr hinter euch her zu laufen und meine Änderungen ständig anzupassen. Von daher bleibt uns allen nichts anderes übrig, als sich mit modlibrc/inetd-Version von cuma abzufinden.

MfG
 
Hi Hermann, Hi cuma
selbst ich als nicht-coder hab das die letzte Zeit bemerkt das ihr das "grundsätzlich" selbe Thema parallel angeht und versucht zu lösen. Auch wenn ich ich davon letztendlich nicht viel von verstehe, also von den backgrounds, ist deine Version für mich die einfachere und plausiblere.... ist aber auch zu 70% nur Intuition :)
Was ich nicht verstehe ist, warum setzt ihr euch nicht mal (privat oder online) zusammen und diskutiert das mal aus. Es bringt ja NIEMANDEN weiter wenn der eine was entwickelt und der andere was "drüber-ckeckt" Findet doch mal ne Basis... wegen mir macht ne Umfrage (auf die Devs baschränkt) was wo wieweit inwiefern weshalb besser ist oder nicht.

Alles andere is für das Gesamt-Projekt sicherlich kontraproduktiv.

Just my 2 cent :)
 
Zuletzt bearbeitet von einem Moderator:
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.