[Frage]Fritzbox: crontab startet skript nicht richtig - was ist falsch?

phreichmuth

Neuer User
Mitglied seit
16 Mrz 2014
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Ich habe auf meiner Fritzbox 7490 mit FW 113.06.20 mittels http://www.ip-phone-forum.de/showthread.php?t=273304 die debug.cfg wieder aktiviert und nutze cron und crontab gemäss https://www.fritzmod.net/modification/busybox/cron/, um ein paar Skripte regelmässig abzuarbeiten (um einen anderen dynDNS-Dienst zu nutzen, der über die normale FW nicht funktioniert, da die Authentifiaktionsmodi nicht kompatibel sind). Das automatische Ausführen der Skripte funktioniert aber anscheinend nicht.

Meine crontab-Datei sieht so aus:
Code:
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/tmp/var
MAILTO=""
HOME=/

# Hier auzuf?hrende Aufgaben eintragen

# SSH-Server starten
@reboot       sh /var/media/ftp/ssh/ssh-server.sh start

# Benutzerdefinierter DynDNS-Dienst updaten
*/5 * * * *   sh /var/media/ftp/dyndns/dyndns.sh
Der SSH-Server wird mit dem eingetragenen Skript korrekt gestartet und funktioniert, aber das zweite Skript wird nicht richtig ausgeführt. Ich bekommen zwar auf dem Terminal alle 5 Minuten, wie in crontab eingestellt, den Output:
Code:
Apr 26 19:45:01 crond[2468]: crond: USER root pid 2545 cmd sh /var/media/ftp/dyndns/dyndns.sh
Das Skript schreibt aber nichts in die Log-Datei, wird also nicht richtig ausgeführt. Wenn ich das Skript mit demselben Befehl "sh /var/media/ftp/dyndns/dyndns.sh" manuell starte, funktioniert es.

Wie muss die crontab-Datei genau aussehen, damit das Skript läuft?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
Sollte eigentlich keine Rolle spielen, aber ich rate mal, daß es kein Verzeichnis "/tmp/var" gibt, wie Du in Deinem PATH angibst.

Das sollte aber tatsächlich nicht das Problem sein. Setze doch einfach mal ein SheBang mit "#! /bin/sh -x" in Dein Skript ein und laß Dir die Mail mit der Ausgabe zuschicken (wenn das bei der binär eingesammelten Busybox überhaupt klappt, stimmt da überhaupt die Version der stdlib oder ist die statisch gelinkt oder wie sieht das aus?) oder lasse Dir sowohl stderr (da landet die debug-Ausgabe der ash) und stdout in ein File schreiben durch Umleitung in der crontab.

Ich würde aber ohnehin eine BB 1.23.2 mit Freetz bauen, dann kann man auch gleich das auswählen, was man tatsächlich braucht ... ich weiß ja nicht, mit welchen Einstellungen die bei fritzmod.net kompiliert wurde.

Wenn das Skript erst irgendwann im Laufe seiner Verarbeitung etwas in irgendeine Datei schreibt und wegen der abweichenden Umgebung (es gibt z.B. kein Terminal) vorher abbricht, wirst Du mit Deinem Log-File nur wenig Erfolg haben ... deshalb die debug-Ausgabe der Shell, da siehst Du wenigstens, wo abgebrochen wird. Die Alternative der Angabe von "sh -x script >output 2>&1" in der crontab anstelle einer Änderung des SheBang will ich auch nicht unerwähnt lassen.
 

phreichmuth

Neuer User
Mitglied seit
16 Mrz 2014
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Freetz möchte ich eigentlich nicht installieren, finde ich ein bisschen Overkill für meinen Bedarf. Die beiden Skripte für den SSH-Server und Crontab ist eigentlich alles, was ich brauche. Ausserdem habe ich gelesen, dass mit Freetz elementare Funktionen wie Telefonieren Probleme machen kann.

Was ich nicht verstehe, das Skript für den SSH-Server wird ausgeführt, dyndns.sh nicht. direkt in der shell aufgerufen funktionieren beide korrekt.

