Anleitung: GitLab 3.0 bei Uberspace.de installieren

GitLab ist ein Webinterface, ähnlich dem vom GitHub, welches die Projektverwaltung mit Git um einiges erleichtert. Dabei vereint es mehrere Elemente, wie Issues, Wiki oder Mehrbenutzer-Verwaltung. (GitLab Demo.)

Vor kurzem habe ich von GitLab gehört und wollte die Anwendung auf meinem Uberspace ausprobieren. Schaut man sich allerdings die Installationsanleitung an, so überschlägt sich diese nur so von sudo Aufrufen. Ein Hindernis für die Installation auf Uberspace.
Doch es geht auch ohne!

Die Anleitung bezieht sich auf eine GitLab Installation von Grund auf und umfasst 15 Schritte.
Als Grundlage habe ich die Anleitung vom Alexander (Danke!) aufgegriffen und entsprechend der jeweiligen neuen Versionen angepasst.

Diese Anleitung ist veraltet. Bitte schaut beim Tutorial HowTo install Gitlab at Uberspace vom Richard vorbei.

0. Vorbereitungen

Dinge, die du nun brauchst:

Etwas Geduld und Zeit
Grundwissen über die Shell
Einen Uberspace Account :-)

(Sofern nicht anders angeben, werden die folgenden Befehle im Home-Verzeichnis ausgeführt. <uberspacename> bitte mit Deinem Benutzernamen ersetzen, analog <uberspacehost> mit dem Servernamen.)

1. Git aktualisieren und konfigurieren

Wer möchte kann zunächst Git auf Version 1.8.0 aktualisieren. Dies kann mithilfe von toast erledigt werden. (Sollte kein gettext installiert sein, muss dies zuerst installiert werden.)

$ toast arm http://ftp.gnu.org/pub/gnu/gettext/gettext-0.18.1.1.tar.gz
$ toast arm http://git-core.googlecode.com/files/git-1.8.0.tar.gz

Wenn noch nicht geschehen, dann müssen Name und E-Mail-Adresse für Git festgelegt werden:

$ git config --global user.email "<mail@example.com>"
$ git config --global user.name "<Dein Name>"

2. Temporären Ordner anlegen

Da GitLab temporäre Dateien anlegt, sollte ein temporären Ordner im Home-Verzeichnis anlegt werden. Damit hast auch wirklich nur Du Zugriff auf dein GitLab.

$ mkdir ~/tmp

Damit der Ordner genutzt wird, muss die Shell-Konfiguration (.rc, .bashrc oder .zshrc) um Folgendes erweitert werden:

export TMPDIR=$HOME/tmp

3. SSH-Key generieren

Für gitolite wird ein eigener SSH-Key generiert:

$ ssh-keygen -t rsa -f admin -C "GitLab Key"

(Passwort-Eingabe überspringen.)

4. gitolite installieren und konfigurieren

gitolite dient für die Benutzerverwaltung der Git-Repositories. Die Jungs von Uberspace bieten dazu ein Setup-Skript an. Dies kann genutzt werden:

$ gl-setup admin.pub

Danach die eben angelegten Keys ins SSH Verzeichnis verschieben…

$ mv admin .ssh/id_rsa.gitlab
$ mv admin.pub .ssh/id_rsa.gitlab.pub

…, damit der Key genutzt wird, eine SSH-Config anlegen (wenn noch nicht vorhanden)…

$ touch .ssh/config
$ chmod 600 .ssh/config

…und schließlich die Key Datei verlinken:

$ echo -e "Host <uberspacehost>.uberspace.de localhost\n\tIdentityFile ~/.ssh/id_rsa.gitlab" >> .ssh/config

Zur Überprüfung einmal den Host per SSH aufrufen:

$ ssh <uberspacename>@<uberspacehost>.uberspace.de

Die Antwort sollte in etwa so aussehen:

The authenticity of host 'XXXXXXXX' can't be established.
RSA key fingerprint is XX:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XXXXXXXX,XXXXXXXX' (RSA) to the list of known hosts.
hello admin, this is gitolite 2.3.1-1.el6 running on git 1.8
the gitolite config gives you the following access:
 R   W  gitolite-admin
 @R_ @W_    testing
Connection to XXXXXXXX closed.

Um später keine Problem mit der Authentifizierung in Git zu haben, sollte das Repo einmal geklont werden. Danach kann es wieder gelöscht werden:
(Die aufkommende Frage auch wieder mit yes beantworten.)

$ git clone <uberspacename>@localhost:gitolite-admin
$ rm -rf gitolite-admin

Zur Konfiguration die Datei .gitolite.rc aus dem Home-Verzeichnis öffnen und die folgenden Variablen abändern:

$GL_GITCONFIG_KEYS auf $GL_GITCONFIG_KEYS = ".*"; setzen und $REPO_UMASK auf $REPO_UMASK = 0007; setzen.

5. Ruby installieren

GitLab basiert auf Ruby on Rails. Um Ruby zu installieren gibt es zwei Möglichkeiten.

Möglichkeit 1:

Uberspace bietet die Version 1.9.3 global an. Den Wiki-Eintrag bitte lesen; zusammengefasst:

