Hi. Hab das Gleiche vor (auch wenn ich evtl. schon etwas weiter bin). Den oben gezeigten Fehler habe ich beheben können indem ich im Application root verzeichnis eine neue Datei .npmrc mit folgendem Inhalt angelegt habe:
scripts-prepend-node-path=trueDadurch konnte ich schonmal die dependencies ohne Fehlermeldung installieren. Sobald ich nun aber directus bootstrap oder directus start ausführen will kommt immer diesen Fehler:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /var/www/vhosts/<...>/node_modules/argon2/lib/binding/napi-v3/argon2.node)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! directus-test@1.0.0 start: `npx directus start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the directus-test@1.0.0 start script.Kennt jemand hierzu eine Lösung?
Hab den obigen Fehler nun auch gefixed bekommen, indem ich npm rebuild argon2 --build-from-source ausgeführt habe. Jetzt kann ich wenigstens schonmal directus bootstrap ausführen und directus start scheint auch zu funktionieren beim ersten Aufruf (blöderweise sieht man die Ausgabe ja nicht, da der Server dann läuft und das Skript nicht beendet wird.) Irgendwie lässt sich die Directus-Seite aber immer noch nicht aufrufen. Gibt immer nur einen Fehler von Passenger bzw. seit neustem gibt es komischerweise immer 403-Fehler...
Nochmal eine Statusmeldung:
Mittlerweile funktioniert es endlich. Habe bei application mode einmal die andere Option genommen dann ging es. Komischerweise geht es jetzt auch weiterhin, selbst wenn ich wieder auf production (die ursprüngliche Option) umstelle. Naja, hauptsache es tut jetzt. 
Falls jemand nochmal eine genaue Anleitung haben will: Meine Installationsanleitung ist auf der Directus Website veröffentlicht: https://docs.directus.io/guides/installation/plesk/
Ich schließe einmal hier an, weil dieser Thread die einzige Quelle zum Thema ist (abgesehen von der aus ihm erwachsenen Dokumentationsseite). Ich meinerseits scheitere leider an der Ausführung von `npm rebuild argon2 --build-from-source` . Wenn ich den Befehl so laufen lasse, beschwert sich C++ :
../src/argon2_node.cpp:52:25: error: invalid conversion from 'const unsigned char*' to 'uint8_t* {aka unsigned char*}' [-fpermissive]
ctx.pwd = plain.data();
~~~~~~~~~~^~
../src/argon2_node.cpp:54:25: error: invalid conversion from 'const unsigned char*' to 'uint8_t* {aka unsigned char*}' [-fpermissive]
ctx.salt = salt.data();
~~~~~~~~~^~
../src/argon2_node.cpp:56:38: error: invalid conversion from 'const unsigned char*' to 'uint8_t* {aka unsigned char*}' [-fpermissive]
ctx.secret = opts.secret.empty() ? nullptr : opts.secret.data();
~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/argon2_node.cpp:58:30: error: invalid conversion from 'const unsigned char*' to 'uint8_t* {aka unsigned char*}' [-fpermissive]
ctx.ad = opts.ad.empty() ? nullptr : opts.ad.data();
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Release/obj.target/argon2/src/argon2_node.o] Error 1Interessanter wird es, wenn ich die node binary direkt angebe: `/opt/plesk/node/17/bin/npm rebuild argon2 --build-from-source`. Dann beschwert sich gyp über eine zu niedrige Python-Version:
npm ERR! gyp ERR! find Python checking if "python3" can be used
npm ERR! gyp ERR! find Python - executable path is "/usr/bin/python3"
npm ERR! gyp ERR! find Python - version is "3.5.3"
npm ERR! gyp ERR! find Python - version is 3.5.3 - should be >=3.6.0
npm ERR! gyp ERR! find Python - THIS VERSION OF PYTHON IS NOT SUPPORTED
npm ERR! gyp ERR! find Python checking if "python" can be used
npm ERR! gyp ERR! find Python - executable path is "/usr/bin/python"
npm ERR! gyp ERR! find Python - version is "2.7.13"
npm ERR! gyp ERR! find Python - version is 2.7.13 - should be >=3.6.0
npm ERR! gyp ERR! find Python - THIS VERSION OF PYTHON IS NOT SUPPORTED
Kann man da irgend etwas machen oder muss ich davon ausgehen, dass ich Directus auf meinem Shared Hosting (ebenfalls 4000SE) nicht werde einsetzen können?
Hi Phylax, da bin ich vor kurzem auch drüber gestolpert. Grund ist die neue Version 0.28.3 von argon2. Damit rennt man komischerweise in diesen Fehler. Du kannst aber stattdessen einfach die vorherige Version erzwingen, indem du folgenden Befehl ausführst: npm install argon2@0.28.2 --build-from-source
Siehe auch diese Diskussion: https://github.com/ranisalt/node-argon2/issues/328
Damit klappt es bei mir wieder mit der aktuellen Directus Version 9.4.2.
Ich habe eben Directus v9.5.1 auf meinem Webhosting 4000 Paket ans Laufen bekommen, und wollte nur nochmal ein paar Punkte erwähnen, die ich hier bisher nicht gesehen habe:
"scripts": {
[...]
"argon": "npm rebuild argon2 --build-from-source",
"sharp": "npm install --platform=linux --arch=x64 sharp"
},Was mich außerdem irritiert hat, ist, dass eine Änderung der Umgebungsvariablen auch nach einem App-Neustart nicht sofort angewendet werden. Wenn ihr also Einstellungen ändert und euch wundert, warum nichts passiert, probiert es am besten einfach ein bisschen später nochmal.
Guten Abend, gern würde ich auch Directus installieren, komme aber nicht weiter... Deshalb erstelle ich hier mal eine Schritt-für-Schritt Anleitung:
(1) Ich habe folgende Version heruntergeladen und per FTP auf den Server kopiert: https://github.com/directus/directus/releases/tag/v9.5.1
(2) Ich habe begonnen die Anleitung durchzuarbeiten: https://docs.directus.io/getting-started/installation/plesk/
Node 14.17.5 gibt es nicht zur Auswahl ... deshalb nehme ich Node 14.19 ... da in der "package.json" höhere Versionen für Node und npm gefordert werden ... passe ich die an
Leider kommen Fehlermeldungen:
NPM Error log siehe Anhang
npm_errorlog.zip
Bei Zugriff auf Webseite meldet Phusion Passenger:
internal/modules/cjs/loader.js:905 throw err; ^
Error: Cannot find module 'directus/server'
Require stack:
- /var/www/vhosts/hostingXXX.ae828.netcup.net/httpdocs/directus/index.js
- /usr/share/passenger/helper-scripts/node-loader.js at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15) at Function.Module._load (internal/modules/cjs/loader.js:746:27) at Module.require (internal/modules/cjs/loader.js:974:19) at Module.require (/usr/share/passenger/helper-scripts/node-loader.js:80:25) at require (internal/modules/cjs/helpers.js:101:18) at Object.<anonymous> (/var/www/vhosts/hostingXXX.ae828.netcup.net/httpdocs/directus/index.js:1:23) at Module._compile (internal/modules/cjs/loader.js:1085:14) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10) at Module.load (internal/modules/cjs/loader.js:950:32) at Function.Module._load (internal/modules/cjs/loader.js:790:12) { code: 'MODULE_NOT_FOUND', requireStack: [ '/var/www/vhosts/hostingXXX.ae828.netcup.net/httpdocs/directus/index.js', '/usr/share/passenger/helper-scripts/node-loader.js' ]
}Leider kommt eine Fehlermeldung…
*ENDE*
Ich hasse es wenn solche spannenden Geschichten als Mehrteiler verfilmt werden!
Morgen kommt dann: "Was bisher geschah ..." 
Zwischenzeitlich hat es funktioniert mit folgenden Schritten:
Anleitung siehe: https://docs.directus.io/getting-started/installation/plesk/
package.json
{
"scripts": {
"apply-snapshot--noninteractive": "npx directus schema apply --yes ./snapshots/\"$npm_config_filename\"",
"argon2-rebuild": "npm rebuild argon2 --build-from-source",
"sharp": "npm install --platform=linux --arch=x64 sharp",
"bootstrap": "directus bootstrap",
"start": "npx directus start"
},
"dependencies": {
"directus": "*",
"mysql": "^2.18.1"
}
}index.js
var { startServer } = require('directus/server');
startServer();.npmrc
scripts-prepend-node-path=true.env
MySQL Daten eingeben; bei Zeilen für PostGres # vorsetzen, dafür bei MySQL 8 die # löschen
Wie sieht es bei euch eigentlich mit der Performance aus? Bei mir lädt Directus zurzeit eeewig, und als wäre das schon nicht genug, kommt dann oft auch nur eine weiße Seite oder dieser nervige Fehler von Passenger:
An anderen Tagen läuft es dann aber hin und wieder ganz gut.
Der Netcup-Support ist dabei leider gar keine Hilfe. Die sagen immer nur, dass die Serverlast zurzeit allgemein gering ist und keine Probleme bekannt sind. Was halt etwas komisch ist, ist dass selbst zu den Zeiten in denen Directus nicht erreichbar ist, meine parallel installierte Nextcloud (die wahrscheinlich nicht weniger Serverlast erzeugt) gar keine Probleme macht...
Abseits von dem Debug application mode habe ich bisher auch leider keine Möglichkeit gefunden an evtl. detailliertere Passenger-Logs zu kommen.
Das Ganze macht auf mich den Eindruck, dass die Node.js-Unterstützung immer noch ziemlich schäbig ist 
Ich hatte Directus mit der Hilfe dieses Forums auch zum Laufen gebracht. Mit der Performance war ich aber auch nicht zufrieden. Anscheinend legt sich die Anwendung bei Lastpausen schlafen und wacht erst bei Zugriffen wieder auf. Oft konnten einige Dinge nicht nachgeladen werden. Also insgesamt überschaubarer Erfolg.
Strapi scheint ja auch so ein Kandidat zu sein, den man nur mit Mühe zum Laufen bringen kann. Und Netcup anzubeten oder anzuflehen, eine bessere Node.JS-Unterstützung bereitzustellen, hilft auch nicht. Daher probiere ich gerade folgenden Ansatz, der vielversprechender aussieht:
* Download des NodeJS Binary Pakets und auspacken in /nodejs/node-v14.20.0-linux-x64. Alternativ habe ich auch node-v16.16.0-linux-x64. Aber da scheint npm einen Bug zuhaben. Ich würde die Version wählen, die man im Webhosting auswählt.
* Path erweitern in ~/.profile um /nodejs/node-v14.20.0-linux-x64/bin
* Nach einem neuen Login in der Shell kann npm, npx und was auch immer mit NodeJS in der Konsole alles möglich ist,innerhalb eines Webhosting Accounts ausgeführt werden.
* Grundsätzlich geht das auch mit Python (für Flask oder Django z.B:), was auch hier im Forum irgendwo dokumentiert ist.
Aktuell hatte ich Strapi schon einwandfrei zum Laufen gebracht. Ich lerne noch. Deswegen ist mir dann irgend ein Fehler unterlaufen, den ich gerade untersuche. Das wird schon wieder. Dennoch lief es schon mal ziemlich gut und sehr flott auf einem Webhosting 4000. Ich wollte das hier nur als einen weiteren Weg für ein Headless CMS aufzeigen.
Folgende Eigenheiten würde ich beachten:
* mit dem Quickstart-Kommando wird eine index.js (Anwendungsdatei) hinterlegt, wo ein Bootstrapping vorgeschaltet ist. Das scheint mit Netcups Webhosting nicht zu funktionieren. Alternative Konfigurationen gibt es in der Strapi-Doku (letzter Code-Schnipsel).
* Einige Konfigurationsänderungen erfordern ein Rebuild der Adminoberfläche. Wenn man das vergisst, hagelt es Fehler.
* All das ist aber gut dokumentiert.
* Es kann vorkommen, dass das npm-Modul Sharp nicht installiert wird (Logging beobachten). Das lässt sich dank der Shell aber einfach nachziehen mit: npm install --ignore-scripts=false --foreground-scripts --verbose sharp
* Und Strapi verfolgt einen anderen Ansatz als Directus: Also Development auf einem Client und Übertragen des Datenmodells auf den Server. Zeitgleich entwickeln und veröffenlichen wie Directus es tut, sehen die Entwickler nicht vor.
Hier noch die Einstellungen für das Netcup Webhosting:
Nachtrag: jetzt habe ich meinen Fehler auch gefunden: Bei der Installation und beim Rebuild der Admin-Oberfläche mit npm taucht in der Konsole hin und wieder "/bin/sh: hostname: command not found" auf. Ich hatte das ignoriert. Beim Rebuild setzt das Script dann in der Konfigurationsdateie den Hostnamen auf 0.0.0.0. Das scheint eine Begrenzung in der Shell des Webhostings zu sein. Wenn ich die IP 0.0.0.0 in der config/server.js mit der Subdomain meines Webhostings ersetze und ein npm run build läuft alles wieder einwandfrei:
Ganz dumme Frage:
Da hier offenbar ein paar Leute vertreten sind, die Node.js im Webhosting 4000 oder 8000 verwenden, wollte ich mal fragen: Kann das Paket dann auch mehrere Node.js Anwendungen hosten, z.B. unter verschiedenen URLs oder Subdomains? Oder nur 1 einzige Node.js App pro Domain/Webhosting-Paket?
Beispiel (URLs):
Node.js App1 -> http://meinedomain.de/app1
Node.js App2 -> http://meinedomain.de/app2
Beispiel (Subdomains):
Node.js App1 -> http://app1.meinedomain.de
Node.js App2 -> http://app2.meinedomain.de
Da blöderweise NetCup bei den Webhosting-Paketen keine Auswahl zwischen monatlicher und jährlicher Abrechnung anbietet (was ich sehr dünn finde), kann ich das nicht mal so einfach kurz selbst ausprobieren, ohne mich gleich 12 Monate zu verpflichten. Und ich hab halt noch nicht einmal gesehen, wie überhaupt die Web-Konfigurations-UI für eine Node.js App bei NetCup aussieht.
Und falls jemand die Frage wirklich sehr dumm vorkommt: Ich bin damit schon bei [Name von großem deutschen Hosting-Anbieter mit I] und ASP.NET Core Hosting ganz mies reingefallen. Kommt also nicht von ungefähr.
Da blöderweise NetCup bei den Webhosting-Paketen keine Auswahl zwischen monatlicher und jährlicher Abrechnung anbietet (was ich sehr dünn finde), kann ich das nicht mal so einfach kurz selbst ausprobieren, ohne mich gleich 12 Monate zu verpflichten.
Doch, kannst du.
Für Webhostings gilt die Zufriedenheitsgarantie. (Schau mal auf der Angebotsseite der Hostings. Da steht das ganz unten) Du kannst das Produkt also tatsächlich ausprobieren und falls du nicht damit zufrieden bist, innerhalb von 30 Tagen stornieren.
(Diese Garantie gilt auch für Rootserver, aber nicht für VPS)
und das gesetzliche Wiederufrecht gibt es ja auch noch.
(Auch wenn schlechter als die Garantie - dafür aber gesetzlich immer vorhanden)
Just saying:
https://docs.directus.io/self-hosted/installation/docker/ -> Docker Compose File anpassen und die Sache läuft.
Na sowas, ich wusste gar nicht, dass Docker auch in einem Webhosting läuft.
Joa, wäre halt was für nen kleinen Server. Läuft vermutlich auch performanter.
FYI: Ich habe Directus jetzt mal zum Vergleich auf dem kleinsten angebotenen VPS-Server installiert (VPS 200 G10s). Da gibt es bisher gar keine Probleme und es lädt alles schön schnell (mit kopierter Datenbank vom Webhosting).
