\ndaniel@pi:~ $ apt show nodejs\nPackage: nodejs\nVersion: 12.22.12~dfsg-1~deb11u4\n<\/pre>\n<\/div>\nVeraltete Software, die vom Hersteller nicht mehr unterst\u00fctzt wird, sollte man grunds\u00e4tzlich nicht einsetzen. Aufgrund der Architektur von Debian erhalten Debian und Raspberry Pi OS 11 Bullseye jedoch keine neue Hauptversion mehr, sondern erst die Nachfolgeversion. Dies w\u00e4re im Falle von Node.js aber notwendig, da jede Version nur vergleichsweise kurze Zeit unterst\u00fctzt wird – zu wenig f\u00fcr den Lebenszyklus einer Debian-Version. Debian 12 ist vor wenigen Wochen erschienen, das Raspberry Pi OS folgt bald. Derzeit hat man \u00fcber die offiziellen Paketquellen jedenfalls keine Alternative. Und auch in der Nachfolgeversion kann es schnell passieren, dass man vor dem gleichen Problem steht.<\/p>\n
\n\nsudo apt install nodejs\n<\/pre>\n<\/div>\nTheoretisch kann man das Paket mit diesem Befehl sehr einfach installieren. Ich rate jedoch davon ab und empfehle stattdessen Container (z.B. mit Docker) oder die inoffiziellen Debian-Paketquellen, welche von Node.js bereitgestellt werden. Beide Wege sind etwas aufw\u00e4ndiger. Daf\u00fcr erhaltet ihr aber eine aktuellere, unterst\u00fctzte Node.js Version und zudem eine bessere Kontrolle dar\u00fcber, welche Hauptversion \u00fcberhaupt installiert wird. Neben der Sicherheits- und Fehler-Problematik ben\u00f6tigen manche Programme eine neuere Version, weil sie deren Funktionen verwenden. Bei Etherpad beispielsweise mindestens Node.js 16.20.1 oder neuer. Diese Software w\u00fcrde mit der \u00e4lteren Version 12 aus den Paketquellen nur fehlerhaft oder gar nicht funktionieren. Zumindest wenn die in den Paketquellen angebotene Version ihr Lebensende erreicht hat, \u00fcberwiegen die Nachteile definitiv, sodass man davon grunds\u00e4tzlich Abstand nehmen sollte.<\/p>\n
Methode #2: Manuelle Bin\u00e4rdateien<\/h2>\n
Im Download-Bereich von Node.js werden Archive angeboten, die alle notwendigen Bin\u00e4rdateien enthalten. Man l\u00e4dt sich das zur Architektur passende Archiv: 64 Bit f\u00fcr X86, bei ARM v8 f\u00fcr den Raspberry Pi 4. V7 ist f\u00fcr den mittlerweile recht betagten Raspberry Pi 2 B. <\/p>\n
Ab dem RPI 2 v1.2 nutzen alle neueren Modelle die 64 Bit ARMv8 Architektur. Das mag manche schon alleine deswegen \u00fcberraschen, weil die 64 Bit Version des Raspberry Pi OS erst Jahre sp\u00e4ter \u00fcberhaupt als Beta erschien. Der Prozessor ist jedoch schon weitaus vorher (ab den 2016 erschienenen Modellen)<\/a> f\u00fcr die neue Architektur fit gewesen. Praktisch relevant wurde sie erst durch die Entscheidung mancher Softwarehersteller, ARM nur in 64 Bit zu unterst\u00fctzen. Sowie dem Erscheinen der 8 GB Edition des Raspberry Pi 4, womit die Architektur ihre Vorteile bei Systemen mit mehr als 4 GB Arbeitsspeicher tats\u00e4chlich ausspielen kann.<\/p>\n\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2023\/07\/grafik-3.png\")
<\/a><\/figure>\n<\/div>\nF\u00fcr den Raspberry Pi 4 verwende ich die ARMv8 Version, kopiere per Rechtsklick im Browser den Link und lade die Datei per wget herunter. Der folgende Link ist beispielhaft f\u00fcr die aktuellste Version zum Zeitpunkt des Artikels. Er sollte mit dem jeweils aktuellsten aus dem Download-Bereich<\/a> ersetzt werden. Anschlie\u00dfend das Archiv mit tar entpacken. Dadurch erhalten wir einen Ordner, der den gleichen Name tr\u00e4gt, wie das Archiv. Im Unterordner bin<\/strong> liegen die Bin\u00e4rdateien der bekannten Node.js Werkzeuge: Die Laufzeitumgebung node<\/strong>, der Paketmanager npm<\/strong> und das Hilfswerkzeug npx<\/strong> zur Ausf\u00fchrung von Anwendungen aus NPM-Paketen heraus.<\/p>\n\n\nwget https:\/\/nodejs.org\/dist\/v18.17.0\/node-v18.17.0-linux-arm64.tar.xz\ntar -xf node-v18.17.0-linux-arm64.tar.xz\n\n$ ls -lh | grep node-v18\ndrwxr-xr-x 6 daniel docker 4.0K Jul 18 13:39 node-v18.17.0-linux-arm64\n-rw-r--r-- 1 daniel docker 23M Jul 18 13:41 node-v18.17.0-linux-arm64.tar.xz\n\n$ node-v18.17.0-linux-arm64\/bin\/node -v\nv18.17.0\n<\/pre>\n<\/div>\nDa der Ordner noch weitere Abh\u00e4ngigkeiten enth\u00e4lt, ist es nicht Ratsam, lediglich den Inhalt des Unterordners bin<\/strong> nach \/usr\/local\/bin<\/strong> zu verschieben. Besser: Alles in \/opt anlegen und falls man die Werkzeuge global aufrufen k\u00f6nnen m\u00f6chte (wie bei einer Installation per APT), diesen Pfad zu $PATH<\/strong> hinzuf\u00fcgen (etwa in ~\/.bashrc)<\/p>\n\n\nsudo mkdir \/opt\/nodejs-18\nsudo chown $USER:$USER -R \/opt\/nodejs-18\nmv node-v18.17.0-linux-arm64\/* \/opt\/nodejs-18\/\nsed -i '1s#^#PATH=$PATH:\/opt\/nodejs-18\/bin\\n#' ~\/.bashrc\n. ~\/.bashrc\n\n$ node -v\nv18.17.0\n$ which node\n\/opt\/nodejs-18\/bin\/node\n<\/pre>\n<\/div>\nWir installieren APT und jeglichen anderen Paketmanagern vorbei – das ist Vorteil und Nachteil zugleich: Positiv ist die Flexibilit\u00e4t. Wir k\u00f6nnten beispielsweise in \/opt\/nodejs-20<\/strong> problemlos die neuere (nicht LTS-Version) 20 ablegen. Zwar nicht global per $PATH <\/strong>nutzbar. Aber das w\u00fcrde etwa erm\u00f6glichen, die 18 LTS f\u00fcr produktive Software zu nutzen. W\u00e4hrend parallel mit 20 experimentiert wird: Neue Funktionen ausprobieren, eine m\u00f6glicherweise selbst entwickelte Anwendung auf die neue Version migrieren, usw. Nach dem gleichen Schema lie\u00dfe sich auch eine \u00e4ltere Version installieren, falls ein einzelnes Programm noch nicht mit 18 kompatibel ist. Es h\u00e4ngt also nicht mehr alles zusammen, sondern wir k\u00f6nnen flexibel verschiedene Versionen einsetzen, wie es f\u00fcr den Anwendungszweck notwendig\/sinnvoll ist.<\/p>\nWarum ist diese Methode schlecht?<\/h3>\n
Was ist daran schlecht? Nun, durch diesen Vorteil erhalten wir eben auch keine zentralen Aktualisierungen per APT oder einer anderen Paketverwaltung. Der Verantwortliche muss sich selbstst\u00e4ndig \u00fcber neue Versionen informieren – etwa, in dem er den Node.js Blog regelm\u00e4\u00dfig aufruft<\/a>. Sind Updates verf\u00fcgbar, m\u00fcssen alle eingesetzten Versionen aktualisiert werden. Das ist machbar, vor allem wenn man sich mit Hilfsmitteln vor dem Vergessen sch\u00fctzt: Beispielsweise durch Abonnieren des RSS-Feeds vom Node.js Blog, damit man die Aktualisierungen beim morgendlichen Lesen der Feeds auf jeden Fall sieht. <\/p>\nDie Praxiserfahrung zeigt jedoch: Viele nehmen das nicht so ernst. Nach ein paar Monaten wird vergessen, dass man da ja was h\u00e4ndisch installiert hatte. Mangels Dokumentation f\u00e4llt es dann leider meist erst auf, wenn z.B. die auf Node laufende Software aktualisiert wurde und mit der inzwischen alten Laufzeitumgebung nicht mehr kompatibel ist. Oder noch viel schlimmer: Durch die fehlenden Aktualisierungen sind Schwachstellen vorhanden, die von einem Angreifer ausgenutzt werden.<\/p>\n
Ich setze diesen Weg nur auf einem Buildserver ein, der mehrere Node.js Laufzeitumgebungen (alle LTS) ben\u00f6tigt. Diese haben keine direkte Verbindung zum Internet, ich verfolge die neuen Ver\u00f6ffentlichungen und spiele Aktualisierungen mittels Ansible zeitnah ein.<\/p>\n
Fazit<\/h3>\n
Mit den offiziellen Paketquellen erh\u00e4lt man oft von Anfang an eine alte Version, \u00fcber die manuelle Version wird sie leicht schleichend und unbemerkt alt – so k\u00f6nnte man die Problematik in einem Satz zusammen fassen. Je nach Einsatzzweck sind die daraus entstehenden Probleme sowie Risiken geringer oder h\u00f6her. Ich pers\u00f6nlich rate vom Einsatz veralteter Software ab und pl\u00e4diere daf\u00fcr, Aktualisierungen so zeitnah wie m\u00f6glich einzuspielen. Die offiziellen Paketquellen disqualifizieren sich daher leider komplett. <\/p>\n
Bei Variante 2 ist es schon schwieriger: Hier hat man eine recht flexible und sichere M\u00f6glichkeit, wenn man sich konsequent um die Pflege k\u00fcmmert – was jedoch leicht vergessen wird. Auch das w\u00fcrde ich daher meiden, au\u00dfer es ist unvermeidbar und man wei\u00df genau, was man tut. F\u00fcr viele Szenarien gibt es bessere Alternativen, wie etwa der Einsatz von Containern. Hier kann man relativ leicht Sicherheitsupdates und Bugfixes automatisch mit Watchtower einspielen lassen<\/a>.<\/p>\n
\n","protected":false},"excerpt":{"rendered":"Node.js brachte Googles V8 Engine vom Web auf den Desktop und Server. L\u00e4ngst wird die Plattform auch auf dem Raspberry Pi eingesetzt. Es gibt viele Wege, wie man Node.js auf dem Raspberry Pi oder auf (Debian) Servern installieren kann. Nicht alle davon sind empfehlenswert. In diesem Beitrag zeige ich euch zwei Wege, die ich nicht …<\/p>\n","protected":false},"author":5,"featured_media":10808,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[671,61],"tags":[817],"class_list":["post-10800","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-raspberry-pi","category-softwareentwicklung","tag-nodejs"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/10800","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=10800"}],"version-history":[{"count":3,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/10800\/revisions"}],"predecessor-version":[{"id":10809,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/10800\/revisions\/10809"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/10808"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=10800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=10800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=10800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}