Category Archives: Linux

Linux, Network

linux下使用speedtest测速

Speedtest测试网络上传/下载速度还是挺不错的，windows下非常方便。Linux下也可以很方便的使用命令行speedtest来测试。speedtest是一个用Python编写的轻量级Linux命令行工具，在Python2.4至3.4版本下均可运行。它基于Speedtest.net的基础架构来测量网络的上/下行速率。安装speedtest很简单——只需要下载其Python脚本文件。以下步骤参考了linuxtoday的文章。

  1. wget https://raw.github.com/sivel/speedtest-cli/master/speedtest.py
  2. chmod a+rx speedtest.py
  3. mv speedtest.py /usr/local/bin/speedtest
  4. chown root:root /usr/local/bin/speedtest

执行以上几个命令就安装好了，然后运行的时候只要输入
speedtest

linux下使用speedtest测速

如上图所示，我拿搬瓦工洛杉矶测试了下速度，果然是G口的速度。如果你想分享测试结果，你可以使用参数“–share”。它将会把你的测试结果上传到Speedtest.net服务器并以图形的方式分享给其他人。

如果你对目前所有可用的Speedtest.net服务器感兴趣，你可以使用参数“–list”。它会打印出所有的Speedtest.net服务器（按照离你的地理距离由近及远排序）。

linux下使用speedtest测速

在上面的列表中，每一行前面都有一个与服务器对应的ID。如果想使用指定的节点来测试你的网速，你只需要在speedtest命令后指定其ID即可。例如，如果想使用上图中的QuadraNet服务器，你只需要指定相对应的服务器ID7456即可。

linux下使用speedtest测速

Linux, Nginx

Nginx日志增长过快详细分析

前言：

         Nginx日志里面Mobileweb_access.log增长特别大，一天上百兆，将近100W的访问记录，按照我们目前的规模，热点用户才500个左右，就算人人用手机app访问，怎么可能会有这么大的url访问量？以前只是安装使用nginx，还没有抽出时间仔细研究，这回需要彻底的去分析nginx日志了。

1，日志分类

主要2种，一种是错误日志，一种是访问日志，这些配置都在/usr/local/nginx/conf/nginx.conf里面，默认都是打开的，自己也可以选择关闭。

1.1，访问日志

访问日志主要记录每一个访问nginx的请求，格式可以自己定义，在nginx.conf文件里面，通过访问日志，你可以看到每一个请求的详细信息，对于访问日志的格式，主要是配置文件中的log_format来限制的。

1.1.1 log_format日志格式

$request_time：整个请求的总时间。

$time_iso8601：访问的时间与时区，比如18/Jul/2012:17:00:01 +0800，时间信息最后的”+0800″表示服务器所处时区位于UTC之后的8小时。

$upstream_response_time：请求过程中，upstream的响应时间。

$request_method：客户端请求的动作，通常为GET或POST。

$request_uri：是浏览器发过来的值。该值是rewrite后的值。例如做了internal redirects后。

$args：这个变量等于请求行中(GET请求)的参数，例如foo=123&bar=blahblah;

$query_string：与$args相同。

$proxy_add_x_forwarded_for：变量包含客户端请求头中的”X-Forwarded-For”，与$remote_addr用逗号分开，如果没有”X-Forwarded-For” 请求头，则$proxy_add_x_forwarded_for等于$remote_addr。

$upstream_addr：upstream的地址，即真正提供服务的主机地址。

$status：记录请求返回的http状态码，比如成功是200。

$http_user_agent：客户端浏览器信息

$http_range

$sent_http_content_length：发送内容的长度

$body_bytes_sent：发送给客户端的文件主体内容的大小，比如899，可以将日志每条记录中的这个值累加起来以粗略估计服务器吞吐量。

$http_referer：记录从哪个页面链接访问过来的。

$host：请求主机头字段，否则为服务器名称。

$http_x_forwarded_for：客户端的真实ip，通常web服务器放在反向代理的后面，这样就不能获取到客户的IP地址了，通过$remote_add拿到的IP地址是反向代理服务器的iP地址。反向代理服务器在转发请求的http头信息中，可以增加x_forwarded_for信息，用以记录原有客户端的IP地址和原来客户端的请求的服务器地址。

$http_user_agent：客户端浏览器信息

$body_bytes_sent：发送给客户端的文件主体内容的大小，比如899，可以将日志每条记录中的这个值累加起来以粗略估计服务器吞吐量。

