====== Achtung! FREETZ-WIKI ist zu www.freetz.org umgezogen! ====== **Die aktuellen WIKI-Seiten zu FREETZ befinden sich auf [[http://www.freetz.org/wiki/freetz|www.freetz.org]]. Alle Aktualisierungen und Änderungen werden nur dort eingepflegt! Bitte dieses WIKI nicht mehr ergänzen!** ====== Howtos ====== **Aktuelle [[http://www.freetz.org/wiki/help/howtos|Howtos]] befinden sich auf [[http://www.freetz.org/wiki/help/howtos|www.freetz.org]]!** ---- Sammlung von Howtos und Kurztipps rund um Freetz (ehemals ds-mod). ===== Projekte ===== [[software:ds-mod:howtos:interner-router|Fritz!box als interner Router mit Firewall und DMZ]] ===== Kurzanleitungen ===== ==== Eigene Dateien in die Firmware integrieren ==== Dies kann ohne großen Aufwand über das Verzeichnis ./root/ realisiert werden. Einfach die gewünschten Dateien in das Verzeichnis ./root/ an die Stelle kopieren, an der sie im root Dateisystem der Box landen sollen (außer ./root/lib/ und ./root/usr/lib/, welche seperat behandelt werden). Beispiel: eine Datei ./root/usr/bin/foo wird auf der Box in /usr/bin/foo landen. ==== Original Firmware wiederherstellen ==== Wenn die Box nicht mehr ansprechbar ist, die Power LED leuchtet und die übrigen LEDs in regelmäßigen Abständen aufblinken, dann kann folgende Vorgehensweise die Box wieder zum Leben erwecken. In diesen Fällen ist meist mtd0 (Filesystem) und mtd1 (Kernel) betroffen, nicht mtd3 / mtd4 (mtd2 auf **KEINEN** Fall anrühren). - Der Computer muss sich im gleichen Subnetz (und auch Broadcast-Domäne) wie die Box befinden: 192.168.178.0/24 - make recover - Den Anweisungen folgen (zur Zeit leider nicht bei allen Fritzbox-Typen möglich) Am bequemsten funktioniert es, wenn nach einem `make' der ds-mod noch nicht mit `make clean', `make dirclean' oder `make distclean' bereinigt wurde und noch eine für die Box passende Konfiguartion des Mods vorhanden ist. In diesem Fall lädt `make recover' die unmodifizierte original Firmware auf die Box. ==== Cross-Compiler / Toolchain erstellen ==== Das Erstellen eines Cross-Compilers ist mit dem ds-mod denkbar einfach: - make menuconfig Hier unter "Advanced options" > "Compiler options" die Optionen für den Cross-Compiler wählen. Soll der Compiler Programme für eine mit dem ds-mod erzeugte Firmware kompilieren, so ist in der Regel nichts zu ändern. Soll der Compiler hingegen für eine originale Firmware kompilieren können, so solltest du bei "uClibc config" die entsprechende Konfiguration auswählen. ACHTUNG: Im zweiten Fall sollte diese entpackte Instanz des ds-mod nicht mehr zum Erstellen von Images verwendet werden, sondern nur noch der Cross-Compiler selbst. - Benötigt wird gcc, binutils, make, bison, flex und texinfo: make toolchain Eine ganze Weile und ca 2 GB später wurden zwei Cross-Compiler erstellt: * ./toolchain/kernel/bin/mipsel-unknown-linux-gnu-gcc : Cross-Compiler für die Kernel Sourcen * ./toolchain/target/bin/mipsel-linux-uclibc-gcc : Cross-Compiler für Userspace Programme - make libs Erstellt alle im menuconfig ausgewählten Libraries und installiert deren Header. ==== Vorkompilierte Programme neu übersetzen ==== - make menuconfig Wähle deinen Boxtyp (Type) und die gewünschten Pakete aus, denn es werden nur die vorkompilierten Programme der aktuellen ds-mod Konfiguration kompiliert. - make precompiled Dies erstellt sowohl die Toolchain (falls noch nicht geschehen) und alle für deine Konfiguration benötigten vorkompilierten Programme und den Kernel. ==== Kernel konfigurieren und kompilieren ==== Vorraussetzung ist eine Toolchain (siehe [[#cross-compiler_toolchain_erstellen|Cross-Compiler / Toolchain erstellen]]). Sollten jemals Probleme mit nicht vorhandenen Verzeichnissen auftauchen, so kann ein make world Abhilfe schaffen. In der Regel sollte das aber nicht nötig sein. - Der Boxtyp (Type) sollte richtig gewählt sein, da nur der Kernel für die entsprechende Box kompiliert wird - make kernel-dirclean Löscht den aktuell entpackten Source Tree des Kernels (wir werden von komplett sauberen Kernel Sourcen kompilieren; wer das nicht will, kann es mit `make kernel-clean' versuchen) - make kernel-menuconfig Die Konfiguration des Kernels wird danach wieder nach ./make/linux/Config. zurückgespeichert - make kernel-precompiled Nun werden der Kernel und die Kernel Module kompiliert: * ./kernel/kernel-.bin * ./kernel/modules-/ ==== Busybox konfigurieren und kompilieren ==== Vorraussetzung ist eine Toolchain (siehe [[#cross-compiler_toolchain_erstellen|Cross-Compiler / Toolchain erstellen]]). Sollten jemals Probleme mit nicht vorhandenen Verzeichnissen auftauchen, so kann ein make world Abhilfe schaffen. In der Regel sollte das aber nicht nötig sein. - Der Boxtyp (Type) sollte richtig gewählt sein, da nur die Busybox für die entsprechende Box kompiliert wird - make busybox-dirclean Löscht die aktuell entpackten Sourcen der Busybox (wir werden von komplett sauberen Busybox Sourcen kompilieren; wer das nicht will, kann es mit `make busybox-clean' versuchen) - make busybox-menuconfig Die Konfiguration der Busybox wird danach wieder nach ./make/busybox/Config. zurückgespeichert - make busybox-precompiled Dies kompiliert die Busybox und aktualisiert: * ./busybox/busybox- * ./busybox/busybox-.links ==== Patches in den ds-mod einspielen ==== Bei dringenden oder kleinen Änderungen / Neuerungen werden passend zum letzten Release so genannte Patches angeboten. Diese Patches haben einen Dateinamen ähnlich diesem: ds//26-x.y-patch-name//.patch.bz2. Der Patch muss **nach** dem Entpacken des zugehörigen ds-mod ds//26-x.y//.tar.bz2 und **vor** dem Erstellen des Image eingespielt werden. Folgende Anleitung geht davon aus, dass beide Dateien im aktuellen Verzeichnis liegen: - //Falls noch nicht geschehen//: ds-mod entpacken tar -xvjf ds26-x.y.tar.bz2 - Patch entpacken bunzip2 ds26-x.y-patch-name.patch.bz2 - Patch anwenden patch -p0 < ds26-x.y-patch-name.patch Nun ist der Patch in den entpackten ds-mod eingespielt und man kann mit dem Erstellen des Image fortfahren. ==== Addon Paket installieren ==== Pakete, die noch nicht in den Mod integriert sind, können als sogenanntes "Addon Paket" installiert werden. Dazu das gewünschte Paket **vor** dem Erstellen des Image herunterladen und nach ./addon entpacken. Folgendes Beispiel geht davon aus, dass man sich im Verzeichnis des entpacken ds-mod befindet: tar -C addon -xjvf /pfad/zu/addon-paket-0.1-dsmod.tar.bz2 Danach muss das Paket in der Liste ./addon/static.pkg in eine neue Zeile eingetragen werden (im obigen Beispiel: addon-paket-0.1). Addon Pakete werden nach den integrierten Paketen in der Reihenfolge des Auftretens in ./addon/static.pkg gestartet. ==== Eigene Programme kompilieren ==== Nachdem die Toolchain heruntergeladen oder gebaut wurde, kann sie verwendet werden, um eigene Programme, oder solche, die noch nicht als Paket zur Verfügung stehen, zu übersetzen. Den MIPS-Compiler zum Pfad hinzufügen: export PATH=/pfad/zu/dsmod/toolchain/target/bin:$PATH Optionen für ./configure: ./configure --build=i386-linux-gnu --target=mipsel-linux --host=mipsel-linux (i386-linux-gnu ist nicht unbedingt notwendig, nur beschwert sich configure, wenn es nicht angegeben ist. Auf 64-Bit-Plattformen oder Nicht-Intel-Architekturen muß es natürlich anders heißen.) Statisches Linken der Binaries, damit sie keine separaten Libraries benutzen, sondern sie gleich enthalten (funktioniert aber nicht bei jeder Software): LDFLAGS=-static ./configure ... Statisch gelinkte Binaries sind einfacher zu installieren, weil sie eben alles enthalten, aber dadurch sind sie größer, und wenn sie mit anderen Programmen gemeinsam genutzte Funktionalität haben, verschwenden sie Speicherplatz. Außerdem müssen sie separat upgedatet werden, wenn z.B. in einer Library eine Sicherheitslücke gepatcht wurde. Es ist also am besten, statische Binaries nur zum Testen, oder wenn es anders nicht geht, zu verwenden. In manchen Fällen ist es ratsam die CC-Variable explizit zu setzen. Auch die Angabe der CFLAGS kann nicht schaden: ./configure ... CC="mipsel-linux-gcc" CFLAGS="-Os -pipe -march=4kc -Wa,--trap" ==== Link von ds-mod auf Fritz Webinterface ==== Die Datei **root/usr/lib/libmodcgi.sh** muss um einen Hyperlink erweitert werden. ==== Benutzer anlegen ==== Nehmen wir an, der neue Benutzer soll //picard// heißen. Benutzer //root// macht dann Folgendes: === Freetz: === # Benutzer hinzufügen (Standard adduser Kommando) adduser picard # Paßwort vergeben (Standard passwd Kommando) passwd picard # Persistent speichern modsave flash === ds-mod: === # Benutzer hinzufügen echo "picard:*" >> /tmp/flash/shadow.save # Persistent speichern modsave flash # Alle Benutzer neu laden, fehlende Heimverzeichnisse erzeugen modpasswd load # Paßwort vergeben (wird automatisch persistent gespeichert) modpasswd picard # Test login picard ==== Benutzer löschen ==== Jetzt der umgekehrte Weg - Benutzer //picard// soll wieder weg. Benutzer //root// macht dann Folgendes: === Freetz === # Heimverzeichnis löschen rm -rf /mod/home/picard # Benutzer löschen (Standard deluser Kommando) deluser picard # Persistent speichern modsave flash === ds-mod === # Heimverzeichnis löschen rm -rf /mod/home/picard # Temporäre Datei mit gelöschtem Benutzer erzeugen grep -v '^picard:' /tmp/flash/shadow.save > /tmp/deleted-user # Benutzerdatei überschreiben mv /tmp/deleted-user /tmp/flash/shadow.save # Persistent speichern modsave flash # Alle Benutzer neu laden (jetzt einen weniger) modpasswd load # Test (schlägt mit "Login incorrect" bei PW-Eingabe fehl) login picard