維基基金會的 Git Server 從 Gerrit 換到 GitLab

這兩天受到注意的消息,維基基金會決定把 Git Server 從本來的 Gerrit 轉換到自建的 GitLab 上:「GitLab consultation」,在 Hacker News 上也有不少討論 (i.e. 戰文):「Wikimedia is moving to Gitlab (mediawiki.org)」。

先從官方的說法開始看,主要是 Gerrit 的運作方式與目前業界與社群的常用方式不同,也導致了 usability 不怎麼好,這使得社群與基金會的員工的學習成本偏高:

While Gerrit’s workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff.

另外也發現內部很多人會直接用外部的 Git 服務,了解後主要列出三個原因:

  • lower friction to create new repositories
  • easier setup and self-service of Continuous Integration configuration
  • more familiarity with pull-request style workflows

再來就是尋找與選擇的過程了,但其實市場上也沒什麼可以選的,從說明的 FAQ 部份可以看到 GitHub 與 GitLab,另外因為基金會的特性有強烈偏好 open source self-hosting 方案,基本上就是 GitLab 了...

不過如果是因為 code review 而決定換過去的話,我猜不完全是工具的問題,內部應該有不少政治上的問題,只是外面這次看不出來而已。

在 Hacker News 上的討論還蠻有趣的,有些前員工的發言點出了在 code review 時遇到的問題看起來不是這次換成 GitLab 可以解的。

Starlink 北美北部封測

看到 Starlink 的北美北部的封測消息了:「I just officially received an email invite to the Starlink beta.」。

大家最在意的費用部份,設定費 USD$499,月費 USD$99:

It's called the Better Than Nothing Beta.

  • Estimated speeds 50Mbps to 150Mbps
  • Estimated latency 20ms to 40ms
  • Some interruptions in connectivity to be expected
  • $499 for the phased array antenna and router
  • $99 per month subscription

翻了一下 Reddit 上面的討論,目標族群跟之前猜測的差不多,這對於地廣人稀地區的使用者 (像是阿拉斯加的村落) 多了一個替代方案:「Starlink is 600x better than my current ISP BEFORE you consider data cap. My jaw dropped when I saw the official numbers.」。

I live in a rural village in Alaska and pay around $200/mo for service that is running fast if it hits 500kbps with a 40GB data cap.

Half the price for up to 300x faster service? Elon please start launching some polar orbits.

另外從「Mods, could we get a stickied post for confirmed beta invited states?」這邊可以看到目前主要都是北美北部的州拿到邀請,應該是商業策略...

OpenBGPD 接 AWS Direct Connect 時只讓單區路由的方法

算是繼上篇「用 pfSense 接 AWS Direct Connect (Public VIF) 的方式」的改善,上篇的方法設定完後預設會是全部都會 routing 進來。也就是說,如果你接到新加坡區,美東 routing 也會進來。

這可能是你要的,但也可能不是你要的,所以找了一下方法,在 AWS 的文件裡面有提到可以透過 BGP community 控制這些 routing:「Routing policies and BGP communities」。

第一個方向是從 pfSense 送出去的封包,這個要過濾從 BGP 送進來的 routing table:

AWS Direct Connect applies the following BGP communities to its advertised routes[.]

把:

allow from 1.2.3.4

改成:

allow from 1.2.3.4 community 7224:8100

另外一個是讓 AWS 不要把我們的 network 送到其他區,這是在 network 上加上 BGP community tag:

You can apply BGP community tags on the public prefixes that you advertise to Amazon to indicate how far to propagate your prefixes in the Amazon network, for the local AWS Region only, all Regions within a continent, or all public Regions.

把本來的:

network 1.2.3.4/30

變成:

network 1.2.3.4/30 set community 7224:9100

先這樣搞,用 mtr 看了一下應該沒錯...

用 pfSense 接 AWS Direct Connect (Public VIF) 的方式

公司在菲律賓的辦公室因為常常會需要連到 AWS 傳輸影音資料 (新加坡,ap-southeast-1),但發現偶而會很不順,傳輸的時候會很卡,所以後來決定租了一條專線用 AWS Direct Connect 接進去。

不過因為跑在 AWS 上面的服務是掛在 public network 上,而不是 private ip 的網段,所以就不能用 IPsec site-to-site 打通收工,而需要搞 BGP routing,然後就卡關卡的亂七八糟 XD

首先是文書作業的部份,因為 AWS 對於 public network peering 需要證明你要交換的 IP address 是你自己的 (或是有被授權),這部份在 web console 上建立完 Public VIF 後會進入審核階段,接下來就要開 support ticket 提供 LOA-CFA 文件後才能繼續設定,我們這邊是從 ISP 申請 AWS Direct Connect 線路時拿到這份 PDF 文件。

這邊比較有趣的是,如果你沒有買 support plan 的話無法開 technical support,但官方有跟你說這邊可以 workaround 開 General Info and Getting Started 這個類別:「My public virtual interface is stuck in the "Verifying" state. How can I get it approved?」。

過了審核後接下來是設定 pfSense 的部份,因為是要接通 public network 的部份,所以你要收 AWS 提供的 BGP routing,這部份在 pfSense 上會透過 OpenBGPD 解決,但主要還是因為對 BGP 不熟悉,所以花了不少時間跟 AWS 原廠與台灣的 Partner 一起找問題,不然現在事後來看,自己 tcpdump 應該就有能力找到問題了...

主要的盲點是在我們的 AWS Direct Connect 裡面 BGP 需要走 TCP MD5 Signature Option。

這是一個 TCP extension,連線雙方有一把 shared secret 可以驗證每個 TCP packet 沒有被竄改:「Protection of BGP Sessions via the TCP MD5 Signature Option」。

要注意的是這個協定不是 application level,而是在 TCP 層本身就保護起來,包括 3-way handshake 的部份,所以從一開始 SYN 封包過去就要有 md5sig 的資訊。

這也表示用 telnet 不會通是正常的,這點讓我找問題找錯方向好久...

另外一點是 pfSense 的預設值不支援 TCP MD5 Signature Option (完全沒想過這個可能性 XDDD),這點在 pfSense 的「md5 bgp sessions fail in 2.4.0」這邊有提到:

Do you have "BSD Crypto Device" selected under System > Advanced, Misc tab, for Cryptographic Hardware? If not, select it there and try again.

That module is required for TCP_SIGNATURE to function.

If that works I can either add some warning text to Quagga and FRR or force it to load when that is enabled.

到了對應的選項那邊要選擇,因為我們的 pfSense 機器比較低階,沒有那堆硬體加速度的東西,所以選「BSD Crypto Device (cryptodev)」讓底層的 FreeBSD 去處理。

設定完後新的連線也還是不會有效果,後來想了一下還是整台重開機,然後就通了就通了就通了就通了就通了...

果然弄很久的問題都會是蠢問題,純粹就是不熟悉這些東西造成的。

抓出正在使用的 DNS Server

Hacker News 上看到的方式:「Which DNS」,另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。

這個方式是去抓 DNS server 對外的 IP,像 HiNet168.95.1.1 這種 DNS server 後面都有一堆 resolver,這個方式可以知道出去的 IP 是哪個,可以幫助分析 routing 之類的問題...

記得 Akamai 有類似的服務,不過查了一下沒找到之前有印象的那個,反倒是查到另外一組可以用的:「Introducing a New whoami Tool for DNS Resolver Information」。

Google 與 AWS 都釋出往 OpenTelemetry 靠攏的消息

前幾天看到 GoogleAWS 都釋出往 OpenTelemetry 靠攏的消息:「OpenTelemetry's First Release Candidates」以及「Public Preview – AWS Distro for OpenTelemetry」。

AWS 這邊的 AWS X-Ray 看起來跟 OpenTelemetry 有點關係,找了一下果然發現之前有些計畫在跑:「AWS X-Ray SDK w/ OpenTelemetry API」,不過看起來後續應該是由「AWS Distro for OpenTelemetry」這個計畫接手了。

另外 Google 這邊看起來則是 Cloud Trace 這個產品線,本來在推的 OpenCensusOpenTracing 從網站上可以看到決定會再支援兩年,但重心會改放到 OpenTelemetry 上:

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years.

翻了一下 Azure 相關的消息,先前有一些稿子是會往 OpenTelemetry 支援,但這一波沒看到新聞稿...

用 Amazon SNS 送簡訊可以固定發送號碼了

Amazon SNS 的簡訊功能可以申請固定發送號碼了:「Amazon SNS now supports selecting the origination number when sending SMS messages」。

