Show HN: Systemd แบบอินเทอร์แอ็กทีฟ – วิธีที่ดีกว่าในการทำงานกับยูนิต Systemd

 (isd-project.github.io)
2 คะแนน โดย GN⁺ 2025-01-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • isd เป็นเครื่องมือที่มอบวิธีที่ดีกว่าในการจัดการยูนิต systemd โดยมีเทอร์มินัลยูสเซอร์อินเทอร์เฟซ (TUI) สำหรับค้นหายูนิต อัปเดตพรีวิวอัตโนมัติ จัดการ sudo อย่างชาญฉลาด และมีอินเทอร์เฟซที่ปรับแต่งได้

แรงจูงใจสั้นๆ

  • isd ช่วยทำให้กระบวนการที่ซับซ้อนในการโต้ตอบกับยูนิต systemd ง่ายขึ้น และแสดงข้อมูลที่เป็นประโยชน์ให้ผู้ใช้
  • ลดความยุ่งยากจากการต้องพิมพ์คำสั่ง systemctl ซ้ำๆ และรีเฟรชผลลัพธ์ที่แสดงให้อัตโนมัติ

การติดตั้ง

  • สามารถติดตั้ง isd ได้ผ่าน AppImage, nix และ uv
  • AppImage เป็นไฟล์รันเดี่ยวที่ใช้งานได้บนทุก Linux distribution และยังใช้ได้บนรีโมตเซิร์ฟเวอร์ที่มีข้อจำกัดด้านสิทธิ์
  • หากต้องการติดตั้ง isd ในสภาพแวดล้อม nix สามารถติดตั้งผ่านแพ็กเกจ nix ได้
  • uv เป็นตัวจัดการแพ็กเกจ Python ซึ่งสามารถใช้ติดตั้งและจัดการ isd ได้

วิธีใช้ isd

  • isd สามารถค้นหายูนิต systemd ตรวจสอบสถานะ และแสดงพรีวิวข้อมูลรายละเอียดของหลายยูนิตได้
  • ส่งคำสั่ง systemctl ไปยังยูนิตที่เลือก และอัปเดตผลลัพธ์สถานะโดยอัตโนมัติ
  • สามารถเปิด pager ภายใน isd เพื่อดูผลลัพธ์สถานะแบบเต็มได้
  • สามารถเปิด pager แยกสำหรับผลลัพธ์ Journal และตั้งค่าธีมกับคีย์ไบน์ดิงที่ปรับแต่งเองได้

โหมดผู้ใช้/ระบบ

  • isd ทำงานได้ในโหมด user หรือ system และประเภทของยูนิตที่แสดงจะแตกต่างกันไปตามโหมด

การค้นหาแบบฟัซซี

  • ผ่านแถบค้นหาแบบฟัซซี สามารถโหลดทุกยูนิตและไฟล์ยูนิตที่ตรงกับข้อความที่ป้อน และไฮไลต์ตามสถานะปัจจุบันได้

การเลือกหลายยูนิต

  • สามารถเลือกหลายยูนิตได้ในวิดเจ็ตผลการค้นหา และมีพรีวิวของยูนิตที่เลือกให้

Command palette

  • สามารถเปิด command palette เพื่อดูคำสั่งทั้งหมดที่ใช้งานได้และคีย์ไบน์ดิง

คำสั่ง

  • ตัวอย่างเช่น กด Ctrl+O เพื่อหยุดยูนิตที่เลือกได้

การรองรับเพจเจอร์

  • ระหว่างที่ใช้งาน isd สามารถเปิด pager เพื่อดูผลลัพธ์พรีวิวแบบเต็มได้

การปรับแต่ง

  • isd รองรับการปรับแต่งและการตั้งค่าที่หลากหลาย โดยมีธีมและคีย์ไบน์ดิงหลายแบบเพื่อช่วยให้ผู้ใช้ทำงานได้อย่างมีประสิทธิภาพสูงสุด

สรุป

  • แนะนำให้ลองใช้งาน isd ด้วยตัวเองเพื่อดูว่ามีประโยชน์กับคุณหรือไม่

ขั้นตอนถัดไป

  • ดูส่วนการปรับแต่งและความปลอดภัย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-19
ความคิดเห็นจาก Hacker News

  • ดูดีเลย
    วิธีจัดการ ExecStop ในสคริปต์บริการของ systemd ทำให้สับสนจริง ๆ
    ExecStart คือคำสั่งที่จะรันตอนระบบบูตหรือเมื่อผู้ใช้เริ่มบริการ แต่ ExecStop จะรันหลังจากคำสั่งเริ่มต้นจบลง
    ถ้าต้องการให้คำสั่ง stop รันตอนปิดระบบหรือเมื่อผู้ใช้หยุดบริการ ต้องตั้งค่า RemainAfterExit=yes
    จริง ๆ แล้ว ExecStop ใกล้เคียงกับอีเวนต์ “ช่วง cleanup” มากกว่าอีเวนต์ “สำหรับหยุดบริการ”

    • คิดเป็น “ตอนเริ่ม” กับ “ตอนหยุด” ก็พอ
      ต้องจำไว้ว่า systemd ถูกออกแบบมาให้เหมาะกับ daemon
      ถ้าบริการแค่รันคำสั่งเดียวที่สักวันจะจบลง ต้องบอก systemd ให้ปฏิบัติต่างจาก daemon อย่างชัดเจน
      อย่างที่คนอื่นบอกกัน อาจเป็นไปได้ว่าส่วนผสมที่ต้องการคือ oneshot + RemainAfterExit
    • ใน type=forking นั้น ExecStop ทำงานในแบบที่คาดไว้

  • ชอบมากจริง ๆ
    เคยใช้แต่ command line ล้วน ๆ จนเริ่มเหนื่อย แล้วช่วงหลังเริ่มใช้เครื่องมืออย่าง lazygit/lazydocker เพื่อส่องสถานะของระบบ/ทรีที่มองไม่ค่อยเห็น ทำให้ productivity เพิ่มขึ้นมาก
    ผมจัดการบริการหลายตัวทั้งระดับผู้ใช้และระดับระบบ แต่การ debug น่าเบื่อมาก
    ส่วนในประโยคแรกที่ไล่คำสั่งที่ใช้กันบ่อย ๆ กับความลำบากของมันนี่โดนใจจริง ๆ
    เพราะใช้ NixOS วิธีแก้ไขไฟล์ unit ที่ immutable โดยตรงคงทำไม่ได้ แต่การสำรวจบริการ การมองเห็นสถานะ และการจัดการน่าจะช่วยได้มาก

    • ผมก็เป็นผู้ใช้ NixOS เหมือนกัน และจุดนี้เองที่ทำให้เริ่มทำโปรเจกต์นี้
      มีแผนจะเพิ่ม “guide” ในเอกสาร สรุปคือเวลาจะ debug unit บน NixOS ลองดู systemctl edit --runtime จะดี
      ทำให้ debug ง่ายขึ้นมาก

  • ดูดีมาก
    ผมดูแลโปรเจกต์คล้าย ๆ กันอยู่ และการทำงานกับ systemd/dbus API ค่อนข้างเจ็บปวด
    อยากลองใช้ตัวนี้ดูว่าจะมีอะไรให้เรียนรู้ไหม
    https://github.com/rgwood/systemctl-tui

    • สุดยอดมาก
      น่าจะได้ใช้เยอะเลย
      ที่ขาดก็มีแค่ deb package เท่านั้น

  • ในที่สุด systemd-client ก็มาแล้ว ดีใจมาก
    ขั้นต่อไปอยากให้เป็น TUI สำหรับแพลตฟอร์มที่ไม่ใช่ Linux อย่าง macOS, FreeBSD, Windows
    บน macOS ผมใช้ LaunchControl.app อยู่ แต่มันไม่ใช่ TUI
    อย่างหนึ่งคือใน uv 0.5.21 ต้องทำแบบด้านล่าง และ uvx ใช้ไม่ได้เลย
    $ uv tool install git+https://github.com/isd-project/isd
    แต่ $ uv tool install https://github.com/isd-project/isd/isd@latest ในเอกสารใช้ไม่ได้
    ถึงอย่างนั้น uv ก็เร็วกว่า pip(x) มาก เลยย้ายมาใช้แล้ว

    • เป็นความผิดพลาด และตอนนี้แก้แล้ว
      ขอบคุณที่แจ้งให้ทราบ

  • เจ๋งดีที่ uv ทำให้ติดตั้งเครื่องมือแบบนี้ง่ายขนาดนี้
    สิ่งที่ขาดไปในขั้นตอนติดตั้งคือ uv จะติดตั้งเครื่องมือนี้โดยไม่สนใจ dependency ของ Python
    เครื่องของผมเป็น 3.10 ทำให้ isd ใช้งานไม่ได้ และแก้ได้ด้วยออปชัน -p 3.13
    น่าจะควรกล่าวถึงในเอกสาร

    • ขอบคุณที่แจ้งให้ทราบ
      เพิ่ม flag นั้นไว้ในเอกสารแล้ว

  • “ถ้าเคยหงุดหงิดระหว่างพิมพ์” นี่ตรงกับผมเลย
    ทั้งที่ผมชอบ systemd นะ
    ยังไม่ได้ลองติดตั้ง แต่สงสัยว่าสามารถเชื่อมต่อไปยัง remote host ได้ไหม
    ผมใช้ systemctl --host status foo.service บ่อย และตรวจ status, timers, logs ฯลฯ จากระยะไกล

    • เพิ่งเคยได้ยิน systemctl --host เป็นครั้งแรก
      น่าเสียดายที่ยังไม่รองรับ
      โดยคร่าว ๆ แล้วมันเป็น wrapper สวย ๆ ที่ครอบ systemctl ในเครื่อง local
      แต่มี AppImage อยู่ ดังนั้นหวังว่าน่าจะรันบนเซิร์ฟเวอร์ระยะไกลได้ง่าย
      อย่างไรก็ดี ถ้าเปิด issue ไว้จะลองดูให้

  • บนเซิร์ฟเวอร์ระยะไกลหรือ Docker image เราติดตั้งของแบบนี้ไม่ได้
    ต้องมี backend หลายแบบ สำหรับรันคำสั่งและรวบรวมข้อมูล: local, SSH, Docker
    ควรติดตั้งไว้ในเครื่อง local แล้วรันคำสั่งบนเครื่องระยะไกลผ่าน SSH และรันผ่าน docker exec ได้ด้วย

  • ผมสงสัยว่า “ถ้าติดตั้ง Nix ไว้ AppImage นี้จะไม่ทำงาน” นั้นถูกต้องจริงหรือเปล่า
    เข้าใจเหตุผลที่ใช้ไม่ได้บน NixOS ดูเหมือนว่ามันจะรัน systemctl ของโฮสต์ไม่ได้
    แต่ถ้าเป็นแค่ OS อื่นที่ติดตั้ง Nix ไว้เฉย ๆ ก็ไม่เห็นเหตุผลว่าทำไมถึงจะใช้ไม่ได้
    น่าสนใจที่ใน Nix v2.24.11 คำสั่ง Nix ที่ให้มาก็ใช้ไม่ได้เช่นกัน
    $ nix run https://github.com/isd-project/isd ล้มเหลวด้วย Failed to open archive (Unrecognized archive format)
    ถ้าเปลี่ยนเป็นรูปแบบ Git URL อาจทำงานได้ แต่ใน Nix มี GitHub fetcher พื้นฐานที่มีประสิทธิภาพกว่า ดังนั้นคำสั่งจริงน่าจะเป็น nix run github:isd-project/isd
    ตัวโปรเจกต์เองเจ๋งมาก
    เดิมทีเคยอยากทำอะไรคล้าย ๆ กันด้วย DBus API ของ systemd และ Qt และก็เขียนโค้ดไว้บ้างแล้ว
    DBus API มีแนวโน้มสูงว่าจะให้ฟังก์ชันที่จำเป็นได้แทบทั้งหมด แน่นอนว่าการเรียก systemd -H ง่ายกว่าการทำ SSH tunneling เองมาก
    น่าหงุดหงิดที่ systemd และ Linux สมัยใหม่มีข้อมูลและอินเทอร์เฟซมากมายที่จะช่วยให้การจัดการระบบ โดยเฉพาะการจัดการเดสก์ท็อปที่ตามธรรมเนียมแล้วมองไม่ค่อยเห็นภายใน ทำได้ง่ายขึ้น แต่กลับไม่ค่อยถูกเปิดเผยออกมา
    เมื่อก่อนเวลาที่แอป xdg autostart ล้มเหลว ก็ยากที่จะรู้ว่าเกิดอะไรขึ้น แต่ตอนนี้ในเดสก์ท็อปบางตัว systemd เป็นตัวรันแอป xdg autostart แล้ว จึงทำ GUI ที่แสดงรายการ autostart ที่ล้มเหลวพร้อม log viewer ได้ง่าย
    แต่ดูเหมือนไม่มีเครื่องมือที่มีการดูแลต่อเนื่องและฟีเจอร์ค่อนข้างครบอยู่เลย เลยน่าหงุดหงิดอยู่พอสมควร

    • ใช่ครับ มันซับซ้อนขึ้น เลยไม่อยากแนะนำพร้อมอธิบายรายละเอียด
      สรุปคือ AppImage ถูก สร้างด้วย nix และ AppImage จะ “เมานต์” ไดเรกทอรี /nix/ ที่อยู่ภายใน AppImage ไม่ใช่ overlay
      ดังนั้นการเรียกจาก TUI ที่เข้าถึง /nix/ จะไม่ได้ไปยังไดเรกทอรี /nix ของระบบ และจะเกิดปัญหาแปลก ๆ สารพัด
      เช่น บน Ubuntu คุณอาจติดตั้ง EDITOR ด้วย home-manager ได้
      systemctl “เข้าถึงได้” ดังนั้น isd จึงเริ่มได้ตามปกติ แต่พอเปิด EDITOR ใต้ /nix ก็หาไม่เจอ ซึ่งทำให้ผู้ใช้สับสนมาก
      ดังนั้นถ้าใช้ Nix อยู่แล้ว การบอกให้ใช้วิธีติดตั้งผ่าน Nix จึงง่ายกว่า
      เอกสารที่ผิดตอนนี้แก้แล้ว
      เข้าใจความหงุดหงิดนั้นเหมือนกัน
      โดยส่วนตัวถ้าได้ทำเครื่องมือแบบนั้นคงสนุกมาก แต่ไม่ใช่งานง่าย และยังมีปัญหาว่าใครจะสนับสนุนงานนั้น
      TUI นี้แม้ขอบเขตจะยังจัดการได้ ก็ยังใช้แรงทำค่อนข้างมาก
      ดังนั้นผมคงไม่น่าจะลงทุนกับ “อินเทอร์เฟซระดับสูง” มากเกินไป
      เพิ่มเติมคือ ผมก็ไม่รู้ว่าทำไมความเห็นต้นทางถึงได้รับปฏิกิริยาไม่ดี
    • ไม่เข้าใจเลยว่าทำไมความเห็นนี้ถึงได้รับปฏิกิริยาไม่ดี
      มีใครอธิบายได้ไหม?

  • ดูยอดเยี่ยมและทำออกมาดี
    แต่ก็น่าเสียดายที่จำเป็นต้องมีเครื่องมือแบบนี้ตั้งแต่แรก
    การโต้ตอบกับ systemd ส่วนใหญ่เป็นเรื่องเล็กน้อย: รีสตาร์ตบริการ, ดูไฟล์ล็อกเพื่อตรวจว่ามีอะไรผิดพลาด, ตรวจว่าบริการเริ่มตอนบูตหรือไม่
    ไม่เข้าใจว่าทำไม การใช้งานของ systemd ถึงยังขาดตกบกพร่องขนาดนี้ในงานที่พบบ่อยเหล่านี้
    ถึงอย่างนั้น TUI นี้ก็ดูเหมือนจะช่วยได้ ขอบคุณ
    แน่นอนว่า systemd ต่างจาก initd ตรงที่ deterministic กว่าและรวมฟีเจอร์สารพัดไว้หมด
    โชคดีที่ทุกวันนี้การโต้ตอบส่วนใหญ่แบบนี้สามารถทำให้หายไปได้ด้วย automation จึงไม่มีความเกลียดชังเดือดพล่านแบบเมื่อก่อนแล้ว
    ตอนนี้เหลือแค่เหมือนไฟคุกรุ่น

    • เข้าใจเหตุผลที่ไม่อยากใส่ TUI ที่ซับซ้อนและมีความเห็นเชิงอัตวิสัยเข้าไปใน systemd จนทำให้มัน “บวม”
      แต่ถ้ามี อินเทอร์เฟซที่ใกล้กับโปรเจกต์ต้นน้ำมากกว่านี้ ก็คงดีมากจริง ๆ
      อย่างไรก็ตาม ดูเหมือนว่าการทำให้ systemd เป็นมิตรกับมือใหม่และเข้าถึงง่ายไม่ได้สำคัญมากนักในด้านเงินทุนสนับสนุนของพวกเขา

  • เรื่องความปลอดภัยจัดการอย่างไร?
    ไม่ได้หมายถึงสิทธิ์ของระบบที่ Linux จัดการได้ดีอยู่แล้ว แต่อยากรู้ว่ามีอะไรรับประกันว่าเครื่องจะไม่ถูกผู้โจมตีภายนอกยึดไป ควบคุมระยะไกล

    • ผู้เขียนครับ
      ผมคิดว่านี่เป็นคำถามสำคัญที่ควรถามตัวเองเมื่อรันแอปพลิเคชันหรือสคริปต์ที่ทำบางอย่างด้วย sudo
      ดังนั้นผมจึงเขียนหัวข้อ Security ไว้ค่อนข้างละเอียดในหน้าเอกสารของ isd
      https://isd-project.github.io/isd/security/
      ถ้ามีอะไรตกหล่นไป บอกได้เลยครับ