$ cat <<'__EOF__' >> ~/.bash_profile
export PATH=/package/host/localhost/ruby-1.9.3/bin:$PATH
export PATH=$HOME/.gem/ruby/1.9.1/bin:$PATH
__EOF__
$ echo "gem: --user-install --no-rdoc --no-ri" > ~/.gemrc

Danach kann Bundler und CharlockHolmes installiert werden

$ gem install bundler charlock_holmes
$ bundle install --path ~/.gem

Nachteil: Man hat nicht die aktuelle Ruby Version zur Verfügung.

Möglichkeit 2:

Den Ruby Version Manager nach dieser Anleitung installieren.

Danach Ruby 1.9.3, Bundler, CharlockHolmes und sqlite3 (siehe Doku-Hinweis) installieren:

$ rvm install 1.9.3
$ rvm use 1.9.3
$ gem install --no-rdoc --no-ri bundler charlock_holmes
$ gem install sqlite3 -- \
  --with-sqlite3-include=/package/host/localhost/sqlite-3/include \
  --with-sqlite3-lib=/package/host/localhost/sqlite-3/lib

6. Redis installieren und konfigurieren

GitLab benötigt außerdem Redis. Dank toast wieder kein Problem:

$ toast arm http://redis.googlecode.com/files/redis-2.6.2.tar.gz

Zur Konfiguration den Ordner ~/.redis erstellen und in Diesem eine Datei names conf mit folgendem Inhalt anlegen:

unixsocket /home/<uberspacename>/.redis/sock
daemonize yes
logfile /home/<uberspacename>/.redis/log
port 0

7. GitLab installieren und konfigurieren

Nun ist GitLab selbst an der Reihe. Wir klonen uns das Repo und wechseln dann in den 3.0.3 Zweig:

$ git clone git@github.com:gitlabhq/gitlabhq.git gitlab
$ cd gitlab
$ git checkout v3.0.3 -q

Die Beispiel-Konfigurationsdateien kopieren…

$ cp config/database.yml.example config/database.yml
$ cp config/gitlab.yml.example config/gitlab.yml

…und die database.yml mit den richtigen Daten füllen. Achtung: Die Datenbanknamen müssen Deinen Benutzernamen mit Unterstrich als Präfix haben!

Danach gitlab.yml öffnen und folgendermaßen abändern:

web:
  host: <uberspacename>.<uberspacehost>.uberspace.de
  port: 80
  https: false

# Email used for notification
# about new issues, comments
email:
  from: noreply@<uberspacename>.<uberspacehost>.uberspace.de

# Git Hosting configuration
git_host:
  system: gitolite
  admin_uri: <uberspacename>@localhost:gitolite-admin
  base_path: /home/<uberspacename>/repositories/
  hooks_path: /home/<uberspacename>/.gitolite/hooks/
  gitolite_admin_key: gitlab 
  git_user: <uberspacename>
  upload_pack: true
  receive_pack: true
  host: <uberspacename>.<uberspacehost>.uberspace.de
  # port: 22

(Die Hosts können später, oder auch jetzt schon, mit einer beliebigen URL ersetzt werden.)

Wenn git über toast installiert wurde muss noch folgende Änderung gemacht werden:

# Git settings
# Use default values unless you understand it
git:
  path: /home/<uberspacename>/.toast/armed/bin/git

Danach die restlichen GitLab Abhängigkeiten installieren:

$ bundle install --without development test sqlite postgres  --deployment

Damit Redis und Resque miteinander harmonieren, müssen noch ein paar Änderungen vollzogen werden.
Öffne die Datei config/initializers/4_resque.rb und füge folgende Zeile am Anfang ein:

Resque.redis = Redis.new(:path => "/home/<uberspacename>/.redis/sock")

Öffne die Datei lib/hooks/post-receive und ersetze redis-cli mit /home/<uberspacename>/.toast/armed/bin/redis-cli -s /home/<uberspacename>/.redis/sock.

Jetzt die Hooks einrichten:

$ cp lib/hooks/post-receive ~/.gitolite/hooks/common/post-receive

Für das Deployment wird thin genutzt. Damit die Assets mit thin funktionieren muss in der Datei config/environments/production.rb die folgende Einstellung geändert werden:

config.serve_static_assets = true

8. Redis starten

Der Redis Server muss gestartet werden:

$ redis-server ~/.redis/conf

9. GitLab initialisieren

Jetzt kann die Datenbank und der Admin Account für GitLab angelegt werden. Das geht mit:

$ cd ~/gitlab
$ bundle exec rake db:setup RAILS_ENV=production
$ bundle exec rake db:seed_fu RAILS_ENV=production

10. GitLab Status Check

Um sicher zu gehen, dass bisher alles richtig gemacht wurde, sollte der Status der GitLab Installation geprüft werden:

$ cd ~/gitlab
$ bundle exec rake gitlab:app:status RAILS_ENV=production

Das Ergebnis sollte dem Screenshot ähnlich sein.

gitlab-app-status — Erfolgreiche Überprüfung der GitLab Installation

11. Resque starten

Wenn die Überprüfung erfolgreich war, kann Resque gestartet werden (könnte etwas dauern):

