2 điểm bởi GN⁺ 2025-01-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • isd là một công cụ cung cấp cách tốt hơn để quản lý các unit systemd, cho phép tìm kiếm unit qua giao diện người dùng terminal (TUI), tự động làm mới phần xem trước, xử lý sudo thông minh và cung cấp giao diện có thể tùy biến

Động lực ngắn gọn

  • isd đơn giản hóa quy trình phức tạp cần thiết để tương tác với các unit systemd và cung cấp thông tin hữu ích cho người dùng
  • Giảm sự phiền toái khi phải nhập lặp đi lặp lại các lệnh systemctl, đồng thời tự động làm mới kết quả đầu ra

Cài đặt

  • isd có thể được cài đặt thông qua AppImage, nix và uv
  • AppImage là một tệp thực thi đơn có thể chạy trên mọi bản phân phối Linux, nên cũng có thể dùng trên các máy chủ từ xa bị giới hạn quyền
  • Để cài đặt isd trong môi trường nix, có thể dùng gói nix để cài đặt
  • uv là trình quản lý gói Python, có thể dùng uv để cài đặt và quản lý isd

Cách dùng isd

  • isd cho phép tìm kiếm các unit systemd, kiểm tra trạng thái và cung cấp phần xem trước thông tin chi tiết của nhiều unit
  • Gửi các lệnh systemctl tới unit đã chọn và tự động làm mới phần xuất trạng thái
  • Có thể mở pager trong isd để xem toàn bộ phần xuất trạng thái
  • Có thể mở một pager riêng cho đầu ra Journal, đồng thời thiết lập theme và key binding tùy chỉnh

Chế độ người dùng/hệ thống

  • isd chạy ở chế độ user hoặc system, và loại unit được hiển thị sẽ khác nhau tùy theo từng chế độ

Tìm kiếm mờ

  • Qua thanh tìm kiếm mờ, có thể tải tất cả unit và tệp unit khớp với nội dung đã nhập, rồi làm nổi bật chúng theo trạng thái hiện tại

Chọn nhiều unit

  • Có thể chọn nhiều unit trong widget kết quả tìm kiếm, đồng thời xem trước các unit đã chọn

Bảng lệnh

  • Có thể mở bảng lệnh để xem tất cả lệnh khả dụng và các key binding

Lệnh

  • Ví dụ, có thể nhấn Ctrl+O để dừng unit đã chọn

Hỗ trợ pager

  • Trong khi chạy isd, có thể mở pager để xem toàn bộ đầu ra xem trước

Tùy biến

  • isd cung cấp khả năng tùy biến và cấu hình, với nhiều theme và key binding để giúp người dùng đạt năng suất tối ưu

Tóm tắt

  • Khuyến nghị tự dùng thử để xem isd có hữu ích với bạn hay không

Bước tiếp theo

  • Hãy xem phần tùy biến và bảo mật

1 bình luận

 
GN⁺ 2025-01-19
Ý kiến trên Hacker News
  • Trông hay đấy
    Cách xử lý ExecStop trong script dịch vụ systemd thật sự rất dễ gây nhầm lẫn
    ExecStart là lệnh được chạy khi hệ thống khởi động hoặc khi người dùng khởi động dịch vụ, còn ExecStop được chạy sau khi lệnh khởi động kết thúc
    Nếu muốn lệnh stop được chạy khi hệ thống tắt hoặc khi người dùng dừng dịch vụ, cần đặt RemainAfterExit=yes
    ExecStop thực ra gần với sự kiện “thời điểm dọn dẹp” hơn là sự kiện “để kết thúc dịch vụ”

    • Có thể nghĩ theo kiểu “khi bắt đầu” và “khi dừng”
      Cần nhớ rằng systemd được thiết kế xoay quanh daemon
      Nếu dịch vụ chỉ chạy một lệnh rồi sẽ kết thúc vào lúc nào đó, bạn phải nói rõ với systemd rằng hãy đối xử với nó khác daemon
      Như những người khác đã nói, có lẽ oneshot + RemainAfterExit là tổ hợp bạn muốn
    • Với type=forking, ExecStop hoạt động đúng như mong đợi
  • Rất thích
    Tôi đã chỉ dùng dòng lệnh thuần túy đến phát mệt, rồi gần đây bắt đầu dùng các công cụ như lazygit/lazydocker để nhìn vào trạng thái hệ thống/cây vốn khá mù mờ, và năng suất tăng lên rõ rệt
    Tôi quản lý nhiều dịch vụ ở cấp người dùng và hệ thống, nhưng việc debug thì chán ngắt
    Phần ở câu đầu liệt kê các lệnh phổ biến và sự bất tiện của chúng thật sự rất đúng với trải nghiệm của tôi
    Vì dùng NixOS nên cách chỉnh trực tiếp các file unit bất biến sẽ không dùng được, nhưng việc khám phá, tăng khả năng quan sát và quản lý dịch vụ có vẻ sẽ rất hữu ích

    • Tôi cũng là người dùng NixOS, và chính vì điểm đó mà tôi tạo dự án này
      Tôi dự định thêm phần “hướng dẫn” vào tài liệu; tóm lại, khi debug unit trên NixOS, nên thử xem systemctl edit --runtime
      Việc debug sẽ dễ hơn nhiều
  • Trông rất tuyệt
    Tôi đang bảo trì một dự án tương tự, và việc xử lý API systemd/dbus khá đau đầu
    Muốn dùng thử cái này để xem có học được gì không
    https://github.com/rgwood/systemctl-tui

    • Quá đỉnh
      Có lẽ tôi sẽ dùng nhiều
      Thứ còn thiếu chỉ là gói deb
  • Cuối cùng cũng có systemd-client rồi, vui thật
    Bước tiếp theo mong là TUI cho các hệ không phải Linux như macOS, FreeBSD, Windows
    Trên macOS tôi dùng LaunchControl.app, nhưng đó không phải TUI
    Có một điểm là với uv 0.5.21 thì phải làm như dưới đây, còn uvx thì hoàn toàn không chạy được
    $ uv tool install git+https://github.com/isd-project/isd
    Còn lệnh trong tài liệu $ uv tool install https://github.com/isd-project/isd/isd@latest thì không chạy
    Dù vậy uv nhanh hơn pip(x) rất nhiều nên tôi đã chuyển sang dùng nó

    • Đó là lỗi và giờ đã được sửa
      Cảm ơn đã báo
  • Thật tuyệt khi nhờ uv mà việc cài các công cụ kiểu này trở nên dễ đến vậy
    Điều còn thiếu trong quy trình cài đặt là việc uv bỏ qua phụ thuộc Python và cài công cụ này
    Máy của tôi là 3.10 nên isd không chạy, và tôi đã giải quyết bằng tùy chọn -p 3.13
    Đáng để nhắc trong tài liệu

    • Cảm ơn đã báo
      Tôi đã đưa cờ đó vào tài liệu
  • “Nếu bạn từng bực mình khi gõ” — đúng là nói về tôi rồi
    Dù tôi vẫn thích systemd
    Tôi chưa cài thử, nhưng tò mò không biết có thể kết nối tới host từ xa không
    Tôi thường dùng systemctl --host status foo.service và kiểm tra status, timers, logs, v.v. từ xa

    • Lần đầu tôi nghe đến systemctl --host
      Tiếc là chưa hỗ trợ
      Về cơ bản nó giống một wrapper hào nhoáng bọc quanh systemctl cục bộ hơn
      Dù vậy có AppImage nên hy vọng việc chạy trên server từ xa có thể khá dễ
      Dù sao nếu bạn mở issue thì tôi sẽ xem xét
  • Không thể cài thứ như thế này lên server từ xa hoặc image Docker
    Cần nhiều backend để chạy lệnh và thu thập thông tin: cục bộ, SSH, Docker
    Sau khi cài ở máy cục bộ, nó phải có thể chạy lệnh trên máy từ xa qua SSH và cũng có thể chạy qua docker exec

  • Tôi nghi ngờ liệu câu “Nếu đã cài Nix thì AppImage này sẽ không hoạt động” có thực sự đúng không
    Tôi hiểu vì sao nó không chạy trên NixOS. Có vẻ như nó không chạy được systemctl của host
    Nhưng nếu chỉ cài Nix trên một hệ điều hành khác thì có vẻ không có lý do gì để nó không chạy
    Thú vị là với Nix v2.24.11, lệnh Nix được cung cấp cũng không chạy được
    $ nix run https://github.com/isd-project/isd thất bại với lỗi Failed to open archive (Unrecognized archive format)
    Nếu đổi sang dạng Git URL thì có thể sẽ chạy, nhưng Nix có GitHub fetcher mặc định hiệu quả hơn, nên lệnh thực tế có vẻ phải là nix run github:isd-project/isd
    Bản thân dự án này rất hay
    Trước đây tôi từng muốn làm một thứ tương tự bằng DBus API của systemd và Qt, và cũng đã viết một ít mã
    DBus API nhiều khả năng cung cấp gần như mọi chức năng cần thiết. Tất nhiên gọi systemd -H thì dễ hơn nhiều so với tự triển khai SSH tunneling
    Điều gây khó chịu là systemd và Linux hiện đại có rất nhiều dữ liệu và interface có thể giúp việc quản trị hệ thống, đặc biệt là quản lý desktop vốn trước đây khó nhìn thấy bên trong, trở nên dễ dàng hơn, nhưng chúng lại không được phơi bày tốt
    Trước đây khi ứng dụng xdg autostart thất bại thì rất khó biết chuyện gì đã xảy ra, nhưng giờ ở một số desktop, systemd chạy các ứng dụng xdg autostart, nên khá dễ tạo GUI hiển thị các mục autostart bị lỗi và trình xem log
    Vậy mà có vẻ không có công cụ nào được bảo trì và tương đối hoàn chỉnh về tính năng, nên khá bực

    • Đúng vậy, chuyện này phức tạp nên tôi không muốn khuyến nghị rồi lại phải giải thích chi tiết
      Tóm lại là AppImage được tạo bằng nix, và AppImage “mount” thư mục /nix/ bên trong AppImage. Nó không phải overlay
      Vì vậy các lệnh trong TUI truy cập /nix/ sẽ không đi tới thư mục /nix của hệ thống, mà gây ra đủ loại vấn đề kỳ lạ
      Ví dụ trên Ubuntu, bạn có thể cài EDITOR bằng home-manager
      systemctl “truy cập được” nên isd khởi động bình thường, nhưng khi mở EDITOR dưới /nix thì không tìm thấy, khiến người dùng rất bối rối
      Vì vậy nếu bạn đã dùng Nix thì nói dùng cách cài đặt bằng Nix sẽ dễ hơn
      Tài liệu sai hiện đã được sửa
      Tôi cũng đồng cảm với sự bực bội đó
      Cá nhân tôi nghĩ làm một công cụ như vậy sẽ rất thú vị, nhưng đó không phải việc dễ, và ai sẽ tài trợ cho việc đó cũng là một vấn đề
      TUI này có phạm vi còn quản lý được mà cũng đã tốn khá nhiều công sức
      Vì vậy tôi không nghĩ mình sẽ đầu tư quá nhiều vào “interface cấp cao hơn”
      Ngoài ra, tôi không biết vì sao phản ứng với bình luận gốc lại tiêu cực
    • Tôi hoàn toàn không hiểu vì sao phản ứng với bình luận này lại tiêu cực
      Có ai giải thích được không?
  • Trông tuyệt vời và được làm rất tốt
    Chỉ tiếc là bản thân việc cần đến một công cụ như thế này đã là điều đáng tiếc
    Phần lớn tương tác với systemd đều rất đơn giản: khởi động lại service, xem log file để biết có gì sai, kiểm tra service có khởi động khi boot không
    Tôi không hiểu vì sao khả năng sử dụng của systemd lại thiếu sót đến vậy trong những tác vụ phổ biến này
    Dù sao TUI này có vẻ hữu ích, nên cảm ơn
    Tất nhiên systemd khác initd ở chỗ nó mang tính quyết định hơn và bao gồm đủ loại chức năng
    May là giờ có thể tự động hóa và làm biến mất phần lớn các tương tác kiểu này, nên tôi không còn sự căm ghét bùng cháy như trước nữa
    Giờ chỉ còn âm ỉ như than hồng thôi

    • Tôi hiểu lý do không muốn nhét một TUI phức tạp và mang tính chủ quan vào systemd để khiến nó “phình to”
      Dù vậy, sẽ thật tuyệt nếu có một interface gần với dự án upstream hơn
      Tuy nhiên có vẻ việc làm cho systemd thân thiện với người mới và dễ tiếp cận không phải là ưu tiên lớn trong nguồn tài trợ của họ
  • Phần bảo mật được xử lý thế nào?
    Tôi không nói về quyền hệ thống mà Linux xử lý tốt, mà muốn biết có gì bảo đảm rằng nó không bị kẻ tấn công bên ngoài chiếm đoạt để điều khiển từ xa không

    • Tôi là tác giả
      Tôi nghĩ đây là câu hỏi quan trọng cần tự hỏi khi chạy một ứng dụng hay script làm việc gì đó bằng sudo
      Vì vậy tôi đã viết một mục Security khá chi tiết trong trang tài liệu của isd
      https://isd-project.github.io/isd/security/
      Nếu còn thiếu gì thì mong bạn cho biết