Installationsproblem wg Git / Composer

Deutsches Forum
1

Hallo zusammen,

ich habe leider andauernde Probleme in der Vorbereitung des Shop-Upgrades auf die v6.0.0. Die Nutzung von Suchmaschinen bzw. die Forensuche hatte mir bislang noch nicht geholfen.

Es geht darum, dass ich im Zusammenhang mit dem Versionsupgrade von der v4.10.6 nach 6.0.0 versuche, Git und vor allem Composer auf unserer lokalen Entwicklungsumgebung lauffähig zu installieren (auch vor dem Hintergrund, dass nach meinem bisherigen Verständnis der Übergang auf die Nutzung von Composer mehr oder weniger erzwungen ist. Stimmt das hart so oder ist die Nutzung von Composer ‘nur’ die empfohlene, weil aufwandärmste Methode?).
Wir arbeiten mit w7 und haben vor Jahren ein Bitnami-Paket für die lokale Entwicklung installiert, das nun aber z.B. bzgl. der PHP-Version veraltet ist, so dass die v6.0.0 damit voraussichtlich gar nicht mehr funktionieren würde.

Infolge dessen wollte ich nun eine aktuelle Entwicklungsumgebung auf den Rechner bringen und habe es zunächst mit der Docker-Variante von ProudCommerce versucht.

In dem Kontext hatte sich leider heraus gestellt, dass ich sowohl mit Git (einem Programm zur Interaktion mit Github) als auch vor allem mit Composer nicht imstande bin, auf externe Server zuzugreifen.

Bei Git erhalte ich diese Message:

fatal: unable to access ‘https://github.com/proudcommerce/docker-oxid6.git/’: Failed to connect to github.com port 443: Bad access

Composer kann ich noch nicht einmal fertig installieren, ich erhalte dabei folgende Fehlermeldung:

The “https://getcomposer.org/versions” file could not be downloaded: failed to open stream: Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig.

Ich bin mir relativ sicher, dass beide Meldungen im Kern auf ein Grundproblem zurückzuführen sind. Allerdings weiß ich trotz meiner bisherigen Recherchen nicht, welches das ist, somit kann ich es auch nicht lösen.

Hat jemand von Euch eine Idee bzw. einen Vorschlag, wie ich jetzt weiter vorgehen könnte?

Gesetzt den Fall, das Problem bleibt unlösbar, so dass bestimmte Zugriffsarten auf Remote Server mit unserem Rechner nicht möglich sind:
Wie kann ein Workaround aussehen? Ich hoffe nicht, dass es nur noch ausschließlich den komplex-technologischen Weg gibt, und wenn der nicht funktioniert, hat man Pech gehabt und kann nach Hause gehen.

Ich bedanke mich schon mal vorab!

Gruß,
Steffen

2

Wir hatten das Thema ja bereits …

Hast du es mit der VM Box mal versucht?

3

Steffen, ich denke das Grundproblem könnte bei Dir die Windowsinstallation mit seiner kruden Rechteverwaltung oder irgendeine Firewall sein. Selbst wenn Du den Shop lokal aufgesetzt bekommst - z.B. über die Download-Datei - wirst Du Probleme an ganz anderen Stellen auftun.

4

Hallo, Ihr beiden,

danke für die schnellen Antworten!

Was die Virtualisierung angeht: Ich habe versucht, die Docker Toolbox zu installieren, in jener ist eine Virtual Machine enthalten. Die Toolbox ist nicht das empfohlene Werkzeug, aber das aktuelle Docker-Programm setzt w10 voraus, und w7-Leute müssen mit der Toolbox arbeiten.

Doch auch hier wurde ich während der Installation mit meinem Grundproblem konfrontiert. Ich konnte die Installation nicht abschließen, weil irgendwann mittendrin Docker mit einem Remote Server kommunizieren wollte (es ging um den Austausch und die Verifizierung von Zertifikaten), und da hieß es wieder: Nee, das geht nicht.

