Home » Computer » Network » Archive by category "Service"

Trac 的 DuplicateTicketSearchPlugin

DuplicateTicketSearchPluginTrac 的 plugin,在開新票時會搜尋系統內可能重複開過的票給出建議。

之前在寫 wiki 上的「Trac」條目時沒寫到,大概是最早的時候都沒裝,後來有人找出來要我裝的東西,所以印象沒那麼深刻。剛剛是在找 Trac + Elasticsearch 有沒有現成的方案可以搭,結果先看到這個...

產生的效果是這樣,在改變 summary 後會出現 (focus 從 summary 移開時):

當然就算裝了還是難免會重複開 (尤其組織夠大的時候),但算是有幫助的東西...

nginx 推出了 1.14.0 的 PPA

nginxPPA (「NGINX Stable : “Nginx” team」這個) 推出了 1.14.0 的版本。

這個版本使用了 OpenSSL 1.1.0,對 cipher 這塊最大的差異主要是包括了 CHACHA20AESCCM 演算法。後者的 CCM 指的是 CCM mode,這是當時 OCB mode 因為專利問題而發展出來的演算法,就目前的效能測試沒有 GCM 好,而且普及率也沒有 GCM 高,放進來應該是當備案 (當 GCM 有狀況時標準裡至少有方案可以選):

The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.

真正的重點在於 CHACHA20 的引入,讓 OpenSSL 重新有主流 stream cipher 可以使用了... 上一個主流 stream cipher RC4 被打趴好久了。

不過 TLSv1.3 要等 OpenSSL 1.1.1 才有 (參考「Using TLS1.3 With OpenSSL」這邊的說明),目前可以在設定檔裡面設 TLSv1.3 而不會出現錯誤訊息,但暫時還不會有效果...

關閉 Google Search 的 JavaScript

關閉 Google Search 的 JavaScript 速度快好多,而且左方會有「中文」與「繁體中文」的選項,以及時間的選項可以選,另外也沒有奇怪的界面效果...

我在 Google Chrome 裡是在這邊設定阻擋 www.google.com,如果你搜尋是用 .com.tw 網域的話則是設 www.google.com.tw

然後搜尋選項加上 gbv=1,這樣不會有重導:

不過這樣做的缺點是沒辦法使用 Google Maps,這個部份可以安裝「Simple JavaScript Toggle」,套件可以臨時打開 tab 這個網域的 JavaScript。

Bootstrap 的 CDN 從 MaxCDN 換到 StackPath (Highwinds) 了...

最近在寫網頁時發現 Bootstrap 的網站上給的 CDN 網址改了,從本來用的 maxcdn.bootstrapcdn.com (MaxCDN) 變成 stackpath.bootstrapcdn.com (StackPath,本來的 Highwinds)。

而且看起來跟 MaxCDN 的合作已經全部停了,現在 maxcdn.bootstrapcdn.com 也是指到 StackPath 上。

翻了 Wayback Machine 上的記錄,看起來是在 2018040904501720180410051321 這之間換的,也就是大約是在 2018/04/10 前後換的。不知道後面的交易是什麼...

可以參考 K 社的 SmokePing 資料「SmokePing Latency Page for netdna.bootstrapcdn.com (NetDNA, Bootstrap)」:

可以看到 HiNet 走的點的latency 比之前好不少...

把本來 dehydrated 的 PPA 改成 dehydrated-lite

本來有做 dehydratedPPA (在「PPA for dehydrated : Gea-Suan Lin」這邊),後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」),為了避免名稱相同但是內容物差很多,我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。

然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正,這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1),這點需要注意一下:

Don't walk certificate chain for ACMEv2 (certificate contains chain by default)

之後再找機會拔掉 gslin/dehydrated,也許會照著現在 APT 內的架構來做...

AWS CodeDeploy 跑在 On-Premises Instance 時的地雷...

AWS CodeDeploy 可以除了可以更新跑在 AWS 自家的程式外 (像是 EC2Lambda 之類的),也能更新不是跑在 AWS 裡的程式。比較明顯的差異就是跑在 AWS 內的 CodeDeploy 是不另外收費的 (應該需要同一區,不過沒特別提到),但跑在 AWS 外的需要收費:

For CodeDeploy on EC2/Lambda: There is no additional charge for code deployments to Amazon EC2 or AWS Lambda through AWS CodeDeploy.

For CodeDeploy On-Premises: You pay $0.02 per on-premises instance update using AWS CodeDeploy. There are no minimum fees and no upfront commitments. For example, a deployment to three instances equals three instance updates. You will only be charged if CodeDeploy performs an update to an instance. You will not be charged for any instances skipped during the deployment.