固定的號碼包括了短碼與長碼:「Requesting dedicated short codes for SMS messaging with Amazon SNS」、「Requesting dedicated long codes for SMS messaging with Amazon SNS」。

短碼是三到七碼,依照地區而有差異:

A short code typically contains between three and seven digits, depending on the country or region that it's based in.

要注意的是短碼的部份需要開 support case 申請,而不是直接在 web console 上操作:

Open a case with AWS Support by completing the following steps.

長碼則是有可能到 12 碼,依照不同地區的設計有所不同:

A long code (also referred to as a long virtual number, or LVN) is a standard phone number that contains up to 12 digits, depending on the country that it's based in.

不過現在長碼的部份只有美國可以用,而且有速率限制:

Support for long codes is restricted to the United States only. Sending rates for long codes are restricted to 1 message per second. This restriction is set by the telecom carriers, and isn't a limitation of Amazon SNS. If you send a large volume of messages from a long code, wireless carriers might begin to block your messages. Your applications that use Amazon SNS should limit the number of messages that they send each second.

說道 Amazon SNS 送簡訊的費用,實在不怎麼好看,量小加減用 (包在 AWS 費用裡,省人力另外跑請款的單子),量大還是要找其他家接比較划算...

PayPal 也要提供加密貨幣服務

先是看到「PayPal to allow cryptocurrency buying, selling and shopping on its network」這篇,另外翻到了 PayPal 的新聞稿:「PayPal Launches New Service Enabling Users to Buy, Hold and Sell Cryptocurrency」。

幾個比較重要的地方是,這次會提供的是 BitcoinEthereumBitcoin Cash 以及 Litecoin 這四種:

To increase consumer understanding and adoption of cryptocurrency, the company is introducing the ability to buy, hold and sell select cryptocurrencies, initially featuring Bitcoin, Ethereum, Bitcoin Cash and Litecoin, directly within the PayPal digital wallet.

會先提供美國 PayPal 的使用者使用,然後再展到其他服務以及地區:

The service will be available to PayPal accountholders in the U.S. in the coming weeks. The company plans to expand the features to Venmo and select international markets in the first half of 2021.

另外這次的服務也不是自己跳進去搞,而是透過 Paxos Trust Company 建立起防火牆,所以當加密貨幣那邊出包的時候大概就會切割出來:

The service is enabled in the U.S. through a partnership with Paxos Trust Company, a regulated provider of cryptocurrency products and services.

比較像是個嘗試,只是這個主題很適合發新聞稿...

Amazon SNS 也支援 FIFO 模式了

看到 Amazon SNS 也支援 FIFO 模式了:「Introducing Amazon SNS FIFO – First-In-First-Out Pub/Sub Messaging」。

Amazon SQS 在 2016 年就已經先支援了:「Amazon SQS 支援 FIFO 了」,官方的文件可以在「Amazon SQS FIFO (First-In-First-Out) queues」這邊翻到。

在使用 FIFO mode 時與 SQS 有一樣的速度限制,每個 topic 只能到 300 TPS:

You can use SNS FIFO topics in all commercial regions. You can process up to 300 transactions per second (TPS) per FIFO topic or FIFO queue. With SNS, you pay only for what you use, you can find more information in the pricing page.

不過之前有需要保持順序的應用應該都先用 SQS workaround 了,不然就是自己搞能夠 FIFO 的 pub/sub 架構了。

Atlassian 將消滅 Server 版本

Hacker News Daily 上看到 Atlassian 打算消滅 server 版本:「Moving to a cloud future, together」。

話說回來,之前工作時用 Jira 的時候 (雲端版本),所有人都抱怨 Jira 慢到爆炸的問題不知道解了沒,當時記得每個按鍵都要 10+ 秒才會反應,不管是在台灣還是在香港都很慢,然後在公司反應了十個月也都沒什麼改善 XD

至於官方說要推 cloud 版本的理由聽聽就好,Hacker News 上有些討論反而還蠻有趣的,像是講到裡面同時在維護 Cloud 與 Server 版本時遇到的問題,看起來團隊沒有足夠的能量處理這些東西:「Atlassian moving to cloud-only, will stop selling server licenses (atlassian.com)」。

另外一個是討論裡面提到的替代方案,看起來也不算很好的替代方案啊,出現 MediaWiki 作為 Confluence 的替代品,少了 WYSIWYG 其實門檻高不少耶...

來看看這波反應會有多大 XD