本文基于的应用场景是作者个人维护十数台可用性要求不是很高的非生产环i8境服务器（个人博客，团队git服务器等）。

那么这样的应用场景要求选用的系统尽量满足一下特性：

• 免费/开源/便宜
• 快速
• 轻量
• 可扩展性强

目前作者接触到的服务器监控系统大概有那么几个，全部都基于开源软件。传统老牌监控系统Zabbix和Nagios、基于Prometheus的监控系统解决方案和基于InfluxDB的解决方案。对比了这些方案后，作者选出了一种最适合的系统，只想看结论的同学请直接翻到文末。

Zabbix 和 Nagios

Zabbix

Zabbix 作为老牌的企业级服务器监控系统，功能非常强大。
官方介绍有许多功能，包括：

• 几乎所有协议和数据结构的数据来源（包括SNMP, IPMI等基础设施管理协议）
• 极其丰富的配置项
• 丰富的API控制
• 完全的用户权限和认证系统，提供PAM支持
• 一站式的解决方案，可提供图表绘制、日志审查、报警等所有可能用到的健康度监控工具
• 自动发现设备和数据来源
• 自动化维护和检查
• 可自定义的前端样式

功能强大的同时也相应的会带来重量级的问题，官方文档给出的要求是100个监控项的数量级至少需要128MB内存和256M硬盘来安装，实际使用中一般需要1GB内存和100G左右的硬盘来保证比较良好的可用性。
不过这样的问题仅仅是对于小规模应用场景来说的，真正企业级的应用中zabbix还是属于相当轻量的，也是当之无愧的首选。
Zabbix虽然提供了高度的可定制性和多到令人厌烦的配置选项，但是作为一站式方案的系统，系统耦合度很高，不利于大型、实力强的企业做二次开发和组件替换。
我个人在一年多前使用过一会zabbix，安装并不困难，甚至比Mysql的安装配置都简单，但是完成后监控配置十分负复杂，对于两位数的机器没有必要如此细致的配置。Zabbix适用于中型企业专门雇有2-3人运维团队的场景，对于个人非专职而言全套系统一一配置下来还是显得过于繁杂。
当然，Zabbix仍然不失为一个优秀的监控系统。

Nagios

Nagios相比于Zabbix似乎更为的重量级，至少需要1GB的内存和8GB的硬盘来完成一次完整的安装。
与Zabbix提供的一体式解决方案不同，Nagios的系统更加组件化，提供给大型企业更大的自定义空间，组件间耦合度较Zabbix低。
我自己未安装使用过Nagios，因此不作过多评价。

总体而言，Zabbix和Nagios都是企业级的监控方案，主要面对企业用户开发，也适用于企业的应用场景。但是其部署和配置的过程十分烦琐，不符合我们“快速”的宗旨，所以不是特别合适。

第三方监控服务

第三方提供的监控服务从简单到复杂，从免费到收费，几乎应有尽有，只要你肯出钱，没有找不到的解决方案。如果你比较不愿意自己动手搭建，或者不愿意雇佣专职运维，这样的外包服务在公司规模较小的情况下还是很常见的。
当然，这很难满足我们“免费/便宜”原则，可扩展性相比于前文的两个企业解决方案更差。所以第三方的监控服务更适用于希望能够直接外包运维的非互联网甚至非技术型企业。

基于Prometheus

基于Prometheus的监控系统架构一般如下

或是这个简化版

Prometheus本身是一个时序数据库套件，提供了监控系统中的数据收集服务端和数据库的角色（也就是上图中的Prometheus Server部分），官方还提供了报警管理的模块（上图中Alert Manager)，因此我们还额外需要数据展示和数据收集的客户端（上图中Prometheus Target和Data Visualization）。

这一额外的部分有很多的选择。对于Target 可以有各种Exporter 在官方页面有列举。甚至任何支持metric格式输出的数据收集端，比如nNetdata、statsd等。数据可视化我们一般会选择Grafana，当然其它如Grafite等只要支持PromQL查询的都可以。

