सर्वरों के लिए वेब-आधारित ग्राफिकल इंटरफ़ेस Cockpit

 (cockpit-project.org)
6 पॉइंट द्वारा GN⁺ 2023-10-17 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Cockpit Linux सर्वरों को ब्राउज़र से मैनेज करने के लिए एक ग्राफिकल इंटरफ़ेस है, जिससे शुरुआती और पेशेवर एडमिन अलग-अलग सिस्टम की स्थिति को जल्दी देख और संचालित कर सकते हैं
  • यह कमांड लाइन की तरह ही system API और commands का उपयोग करता है, इसलिए Cockpit, CLI, Ansible और मौजूदा server management tools को साथ इस्तेमाल करने पर भी management workflow में टकराव नहीं होता
  • नेटवर्क, firewall, RAID·LUKS storage, virtual machines, containers, logs, hardware, updates, performance, user accounts, systemd services और remote terminal को एक ही स्क्रीन से संभाला जा सकता है
  • डिफ़ॉल्ट authentication सिस्टम के सामान्य user login और permissions का पालन करता है, साथ ही single-sign-on और अन्य authentication methods का भी समर्थन करता है, और ज़रूरत पड़ने पर ही systemd socket activation के ज़रिए चलता है
  • इसे प्रमुख Linux distributions पर install करने के बाद Windows, MacOS, Android सहित किसी भी operating system के ब्राउज़र से server के 9090 port पर कनेक्ट करके इस्तेमाल किया जा सकता है

ब्राउज़र में व्यक्तिगत सर्वर प्रबंधन

  • Cockpit सर्वरों के लिए बनाया गया एक एकीकृत web-based graphical interface है
  • इसके target users बहुत व्यापक हैं
    • Linux के शुरुआती उपयोगकर्ता, जिनमें Windows administrators भी शामिल हैं
    • वे उपयोगकर्ता जो Linux से परिचित हैं लेकिन graphical तरीके से सर्वर आसानी से मैनेज करना चाहते हैं
    • पेशेवर एडमिन जो मुख्य रूप से अन्य tools इस्तेमाल करते हैं, लेकिन अलग-अलग सिस्टम का overview देखना चाहते हैं
  • इसे मौजूदा management तरीके को बदलने के बजाय, एक ही सिस्टम को कई तरीकों से मैनेज करने लायक बनाया गया है
    • Cockpit और command-line utilities को साथ इस्तेमाल किया जा सकता है
    • Ansible और अन्य मौजूदा tools का उपयोग जारी रखा जा सकता है
    • non-Linux devices से कनेक्ट होने पर काम आने वाला built-in terminal भी दिया गया है
  • Linux commands याद किए बिना भी web browser में server status देखकर mouse से काम किया जा सकता है
    • containers शुरू करना
    • storage मैनेज करना
    • network settings कॉन्फ़िगर करना
    • logs की जांच करना
  • Cockpit को व्यक्तिगत सर्वरों के लिए एक ग्राफिकल “desktop interface” की तरह देखा जा सकता है

authentication, integration और विस्तार का तरीका

  • Cockpit सिस्टम में पहले से मौजूद API का उपयोग करता है, और कोई नया lower-level subsystem नहीं बनाता या अपनी अलग tool layer नहीं जोड़ता
  • डिफ़ॉल्ट रूप से यह सिस्टम के सामान्य user login और permissions का उपयोग करता है
    • पूरे network में login के लिए single-sign-on और अन्य authentication तकनीकों का समर्थन है
  • उपयोग न होने पर यह बैकग्राउंड में लगातार नहीं चलता, बल्कि systemd socket activation के ज़रिए ज़रूरत पड़ने पर शुरू होता है
  • हर Cockpit host पर किए जा सकने वाले काम इस प्रकार हैं
    • network settings देखना और बदलना
    • firewall settings
    • RAID और LUKS partitions सहित storage मैनेजमेंट
    • virtual machines बनाना और मैनेज करना
    • containers डाउनलोड और रन करना
    • system logs ब्राउज़ और सर्च करना
    • system hardware देखना
    • software upgrades
    • performance मॉनिटर करना
    • user accounts मैनेज करना
    • systemd-आधारित services को देखना और उनके साथ interact करना
    • local web browser से remote server terminal का उपयोग
    • कई Cockpit servers के बीच स्विच करना
    • apps और add-ons install करके features बढ़ाना
    • custom modules लिखना
  • इसे troubleshooting के लिए भी इस्तेमाल किया जा सकता है
    • network problems का diagnosis
    • खराब चल रही virtual machines को ढूँढना और संभालना
    • SELinux logs देखना और सामान्य violations को एक क्लिक में ठीक करना
    • CPU load, memory usage, network activity और storage performance के detailed metrics को system journal से जोड़कर देखना
  • यह optional और third-party applications को सपोर्ट करता है
  • usability research के आधार पर इसके design को test और refine किया जाता है, और हर code change को merge से पहले अनिवार्य tests से गुजरना होता है
  • यह मुफ़्त में उपलब्ध है और GNU LGPL के तहत दिया जाता है

