生产环境下更换Gitlab存储目录踩过的坑
场景描述:
朋友公司的一台Gitlab服务器由于磁盘空间没有规划好,外加使用规范的问题导致存储分区撑爆了,服务全部down掉,歇菜了。。。
服务器上有一个比当前存储分区大的分区,可以满足未来几年的数据存储,遂将/var/opt/gitlab/
目录下的文件cp -rf
到了大分区下,半天后,启动服务,页面报500错误,于是开启了我的填坑之旅。
坑一:复制时丢失了文件权限
查询日志gitlab-ctl tail
后发现读取redis.socket
文件时Permission denied
,进入到/var/opt/gitlab/redis/
目录下,redis.socket
文件存在的好好的,查看权限是777,没问题,再查看父目录的权限,属组是root
,权限位是dwrxr-x---
,问题定位到,属组改成git
,访问页面,告别了500。
坑二:配置了ssh密钥的用户clone时提示输入密码
不久又报告来一个问题,配置了ssh密钥的用户在执行git clone时,提示输入密码,拿到一个账号,添加了自己的公钥上去,亲测,果然,查看了下目录结构,没有找到关于ssh的目录或者文件,对比了下另外一个环境下的目录结构,发现少了.ssh
,手动创建之并赋权,gitlab reconfigure
,.ssh
目录下的authorized_keys
文件出现了,测试,不再需要输入密码了。
总结: 两个坑皆因copy
操作导致,未在复制时保留文件及文件夹权限,丢失了隐藏文件夹及文件,因此强烈建议复制时加上-a
和-p
选项。