nginx + fcgiwrap (spawn-fcgi) + Mailgraph

手上還是有固定一台機器是自己架設 Postfix 管理郵件系統,所以還是想跑個 Mailgraph 看一下有多少量在上面跑...

不過因為 Mailgraph 的 web interface 只有 CGI 界面,但 nginx 不支援 CGI,所以需要找個工具透過 nginx 支援的 FastCGI 轉換進去。

概念與設定都不算太難,但是得把工具找齊才會動 (這段花了不少時間),所以記錄一下怎麼做,以後找比較好找資料。

首先先裝 Mailgraph 與 fcgiwrap:

sudo apt install -y fcgiwrap mailgraph

這兩個程式預設都會跑起來。如果沒有的話自己用 sudo service fcgiwrap statussudo service mailgraph status。接下來在 nginx 的找個 virtual host 裡面這樣設:

    location /mailgraph/ {
        index mailgraph.cgi;

        location ~ \.cgi$ {
            include fastcgi.conf;

            fastcgi_pass unix:/var/run/fcgiwrap.socket;
        }
    }

然後把 Mailgraph 的 CGI 與 css 透過 symbolic link 建到 document root 的 mailgraph/ 下:

export DOCUMENT_ROOT="/srv/home.gslin.org"
cd "${DOCUMENT_ROOT}"
sudo mkdir mailgraph
sudo ln -s /usr/lib/cgi-bin/mailgraph.* .

接著重讀設定檔,或是重跑 nginx,就應該可以在 https://virtualhost.com/mailgraph/ 下看到了。

CGI 程式與 LD_PRELOAD...

在「elttam - Remote LD_PRELOAD Exploitation」這邊看到的技巧,記得以前有被提過 (還有 IFS 變數被拿來玩),但這幾年純 CGI 程式比較少了 (像是 nginx 不支援 CGI),所以有種新鮮感... (雖然不是新東西 XD)

這次中獎的是 GoAhead 這套 web server,被發 CVE-2017-17562,然後作者用 Shodan 翻了一下,Internet 上有不少肉雞可以玩:

當年 CGI 架構的餘孽 XDDD

關於圍棋貼目的問題...

前陣子 AlphaGo 大獲全勝後放出了五十盤自戰棋譜 (兩台 AlphaGo 自己下),其實有件事情有點出乎大家意料,而在圍棋界被一直討論。就是在這五十盤裡,黑棋與白棋的勝率比是 12:38 (中國規則,黑棋貼 7.5 目的情況),明顯白棋有強大的優勢。

這個 7.5 目指的是,由於黑棋先下 (先手優勢),所以圍的地會比較多,為了彌補白棋後下的這個缺點,一般都會設計「貼目」這個規則。

交大資工的 CGI 團隊在上個月月底發了一篇論文 (參考「CGOS Whole Period Ratings for 19x19 Board」這邊的記錄,在有參加 CGOS 的團隊裡只輸新版的 Zen),討論 value network 的新想法:「Multi-Labelled Value Networks for Computer Go」。

他們對貼目的數量做了分析:

For the training data, we label on output ?? as follows. For each self-play game, first calculate territory difference ? at the end of the game. Then, based on the Chinese rule, label 1 (win) on ?? for all ? < ?, and -1 (lose) for all ? > ?. (Note that the draw case ? = ? is ignored in this paper since the komi is not an integer normally.) For example, if black occupies 7 more points of territory than white, the ?-komi game is considered a win for all ? < 7, and a loss for all ? > 7. Thus, in this case, a 7.5-komi game is a loss, and a 6.5-komi or 0.5-komi game is a win.

這個研究完全顛覆了目前職業棋手一般的理解。目前的理解是,貼 5.5 目是黑棋優勢,貼 7.5 目是白棋優勢 (所謂的大貼目時代)。

接下來應該會有更多的研究出來,圍棋界會不會反思貼目規則呢...

