Show HN: Systemd tương tác – cách tốt hơn để làm việc với các unit Systemd
(isd-project.github.io)isdlà một công cụ cung cấp cách tốt hơn để quản lý các unitsystemd, 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ýsudothô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 unitsystemdvà 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
isdcó 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
isdtrong 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
isdcho phép tìm kiếm các unitsystemd, 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
systemctltới unit đã chọn và tự động làm mới phần xuất trạng thái - Có thể mở
pagertrongisdđể xem toàn bộ phần xuất trạng thái - Có thể mở một
pagerriêng cho đầu raJournal, đồng thời thiết lập theme và key binding tùy chỉnh
Chế độ người dùng/hệ thống
isdchạy ở chế độuserhoặcsystem, 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
isdcung 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
isdcó 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
Ý 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
ExecStartlà 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ònExecStopđược chạy sau khi lệnh khởi động kết thúcNế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=yesExecStopthự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ầ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+RemainAfterExitlà tổ hợp bạn muốntype=forking, ExecStop hoạt động đúng như mong đợiRấ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ệtTô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 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 --runtimeViệ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
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.21thì phải làm như dưới đây, cònuvxthì hoàn toàn không chạy được$ uv tool install git+https://github.com/isd-project/isdCòn lệnh trong tài liệu
$ uv tool install https://github.com/isd-project/isd/isd@latestthì không chạyDù vậy
uvnhanh hơnpip(x)rất nhiều nên tôi đã chuyển sang dùng nóCảm ơn đã báo
Thật tuyệt khi nhờ
uvmà 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
uvbỏ qua phụ thuộc Python và cài công cụ nàyMáy của tôi là 3.10 nên
isdkhô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
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.servicevà kiểm tra status, timers, logs, v.v. từ xasystemctl --hostTiếc là chưa hỗ trợ
Về cơ bản nó giống một wrapper hào nhoáng bọc quanh
systemctlcục bộ hơnDù 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 execTô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
systemctlcủa hostNhư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/isdthất bại với lỗiFailed 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/isdBả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 -Hthì 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
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 overlayVì vậy các lệnh trong TUI truy cập
/nix/sẽ không đi tới thư mục/nixcủ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
EDITORbằng home-managerVì
systemctl“truy cập được” nênisdkhởi động bình thường, nhưng khi mởEDITORdưới/nixthì không tìm thấy, khiến người dùng rất bối rốiVì 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
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
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 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
sudoVì 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