$ cd ~/gitlab
$ ./resque.sh

12. GitLab starten

Fast geschafft. Jetzt kann GitLab gestartet werden. Das geht über folgenden Aufruf (Wenn Ruby nicht über den RVM installiert wurde, && rvm use 1.9.3 weglassen):

$ cd ~/gitlab && rvm use 1.9.3 && bundle exec thin start --environment production --port <Port>

<Port> mit einem beliebigen, fünfstelligen, freien Port ersetzen.
Das Konsolenfenster noch nicht schließen! Es dient noch der späteren Überprüfung!

13. Apache-Rewrites anlegen

Damit GitLab im Web erreichbar ist, sollte im ~/html Verzeichnis eine .htaccess mit folgendem Inhalt angelegt werden:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule (.*) http://localhost:<Port>/$1 [P]
</IfModule>

<Port> mit dem selben Port wie beim thin Server ersetzen.

14. GitLab Installation finalisieren

Öffne GitLab im Browser, melde dich an (Name: admin@local.host, Passwort: 5iveL!fe, Passwort später unbedingt ändern!) und erstelle ein Beispiel-Projekt. Achte dabei auf das noch offene Konsolenfenster. Sollte dort keine Fehlermeldung erscheinen kann der thin-Server mit CTRL+C gestoppt werden.
Danach dann als Daemon wieder starten (Wenn Ruby nicht über den RVM installiert wurde, && rvm use 1.9.3 weglassen):

$ cd ~/gitlab && rvm use 1.9.3 && bundle exec thin start --environment production --port <Port> --daemonize

FERTIG!

Zum Thema

GITLAB: Self Hosted Git Management Application — gitlabhq.com
GitLab Demo — gitlabhq.com
Uberspace Doku: Ruby — uberspace.de
gitolite — github.com

Related

62 thoughts on “Anleitung: GitLab 3.0 bei Uberspace.de installieren”

Hendrik says:

31. October 2012 at 16:45

Hi,

Erstmal: Danke für diese Anleitung, GitLab kannte ich davor noch nicht, sieht aber wirklich viel versprechend aus!

Der Guide enthält jedoch einen kleinen Fehler: Ich musste Schritt 10 vor 9 ausführen, weil sich sonst darüber beschwert wurde, dass /home//.redis/sock nicht gefunden wurde (es war wirklich nicht vorhanden).

Danach ging alles reibungslos bis Schritt 13. Dort erhielt ich folgende Fehlermeldung http://d.pr/n/3m79 .
“bundle exec” meldet “bundler: exec needs a command to run”.

Ideen?
Einen gem mit dem Namen “daemons” hab ich im Gemfile nicht gefunden (kenne mich aber auch nicht gut mit Ruby aus)..

Viele Grüße,
Hendrik

Reply
1. Dominik Schilling says:
  
  31. October 2012 at 17:12
  
  Hi Hendrik,
  hab dir eine Mail geschickt.
  
  Wegen bundle exec, versuch mal bundle exec thin start --environment production --port <Port>.
  
  Edit:
  Danke fürs Testen. Reihenfolge ist geändert und bundle exec für die thin Aufrufe als Präfix gesetzt.
Gabriel says:

1. November 2012 at 17:08

Hi,
danke erst einmal für die Anleitung. Ich hatte gehofft, dass sich meine Probleme damit lösen, aber leider funktioniert es mit gitolite immer noch nicht, dass der User Write access gewährt bekommt. Folgendes sagt mir git push:
git push -u origin master
W access for test DENIED to kanedo
(Or there may be no repository at the given path. Did you spell it correctly?)
fatal: The remote end hung up unexpectedly

Hast du eine Idee woran das liegt?

Reply
1. Dominik Schilling says:
  
  1. November 2012 at 21:20
  
  Hi,
  meinst du einen neuen User oder dein Admin-Account? Was sagt denn der Status Check?
2. Gabriel says:
  
  2. November 2012 at 09:23
  
  Hi,
  der Test sagt folgendes:
  bundle exec rake gitlab:app:status RAILS_ENV=production
  Starting diagnostics
  config/database.yml…………exists
  config/gitlab.yml…………exists
  /home/kanedo/repositories/…………exists
  /home/kanedo/repositories/ is writable?…………YES
  remote: Counting objects: 25, done.
  remote: Compressing objects: 100% (19/19), done.
  remote: Total 25 (delta 4), reused 0 (delta 0)
  Receiving objects: 100% (25/25), done.
  Resolving deltas: 100% (4/4), done.
  Can clone gitolite-admin?…………YES
  UMASK for .gitolite.rc is 0007? …………YES
  /home/kanedo/.gitolite/hooks/common/post-receive exists? …………YES
  Validating projects repositories:
  test…..post-receive file missing
  rake aborted!
  unexpected return
  
  Tasks: TOP => gitlab:app:status
  (See full trace by running task with –trace)
  
  Also da scheint wohl etwas beim anlegen schief gelaufen zu sein.
3. Dominik Schilling says:
  
  2. November 2012 at 10:12
  
  Hast du mal geschaut, ob das Repo angelegt wurde? Sollte sich in ~/repositories befinden?
  
  Thin auch mal ohne den Daemon starten und dann ein neues Projekt erstellen. Dann in die Konsole schauen, was dort gesagt wird.
  
  $GL_GITCONFIG_KEYS = ".*"; in ~/.gitolite.rc ist auch gesetzt?
