mein Provider (IONOS) unstützt PHP 7.4 bald nicht mehr.
Somit möchte ich meinen Shop (V6.2.3 unter PHP 7.4) nun unter PHP 8.1 (oder 8.2) betreiben.
Gibt es dafür eine Schritt-für-Schritt-Anleitung?
Vergleich der Systemvoraussetzungen:
Mach ein Shopupdate auf V6.4.3. Die Anleitung findest bei Eingabe der Begriffe in G00gle.
das Update von 6.2.3 wollte ich wie hier beschrieben durchführen: Minor Update installieren — OXID eShop 6.4 | Anwenderdokumentation
Beim Aktualisieren der Abhängigkeiten erhalte ich leider nur folgende Meldung:
/usr/bin/php7.4-cli composer.phar update --no-plugins --no-scripts --no-dev
Loading composer repositories with package information
Updating dependencies
mmap() failed: [12] Cannot allocate memory
Fatal error: Out of memory (allocated 612376576) (tried to allocate 4096 bytes) in phar:///homepages/33/xxxx/htdocs/webshop21/composer.phar/src/Composer/DependencyResolver/Solver.php on line 201
Nach dem Update auf OXID 6.2 solltest du unbedingt bei IONOS erst einmal composer auf v2 updaten. Die v1 benötigt extrem viel Arbeitsspeicher für die ganzen dependencies innerhalb des composer-Baums, weswegen diese Meldungen ständig kommen und die Installation permanent abbricht. Leider funktioniert alles unter OXID 6.2 nur mit der v1, so dass du erst einmal den Sprung auf 6.2 machen musst.
der bestehende Shop ist V6.2.3 unter PHP 7.4, die Composer-Version ist 2.0.8
funktioniert leider beides nicht:
/usr/bin/php7.4-cli COMPOSER_MEMORY_LIMIT=-1 composer.phar update --no-plugins --no-scripts --no-dev
oder
/usr/bin/php7.4-cli composer.phar COMPOSER_MEMORY_LIMIT=-1 update --no-plugins --no-scripts --no-dev
das ist ungewöhnlich. Wir hatten mit composer v2 meines Wissens nach nie mehr Probleme mit dem memory_limit. Allerdings kennen wir auch die Server/Accountumgebung von euch bei IONOS nicht. Gut möglich dass hier der Arbeitsspeicher generell aufgestockt werden muss.
Vor composer.phar:
Du kannst es mit -d versuchen:
/usr/bin/php7.4-cli -d COMPOSER_MEMORY_LIMIT=-1 composer.phar update --no-plugins --no-scripts --no-dev
oder
usr/bin/php7.4-cli -d memory_limit=-1 composer.phar update --no-plugins --no-scripts --no-dev
Quelle: https://getcomposer.org/
Leider bleibt es bei beiden Befehlen bei der Fehlermeldung:
Loading composer repositories with package information
Updating dependencies
mmap() failed: [12] Cannot allocate memory
Fatal error: Out of memory (allocated 612376576) (tried to allocate 4096 bytes) in phar:///homepages/33/dxxx/htdocs/webshop21/composer.phar/src/Composer/DependencyResolver/Solver.php on line 201
Puuh. Dann fällt mir nur noch ein, dass Du es mit Löschen oder Umbennen der composer.lock versuchen kannst.
hilft leider auch nicht - jetzt kommt:
mmap() failed: [12] Cannot allocate memory
Fatal error: Out of memory (allocated 612376576) (tried to allocate 4096 bytes) in phar:///homepages/33/dxxxx/htdocs/webshop21/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 53
Frag’ beim Provider, ob du (oder sie) für die Konsole mehr Arbeitsspeicher freigeben kannst. Composer schafft es offensichtlich nicht den gesamten dependency Baum in den für Scripte verfügbaren RAM zu laden.
komischerweise kommt bei einer testweisen Neuinstallation (/usr/bin/php8.1-cli composer.phar create-project --no-dev OXID-esales/oxideshop-project test2 dev-b-6.4-ce) keinerlei Fehlermeldung bzgl. fehlendem Speicher - nur beim Update…
Sind bei Host Europe. Die haben auch ab und an alte PHP - Versionen deaktiviert.
Deswegen hab ich unseren Shop auf einen V-Sever installiert.
Jetzt haben wir unsere eigene Umgebung.
Virtual Server 10.0 - 2vCPU | 4GB RAM | 100GB SSD - Linux 9,99 im Monat.
Zum Testen hab ich noch einen Kleineren
Virtual Server 10.0 - 1vCPU | 2GB RAM | 40GB SSD - Linux 5,99 im Monat
Neben dem Shop hab ich auch einen Mail-Server installiert.
CPU verbrauch 1 %, RAM 26 %.
Wir werden auf den kleineren umziehen.
Ein Zertifikat gibt´s kostenlos bei Let´s Encrypt
Der einzige Unterschied. Um die Hacker muss man sich selber kümmern.
Ufw ist eine gute Firewall. Fail2Ban ist hilfreich.
tatsächlich macht es für den Speicherbedarf einen großen Unterschied, ob man per composer nur ein install oder ein update macht, was deutlich mehr Speicher benötigt.
Der “einzige Unterschied” ist ein ziemlich großer, weswegen betreute Pakete/Server gern das 10fache kosten und dieser Preis auch völlig gerechtfertig ist. Dort musst du dich nicht um die permanenten Aktualisierungen kümmern, die monatlich für eine Einzelperson einen nicht unerheblichen Zeitaufwand bedeuten. Zumal man gern auch Mal nicht weiß man man da gerade tut, wenn irgend ein Systemupdate ansteht und die Strickanleitung von UserXY im Forum für irgendeine Bibliothek nicht das macht was sie machen soll.
DIe Mehrkosten für managed Systeme sollte man ohne viel Nachdenken investieren, wenn der Shop nur halbwegs rentabel ist und man sich mit dem Zeug nicht unbedingt aus Lust und Laune beschäftigen will.
Beispiel: Erfolgreich digitalisieren mit den Managed FlexServern & Services
Ab und an Update / Upgrade.
Das war´s. Im Preis inbegriffen ist sogar noch eine tägliche Sicherung.
Tatsächlich versuchen 50 bis 100 sich über ssh bei uns anzumelden.
Aber die haben noch nicht einmal den richtigen Usernamen.
"sudo cat /var/log/auth.log | grep -a 'Invalid user "
…
Jan 24 08:44:59 151 sshd[2575884]: Invalid user postgres from 77.69.160.249 port 50686
Jan 24 09:37:07 151 sshd[2576576]: Invalid user postgres from 213.110.32.4 port 36045
Jan 24 10:06:27 151 sshd[2577031]: Invalid user gpadmin from 122.117.118.184 port 56374
Jan 24 10:40:13 151 sshd[2577638]: Invalid user guest from 220.132.131.6 port 33102
Jan 24 11:21:35 151 sshd[2578219]: Invalid user clinton from 113.22.192.176 port 52503
Jan 24 12:15:20 151 sshd[2579031]: Invalid user magento from 122.117.162.170 port 43064
Jan 24 13:15:30 151 sshd[2580042]: Invalid user ubuntu from 81.215.196.121 port 38901
Jan 24 13:15:58 151 sshd[2580041]: Invalid user admin from 81.215.196.121 port 38885
Jan 24 14:50:03 151 sshd[2581434]: Invalid user ubnt from 47.50.219.110 port 51670
Jan 24 14:50:31 151 sshd[2581480]: Invalid user pi from 193.242.176.193 port 56060
USW 
das Problem sind nicht die Einträge im log die du siehst. Das sind legilich Script-Kiddies oder automatisierte Scanner, die pauschal die IP-Ranges nach offenen Ports abgrasen. Das Problem sind die Angriffe, die du/das System nicht sehen 
Die meisten (erfolgreichen) Angriffe passieren auch nicht über SSH. Das ist ziemlich stabil. Da funktioniert ein Einbruch nur per Rainbow-Tables und schwachen Passwörtern.
Problematisch sind unsicher konfigurierte Dienste, PHP, MySQL, der Shop selbst oder Wordpress. Darüber kommen Angreifer über Schwachstellen rein und hangeln sich darüber immer tiefer ins System.
WIe gesagt: Erfolgreiche Angriffe siehst du nicht. Wie auch?
Ich würde niemals ein Produktivsystem ohne managed Services betreiben, wenn ich selbst kein hauptberuflicher Sys-Admin bin (was ich nicht bin). Alles andere (persönliche Meinung) ist grob fahrlässig und ggf. ein Fall für die DSGVO. Immerhin hostest du im Zweifel einige tausend aktuelle Kundendaten in der Shop-DB. Das ist pures Gold für Angreifer.
Das aller wichtsigste ist! Sobald das System online ist, muss man UFW installieren und konfigurieren.
Im Kern sind das 3,4 Befehle per Copy Paste.
Dann ist das System gut abgesichert,