Debian 9 开启 BBR

Debian 9 和 10 的内核自带了google 开发的 BBR 拥塞算法,我们可以很方便的开启BBR 进行访问加速

开启方法:

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

如果执行之后没有报错,重启一下系统就可以让配置生效.

重启之后,执行如下命令查看内核是否已开启BBR:

sysctl net.ipv4.tcp_available_congestion_control

显示以下即已开启:

root@localhost:~# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = bbr cubic reno

查看BBR是否启动:

lsmod | grep bbr

显示以下即启动成功:

root@localhost:~# lsmod | grep bbr
tcp_bbr 16384 14

 

nginx 和 cgi, fcgi 以及php-cgi, php-fpm

在apache 称雄的时代,经常会看到cgi,但是随着nginx 的出现以及时代的进步, cgi 的程序越来越少了.

最近有需求安装smokeping,因此cgi 又被拿了出来

CGI是common gateway interface的缩写,大家都译作通用网关接口,但很不幸,我们无法见名知意。

我们知道,web服务器所处理的内容都是静态的,要想处理动态内容,需要依赖于web应用程序,如php、jsp、python、perl等。但是web server如何将动态的请求传递给这些应用程序?它所依赖的就是cgi协议。没错,是协议,也就是web server和web应用程序交流时的规范。换句话说,通过cgi协议,再结合已搭建好的web应用程序,就可以让web server也能”处理”动态请求(或者说,当用户访问某个特定资源时,可以触发执行某个web应用程序来实现特定功能),你肯定知道处理两字为什么要加上双引号。CGI可以是任何的可执行程序,可以是Shell脚本,二进制应用,或者其他的脚本(Python脚本,Ruby脚本等)

简单的cgi工作方式如下:

有多种方式可以执行cgi程序,但对http的请求方法来说,只有get和post两种方法允许执行cgi脚本。实际上post方法的内部本质还是get方法,只不过在发送http请求时,get和post方法对url中的参数处理方式不一样而已。

任何一种语言都能编写CGI,只不过有些语言比较擅长,有些语言则非常繁琐,例如用bash shell开发,那么需要用echo等打印语句将执行结果放在巨多无比的html的标签中输出给客户端。常用于编写CGI的语言有perl、php、python等,java也一样能写,但java的servlet完全能实现CGI的功能,且更优化、更利于开发

总体上来说,CGI(common gateway interface) 就是所谓的短生存应用程序,Fast CGI 就是所谓的长生存应用程序. FastCGI 像是一个常驻 long-live 型的CGI, 它可以一直执行者,不会每次都要话费时间去fork一次

CGI 和 fastcgi 有自己输入和输出标准,比如HTTP头部, CGI环境变量,get和post等等

CGI, Fast-CGI 是protocols, CGI 慢点, Fast-CGI 要快很多

CGI程序能够用 Python, PERL, Shell, C or C++等语言来实现,尽管没有明确的规定,但是一般用C写的cgi,我们会用.cgi作为后缀,用perl 的用.pl作为后缀,其实我们都可以用.cgi作为后缀. Perl由于其跨操作系统、易于修改的特性成为了CGI的主流编写语言,以至于一般的“cgi程序”就是Perl程序

nginx + fastcgi: nginx只能处理静态文件,对于动态文件,一般用fastcgi 来作为“沟通”的协议. fastcgi 进程由fastcgi 进程管理器管理,而不是nginx,这样就需要一个fastcgi 管理器,这里可以使用spawn-fcgi 作为fastcgi 的进程管理器

nginx + cgi: nginx 不能直接执行外部可执行程序,因此nginx天生不支持cgi的, nginx 虽然不支持cgi,但是他“支持”fastCGI, 这样我们可以fastcgi 来wrap 一下cgi,这样变相的支持cgi,常见的fastcgi wrapper 有fcgiwrap

另外其实cgi 程序也可以被当成fastCGI,因此也可以用nginx + spawn-fcgi 来执行cgi

Spawn-FCGI是一个通用的FastCGI管理服务器,它是lighttpd中的一部份,很多人都用Lighttpd的Spawn-FCGI进行FastCGI模式下的管理工作,不过有不少缺点。而PHP-FPM的出现多少缓解了一些问题

fastcgi 是一个协议, php-fpm 实现了这个协议

通过webserver 来运行php, 一般有两种方式,一个是php-cgi, 另外一个php-fpm (php FastCGI Process Manager) (apache 的mod_php, 把php当作一个模块来执行,以及cli 和 isapi 不在考虑范围之内, php总共来说有5种执行模式)

php-fpm 比传统的CGI方式 (suPHP) 要快,

php-cgi是php自带的fastcgi进程管理器,php-cgi变更php.ini配置后需重启php-cgi才能让新的php-ini生效,不可以平滑重启。另外直接杀死php-cgi进程,php就不能运行了,但是php-fpm和 spawn-fcgi就没有此类问题

php-fpm 就是一个支持php 解析的 fastcgi进程管理器,只能适用于php,其余语言写的cgi,例如perl,python,C,都不能使用

