OpenWrt-Batch-Systemgerät

Das OpenWrt-Betriebssystem wird üblicherweise als Firmware für Router verwendet. Die typische Anwendung ist das Einstellen und Vergessen. Aber wenn Ihnen plötzlich etwas nicht mehr ausreicht, müssen Sie das Verteilungskit verstehen.

OpenWrt verwendet opkg als Paketmanager bzw. als eigenen Fork . Debian-Ingenieure werden es in vielerlei Hinsicht kennen: ähnliche Befehle, ähnliches Format des Repositorys und der Pakete.



Ich wollte LUCI patchen (dies wird nicht im Artikel enthalten sein), fand jedoch keine angemessene schnelle Einführung. Ich musste unabhängig Informationsfragmente aus verstreuten Dokumentationen, Artikeln und Beispielen sammeln und dabei den Code und die Ergebnisse der Arbeit betrachten. Als Bonus habe ich ein primitives (aber in der Praxis nutzloses) Paket gesammelt, das sich noch nicht im Repository befindet. Ich teile das gesammelte Bildungsprogramm unten.

Repository-Gerät

Im OpenWrt-Dateisystem befindet sich eine Datei, die die Systemliste /etc/opkg/distfeeds.conf



(bereitgestellt von den OpenWrt- und opkg-Entwicklern) der Repositorys angibt. Eigene Repositorys und Repositorys von Drittanbietern können in angegeben werden /etc/opkg/customfeeds.conf



. Das Format ist einzeilig und besteht aus drei Wörtern:

1. src
   
   
   
   oder src/gz
   
   
   
   es hängt davon ab, Packages
   
   
   
   ob die Datei heruntergeladen wird oder Packages.gz
   
   
   
   . Dem Code nach zu urteilen, gibt es andere Optionen für das erste Wort, aber ich habe keine Repositories gefunden, für die dies relevant wäre. Trotz des src
   
   
   
   Namens ist dies ein Repository für Binärpakete. Das opkg hat kein spezielles Repository-Format für Quellpakete, das dem in Debian / APT verwendeten ähnelt.
2. Der Name des Repositorys oder "Feeds" in der opkg / OpenWrt-Terminologie.
3. Die URL, die das Packages
   
   
   
   / enthält Packages.gz
   
   
   
   .

Wenn die Liste der Pakete und Signaturen ausgeführt oder opkg update



zur URL /



hinzugefügt wird , wird sie gespeichert . Die Datei wird nach dem zweiten Wort in der Liste der Repositorys benannt. Daraus ergeben sich zwei wichtige Schlussfolgerungen:Packages



Packages.gz



/tmp/opkg-lists

1. Beim Neustart wird der Cache geleert. Auf eingebetteten Systemen wie Routern ist dies absolut sinnvoll.
2. Sie /etc/opkg/customfeeds.conf
   
   
   
   können System-Feeds mit Ihren eigenen überschreiben und ihnen denselben Namen geben. opkg wird schwören, aber die Überschreibung schlucken und die gewünschte Datei anstelle der zuvor geladenen hinzufügen.

Gleichzeitig wird es geladen Packages.sig



, das den Hash der entpackten Paketliste enthalten sollte. Die Liste selbst listet einfach die Pakete auf, es gibt mehrere Werte für jedes Paket, die Werte für verschiedene Pakete sind durch eine leere Zeile getrennt. Hier sind die wichtigsten Felder für jedes Paket:

• Package
  
  
  
  , Paketnamen;
• Version
  
  
  
  Wenn es mehrere Pakete mit demselben Namen gibt, können Sie die Version auswählen. Die neueste Version wird standardmäßig installiert.
• Depends
  
  
  
  Abhängig von anderen Paketen installiert der Paketmanager die aufgelisteten Pakete, wenn sie nicht im System vorhanden sind.
• Filename
  
  
  
  ist der Pfad zur Datei relativ zur Basis-URL des Repositorys, normalerweise ist das Repository flach und alles befindet sich an derselben Stelle wie "Packages.gz";
• SHA256sum
  
  
  
  Der vom Repository deklarierte Paket-Hash.

Wenn Sie weitere Informationen wünschen, können Sie einfach eine dieser Listen direkt in Ihrem Browser lesen .

Binärpakete

Binärpakete sind fast identisch mit Debian-Paketen. Der Unterschied ist wie folgt:

1. Erweiterung .ipk
   
   
   
   statt .deb
   
   
   
   .
2. `tar` gzip
   
   
   
   , . Debian ar
   
   
   
   , .tar.xz
   
   
   
   , .

Wenn Sie die Paketerweiterung für OpenWrt in ändern .tar.gz



und entpacken, finden Sie zwei Archive und eine Textdatei. Die Datei heißt debian-version



, sie enthält die Version des Binärdateiformats und ist für uns nicht sehr interessant. In modernen Systemen ist diese Version immer gleich 2.0



