Home » Posts tagged "linux" (Page 2)

Google 推出 gVisor 強化 Container 的安全性

Google 發表了 gVisor,針對 Linux 所使用的 container 技術強化安全的部份:「Open-sourcing gVisor, a sandboxed container runtime」。

依照 Google 的說法,一般 container 的架構是這樣:

而具有強隔離性的 VM 技術則是這樣:

在 VM 的 overhead 偏重,但一般的 container 安全性又不夠。而 gVisor 則是這樣:

對於目前最常見的 Docker 系統上,在安裝 gVisor 後只需要指定 --runtime=runsc 就可以使用 (預設是 --runtime=runc),像是這樣:

$ docker run --runtime=runsc hello-world
$ docker run --runtime=runsc -p 3306:3306 mysql

其中 runsc 的意思是「run Sandboxed Container」。

另外而因為 gVisor 卡在中間,不認識的 syscall 都會被擋下來,所以目前並不是所有的應用程式都可以跑,但開發團隊已經測了不少應用程式可以在上面運作,算是堪用的程度:

gVisor implements a large part of the Linux system API (200 system calls and counting), but not all. Some system calls and arguments are not currently supported, as are some parts of the /proc and /sys filesystems. As a result, not all applications will run inside gVisor, but many will run just fine, including Node.js, Java 8, MySQL, Jenkins, Apache, Redis, MongoDB, and many more.

值得一提的是,雖然是處理 syscall,但是是用 Go 開發的,而不是 C 或是 C++,這點頗特殊的...

Ubuntu 18.04 推出

Ubuntu 兩年一度的 LTS 版本在前幾天放出來了,18.04 版的 code name 為 Bionic Beaver,官方有發出一篇介紹文章「Breeze through Ubuntu Desktop 18.04 LTS Bionic Beaver」,而下載可以在「Ubuntu 18.04 LTS (Bionic Beaver)」這邊抓。

因為不少新功能的穩定性沒跟上這次的 LTS (像是想要用 Wayland 換掉 X.org),所以目前看到的改變沒有想像中的大...

最主要的改變應該是不再提供 i386 版本,不過 x86-64 (AMD64 & Intel 64) 推出都已經超過十年了,加上要使用超過 4GB RAM 應該都會裝 x86-64 版本 (有人用 PAE 撐著嗎?),所以只要不是古董應該都沒問題...

另外一個則是預設從 Unity 換成 GNOME 了,用 Unity 已經算很習慣了,不知道之後換過去會有什麼感想... (到時再寫好了)

預定等一個版本再來換 (i.e. 18.04.1),現在不想當白老鼠 XD 不過手上一些 PPA package 要先 porting 過去...

出租 GPU 的服務...

前陣子在「Rent out your GPU compute to AI researchers and make ~2x more than mining the most profitable cryptocurrency.」這邊看到的消息,服務網站是「Vectordash: GPU instances for deep learning」。

起因是搞計算的弄不到顯卡計算,而雲服務的 GPU 又太貴,所以再找方法解決... 結果注意到 cryptocurrency 計算的獲利與雲服務的 GPU 中間有不少差價,於是就弄出一個服務來媒合手上有顯卡與需要科學計算的人,一邊提供較高的獲利給本來在挖礦的人,另外一邊提供較低的價錢給需要科學計算的人。

目前支援的平台有限 (Nvidia 的顯卡,另外不支援 Windows,不知道是不是 Linux only),其他支援目前都還沒列 ETA,不過感覺是個解決大家痛點的服務 (而且挖礦這邊就是在拼獲利),應該有機會弄得很大...

繼續觀望... XD

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

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

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

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

找了些資料並且測試,發現是 Linuxfontconfig 所設計的 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 找,然後依序是 CambriaTimes New RomanTimes,最後到 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。所以就來問問看有沒有人有建議...?

KPTI (Meltdown Mitigation) 對 MyISAM 的痛點

MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字,這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」),說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大:

Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).

他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速,在新版應該可以改善不少。但即使如此,文章內還是在實體機器上看到了 40% 的效能損失:

A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.

然後後面就在推銷 MariaDB 的 Aria Storage Engine 了,不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的,因為接下來五年應該都還是愈的到 KPTI,應該還是有人在用 MyISAM...

Ubuntu 18.04 LTS Minimal Image 的大小

看到「RFC: Ubuntu 18.04 LTS Minimal Images」這篇,在蒐集將來要出的 Ubuntu 18.04 LTS Minimal Image 的意見...

The Ubuntu Minimal Image is the smallest base upon which a user can apt install any package in the Ubuntu archive.

雖然應該還會有改變,不過以目前的版本來看,可以看出壓縮前後兩種版本都比 16.04 小了不少:

對需要這些 image 的人來說 (像是當作 Docker 的 base image),小一點操作起來也比較開心...

Ubuntu 18.04 將從 Wayland 換回 Xorg...

在「Ubuntu 18.04 LTS is Switching back to Xorg」這邊看到 Ubuntu 18.04 將要從 Wayland 換回 Xorg 的消息,只能說不意外 XDDD

Ubuntu 官方的說明在「Bionic Beaver 18.04 LTS to use Xorg by default」這邊,文章裡面給了三個理由:

  • Screen sharing in software like WebRTC services, Google Hangouts, Skype, etc works well under Xorg.
  • Remote Desktop control for example RDP & VNC works well under Xorg.
  • Recoverability from Shell crashes is less dramatic under Xorg.

講白了就是還有一堆東西有問題,看起來在 17.10 導入 Wayland 後沒搞定:

17.10, released in October 2017, ships with the Wayland based graphics server as the default and the Xorg based equivalent is available as an option from the login screen.

在 18.04 預設會用 Xorg,但系統內還是會有 Wayland 讓使用者可以選:

The Wayland session will still be available, pre-installed, for people to use, but for our ‘out of the box’ users the Ubuntu experience needs to be stable and provide the features they have come to expect and use in daily life and Xorg is the best choice here, at least for 18.04 LTS, but for 18.10 we will re-evaluate Wayland as the default.

再測個兩年吧 XD

Percona 版本的 MySQL 對於 Meltdown/Spectre 漏洞修復造成的效能損失 (Intel 平台)

而且這還不是完全修復,只是大幅降低被攻擊的機率...

PerconaUbuntu 16.04 上測試 MeltdownSpectre 這兩個安全漏洞的修正對於效能的影響。在原文標題就講了結論,為了修正 Meltdown 與 Spectre 兩個安全漏洞,效能的損失很明顯:「20-30% Performance Hit from the Spectre Bug Fix on Ubuntu」。

這邊測的結果發現,在 CPU bound 時的損失大約是 20%~25% (甚至到 30%),而 I/O bound 會輕一些,大約是 15%~20%:

We can see that in CPU-bound workloads the overhead is 20-25%, reaching up to 30% in point select queries. In IO-bound (25G buffer pool) workloads, the observed overhead is 15-20%.

在 comment 的地方 Percona 的人被問到 AMD 平台上效能會損失多少的問題,但因為他們手上目前沒有 AMD 平台的新機器所以不知道會有多少:

I do not have modern AMD servers on my hands right now

理論上 AMD 平台不需要處理 Meltdown 問題,損失應該會少一些,但沒測過也不曉得會是什麼情況... (像是 Spectre 的修正損失會不會比 Intel 還重,這之類的...)

另外補上早些時候的文章,當時 Ubuntu 上的 kernel 只有對 Meltdown 攻擊的修正,當時 Percona 的人也測了一次:「Does the Meltdown Fix Affect Performance for MySQL on Bare Metal?」,看起來對 Meltdown 攻擊的修正對效能的影響不太大,不過文裡有測試到 syscall 的效率的確如同預期掉很多。

Archives