此套解决方案我不久前部署过，它的优点很多，包括了全部开源，模块化，可扩展性强，可以docker部署，部署非常简单。它也较为的轻量，完全部署仅需30M左右的内存。当然硬盘占用是跟随着数据量的增大而增大的，无数据情况下大约占用200-300M的硬盘空间。

基于InfluxDB

TICK栈

TICK是InfluxData官方主推的监控技术栈。
Telegraf+InfluxDB+Chronograf+Kapacitor，将整套系统拆分成为四个模块，模块化特征明显。因此任意支持InfluxDB读写的数据收集或者监控模块都可以使用。
TICK当然也可以使用docker-compose管理，无论是部署还是迁移都很方便。
Telegraf提供了近百种不同的系统健康信息收集，若是还不够用也可以自己写插件，具有非常强大的可扩展性。
Chronograf集成了Kapacitor的管理功能、InfluxDB的直接查询和Dashboard数据展示功能。不仅如此，前端设计也非常养眼。
同样地，TICK栈也拥有与Prometheus媲美的优势——轻量、可扩展性强等等。下面我们就会讲到使用Grafana扩展数据可视化的功能。

TICGK栈

虽然官方开发的Chronograf已经拥有精美的图表可以显示，但是论数据可视化，Grafana是难以逾越的强大开源方案。因此我们在TICK中加入Grafana，成为TICGK栈，这样一来几乎所有的优点都被涵盖了。虽然五个容器会带来磁盘和内存占用增大的影响，但是对比于异常强大的功能和简单易用的界面，这个技术栈完全适合作者的应用场景。也许在高并发和大数据量的场景下TICGK栈表现会下降，但是作为个人使用，担心并发无疑是杞人忧天。

毫无疑问，最后作者选择部署的就是TICGK栈，使用docker-compose管理（就几个容器没必要k8s吧）。目前状况良好，总体内存占用60M左右，设置了5s的时间粒度，15天周期后预计的硬盘使用是4GB，还是可以接受的。存在一个现象就是5s的粒度会带来Telegraf内存占用问题，开了很多Buffer，但是事实上Buffer什么的并不真正影响啊。

看完作者的选型，你有什么想法呢？欢迎在评论区交流。
才疏学浅，若有错漏，也恳请指正。

敬请期待下一篇——服务器性能监控（二）

对于生产环境下php响应缓慢的问题，一般我们可以把分析流程拆分为如下几步操作：

1.分析开发环境下执行是否会慢；

如果是代码问题，在开发环境下就能检测出来；

2.分析测试机器执行是否会慢；

如果是数据库或者第三方扩展问题，在测试阶段就能检查出来。

3.从生产环境下线一台机器，分析代码执行慢的原因；

如果是机器的问题，在这一步才能检查出来。

1，2，3步骤都需要去分析代码，看哪部分执行时间长。如果迫不得已在生产环境下调试代码，不但要耗费大量时间还可能导致用户流失。

大多时候我们会使用第三方的分析工具xhprof来快速发现问题。‌‌xhprof是由facebook开发的一款非侵入式php性能分析框架。但是官方已经不在维护，也没有跟进php7，只能在php5上运行，tideways则是一直由商业公司在xhprof停止维护后fork出的版本，开源在Github上（托管服务需付费，自行搭建免费），支持PHP7。‌‌显而易见，tideways是我们的选择。

tideways扩展能把每条请求生成详细的执行日志，通过对日志做简单的分析就能看到程序哪部分耗时最长，这里可以使用xhprof的UI程序（xhprof生成的日志和tideways生成的日志格式通用），交互虽然不大友好但是够用了。‌‌当然，也可按照本文介绍使用xhgui来进行可视化的分析。

先决条件

本文部署所用环境为Ubuntu 18.04 LTS，其它环境请自行研究类似的配置。

安装Tideways

由于部署环境php采用编译安装，故Tideways也采用编译安装。‌‌如果采用apt安装，也可以直接使用apt安装php-tideways。‌‌还可以使用pecl安装，具体方法不详细讲了。

