doppelte überprüfung GitLab-installation : gitlab-shell-self-check fehlgeschlagen

Ich GitLab installiert und alles scheint in Ordnung. Bis ich double check Anwendung status durch ausführen von: sudo -u git -H editor /home/git/gitlab-shell/config.yml. Dieser Artikel ist in rot und scheint ein Fehler:

  gitlab-shell self-check failed
  Try fixing it:
  Make sure GitLab is running;
  Check the gitlab-shell configuration file:
  sudo -u git -H editor /home/git/gitlab-shell/config.yml
  Please fix the error above and rerun the checks.

Ich versuche Eröffnung config.yml aber ich weiß nicht scheinen, um herauszufinden, jede ungewöhnliches. Sie denken, was bin ich?

Außerdem habe ich eine benutzerdefinierte SSH-Verbindung. Was ich nicht verstehe, aus dieser Erklärung:

Custom SSH Connection

If you are running SSH on a non-standard port, you must change the gitlab user's SSH config.

# Add to /home/git/.ssh/config
host localhost          # Give your setup a name (here: override localhost)
    user git            # Your remote git user
    port 2222           # Your port number
    hostname 127.0.0.1; # Your server name or IP
You also need to change the corresponding options (e.g. ssh_user, ssh_host, admin_uri) in the config\gitlab.yml file.

Aus verloren, ich habe nicht diese /home/git/.ssh/config, sollte ich Sie erstellen oder ich bin einfach etwas fehlt?

Mein call stack:

Checking Environment ...

Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version >= 1.7.4 ? ... OK (1.7.6)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
update hook up-to-date? ... yes
update hooks in repos are links: ... can't check, you have no projects
Running /home/git/gitlab-shell/bin/check
Check GitLab API access: /usr/local/lib/ruby/2.0.0/net/http.rb:878:in `initialize': getaddrinfo: Name or service not known (SocketError)
        from /usr/local/lib/ruby/2.0.0/net/http.rb:878:in `open'
        from /usr/local/lib/ruby/2.0.0/net/http.rb:878:in `block in connect'
        from /usr/local/lib/ruby/2.0.0/timeout.rb:52:in `timeout'
        from /usr/local/lib/ruby/2.0.0/net/http.rb:877:in `connect'
        from /usr/local/lib/ruby/2.0.0/net/http.rb:862:in `do_start'
        from /usr/local/lib/ruby/2.0.0/net/http.rb:851:in `start'
        from /home/git/gitlab-shell/lib/gitlab_net.rb:62:in `get'
        from /home/git/gitlab-shell/lib/gitlab_net.rb:29:in `check'
        from /home/git/gitlab-shell/bin/check:11:in `<main>'
gitlab-shell self-check failed
  Try fixing it:
  Make sure GitLab is running;
  Check the gitlab-shell configuration file:
  sudo -u git -H editor /home/git/gitlab-shell/config.yml
  Please fix the error above and rerun the checks.

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
projects have namespace: ... can't check, you have no projects
Projects have satellites? ... can't check, you have no projects
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/local/bin/git"
Git version >= 1.7.10 ? ... yes (1.8.4)

Checking GitLab ... Finished

Sie sind auf der öffnung der Datei mit dem folgenden Befehl aufgelistet werden? Es ist möglich, dass die git-Benutzer kann die Datei nicht öffnen, da die Datei-Berechtigungen falsch sein können.
Ja, das Tue ich. Ich wusste nur zu beobachten, was auf die Produktion readme
Sie können kopieren Sie den call-stack, die führt zu der Fehlermeldung?
Pardon, aber wie kann ich Ihnen das?
Dann zurück in die /etc/hosts (der gitlab-server, wie bereits in github.com/gitlabhq/gitlab-shell/issues/...). Ich bearbeitet meine Antwort.

InformationsquelleAutor Leandro Garcia | 2013-11-08

git gitlab

10

Könnte es ähnlich sein, die Problem 5437:
Lief ich in der exakt gleichen problem zu tun, eine saubere Installation auf meinem debian wheezy 7.2 server.

Ich zwei änderungen vorgenommen und den server neu gestartet (kein problem, da es nur ein testserver):
- stellen Sie sicher, dass Ihre Domäne Punkte an 127.0.0.1 im /etc/hosts (auf meinem server es wies auf 127.0.1.1)
- hinzufügen /home/git/.ssh/config für den non-standard ssh-port wie bereits in der installation
In diesem Fall, die Einstellung der domain auf 127.0.0.1 im /etc/hosts genug war.

Andere Frage, möglich: Problem 5426: falsch sidekick Befehl

