and then, it .....

Monday, May 23, 2022

更新 MacOS 後,修正常用工具項目(緩慢增加中) | The fix after installing the new version of MacOS

MacOS 的更新是 Mac 的賣點之一,修正了系統的錯誤 + 提供新功能 +滿足公司資安要求

*** Issues and Fixes *** 

Issue 1: 登入 ssh 連線時出現 LC_TYPE 錯誤。

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

manpath: can't set the locale; make sure $LC_* and $LANG are correct

修正方式:

- 修改 /etc/ssh/ssh_config

將 Host *下方的 SendEnv LANG LC_* 註釋取消




Issue 2: 

ssh 很快就自動斷線

修正方式: 

同樣是修正 ssh_config 檔案,將 Host * 這段下方加上

ServerAliveInterval 60      # To prevent a session from disconnecting after idle

AddKeysToAgent yes          # Must add on macOS 10.12.2 and above. Detail see here

UseKeychain yes             # Must add on macOS 10.12.2 and above. Detail see here

StrictHostKeyChecking no    # Do not show the fingerprint of the public key

IdentityFile ~/.ssh/id_rsa  # Private key file to forward




=== English Version ===

Updating MacOS provides the following upsides: 

- Bug Fix & Security Patches

- New Functions 

- Being compliant to the security requirement from the IT department. 

However, it may also introduce some issues after the update is deployed, the followings are the corresponding handle/fix for the issues. 

Issue 1. The LC_TYPE error while making a ssh connection to the remote server. 

ex:  -bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

manpath: can't set the locale; make sure $LC_* and $LANG are correct

Ans: You can fix this by modify you /etc/ssh/ssh_config file, which is the system-wide ssh connection setting of your MAC. By doing this, you need to comment the line of the 'Host *' section . 

#   SendEnv LANG LC_*

After it, you can connect your server with no such warnings.


Saturday, December 30, 2017

[以管窺天] AWS RDS Query Thruoughput 太高.

公司的網站在改版後, 雖然使用同樣的database (Aurora RDS), 但一直有個奇怪的現象.
每秒的select 數一直偏高. 工程師猜測應該只是RDS 統計介面的一個Bug...





Well, 在Google 的幫忙下, 我們找到了一個Script(run in python)可以做這統計.
https://www.centos.bz/2015/02/analysis-mysql-general-log/



After the new version of web site launched, we found that the number of select/sec goes high all the time. The db is running on AWS Aurora service with MySQL compatible. Engineer of my department says that is an bug of RDS, while I dont think so. After the great 'Google', we found a tool that could help us what are the often-run statements.



預設這個script 會將所有的資料印出在螢幕上, 為了使用方便, 建議轉向寫入檔案來觀看,
下圖是我們主機執行的結果 (query 內文先馬賽克起來 *笑*)
嗯, 前幾名加起來跑了超過100萬次. (一小時內). 後面看來有不小的調整要進行啊.


By default the script directly shows the result on STDOUT, and we suggest you may using I/O redirection to check it.
The following screenshot(with mozaic mask, lol), tell us that the top queries run more than 1,000,000 times in an hour. well, we have lot's of things to do...






Wednesday, December 20, 2017

[以管窺天] AWS S3 Bucket 定期清除舊檔案

不少人都有使用S3 的經驗, 但無論個人或者企業, 除非不用考慮$$ 的問題, 否則盡可能把錢花在必要之處是一定會需要注意的項目.

有時候我們會把EBS內的某些資料(or 臨時開立的EC2 主機中臨時產生卻需要留下的資料)留在S3 中, 或甚至把CDN Log 也放在裡面, 確保資料可用.


但, 留在S3中的資料, 有時我們不想保留那麼久....
如果是在UNIX 環境, 許多老一點的人大概都用過類似的command.

ex: find /var/log/nginx -mtime +30 -exec rm -f {};

為了刪除s3的檔案, 理論上我們也可以用類似的做法, 只要
a. 以s3fs 之類的程式掛載s3 到主機上
b. 以crontab 執行類似的command
c. 等, 然後期望在下次crontab起來前能跑完, 不要出包

溫馨提示: s3 的速度一般來說不怎麼快, 傳輸不快是一回事, 小檔案的操作更是不快.


上述方法理論可行, 實際上建議別這麼幹, 真心不騙.

這邊分享另一個作法.
簡單的步驟是:
1. 找到該s3 bucket
2. 設定 'expiration' 的天數
3. 收工(驚)

就跟菲姐做菜一樣, 就是這麼簡單.

