BSD उपयोगकर्ता की Alpine Linux आज़माने की कहानी

 (rubenerd.com)
1 पॉइंट द्वारा GN⁺ 2024-04-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • BSD डेस्कटॉप और chroot, jail का अक्सर उपयोग करने वाला एक उपयोगकर्ता Alpine Linux को आज़माते हुए पाता है कि इसकी security, simplicity और resource efficiency-केंद्रित डिज़ाइन BSD उपयोगकर्ताओं को परिचित लगती है
  • छोटे आकार और सीमित dependencies की वजह से Alpine का उपयोग सिर्फ container base image के रूप में ही नहीं, बल्कि embedded systems, routers, mobile devices, servers और desktops तक व्यापक रूप से होता है
  • इंस्टॉलेशन live environment में setup-alpine चलाकर keymap, network, timezone, SSH, NTP जैसी बुनियादी settings को क्रम से सेट करने के तरीके से होता है
  • पहली boot के बाद OpenRC, musl, और busybox का संयोजन दिखाई देता है, और /etc/rc.conf व crond(8) जैसे तत्व BSD-style rc अनुभव से मेल खाते हैं
  • apk package management, repository settings, और ZFS install की संभावना तक देखने के बाद इसे testing और servers के लिए मुख्य Linux distribution के उम्मीदवार के रूप में गंभीरता से विचार करने लायक अच्छा प्रभाव मिला

BSD उपयोगकर्ताओं को परिचित लगने वाला Alpine का स्वभाव

  • Alpine Linux security, simplicity और resource efficiency को महत्व देने वाले power users के लिए एक independent, non-commercial, general-purpose Linux distribution है
  • user-space binaries को PIE(Position Independent Executables) और stack smashing protection के साथ compile किया जाता है, ताकि कुछ zero-day और vulnerability exploits के असर को कम किया जा सके
  • Natanael Copa ने 2005 में इस project की उत्पत्ति पर चर्चा की थी, यानी Alpine अपेक्षा से पुराना project है
  • BSD परिवार की तरह यह embedded systems, routers, mobile devices के अलावा सामान्य servers और desktops पर भी उपयोग होता है
  • छोटे आकार और सीमित dependencies की वजह से यह Linux containers की base image के रूप में व्यापक रूप से इस्तेमाल होता है, और chroot(8) में आसानी से चलाने के लिए alpine-chroot-install जैसे tools भी मौजूद हैं
    • NetBSD chroot(8) और FreeBSD jail को testing और deployment में बहुत उपयोग करने वाले उपयोगकर्ताओं के लिए यह विशेष रूप से दिलचस्प बिंदु है

इंस्टॉलेशन अनुभव

  • Alpine ARM, PPC64, x86, x86_64 सहित कई builds उपलब्ध कराता है
  • Xen ISO image को VM में boot किया गया, लेकिन Dom0 को DomU समझ लेना गलत चुनाव था
    • Dom0 का अर्थ Xen hypervisor है, guest नहीं
    • फिर भी boot और installation सामान्य ISO की तरह आगे बढ़ गए
  • इंस्टॉलेशन live environment में root और खाली password से login करने के बाद setup-alpine चलाकर किया जाता है
  • इंस्टॉलेशन के दौरान keymap, networking, timezone, root authentication जैसे बुनियादी items क्रम से configure किए जाते हैं
  • शुरुआत में SSH keys inject की जा सकती हैं
    • बाद में orchestration tools से VM या servers के समूह deploy करते समय यह उपयोगी होता है
    • OOB console न देने वाले hosting environments में भी यह मददगार है
  • SSH server और NTP client चुने जा सकते हैं, इसलिए OpenSSH और openntpd चुनना संभव था
  • इंस्टॉलेशन प्रक्रिया ने सही तरह से पहचान लिया कि यह Xen पर चल रहा है
  • LVM configuration भी संभव है, लेकिन इस बार Alpine के अनुसार sys partition वाली standard configuration चुनी गई
    • यह configuration ext4 का उपयोग करती है

पहली boot के बाद दिखने वाली system configuration

  • पहली boot के बाद dmesg(1) में यह पुष्टि की जा सकती है कि system OpenRC का उपयोग कर रहा है
  • OpenRC एक init system है जो portability, छोटे आकार, speed, efficiency, transparency और security प्रदान करता है
  • BSD-style rc scripts लिखने के अभ्यस्त उपयोगकर्ताओं को OpenRC बहुत परिचित लगेगा
    • /etc/rc.conf और crond(8) जैसे तत्व BSD उपयोगकर्ता अनुभव से मेल खाते हैं
  • Devuan, Gentoo और Alpine जैसी Linux distributions के OpenRC उपयोग करने से Linux फिर से रोचक महसूस होता है
  • Alpine, OpenRC के साथ musl शामिल करता है और busybox का उपयोग करता है
    • musl और busybox, GCC और GNU coreutils की तुलना में अधिक सीमित हैं, लेकिन base system के छोटे आकार और कम attack surface में योगदान देते हैं
  • llvm भी उपलब्ध है
  • MirBSD Korn shell भी package के रूप में उपलब्ध है, और यह पसंदीदा interactive shells में से एक है

पैकेज प्रबंधन और repositories

  • Alpine का डिफ़ॉल्ट package manager apk है
  • Linux में आम तरीके की तरह apk base system और packages को अलग नहीं मानता, बल्कि साथ में update करता है
  • BSD की तरह इसे unprivileged copy के रूप में चलाया जा सकता है या नहीं, यह अभी तक जांचा नहीं गया है
  • pkgsrc भी उपयोग किया जा सकता है, इसलिए एक विकल्प मौजूद है
  • repository settings /etc/apk/repositories में होती हैं
    • installer द्वारा दिए गए दूसरे URL की comment हटाने पर community repository सक्रिय की जा सकती है
    • Alpine में testing repository भी है, और अपनी repository भी जोड़ी जा सकती है
  • उपयोग सरल है, लेकिन पुरानी आदतों की वजह से कभी-कभी apk add की जगह गलती से apt install टाइप हो जाता है
  • आधिकारिक package web interface pkgs.alpinelinux.org पर है
  • Alpine repositories को pkgs.org पर भी देखा जा सकता है

ZFS और server उम्मीदवार के रूप में मूल्यांकन

  • कुछ packages install करने के बाद console-only laptop पर उपयोग होने वाली “ज़रूरी tools” configuration बनाई जा सकी
  • सबसे चौंकाने वाले packages में से एक ZFS था
    • install और kernel module load करना दो commands से संभव था
# apk add zfs zfs-lts


# modprobe zfs
  • root filesystem को ZFS पर बनाना अधिक जटिल हो सकता है
  • upgrade के बाद ZFS configuration कैसे काम करेगी, यह अभी तक जांचा नहीं गया है
  • अब तक के अनुभव के आधार पर ही इसे testing और servers के लिए मुख्य Linux distribution के रूप में अपनाने पर गंभीरता से विचार किया जा सकता है
  • htop(1) और lsof(1) में पहचाने जा सकने वाले बहुत कम processes दिखना, OpenRC का उपयोग, सरल लगने वाला package management, और आसान configuration इसके फायदे हैं
  • अगर कोई आधुनिक और functional “Occam’s Linux” है, तो Alpine उसकी छवि के काफ़ी करीब माना गया है
  • busybox से अधिक सुविधाओं की ज़रूरत होने पर uutils आज़माया जा सकता है, लेकिन server पर इसकी ज़रूरत कम लगती है

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

1 टिप्पणियां

 
GN⁺ 2024-04-28
Hacker News की राय

  • सुरक्षा के नज़रिए से देखें तो आजकल ज़्यादातर Linux binaries PIE के साथ compile की जाती हैं
    Ubuntu की किसी भी random binary पर checksec चलाकर यह देखा जा सकता है, और pip install pwntools से checksec install किया जा सकता है
    दूसरी ओर, मेरी जानकारी में GLIBC के पास सबसे hardened heap implementations में से एक है, और double-free व दूसरे heap attacks के खिलाफ ज़्यादा mitigations भी हैं
    इसलिए उस नज़रिए से Alpine, musl इस्तेमाल करने की वजह से कम सुरक्षित लग सकता है, लेकिन इसका छोटा और आसानी से समझ आने वाला system होना सुरक्षा के लिहाज़ से सच में एक बड़ा फ़ायदा है

    • मुझे समझ नहीं आता कि “छोटा और आसानी से समझ आने वाला system” glibc के पक्ष में तर्क कैसे बनता है। मुझे तो इसका उलटा लगता है
    • मैं Alpine nodes पर हमेशा हर चीज़ पर checksec चलाता हूँ, और processes हमेशा ऐसे ही दिखते हैं। पूरा output लंबा है इसलिए छोड़ा गया है, लेकिन Alpine के build किए हुए किसी भी चीज़ में मैंने ये flags गायब नहीं देखे
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • OpenBSD libc को भी देखना चाहिए
    • Linux security के नज़रिए से, अगर कोई system पर ज़रा भी code execute कर सकता है तो खेल पहले ही खत्म माना जाता है। Linux छेदों से भरा हुआ है, और Windows जितना malware उसमें इसलिए नहीं है क्योंकि desktop पर Linux चलाने वाले लोग कम हैं, इसलिए malware बनाने वाले उसे उतना निशाना नहीं बनाते
      ईमानदारी से कहूँ तो modern Windows और macOS — दोनों के पास बेहतर security architecture है

  • मैं भी BSD पक्ष का ही आदमी हूँ, और संयोग से इसी हफ़्ते मैंने bhyve पर VM में पहली बार Alpine चलाया
    असली बात BusyBox है। अगर /bin और /sbin utilities को अलग-अलग binaries होने की ज़रूरत न हो, तो user space बहुत छोटा हो जाता है और boot भी तेज़ होता है। Tmux और zsh जैसा थोड़ा-बहुत install करने के बाद यह ज़्यादातर Unix उपयोगों के लिए काफ़ी था
    अंतिम setup तक पहुँचने के लिए मुझे apk से काफ़ी कुछ install करना पड़ा, लेकिन कुल मिलाकर यह लंबे समय में मिला सबसे अच्छा Linux अनुभव था। ZFS का built-in होना अच्छा है, और bhyve के ZFS-based operation के हिसाब से virtio connection अगर थोड़ा ज़्यादा स्पष्ट होता तो और अच्छा रहता

    • मैं 20 साल से ज़्यादा समय से FreeBSD इस्तेमाल और deploy कर रहा हूँ, और सच कहूँ तो GNU/Linux box में login करना पसंद नहीं आता। variation और inconsistency इतनी ज़्यादा है कि system बिखरा हुआ लगता है। यहाँ तक कि Windows server में login करना मुझे ज़्यादा “समझ में आने वाला” लगता है
      फिर भी यह सुनकर अच्छा लगा कि शायद कोई sane Linux distribution है, तो जब कभी Linux box की ज़रूरत पड़ेगी, इसे आज़माऊँगा। हालांकि ऐसा बहुत कम होता है
    • मैं जानना चाहता हूँ कि आप ZFS को किस हद तक “built-in” देखना चाहते हैं। Alpine उन कुछ distributions में से है जो binary ZFS kernel module देती हैं, इसलिए एक apk command से काम लगभग हो जाता है
      Alpine wiki पर root filesystem को ZFS पर install करने का दस्तावेज़ भी काफ़ी अच्छा है: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS Alpine पर बहुत अच्छा चलता है। Alpine + ZFS कई सालों से मेरा default server setup है

  • अगर आप BSD user हैं, तो Void Linux भी पसंद आ सकता है। यह NetBSD developer xtraeme द्वारा बनाई गई distribution है, इसमें glibc और musl दोनों versions हैं, और init system के रूप में runit का इस्तेमाल होता है
    xbps-src से source से packages build भी किए जा सकते हैं
    https://voidlinux.org/

    • मैं Arch इस्तेमाल करता था और Arch जैसा feel देने वाला non-SystemD alternative ढूँढ़ते-ढूँढ़ते Void पर आकर टिक गया। Alpine की जगह Void चुनने की वजह glibc support थी, क्योंकि उससे NVidia drivers इस्तेमाल कर सकता था। हाँ, “NVidia पर हूटिंग” वाली बात मालूम है
    • मुझे Void बहुत पसंद है। package selection बड़ा है और systemd की सुविधा की वजह से मेरा main system Arch है, लेकिन मैंने अपने रिश्तेदारों और अपनी तीन machines पर Void install किया है, और यह शानदार रहा
      बस इतना ध्यान रहे कि मैंने केवल हल्के बदलावों वाला xfce install ही इस्तेमाल किया है। complex multi-user setup में runit, systemd की तुलना में कम built-in features देता है, इसलिए थोड़ा ज़्यादा झंझट हो सकता है
    • कुछ साल पहले voidlinux+musl पर Rust इस्तेमाल करते समय दिक्कतें थीं। अच्छी बात यह है कि Void में glibc पर आसानी से reinstall किया जा सकता है
    • Chimera भी अच्छा हो सकता है। इसका ज़्यादातर core tools user space FreeBSD lineage का है, इसलिए BSD users को यह काफ़ी परिचित लग सकता है
    • CRUX भी है। यह Archlinux का आध्यात्मिक पूर्वज जैसा distribution है

  • मुझे लगा था कोई यह ज़रूर कहेगा कि BSD की शान माने जाने वाले man pages Alpine में default रूप से शामिल नहीं होते। यही उन वजहों में से एक थी जिनके कारण मैंने travel laptop पर Alpine इस्तेमाल नहीं किया, और अब OpenBSD इस्तेमाल करता हूँ
    क्या Alpine में ऐसा कोई configuration option है जो packages लेते समय documentation को हमेशा install कर दे? या फिर हर बार -doc packages manually install करने पड़ते हैं?

    • अगर आप हमेशा documentation चाहते हैं, तो docs meta package install कर लें। उसके बाद यह install की जाने वाली चीज़ों के अनुसार *-doc packages खींच लाएगा
    • laptop पर OpenBSD इस्तेमाल करने पर hardware support कैसा रहता है?

  • मुझे ईमानदारी से बिल्कुल समझ नहीं आता कि लोगों को OpenRC जैसी चीज़ें आकर्षक क्यों लगती हैं। अगर तरीका निगरानी-आधारित है, तो मेरे हिसाब से वह उस तरीके से बेहतर ही है जिसमें PID इधर-उधर छूट जाते हैं, उन्हें PID फ़ाइल में सहेज दिया जाता है, और फिर उम्मीद की जाती है कि 3 हफ्ते बाद भी वही मान अब भी चल रहे daemon की ओर इशारा करेगा
    ऊपर से कुछ मामलों में किसी खास process name को pgrep करके service management का काम किया जाता है। मैं इस बात से कुछ हद तक सहमत हूँ कि हर चीज़ को default रूप से auto-restart नहीं होना चाहिए, लेकिन इस तरह की सोच वाले लोग असल में यही एक फायदा गिना सकते हैं
    और आखिर में ये चीज़ें syslog पर बहुत ज़्यादा निर्भर करती हैं, जो अपने आप में 80 के दशक की तकनीक है। multilog या svlogd जैसे टूल बेहतर बनाए जा सकते हैं ताकि कई टूलों की घटनाओं का क्रम एक नज़र में दिखाने वाला central view आसान हो, लेकिन logs को धुंधली श्रेणियों में बाँधना और किसी को भी किसी भी नाम से कहीं भी log लिखने देना अजीब लगता है

    • संदर्भ के लिए, Alpine कई सालों से OpenRC replacement आज़मा रहा है, लेकिन उसे कोई उपयुक्त विकल्प नहीं मिला है। इसे init system-independent distribution बनाने की कोशिश भी चल रही है
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • फिर भी मुख्य विकल्प systemd ही है, और वह इस तरह डिज़ाइन किया गया है कि सुरक्षा की दृष्टि से ठीक नहीं कहा जा सकता, इसलिए नए और दिलचस्प CVE लगातार निकलते रहने की गुंजाइश बनी रहती है
      PID1 के अंदर बहुत ज़्यादा चीज़ें ठूँस दी गई हैं, और यह memory-safe नहीं होने वाली भाषा में लिखा गया है। मुझे कोई तकनीकी वजह नहीं दिखती कि इसे एक minimal PID1 और कुछ setuid programs में बाँटा न जा सके
      Docker container के अंदर systemd चला पाना एक बात हो सकती है, लेकिन Red Hat/IBM शायद अपने containerization टूल जैसे systemd-nspawn का उपयोग करवाना ज़्यादा पसंद करेगा, इसलिए मुझे नहीं लगता कि वे इसे बहुत ज़ोर से चाहेंगे। मौजूदा संरचना में यह सुरक्षा के नज़रिए से कभी भी सही नहीं ठहर सकता

  • Alpine के कुछ दिलचस्प फायदे हैं। जब Nix उपयोगकर्ता declarative package management का दिखावा करते हैं, तो आप सीधे /etc/apk/world संपादित करके और apk fix चलाकर दिखा सकते हैं कि यह Nix के बिना भी कैसे किया जा सकता है

    • आम तौर पर Gentoo वाला तरीका बेहतर है। manually installed packages /var/lib/portage/world में, चुने हुए sets /var/lib/portage/world_sets में, और set definitions /etc/portage/sets/ में रखे जा सकते हैं
      इससे packages को श्रेणियों के हिसाब से बाँटना, ज़रूरत वाले सिस्टम पर केवल कुछ ही install करना, और फ़ाइलों में मनचाहे comments जोड़ना संभव होता है। apk fix के बराबर emerge -uDU @world && emerge -c है, हालाँकि यह थोड़ा ज़्यादा बोझिल है
      Alpine में apk add -t setname pkg1 pkg2 pkg3 से set जैसी चीज़ बनाई जा सकती है, और इससे चुने हुए packages पर निर्भर एक dummy package बनता है। मैं आम तौर पर Gentoo जैसा अहसास लाने के लिए /etc/apk/sets/ में shell scripts बनाता हूँ, लेकिन यह हमेशा एक जैसा नहीं होता
    • जितने समय में Nix मेरे system flake का evaluation करता है, उतने में Alpine को शुरू से फिर से install किया जा सकता है
    • यह अच्छा है, लेकिन Nix/OS declarative package installation से कहीं ज़्यादा काम करता है

  • पहले Docker में Alpine चलाने को लेकर performance संबंधी पोस्टें थीं, और मुझे याद है कि लोग Debian/Ubuntu इस्तेमाल करने की सलाह देते थे
    Alpine के धीमे होने पर लेख:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Alpine के पक्ष में लेख:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    जानना दिलचस्प होगा कि क्या यह बात आज भी लागू होती है

    • कम से कम कुछ ठोस शिकायतें अब सुलझ चुकी हैं। जैसा कि पहले लिंक के बिलकुल नीचे भी माना गया है, Alpine-compatible Python wheels अब मौजूद हैं, और DNS समस्या भी काफ़ी पहले ठीक हो चुकी थी
      फिर भी performance के लिहाज़ से benchmark चलाकर वास्तविक आँकड़े देखना दिलचस्प होगा

  • क्या musl अब भी pthread_attr_setaffinity_np को support नहीं करता? अगर हाँ, तो कुछ software चल ही नहीं सकते, और सबसे बड़ा उदाहरण PyTorch है

    • अगर performance-sensitive workloads अपनी performance के कारण glibc पर निर्भर हैं, तो शायद सिर्फ़ उसी application को container में “बस” चला देना चाहिए
      कई स्थितियों में performance से ज़्यादा सरलता या सुरक्षा अधिक महत्वपूर्ण चिंता होती है

  • BSD और Linux के बीच मुझे जो ठीक-ठाक मध्य बिंदु मिला, वह Slackware है। खुलकर Unix-जैसा, जटिल नहीं, और Slackbuilds के ज़रिए इसका अपना समृद्ध ports tree भी है

    • Slackware ने desktop distribution से प्रतिस्पर्धा करने की कोशिश की, लेकिन पूरी तरह समर्पित हुए बिना ही दिशा खो दी
      पहले मुझे यह इसलिए पसंद था क्योंकि यह बिना दखल देने वाली minimal distribution थी, और मुझे लगता था कि यह थोड़ा अधिक technical लोगों के लिए है
      लेकिन जब भी आप किसी समस्या में गहराई से जाते, community कभी-कभी इस वजह से hostile हो जाती कि आपने full install नहीं किया। full install इसलिए recommended था, और अगर आप ऐसा न करें तो samba न होने की वजह से mplayer न चलने जैसी बेवकूफ़ाना dependency समस्याएँ भी आती थीं
      मेरे हिसाब से Alpine हर मायने में Slackware से बेहतर है
    • मैं Slackware इस्तेमाल करने वालों का सम्मान करता हूँ, लेकिन dependency management की कमी काफ़ी झंझटभरी लगती है

  • तो Alpine Linux असल में GNU/Linux नहीं निकला। यह मुझे पता नहीं था
    तो क्या इसे BusyBox/Linux कहना चाहिए?

    • इसे बस Alpine Linux कहना काफ़ी है। जहाँ तक मुझे पता है, BusyBox का RMS से जुड़ी कभी-कभार झलकने वाली आत्म-प्रदर्शक हरकतों से कोई लेना-देना नहीं है, इसलिए यह ठीक है