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.

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
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
Hi Hendrik,
hab dir eine Mail geschickt.
Wegen
bundle exec
, versuch malbundle 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.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?
Hi,
meinst du einen neuen User oder dein Admin-Account? Was sagt denn der Status Check?
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.
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?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.
Befindet sich die Datei denn in
~/.gitolite/keydir
bzw.~/.gitolite/conf/gitolite.conf
?Hast du Gitolite mal deistalliert und es nochmal probiert?
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!
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
Ich nehme mal an, dass er da versucht das gitolite-admin zu klonen. Hat das auch bei Schritt 4 nicht funktioniert?
Ja, Schritt 4 hat funktioniert, aber die Meldung kriege ich immer noch.
Hast du die Installation nochmal probiert? (Gitolite deistallieren)
Ja, das habe ich auch schon mehrmals durchgeführt.
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.
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
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 :)
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?
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.
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.
In der besagten Zeile stand eigentlich immer das “P” in eckigen Klammer, nur “.*” ist in runden Klammern. Aber schön, dass es nun klappt. :)
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
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?
Hast du schon die Schritte aus dem Doku-Wiki probiert?
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
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
Das sollte oben defintiv mal korrigiert werden, ich hab den PATH einfach mal weggelassen, bin mir aber nicht sicher ob jetzt der rest funktioniert…
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?
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
Habt ihr irgendwo einen Unterordner verwendet?
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?
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 :(
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(
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.
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)
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.
Hallo,
Bei mir funkteniert das leider nicht. Hast du sonst noch irgendetwas gemacht? Neu gestartet?
m.f.G.:Thomas131
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.
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]$
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.
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?
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
Hat sich erledigt. Siehe #comment-7206.
Hallo,
Wie stoppt man GitLab?
m.f.G.:Thomas13
Hi Thomas,
wenn du Gitlab mit dem Befehl ‘bundle exec thin start –environment production –port ‘ gestartet hast, kannst du es mittels CTRL+C stoppen.
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
danke für die ausführliche anleitung.
ich muss mich schany in vollem umfang anschliessen.
lg
sascha
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
Habs gefunden, die zeilen müssen in die ./config/boot.rb
require ‘yaml’
YAML::ENGINE.yamler = ‘syck’
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.
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.
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
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. ;)
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?
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
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).
Bezg. Unterordner schau mal hier vorbei: https://julo.ch/blog/gitlab-uberspace
Unter „Gitlab im Unterordner“ werden die nötigen Änderungen beschrieben.
Perfekt, läuft, vielen Dank! :)
Ich bekomme bei
$ bundle install –path ~/.gem
Nur diesen Fehler hier:
Bundler::GemfileNotFound
…help?
Ich habe den selben Fehler wie Flo und würde mich über Hilfe freuen.
Gruß
Chris
Ich habe den selben Fehler leider auch, habe sogar die Schritte im Wiki von Uberspace noch nach geschaut.
Greetz.
Das selbe hier :(