Das dyndns-Skript schreibt Daten in eine Datei, wird aber leidernicht gemacht. Hab auch versuch, einen Eintrag in eine Datei gleich als erste Zeile einzutragen. Wird auch nicht gemacht.
Werde wohl mal versuchen, das Skript ebenfalls bein Starten ausführen zu lassen. Wenn das funktioniert, dann muss es an der Zeitkonfiguration von crontab liegen.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
Du verwechselst (wie viele, weil es eben alles wie ein großes Paket aussieht) die Build-Umgebung von Freetz (also alles, was man zum Cross-Compiling für die 7490 braucht) mit dem "Freetz-Mod" für das Firmware-Image. Das sind aber zwei verschiedene Paar Schuhe, ich habe auch ausschließlich meine eigenen Erweiterungen auf meinen Boxen (und denen von Kunden) in Benutzung.

Trotzdem muß man ja irgendwo auch mal Binärdateien generieren können und genau dafür kann/soll/muß man dann wieder Freetz benutzen, wenn man nicht selbst eine buildroot-Umgebung aufsetzen will. Das macht aber nur dann Sinn, wenn man wirklich vom Rest der Welt unabhängig sein will ... ein paar Einstellungen bei Freetz richtig gesetzt (z.B. das Lib-Verzeichnis nicht nach /usr/lib/freetz, was ich hasse) und man kann die Umgebung wunderbar auch für eigene Programme nutzen, die dann auch von der Laufzeitumgebung von Freetz vollkommen unabhängig sind.

Etwas anderes sind die Pakete auf fritzmod am Ende auch nicht, nur daß man wirklich seine eigenen Pakete übersetzt und somit auch weiß, was man da erhält - wenn man gleich beim Build einige Sachen so einstellt, wie man es gerne hätte, funktionieren viele Pakete mit ihrem modifizierten Standardeinstellungen sogar ohne Konfigurationsorgien zur Laufzeit ... eben weil alles schon beim Build konfiguriert wurde.

EDIT:
Ich habe mal vor Urzeiten auch auf dieser Grundlage irgendwelche Dienste gestartet, bis ich dann auf die Service-Funktionen der Busybox umgeschwenkt bin. Ich hänge mal ein (altes) Helper-Skript aus dieser Zeit hier an (die txt-Extension dient nur dazu, daß die Forensoftware nicht mault), in dem unter anderem auch ein paar Funktionen zur Verwaltung von crontab-basierten "Services" enthalten sind. Die habe ich dann eingesetzt, wenn ich keine langen "sleep"-Schleifen wollte, um die Prozessliste klein zu halten. Funktionieren sollten sie eigentlich alle, vielleicht helfen ja einige als Anregung. Wenn es irgendwo klemmt (ist eben seit fast 2 Jahren nicht mehr im Einsatz bei mir), muß man halt suchen ...
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Urgestein
Mitglied seit
29 Sep 2009
Beiträge
10,034
Punkte für Reaktionen
681
Punkte
113

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
13,069
Punkte für Reaktionen
405
Punkte
83
Moins

Die crontab sieht (bis auf /tmp/var) eigentlich OK aus.

(Glaskugeldreh)
...vielleicht ist es noch simpler...
wiki.ubuntuusers.de/Cron schrieb:
Wichtig ist, dass am Ende der Tabelle ein Kommentar oder eine Leerzeile stehen. Ähnlich wie die fstab muss die crontab mit einer Leerzeile enden!
Quelle
...

Mein Tip fürs SHEBANG: Einfach env benutzen, der findet schon den Interpreter.

Skript
Code:
#!env sh
echo -n 'Hello '$USER
echo $(date) > /dev/pts/0
#EOF
crontab
Code:
* * * * * env sh /tmp/test.sh
#EOF
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
Leerzeile am Ende:
Das sollte eigentlich beim Busybox-crond keine Rolle spielen. Der liest mit "libbb/parse_config.c -> config_read()" aus der crontab, was nach einigen Schritten dann beim "getline" der µClibc landet und das arbeitet auch korrekt, wenn die letzte Zeile im Stream nicht mit einem Newline endet. Die Aussage im Wiki gilt eher für den bei Ubuntu normalerweise verwendeten Daemon, nicht für die Busybox ... einfach mal ausprobieren.

Und das "env sh" sollte man auch gleich durch ein "sh" ersetzen können (dann geht die Suche eben wieder über die PATH-Variable), wenn man nicht noch irgendwelche Sachen im Environment parallel verändern will:
Code:
        if (argv[0]) {
                BB_EXECVP_or_die(argv);
        }
(aus Busybox 1.23.2, coreutils/env.c)

