先前試著逼自己用 Phabricator,用了一個多月後發現設計的邏輯還是跟 Trac 差了不少,算是為了 Facebook 特化的產品吧。在這一個月查資料的過程也發現當初 Wikimedia 要採用的時候也花了不少力氣送 patch 回官方,然後針對不少地方客製化調整。
另外比較痛的地方是 plugin 的支援能力還沒有很好,變成很多東西都要改主體... 而且效能也不太好 (不支援 PHP 7.0 還蠻痛的),在比較低階的 VPS 上跑特別明顯。
這幾天花了點時間把 Trac 給架起來,之前都是用 FreeBSD ports 架,但已經愈來愈沒有再接觸 FreeBSD 了,所以這次在 Ubuntu 上用 pyenv 裝起來再用 pip 裝起來。
另外一個跟之前不同的,是先前都用 Apache 接 mod_wsgi,在低階的 VPS 上則是要找省資源的方案,這次則是用 nginx + FastCGI 去接,比起之前複雜不少...
最主要是參考了官方的文件以及「Gentoo下使用nginx+fastcgi部署trac」這邊的說明達到效果,重點是這段 location
的設定:
location / { auth_basic "trac realm"; auth_basic_user_file /srv/domain.example.com/.htpasswd; include fastcgi.conf; fastcgi_param AUTH_USER $remote_user; fastcgi_param HTTPS on; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param REMOTE_USER $remote_user; fastcgi_param SCRIPT_NAME ""; fastcgi_pass unix:/var/run/trac/trac.sock; } location /.well-known/acme-challenge/ { alias /var/www/dehydrated/; }
網路上有找到用 location ~ (/.*)
去 match,然後拉出 $1
給 PATH_INFO
用的,這這會使得這段 location
的優先權太高 (參考官方對於 location
的順序說明),而蓋掉下面 Let's Encrypt 的 acme challenge 過程,所以還是得這樣搞。
另外是自己一個人用,就用 .htpasswd 的方式認證了,沒必要弄 LDAP 之類的認證...
接下來就是裝一堆 plugin 並且調整 css/js 與 SQL query 了...