mod_php 和 php-fpm 是运行php 的两种方式,mod_php 是running php as apache module

在segmentfault上看到了一个文章,写的很不错https://segmentfault.com/q/1010000000256516

你(PHP)去和爱斯基摩人(web服务器,如 Apache、Nginx)谈生意

你说中文(PHP代码),他说爱斯基摩语(C代码),互相听不懂,怎么办?那就都把各自说的话转换成英语(FastCGI 协议)吧。

怎么转换呢?你就要使用一个翻译机(PHP-FPM)
(当然对方也有一个翻译机,那个是他自带的)

我们这个翻译机是最新型的,老式的那个(PHP-CGI)被淘汰了。不过它(PHP-FPM)只有年轻人(Linux系统)会用,老头子们(Windows系统)不会摆弄它,只好继续用老式的那个。

CentOS 7 Nginx 默认配置

在centos 7 下,用nginx official repo安装的nginx stable版本的config 默认配置如下:

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;


events {
worker_connections 1024;
}


http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;
#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;
}

但是很明显, 这个配置过于简单了,结合军哥的LNMP,我们可以稍微改动一下config:

user nginx;

worker_processes auto;
worker_cpu_affinity auto;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

#Specifies the value for maximum file descriptors that can be opened by this process.
worker_rlimit_nofile 51200;

events {
use epoll;
worker_connections 51200;
multi_accept off;
accept_mutex off;
}


http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 50m;

sendfile on;
sendfile_max_chunk 512k;
tcp_nopush on;

keepalive_timeout 60;

tcp_nodelay on;


gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 2;
gzip_types text/plain application/javascript application/x-javascript text/javascript text/css application/xml application/xml+rss;
gzip_vary on;
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6]\.";

#limit_conn_zone $binary_remote_addr zone=perip:10m;
##If enable limit_conn_zone,add "limit_conn perip 10;" to server section.


server_tokens off;
access_log off;

server {

listen 80 default_server;
server_name _;
index index.html index.htm index.php;
root /usr/share/nginx/html;


}


