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 [e-mail] 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邮箱，按设置，反垃圾，设置邮件地址白名单，把[e-mail]加入到白名里。也可以把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 = 411fatal: The remote end hung up unexpectedlyWriting 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 unexpectedlyEverything up-to-date 

解决办法：

$ git config http.postBuffer 100m

413错误：

error: RPC failed; result=22, HTTP code = 413fatal: The remote end hung up unexpectedlyfatal: The remote end hung up unexpectedlyEverything 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.0upstream 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_fromproduction: &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: [e-mail]    # Email address of your support contact (default: same as email_from)    ##support_email: support@vm-gitlab    support_email: [e-mail]    ## 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......