‌git clone https://github.com/tideways/php-xhprof-extension
cd php-xhprof-extension phpize ./configure make make install //sudo make install if not root

配置php.ini，加入

extension=tideways_xhprof.so tideways.auto_prepend_library=0 //optional 

注意最好加上后面那行，因为如果不加，tideways会调试所有经过php-fpm的请求，包括xhgui的请求，而这些请求不是我们想看的。

安装xhgui

其实xhgui就是一个网站程序，建过站的同学都知道大概怎么回事，只不过数据库换用了mongodb而已。

安装mongodb

因为xhgui需要储存由tideways传入的信息，所以需要安装mongodb。‌‌另有人维护了一个mysql版本的xhgui，如果不喜欢mongodb可以换用。‌‌部署环境使用了oneinstack安装lnmp栈，所以也使用oneinstack安装mongodb

wget http://mirrors.linuxeye.com/oneinstack.tar.gz tar zxf oneinstack.tar.gz
cd oneinstack ./install.sh // sudo install.sh if not root 

按照提示交互式安装mongodb就行了。‌‌如果你不想这么麻烦或者非生产环境部署，也可以直接使用apt安装：apt install mongodb

如果没有在php中加入mongodb扩展，则需继续安装mongodb扩展。

git clone https://github.com/mongodb/mongo-php-driver.git
cd mongo-php-driver
git submodule update --init phpize ./configure make make install // add sudo if not root >‌

同样地，在php.ini中添加extension=mongodb.so

官方基于性能建议我们为mongodb添加索引

$ mongo "use xhprof";
db.results.ensureIndex( { 'meta.SERVER.REQUEST_TIME' : -1 } ) >
db.results.ensureIndex( { 'profile.main().wt' : -1 } ) >
db.results.ensureIndex( { 'profile.main().mu' : -1 } ) >
db.results.ensureIndex( { 'profile.main().cpu' : -1 } ) >
db.results.ensureIndex( { 'meta.url' : 1 } ) >
db.results.ensureIndex( { 'meta.simple_url' : 1 } )

至此mongodb算是安装完毕。‌‌注意生产环境安装还需要为mongodb配置访问权限，此处不详细讨论了。

下载xhgui

‌ git clone https://github.com/perftools/xhgui

代码下载完以后上传到网站目录，具体操作因环境而异，若不熟悉请先熟悉lnmp架构。‌‌上传完后执行

‌ php /wwwroot/install.php

配置Nginx

假设我们需要调试的网站位于dev.fqdn‌‌而xhgui位于xhgui.fqdn

则需要在dev.fqdn配置文件的location段加入

‌fastcgi_param PHP_VALUE "auto_prepend_file=/wwwroot of xhfui.fqdn/xhgui/external/header.php"; 

此配置的作用是在dev.fqdn下的每个php经过fastcgi的时候自动在开头加入这个xhgui/external/header.php‌‌而这个文件的作用是运行你的代码前调用tideways开启调试‌‌你的代码运行完毕后结束调试并把结果传入mongodb等待查看。

xhgui.fqdn配置则是正常php网站的配置，不赘述了。‌‌注意需有这一行

‌                              location / {     try_files $uri $uri/ /index.php?$args; }

配置tideways

tideways的配置文件位于/config/config.php‌‌安装时这个文件不存在，故需要把默认配置复制到这个文件

‌                              cp <wwwroot>/config/config.default.php <wwwroot>/config/config.php

除了mongodb链接配置（一般无需调整）‌‌主要关注这一个回调函数

‌                              // In config/config.php return array(     // Other config     'profiler.enable' => function() {         return rand(1, 100) === 42;     } );

• ‌

默认配置的此函数仅仅做了节流，截取1%的流量进行分析。这是基于生产环境的性能考虑，如果我们仅仅是在开发环境中使用，就不需要管这么多了。‌‌例如

‌                              // In config/config.php return array(     // Other config     'profiler.enable' => function() {         return true;     } );

• ‌