Auf den Punkt gebracht: Ich bin noch gar nicht zu eigentlichen Upgrade-Arbeiten gekommen, weil schon bei der Einrichtung des Rahmens etwas hart aus dem Ruder läuft (nochmals die Stichworte: VM, Git, Composer).

Ich kann und werde vermutlich zu Fuß eine Menge lösen, aber die unabsehbare Zahl an Stunden würde ich gerne angenehmer verbringen, und ich weiß ja tatsächlich nicht, ob ich alles, was nun per Tool laufen soll, es aber nicht macht, alternativ lösen kann.

Ja, Marco, ich halte es für sehr gut möglich, dass ein krummes Windows-Setting bei uns quer schießt. Auf meinem schlauen Zettel steht, dass der Extended Support für w7 im Januar 2020 ausläuft, und wir haben uns intern schon verständigt, dass wir dann auch auf dem Oxid-Notebook auf Linux umsteigen wollen.

Aber es kann doch nicht ernsthaft als Lösung zur Debatte stehen, dass man im Falle von Problemen halt das Betriebssystem zu wechseln hat. Es gibt Bekloppte wie mich, die mit MS-Produkten unterwegs sind, es gibt Linux-Leute (zu denen ich auch gehöre, ich bin halt viele), dann gibt es die Mac-Community etc pp.
Will sagen, ein Softwaretool wie z.B. Oxid kann und darf sich doch nicht dahin entwickeln, dass man es nur noch unter immer spezielleren Rahmenbedingungen nutzen kann. Im Gegenteil, es sollte meiner Auffassung nach so breit wie möglich einsetzbar sein.

Aus gegebenem Anlass will ich noch ein paar allgemeinere Gedanken hinzu fügen.

Ich habe den Eindruck, dass mit der v6 den NutzerInnen die technologische Meßlatte deutlich höher gehängt wird. Vorausgesetzt wird nun Composer, es soll mit Git gearbeitet werden (was meiner Auffassung zufolge aber nicht essentiell ist), bei der ‘stark angeratenen’ Verwendung von Flow kann man die CSS-Files nicht mehr direkt editieren and so on.

Ich höre schon vor meinem inneren Ohr: Was willst Du, es gibt viele, bei denen das Upgrade prima funktioniert hat. Bei wie vielen hat es nicht prima funktioniert? Haben alle Betroffenen das Problem angesichts des die knappen Ressourcen absorbierenden Weihnachtsgeschäfts überhaupt schon in seiner Tragweite auf dem Zettel?
Meiner Meinung nach hat die Komplexität des Gesamtsystems deutlich zugenommen, und ich denke, dass das so gewollt ist und entsprechend beschlossen wurde. Damit wächst aber die Anfälligkeit für Probleme und Fehler. Ich halte das für zwangsläufig, und ich gehe davon aus, dass nicht wenige UserInnen die neuen Anforderungen, die mit dem Upgrade verbunden sind, nicht mehr aus eigener Kraft bewältigen können. Einige von ihnen werden das Shopsystem wechseln (es stellt sich aber die Frage, ob es anderswo besser ist - es hatte ja Gründe, weshalb wir uns irgendwann für Oxid (um-)entschieden haben…), andere werden aufgeben oder den Kopf in den Sand stecken und einfach weiter machen, und wieder andere werden Aufträge an Oxid-spezialisierte Webagenturen vergeben müssen. Ob letzteres Zufall ist oder intendiert, kann ich nicht beurteilen.

Versteht mich richtig, ich finde es in Ordnung, wenn Leute aus freien Stücken Aufträge vergeben, und die in Agenturen Beschäftigten machen einen prima Job und wollen dafür auch anständig leben. Darum geht es nicht. Ich denke, die aktuellen Entwicklungen können auch in der Weise interpretiert werden, dass mit Hilfe von technologischen ‘Sachzwängen’ der Vergabe von Aufträgen ein kleines bissel nachgeholfen wird, weil man sich zumindest nicht mehr so leicht wie bisher selber helfen kann. ‘Der Quellcode liegt doch offen, und alle neu einzusetzenden Tools sind so was von bewährt! Es klappt nicht? Och, wie schade. Das muss an und bei Dir liegen. Aber Du musst ja nicht xyz nutzen, such Dir was Besseres, good luck!’