$ssl_protocol：SSL协议版本，比如TLSv1。

$ssl_cipher：交换数据中的算法，比如RC4-SHA。

生产环境上的范例：

log_format  main  ‘$proxy_add_x_forwarded_for  $remote_user [$time_local] “$request” ‘

                      ‘$status $body_bytes_sent “$http_referer” ‘

                      ‘”$http_user_agent” “$http_x_forwarded_for” ‘

                      ‘upsteam: $upstream_addr’;

    access_log  logs/access.log  main;

    log_not_found off;

1.1.2，访问日志路径

access_log  logs/access.log  main;

Nginx支持为每个location指定强大的日志记录。同样的连接可以在同一时间输出到不止一个的日志中。如果想关闭日志，可以如下：

access_log off;

能够使用access_log指令的字段包括：http、server、location。

PS：Nginx进程设置的用户和组必须对日志路径有创建文件的权限，否则，会报错。

1.2，错误日志

错误日志主要记录客户端访问Nginx出错时的日志，格式不支持自定义。通过错误日志，你可以得到系统某个服务或server的性能瓶颈等。因此，将日志好好利用，你可以得到很多有价值的信息。错误日志由指令error_log来指定，具体格式如下：

error_log path(存放路径) level(日志等级)

        path含义同access_log，level表示日志等级，具体如下：

        [ debug | info | notice | warn | error | crit ]

    从左至右，日志详细程度逐级递减，即debug最详细，crit最少，举例说明如下：

        error_log  logs/mobileweb_error.log error;

    需要注意的是：error_log off并不能关闭错误日志，而是会将错误日志记录到一个文件名为off的文件中。正确的关闭错误日志记录功能的方法如下：

        error_log /dev/null;

    上面表示将存储日志的路径设置为“垃圾桶”。

2，为每一个工程定义特定的日志

location ~* ^/mobileWeb/.*$ {

           client_max_body_size 5m;

           include deny.conf;

           proxy_pass http://mobilewebbackend;

           include proxy.conf;

           error_log  logs/mobileweb_error.log error;

           access_log  logs/mobileweb_access.log  main;

           include gzip.conf;

}

这样，就会在日志路径/usr/local/nginx/logs/下面生成mobileWeb工程的专门日志mobileweb_error.log 以及mobileweb_access.log 日志，如果想查询mobileWeb工程的访问记录，就可以单独去查看这2个日志。

3，开始分析

根据来源ip进行分组统计分析，看看哪个ip的访问量最多

[root@wgq_idc_web_1_21 tmp]# cat mobileweb_access.log |grep “14/Oct/2014” |awk ‘{print $1}’|sort -nr |uniq -c |sort -nr |more

705980 1xx.xx.xx.185,

190273 6x.1×4.1xx.35,

14900 1xx.xxx.xx.xx3,

14670 1xx.xxx.x3.8x,

结果发现，这几个ip都是我们公司广场公用的wifi出口ip地址，属于安全地址，不是私人的IP地址，很大程度上排除了从外部恶意攻击我们网站的可能性。接下来就需要重点分析，为什么会有这么多的URL记录。

仔细排查来源为1xx.xx.xx.185的日志记录，发现有很多$http_user_agent为空的记录，大概90%的记录都是如此，看记录如下：

