又一个wORdPRess站点

离线下载一条龙

因为怕死 遵纪守法,所以不在自家bt下新番和剧。目前的架构是这样的,造福一下海外党

  1. 一个offshore的DMCA不敏感的服务器。RSS爬取某两个网站添加磁力链接到deluge。nginx添加一个下载目录的location,记得要https,并且给default_server加上假证书,参见这篇博客
  2. 家里一个树莓派或者类似的硬件,运行aria2,开放aria2 rpc端口到公网,加上token。或者ssh转发aria2的端口到一个跳板机。
  3. deluge使用execute插件,在Torrent Complete事件执行shell脚本添加到家里的aria2,并且设置pause值为true。
  4. 树莓派crontab半夜执行aria2.unpauseAll开始下载

用 OpenResty 写了一个 SNI 代理

功能类似于dlundquist/sniproxy

推荐 OpenResty 加上 stream 模块和 ngx_stream_lua_module 模块。在 1.9.15.1 上测试通过。

Github→ https://github.com/fffonion/lua-resty-sniproxy.git

示例配置:

A Lua table sni_rules should be defined in the init_worker_by_lua_block directive.

The key can be either whole host name or regular expression. Use . for a default host name. If no entry is matched, connection will be closed.

The value is a table containing host name and port. If host is set to nil, the server_name in SNI will be used. If the port is not defined or set to nil, 443 will be used.

Rules are applied with the priority as its occurrence sequence in the table. In the example above, twitter.com will match the third rule rather than the fourth.

If the protocol version is less than TLSv1 (eg. SSLv3, SSLv2), connection will be closed, since SNI extension is not supported in these versions.

那么问题就来了

为什么像我这么多愁善感的人,一个月才写一篇博客呢

升级到Ubuntu16.04,开始接受systemd的调教

sudo do-release-upgrade -d

然后进入看戏模式

OpenVZ

openvz(打满补丁的)内核2.6.32-042stab111.X之前不支持220以上版本的systemd,而16.04用的是229,所以升完之后你会得到一个没有systemd存在的美好世界。

只是因为systemd启动不了,所以开机启动项也都不启动了,你得去serial console里手动设ip和route。所以还是发个tk让客服去升级母鸡内核吧www

 

udev

system-udev会自动把网卡名字改成奇怪的em0或者ens0什么的,详情见这里

反正systemd说什么都是对的,所以兄弟请干了这碗热巧克力

可以修改/etc/default/grub 的GRUB_CMDLINE_LINUX,改成:

biosdevname=0

就可以继续使用eth0命名了

 

mysql-apt-config

mysql的官方apt源里还没有支持16.04,而update-manager会尝试将sources.list.d里的源都替换成xenial去更新,所以可能会因为mysql的源没有candidate而报错。

解决办法就是先把/etc/apt/sources.list.d/mysql.list改个扩展名,升完再改回去,然后把里面的trusty改成xenial。这样(mysql支持以后)就可以收到16.04的更新了。

 

update-manager的编码问题

哈哈哈哈哈哈哈哈哈哈哈哈哈哈我先笑一会

add-apt-repository的时候这个问题就存在,如果ppa源的标题带有奇怪的字符会报错。因为Python3是根据当前LC_ALL来自动选择codec的。

然后update-manager也会死在同一个地方,所以记得先export LC_ALL=posix,再sudo do-release-upgrade -d,再喝茶

Let’s Encrypt集中化管理

Let’s Encrypt的证书签发原理实际上和传统的PKI一样,只不过自动化完成了生成CSR和私钥、提交CSR、取回证书的过程。

此外还要验证域名所属,这一部分和传统的签发机构是一样的,不过传统的签发机构还允许我们使用域名whois中填写的邮箱来验证,而Letsencrypt貌似只能通过http challenge的方式来验证。即和验证服务器约定一个uri和随机字符串,验证服务器请求这一uri,如果得到的内容和约定的随机字符串相同,则验证通过。如图所示:

letsencrypt_howitworks

官网上抄的)

这意味着我们得在每台部署https的前端的负载均衡服务器上都装一个letencrypt工具。有没有什么集中化管理的办法的呢?

实际上,由于challenge的uri的有规律,我们可以将前端服务器收到的这类请求代理到同一台专门用来签发、更新证书的服务器上。如图所示:

letsencrypt_howitworks_proxypass

  1. 当在服务器B上发起域名a.example.com新的签发请求后,Let’s Encrypt的签发服务器返回一个challange uri (8303)和response (ed98)。
  2. 服务器B使用webroot插件将这个uri和response写入本地磁盘上对应的文件。
  3. Let’s Encrypt的签发服务器为了验证example.com的所属,查询到example.com指向前端服务器A,于是发送一个HTTP请求/.well-known/acme-challenge/8303到服务器A
  4. 服务器A反代这一请求到服务器B
  5. B读取刚才第二步时写入到response,返回到A;A返回到Let’s Encrypt的签发服务器
  6. 验证成功,发证!

然后,我们只要从服务器A上取回存储在B上到证书就可以了。可以在B上做一个RESTful的api。注意要配置allow和deny。

A服务器(前端)的nginx配置如下:

B服务器的nginx配置如下:

然后在B上运行:

评论现已支持多种表情包

Screen Shot 2016-03-30 at 7.31.00 AM

当然肯定还有滑稽

返回顶部