funktioniert Composer mit privatem Bitbucket Repository ohne SSH-Key auf Server?

Hallo zusammen,

Ich finde leider keine funktionierende Lösung, weder im Forum noch über unzähligen Suchen im WWW.

Benutzt jemand von Euch die Möglichkeit von eingebettetem Username/Password in der Composer URL für auf Bitbucket abgelegte private Repositories?
Funktioniert dass bei Euch ganz ohne SSH Key auf dem Server?

Ich teste eine Installation auf nem Shared-Host ohne SSH-Zugriff. Alles funktioniert recht passable. Nur die Installation einer Contao-Extension die auf einem privaten Repository auf Bitbucket liegt, bringt mich zur Verzweiflung. Auf dem Shared-Host gibt es keine Möglichkeit einen SSH-Key zu generieren. Durch das Posting von Trill : https://community.contao.org/de/show...mposer+private

hoffte ich, dass es ohne SSH-Key auf dem simplen Server über die URL-Einbettung von Username und Passwort funktioniert.

Zitat:

---

Zitat von tril

Ja, verwende ich regelmäßig.


Das hat nichts mit Contao oder Bitbucket zu tun.
https://github.com/composer/composer...mment-23128547


Ich würde dir empfehlen, die HTTP URL mit eingebetteten Passwörtern zu verwenden. Der Web-Benutzer hat idR ja keinen Zugriff auf deinen SSH Key und kann deshalb keine Verbindung aufbauen.

Code:

---

{
    ....
    "repositories": [
        {
            "type": "vcs",
            "url": "https://username:password@bitbucket.org/vendor/repo.git"
        }
    ]
}

---

---

Nur bei mir kommt immer die Fehlermeldung

Code:

---

Failed to clone https://bitbucketUsername:***@bitbucket.org/OwnerName/RepoName.git, git was not found, check that it is installed and in your PATH env. git: not found

---

Vielleicht hat mir jemand einen Tipp. Womöglich funktionierte der Zugriff über HTTP URL mit eingebetteten Passwörtern nach dem Muster:

Code:

---

https://bitbucketUsername:bitbucketPassword@bitbucket.org/OwnerName/RepoName.git

---

früher (Posting ist von Mitte 2014) und jetzt 2015 nicht mehr.
Vielleicht verstehe ich auch grundsätzlich etwas falsch, oder es braucht sowieso immer einen SSH-KEY auf dem Server und Shared-Hosting Angebote ohne SSH Zugriff sind für private Repos auf Bitbucket nicht geeignet.

Habt Ihr da Erfahrungen? Wie könnte ich das sonst noch lösen?
Über Server mit SSH-KEY funktioniert der Zugriff auf das private Repo. Auch mit zwischengeschaltetem Satis-Server läuft da alles reibungslos. Der Versuch, dem Satis-Server in der satis.json gleich die UserName:Passwort https Url zu liefern führte auch nicht zum Erfolg; dann wirft der einen Error. Macht auch nicht wirklich Sinn, Username und Passwort des Repo auf dem Satis ungeschützt zu lagern. Aber einen Versuch war es wert.

Ich hoffe jemand kennt eine Lösung, oder den Ort, wo ich eine Lösung finden kann.
Vielen Dank schon im Voraus für Eure Hilfe.

Gruß Martin

Die Fehlermeldung sagt, dass git auf deinem System nicht gefunden werden konnte. Du musst auf dem System git installieren.

Hey Spooky,
vielen Dank für Deine schnelle Antwort.

Ich dachte mir auch, dass diese Fehlermeldung irgendwie sagen will, dass GIT nicht installiert ist. Aber das ist mir sehr schleierhaft, denn alle anderen öffentlichen Git-Repositories von Bitbucket unter dem selben Owner funktionieren auf dem Shared-Host-Server total fehlerfrei. Wenn ich für ein öffentliches Repo eine neue Version tagge, wird diese sauber deinstalliert/installiert und auch das Grundsystem wird sauber installiert. Somit sollte doch GIT vorhanden und installiert sein. Oder wird bei einem public Repository kein GIT nötig und ein völlig anderes Prozedere angewendet? Braucht es bei public Repo's kein GIT?

Was hast du in den Einstellungen der Paketverwaltung unter Bevorzugte Installationsart eingestellt?

Distributionsarchiv