Es wird - nach Verarbeitung der hier ja nicht genutzten Optionen - ganz simpel der Rest der Zeile an "execvp" übergeben, der "Umweg" über "env" bringt also im Endeffekt tatsächlich nichts als einen weiteren (unnötigen) Programmaufruf. Die Suche läuft genauso ab, wie ohne "env" ...

Embedded ist eben immer noch ein klein wenig anders, als "normales" Linux ... macht nicht in jedem Falle einen entscheidenden Unterschied, kann aber auch mal zur Falle werden, weil bei Embedded-Systems eben gerne mal - wie bei AVM auch - alles in einem privilegierten Kontext läuft und schon kleine Fehler die Sicherheit komplett in die Tonne treten können.

Sorry für den Zeigefinger ... wollte den Unterschied "Linux <-> Embedded Linux" (in erster Linie allerdings bei den eingesetzten Tools auf "kleinen" Systemen) einfach noch einmal loswerden oder betonen.

@phreichmuth:
Der crond startet ja nach den Angaben auf Deiner Console den Job, sogar die PID des gestarteten Jobs ist vorhanden, da wird also tatsächlich etwas geforkt und das Protokollieren erfolgt erst danach.

Bis dahin ist also alles erst einmal in Ordnung mit Deiner crontab und eine Suche davor macht nur bedingt Sinn.

Das Problem muß demnach irgendwo im Start des Skripts aus dem crond heraus liegen, da besteht offenbar ein Unterschied zu Deiner Shell-Session.

Wenn Du den Hinweis zur PATH-Variablen umgesetzt hast und es immer noch nicht funktioniert, wäre vielleicht mal das auszuführende Skript eine echte Hilfe beim Erraten der Ursache ... den Hinweis zum Debuggen mit "-x" hast Du ja vielleicht nur überlesen oder nicht verstanden, ansonsten müßtest Du ja irgendeine Ausgabe erhalten haben, die Du mit uns teilen könntest.

Letzter Hinweis: Wenn Du die MAILTO-Variable nicht brauchst, kannst Du sie problemlos auch weglassen, dann läuft man keine Gefahr, sich mit dem leeren Parameter Probleme einzuhandeln (s. Busybox, miscutils/crond.c). Das gilt für die Standard-Einstellungen (SHELL und HOME) genauso ... ist alles Ballast, den es eigentlich nicht braucht. Wenn Du nicht tatsächlich irgendwelche zusätzlichen ausführbaren Files in /var/tmp (/tmp/var ist ja wahrscheinlich fehlerhaft) suchen lassen willst (gefährlich, da darf jeder schreiben ... aber bei Dir wird ja wenigstens - richtigerweise - erst dann dort gesucht, wenn vorher nichts gefunden wird), dann kannst Du die PATH-Angabe auch noch weglassen. Es ist - bis auf /tmp/var - nichts Falsches daran, aber zur Fehlersuche würde ich mögliche Quellen eben minimieren.

Die Bemerkung zur PATH-Variablen würde ich auch gerne noch etwas ergänzen: Es gibt bei der Busybox eine Option (CONFIG_FEATURE_PREFER_APPLETS), mit der zur Build-Time die Suchreihenfolge geändert werden kann ... deshalb sollte man als Verwender einer fremden Busybox schon wissen, wie diese generiert wurde. Wenn dieses Feature aktiviert ist, wird immer als erstes die Liste der in der Busybox enthaltenen Applets durchsucht. Damit ist es dann eben auch möglich, sagen wir mal das "rpm"-Applet aufzurufen, auch wenn für dieses kein Link auf das Busybox-Binary im Suchpfad existiert. Ist diese Option nicht gesetzt, wird der Pfad sofort durchsucht. An dieser Stelle kommt dann die Warnung vor ungültigen Annahmen ins Spiel ... wenn der Pfad - wie bei Dir - Verzeichnisse enthält, wo praktisch jeder Schreibzugriff hat und man Kommandos aufruft, deren Pfad nicht absolut angegeben ist bzw. man sich auf die Suche durch das System verläßt, dann würde eben bei einer Busybox mit CONFIG_FEATURE_PREFER_APPLETS=n eine ausführbare Datei in /var/tmp eher gefunden und aufgerufen, als ein in der Busybox enthaltenes Applet. Das muß nicht, kann aber, zu einem Einfallstor für einen Angreifer werden ... nach /var/tmp wird praktisch alles geschrieben. Das mit einem Aufruf von "tar" durch die Firmware verbunden (es gibt einige davon in der AVM-Firmware) und man kann mit hoher Wahrscheinlichkeit problemlos eine Datei in /var/tmp erzeugen, die dann auch noch "executable" ist - von der Möglichkeit des "normalen" Schreibens mit passender umask ganz zu schweigen. Wenn dieses Verzeichnis hingegen nicht im Pfad ist, vermeidet man zumindest die Probleme, die sich aus impliziten Aufrufen (also ohne absoluten Pfad zum Kommando) ergeben könnten. Wenn man unbedingt zur Laufzeit in einer FRITZ!Box ein beschreibbares Verzeichnis benötigt, das bei der Suche nach ausführbaren Dateien einbezogen wird, dann legt man sich ein solches gesondert an (meinetwegen /var/scripts oder /var/exec) und benutzt nicht das TMP-Verzeichnis.
 