1xx.xx.xx.185, 10.2xx.xx1.xx0 – [10/Oct/2014:10:52:11 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “1xx.xx.xx.185″upsteam: 110.xx7.1.22:7100

猜测是否不是手机app访问的记录？只有自己停掉wifi，用手机的4G网络，去登录我们的移动app应用，操作完，点击了几下赞，访问了一些页面，操作时间2分钟，然后使用自己的移动4Gip地址“2xx.10x.5.129”去检索下nginx下的mobileweb的记录，4台nginx记录，每一台40个左右url访问，4台就是160个记录，下面是一台的记录

[root@wgq_idc_web_1_22 logs]# more mobileweb_access.log |grep “2xx.10x.5.129”

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:01 +0800] “POST /mobileWeb/userMobileCenter/queryUserNameAndIconByIds.htm? HTTP/1.1” 200 20 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:37 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:42 +0800] “POST /mobileWeb/square/query.htm? HTTP/1.1” 200 9485 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:42 +0800] “POST /mobileWeb/square/query.htm? HTTP/1.1” 200 9485 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:49 +0800] “POST /mobileWeb/square/clickSupport.htm? HTTP/1.1” 200 46 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:51 +0800] “POST /mobileWeb/square/clickSupport.htm? HTTP/1.1” 200 46 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:54 +0800] “POST /mobileWeb/square/clickSupport.htm? HTTP/1.1” 200 46 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:55 +0800] “POST /mobileWeb/square/query.htm? HTTP/1.1” 200 4831 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:54:57 +0800] “POST /mobileWeb/userMobileCenter/queryUserNameAndIconByIds.htm? HTTP/1.1” 200 20 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:03 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:04 +0800] “POST /mobileWeb/version/queryVersion.htm? HTTP/1.1” 200 160 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:06 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:06 +0800] “POST /mobileWeb/mobile/loadCart.htm? HTTP/1.1” 200 940 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:07 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:07 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:07 +0800] “POST /mobileWeb/userMobileCenter/findAllinterfaceVersion.htm? HTTP/1.1” 200 411 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:13 +0800] “POST /mobileWeb/userMobileCenter/unReadNumsMobile.htm? HTTP/1.1” 200 239 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:56 +0800] “POST /mobileWeb/userMobileCenter/queryUserNameAndIconByIds.htm? HTTP/1.1” 200 20 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:57 +0800] “POST /mobileWeb/userMobileCenter/findAllinterfaceVersion.htm? HTTP/1.1” 200 411 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:58 +0800] “POST /mobileWeb/userMobileCenter/unReadNumsMobile.htm? HTTP/1.1” 200 239 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:58 +0800] “POST /mobileWeb/version/queryVersion.htm? HTTP/1.1” 200 160 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:55:59 +0800] “POST /mobileWeb/userMobileCenter/unReadNumsMobile.htm? HTTP/1.1” 200 239 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:00 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:06 +0800] “POST /mobileWeb/userMobileCenter/findAllinterfaceVersion.htm? HTTP/1.1” 200 411 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:07 +0800] “POST /mobileWeb/userMobileCenter/unReadNumsMobile.htm? HTTP/1.1” 200 239 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:07 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:08 +0800] “POST /mobileWeb/version/queryVersion.htm? HTTP/1.1” 200 160 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:08 +0800] “POST /mobileWeb/userMobileCenter/unReadNumsMobile.htm? HTTP/1.1” 200 239 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:08 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:16 +0800] “POST /mobileWeb/userMobileCenter/queryUserNameAndIconByIds.htm? HTTP/1.1” 200 20 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:19 +0800] “POST /mobileWeb/userMobileCenter/findAllinterfaceVersion.htm? HTTP/1.1” 200 411 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:21 +0800] “POST /mobileWeb/userMobileCenter/unReadNumsMobile.htm? HTTP/1.1” 200 239 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:21 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:23 +0800] “POST /mobileWeb/userMobileCenter/queryUserNameAndIconByIds.htm? HTTP/1.1” 200 20 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:23 +0800] “POST /mobileWeb/userMobileCenter/findAllinterfaceVersion.htm? HTTP/1.1” 200 411 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:24 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:24 +0800] “POST /mobileWeb/userMobileCenter/queryAdvertisement.htm? HTTP/1.1” 200 5175 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:24 +0800] “POST /mobileWeb/version/queryVersion.htm? HTTP/1.1” 200 160 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:25 +0800] “POST /mobileWeb/userMobileCenter/unReadNumsMobile.htm? HTTP/1.1” 200 239 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:56:25 +0800] “POST /mobileWeb/mobile/getCartItemNum.htm? HTTP/1.1” 200 114 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:14:57:37 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:00:37 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:02:07 +0800] “POST /mobileWeb/userMobileCenter/messageListMobile.htm? HTTP/1.1” 200 106 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:02:08 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:02:37 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:05:07 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:05:08 +0800] “POST /mobileWeb/push/query.htm? HTTP/1.1” 200 97 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:05:37 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.21:7100

2xx.10x.5.129, 10.2xx.xx1.xx0 – [16/Oct/2014:15:11:44 +0800] “POST /mobileWeb/square/queryCounts.htm? HTTP/1.1” 200 82 “-” “-” “2xx.10x.5.129″upsteam: 110.xx7.1.22:7100

[root@wgq_idc_web_1_22 logs]#

看到了我的访问url记录，其中$http_user_agent几乎都是为”-”空记录，奇怪，我也是用手机访问的，询问andriod开发人员，他说有些低版本的手机在记录$http_user_agent后退回去会报错返回空界面，所以后来就不记录$http_user_agent信息了。

