GitLab 的惨剧让我造了个防 rm 的轮子: rm-protection

2017-02-03 22:11:49 +08:00
 discrete

rm-protection

GitLab 的惨剧想必大家都知道了:rm -rf了生产服务器上的数据库。常在河边走,哪能不湿鞋。即便是再认真,总是有失误的风险。

现在网上已经流行了数种方法: rm -i , trash-cli 等等。rm -i 显然并不实用:想必没人能忍受每个文件都被问一次?况且就 GitLab 的情况,rm -i并不能起保护作用。trash-cli相当于启用了回收站,但是这又会带来一些小麻烦(比如在磁盘被 log 挤爆的情况下)。

rm-protection 则采取了一种全新的思路:由用户自行设置一个安全问题来保护文件,在删除时询问相应的问题。想象一下,若 YP 在执行删除时突然被问一句:「 Which server are you on? 」,还会出现这样的惨剧吗?

快速开始

rm-protection 几乎完全兼容rm,因此可以作为 alias 使用。

  1. 从 PyPi 中安装并为 rm-p 创建 alias 。

    pip install rm-protection & alias rm="rm-p"

  2. 使用 protect 命令保护你想要保护的文件或者文件夹。

  3. Happy rm-ing!

原理

rm-protection 获取 arguments 后,会逐一检测是否存在 .<filename>.rm-protection 文件。若存在,则询问用户,否则将不再传递这个 argument 。安全的 argument 将被传递给 rm 进行删除。

栗子:

它也能保护批量的递归删除:

与其他工具的对比

参见 GitHub 中的表格

未来?

若是这个工具能被推广使用,团队协作之间可以大有功用。在软件、文件分发时,分发者可以提前保护文件防止误删。在开发和部署时也可提前保护文件,防止在生产环境中的误删。

贡献

Github 欢迎 PR, 提 Issue 或者 Star :)

6634 次点击
所在节点    分享创造
36 条回复
qiuai
2017-02-03 22:26:59 +08:00
如果是为了服务器多的情况下准备的,为什么不直接设置问题为服务器的名字.
比如提前在文件中定义服务器的名字为 Prod-1
那么删除的时候要输入 Prod-1.如果要删除 2.那么不会去输入-1 吧?
如果输入了-2..那就可以直接拒绝了嘛...

弄一个问题上去,好像有点复杂?
jingniao
2017-02-03 22:40:03 +08:00
其实我觉得如果给 rm 添加个功能,读取配置文件避开
jingniao
2017-02-03 22:40:37 +08:00
重要文件,如果要删除,加个参数
discrete
2017-02-03 22:40:38 +08:00
@qiuai 你确实可以设置为问服务器的名字呀。问题和答案都是用户在保护文件时设定的。在 Prod-1 上你的回答应该是 Prod-1 ,在 Prod-2 上应该是 Prod-2 。

与丢失重要文件的相比,我觉得问一个问题的时间挺值的。
discrete
2017-02-03 22:42:43 +08:00
@jingniao 这个轮子已经有了,叫 Safe-rm 。相比之下我觉得 rm-protection 的方式更加灵活一点。假定你不问问题的话,加个参数还不是顺手事情?(想象一下 YP 的状况。
Akagi201
2017-02-03 22:44:20 +08:00
建议用 bash 重写, 不依赖任何环境.
discrete
2017-02-03 22:55:09 +08:00
@Akagi201 这种轻量级的程序确实应该用 bash 写……不过现在哪台机器上没个 python 呢
不过当然欢迎各种语言的 implementation 。只要 .rm-protection 这个格式互相能兼容就行。
snnn
2017-02-03 22:55:12 +08:00
然后硬盘爆了,数据库写入失败,挂掉了
xuboying
2017-02-03 23:46:39 +08:00
300G 的数据复制一下,也没多久时间,关键还是要做好备份啊
rm 再小心还是会有错误的时候。
问题的关键点还是备份做的不好啊
Doubear
2017-02-04 01:40:22 +08:00
which server are you on?

???

[我不是在测试环境么???]

> dev server

……

[卧槽哪来那么多文件?!!糟糕这尼玛不是测试服……]

《 MySQL 从删库到跑路》
chuhades
2017-02-04 02:02:42 +08:00
➜ ~ grep trash .zshrc
alias trash='gvfs-trash'
cuebyte
2017-02-04 02:16:42 +08:00
@discrete 你好意思……你的是 python3
yangqi
2017-02-04 02:19:41 +08:00
你这个显然解决不了类似这次 gitlab 的问题。人家不是误删文件,而且误以为自己在 slave 机器上,结果是在主机上。

即使有了各种确认也没用
em70
2017-02-04 02:24:39 +08:00
@yangqi 我觉得楼主的方案可以解决,因为会问你当前操作机器的名字,你以为在 slave,输入就是错的,不执行
yangqi
2017-02-04 02:40:42 +08:00
@em70 那要看问题是什么了,如果你问了机器名字,下次我文件夹搞错了,误以为在别的文件夹咋办
cxbig
2017-02-04 03:32:54 +08:00
我们家是在 PS1 上直接加机器代号, admin 、 backend 、 frontend-1~x 。根本不会弄混。
WildCat
2017-02-04 04:13:45 +08:00
SharkIng
2017-02-04 06:53:29 +08:00
显然这个也不能完全解决问题, Gitlab 的情况是程序员太累,以为自己在 db2 结果实际是 db1. 即使有这么个问题也有可能因为太累输错之类的。
eccstartup
2017-02-04 06:56:26 +08:00
叫 `rm-gitlab` (逃
deamwork
2017-02-04 07:42:55 +08:00

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/337936

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX