新しいクリーンなサーバーでgitlab(6.5.1)をセットアップしようとしています。すべてが機能しているように見えますが、gitはどのプロジェクトにもプッシュできません。新しく作成されたプロジェクトページのコマンドに従い、sshを介してリモートにプッシュすると、次のようになります。
$ git Push -u Origin master
fatal: Could not read from remote repository.
Please make sure you have the correct access
rights and the repository exists.
これはかなり一般的な問題のようです。残念ながら、これにはいくつかの潜在的な原因があり、それらのどれも一致しないようです。 issue 3424 から、古いリリースと他のさまざまなソースをオンラインで見て、次の提案を確認しました。
残りのSSHキー
これは、残り物がないクリーンなセットアップです。私のキーは認証済みキーファイルに適切に追加され、リストされているのはこのキーだけです。
デバッグロギングでsshを実行すると、Ruby環境変数に関連するエラーが表示されます。
鉱山がきれいになりました。 SSHデバッグ 表示 正常な接続。認証ハンドシェイクに関するすべてが正常であり、これが出力の終わりです。
debug1: Sending command: git-receive-pack 'username/reponame.git'
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Gitlab-Shell環境の問題。
上記と同じエラーメッセージが表示される他の多くのアプリケーションとは異なり、私のgitlab-Shellチェックスクリプトは正常な医療費を返します。
% Sudo -u gitlab -H ~gitlab/gitlab-Shell/bin/check
Check GitLab API access: OK
Check directories and files:
/var/lib/gitlab/repositories: OK
/var/lib/gitlab/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.8.5
Send ping to redis server: PONG
{Unicorn、sidekiq、redis}を再起動します
1つ以上のサービスを再起動するとこれが解消されるというレポートは、ここでは適用されないようです。これは、デーモンの修正を先導する断続的な問題ではありません。
リポジトリが物理的に作成されていない
しかしそうです。毎回初めて、~gitlab/repositories/username/reponame.git
の裸のgitリポジトリが毎回作成され、正しい権限を持っているようです。
Gitlab-ShellはAPIサーバーと通信できません。これは、A)DNSの問題、B)間違ったip/port/interfaceバインディングC)末尾にスラッシュがない/ないためです。
チェックスクリプトは、APIアクセスに問題がないことを示しています。
私はnginxを実行していないので、それに関連するデフォルトのIPバインディングの問題はn/aです。
*:8080
のリッスン値として127.0.0.1:8080
とUnicorn.yml
の両方を試しました。
それ以上に、localhostのさまざまな反復、127.0.0.1、および完全修飾ドメイン名(DNSは問題解決)を試しましたが、Shell.yml
の末尾にスラッシュを付けた場合と付けない場合で、失敗しました。また、ポート80のApache SSL /プロキシホストではなく、ポート8080のユニコーンサーバーに直接接続してみました。何も変わらないようです。私の証明書は自己署名されておらずブラウザーで正常に動作していますが、とにかくself_signed_cert: true
を設定してみました。何もない。
報告されたgitパスが間違っています。gitlabユーザーホームからの完全修飾パスを追加してください。
これは、gitlab-Shellがこれを修正するためのサルビジネスをまだ行っていない場合の合法的な提案のようですが、git remote add Origin gitlab@server:username/reponame.git
を `` git remote add Origin gitlab @ server:repositories/username/reponame.gitに変更してみました`役に立たない。同じエラー。
これは提案された解決策の無味無さのようですが、どれも正しくないようです。注:httpを介してプッシュできる。ログインプロンプトはLDAPユーザー名とパスワードを受け入れ、プッシュを受け入れます。これは、SSHを使用しようとしたときの問題です。 ssh -T gitlab@server
を使用したsshログイン部分のみのテストは正常に機能します。
このエラーの原因は他にありますか?
gitlabでこのような問題をデバッグするにはどうすればよいですか?~gitlab/gitlab-Shell/gitlab-Shell.log
には何も関連がないようです。より有益なエラーメッセージはどこにありますか?
このSSHデバッグメッセージが原因で、SSHとシステムの間の構成に問題があると確信しています。
client_input_channel_req: channel 0 rtype [email protected] reply 0
認証が成功した直後にこのメッセージが表示され、bashからのメッセージは表示されません。これは、ログイン後にプログラムが起動されなかったことを意味します。
Gitlabユーザーに適切な設定がある場合は、passwdファイルを確認します。
gitlab:x:1011:1012:GitLab,,,:/path/to/gitlab:/bin/bash
Bashが以下のような設定ファイルに奇妙なことをしていないことを確認してください
次に、上位レベルに移動します。Gitlab-Shell / path/to/gitlab/.ssh/authorized_keysが以下の構成であることを確認します。
command="/path/to/gitlab/gitlab-Shell/bin/gitlab-Shell key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa A...
/ path/to/gitlab/gitlab-Shell/bin/gitlab-Shellはgitlabユーザーが所有し、実行可能です。
次のコマンドを実行して、gitlab-Shellが完全に機能していることを確認できます。
# /path/to/gitlab-Shell/bin/gitlab-Shell
Welcome to GitLab, Anonymous!
リモートログインが実際に機能し、gitlab-Shellに適切に接続されている場合、リモートでログインしようとすると、ダンプする前に同じウェルカムメッセージ(ただし、ログインに使用したsshキーを持つユーザーに一致)が表示されます。
$ ssh gitlab@server
Welcome to GitLab, <your user's full name>!
Connection to <server> closed.
ここのメッセージはおそらくsshがあなたをgitlabに接続していないことを示しているでしょう。
最後に、gitlab-Shell構成(config.yml)をチェックアウトして、次のことを確認します。
http_settings:
# trailing slash is important
gitlab_url: "https://remote_server/"
ca_file: /path/to/webserver/certificate.crt
そして最終的に:
self_signed_cert: false
私も同じ問題を抱えていて、何日かグーグルしてスタックオーバーフローを検索した結果、ようやく自分の問題が見つかりました。他の誰かが同じ問題を抱えている場合に備えて、これを書面でGitlabに接続したかったのです。
私はここに私の解決策を見つけました: https://stackoverflow.com/questions/17307154/git-bash-Push-to-bitbucket-ignores-ssh-key
私はWindowsを使用していますが、Git BashがSSHキーの場所をPuTTYと共にインストールされるplink.exeから取得しようとしていたことが問題でした。
解決策は、環境変数GIT_SSHを削除することでした。その後、すべてが機能しました。
これが誰かを助けることを願っています。