Gruß,
Steffen

5

Mein Vorschlag wäre: installiere dir mit Virtualbox eine komplette Linuxmaschine, dieselbe Version wie du auf dem Server hast. In der Maschine richtest du mit Samba filesharing ein, so daß du mit windows-Tools auf die Dateien zugreifen kannst.

Ich habe mir eine separaten Linuxserver installiert, auf dem Virtualbox läuft, und darin wiederum eine virtuell Linuxmaschine, die ich mit “VBoxManage startvm DebianOne --type headless” starte. In der VM läuft Samba.

Auf meinem Windows-Laptop verbinde ich ein Laufwerk mit dem Samba der VM.

Innerhalb der VM habe ich eine echte Linuxumgebung und somit keine Probleme.

Du kannst das aber auch alles auf einem einzigen Laptop machen, wenn der ausreichend leistungsfähig ist.

Man kann die VM auch mit Vagrant steuern.

6

Natürlich kann man eine Linux-VM installieren, die Frage ist warum das notwendig sein sollte wenn die benötigte Umgebung plattformunabhängig ist. Die Installation funktioniert pinzipiell auf Windows, der Shop auch, allerdings laden die Module nicht weil der Modul-Lader die Klassennamen unter Windows zerstückelt.

@nulldrei: Ich denke auch dass bei dir eine Firewall reinpfuscht. Ich würde mal alle 3rd-Party Firewalls deinstallieren falls vorhanden. Außerdem würde ich auf Win 10 upgraden, und wenn auf dem Notebook keine 1000 Sachen installiert sind gleich als Neuinstallation. Oder eben gleich ein neues und da Win 10 oder Linux installieren und nicht bis 2020 warten.

Und es stimmt schon, dass nicht so technikbegeisterte User vielleicht etwas aus dem Fokus geraten sind. Dass die Technik mit Absicht verkompliziert wurde um jemand das Leben schwerzumachen halte ich allerdings für etwas abwegig.

1 Like
7

Hallo und guten Morgen!

Ich hatte schon befürchtet, dass ich als Reaktion auf meine grantigen Zeilen nun virtuell Kloppe bekommen würde, aber es freut mich, dass dem nicht so ist, sondern sachliche und konstruktive Reaktion kamen.
Großes Lob und vielen Dank dafür! :slight_smile:

Unser kleines Frühstückskabinett hat soeben getagt, vermutlich werden wir nun tatsächlich eher als geplant den Entwicklungsrechner auf Linux umstellen.

Was MS angeht, so möchten wir uns inzwischen so weit wie möglich davon unabhängig machen, insofern ist w10 keine Option.

An einem Punkt möchte ich aber nachhaken:

Man muss Microsoft-Produkte nicht mögen und dafür mag es gute Gründe geben, aber wenn angesichts der Verbreitung von MS-Betriebssystemen ein plattformunabhängiges Tool mit professionellem Anspruch so gestaltet wird, dass eine wesentliche Funktionalität unter Windows nicht funzt, dann finde ich das erstaunlich.
Ich lasse mich immer gerne korrigieren, aber ich habe bislang noch nicht gesehen, dass bei den Systemvoraussetzungen einer lokalen Entwicklungsumgebung von MS Windows explizit abgeraten wird. Entweder sollte das nachgeholt oder der Bug im Modul-Loader sollte gefixt werden (letzteres ist aus NutzerInnensicht vermutlich vorzuziehen).

Nochmals danke und Gruß aus Berlin-Hermsdorf,
Steffen

8

Ich kann mich @nulldrei eigentlich nur anschließen. PHP und die bei OXID im eingesetzten Tools sind plattformunabhängig und bietet daher große Vorteile bei der Entwicklung von Software und der Auswahl der Entwicklung- bzw. Staging Umgebungen.