4. Gabriel says:
  
  3. November 2012 at 14:12
  
  Hi,
  $GL_GITCONFIG_KEYS = “.*”; in ~/.gitolite.rc ist gesetzt.
  Beim Anlegen eines neuen Projekts kommt folgende Meldung (unter anderem)
  
  Total 4 (delta 1), reused 2 (delta 0)
  remote:
  remote: ***** WARNING *****
  remote: the following users (pubkey files in parens) do not appear in the config file:
  remote: admin_local_host_1351785527(admin_local_host_1351785527.pub)
  
  Weißt du wie ich das beheben kann? Da scheint ja mein SSH-Setup nicht ganz zu stimmen oder?
  
  Aber das repository wird auf jeden fall angelegt.
5. Dominik Schilling says:
  
  5. November 2012 at 23:15
  
  Befindet sich die Datei denn in ~/.gitolite/keydir bzw. ~/.gitolite/conf/gitolite.conf?
  
  Hast du Gitolite mal deistalliert und es nochmal probiert?
6. Gabriel says:
  
  15. November 2012 at 09:00
  
  Ja mehrfach.
  Ich habe mich so eben dazu entschlossen, den großartigen Support von uperspace in Ansrpuch zu nehmen. Vielleicht haben die eine Idee.
  
  Aber danke dir für’s helfen und für die großartige Anleitung!
fralex says:

2. November 2012 at 00:05

Hallo,

Schritt 10 ausführe komme ich ein Fehler:

fatal: Not a git repository (or any of the parent directories): .git

Was kann ich machen um diesen Fehler zu beseitigen? Was sagt mir der Fehler?

Vielen Dank.

Gruß
fralex

Reply
1. Dominik Schilling says:
  
  2. November 2012 at 10:16
  
  Ich nehme mal an, dass er da versucht das gitolite-admin zu klonen. Hat das auch bei Schritt 4 nicht funktioniert?
2. fralex says:
  
  5. November 2012 at 22:32
  
  Ja, Schritt 4 hat funktioniert, aber die Meldung kriege ich immer noch.
3. Dominik Schilling says:
  
  5. November 2012 at 23:08
  
  Hast du die Installation nochmal probiert? (Gitolite deistallieren)
4. fralex says:
  
  5. November 2012 at 23:15
  
  Ja, das habe ich auch schon mehrmals durchgeführt.
5. Dominik Schilling says:
  
  5. November 2012 at 23:22
  
  Dann bin ich leider auch ratlos. Du könntest aber mal den Support ansprechen, die hätten da bestimmt mehr Ideen bzw können direkt schauen was los ist.
  
  Sorry, dass es nicht klappt.
snod says:

2. November 2012 at 20:39

Hi,

ich habe gitlab nach der Anleitung installiert. Die Webseite funktioniert auch, ich kann ebenfalls Repositories anlegen.

Leider kann ich aber nicht darauf zugreifen und das debuggen wo genau das Problem auftritt gestaltet sich eher schwierig.

Folgende Fehlermeldung kommt wenn ich versuche in das Repo zu pushen:

fatal: ‘foo.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.

Ich vermute dass hier irgendwas mit SSH schiefläuft. Ist es ein Problem wenn man den gleichen SSH Public-Key für Repo und SSH-Shell benutzt?

Gruß
snod

Reply
1. snod says:
  
  3. November 2012 at 13:55
  
  Problem gelöst:
  
  Es lag wirklich daran, dass ich den gleichen SSH-Key für Login und gitlab verwenden wollte. Ich habe dann einen neuen erstellt, in der ssh config für den host (ich verwende hier eine eigene Domain) den Key für den Host eingetragen und zusätlich noch IdentitiesOnly yes gesetzt da ich den ssh-key agent benutze und diese immer den Standardkey zuerst gesendet hat.
  
  Vielen Dank für das coole Tutorial :)
Simon says:

5. November 2012 at 22:21

Hi,

ich versuche mich auch gerade mal an deiner Anleitung, und habe eine Frage, und ein Problem. Zunächst zur Frage:
Würde es sich lohnen, die Dienste, die eh immer irgendwie laufen müssen, noch in die daemontools mit einzubinden? D.h. Redis und Gitlab selbst? Das –daemonize überdauert ja vermutlich keinen Reboot, wenn Jonas und seine Jungs meinen Host mal irgendwie warten müssen.

Und nun das Problem:
Wie zu erwarten, bekomme ich bei laufendem thin zum testen, und der .htaccess einen Error 500. Ich habe die .htaccess allerdings in einer “Subdomain” liegen, dass ich gitlab später über git.simonszu.de aufrufen kann. Die gitlab config ist angepasst, aber ich weiß aus eigener Erfahrung, dass die RewriteRules der Userprojekte sich mit den RewriteRules für die Subdomains beißen können. Anyway, der Grund für den 500 ist laut error.log ein:
“/var/www/virtual/simonszu/git.simonszu.de/.htaccess: RewriteCond: bad flag delimiters”