这个配置就会把所有流量全部截取分析。‌‌令人哭笑不得的是，这所有流量包括了xhgui.fqdn的流量，这显然不是我们想要分析的。‌‌还有的时候我们也不想看到dev.fqdn中管理界面的流量，这就需要一些进阶配置了。‌‌例如

‌                              'profiler.enable' => function() {         $url = $_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];         if (strpos($url, 'dev.fqdn/admin') === 0) {             return false;         } elseif (strpos($url, 'dev.kucloud.win') === 0) {             return true;         }         return false;     },

• ‌

这样一来就只会看到我们希望分析的请求了。

参考：‌‌

phperzh‌‌

Xhgui

Readme

冰点DeepFreeze是一款系统还原软件，可以防止病毒和恶意软件更改系统。冰点的权限非常高，是SYSTEM,普通的方法对它无效，下面介绍一种可以绕过密码卸载冰点还原的办法。

前提:你可以操作机器的BIOS并选择引导顺序

获取Persi0.sys配置文件

提供一个7.3版本的
Persi0.sys
更加通用的做法是找一台机器装一个一样版本的未启用还原的冰点Persi0.sys配置文件

Persi0.sys是冰点的配置文件，在C:\下

而如果我们正常进入系统，冰点的SYSTEM权限会使得没有人能读取或者写入这个文件(除非采用非常手段提权至SYSTEM)
所以我们要避开windows的权限限制

从U盘启动

找一个可以启动的U盘，里面可以是Ubuntu安装盘，WinPE启动盘，甚至是Win10 OTG都可以
只要将上一步中的Persi0.sys复制到C:\下，再进入系统，就会发现冰点还原被关闭了，若是复制的配置文件是已知密码的，这时密码也一并知道了。

解除还原保护以后就可以正常卸载冰点了。
卸载的方法是再次打开安装所用的exe文件，安装文件会检测安装情况并提供卸载选项。

不久前的热门消息是[微软](https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/)[收购了Github](https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/)（全球领先的软件开发平台）。 对于微软来说，这可能会让它回到在软件市场10年前的地位，但是，很多开源粉丝对此感到很不满。

Github的替代品（免费、付费、自建）

几年前，微软是反开源的。

“开源是一个知识产权破坏者。我无法想象有什么比这对于软件业务和知识产权业务来说更糟糕。“ – Jim Allchin（前Windows总裁），2001年

“Linux是一种癌症，它把它自己附着在任何它能触碰得到的知识产权产物上” – 史蒂夫鲍尔默（前首席执行官）

然而，近年来，微软正努力赶上开源世界的脚步。
他们正在推动自己成为开源的支持者。
他们已经开源了他们的一些项目，并且还以白金会员的身份加入了The Linux Foundation。

没有人知道他们是否这样做是因为他们接受并认同开源，还是他们只是试图通过吸引开源用户的注意力而维持业务。
这当然会带来信任问题。
一些GitHub用户已经开始寻找Github的替代品了。

以下是一些类似于GitHub的热门服务列表：

1. Gitlab

社交媒体上的大多数用户似乎都选择Gitlab作为GitHub的替代品。

特性：

• issue版，issue跟踪（含有截止日期）
• 内置CI / CD
• 无限的私有仓库
• 更快的文件搜索
• Cherry pick
• 文件锁定
• Web IDE
• 项目wiki
• 无广告
• 代码审查和pull requests支持评论
• 静态/动态应用安全测试，Docker容器扫描
• 智能镜像加快clone，fetch，pull（高级功能）
• 托管静态网站

GitLab的统计数据显示，在过去几个小时内从GitHub导入了大量仓库。

2. BitBucket

一个Atlassian旗下的产品，是GitHub最受欢迎的替代产品之一。

特性：

• 无限的私有仓库
• JIRA集成
• 双因子认证
• LFS支持
• 源代码搜索
• 项目wiki
• issue追踪
• 无广告
• 代码审查和pull requests支持评论
• 用于托管静态网站的BitBucket云（类似于GitHub页面）
• 智能镜像加快clone，fetch，pull(高级功能)

价格:

