Month: May 2018

2018 五月 Packagist 看到的 PHP 版本分佈

在「PHP Versions Stats - 2018.1 Edition」這邊看到這次的統計資料了，可以看到會使用 Composer (以及 Packagist) 的 PHP 版本中，7.0+ 已經是 78% 了，半年前是 67% 左右...

除了 PHP 5.x 以外，PHP 7.0 也是 12 月要停止支援 (2018/12/3)，比 PHP 5.6 的支援期還早一個月左右 XD

Trac 的 DuplicateTicketSearchPlugin

DuplicateTicketSearchPlugin 是 Trac 的 plugin，在開新票時會搜尋系統內可能重複開過的票給出建議。

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

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

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

最近開的課程：程式進階效能優化實作

跟五倍紅寶石聊了蠻多方向的，決定合作開一門跟資料庫有關的課。上個禮拜先貼連結到我的 social network 上，但一直沒寫文章說明內容。所以就來寫文章推銷了：「| 五倍紅寶石 | 程式課程：?SQL 程式進階效能優化實作 - 台北假日班 | Accupass 活動通」。

這門課程預定在 5/26 與 6/2 上課，共 12 小時，分成兩個週六上課。課程主要是以 MySQL 的 InnoDB 為內容 (會採用 Percona Server 5.7 的系統)，在課堂上會有實際的 MySQL server 與 phpMyAdmin，可以拿預載好的 data set 實際練習。

由於是效能改善的主軸的課程，會從圍繞與效能有關的主題說明：

  • 有哪些資料結構可以使用。像是 VARCHAR 與 CHAR 的差異，以及對 Index 的影響。
  • 怎麼樣設計出符合正規化規範的表格，以及使用與不用的時機。
  • 當表格正規化後，有哪些方式可以取得資料。像是各式的 JOIN、GROUP BY 以及 subquery。
  • 在系統內 Index 要怎麼下才會有效率。
  • 怎麼看 MySQL 對一組 SQL query 的解讀，這邊會針對 EXPLAIN 的操作以及輸出結果。
  • 常見的效能問題，像是 ORDER BY RAND()、N+1 以及 LIMIT N,20 造成資料庫效能不佳以及改善的方式。

而這門課主要針對兩種客群：

  • 第一種是會對資料庫操作的 Programmer，像是後端工程師，全端工程師，或是 DevOps。由於課程內包括了系統上線前的設計與預防措施，以及上線後遇到狀況時的判讀與排除，對於 Programmer 來說是不可或缺的課程。
  • 第二種是管理資料庫的 DBA。在前期參與規劃資料表格設計時，可以提供精確的建議，以大幅降低後續維運上可能遇到的問題。以及當真的遇到效能問題，或是接手的系統就已經有效能問題時，提供可能的解決方案。

目標是透過這門課程，讓資料庫 (尤其是 MySQL) 被用的更淋漓盡致，而不是單純的遇到效能問題就加大機器。

nginx 推出了 1.14.0 的 PPA

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

這個版本使用了 OpenSSL 1.1.0，對 cipher 這塊最大的差異主要是包括了 CHACHA20 與 AESCCM 演算法。後者的 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。

Vultr 開始要收台灣的稅了...

這幾天收到 Vultr 的通知信，要收 5% 的稅了：

Dear Valued Client,

Vultr.com will start collecting a Value Added Tax (also known as VAT) for services provided after 2018 June 01 in order to comply with new Taiwan regulations. Beginning on 2018 July 1, your invoices will include an additional tax charge of 5% for customers who purchase electronic services in Taiwan. The tax is applied to comply with new Taiwan VAT legislation requiring non-residents who are providing "remote services" to begin collecting Taiwanese VAT on these services when they are provided to Taiwanese residents or persons who are not registered for VAT.

Affected customers need to submit their VAT ID to Vultr. If you don’t provide a business VAT ID, your account charges might increase.

If you have any questions about this upcoming change, please contact our support team today. Thank you again for being a customer!

The Vultr.com Team

從 2018 七月開始收...

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

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

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

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

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

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

Amazon Aurora for MySQL 支援 Point-in-Time Recovery 了

繼四月出 DynamoDB 推出的 PITR 後 (參考「Amazon DynamoDB 的 Point-In-Time Recovery」這篇)，Amazon Aurora for MySQL 也宣佈支援 PITR 了：「Amazon Aurora Backtrack – Turn Back Time」。

從截圖可以看到支援到秒層級：

然後最多 72 小時，會有額外費用：

這樣又讓 DBA 少了一些事情 XD

把本來 dehydrated 的 PPA 改成 dehydrated-lite

本來有做 dehydrated 的 PPA (在「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 自家的程式外 (像是 EC2、Lambda 之類的)，也能更新不是跑在 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 那邊繼續整理。