phreichmuth

Neuer User
Mitglied seit
16 Mrz 2014
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
@PeterPawn:
Wie muss ich mir denn vorstellen, was Freetz genau ist? Ich dachte immer das ist eine aus der Quelle selber kompilierte Firmware für die Fritzbox.
 

phreichmuth

Neuer User
Mitglied seit
16 Mrz 2014
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Gelöst! Problem gefunden

Danke Leute! Dank euren Hinweisen und einer Log-Datei an einem Ort, wo sie nicht hin gehört, konnte ich das Problem lösen.

In meinem dyndsn.sh-Skript hatte ich natürlich auf Dateien in demselben Verzeichnis mittels ./<Dateiname> verwiesen. Crontab sucht dann aber in seinem Verzeichnis.
Habe nun am Anfang des Skripts mit
Code:
mypath="$(dirname "$(realpath "$0")")"
den Pfad des Skripts als Variable gespeichert und vor alle Dateien gesetzt. Jetzt schein es zu funktionieren, es tauchen jedenfalls Einträge in den richtigen Log-Dateien auf, was bedeutet, dass das Skript ausgeführt wird.

Sprich, cron und crontab von http://www.fritzmod.net/ funktioniert, wenn das auszuführende Skript richtig geschrieben ist.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
phreichmuth schrieb:
Ich dachte immer das ist eine aus der Quelle selber kompilierte Firmware für die Fritzbox.
Ja und nein.

Es ist einerseits eine Build-Umgebung für das Cross-Compiling mit verschiedenen FRITZ!Boxen als Zielplattform. Andererseits - das ist aber nicht zwingend zusammenhängend - ist es eine Paketverwaltung für zusätzliche Software, mit entsprechenden Anpassungen an eine FRITZ!Box. Und erst hier ist dann wieder ein einzelnes Paket "mod" (meinetwegen auch zwei, wenn man das CGI-Paket "mod-cgi" gesondert rechnet) für die Modifikationen auf dem Zielsystem verantwortlich, allerdings kann man diese(s) Paket(e) nicht abwählen und somit mit dem fertigen Image bei der von Dir gewünschten Vorgehensweise tatsächlich nichts anfangen.

Wenn man aber nur die Buildumgebung zur Übersetzung eigener Pakete benutzt, kann man diese problemlos (wenn die Libs passen oder passend erzeugt werden) direkt auf eine FRITZ!Box kopieren, etwas anderes machst Du mit der BB von fritzmod.net ja auch nicht. Nur kann man sie eben noch besser an die eigenen Wünsche anpassen ... wenn Du das System ohnehin mit "modfs" ändern läßt, kannst Du die fixen Teile auch gleich ins Root-FS einbauen lassen.

Für "modfs" habe ich - nur für mich selbst, das habe ich nicht in das Paket auf dem Server gepackt - noch ein zusätzliches "modscript" in Benutzung, mit folgendem Inhalt:
Code:
[email protected]:~ $ cat /var/media/ftp/modfs/modscripts/copy_binaries
# MODFS_MODSCRIPT
# SUPPORTS install
# NAME own files
# DESCRIPTION en
# add/replace some binaries at the target system
# DESCRIPTION de
# Programme hinzufügen/ersetzen
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ ${#4} -eq 0 ] && exit 59 # invalid call
# execute the requested step
#
rc=0
srcfile=files/binaries_7490.tgz
case $step in
        install)
                gunzip -c $srcfile | tar x -C $rootdir
                rc=0
                ;;
        *)
                rc=59
                ;;
