# PHP-Update 7.4 auf 8.x

**URL:** <https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922>\
**Category:** Deutsches Forum\
**Created:** [January 22, 2023, 1:08pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922 "2023-01-22T13:08:46Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mirko\_R](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/m/bbce88/32.png) [@Mirko\_R](https://forum.oxid-esales.com/u/Mirko_R)\
**Post date:** [January 22, 2023, 1:08pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/1 "2023-01-22T13:08:47Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![rubbercut](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/rubbercut/32/3520_2.png) [@rubbercut](https://forum.oxid-esales.com/u/rubbercut)\
**Post date:** [January 22, 2023, 1:40pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/2 "2023-01-22T13:40:33Z")

</div>

Vergleich der Systemvoraussetzungen:

Mach ein Shopupdate auf V6.4.3. Die Anleitung findest bei Eingabe der Begriffe in G00gle.

---

<div class="post-metadata">

**Author:** ![Mirko\_R](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/m/bbce88/32.png) [@Mirko\_R](https://forum.oxid-esales.com/u/Mirko_R)\
**Post date:** [January 22, 2023, 2:06pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/3 "2023-01-22T14:06:40Z")

</div>

das Update von 6.2.3 wollte ich wie hier beschrieben durchführen: [Minor Update installieren — OXID eShop 6.4 | Anwenderdokumentation](https://docs.oxid-esales.com/eshop/de/6.4/installation/update/minor-update.html)

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

---

<div class="post-metadata">

**Author:** ![rubbercut](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/rubbercut/32/3520_2.png) [@rubbercut](https://forum.oxid-esales.com/u/rubbercut)\
**Post date:** [January 22, 2023, 9:59pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/4 "2023-01-22T21:59:02Z")

</div>

> [@Probleme bei update auf 6.2](https://forum.oxid-esales.com/t/probleme-bei-update-auf-6-2/98061/16):
>
> OK, es könnte tatsächlich der Memory sein. Du kannst versuchen, COMPOSER\_MEMORY\_LIMIT=-1 vor den Composer-Befehl zu setzen.

---

<div class="post-metadata">

**Author:** ![Thomas\_Dartsch](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/thomas_dartsch/32/2005_2.png) [@Thomas\_Dartsch](https://forum.oxid-esales.com/u/Thomas_Dartsch)\
**Post date:** [January 23, 2023, 8:01am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/5 "2023-01-23T08:01:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Mirko\_R](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/m/bbce88/32.png) [@Mirko\_R](https://forum.oxid-esales.com/u/Mirko_R)\
**Post date:** [January 23, 2023, 8:52am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/7 "2023-01-23T08:52:08Z")

</div>

der bestehende Shop ist V6.2.3 unter PHP 7.4, die Composer-Version ist 2.0.8

---

<div class="post-metadata">

**Author:** ![Mirko\_R](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/m/bbce88/32.png) [@Mirko\_R](https://forum.oxid-esales.com/u/Mirko_R)\
**Post date:** [January 23, 2023, 8:53am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/8 "2023-01-23T08:53:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Thomas\_Dartsch](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/thomas_dartsch/32/2005_2.png) [@Thomas\_Dartsch](https://forum.oxid-esales.com/u/Thomas_Dartsch)\
**Post date:** [January 23, 2023, 9:50am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/9 "2023-01-23T09:50:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rubbercut](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/rubbercut/32/3520_2.png) [@rubbercut](https://forum.oxid-esales.com/u/rubbercut)\
**Post date:** [January 23, 2023, 11:12am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/10 "2023-01-23T11:12:43Z")

</div>

> [@Mirko\_R](#):
>
> funktioniert leider beides nicht:

**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

```auto
usr/bin/php7.4-cli -d memory_limit=-1 composer.phar update --no-plugins --no-scripts --no-dev

```

Quelle: [https://getcomposer.org/](https://getcomposer.org/)

---

<div class="post-metadata">

**Author:** ![Mirko\_R](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/m/bbce88/32.png) [@Mirko\_R](https://forum.oxid-esales.com/u/Mirko_R)\
**Post date:** [January 23, 2023, 11:36am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/11 "2023-01-23T11:36:52Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rubbercut](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/rubbercut/32/3520_2.png) [@rubbercut](https://forum.oxid-esales.com/u/rubbercut)\
**Post date:** [January 23, 2023, 1:10pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/12 "2023-01-23T13:10:02Z")

</div>

Puuh. Dann fällt mir nur noch ein, dass Du es mit Löschen oder Umbennen der composer.lock versuchen kannst.

---

<div class="post-metadata">

**Author:** ![Mirko\_R](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/m/bbce88/32.png) [@Mirko\_R](https://forum.oxid-esales.com/u/Mirko_R)\
**Post date:** [January 24, 2023, 7:53am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/13 "2023-01-24T07:53:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Thomas\_Dartsch](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/thomas_dartsch/32/2005_2.png) [@Thomas\_Dartsch](https://forum.oxid-esales.com/u/Thomas_Dartsch)\
**Post date:** [January 24, 2023, 8:07am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/14 "2023-01-24T08:07:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Mirko\_R](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/m/bbce88/32.png) [@Mirko\_R](https://forum.oxid-esales.com/u/Mirko_R)\
**Post date:** [January 24, 2023, 11:25am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/15 "2023-01-24T11:25:35Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![heinz.klauke](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@heinz.klauke](https://forum.oxid-esales.com/u/heinz.klauke)\
**Post date:** [January 24, 2023, 11:42am UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/16 "2023-01-24T11:42:24Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Thomas\_Dartsch](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/thomas_dartsch/32/2005_2.png) [@Thomas\_Dartsch](https://forum.oxid-esales.com/u/Thomas_Dartsch)\
**Post date:** [January 24, 2023, 2:08pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/17 "2023-01-24T14:08:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Thomas\_Dartsch](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/thomas_dartsch/32/2005_2.png) [@Thomas\_Dartsch](https://forum.oxid-esales.com/u/Thomas_Dartsch)\
**Post date:** [January 24, 2023, 2:16pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/18 "2023-01-24T14:16:06Z")

</div>

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](https://www.profihost.com/managed-server-services/)

---

<div class="post-metadata">

**Author:** ![heinz.klauke](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@heinz.klauke](https://forum.oxid-esales.com/u/heinz.klauke)\
**Post date:** [January 24, 2023, 3:07pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/19 "2023-01-24T15:07:23Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![Thomas\_Dartsch](https://forum.oxid-esales.com/user_avatar/forum.oxid-esales.com/thomas_dartsch/32/2005_2.png) [@Thomas\_Dartsch](https://forum.oxid-esales.com/u/Thomas_Dartsch)\
**Post date:** [January 24, 2023, 3:10pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/20 "2023-01-24T15:10:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![heinz.klauke](https://forum.oxid-esales.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@heinz.klauke](https://forum.oxid-esales.com/u/heinz.klauke)\
**Post date:** [January 24, 2023, 3:18pm UTC](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922/21 "2023-01-24T15:18:58Z")

</div>

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,

[Next page](https://forum.oxid-esales.com/t/php-update-7-4-auf-8-x/98922.md?page=2)
