gitlab6 配置的几个问题说明

gitlab6 配置的几个问题说明

按照gitlab的网站的详细步骤，终于把gitlab 6.1 stable安装到2台虚拟机上了。由于gitlab6运行于虚拟机上，所以配置这个虚拟机的hostname与提供最终对外服务的机器的hostname一致，可以减少很多不必要的麻烦，例如我的对外服务的host为www.cheungmine.org，则我的gitlab6的虚拟机的hostname也为www.cheungmine.org。本文中为：vm-gitlab。

https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md

但是随之而来的问题一堆一堆的。首先是我的架构是一台有固定IP的物理主机A作为唯一入口点，子网中的2台虚拟机B，C提供gitlab服务。B与C是通过A的网桥通过NAT外部联网，A与B中间用nginx联系，之间走https协议。A对外的服务也是nginx。参考：

http://blog.csdn.net/cheungmine/article/details/12340297

clients......https......A(nginx) <=https=> [ B(nginx) <-> C(mysqldb) ]

1）每次克隆代码都需要输入用户名和密码问题的解决

这样的结构就导致ssh协议不能用。也就是下面的语句失效：

$ git clone git@vm-gitlab:zhangliang/abc.git

因为对于用户电脑clients，只能看到主机A。但是下面的语句可用：

$ git clone https://vm-gitlab/zhangliang/abc.git

但是每次都提示输出用户名和密码。这个可以在用户的电脑(Ubuntu)上，修改~/.netrc：

machine code.google.com login cheungmine@gmail.com password wK6xZwgxfuZ2
machine vm-gitlab login zhangliang password a3B6TdfH

把红色部分更改为你的配置。

用户还需要把类似下面的条目加入到/etc/hosts中。这样方便每次访问：https://vm-gitlab。否则只能用IP地址访问。

192.168.1.8 vm-gitlab

2）qq邮箱不能收到gitlab发的邮件的问题解决

默认配置后， qq邮箱不能收到gitlab发的邮件，而gmail的可以。这个需要更改qq邮箱的设置。进入qq邮箱，按设置，反垃圾，设置邮件地址白名单，把gitlab@vm-gitlab.com加入到白名里。也可以把vm-gitlab.com加入到域名的白名单里。qq就不拦截邮件了。

3）设置https后，证书校验问题的解决

$ git clone https://vm-gitlab/zhangliang/abc.git

报错：

fatal: Unable to find remote helper for 'https'

原因是git没装好。按下面的步骤重装git，第1行尤其重要:

$ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev build-essential
$ wget https://git-core.googlecode.com/files/git-1.8.1.2.tar.gz
$ tar -zxf git-1.8.1.2.tar.gz
$ cd git-1.8.1.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install

$ git clone https://vm-gitlab/zhangliang/abc.git

报错，说证书校验有问题：
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
最简单的解决方法是调用前加一个环境变量：

$ export GIT_SSL_NO_VERIFY=1

$ git clone https://vm-gitlab/zhangliang/abc.git

但是这个方法肯定不方便，更好的方法是：

$ git config --global http.sslverify false

4）关于生成ssl证书的问题

既然我在A和B都设置成了https访问，所以需要在A和B上都生成ssl证书: ssl.key, ssl.crt。都放在/etc/nginx/sites-available下面(A和B都安装了nginx)。下面以 A 为例说明证书的生成过程。B的过程也是一样的。

Linux 通过openssl命令生成证书:

$ cd /etc/nginx/sites-available/

首先执行如下命令生成一个key

$ sudo openssl genrsa -des3 -out ssl.key 1024
然后他会要求你输入这个key文件的密码。不推荐输入。因为以后要给nginx使用。每次reload nginx配置时候都要你验证这个PAM密码的。

由于生成时候必须输入密码。你可以输入后1234, 再删掉。

$ sudo mv ssl.key xxx.key
$ sudo openssl rsa -in xxx.key -out ssl.key
输入1234
$ sudo rm xxx.key

然后根据这个key文件生成证书请求文件:

$ sudo openssl req -new -key ssl.key -out ssl.csr

以上命令生成时候要填很多东西 一个个看着写吧（可以随便，毕竟这是自己生成的证书）

最后根据这2个文件生成crt证书文件:

$ sudo openssl x509 -req -days 365 -in ssl.csr -signkey ssl.key -out ssl.crt
这里365是证书有效期。这个大家随意。最后使用到的文件是key和crt文件。

如果需要用pfx 可以用以下命令生成:

$ sudo openssl pkcs12 -export -inkey ssl.key -in ssl.crt -out ssl.pfx

5) git push 的错误解决

411错误：

error: RPC failed; result=22, HTTP code = 411
fatal: The remote end hung up unexpectedly
Writing objects: 100% (1967/1967), 1.99 MiB | 3.61 MiB/s, done.
Total 1967 (delta 183), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly
Everything up-to-date 