Bei der Entwicklung von Software für verschiedene Systeme wird die Stabilität der Umsetzung erhöht, sofern im Entwicklungsprozess auf allen environments (OS) getestet wird, auf denen die Software am Ende auch laufen soll. Ich denke, dass man bei einer plattformunabhängig Software schon erwarten kann, dass diese auch wirklich plattformunabhängig ist.

Ich hoffe stark, dass mögliche Fehler unter Windows nicht auch die Ursache für das Problem hier sind: OXID 6 - Module with namespaces not working on Windows

9

Hi, ich möchte mich hier mal etwas verspätet einklinken, da es thematisch wohl am besten passt. Generell geht es mir sehr ähnlich wie @nulldrei, aber ich will versuchen, halbwegs neutral zu bleiben. Denn wir sind nun ja bereits bei OXID 6.0.2 und kommen um dieses Composer/Git/VM/etc-Thema scheinbar echt nicht drum herum. :wink:
Ich möchte aber gerne 2 Aspekte genauer aufgreifen:

  1. Ich sehe es mit der Plattformunabhängigkeit absolut genauso: wenn alle Grundlagen (PHP, MySQL, Apache, etc.) OS-übergreifend laufen, dann muss es der Shop doch eigentlich auch (mal abgesehen von dieser Namespace/Backslash-Problematik)? Aber ich wäre ja schon glücklich, wenn dies “nur” auf das komponierte Artefakt zutrifft, nicht die komplette Entwicklungsumgebung mit Composer & Co. Liege ich da richtig oder was spricht konkret dagegen?
    Mein Problem ist nämlich folgendes und ich kann mir nicht vorstellen, dass ich damit allein bin(?): Es läuft hier seit fast 20 Jahren ein Webserver (Apache) + simulierte Kundenkonsole unter Windows, quasi als kompletter Spiegel unseres Live-Webservers, und das ohne jegliche Probleme, egal welches Web-System für einzelne Kunden installiert wurde. Darum geht es aber nicht, und auch nicht zwingend um Windows, sondern darum, dass es mit VMs zigfach umständlicher wäre, >50 Kundensysteme gleichzeitig am laufen zu haben! Man liest dauernd: Installier doch schnell eine VM oder einen Docker-Container, aber das stimmt halt nur, solange man mit nur wenigen Shops/CMS gleichzeitig arbeiten muss. Agenturen haben da aber evtl. einen anderen Bedarf, man denke alleine an Updates.

  2. Egal, welche 6er-Version ich bisher anschaute, es sieht immer gleich aus auf Dateiebene: es gibt den Ordner source/ und es gibt vendor/oxid-esales/oxidshop-ce/source/ und beide sind größtenteils identisch und damit scheinbar redundant? Ich verstehe jedenfalls das Prinzip nicht ganz: eigentlich erwarte ich (aus Gewohnheit), dass nur die Ordner online stehen müssen (per FTP), die innerhalb des Document-Roots liegen. OXID 6 braucht aber parallel dazu scheinbar zwingend diesen vendor-Ordner. Ist dies so gewollt, korrekt und unabänderlich, oder kann man da irgendwas beeinflussen, sofern sinnvoll? Ich sehe da bisher nur >10.000 Dateien, die ich ungern bei jedem Shop-Setup online stellen müssen würde (serverseitig betrachtet wäre das dann ja mega-redundant!).

10

Schau dir mal an wie composer funktioniert, dann weisst du auch warum “dieser komische vendor” Ordner da ist. :wink:

Es gibt auch im Forum schon ein paar Threads wo genau da drüber diskutiert wird …

11