Hast du da eine Idee?

Reply
1. Dominik Schilling says:
  
  5. November 2012 at 23:06
  
  Hi,
  
  da scheint wohl ein Fehler in deiner Rewrite Condition zu sein. Was hast du denn da noch ergänzt? Hinweis zu den Rewrite Rules aus dem Wiki.
2. Simon says:
  
  6. November 2012 at 13:07
  
  Ich habe lediglich in der gitlab config bei den Hostnamen nicht mehr uberspacename.host.uberspace.de stehen, sondern halt git.simonszu.de.
  Eine ebenjene Subdomain habe ich auch angelegt, und da die .htaccess wie von dir vorgeschlagen, eingebaut.
  Nun wird es interessant: Wenn ich da noch “RewriteBase /” stehen habe, bekomme ich zwar auch noch einen Error 500, aber keinen entsprechenden Logeintrag in meinem error.log. Lasse ich die Zeile weg, bekomme ich sowohl den Error 500, als auch einen Logeintrag. Gitlab scheint aber zu laufen.
  
  Des Rätsels lösung: Am Ende der RewriteCond hast du (P) in runden Klammern geschrieben. Wenn ich es in eckige Klammern setze, geht es.
3. Dominik Schilling says:
  
  6. November 2012 at 17:16
  
  In der besagten Zeile stand eigentlich immer das “P” in eckigen Klammer, nur “.*” ist in runden Klammern. Aber schön, dass es nun klappt. :)
fralex says:

7. November 2012 at 23:53

Hallo,

ich habe eine Frage. Ich möchte post-receive hook erweitern. Wie mache ich es richtig?
Ich möchte folgenden Befehl ausführen:
cd ~/var/redmine/git_repositories/test && git pull origin maste
Im repos ist ein Systemlink auf die angepasst Datei (siehe oben). Kann ich die Datei anpassen?
Ich habe folgendes Versucht: Systemlink gelöscht und die post-receive Datei angelegt mit meinem Befehl. Im repo eine Datei verändert und an das zentrale repo versendet. Leider wurde der hook nicht ausgeführt.
Habt ihr Tipps für mich.

Danke

Gruß
fralex

Reply
Simon says:

8. November 2012 at 21:52

Ich merke gerade: Es gibt da ein schwereres Problem im Gesamtkonzept.

Ich nutze auf meinem Desktop einen SSH-Key für den normalen Shell-Access auf meinem Uberspace. Wenn ich diesen Key auch für Gitlab nutzen möchte, klappt das nicht.

Entweder der Key ist über “gl-tool shell-add key.pub” wie im US-gitolite-Tutorial so zu meiner authorized_keys hinzugefügt, dass ich ihn für normalen SSH logon nutzen kann. Wenn ich ihn dann über das Webfrontend von gitlab zu meinem Gitlabaccount hinzufüge, und dann mit dem Key auf ein Repo zugreifen will, meldet sich mein Uberspace mit /bin/login zurück, und git ist verwirrt.

Wenn ich ihn dann aus der authorized_keys rausnehme, und nur noch über gitolite eingebunden habe, kommt git zwar klar, aber ich bekomme verständlicherweise kein SSH mehr.

Wie mach ich das dann am besten? Hast du ne Idee?

Reply
1. Dominik Schilling says:
  
  9. November 2012 at 18:45
  
  Hast du schon die Schritte aus dem Doku-Wiki probiert?
2. SonicHedgehog says:
  
  10. November 2012 at 00:20
  
  Hatte damit auch einige Probleme, die (eigentlich recht simple) Lösung fand ich dann bei der alten Anleitung auf julo.ch [0]:
  
  > 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.
  
  [0]: http://blog.julo.ch/post/40340697227/gitlab-auf-deinem-uberspace-installieren
SonicHedgehog says:

10. November 2012 at 00:27

Auch wenn es bei mir (nach mehreren Anläufen) geklappt hat: Sollte der Parameter „–path“ bei „$ gem install bundler charlock_holmes –path ~/.gem“ funktionieren?

Den kannte er bei mir nämlich nicht und deshalb habe ich dann eine „~/.gemrc“ wie im Uberspace-Wiki beschrieben [0] angelegt. In der RubyGems-Dokumentation [1] finde ich auch keinen Hinweis darauf.

Vielleicht hilft’s ja jemanden anderen.

[0]: https://uberspace.de/dokuwiki/development:ruby#eigene_gems_installieren
[1]: http://docs.rubygems.org/read/chapter/10#page33

Reply
1. c3p says:
  
  28. March 2013 at 16:48
  
  Das sollte oben defintiv mal korrigiert werden, ich hab den PATH einfach mal weggelassen, bin mir aber nicht sicher ob jetzt der rest funktioniert…
Thomas Flad says:

16. November 2012 at 22:09

Hi,

danke für das tolle Tutorial! Eine Sache funktioniert noch nicht ganz. Wenn ich ein Projekt erstelle bekomme ich die url nach dem muster “xxx@xxx.libra.uberspace.de:projekt.git” serviert.

