Gitlab auf deinem Uberspace installieren
Also, da ich im Moment auf Uberspace umziehe, habe ich viel Zeit drauf verwendet (mit viel Unterstützung des Teams, großes Lob dafür! :) ) einige Sachen zum Laufen zu bringen. Insbesondere viel Zeit auf Gitlab.
Ich bin im Wiki unter Brainstorming auf Gitlab gestoßen, und fühlte mich ein wenig herausgefordert von der Aussage, dass das auf Uberspace nicht laufen würde. Also habe ich einfach mal angefangen, und siehe da? Mit viel Trickserei, geht es!
(Ich beziehe mich hier jetzt auf die v2.4 um sicher stellen zu können, dass die Anleitung auch wirklich funktioniert und es auch in Zukunft wird.)
Grundlagen schaffen
Für diejenigen, die gitolite schon eingerichtet haben, ist dieser Abschnitt auch wichtig. Ich habe für gitolite extra einen SSH-Key generiert, damit ich meinen noch für mich selber in Gitlab eintragen konnte, dafür ist ein wenig Trickserei nötig.
Git konfigurieren
Falls ihr euer git noch nicht konfiguriert habt, macht folgende Einstellungen:
1
2
git config --global user.email "<you@your-provider.tld>"
git config --global user.name "<Your Name>"
Lokaler tmp-Ordner
Da es Gitlab irgendwie darauf anlegt möglichst nicht mit Shared-Hosting-System zu kooperieren legt es eine persönliche Datei in /tmp/ an, die nur euch gehört, was verhindert, dass irgendjemand anderes gitlab erfolgreich zum Laufen bringt. (Vielen Dank an dieser Stelle an Jonas, der mich auf das Problem aufmerksam gemacht hat.)
Um das zu verhindern, müsst ihr in eurem Heimverzeichnis einen eigenen tmp-Ordner anlegen:
1
mkdir ~/tmp
Und dann folgende Zeile in die .rc eurer Shell eintragen:
1
export TMPDIR=$HOME/tmp
Wenn ihr zsh nutzt wäre das die ~/.zshrc und bei bash (im Zweifelsfall nutzt ihr bash) ~/.bashrc.
SSH-Key generieren
1
ssh-keygen -f admin
Den Password-Prompt könnt ihr einfach leer lassen.
Setup gitolite[2]
Entfernt bitte nicht euren SSH-Key aus .ssh/authorized_keys, weil ihr euch sonst nicht mehr einloggen könnt.
1
2
3
gl-setup admin.pub
mv admin .ssh/id_rsa
mv admin.pub .ssh/id_rsa.pub
Außerdem müsst ihr in der ~/.gitolite.rc die Einstellung UMASK auf 0007 setzen.
Danach solltet ihr auch aus eurem Uberspace einmal selbst sshen, wenn das Ergebnis aussieht wie unten, ist alles gut:
1
2
3
4
5
6
7
8
9
10
11
ssh <uberspacename>@<uberspacehost>.uberspace.de
% ssh alexex@julo.ch
The authenticity of host 'julo.ch (2001:1a50:11:0:5f:8f:ac4f:a8)' can't be established.
RSA key fingerprint is 82:24:b5:69:28:63:8a:fd:97:2a:6e:2d:71:b8:0c:07.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'julo.ch,2001:1a50:11:0:5f:8f:ac4f:a8' (RSA) to the list of known hosts.
hello admin, the gitolite version here is v2.0-25-g78444c2
the gitolite config gives you the following access:
R W gitolite-admin
@R_ @W_ testing
Connection to julo.ch closed.
Danach einmal das Repo klonen und wieder löschen, nur zur Sicherheit. ;)
1
2
git clone <euer uberspace name>@localhost:gitolite-admin
rm -rf gitolite-admin
Ruby
Um Probleme zu vermeiden, solltet ihr RVM nach dieser Anleitung installieren.
Danach installiert ihr euch mit dem folgenden Befehl Ruby 1.9.2, aktiviert es und installiert bundle und sqlite3[3]:
1
2
3
4
5
6
rvm install 1.9.2
rvm use 1.9.2
gem install --no-rdoc --no-ri bundler charlock_holmes
gem install sqlite3 -v "1.3.5" -- \
--with-sqlite3-include=/package/host/localhost/sqlite-3/include \
--with-sqlite3-lib=/package/host/localhost/sqlite-3/lib
Redis
Ein wirklich schwieriges Problem, da Redis nicht wirklich gut für shared-hosting ist, aber gut. Was sein muss, muss sein. Installiert es mit:
1
toast arm redis
Dann solltet ihr es konfigurieren, dazu legt ihr den Ordner ~/.redis an und darin eine Datei conf mit folgendem Inhalt:
1
2
3
4
unixsocket /home/<euer uberspace name>/.redis/sock
daemonize yes
logfile /home/<euer uberspace name>/.redis/log
port 0
Nach der Konfiguration könnt ihr es dann so starten:
1
redis-server ~/.redis/conf
Gitlab
Installation
Ich nutze in diesem Beispiel die stabile Version von Gitlab. Zunächst solltet ihr euch den Source von Github laden:
1
2
3
4
wget https://github.com/gitlabhq/gitlabhq/zipball/v2.4.1
unzip v2.4.1
mv gitlabhq-gitlabhq-432bd54 gitlab
cd gitlab
Konfiguration
Am besten kopiert ihr erstmal die Konfigurationsdateien und passt diese an:
1
2
cp config/database.yml.example config/database.yml
cp config/gitlab.yml.example config/gitlab.yml
Ihr solltet in der neu erstellten database.yml euere Zugangsdaten eintragen und die Databases mit eurem Uberspace-Usernamen prefixen, damit ihr die Berechtigung habt sie anzulegen.
Die gitlab.yml sollte nach diesem Schema angepasst werden:
1
2
3
4
5
6
7
8
9
10
11
12
email:
from: notify@<uberspacename>.<uberspacehost>.uberspace.de
host: <uberspacename>.<uberspacehost>.uberspace.de
# Git Hosting congiguration
git_host:
system: gitolite
admin_uri: <uberspacename>@localhost:gitolite-admin
base_path: /home/<uberspacename>/repositories/
host: <uberspacename>.<uberspacehost>.uberspace.de
git_user: <uberspacename>
# port: 22
Dann installiert ihr die anderen Abhängigkeiten von gitlab mit bundle, das kann ein wenig dauern:
1
bundle install --without development test
Initialisierung
Mit folgenden Befehlen könnt ihr dann die Datenbanken initialisieren:
1
2
bundle exec rake db:setup RAILS_ENV=production
bundle exec rake db:seed_fu RAILS_ENV=production
Resque
Erwähnte ich bereits, dass Redis schwierig vom Handling her ist? Ist es nämlich. Damit Resque mit eurem Redis-Socket arbeitet müsst ihr jetzt noch ein wenig basteln.
Ihr müsst die Datei config/initializers/gitlabhq/30_resque_queues.rb ergänzen. Ihr müsst vor die Zeile, die schon in der Datei steht folgende Zeile einfügen:
1
Resque.redis = Redis.new(:path => "/home/<euer uberspace name>/.redis/sock")
Desweiteren solltet ihr in lib/post-receive-hook das redis-cli durch /home/<euer uberspace name>/.toast/armed/bin/redis-cli -s /home/<euer uberspace name>/.redis/sock ersetzen, um ein einwandfreies Funktionieren zu gewährleisten.
Danach einfach mit ./resque.sh starten und fertig.
Deployment
Es gibt verschiedene Möglichkeiten gitlab zu deployen, ich habe mich gegen fastcgi und für ein Durschleifen des Rails-Servers entschieden, da Ruby on Rails wahnsinnig lange braucht, um zu starten.
Da der interne Server von Ruby on Rails nicht der Blitz schlechthin ist, habe ich mich für thin entschieden. Einfach mit
1
gem install thin
installieren und schon ist er einsatzbereit.
Damit die Assets funktionieren müsst ihr in config/environments/production.rb folgende Einstellung verändern:
1
config.serve_static_assets = true
Zunächst solltet ihr Gitlab mit folgendem Befehl starten:
1
cd ~/gitlab && rvm use 1.9.2 && thin start --environment production --port <Port> --daemonize
Für Port solltet ihr zufällig einen freien 5-stelligen Port aussuchen, damit ihr keinen Konflikt mit anderen Nutzern auf dem selben Host bekommt.
Apache-Rewrites einrichten
Damit ihr euer Gitlab auch von außerhalb erreichen könnt, geht ihr in euer ~/html oder in einen Unterordner davon (oder wenn ihr eine Domain bzw. Subdomain habt, unter dem Gitlab erreichbar sein soll, in die passenden Ordner) und legt folgende .htaccess-Datei an:
1
2
RewriteEngine On
RewriteRule (.*) http://localhost:<Port>/$1 [P]
Wobei der Port der Port sein muss, mit dem ihr eben Gitlab gestartet habt.
Gitlab im Unterordner
Wenn ihr Gitlab in einem Unterordner betreiben wollt, müsst ihr im gitlab-Ordner noch in der config/environments/production.rb anpassen. Setzt dazu:
1
config.action_controller.asset_host = "http://<domain.tld>/<euer unterordner>"
Zudem müsst ihr thin dann mit dem zusätzlichen Argument --prefix /<unterordner> starten, dann sollte alles gehen.
Und als letztes noch die .htaccess anpassen:
1
2
RewriteEngine On
RewriteRule (.*) http://localhost:<Port>/<unterordner>/$1 [P]
HTTPS
Da ich mich hierfür nicht im Geringsten verantwortlich zeigen kann, zitiere ich einfach mal Jonas:
Außerdem dann gleich noch eine Anmerkung für User, die GitLab via HTTPS laufen lassen wollen (unabhängig von den Unterverzeichnis-Sachen): Das funktioniert natürlich schon durchaus, aaaber: Da der Apache mit thin ja via HTTP kommuniziert, glaubt thin, es würde eben HTTP gesprochen. Wenn daraufhin Redirects generiert werden, generiert es die Ziel-URLs mit “http://” - der User fliegt also aus der SSL-Session. Schlimmer noch: Setzt man
config.force_ssl = true, wird ein Endlos-Redirect daraus, weil thin ja immer glaubt, es sei kein HTTPS im Spiel.Trick 17: Einfach diese Zeile in der
.htaccess-Datei ergänzen …
RequestHeader set X-Forwarded-Proto https… damit weiß thin dann, dass das Frontend sehr wohl HTTPS mit dem User spricht, und generiert dann alles Redirects auch mit
https://. (Es obliegt dann natürlich dem User selbst, sicherzustellen, dass auch wirklich HTTPS zum Einsatz kommt, denn thin glaubt das ja durch diesen Header fortan immer.)
Konfiguration des Webinterfaces
Danach solltet ihr das Administratorpasswort ändern und euren ersten User anlegen: Euch selbst! Ihr loggt euch mit den Standard Zugangsdaten ein geht auf Users und dann auf Edit beim Administratoraccount. Dort ändert ihr das Passwort und speichert. Danach müsst ihr euch mit dem neuen Passwort wieder einloggen.
Dann legt ihr einen neuen User mit eurem Namen und eurer E-Mail-Adresse an, macht ihn zum Admin und loggt euch als ihr selber ein. Fügt euren SSH-Key hinzu und schon kann es losgehen.
SSH-Key Verwirrung?
Solltet ihr euren eigenen SSH-Key, den ihr auch so für den SSH-Login hinzugefügt habt, auch für Gitlab nutzen wollen, so müsst ihr noch eine Sache tun. Fügt euren Key erneut mit
1
gl-tool add-shell-user <yourkey>.pub
Sucht dann euren SSH-Key in der .ssh/authorized_keys. Der sollte jetzt 2x vorhanden sein. Ihr müsst nun den Namen hinter gl-auth-command bei dem Key im # gitlolite-Bereich suchen und im ersten Eintrag mit eurem SSH-Key einfügen. Nur so erkennt Gitlab euren Accounts bei Pushs und trotzdem könnt ihr euch normal in die Shell einloggen.
Wenn etwas nicht passt, ihr auf Probleme stoßt oder euch Fehler auffallen, links klicken für E-Mail. Weitere Kontaktmöglichkeiten findet ihr unter “About”, ansonsten auch gerne einen Kommentar direkt hier schreiben. :-)
