centos清空tmp，centos安装软件命令

老铁们，大家好，相信还有很多朋友对于centos清空tmp和centos安装软件命令的相关问题不太懂，没关系，今天就由我来为大家分享分享centos清空tmp以及centos安装软件命令的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！

CentOS下如何实行计划任务CentOS下实行计划任务的方法

今天在一个项目里面，遇到一个故障：系统在做基于Weblogic的OA系统压力测试中，并发的连接数非常的少（大大低于正常数），系统是采用红旗的DC 4.1 for安腾2版本，使用apache做web服务转发。

后来经过一系列的检查，最后发现原来是之前连续两天的压力测试，导致摆放日志的/var目录20G的空间都给占满了；导致新的日志需要不断的覆盖旧日志，磁盘的读写频繁，导致IO占用过大，所以并发连接数不能满足要求。清空日志文件即可。

考虑到今后可能也会出现类似的问题（当然，现实中不可能几天就达到测试的结果），所以希望使用定时删除日志的方法。这里就考虑到需要使用linux的计划任务，也叫例行性命令。

1、循环执行的计划任务

linux下面有atd和crond两种计划任务，其中，atd服务使用的at命令只能执行一次，而crond服务使用的crontab定义的命令，是循环作用的，所以crond才符合我们的要求。

crontab支持两种状态：一、直接编写计划任务；二、使用目录的方式，放在目录里面的都会定时执行。

2、可以使用的用户

默认情况下，系统中可以登陆的用户，都可以使用crontab定义计划任务。不过，可以通过下面两个文件限制权限：

引用

◆/etc/cron.allow：

将可以使用 crontab的账号写入其中，若不在这个档案内的使用者则不能使用 crontab；

◆/etc/cron.deny：

将不可以使用 crontab的账号写入其中，若未记录到这个档案当中的使用者，就可以使用 crontab。

※类似TCPWrapper定义的方式。

3、直接使用crontab编辑计划任务：

命令：

crontab [-u username] [-l|-e|-r]

参数：

-u：通过-u帮其它使用者建立/移除 crontab；

-e：编辑 crontab的内容

-l：查看 crontab的内容

-r：移除 crontab的所有内容（是全部的内容，如果只是删除某个，用-e编辑即可）

内容格式：

*****命令

前面的五个*号，表示分、时、日、月、周，如：

代表意义分钟小时日期月份周

数字范围 0-59 0-23 1-31 1-12 0-7

*号代表任何时间都接受的意思，任意。

*号之间用空格分开，如果是一段范围，用-号连接；如果是隔开几个时间，用,号表示。

另外，命令必须是编写计划任务的用户有权限执行的，并且最后用绝对路径。

例如：

#crontab-e

59 23 1 5* mail linuxing/home/test.txt

每在5月1日，23点59分就把/home/test.txt的内容作为邮件发给linuxing用户

*/5****/opt/test.sh

每5分钟就执行一次/opt/test.sh脚本

0 3,6***/usr/local/bin/test.sh

每在3点和6点整点都执行/usr/local/bin/test.sh命令

0 8-12***/root/backup.sh

8点到 12点之间的每小时的0分都执行/root/backup.sh

4、基于目录的方式执行计划任务

对于系统的计划任务，已经在/etc/crontab里面定义，采用的就是基于目录的方式。系统会定时读取该文件，并根据里面的定义执行命令。

可以使用vi直接编写/etc/crontab文件，其中格式如下：

#cat/etc/crontab

SHELL=/bin/bash#使用的shell

PATH=/sbin:/bin:/usr/sbin:/usr/bin#预定义的PATH路径

MAILTO=root#出现问题发Email给该用户

HOME=/#家目录

# run-parts

01**** root run-parts/etc/cron.hourly#每小时的目录

02 4*** root run-parts/etc/cron.daily#每天

22 4** 0 root run-parts/etc/cron.weekly#每周日

42 4 1** root run-parts/etc/cron.monthly#每个月1号

分时日月周执行者身份命令

可以看到前面的五个参数的定义和直接编辑计划任务是一样的，增加了执行的用户定义和run-parts参数。

run-parts后面跟的是目录名称，例如：/etc/cron.hourly，表示每小时01分就到/etc/cron.hourly目录中执行目录下的所有可执行文件；当然，目录是可以自己定义的。

如果你需要增加系统的计划任务，只需要在对应的目录添加执行文件即可，例如：我需要在每天都执行updatedb的操作，则我只需要把/usr/bin/updatedb的执行命令链接到/etc/cron.daily目录就可以了。