不過最近在測試的時候發現一堆雷,寫下來讓大家摸索的時候可以少痛苦一點... 之後 wiki 上的「AWS CodeDeploy」會持續更新。

第一個是在測試時,會反覆安裝練習,但會發現 Deregistered 後一直沒消失,而同樣名字的 instance 與 IAM 都不能再被使用。這個問題在 AWS 官方的 forum 上有被提到是 bug,而且目前沒有解 (deregister 後會有一段時間留在系統上),只能用 workaround 先處理 (用另外一個名字註冊),所以在練習的人得注意:「Deregister and register on-premise instance again」。

Thanks for your posting, this is a known bug on our side for deregister on-premise hosts. After you deregister an on-premises instance, you cannot create a replacement instance with the same name or the same associated IAM user name until AWS CodeDeploy deletes its records about the deregistered on-premises instance. This typically takes about 24 hours.

再來是跑 aws deploy install 的時候會裝 ruby2.0,但從前面的連結可以看到,ruby2.0 只在 14.04 上有,所以 16.04 (或是最新的 18.04) 都會安裝失敗。這點在 AWS 的 GitHub 上被戳了很多次,但目前都沒有下文:「Ruby 2.0 is unmaintained - also cannot install on Ubuntu LTS #61」、「eu-west-2 Agent Version Incorrect (ruby2.0 error) #92」、「ruby-2.0 won't work for recent ubuntu #2976」。目前我的 workaround 是自己裝 codedeploy-agent,隨便抓一區的 install 檔案裝就可以了。

然後是延續上一個問題,你雖然不在 AWS 內安裝 codedeploy-agent,但 install 檔案還是會去看看你是不是在 AWS 內... 而檢查的方法是去 http://169.254.169.254/ 裡挖資料,於是像 Vultr 也學 EC2 支援 http://169.254.169.254/ 的就會跟你說不能裝... 這邊的 workaround 是用 iptables -A OUTPUT -d 169.254.169.254 -j DROP 擋下來,重開機的時候這條消失沒關係,只要安裝時有擋下來就好。

最後是 AWS CodeDeploy 的 Web Console 後台上,On-premises instances 的 Matching instances 出不來,我是硬設下去發現 deploy 是有效的才發現 Web Console 這邊怪怪的。而且 On-premises 的 tag 部份不支援 *,也就是不能用 api-example-* 這樣去抓 (設下去也抓不到),但在 Amazon EC2 instances 的部份都是正常的 (Matching instances 看得到,* 也是有用的)。這點在 AWS 的 forum 上有翻到類似的現象,但不確定是不是同樣問題:「" Deployment Failed No instances found in deployment."」。

不過 On-Premises Instances 通常都是 non-cloud solution (實體機器或是租用 VPS),這個限制倒不是太大的問題,而且本來就有 tag 可以用了...

上面提到的問題也許會隨時間改善,即使過了幾個月或是幾年,歡迎在 comment 留言提醒修正... 我應該會在 wiki 那邊繼續整理。

Microsoft 啟用自己的 CDN 了...

在朋友的 tweet 裡看到微軟啟用自己的 Azure CDN 了,先前應該是提供 AkamaiEdgeCast 的服務:「Announcing Microsoft's own Content Delivery Network」。

看圖似乎是有台灣的點,不過我找不到可以測試 traceroute 的 endpoint,頁面上用的圖還是 EdgeCast 的啊 XDDD

;; ANSWER SECTION:
azurecomcdn.azureedge.net. 1604 IN      CNAME   azurecomcdn.ec.azureedge.net.
azurecomcdn.ec.azureedge.net. 3404 IN   CNAME   cs9.wpc.v0cdn.net.
cs9.wpc.v0cdn.net.      3404    IN      A       117.18.232.200

然後公測期間優惠價 50%:

Azure Content Delivery Network Standard from Verizon (S1) and Akamai (S2) and Microsoft (S3)*
*S3 is currently in public preview. CDN rates will be 50% of the stated price during this period.

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt,參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇),但測了一下不是我想要的效果,就找了一下網路上的資源,結果有找到還算可以的方案...

  • 先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
  • 然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt,會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係,可以之後再開。)
  • 然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME,一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理,而且有蠻多 header 可以設定,其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的),可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header,當設定 HSTS 之後,SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day),不過只拿來做 redirect 應該還好...

PS:如果有人要推薦其他的組合也歡迎...

Archives