用 VirtualBox 開啟實體硬碟中的 Windows

如果用 Linux 當開發環境,常常會碰到一個問題:因為一般企業使用的管理系統沒有 Linux 版本,導致有些操作必須使用 Windows 來完成。對於大部分的應用來說,在 VirtualBox 內安裝 Windows 可能就能解決,問題是,通常 VirtualBox 的 Windows 都是由工程師自行安裝,不是正式授權;再來,在 VirtualBox 內安裝 Windows,意味加上原來預設的 Windows,硬碟內要有兩套 Windows,這真的讓人很難接受,一套已經很佔空間了,居然還要兩套?

於是我有個想法,要是 VirtualBox 可以用實體空間來開機的話,就能直接在 VirtualBox 執行原本配置的系統,如此一來,可以用 IT 已經安裝好的授權軟體不說,也省掉了後續資料交換的麻煩。Google 後發現還真的有這種應用,當然馬上試試看。

列出分區

首先因為是使用硬碟的資料,我們需要確認 Windows 安裝在哪個 Partition,使用 fdisk -l 列出所有 Partition 的狀態

ken:~$ sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 664C31C9-8F24-4D89-B16A-426FDCDBB716
Device             Start       End   Sectors  Size Type
/dev/nvme0n1p1      2048    534527    532480  260M EFI System
/dev/nvme0n1p2    534528    567295     32768   16M Microsoft reserved
/dev/nvme0n1p3    567296 111706111 111138816   53G Microsoft basic data
/dev/nvme0n1p4 248020992 250068991   2048000 1000M Windows recovery environment
/dev/nvme0n1p5 111706112 112504831    798720  390M Linux filesystem
/dev/nvme0n1p6 112504832 144502783  31997952 15.3G Linux swap
/dev/nvme0n1p7 144502784 248020991 103518208 49.4G Linux filesystem

可以看到 Windows 的資料位於 dev/nvme0n1

創建 VMDK 檔

接著,為了讓 VirtualBox 可以從實體硬碟開機,我們需要建立 vmdk 檔來表示實體硬碟。使用 VirtualBox 指令

ken:~$ sudo VBoxManage internalcommands createrawvmdk -filename ~/vmdk/windows_10.vmdk -rawdisk /dev/nvme0n1p1
RAW host disk access VMDK file /home/ken/vmdk/windows_10.vmdk created successfully.

創建虛擬機

再來,開啟 VirtualBox,用剛剛建好的 vmdk 檔來開機

這邊要注意,雖然我們的系統安裝在 SSD,使用的是 NVMe,但 VirtualBox 的 NVMe 似乎有問題,因此這邊選擇用 SATA

前面看到 nvme0n1 開頭是 EFI,因此記得要 Enable EFI

啟動虛擬機

設定都完成後,只要開啟 Virtual Machine,應該能看到 GRUB 的畫面,選擇 Windows Boot Manager,進入 Windows,完工。

小結

使用 VirtualBox 開啟 Windows 後,就能省掉很多資料交換的麻煩,但畢竟是 Virtual Machine,使用上不比 Native,可能會有些狀況;另外,我電腦的 Windows 跟 Ubuntu 開機都安裝在 SSD,要用 EFI 從 dev/nvme0n1 開機,但如果可以的話,最好將兩個系統切開,免得不小心開到 Ubuntu,造成資料損壞。

Reference

Read more

OAuth 2.0 的身份認證:OpenID Connect

OAuth 2.0 的身份認證:OpenID Connect

OAuth 2 讓網路服務可以存取第三方的受保護資源,因此,有些開發者會進一步利用 OAuth 2 來進行使用者認證。但這中間存在著一些語義落差,因為 OAuth 2 當初設計目的是「授權」而不是「認證」,兩者關注的焦點會有些不同。OpenID Connect 是基於 OAuth 2 的一套身份認證協定,讓開發者可以在 OAuth 2 授權的基礎上,再加入標準的認證流程。在這篇文章中,我會說明授權跟認證的場景有何差異,並講解 OpenID Connect 如何滿足認證需求。 因為 OpenID Connect 是建構在 OAuth 2 的基礎上,我會假設這篇文章的讀者已經知道 OAuth 2 的組件與流程,如果你不熟悉,可以先閱讀另外兩篇文章 * OAuth 2.0:

By Ken Chen
更好的選擇?用 JWT 取代 Session 的風險

更好的選擇?用 JWT 取代 Session 的風險

因為 HTTP 是無狀態協定,為了保持使用者狀態,需要後端實作 Session 管理機制。在早期方式中,使用者狀態會跟 HTTP 的 Cookie 綁定,等到有需要的時候,例如驗證身份,就能使用 Cookie 內的資訊搭配後端 Session 來進行。但自從 JWT 出現後,使用者資訊可以編碼在 JWT 內,也開始有人用它來管理使用者身份。前些日子跟公司的資安團隊討論,發現 JWT 用來管理身份認證會有些風險。在這篇文章中,我會比較原本的 Session 管理跟 JWT 的差異,並說明可能的風險所在。 Session 管理 Session 是什麼意思?為什麼需要管理?我們可以從 HTTP 無狀態的特性聊起。所謂的無狀態,翻譯成白話,就是後面請求不會受前面請求的影響。想像現在有個朋友跟你借錢,

By Ken Chen

Goroutine 的併發治理:掌握生命週期

從併發的角度來看,Goroutine 跟 Thread 的概念很類似,都是將任務交給一個執行單元來處理。然而不同的是,Goroutine 將調度放在用戶態,因此更加輕量,也能避免多餘的 Context Switch。我們可以說,Go 的併發處理是由語言原生支援,有著更好的開發者體驗,但也因此更容易忘記底層仍存在著輕量成本,當這些成本積沙成塔,就會造成 Out of Memory。這篇文章會從 Goroutine 的生命週期切入,試著說明在併發的情境中,應該如何保持 Goroutine 的正常運作。 因為這篇講的內容會比較底層,如果對應用情境不熟的人,建議先看過同系列 * Goroutine 的併發治理:由錯誤處理談起 * Goroutine 的併發治理:值是怎麼傳遞? * Goroutine 的併發治理:管理 Worker Pool 再回來看這篇,應該會更容易理解。 Goroutine 的資源使用量 讓我們看個最簡單的例子,假設現在同時開

By Ken Chen

Goroutine 的併發治理:管理 Worker Pool

併發會需要多個 Goroutine 來同時執行任務,Goroutine 雖然輕量,也還是有配置成本,如果每次新的任務進來,都需要重新建立並配置 Goroutine,一方面不容易管理 Goroutine 的記憶體,一方面也會消耗 CPU 的運算效能。這時 Worker Pool 就登場了,我們可以在執行前,先將 Goroutine 配置好放到資源池中,要用時再調用閒置資源來處理,藉此資源回收重複利用。這篇文章會從 0 開始建立 Work Pool,試著丟進不同的場景需求,看看如何實現。 基本的 Worker Pool Worker Pool 的概念可以用這張圖來解釋 Job 會放在 Queue 中送給 Pool 內配置好的 Worker,Worker 處理完後再將結果送到另一個 Queue 內。因為這是很常見的併發模式,

By Ken Chen