Home » Articles posted by Gea-Suan Lin (Page 2)

把本來 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 那邊繼續整理。

把 Blog 換成 PHP 7.2

去年十一月出 PHP 7.2,現在已經更新到 7.2.5,各家軟體的相容性也都修的差不多了,差不多該升級了。

在「PHP 7.2 的效能改善」這邊有提到與 PHP 7.1 的效能改善主要來自於同時間有多人同時存取時的最佳化。

同樣 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:如果有人要推薦其他的組合也歡迎...

加州打算強制規定新房子都要有太陽能...

加州打算直接從法律上規定從 2020 年開始的新房子都要有太陽能:「California set to become first US state requiring solar panels on new homes」。

The state’s Energy Commission is due to vote next week on new energy standards that would require virtually all new homes to be constructed with solar panels from 2020.

如果通過的話,從 20% 直接變成強制性的 100%:

Currently around 20 per cent of single-family homes are constructed with solar capacity built in, but if the new standards are approved as expected this proportion will rise sharply.

下個禮拜回來看看消息好了,這應該是蠻指標性的事情... 無論是在經濟上還是在環保題材上。

MySQL 的 binlog 對效能的影響

Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性,再加上 MySQL 8.0 有改變 binlog 相關的預設值,所以他後續花了不少時間測試,寫了兩篇關於 binlog 對於 MySQL 效能的影響:「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。

第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響,做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌):

而其中的 workaround 就是調整 flush 參數,讓他比較頻繁的小量寫入,而不是突然要寫很多資料。這樣一來對平均效能也許比較差,但對前端應用衝擊會比較小:

在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字:

The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.

另外有測試 ext4 與 XFS 是否有影響,就測試的結果看起來 ext4 比 XFS 好一些,但差距有限:

第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較,可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失:

It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.

雖是推銷一下自家產品在這塊還不錯 XD

7-Zip 的 RCE 安全性問題

7-Zip 被發現安全性問題 (CVE-2018-10115):「7-Zip: From Uninitialized Memory to Remote Code Execution」。而在 2018/04/30 推出的 18.05 修正了這個問題:「7-Zip 18.05」。

The vulnerability in RAR unpacking code was fixed (CVE-2018-10115).

除了修正以外,另外也開了 ASLR,對安全性會多一些防禦:

2018-03-06 - Discovery
2018-03-06 - Report
2018-04-14 - MITRE assigned CVE-2018-10115
2018-04-30 - 7-Zip 18.05 released, fixing CVE-2018-10115 and enabling ASLR on the executables.

手上有裝 7-Zip 的人要記得更新...

Archives