Ich möchte mir auf meinem Laptop (Windows 10) gerne zu Testzwecken eine kleine Build-Pipeline aufbauen. Als Git-Server soll dabei der Git-Server auf meinem NAS (DS-415) dienen, der Jenkins soll vorläufig auf meinem Laptop laufen (evtl. später einmal ebenfalls auf dem NAS in einem Docker-Container, aber das ist vorläufig noch Zukunftsmusik).
Ich habe dazu das Git-Server package auf dem NAS installiert und gemäss https://www.synology-wiki.de/index.php/Git_Server ein Git-Repo angelegt:
Ort des Repo's auf dem NAS: /volume1/git_repos/ci-cd/first-steps.git
User: gituser (Mitglied der Gruppen "users" und "administrators").
Was ich als erstes schon mal nicht kapiere: ich habe beim ersten Mal das initiale git init --bare --shared unter dem neu angelegten "gituser" ausgeführt. Das Kreieren des Repos hat zwar funktioniert (zumindest gab es keinerlei Fehlermeldung), als ich dann aber von meinem Laptop via git commandline unter der user-id "gituser" auf das Repo zugereifen wollte, kam immer nur der Fehler "Permission denied or the location is not a git repo".
Ich habe das repo dann wieder gelöscht, das init noch einmal, diesmal als user admin ausgeführt. Danach ging der Zugriff via git commandline (aber immer noch als user "gituser"!) dann.
Warum ist das so??? Was ist der Unterschied, ob ich das repo auf dem NAS als gituser oder als admin anlege? Klar, die Files gehören im ersten Fall alle dem "gituser", im zweiten Fall dem user "admin", aber warum juckt das den Git-Server? Egal, ob der als admin oder als gituser läuft, er sollte doch in beiden Fällen auf diese Files zugreifen können, zumal alle Directories als drwxrwsrwx und alle Files mindestens als -rw-rw-r-- definiert sind und gituser ebenfalls Mitglied der Gruppe "administrators" ist. Ist dieses Requirement, dass neue Repositories imemr als admin erzeugt werden müssen, irgendwo dokumentiert und begründet?
Was mich aber noch viel mehr nervt, weil ich dort momentan völlig anstehe:
Ich kann nun - wie gesagt - via die Git commandline (Git-2.21.0-64-bit) auf das Repo zugreifen (push & fetch), nachdem ich auf meinem Laptop den origin auf "ssh://gituser@192.168.1.15:/volume1/git_repos/ci-cd/first-steps.git" gesetzt habe.
Wenn ich die genau gleiche Repo-URL im Jenkins eingebe, dann erhalte ich immer nur die Fehlermeldung:
Warum hat Jenkins keinen Zugriff auf das Repo, während der Zugriff via die Git-commandline funktioniert?
Ich habe sogar den im Log aufgeführten Befehl "C:/Program Files/Git/bin/git.exe" ls-remote -h ssh://gituser@192.168.1.15:/volume1/git_repos/ci-cd/first-steps.git HEAD auf der Kommandzeile ausgeführt - ich erhalte keinerlei Fehlermeldung (allerdings auch keinerlei output, es kommt einfach wieder das Prompt).
Es ist der gleiche Rechner (also sicher keine Firewalls oder dergleichen), der gleiche User und die Credentials, die man in Jenkins dazu definieren muss, habe ich selbstredend definiert (und mehrmals verifiziert). Hat jemand eine Idee, warum das nicht funzt? Was ich hier versuche, ist doch nicht derart exotisch! Das haben doch sicher schon hunderte andere auch schon probiert ...
Ich habe dazu das Git-Server package auf dem NAS installiert und gemäss https://www.synology-wiki.de/index.php/Git_Server ein Git-Repo angelegt:
Ort des Repo's auf dem NAS: /volume1/git_repos/ci-cd/first-steps.git
User: gituser (Mitglied der Gruppen "users" und "administrators").
Was ich als erstes schon mal nicht kapiere: ich habe beim ersten Mal das initiale git init --bare --shared unter dem neu angelegten "gituser" ausgeführt. Das Kreieren des Repos hat zwar funktioniert (zumindest gab es keinerlei Fehlermeldung), als ich dann aber von meinem Laptop via git commandline unter der user-id "gituser" auf das Repo zugereifen wollte, kam immer nur der Fehler "Permission denied or the location is not a git repo".
Ich habe das repo dann wieder gelöscht, das init noch einmal, diesmal als user admin ausgeführt. Danach ging der Zugriff via git commandline (aber immer noch als user "gituser"!) dann.
Warum ist das so??? Was ist der Unterschied, ob ich das repo auf dem NAS als gituser oder als admin anlege? Klar, die Files gehören im ersten Fall alle dem "gituser", im zweiten Fall dem user "admin", aber warum juckt das den Git-Server? Egal, ob der als admin oder als gituser läuft, er sollte doch in beiden Fällen auf diese Files zugreifen können, zumal alle Directories als drwxrwsrwx und alle Files mindestens als -rw-rw-r-- definiert sind und gituser ebenfalls Mitglied der Gruppe "administrators" ist. Ist dieses Requirement, dass neue Repositories imemr als admin erzeugt werden müssen, irgendwo dokumentiert und begründet?
Was mich aber noch viel mehr nervt, weil ich dort momentan völlig anstehe:
Ich kann nun - wie gesagt - via die Git commandline (Git-2.21.0-64-bit) auf das Repo zugreifen (push & fetch), nachdem ich auf meinem Laptop den origin auf "ssh://gituser@192.168.1.15:/volume1/git_repos/ci-cd/first-steps.git" gesetzt habe.
Wenn ich die genau gleiche Repo-URL im Jenkins eingebe, dann erhalte ich immer nur die Fehlermeldung:
Rich (BBCode):
Failed to connect to repository : Command "C:/Program Files/Git/bin/git.exe ls-remote -h ssh://gituser@192.168.1.15:/volume1/git_repos/ci-cd/first-steps.git HEAD" returned status code 128:
stdout:
stderr: Permission denied, please try again.
Permission denied, please try again.
gituser@192.168.1.15: Permission denied (publickey,password).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.Warum hat Jenkins keinen Zugriff auf das Repo, während der Zugriff via die Git-commandline funktioniert?
Ich habe sogar den im Log aufgeführten Befehl "C:/Program Files/Git/bin/git.exe" ls-remote -h ssh://gituser@192.168.1.15:/volume1/git_repos/ci-cd/first-steps.git HEAD auf der Kommandzeile ausgeführt - ich erhalte keinerlei Fehlermeldung (allerdings auch keinerlei output, es kommt einfach wieder das Prompt).
Es ist der gleiche Rechner (also sicher keine Firewalls oder dergleichen), der gleiche User und die Credentials, die man in Jenkins dazu definieren muss, habe ich selbstredend definiert (und mehrmals verifiziert). Hat jemand eine Idee, warum das nicht funzt? Was ich hier versuche, ist doch nicht derart exotisch! Das haben doch sicher schon hunderte andere auch schon probiert ...
Zuletzt bearbeitet:
