debug.cfg verschwindet

[voipd]

So nun muss ich wohl auf die Final und habe auch das Problem vor der Brust: :-(

1. Wird die /var/callog bei jedem Anruf ausgefuehrt?

2. Kann mir jemand helfen wie ich mein OpenVPN vom USB-Stick gestartet bekomme?

Ich dachte an "if not openvpn running, dann starte openvpn; else do nothing"
Kann mir das jemand in FritzBox Shell Systax uebersetzen?

Danke

voipd.

 

[koyaanisqatsi]

zu 1.) Ja

zu 2.) Hier findest du ein simples Beispiel, es wird mit ps|grep nach dem Prozess gesucht, wenn nicht da dann wird er gestartet.
Wenn da, dann nicht.

Tip: Einfach zum testen mit Mobile anrufen.
Auch geht z.B.: sh /var/calllog
Aber anrufen macht mehr Spaß.

 

[voipd]

Danke fuer die Info. Hatte den anderen Beitrag schon gesehen aber nicht verstanden, dass hier per Scriptbefehle erst die "calllog" gefuellt wird.
Komme aber im Prinzip klar. Ich muss es remote machen und hoffen, dass da nichts schief geht. Habe nur einen Versuch. :silly:


voipd.

 

[navigatorXL]

Apache@FritzBox

Ha so jetzt läufts .... Ich hab mir noch mal die Version hier runtergeladen **apache-2.2.17_php-5.4.3_mips_static** und damit läufts :-D .... Und komischerweise im positiven natürlich auch nach einem neustart meine debug.cfg bleibt erhalten.

Ich hatte das selbe Problem:
Auf meiner FritzBox 7390 ist der Apache 1.3.42 (mips-Version apache-1.3.42_php-5.5.6_mips.tar von http://www.fritzmod.net/de/modification/apache/installation/) nicht gestartet:
Die Kommandozeile wurde ohne Murren akzeptiert. Allerdings lief der Apache danach nicht.

Das Apache-log "/apache/logs/apache-log" hat mir verraten, das er eine Datei vermisst: mime.type
Nachdem ich eine leere Datei im geforderten Pfad erzeugt habe, lief der Apache los.

Der Apache 2.2.17 lief auf Anhieb.
Allerdings hat der, wie MacNobi richtig gesagt hat, trotz der höheren Versions-Nummer KEIN SSL-Modul integriert.
Damit ist also kein Fernzugriff über https möglich.


Viel Erfolg,

nXL

 

[koyaanisqatsi]

mime.types

Moin

Komisch, denn die sind sehr wichtig.
Kann denn dein Apache irgendetwas ordentlich ausliefern, mit einer leeren mime.types?

Für meinen busybox httpd mit php-cgi musste ich schon was von Hand nachtragen, damits zu meiner Zufriedenheit funktioniert.
httpd.conf (busybox httpd)

# mime-types
.xhtml:application/xhtml+xml            # xhtml ;-)
.xml:application/xml                    # extended markup language (XML)
.xsl:application/xml+xsl                # extended markup language (XML-Transformation)
.dtd:application/xml+dtd                # extended markup language (XML-DocTypeDefinition)
.svg:image/svg+xml                      # scalable vector graphic
.swf:application/x-shockwave-flash      # shockwave flash
.oga:audio/ogg
.wav:audio/wav
.ogv:video/ogg
.ogg:video/ogg
.mp4:video/mp4
.txt:text/plain
.cfg:text/plain
.conf:text/plain
.ini:text/plain
.log:text/plain
.cgi:text/plain
.sh:text/plain
# externals
*.php:/var/media/NEW_LINK/mips/php.sh   # run xxx.php through an interpreter

Melde denn Bug doch an Radislav auf fritzmod.net. Der freut sich über jede Fehlerkorrektur.

 

[radislav]

Morgen!

Ich lese schon mit

Ich verstehe das allerdings nicht ganz. Was darf ich denn nun genauer ändern?

 

[navigatorXL]

mime.types

Dank erstmal an radislav für die fritzmod-Seite!
Und an buffo1987 und MacNobi für das HowTo!

Mein Ziel ist, OwnCloud mit SSL auf die FritzBox zu bekommen und ich bin froh, das so vorgekaut zu bekommen von radislav und buffo/MacNobi! ;o)

Mit "...Apache läuft..." meine ich, dass die Prozesse auf der FritzBox laufen und der Startbildschirm vom Apache kommt.
Weiter bin ich gestern nicht gekommen.

Was mich wundert, ist dass außer mir und re1hro noch niemand darüber gestolpert ist, dass der Apache 1.3.42 Probleme macht.
M.E. ist das eine wichtige Variante!

