1. Uninstall old versions

$ sudo apt-get remove docker docker-engine docker.io containerd runc

2. Install Tool Chain

$ sudo apt-get update

$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

3. Add GPG key

$ curl -fsSL https://download.docker.com/linux/raspbian/gpg | sudo apt-key add -

4. Add repository

$ sudo vim /etc/apt/sources.list.d/docker.list

Add this line and save:

# add docker repository
deb [arch=armhf] https://download.docker.com/linux/raspbian buster stable

5. Install via apt

 $ sudo apt-get update
 $ sudo apt-get install docker-ce docker-ce-cli containerd.io

Troubleshooting

You may encounter this error when apt install running:

Errors were encountered while processing:
 aufs-dkms

We can simply ignore it. Because aufs-dkms is not a dependency of docker-ce, but a recommendation.

Docker is not default to use aufs anymore; It now default prefer to use overlayfs2, which have been merged to the linux kernel mainline since 3.18.

[1] https://docs.docker.com/engine/install/debian/ [2] https://github.com/raspberrypi/linux/issues/3021#issuecomment-508704040

Solution:

Open your Registry Editor, In HKEY\_LOCAL\_MACHINE\Software\Google\DriveFS, create two new DWORD values, DisableCRLCheck and DirectConnection, assigning value data as 1.

Reference: https://tinyapps.org/blog/201909120700_can't_reach_google_drive.html

树莓派安装

至少需要以下硬件：树莓派4主板 + TF 存储卡 + USB存储设备 + 电源(3V/5A) + 连网（有线）

操作工具：PC一台 + USB 接口的 TF 读卡器 + 连网（有线或无线均可）

流程如下：

1. 下载官方镜像，插入读卡器，使用软件写入 TF 卡（PC上操作）
2. 修改 TF 卡镜像文件中部分配置（PC上操作）
3. 把 TF 卡从读卡器取出并插入树莓派主板（操作树莓派）
4. 接网线、电源、USB存储设备，通电（操作树莓派）
5. 进入路由器查看树莓派的 IP（PC上操作）
6. SSH 连接（PC上操作）

细节补充

1. 官方镜像请使用 lite 版本：Raspbian Buster Lite。Desktop 不在讨论之列。写入镜像使用 Win32 Disk Imager：https://sourceforge.net/projects/win32diskimager/
2. 只需要在 TF 卡新的分区中新建一个空白的文件，名字为 ssh
3. 树莓派主板上有个插口用来接 TF 卡的。如果直接把 USB 读卡器塞到 USB 接口里，系统不会启动。
4. 电源最好 3V 以上，否则怕电压不稳。USB 存储设备最好能独立供电。
5. 这一步需要有路由器权限，如果无法进路由器，下载一个内网 ARP 扫描器也可以。树莓派的 Hostname 就是英文的 raspberry pi。如果路由器里没有看到树莓派，那就是树莓派没有启动，需要检查 3、4 步骤是否正确。
6. 用户名和密码分别是 pi 和 raspberry。进去后先 passwd 改密码。进入 SSH 后更新源等操作略过。

挂载 USB 存储

1. 检查存储设备是否被识别
2. 安装 ntfs-3g
3. 挂载 ntfs 分区

先看看自己的设备是否有被识别到：sudo lsblk -f 或者 sudo fdisk -l

为了方便存储日后与 Windows 共享，我的存储设备使用的 NTFS 格式的文件系统。所以在分区系统里会有 sda1 和 sda2，sda1 是 NTFS 自用预留的分区，sd2 是数据存放区，也是需要挂载的分区。在 NTFS 系统上读写需要在 Linux 上安装 ntfs-3g：apt install ntfs-3g

最后将存储设备挂载到 /mnt/hd1 目录下： mkdir /mnt/hd1 && sudo mount -t ntfs-3g /dev/sda2 /mnt/hd1 挂载完成后使用 df -h 即可看到可用空间已经增加。

Aria2 安装

1. 安装并建立配置文件与下载目录
2. 写入配置文件
3. 启动守护进程，提供 rpc 服务