Diese Weise zu starten sidekiq nicht mehr funktioniert. Sie haben zu verwenden:
```
sudo -u git -H RAILS_ENV=production script/background_jobs start
```
Einer http.rb:xxx:ininitialize -': getaddrinfo: Name oder Dienst nicht bekannt (SocketError)` Fehlermeldung ist zu sehen in:
- Problem 5151 => gelöst von dieser Kommentar:
```
sudo -u git -H vim /home/git/gitlab-shell/config.yml
# and change:
gitlab_url: http://yourhost to gitlab_url: http://yourhost/
# Slash at the end is important.
```
- Ausgabe 42 von gitlab-shell: noch einmal: die /etc/hosts ist wichtig, um richtig zu machen.
Den OP Leandro Garcia bestätigt in den Kommentaren:

Ich vergaß, um den setup-domain, die ich auf gitlab_url.

Hinzufügen, dass die Korrektur der DNS auf meinem domain-Anbieter löst das Problem

Leider beide nicht das Problem behoben. Dabei sudo -u git -H RAILS_ENV=production script/background_jobs start nichts ausgibt.
Auf meinem /etc/hosts/ ich habe diese 127.0.0.1 localhost leandro sollte entweder "localhost" oder " leandro ist die URL, die ich angeben muss im GitLab config?
localhost sollte funktionieren. Oder versuchen 127.0.0.1
Ich habe vergessen, um den setup-domain, die ich auf gitlab_url. Hinzufügen, dass die Korrektur der DNS auf meinem domain-Anbieter löst das Problem. Man füge dies in deine Antwort. Danke!
Super!!! Ich habe bearbeitet Sie meine Antwort auf Ihre Schlussfolgerung, für mehr Sichtbarkeit.

InformationsquelleAutor VonC
0

Etwas ähnliches für mich, ich hatte meine Omnibus-Gitlab-installation alle feinen arbeiten. Ich war in der Lage, die verschiedenen GIT-updates und schiebt und zieht.

Aber dann wechselte ich den host-und domain-Namen-Konfigurationen der server, und dann mein gitlab würde nicht korrekt reagiert, geben die gleiche Art von Fehler wie oben. Der tatsächliche hostname hatte sich nicht verändert, aber wie, die hostname wurde dargestellt wird, in /etc/hosts und in meinem LAN. Ich dachte, dass ich das tun könnte, die Seite ausführen, um Probleme wie diese, indem Sie nur die Einstellung, in meinem lokalen ~/.git/config Datei, den Speicherort der die gitlab-server seine IP-Adresse, aber das war nicht genug. Ich hatte, um sicherzustellen, dass Gitlab eigenen NGINX-config-Datei ist die Vertretung der lokale hostname wurde von der Maschine verstanden.

In einem standard-Omnibus-Gitlab-Bereitstellung, Ihre nginx-config-Datei ist hier zu finden: /var/opt/gitlab/nginx/etc/gitlab-http.conf,
und Sie sind daran interessiert, die server Teil:

server { listen *:80; server_name hostname.on.your.domain;

Einem quick-test: ist der hostname, wie er in Ihr gitlab-http.conf-Datei "pingbar" geführt?

ping hostname.on.your.domain

wenn nicht, dann Doppel-triple-überprüfen Sie Ihre /etc/hosts und Netzwerk-Konfigurationen.

InformationsquelleAutor Phil Ryan
0

Ich nur ein Upgrade zu 7.2.2 und lief in dieses Problem unter Ubuntu 14.04 LTS und habe nie zuvor sah Ruby-code.

Suche im gitlab-shell/lib/gitlab_config.rb in Zeile 54 ich finde, dass die definition von redis['bin'] leer ist und somit der test in der gitlab-shell/bin/check fehlschlägt.

Als quick hack, um es an die Arbeit, die ich geändert:

# Build redis command to write update event in gitlab queue def redis_command if redis.empty? # Default to old method of connecting to redis # for users that haven't updated their configuration %W(env -i redis-cli) else if redis.has_key?("socket") %W(#{redis['bin']} -s #{redis['socket']}) else %W(#{redis['bin']} -h #{redis['host']} -p #{redis['port']}) end end end
zu
# Build redis command to write update event in gitlab queue def redis_command # Default to old method of connecting to redis # for users that haven't updated their configuration %W(env -i redis-cli) end

InformationsquelleAutor Yermo Lamers
0

Hatte ähnliches problem.
Ich hatte die falsche Adresse in meinem gitlab-shell.
127.0.0.1:3000 falsch war, denn ich musste die gleiche Adresse wie ich via web (nginx-proxy), z.B. in gitlab.com.

InformationsquelleAutor Dariss

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.