※同样的，如果不需要使用目录的方式，也可以使用如下的方式：

02 01*** root/root/test.sh

也就是没有了run-parts，后面就直接跟命令的绝对路径

5、注意事项

◆如果使用crontab编辑计划任务或直接修改/etc/crontab文件后，计划任务没有生效，可能需要重启一下crond服务：service crond restart

◆当编写/etc/crontab文件的时候，不要漏了指定执行计划任务的用户，这是和直接用crontab-e编辑不同的。

◆某用户（如root）用crontab-e编辑的计划任务存放在/var/spool/cron/root，这个文件下。但最好不要直接编辑他，因为crond执行的时候，会在/tmp目录中建立需要的临时文件，直接编辑会对此有影响，甚至出错。

◆cron执行的每一项工作都会被纪录到/var/log/cron这个日志文件中，可以从这个文件查看命令执行的状态。

CentOS7安装MYSQL8.X详细教程

欲在 CentOS 7上安装 MySQL 8.x，首先访问阿里云开源镜像站下载所需软件。步骤如下：

1.检查系统中是否已安装 mysql，若未安装则跳过此步骤。

2.安装 wget工具。

3.使用 wget抓取 mariadb包并删除旧版本。

4.配置阿里云的 yum源。

5.重启 yum以应用配置更改。

6.进入 tmp文件夹清空内容。

7.通过 wget下载 MySQL 8.0最新版本的包。

8.打开 MYSQL官网并获取阿里云下载地址，确保包为最新版本。

9.配置 mysql的 yum源，文件会生成在/etc/yum.repos.d目录。

10.检查 yum.repos.d目录下文件。

11.开始安装 MySQL。

12.如果通过 wget获取的包不是最新版本，执行 GPG升级后重新安装。

13.安装完成后，打开 my.cnf文件并添加 [skip-name-resolve]语句，以跳过名称解析设置（可选）。

14.启动 MySQL服务并检查状态及端口。

15.设置开机自动启动 MySQL。

16.抓取 MySQL临时密码。

17.使用临时密码登录 MySQL。

18.更改密码为强密码，并刷新数据库。

19.打开 3306端口，重启防火墙并验证端口已开放。

MySQL知识点：

创建用户时，MySQL 5.6版本与 8.0版本的授权方式有所差异。了解这两种版本的授权方式对于正确配置权限至关重要。

以上步骤完成后，您已成功在 CentOS 7上安装并配置 MySQL 8.x，可进行下一步数据库管理与应用部署。

Linux服务器被rootkit恶意软件攻击后的处理方法

rootkit是一种恶意软件，通常和木马等其他恶意程序一起结合使用，而Linux是其重要的攻击对象，那么Linux被rootkit攻击后该怎么办呢？下面小编就给大家介绍下Linux服务器被rootkit攻击后该如何处理。

IT行业发展到现在，安全问题已经变得至关重要，从最近的“棱镜门”事件中，折射出了很多安全问题，信息安全问题已变得刻不容缓，而做为运维人员，就必须了解一些安全运维准则，同时，要保护自己所负责的业务，首先要站在攻击者的角度思考问题，修补任何潜在的威胁和漏洞。

下面通过一个案例介绍下当一个服务器被rootkit入侵后的处理思路和处理过程，rootkit攻击是Linux系统下最常见的攻击手段和攻击方式。

1、受攻击现象

这是一台客户的门户网站服务器，托管在电信机房，客户接到电信的通知：由于此服务器持续对外发送数据包，导致100M带宽耗尽，于是电信就切断了此服务器的网络。此服务器是Centos5.5版本，对外开放了80、22端口。

从客户那里了解到，网站的访问量并不大，所以带宽占用也不会太高，而耗尽100M的带宽是绝对不可能的，那么极有可能是服务器遭受了流量攻击，于是登录服务器做详细的检测。

2、初步分析

在电信人员的配合下通过交换机对该服务器的网络流量进行了检测，发现该主机确实存在对外80端口的扫描流量，于是登录系统通过“netstat–an”命令对系统开启的端口进行检查，可奇怪的是，没有发现任何与80端口相关的网络连接。接着使用“ps–ef”、“top”等命令也没有发现任何可疑的进程。于是怀疑系统是否被植入了rootkit。

为了证明系统是否被植入了rootkit，我们将网站服务器下的ps、top等命令与之前备份的同版本可信操作系统命令做了md5sum校验，结果发现网站服务器下的这两个命令确实被修改过，由此断定，此服务器已经被入侵并且安装了rootkit级别的后门程序。