esac
exit $rc
Ohne viel Federlesens wird da einfach das tar-File, welches im files-Unterverzeichnis liegen und "binaries_7490.tgz" heißen muß, in das neue Root-Filesystem entpackt, da braucht es keinen Schutz gegen doppelte Ausführung oder ähnliches, das kann zig mal laufen, immer mit demselben Ergebnis.

Man muß also nur vorher ein passendes tar-File (Busybox-tar verwenden, das Format des GNU-tar versteht die Box nicht) mit den zusätzlichen Programmen für die 7490 zusammenpacken, dann braucht man auch das NAND-Filesystem unter /var/media/ftp nicht wirklich, weil man die benötigten Programme (bei der 7490 sind 16 zusätzliche MB immer noch kein Problem, man darf es nur nicht allzusehr übertreiben, durch das Wrapper-FS stimmen die Dateisystem-Größen für die Freetz-Warnung nicht richtig) gleich direkt mit in das Root-Filesystem packen kann. Das hat auch noch den Vorteil, daß die - in Grenzen - nicht modifiziert werden können, ist eben r/o. Auch alles andere, was man sonst noch so brauchen könnte (von Symlinks von /etc/ssh nach /var/ssh bis zum Zertifikat der eigenen Root-CA), kann man dann direkt mit in das Root-FS aufnehmen.

Ich will bloß keine weiteren Binärpakete "anbieten", denn nach meiner Überzeugung soll sich jeder selbst seine Software direkt aus den Quellen übersetzen (oder einen Build-Service im Netz nutzen), dann kann man ihm auch nur schwer irgendwelchen Quatsch in Binärform als Angriff unterjubeln. Aber es wäre theoretisch (und praktisch) auch kein Problem, eine kleine Anleitung zur Integration des dropbear-Servers direkt in die Firmware mithilfe eines passenden "modscript"-Files zu erstellen. Nur muß eben (noch) jeder selbst sehen, wie er an die notwendigen Binaries - mit den passenden Einstellungen übersetzt - kommt. Wenn mir jemand einen Build-Service im Internet zeigt, der Pakete für MIPSEL32 übersetzt, baue ich glatt ein komplettes zusätzliches modscript für die Integration des SSH-Servers anstelle des Telnet-Dienstes in der Box ein. Es scheitert im Moment nur an Desinteresse meinerseits, mich selbst nach einem Build-Service (so a la OBS) umzutun, der auch noch eine passende Umgebung (buildroot + µClibc) bereit stellt. Wenn jemand das dropbear-Paket seinerseits schon als tar-Archiv für die 7490 hat, ist es ja nur ein Ersetzen des Symlinks in /usr/sbin/telnetd durch einen Verweis auf ein passendes Wrapper-Script (wegen der ggf. abweichenden Optionen zwischen telnetd und dropbear) und dann kann man einfach den SSH-Server anstelle des Telnet-Daemons vom AVM-Binary "telefon" starten lassen.
 
Zuletzt bearbeitet:

phreichmuth

Neuer User
Mitglied seit
16 Mrz 2014
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Jetzt stört nur noch der Output von crond auf dem ssh-Terminal jedesmal, wenn das Skript ausgeführt wird. Es erscheint immer die Zeile
Code:
Mon Apr 27 13:10:01 crond[1908]: crond: USER root pid 1966 cmd sh /var/media/ftp/dyndns/dyndns.sh
Das ist nicht der Output meines Skripts, sondern von crond, dass es ausgeführt wird.

Wie kann ich diesen Output unterdrücken?
Hab im Netz bis jetzt nichts gefunden, oder zumindest nichts, das ich verstanden und hätte umsetzten können.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
Ich schreibe mir zwar einen Wolf, aber das ist zu dem Thema erst mal der letzte Link/Beitrag und es gäbe tatsächlich eine Lösung:

http://freetz.org/changeset/12904

Keine Ahnung, ob die BB von fritzmod.net den Patch auch enthält, der ist zwar schon älter, ich weiß aber auch nicht mehr, wann ich den Thread dazu eröffnet habe ... in Freetz ist er erst seit Anfang des Jahres automatisch mit drin.

Die Umsetzung wäre wieder ganz einfach ... eine eigene Busybox mit Freetz bauen, der Patch wird im "make menuconfig" für die Busybox angeboten. Wenn Du das nicht willst, fehlt mir aber auch die Phantasie ... bliebe noch die Nachfrage bei fritzmod.net, vielleicht baut Dir der Autor dort ja Deine eigene.
 