@radislav
Wenn Du den Apache 1.3.42 von Deiner Seite in Ordnung bringen könntest, wäre das schick!
Wenn ich mit meiner FritzBox 7390 helfen kann, dann gerne (lt. Signatur hast Du keine).

Viele Grüße,
nXL

 

[radislav]

Ich habe mal apache v2.4.6 für mips und mipsel kompiliert: https://www.fritzmod.net/modification/apache/installation/ Leider habe ich momentan keine Möglichkeit, sie zu testen. Bitte also um Feedback.

@navigatorXL: Vielleicht kannst du ja eine davon testen. Apache 1.xx kann ich leider nicht mit SSL kompilieren :?

p.s. wir sind ja vom eigentlichen Thema komplett auf apache umgestiegen... Vielleicht sollten wir den Thread ändern oder einen neuen öffnen.

 

[navigatorXL]

Danke!

Den Apachen teste ich heute abend.
Da ich aber keinen Plan von Servern habe, kann ich nur bewerten:
- ob der Prozess läuft
- ob die Startseite kommt
- was die logs sagen
Hast Du irgendwelche Funktionen, Skripte, Spyware, die ich mittesten soll? ;o)


Ja, wir sind off-topic.

Das Thema "Apache goes FritzBox" ist unter den beiden links aus meinem letzten Post schon hinlänglich diskutiert worden.
Ich würde das erstmal per PN klären.
Das Ergebis sollte dann hier rein und auch in den "OwnCloud@FritzBox" thread.
Ggf. bohre ich Deine Anleitung noch etwas auf.

nXL

 

[Joe82]

Hallo,

auch bei mir hat nun die Wende einzug gehalten. Ich habe mir eine Synology DS414 gekauft und alle Modifikationen darauf umziehen lassen. Trotzdem bleibt meine 7390 noch einige Zeit mit der 6.03 in Betrieb. Aber damit hat sich AVM zumindest für mich erstmal erledigt. Natürlich habe ich das auch so bei AVM gemeldet.

LG

 

[scraemgo]

Hatte den Vorschlag Anfang Mai schon an anderer Stelle gelesen, statt der nicht mehr verfügbaren debug.cfg die calllog zu verwenden, die bei jedem eingehenden Anruf aufgerufen wird. Heute bin ich dazu gekommen, das zu testen - geht prima.
So ist die Einrichtung der Datei calllog in der Telnet-Sitzung vorzunehmen:
echo "blabla" > /var/flash/calllog # initiale Bereitstellung der calllog auf der FRITZ!Box (FB)
nvi /var/flash/calllog

Im nvi dann ungefähr diesen Inhalt für calllog einfügen:
ps > /var/tmp/ps.dmp
cat /var/tmp/ps.dmp | if (! grep -q TEILSTRING_PROZESSNAME) then (/VOLLERPFAD/SHELLDATEI) fi
(für vi bzw. nvi Dummies: Nach Aufruf des nvi zunächst zweimal Taste d drücken (um die Zeile mit blabla zu löschen), Taste i (=insert) drücken, dann den vorbereiteten Inhalt für die calllog mit STRG Einfg einfügen, dann nacheinander die Tasten ESC : w q drücken. {das war jetzt die vi-Bedienung im Kern auf zwei Zeilen })
Oben ist einzusetzen:
TEILSTRING_PROZESSNAME : das, was man mit dem Befehl ps von dem Programm sieht, was immer in der FB laufen soll,
in meinem Fall der thttpd
/VOLLERPFAD/SHELLDATEI : In der Regel /var/media/ftp/USBSTICKNAME-01/Name_der_Shelldatei
in meinem Fall startthttpd.sh
Die Funktionsweise der calllog:
Es wird ein Dump der Prozessauflistung (ps) in ps.dmp zwischengespeichert (dieser Zwischenschrift IST NOTWENDIG, sonst grept sich das grep selbst als laufenden Prozess), dann wird ps.dmp daraufhin untersucht, ob TEILSTRING_PROZESSNAME nicht (!) darin enthalten ist. Trifft dies zu, muss die gewünschte Shelldatei aufgerufen werden, andernfalls läuft der gewünschte Prozess schon.
Nun wird natürlich die calllog nicht automatisch nach dem Hochfahren der Fritz!Box aufgerufen, aber bei JEDEM Anruf. Will man also seinen Prozess gestartet haben, ruft man einfach einmal seine FB bzw. Telefonnummer an, und schon geht's los. Bei folgenden Anrufen wird der gewünschte Prozess aber nicht erneut gestartet.
Gerade vor zehn Minuten mit einem Reboot meiner FB getestet, alles paletti!
Have fun without debug.cfg !
SEB

