Docker में QEMU पर चलने वाला macOS

 (github.com/sickcodes)
3 पॉइंट द्वारा GN⁺ 2024-08-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Docker-OSX Docker कंटेनर के अंदर QEMU + KVM आधारित macOS चलाता है और X11 आउटपुट, SSH, VNC, iPhone USB इंटीग्रेशन, iMessage सुरक्षा रिसर्च के लिए सीरियल जनरेशन आदि देता है
  • चलाने का तरीका Docker को /dev/kvm डिवाइस, X11 सॉकेट, पोर्ट फ़ॉरवर्डिंग और macOS वर्ज़न चुनने के लिए SHORTNAME environment variable देने की संरचना पर आधारित है; Catalina 10.15 से Tahoe 16 तक के उदाहरण शामिल हैं
  • इमेज कॉन्फ़िगरेशन उद्देश्य के हिसाब से latest, auto, naked, naked-auto जैसे भागों में बंटा है; अपनी बनाई .img जोड़ सकते हैं या pre-configured Catalina इमेज से command-line कार्य चला सकते हैं
  • आवश्यकताएं हैं x86_64 KVM-सक्षम host, BIOS virtualization enabled, कम से कम 20GB से अधिक disk space; Xcode इस्तेमाल करने पर 50GB और :auto इस्तेमाल करने पर कम से कम 50GB चाहिए
  • यह Linux के अलावा Windows 11 build 22000+ के WSL2 nested virtualization में भी चल सकता है, लेकिन display output के लिए WSLg, VNC या desktop environment में से कोई एक सेट करना होगा

Docker कंटेनर के अंदर macOS चलाना

  • Docker-OSX एक प्रोजेक्ट है जो macOS को Docker कंटेनर के अंदर चलाता है
    • यह QEMU + KVM पर काम करता है
    • X11 forwarding सपोर्ट करता है
    • iPhone USB काम करे ऐसी configuration देता है
    • बताता है कि Linux और Windows पर macOS सुरक्षा रिसर्च की जा सकती है
  • प्रोजेक्ट OSX-KVM पर बनाया गया है और KVM-OpenCore, OpenCorePkg का भी उल्लेख करता है
  • Docker Hub इमेज भी उपलब्ध है: sickcodes/docker-osx

समर्थित macOS वर्ज़न और quick run तरीका

  • Quick Start में docker run के जरिए ये चीज़ें पास की जाती हैं
    • --device /dev/kvm
    • SSH के लिए -p 50922:10022
    • X11 के लिए /tmp/.X11-unix volume
    • DISPLAY
    • macOS वर्ज़न चुनने के लिए SHORTNAME
  • README में शामिल run targets इस प्रकार हैं

    • High Sierra 10.13

    • Mojave 10.14

    • Catalina 10.15

    • Big Sur 11

    • Monterey 12

    • Ventura 13

    • Sonoma 14

    • Sequoia 15

      • Tahoe 16
      • Monterey के बाद के कुछ उदाहरण GENERATE_UNIQUE=true और MASTER_PLIST_URL को साथ में इस्तेमाल करते हैं
      • Sonoma, Sequoia, Tahoe के उदाहरणों में CPU='Haswell-noTSX' और CPUID_FLAGS भी शामिल हैं

इमेज प्रकार और उपयोग का उद्देश्य

  • Docker-OSX उद्देश्य के अनुसार container images देता है
    • sickcodes/docker-osx:latest: जल्दी try करने या खुद macOS इमेज बनाने के लिए
    • sickcodes/docker-osx:auto: pre-configured Catalina सिस्टम इस्तेमाल करता है; user name user, password alpine
    • sickcodes/docker-osx:naked: उपयोगकर्ता की .img फ़ाइल जोड़कर चलाने के लिए
    • sickcodes/docker-osx:naked-auto: user image में USERNAME, PASSWORD, OSX_COMMANDS देकर SSH और command execution automate करने के लिए
    • sickcodes/docker-osx:big-sur, :monterey, :ventura, :sonoma, :high-sierra, :mojave: specific version चलाने के लिए
  • naked इमेज मौजूदा disk image को बार-बार boot करने या container को पिछली state में वापस ले जाने वाली workflow के लिए बनी है
  • auto और naked-auto का उपयोग command-line focused tasks या Homebrew आधारित builds जैसे headless कामों में किया जा सकता है