.



Das Archiv data.tar.gz



enthält ausführbare Dateien, Konfigurationsdateien und alles, wofür das Paket installiert ist. Wenn Sie es an die Wurzel der FS entpacken, erhalten Sie alle die erwarteten Dateien an den richtigen Stellen bekommen, in /usr/bin/



, /etc/



und so weiter.



Und darin gibt control.tar.gz



es Zusatzdateien für den Paketmanager. Das Skript , das vor oder nach der Installation und Deinstallation (ausgeführt werden soll preinst



, postinst



, prerm



,postrm



), Informationen zu Dateien, bei denen es sich um Konfigurationsdateien handelt, und Metainformationen zum Paket, die weitgehend mit denen in übereinstimmen Packages



.

Paket-Build-System

Das Assemblierungssystem (auch bekannt als SDK) besteht aus einem Make-Framework. Das Framework bedeutet nicht, dass Sie Pakete separat erstellen. Die Hauptaufgabe besteht darin, ganze Repositorys zu erstellen.



Das SDK x86_64



ist in Git . Es gibt ein Archiv (der Link wird bald veraltet sein, aber es ist nicht schwer, ein neues zu finden), mit dem Sie Zeit beim Kompilieren der Toolchain für die Montage sparen. Im Inneren ist die Datei von besonderem Interesse feeds.conf.default



. Das Format ist einfach und durch ein Leerzeichen getrennt:

1. Schlüsselwort src-git
   
   
   
   . Es wird nicht nur Git unterstützt , sondern es gibt auch keine Repositorys in anderen VCS.
2. Feed-Name.
3. Eine Git-Repository-URL, unter der Sie ein Commit oder Tag angeben können. Wenn Sie den Namen einer solchen Spezifikation kennen, sagen Sie es mir bitte.

Das Repository mit den Paketen selbst ist so einfach wie möglich: Im Stammverzeichnis des Repositorys befindet sich eine Paketkategorie, auf der zweiten Ebene ein Verzeichnis mit dem Paketnamen und Makefile



optional "Config.in" für zusätzliche Optionen während der Ausführung make menuconfig



sowie ein Unterverzeichnis patches



mit dem entsprechenden Inhalt. Nur für das einfachste Paket Makefile



. Sie können beispielsweise den Spiegel des Hauptrepositorys betrachten .

Testaufbau

Ich habe versucht, GNU Hello zu erstellen, um zu testen, wie das SDK funktioniert. Dies ist eine relativ monströse Hello World, die in strikter Übereinstimmung mit den GNU-Projektrichtlinien geschrieben wurde und deren einziger Zweck darin besteht, diese Richtlinien zu veranschaulichen. Ich habe kein separates Repository dafür erstellt, sondern es in die grundlegenden SDK-Pakete "verschoben", von wo aus ich es kompiliert habe.



Für den Betrieb des SDK von den benötigten Debian Umgeben Pakete libncurses-dev



(für die Montage des Menüs), build-essential



(von GCC und anderen Standardprogrammen auf dem C abhängig) gawk



, unzip



, file



, rsync



und python3



. Um ein Repository aus den gesammelten Paketen zu erstellen, benötigen Sie ein Dienstprogramm zum Generieren von Schlüsseln usign



. Es befindet sich nicht im Repository, daher benötigen Sie zum Erstellen zusätzlich "cmake". Dieses Tool kann sowohl durch GPG als auch durch GPG ersetzt werdensignify-openbsd



Es wird jedoch vom OpenWrt-Projekt empfohlen und entwickelt und ist viel besser zu verwenden.



Kompilieren und installieren usign



:

git clone https://git.openwrt.org/project/usign.git
cd usign
cmake .
make
sudo make install 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Anstatt set ( sudo make install



) zu setzen, können Sie sich einfach merken, wo sich das Binar befindet, um es mit Ihren Händen weiter zu ziehen.



Nun das grundlegende SDK-Setup:

git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
./scripts/feeds update -a
./scripts/feeds install -a
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ich möchte Sie daran erinnern, dass Sie das Archiv nicht von git klonen, sondern mit der vorkompilierten Toolchain herunterladen und entpacken können. Vergessen Sie nicht, einfach die neueste Version herunterzuladen!



Bei der Ausführung ./scripts/feeds update -a



klonen / aktualisieren wir alle Repositorys aus feeds.conf (.default), überprüfen Abhängigkeiten und bereiten ein Verzeichnis staging_dir/host/bin



mit ausführbaren Dateien vor (dies sind hauptsächlich Symlinks zu Systemdienstprogrammen). Mit dem folgenden Befehl ./scripts/feeds install -a



werden Symlinks verschoben package/feeds



, von wo aus sie zur Kompilierung verwendet werden. Diese beiden Befehle sind nicht erforderlich, um mein benutzerdefiniertes Paket zu erstellen.



