Creating symbolic link on NTFS

Windows 底下有一個 Installer 的資料夾，裡面主要是放 安裝程式的 MSI 檔案
如果任意移除會倒置很多應用程式無法正常運作
但是這個資料夾又非常佔用空間，勢必得想個方法把他搬到 D: 或其他地方

在 Linux 系統中有 ln 指令可以做 link 的動作
慶幸 Windows 中也有類似的工具 Junction，只要是 NTFS 的系統就有支援
下載點: http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx

安裝方式:
把解壓縮後的 junction.exe 複製到 \Windows\system32

使用方式:
junction dir1 dir2
這樣 dir1 就會成回 dir2 的 symbolic link 了

所以要把 Installer 移到其他硬碟的步驟為:

1. 搬移 C:\Windows\Installer 到 D:\Installer
2. junction C:\Windows\Installer D:\Installer

這樣當 Windows 存取 C:\Windows\Installer 的時候，就會自動轉向 D:\Installer 了

Windows 無法安裝列表機

今天幫朋友安裝列表機一直無法成功
安裝最後給的錯誤訊息是 "無可用的連接埠"
到 "列表機與傳真" 那邊嘗試新增列表機的時候
發現上面完全沒有可用的連接埠可以選
正常情況應該如下圖會列出很多選項

新增列表機的畫面(正常)

經過一翻 google, 最後在微軟[1]的網頁上找到類似問題的解法
根據微軟的說法, 是管理列表機連接埠的驅動可能被其他列表機取代
而導致與系統不相容
只要將驅動改回原本的 Windows 提供的即可

1. 啟動 「 登錄編輯程式 」 (Regedt32.exe)。
2. 找出下列機碼：
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\Local Port
3. 編輯 "Driver", 把字串值改回 "localspl.dll"
4. 按一下 [確定]，然後再結束「登錄編輯程式」
5. 重新啟動「多工緩衝處理器」(Print Spool)服務。

不過我遇到的問題卻是這個登錄表的值 存取被拒絕!!
這時需要把 Local Port 下面的所有子資料夾權限改回來才可
正常的權限應該如下

權限設定

但我這邊卻是一片空白，完全無法存取
修復方法是修改這些子資料夾的擁有者
改回 Administrators 就可以存取了

取回擁有權

參考資料:
[1] 沒有本地埠可供印表機: http://support.microsoft.com/kb/255507

解決 Java SecureRandom 過久的問題

【問題原因】
Java 的 SecureRandom 為了取得足夠亂、無法預測的 random data
會依據當時系統的 中斷、網路傳輸以及處理器負載 等資訊來產生
當系統處於閒置狀態時，便無法取得足夠多變異的資料來產生 random data
導致需要更多時間去完成這個動作

【解決方法】
啟動 Java 時，增加以下參數

-Djava.security.egd=file:/dev/./urandom

P.S 雖然他產生的亂度相對較低
但...除非是需要【極高/無法預測】的 key
不然還是愈快愈好 XDD

【可能會遇到此問題的軟體】

1. Hadoop system: HDFS namenode
2. Web server: Jetty

【參考文獻】
How to solve performance problem with Java SecureRandom?
Jetty: Connectors are slow to startup

Git through proxy authentication

How to git clone from https://github.com/FreeRDP/FreeRDP.git through proxy authentication.

Add git proxy configuration:
# git config --global http.proxy http://user:pass@proxy.server:port/

Troubleshooting:
add GIT_CURL_VERBOSE=1 environment variable for git
ex: GIT_CURL_VERBOSE=1 git clone https://xxx

使用 usbip 分享本機 usb 裝置到遠端電腦 - 網路報稅篇

再兩天就要截止網路報稅了，可是自然人憑證卻不在身邊
就突發其想有沒有辦法透過網路把遠端的 USB讀卡機 分享到本地端
找了一下 usb over ip 的相管資料，發現有 usbip 這個好用的小工具
支援由 linux 端分享 usb 裝置到遠端的 windows 系統

