Ich richte eine Gitlab-Instanz in meinem VM-Labor zu Hause ein und bin verblüfft über die Art und Weise, wie SSH in Gitlab konfiguriert ist. Daher würde ich gerne wissen, ob ich etwas falsch mache oder ob Gitlab eine Konvention verwendet, die mir nicht bekannt ist.
Ich habe gerade Gitlab 7.10 CE unter CentOS 7 unter ESXi 5.5 U2 installiert yum install gitlab-ce. Vor der ersten Neukonfiguration von gitlab habe ich /etc/gitlab/gitlab.rbdie Verwendung einer externen Postgresql-Datenbank, eines definierten externen SMTP-Servers, eines externen Ports und eines externen Git-Repository-Verzeichnisses (NFS-unterstütztes Verzeichnis von meinem NAS) geändert .
Alles läuft reibungslos ( gitlab-ctl reconfigurewirft keine Ausnahmen, gitlab-rake gitlab:checkbehebt keine Fehler, ich kann mich an der Instanz anmelden, ich kann Projekte erstellen und ich sehe, dass die Änderungen in das NFS-gesicherte Verzeichnis übertragen werden) - bis zu dem Zeitpunkt, an dem ich versuche, das Git-Repository für das zu pushen Erstmalige Verwendung generierter Anweisungen von der Projektwebseite (ich verwende msysgit, um auf Git Repo zu pushen, falls dies überhaupt aus der Ferne relevant ist).
Es gibt keine andere Instanz / Installation von gitauf dem Server als die von gitlab eingebettete - die offiziellen Anweisungen haben dies nicht als notwendig erwähnt und das klingt vernünftig; Warum brauche ich überhaupt zwei Git-Instanzen? Es klingt nach Ärger.
Bei Bedarf werde ich gitlab-rakedie Ausgabe hier als Update veröffentlichen, aber ich möchte die Größe des Beitrags zunächst reduzieren.
client user ssh key -> über die Gitlab-Weboberfläche hinzugefügt
server git bin path -> /opt/gitlab/embedded/bin/git
server git home dir -> /var/opt/gitlab/
server git shell -> sh
gitlab project group ->algorithms
Hier ist die Chronologie meiner Bemühungen:
Aktion :
$ git push -u origin master
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Antwort : Fügen Sie den autorisierten Schlüssel zum .ssh-Verzeichnis des git-Benutzers hinzu.
Aktion :
$ git push -u origin master
sh: git-receive-pack: command not found
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
$ ssh git@remote-machine.net echo \$PATH
/usr/local/bin:/usr/bin
Antwort : Fügen Sie die ~git/.profileDatei dem gitBenutzer mit dem exportierten eingebetteten Git-Pfad hinzu. Fügen Sie die ~git/.ssh/environmentDatei mit dem exportierten eingebetteten Git-Pfad hinzu (für den nicht interaktiven Shell-Modus). Geändert /etc/ssh/sshd_config, um die neue Konfiguration zu akzeptieren. Neu gestartet sshd.
Aktion :
$ ssh git@remote-machine.net echo \$PATH
/usr/local/bin:/usr/bin:/opt/gitlab/embedded/bin/
$ git push -u origin master
fatal: 'algorithms/sedgewick-book.git' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Maßnahme (motiviert durch SO-Post ): Es wurde eine explizite AllowUsers <...> gitAnweisung hinzugefügt , sshdobwohl ich keinen Nicht-Standard-Port verwende.
Antwort : keine. Gleiche Fehlermeldung wie zuvor.
Aktion : Ich habe den Verdacht, dass in der SSH-URL etwas fehlt. Daher habe ich angefangen, den vollständigen Pfad zu meinem Remote-Repository zu verwenden, obwohl ich dies nicht tun sollte und Gitlab es während des anfänglichen Projekt-Setups nicht generiert.
$ git push origin master
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (5/5), 520 bytes | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)
remote: GitLab: No such user or key
To git@remote-machine.net:/mnt/git/repositories/algorithms/sedgewick-book.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@remote-machine.net:/mnt/git/repositories/algorithms/sedgewick-book.git'
Antwort : Keine. Siehe Fehler oben.
An dieser Stelle muss ich mich geschlagen geben. Ich habe versucht, einen anderen gitlab-Namespace zu verwenden (nämlich meinen eigenen Benutzernamen anstelle der Projektgruppe). Ich habe versucht, meinen gitlab-Benutzernamen genau mit dem auf dem SSH-Schlüssel verwendeten Benutzernamen abzugleichen. Ich habe versucht, ein Commit über die Gitlab-Benutzeroberfläche unter origin / zu erstellen. Master und dann den Zweig ungeschützt - das Endergebnis ist immer das gleiche, Fehler oben.
Es ist sehr zu vermuten, dass ich den absoluten Pfad zum Repository angeben sollte (der Client sollte nicht wissen, wo sich das Repository befindet!) Und die Gitlab-Gruppen haben keine Metadaten, die sich störend auswirken und zusätzliche Daten einspeisen könnten unter dem Tisch (ich sehe sie als triviale Convenience-Container von Projekten).
Letztendlich hatte dieser SO-Beitrag ein sehr ähnliches Problem für mich, aber die vorgeschlagene Lösung macht nicht viel Sinn - es ist, als würde ich für jede Gruppe einen eigenen Gitlab-Benutzer erstellen, was völlig verrückt wäre, ganz zu schweigen von dem, was ich habe Ich habe bereits erfolglos versucht, den Pfadnamen des Repositorys mit dem Gitlab-Benutzernamen abzugleichen (nota bene, das ist auch wirklich fragwürdig, aber ich war verzweifelt, also habe ich es versucht).
Der Fehler zeigt an, dass Gitlab nicht weiß, wie man den (Git-) Benutzer findet, mit dem ich pushe, aber ich weiß nicht, was ich sonst noch versuchen soll Git-Client-Name (wird im öffentlichen SSH-Schlüssel selbst verwendet).
Ich weiß nicht, was ich sonst noch versuchen soll. Irgendwelche Tipps, bitte?