Weiter wird ausgeführtmake menuconfig



... Sie können es überspringen, aber beim Kompilieren des Pakets wird weiterhin das entsprechende Fenster angezeigt. Darin reicht es aus, das Ziel und das Unterziel zu ändern, damit alles unter x86_64 kompiliert und beendet wird, um die Konfiguration zu speichern. Sie müssen auch zusätzliche Montagewerkzeuge ( make tools/install



) und Werkzeugketten ( ) sammeln make toolchain/install



. Wenn Sie das SDK aus dem Archiv heruntergeladen haben, werden make menuconfig



Ihnen keine Optionen zur Auswahl eines Ziels angezeigt, und das Zusammenstellen des Toolkits und der Toolchain ist nicht erforderlich - alles ist bereits vorhanden.



Jetzt erstelle ich ein Verzeichnis, package/devel/hello



in das ich Makefile



folgenden Inhalt lege:





Grundsätzlich sollte alles ohne Erklärung klar sein. Die Framework-Dateien werden verbunden, die Hauptparameter des Pakets werden beschrieben, @GNU



durch die Spiegel des GNU-Projekts (im Framework definiert) ersetzt, und der Pfad besteht aus zwei Teilen: Er PKG_SOURCE_URL



gibt die Basis-URL für alle Versionen an und wird durch Verketten des Dateinamens PKG_SOURCE



mit einem Schrägstrich erweitert. Es Package/hello/install



enthält Anweisungen zum Zusammenstellen von Binärdateien zu einem Archiv data.tar.gz



. Weitere Build-Optionen finden Sie bei Bedarf in der Dokumentation . Vergessen Sie übrigens nicht, dass make beim Einrücken sehr wählerisch ist. Ich hatte einzelne Tabulatoren anstelle von führenden Leerzeichen.



Erneut aufrufenmake menuconfig



Überprüfen Sie, ob das Hallo-Paket im angegebenen Abschnitt markiert ist (Entwicklung in meinem Fall), und beenden Sie das Speichern der Konfiguration. Schließlich bauen wir das Paket in drei Schritten zusammen; herunterladen, entpacken und tatsächlich kompilieren:

make package/hello/download
make package/hello/prepare
make package/hello/compile
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Als Ergebnis erhielt ich ein Paket bin/packages/x86_64/base/hello_2.9-1_x86_64.ipk



. Sie können ein Repository erstellen. Wir generieren ein Schlüsselpaar ( usign -G -c 'openwrt test repo' -s key-build -p key-build.pub



der private Schlüssel muss "key-build" heißen) und sammeln das Repository : make package/index



. In diesem Stadium kann die Baugruppe auf die Abwesenheit usign



im Verzeichnis mit Hilfstools schwören , ich entschied mich, Symlink-Problem : ln -s `which usign` staging_dir/host/bin/usign



. Neben dem Paket befindet sich nun der vollständige Satz, der für das Repository erforderlich ist.

Überprüfen des Repositorys zusammen mit dem Paket

Sie können alles auf einem echten Router überprüfen (denken Sie daran, das richtige Ziel auszuwählen), aber ich habe Docker verwendet. In Dokerhabe gibt es ein OpenWrt-Image für x86_84, das ausgeführt werden kann und mit dem SDK im Containerverzeichnis vereist : sudo docker run -it --name openwrt_test -v $PWD:/opt openwrtorg/rootfs



. Drücken Sie die Eingabetaste, bis die Bash-Eingabeaufforderung angezeigt wird.



Ich kopiere den Schlüssel aus dem weitergeleiteten Verzeichnis (der cp /opt/key-build.pub /etc/opkg/keys/usign -F -p /opt/key-build.pub



Name des Schlüssels muss mit dem Bezeichner übereinstimmen), füge mein lokales Repository hinzu ( echo src/gz local file:///opt/bin/packages/x86_64/base >> /etc/opkg/customfeeds.conf



) und aktualisiere das Repository ( opkg update



). Die Schlussfolgerung beginnt mit ermutigendem Text, alles ist korrekt signiert:

# opkg update
Downloading file:///opt/bin/packages/x86_64/base/Packages.gz
Updated list of available packages in /var/opkg-lists/local
Downloading file:///opt/bin/packages/x86_64/base/Packages.sig
Signature check passed.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Es bleibt nur zu installieren und zu überprüfen:

root@34af2f6e849b:/# opkg install hello
Installing hello (2.9-1) to root...
Downloading file:///opt/bin/packages/x86_64/base/hello_2.9-1_x86_64.ipk
Configuring hello.
root@34af2f6e849b:/# hello
Hello, world!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Hurra, es ist geschafft! Trotz der in den Artikeln verteilten Dokumentation ist das Erstellen von Paketen ziemlich einfach.