Update content

content/about.md

@@ -5,7 +5,7 @@ draft: false
 comments: false
 ---
 
-博主是一只大学狗，纺织工程专业。喜欢折腾各种事物，热爱数码科技，本想学计算机专业，却在纺织的路上越走越远。
+大学狗一只，纺织工程专业。喜欢折腾各种事物，热爱数码科技，本想学计算机专业，却在纺织的路上越走越远。
 
 本站始建于2016年，用了两年多的WordPress，终于还是换成了静态博客。不管怎么说，这还是那个分享个人所见所闻所思的自留地。
 
@@ -23,5 +23,4 @@ comments: false
 * 网易云: [@Track3](http://music.163.com/#/user/home?id=34583669)
 
 [^1]: 去掉“-”，原因你懂的。
-
 [^2]: 你懂的。

content/posts/2017/raspberrypi-lede-setup.md

@@ -46,7 +46,7 @@ tags:
 
 不知道是不是心理因素，用了树莓派的路由器感觉网比以前快多了（65元的渣渣路由器你懂的）。就是开网页的时候感觉反应飞快。虽然网速没有变快，但是感觉网络整体响应变快，可能网络延迟降低了吧。毕竟树莓派四核CPU加上1G内存对一个路由器来说简直豪华……
 
-然而，如果我们把树莓派刷成路由器，只是简单的把它当成一个上网用的设备，那是不是有点过于大材小用了？LEDE是OpenWrt的一个分支，本质还是一个Linux系统，因此有很多软件包可以使(zhe)用(teng)。这些软件可以极大地拓展路由器的功能，实现各种黑科技。
+然而，如果我们把树莓派刷成路由器，只是简单的把它当成一个上网用的设备，那是不是有点过于大材小用了？LEDE是OpenWrt的一个分支，本质还是一个Linux系统，因此有很多软件包可以<ruby>使<rp>(</rp><rt>zhē</rt><rp>)</rp></ruby><ruby>用<rp>(</rp><rt>teng</rt><rp>)</rp></ruby>。这些软件可以极大地拓展路由器的功能，实现各种黑科技。
 
 LEDE采用opkg的软件包管理系统，类似于Debian系的"apt-get"与红帽系的"yum"。我大致看了看软件源，感觉基本上可以把路由器弄成一个服务器了。
 
@@ -65,4 +65,4 @@ LEDE采用opkg的软件包管理系统，类似于Debian系的"apt-get"与红帽
 * LNMP：LEDE是带了一个web server的（不然Luci的web界面怎么打得开），叫uHTTPd。看了一下软件源，发现Nginx和php版本好新，Apache很旧。可能没有多少人会在路由器上跑数据库吧，mysql版本才5.1……考虑到树莓派的性能，sqlite可能是更好的选择。
 * Seafile：私有云。
 
-说实话，树莓派还是适合用来折腾，而不是拿来使用。毕竟不是专门的网络设备，网卡的带宽还是共享USB的，而且还是USB2.0，所以就捉襟见肘了。另外，市面上有很多智能路由器产品，它们都有图形化的后台界面，有配套的手机app，只需要几个简单的操作就能实现上面的很多功能，用户体验不知道要强多少。然而，费尽辛苦做成一件事时的喜悦，真的只有经历过才会懂。这也许就是折腾的意义吧。
+说实话，树莓派还是适合用来折腾，而不是拿来使用。毕竟不是专门的网络设备，网卡的带宽还是共享USB的，而且还是USB2.0，所以就捉襟见肘了。另外，市面上有很多智能路由器产品，它们都有图形化的后台界面，有配套的手机app，只需要几个简单的操作就能实现上面的很多功能，用户体验不知道要强多少。然而，费尽辛苦做成一件事的喜悦，真的只有经历过才会懂，这或许就是折腾的意义吧。

content/posts/2017/what-i-learned-from-removing-seafile.md

@@ -12,7 +12,9 @@ tags:
 
 > ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-db' at line 1
 
-What？难道新版改了语法？我真的没有注意到后面的提示'-db'，还以为真的是我的语句打错了。首先我检查的是后面的分号是不是打成了中文的“；”，很显然不是，我把成功执行过的sql语句中的分号直接复制下来，结果还是报错。难道是语句前面部分要大写？我试了`DROP DATABASE ccnet-db;`，依然不行。难道是因为这个数据库特殊了，设定了什么不能删除的东西？不可能，明明报的是语法错误啊。百思不得其解，然后我就去找度娘了，还去了Seafile的官方社区，都没有什么线索，场面一度陷入僵局，我甚至想装一个phpmyadmin了。
+What？难道新版改了语法？
+
+TL;DR 太长不看（~~我真的没有注意到后面的提示'-db'，还以为真的是我的语句打错了。首先我检查的是后面的分号是不是打成了中文的“；”，很显然不是，我把成功执行过的sql语句中的分号直接复制下来，结果还是报错。难道是语句前面部分要大写？我试了`DROP DATABASE ccnet-db;`，依然不行。难道是因为这个数据库特殊了，设定了什么不能删除的东西？不可能，明明报的是语法错误啊。百思不得其解，然后我就去找度娘了，还去了Seafile的官方社区，都没有什么线索，场面一度陷入僵局，我甚至想装一个phpmyadmin了。~~）
 
 我仔细看了一下错误提示，好像就是这个"-db"的锅，我猜测这个是MySQL的保留字段，所以整个数据库的名字应该用引号包起来：`drop database "ccnet-db";`，结果不行。那单引号呢，也不行。最后还是上百度查了一下，原来MySQL还真的有保留字，解决方法就是……用单引号括起来？不，那不是单引号，是“\`”这个字符，就是键盘数字1左边的那个键。好吧，问题就这么解决了，感觉自己宛如一个智障……
 

content/posts/2017/wp-sites-nginx-conf.md

@@ -11,16 +11,16 @@ tags:
 
 众所周知，Apache是全球使用最广泛的Web服务器，各种模块很多、教程也多，几乎可以满足你的各种需求。Nginx是一个高性能的Web服务器，它占用资源少，能轻松应对高并发的连接，相比Apache更加轻量化。可以说Nginx与Apache风格迥异，然而，网上很多关于Nginx的教程都是用的Apache的思路，一个配置文件各种写法的都有，让人很疑惑。也许是Nginx配置文件比较智能吧，感觉怎么写都能正常访问，然而作为强迫症，找不到最正确最科学的配置方法，简直难受。
 
-好好看了一下Nginx的官方文档，结合了codex.wordpress.org以及Nginx Wiki上的教程，姑且认为我现在Nginx的配置文件写对了吧，有什么不妥的欢迎讨论……
+好好看了一下Nginx的官方文档，结合了codex.wordpress.org以及Nginx Wiki上的教程，我这里就简单总结一下，贴一下我的配置，有什么问题欢迎指出……
 
-在运行WordPress时，Nginx与Apache有些区别是你必须要了解的：
+首先，在运行WordPress时，Nginx与Apache大概有这些区别：
 
-* 执行php请求时，Nginx无法直接处理php文件，所以一般它是将php请求传送到后端的php-fpm（默认在本地的9000端口侦听，即127.0.0.1:9000）来处理。而Apache是将php当作自己的一个模块来调用，只要开启了这个模块，无需进一步的配置，Apache就能直接执行php请求。
-* Nginx没有像Apache的.htaccess那样的文件目录级别的配置文件。Apache的配置文件是可以AllowOverride的，也就是说你在.htaccess文件中的配置可以覆盖程序目录中的主配置文件（那么这也就意味着每次请求，Apache都会去读取网站根目录下的.htaccess文件，这效率想想就可怕）。当然对于虚拟主机用户来说，由于无法自行更改Apache的主配置文件，.htaccess就很有用了。WordPress的自定义固定链接功能正是通过自动将伪静态规则添加到.htaccess中实现的，由于Nginx没有这个特性，所以伪静态规则就要在nginx.conf中自行添加了。
+* 对于一个php请求，Nginx无法直接处理php文件，所以一般它是将php请求传送到后端的php-fpm（默认在本地的9000端口侦听，即127.0.0.1:9000）来处理。而Apache是将php当作自己的一个模块来调用，只要开启了这个模块，无需进一步的配置，Apache就能直接解析php。
+* Nginx没有像Apache的`.htaccess`那样的文件目录级别的配置文件。Apache的配置文件是可以`AllowOverride`的，也就是说你在`.htaccess`文件中的配置可以覆盖程序目录中的主配置文件（那么这也就意味着每次请求，Apache都会去读取网站根目录下的`.htaccess`文件，这效率想想就可怕）。当然对于虚拟主机用户来说，由于无法自行更改Apache的主配置文件，`.htaccess`就很有用了。WordPress的自定义固定链接功能正是通过自动将伪静态规则添加到`.htaccess`中实现的，由于Nginx没有这个特性，所以伪静态规则就要在`nginx.conf`中自行添加了。
 
 ## HTTPS+HTTP/2配置
 
-这一部分配置应该写在`http {}`块中。
+这一部分配置应该写在`http`块中。
 
 ```nginx
 # Upstream to abstract backend connection(s) for php
@@ -82,7 +82,7 @@ server {
 }
 ```
 
-其中，`location / {}`块的`try_files`非常机智。网上很多教程都是在这里用了if判断加rewrite，就像这样：
+其中，`location / {}`里的`try_files`非常机智。网上很多教程都是在这里用了if判断加rewrite，就像这样：
 
 ```nginx
 if (-f $request_filename/index.html) {
@@ -143,13 +143,13 @@ Nginx官方文档上是这么写的，强烈建议大家去看看这一页：
 
 > This is a wrong, cumbersome, and ineffective way. The right way is to define a separate server for `example.org`
 >
-> <cite>《[Converting rewrite rules](http://nginx.org/en/docs/http/converting_rewrite_rules.html)》</cite>
+> <cite>[Converting rewrite rules](http://nginx.org/en/docs/http/converting_rewrite_rules.html)</cite>
 
 这里使用的是`return 301`，也是新版Nginx推荐的用法。
 
 ## WP Super Cache
 
-Apache下，WP Super Cache可以自己生成rewrite规则并写入.htaccess文件中，而Nginx没有.htaccess这样的机制，因此rewrite规则需要自己配置。这个规则可以直接放入`server {}`块中。
+Apache下，WP Super Cache可以自己生成rewrite规则并写入`.htaccess`文件中，而Nginx没有这样的机制，因此rewrite规则需要自己配置。这个规则可以直接放入`server`块中。
 
 ```nginx
 # WP Super Cache rules.
@@ -198,18 +198,16 @@ location / {
 
 ## 一些其他问题
 
-我们知道WordPress能上传文件的最大体积是由php.ini的配置决定的。除此之外，Nginx对文件的上传大小也有限制（默认好像是2MB），超过这个大小WordPress会报http错误。因此nginx.conf的`http {}`块中需加一句`client_max_body_size  64m;`（改成你想要的大小）。另外，别忘了开启gzip压缩，`gzip on;`。
+我们知道WordPress能上传文件的最大体积是由php.ini的配置决定的，然而除此之外，Nginx对文件的上传大小也有限制（默认好像是2MB），超过这个大小WordPress会报http错误。因此nginx.conf的`http`块中需加一句`client_max_body_size  64m;`（改成你想要的大小）。另外，别忘了开启gzip压缩，`gzip on;`。
 
 使用`nginx -t`命令可以测试nginx.conf的语法是否正确。
 
 暂时就说这么多吧，有什么其他东西以后再慢慢添加。并非专业人士，有问题欢迎指出。
 
-个人感觉Nginx的配置文件比Apache的简洁多了，写Nginx的配置文件就跟写作文一样，每一行的意思都很清楚，非常接近英文语句，可读性高。还记得我刚换Nginx时的各种不适应，感觉现在已经离不开了。Nginx的一些特性真的是让人不得不爱。
+个人感觉Nginx的配置文件比Apache的简洁多了，写Nginx的配置文件就跟写作文一样，每一行的意思都很清楚，非常接近英文语句，可读性很高。
 
----
-
-我的Nginx配置参考自这些页面，英语好的强烈建议打开看看：
+我的Nginx配置主要参考自：
 
 * https://codex.wordpress.org/Nginx
 * https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/
-* 关于Nginx的配置常见错误，官方吐槽：《[Pitfalls and Common Mistakes](https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/)》
+* 关于Nginx的配置常见错误，官方吐槽：[Pitfalls and Common Mistakes](https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/)

content/posts/2018/compile-nginx-tls1.3.md

@@ -10,13 +10,13 @@ tags:
 
 ## 从PCI DSS说起
 
-PCI DSS，全称Payment Card Industry Data Security Standard，第三方支付行业（支付卡行业）数据安全标准，是由PCI安全标准委员会制定，力在使国际上采用一致的数据安全措施。 早在去年，PCI安全标准委员会就为TLS 1.0设定了最后期限——2018年6月30日，也就是说自2018年6月30日起，网站将需要停止支持TLS 1.0协议才能实现PCI合规。 虽然我这博客跟支付行业并没有什么关系，但是考虑到网站上有大量的`css3`、`es6`代码，那些老旧的浏览器就算能连上，又能有多好的用户体验呢，于是我果断去掉了TLS 1.0和1.1的支持。
+PCI DSS，全称Payment Card Industry Data Security Standard，第三方支付行业（支付卡行业）数据安全标准，是由PCI安全标准委员会制定，力在使国际上采用一致的数据安全措施。 早在去年，PCI安全标准委员会就为TLS 1.0设定了最后期限——2018年6月30日，也就是说自2018年6月30日起，网站将需要停止支持TLS 1.0协议才能实现PCI合规。 虽然我这博客跟支付行业并没有什么关系，但是考虑到网站上有大量的CSS3、ES6代码，那些老旧的浏览器就算能连上，又能有多好的用户体验呢，于是我果断去掉了TLS 1.0和1.1的支持。
 
-事实上，TLS 1.0发布于1999年，至今将近20年。该版本协议有各种已知漏洞，容易遭受BEAST、POODLE等攻击，在已是2018年的今天，的确是老了。现如今最流行的TLS版本毫无疑问是1.2，而且，支持TLS 1.1的浏览器一般都支持1.2，这也是我同时去掉TLS 1.1支持，仅保留1.2版本的原因了。TLS 1.2发布于2008年，是服役时间最长的一个版本，整整10年，TLS协议都没有更新过。要知道TLS协议跟HTTP可不能比啊，HTTP可以10年不更新，TLS不行。HTTP设计之初就几乎没有考虑到安全问题，正因为如此才有SSL和后来的TLS，所以才有HTTPS嘛。TLS是HTTP下面的一个安全层，跟安全有关的东西，就有潜在的漏洞，发现漏洞就得打补丁。与其修修补补，不如出个干净的新版。
+事实上，TLS 1.0发布于1999年，至今将近20年，该版本协议有各种已知漏洞，易遭受BEAST、POODLE等攻击。现如今最流行的TLS版本毫无疑问是1.2，而且，支持TLS 1.1的浏览器一般都支持1.2，这也是我同时去掉TLS 1.1支持，仅保留1.2版本的原因了。TLS 1.2发布于2008年，是服役时间最长的一个版本，整整10年，TLS协议都没有更新过。要知道TLS协议跟HTTP可不能比啊，HTTP可以10年不更新，TLS不行。HTTP设计之初就几乎没有考虑到安全问题，正因为如此才有SSL和后来的TLS，所以才有HTTPS嘛。TLS是HTTP下面的一个安全层，跟安全有关的东西，就有潜在的漏洞，发现漏洞就得打补丁。与其修修补补，不如出个干净的新版。
 
-TLS 1.3从2014年开始准备到现在，终于快要发布了。要说新版的亮点，除了安全性提高之外，更让大家兴奋的是速度与性能的提升。TLS 1.3增加了新的握手模式，建立连接的速度更快，而且还支持0-RTT的特性。关于TLS 1.3的技术特性以及跟旧版的区别，这里就不多说了，网上文章多的是，反正你只要知道TLS 1.3有很多好处就行了……
+TLS 1.3从2014年开始准备到现在，终于快要发布了。要说新版的亮点，除了安全性提高之外，更让大家兴奋的是速度与性能的提升。TLS 1.3增加了新的握手模式，建立连接的速度更快，而且还支持0-RTT的特性。关于TLS 1.3的技术特性以及跟旧版的区别，这里就不多说了，网上文章多的是，总之，TLS 1.3好处有很多就是了……
 
-如今像Cloudflare、又拍云等CDN都纷纷支持了TLS 1.3，谷歌首页也用上了，我自己何尝不想体验一番，可我用着Nginx官方维护的软件源，实在是太舒服，根本就懒得重新编译安装。然而就在几天前，我一不小心`rm -rf`了服务器的上的`/usr/local/bin`及`/usr/local/lib`文件夹，虽然不是什么关键位置，并没有造成严重的后果，但是强迫症还是决定重装个系统吧，重新编译Nginx，试一下 TLS 1.3，再顺带加上Brotli压缩算法的支持以及对Certificate Transparency的支持。
+如今，像Cloudflare、又拍云等CDN都纷纷支持了TLS 1.3，谷歌首页也用上了，我自己何尝不想体验一番，可我用着Nginx官方维护的软件源，实在是太舒服，根本就懒得重新编译安装。然而就在几天前，我一不小心`rm -rf`了服务器的上的`/usr/local/bin`及`/usr/local/lib`文件夹，虽然不是什么关键位置，并没有造成严重的后果，但是强迫症还是决定重装个系统吧，重新编译Nginx，试一下 TLS 1.3，再顺带加上Brotli压缩算法的支持以及对Certificate Transparency的支持。
 
 ## TLS 1.3的现状
 
@@ -182,8 +182,6 @@ update-rc.d -f nginx defaults
 
 ### Nginx的配置
 
-这里就贴一下SSL与ngx_brotli相关配置了，nginx-ct还没弄好……
-
 #### SSL相关
 
 ```nginx

content/posts/2018/hugo-deployment-webhook.md

@@ -11,11 +11,11 @@ tags:
 
 ## 前提
 
-此方法仅适用于在VPS上的部署，对于使用GitHub Pages或用Netlify部署的同学们并不适用。用各类Pages服务的直接本地生成然后Push到Git仓库就行，或者搞个CI自动构建；Netlify就不用多说，绑定账号，选定好Git Repo和分支就不用操心了，一切都是全自动的。
+本文记录的方法适用于有shell访问的云服务器或VPS上的部署，对于使用GitHub Pages或用Netlify部署的同学们，你们根本就不用这么折腾。用各类Pages服务的直接本地生成然后Push到Git仓库就行，或者搞个CI自动构建；Netlify就不用多说，绑定账号，选定好Git Repo和分支就不用操心了，一切都是全自动的。
 
-关于怎么搭建并配置Hugo站点这里就不做讨论，这篇文章默认你已经在本地安装好了环境，搭好了Hugo站点，并且，你已经把源放到远程Git代码托管了了，我本人用的是GitLab，后面也是以GitLab为例，当然，跟GitHub大同小异。
+关于怎么搭建并配置Hugo站点这里就不做讨论，这篇文章默认你已经在本地安装好了环境，搭好了Hugo站点，并且，你已经把源放到远程Git代码托管了，我本人用的是GitLab，后面也是以GitLab为例，当然，跟GitHub大同小异。
 
-另外，我服务器的系统是Debian 9，其他Linux发行版应该也是大同小异的。并且，以下操作我都是以root身份，如果你用的是非root账户，出现权限问题记得加`sudo`哦。
+另外，我服务器的系统是Debian 9，其他Linux发行版应该也是大同小异的。并且，以下操作我都是以root身份，如果你用非root账户，出现权限问题记得加`sudo`哦。
 
 ## 原理
 
@@ -25,8 +25,6 @@ tags:
 
 ###  配置环境
 
-指VPS的环境配置。
-
 #### Git
 
 安装Git，这个不用多说了吧：
@@ -130,7 +128,7 @@ handler.on('error', function (err) {
 
 handler.on('push', function (event) {
     let currentTime = new Date();
-    console.log('\n|--------------------> ' + currentTime.toLocaleString());
+    console.log('\n--> ' + currentTime.toLocaleString());
     console.log('Received a push event for %s to %s', event.payload.repository.name, event.payload.ref);
     exec('sh ./hugo-deploy.sh', function (error, stdout, stderr) {
         if(error) {