原来如此，而且看到这么多url全是我访问过的，移动mobileweb后台开发人员说，移动app一个页面里面有许多url需要加载，所以你访问1个页面就会加载N个link连接去取各种数据值。分析道这里，已经差不多明了：就是一个登录用户访问页面，会加载N（N>10）个link连接url，这些url都被记录在nginx访问日志里面，短短2分钟内，我访问了一些页面，就有160个左右的记录，照这么算下来，一个小时就是5000个左右的记录，一天平均25分钟分钟，500个用户个就是SELECT 5000*25/60*500=1041667，差不多100W左右了，通常来说nginx日志的量比较大是正常的。

           其中，半夜1点到6点左右，这个公司广场wifi的ip地址还会不停的访问mobileweb，经过分析是由于登录了移动app应用，但是睡觉了没有退出应用，手机也没有关系，所以导致移动app依然不停的在访问mobile应用（因为1分钟左右会刷新一次去获取访问当前登录用户的站内互动消息）。

      从此可以看出nginx的访问日志记录了用户的所有访问行为记录，而且详细到每一个页面里内嵌的url记录，如果用适当的工具仔细分析nginx日志，就会大概摸清楚用户的访问习惯，这些数据对于市场部门、产品部门来说，是非常有价值的。

Apache, Linux

【CentOS 6】透過 SCL 將 Apache(httpd) 升級到 2.4 版

參考資料 —-
軟件選集（SCL）軟件庫
義守大學檔案伺服器
Using Apache httpd 2.4 on Red Hat Enterprise Linux 6

RHEL/CentOS 的慣例是主版本發行後，接下來就進入維護狀態，只做 bug fix / 次版本 的更新。

例如：
CentOS 6.x 的 Apache 是 2.2 版，即使現在最新的 CentOS 6.7，Apache 是 2.2.15-47。

但 Apache 2.2 被發現有安全性漏洞(CVE-2012-0053)，必須要升級到 2.2.22 以上的版本，這怎麼辦呢? 尤其對企業而言，不可能任意地就將主機 從 CentOS 6.x 升級到 CentOS 7.x。

所幸 CentOS 推出了 SCL (RHEL 則為 RHSCL) 彌補了上述的缺憾。

centos-release-scl 歸類在 extras section，所以如果原本您有將

[extras]
enabled=0

則需

[extras]
enabled=1

[root]# yum  install  centos-release-scl

yum 會連帶安裝 centos-release-scl-rh

為了跟正式版本區隔，Apache 2.4 的程式名稱為 httpd24

[root]# yum  install  httpd24

您也可以上義守大學 FTP server 看看有哪些新版本的套件。

安裝完成後，要啟動 httpd24 的指令為

［root］＃ service  httpd24－httpd  start

設為開機啟動

[root]# chkconfig  httpd24-httpd  on

大多數人都會 Apache 搭配 PHP 使用，因為 CentOS 6 內建的 PHP 相依於 Apache 2.2，所以您移除 httpd2.2 時會一併移除 PHP。

要改用 Apache 2.4，則要搭配 PHP 5.5

[root]# yum  install  php55

注意 Apache 2.4 的 config 設定檔在 /opt/rh/httpd24/root/etc/httpd/conf/

Linux

yum安裝php錯誤缺少libmcrypt.so.4

[root@localhost ~]# yum install php56w-mcrypt

Loaded plugins: fastestmirror, replace, security

Setting up Install Process

Loading mirror speeds from cached hostfile

* base: ftp.tc.edu.tw

* extras: ftp.tc.edu.tw

* updates: ftp.tc.edu.tw

* webtatic: sp.repo.webtatic.com

Resolving Dependencies

–> Running transaction check

—> Package php56w-mcrypt.x86_64 0:5.6.32-1.w6 will be installed

–> Processing Dependency: libmcrypt.so.4()(64bit) for package: php56w-mcrypt-5.6.32-1.w6.x86_64

–> Finished Dependency Resolution

Error: Package: php56w-mcrypt-5.6.32-1.w6.x86_64 (webtatic)

           Requires: libmcrypt.so.4()(64bit)

You could try using –skip-broken to work around the problem

You could try running: rpm -Va –nofiles –nodigest

 

 

 

Resolve :

 

#rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm

#rpm -Uvh https://mirror.webtatic.com/yum/el6/latest.rpm

#yum clean

 

#yum install php56w-mcrypt

 

Dependencies Resolved

===================================================================================================================

Package                       Arch                   Version                       Repository                Size