使用 apt install aria2 安装后需要为其建立一个配置文件存放地，我选择放在 pi 目录下。mkdir ~/.aria2。建立以下两个文件：touch ~/.aria2/aria2.conf 和 touch ~/.aria2/aria2.session 后面配置会用到。建立一个下载文件的目录，我选择在 USB 存储设备上建立 mkdir /mnt/hd1/downloads

写入以下内容到 aria2.conf 中：

dir=/mnt/hd1/downloads
continue=true
disable-ipv6=true
input-file=/home/pi/.aria2/aria2.session
save-session=/home/pi/.aria2/aria2.session
enable-rpc=true
rpc-listen-port=6800
rpc-secure=false
rpc-listen-all=true
rpc-allow-origin-all=true
rpc-secret=密码

启动守护进程：aria2c --conf-path ~/.aria2/aria2.conf -D。这样 aria2 会在后端监听 6800 端口。每次修改完配置文件后，需要杀掉进程重启 killall aria2c。你当然可以把 aria2c 做成服务，但我太懒了。

Aria2 WebUI 安装和设置

1. 下载文件
2. 放到树莓派 Nginx 下
3. 使用 token 配置并访问

Aria2 WebUI 本质上就是一个静态 HTML 文件，通过 Javascript 远程向 rpc 服务发送 http 请求。在这里直接下载 zip 文件：https://github.com/ziahamza/webui-aria2/archive/master.zip

下载后的文件夹一大堆文件，请仅保留 docs 目录，其他的都删除即可。

安装 nginx apt install nginx 把 docs 目录放到 /var/www/html 之下。

在 PC 端浏览器输入 http://树莓派IP/docs 即可进入 webui 界面。进去后点击 Connection Settings

在这一栏 Enter the port: 写 6800 在这一栏 Enter the secret token (optional): 写进去上一步的密码即可。

连接成功后，左侧会出现配置文件等信息。

目前为止仅仅支持内网访问。你可以绑定一个域名，用 ddns 去映射到公共网络，或者如果你在内网，使用 frp 穿透到公共网络。这些需要额外设置一下 nginx。由于本人太懒，就先写到这里了。😁

minio 发音是迷你欧，是一个兼容 S3 协议的存储系统，使用 Go 开发，推荐用 docker 部署。

docker pull minio/minio

用最少参数启动 minio：docker run -p 9000:9000 minio/minio server /data 这样启动的容器无法保留数据，重启后数据会清零，不能在生产环境使用。

实际环境中：docker run -p 9000:9000 --name minio1 -e "MINIO_ACCESS_KEY=YOURKEY" -e "MINIO_SECRET_KEY=YOURSECRET" -e "MINIO_BROWSER=off" -v /mnt/data:/data -v /mnt/config:/root/.minio minio/minio server /data，如果是第一次建立镜像，Key 参数可以省略，会自动生成 Key 和 Secret。

这些参数建立的容器可以把配置文件和数据文件持久化到 /mnt/ 目录下。带上访问 Key 参数否则每次新建的容器都会产生新的随机密钥。MINIO_BROWSER=off 带上这个环境变量可以关闭 web ui 界面。使用官方的 mc 客户端管理功能强大，不建议开启 web 界面，只会增加安全风险。

配置 nginx

server {
  listen 80;
  server_name example.com;
  ignore_invalid_headers off;
  client_max_body_size 0;
  proxy_buffering off;
 
  location / {
    proxy_http_version 1.1
    proxy_set_header Host $http_host;
    proxy_read_timeout 15m;
    proxy_send_timeout 15m;
    proxy_request_buffering off;
    proxy_pass http://localhost:9000;    
  }
 }

这是 80 端口的配置，443 端口类似。官方给的配置中包含 health_check uri=/minio/health/ready; 这个是商业版的 nginx 才有的功能。

mc 设置

mc 是连接 bucket 的客户端工具，安装在 rails app 所在的服务器上方便直接拷贝相关文件。

wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
./mc config

以上命令下载 mc 并生成默认配置文件。

vim .mc/config.json 编辑配置文件，直接修改 play 的 block，把 Key 填写进去。

