生产环境下更换Gitlab存储目录踩过的坑

生产环境下更换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选项。

你可能感兴趣的:(Coder)