AWS Lambda 的系統環境

Eric Hammond 在「Exploring The AWS Lambda Runtime Environment」觀察了目前 AWS Lambda 的系統環境。

不過這只是好奇性質而已,Amazon 本來就不保證不會改變:

For the curious, here are some results. Please note that this is running on a preview and is in no way a guaranteed part of the environment of a Lambda function. Amazon could change any of it at any time, so don’t build production code using this information.

因為可以執行 shell command,所以什麼都可以做 XD

工具的說明在另外一篇:「lambdash: AWS Lambda Shell Hack」。

Google Chrome 39 釋出,拔除對 SSLv3 的支援

看到 Google Chrome 39 釋出,拔除對 SSLv3 的支援:「Google Removes SSLv3 Fallback Support From Chrome」,官方的 post 反而沒有特別著墨這點:「Stable Channel Update」。

可以利用「POODLE Attack and SSLv3 Support Measurement」測試瀏覽器是否支援 SSLv3。

Ubuntu 上把 Chrome 拔掉 RC4 連線的方法

首先先看「SSL Cipher Suite Details of Your Browser」這個網站,會列出你目前瀏覽器支援的 cipher suite,會需要知道要拔掉哪些號碼。

接下來的資料是參考「Remove RC4 from SSL/TLS ciphers in Chromium」這篇的方法。

Ubuntu 的使用者可以到 /usr/share/applications/google-chrome.desktop 這邊修改,本來是:

Exec=/usr/bin/google-chrome-stable

改成:

Exec=/usr/bin/google-chrome-stable --cipher-suite-blacklist=0x0004,0x0005,0xc011,0xc007

其中的十六進位數字就是出自最前面提到的網站:

  • 0x0004 對應 RSA-RC4128-MD5,
  • 0x0005 對應 RSA-RC4128-SHA,
  • 0xc011 對應 ECDHE-RSA-RC4128-SHA,
  • 而最後的 0xc007 對應 ECDHE-ECDSA-RC4128-SHA。

這樣就可以將 RC4 禁用掉。

NCCC (聯合信用卡處理中心) 的網站不支援 AES 加密...

看到廉價航空機票在特價跑去刷,結果刷了兩次都死在聯合信用卡處理中心的 acs.nccc.com.tw 畫面出不來。突然想到我把 RC4 關掉了,該不會是這種原因吧...

跑去「SSL Report: acs.nccc.com.tw (210.61.215.16)」這邊一看,果然是不支援 AES

抱頭痛哭啊... 只好 rollback 回來 @_@

Salt 要做到「當某個檔案存在時,執行某個指令」的方法...

愈用愈有感覺 SaltStack 是一堆 workaround 的集合,一開始在設計整個系統時沒有規劃好,然後一直堆上去。

標題的這個問題是出自於 Ubuntu 預設會將 CPU 調節成 ondemand,方式是透過 /etc/rc*.d/ 下的 symbolic link 在開機時自動執行。

拔掉的方法是 updated-rc.d ondemand disable (而非直接砍掉 /etc/rc*.d/ 裡面的檔案),想要透過 SaltStack 提供的 file.exists 或 file.missing 都發現不可行。

最後是 cmd.run + onlyif + test 搞定:

ondemand-disable:
  cmd.run:
    - name: update-rc.d ondemand disable
    - onlyif: test -e /etc/rc2.d/S99ondemand

SaltStack 對於 dependency 的設計看起來問題重重,如果想要用 SaltStack 的人可以好好考慮一下。

現在的作法是直接 trial and error 跟他拼,PuppetChefSaltStack 都直接用時間跟他換。原因是這東西實在太底層了,架構不好就是上面的管理員與 DevOps 一直 workaround。

現在有種互相在比爛的感覺...

Netflix 在 USENIX/LISA2014 上講「Linux 效能調校」

NetflixBrendan Gregg 在「Linux Performance Analysis: New Tools and Old Secrets」這份投影片裡面給了很多有用的工具。

「先找出問題」一向是解決問題的大前提,在投影片裡提到了很多工具,像是這兩個看起來就很有用:

Google 資助圖靈獎 (Turing Award) 獎金至百萬美金

計算機科學領域裡的最高獎項,Turing Award,在 Google 的資助下,獎金從本來的 25 萬美金提升到百萬美金,ACM 的公告在這邊:「Google to Provide All Funding for Most Prestigious Award in Computing」。

諾貝爾獎的獎金是八百萬瑞典客朗,剛好大約是百萬美金 (約 USD$1.08M)。

這則新聞剛好跟「The Man Who Made the UK Say “I’m Sorry For What We Did To Turing.”」這篇報導一起看。

利用觀察流量的技巧可以抓出 81% 的 Tor 使用者

Slashdot 上看到「81% of Tor Users Can Be De-anonymized By Analysing Router Information」,原報導在「81% of Tor users can be de-anonymised by analysing router information, research indicates」。

PDF 論文在「On the Effectiveness of Traffic Analysis Against Anonymity Networks Using Flow Records」這邊。

當 Entry node 與 Exit node 都能夠被 Netflow 涵蓋觀察時,就可以利用流量資訊分析得到原始 Tor 使用者的原始 IP address,這意味著 ISP 與政府是有能力反匿名的。

但 Tor 其中一個目標是 low latency,繞太多節點以避開監控的速度會掉太多... 這不知道要怎麼取捨 :o

Facebook 研究用鋰電池當作 UPS 替代方案

Slashdot 上看到「Facebook Testing Lithium-Ion Batteries For Backup Power」,原報導出自「Facebook gives its server racks a Tesla touch」。

這讓我想到之前 Google 也做過類似的架構,不過是用蓄電池:「Google Finally Declassifies Some Key Server Design Secrets」。

上圖右上邊的那個區塊就是蓄電池。

Facebook 會考慮鋰電池是因為 Telsa 的需求使得價錢往下掉,進而考慮將本來的 UPS 換成鋰電池。