代碼 Archives - 第9頁共25頁 - 論野生技術&二次元

升級到Ubuntu16.04，開始接受systemd的調教

on 2016 年 4 月 22 日

Linux

7 18929 轉為簡體

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集中化管理

on 2016 年 4 月 7 日

9 11780 轉為簡體

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 15164 轉為簡體

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 17614 轉為簡體

有時候我們可能需要只修改一部分代碼而且要求修改立即生效，或者為了高可用性不允許停止服務程序，這時我們就需要熱補丁。

在debian，red hat等系統(或者vista之後的windows)的軟體更新時，通常使用替換符號鏈接來達到高可用性。

對Python來說，解釋器預先處理了腳本生成位元組碼，並讀入內存；所以之後硬碟上的文件發生了什麼變化，就只能想辦法命令解釋器重新讀入新的腳本。實現這個功能的內建命令是reload

Let’s Encrypt！

on 2016 年 1 月 10 日

0 8028 轉為簡體

試一下Let’s Encrypt

順便前幾天剁了Alpharacks的辣雞vps，拿來做前端好了，聽說國內效果ping不錯（？

因為還有一堆微博圖床上的圖沒法https，所以就不強行301了，你們看心情就好

點此進入作死模式

搭建一個不被審查的串流站點

on 2015 年 12 月 18 日

Web
作死

17 48900 轉為簡體

原標題：被害妄想症該如何生存

先看配置：

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。

Category Archives

升級到Ubuntu16.04，開始接受systemd的調教

OpenVZ

udev

mysql-apt-config

update-manager的編碼問題

Let’s Encrypt集中化管理

讓Coreseek支持索引日語假名

Python中熱補丁(Hot Patching)的實現和一些問題

Let’s Encrypt！

搭建一個不被審查的串流站點