解决办法：

$ git config http.postBuffer 100m

413错误：

error: RPC failed; result=22, HTTP code = 413
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date

解决办法：

在所有 /etc/nginx/nginx.conf 文件中加入下面这句：

client_max_body_size 50m;

然后重启nginx服务：

$ sudo /etc/init.d/nginx restart

6) A上的nginx配置文件 /etc/nginx/sites-available/gitlab-ssl

# GITLAB-SSL
# Maintainer: @randx
# App Version: 5.0

#upstream gitlab {
#  server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
#}

server {
  listen 443;
  ssl on;
  ssl_certificate /etc/nginx/sites-available/ssl.crt;
  ssl_certificate_key /etc/nginx/sites-available/ssl.key;

  ssl_session_timeout 10m;
  ssl_protocols SSLv2 SSLv3 TLSv1;
  ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
  ssl_prefer_server_ciphers on;

  ##listen 80;     # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea

  #server_name vm-gitlab;     # e.g., server_name source.example.com;
  server_tokens off;     # don't show the version number, a security best practice
  root /home/git/gitlab/public;

  # individual nginx logs for this gitlab vhost
  access_log  /var/log/nginx/gitlab_access.log;
  error_log   /var/log/nginx/gitlab_error.log;

  location / {
    # serve static files from defined root folder;.
    # @gitlab is a named location for the upstream fallback, see below
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

  # if a file, which is not found in the root folder is requested,
  # then the proxy pass the request to the upsteam (gitlab unicorn)
  location @gitlab {
    proxy_read_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
    proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
    proxy_redirect     off;

    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   Host              $http_host;
    proxy_set_header   X-Real-IP         $remote_addr;

    proxy_pass https://192.168.122.24;
  }
}

7) B(192.168.122.24)上的nginx配置文件 /etc/nginx/sites-available/gitlab-ssl

# GITLAB-SSL
# Maintainer: @randx
# App Version: 5.0

upstream gitlab-ssl {
  server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
}

server {
  listen *:443 default_server;
  ssl on;
  ssl_certificate /etc/nginx/sites-available/ssl.crt;
  ssl_certificate_key /etc/nginx/sites-available/ssl.key;

  ssl_session_timeout 10m;
  ssl_protocols SSLv2 SSLv3 TLSv1;
  ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
  ssl_prefer_server_ciphers on;

  ##listen 80;     # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea

  server_name 192.168.122.24 vm-gitlab;     # e.g., server_name source.example.com;
  server_tokens off;     # don't show the version number, a security best practice

  root /home/git/gitlab/public;

  # individual nginx logs for this gitlab vhost
  access_log  /var/log/nginx/gitlab_access.log;
  error_log   /var/log/nginx/gitlab_error.log;

  location / {
    # serve static files from defined root folder;.
    # @gitlab is a named location for the upstream fallback, see below
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

  # if a file, which is not found in the root folder is requested,
  # then the proxy pass the request to the upsteam (gitlab unicorn)
  location @gitlab {
    proxy_read_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
    proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
    proxy_redirect     off;

    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   Host              $http_host;
    proxy_set_header   X-Real-IP         $remote_addr;

    proxy_pass http://gitlab-ssl;
  }
}

8) B(192.168.122.24)上的gitlab配置文件(前面部分）:

# # # # # # # # # # # # # # # # # #
# GitLab application config file  #
# # # # # # # # # # # # # # # # # #
#
# How to use:
# 1. copy file as gitlab.yml
# 2. Replace gitlab -> host with your domain
# 3. Replace gitlab -> email_from

production: &base
  #
  # 1. GitLab app settings
  # ==========================

  ## GitLab settings
  gitlab:
    ## Web server settings
    host: vm-gitlab
    port: 80
    https: true 

    # Uncomment and customize the last line to run in a non-root path
    # WARNING: This feature is no longer supported
    # Note that three settings need to be changed for this to work.
    # 1) In your application.rb file: config.relative_url_root = "/gitlab"
    # 2) In your gitlab.yml file: relative_url_root: /gitlab
    # 3) In your unicorn.rb: ENV['RAILS_RELATIVE_URL_ROOT']
    #
    # relative_url_root: /gitlab

    # Uncomment and customize if you can't use the default user to run GitLab (default: 'git')
    # user: git

    ## Email settings
    # Email address used in the "From" field in mails sent by GitLab
    ##email_from: gitlab@vm-gitlab
    email_from: gitlab@vm-gitlab.com

    # Email address of your support contact (default: same as email_from)
    ##support_email: support@vm-gitlab
    support_email: support@vm-gitlab.com

    ## User settings
    default_projects_limit: 10
    # default_can_create_group: false  # default: true
    # username_changing_enabled: false # default: true - User can change her username/namespace
......