3、断网分析系统

由于服务器不停向外发包，因此，首先要做的就是将此服务器断开网络，然后分析系统日志，寻找攻击源。但是系统命令已经被替换掉了，如果继续在该系统上执行操作将变得不可信，这里可以通过两种方法来避免这种情况，第一种方法是将此服务器的硬盘取下来挂载到另外一台安全的主机上进行分析，另一种方式就是从一个同版本可信操作系统下拷贝所有命令到这个入侵服务器下某个路径，然后在执行命令的时候指定此命令的完整路径即可，这里采用第二种方法。

我们首先查看了系统的登录日志，查看是否有可疑登录信息，执行如下命令：

more/var/log/secure|grep Accepted

通过对命令输出的查看，有一条日志引起了我们的怀疑：

Oct 3 03:10:25 webserver sshd［20701］： Accepted password for mail from 62.17.163.186 port 53349 ssh2

这条日志显示在10月3号的凌晨3点10分，有个mail帐号从62.17.163.186这个IP成功登录了系统，mail是系统的内置帐号，默认情况下是无法执行登录操作的，而62.17.163.186这个IP，经过查证，是来自爱尔兰的一个地址。从mail帐号登录的时间来看，早于此网站服务器遭受攻击的时间。

接着查看一下系统密码文件/etc/shadow，又发现可疑信息：

mail：$1$kCEd3yD6$W1evaY5BMPQIqfTwTVJiX1:15400:0：99999:7：：：

很明显，mail帐号已经被设置了密码，并且被修改为可远程登录，之所以使用mail帐号，猜想可能是因为入侵者想留下一个隐蔽的帐号，以方便日后再次登录系统。

然后继续查看其他系统日志，如/var/log/messages、/var/log/wtmp均为空文件，可见，入侵者已经清理了系统日志文件，至于为何没有清空/var/log/secure文件，就不得而知了。

4、寻找攻击源

到目前为止，我们所知道的情况是，有个mail帐号曾经登录过系统，但是为何会导致此网站服务器持续对外发送数据包呢？必须要找到对应的攻击源，通过替换到此服务器上的ps命令查看系统目前运行的进程，又发现了新的可疑：

nobody 22765 1 6 Sep29？ 4-00:11:58.t

这个.t程序是什么呢，继续执行top命令，结果如下：

PID USER PR NI VIRT RES SHR S%CPU%MEM TIME+ COMMAND

22765 nobody 15 0 1740m 1362m 1228 S 98.3 91.5 2892:19.t

从输出可知，这个t程序已经运行了4天左右，运行这个程序的是nobody用户，并且这个t程序消耗了大量的内存和cpu，这也是之前客户反映的网站服务器异常缓慢的原因，从这个输出，我们得到了t程序的进程PID为22765，接下来根据PID查找下执行程序的路径在哪里：

进入内存目录，查看对应PID目录下exe文件的信息：

［root@webserver~］#/mnt/bin/ls-al/proc/22765/exe

lrwxrwxrwx 1 root root 0 Sep 29 22:09/proc/22765/exe-》/var/tmp/…/apa/t

这样就找到了进程对应的完整程序执行路径，这个路径很隐蔽，由于/var/tmp目录默认情况下任何用户可读性，而入侵者就是利用这个漏洞在/var/tmp目录下创建了一个“…”的目录，而在这个目录下隐藏着攻击的程序源，进入/var/tmp/…/目录，发现了一些列入侵者放置的rootkit文件，列表如下：

［root@webserver。。.］#/mnt/bin/ls-al

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa

-rw-r--r-- 1 nobody nobody 0 Sep 29 22:09 apa.tgz

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 haha

-rw-r--r-- 1 nobody nobody 0Sep 29 22:10 kk.tar.gz-

rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 login

-rw-r--r-- 1 nobody nobody 0 Sep 29 22:10 login.tgz

-rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 z

通过对这些文件的分析，基本判断这就是我们要找的程序攻击源，其中：

1）、z程序是用来清除系统日志等相关信息的，例如执行：

。/z 62.17.163.186

这条命令执行后，系统中所有与62.17.163.186有关的日志将全部被清除掉。

2）、在apa目录下有个后门程序t，这个就是之前在系统中看到的，运行此程序后，此程序会自动去读apa目录下的ip这个文件，而ip这个文件记录了各种ip地址信息，猜想这个t程序应该是去扫描ip文件中记录的所有ip信息，进而获取远程主机的权限，可见这个网站服务器已经是入侵者的一个肉鸡了。