Wenn ich das genau so versuche zu klonen bekomme ich “… does not appear to be a git repository”. Erst wenn ich noch den Pfad repositories hinzufüge funktioniert es: “xxx@xxx.libra.uberspace.de:repositories/projekt.git”

Wo liegt der Hund begraben? Oder muss ich den Pfad immer ergänzen?

Reply
Nickel715 says:

22. November 2012 at 15:33

Hallo,
super anleitung hat eigtl alles soweit geklappt, nur habe ich das selbe problem wie Thomas das er das git repo nicht findet. Ändere ich jedoch die url auf user@user.server.uberspace.de:repositories/myrepo.git findet er es zwar aber pushen kann ich immernoch nicht, es wird zwar übertragen dannach allerdings kommt dieser fehler:
emote: ENV GL_RC not set
remote: BEGIN failed–compilation aborted at hooks/update line 20.
remote: error: hook declined to update refs/heads/master
To user@user.server.uberspace.de:repositories/myrepo.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to ‘user@user.server.uberspace.de:repositories/myrepo.git’
vlt kannst du mir/uns weiterhelfen wäre super

Reply
1. Dominik Schilling says:
  
  22. November 2012 at 19:09
  
  Habt ihr irgendwo einen Unterordner verwendet?
2. Nickel715 says:
  
  22. November 2012 at 21:03
  
  hmm nein, ich habe gitlab in mein home installiert und die htaccesse wie beschrieben im html ordner abglegt und die repos liegen in /home/user/repositories/.
  Allerdings befindet sich bereits der pk von meiner lokalen Maschine mit der ich den obigen fehler habe bereits in der authorized_keys Datei, vlt hat das was damit zu tun?
