下面两种方式统计nginx或者apache等http服务日志，所有URI接口的调用次数并显示出现次数最多的前十的URL，哪个更准确？
方法一：统计URI包括所有参数
cat /tmp/log |awk ‘{print $7}’ | sort | uniq -c | sort -nr |head -10
方法一：统计URI忽略所有参数
cat /tmp/log |awk ‘{split($7,b,”?”);COUNT[b[1]]++;}END{for(a in COUNT) print COUNT[a], a}’|sort -k1 -nr|head -10
其实是不通的统计方式
最近在折腾CDN缓存配置，就发现在伪静态环境下，缓存命中率还是非常低，一番折腾后发现如果源站的http头部包含一些不缓存的信息，那么CDN”也许“会相应的继承源站发出的HTTP状态。
通常喜欢用LNMP安装包的朋友会发现，在动态及伪静态的环境中，HTTP头部信息会包含Cache-Control: no-store,no-cache,must-revalidate,post-check=0,pre-check=0 和 Pragma: no-cache，就是这种状态影响了CDN对源站缓存的判断，proxy。
如何去掉Cache-Control及Pragma在http头部中的状态呢？
如果没有看到此文的话，你会非常痛苦的认为是网站程序本身所发出的状态，然后一番查找修改后发现依然无解，我理解这个过程，因为我就是这么干的。非常之痛苦。。。。
其实解决Cache-Control: no-store,no-cache.....和Pragma: no-cache很简单，只需修改php.ini中的session.cache_limiter参数，军哥lnmp默认值是nocache，只要修改为none即可解决这个HTTP状态中的缓存问题。耶！耶！耶！耶！耶~~~~~~~~~
老外vps无特别说明(即使用优惠码)都按优惠后的价格续费。此vps无爱可看之前其它文章 发现Out of Stock说明缺货中，可考虑购买其它VPS。自备谷歌浏览器有简单的翻译功能。
相关软件下载地址
Apache：http://httpd.apache.org/
Nginx：http://nginx.org/en/download.html
OpenSSL：http://www.openssl.org/
openssl-poc
附件说明
PoC.py : 漏洞利用测试PoC脚本
showssl.pl：OpenSSL动态库版本检测脚本
安装OpenSSL步骤
由于运营环境不同，以下过程仅供参考。openssl属于系统应用，被较多应用依赖，由于环境不同等因素，请先在测试环境进行充分测试。
从官方下载最新版本的opensssl库
wget https://www.openssl.org/source/openssl-1.0.1g.tar.gz
解压下载的openssl压缩包
tar -zxvf openssl-1.0.1g.tar.gz
进入解压后的openssl文件夹
cd openssl-1.0.1g
执行文件夹中的config文件，这里openssl的安装目录默认是/usr/local/ssl（由于系统环境差异路径可能不一致，下同），注意添加zlib-dynamic参数，使其编译成动态库
| 代码如下 | 复制代码 |
|
./config shared zlib-dynamic config完成后执行 make 命令 make make 命令执行完后再执行 make install 命令，安装openssl make install 重命名原来的openssl命令 mv /usr/bin/openssl /usr/bin/openssl.old 重命名原来的openssl目录 mv /usr/include/openssl /usr/include/openssl.old 将安装好的openssl 的openssl命令软连到/usr/bin/openssl ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl 将安装好的openssl 的openssl目录软连到/usr/include/openssl ln -s /usr/local/ssl/include/openssl /usr/include/openssl 修改系统自带的openssl库文件，如/usr/local/lib64/libssl.so(根据机器环境而定) 软链到升级后的libssl.so ln -s /usr/local/ssl/lib/libssl.so /usr/local/lib64/libssl.so 执行命令查看openssl依赖库版本是否为1.0.1g： strings /usr/local/lib64/libssl.so |grep OpenSSL 在/etc/ld.so.conf文件中写入openssl库文件的搜索路径 echo “/usr/local/ssl/lib” >> /etc/ld.so.conf 使修改后的/etc/ld.so.conf生效 |
|
ldconfig -v
查看现在openssl的版本是否是升级后的版本
openssl version
更新Webserver的 OpenSSL依赖库
如果webserver在安装编译时加载了openssl，还需对webserver进行重启或者重新编译操作。因webserver安装时分为动态编译和静态编译openssl两种方式，所以具体操作方式也不同。
判断webserver是否为动态编译ssl的两种方法
wget -c https://www.openssl.org/source/openssl-1.0.1s.tar.gz tar -zxvf openssl-1.0.1s.tar.gz cd openssl-1.0.1s ./config shared zlib-dynamic make && make install mv /usr/bin/openssl /usr/bin/openssl.old mv /usr/include/openssl /usr/include/openssl.old ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl ln -s /usr/local/ssl/include/openssl /usr/include/openssl ln -s /usr/local/ssl/lib/libssl.so /usr/local/lib64/libssl.so strings /usr/local/lib64/libssl.so |grep OpenSSL echo "/usr/local/ssl/lib" >> /etc/ld.so.conf ldconfig -v openssl version
通过ldd命令查看依赖库
查看编译参数
如输入以命令/usr/sbin/nginx -V，查看nginx的编译参数，参数中不存在–with-openssl则为动态编译ssl的，反之为静态：
更新OpenSSL库
a) 如果webserver是动态编译ssl安装的，直接重启apache，nginx等相应webserver服务即可。
b) 如果webserver是静态编译ssl安装的，可参照以下方法更新：
apache静态编译ssl的情况：
源码重新安装apache，使用ssl静态编译：
执行apache的configure文件时，除了业务需要的参数外，需要指定ssl为静态编译
| 代码如下 | 复制代码 |
|
./configure –enable-ssl=static –with-ssl=/usr/local/ssl (openssl的安装路径) |
|
安装apache
| 代码如下 | 复制代码 |
| make && make install | |
恢复原有apache配置，重启服务即可
nginx静态编译ssl的情况：
源码重新安装nginx，使用ssl静态编译：
执行nginx的configure文件时，除了业务需要的参数外，需要指定ssl为静态编译，编译参数带上–with-openssl便表明为静态编译ssl
| 代码如下 | 复制代码 |
|
./configure –with-http_ssl_module –with-openssl=/usr/local/ssl （openssl的安装路径） |
|
安装nginx
| 代码如下 | 复制代码 |
| make && make install | |
恢复原有nginx配置，重启服务即可
如有其他使用openssl的情况，参照apache和nginx的解决方式。
测试漏洞是否存在
使用附件PoC.py根据脚本提示检测是否存在漏洞。
如：
测试https://192.168.0.1漏洞是否存在执行命令如下
| 代码如下 | 复制代码 |
| python PoC.py -p 443,8443 192.168.0.1 | |
检测动态库libssl.so版本
检测当前进程使用的libssl.so版本
执行附件showssl.pl检查脚本，无信息输出或无漏洞版本openssl输出，表示升级成功；如输出中有unknown，请业务自查libssl.so.1.0.0的版本是否是受影响的版本。
（详情见附件）
| 代码如下 | 复制代码 |
|
#!/usr/bin/perl -w my @listInfo = `lsof |grep libssl|awk ‘{print $1″ “$2” “$NF}’|sort -u`; foreach my $info (@listInfo) { my ($procName, $procPid, $libPath) = split(/s/, $info); next if (!defined($procName) || !defined($procPid)|| !defined($libPath)); my $version = `strings $libPath|grep -E “^OpenSSL [0-9]+.[0-9]+”`; chomp $version; if ($version =~ /s*OpenSSLs*1.0.1[a-f]{0,2}/) { print “$procName($procPid) : $libPath ($version).n”; } } |
|
检测系统使用的libssl.so版本
执行命令：
| 代码如下 | 复制代码 |
| strings /usr/local/lib64/libssl.so |grep OpenSSL | |
查看openssl依赖库版本是否为1.0.1g
注：/usr/local/lib64/libssl.so 路径仅供参考，由具体机器环境决定，参考升级步骤
Git现在的版本（我在写下本文时）已经是1.7.12了，然而CentOS的Git的版本却是1.7.1，而且用yum安装的Git的最高版本也只是去1.7.1，当然，如果你在工作使用中没有遇到问题，使用这个版本当然没有什么问题，但是如果你在工作中遇到只有高版本的Git才能支持的任务时，如何升级我们的Git呢？事实上，GitHub和许多Git服务依赖的Git版本不低于1.7.2。下面就以CentOS-6.5为例来说明，如何升级我们的Git。
感谢WANdisco，是维持最新的颠覆版的RPM包。这篇文章将帮助您安装Subversion（SVN）1.8.15 CentOS / RHEL 7 / 6 / 5系统。如果要配置颠覆服务器访问本文。
Thanks to Wandisco, which is maintaining the rpm packages for latest Subversion version. This article will help you to Install Subversion 1.8.15 ( SVN Client ) on CentOS/RHEL 7/6/5 Systems. If you want to configure Subversion server visit this article.
首先，我们需要在我们的系统中配置yum仓库。创建一个新的回购文件/ etc / yum.repos.d/wandisco-svn.repo并添加以下内容按你的操作系统版本。
Firstly we need to configure yum repository in our system. Create a new repo file/etc/yum.repos.d/wandisco-svn.repo and add following content as per your operating system version.
[WandiscoSVN] name=Wandisco SVN Repo baseurl=http://opensource.wandisco.com/centos/$releasever/svn-1.8/RPMS/$basearch/ enabled=1 gpgcheck=0
Before installing latest package remove existing subversion packages from system to remove conflict.
在安装最新方案之前，从系统中删除现有的颠覆软件，以消除冲突。
# yum remove subversion*
Now install latest available Subversion package using yum command line package manager utility.现在安装新的颠覆包使用yum命令行软件包管理器。
# yum clean all # yum install subversion
At this stage you have successfully install Subversion client on your system. Lets use following command to verify version of svn client.在这个阶段，您已经成功地安装了系统的颠覆客户端。让我们用以下命令来验证SVN客户端版本。
#svn --version svn, version1.8.15 (r1718365) compiled Dec 11 2015, 14:28:48 on x86_64-redhat-linux-gnu Copyright (C) 2015 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.7 - handles 'http' scheme - handles 'https' scheme
References:
1. http://opensource.wandisco.com/
CentOS 6.6自带的是Python 2.6.6，而编译llvm需要Python 2.7以上，必须升级Python
checking for python... /usr/bin/python checking for python >= 2.7... not found configure: error: found python 2.6.6 (/usr/bin/python); required >= 2.7
yum中最新的也是Python 2.6.6，只能下载Python 2.7.9的源代码自己编译安装。
操作步骤如下：
1）安装devtoolset
yum groupinstall "Development tools"
2）安装编译Python需要的包包
yum install zlib-devel yum install bzip2-devel yum install openssl-devel yum install ncurses-devel yum install sqlite-devel
3）下载并解压Python 2.7.9的源代码
cd /opt wget --no-check-certificate https://www.python.org/ftp/python/2.7.9/Python-2.7.9.tar.xz tar xf Python-2.7.9.tar.xz cd Python-2.7.9
4）编译与安装Python 2.7.9
./configure --prefix=/usr/local make && make altinstall
5）将python命令指向Python 2.7.9
ln -s /usr/local/bin/python2.7 /usr/local/bin/python
6）检查Python版本
sh sh-4.1# python -V Python 2.7.9
不管你是做运维还是做开发，哪怕你是游客，时不时会遇到502 Bad Gateway或504 Gateway Time-out。出现这页面，把服务重启下，再实在不行重启下服务器，问题就解决了，但是，这问题还是会困扰着你，特别是做运维的人员。夜黑风高正酣睡时，一个电话响起，让你重启服务或IISRESET，肯定是极大不爽，立马要问候他妈了。呵呵，本文总结502与504故障分析与解决方法。
二. 状态码解释
502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
504 Gateway Time-out：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
三. 502 Bad Gateway原因分析
将请求提交给网关如php-fpm执行，但是由于某些原因没有执行完毕导致php-fpm进程终止执行。说到此，这个问题就很明了了，与网关服务如php-fpm的配置有关了。
php-fpm.conf配置文件中有两个参数就需要你考虑到，分别是max_children和request_terminate_timeout。
max_children最大子进程数，在高并发请求下，达到php-fpm最大响应数，后续的请求就会出现502错误的。可以通过netstat命令来查看当前连接数。
request_terminate_timeout设置单个请求的超时终止时间。还应该注意到php.ini中的max_execution_time参数。当请求终止时，也会出现502错误的。
当积累了大量的php请求，你重启php-fpm释放资源，但一两分钟不到，502又再次呈现，这是什么原因导致的呢？ 这时还应该考虑到数据库，查看下数据库进程是否有大量的locked进程，数据库死锁导致超时，前端终止了继续请求，但是SQL语句还在等待释放锁，这时就要重启数据库服务了或kill掉死锁SQL进程了。
对于长时间的请求可以考虑使用异步方式，可以参阅《关于PHP实现异步操作的研究》。
四. 504 Gateway Time-out原因分析
504错误一般是与nginx.conf配置有关了。主要与以下几个参数有关：fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout、fastcgi_buffer_size、fastcgi_buffers、fastcgi_busy_buffers_size、fastcgi_temp_file_write_size、fastcgi_intercept_errors。特别是前三个超时时间。如果fastcgi缓冲区太小会导致fastcgi进程被挂起从而演变为504错误。
五. 小结
总而言之，502错误主要从四个方向入手：
1. max_children
2. request_terminate_timeout、max_execution_time
3. 数据库
4. 网关服务是否启动如php-fpm
504错误主要查看nginx.conf关于网关如fastcgi的配置。
