2017年5月11日 星期四

Debian 6.0 VM 複製到 ESXi 6.0 網路卡問題

Debian VM原運作於VMWare Player,因匯入失敗,乾脆將整個目錄(含vmdk檔等)直接上傳到ESXi資料存放區

由於檔案格式不同,先用以下指令轉換為ESXi相容格式

   vmkfstools -i <原vmdk檔> <新vmdk檔>


建立VM後成功啟動系統,發現網路卡都沒出現



Google搜尋結果:

正確運作的系統會由udev於開機時偵測到網路卡,自動建立設定檔為/etc/udev/rules.d/70-persistent-net.rules。但我的/etc/udev/rules.d/下沒這個檔案!

執行 ifconfig -a 有看到 eth0 裝置,不過 ifup eth0 失敗

重新開機數次,確認系統不會自動找回網路卡



一番瞎搞後,終於成功救活,紀錄如下:

(此非正規作法,請斟酌參考,專家勿罵,留言批評者請順便提供正確教學)
(作法參考某論壇國外先進討論串,但已搜尋不到該文,對不起~)



1.手動讓它產生正確的 70-persistent-net.rules 檔

   a.下指令 ifconfig -a 找出正確的 eth0 mac 位址如(00:a0:11:22:33:44)

   b.複製原script(幫不上忙的那個)準備手動執行

      cp /lib/udev/write_net_rules /lib/udev/my_net_rules


   c.編輯手動版script (vi /lib/udev/my_net_rules),加上


      INTERFACE=eth0

      MATCHADDR="00:a0:11:22:33:44" << 步驟a 抄下來的 mac位址
 

   d.修改權限

      chmod 744 /lib/udev/my_net_rules

   e.執行!

      /lib/udev/my_net_rules

   f.檢查結果

      /etc/udev/rules.d/70-persistent-net.rules  出現!!!




 

2.測試新的設定檔

   a.重新載入設定檔

      /sbin/udevadm control --reload-rules

   b.手動啟動 eth0

      ifup eth0

   c.看看結果

      ifconfig
   (此時應該要有eth0了,沒有就是.....失敗)


 
其實還有些細節,寫多了偏離主題,下方網路設定檔供參考

/etc/network/interfaces 檔案內容

auto eth0

iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameserver 168.95.192.1

如果 ifup eth0 得到 don't seem to have all the variables... 錯誤,檢查上面這個檔的內容





2017年3月15日 星期三

VirtualBox匯出之OVF,嘗試匯入ESXi 6.0失敗解法

遭遇這種問題真的很無奈

還好老外對於研究結果很大方的分享

主要參考網頁: www.itsecurenet.com
本文係參考多個網頁/論壇整理而成,可點選連結閱讀原文

親自試成功後 整理成中文版給需要的人參考

步驟1.
從VirtualBox匯出VM,選項如下圖(勾選Write Metafest file)

建議匯成OVF格式(副檔名直接加.ovf,匯出後有3個檔案),





















步驟2.
將匯出的3個檔案複製到本地硬碟(如果前一步驟儲存在server上的話)


步驟3.
嘗試用vSphere Client部署OVF檔 (ESXi 6.5後只有WEB介面),運氣好的話,系統只會偵測出Metafile裡有2或3組不支援的硬體定義,導致部署失敗。解決對策如下方(i) (ii) (iii)

說明: 部署OVF的過程,遇到問題就會馬上暫停。因此,第n個問題就是部署第n次時才會遇到的。


   (i) 虛擬硬體不相容 :

   錯誤訊息:  

   OVF 套件要求不支援的硬體  
   詳細資料: Line 25: Unsupported hardware family 'virtualbox-2.2'  











   對策: 

   以純文字編輯器(如 notepad++)編輯ovf檔,找到下面這段

      <System>
        <vssd:ElementName>Virtual Hardware Family</vssd:ElementName>
        <vssd:InstanceID>0</vssd:InstanceID>
        <vssd:VirtualSystemIdentifier>Windows Server 2012</vssd:VirtualSystemIdentifier>
        <vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
      </System>

   將 virtualbox-2.2 至換成 vmx-07 (請注意: 原本沒空白就別自己添加)


   (ii) 不支援VirtualBox定義的音效卡 :

   錯誤訊息:  

   OVF套件要求不支援的硬體  
   詳細資料: Line 92: OVF hardware element 'ResourceType' with instance ID '8': No support for the virtual hardware device type '35'  













   對策:

   同一個ovf檔內,移除以下這段定義

      <Item>
        <rasd:AddressOnParent>3</rasd:AddressOnParent>
        <rasd:AutomaticAllocation>false</rasd:AutomaticAllocation>
        <rasd:Caption>sound</rasd:Caption>
        <rasd:Description>Sound Card</rasd:Description>
        <rasd:ElementName>sound</rasd:ElementName>
        <rasd:InstanceID>8</rasd:InstanceID>
        <rasd:ResourceSubType>ensoniq1371</rasd:ResourceSubType>
        <rasd:ResourceType>35</rasd:ResourceType>

      </Item>

   整段全部刪除 (包括 <Item> 及 </Item> 都刪掉)

   (iii) 不支援AHCI硬體

   錯誤訊息 :  

   Line 111: No space left for device '11' on parent controller '5'.  
   Line 66: Unsupported virtual hardware device 'AHCI'.  




















   對策 :

   同一個ovf檔內,找到這一段

      </Item>
      <Item>
        <rasd:Address>0</rasd:Address>
        <rasd:Caption>sataController0</rasd:Caption>
        <rasd:Description>SATA Controller</rasd:Description>
        <rasd:ElementName>sataController0</rasd:ElementName>
        <rasd:InstanceID>5</rasd:InstanceID>
        <rasd:ResourceSubType>AHCI</rasd:ResourceSubType>
        <rasd:ResourceType>20</rasd:ResourceType>
      </Item>

   改成這樣

      <Item>
        <rasd:Address>0</rasd:Address>
        <rasd:Caption>SCSIController</rasd:Caption>
        <rasd:Description>SCSI Controller</rasd:Description>
        <rasd:ElementName>SCSIController</rasd:ElementName>
        <rasd:InstanceID>5</rasd:InstanceID>
        <rasd:ResourceSubType>lsilogic</rasd:ResourceSubType>
        <rasd:ResourceType>6</rasd:ResourceType>
      </Item>

   修改完成後,儲存ovf檔。

   基於安全考量,匯出VM時選擇產生Metafile後,系統會將對應VM的vmdk硬碟檔及ovf定義檔做checksum計算寫入.mf檔。因此必須為修改過的新ovf檔更新mf內的資訊(沒有勾選Write Metafile就沒有.mf檔,匯入時好像就不檢查。請自行查詢)


步驟4.
更新.mf檔以對應新的.ovf檔 (如果匯出時有勾選Write Metafile)

下載微軟提供的checksum計算工具 (載點)

開啟DOS Shell(命令提示字元),移至剛才下載工具程式的目錄下

(如果你不是 DOS 時代長大的,指定大概是 C:\>cd /d d:\downloads 這樣)

計算新ovf檔的checksum


D:\DOWNLOADS>fciv -sha1 c:\temp\w2012svr.ovf

//
// File Checksum Integrity Verifier version 2.05
//
01970fab299090ec43355f6059f51a391d629b6f c:\temp\w2012svr.ovf

把舊的(下方xxx代表)用這一段 "01970fab299090ec43355f6059f51a391d629b6f" 換掉

SHA (w2012svr.ovf)=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx




儲存後再部署一次,成功了! 恭喜你!

如果還是有問題,用相同的方式繼續調整,應該很有機會。







VirtualBox V4.1.8 r75467

2017年2月12日 星期日

呼叫c++寫的dll時發生 "找不到指定的模組,發生例外狀況於HRESULT:0x8007007E)"

一般來說,被引用的dll檔放在執行檔目錄下都可以正確被引用
本篇要解決的問題是,被呼叫的dll檔確定已存在正確位置
執行程式呼叫該dll檔卻發生找不到dll檔的問題。

簡單紀錄解決方法如下:

1.開啟 VS2015開發人員命令提示字元
(通常在開始功能表的Visual Studio 2015下)

2.執行 dumpbin.exe xxxxx.dll /dependents 列出該dll檔所引用的其它dll
(xxxxx.dll就是你的程式執行時系統說找不到的dll檔名)



3.逐一確認發生問題電腦上是否有安裝這些dll

  • x86程式用的應該在 C:\Windows\SysWOW64
  • x64程式用的應該在 C:\Windows\System32

4.從安全的來源將缺少的dll檔補上
如果不知道該安裝那些軟體會重新安裝這些dll,可嘗試從其它電腦複製

2016年1月24日 星期日

VirtualBox複製硬碟檔發生 "虛擬硬碟的UUID已存在系統" 問題

VirtualBox 4.1.8 r75467還算穩定運作數個月後
原硬碟快滿了,將VM目錄完整複製到系統新硬碟
修改VirtualBox內VM設定,將虛擬硬碟檔案指向新位置失敗

因為該虛擬硬碟的UUID已存在系統,無法重覆註冊
使用下列修改新虛擬硬碟檔的UUID後就可以了


VBoxManage internalcommands setvdiuuid mydrive.vmdk

註1 
VBoxManage可能在C:\Program Files\Oracle\VirtualBox請自行蒐尋

註2
原PO內改的是.vdi檔,我的檔案是vmdk格式一樣沒問題

2015年3月15日 星期日

安裝於CentOS的supervisord無預警關閉 (crash with system time change - fixed)

有一隻自己寫的Linux程式跑在CentOS 6.6 x86_64上
寫的不好 執行發生錯誤時有可能會當掉
但為了某些原因它必須重新跑起來
[I installed supervisord 3.1.3 on CentOS 6.6 x86_64 to monitor a daemon
and to respawn it automatically whenever necessary]

網路文說supervisord是宣稱唯一不需要搶系統優先控制權的工具

簡單裝起來 只把自己的程式路徑名稱寫入設定檔
用預設值就跑起來了 以為一切就是這麼簡單美妙
[With almost everything in default value, supervisord started to run as exepcted]

第二天進系統檢查一下....


我的程式還苟活著 不錯

咦~ supervisord不見了 它......竟然掛了!
[However, surprise came to me on the second day. Supervisord crashed with no hint at all. It just gone!]


查遍各大論壇 終於看到有人po文表示:
自己的Linux時間常跑掉 用ntp對時後supervisord就無預警的掛了
[Some thread in a forum mentioned a symptom that supervisord crashes after ntpdate adjusted system time]

回測自己主機 確實在手動將時間往前調之後supervisord就閃退了
[I made some tests with manual 'date' command to turn back system time (hours). Oops! Same here: crash... crash... and crash.....]

再經過一番努力搜尋又測了三天 確認這個解法有用
[Luckily I found a solution by the honorable person "Mook-as". And his/hers solution was tested to work on my system]

 Use monotonic time for process state tracking by Mook-as

成因大致是supervisord處理time的方式讓它在系統時間倒退後出了問題
(例如某程序在檢查目前時間是否已到執行某工作時 發現自己回到過去了)

把所有time.time()換成monotonic_time()就好了
[For those who having the same problem as I did, apply the patch (I did it by manual input) to replace time.time() then it should work]

連結就是上方的標題

有相同需求的朋友請自行patch你的.py程式吧
[Thank you, Mook-as!]

cheers~

2015年2月24日 星期二

Tomato by Shibby之Access Restriction失效問題

為了限制部分電腦只能於特定時間上網
找了部Tenda N6改成Tomato by Shibby

設定Access Restriction功能後測試  無效!!!

電腦的IP位址已經被鎖了,卻仍可上網

挖出用過沒問題的無線路由器來比對

兩台路由器只有韌體版本不同

新: Tomato Firmware 1.28.0000 MIPSR2-124 K26 Max
舊: Tomato Firmware 1.28.0000 MIPSR2-123 K26 Max

直接將Tenda N6降版到123沒改設定,功能生效了

結論: 目前最新版v1.28 build 124的部分功能有問題

Function "Access Restriction" does not work properly in Tomato by Shibby v1.28 build 124. Pretty sure it's a bug in latest version because the same setting works after I downgrade firmware to v1.28 build 123.


2015年2月11日 星期三

kamailio IPv6運作超難搞 (失敗收場)


如果你想試試SIP/IPv6,很可能會搜尋到這篇文章:
Run your own SIP VoIP service on both IPv4 and IPv6


讀來如此簡單而美好

花兩天時間試過裝在以下各VM
CentOS 6.3 x86 (source編譯安裝)
Debian 7.7.0 i386 (source編譯安裝)
Debian 6.0.4 i386 (source編譯安裝)
Debian 7.0.0 i386 (直接從repo用apt-get安裝)

全部同樣的情況:
IPv4幾乎不需要設定就能動
IPv6怎麼設定5060 port都不收封包 (netstat確定有listen)

怎麼送封包給kamailio,只有下面這個系統回應
ICMPv6 Destination Unreachable (Port unreachable)

功力太淺,放棄

(kamailio has put me in hell for two days. too tired now to write in English..... 
my suggestion to the ones who got the same ICMPv6 Port unreachable packet is,
"give it up, now!", this is no fun at all)