关于丢失.bansh_profile配置文件造成-bansh-4.2#问题
首先是描述一下问题的产生过程吧:不小心cp了很多的文件到/root/下面去了,去/root/下执行ll发现好多好多文件,这样对我要查找需要的文件来说实在是太麻烦了,没有一目了然的感觉了,于是我rm –rf /root/ 和rm –f /root/将/root/目录下的所有文件都删除了,当时以为这样式正常的删除,没有什么副作用。但是,以后问题就来了,发现只要su到root用户下面去就会出现-bash-4.2#开头的命令行,以前的是[root@localhost~]#,这肯定有问题啊,虽然后面的命令不会受影响,但是前面的路径看不到了,这是很难受的!
于是百度,发现了原来是因为/root/下面的隐藏文件“.bash_profile”文件丢掉了,到这儿才发现是删除/root/下的文件的时候,是全部删掉了的,没有注意到隐藏文件。到了这儿问题就明显了,好了,接下来就是修复这个问题了!但是在修复前有个问题就是网上一些说直接从普通用户家目录下面复制.bash_profile文件到/root/目录下面就可以了,但是测试后不可以,原先很简单,就是两个文件不一样。我们先来看看普通用户user1和user2 下的.bash_profile文件是不是一样的:
[root@localhost ~]# vimdiff/home/user1/.bash_profile /home/user2/.bash_profile
结果发现普通用户之间是相同的,那么我们再看看root用户和普通用户之间是否也一样呢?
[root@localhost ~]# vimdiff .bash_profile /home/user1/.bash_profile
这是截图,看出不同了吧,所以要从普通用户复制.bash_profile过来,还要修改一点文件的,就是将红色区域删除,就是删除“.local/bin:$HOME/”就可以了。
好了,到这儿了,原理文件都说的差不多了,接下来就是模拟出错环境和恢复过程:
首先在没有删除/root/下隐藏文件的时候去/root/下面ls –al | grep “.bash_profile”一下,看看有没有.bash_profile
[root@localhost ~]# ls -al | grep".bash_profile" -rw-r--r--. 1 root root 176 Apr 12 16:18.bash_profile -rw-r--r--. 1 root root 12288 Apr 12 12:41 .bash_profile.swp
结果发现是有“.bash_profile”这个文件的!,接下来我们把它删了
[root@localhost ~]# rm -f .bash_profile [root@localhost ~]# ls -al | grep".bash_profile" -rw-r--r--. 1 root root 12288 Apr 12 12:41 .bash_profile.swp
看出确实是删掉了,到这儿就是模拟了丢失.bash_profile文件环境,接下来我们就看看丢了这个文件的后果:
[user1@localhost ~]$ su - Password: Last login: Wed Apr 12 16:18:58 CST 2017 onpts/0 -bash-4.2# ls anaconda-ks.cfg initial-setup-ks.cfg -bash-4.2# pwd /root -bash-4.2#
结果是不是很怪,切换到root用户的时候,竟然不是[root@localhost ~]#,而是-bash_4.2#,这样我们一眼看不出当前的工作目录,很不舒服,接下来就是去恢复这个.bash_profile的文件了,如果之前有备份/root/下的.bash_profile文件,就好办了,直接cp到/root/下就可以了,但是之前是直接删掉了的,没有备份,没有原件了。那就到普通用户下面去复制修改一份.bash_profile文件到/root/文件下去
先复制文件到root家目录中去:
-bash-4.2# cp /home/user1/.bash_profile ./ -bash-4.2# ls -al | grep".bash_profile" -rw-r--r--. 1 root root 193 Apr 12 19:09.bash_profile
修改.bash_profile文件:
-bash-4.2# cat ./.bash_profile # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then .~/.bashrc fi # User specific environment and startupprograms PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH -bash-4.2# vim ./.bash_profile -bash-4.2# cat ./.bash_profile # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then .~/.bashrc fi # User specific environment and startupprograms PATH=$PATH:$HOME/bin export PATH -bash-4.2#
好了,修改成功了;我们su – 刷新一下!
-bash-4.2# su - Last login: Wed Apr 12 19:09:03 CST 2017 onpts/0 [root@localhost ~]#
O(∩_∩)O~,发现又恢复了,到这儿就彻底解决了!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
centos7/rhel7新特性详解(2)
七、链路聚合 NIC teaming,简单的说就是多个物理端口绑定在一起当成一个逻辑端口使用,以便提高带宽,实现负载平衡或高可用的功能。RHEL7里面是通过runner (可以视作一段代码)来实现不同的目的。 配置的基本过程就是配置一个逻辑端口的连接,视作master;然后把需要的物理端口配置成slave 连接,绑定到组。然后把这个逻辑端口分配IP就可以用了 team:高可用性 首先准备两块网卡,它们有不同的MAC地址 创建一个新连接,类型是team连接名称team0。 activebackup表示热备,loadbalance表示负载均衡 master 配置好了,还得配置slave,即将eno16777736和eno33554960两块网卡加入到team0 执行nmcli connection show命令查看team0-1和team0-2的状态 上图可以看出team0-1和team0-2没有连接,执行下列命令连接team0-1和team0-2 执行ifconfig,发现网卡的地址都一样了,这样交换机才能转发包到同一个逻辑端口 最后给team0 分配一个IP...
- 下一篇
Gartner:自建大数据安全分析平台恐难逃失败厄运!
就在2017年4月11日,Gartner的著名分析师Anton Chuvakin在其Gartner官方博客上称“企业和组织如果打算自建安全数据湖或者定制自己的大数据安全分工具的话,那么基本上肯定会失败”! Anton以自己在跟客户沟通中了解到的信息作为佐证,说包括一些财富50强在内的企业在几年前自建的所谓安全分析项目耗费了大量资源,但收效甚微。有的客户表示“我宁愿希望我们从未听说过Hadoop这个东东,我们浪费了数年时间在企图基于Hadoop构建安全分析能力之上”(we wish we’d never discovered Hadoop – we wasted years of trying to make a security analytics capability out of it.) Anton进一步探讨了可能的失败原因,包括: 1)大数据池中充斥者垃圾数据;【我注:安全数据湖变成了安全数据臭水塘】 2)收集数据其实是个坑;【我注:没错,要知道,SIEM/SOC厂商用了N年时间才差不多掌握收集数据的种种坑,自建大数据安全分析平台,那么这些坑还要重走一遍,flume, logs...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS6,7,8上安装Nginx,支持https2.0的开启