include /etc/nginx/conf.d/*.conf;
}

在CentOS7上,nginx的启动是有systemd 来管理的,位置在/usr/lib/systemd/system/nginx.service

配置文件为:

[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/var/run/nginx.pid
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID

[Install]
WantedBy=multi-user.target

简单的把SysV init转变成SystemD启动

Github上看到的,对于大部分的init script可以这么用,但是其实还是不太准确

Let’s say you have a SysV Init Script named foo

Copy the file to /etc/init.d/foo

Enable the SysV service: chkconfig --add foo

Enable the SysV service: chkconfig foo on

Start the service: service foo start. After this, systemd-sysv-generator will generate this file /run/systemd/generator.late/foo.service, copy this file to /etc/systemd/system by running: cp /run/systemd/generator.late/foo.service /etc/systemd/system/foo.service

Edit /etc/systemd/system/foo.service by running systemctl edit foo.service, add in the following line to foo.servie (this makes the service installable)

[Install] WantedBy=multi-user.target 

Enable the service: systemd enable foo.service

(Optional) You can then remove the SysV script by running

 foo off && chkconfig --del foo

Centos7设置smokeping自动启动

由于在centos7以及RHEL中,系统的启动已经由centos6的SysV变成了SystemD了,虽然原来的init的形式还是可以用的,但是最新的systemd的配置还是比较方便的.

这里我收集了centos7,debian9,ubuntu18.04以及fedora的默认自动启动配置文件

https://github.com/hippoking/public/tree/master/smokeping_init

其中ubuntu和debian还在继续使用老旧的init的方式进行自动启动,centos7和fedora28已经采用最新的systemd的方式了,但是没想到这里面有一个很大的bug,从Fedora17开始就有。。28了还没有修复

在fedora28中,典型的smokeping.service的配置是:

[Unit]
Description=Latency Logging and Graphing System
After=syslog.target network-online.target

[Service]
ExecStart=/usr/sbin/smokeping --nodaemon
ExecReload=/bin/kill -HUP $MAINPID
StandardError=syslog

[Install]
WantedBy=multi-user.target

问题就出现在–nodaemon上。

如果使用了–nodaemon,smokeping就不会以守护进程启动,这样在使用systemctl查看status的时候,会发现smokeping在不断重启或者状态显示不正确

在如下两篇文章中发现了同样的问题:

https://forums.fedoraforum.org/showthread.php?286002-smokeping-2-6-on-fedora-17

https://github.com/oetiker/SmokePing/issues/44

正确的做法是设置smokeping 为守护程序,去掉–nodaemon即可

 

Linux 守护进程(Daemon)

守护进程(daemon)是一类在后台运行的特殊进程,用于执行特定的系统任务。很多守护进程在系统引导的时候启动,并且一直运行直到系统关闭。另一些只在需要的时候才启动,完成任务后就自动结束。

首先,守护进程最重要的特性是后台运行。其次,守护进程必须与其运行前的环境隔离开来。这些环境包括未关闭的文件描述符、控制终端、会话和进程组、工作目录以及文件创建掩码等。这些环境通常是守护进程从执行它的父进程(特别是shell)继承下来的。最后,守护进程的启动方式有其特殊之处。它可以在Linux系统启动时从启动脚本/etc/rc.d中启动,也可以由作业控制进程crond启动,还可以由用户终端(通常是shell)执行。

除这些,守护进程与普通进程基本上没有什么区别。因此,编写守护进样实际上是把一个普通进程按照上述的守护进程的特性改造成为守护进程

按照服务类型分为如下几个。

系统守护进程:syslogd、login、crond、at等。
网络守护进程:sendmail、httpd、xinetd、等。
独立启动的守护进程:httpd、named、xinetd等。
被动守护进程(由xinetd启动):telnet、finger、ktalk等

在正常条件下,我们将程序运行产生的信息打印到控制台实时显示,如果我们想讲一个程序以守护进程的方式进行运行,就需要改变信息的输出方向,将其导向到配置文件里设置的日志文件。

  将一个进程转换为守护进程需要进行几个步骤:

 1) 调用fork( )。
2) 在父进程中,调用exit( )。
3) 调用setsid( ),给守护进程一个新的进程组和会话。
4) 通过将工作目录更改为根目录chdir( )。这是因为继承的工作目录可以位于文件系统的任何位置。守护进程倾向于在系统正常运行时间内运行,并且你不希望保持某个随机目录处于打开状态,从而阻止管理员卸载包含该目录的文件系统。
5) 关闭所有文件描述符。
6) 打开文件描述符0,1和2(标准输入,标准输出和标准错误)并将它们重定向到/dev/null。

apache2.4 运行cgi的几种方式

我这边的服务器的web server基本上都是nginx的,但是今天在配置smokeping的时候,发现还得是使用apache做为后端来跑cgi,nginx对于cgi以及fastcgi的支持不是太好,google了一整天才发现原来apache的官方文档才是最好的资料. 本文以下内容均以apache2.4 为标准

如果我们想让apache来运行cgi程序,我们首先需要配置apache来允许cgi 程序. 主要有以下几种方式:

首先我们需要注意的是,无论是以哪种方式运行,我们都需要保证在http.conf中,LoadModule命令中要有cgi或者fcgi的模块:

LoadModule cgid_module modules/mod_cgid.so

or

LoadModule fcgid_module modules/mod_fcgid.so

因为fastcgi要比cgi要快很多,因此建议这里都使用fastcgi的module

在通过yum安装完apache 以后,我们可以直接用

yum install mod_fcgid

来安装apache fastcgi module

方式一: ScriptAlias

ScriptAlias 告诉apache有一个目录被专门设定来跑cgi程序, apache也会因此默认这个目录里面都是cgi程序,进而用cgi的handler来执行

ScriptAlias 命令:

ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/"

这里需要注意的是, ScriptAlias和Alias不同, ScriptAlias被专门用cgi程序的alias, Alias则是普通意义上的一个目录的map命令

方式二: CGI outside of ScriptAlias directories

我们经常会遇到把cgi程序放在/cgi-bin/外面的情况,我们只需要两步就可以完成这个任务: 1)  用AddHandler或者SetHandler 来设置cgi-script的handler 2) 在Options命令中,必须指定ExecCGI

以下是用options的方式来设定CGI运行:

<Directory "/usr/local/apache2/htdocs/somedir">
Options +ExecCGI

AddHanlder  cgi-script .cgi
</Directory>

以上命令告诉apache 在这个目录下,以.cgi结尾的都是cgi文件

当然了,如果你没有编辑httpd.conf的权利,也是可以在.htaccess中设定的

另外你可以设定某个目录下都是cgi文件,可以使用下面的配置方式:

<Directory "/home/*/public_html/cgi-bin">
Options ExecCGI
SetHandler cgi-script
</Directory>

 

wordpress 使用cloudflare flexible SSL

这两天帮朋友做一个外贸站点,准备直接挂上cloudflare flexible SSL 就完事了

可是事情没有想象的那么简单,在站点使用普通的http的情况下,在外面加一层cloudflare flexible的情况下,会造成wordpress的 infinite loop.

这是因为虽然用户是用的ssl 来进行访问的,但是cloudflare 会用http 来和后端进行通话,但是后端,也就是wordpress 所在的服务器,已经强制使用SSL 了,这样就会造成http 和 https的不断跳转,以至于造成infinite loop

网上虽然有很多的解决办法,但是最好的办法,还是用cloudflare 来获取一个免费的有cloudflare签名的original certificate,并且把这个ca和key 传到你的wordpress服务器上并且打开443端口,就解决了这个问题

需要注意的一个问题,这个免费的original certificate,只有cloudflare 承认,也就是说这个ssl 只有在你把website 放在 cloudflare后面,并且打开FULL SSL 或者FULL(strict) SSL (推荐)的时候才有用

直接使用这个SSL,会被浏览器显示错误, untrusted CA

最后需要注意的是,一旦在wordpress的后台开启https, 那么cloudflare的 SSL的选项中必须要选择Full 或者 Full(strict)