Magento 2.4.2 installieren über SSH

Da wir gerade eine Anfrage diesbezüglich hatten – ab Magento Version 2.4 kann man die Installation von Magento nicht mehr wie von vorigen Versionen gewohnt über den Browser durchführen. In einem früheren Artikel (HIER) hatte ich bereits über die Vorbereitungen einer Magento-Installation mit Composer informiert. Dieser Artikel endete damit, dass man die Installation nun durch Aufruf der zu verwendenden und im Hosting hinterlegten und auf das Magento-Root-Verzeichnis verweisenden Domain installieren würde.

Dies geht nun also nicht mehr und wenn man die Domain aufruft, erhält man eine Info, dass es einen Umleitungsfehler gibt und die URL domain.xyz/pub/setup nicht erreicht werden kann.

Ruft man dann die URL domain.xyz/setup auf, bekommt man dann die nicht sehr viel aussagekräftigere Meldung “Welcome to Magento Admin, your online store headquarters.
Please review Terms & Agreement and read Getting Started to learn how to install Magento using the command line.”

Klickt man nun auf den Link zu “Getting Started” wird man auf die “Advanced Install” Seite geleitet, die attestiert, dass man per SSH / CLI installieren muss.

(KURZE Zwischennotiz mit der Bitte auch noch das P.S. unten zu berücksichtigen, da es VIELLEICHT eine weitere Möglichkeit gibt.) Darauf werde ich nun nicht weiter eingehen, sondern den konkreten Weg beschreiben, der nun also notwendig ist, um Magento 2.4.x zu installieren. Mit folgendem Befehl, der zu großen Teilen natürlich zu editieren ist, wird die eigentliche Magento-Installation durchgeführt:

php bin/magento setup:install --base-url="https://domain.xyz/" --db-host="localhost" --db-name="hierderdbname" --db-user="hierderdbuser" --db-password="hierdasdbpasswort" --admin-firstname="admin" --admin-lastname="istrator" --admin-email="admin@emailadresse.xyz" --admin-user="admin" --admin-password="admin123" --language="de_DE" --currency="EUR" --timezone="Europe/Berlin" --use-rewrites="1" --backend-frontname="hierdieadminurlhinterdomain.xyz" --search-engine="elasticsearch7" --elasticsearch-host="localhost" --elasticsearch-port="9200" --elasticsearch-index-prefix="shopprefix"

Dies ist natürlich ein ziemlich umfangreicher (und lange noch nicht mit allen Möglichkeiten ausgeschöpfter) Befehl. Genaue Angaben gibt es auf der Magento-Seite. Und natürlich kann es auch abweichende Angaben geben. Für Magento 2.4.2 ist Elasticsearch Voraussetzung. Wir verwenden Version 7. Wer Version 6 verwendet, trägt eben 6 ein. Bei den einzelnen Angaben einfach schauen, was für einen selber notwendig ist.

Sidenote:
Da man auch schnell Probleme mit dem Elasticsearch-Zugriff bekommen kann (Magento prüft dies bei der Installation), kann man im Falle von Problemen oder vor der Installation direkt per SSH die mögliche Verbindung zum Elasticsearch-Dienst testen. Dazu folgenden Befehl verwenden:
curl -XGET https://localhost:9200
Sollte nun der ES-Server nicht local sein, sondern extern, kann man natürlich auch
curl -XGET https://pfadzumelasticsearchserver.xyz:9200
verwenden. Werden dann noch Benutzername und Passwort verlangt, kann es auch so sein
curl -XGET https://benutzername:passwort@pfadzumelasticsearchserver.xyz:9200
Und zuletzt kann natürlich auch der Port abweichend von 9200 sein. In diesem Fall den vom Hoster angegebenen Port verwenden. Bei Rackspeed war es im konkreten Fall der Port 443

Sollte die Installation dann durchgelaufen sein, kommt meist das nächste Problem. Ruft man die URL auf auf der der Shop nun verfügbar sein sollte, bekommt man meist ein 404 – Seite nicht gefunden. Na – herzlichen Dank! Warum kann eigentlich nichts einfach mal funktionieren?

Hierfür ist eine Neuerung ab Magento 2.4.2 verantwortlich, die laut Magento das Sicherheitsniveau erhöhen soll. Es gibt hierzu auch eine offizielle Anleitung, die einem mitteilt, dass man einen “Virtual Host” erstellen soll.

Unser Hoster hat uns folgenden Workaround empfohlen und umgesetzt:

1. Erstellung eines neuen Ordners im Webspace (außerhalb des aktuellen Rootfolders. Beispiel: Wir haben das Verzeichnis public_html verwendet für die Magento-Installation. Die Domain verweist auf dieses Verzeichnis. Nun wurde auf derselben Verzeichnisebene ein neues Verzeichnis erstellt, so dass “public_html” und “neuesverzeichnis” auf derselben Ebene sind.)
2. Alle Magento-Daten aus dem aktuellen Verzeichnis (bei mir “public_html”) in das eben erstellte Verzeichnis verschieben.
3. Entfernen des alten Ordners (hier “public_html”) und Erstellung eines Symlinks (“Verknüpfung”) “public_html” (auf die sich dann die Domain bezieht), der auf das Verzeichnis und dort den Unterordner “pub” verweist (also beispielsweise “neuesverzeichnis/pub”). Man muss sich dafür im Root-Verzeichnis des Servers befinden bzw. da wo die Domain hinzeigt. Per SSH wäre der Befehl bspw.

ln -s neuesverzeichnis/pub public_html

Das entspricht der Logik zuerst den kompletten Pfad zum gewünschten Ziel zu hinterlegen und als nächstes den Pfad zur Verknüpfung / Symlink. Wichtig ist natürlich den korrekten Serverpfad zu berücksichtigen – den aktuellen Pfad kann man übrigens durch Eingabe des Befehls “pwd” per SSH erfahren.

Anschließend sollte Magento dann normal erreichbar sein. In meinem konkreten Fall hatte sich das System noch eine kleine Überraschung einfallen lassen und zeigte bei Aufruf

Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

In diesem Fall dann noch schnell die Datei .maintenance.flag (in Magento 1 hieß sie noch maintenance.flag und war im Root-Verzeichnis) im Verzeichnis var/ löschen.

Das war’s dann “schon”. War doch einfach – oder?

P.S. Was ich nicht probiert habe und noch auf meiner “To-Do-Liste” steht: Es wäre denkbar, dass nach dem Schritt mit dem Symlink (Hier) evtl. auch die Installation per Browser wieder funktioniert und man nicht per SSH installieren muss. Wenn das jemand mal ausprobiert hat, bitte Kommentar hinterlassen.

P.P.S. und nochwas zum Schluss: Achtet darauf, dass Ihr bei der Installation eine funktionierende Mail-Adresse für die Anlage des Administrator-Kontos hinterlegt UND, dass diese Adresse auch Mails von einer Quelle empfangen kann, die nicht über einen SMTP-Server sondern über ein PHP-Skript verschickt wurden. Hintergrund ist, dass man bereits bei der ersten Anmeldung als Administrator -nach Eingabe von Benutzername und Passwort- aufgefordert wird die zwei-Faktor-Autorisierung (2FA) zu aktivieren. Hierzu hat das System gerade eine Mail an die hinterlegte Mail-Adresse gesendet. Funktioniert dies nicht – geht es nur mit einem Workaround.

1. Deaktivierung der 2FA per SSH/CLI: Hierzu gibt man folgenden Befehl ein:

bin/magento module:disable Magento_TwoFactorAuth

Hiermit wird die 2FA generell deaktiviert.

2. Änderung der hinterlegten Mail-Adresse auf eine, die keine so hohen Ansprüche an die Quelle stellt. Bspw. GMX funktioniert bei uns meistens im Gegensatz zu Host Europe. Dies geht am einfachsten über die Datenbank und dort die Tabelle “admin_user” – dort die Mail ändern und nochmals – ggfs. nach Löschen der Cookies oder Verwendung des Privaten Modus’- anmelden.

Tipp

Da Magento 2 ordentlich (nennen wir es mal böse) Bloatware mitbringt, macht es m.E. Sinn nach einer Neuinstallation zu schauen welche Extensions, die Magento direkt mitbringt wirklich sinnvoll sind und welche nicht. Der bekannte Magento-Experte Andreas von Studnitz hat hier eine sehr sinnvolle Funktion geschaffen, die bei Github heruntergeladen werden kann (HIER). Diese erstellt nach Aufruf eine Datei, die alle Funktionen anzeigt, die keine Abhängigkeiten (für den Standard-Betrieb des Shops) haben und deaktiviert werden könnten.

Nach dem Deaktivieren der Extensions lassen sich spürbare Leistungszuwächse gewinnen.
AvS gibt auch gleich noch die Anleitung, wie man seine Extension nach der Nutzung (macht man ja nur einmal) wieder deinstallieren kann. Tolles Tool!

Und noch ein kleiner Tipp, um schnell viele Extensions deaktivieren zu können: Die Datei modules-removable.csv in Excel oder Calc ziehen, eine neue Spalte mit

bin/magento module:disable

füllen und dann diese Spalte und die Spalte mit den Extensionnamen in einer weiteren Spalte zusammenführen.

So kann man dann einfach durch Copy & Paste in Putty die Extensions deaktivieren.