3）、haha目录里面放置的就是用来替换系统相关命令的程序，也就是这个目录下的程序使我们无法看到操作系统的异常情况。

4）、login程序就是用来替换系统登录程序的木马程序，此程序还可以记录登录帐号和密码。

5、查找攻击原因

到这里为止，服务器上遭受的攻击已经基本清晰了，但是入侵者是如何侵入这台服务器的呢？这个问题很重要，一定要找到入侵的根源，才能从根本上封堵漏洞。

为了弄清楚入侵者是如何进入服务器的，需要了解下此服务器的软件环境，这台服务器是一个基于java的web服务器，安装的软件有apache2.0.63、tomcat5.5，apache和tomcat之间通过mod_jk模块进行集成，apache对外开放80端口，由于tomcat没有对外开放端口，所以将问题集中到apache上面。

通过查看apache的配置发现，apache仅仅处理些静态资源请求，而网页也以静态页面居多，所以通过网页方式入侵系统可能性不大，既然漏洞可能来自于apache，那么尝试查看apache日志，也许能发现一些可疑的访问痕迹，通过查看access.log文件，发现了如下信息：

62.17.163.186--［29/Sep/2013:22:17:06+0800］“GET ？configdir=|echo;echo;ps+-aux%00 HTTP/1.0” 200 12333“-”“Mozilla/5.0（Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1） Gecko/20121010 Firefox/2.0”

62.17.163.186--［29/Sep/213:22:17:35+0800］“GET ？configdir=|echo;echo;cd+/var/tmp/。。./haha;ls+-a%00 HTTP/1.0” 200 1626“-”“Mozilla/5.0（Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1） Gecko/20121010 Firefox/2.0”

至此，发现了漏洞的根源，原来是awstats.pl脚本中configdir的一个漏洞，通过了解此服务器的应用，客户确实是通过一个Awstats的开源插件来做网页访问统计，通过这个漏洞，攻击者可以直接在浏览器上操作服务器，例如查看进程、创建目录等。通过上面第二条日志可以看出，攻击者正常浏览器执行切换到/var/tmp/。。./haha目录的操作。

这个脚本漏洞挺可怕的，不过在Awstats官网也早已给出了修补的方法，对于这个漏洞，修复方法很简单，打开awstats.pl文件，找到如下信息：

if（$QueryString=~/configdir=（［^&］+）/i）

{

$DirConfig=&DecodeEncodedString（“$1”）;

}

修改为如下即可：

if（$QueryString=~/configdir=（［^&］+）/i）

{

$DirConfig=&DecodeEncodedString（“$1”）;

$DirConfig=~tr/a-z0-9_\-\/\。/a-z0-9_\-\/\。/cd;

}

6、揭开谜团

通过上面逐步分析和介绍，此服务遭受入侵的原因和过程已经非常清楚了，大致过程如下：

（1）攻击者通过Awstats脚本awstats.pl文件的漏洞进入了系统，在/var/tmp目录下创建了隐藏目录，然后将rootkit后门文件传到这个路径下。

（2）攻击者通过植入后门程序，获取了系统超级用户权限，进而控制了这台服务器，通过这台服务器向外发包。

（3）攻击者的IP地址62.17.163.186可能是通过代理过来的，也可能是攻击者控制的其他肉鸡服务器。

（4）攻击者为了永久控制这台机器，修改了系统默认帐号mail的信息，将mail帐号变为可登录，并且设置了mail帐号的密码。

（5）攻击者在完成攻击后，通过后门程序自动清理了系统访问日志，毁灭了证据。

通过对这个入侵过程的分析，发现入侵者的手段还是非常简单和普遍的，虽然入侵者删除了系统的一些日志，但是还是留下了很多可查的踪迹，其实还可以查看用户下的.bash_history文件，这个文件是用户操作命令的历史记录。

7、如何恢复网站

由于系统已经文件被更改和替换，此系统已经变得完全不可信，因此建议备份网站数据，重新安装系统，基本步骤如下：

（1）安装稳定版本的操作系统，删除系统默认的并且不需要的用户。

（2）系统登录方式改为公钥认证方式，避开密码认证的缺陷。

（3）安装更高版本的apache和最新稳定版本的Awstats程序。

（4）使用Linux下的Tcp_Wrappers防火墙，限制ssh登录的源地址。

上面就是Linux服务器被rootkit攻击后的处理方法，你要先对服务器进行分析，确实是否是rootkit攻击所致，然后再根据具体情况进行恢复。