===================================================================================================================

Installing:

php56w-mcrypt                 x86_64                 5.6.32-1.w6                   webtatic                  26 k

Installing for dependencies:

libmcrypt                     x86_64                 2.5.8-9.el6                   epel                      96 k

Transaction Summary

===================================================================================================================

Install       2 Package(s)

 

 

Installed:

  php56w-mcrypt.x86_64 0:5.6.32-1.w6                                                                               

Dependency Installed:

  libmcrypt.x86_64 0:2.5.8-9.el6 

Linux

Linux TCP/IP Settings 解決TIME_WAIT過多問題

查看Apache的並發請求數及其TCP連接狀態：
Linux命令：
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
返回結果示例：
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
CLOSING 33
TIME_WAIT 1057
說明:
SYN_RECV表示正在等待處理的請求數；
ESTABLISHED表示正常數據傳輸狀態；
TIME_WAIT表示處理完畢，等待超時結束的請求數。

檢查net.ipv4.tcp_tw當前值，將當前的值更改為1分鐘：
[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
[root@aaa1 ~]#

vi /etc/sysctl
增加或修改net.ipv4.tcp_tw值：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

使內核參數生效：
[root@aaa1 ~]# sysctl -p

[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

用netstat再觀察正常

這裡解決問題的關鍵是如何能夠重複利用time_wait的值，我們可以設置時檢查一下time和wait的值
#sysctl -a | grep time | grep wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

打開tcp的連接復用:
sysctl -w net.ipv4.tcp_tw_reuse=1#打開復用
sysctl -w net.ipv4.tcp_tw_recycle=10#表示復用10次
或者:
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 10 > /proc/sys/net/ipv4/tcp_tw_recycle

通過此方法，可以強制減少TCP的：time_wait連接，至於副作用，我還沒發現:-)

引用:

Tomcat,Apache,Jboss,有大量 CLOSE_WAIT 怎麼辨?

在 Linux 上 用netstat 統計資料如下
[root@temp]# netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
LAST_ACK 3
SYN_RECV 10
CLOSE_WAIT 655
ESTABLISHED 200

***************************************************************************
大量 CLOSE_WAIT 的影響:
大量的CLOSE_WAIT連接，直接佔滿TCP隊列，導致Apache,Tomcat,Jboss…失去回應,
CPU 使用量 快速提高

***************************************************************************

CLOSE_WAIT狀態的生成原因

如果是CLIENT端主動斷掉當前連接的話，那麼雙方關閉這個TCP連接共需要四個packet：

Client —> FIN —> Server

Client <— ACK <— Server

這時候Client端處於FIN_WAIT_2狀態；而Server 程序處於CLOSE_WAIT狀態。

Client <— FIN <— Server

這時Server 發送FIN給Client，Server 就成為LAST_ACK狀態。

Client —> ACK —> Server

Client回應了ACK，那麼Server 才會成為CLOSED狀態。

******************************************************************************
解決方法:
1.(暫時生效,重新啓動 linux 後,會還原成預設值)
sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.ipv4.tcp_keepalive_time=1800
sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_keepalive_intvl=2

2.(永久生效)
vi /etc/sysctl.conf
# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 30
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800
# 探測次數
net.ipv4.tcp_keepalive_probes=2
# 探測間隔秒數
net.ipv4.tcp_keepalive_intvl=2

編輯完 /etc/sysctl.conf,要重啓network 才會生效
[root@temp /]# /etc/rc.d/init.d/network restart
**********************************************************************************
PS: 發生CLOSE_WAIT 的原因,可能在於程式內 一端的Socket使用close後，另一端的Socket沒有使用close.檢查一下代碼內是否有 Server端在某些異常情況時，沒有關閉Socket，將之修改,應可改正此一問題

Linux, Network

使用 shell script 刪除 cloudflare 上的快取

1.先取得 domain name 的 ID

curl -X GET "https://api.cloudflare.com/client/v4/zones?name=網址" \
# -H "X-Auth-Email: test@gmail.com" \
# -H "X-Auth-Key: 7b9fb4xxxxxxxxxxxxxxxxxxxxxxxxxx" \
# -H "Content-Type: application/json" \

X-Auth-Email: 使用帳號
X-Auth-Key: API KEY 在 My settings 裡面可以查看

2.執行後會取得一連串的 json 字串、可以用線上 JSON檢視工具 直接看

3.取得後寫成shell script執行就好了

curl -X DELETE "https://api.cloudflare.com/client/v4/zones/e74b73xxxxxxxxxxxxxxxxxxxxxxxxxx/purge_cache" \
-H "X-Auth-Email: test@gmail.com" \
-H "X-Auth-Key: 7b9fb4xxxxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
--data '{"purge_everything":true}'

Linux

linux error . : backlog limit exceeded

此文完整連結 http://n.zipko.info/601.html
文章歡迎轉載，請尊重版權註明連結來源。
linux 的 audit 服務

Linux 的 audit (in Redhat, Suse) 服務是什麼？以前我也不會去注意，直到有一天系統 crash，不知道為什麼，打開 Monitor，只出現一堆這樣的訊息：

audit: audit_backlog=326 > audit_backlog_limit=320
audit: audit_lost=39095317 audit_rate_limit=0 audit_backlog_limit=320
audit: backlog limit exceeded

這也許不是 crash 的主因，不過先解決吧，下面是 FedoraForum 的建議：

It means that you are getting flooded with audit events. You can increase the audit daemon’s priority to make sure it has enough run time to empty its
queue or lengthen the backlog.

才引起我的注意，因此來研究一下 audit。

1. 什麼是 audit ？

Linux 系統中已經 syslog 了，syslog 會記錄系統狀態、如硬體的警告或應用軟體的記錄等。但是syslog屬於應用層，且僅只於此一應用而已，沒辦法記錄太多資訊。因此，audit 誕生以取代 syslog 的責任，來記錄核心層的事件：檔案的讀寫、系統呼叫、權限的狀態等。

2. 來看看 audit 運作的流程(圖片取自參考資料4)

Audit Daemon 運作和一般的daemon 一樣，運作後會引入selinux的系統。

3. audit 有三個操作的工具

audit 可用的三個指令：

=> auditctl – 控制 kernel audit system，能取得狀態，增或刪除rules、設定某個檔案的「檢視」(watch)。

=> ausearch – 用來查詢 audit logs 的工具。

=> aureport – 產生 audit 系統簡報的工具。

4. 設定檔

audit 的設定檔為 /etc/audit/audit.rules，主要分為三種類別：

• Basic audit system parameters
• File and directory watches
• System call audits

# basic audit system parameters
-D    (刪除舊記錄，預設-D)
-b 8192  (buffer大小，預設256，改為8192)
-f 1  (失敗控制旗標，可設為 0 (silent), 1 (印出錯誤，預設), and 2 (panic, 把系統關閉—非正常關閉，所以會有資料遺失的風險).
-e 1 (生失效，0為失效，1為生效(預設)
# some file and directory watches
-w /var/log/audit/   (觀查目錄 /var/log/audit/)
-w /etc/auditd.conf -p rxwa    (觀查檔案 /etc/auditd.conf，-p 設定權限為rxw及a屬性變更)
-w /etc/audit.rules -p rxwa
-w /etc/passwd -p rwxa
-w /etc/sysconfig/
# an example system call rule
-a entry,always -S umask

對於設定檔有幾點要說明：
• 目錄觀察的詳細度比檔案觀察低
• 無法使用任何的pathname globbing，如?或*
• 只能設定已存在的檔案，若設定觀察目錄而有新增檔案，新檔案只會在下次 audit 重啟後才會加入

利用 -k 產生 key string，以供ausearch 直接索引
-w /etc/var/log/audit/ -k LOG_audit

5. 操作實務

重啟 auditd
# service auditd restart

更新 auditd
# yum update audit

檢查檔案及系統的更動狀態
# aureport –start today –event –summary -i

查詢單一檔案
# ausearch -f filename

利用 -ts 指定日期 -k 指定 key string，其中password-file 使用 auditctl -k 來產生。
# ausearch -ts today -k password-file
# ausearch -ts 3/12/07 -k password-file

-ui 來指定 user name (UID)，例如找出  (uid 506) 的操作
# ausearch -ts today -k password-file -x rm -ui 506
# ausearch -k password-file -ui 506

[參考資料]

1. FedoraForum.org http://forums.fedoraforum.org/showthread.php?t=213680

2. 檢查誰修改檔的動作 http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html

3. Linux Audit Quick Start SUSE Linux Enterprise 10 SP1 http://www.novell.com/documentation/sled10/pdfdoc/auditqs_sp2/auditqs_sp2.pdf

4. The Linux Audit Subsystem Deep Dive http://linuxvm.org/present/SHARE113/S9203sw.pdf

 

http://note-end.zipko.info/601.html