labview除了全局变量还有别的办法_红帽系统服务器执行完"rm -rf *",程序员除了跑路还有别的办法么？...

目录

• 一、我为什么会手欠的执行"rm -rf *"
• 二、亡羊补牢?不如未雨绸缪
• 1. 一键快处法
• 2. 高级技巧法
• 3. 回收站法
• 4. 开源工具法
• 5. 综合处置法
• 三、总结

一、我为什么会手欠的执行"rm -rf *"

话说昨天,风和日丽,天朗气清,我没招着谁,也没惹着谁,大晚上好不容易抽了个空闲的时间,准备继续学习下我的ansible。然后呢，我的VPS突然提示我硬盘空间不足。 这个网上买的廉价VPS嘛，大家都懂的，性能不怎么样吧，硬盘还不给够数，看着磁盘还明明还有20%以上的空间，竟然就不让写入文件了。

当然这难不到我，不就是清理清理日志，腾腾空间么。切换到/var/log/httpd ,然后 rm -rf * ,切换输入一气呵成,然后搞定!自己的服务器就是这么任性.

不过等等,这一堆的权限不足是咋回事? 我是用root操作的啊...我顿感不妙,尝试着" ls /".Good!!! 常在河边走,哪有不湿鞋,我成功的把红帽系统的 根路径清空了..而原因也很简单,因为我切换目录没成功........你也许会说,默认清空的也是/home路径,没多大关系.....嗯,那是理想情况,但是...就是这个但是,我之前为了检查磁盘占用情况,把路径切换到了根下..。你要问我为啥犯如此低级的错误，我决定找个“我是程序员，不熟悉linux操作”的借口来搪塞。。。请务必放过我~~

二、亡羊补牢?不如未雨绸缪

没想到网上流传的笑话,终究被我亲身尝试了一遍,但是这次我是真的没笑出来。 这种情况下，如果没有备份或者快照，已经是无法挽回的重大事故了。这得亏是我自己学习用的破VPS，没人拿这事扣我工资。但是我认真反思了下，rm操作是根据业务特点来的,确实有手动执行的必要,而且某些场景下确实有批量删除的必要性,不能简单的逐个文件确认. 因此我必须寻找一种方便与安全相结合的解决方案.

主观上肯定要提高认识：

1. 生产环境任何操作存有敬畏心里，三思而后行
2. 在任何地方执行rm命令前，务必pwd查看当前路径

技术上上应该有这么几个办法(本文所列方法仅在Redhat7(Centos)红帽系统上实际验证通过)：

1. 一键快处法

# 临时生效alias rm='ls'# 想让命令永久生效，规则要写入环境变量配置文件里vi /root/.bashrc

但是这样安全貌似是安全了，但是真是要删除文件的时候，就不友好了，所以这种方法不推荐。

2. 高级技巧法

如易我这次犯错主要是切换目录时，输入错误，造成了目录未切换成功，自己在没有复核的情况下直接执行了rm -rf *, 那么有没有一种安全的命令输入方式呢？答案是有,在实际情况中可以使用以下技巧。当前序命令未执行成功时，就直接返回了，后面的命令会直接忽略。这样就避免酿成大错。

# 查看系统当前生效的alias配置 alias# 切换到错误目录并执行cd /tmpa && rm -rf *# 切换到正确目录并执行cd /tmp && rm -rf *

下图，我们做了一个比较全面的实验，在未设置rm别名的情况下，依次执行命令，返回了预期的结果，且没有造成次生灾害。

3. 回收站法

linux本身没有回收站机制，删了就是删了。那么我们顺着这个思路，给他补充一个“回收站”。可以写个shell脚本替换rm命令，或者在需要删除文件的时候使用mv命令将文件移动到回收站。

• 在/home/username/ 目录下新建一个目录，命名为：.trash
• 在/home/username/tools/目录下，新建一个shell文件，命名为： remove.sh

TRASH_DIR="/home/username/.trash"  for i in $*; do  STAMP=`date +%s`  fileName=`basename $i`  mv $i $TRASH_DIR/$fileName.$STAMP done

• 修改~/.bashrc， 把rm命令替换成我们的脚本

# 命令替换alias rm="sh /home/username/tools/remove.sh"# 替换实时生效source ~/.bashrc

• 设置crontab，定期清空垃圾箱，如：

crontab -e#每天0点清空垃圾箱0 0 * * * rm -rf /home/username/.trash/*

这种办法看起来貌似不错，但是缺点也比较明显，不能立刻释放磁盘空间。也不能完全避免在根路径下执行rm -rf * 的尴尬。对普通目录的删除倒是用途很大。

4. 开源工具法

嗯，大家都推荐safe-rm，我也借花献佛推荐一下。这个东西呢，通过配置文件可以有效的保护预置的目录，防止我们误操作。 下面如易我来验证下:

• 下载安装safe-rm

# 不用怀疑版本号，我已经替您去确认过了，这货2014年就停更了，估计以后也不打算更。# 可能是因为功能太简单没啥要完善的了，够用就好wget https://launchpadlibrarian.net/188958703/safe-rm-0.12.tar.gztar xf safe-rm-0.12.tar.gzmv safe-rm-0.12 /usr/local/safe-rmmkdir -p /usr/local/safe-rm/bincp /usr/local/safe-rm/safe-rm /usr/local/safe-rm/bin/rm

• 配置环境变量

# 加入环境变量sed -i '$a export PATH=/usr/local/safe-rm/bin:/bin:/usr/bin:$PATH' /etc/profile# 变量即时生效source /etc/profile

设置后，再次检查，rm命令已经变成了我们的安全删除命令。

• 修改/etc/safe-rm.conf配置,将需要保护的目录注明

vi /etc/safe-rm.conf#推荐的列表//bin/boot/dev/etc/home/initrd/lib/proc/root/sbin/sys/usr/usr/bin/usr/include/usr/lib/usr/local/usr/local/bin/usr/local/include/usr/local/sbin/usr/local/share/usr/sbin/usr/share/usr/src/var/etc/safe-rm.conf

我们来验证一下,请务必在测试环境或虚拟机上实验，出现问题，本人概不负责！！，请谨慎配置conf文件。

 rm -rf / cd / rm -rf *

放心得瑟

• 例外情况处理
• 1.执行删除命令出错，提示“-bash: /usr/local/safe-rm/bin/rm: /usr/bin/perl: bad interpreter: No such file or directory”
• 原因：缺少gcc编译环境
• 解决：“yum -y install gcc gcc-c++ perl make kernel-headers kernel-devel”
• 2.如果想强烈删除某保护路径下的文件，又不想修改/etc/safe-rm.conf时，可以采取显示调用系统原有rm的方式。

/bin/rm -rf /tmp

5. 综合处置法

本来计划是在safe-rm的基础上增加一定的灵活性，加入软提示的机制，比如在批量删除时，通过交互时的提醒来强制提醒操作员在进行危险操作。管理员可以强制忽略，执行删除。毕竟主观恶意怎么防也防不住对吧。不过考虑到脚本在不同场景的兼容性，且与safe-rm功能高度重合，就不重复造轮子了。

三、总结

通过本次学习，终于给服务器加了一道保险，以后我这种马大哈程序员再也不用担心跑路的问题了，心满意足，夜色正好，赶紧去睡觉。

tips: 我在学习过程中，不小心把系统原有的rm给覆盖掉了，导致我不得不又重新装了一次系统，求教各位大神，有什么便捷的方式恢复rm等系统自带命令，欢迎评论指教，不胜感激。