3. Nickel715 says:
  
  22. November 2012 at 21:49
  
  ich hab nun mal mein pk aus der authorized_keys Datei gelöscht und schon ging es, nur geht nun kann ich ssh nicht mehr anderweitig nutzen, was auch doof ist. Auch ein eintrag in der .ssh/config hilft komischerweise nicht :(
Nicolas says:

22. November 2012 at 23:01

ok nach dem ich jetzt fast verzweifelt war hab ichs nun endlich geschafft, ich musste einfach nur in die .ssh/config mit folgendem inhalt erstellen:
Host example.tld
HostName example.tld
User username
IdentityFile ~/.ssh/id_rsa.gitlab
IdentitiesOnly yes
wichtig ist das das example.tld in der ersten zeile das gleich ist wie das in der zweiten sonst gehts net, das war mein fehler m(

Reply
1. Michael says:
  
  2. January 2013 at 13:30
  
  Danke Nicolas! Das Problem hatte ich auch!
  Hat super geklappt mit der config und dem separaten key für einen bestimmten Host.
  Ich hab dabei einfach eine gitlab-subdomain angelegt für die der entsprechende key mitgeschickt werden soll. Die nehm ich jetzt als remote origin für meine repositories.
Michael says:

9. December 2012 at 09:09

Vielen Dank, super Anleitung, funktioniert auch wenn man keinerlei Ruby und nur rudimentäre Linux-Kenntnisse hat :)

Bin mir nicht sich, aber glaube, dass in Punkt 5, Möglichkeit 1 der Parameter –path durch –install-dir getauscht werden muss. Mit –path hat es bei mir nicht funktioniert, aber mit

$ gem install bundler charlock_holmes –install-dir ~/.gem

(http://docs.rubygems.org/read/chapter/10#page33)

Reply
zeidlos says:

11. December 2012 at 04:00

Wer Gitlab in einem Unterverzeichnis haben möchte, muss

“config.action_controller.relative_url_root = “/foo-app”” in seine ~/gitlab/config/environments/production.rb schreiben.

Reply
1. Thomas131 says:
  
  21. February 2013 at 20:31
  
  Hallo,
  Bei mir funkteniert das leider nicht. Hast du sonst noch irgendetwas gemacht? Neu gestartet?
  
  m.f.G.:Thomas131
ludowique says:

30. December 2012 at 09:09

moinmoin,
versuch mich gerade an der Anleitung und habe soweit ich das sehen kann bisher alles erfolgreich hinbekommen, scheitere aber am Statuscheck in Schritt 10:

[schustel@cygnus gitlab]$ bundle exec rake gitlab:app:status RAILS_ENV=production
rake aborted!
Don’t know how to build task ‘gitlab:app:status’
(See full trace by running task with –trace)
[schustel@cygnus gitlab]$ bundle exec rake –trace gitlab:app:status RAILS_ENV=production
rake aborted!
Unrecognized –trace option ‘gitlab:app:status’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:506:in `select_trace_output’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:464:in `block in standard_rake_options’
/package/host/localhost/ruby-1.9.3-p125/lib/ruby/1.9.1/optparse.rb:1360:in `call’
/package/host/localhost/ruby-1.9.3-p125/lib/ruby/1.9.1/optparse.rb:1360:in `block in parse_in_order’
/package/host/localhost/ruby-1.9.3-p125/lib/ruby/1.9.1/optparse.rb:1347:in `catch’
/package/host/localhost/ruby-1.9.3-p125/lib/ruby/1.9.1/optparse.rb:1347:in `parse_in_order’
/package/host/localhost/ruby-1.9.3-p125/lib/ruby/1.9.1/optparse.rb:1341:in `order!’
/package/host/localhost/ruby-1.9.3-p125/lib/ruby/1.9.1/optparse.rb:1432:in `permute!’
/package/host/localhost/ruby-1.9.3-p125/lib/ruby/1.9.1/optparse.rb:1453:in `parse!’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:516:in `handle_options’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:79:in `block in init’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:158:in `standard_exception_handling’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:77:in `init’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:69:in `block in run’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:158:in `standard_exception_handling’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:68:in `run’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/bin/rake:37:in `’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/bin/rake:19:in `load’
/home/schustel/gitlab/vendor/bundle/ruby/1.9.1/bin/rake:19:in `’
[schustel@cygnus gitlab]$

ich weiß leider nicht, wo ich ansetzen soll um das Problem zu lösen.

Reply
1. ludowique says:
  
  30. December 2012 at 09:12
  
  sorry, die trace option war falsch: der Trace output sieht so aus:
  
  [schustel@cygnus gitlab]$ bundle exec rake gitlab:app:status RAILS_ENV=production –trace
  rake aborted!
  Don’t know how to build task ‘gitlab:app:status’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/task_manager.rb:49:in `[]’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:140:in `invoke_task’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:99:in `block (2 levels) in top_level’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:99:in `each’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:99:in `block in top_level’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:108:in `run_with_threads’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:93:in `top_level’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:71:in `block in run’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:158:in `standard_exception_handling’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/lib/rake/application.rb:68:in `run’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/gems/rake-10.0.1/bin/rake:37:in `’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/bin/rake:19:in `load’
  /home/schustel/gitlab/vendor/bundle/ruby/1.9.1/bin/rake:19:in `’
  [schustel@cygnus gitlab]$
2. Dominik Schilling says:
  
  31. December 2012 at 08:51
  
  Hi,
  da bin ich etwas überfragt. So wie die Anleitung geschrieben wurde, hast du dir auch bestimmt die 4.0 schon gezogen, da diese im Moment stabil ist. Diese läuft allerdings nicht auf Uberspace ohne Weiteres.
  
  Wenn du dich mit Git auskennst, dann check mal https://github.com/gitlabhq/gitlabhq/tree/v3.0.3 aus.
Ben says:

30. January 2013 at 18:44

Vielen Dank für diese hervorragende Anleitung, Dominik.

Nach einigen Fallen mit den SSH-Keys läuft nun auch alles bei mir.

Aber einen Fehler habe ich dennoch bei mir festgestellt. Wenn ich ein File in Gitlab bearbeitet und Commiten möchte, bekomme ich einen 500er.
Ist dies bei euch auch so oder nur bei mir?

Reply
Thomas131 says:

21. February 2013 at 18:45

Hallo,
Ich habe versucht alles Ordnungsgemäß zu installieren, komme allerdings zu folgenden Fehler:
nice -n 19 gem install bundler charlock_holmes –path ~/.gem
ERROR: While executing gem … (OptionParser::InvalidOption)
invalid option: –path
m.f.G.:Thomas131

Reply
1. Thomas131 says:
  
  21. February 2013 at 18:51
  
  Hat sich erledigt. Siehe #comment-7206.
Thomas131 says:

21. February 2013 at 20:33

Hallo,
Wie stoppt man GitLab?

m.f.G.:Thomas13

Reply
1. Ben says:
  
  26. February 2013 at 10:45
  
  Hi Thomas,
  wenn du Gitlab mit dem Befehl ‘bundle exec thin start –environment production –port ‘ gestartet hast, kannst du es mittels CTRL+C stoppen.
Schany says:

5. March 2013 at 13:33

Super Anleitung aber ich komm bei Schritt 7 nicht weiter.
Kann mir da vlt. jemand helfen? Ich bin Linux Newbie und weis einfach nicht was ich falsch mache.

Fehler:
[rh@cepheus ~]$ git clone git@github.com:gitlabhq/gitlabhq.git gitlab
Cloning into ‘gitlab’…
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Wäre echt Super wenn mir jemand helfen könnte.

Danke.

VG Schany

Reply
sascha says:

21. March 2013 at 15:53

danke für die ausführliche anleitung.

ich muss mich schany in vollem umfang anschliessen.

lg
sascha

Reply
MIchael Fritz says:

26. March 2013 at 18:28

Danke für die lange Beschreibung. Ich saß den halben Tag davor. Jetzt stehe ich kurz vor Ende und es kommt ein Fehler. Jemand eine Idee?

bundle exec rake db:setup RAILS_ENV=production --trace
** Invoke db:setup (first_time) ** Invoke db:schema:load_if_ruby (first_time) ** Invoke db:create (first_time) ** Invoke db:load_config (first_time) ** Execute db:load_config rake aborted! (): couldn't parse YAML at line 1 column 0

Reply
1. MIchael Fritz says:
  
  26. March 2013 at 18:34
  
  Habs gefunden, die zeilen müssen in die ./config/boot.rb
  
  require ‘yaml’
  YAML::ENGINE.yamler = ‘syck’
Benjamin says:

26. March 2013 at 22:23

Hallo Dominik,

die Anleitung ist soweit super, hab auch letztlich alles hinbekommen. Dabei bin ich aber darüber gestolpert, dass du hier eine ältere Version von Gitlab verwendest, und das genannte Repository für die Gitlab-Installation wohl nicht mehr funktioniert.
Könntest du das Tutorial bei Gelegenheit mal auf die neue Gitlab Version 5.0 updaten?
Dann bräuchte man wohl auch kein gitolite mehr.

Reply
1. Dominik Schilling says:
  
  27. March 2013 at 10:03
  
  Hi Benjamin,
  
  für GitLab 4.1 kann ich dir diese Anleitung empfehlen: http://blog.kanedo.net/1306,gitlab-4-1-auf-einem-uberspace-installieren.html
  
  GitLab 5.0 ist im Moment noch mit Problemen behaftet, was unter anderem an dem nicht mehr benötigten gitolite liegt.
MIchael Fritz says:

27. March 2013 at 08:31

Noch eine Frage, ich habe alles prima installiert, und es lief auch. nur kommt jetzt ein 503 Service Unavailable auf meinem Port.

Ich starte dann das Ding einfach nochmal und es läuft, aber das kanns ja nicht sein, oder?

cd ~/gitlab && rvm use 1.9.3 && bundle exec thin start –environment production –port 55555

Reply
1. Dominik Schilling says:
  
  27. March 2013 at 10:05
  
  Den 503 Fehler habe ich auch manchmal, vllt. einmal in zwei Monaten. Meine Vermutung liegt darin, dass der Port dann woanders genutzt wurde. Probier es mal mit einem zufälligeren, 5 mal die 5 ist nicht grad sehr einfallsreich. ;)
Nicolas says:

27. March 2013 at 14:03

ich habe mein gitlab jetzt seit einiger zeit am laufen, im großen und ganzen läuft es auch. Allerings wenn ich in unter files dann eine datei auswähle um den inhalt anzusehen wird die datei nicht angezeigt, an der stell wo die datei erscheinen soll erscheint einfach nur weis, es gibt keine fehler und die navigation wird auch geladen… kann mir vlt jemand weiterhelfen?

Reply
1. Nicolas says:
  
  5. April 2013 at 11:13
  
  ich habe inzwischen eine lösung gefunden, es ist ein bekanntes problem das es bei gitlab probleme mit der python version gibt es funktionieren nur bestimmte versionen u.a. die version 2.7 da auf uberspace zum teil 2.4 drauf ist ist das die fehler ursache.
  Die lösung ist aber ganz einfach, man muss im gitlab verzeichnis in /vendor/bundle/ruby/1.9.1/gems/pygments.rb-0.3.1/lib/pygments/mentos.py muss die erste zeil wie folgt ändern:
  #!/usr/local/bin/python2.7
Benjamin says:

11. April 2013 at 17:24

Moin moin,

erstmal: super Anleitung. Nachdem ich gitphp und und gitweb ausprobiert hatte und von eher kurzen Anleitungen verwöhnt war, musste ich hier schon etwas schlucken, nachdem ich nach 10min gefühlt bei Schritt 3/15 war. Dafür hat aber alles wie beschrieben funktioniert und es war bequemes Copy & Pasten. Vielen Dank dafür! :)