phreichmuth

Neuer User
Mitglied seit
16 Mrz 2014
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
@PeterPawn:
Ja, hab gesehen, dass du enorm viel geschrieben hast. Vielen Dank dafür. Ich konnte ja nicht wissen, wo die Lösung am Ende liegen wird.
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
13,069
Punkte für Reaktionen
405
Punkte
83
Die Ausgabe auf /dev/pts/0 ?
...indem du...

1. Eine neue Session aufmachst (SSH) und dann die Erste schliesst?
2. Oder den syslogd startest, beispielsweise so...
Code:
syslogd -l 8 -S -D -s 512 -b 0 -O /tmp/messages
...die Datei messages wird so höchstens 512KB klein.
...patchen wäre natürlich auch eine Lösung. ;)
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
Nochmal: Du sollst ja gar nicht das entstehende Freetz-Image auf die Box flashen. Um dieses Image zu bauen, müssen ja die ganzen Programme vorher auch übersetzt werden. Das macht das "Freetz" (wenn man es mal als Monolithen betrachten will) auch für Dich. Hinterher nimmt man dann einfach die einzelnen Programme (da geht auch nichts kaputt, wenn man es richtig macht) und baut sich daraus ein tar-File (das man dann noch durch "gzip" jagt), kopiert das auf die Box und läßt "modfs" (inkl. des zusätzlichen Skripts) seine Arbeit machen. Dann hat man die zusätzlichen Programme direkt im System (wenn die sich nicht alle Nase lang ändern sollen, dann ist natürlich der NAND-Flash tatsächlich besser) und: "... sie lebten glücklich bis an ihr Ende.".

Hoppla, jetzt fehlt ein Teil der Frage, ich lasse das hier trotzdem stehen ... und bin jetzt bis zu neuen substantiellen Fragen dazu (die dann vielleicht besser in einen neuen Thread gehören) hier auch raus.
 
Zuletzt bearbeitet:

phreichmuth

Neuer User
Mitglied seit
16 Mrz 2014
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
@PeterPawn:
Das heisst, die gebrauchsfertigen Pakete auf fritmod.net sind auch auf Freetz kompiliert worden?
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
13,069
Punkte für Reaktionen
405
Punkte
83
Macht mir jetzt den Radislav nicht schlecht.
Ich schlag vor du fragst ihn einfach.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
Das heisst, die gebrauchsfertigen Pakete auf fritmod.net sind auch auf Freetz kompiliert worden?
Mal ehrlich, woher soll ich das wissen?

Falls es nicht deutlich geworden ist, ich bin eigentlich sogar ein strikter Gegner von Binärdateien aus unbekannten Quellen unter (vermutlich) singulärer Kontrolle und dazu gehört nun einmal auch fritzmod.net. Das geht sogar so weit, daß eigentlich dort auch die Skripte zum Erstellen der Busybox zu laden sein müßten (ob das der Fall ist oder nicht, weiß ich gar nicht genau), da schon das Konfigurieren der Busybox über "make menuconfig" eine geänderte Variante erzeugt und die GPLv2 (meines Wissens gilt die für die BB) fordert, daß man dann auch die Quellen (bzw. zumindest die ggü. der originalen Version geänderten Dateien) zur Verfügung stellt.

Wenn ich irgendeinen besseren Weg wüßte, würde ich auch nicht in "modfs" meine eigenen Versionen von "mksquashfs" und "unsquashfs" als Binärdateien aufnehmen und ich weise hoffentlich bei der Dokumentation von modfs auch extra darauf hin, wie man mich kontrollieren kann ... ich nehme aber auch jeden Vorschlag dankend an, wie man das Ausliefern von Binärdateien in diesem Falle vermeiden kann (außer modfs zurückzuziehen).

Allerdings kann ich natürlich jedem Interessenten auch gerne meine eigene - vollkommen unverdächtige - Variante der Busybox anbieten, die mit einem "stillen" Applet erweitert wurde, was - meinetwegen bei jedem Aufruf von "mknod" - die ar7.cfg aus /var/flash irgendwo auf einen Webserver unter meiner Kontrolle überträgt. Wie (un)realistisch das ist, muß jeder selbst beurteilen ... und ich will auch dem Anbieter von fritzmod.net nichts unterstellen. Aber man sollte eben jedem Binärpaket mißtrauen, wenn man es problemlos auch selbst erstellen könnte. Das gilt auch für mich selbst ... ich bin da keinen Deut vertrauenswürdiger als irgendeine andere Quelle im Internet.
 