mc admin info play 看到类似信息就说明连接成功了。

● example.com Uptime: 33 minutes
Version: 2019-07-17T22:54:12Z Storage: Used 2.9 GiB

bucket 设置

mc md play/mastodon 新建一个桶，mc policy download play/mastodon 使得可以通过 http(s)://base-url/mastodon/file-path.jpg 来直接访问文件。

以上设置会导致访问目录时列出所有文件。当前使用 mc 客户端无法设置 S3 兼容的 policy，所以还需要下载 aws-cli 来设置更精准的权限。

aws 安装后首先配置aws configure

AWS Access Key ID [****************9TA4]:
AWS Secret Access Key [****************Puw8]:
Default region name [None]:
Default output format [None]: text

准备好 /tmp/policy.json 文件，内容如下：

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Principal":{
            "AWS":[
               "*"
            ]
         },
         "Action":[
            "s3:GetObject"
         ],
         "Resource":[
            "arn:aws:s3:::mastodon/*"
         ]
      }
   ]
}

把 policy 更新到 minio：aws --endpoint-url http://localhost:9000 s3api put-bucket-policy --bucket mastodon --policy file:///tmp/policy.json

注意本地文件名必须要以 file:// 协议打开，否则会返回如下错误：

An error occurred (MalformedPolicy) when calling the PutBucketPolicy operation: Policy has invalid resource.

复制文件到 minio

mc cp --recursive ~/live/public/system play/mastodon 会把 system 文件夹复制到 minio 的 mastodon 桶里。可以在切换 mastodon 配置时候重新执行一次 mc cp --recursive --newer-than 0d1h ~/live/public/system play/mastodon 这样会只复制 1 小时之前到现在产生的文件。

修改 mastodon 环境配置

 S3_ENABLED=true
 S3_PROTOCOL=https
 S3_BUCKET=mastodon
 S3_HOSTNAME=example.com
 AWS_ACCESS_KEY_ID=YOURKEY
 AWS_SECRET_ACCESS_KEY=YOURSECRET
 S3_ENDPOINT=http://example.com/

修改完毕后重启 web、streaming 和 sidekiq 服务。sudo systemctl restart mastodon-*。刷新前端，图片应该已经改为 minio 的网址了。格式为：http(s)://your-minio-domain/mastodon/media_attachments/files/***

想要使用 Cloudflare 必须要修改域名的 Name Server。Cloudflare 的 DNS 系统在界面和功能都堪称业界一流，就单说 CNAME Flattening 就非常的好用，支持这个功能的 DNS Provider 也没几家。还有就是解析速度快的飞起，修改解析记录后，本地网络几乎都是秒级响应。

最大的问题是在于中国境内复杂的网络环境下，Cloudflare 的优势荡然无存。无论从连接的稳定性还是速度都很差，往往不如直接访问源主机更快。

Cloudflare 适合以下的情况使用：

1. 访客群体在中国大陆以外
2. 网站经常经受高强度 DDos 攻击

满足以上任意一条，Cloudflare 都是很好的选择。其他情况下几乎都不是好的选择。

Google Cloud CDN 的问题

Google 的 CDN 只能给自己云上的实例使用，不支持外部源。这点让自己处于二线选手。

Windows Azure

Windows Azure 的优势和劣势也很明显。优势是他家的 CDN 部署后，在中国的访问速度非常快；劣势就是烦人的后台操作以及感人的价格。

就单 Azure 的操作界面来讲，功能和布局算是合理的。后台之所以烦人，是因为几乎所有的操作都需要等待时间。当你点击了任意的按钮，右上角的 Notifications 就开始转了起来。接下来你可以去上个厕所回来再喝个咖啡，然后它可能还在转。我一点也没有夸张。

想要在 Windows Azure CDN 中使用 APEX/ROOT 域名是一个高难度的操作。 我用了几天的时间才琢磨出来解决方法，期间一度想要放弃。

基本思路如下：

1. 域名使用 Azure 的 DNS 服务
2. @ 绑定 Azure resource，选择你的 CDN Endpoint
3. 在 CDN Endpoint 中添加自定义域名，绑定 APEX
4. 在 CDN Endpoint 中添加外部购买的自定义 SSL