Eine Frage habe ich aber noch: Wie richte ich denn gitlab so ein, dass es unter einem Unterordner erreichbar ist?

Mein gitlab ist unter ..uberspace.de/gitlab erreichbar. Zeigt jedoch keine Styles an.
In dem sonst leeren Ordner liegt die .htaccess, aber egal wie ich sie anpasse, ich bekomme keine funktionierende Ausgabe.

In der gitlab.yml habe ich auch schon web: host und git_host: host angepasst, jedoch ohne eine Änderung zu bemerken. Ich hatte auch schon den Schritt mit dem Daemon gemacht, wie restarte ich das denn bei Uberspace? Ich habe Gitlab nach Config-Änderungen zum Test immer wie in Schritt 12 beschrieben gestartet (und mit Strg + C gestoppt).

Reply
1. Dominik Schilling says:
  
  11. April 2013 at 17:27
  
  Bezg. Unterordner schau mal hier vorbei: https://julo.ch/blog/gitlab-uberspace
  
  Unter „Gitlab im Unterordner“ werden die nötigen Änderungen beschrieben.
2. Benjamin says:
  
  11. April 2013 at 18:39
  
  Perfekt, läuft, vielen Dank! :)
Flo says:

10. May 2013 at 13:33

Ich bekomme bei
$ bundle install –path ~/.gem
Nur diesen Fehler hier:
Bundler::GemfileNotFound

…help?

Reply
1. Chris says:
  
  28. May 2013 at 12:39
  
  Ich habe den selben Fehler wie Flo und würde mich über Hilfe freuen.
  
  Gruß
  Chris
2. Angel says:
  
  16. January 2014 at 09:27
  
  Ich habe den selben Fehler leider auch, habe sogar die Schritte im Wiki von Uberspace noch nach geschaut.
  Greetz.
3. Stefan says:
  
  27. January 2014 at 22:13
  
  Das selbe hier :(

Leave a Reply Cancel reply

%d bloggers like this: