自建 Mail System 的難度

Hacker News 上的「Ask HN: Is it possible to run your own mail server for personal use?」這篇道出了現在自建 mail system 的難度。作者遇到信件常常被各大 mail 服務歸類成 spam:

The problem is making sure my mail is not marked as spam by the major MTAs out there, gmail and hotmail both mark my mails as spam.

整理一下現在自己建 mail system 要做到哪些事情:

  • 確認 IP (包括 IPv4/IPv6) 沒有列入任何 Open Relay 清單中。
  • 確認 IP 的反解可以查出對應的正解。
  • 確認 SPF 設定。
  • 確認送出去的信件有 DKIM 簽名,而且 DNS 也有設上對應的設定。
  • 確認 TLS 的發送與接收都正常。
  • 確認 DMARC 機制正確運作。

如同「Exercising Software Freedom in the Global Email System」這邊講的,現在要自己搞 mail system 超累...

Linode 記憶體升級,以及新的日本機房計畫

Linode 的 13 歲禮物:「Linode’s 13th Birthday – Gifts for All!」。包括了記憶體的升級計畫:

Old Plan New Plan Price
Linode 1 GB Linode 2 GB $10/mo ($0.015/hr)
Linode 2 GB Linode 4 GB $20/mo ($0.03/hr)
Linode 4 GB Linode 8 GB $40/mo ($0.06/hr)
Linode 8 GB Linode 12 GB $80/mo ($0.12/hr)
Linode 16 GB Linode 24 GB $160/mo ($0.24/hr)
Linode 32 GB Linode 48 GB $320/mo ($0.48/hr)
Linode 48 GB Linode 64 GB $480/mo ($0.72/hr)
Linode 64 GB Linode 80 GB $640/mo ($0.96/hr)
Linode 96 GB Linode 120 GB $960/mo ($1.44/hr)

比較小的機器都是 double RAM,比較大的機器就沒那麼明顯了... 但這樣就超越 DigitalOcean 的規格,而且還領先其他 VPS 不少。

不過由於東京機房已經滿了,這次升級不包括在內,但也透漏了東京的新機房將會在今年年底前啟用:

Unfortunately, since Tokyo is sold out, the upgrade is not available there. We hope to have our second Tokyo facility online before the end of the year.

是個好消息 XD

Ubuntu 桌機的 Split DNS

Split DNS 指的是某個 DNS domain 使用另外一組 DNS servers,常用在 Partial Route 的 VPN 上,讓內部網域的 DNS domain 正確的被解出來。一般商業的 VPN Software 都會處理掉這塊,不過有時候還是希望可以自己設定...

Ubuntu 桌機上的 Split DNS 可以透過 Dnsmasq 做到,在我的機器上因為透過 ps awx | grep dnsmasq 可以看到 --conf-dir=/etc/NetworkManager/dnsmasq.d,表示設定的目錄在 /etc/NetworkManager/dnsmasq.d 下,所以我把檔案 mysplit 放到 /etc/NetworkManager/dnsmasq.d 下:

#
server=/mysplit.com/10.1.2.3

然後在 dnsmasq 的 manpage 裡面有提到,SIGUSR{1,2} 是拿來分析用的,而 SIGHUP 不是拿來給你重新讀設定檔用的 XDDD

SIGHUP does NOT re-read the configuration file.

所以就砍掉他,隨便對 NetworkManager 做個動作,就會重新把 dnsmasq 帶起來了,或者重開機也可以... 再跑 dig 查的時候就可以查到資訊了。

CloudFlare 的 Origin CA:保護 CloudFlare 到 Origin 這段的傳輸過程

CloudFlare 推出的 Origin CA 用來保護從 CloudFlare 到 Origin Server 這段的過程:「Introducing CloudFlare Origin CA」,也就是右半部這段:

CloudFlare 把這個新功能包裝得很神,但實際上只是弄個 CA 出來跑而已,僅此而已。

當然,由於他不需要處理 Public CA 的問題,所以有很多在一般 TLS 連線需要做的檢查步驟可以被簡化,藉此達到效能改善,包括了省掉 intermediate certificates、OCSP 以及 SCTs:

With Origin CA certificates, we’ve stripped everything that’s extraneous to communication between our servers and yours to produce the smallest possible certificate and handshake. For example, we have no need to bundle intermediate certificates to assist browsers in building paths to trusted roots; no need to include signed certificate timestamps (SCTs) for purposes of certificate transparency and EV treatment; no need to include links to Certification Practice Statements or other URLs; and no need to listen to Online Certificate Status Protocol (OCSP) responses from third-parties.

進而省下大量的連線成本:

Eliminating these unnecessary components typically found in certificates from public CAs has allowed us to reduce the size of the handshake by up to 70%, from over 4500 bytes in some cases to under 1300.

CloudFlare 宣佈支援 HTTP/2 的 Server Push

CloudFlare 宣佈支援 HTTP/2 的 Server Push:「Announcing Support for HTTP/2 Server Push」。

如同預期的 (最簡單的方式),是透過 HTTP header 標示,也就是透過 rel=preload 辨識:

