代码 Archives - 第9页共25页 - 论野生技术&二次元

Let’s Encrypt集中化管理

on 2016 年 4 月 7 日

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

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

letsencrypt_howitworks

（官网上抄的）

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

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

letsencrypt_howitworks_proxypass

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

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

A服务器（前端）的nginx配置如下：

server {
    # 其他的location
    # location { ..... }

    location ~ /.well-known {
        proxy_pass http://B.example.com:23333;
    }
}

server {

# 其他的location

# location { ..... }

location ~ /.well-known {

proxy_pass http://B.example.com:23333;

}

B服务器的nginx配置如下：

server {
    listen 23333;
    server_name B.example.com;
    location ~ /.well-known {
        root /tmp/letsencrypt;
        allow IP-OF-A;
        deny all;
    }
}

server {

listen 23333;

server_name B.example.com;

location ~ /.well-known {

root /tmp/letsencrypt;

allow IP-OF-A;

deny all;

}

然后在B上运行：

./letsencrypt-auto --webroot -w /tmp/letsencrypt -d exmaple.com;

1	./letsencrypt-auto --webroot -w /tmp/letsencrypt -d exmaple.com;

让Coreseek支持索引日语假名

on 2016 年 3 月 15 日

C/C++

10 13952 转为繁体

coreseek是一个修改版的sphinx，用mmseg来做中文分词。但是发现一个问题，日语搜索总是效果很差，全部是假名的关键词会返回一个空结果。

开始猜想是不是词库没有包含日语的关系，后来仔细想了一想，mmseg对于没有在词典里的词应该是直接一元分词的，按理说也不应该出现无法索引日语的关系。我们可以通过mmseg命令行工具来证明这一点：

$ /usr/local/mmseg/bin/mmseg -d /usr/local/mmseg/etc/ 1.txt
ヨ/x ス/x ガ/x ノ/x ソ/x ラ/x

1 2	$ /usr/local/mmseg/bin/mmseg -d /usr/local/mmseg/etc/ 1.txt ヨ/x ス/x ガ/x ノ/x ソ/x ラ/x

证明mmseg进行了一元分词。

那么为什么coreseek搜不到假名呢？我找啊找啊终于发现在coreseek使用mmseg进行分词的过程中，对输入字符做了一个过滤，并且有一个注释：

// BEGIN CJK There is no case folding, should do this in remote tokenizer.
// Here just make CJK Charactor will remain. --coreseek
dRemaps.Add ( CSphRemapRange ( 0x4e00, 0x9FFF, 0x4e00 ) );
dRemaps.Add ( CSphRemapRange ( 0xFF00, 0xFFFF, 0xFF00 ) );
dRemaps.Add ( CSphRemapRange ( 0x3040, 0x303F, 0x3040 ) );

// BEGIN CJK There is no case folding, should do this in remote tokenizer.

// Here just make CJK Charactor will remain. --coreseek

dRemaps.Add ( CSphRemapRange ( 0x4e00, 0x9FFF, 0x4e00 ) );

dRemaps.Add ( CSphRemapRange ( 0xFF00, 0xFFFF, 0xFF00 ) );

dRemaps.Add ( CSphRemapRange ( 0x3040, 0x303F, 0x3040 ) );

可见coreseek虽然将CJK (Chinese, Japanese, Korean) 中所有汉字、全角字符和标点加入了范围，但是却漏掉了平假名和片假名。因此我们将第三个range改成0x3000, 0x30FF, 0x3000就可以修正这个问题。

其中：

// 4e00 - 9fff CJK unified ideographs
// 3000 - 303f CJK symbols and punctuation
// 3040 - 30ff Hiragana/Katagana
// ff00 - ffff half/fullwidth forms

// 4e00 - 9fff CJK unified ideographs

// 3000 - 303f CJK symbols and punctuation

// 3040 - 30ff Hiragana/Katagana

// ff00 - ffff half/fullwidth forms

我把修改后的版本放到了github

另外，这里可以查询到Unicode编码范围对应的字符内容；unicode.org有一个database，但是是一个列出了全部字符的大pdf，我似乎没有找到类似的分类。

对于Ubuntu/Debian，这里有编译好的coreseek的deb包：i386 amd64；依赖于mmseg：i386 amd64；mmseg自带的词典

对于>2.2.10的版本，我在这篇博客里提供了完整的补丁，可以应用在sphinx的源码上编译。

Python中热补丁(Hot Patching)的实现和一些问题

on 2016 年 1 月 11 日

Python

2 16474 转为繁体

有时候我们可能需要只修改一部分代码而且要求修改立即生效，或者为了高可用性不允许停止服务程序，这时我们就需要热补丁。

在debian，red hat等系统(或者vista之后的windows)的软件更新时，通常使用替换符号链接来达到高可用性。

对Python来说，解释器预先处理了脚本生成字节码，并读入内存；所以之后硬盘上的文件发生了什么变化，就只能想办法命令解释器重新读入新的脚本。实现这个功能的内建命令是reload

Let’s Encrypt！

on 2016 年 1 月 10 日

0 7353 转为繁体

试一下Let’s Encrypt

顺便前几天剁了Alpharacks的辣鸡vps，拿来做前端好了，听说国内效果ping不错（？

因为还有一堆微博图床上的图没法https，所以就不强行301了，你们看心情就好

点此进入作死模式

搭建一个不被审查的串流站点

on 2015 年 12 月 18 日

Web
作死

17 47583 转为繁体

原标题：被害妄想症该如何生存

先看配置：

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        listen 443 ssl default_server;

        root /usr/share/nginx/html;

        ssl_certificate certs/default.pem;
        ssl_certificate_key certs/default-nopass.key;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
        ssl_prefer_server_ciphers on;
}

server {
	listen 443 ssl spdy;

	ssl_certificate certs/real-cert.pem;
	ssl_certificate_key certs/real-cert-nopass.key;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
	ssl_prefer_server_ciphers on;

	root /usr/share/nginx/html;

	server_name example.com;
 
	location / {
                root /path/to/your/files;
                if (-d $request_filename) {
                        return 404;
                }
		try_files $uri $uri/ =404;
		charset utf-8; 
	}

               
        location ~ .*/$ {
                root /path/to/your/files;
                access_by_lua '
                        local coo = ngx.var.cookie_coo
                        if coo ~= "coo" then
                                ngx.exit(404)
                        end
                ';
                autoindex on;
                autoindex_exact_size off;
        }

}

server {

listen 80 default_server;

listen [::]:80 default_server;

listen 443 ssl default_server;

root /usr/share/nginx/html;

ssl_certificate certs/default.pem;

ssl_certificate_key certs/default-nopass.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;

ssl_prefer_server_ciphers on;

}

server {

listen 443 ssl spdy;

ssl_certificate certs/real-cert.pem;

ssl_certificate_key certs/real-cert-nopass.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;

ssl_prefer_server_ciphers on;

root /usr/share/nginx/html;

server_name example.com;

location / {

root /path/to/your/files;

if (-d $request_filename) {

return 404;

}

try_files $uri $uri/ =404;

charset utf-8;

}

location ~ .*/$ {

root /path/to/your/files;

access_by_lua '

local coo = ngx.var.cookie_coo

if coo ~= "coo" then

ngx.exit(404)

end

autoindex on;

autoindex_exact_size off;

}

假设：

审查机关拥有运营商级别的入侵检测设备（比如GFW）

说明：

全站使用https，关闭SSLv3，关闭弱加密组件
default_server开启80端口，使用自签名证书；真实需要访问的域名(example.com)必须使用有效的证书，或者在本地信任根证书。注意example.com不能开启80端口，且与default_server使用的证书不能相同。不要使用泛域名证书。这是为了防止审查机关通过直连IP查看返回的证书中的Common Name来得到真实域名。这样配置之后，直连IP https://xxx.xxx.xxx.xxx默认是返回自签名证书，无法得到真实example.com。
选择性开启autoindex，通过cookie鉴别。注意也可以通过HTTP Basic Authenication认证。对匹配文件夹的uri（”/”结尾）做认证，示例中只有带cookie coo=coo的请求才会返回autoindex，否则返回404。
在location /中禁用目录末尾自动加斜杠，因为如果自动加斜杠，审查机关可以通过暴力猜测出服务器上有哪些目录确实存在（返回了301到末尾加/的url）。方法是if (-d $request_filename)返回404。

修改闹钟应用支持Android 6.0 Marshmallow

on 2015 年 12 月 5 日

Android

1 33870 转为繁体

副标题：流氓应用Android6.0生存指南

我跟你们说，周三给五儿子升级了android6.0，周四起床失败，周五上课在下课前赶到，简直整个人都和吃了苍蝇一样。

而一切的根源都是因为我用了第三方闹钟应用而Android又踏马改休眠机制啦！

Category Archives

Let’s Encrypt集中化管理

让Coreseek支持索引日语假名

Python中热补丁(Hot Patching)的实现和一些问题

Let’s Encrypt！

搭建一个不被审查的串流站点

修改闹钟应用支持Android 6.0 Marshmallow