BUAAZP.

搭gitlab的那些坑

June 13, 2014

搭gitlab的那些坑

@招牌疯子

手动搭建gitlab的复杂程度想必大家也有所耳闻,我也曾有过在测试机上搭建成功的经验,后来想放到线上机器给团队用,搭建之初,综合利弊,选择了最简单方便的bitnami-gitlab一键安装包,本以为这样就可以轻松加愉悦了,事实证明我还是图样图森破。

首先,我厂的线上机器不允许非自然人账户通过ssh登陆(想ssh登陆服务器的帐号必须通过微盾认证),你新建的git帐号会在系统定期检查时被清理掉,OP给的建议是申请一个假账户绑定一个微盾,作为一个假人存在,但弊端是我得随身携带两个微盾,蛋疼。

于是想别的办法,发现一个线上服务器清理账户的bug,然后采用了一个非常hack的手段保证了这个git帐号长期存在,具体过程由于安全原因在此就不透漏了。

然后是sshd服务的问题,本来想的是从别的机器上复制一份白名单文件authorized_keys过来,省的这些老用户再次添加id_rsa.pub,同时拷贝的还有ssh_host_dsa_keyssh_host_rsa_key等文件,启动sshd服务之后ssh就是连不上,最后发现是这些文件的权限给高了,chown和chmod之后终于ssh连接成功。

-rw-r–r– 1 git git 275 Mar 10 15:40 authorized_keys

接着发现git push的时候死活就是提交不上去,报repo路径不对神马的错误,按着这条错误的道路追了好久都没法解决。最后偶然想到authorized_keys不是空的,于是删掉重新生成之后终于可以了。这个错误是由于authorized_keys文件中的pub key跟gitlab数据库中保存的白名单不一致,略坑。

gitlab总算跑起来了,心情舒畅地回家过了个周末,然后准备搭gitlabci。

第一次搭建的时候没想到要装ci组建,bitnami也不支持增量安装,只能想到先备份后恢复的办法。于是先将gitlab数据库dump出来,再把gitlab目录备份,然后重新安装带ci组建的gitlab,导入数据库备份,复制旧的repos和头像等文件到新目录中,恢复gitlab和gitlab-shell的配置文件:

sudo ./ctlscript.sh stop  
./bitnami-gitlab-6.6.3-0-linux-x64-installer.run 
Select a folder [/opt/gitlab-6.6.3-0]: /opt/gitlab-6.6.3-0  
sudo ./ctlscript.sh stop  
cd /opt/gitlab-6.6.3-0/apps/gitlab/gitlab-shell  
sudo cp ~/config.yml .  
cd /opt/gitlab-6.6.3-0/apps/gitlab/htdocs/config  
sudo cp ~/gitlab.yml .  
cd /opt/gitlab-6.6.3-0/apps/gitlab/htdocs/public/uploads  
sudo cp -r /opt/gitlab-test/apps/gitlab/htdocs/public/uploads/* .  
sudo ./ctlscript.sh start mysql  
sudo ./use_gitlab mysql -u bitnami -p bitnami_gitlab < ../bitnami_gitlab_bk.sql  
sudo ./ctlscript.sh restart  

重新启动,结果,git push又不行了。。。

准备tail -f一下gitlab-shell的日志看看,结果新路径下的gitlab-shell竟然完全没有日志,我整个人都不好了,查遍了gitlab下的配置,确认设定的路径没有问题,着实让人费解。

没办法,去洗了把脸继续搞,发现旧的gitlab安装目录下gitlab-shell在打错误日志,实在想不通为什么会调用旧的shell,果断停掉gitlab所有服务,将旧的目录重命名,直接使用ssh git@10.XX.XXX.XXX登陆一下,发现打出来

PTY allocation request failed on channel 0  
/opt/gitlab-test/ruby/lib/ruby/1.9.1/net/http.rb:763:in `initialize’: Connection refused – connect(2) (Errno::ECONNREFUSED) 

的错误,这个路径还是旧的,说明ssh连上的第一时间就定向了错误的地方,开始怀疑是bashrc的问题,删掉,依旧不行。

再去洗个脸,终于灵机一动发现gitlab web端添加ssh key进白名单文件的时候,会加上全路径的shell命令,示例如下:

command=”/opt/gitlab-test/apps/gitlab/gitlab-shell/bin/gitlab-shell key-1″,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQZL/X3JVbozKKQ7MKgfnh+j/uU3m0MQLbwCfxHc3Xf4c2R7wNl6Pr0DXhnX1eBE0Dg0fCLfckMJa2V zippo@MacBook-Pro.local  

这下总算找到问题所在了,如果你新安装的路径与旧的不一致,就不能使用备份(光修改authorized_keys文件中的shell路径也是不行的,因为数据库已经被恢复,两者不一致又会导致上面所说的问题)。无奈,全新安装不恢复,好在刚搭起来没两天,影响不大,重新启动后ci和gitlab都可用了。

注:忽然想到可以按照原路径重新安装一下,也许可行,明天试试。

补充:2014-03-19已测试,果然按照原路径重新安装一下是可以的。

坑填得好累,不知道该怎么去爱了。。。

招牌疯子

Coder, OpenSource, DataStorageEngineer. Work@ByteDance
开源爱好者,zimg作者,大规模数据存储工程师。