मुख्य features

  • Docker-OSX ने जिन features का उल्लेख किया है, वे ये हैं
    • Linux पर usbfluxd का उपयोग करके iPhone OSX KVM इस्तेमाल
    • macOS Monterey VM चलाना
    • folder sharing
    • USB passthrough और hotplug
    • SSH enable: localhost:50922
    • VNC enable: ./vnc version इस्तेमाल करने पर localhost:8888
    • serial number generator के जरिए iMessage सुरक्षा रिसर्च
    • X11 forwarding
    • Big Sur, custom images, Xvfb headless mode सपोर्ट
    • docker commit से container clone करना संभव
  • Kubernetes भी सपोर्ट करता है और बताता है कि Helm Chart और documentation helm directory में हैं

आवश्यकताएं और शुरुआती setup

  • न्यूनतम आवश्यकताएं इस प्रकार हैं
    • 20GB से अधिक disk space
    • Xcode इस्तेमाल करने पर 50GB
    • :auto इस्तेमाल करने पर कम से कम 50GB
    • BIOS में virtualization enabled
    • x86_64 KVM-सक्षम host
  • शुरुआती setup में host पर QEMU और संबंधित dependencies install करने के बाद libvirtd, virtlogd, KVM kernel modules enable करने की प्रक्रिया है
  • Arch, Ubuntu/Debian, CentOS/RHEL/Fedora के लिए package install commands अलग-अलग दिए गए हैं
  • कुछ मामलों में user को Docker, KVM, libvirt groups में होना पड़ सकता है, और Docker daemon running state भी check करनी होगी

Windows पर चलाने की शर्तें

  • Windows पर Docker-OSX चलाना Windows 11 + WSL2 environment में संभव है
    • Windows 11 build 22000+, 21H2 या बाद का version चाहिए
    • WSL install करने के बाद .wslconfig में nestedVirtualization=true जोड़ें
    • WSL distribution में kvm-ok से /dev/kvm और KVM acceleration उपलब्ध है या नहीं, check करें
    • Docker for Windows में WSL2-based engine और default WSL distribution integration enable करना होगा
  • screen output के तरीके 3 प्रकार में बंटे हैं
    • WSLg: सबसे सरल और recommended option, लेकिन keyboard pass-through या second mouse display जैसी समस्याएं हो सकती हैं
    • VNC: QEMU VNC या VNC section की settings इस्तेमाल करें
    • Desktop Environment: ज्यादा resources इस्तेमाल करता है, लेकिन पूरा Linux desktop experience देता है

file sharing और disk operations

  • सबसे आसान और सुरक्षित sharing method के रूप में sshfs बताया गया है
    • Linux/Windows पर sshfs user@localhost: -p 50922 ~/mnt/osx के रूप में macOS rootfs को user space में mount करें
  • QEMU 9p sharing भी संभव है
    • host folder को /mnt/hostshare के रूप में container में पास करें
    • macOS के अंदर sudo -S mount_9p hostshare से mount करें
  • NFS sharing भी बताया गया है
    • host के /etc/exports में shared directory register करें
    • Docker-OSX container को --network host से start करें
    • macOS terminal में mount_nfs इस्तेमाल करें
  • Docker disk space कम होने पर /var/lib/docker को external drive, block storage, NFS आदि पर move करके symbolic link बनाया जा सकता है
    • current Docker images और layers delete हो सकते हैं, यह स्वीकार हो तभी संबंधित tutorial follow करने को कहा गया है

iPhone USB और USB passthrough

  • desktop PC पर VFIO-based iPhone USB passthrough method के लिए अलग link दिया गया है
  • laptop, PC आदि पर usbfluxd का उपयोग करके network-based USB passthrough इस्तेमाल किया जा सकता है
    • Linux में iPhone या iPad को USB से connect करें
    • usbmuxd को TCP port 5000 पर expose करें
    • macOS guest में usbfluxd -f -r 172.17.0.1:5000 के रूप में host से connect करें
    • Xcode जैसी apps बंद करके फिर खोलने पर device दिखने लगता है, ऐसा बताया गया है
  • सामान्य USB passthrough के लिए QEMU को root के रूप में start करना होगा, ऐसा बताया गया है
    • lsusb -t से bus और port check करें
    • --privileged, /dev/kvm, EXTRA="-device ... usb-host ..." आदि इस्तेमाल करें
    • VM चलते समय host system उस USB device को access नहीं कर पाएगा