installation और access

  • इसे प्रमुख distributions पर install किया जा सकता है, और चलने के बाद किसी भी operating system के प्रमुख web browsers से access किया जा सकता है
    • Windows, MacOS, Android सहित
    • install और enable करने के बाद server के 9090 port पर कनेक्ट करें
    • उसी मशीन के browser से https://localhost:9090/ पर access किया जा सकता है
  • Cockpit का time-based release cycle है, और नया version हर 2 हफ्ते में आता है

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

2 टिप्पणियां

 
GN⁺ 2023-10-17
Hacker News राय

  • ग्राफिकल मैनेजमेंट इंटरफ़ेस को कोसना और सिर्फ command line को पसंद करना काफी हद तक पेड़ों को देखकर जंगल न देख पाने जैसा रवैया है
    क्लिक करके server चलाना कोई अच्छा तरीका नहीं है, लेकिन सच कहें तो ऑपरेशन के तरीके के तौर पर ssh भी वैसा ही है
    वास्तविक production server की state शुरू से reproducible होनी चाहिए, और OS install, software add, settings apply करने के बाद उसे छेड़े बिना छोड़ देना ही बेहतर है
    ssh हो या Cockpit, सीधे अंदर जाने पर कुछ न कुछ बिगाड़ देने की संभावना ज्यादा होती है
    server में सीधे जाना सिर्फ exploratory काम करते समय होना चाहिए, और उस समय GUI और command line में श्रेष्ठता इतनी साफ नहीं होती
    GUI की discoverability और visibility बेहतर होती है, इसलिए settings का तरीका खोजने वाले experiment phase में यह मदद करता है

    • “क्लिक-आधारित operation server चलाने का तरीका नहीं है”, “server state शुरू से reproducible होनी चाहिए” जैसी बातें बहुत self-evident truth की तरह इस्तेमाल होती हैं, लेकिन असल में engineering trade-off की जरूरत होती है
      यह समझाना जरूरी है कि server state शुरू से reproducible क्यों होनी चाहिए, “शुरू से” का मतलब क्या है, और क्लिक-आधारित operation क्यों नहीं चलेगा
      यह मानना भी मुश्किल है कि OS install, software add और settings apply भर से server state पूरी तरह capture हो जाती है
      software patch level, application data और user data भी server state में शामिल होते हैं
      production server state को backup से restore करके सटीक रूप से reproduce किया जा सकता है, और backup/restore क्लिक-आधारित operation के साथ भी अच्छी तरह फिट बैठता है; यह OS reinstall और configuration scripts से तेज और ज्यादा भरोसेमंद हो सकता है
      अगर server non-volatile data store करता है, तो नया server deploy करने के बाद user data restore करने के लिए वैसे भी backup system चाहिए
    • यह premise ऐसे environment को मानकर चलता है जहाँ servers को pets नहीं बल्कि cattle की तरह treat किया जाता है
      हर कोई orchestration platform पर बड़े पैमाने का web platform नहीं चला रहा होता
      फिर भी pet-style server के लिए भी recovery या rebuild का तरीका पता होना चाहिए; नहीं तो इसका मतलब है कि सही disaster recovery strategy नहीं है
    • “production server state को शुरू से reproduce” करने के लिए कौन-सा tool मन में है, यह जानने की उत्सुकता है
      homelab में Raspberry Pi setup के लिए Ansible इस्तेमाल कर रहा हूँ, और OS install वाला हिस्सा boot media पर image को bit-by-bit copy करने और कुछ optional settings करने का है, इसलिए यह संभव लगता है
    • उस standard के हिसाब से तो लगता है कि बस NixOS ही इस्तेमाल करना होगा
    • दोनों अलग-अलग वजहों से अच्छे हैं
      मैं terminal work को prefer करता हूँ, लेकिन visualization के लिए GUI बेहतर है—यह बहस की बात भी नहीं लगती

  • इस project की शानदार बात यह है कि यह systemd socket activation इस्तेमाल करता है, इसलिए हमेशा चलने वाला server process जरूरी नहीं होता
    जब Cockpit इस्तेमाल नहीं हो रहा होता, तो resource waste नहीं होता, और page access करना असल में command line tool चलाकर फिर बंद करने जैसा ही है
    design सचमुच खूबसूरत है

    • निष्पक्षता से कहें तो BSD4.3 के inetd के बाद से 1986 से ही मिलता-जुलता तरीका मौजूद था
      implementation की details अलग थीं, लेकिन बड़ा idea वही था; एक समय यह लोकप्रिय था, पर किसी खास वजह के बिना fashion से बाहर हो गया
      अच्छे server process को कुछ न होने पर idle रहना चाहिए और actual memory usage भी बहुत छोटा होना चाहिए ताकि swap out करना आसान हो
      अगर कोई server अपने use case के कारण बहुत memory इस्तेमाल करता है, तो on-demand start से बीच-बीच में memory pressure पैदा होना भी आप नहीं चाहेंगे
      हालांकि initial boot के समय service start का इंतजार करते हुए block होने की समस्या से बचना आसान हो जाता है, इसलिए boot performance में मदद मिलती है
    • इसे खोजते हुए लगा कि Ubuntu 22.10 के बाद का SSHD भी systemd socket activation इस्तेमाल करता है
      जब तक कोई SSH से connect नहीं करता, sshd process start नहीं होता
      https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
    • लगता है systemd को और सीखना चाहिए
      जितना अंदर देखते हैं, उतने ही शानदार और उपयोगी features लगातार मिलते हैं
    • Cockpit लगभग 99% “command line से करने से अलग नहीं” के करीब है, और यह एक छोटा JavaScript terminal GUI, native users और passwords, हल्की monitoring history, और जटिल systemd commands याद रखे बिना settings explore करने की सुविधा भी देता है, इसलिए काफी बढ़िया है
      इसे छोटे Raspberry Pi devices पर install करके रखना अच्छा है
      जब terminal के सामने न हों तब status पर नजर डालने के लिए, या सिर्फ web browser उपलब्ध होने की स्थिति में web server के जरिए लगभग native जैसा SSH connect करने और वास्तविक command prompt में curl ...etc... चलाने के लिए यह बहुत उपयोगी है
    • फिर भी लगता है कि Cockpit webapp के static HTML/JS assets serve करने वाला server process तो चल रहा होगा
      क्या systemd socket activation का मतलब यह है कि यह सिर्फ तब इस्तेमाल होता है जब end user's web client log lookup जैसी REST/GQL requests भेजता है?

  • “porcelain” की अपनी value होती है
    ready-made backend होने के बावजूद product development को UI/UX तक आगे न बढ़ा पाने के कारण बंद हुए startups देखे हैं
    एक company में मैंने दिखाया था कि पूरी तरह custom container orchestrator वाले backend को एक weekend में AWS Lambda और ECS से replace किया जा सकता है, लेकिन UI/UX और workflow tools में कहीं ज्यादा समय लगना था
    फिर भी उन्होंने “नया Raft-based cluster” बनाने में पैसा और समय बर्बाद करना जारी रखा
    इसी बीच मुझे “batch processing add” करने का काम मिला, और चूँकि वे पहले से Go इस्तेमाल कर रहे थे, मैंने internally Nomad जोड़कर आगे बढ़ा दिया
    सिर्फ technology के लिए technology नहीं, बल्कि features ship करने वाली team में काम करना अच्छा है
    https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

  • इस क्षेत्र के हर tool में “disk space कम है” वाला एक बड़ा banner होना चाहिए
    server debug करने वाले लोगों के लिए भी यह आश्चर्यजनक रूप से कई बार common sense नहीं होता

    • पता नहीं क्यों, लेकिन मैंने भी यही देखा है

  • 2022 में, 81 टिप्पणियां: https://news.ycombinator.com/item?id=31439811
    2021 में, 128 टिप्पणियां: https://news.ycombinator.com/item?id=26197510
    2018 में, 149 टिप्पणियां: https://news.ycombinator.com/item?id=16445612

    • जब कोई project mature हो जाता है और ज्यादा लोग उसके बारे में जानने लगते हैं, तो इस तरह का रुझान कुछ हद तक अपेक्षित होता है

  • लगता नहीं कि मैं इसे इस्तेमाल करूंगा
    एक और खुला port, vulnerabilities को लगातार scan करने वाले bots के लिए एक और attack surface, और एक और service जिसे हमेशा up to date रखना पड़ेगा
    हालांकि Linux server को ज्यादा accessible बनाने में यह मददगार लग सकता है
    खासकर उन लोगों के लिए उपयोगी है जो PHP-based shared hosting से full VPS पर जा रहे हैं, लेकिन server knowledge ज्यादा नहीं है और cPanel या DirectAdmin जैसा कुछ चाहते हैं

    • port खोलना जरूरी नहीं है; इसके बजाय VPN या SSH tunnel इस्तेमाल कर सकते हैं
      दोनों में फर्क क्या है, यह मुझे ठीक से नहीं पता

  • मैं सचमुच RHCE हूं, और इस thread में इतनी artificial positive vibe है कि यह Red Hat की तरफ के click farm जैसा लगता है
    Cockpit ठीक-ठाक है, लेकिन असल में यह Red Hat वाला Windows Server Manager जैसा है, और शायद Server Manager से सीधे प्रभावित भी हुआ हो
    कई सालों तक development और improvement की रफ्तार भी तकलीफदेह रूप से धीमी रही
    जो लोग SSH session के आदी हैं, वे नई VM बनाने जैसे मामलों को छोड़कर Cockpit इस्तेमाल नहीं करते, और इसकी तुलना Proxmox से करना बेमतलब है
    इसमें Proxmox UI की एक-चौथाई features भी नहीं हैं, और VM management features भी comparatively हाल ही में आए हैं; ऊपर से browser के जरिए आने वाली latency और constraints की वजह से Virtual Machine Manager अब भी बेहतर है
    Cockpit से बहुत-सी चीजें नहीं की जा सकतीं, और आगे भी बहुत-सी चीजें नहीं हो पाएंगी
    यह ज्यादा उन लोगों के लिए tool है जो click करना चाहते हैं, Bash for/while loop नहीं लिख सकते, pipe chaining नहीं समझते, और vim से नफरत करते हैं
    कहें तो यह Red Hat के लिए webmin है; थोड़ा stylish जरूर है, लेकिन बहुत पुराना है, development धीमी रही है, और इसे जरूरत से ज्यादा hype किया गया है, इसलिए certification exam के लिए जरूरी चीजों के अलावा मैंने इसे कभी इस्तेमाल नहीं किया

    • यह कुछ ऐसा कहने जैसा है कि “Instagram filters उन लोगों के लिए हैं जिन्हें Photoshop layers संभालना नहीं आता, basic color compositing भी नहीं समझते, और बस swipe करना चाहते हैं”
      यानी बात सही भी है
    • HN guidelines कहती हैं कि “astroturfing, PR accounts, brigading, foreign agents” जैसे संकेत discussion quality को गिराते हैं और आम तौर पर अक्सर गलत होते हैं, इसलिए उन्हें post न करें
      अगर abuse की चिंता हो, तो hn@ycombinator.com पर mail भेज सकते हैं; कहा गया है कि वे data देखते हैं
      https://news.ycombinator.com/newsguidelines.html
    • क्या हमें SSH-capable terminal emulator हमेशा deployed रखने के लिए तैयार रहना चाहिए? आसान कामों को आसान बनाने में क्या दिक्कत है, समझ नहीं आता
      जब परिवार travel करता है, तो pets को देखने के लिए मैं बेहतर camera modules वाले कई Raspberry Pi cameras चलाता हूं
      RTSP camera streams हर device पर systemd unit के रूप में चलती हैं, और packet streaming हो रही है या नहीं यह check करने वाला healthcheck भी एक अलग systemd unit है
      हर camera को मेरे managed ZeroTier network में private IP मिलता है
      Cockpit जरूरत पड़ने पर ही चलता है, इसलिए management के लिए इसे install करके रखने से बचने की कोई वजह नहीं
      कभी-कभी कोई camera सिर्फ blank frames भेजना शुरू कर देता है; vacation पर keyboard ढूंढकर SSH से login करके stream unit restart करने की बजाय phone के Cockpit web interface से करना कहीं बेहतर है
      blank frames detect करने वाला healthcheck भी बना सकता हूं, लेकिन साल में कुछ ही बार होने वाली चीज के लिए उसे लिखने से Cockpit में restart करना कहीं ज्यादा आसान है
    • Cockpit, खराब documentation वाले XML में झांकने के बिना remote से libvirt + KVM manage करने के लिए बहुत उपयोगी है
      iPad सहित किसी भी platform से access किया जा सकता है, और setup भी लगभग न के बराबर है—package install और certificate add करने जितना
      जिन Debian servers पर VM चलती हैं, वहां Proxmox के बजाय Cockpit इस्तेमाल करता हूं, क्योंकि यह काफी कम intrusive है और वे machines Docker containers जैसे दूसरे काम भी साथ में करती हैं
      करीब 2019 से इसे इसी use case के लिए इस्तेमाल कर रहा हूं
      stats screen भी useful है, लेकिन सिर्फ उसी के लिए शायद install नहीं करूंगा
      पूरे system पर कब्जा किए बिना single machine पर web browser से libvirt VM बनाने देने वाले, well-maintained alternatives बहुत कम हैं
    • मुझे यह आधा-अधूरा webmin लगता है
      इसे सिर्फ NetworkManager के साथ इस्तेमाल किया जा सकता है, लेकिन VM के लिए network configuration जरा भी complex हो जाए तो आमतौर पर NetworkManager बंद करना पड़ता है, इसलिए Cockpit practically unusable हो जाता है
      जो लोग GUI से VM manage करना चाहते हैं, उनके लिए virt-manager कहीं ज्यादा powerful है
      [1] https://virt-manager.org/

  • quality “बस ठीक-ठाक” स्तर की है
    बहुत छोटे subset of use cases में काम आ सकता है, लेकिन अगर home server चला रहा होता तो इससे बचता
    Cockpit का file server interface plugin पुराना और अच्छा नहीं है
    समझ नहीं आता आखिर इसे कहां इस्तेमाल किया जाए; basic monitoring तक तो संभव है, लेकिन management tool के रूप में यह खास नहीं है

    • बिल्कुल यही
      समझ नहीं आता Red Hat इस project को क्यों push कर रहा है, और इसके practical use cases ज्यादा नहीं हैं
      systemd services की list दिखाना, command-line output में सब देखने से ज्यादा मददगार नहीं है

  • जब NAS को खुद host करना हो, तो मुझे लगता है Cockpit OMV से काफी बेहतर है

    • यह उपयोग और कुछ शर्तों पर निर्भर करता है, और मैं दो अलग-अलग NAS पर दोनों से संतुष्ट होकर इस्तेमाल कर रहा हूँ
      OMV में Compose support वाला Docker plugin है, इसलिए Portainer जैसा अलग Docker GUI ज़रूरी नहीं होता, और Windows clients पर SMB shares किसी वजह से ज़्यादा stable हैं
      इसका GUI और approach beginner-friendly है, इसलिए इसे दूसरे users के साथ share करना भी आसान है, और fail2ban व WireGuard जैसे built-in features भी हैं
      Cockpit, EL/Fedora distributions में first-class citizen है, और Podman support करता है, लेकिन Docker नहीं; Compose/Quadlet support भी नहीं है
      इसमें VM management और terminal जैसे powerful features हैं, लेकिन Samba से जुड़े bugs हैं
    • मुझे जानना है कि ऐसा क्यों है
      फिलहाल मैं OMV से local network file sharing और कुछ Docker containers चला रहा हूँ
      यह ठीक चलता है, लेकिन मैं इसके 90% features इस्तेमाल नहीं करता
    • जानना चाहूँगा कि Proxmox कैसा है

  • जिन लोगों को curiosity है, उनके लिए: https://github.com/cockpit-project/cockpit के अनुसार Cockpit कई भाषाओं में लिखा गया है, जिनमें C सबसे अधिक है, उसके बाद JavaScript और Python आते हैं
    src/cockpit शायद मुख्य backend logic लगता है और Python में है

    • Cockpit developer के तौर पर कहूँ तो, web server C में लिखा गया है, और पुराना bridge एक “API” था जिसके जरिए JavaScript, web server के माध्यम से systemd, podman, dbus जैसे system APIs से communicate करता था
      नया bridge Python में लिखा गया है, और समय आने पर हम web server को भी किसी ज़्यादा modern तरीके से फिर से लिखना चाहेंगे
    • server पर चलने वाला product बनाते समय कौन-सा tech stack इस्तेमाल हुआ है, लोग इसकी कितनी परवाह करते हैं—यह जानने की उत्सुकता है
      कौन-सी dependencies हैं, logging library या Curl vulnerabilities की चिंता करनी चाहिए या नहीं—ये बातें भी महत्वपूर्ण हैं
      यह देखना भी दिलचस्प है कि product एक साफ़-स्पष्ट stack में लिखा गया है या कई technologies का mix है