BitBucket DataCentre 和 Github Enterprise 对比

3. Gitea

用Go语言编写的轻量级GitHub仿制版本（由GoGs fork出）。

特性：

• GitHub翻版
• 运行在Windows，Mac和Linux上
• 轻量级（甚至支持树莓派）
• 从二进制安装
• 可以从Docker，Vargrant包管理器安装
• 仓库查看器
• issue跟踪器
• 项目wiki
• API支持
• 帮助（支持论坛和聊天）

4. SourceForge

一个最早（从1999年开始）为开源项目提供免费服务的网站之一。

特性：

• issue跟踪
• 代码托管
• 镜像
• wiki
• 邮件列表
• 支持论坛
• 用户对项目的评论
• 项目的微博客
• 无限带宽
• 下载统计
• 导入GitHub项目的工具

5. Launchpad

一款来自Canonical的产品，因托管Ubuntu项目而闻名。

特性：

• issue跟踪
• 代码托管（支持Git和Bazaar）
• 代码评论
• 构建和托管Ubuntu项目
• 邮件列表
• 翻译
• 常见问题解答
• 规范跟踪

6. Cloud Source Repositories (付费)

这个来自Google的产品是Google Cloud的一部分。

特性：

• 将您的仓库从BitBucket或GitHub连接起来
• 源代码浏览器
• 调试和错误报告工具
• 稳定且易于扩展的基础架构
• 通过容器构建的CI
• 预安装的工具（编程语言，云命令行和Shell编辑器）
• 通过App Engine加快部署
• 通过自定义触发器进行部署（HTTP，Pub / Sub等）

价格:

7. AWS CodeCommit (付费)

该产品与Cloud Source Repo类似，如果您已拥有AWS账户，您可以免费获得它（每月最多5个用户）。

特性：

• 托管在AWS上
• 加密存储库
• 代码审查和pull requests支持评论
• 可扩展
• 数据的大小或类型没有限制
• 轻松从其他服务迁移

价格:

8. Phabricator (付费或自建)

特性：

• 源代码托管
• Git，Mercurial，SVN支持
• 代码审查和审计
• wiki
• 问题跟踪器
• 工作板
• 聊天频道
• 命令行工具（lint，单元测试）
• API支持

价格:

9. GitBucket (自建)

JVM上的git平台。

特性：

• 用Scala支持
• 高度可扩展性
• GitHub API兼容
• 仓库查看器
• issue跟踪器
• wiki
• 插件支持

10. GoGs (自建)

用Go编写的易于安装和轻量级的GitHub仿制版。

特性：

• GitHub翻版
• 从二进制安装
• 从Docker,Vargrant包管理器安装
• 跨平台支持
• 轻量级（运行在树莓派上）
• 仓库查看器
• issue跟踪器
• wiki

11. GitPrep (自建)

用Perl编写的GitHub仿制版本。

特性：

• GitHub翻版
• 绿色(无需安装)
• issue跟踪器
• CGI支持
• 内置Web服务器
• SSL支持
• 公钥认证支持

12. Allura (自建)

一个来自Apache的产品。
Sourceforge就运行在Allura上。

特性：

• 代码仓库
• 支持Git，Mercurial，SVN
• issue tracker
• 讨论论坛
• wiki
• 邮件列表

你更青睐哪个Github的替代品？在留言中告诉我吧。

原文地址(English):Github Alternatives

最近把博客从RFCHost家的洛杉矶GIA CN2小鸡上搬到tsukaeru的日本IIJ线路的VPS上，价格相差无几，但tsukaeru家的适合建站，所以我就把博客搬过来了

GIA CN2虽然线路很好，但是配置实在有点低(估计主要跨Wa11上网用)。tsu家这台IO非常不错，接近bwg家的1Gbps
,还给免费50G备份空间，2H1G 50G SSD。原来那台是1H512M 10G SSD ,装完lnmp就60%占用了！最近tsu促销，果断搬迁博客。
以下是搬迁过程中遇到的问题和解决方案

Access denied & No input file found

这个是老问题了，网上也有很多地方有解释，官方安装教程也有。
就是那个cgi.fix_pathinfo
把php.ini文件中的cgi.fix_pathinfo=0改成cgi.fix_pathinfo=1就行了
php.ini文件在哪里？
对于oneinstack安装的php，在/usr/local/php/etc/php.ihi
对于ubuntu系统自带的php在/etc/php/fpm/php.ini
实在找不到可以放大招：phpinfo();
在命令行使用交互模式(php -a)输入phpinfo();仔细找一找php.ini的位置
什么？输出太多不想找？
那只好系统帮我找一找了

echo 'phpinfo();' > 1.php
php 1.php | grep 'php.ini'

当然你也可以暴力一些

find php.ini /

首页正常二级页面全部404

这是typecho伪静态的问题，需要向nginx配置文件http->server的内部添加

if (!-e $request_filename) {
      rewrite ^(.*)$ /index.php$1 last;
}

fastcgi_params配置

nginx给出的默认配置文件在http->server->location块使用

fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
include        fastcgi_params;

但是Oneinstack的处理是将SCRIPT_FILENAME加入fastcgi_params中，我个人认为这种做法更清晰明了，推荐这样的做法。

目录权限

我每次安装typecho都是直接clone项目在复制的(反正最近的commit都是修bug)，有时会有权限问题
根目录下

var
usr/themes
usr/uploads
usr/plugins

这些目录最好都
chown -R www:www

缓存插件TpCache

Github项目
这个插件应该是比较完善的，据作者readme,原生评论测试过可以更新缓存。第三方评论就更加没所谓啦。

启用之前要先在服务器安装好Memcached、memcache或Redis，据说Memcached在键值较大时性能较优，本博客就选择的是Memcached。
当然一键包啦，安装和php扩展一并搞定。
哦对了，推荐一键包Oneinstack
直接下载Oneinstack不含源码版
个人认为比军哥的lnmp.org的要好(而且开源)

Comment2Mail

这是常规啦
只是为什么总是发件人Root root@localhost
我明明配置的是Sendgrid的smtp发信啊
难道源码有问题？
有谁知道吗？

数据迁移

typecho自带的导出导入已经基本够用了
但是之前曾经用过iviews插件，修改过数据库结构(也不告诉我……)到了导入的时候出错了(typecho也真是奇怪，导出不检查数据库结构，导入检查)
不想改动数据库，干脆在原来那里删了那张views表
嗯
所以还是我的NewMaterial主题好，用自定义字段统计，不乱改数据库。

暂时想到的就这些吧
其他的服务器安全加固等等就不写在这里了

最近写模板又遇到问题了，同样的代码在测试机上正常工作，换到线上又出错了，后来一看，是php7的锅……

php7+中isset()函数在判断类成员是否设置时的行为与php5.6有所不同。 我们先来看看php的官方git commit message

PHP 7 has fixed a bug with __isset which affects both the native isset and empty methods. This causes specific issues 
with checking isset or empty on relations in Eloquent. In PHP 7 checking if a property exists on an unloaded relation, 
for example isset($this->relation->id) is always returning false because unlike PHP 5.6, PHP 7 is now checking the offset of each attribute before chaining to the next one. In PHP 5.6 it would eager load the relation 
without checking the offset. This change brings back the intended behavior of the core Eloquent model __isset method 
for PHP 7 so it works like it did in PHP 5.6.

For reference, please check the following link, specifically Nikita Popov's comment (core PHP dev) - https://bugs.php.net/bug.php?id=69659

假设我们有如下php代码

<?php

class Post
{
    protected $attributes = ['foo' => 'bar'];

    public function __get($key)
    {
        if (isset($this->attributes[$key])) {
            return $this->attributes[$key];
        }
    }
}

$post = new Post();
echo isset($post->foo);  // false

我们会发现无论如何isset总是返回false
因为变量foo不是类Post的成员
也就是说，PHP7开始，isset执行前不会先执行->
也就是__get()函数

当然也可使用魔术方法__isset解决此问题

<?PHP
class Post
{
    protected $attributes = ['foo' => 'bar'];

    public function __get($key)
    {
        if (isset($this->attributes[$key])) {
            return $this->attributes[$key];
        }
    }

    public function __isset($key)
    {
        if (isset($this->attributes[$key])) {
            return true;
        }

        return false;
    }
}

$post = new Post();
echo isset($post->foo);   //true

此时我们可以看到isset()返回了true
因为我们对类Post执行isset()时调用了我们定义的__isset()函数，而__isset()函数中的isset()是可以访问foo的，故此处返回true

当遇到isset($widget->fields->$var)
这样的写法时
php5.6 和以前会先执行$widget->fields->$var
php7则会在每次调用前执行isset
于是typecho常用的判断自定义字段是否为空的代码
isset($widget->fields->$var)
总是返回false
网上大多数判断typecho自定义字段是否设置的教程都直接使用isset函数，当然会在php7的线上环境下出问题啊。
从兼容性角度考虑，建议还是写

if ($widget->fields->$var !== NULL){
    //code...
}

比较保险。

原理

主要利用的是Github的公钥公开地址‌‌比如我的是Github keys‌‌形如https://githib.com/{username}.keys

使用

每次只要执行curl https://…. >> .ssh/authorized_keys‌‌就可以快速搞定了

还要注意权限问题，如果原本就有.ssh/authorzied_keys就没什么问题‌‌若是新创建的要.ssh 700‌‌.ssh/authorized_keys 600‌‌ssh对公钥读写还是有安全要求的。

居然有大佬写了个脚本？SSHKEY_Installer

一阵无语……

这个脚本有一个好，顺便帮忙关了密码登录。搞定了.ssh目录下的权限问题。

无论是Systemd和Supervisord都可以用于控制进程，实现进程的分组管理和崩溃自动重启，下面我们看看他们都是怎么实现的。

进程控制

无论 Supervisord 还是 Systemd，都采用 ini 作为配置文件的格式。跟 Supervisord 不同的是，Systemd 每个程序都要单独开一个 unit 文件。
Supervisord 可以同时启动/停止配置文件中所以的进程（或者某个进程组配置中的进程）。
也就是说，Supervisord 使用“进程组”这个概念来控制多个进程
Systemd 则用用依赖来实现这一点。

我们来看一个简单的Systemd配置文件，实现了进程组管理

; group.target
[Unit]
Description=Application
Wants=prog1.service prog2.service

; prog1.service
[Unit]
Description=prog1
PartOf=group.target

[Service]
ExecStart=/usr/bin/prog1
Restart=on-failure

; prog2.service
[Unit]
Description=prog2
PartOf=group.target

[Service]
ExecStart=/usr/bin/prog2
Restart=on-failure

systemctl start group.target ，prog1 和 prog2 也会启动。systemctl restart group.target，prog1 和 prog2 也会跟着重启

相比起来Supervisord的管理方式就要明了一些了

[program:prog1]
command=python /home/user/myapp/prog1.py

[program:prog2]
command=python /home/user/myapp/prog2.py

[group:prog]
programs=prog1,prog2

supervisorctl start prog:*可以启动prog组下的所有进程

如果要更改 supervisord 的配置文件，supervisord 需要运行 supervisorctl reread 才会生效。
而 systemd 则需要 systemctl daemon-reload。这方面两者差不多
不过 supervisord 有一个优点。如果你不知道哪些程序的配置改变了，简单地执行 supervisorctl update，所有涉及的进程都会被重启。
而 systemd 貌似做不到这一点。

systemd 可以指定 stop 操作时可以选择的命令（ExecStop=）。另外它还提供了 ExecReload=，可以自定义调用 systemctl reload xxx 重新读取程序配置文件时的操作。
supervisord 不支持 reload 指定进程。同时对于 stop 操作，它只允许你选择要发送哪种信号…