eisbaerin

IPPF-Urgestein
Mitglied seit
29 Sep 2009
Beiträge
10,034
Punkte für Reaktionen
681
Punkte
113
und einer Log-Datei an einem Ort, wo sie nicht hin gehört,
Dann wäre es ja nett, wenn du uns verrätst wo die sich genau befand und wie sie heißt.

Mich interessieren auch noch deine 2 Scripte (ssh-server.sh + dyndns.sh)
Kannst du die bitte (natürlich geschwärzt) hier oder per PM mal zeigen.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,563
Punkte für Reaktionen
1,168
Punkte
113
@koy:
Das geht ja auch gar nicht gegen "rad".

Es sind prinzipielle Erwägungen ... und davon, wie realistisch so etwas am Ende ganz schnell werden kann, kriegt man z.B. einen Eindruck, wenn man die Meldung zur Modifikation von Downloads für Windows-PCs auf Tor-Exit-Nodes noch einmal sucht.

Wenn bei rad in seine WordPress-Installation eingebrochen wird (such mal nach der letzten WP-Lücke) und die Files ausgetauscht werden, kann man das wegen fehlender Hash-Werte nicht einmal verifizieren ... ob er es mitbekommen würde, kann nur er selbst einschätzen.

Ich halte die Anleitungen auf fritzmod.net gerade für Einsteiger für wirklich gut. Wenn sie aber anstelle einer Anleitung, wie man die Pakete selbst erstellen kann, auf die fertigen Pakete zum Download verweisen (und meines Wissens auch keine Alternativen aufzeigen), finde ich das eben nicht gut.

Wäre ja aber auch komisch ... auf der einen Seite über Sicherheit schreiben und auf der anderen Seite solche Pakete (ohne Quellen, keine Hashes, die gehören am besten sogar noch an eine weitere unabhängige Stelle, denn wenn die WP-Präsenz gehackt und die Files samt Hashes getauscht werden, merkt das auch nur eine Suchmaschine, weil sich der Seiteninhalt ändert) für eine gute Idee halten, das paßt einfach nicht zusammen.

Da spielt die Person hinter dem Nick "rad" und sein Engagement auch keine spezielle Rolle ... wenn das Bruce Schneier oder Tim Cook wäre, würde sich meine Argumentation auch nicht ändern. Ich stehe mit dieser Meinung ja auch nicht vollkommen alleine ... die Idee bei OpenSource ist ja unter anderem auch Transparenz. Die geht bei so einem Angebot aber verloren ... wie gesagt, schon die konkrete .config mit Angaben zum ungefähren Stand der Sources würde eine Einschätzung erlauben, welche Fehler in der Busybox stecken könnten.

Die "alte" Version (1.21.1) kann man vielleicht noch verkraften, AVM ist da ja auch nicht viel "schneller" beim Aktualisieren ... andererseits hat AVM eben mit den kompletten Images auch die deutlich schlechteren Voraussetzungen für solche Aktualisierungen und die Busybox ist inzwischen bei 1.23.2.

Ob da Security-relevante Updates fehlen oder nicht, weiß ich aktuell auch nicht ... aber sind sich die "Kunden" von fritzmod.net dessen bewußt, daß da u.U. ein alter Stand verwendet wird?

Selbst die Angabe des Datum der Quellen würde schon helfen ... so kann man nur noch raten, welche der Patches zwischen 1.21.1 (29.06.2013) und 1.22.1 (20.01.2014) in der angebotenen Version enthalten sind. Wie gesagt, das sind alles Punkte, die man durchaus beheben könnte, wenn man will ... und ein Router ist nun mal kein Spielzeug, auch wenn eine FRITZ!Box dazu einlädt.

Am Ende muß es aber tatsächlich jeder selbst wissen ... ich kann eigentlich nur das "Hätte mir das nur jemand vorher gesagt ..." nicht mehr hören. Ich bin mir aber auch bewußt, daß nur "Bedenkenträger" sich auch abnutzt ... der Mittelweg ist nicht immer leicht zu finden.

EDIT:
LOL, gerade frisch "reingekommen" zum Thema Sicherheit von WordPress-Installationen : http://heise.de/-2622268
 
Zuletzt bearbeitet: