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

CentOS, LinuxLeave a comment

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自动启动

CentOS, LinuxLeave a comment

由于在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)

CentOS, LinuxLeave a comment

守护进程(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的几种方式

Linux, NginxLeave a comment

我这边的服务器的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>

 

阿里云香港HKB简配benchmark

Benchmark, Leave a comment

新开一台服务器来做reverse proxy，正好先测一下benchmark

———————————————————————-
CPU model : Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz
Number of cores : 1
CPU frequency : 2494.136 MHz
Total size of Disk : 40.0 GB (1.7 GB Used)
Total amount of Mem : 991 MB (54 MB Used)
Total amount of Swap : 0 MB (0 MB Used)
System uptime : 0 days, 0 hour 4 min
Load average : 0.01, 0.04, 0.03
OS : CentOS 7.6.1810
Arch : x86_64 (64 Bit)
Kernel : 3.10.0-957.1.3.el7.x86_64
———————————————————————-
I/O speed(1st run) : 146 MB/s
I/O speed(2nd run) : 147 MB/s
I/O speed(3rd run) : 146 MB/s
Average I/O speed : 146.3 MB/s
———————————————————————-

Platinum 8163应该是intel定制的新的CPU. 这是阿里云第四代服务器采用的CPU，Skylake架构，主频2.5GHz，计算性能问题。8163这款型号在intel官网上并没有相关信息，应该是阿里云向阿里云定制的，与之相近的Intel Xeon Platinum 8168，价格是$5890，约合￥38900元。

此类服务器提供的ECS实例族包括通用型实例g5、计算型实例c5、内存型实例r5、本地 SSD 型实例 i2、突发性能实例 t5、超级计算集群计算型实例规格族 scc、通用型神龙云服务器规格族 ebmg5等。

 

阿里云平台的ecs服务器大多使用intel 至强处理器，而且大多是定制版，包括Platinum(铂金) 8163、Gold(金牌) 6150、Gold(金牌) 6149、E5-2682v4、E5-2680v3、E5-2667v4以及E3-1240v6等CPU。

 

wordpress 使用cloudflare flexible SSL

Linux, Misc, Leave a comment

这两天帮朋友做一个外贸站点，准备直接挂上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)

Debugging Nginx Configuration

NginxLeave a comment

By default, Nginx logs only standard errors to default Nginx error log file or a file specified by error_log directive in site-specific server configuration.

We can control many aspects about error logging which will help us debug our Nginx configuration.

Important: After any change to any Nginx configuration file, you must test and reload Nginx configuration for changes to take effect. On CentOS, you can simply run nginx -t && service nginx reload command.

更多

AWS Lightsail IO 大坑

Linux, NginxLeave a comment

这两天帮朋友的企业网站迁移到aws amazon lightsail， 选用的环境是军哥的LNMP，php 7.2 和mysql 5.7.22， 用的是2GB的 RAM版本

这个环境在linode上编译只需要67分钟左右，但是在lightsail上竟然需要106分钟。。十分不可思议。。用bench.sh bash script测试了一下才发现IO只有40多。。于此同时linode上的IO有400多。。

哎，lightsail 的IO 真是坑王啊。。如果不运行数据库，只是简单的nginx 还是非常不错的

01/25/2019 更新：

今天测了一个4vCPU 16GB的lightsail， I/O的平均速度到了130，还是马马虎虎可以接受的

———————————————————————-
CPU model : Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
Number of cores : 4
CPU frequency : 2400.035 MHz
Total size of Disk : 320.0 GB (0.9 GB Used)
Total amount of Mem : 15884 MB (162 MB Used)
Total amount of Swap : 0 MB (0 MB Used)
System uptime : 0 days, 0 hour 2 min
Load average : 0.18, 0.11, 0.05
OS : CentOS 7.5.1804
Arch : x86_64 (64 Bit)
Kernel : 3.10.0-862.3.2.el7.x86_64
———————————————————————-
I/O speed(1st run) : 134 MB/s
I/O speed(2nd run) : 131 MB/s
I/O speed(3rd run) : 125 MB/s
Average I/O speed : 130.0 MB/s