supervisord 的 stopwaitsecs 可以控制 stop 操作后等待程序退出的耐心（以秒衡量）。待给定的耐心都消耗完毕后，supervisord 才会痛下杀手，发送 SIGKILL。
systemd 对应的配置项是 TimeoutStopSec=。systemd 会给多一次机会，在下最后通牒之前，会先发送 SIGTERM，过另一个 TimeoutStopSec 之后才发送 SIGKILL。

对比

systemd 和 supervisord 各有长短，不存在哪一方绝对的碾压。
systemd 跟 Linux 紧密结合，主流的发行版几乎全部使用systemd，所需的依赖少，其提供的保障自然比 supervisord 更可靠。然而在强大的能力背后，也有配置复杂、不易上手等问题。
systemd使用C语言编写，启动速度要快于supervisor，因此底层和对可用性有较高要求的情景，systemd还是更加适应的。
supervisord 偏于应用层，却因此有独特的用武之地。
举个例子，许多人会往 docker 打包里面封入一份 supervisord，让它来做 PID 1，以此稍微增强下健壮性。
supervisord还有XMLRPC接口，使得它和上层应用更容易结合，无论是否是Python应用。

换 systemd 做同样的事，就像用园艺剪刀裁纸，即使能够顺利完成，也难免事倍功半。毕竟这样的方式跟 systemd 的设计是背道而驰的。

至于健壮性的对比，我没有做过实验不知道，但两者都是经过多年检验过的项目，健壮性对于小型服务来说都是足够好的了。

这几天把页面底部的sns图标加进New Material主题，发现原作者是直接用png做 <button> 的背景图，这样的话有几个缺点，一是png放大了一以后会不清楚（虽然改用svg也能解决），二是要写太多自定义的css了，可移植性差，这也是最主要的一点（我懒，嘻嘻嘻），还有就是html里标签又div又a又button又span的，可读性也差。作为一个完美主义者，我怎么能容忍这样的结构呢，于是我果断加入@font-face方式的图标。

什么是font-face字体图标

unicode编码（也叫utf-8）除了正常的字符以外，\e000 开始的一段是空的，也就是留给自造字用。如果把图标放到这一段呢？这就是字体图标的原理，字体在css里类是@font-face，所以又叫font-face图标。

Fontcustom

说了那么多，到底Fontcustom是什么呢？

Fontcustom Github

Fontcustom是一个基于rubygems的工具，帮助个位开发者把svg图片转成@font-face需要的字体格式，也生成好所需的css，要用时只需外链一个css就可以了。

安装fontcustom

安装rubygems

其实主要麻烦之处在于rubygems的安装，除了有一些坑以外，别的应该没有什么难度

ubuntu 16.04

apt install ruby ruby-dev 

ubuntu 14.04

apt install ruby rubygems

安装Fontcustom

Fontcustom要求安装好 Ruby 1.9.3+, WOFF2, FontForge

安装依赖

# On Mac
brew tap bramstein/webfonttools
brew update
brew install woff2

brew install fontforge --with-python
brew install eot-utils
gem install fontcustom

# On Linux
sudo apt-get install zlib1g-dev fontforge
git clone https://github.com/bramstein/sfnt2woff-zopfli.git sfnt2woff-zopfli && cd sfnt2woff-zopfli && make && mv sfnt2woff-zopfli /usr/local/bin/sfnt2woff
git clone --recursive https://github.com/google/woff2.git && cd woff2 && make clean all && sudo mv woff2_compress /usr/local/bin/ && sudo mv woff2_decompress /usr/local/bin

安装fontcustom

gem install fontcustom

大功告成！
安装过程可能出现
gems报错
Cannot Compile Extension ffi
或者之类的

这是由于apt安装的rubygems要自行编译所有extension

安装libffi就可以了

apt install libffi-dev

Fontcustom 简单使用

fontcustom compile my/vectors  # 生成到 `fontcustom/`
fontcustom watch my/vectors    # 监视my/vectors的文件改变，即时生成
fontcustom compile             # 使用默认的配置文件 ./fontcustom.yml
fontcustom config              # 生成空白的配置文件
fontcustom help                # 查看所有用法

啊哈！简直太方便了