Month: March 2018

fontconfig fallback 機制與 CSS font-family fallback 機制的衝突...

自己搞不定，加上需要有圖才比較好理解，所以發篇文章問看看...

起因是在 Twitter 上發現某篇文章的截圖，在我的機器上顯示是 sans-serif 類的字型，而對方顯示的是 serif (看起來像是 Mac 的機器上)：

而翻了網站本身的 CSS 設定，發現是設成 serif，所以表示我這邊的設定有問題...

找了些資料並且測試，發現是 Linux 上 fontconfig 所設計的 fallback 機制跟一般人認知的不一樣，使得 CSS font-family fallback 機制直接失效...

在那篇文章的 font-family 設定是「medium-content-serif-font,Georgia,Cambria,"Times New Roman",Times,serif」，所以你會假設 medium-content-serif-font (這是 Medium 設定的 web fonts) 內沒有的字型會去 Georgia 找，然後依序是 Cambria、Times New Roman 與 Times，最後到 serif。

但在 Linux 下的 fontconfig 的設計則跟這點衝突。當你丟 medium-content-serif-font 查詢時，系統會將全系統有的字型都給你 (但是排序好)，而不是只有找 medium-content-serif-font 這個字型：

gslin@GSLIN-HOME [~] [22:11/W2] fc-match -s 'medium-content-serif-font' | wc -l
122
gslin@GSLIN-HOME [~] [22:11/W2] fc-match -s 'medium-content-serif-font' | head 
FreeMono.ttf: "FreeMono" "Regular"
FreeSans.ttf: "FreeSans" "Regular"
FreeSerif.ttf: "FreeSerif" "Regular"
opens___.ttf: "OpenSymbol" "Regular"
LinLibertine_R_G.ttf: "Linux Libertine G" "Regular"
Norasi.ttf: "Norasi" "Regular"
KacstOne.ttf: "KacstOne" "Regular"
FiraSans-Regular.otf: "Fira Sans" "Regular"
NanumGothic.ttf: "NanumGothic" "Regular"
fonts-japanese-gothic.ttf: "TakaoPGothic" "Regular"

而因為將所有系統內有的字型都放進去了，所以 font-family 第二個設定基本上都沒用了，因為我裝了一堆語系的文字... Orz

而我想要關閉這套機制，卻發現看起來關不掉：「How to block glyph fallback on Linux?」。

後來想要找 workaround 來解這個問題，不過看起來沒有堪用的 workaround。所以就來問問看有沒有人有建議...？

MySQL 8.0 的 innodb_dedicated_server

Percona 介紹了 MySQL 8.0 將會推出的 innodb_dedicated_server 參數：「New MySQL 8.0 innodb_dedicated_server Variable Optimizes InnoDB from the Get-Go」，Oracle 官方的文件在「15.6.13 Enabling Automatic Configuration for a Dedicated MySQL Server」這邊可以翻到。

這是針對整台機器完全給 MySQL 用的情況所設計的參數。在這種情況下，可以透過 RAM 的大小以及一些簡單的公式，得到還算堪用的系統參數...

依照說明，可以看到系統會依照記憶體的大小自動計算出 innodb_buffer_pool_size、innodb_log_file_size 這兩個參數，並且把 innodb_flush_method 設為 O_DIRECT_NO_FSYNC (如果所在平台有支援這個值)。

不過看了一下公式，依照經驗可以設的更積極一點... 像是 Percona 文章裡提到的，當記憶體夠大時，其實可以考慮從 80% 開始調整大小 (innodb_buffer_pool_size)：

For InnoDB buffer pool size (based on this article), consider allocating 80% of physical RAM for starters. You can increase it to as large as needed and possible, as long as the system doesn’t swap on the production workload.

而 innodb_log_file_size 則應該要分析寫入的 pattern 而不是直接看 RAM 大小。有些機器雖然很大台但幾乎沒有寫入的量，照著公式的值就偏大很多：