Nein sorry, genau dass meine ich ja: ich möchte mich aktuell (aus Zeitgründen) überhaupt nicht auf Composer-Ebene mit OXID auseinandersetzen, sondern einfach nur das fertig “komponierte” Produkt nutzen. Es reicht doch, wenn sich ein paar Spezies damit gut auskennen und mir das Resultat zur Verfügung stellen, wie ja bereits durch Marco geschehen, dachte ich zumindest. Die ganze Kompatibilitäts-Debatte wg. Windows bezieht sich bisher doch immer auf das volle Programm inkl. Composer, und ich dachte, ich füge dem mal einen vereinfachten Blickwinkel hinzu. Ich habe es halt so verstanden: “vendor” sind die eigentlichen Quellen, aus denen “source” gebildet wird durch den Composer (warum heisst es dann nicht “target”?). Aber ich fürchte, das ist wohl nur die halbe Wahrheit? Ich habe auch schon im Forum gesucht, aber welche Threads zum Thema meinst du genau @tabsl?
Ich erwarte jedenfalls, dass ALLE benötigten Files immer innerhalb des Docroots liegen, notfalls halt auch vendor, so kenne ich es auch von Contao & Co. Warum ist dies bei OXID anders und warum diese Redundanzen?

12

Oxid läuft auf Windows, ab 6.0.1. Composer etc. sowieso. Leider haben die Entwickler sich trotzdem nicht dazu durchgerungen auf Linux als Systemvoraussetzung zu verzichten.

Templates und Module werden vom composer Plugin in das source-Verzeichnis kopiert, alles andere verbleibt im vendor-Ordner, deshalb funktioniert der Shop nicht ohne diesen. Im Verzeichnis “source” (normalerweise heißt das “src”) liegen die Dateien an denen gebastelt werden soll oder kann, alles andere wird direkt aus “vendor” geladen.

Die Option nur das fertig kompilierte Produkt zu nutzen gibt es nicht mehr, ebenso wenig die Option alles im Docroot zu halten. Oxid hat sich damit vom Endanwender-Produkt in Richtung Baukastensystem für Entwickler bewegt. Der Download für das fertig zusammengestellte Produkt ist nicht erweiter- und updatebar und maximal als Übergangslösung geeignet. Allerdings sind die benötigten Kenntnisse über composer nicht besonders anspruchsvoll.

13

Danke @leofonic für die nette Zusammenfassung! Im Prinzip ist mir das meiste auch bereits klar, aber ich habe wohl auch Probleme damit, die richtigen Fragen zu stellen. Mir fiel eben noch ein weiterer Versuch ein: Sollte das Composer-Ergebnis nicht eigentlich identisch sein, egal, ob man dies unter Linux oder Windows erzeugt? Wenn ja, wäre doch alles halb so schlimm und man könnte auch mit ZIPs leben, zumindest temporär. Falls nein, hätte ich gerne konkrete Beispiele, wo sich etwas unterscheiden könnte.
Ich fürchte aber bald, ich gehe die Sache bisher falsch an, und man kommt um den Composer wirklich nicht herum, auch als “nur” Modul-/Theme-Entwickler. Hauptsache aber, ich kann vorerst bei meinem Windows-Apache zum Entwickeln bleiben, alles andere wäre für mich momentan Overkill. Ist mir schon klar: aus OXID-Sicht bin ich damit wahrscheinlich die Ausnahme, aber aus meiner Sicht ist eindeutig OXID 6 die Ausnahme, und letztlich haben wir alle Recht! :wink:

PS: aber warum soll sich ein ZIP-Setup nicht erweitern lassen? Module konnte ich bisher problemlos dort installieren wie gehabt, oder was meintest du?

14

Die Dateien werden identisch vom Composer erstellt, das stimmt. Verschiedene PHP-Versionen werden dagegen unterschiedliche Dateien produzieren. Man kann auch source und vendor lokal mit Composer erstellen und komplett in die Live-Umgebung hochladen, das funktioniert auch: Install OXID eShop compilation on servers, where Composer is not available — OXID eShop developer documentation 6.0.0 documentation

Nur Module ohne Namespaces, wenn ein Modul Namespaces verwendet, kann es nicht ohne Composer installiert werden. Updates laufen ebenfalls über Composer.

Bringt keinen Vorteil imho, Composer kann unter Windows global mit setup.exe installiert werden, dann kannst du mit der Zeile aus der Installationsanleitung den Shop komplett installieren und brauchst kein Zip.