Ich wollte diese Möglichkeit bei meiner 7270v2 mit Fritz!OS 6.05 auch nutzen. Bei der ersten Einrichtung hat auch alles super geklappt.
Nur nach einem Neustart leider nicht. Habe gesehen, dass die "calllog" nach einem Neustart wieder leer war. Wo könnte das Problem sein?

 

[koyaanisqatsi]

Meiner Erfahrung nach....

Hast du es schlicht nicht richtig gemacht.
Die Dateien in /var/flash sind durchweg Zeichenorientierte Gerätedateien.
Die dürfen nicht wie eine normale Datei behandelt werden.
Tabu sind, besonders für Newbies: vi cp rm
Richtig wären: nvi cat echo

Du hast mit an Sicherheit grenzender Wahrscheinlichkeit die Zeichenorientierte Gerätedatei zerstört.
Nach einem Neustart wird sie aber wieder neu angelegt, deine Datei ist schon nach dem Neustart verschwunden.

Für die Prüfung und gegebenenfalls Neuerstellung sind diese zwei Dateien verantwortlich, die bei Systemstart ausgeführt werden:
/etc/init.d/S08-tffs
/etc/init.d/S12-default

 

[scraemgo]

Ich habe die Datei wie im Zitat befüllt.

Habe mittlerweile aber auch noch eine Änderung an der "ar7.cfg" mit nvi durchgeführt. Die Änderung ist ebenso nach dem Neustart verschwunden. Ich habe es aber 100% richtig gemacht, da ich ich diese Datei schon öfter bearbeitet habe und bisher immer alles geklappt hat. Erst seit Version 6.05 gibt es Probleme. Auch interessant: Die "ar7.cfg" verliert erst nach dem Neustart die Änderungen. Mit einem ar7cfgchanged werden die Änderungen übernommen und sind auch aktiv.

 

[koyaanisqatsi]

ls -la /var/flash/calllog
[color="red"][b]c[/b][/color]rw-r--r--    1 root     root      243, 141 Jan  1  1970 /var/flash/calllog

1. Dann öffne mal eine telnet Konsole zur Fritz!Box.
2. Kommando absetzen: echo 'echo $@' > /var/flash/calllog
3. Ruf dich mit Mobile an und guck auf die Konsole.
4. Jetzt Box neustarten.
5. Schritte 1. und 3. ausführen, nicht 2..
Ist sie immer noch leer?

 

[PeterPawn]

Ich habe die Datei wie im Zitat befüllt.

Dann einfach vor den zitierten Aktionen überprüfen, ob das char-Device für /var/flash/calllog überhaupt existiert ('ls -l /var/flash/calllog' muß in Spalte 1 ein 'c' enthalten).

Ansonsten wird durch das 'echo'-Kommando einfach ein "regular file" mit dem Namen angelegt, das Du dann hinterher mit 'nvi' editierst. 'nvi' macht auch nichts anderes, als den alten Inhalt per zeichenorientiertem 'cat' in eine temporäre Datei zu kopieren, dann den 'vi' aufzurufen und nach dessen Ende (und zwar unabhängig davon, ob die Datei überhaupt geändert wurde) die temporäre Datei einfach per 'cat' wieder zurückzuschreiben.

Insofern kann man nicht oft genug darauf hinweisen, daß man 'nvi' wirklich nur für Änderungen an Konfigurationsdateien und nicht für simples Anzeigen (weil es mit dem 'vi' so viel bequemer mit dem seitenweisen Blättern ist und man mal gelesen hat, man soll für die Dateien in /var/flash immer 'nvi' anstelle von 'vi' benutzen) verwenden sollte, da man damit dann wirklich vollkommen unnötige Schreibzugriffe auf das TFFS auslöst. Selbst wenn man den von 'nvi' aufgerufenen 'vi' mit ':q' ohne Schreiben der Datei oder mit ':q!' beendet, wird die (unveränderte) Datei trotzdem wieder in das char-Device zurückkopiert.

Die "ar7.cfg" verliert erst nach dem Neustart die Änderungen. Mit einem ar7cfgchanged werden die Änderungen übernommen und sind auch aktiv.

Eine zentrale Komponente der AVM-Firmware (ctlmgr) liest die Konfigurationsdaten ein und dient dann so ziemlich allen anderen Komponenten als "Proxy" beim Zugriff auf Konfigurationseinstellungen. Wenn man jetzt die gespeicherten Einstellungen per Editor ändert, ohne daß der ctlmgr davon Kenntnis erhält, passiert folgendes:

1. Manuelle Änderung
2. Eine beliebige Komponente ändert eine Einstellung über den ctlmgr, der nimmt die Änderung erst einmal nur an seinem internen Abbild vor.
3. Nun wartet der ctlmgr noch eine gewisse Zeit, ob weitere Änderungen folgen (damit werden die Schreibzugriffe auf den Flash auch verringert)... wenn nicht, wird die Datei aus seinem internen Abbild ihres Inhalts neu geschrieben.
4. Die manuelle Änderung ist wieder "verschwunden".

Ich habe zwar inzwischen gesehen, daß koy quasi Punkt 1 durch Anweisungen schon schneller abgehandelt hat (ich hatte noch einen Anruf zwischendrin), ich lasse meine Bemerkungen zum 'nvi' aber trotzdem stehen, wenn ich jetzt auf "Antworten" drücke.

 

[scraemgo]

Danke euch beiden! Ich werde heute Abend alles testen und mich dann nochmal melden.

 

[scraemgo]

ls -la /var/flash/calllog
[color="red"][b]c[/b][/color]rw-r--r--    1 root     root      243, 141 Jan  1  1970 /var/flash/calllog

1. Dann öffne mal eine telnet Konsole zur Fritz!Box.
2. Kommando absetzen: echo 'echo $@' > /var/flash/calllog
3. Ruf dich mit Mobile an und guck auf die Konsole.
4. Jetzt Box neustarten.
5. Schritte 1. und 3. ausführen, nicht 2..
Ist sie immer noch leer?

Es funktioniert

Dank eurer Erklärungen bin ich auch auf den Fehler gekommen. Ich habe die originale calllog nicht via echo bzw. nvi befüllt, sondern am PC erstellt und per FTP auf den USB-Stick geladen. Von dort habe ich dann die /var/flash/calllog mit der calllog vom USB-Stick überschrieben. Das war dann schon der Fehler. Also bin ich doch ein Noob

Und das Problem mit der ar7.cfg hat PeterPawn super erklärt. Da hatte ich wohl bisher immer Glück und heute hats mich erwischt.

 

[koyaanisqatsi]

Noob

Nein, bist du nicht.
Ein Noob ist nicht willens etwas dazuzulernen.

Deswegen bevorzuge ich die Bezeichnung: Newbie

Du hast deinen Fehler erkannt und dazugelernt.
Woher solltest du wissen was Zeichenorientierte Gerätedateien sind?

 

[scraemgo]

Naja ich habe bereits 2010 dropbear auf meiner Fritz!Box als SSH Server eingerichtet. Daher hätte ich das innerhalb von vier Jahren schon lernen können ;-)

Trotzdem danke, dass ihr so eine ausführliche Erklärung geliefert habt. Oft liest man ja nur: "Nutze die Suchfunktion" oder "das wurde hier im Forum schon 100mal erwähnt".

 

[kmeleon]

Hat hier jemand apache2 auf seiner Fritzbox mit aktuellster Firmware am Laufen? Hintergrund:

Ich benutze subversion in Verbindung mit dem apache2 und habe mir ein eigenes Startskript gebastelt. Seit einem Jahr funktionierte es ohne Probleme. Nun wollte ich ein bisschen mehr RAM in der Fritzbox haben und habe mir Ende Juli 2014 eine 7490 (Firmware: 6.05 vom März glaube ich) gekauft. Also apache2 und subversion für die 7490 neu kompiliert, installiert und es lief sofort. Seltsamerweise musste ich den sleep-Command auf 30s setzen, damit das Skript ausgeführt wird. Aber es lief alles wunderbar: apache2 und Subversion waren von außerhalb und im Home-Netz ohne Probleme zugänglich. Letzte Woche habe ich dann den "Fehler" gemacht, auf die neue Firmware zu updaten und mein Startskript wurde nicht mehr ausgeführt. OK, nicht schön, aber ich kann damit leben. Starte ich das Skript von Hand, dann wird subversion und apache2 auch wieder gestartet, aber leider reagiert der apache2 nicht mehr auf den bisher bekannten Port. apache2.conf habe ich natürlich nicht geändert. Stattdessen öffnet sich (zumindest innerhalb des Home-Netzes) die normale fritz.box-Seite zum Anmelden (auf Port 80). Wenn ich den "fritz.box:85" öffne (der in apache2 konfiguriert ist), dann wird die Seite nicht geöffnet. Der apache2-Task läuft aber (über ps zu sehen). Im apache-Log sehe ich keine Hinweise, die mir sagen, dass irgend etwas nicht stimmt. subversion funktioniert intern ohne Probleme und reagiert auf den Standard-Port.

Hat jemand zufällig ähnliche Probleme? Kann es sein, dass die Fritzbox mit der aktuellen Firmware irgendwelche Ports gar nicht mehr zulässt/sperrt?

Danke Euch und viele Grüße