For InnoDB log file size, it should be able to handle one hour of writes to allow InnoDB to optimize writing the redo log to disk. You can calculate an estimate by following the steps here, which samples one minute worth of writes to the redo log. You could also get a better estimate from hourly log file usage with Percona Monitoring and Management (PMM) graphs.

不過基本上 tune 出來的值還算堪用，對於剛入手的人頗有幫助。

Facebook 在南韓因為太慢被罰錢？？？

看到「South Korea fines Facebook $369K for slowing user internet connections」這則新聞，裡面提到 Facebook 的 reroute 行為：

The Korea Communications Commission (KCC) began investigating Facebook last May and found that the company had illegally limited user access, as reported by ABC News. Local South Korean laws prohibit internet services from rerouting users’ connections to networks in Hong Kong and US instead of local ISPs without notifying those users. In a few cases, such rerouting slowed down users’ connections by as much as 4.5 times.

沒有告知使用者就導去香港或是美國的伺服器，聽起來像是 GeoDNS 的架構，以及 Facebook 的 CDN 架構幹的事情？不過在原報導裡面，另外一個指控是：

The KCC probed claims that Facebook intentionally slowed access while it negotiated network usage fees with internet service providers.

另外南韓官方也不承認使用者條款內的告知有效的：

Facebook said it did not violate the law in part because its terms of use say it cannot guarantee its services will operate without delays or interference. KCC officials rejected that argument, saying the terms were unfair. It recommended the company amend its terms of use.

現在看起來應該是要打官司？

TLS 1.3 進入 Proposed Standard

最近蠻熱的一個新聞，TLS 1.3 的 draft-ietf-tls-tls13-28.txt 進入 Proposed Standard 了 (在「draft-ietf-tls-tls13-28 - The Transport Layer Security (TLS) Protocol Version 1.3」這邊可以看到歷史記錄)：「Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)」。

沒意外的話這就會是最終版本了。如果要看 TLS 1.2 與 TLS 1.3 的差異，看維基百科上的 Transport Layer Security - TLS 1.3 會比較清楚。

大家等很久了... 像是 OpenSSL 1.1.1 其實一部分也是在等 TLS 1.3 正式推出：(出自「Using TLS1.3 With OpenSSL」)

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the meantime the OpenSSL git master branch contains our development TLSv1.3 code which can be used for testing purposes (i.e. it is not for production use).

主要還是期待非 NSA 派系的 cipher (其實幾乎都是 djb 的戰果) 與 1-RTT handshake，後續等 TLS 1.3 變成 Standard Track 應該就會被各家瀏覽器開預設值了...

Facebook 的 Certificate Transparency Monitoring 工具

前幾天找資料才發現原來 Facebook 很早就有提供 Certificate Transparency 相關的服務，可以用網域名稱搜尋查詢，甚至是訂閱：「Introducing our Certificate Transparency Monitoring tool」。

服務在「Certificate Transparency Monitoring - Facebook for Developers」這邊，搜尋與訂閱都可以在這邊處理。

打 tp.edu.tw 與 ntpc.edu.tw 可以看到不少學校都用 Let's Encrypt 的服務，像是「臺北市內湖區碧湖國小全球資訊網」這個 (雖然一進去就看到 flash...)。

Cloudflare 的 CT Dashboard

Cloudflare 發表了他們的 CT (Certificate Transparency) Dashboard：「Introducing Certificate Transparency and Nimbus」。前面的篇幅解釋 CT 是什麼，以及為什麼要存在，另外也大略解釋了一下 Google 要求要帶有 SCT (signed certificate timestamp) 的新規定 (基於 Browser 方，也就是 Google Chrome 的立場)。

再來就是講 Cloudflare 推出的 Dashboard，也就是 Merkle Town。這個網站提供了網頁操作界面，讓大家可以了解現在 certificate 的情況。

點了 Current 後，可以看到 Let's Encrypt 的比率相當高，但 Comodo 的量不算差 (以收費的情況來說)，再來是 DigiCert。

話說回來，當所有的 SSL certificate 都需要 SCT 後，相當於一般人就能夠很精確的統計市占率了，商業的憑證公司應該不是很開心... (當初 EV 也有類似的問題，不過現在 DV 已經被 Let's Encrypt 打趴了...)

AWS 提供模擬 Amazon Aurora 異常的測試功能...

在 Twitter 上看到 Jeff Barr 提到了在 Amazon Aurora 上的模擬 (這邊應該是講 MySQL)：

指到的頁面是文件「Managing Amazon Aurora MySQL - Amazon Relational Database Service」，翻了一下 Wayback Machine，看起來之前就有了，只是現在拿出來再宣傳一下：「Managing Amazon Aurora MySQL - Amazon Relational Database Service」。

透過主動觸發 Amazon Aurora 異常，可以測試整個系統的後續反應：

  • A crash of the master instance or an Aurora Replica
  • A failure of an Aurora Replica
  • A disk failure
  • Disk congestion

前面三種都屬於 Aurora 本身的故障測試，第四種除了有可能是 Aurora 本身的問題外，也可以測壓力過大時的情境 (i.e. 前面透過 auto scaling 撐住了，但後面的資料庫可能沒有足夠的能力支撐)。

PyPI 支援 Markdown

在「Markdown Descriptions on PyPI」這邊看到 PyPI 的網站要支援 Markdown 語法了，目前有 markdown-description-example 這個專案可以看效果。

同一個 package，舊的在「markdown-description-example 0.0.1 : Python Package Index」這邊可以看到，新的則可以在「markdown-description-example · Warehouse Preview (PyPI)」這邊看到。

code block 的地方看起來還不太好看，也許之後還會調整？

Amazon ECS 的 Service Discovery

AWS 宣佈了 Amazon ECS 也支援 Route 53 提供的 Service Discovery 了：「Introducing Service Discovery for Amazon ECS」。

也就是說現在都整合好了... 比較一下先前需要自己包裝起來套用的方式會少不少功夫：

Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system or connect every service to a load balancer. Now, you can enable service discovery for your containerized services with a simple selection in the ECS console, AWS CLI, or using the ECS API.

AWS 在 2016 年的時候有寫一篇「Service Discovery for Amazon ECS Using DNS」在講怎麼透過事件的觸發配合 AWS Lambda 把服務掛上去或是移除掉：

Recently, we proposed a reference architecture for ELB-based service discovery that uses Amazon CloudWatch Events and AWS Lambda to register the service in Amazon Route 53 and uses Elastic Load Balancing functionality to perform health checks and manage request routing. An ELB-based service discovery solution works well for most services, but some services do not need a load balancer.

現在看起來都可以改用 Auto Naming API 了...

Percona XtraDB Cluster 裡各種與 LOCK 相關的指令會產生的效果

在「FLUSH and LOCK Handling in Percona XtraDB Cluster」這邊看到在 Percona XtraDB Cluster 內各種不同形式的 LOCK 指令會有不同的效果。有些跟一開始用的印象已經不太一樣了...

FLUSH TABLE WITH READ LOCK 與 FLUSH TABLE <tablename> (WITH READ LOCK|FOR EXPORT) 都會直接讓整個 node 卡住，但 LOCK TABLE <tablename> READ/WRITE 就只會卡對應的表格，另外 GET_LOCK 本來應該是完全不支援，現在似乎變成 experimental 的功能了 (參考「PXC Strict Mode」這邊)，這樣一來 MogileFS 的資料庫部分就可以在上面跑了嗎？(當初就是因為這個問題而另外弄一組 DRBD + Heartbeat 的 MySQL 起來跑 XD)

之後看一下什麼時候加進去的...