Vielleicht ist es so, dass von deinem Repository kein Distributionsarchiv bezogen werden kann und daher git benötigt wird. Vielleicht weiß da jemand anderer genaueres.

Vielen Dank für Deine Mühe.
Habe interessehalber bevorzugte Installationsart auf »Quellen« gesetzt und erneut mit der eingebetteten URL https://username:password@bitbucket.org/owner/repo.git getestet. Wirft den selben Error.

Freue mich auf helfende Ideen.

Zitat:

---

Zitat von mad99

Vielen Dank für Deine Mühe.
Habe interessehalber bevorzugte Installationsart auf »Quellen« gesetzt und erneut mit der eingebetteten URL https://username:password@bitbucket.org/owner/repo.git getestet. Wirft den selben Error.

---

Logisch, für Quellen brauchst du git. Steht ja auch dort in den Einstellungen ;)

Wer genug Geduld für die PopUpInfo hat und lesen kann, ist klar im Vorteil.:(
Danke! Zurück auf Archiv ... und hoffen, dass jemand helfen kann.

Kurzer Test schließt Schreibfehler in URL aus:
Setzte ich das Repo auf private kann Composer nicht von Bitbucket installieren (nimmt zwar Cache, aber wenn ich den manuell Lösche, ist es vorbei mit der Installation).
Setzte ich das Repo auf public kann Composer von Bitbucket installieren (wenn ich Cache davor manuell lösche siehe Anhang: Anhang 15569)
Auch wenn Repo auf public bleibt, ich aber mit eingebettetem username:password@bitbucket.... zugreifen möchte, kommt die genau gleiche Fehlermeldung :Failed to clone https://bitbucketUsername:***@bitbucket.org/OwnerName/RepoName.git, git was not found, check that it is installed and in your PATH env. git: not found.

Ich war mir nicht sicher, ob vielleicht das GIT auf Bitbucket nicht zu finden ist, weil ich eventuell einen Fehler in der URL gehabt habe. Dies ist aber damit sicher ausgeschlossen.

Ist es so, dass Composer automatisch GIT auf dem Hosting-Server braucht, sobald die eingebettete URL-Variante benutzt wird?
Gibt es eine andere Möglichkeit, über BitBucket mit privatem Repo?
Oder bin ich total falsch gewickelt und die Lösung mit der eingebetteten URL ist sowieso nur mit ssh-Key auf dem Hosting-Server und/oder GIT-Installation möglich?
Oder bin ich sowieso auf dem falschen Dampfer und suche in der falschen Richtung?

Wäre froh um Tipps.

Also bei mir gehts auf nem kleinen 1und1 Paket.

Welchen Chache meinst du? Dann kann ich das mal löschen und schauen obs danach noch geht.

Meldung, beim Updaten:

Code:

---

Loading composer repositories with package information
Reading composer.json of znrl/znrl_ics (0.1.0)
Reading composer.json of znrl/znrl_ics (0.1.1)
Reading composer.json of znrl/znrl_ics (master)

---

Im Expertenmodes vom Composer habe ich unter require:

Code:

---

"znrl/znrl_ics": "dev-master"

---

und bei repositories (hinten Kleinerschreibung, weiß nicht ob das was macht):

Code:

---

"type": "vcs",
"url": "https://Name:Password@bitbucket.org/znrl/znrl_ics.git"

---

Ich hatte aber auch diverse Probleme bis das lief, u.a. hatte ich deinen Fehler. Irgendwann giengs dann :>.
So genau kann ich nicht sagen wann und warum bzw. was ich gemacht hab.
Aber ich hatte während dem versuchen die Tags 0.1.0 etc angelegt.
Wichtig war auch, aber ich meine wegen ner anderen Fehlermeldung, dass die composer.json im root (direkt zu sehen, wenn man auf Source klickt) lag sonst hats die nicht gefunden.

Hey Znlr,
vielen Dank für Deine Hilfe.

Ich kenne die Details zu 1und1 Paketen nicht so ganz. Aber damit wir uns nicht falsch verstehen: Du hast keinen SSH-KEY für Bitbucket generiert und auch kein GIT installiert?

Nicht, dass Du Dir die Installation zerschießt, ich kenne mich dafür zu wenig mit Composer und Contao aus, aber vielleicht kannst Du den Ordner unter ContaoRoot/composer/cache/files/ownerName/repoName ja testweise »umbenennen«. Als ich den Cache dort gelöscht habe, wurde erst Github angesteuert, davor nahm er es aus dem Cache (siehe vorherigen Anhang). Daher denke ich, dass war der »richtige Cache«. Aber wie gesagt, es war ein Test auf einem Testsystem. Nicht das Du da was live anrichtest.

Danke für Deinen Tipp mit der Kleinschreibung. Die CamelCase nahm ich nur beim Beispiel aus Gewohnheit. die ganze url ist real in lowercase geschrieben. Daran kann es also nicht hängen.
Und in meinen Repos auf Github liegt die composer.json direkt im Root-Verzeichnis. Das passt wohl.
Das mit den Tags verstehe ich nicht ganz:

Zitat:

---

Zitat von Znrl

Aber ich hatte während dem versuchen die Tags 0.1.0 etc angelegt.

---

Meinst Du ein Tag 0.0.x könnte Probleme auslösen? Auf dem Server mit SSH-KEY und Git klappte es aber damit. Ich denke, das hat wenig bis keinen Einfluss.

Würde mir schon sehr helfen, zu wissen, ob Du es ohne SSH-KEY und GIT auf dem Server hinbekommen hast. Bei 1und1 finde ich zu SSH etc. nichts brauchbares in der Übersicht vom Starter. Ist aber auch etwas unübersichtlich mit all den akkordeons ...

Username ist nicht meine E-Mail Adresse, ich meine das hatte bei mir nicht funktioniert.

Bei mir ist das nicht in files sondern unter vcs. Dort ist ein Ordner https---name-passwort-bitbucket[...].git, halt das komplette git.

Ich hab selbst kein git installiert aber es kann natürlich sein, dass das bei 1und1 schon drauf ist und bei dir nicht...

SSH keys sind keine angelegt.

Ich hab den git Ordner unter composer/cache/vcs gelöscht (unter repo ist der gleiche Ordner nochmal, auch dort hab ichs gelöscht) bzw. dann auch mal im Backend den Composer Cache geleert und die composer/composer.lock gelöscht, trotzdem geht es und es wird alles wieder angelegt.

Der relevante Teil in der composer.lock sieht bei mir so aus:

Code:

---

        {
            "name": "znrl/znrl_ics",
            "version": "dev-master",
            "source": {
                "type": "git",
                "url": "https://name:passwort@bitbucket.org/znrl/znrl_ics.git",
                "reference": "vielebuchstabenundzahlen987d789" (keine Ahnung wofür das ist, deshalb mal wegemacht)
            },
            "type": "contao-module",
            "extra": {
                "contao": {
                    "sources": {
                        "system/modules/znrl_ics": "system/modules/znrl_ics"
                    }
                }
            },

---

Ich weiß nur, dass ich auch 3-4 Stunden rumprobiert hab bis das lief und ich bin mir ziemlich sicher, dass der Fehler mit dem git auch kam, zusammen mit vielen andern während ichs versucht hab.

Die Tags sind denke ich egal, wollte es nur erwähnt haben. Wäre ja dämlich, wenn es aus irgendwelchen gründen Tags braucht um das zu erkennen.

Sonst vtl. das ganze mal woanders testen, wo es gehen müsste.

Hallo Znlr,
vielen Dank für Deine Hilfe.

Ich habe Mal den Deployment Key auf Bitbucket falsch definiert. Resultat, es funktioniert immer noch sauber! Musste danach bei Zugriff über SourceTree das Passwort eintippen. Somit ist klar, es geht auf dem lokalen Testserver auch ohne SSH-KEY.
Wahrscheinlich braucht es wirklich GIT auf dem Hostingangebot und 1und1 hat das drauf.
Interessanterweise habe sollte auf meinem Server vom SharedHoster der Git-Client installiert sein soll...
Habe ich da mal nachgefragt, an was es liegen kann. Erster Tipp es könnte was mit der "Test"-»Subdomain« zu tun haben. Hatte es aber nicht. Montag Morgen nehmen Sie sich dem Befehl und dem Error an.
Mal schauen, ob das Früchte trägt.

Wenn ja, wäre zumindest eine Frage unumstößlich geklärt: Private Repo's brauchen im Gegensatz zu public gesetzten ein installiertes und "findbares" GIT auf dem Server. Vorerst kann ich das aber noch nicht mit Sicherheit abstreichen.
Geduld bringt Blumen.

Finde ich es heraus oder erhalte sonstige Neuigkeiten werde ich diese, für andere mit dem selben Problem hier posten.

Hab jetzt dazu nur den Composer Quellcode überflogen und nicht konkret getestet, aber:

1. Für BitBucket kommt ein spezieller "Treiber" zum Einsatz, der kein installiertes GIT benötigt, weil BitBucket alle GIT-Daten per API/JSON bereitstellt
2. Die Prüfung, ob ein in der composer.json angegebenes Repository bei BitBucket liegt oder nicht wird mittels regulärem Ausdruck geprüft: GitBitbucketDriver.php:146
3. Der reguläre Ausdruck berücksichtigt aber aktuell nicht den Use Case, den Du hast: Benutzername & Password in der Repo-URL
4. Composer denkt daher bei der aktuellen URL, dass es ein ganz normales GIT-Repository ist und nutzt dann den GIT-"Treiber" (Fallback)
5. Da kein GIT installiert ist -> Fehler

Composer bietet aber noch nicht Möglichkeit Zugangsdaten für Repositories in einer auth.json anzugeben. Erstelle dazu mal per FTP die Datei contao-installation/composer/auth.json mit folgendem Inhalt:

Code:

---

{
    "http-basic": {
        "bitbucket.org": {
            "username": "_BENUTZER_",
            "password": "_PASSWORT_"
        }
    }
}

---

Werte für Benutzername und Passwort entsprechend einsetzen und dann im Expertenmodus die URL für das Repository wieder ändern in

Code:

---

https://bitbucket.org/znrl/znrl_ics.git

---

Evtl. kannst Du das Problem so umschiffen.

Wenn Du magst, kannst Du ja ein Ticket auf Github für Composer aufmachen - sollten sich die Composer-Jungs mal ansehen.

Hey Michael,
»you are my hero«, oder etwas weniger theatralisch: »Vielen lieben Dank für Deine Hilfe und das Überfliegen des Composer Quellcodes«.

Dein Tipp mit der auth.json hilft perfekt. So kann ich sogar den Satis-Server nutzen. Muss da nicht irgendwelche Passwörter einpflügen und habe für jede Website die Zugangsdaten sauber getrennt.

Ich war selber schon sehr nahe dran. Beim Versuchen erzeugte ich bereits eine auth.json im Composer Verzeichnis. Nur habe ich da - warum auch immer - statt der "bitbucket.org": Schreibweise den Owner angehängt. Und "bitbucket.org/ownername": hat nichts gebracht.
Das ganze Testen mit Composer ist ja eine eher langwierige Sache und so gab ich ungeahnt nahe am Ziel, sehr unbewusst auf. Bei der zigsten Fehlermeldung und unzähligen Aktualisierung- und Abwart-Phasen glaubt man plötzlich nicht mehr, dass man auf der richtigen Spur sein könnte ...

So klappt es einfach genial!
Ich habe aber trotzdem ein Ticket auf Github geöffnet: https://github.com/composer/composer/issues/3893.
Vielleicht verstehen die Entwickler ja mein Baby-English und können dadurch dem ein oder anderen zukünftig Verzweifelnden mit einem guten Tipp in der Composer-Console oder einem geänderten Regex helfen.

Doch noch eine Frage zum Abschluss: Wenn GIT auf dem Host-Server installiert wäre, hätte es ohne den Workaround mit der auth.json klappen müssen? Meine Frage kommt deshalb, weil ich beim Hoster ein Ticket eröffnet habe, denn eigentlich wirbt er damit, dass der GIT-Client auf dem Server installiert sei. Gibt es da eventuell einen Trick, den man den Entwicklern da stecken könnte? Oder anders gefragt, benötigt Contao eine etwas anders gesetzte ENV-Variable oder sollte der GIT-Client irgendwelche Subdomains oder andere Details speziell behandeln, wenn er von Contao gefunden werden soll?
Oder gibt es eine Möglichkeit, zu testen, ob GIT installiert, oder besser gesagt am richtigen Ort für Contao zu finden ist?

Vielleicht hast Du oder jemand anders da ja einen Tipp. Dann würde ich das den Host-Anbieter-Entwicklern gerne weiterreichen.

Vielen Dank noch einmal
Martin

Jap - wenn GIT installiert wäre, hätte es klappen müssen. Im Normalfall kann GIT von PHP auch genutzt werden, wenn es installiert ist. Der Hoster kann aber auch bestimmte PHP-Funktionen deaktiviert haben, was dann die Ausführung von Shell-Programmen durch PHP verhindert.

Du könntest eine info.php hochladen mit Inhalt:

Code:

---

<?php phpinfo();

---

Und die dann mit dem Browser aufrufen. Dort nach

Code:

---

disabled_functions

---

suchen und, falls etwas drin steht, das hier kurz posten.

Leider bis auf »no value« recht leer (Anhang 15605)

Hallo zusammen,
auf das vorgeschlagene Ticket beim Composer Projekt hat Jérôme Tamarelle eine klare Rückmeldung gegeben:

Zitat:

---

The auth.json is the preferred method to handle authentication. You should never commit your credentials. Composer should have asked you the credentials.

See also: http://seld.be/notes/authentication-...nt-in-composer

---

Wird wohl nichts mit einem eventuell veränderten Regex oder einer aussagekräftigeren Fehlermeldung. Habe mich vielleicht auch etwas unbeholfen ausgedrückt. Ist aber auch kein Beinbruch ... auth.json sollte auch allen anderen helfen, die eventuell über den selben Fehlermeldungsstrick stolpern.

Auch der Hoster-Support hat heute auf meine Anfrage ob und wo GIT installiert sei, Beschied gegeben:

Zitat:

---

Wir stellen soweit die technischen Anforderungen zur Verfügung, Applikationssupport dafür können wir so aber leider nicht geben.

Das GIT Binarie ist unter folgendem Pfad verfügbar:
/usr/local/bin/git

Wenn bei Ihrem Programm die Meldung kommt dass GIT nicht gefunden wurde, ist dort allenfalls ein falscher Pfad hinterlegt. Wo Sie dies aber genau definieren kann ich Ihnen leider nicht sagen.

---

Hat jemand Ahnung ob der Pfad /usr/local/bin/git passen sollte für die Composer Anbindung in Contao?
Oder sucht Contao/Composer woanders?
Kann ich Composer da irgendwie auf die Sprünge helfen?
Vielleicht kann der Hoster ja auch einen symlink setzten ... Müsst dann nur wissen wohin.

Oder muss ich mich für die Frage des Pfades/Umleitung oder Veränderung/symLink Target oder der ENV -Variablen des Server direkt an die Composer Jungs und Mädels wenden? Ich weiß nicht, ob Composer für Contao verändert wurde, oder einfach so ist wie überall sonst ...
Vielen Dank schon im Voraus für Tipps und Hilfen.

Ticket: Glaubensfrage. Aber da die composer.json in die Versionierung eingecheckt wird, sind Zugangsdaten da drin generell nicht ganz glücklich - insoweit schon richtig, dass es nicht zwingend beachtet werden muss. Gibt ja auch die auth.json.

GIT @ Provider: hast Du SSH-Zugang zum Hostingpaket? Im Normalfall ist aber /usr/local/bin ein Standardpfad, der funktionieren müsste.

Lade mal eine PHP-Datei mit folgendem Inhalt hoch:

Code:

---

<?php var_dump(exec('echo $PATH'));

---

und öffne die Datei mit dem Browser. Die Ausgabe wieder hier posten.

Hallo Michael,
auf dem Server habe ich leider keinen SSH Zugriff. Daher auch kein SSH-Key möglich.
Ich habe auf Deinen Tipp mit dem var_dump auf $PATH den Wert:
string(60) "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
erhalten.

Habe den Support daraufhin angefragt, in welchem Pfad GIT abgelegt sei. Antwort:

Zitat:

---

Das GIT Binarie ist unter folgendem Pfad verfügbar:
/usr/local/bin/git

---

Leider hat sich durch nochmaliges Nachfragen herausgestellt, dass der Pfad bereits auch das Binary beinhaltete. Antwort:

Zitat:

---

Das "git" am Ende von /usr/local/bin/git ist das Binary. Der Pfad selbst lautet also "/usr/local/bin/" und das Binary sollte demnach eigentlich gefunden werden.

---

Also scheint der Pfad zu GIT in den Pfaden $PATH abgedeckt ...

Keine Ahnung, warum es trotzdem dazu führt, dass GIT nicht gefunden wird.
Aber durch die auth.json klappt es ja gut ohne.

Vielen Dank noch einmal für Deine Mühe. Der Hoster ist sowieso nicht mein Lieblingshoster. Sonst läuft es ja 1A. Ich denke das passt.
Martin