简单的把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)

AWS Lightsail IO 大坑

这两天帮朋友的企业网站迁移到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

Centos7 一张网卡上添加多个IP

centos 7 出来了这么长的时间了,应该很稳定了,是时候把服务器们的系统升级到centos7了. 我现在都有点不太乐意用centos6了

但是在centos7 中,添加多个IP以及IP range的办法与centos 6 有了很大的不同. 我今天搜索了半天,才找到一个行之有效的解决办法.

首先,在centos 7中,添加IP段,已经不能用ifcfg-eth-range0之类的方式了,你会发现这样使用根本添加不上IP.  

Centos7已经把networking的设置完全交给了NetworkManager,也就是nmcli和nmtui的方式。顾名思义,nmcli是 command line,nmcli 是 GUI。但是作为从centos5就开始用ifcfg的人来说,更喜欢ifcfg的方式.

幸好centos7 仍然保留了ifcfg (interface configure)的方式,但是所有的IP都要写入ifcfg-ethx当中.

更多

Xenserver 安装CentOS7 的坑以及安装LNMP的问题

一直在通过xenserver来安装centos6,可是centos6 确实够老了,安装mysql 5.7,其实在编译的时候总会出现各种warning,尤其是使用boost了以后,geometry这里出现的warning更多,但是用centos 7自带的gcc 4.8.5编译就没有这种问题,这让有强迫症的我感觉很不爽,于是心里盘算着在xenserver上安装centos7.

出现的问题,在xenserver 6.5以上安装centos7,配置好以后,在启动的时候就会黑屏,这个应该是xencenter的驱动问题,一个简单的解决办法就是关闭xencenter,然后重新打开xencenter,连上这个server,在打开console,就看到安装画面了。另外一个解决办法就是在启动的时候,选择“install centos 7”,然后按tab来编辑启动选项,可以在启动选项的最后面加上 inst.vnc,这个就会启动VNC服务,我们就可以使用各种VNC的客户端连上来安装centos 7 了. 同理我们也可以使用text模式来装centos 7,只需要在启动选项后面加上text就可以了

在使用netinstallation的时候,我们可以使用下面的URL:

http://mirror.centos.org/centos/7/os/x86_64/

http://repos.lax.quadranet.com/centos/7/os/x86_64/

http://mirror.sfo12.us.leaseweb.net/centos/7/os/x86_64/

http://mirrors.oit.uci.edu/centos/7/os/x86_64/

安装好centos 7以后,对我个人而言,简单省事就是安装军哥的LNMP,但是centos7 有另外一个坑,标准的netinstallation里面没有bzip2,我们需要使用下面命令来安装bzip2:

yum install bzip2

还有一个问题,就是network manager会接管/etc/resolv.conf, 造成你自己设置的resolver每次启动会被重写。解决办法:

编辑/etc/NetworkManager/NetworkManager.conf, 在[main]下面添加dns=none即可