Screen Shot 2014-06-27 at 21.14.28 There is an update available for your software!

Letztes Jahr habe ich hier eine Anleitung veröffentlich wie man gitlab 4.1 auf einem uberspace installiert. Mit Version 5 wurde dann von gitolite auf eine eigene gitlab-shell umgestellt und plötzlich war das setup so nicht mehr möglich.

Letzte Woche wurde ich dann auf eine Anleitung von @ricwein gestoßen, der behauptete genau das mit der aktuellen Version geschafft zu haben. und er hat!

Ich habe soeben die Installation abgeschlossen und es läuft wunderbar! Für die Installation schaut ihr bitte bei ricwein im gitlab nach.

Ich möchte lediglich ein paar Hinweise dazu geben.

charolck_holmes auf CentOS 5

Zunächst einmal kann es passieren das auf CentOS 5 hosts beim installieren der gems ein Fehler mit charlock_holmes auftreten. Die Uberspace-Doku kennt aber das Problem und weiß auch abhilfe:

bundle config build.charlock_holmes --with-icu-dir=/package/host/localhost/icu4c

SSH-Key konfiguration

Nun aber zum spannendsten Thema SSH. Ich bevorzuge die Authentifizierung mittels Public-Key. Das ist sicher und unglaublich praktisch. Nun gibt es hier aber ein kleines Prioritätsproblem: Gitlab-Shell lässt keinen Shell zugriff zu und das ist gut so. Blöd nur, wenn ich vom gleichen Rechner aus sowohl git- als auch shell-access haben möchte.

Als Lösung schlage ich daher vor: Installiert euch gitlab in einer subdomain und stellt die URLs die ricwein immer mit der normalen uberspace domain angegeben hat auf eure subdomain um. Vor allem in der git-shell config die gitlab_url und in der gitlab/config/gitlab.yml den host von gitlab (Beides die gleichen Domains)

Nun legt ihr euch für gitlab einen neuen SSH Key auf eurem lokalen rechner an. Zum Beispiel mit:

ssh-keygen -f ~/.ssh/gitlab_rsa anschließend Editiert ihr eure ~/.ssh/config und passt sie wie folgt an (git.kanedo.net durch den eigenen host ersetzen):

Host git.kanedo.net
     IdentityFile ~/.ssh/gitlab_rsa
     IdentitiesOnly yes

Wenn ihr jetzt per ssh (oder eben git) auf euer gitlab zugreift wird automatisch der neue schlüssel verwendet (den ihr euch ins gitlab eintragen müsst) und ihr habt keinen Shell zugriff – nur git. Nutzt ihr als host die uberspace domain (oder jede andere domain die nicht eurer gitlab ist), wird der SSH Key genommen der ganz normal in der authorized_keys drin steht und ihr habt shell zugriff. Toll :-)

Die Ubernauten haben mich auf Twitter daraufhingewiesen das die SSH-Config nicht wirklich auf einen echten Host beschränkt ist. Man kann diese Namen eher als Shortcut oder Bookmark verstehen und dann mittels Hostname in einem solchen Abschnitt den tatsächlichen Host angeben. Damit kann man sich nun beliebig komplexe Setups zimmern.

daemontools

Wer einen uberspace account sein eigenen nennt kenn auf jeden fall daemontools. Damit kann man services verwalten. Ich habe die für gitlab nötigen script in meinem gitlab. Da könnt ihr sie euch herunterladen und auf eurem account verwenden (Anleitung im README)