Link: </asset/to/push.js>; rel=preload;

可以看到沒有 Server Push 與有 Server Push 的效能差異:

Apple 打算把 iCloud 加密用的 Key 放到用戶端

在經過最近 FBIApple 的戰鬥中 (FBI–Apple encryption dispute),Apple 正規劃把 iCloud 加密所使用的 key 放到用戶端裝置上,而非放在伺服器端:「Apple to Hand iCloud Encryption Key Management to Account Holders」:

In effect, Apple is following the lead of secure cloud services such as SpiderOak which has been offering what it calls “Zero Knowledge” cloud storage. By that, SpiderOak retains no information about whatever is stored in its cloud service, nor the means of gaining access to it.

也就是加解密都放在 client 端處理,server 端只是 storage。

這類型最大的問題是 server 端沒辦法運用資料,但 iCloud 的確可以放掉這些功能 (搜尋之類的),純粹當 storage 使用,藉以讓使用者自己裝置保護。

而蘋果在使用者的裝置上把類似於 HSM 的系統做的頗強大... 不知道 Android 有沒有機會也跟進。(雖然我自己是用 Apple 家的東西...)

AWS Database Migration Service

AWS 正式向所有使用者開放「AWS Database Migration Service」了:「AWS Database Migration Service」。

AWS 把前置作業 (setup & initial backup) 與 replication 的部份都包好,讓使用者可以很輕鬆的轉移。

支援的來源資料庫種類包括了這五種:

Supported database sources include: (1) Oracle, (2) SQL Server, (3) MySQL, (4) Amazon Aurora and (5) PostgreSQL. All sources are supported on-premises, in EC2, and RDS except Amazon Aurora which is available only in RDS.

支援的目的資料庫種類也包括了這五種:

Supported database targets include: (1) Amazon Aurora, (2) Oracle, (3) SQL Server, (4) MySQL, and (5) PostgreSQL. All Oracle, SQL Server, MySQL and Postgres targets are supported on-premises, in EC2 and RDS.

所以不只可以搬進 AWS,也透過在 EC2 instance 上架 Proxy 的方式搬出 AWS。比較特別的是可以不同 database 互轉?這好像可以玩玩看...

轉移的機器包括 t2.* 與 c4.* 兩種,一般來說 t2 系列的機器應該夠用,但如果要拼轉移速度的話可以拿 c4 出來撐場面。

Microsoft SQL Server 出 Linux 版...

微軟的 Microsoft SQL Server 將會推出 Linux 版:「Announcing SQL Server on Linux」。

看到 Ubuntu 這個關鍵字:

“We are delighted to be working with Microsoft as it brings SQL Server to Linux,” said Mark Shuttleworth, founder of Canonical. “Customers are already taking advantage of Azure Data Lake services on Ubuntu, and now developers will be able to build modern applications that utilize SQL Server’s enterprise capabilities.”

目前是 private preview,申請後測試:

The private preview of SQL Server on Linux is available starting today and we look forward to working with the community, our customers and our partners to bring it to market.

Route53 的 Health Check 支援 HTTPS SNI 了...

Route53 的 Health Check 總算支援 SNI 了:「Amazon Route 53 Adds SNI Support for HTTPS Health Checks」。

With SNI and HTTPS support, you can now create health checks for secure websites that rely on SNI to serve the correct website and certificate to requests for a particular domain name.

這功能早該出現啦,等好久了...

Stack Overflow 公開 2016 的架構

Stack Overflow 公開了 2016 年現在的系統架構:「Stack Overflow: The Architecture - 2016 Edition」。

Stack Overflow 的重要性可以從前陣子 Twitter 上流傳的一張讓大家笑的很開心的圖看出來:

身為目前「程序猿」(!) 最重要的 debug (!!) 資料來源,而且是目前少數用 ASP.NETMicrosoft SQL Server 作為網站與資料庫的架構,並且是放在傳統 IDC 機房而非 Cloud Service 的知名網站,大家也很好奇他們是怎麼堆出來的。

上次公開 Stack Overflow 的系統架構是 2013 年年底了 (參考當時寫的「Stack Overflow 的現況...」這篇),這份更新距離上次兩年多了,也有很多可以交叉比較的事情。

比較有趣的是效能的提昇的說明,本來以為會是說因為我們改善程式碼的效率或是其他類似的理由,結果居然直接說是因為買新機器了 XDDD:

You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That’s due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves.

另外覺得比較有趣的是 CiscoASR-1001ASR-1001-x,不知道是什麼理由選擇這個系列,改天找 Cisco 的朋友問問看好了...

另外他們的 Websockets 也拿來做有趣的事情:

We use websockets to push real-time updates to users such as notifications in the top bar, vote counts, new nav counts, new answers and comments, and a few other bits.

另外他們也發現有些瀏覽器連線已經連 18 個月了 (喂喂),也許應該去看一下人是不是還活著:

Fun fact: some of those browsers have been open for over 18 months. We’re not sure why. Someone should go check if those developers are still alive.

我猜是 production server 上開瀏覽器查資料後沒關掉,就一直連著...