以上是思路，而不是操作。如果你按照上边步骤去执行，会发现每一步操作可能都会遇到问题。

Endpoint 建立

关于 Endpoint，一定要选择 S1 Standard Verizon，而不是 S3。S1 是外部的 Verizon 供应商，S3 是微软自己的。在使用中发现，S1 功能比 S3 更多，对缓存规则能做更多的控制。使用 S3 后，Mastodon 系统出现了 401 Invalid Token 的错误。切换到 S1 则无此问题。考虑到两者目前是相同价格，强烈推荐不要使用 S1。

]

在 CDN 的 Caching rules 中，必须要设定 Bypass caching for query strings，否则 mastodon 无法登录。对复杂交互的动态网站的缓存还是要尽可能的少，否则很容易遇到 WebSocket 和 token 方面的问题。

购买 SSL 时注意点

添加自定义 SSL，首先要去买一个 Azure 支持的 SSL 证书。虽然文档里有列出来支持哪些，但是坑爹的是对方写的是一些技术参数。当你去购买 SSL 证书的时候，你无法知道证书内部的细节，比如我们欣慰的看到了列表中包含了 Godaddy 的以下证书：

• Go Daddy Root Certificate Authority – G2
• Go Daddy Secure Certificate Authority – G2

当你兴冲冲的去了 Godaddy 官网时，发现情况完全不对。几乎所有销售 SSL 的网站都不会列出来技术细节。你无法知道你选择的证书是否满足 Azure 变态的要求。

]

把证书导入到 Key vault 中

在 Key vault – Certificates 下，选择 Generate/Import，然后你可能悲哀地发现自己下载的 SSL 证书文件竟然无法导入。因为格式不对，Azure 只支持 .Pem 和 .Pfx 格式。只好再去复习一遍 SSL 证书各种格式的区别。

另外需要注意这里上传的证书文件，需要包含 Private Key 信息。

我购买的 Rapid SSL 供应商签发的证书文件中有 P7B 格式，使用了这个 SSL 格式转换网站 可以把 P7B 文件 + 证书链文件 + Private Key 文件转化为一个 Pfx 文件。

成功导入以后并没有万事大吉。你发现还需要为 CDN 添加刚才的 Key Valt 访问权限 。吃惊的是，这一切竟然无法在 Azure 界面完成，你需要下载 Powershell，然后敲一堆命令行（过程也并非一帆风顺会遇到隐含的设置）。如果不去搜索并翻看相关文档，你可能永远无法成功添加一个自定义 SSL。

我曾经想过去联系他们的客服，但是点击 Help 会引导你订购他们的 Basic Support。每月 29 刀会有 24 小时以内响应的 Email 支持。到这里我只能说 Azure 真的太高级了，设计之初就并不是给所有人使用的。

CDN 等待时间

当你验证 CNAME 记录时候，可能需要 30 分钟左右。当你上传并设置好 SSL 以后，部署到 CDN 最高要 30 个小时。总之，在 Azure 中进行某一操作以后，往往不会立即生效。给我隐隐的感觉就好像他们会把每一步操作拿去给领导签字一样，确认以后才放行。这还是云计算服务吗？每当页面转圈圈的时候，就非常怀念 AWS。

截至目前，SSL 状态依然是 Deploying certificate to CDN POPs。使用云计算尤其是 Azure CDN，真的要保持好心态不能急躁。

== 部署成功 5 个小时以后更新

本来以为成功部署了就没问题了。截至现在还是遇到 SSL 证书错误问题。Azure 并没有把我的自定义域名放到 CDN 上，目前证书还是 sni.msft.default.wpc.edgecastcdn.net 这里的。我看到了<<有同样的人遇到此问题>>，有的是部署成功后几小时内才成功的，有的是部署5天后还是错误。这里只能拼人品了……

== 部署成功 15 个小时以后更新

