{"id":7805,"date":"2021-11-07T14:06:09","date_gmt":"2021-11-07T12:06:09","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=7805"},"modified":"2022-12-12T18:26:52","modified_gmt":"2022-12-12T16:26:52","slug":"c-webserver-selbst-kompilieren-aktuellster-nginx-auf-dem-raspberry-pi","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/c-webserver-selbst-kompilieren-aktuellster-nginx-auf-dem-raspberry-pi\/","title":{"rendered":"C Webserver selbst kompilieren: Aktuellster Nginx auf dem Raspberry Pi"},"content":{"rendered":"

Quelloffene Projekte wie den Nginx Webserver kann man selbst kompilieren. Daf\u00fcr gibt es verschiedene Gr\u00fcnde: Etwa m\u00f6chte man die neueste Version nutzen, ihn ver\u00e4ndern, Erweiterungen einbauen oder auch einfach die Funktionsweise besser verstehen, vielleicht sogar selbst am Projekt mitwirken. Das ist gar nicht so schwer, wie es zun\u00e4chst vielleicht klingen mag. In diesem Beitrag werden wir uns dies anhand des Webservers Nginx anschauen, der aufgrund seiner Leistung und Effizient seit l\u00e4ngerem an Verbreitung gewinnt.<\/p>\n

Was bedeutet kompilieren \u00fcberhaupt?<\/h2>\n

Viele g\u00e4ngige Programmiersprachen sind sogenannte h\u00f6here Programmiersprachen, das hei\u00dft: Sie wurden f\u00fcr Menschen optimiert, auch wenn manche dabei gelegentlich Zweifel haben. Computer verstehen nur Nullen und Einsen, womit sich viele Menschen wiederum schwer tun. Ein Compiler ist dabei der \u00dcbersetzer: Durch das Kompilieren verwandelt er den Code in eine f\u00fcr Computer lesbare Form – n\u00e4mlich Bin\u00e4rcode. <\/p>\n

Bei hardwarenahen Sprachen wie C oder C++ muss pro Architektur neu kompiliert werden: Bin\u00e4rcode von einem x86 PC l\u00e4uft also nicht auf einem Pi mit ARM-Prozessor. Aus dem Grunde gibt es auch mehr Softwarepakete f\u00fcr den Linux-Desktop, als den Raspberry Pi: Dort ist x86 der Standard, ARM dagegen selten. Allerdings k\u00f6nnen wir diese alternativ auch selbst kompilieren – sofern sie Open Source ist. Bei propriet\u00e4rer Software ist man dagegen komplett auf den Hersteller angewiesen. Bietet er keine (32 Bit) ARM Builds an, sieht es schlecht aus.<\/p>\n

So kompilierst du die neueste stabilste Nginx Version auf dem Raspberry Pi<\/h2>\n

1. Quellcode herunterladen<\/h3>\n

Zun\u00e4chst ben\u00f6tigen wir den Quellcode. Er l\u00e4sst sich als .tar.gz Archiv vom Downloadbereich der offiziellen Internetseite herunterladen<\/a>. Im Folgenden nehme ich die zum Erstellungszeitpunkt aktuellste Mainline <\/strong>Version 1.21.3, lade sie auf den Pi und entpacke das Archiv:<\/p>\n

\n
\n$ wget https:\/\/nginx.org\/download\/nginx-1.21.3.tar.gz\n$ tar xfvz nginx-1.21.3.tar.gz\n$ ls -l ~\/nginx-test\/\ntotal 1044\ndrwxr-xr-x 9 pi pi    4096 Oct 12 18:55 nginx-1.21.3\n-rw-r--r-- 1 pi pi 1061461 May 25 16:34 nginx-1.21.3.tar.gz\n$ cd nginx-1.21.3\n<\/pre>\n<\/div>\n
Zur Entscheidungshilfe zwischen Stable<\/strong> und Mainline<\/strong> ist gut zu wissen<\/a>: Mainline bekommt alle Fehlerkorrekturen, Stable dagegen nur kritische. Mainline ist daher tendenziell zuverl\u00e4ssiger. Zumindest wenn man keine Drittanbieter-Module verwendet, Probleme damit sind bei Stable unwahrscheinlicher.<\/p>\n
Doch sollten wir den Quellcode nicht in \/usr\/local\/src ablegen, so wie es der Dateisystem-Hierarchiestandard von Linux vorsieht<\/a>? Jein: Der Ordner ist zwar f\u00fcr selbst eingef\u00fcgten Quellcode vorsehen. Aber eher zur Archivierung – also nicht als Arbeitsverzeichnis, in dem er compiliert wird, so wie wir das gleich machen. Daher habe ich das ganze hier ins Home-Verzeichnis vom Pi-Benutzer gelegt.<\/p>\n
2 Zielverzeichnis anlegen<\/h3>\n
Wir legen den Zielordner an, in dem die Daten des kompilierten Nginx sp\u00e4ter liegen sollen und hinterlegen den Pi-Benutzer als Eigent\u00fcmer – so vermeiden wir, das Buildwerzeug sp\u00e4ter mit sudo aufrufen zu m\u00fcssen. Wenn ihr einen anderen Nutzer verwendet, entsprechend anpassen.<\/p>\n
\n
\nsudo mkdir \/opt\/nginx\nsudo chown pi:pi \/opt\/nginx\/\n<\/pre>\n<\/div>\n
3. Abh\u00e4ngigkeiten installieren & Konfigurieren<\/h3>\n
Vor dem kompilieren kommt das konfigurieren: Wir legen fest, was genau mit welchen Funktionen gebaut werden soll. Details dazu findet ihr in der Dokumentation des Quellcodes<\/a>.  Dies geschieht \u00fcber das Werkzeug configure<\/em>. Ein minimalistischer Aufruf sieht so aus:<\/p>\n
\n
\n.\/configure --prefix=\/opt\/nginx \n<\/pre>\n<\/div>\n
Das –prefix <\/strong>Verzeichnis ist der Ordner, in dem sp\u00e4ter die fertig kompilierte Anwendung liegen soll. Bevor du die Konfiguration startest, installieren wir die Abh\u00e4ngigkeiten. Das sind APT-Pakete, die meist auf -dev<\/strong> enden, bei Ubuntu -devel<\/strong>. Sie enthalten alle Dateien die man ben\u00f6tigt, um Code zu kompilieren, der die jeweilige Bibliothek nutzt. Beispielsweise Header-Dateien, welche die Schnittstellen beschreiben. PCRE ist eine Bibliothek f\u00fcr regul\u00e4re Ausdr\u00fccke, die Nginx z.B. f\u00fcr die Routen nutzt. Ein Compiler wird ebenfalls ben\u00f6tigt, wobei gcc in aktuellen Pi-Images normal vorinstalliert ist.<\/p>\n
\n
\nsudo apt install gcc libpcre3-dev\n<\/pre>\n<\/div>\n
Anhand der Dokumentation seht ihr, dass man einige weitere Einstellungen vornehmen kann. Das reicht von Standardpfaden bis hin zu Modulen. Ein Modul erweitert den Webserver um eine bestimmte Funktion. Beispiel: Das http_ssl_modul<\/a> bietet die M\u00f6glichkeit, verschl\u00fcsselte Verbindungen mit HTTPS zu nutzen. Wenn wir das aktivieren m\u00f6chten, brauchen wir wie in der Dokumentation die OpenSSL-Bibliothek:<\/p>\n
\n
\nsudo apt install libssl-dev\n<\/pre>\n<\/div>\n
Nun k\u00f6nnten wir den Compiler anweisen, das SSL-Modul ebenfalls mit einzuschlie\u00dfen. Daf\u00fcr brauchen wir aber zun\u00e4chst das OpenSSL-Modul, wie in der Doku beschrieben:<\/p>\n
\n
\nsudo apt install libssl-dev\n.\/configure --prefix=\/opt\/nginx --with-http_ssl_module\n<\/pre>\n<\/div>\n
Ebenfalls sinnvoll sind –with-threads<\/strong> und –with-file-aio<\/strong> zur Leistungsverbesserung.<\/p>\n
Standardm\u00e4\u00dfig vorhandene Module lassen sich jeweils mit –without-XYZ<\/strong> deaktivieren. M\u00f6chten wir z.B. keine Proxy-Verbindungen an andere Webserver weiterreichen, k\u00f6nnen wir es mit –without-http_proxy_module<\/strong> abschalten. Gleiches gilt f\u00fcr eine Reihe anderer Module, etwa –without-http_memcached_module<\/strong>. Wer diese Funktionen nicht nutzt, kann sie hier deaktivieren – dadurch wird der Webserver schlanker und das compilieren beschleunigt sich etwas.<\/p>\n
W\u00e4hrend des Konfigurierens wird gepr\u00fcft, ob alle Abh\u00e4ngigkeiten vorhanden sind. Wenn ihr also beispielsweise ein Modul aktiviert, das zus\u00e4tzliche Bibliotheken ben\u00f6tigt und diese fehlen, erscheint ein entsprechender Fehler.<\/p>\n
4. Abh\u00e4ngigkeiten installieren & Konfigurieren<\/h3>\n
Durch das vorherige Konfigurieren ist ein Makefile <\/strong>entstanden. Es geh\u00f6rt zu make<\/strong>, ein Werkzeug um den Buildprozess abzubilden. Im Makefile befinden sich alle Anweisungen, die notwendig sind, um Nginx mit den gew\u00fcnschten Modulen zu kompilieren. Au\u00dferdem erstellt es die von der Anwendung ben\u00f6tigte Ordnerstruktur im Zielordner, der mit –prefix<\/strong> zuvor abgegeben wurde. Darin wird z.B. auch eine Standard-Konfigurationsdatei f\u00fcr den Webserver angelegt. Um das zu starten, f\u00fchren wir folgenden Befehl aus:<\/p>\n
\n
\nmake install\n<\/pre>\n<\/div>\n
Der Vorgang dauert auf einem Raspberry Pi 4 gute 1,5 Minuten. Danach solltet ihr einen kompletten Nginx Webserver im Zielverzeichnis (hier \/opt\/nginx<\/strong>) liegen haben:<\/p>\n
\n
\n$ ls -lh \/opt\/nginx\/\ntotal 16K\ndrwxr-xr-x 2 pi pi 4.0K Oct 12 19:55 conf\ndrwxr-xr-x 2 pi pi 4.0K Oct 12 19:55 html\ndrwxr-xr-x 2 pi pi 4.0K Oct 12 19:55 logs\ndrwxr-xr-x 2 pi pi 4.0K Oct 12 19:55 sbin\n<\/pre>\n<\/div>\n
Um ihn zu starten:<\/p>\n
\n
\nsudo \/opt\/nginx\/sbin\/nginx\n<\/pre>\n<\/div>\n
Den Startbefehl m\u00fcssen wir als root ausf\u00fchren, da nginx die privilegierten Ports 80 und bei HTTPS-Aktivierung auch 443 nutzt. Normale Nutzer d\u00fcrfen keine Prozesse starten, die auf Ports unter 1024 lauschen.<\/p>\n
Im Browser sollte unter dem Hostname bzw. der IP-Adresse des Pi nun eine Welcome to nginx<\/strong> Seite zu sehen sein:<\/p>\n
\"\"<\/a><\/figure>\n
Wie kann man auf eine neue Nginx-Version aktualisieren?<\/h2>\n
Zuerst den laufenden Webserver stoppen:<\/p>\n
\n
\nsudo \/opt\/nginx\/sbin\/nginx -s stop\n<\/pre>\n<\/div>\n
Anschlie\u00dfend das neue .tar.gz Archiv wie oben beschrieben herunterladen, entpacken, den .\/configure<\/strong> Befehl gefolgt von make install<\/strong> ausf\u00fchren. Nach dem Start des Webservers l\u00e4uft er in der aktuellen Version. Nachpr\u00fcfen kann man dies beispielsweise mit -v<\/p>\n
\n
\n$ \/opt\/nginx\/sbin\/nginx -v\nnginx version: nginx\/1.21.3\n<\/pre>\n<\/div>\n
Standardm\u00e4\u00dfig sendet Nginx zudem einen Server-Header als Antwort auf jede Anfrage. Er enth\u00e4lt Name und Version:<\/p>\n
\"\"<\/a><\/figure>\n
Um Updates zu erleichtern, macht es Sinn, die Anweisungen in einem Skript zu b\u00fcndeln. Dadurch ist das Aktualisieren leichter und ihr habt die aktivierten bzw. deaktivierten Module automatisch dokumentiert, sodass keines vergessen wird.<\/p>\n
Fazit: Vor- und Nachteile von selbst kompilierten Programmen<\/h2>\n
Das selbst kompilieren kann uns bei quelloffener Software einige Vorteile bieten. Haupts\u00e4chlich Anpassbarkeit und die Verwendung von aktuellen Versionen sowie zus\u00e4tzlichen Module. Es erm\u00f6glichte die Verwendung der aktuellen stabilen 1.21.3<\/strong> Version, wogegen in den Paketquellen zum Zeitpunkt des Tests lediglich 1.14.2<\/strong> enthalten war. Zum Vergleich: 1.14.2<\/strong> ist vom Dezember 2018, also knapp 3 Jahre alt.<\/p>\n
Allerdings gibt es auch einen Nachteil: Selbst kompilierte Software kann nicht \u00fcber die Paketverwaltung aktualisiert werden. Wie alle h\u00e4ndisch installierten Programme m\u00fcssen wir uns daher selbst \u00fcber Aktualisierungen informieren und sollten vor allem Sicherheitsupdates zeitnah einspielen. Dies gilt umso mehr, wenn der Pi nach au\u00dfen hin erreichbar ist. Man sollte im Einzelfall entscheiden, was sinnvoller bzw. wichtiger ist. <\/p>\n
F\u00fcr den selbst kompilierten Nginx solltet ihr zudem beachten, dass dieser nicht automatisch zusammen beim Booten des Pi gestartet wird. Das l\u00e4sst sich am sinnvollsten mit einem Systemd-Dienst umsetzen.<\/p>\n
Grunds\u00e4tzlich l\u00e4sst sich diese Vorgehensweise auch auf andere Open Source Projekte \u00fcbertragen. Sowohl andere Webserver wie z.B. Apache2, als auch Programme mit anderen Verwendungszwecken. Gegebenenfalls sind daf\u00fcr mehr oder weniger \u00c4nderungen notwendig, das h\u00e4ngt stark vom Projekt ab. Und es l\u00e4sst sich eben so auf jedem Linux-Computer oder Server umsetzen, auch mit x86 Architektur.<\/p>\n","protected":false},"excerpt":{"rendered":"
Quelloffene Projekte wie den Nginx Webserver kann man selbst kompilieren. Daf\u00fcr gibt es verschiedene Gr\u00fcnde: Etwa m\u00f6chte man die neueste Version nutzen, ihn ver\u00e4ndern, Erweiterungen einbauen oder auch einfach die Funktionsweise besser verstehen, vielleicht sogar selbst am Projekt mitwirken. Das ist gar nicht so schwer, wie es zun\u00e4chst vielleicht klingen mag. In diesem Beitrag werden …<\/p>\n","protected":false},"author":5,"featured_media":7826,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[671],"tags":[984,985,541,937],"class_list":["post-7805","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-raspberry-pi","tag-kompilieren","tag-makefile","tag-nginx","tag-webserver"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/7805","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=7805"}],"version-history":[{"count":7,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/7805\/revisions"}],"predecessor-version":[{"id":9816,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/7805\/revisions\/9816"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/7826"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=7805"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=7805"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=7805"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}