其中步驟2.
選到對應的bucket 後, 點選 [management] 這個tab.
[選擇] lifecycle.
[選擇] add new rule
[填寫] 你想要設定的rule name
[填寫] 檔案的到期日(檔案create 後幾天會刪除
[填寫] 上傳檔案如果不完整, 幾天後要刪除
到下一頁再看一眼, 存檔, 建立規則.

簡單吧?



後記: 2017.12.20 凌晨00:38 分, 我也開始進行實驗. 第一次增加了rule.
為了測試效果, 我先將expiration period 改為 1day, 後續再來update 實際測試結果.








2017.12.21 紀錄:


2017.12.26 update.
忙了好幾天沒時間看S3, 今天一看, 檔案怎麼都還在, 照參考文件[3] 的修改方法又調整了一次, 讓我們來試試看吧.

2017.12.28 update.
搞了半天是prefix 輸入錯了, 然後, 當啷~ 成功了 :D


參考文章:
1. http://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html
2. http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
3. https://aws.amazon.com/tw/blogs/aws/amazon-s3-object-expiration/

Wednesday, December 13, 2017

[以管窺天] AWS EC2 主機的硬碟I/O 速度. EC2 i系列主機的高 I/O 速度實際測試.



提供虛擬主機(EC2) 給廠商時,  廠商回覆需要EC2 主機有高的硬碟I/O 速度,
我們以AS SSD Benchmark 測試實際速度時, 卻發現EC2主機(m4.2xlarge) I/O 速度很不理想.
和預想的情況有相當大落差




經過了一些交叉測試以及討論後. 得知:

1. EBS 的速度, 除了Provisioned IOPS(目前Max IOPS 32,000)外, 也受到主機網路速度的影響. m4.2xlarge 主機基本上是1Gb Network, 所以基於網路提供服務的EBS 磁碟效能也受到主機端網路頻寬限制. 白話文, IOPS 開再高, 實際虛擬機對外頻寬不足也只是空花錢..


2. 如果要快, 可改以本機硬碟(ex: i系列主機),  效能就噴發.
   溫馨提示1: i系列的SSD 預設沒有掛載, 需要在作業系統中自己掛載、分割、格式化.
   溫馨提示2: i系列一樣有一個EBS磁碟, 請把工作區擺在快的硬碟, 不然也只是白花錢....


在i3.2xlarge 提供的SSD 上跑出的賽豬公分數
同一台i3主機 但使用預設的EBS 時賽豬公




最後提醒.  若僅是DB 需要I/O 快, 或許RDS 是比較合適的作法.
1. 價格可能較為划算(算上了單機服務要設定redundancy 的effort 時)
2. 如果有輪子沒必要自己刻..


參考資料:
EBS 規格

Wednesday, May 26, 2010

自從某公司引進iPhone以來, 我很常被問到一個問題, 那就是, 為甚麼iPhone可以看Youtube影片, 而其它同樣使用Flash Video Solution的網站(如土豆網) 卻不行?

這個問題, 也許我們該從Flash & FLV 的關係說起.
自Flash 6 起, Flash 新增了播放Video 的功能, Flash 的檔案裡面有甚麼東西, 我們可以藉由下圖來說明(取自Adobe 網頁, Flash Platform的圖)




可以看到, Flash 就像一個容器(或稱為Container) 裡面包含了許多Component, 其中有一部份是處理Video的.
在某些情況下, 使用者不想要其它的功能, 只想留Video 的部份時, FLV就成了當然的產物.
或者, 我們從另一個角度來看這樣的情況, 在一個擺有Flash 想讓人看影片的網頁. 他會是像以下的情況


套句Shrek 的話, 很像Orge吧, 不是, 是很像洋蔥吧, 一層一層的.

簡單說完了Flash 和 FLV 的關係. 那麼, 回到原本的命題, 為甚麼iPhone 可以看Youtbue影片而不能看其它Flash Video 網頁呢?(如大陸很火紅的'土豆網')

我作了以下的實驗
1. 找一台裝有FireFox 和 "Modify Headers" Plug-in的電腦. 將iPhone的 user-agent value 設進headers.
2. 打開wireshark, 抓packet.
3. 在firefox 裡輸入http://www.youtube.com 點選影片開始播放.
4. 停止Capture, 從抓到的packet裡進行分析和推論.

我們發現, 在播放影片時, 會去對youtube網頁下一個GET command. youtube 會回傳一個 x-flv 的content type, 和對應的資料回來. 我們將這個URL 直接copy出來, 丟到chrome browser裡, 發現會被存成一個videoplayback(無副檔名) 的檔案.

這時, 打開KMPlayer. 將這檔案丟進player, 看player中帶出的檔案內容為何.



噹噹, 原來是一個FLV File!

根據Wiki 上的說法, iPhone是直接連到Youtube上的FLV 檔進行播放.

所以原本的命題我有了以下的推論.

當年Apple Youtube(Google) 談合作時, 為了讓兩邊要作的事情不要多到爆炸. 兩者達成一些協議,
其中至少包含了:
1. Youtube 配合將Content codecVP6(1) 轉為H.264 以提高Video quality. 在這之前
2. Apple iPhoneimplement 可以解Flash Video Library built-in Media Player 使用
3. Youtube 更改網頁, iPhone手機點選Video , 可以直接存取FLV file, 再由iPhoneMedia Player 繼續後續操作. 要注意的是, 這邊兩方的溝通是否有暗藏一些外人不了解的部份,目前無法得知.


我們來回頭驗證一下前面的3點推論.
第1點, 這是100% 確定的. (見前圖)
第2點, 如果有玩JB的朋友, 也許有聽過 MPlayer 這個iPhone AP, 這是個可以播放FLV 的Media Player.
個人相信一般的App不會願意實作一個新的Media player 出來, 使用既有的Library/API 是最快的方式.
第3點, 我們也從WireShark抓到的Packet中得到了證實.

那麼, 為甚麼一般Flash Video 網頁不能讓iPhone 看呢? 很簡單, 因為他們沒有作 1& 3 這兩點.
如果你的網頁有Flash Video, 又是以H.264進行encode, 也許, 可以考慮Youtube的作法, 作出一個Work Around, 這樣就可以省去deploy HTTP Streaming 的不少時間和精力.



Followers

About Me

My photo
有人叫我肯公, 有人叫我肯公公 或是 肯爺. 總之, 有肯, 又有老的感覺就是了