大约昨日凌晨 4:00 am 左右提交证书，早上 10:00 ~12:00 am 点之间 Azure 后台显示部署成功。但是实际证书变得可用还得十多个小时。在晚上 8:00 pm 左右微软的 edge 浏览器开始认出来了自定义的证书，再往后到了 11:00 pm 查看的时候各浏览器中 SSL 证书已经完全正常了。

从提交证书到正常使用，前前后后需要将近 20 个小时！我推断这 20 个小时中必然会有一些人工审批的过程，否则按照计算机系统处理速度和国际互联网传输速度，不可能在同步到个节点的过程中花费如此长的时间。微软成功的把大公司的官僚作风带入了自家的云计算中。相比 AWS，部分新注册用户或者敏感服务比如 SES 会有明确的提示，告诉你需要填表申请并且人工审核，你自己可以对完成的时间做到心里有数。Azure 则不会告诉你哪些操作有隐形的审核步骤，只会告诉你一个大概时间，但是实际需要的时间往往比他们预估时间要更久。

这次的经历告诉我们：如果要在生产系统上部署 Azure CDN 并且使用 SSL，一定要慎重考虑如何做好过度，否则等待 SSL 生效的时候流量强行中断，老板可能已经把你炒鱿鱼了。

1. Edit postgresql.conf

sudo vim /etc/postgresql/9.5/main/postgresql.conf

Add the following to your postgresql.conf:

sharedpreloadlibraries = 'pgstatstatements' pgstatstatements.track = all pgstatstatements.max = 10000 trackactivityquery_size = 2048

Then restart the PostgreSQL server: sudo systemctl restart postgresql

2. Create extension

sudo -u postgres psql

postgres=# \c mastodon_production

mastodon_production=# CREATE extension pg_stat_statements;

3. Refresh your PgHero Page

All items are green!

Reference:

• https://github.com/ankane/pghero/blob/master/guides/Query-Stats.md
• https://github.com/tootsuite/mastodon/issues/935

时隔多年，我又开始写博客了。十多年前我经常在 bo-blog、WordPress 之间徘徊，后来因为某些特殊的原因，想要跟以前的自己说再见，所以把博客彻底停掉了，长期以来用的域名也丢掉了。

其实回想当初写博客的时候，自己虽然很用心，时常更换一些 theme，添加一些插件，甚至还自己在 WordPress 发布过一款插件，但是每日访问量少的可怜，博客的评论中也大部分都是来发垃圾外链的。不禁在思考，自己使用独立博客的目的到底是什么？是否有必要花费大量精力维护一个除了自己没什么人看的博客？答案似乎是显而易见的。

有人可能要讲，独立博客其实也没什么需要花费精力的地方啊，买域名、VPS，安装 WordPress 都是分分钟的事情，有那么麻烦吗？这个问题对于有大量空闲时间和精力的人（比如学生）来讲，确实是这样，对他们来说生活中并没有太多的其他的事项需要处理。随着年龄增长，工作繁杂以及成家立业以后，每日大脑中思考的杂项大约是学生时代的上百倍，就连吃饭睡觉这样的事情有时候都会消耗精力。维护服务器域名需要记着续费，并且服务器可能还会被黑客入侵，你要去花费时间做一些基础的防护工作，加上哪天博客忽然访问不了了还需要去诊断原因。这种需要经常“惦记着它”的微小压力，会逐渐积累直至某一天将你击溃，产生放弃独立博客的想法。对于成年人来讲，大多数是本着多一事不如少一事的想法，开始追求安逸抵制麻烦，并不会像年少时候那样喜欢折腾了。

两种文章记录方式

虽说放弃了独立博客，但是对于一个偶尔折腾一下的人来说，还是会有需求来记录一些技术操作或者经过整理的想法的。根据公开性质的不同，我把记录分为两类：

给自己看的文章

如果涉及到了不适合公开的隐私类型文章，则记录在本地的日记里，这些是专门给自己看的。这类文章一般有如下诉求：

1. 数据本地化 因为不需要分享，所以没有必要将文章发布在公网；

2. 支持第三方备份并多端同步数据 能够在私有云上备份数据，比如 Dropbox 等，并且在多个设备上自动同步。谨慎使用软件自带的云端同步服务，因为你无法判断服务提供者是否会将你的内容用于大数据分析或者提供给第三者。

3. 私密性 最好能够加密文章数据，并且能够设定访问软件界面的密码。这涉及到两个场景：如果你的电脑硬盘被别人暴力夺取或悄悄偷走，你写的文章是否能够被读取？如果你在开机状态下离开了几分钟，潜入到电脑前的第三者是否能够读取到你的文章信息？

4. 纯文本编辑 因为技术取向，对于暗地里操作格式的富文本编辑器非常厌恶，所以支持 markdown 几乎是必须的。

我考察了很多的日记软件，比如 Evernote、OneNote、SimpleNote 等各种知名或者不知名的软件（国产的一个没试过），最终发现一个终极软件：Standard Notes。推荐原因不展开说，完全满足以上 1、2、3、4。

自己认为有传播价值同时也希望别人能看到的文章

这就是传统的网络博客适用的场景，本想着自己再建一个 WordPress 博客，回味以前独立博客的体验真的有些担心能否坚持。并且目前市面上的博客系统重的太重，轻的太轻。重的系统有如 WordPress 之流，PHP + MySQL，代码动辄几十上百兆字节，功能繁杂无比。相比个人博客，WordPress 更适合做多栏目多分类，每日更新很多条的大中型资讯网站。轻的博客系统有各种基于 GitHub 的生成器，比如 Hexo、Jekyll。这类型系统使用起来很繁琐，传统的撰写、发布操作被复杂化，你需要先对 Git 有初步了解才可以使用，然后各种命令提交、合并、Push。与其说是在写博客，更不如说是在不停地把玩 Git 命令。在这种现状下，我认为有必要使用一种功能简约、操作简单、省心省力的博客服务，也没费太大心思就找到了，那就是 write.as。

当使用一种免费或者付费服务时，首先要思考对方的经营模式是什么，他是否有盈利，盈利模式是否能够支持服务维持下去的开支。目前从我对 write.as 的简单观察来看，这家服务提供商成本很低，并且系统维护起来并不太复杂，或许背后是一个几人的小团队。目前的付费模式完全可能支持他们继续下去。

以上部分是对长文章类型的总结，这些文字写作环境以 PC 端为佳。大段的文字要在大屏幕下配合键盘（最好是机械键盘）才方便撰写，有时候要旁征博引，需要在不同的网页、文件等资源切换，这个时候使用电脑来操作能够事半功倍。所以对于移动端并没有要求。

短文或想法分享

使用日记软件或者博客服务对于内容较多的长文章来讲很合适，但是对于一些几十字的短句、瞬间闪过的想法以及照片+配文的场景来说，是完全不适用的。这种情况下需要类似微博、微信朋友圈或 Twitter 的 timeline 模式才会产生最佳的体验。当时立即想到了使用 Twitter。使用一段时间后发现，Twitter 是一个热闹嘈杂的地方，用户多而杂，精英、小白和无脑黑都混在了一起，很难发现值得去 Follow 的账号，因此信息流中往往的都是一些自己不感兴趣的东西。还有一些国内翻墙后的愤青，无论有理无理都想要黑一把某党某国，似乎不谈这些自己就跟不上 Twitter 的潮流。自己只是想找到一个能发表闲言碎语的地方，最好能安静一些，远离那些与自己不在一个象限内的人。

mastodon 是在我有了相关需求之后很久才出现的。因此在发现它之后我大致看了看便立刻搭建一个实例试用起来。开始的时候是被实例+网络的分布式结构吸引，听起来非常新颖，似乎有着很大的潜力值得来深究一下。试用一段时间后发现，无论在 Web 端还是 APP 端，mastodon 的体验都不输 Twitter。与 Twitter 不同的是，mastodon 是一个非常新的东西，关注并使用 mastodon 的用户，在一定程度上说明了是一个好奇心强并且内心追求新鲜事物的人，这样的人正好是我希望去了解更多的群体，在这里往往能接触到新的理念和思维。对 “mastodon” 不太满意的地方是我并不喜欢这个名字，英文角度来看字母太多打起来不方便，中文翻译又叫长毛象，听起来让人无好感。