headless, VNC, SPICE, remote execution

  • headless execution में docker run से X11 से संबंधित दो lines हटाई जाती हैं
    • /tmp/.X11-unix volume हटाएं
    • DISPLAY environment variable हटाएं
  • custom image-based headless container CI/CD pipelines में useful बताया गया है
  • VNC को local-only इस्तेमाल किया जा सकता है, लेकिन README साफ लिखता है कि TLS/HTTPS encryption बिल्कुल नहीं है
    • SSH tunnel इस्तेमाल करने और external ports बंद करने पर यह सुरक्षित हो जाता है, ऐसा बताया गया है
  • SPICE भी इस्तेमाल किया जा सकता है
    • remote-viewer spice://localhost:3001 से connect करें
    • example में -disable-ticketing authentication के बिना VM access की अनुमति देता है, इसलिए SPICE manual की authentication settings देखने को कहा गया है

serial number और iMessage/iCloud research

  • iMessage या iCloud इस्तेमाल के लिए जिन values को बदलना होगा, वे इस प्रकार हैं
    • SERIAL
    • BOARD_SERIAL
    • UUID
    • MAC_ADDRESS
    • बताया गया है कि ROM colon हटाया हुआ lowercase MAC address है
  • Docker-OSX दो तरीके देता है
    • GENERATE_UNIQUE=true: runtime पर unique values generate करें
    • GENERATE_SPECIFIC=true: specified values इस्तेमाल करें
  • ./custom/generate-unique-machine-values.sh serial number, MAC address, CSV/TSV output, boot disk images बना सकता है
  • ioreg -l | grep IOPlatformSerialNumber से macOS के अंदर serial number check किया जा सकता है

performance, resolution, network settings

  • osx-optimizer इस्तेमाल करके container को तेज बनाया जा सकता है, ऐसा बताया गया है
    • GUI login screen skip करना
    • Spotlight indexing disable करना
    • heavy login screen background disable करना
    • updates disable करना
  • resolution को WIDTH और HEIGHT environment variables से बदला जा सकता है
    • GENERATE_UNIQUE=true या GENERATE_SPECIFIC=true के साथ इस्तेमाल करना होगा
    • नया boot partition बनाने के लिए boot में लगभग 30 सेकंड और लगते हैं
    • गलत resolution default रूप से 800x600 हो जाता है
  • network adapter environment variable से बदला जा सकता है
    • fast internet connection: NETWORKING=vmxnet3
    • slow internet connection: NETWORKING=e1000-82545em
  • remote install में IPv4 forwarding on करने से performance बेहतर हो सकती है, लेकिन container में VPN इस्तेमाल करने पर भी host IP leak हो सकता है, ऐसा बताया गया है

troubleshooting और constraints

  • Docker daemon running न हो तो docker: unknown server OS: . error आ सकता है
    • sudo dockerd
    • sudo systemctl --start dockerd
    • sudo systemctl --enable --now dockerd
  • RAM physical machine से ज्यादा allocate नहीं की जा सकती
    • default value -e RAM=3 है
    • ज्यादा allocate करने पर cannot set up guest memory 'pc.ram': Cannot allocate memory error आ सकता है
  • ALSA संबंधित errors container initialization या boot के दौरान दिख सकते हैं; boot और functionality normal हो तो चिंता करने की जरूरत नहीं, ऐसा बताया गया है
  • TODO में ये items बचे हैं
    • security researchers के लिए documentation
    • GPU acceleration
    • virt-manager support

license और notice

  • Docker-OSX GPL v3+ के तहत licensed है
  • साफ लिखा है कि Docker-OSX को proprietary software बनाने के tool के रूप में इस्तेमाल करना allowed है
  • इसमें Apple security research और Apple Bug Bounty Program से जुड़े notices शामिल हैं, और Hackintosh, OSX-KVM, Docker-OSX के legal issues पर अलग post link की गई है
  • प्रोजेक्ट में उल्लेखित product names, logos, brands, trademarks उनके संबंधित owners की property हैं, और वे trademark holders repository से affiliated नहीं हैं, न ही उसे sponsor या endorse करते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-01
Hacker News की राय

  • जो लोग इस प्रोजेक्ट को सच में इस्तेमाल करना चाहते हैं, उनके लिए यह अहम है, लेकिन समझ नहीं आता कि इतने सारे Dockerfile जैसे build recipes build प्रक्रिया के दौरान इंटरनेट से मनमाना content क्यों डाउनलोड करते हैं
    इस प्रोजेक्ट का Dockerfile भी build के समय 2 Git repositories और 1 script fetch करता है
    इंटरनेट access बंद sandboxed build server पर fail होना तो तय है ही, और जिसे security की ज़रा भी चिंता है उसे इस्तेमाल से पहले पूरा build recipe audit करना पड़ेगा
    README, requirements.txt, package.json जैसे build specifications में लिखी dependencies ही review करना अब काफी नहीं रहा; हाल की core infrastructure failures और supply chain attacks में बढ़ोतरी को देखते हुए यह बहुत चिंताजनक trend है

    • मुझे सच में पसंद नहीं कि project build files को इंटरनेट से खींचें। आमतौर पर यह अनपेक्षित रूप से होता है, और security issue के अलावा उस पर depend करने वाले software को package करना भी बहुत कठिन हो जाता है
      version issues, इंटरनेट न होना, या worst case में dependency का अब उपलब्ध न रहना—ऐसे अप्रिय surprises मिलते हैं। self-contained distribution default होना चाहिए
    • जवाब है change churn। DevOps क्षेत्र में बदलाव इतना ज्यादा है कि अब किसी के पास “सही तरीका” समझने का समय नहीं है
    • सही दिशा यह है कि Red Hat, SUSE, Canonical जैसे बड़े open source players build को सुरक्षित बनाएं, इसका इंतज़ार किया जाए
      Fedora और openSUSE में आम तौर पर policies होती हैं कि distribution packages और container images समेत builds केवल repository के packages से बनें, या build के दौरान स्पष्ट रूप से जोड़े गए binaries ही इस्तेमाल हों
      इसलिए अगर आप dnf/zypper install से install कर सकते हैं या vendor की container registry से ला सकते हैं, तो output artifacts पर भरोसा किया जा सकता है
      अगर latest bleeding edge चाहिए, तो इंटरनेट के arbitrary materials का जोखिम उठाना पड़ेगा
      किसी random open source developer के लिए offline-ready, भरोसेमंद build artifacts बनाना कठिन है और उनके पास ऐसा infrastructure नहीं होता। इसलिए Red Hat या SUSE जैसी companies मौजूद हैं
      अरबों डॉलर की companies खुशी-खुशी भुगतान करती हैं ताकि कोई plumbing work करके इंटरनेट के arbitrary artifacts को trustworthy, reproducible, signed artifacts में बदले, CVE track करे और regular updates देता रहे
    • एक web page दिखाने के लिए JavaScript के दसियों हजार dependencies खींच लाने से यह कैसे अलग है, समझ नहीं आता
      80s में हमने Lego blocks की तरह plug-in होने वाले modular reusable software components की कल्पना की थी, और तब उसे CASE कहा जाता था। अब वह सच हो गया है, लेकिन जाहिर है उसकी कीमत भी है
    • शायद मुख्य वजह अलग Git repository के रूप में configuration cleanup बनाए रखना है
      अगर Dockerfile में clone न करें, तो pre-build instructions देनी पड़ेंगी कि “clone करते समय --recursive इस्तेमाल करें या git submodule init से दूसरे repositories को current working directory में लाएं”

  • GPU acceleration की इकलौती संभावना PCI passthrough से supported dGPU पास करना है। AMD RX 6xxx और उससे ऊपर macOS 14.x में संभव है, लेकिन modern Nvidia की कोई संभावना नहीं
    Intel iGPU Comet Lake तक, और कुछ Ice Lake तक काम करते हैं, लेकिन उससे नए नहीं
    Apple Silicon build वाला macOS फिलहाल emulate करना मुश्किल लगता है, और ARM Darwin booting पर थोड़ा early work हुआ है
    साथ ही AMD में Intel VT-x नहीं है, इसलिए AMD hosts पर virtualization टूट जाती है, लेकिन पुराने VirtualBox का इस्तेमाल करने वाले अजीब hack से Docker को emulation के जरिए कुछ हद तक चलाया जा सकता है

    • सैद्धांतिक रूप से कोई Windows और Linux में मौजूद libvirt/kvm/qemu 3D acceleration display driver जैसा driver बना सकता है। तब performance best न भी हो, तो भी लगभग हर GPU पर GPU performance इस्तेमाल की जा सकेगी
      AMD के पास अपना VT-x alternative AMD-V है, इसलिए उसे ठीक से काम करना चाहिए। हालांकि macOS को AMD CPU पर boot कराने में अलग hurdles हैं, जिन्हें आम तौर पर kext loading या दूसरे workarounds से solve किया जाता है
      Docker से पूरा operating system चलाने का मतलब मुझे समझ नहीं आता। इसे OVA या पसंदीदा virtualization format में distribute किया जा सकता है। qcow2 और VM start करने के लिए bash script ही शायद काफी होंगे
    • “AMD में Intel VT-x नहीं है, इसलिए AMD hosts पर virtualization टूट जाती है” वाली बात AMD-V से नहीं हो जाती?

  • संबंधित लेख:
    Docker-OSX: Run macOS VM in a Docker - https://news.ycombinator.com/item?id=34374710 - जनवरी 2023, 110 comments
    macOS in QEMU in Docker - https://news.ycombinator.com/item?id=23419101 - जून 2020, 186 comments

  • कुछ महीने पहले मैंने experiment के तौर पर set up किया था, और यह काफी अच्छी तरह चला। हालांकि iMessage चलाने के लिए application hardware ID Apple को भेजता है, और पता चला कि यह project fake values इस्तेमाल करता है
    उस point से “शायद यह काम नहीं करेगा” वाली slippery slope शुरू हो गई, और पता चला कि fake values Apple द्वारा flag हो सकती हैं, जिससे आखिर में iCloud ID potential spammer के तौर पर marked हो सकती है और दूसरे devices की access सीमित हो सकती है
    इकलौता विकल्प है धुंधले ढंग से linked hardware ID generation script से values बार-बार try करना ताकि कोई “काम करने वाली” value मिल जाए, लेकिन इसका कोई साफ संकेत नहीं कि वह सच में सही fit है और iCloud reputation को नुकसान नहीं पहुंचाती
    बाकी सब में यह सच में बहुत अच्छी तरह चला, और emergency में बहुत useful है

    • “काम होने तक HWID बदलते रहना” तरीका Hackintosh पर iMessage चलाने के लिए भी common था। checkcoverage.apple.com पर यह verify किया जा सकता था कि वह काम करता है या नहीं
      जल्द ही समझ आ गया कि पुराना लेकिन असली Mac का Serial copy करना ज्यादा आसान है
      हालांकि यह tool personal computer की तरह इस्तेमाल करने के बजाय, proprietary macOS frameworks पर depend करने वाले build scripts जैसे use cases के लिए ज्यादा useful लगता है
    • security research में आम तौर पर primary iCloud account या कोई दूसरा main account इस्तेमाल न करना बेहतर है

  • बस यह टेस्ट करके देखना चाहता/चाहती हूं कि iOS के लिए build किया जा सकता है या नहीं। उदाहरण के लिए Unity, React Native जैसी चीजें
    भले ही build में 5 गुना ज्यादा समय लगे, freedom के लिहाज से यह काफी शानदार हो सकता है

    • Cross-compilation शायद बेहतर तरीका हो सकता है: https://github.com/tpoechtrager/osxcross
      Godot भी iOS target के लिए इसी तरह build करता है: https://github.com/godotengine/build-containers/blob/main/Do...
      tools पहले से install वाली Docker image भी है, लेकिन iOS target करने के लिए थोड़े बदलावों की जरूरत होगी: https://github.com/shepherdjerred/macos-cross-compiler
      RStudio, अब के Posit में रहते हुए, Linux host से x86_64/aarch64 macOS target करके C/C++/Fortran/Rust cross-compilation पर काम किया था
      Posit Package Manager(https://p3m.dev/client/) से अगर native code वाला R package डाउनलोड करते हैं, तो वह इसी तरीके से cross-compile किया हुआ होता है :)
    • खुद करके देखा है। USB port को Docker के पार किसी तरह share करना पड़ा, और repo के निर्देशों के हिसाब से यह लगभग काले जादू जैसा था, लेकिन iOS app build करने के बाद उसे iPhone पर चला पाया/पाई
    • अगर Windows machine पर इस environment में native Swift modules वाला React Native iOS build करके simulator में चला सकें, तो impressive होगा

  • पहले Sick Codes के साथ इस product approach पर interview किया था: https://www.vice.com/en/article/akdmb8/open-source-app-lets-...
    ऐसा ही काम Proxmox home server पर करने वाला OSX-PROXMOX भी है: https://github.com/luchina-gabriel/OSX-PROXMOX
    निजी तौर पर HP Z420 Xeon पर बाद वाला use कर रहा/रही हूं, खासकर GPU passthrough जोड़ने पर यह बहुत stable है

  • अच्छा होगा अगर home server पर iCloud sync चला सकें। अभी iCloud को home server/NAS पर physically backup करने का कोई अच्छा तरीका नहीं है, और यह सिर्फ Windows/Apple पर काम करता है

    • इस data को sync करके local में save करने या कहीं और backup करने में यह मदद कर सकता है:
      https://github.com/steilerDev/icloud-photos-sync
      https://github.com/icloud-photos-downloader/icloud_photos_do...
    • OSX-Docker और OSXPhotos का इस्तेमाल करते हुए एक solution पर काम कर रहा/रही हूं। काफी करीब पहुंच गया/गई हूं, लेकिन iCloud की सारी जानकारी backup करते समय metadata changes भी शामिल करना चाहता/चाहती था/थी
      पता चला कि iCloud original photos को update नहीं करता। समझ में आता है, लेकिन backup करते समय उन changes के शामिल होने की उम्मीद रखने वाले के लिए यह मददगार नहीं है
    • उत्सुक हूं कि यह उस समस्या में कैसे मदद करता है। connected Mac/PC से iCloud folder को NAS पर rsync करने की तुलना में यह अलग क्या करने देता है?

  • सोच रहा/रही हूं कि MacOS image redistribution license के तहत allowed है या नहीं। या फिर यह project Docker Hub पर pirated copies खुलेआम distribute कर रहा है?

    • पक्का नहीं पता, लेकिन Corellium ने iOS instances को virtualize किया था, Apple ने उस पर मुकदमा किया और फिर settlement हुआ
    • यह साफ तौर पर illegal है

  • सोच रहा/रही हूं कि Intel support हटे हुए और नए MacOS versions आने पर progress रुक जाएगी या नहीं
    क्या इस container के अंदर Docker चलाकर MacOS के अंदर MacOS चला सकते हैं? ;)

    • theory में qemu को कभी भी full emulation mode में चला सकते हैं
    • किसी भी supported VM program में बस ऐसा किया जा सकता है

  • जब “USB passthrough” expression असल में ज्यादा से ज्यादा “Ethernet over USB proxy” जैसी स्थिति के लिए इस्तेमाल होता है, तो मुझे सच में चिढ़ होती है
    वह passthrough नहीं है। उसमें कई ऐसे drawbacks आते हैं जो normal passthrough में नहीं होते, और advanced passthrough में भी शायद न हों

    • QEMU USB passthrough सचमुच USB passthrough है। USB passthrough की समस्या खुद USB controller और device enumeration के तरीके से आती है, और एकमात्र बेहतर solution है पूरे USB controller को PCIe passthrough करना
      लेकिन वह तरीका अपनी अलग समस्याएं लाता है। forwarded hardware वाले बड़े VM test farms चलाने के अनुभव से ऐसा कह रहा/रही हूं
      हालांकि “Ethernet over USB proxy” भी असली passthrough ही है, बस VirtIO से ज्यादा latency वाला passthrough है