Caddy Server 要採用 Open Source...

Caddy Server 是一套 HTTP Server,目標是讓使用者可以很容易設定一個安全的 HTTP Server。

程式碼本身是 open source (採用 Apache License 2.0),但官方包出來的 binary 則是限制個人免費使用或是購買訂閱,但如果你自己編譯打包的話又還是 open source license,是一個很奇怪的商業模式...

再加上看到他的設定檔的格式後,發現他包太多東西了 (連 markdown 相關的處理都包進去),實在是不愛這種設計 (感到遲早會有滿滿的 CVE),而 nginx 就是把 HTTP Server 相關的業務處理好,相較起來就懶的理了...

現在看起來 Caddy Server 應該覺得這樣沒賺頭而決定把訂閱拿掉,全部都開放出來:「Proposal: Permanently change all proprietary licensing to open source」。

但比較奇怪的還是,這件事情其實你也不用徵求社群意見,你們自己公司內部確認好就好,這個比較像是 PR 而已...

Apple 新的「Find My」帶來的隱私問題

這次 WWDC 推出的新功能,已經有人在討論機制與隱私問題了:「How does Apple (privately) find your offline devices?」。

前一代的「Find my iPhone」需要透過網路與 GPS 資料才能在系統上看到,這一代則是加上 BLE beacon,然後任何一台 iOS device 收到後就回傳回給蘋果:

Every active iPhone will continuously monitor for BLE beacon messages that might be coming from a lost device. When it picks up one of these signals, the participating phone tags the data with its own current GPS location; then it sends the whole package up to Apple’s servers.

幾個隱私問題在於,代傳的 iOS device 也會暴露位置資訊給蘋果,另外收到 BLE beacon 的 iOS device 本身是否可以解讀遺失機器的資訊?而商家看起來也可以利用這個方式主動發送攻擊而得知不少資料 (像是文章裡提到先前蘋果透過 randomize mac address 加強隱私的問題,這邊又多開了一個洞),現在蘋果給的資訊還不夠清楚,需要真的逆向工程確認才知道...

從 Microsoft SQL Server 轉移到 PostgreSQL 的工具

在「How to Migrate from Microsoft SQL Server to PostgreSQL」這邊看到作者的客戶需要把 Microsoft SQL Server 轉移到 PostgreSQL (但沒有提到原因)。

裡面主要是兩個階段的轉換,第一個階段是 schema 的轉換,作者提到了 dalibo/sqlserver2pgsql 這個用 Perl 寫的工具:

Migration tool to convert a Microsoft SQL Server Database into a PostgreSQL database, as automatically as possible http://dalibo.github.io/sqlserver2pgsql

第二個階段是資料的轉換,是選擇用 Pentaho Data Integration 的 Community Edition:

Pentaho offers various stable data-​centric products. Pentaho Data Integration (PDI) is an ETL tool which provides great support for migrating data between different databases without manual intervention. The community edition of PDI is good enough to perform our task here. It needs to establish a connection to both the source and destination databases. Then it will do the rest of work on migrating data from SQL server to Postgres database by executing a PDI job.

所以用兩個工具串起來... 另外在文章裡面沒提到 stored procedure 之類的問題,應該是他們的客戶沒用到或是很少用到?

從二月開始不回應 EDNS 的 DNS server 將會無法查詢

在「DNS flag day」這邊看到 EDNS 的 workaround。

目前的 workaround 是在 DNS server 對於 EDNS 查詢沒有回應時,就改用不帶 EDNS 的查詢再問一次,以確保相容於不支援 EDNS 而且會直接過濾掉這些封包的環境。

而從今年二月開始,這個 workaround 將會被拿掉,當帶 EDNS 的查詢沒有回應時就直接當作伺服器死掉,不會再用沒有 EDNS 的查詢問一次:

The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.

This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.

往下可以看到會做出改變的廠商包括了 GoogleCloudflare,可以預期 8.8.8.8 (8.8.4.4) 與 1.1.1.1(1.0.0.1) 都會進行更新。

網站上面有可以查詢的工具,剛剛查了一下以前的公司與競爭對手,發現 1111.com.tw 看起來會掛掉,不知道二月前會不會修正這個問題... XD

24 Core 的 ARM Server...

在「Banana Pi to Launch a 24-Core Arm Server」這邊看到 Banana Pi 打算推出 24 core 的 ARM server...

看起來還蠻不錯的:

We have 24-core Arm Cortex A53 processor with 32GB RAM (29.4GB seen by the OS) running Ubuntu 18.04.1 LTS with MATE desktop. There aren’t that many 24-core Arm Cortex A53 processors, so unless the company is using an announced processor, it has to be SocioNext SC2A11 processor also found in Linaro Developer Box.

拿來當 desktop 好像也不錯,不知道最終的定價會是多少...

Percona 推出 MySQL 8.0 的對應版本了...

Percona 在過節前推出 Percona Server for MySQL 8.0 了:「Announcing General Availability of Percona Server for MySQL 8.0」。

Oracle 版的 MySQL 8.0 多了不少功能,像是往 NoSQL 靠的功能與 GIS 相關的功能,但讓我注意到的是 Percona 自己的事情... TokuDB 因為 MyRocks 而要被放生了:

Features Being Deprecated in Percona Server for MySQL 8.0
TokuDB Storage Engine: TokuDB will be supported throughout the Percona Server for MySQL 8.0 release series, but will not be available in the next major release. Percona encourages TokuDB users to explore the MyRocks Storage Engine which provides similar benefits for the majority of workloads and has better optimized support for modern hardware.

Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft,但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響,所以就找了方法讓兩者並存:「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS,可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料,如果裡面有看到想要使用 TLS 1.3 的訊息,就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑:

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼,將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑,就比較不用擔心本來的 stack 會有狀況了。

在 MySQL 上遇到 Replication Lag 的解法

看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決:「MySQL High Availability: Stale Reads and How to Fix Them」,另外在留言也有人提到 Booking.com 的解法:「How Booking.com avoids and deals with replication lag」。

在業務成長到單台 MySQL server 不夠用的情況下,最簡單的擴充方式是架設 slave server,然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split),但因為 MySQL 的 replication 是非同步的,所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料,也就是 replication lag。

這就大概有幾種作法,一種是當發現 lag 時就回 master 讀,但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看,但這個方法就不保證讀的到東西,因為有可能所有的 slave 都 lag。

以前遇到的時候是拆情境,預設還是 R/W split,但敏感性的資料處理以及金流相關的資料就全部都走 master。

不過文章裡的解法更一般性,在寫入時多寫一份資料,然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...

同樣的想法,其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊,然後在 slave 等待這組 binlog 或 GTID 被執行。

看起來算是很不錯的解法,不知道各家 framework 對這些方式的支援度如何...

EC2 支援休眠

AWSEC2 instance 推出了休眠模式:「New – Hibernate Your EC2 Instances」。

休眠模式主要是透過保留記憶體內的內容 (會寫到 EBS 裡),讓機器開起來比較快,不過這邊有要求 root EBS volume 需要加密:

When an instance is instructed to hibernate, it writes the in-memory state to a file in the root EBS volume and then (in effect) shuts itself down. The AMI used to launch the instance must be encrypted, as must the root EBS volume of the instance. The encryption ensures proper protection for sensitive data when it is copied from memory to the EBS volume.

費用的部分是 EBS volume 與 Elastic IP:

While the instance is in hibernation, you pay only for the EBS volumes and Elastic IP Addresses attached to it; there are no other hourly charges (just like any other stopped instance).

一般對外服務的伺服器好像用不太到... 應該是內部系統或是開發機的需求?

AWS 允許 Hybrid Cloud 下的 DNS Query

AWS 對於 Hybrid Cloud (混合雲,通常是講與傳統機房的混搭應用,也就是雲端跟地端的混搭) 推出兩個功能,一個是讓 AWS 的 DNS Resolver 對於某些 domain 可以回機房端查詢 (雲端查詢地端 domain)。另外一種是反過來,讓機房端的 DNS Resolver 可以查 AWS 這邊的資料 (地端查詢雲端 domain):「New – Amazon Route 53 Resolver for Hybrid Clouds」。

兩者都可以自己幹,但就得花功夫自己架設,而且有很多細節得處理:

  • 建立 EC2 instance,在上面跑 Unbound,然後 EC2 instance 的 DNS servers 設定要指到這邊。
  • 由於 EC2 的 DHCP 服務沒有辦法指定發放的 IP range,所以為了多重意外而中獎 (關機的時候剛好有其他機器 DHCP 拿到這組 IP),需要開獨立的 subnet 只放固定 IP 的服務。
  • 為了系統的穩定性,需要在兩個不同 AZ (或是三個) 架設這些 DNS Resolver,所以對應有兩個或是三個 subnet 得建立。

而地端到雲端通常會簡單一些,因為地端通常都已經有內部的 DNS Resolver 可以用,通常只需要在雲上面有 proxy 的角色就可以解決。

不過現在這些 AWS 都直接提供了:

常見的區域都可以用:

Hybrid Cloud is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Asia Pacific (Singapore), with other commercial regions to follow.

費用的部分不算便宜 (跟自己弄三台 t3.nano 比起來),但畢竟不需要自己管理,而且對於已經有機房的單位應該只是零頭而已:

Route 53 Resolver remains free for DNS queries served within your VPC. Resolver Endpoints use Elastic Network Interfaces (ENIs) costing $0.125 per hour. DNS queries that are resolved by a Conditional Forwarding Rule or a Resolver Endpoint cost $0.40 per million queries up to the first billion and $0.20 per million after that.