使用方式:
Server 端: 有實體 usb 裝置的機器需啟動 usbipd 把 usb 分享出去 (Linux)
1. usbipd 啟動 daemon
2. bind_driver --list 列出所有裝置編號, 如下範例:

- busid 2-4.1.1 (0424:2228)
2-4.1.1:1.0 -> usb-storage

3. bind_driver --usbip 2-4.1.1
恢復原本 local 使用:
1. bind_driver --other 2-4.1.1

Client 端: 使用 usb 装置端 (Windows)
1. 先由官方網站下載 Windows 的驅動程式，執行硬體安裝精靈安裝虛擬 USB 裝置
2. usbip --list server_ip 列出有分享的裝置
3. usbip --attach server_ip 2-4.1.1 連接遠端 2-4.1.1 的裝置
移除方式:
1. usbip --port 列出共用中的 USB 裝置
2. usbip --detach 2.4.1.1 即可

Reference:
http://usbip.sourceforge.net/

修改 MSS 解決 Linux PPPOE NAT 後部份網頁無法瀏覽問題

有用 Linux 當作家裡 ADSL 分享器/防火牆 的人應該會發現
有些網頁透過 NAT 後就是無法開啟
但是如果直接在 Linux 主機上卻又可以正常開啟
解決方法：
在 Linux Firewall 上增加以下 rule:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

搞定

為什麼呢？

這主要原因是因為 ppp 網路的 MTU 問題
MTU 的功能在於指定最大可傳輸的單一封包大小
當使用 ADSL(PPP) 時
會再封包裡另外增加 PPP 的 Header 導致單一封包會超過上限
為了解決此問題
一般會把 PPP 的 MTU 設定為原本 Ethernet MTU - 8 也就是 1492

TCP 傳輸方式有自動切割與組合封包的特性
MTU 的值就會被拿來當作 TCP 預設切割的大小(MSS)
MSS = Maximum Segment Size
每次建立 TCP 連線時
雙方會於 handshaking 時互相告知對方允許的 MSS 最後以小的為主
但 NAT 後的 PC 看到的是自己的 MTU 也就是 1500 而非 1492
因此會給對方過大的 MSS 建議
正常來說~當路由器收到大於自己可處理最大封包時
會透過 ICMP 回應給 sender
sender 接下來就會嘗試較小的 MSS
但大多數 ISP 會擋掉 ICMP 導致 sender 傻傻一直等待直到 timeout...

參考資料:
How to Setup a Linux Firewall with PPPoE/NAT/iptables

對於管理大量機器來說，每次新的機器第一次連線都會詢問 'yes' or 'no'
使用以下方式可避免第一次詢問，直接把該 host 加入

# ssh newhost -oStrictHostKeyChecking=no "command"

或是直接修改 /etc/ssh/ssh_config 把這個參數設定就不需要每次打


參考來源:http://wangmk.blog.51cto.com/651644/183939

ssh IP -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no "command"

这样的格式可以避免输入 yes ，可以再交互式脚本中使用

 
man 5 ssh_config
 
 
UserKnownHostsFile
      Specifies a file to use for the user host key database instead of ~/.ssh/known_hosts.
 
 
   StrictHostKeyChecking
      If this flag is set to "yes", ssh will never automatically add host keys to the ~/.ssh/known_hosts file,
      and refuses to connect to hosts whose host key has changed.  This provides maximum protection against
      trojan horse attacks, however, can be annoying when the /etc/ssh/ssh_known_hosts file is poorly main-
      tained, or connections to new hosts are frequently made.  This option forces the user to manually add all
      new hosts.  If this flag is set to "no", ssh will automatically add new host keys to the user known hosts
      files.  If this flag is set to "ask", new host keys will be added to the user known host files only after
      the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose
      host key has changed.  The host keys of known hosts will be verified automatically in all cases.  The
      argument must be "yes", "no" or "ask".  The default is "ask".