舊 bug 新名字:httpoxy

依照慣例,security issue 都會取個名字,這次叫做 httpoxy:「A CGI application vulnerability for PHP, Go, Python and others」。

事情發生在兩個命名變數上的衝突:

  • RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) 定義了 CGI 環境會把 Header 裡的 Proxy 欄位放到環境變數裡的 HTTP_PROXY
  • 而很多程式會拿環境變數裡的 HTTP_PROXY 當作 proxy 設定。

這件事情 2001 年在 libwww-perl 就有發生過 (並且修正),curl 也發生過 (然後修正),2012 年在 Ruby 的 Net::HTTP 也發生過 (也修正了)。

然後在 2016 年還是被發現有很多應用程式會中獎... 這頭好痛啊 :o

Munin 的設定...

Munin 是套資源監視軟體。跟其他資源監視軟體不一樣的地方?畫面漂亮啊 XDDD 拿台堆各種雜物的 database 來看:

Munin screenshot

等到 Munin 監視超過二十台時就會很明顯感覺到很吃資源,再多的時候就會開始罵三字經,罵完後拆一台獨立的機器跑,以免跑個 vim 都要卡三秒... XD

這時候就是該調整了:

  • munin.conf 的 graph_strategy 與 html_strategy 都改成 cgi,告訴 Munin 在更新時只要更新 rrd 資料,而圖片與 html 的資料讓 cgi 做就好,這可以大幅減少 i/o rate。
  • rrdcached 跑起來,讓 rrd 資料寫入次數更少。rrdcached 的預設參數要記得調整。
  • 將網站本來用 CGI 的部份改成 FastCGI,其實對 nginx 之類的 web server 反而是簡化了 (因為 nginx 內建只支援 FastCGI 而不支援 CGI)。

另外有些討厭的地方,strategy 設定不能放到 includedir 裡,一定得放 munin.conf 本體,這對於自建 ports 的人有點麻煩... (得用 pkg-install 與 @unexec 去堆設定,可以參考 ports-mgmt/portconf/etc/make.conf 的作法)

用 Plack 提供的 CGI 跑 Adminer...

在「用 Plack 跑 CGI」提到用 Plack 跑 CGI,目的是把 PHP 寫的 Adminer (一個取代 phpMyAdmin 的工具) 跑起來。

文章裡提到 PHP 沒辦法以 CGI mode 執行,主要有兩個原因。一個是 PHP 本身有安全機制,php-cgi 必須在有 REDIRECT_STATUS 這個環境變數下才能執行,另外一個是 php-cgi 需要用到 SCRIPT_FILENAME 這個非 CGI/1.1 標準 (RFC 3875 - The Common Gateway Interface (CGI) Version 1.1) 的環境變數。

由於我只打算跑 Adminer,而 Adminer 的程式都放在同一個檔案裡,所以可以把這兩個環境變數設死惡搞:

env -i REDIRECT_STATUS= SCRIPT_FILENAME=/path/adminer.php /usr/local/bin/plackup -MPlack::App::CGIBin -e 'Plack::App::CGIBin->new(root => "/path")->to_app'

這樣就跑起來了...

用 Plack 跑 CGI

如標題,有時候總是有些奇怪的需求,想要用 CGI mode 跑一些東西,然後希望很簡單,最好不要動到系統設定,可以在不需要後完全不吃系統資源...

Plack 剛好提供了 Plack::App::CGIBin,可以接受 HTTP request 並丟給下面的程式...

跑起來的方式超簡單:

env -i /usr/local/bin/plackup -MPlack::App::CGIBin -e 'Plack::App::CGIBin->new(root => "/path")->to_app'

這樣會把 /path 下的東西當作 CGI script 跑...

不過 PHP 跑 CGI mode 超麻煩,並不是直接加上 #!/usr/bin/php-cgi 就能夠解決的,還沒找到要怎麼處理... (天曉得哪個環境變數又出問題了)