0起因
test服务器经常要手动在本地执行部署脚本，很是麻烦，索性决定配置CI，
当test分支有push动作的时候，自动执行部署脚本，想法很美，
于是花了整整一下午的时间配置gitlab的CI，由于gitlab的CI的对应ssh用户是gitlab_runner,
所以需要gitlab_runnser去切换身份执行pull脚本，必然使用sudo命令
于是想也没想就敲了下面一句该死的命令
sudo vim /etc/sudoers
然后编辑权限，敲完后一运行就报错，一看报错信息就傻眼了。。。
/etc/sudoers.d/90-cloudimg-ubuntu: syntax error near line 1 <<<
sudo: parse error in /etc/sudoers.d/90-cloudimg-ubuntu near line 1
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
心里暗想，不妙了，所有涉及到sudo的语句都没法执行了，
报错正常业务的更新等等。。。。整个test服务器怕是要废了。
第一反应stack_over_flow：
Xnip2018-08-01_18-54-39.jpg
马上尝试这种方法。。。。
然而，我的电脑仅有的几个用户也没有root认证，太尴尬。。。。
快速分析了下如果重新开一台EC2的成本，包括nginx，supervisor，virtualenv,crontab,sql 。。。。。。等等的配置。成本太大，怕是半天也搞不定。
于是再次冷静分析，不过是一个小小sudoer文件的问题，不至于这么大费周折，既然我们有Volumn，为什么不从Volumn角度入手呢？有磁盘我们就有一切啊。
1 思路分析
把大象装进冰箱的三部同样也适用于Volumn
- 1 取下挂载的Volumn（deattach）
- 2 挂到一个好的EC2上
- 3 mount挂载
- 4 修改
- 5 Volumn装回去
2 实践
2.1 关掉EC2
记得记下原来的device_name ,待会装回来的时候，肯定是需要撞到同样的device_name上
2.22 把Volumn取下来
Xnip2018-08-01_19-07-30.jpg
2.3 重新挂载到一个好的EC2上面
挂载的时候系统会提示到时dev里面的名字会不一样，不过没有关系，只要挂载上去/dev目录下看下就能找到了
aws也给了相应的提示：
Note: Newer Linux kernels may rename your devices to /dev/xvdf through /dev/xvdp internally,
even when the device name entered here (and shown in the details) is /dev/sdf through /dev/sdp.
目前只是物理挂载上了，去找下对应的device_name
ls /dev/
找到后，执行下面命令
mkdir /mnt/other
mount /dev/sdaXXX /mnt/other
挂载成功后，去/mnt/other目录里面直接更改错误的sudoers文件。
2.4 volumn回归
直接attach到原来的ec2上即可，注意device_name要和原来的一致，不然启动会无法启动
2.5 start EC2
启动后去确认下sudoer不再报错
3反思
尽管问题已解决，但是坑是没必要再踩
- 1 坚决不要sudo visudo。
- 2 给root早点起个密码，不至于sudo命令失效的时候切不到 root。
- 3 多给EC2做备份，尽量一周备份一个。
- 4 遇事不慌，大不了从头来过。
网友评论