2017年4月

之前搞的免费证书还没过期,但是被标记为不安全了。
今天下午抽空把网站换了 Let's Encrypt,还是这个靠谱。
记录下几个使用中要注意的点,这里以 Ubuntu + Nginx 为例

1. 服务器安装 certbot

可以在这里查看自己使用的系统和服务器软件对应的安装方式

2. 执行 certbot certonly

会看到如下提示

How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Place files in webroot directory (webroot)
2: Spin up a temporary webserver (standalone)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 

这里会让我们选择 1 还是 2 强烈建议选择 1
因为选择 2 之后 certbot 会在 80 端口临时启动一个 webserver,但是我们的 nginx/apache 往往会占用 80 端口,需要停掉服务才可以继续,一次也就算了,每三个月要续期一次,续期的时候还要停止服务,不太合适。。
所以我们选 1

采用 1 以后需要指定一个文件夹用来存放认证文件,需要提前为要加 https 的域名配置好 nginx,certbot 会访问这个文件来确认这个域名绑定到了当前服务器。
设置方法:
假如我们指定的认证文件存放目录为 /data0/html/certbot
那么就在 nginx 中做如下配置

location '/.well-known/acme-challenge' {
    root /data0/html/certbot;
}

这段配置可以写在另外的文件中,用到时 include 进来。
之后按照 certbot 的提示操作,看到 Congratulations! 就说明证书生成成功了,记录下证书存放的位置,一会配置 nginx 要用到。

3. 配置 https

找到网站的 nginx 配置文件加入一个 server {} 配置如下

server {
    listen 443;

    ...

    ssl on;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ...
}

这里省略掉了与 80 端口相同的配置项,只需将端口改为 443,加入以 ssl 开头的 3 行配置就搞定啦!
当然 example.com 要替换成我们自己域名,这个可以说是最简配置了
更多详细说明可以看这里

4. 自动更新证书

每两个月更新一次并重启 nginx
0 0 1 /2 /usr/bin/certbot renew >> /var/log/certbot.log && /usr/sbin/nginx -s reload

5. 可能遇到的问题

本来配置好了,然后自己清理了一下之前的配置,搞出问题了。。。
之前有个 listen 80 default_server 这样的配置 我又加了个 listen 443 default_server 重启 nginx 之后就不能访问了 会提示 ERR_CONNECTION_CLOSED 或者 ERR_SSL_PROTOCOL_ERROR。。。查了半天才解决这个问题,自己给自己挖坑,醉了。。不过好在涨姿势了。
listen 443 default_server 这种写法是不对的。
由于是泛解析,任意子域名都能访问到网站,https 建立连接是在判断 server_name 之前的,所以采用 https 的访问是无法统一处理的,目前采用的方式是:
在解析的域名中加一条配置

if ($host != 'blog.jiayx.net' ) {
    return 301 https://blog.jiayx.net$request_uri;
}

nginx 在执行 !-e $request_filename 或者 try_files $uri $uri/ /index.php$uri 的时候如果文件所在的文件夹没有执行权限会导致 nginx 认为文件不存在,遇到这种问题的时候,先查看文件夹权限。尤其是从别的地方下载的文件或者压缩包里解压出来的文件

为什么 FAT32 格式的 U 盘无法存放大于 4G 的文件?
为什么 32 cpu 通常只支持 4G 内存?

所有的计算机术语中,所有的“位”都是指 bit 就是一个二进制位(即 0 或 1)

1bit = 1位

1B(byte) = 1字节 = 8bit
1KB = 1024B
1MB = 1024KB = 1024 * 1024B
1GB = 1024MB
1TB = 1024GB

FAT32

这个是硬盘分区格式,32 意思是采用了 32 位(即32个0/1)的文件分配表
也就是说采用 32 个 二进制位 来计数文件的 字节数
32个 0/1 所能记录最大的正整数为 2^32 也就是说能记录的最大文件大小为 2^32byte(字节)这数正好是 4G,所以采用 FAT32 格式的 U 盘无法存放大于 4G 的文件

操作系统以及 CPU 的“位”

这方面的文献搜集的不够全面和专业,先简单列出,后续再补充

  • 32 位系统
    CPU 一次最多能处理 32 个二进制位
  • 64 位系统
    CPU 一次最多能处理 64 个二进制位

介绍

lseek 可以显式地为一个文件设置偏移量,设置成功返回新的偏移量,设置失败返回 -1

每个文件都有一个与其相关的“当前文件偏移量”,一般是个非负整数,用来度量从文件开始出计算的字节数。通常对文件的读写操作都是从“当前文件偏移量”处开始

文件偏移量允许大于当前文件长度,这样一来文件中会包含一个“空洞”。这部分“空洞”不占用磁盘块。在读的时候被读为 0

用途:迅雷下载

之前看到过迅雷下载的文件,只要任务创建好,文件的大小就是将来下载完的文件大小(只是看起来比较大,并没有实际占用那么多磁盘空间)。当时有点奇怪,但是没有深究,看到 lseek 的时候去搜了一下,原来是这样的原理!
先利用空洞文件的特性,建立一个跟目标文件大相同的文件,之后下载可以采用多线程的方式同时写入,加快下载速度。
有的人问为什么没有采用写多个小文件最后合并的策略。两方面原因:

  • 合并文件比较费时间,很多小的碎片,硬盘也很累
  • 提前占用空间的好处是,如果下载空间不足,可以在任务创建时就提醒用户,而不是等下载到一半才发现空间不够用

之前随便申请的 CA 沃通免费SSL证书 现在被 Chrome 标记为不安全了。改日换成 Let's Encrypt 吧