Contao Manager installiert nichts

[Marchie]

Hallo zusammen,

Contao 4.4.7 mit Contao Manager 1.0.0-beta15 lässt mich keine Erweiterungen installieren. Die Konsolenausgabe sagt das hier (ich kann das leider nicht interpretieren, sonst würde ich ja keinen Manager nutzen):

Using version ^1.4 for codefog/contao-cookiebar
/html/contao/composer.json has been updated
Loading composer repositories with package information
Updating dependencies
Error: "Out of memory (allocated 209715200) (tried to allocate 1576960 bytes)" in phar:///html/contao/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php on 419

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

In RemoteFilesystem.php line 419:
                                                                               
  [Symfony\Component\Debug\Exception\OutOfMemoryException]                     
  Error: Out of memory (allocated 209715200) (tried to allocate 1576960 bytes  
  )                                                                            
                                                                               
Exception trace:

tenside:runtask [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [--disable-events] [--] <command> <taskId>

Process terminated with exit code 255
Reason: Unknown error 

Wenn ich auf "Prüfen und Installieren" eines Pakets klicke, bekomme ich sofort einen Hinweis auf "Änderungen" die mir nicht klar sind. Dann kann ich nur noch "Änderungen anwenden" klicken (siehe Screenshot manager.PNG anbei) und dann rödelt er bis zum "Unknown error" :-(

Hat jemand eine Idee was hier los ist? Danke im Vorraus!

[Spooky]

Welcher Hoster? Bei deinem Hoster wird der Arbeitsspeicher stark limitiert, daher kannst du direkt am Server keine Erweiterungen installieren.

[Marchie]

danke für den Hinweis. Bin im Gespräch / Ticket mit dem Hoster :-) Werde berichten ....

[Marchie]

Okay, folgendes bislang rausgefunden:

Installationen bei denen bislang der Contao-Manager problemlos funktionierte, machen alle Probleme seit dieser auf die Versione 1.0.0-beta15 upgedated werden musste. (Ich kann den Manager ja überhaupt nicht starten ohne das Update zu machen.) Und danach in allen Installationen das o.g. Problem.

Ist jemand in der Lage, was dazu zu sagen?

[Spooky]

Mit der Version des Contao Managers hat dein Problem nichts zu tun. Der zur Verfügung stehende Speicher für die Prozesse, die der Contao Manager erzeugt, ist wie schon gesagt auf deinem Server einfach zu wenig.

[Marchie]

Seltsam, denn zuvor hat der Manager ja funktioniert und ich konnte problemlos Erweiterungen installieren. Ich habe das inzwischen bei mehreren Installationen rekonstruiert. Und dann Manager auf die neue Version und nix geht mehr.

[mlweb]

Welcher Provider? Hast Du ssh-Zugriff?

Insgesamt werden aber m.E. grundsätzlich mit der Zeit die vorhandenen Abhängigkeiten die geprüft werden müssen immer mehr, auch wenn Du gar nichts "neues" installiert hast.

[Marchie]

Mittwald und ja ich könnte SSH einrichten, aber ich möchte ja eigentlich gerne den Manager WIEDER nutzen.

[mlweb]

Man könnte mit ssh aber schauen ob ein Update dort durchläuft.

[Spooky]

Seltsam, denn zuvor hat der Manager ja funktioniert und ich konnte problemlos Erweiterungen installieren.

Wie gesagt, das Problem hat nichts mit dem Contao Manger direkt zu tun.

Ich habe das inzwischen bei mehreren Installationen rekonstruiert. Und dann Manager auf die neue Version und nix geht mehr.

Beschreibe die Reproduktionsschritte genauer.

[Marchie]

Wie gesagt, das Problem hat nichts mit dem Contao Manger direkt zu tun.

Verstehe ich nicht, wenn sich nichts außer der Contao Manager Version geändert hat?????????

Beschreibe die Reproduktionsschritte genauer.

OK, ich versuche mal: hatte bspw. eine Contao 4.4.x am Laufen zusammen mit dem Contao Manager 1.0.0-beta13. Damit habe ich auch bereits Erweiterungen problemlos installiert. Öffne ich jetzt den CM MUSS ich diesen updaten auf 1.0.0-beta15. Ohne dieses Update komme ich gar nicht weiter. Das Update läuft auch problemlos durch. Aber danach kann ich über den CM nichts mehr installieren. Egal welche Erweiterung ich installieren möchte, die Konsolenansicht spuckt immer o.g. Fehler aus.

[Spooky]

Verstehe ich nicht, wenn sich nichts außer der Contao Manager Version geändert hat?????????

Administrierst du den Server selbst? Wenn nein, dann kannst du nicht davon ausgehen, dass sich auf jeden Fall nichts geändert hat

OK, ich versuche mal: hatte bspw. eine Contao 4.4.x am Laufen zusammen mit dem Contao Manager 1.0.0-beta13. Damit habe ich auch bereits Erweiterungen problemlos installiert. Öffne ich jetzt den CM MUSS ich diesen updaten auf 1.0.0-beta15. Ohne dieses Update komme ich gar nicht weiter. Das Update läuft auch problemlos durch. Aber danach kann ich über den CM nichts mehr installieren. Egal welche Erweiterung ich installieren möchte, die Konsolenansicht spuckt immer o.g. Fehler aus.

Das beweist aber nicht, dass es am Contao Manager liegt, da du nicht verifizieren konntest, dass es mit der alten Contao Manager Version funktioniert. Wie gesagt hat das Problem selbst nichts direkt mit dem Contao Manager zu tun. Du musst dich an deinen Hoster wenden.

Theoretisch sollte es bei Mittwald aber keine Probleme geben.

[Marchie]

Es ist nun gelungen Erweiterungen zu installieren. Wie und warum es funktioniert, gibt mir allerdings Rätsel auf.

Hostingpaket: Webhosting XL
Installationsversuch über den CM bricht nach wie vor mit o.g. Fehlermeldung (Speicher) ab.
Erweiterungsinstallationen über composer direkt auf dem Server funktionieren, sofern composer aktuell ist.

Hostingpaket: managed vServer XL:
Erweiterungsinstallationen über CM (gleiche Version(en) wie oben) ohne Probleme möglich.

Daher die Frage:
Ist der Manager nicht einfach eine grafische Oberfläche zum Composer? Müsste daher nicht das Ergebnis von Manager und Composer (SSH) das gleiche sein?

Weiter dubios: Deinstallationen brechen im Manager ebenfalls mit verweis auf Speicherknappheit ab, der entsprechende Eintrag im Manager verschwindet. Die Erweiterung ist aber nachwievor installiert und nach einem update (composer request) wieder im Manager sichtbar...

Mein Fazit bis hierher also: Der Manager hinkt nachwievor der manuellen Installation via composer hinterher, aber nur in Hinsicht auf die Speicherauslastung. D.h. kleines Hostingpaket => composer; ausreichend potentes System => Manager

[Spooky]

Daher die Frage:
Ist der Manager nicht einfach eine grafische Oberfläche zum Composer? Müsste daher nicht das Ergebnis von Manager und Composer (SSH) das gleiche sein?

Nein, denn den Prozessen, die der Contao Manager über den Prozess des Web Servers erzeugt, unterliegen unter Umständen (also je nach Hosting Umgebung) anderen Limitationen, als Prozessen, die direkt über SSH erzeugt werden.

[Marchie]

Nein, denn den Prozessen, die der Contao Manager über den Prozess des Web Servers erzeugt, unterliegen unter Umständen (also je nach Hosting Umgebung) anderen Limitationen, als Prozessen, die direkt über SSH erzeugt werden.

Diese Antwort widerspricht für mich der Aussage, dass es ABSOLUT nicht am Contao Manager liegen kann. Und der neue Hinweis von Andi

Es kommt die Meldung: (nach dem Update vom Contao-Manager auf die Version 1.0.0-beta15)

auch.

... meinem Verständnis nach ......

[Spooky]

Diese Antwort widerspricht für mich der Aussage, dass es ABSOLUT nicht am Contao Manager liegen kann.

Das ist schon immer so und nicht erst seit beta15.

Und der neue Hinweis von Andi auch.

... meinem Verständnis nach ......

Das Problem von m-werk hat nichts mit deinem Problem zu tun.

[Spooky]

Moderation: Beiträge für m-werks Problem verschoben: https://community.contao.org/de/show...tion-in-effect

[Marchie]

So ich komme nun nochmals auf mein o.g. Thema zu sprechen. Ich hatte auch mit Mittwald mehrfach Kontakt und es ist defacto so, dass der neue Contao Manager mit 256 MB PHP Memory Limit definitiv nicht läuft. D.h. bspw. ein XL Paket bei Mittwald ist nicht mehr tauglich, müsste ja aber andere Hoster genauso betreffen. Aber auch Mittwald ist kein Wald-und-Wiesen Hoster.

Das Ganze ist extrem ärgerlich und ja ich weiß es liegt nicht am CM, aber eben doch wieder, da Composer und Konsole ja funzt. Ich habe hier im Forum einiges quergelesen und stelle fest, dass es immer wieder diesselben frustrierten Diskussionen gibt, die am Ende auf "friss oder stirb" drauf raus laufen. So auch hier in diesem Thread:
https://community.contao.org/de/show...ng-Medium-quot

Ich denke auch, dass die Entwicklung Contao nicht zugute kommt und finde es wirklich schade, denn es ist ein so tolles CMS.

[Spooky]

So ich komme nun nochmals auf mein o.g. Thema zu sprechen. Ich hatte auch mit Mittwald mehrfach Kontakt und es ist defacto so, dass der neue Contao Manager mit 256 MB PHP Memory Limit definitiv nicht läuft. D.h. bspw. ein XL Paket bei Mittwald ist nicht mehr tauglich, müsste ja aber andere Hoster genauso betreffen. Aber auch Mittwald ist kein Wald-und-Wiesen Hoster.

Das Problem ist, dass Mittwald dem Web Prozess (und allen dessen Kindprozessen) unabhängig von PHP ein Speicherlimit auferzwingt. 256 MiB waren schon immer (zu) wenig - vermutlich hat Mittwald da etwas vor kurzem geändert.

Siehe auch https://github.com/contao/contao-man...ment-340260488 ff.

Hier kann nur Mittwald etwas ändern.

[Marchie]

nein, über Komandozeile geht es ja, wie ich oben mehrfach geschrieben habe. Ist auch offensichtlich egal. Ich finde das bringt auch nichts mehr, das Ding hin und her zu schieben. 256 ist halt auch nicht wenig .....

[Spooky]

nein, über Komandozeile geht es ja, wie ich oben mehrfach geschrieben habe.

Ich habe den Post nochmals editiert, damit klarer ist was ich meine .

256 ist halt auch nicht wenig .....

Für den PHP Prozess des Web Servers ist das ausreichend (außer du musst hochauflösende Bilder prozessieren). Für eine composer update Operation einer Contao Installation ist das in den meisten Fällen wohl zu wenig. Aber das Problem hat ja auch nichts mit dem memory_limit von PHP zu tun.

[tab]

Wie Spooky geschrieben hat. Der Hoster kann Unterschiede machen zwischen direkt von der Konsole gestarteten Prozessen und von PHP aus gestarteten Konsolenprozessen. Wenn er das tut, dann kann kein vom Webserver ausgeführtes PHP-Programm, auch nicht der der Contao-Manager, erzwingen, dass seine von ihm gestarteten Konsolenprozesse mit den gleichen Limitierungen laufen dürfen wie ein direkt von der Konsole aus gestarteter Prozess. Da können die Entwickler noch Jahre weiterentwickeln, daran werden sie nichts ändern können. Insofern ja, der CM ist schuld, weil er den Konsolenprozess startet und nicht du direkt von der Konsole aus . Ja, das ist ärgerlich, aber es ist nun mal so. Die einzigen, die das ändern können, sind die Hoster, indem sie dem armen CM - bzw den von ihm gestartetem Konsolenprozessen - die selben Limits zubilligen wie einem direkt von der Konsole aus gestarteten Prozess. Man könnte nun natürlich den Contao-Manager selbst von der Konsole aus starten . Damit wäre aber nichts gewonnen, wenn im gebuchten Tarif eben keine Konsole verfügbar ist. Und wenn sie doch verfügbar ist, dann braucht man den CM nicht, weil man dann gleich Composer nutzen kann. Viel mehr als ein schöner Wrapper für den Composer und andere Konsolentasks, der allerdings im Gegensatz zum Composer selbst über den Browser/Webserver gestartet werden kann und somit keine Konsole voraussetzt, ist der CM ja schliesslich nicht.

[Marchie]

Der Hoster kann Unterschiede machen zwischen direkt von der Konsole gestarteten Prozessen und von PHP aus gestarteten Konsolenprozessen. Wenn er das tut, dann kann kein vom Webserver ausgeführtes PHP-Programm, auch nicht der der Contao-Manager, erzwingen, dass seine von ihm gestarteten Konsolenprozesse mit den gleichen Limitierungen laufen dürfen wie ein direkt von der Konsole aus gestarteter Prozess.

Bleibt die Frage, warum es schon ging mit verherigen C-M. Offenbar schiebt es jeder auf jemand anderes. Hoster sagt C-M ist schuld, hier sagt man Hoster ist schuld

wenn im gebuchten Tarif eben keine Konsole verfügbar ist. Und wenn sie doch verfügbar ist, dann braucht man den CM nicht, weil man dann gleich Composer nutzen kann. Viel mehr als ein schöner Wrapper für den Composer und andere Konsolentasks, der allerdings im Gegensatz zum Composer selbst über den Browser/Webserver gestartet werden kann und somit keine Konsole voraussetzt, ist der CM ja schliesslich nicht.

Doch Konsole ist verfügbar, aber offensichtlich ist es nicht akzeptabel, dass es nun mal Leute gibt, die damit nicht so gerne arbeiten möchten/können/wollen .....

[Spooky]

Hoster sagt C-M ist schuld

Was genau hat Mittwald gesagt?

[Marchie]

O-Ton: Wir konnten den Fehler soweit eingrenzen, dass der ContaoManager sehr viel Systemresourcen verbraucht. :-(

Ich werde dort auch nochmals persönlich anrufen bzw. am Contao-Agenturtag ist Mittwald vor Ort ....

[Spooky]

O-Ton: Wir konnten den Fehler soweit eingrenzen, dass der ContaoManager sehr viel Systemresourcen verbraucht. :-(

Das ist kein Fehler sondern eine Tatsache . Und wie gesagt ist das Problem, dass Mittwald (ähnlich wie Domain Factory) den maximalen Speicherverbrauch des Webserver Prozesses (inkl. all seiner Kindprozesse) künstlich begrenzt. Dieses Speicher Limit kann der Contao Manager nicht umgehen.

[tab]

Natürlich ist das akzeptabel. Nur muss dann eben auch akzeptiert werden, dass mit der bunten grafischen Oberfläche eben grundsätzlich andere Limitierungen verbunden sein können als mit der kargen Konsole. Können, nicht müssen. Aber ob es so ist, das entscheidet der Hoster. Wenn ich partout nicht LKW fahren will (und kann), dann finde ich es auch blöd, dass in meinen PKW keine komplette Wohnungseinrichtung reinpasst. Aber es ist halt einfach so. Schuld ist natürlich wer? Der PKW? Die Wohnungseinrichtung? Ich (weil ich zwar einen LKW besitze, ihn aber nicht fahren will oder kann)?

Zum anderen Thema, dass es mit älteren Versionen des CM ging. Wenn man das verifizieren kann, hat man zumindest einen Ansatzpunkt, mit dem man an die Entwickler herantreten kann. Aber das zu verifizieren ist nicht ganz so trivial. Selbst wenn es bei dir mit der alten Version geklappt hat - was ich dir duchaus glaube - und mit der neuen Version nicht. Selbst wenn der Hoster in der Zwischenzeit an deinem Hosting (wirklich!) NICHTS geändert hat. Dann heisst das immer noch nicht viel. Denn es ändern sich z.B. über die Zeit auch die verfügbaren Versionen der von dir verwendeten Pakete. Grob gesagt: Mehr Versionen zur Auswahl -> mehr RAM wird benötigt zur Auflösung der Abhängigkeiten.

Es könnte also durchaus sein, dass heute auch mit der alten Version des CM das RAM nicht mehr reichen würde. Das muss man also auch erst mal ausschliessen. Man müsste also z.B. verhindern, dass der (alte) Contao-Manager sich updatet und dann einmal mit der alten Version und einmal mit der neuen Version das Contao-Update anstossen. Am besten erst mit der neuen Version, sonst gibt irgendein Entwickler zwischenzeitlich eine neue Version frei und das Ergebnis des Tests wäre ggf. nicht aussagekräftig . Zudem braucht dein Hoster auch gar nichts aktiv zu verändern um dennoch unterschiedliche Bedingungen zu erzeugen. Die Limits können durchaus auch z.B. automatisch geregelt von der aktuellen Serverlast abhängen. Die mag anfangs auf einem noch recht "leeren" Server deutlich geringer sein als später, wenn - wie im shared hosting Bereich gängig - gnadenlos die maximal mögliche Anzahl von Kundenpaketen draufgequetscht ist. Auch wenn nicht übermäßig "gequetscht" wird, die Last wird mit der Zeit jedenfalls tendenziell höher. Man müsste also eigentlich das allokierte RAM der beiden Contao-Manager-Prozesse an markanten Stellen des Programmablaufs mitprotokollieren und vergleichen. Insbesondere zumindest den Maximalwert des allokierten RAMs während des Programmablaufs.

[Marchie]

Danke für deine ausführliche Anmerkung tab!! :-)
Fazit für mich: ich werde versuchen so viele Kunden wie möglich zu überzeugen auf meinen Managed vServer zu kommen.
Alle anderen, die bei Mittwald und Konsorten sind, kann ich vermutlich, mit noch ein-, zweimal Händchen halten, über die Konsole pflegen.
Neukunden werde ich dann DAS beste Hosting, welches Contao empfiehlt, anraten. Ähem, welches ist das denn????
Aber ich bleibe dabei: Ich bezweifle, dass Contao damit künftig in großen Stil punkten wird. Aber vielleicht ist das ja auch gar nicht das Ziel.

[Stefko]

Insbesondere zumindest den Maximalwert des allokierten RAMs während des Programmablaufs.

Das ist der Wert, den ich über contao-manager.phar.php composer update --profile erhalte, oder?

[Spooky]

Genau, ja.

[tab]

Bin ich mir jetzt nicht sicher. Wenn das exakt den selben Updateprozess anstösst wie der Contao-Manager über die grafische Oberfläche, dann würde ich meinen ja.

[mlweb]

Neukunden werde ich dann DAS beste Hosting, welches Contao empfiehlt, anraten. Ähem, welches ist das denn????

Das beste wird es wohl nicht geben. Viele gute Erfahrungen gibt es bei netcup, webgo, All-Inkl. Wer ganz auf Nummer sicher gehen will geht zu Leo (Hostingwerk) .

[tab]

DAS Beste wird es schon deshalb nicht geben können, weil es eben auch vom konkreten Projekt abhängen wird. Welche Erweiterungen werden gebraucht usw... Klar ist, mit jeder zusätzlichen Erweiterung wird sich der RAM-Verbrauch beim Update erhöhen. Mit genügend Erweiterungen wird man wohl irgendwann jedes Hosting sprengen können. Ob es dann Sinn macht, das Hosting nach dem RAM-Bedarf beim Update zu wählen? Würde ich nicht unbedingt so sehen, außer natürlich man will/muss partout die Möglichkeit haben, das alles auf dem Live-System machen zu können.

[merlincom]

Lies mal hier weiter, vielleicht hilft es:
https://community.contao.org/de/show...ole-(Hostpoint)

[Der Astronaut]

Bzgl. Memory-Limit hat der Premium-Tarif von All-Inkl.com auch 256 MB. Bei einem Projekt (4.4.14) mit 12 Erweiterungen (Contao-Bundles nicht mit eingeschlossen) lief das Update via Contao-Manager (zuvor frisch auf 1.0.0-beta16 aktualisiert) komplett und ohne Probleme innerhalb von 2-3 Minuten durch (PHP 7.1 CGI). Das nur mal so, um einen Vergleich zu ziehen.

[Marchie]

Wenn ich partout nicht LKW fahren will

Für mich wäre Konsole der LKW und der CM der PKW

Und wie gesagt ist das Problem, dass Mittwald (ähnlich wie Domain Factory) den maximalen Speicherverbrauch des Webserver Prozesses (inkl. all seiner Kindprozesse) künstlich begrenzt. Dieses Speicher Limit kann der Contao Manager nicht umgehen.

Genau das ist nun auch die Rückmeldung vom technischen Support von Mittwald. CM braucht so unglaublich viele Ressourcen. Und ja er lief sehr wohl schon mal sehr gut bei Mittwald. Damit bleiben halt immer weniger Hoster bei denen Contao, respektive CM läuft. Das wird Contao nicht guttun

Das beste (hosting) wird es wohl nicht geben

Meine Frage dazu war auch eher rethorisch gemeint . Denn es bleiben nicht viele Hoster. Und nicht jeder Kunde / jede Agentur wird mal kurz einfach wechseln. Und wenn es beim Relaunch darum geht, welches CMS nutzen wir, ist das Argument, "Contao läuft nur auf drei Hostern zuverlässig", wohl eher ein Satz mit X

... alles auf dem Live-System machen zu können.

nööö, nicht alles, aber mal so ein kleines Erweiterüngchen wäre nett

Bzgl. Memory-Limit hat der Premium-Tarif von All-Inkl.com auch 256 MB.

Tip top!! Werde sicher all-inkl als nächstes mal nutzen, denn man hört viel gutes und ich war vor 15 Jahren auch mit vielen Projekten bei denen. Bleibt zu hoffen, dass all-inkl. nie was in seinen Prozessen ändert. Ihre Oberfläche könnten sie modernisieren ...

[Spooky]

CM braucht so unglaublich viele Ressourcen.

Der Contao Manager braucht nicht viel Ressourcen. Die Abhängigkeitsauflösung bei einer composer update Operation braucht sehr viel Arbeitsspeicher. Daran wird sich in absehbarer Zeit vermutlich nichts ändern.

Ihre Oberfläche könnten sie modernisieren ...

Die ist immer noch besser als bei WebGo

[mlweb]

Die ist immer noch besser als bei WebGo

Du sagst es. Wobei ich habe ein Paket bei dem gibt es minimale Veränderungen z.B. größere Schrift.
Netcup finde ich von der Oberfläche her allerdings noch unangenehmer.

[tblumrich]

Hehe, vielleicht gibt es da einen Zusammenhang... bescheiden designte Oberfläche = gute Performance und Reserven = Contao 4 läuft mit Manager und Composer...
...dann lasst uns nach Hostern mit hässlichen Kundenpanels gucken.

Also wir entwickeln grundsätzlich Live, weil wir den Anspruch haben, den Kunden jederzeit im Projektprozess zu beteiligen, ja teilweise schulen wir so live während der Entwicklung, falls gewünscht (Kunde pflegt seine Inhalte selbst ein und lernt). Hat sich hier als enorm praktikabel und effektiv erwiesen. Unsere Kunden lieben das - weil transparent und kommunikativ. So fallen auch oft krampfige Präsentationstermine weg.
UND, ich weiß von Anfang an, das System läuft später und ich muss keine aufwendigen Umzüge von ggf. unterschiedlichen Umgebungen zum Relaunch machen.
Fand ich bisher an der lokalen Entwicklung immer doof.

Das aus Performancegründen jetzt so eine lokale Entwicklungsumgebung wieder Sinn macht... hmm. Hab aus den Diskussionen im Forum schon verstanden, das das kein Contao-spezifisches Problem ist... Weiß trotzdem nicht ob das eine tolle Entwicklung ist.

Woran liegt das eigentlich? Steigt der Ressourcenbedarf von Webseiten und Co. wirklich so viel schneller, wie die Anbindungen, Hardware usw.?
*duck* Manchmal hab ich das Gefühl das ist alles Entwicklerspielwiese und die Vorzüge für die Frontendler halten sich immer mehr in Grenzen.

[mlweb]

Um die Ahängigkeiten aufzulösen brauchst Du gar nicht unbedingt die Kundeninstallation lokal oder auf einem "potenten" Entwicklungsserver. Die composer.json (mit allen gewünschten Erweiterungen und den Angaben zur PHP-Version) und die composer.lock sind ausreichend. Damit löst Du lokal (oder im Entwicklungsserver) über die Konsole die Abhängigkeiten auf oder fügst neue Erweiterungen hinzu und dann schiebst Du Dir die Dateien auf den Liveserver. Wenn man so ein paar "Standard"-Installationen hat und dann auch noch die PHP-Versionen gleich sind geht das echt easy.

Edit: Ich habs gerade noch mal getestet weil ich mir nicht sicher war. Genau genommen brauchst Du zur Auflösung der Abhängigkeiten nicht mal eine Datenbank.