Show HN: İnteraktif Systemd – Systemd üniteleriyle çalışmanın geliştirilmiş yolu

 (isd-project.github.io)
2 puan yazan GN⁺ 2025-01-19 | 1 yorum | WhatsApp'ta paylaş
  • isd, systemd ünitelerini yönetmek için daha iyi bir yöntem sunan bir araçtır; terminal kullanıcı arayüzü (TUI) üzerinden üniteleri aramayı, önizlemeyi otomatik yenilemeyi, akıllı sudo kullanımını ve özelleştirilebilir bir arayüzü sağlar.

Kısa motivasyon

  • isd, systemd üniteleriyle etkileşim için gereken karmaşık süreci basitleştirerek kullanıcıya faydalı bilgiler sunar.
  • systemctl komutunu tekrar tekrar yazma zahmetini azaltır ve çıktı sonuçlarını otomatik olarak yeniler.

Kurulum

  • isd, AppImage, nix ve uv üzerinden kurulabilir.
  • AppImage, tüm Linux dağıtımlarında çalışabilen tek bir yürütülebilir dosyadır; bu sayede izinlerin kısıtlı olduğu uzak sunucularda da kullanılabilir.
  • isd'yi nix ortamında kurmak için nix paketi kullanılabilir.
  • uv bir Python paket yöneticisidir; isd, uv aracılığıyla kurulup yönetilebilir.

isd kullanımı

  • isd, systemd ünitelerini arar, durumlarını kontrol eder ve birden fazla ünite için ayrıntılı bilgileri önizleme olarak sunar.
  • Seçilen üniteye systemctl komutları gönderir ve durum çıktısını otomatik olarak yeniler.
  • isd içinde pager açarak tam durum çıktısı görüntülenebilir.
  • Journal çıktısı için ayrı bir pager açılabilir; ayrıca özel tema ve tuş atamaları yapılandırılabilir.

Kullanıcı/sistem modu

  • isd, user veya system modunda çalışır ve görüntülenen ünite türleri moda göre değişir.

Bulanık arama

  • Bulanık arama çubuğu üzerinden girilen içerikle eşleşen tüm üniteler ve ünite dosyaları yüklenir, mevcut durumlarına göre vurgulanır.

Birden fazla ünite seçimi

  • Arama sonucu bileşeninde birden fazla ünite seçilebilir ve seçilen ünitelerin önizlemesi sunulur.

Komut paleti

  • Komut paleti açılarak kullanılabilir tüm komutlar ve tuş atamaları görülebilir.

Komutlar

  • Örneğin, Ctrl+O tuşlarına basarak seçili ünite durdurulabilir.

Pager desteği

  • isd çalışırken pager açılarak tam önizleme çıktısı görüntülenebilir.

Özelleştirme

  • isd, kullanıcıların en yüksek verimliliğe ulaşabilmesi için çeşitli temalar ve tuş atamalarıyla özelleştirme ve yapılandırma imkânı sunar.

Özet

  • isd'nin faydalı olup olmadığını anlamak için bizzat denenmesi önerilir.

Sonraki adımlar

  • Özelleştirme ve güvenlik bölümlerine göz atın

İlgili okumalar

1 yorum

 
GN⁺ 2025-01-19
Hacker News yorumları

  • Güzel görünüyor
    systemd servis betiklerinde ExecStop’un ele alınma biçimi gerçekten kafa karıştırıcıydı
    ExecStart, sistem açılırken ya da kullanıcı servisi başlattığında çalıştırılacak komut; ama ExecStop, başlatma komutu bittikten sonra çalıştırılıyor
    Sistem kapanırken ya da kullanıcı servisi durdurduğunda stop komutunun çalışmasını istiyorsanız RemainAfterExit=yes ayarlamanız gerekiyor
    ExecStop aslında “servis sonlandırma” olayından çok “temizlik zamanı” olayına daha yakın

    • Bunu “başlatırken” ve “durdururken” diye düşünmek yeterli
      systemd’nin daemon’lara göre tasarlandığını unutmamak gerekiyor
      Servisiniz yalnızca bir noktada sona eren tek bir komut çalıştırıyorsa, systemd’ye bunu bir daemon’dan farklı ele almasını açıkça belirtmeniz gerekir
      Başkalarının da söylediği gibi, muhtemelen istediğiniz kombinasyon oneshot + RemainAfterExit
    • type=forking altında ExecStop beklendiği gibi çalışıyor

  • Gerçekten hoşuma gitti
    Kendimi hasta edene kadar saf komut satırı kullanıyordum; son zamanlarda lazygit/lazydocker gibi araçlarla opak sistem/ağaç durumlarına bakmaya başladım ve üretkenliğim ciddi biçimde arttı
    Kullanıcı ve sistem düzeyinde birkaç servis yönetiyorum ama hata ayıklaması sıkıcı
    İlk cümlede yaygın komutların ve bunların zahmetinin sıralandığı kısım tam bana hitap etti
    NixOS kullandığım için değişmez unit dosyalarını doğrudan düzenleme yöntemi işe yaramaz, ama servisleri keşfetme, görünürlük ve yönetim açısından çok yardımcı olacak gibi

    • Ben de NixOS kullanıcısıyım ve bu projeyi tam da bu yüzden yaptım
      Belgelere bir “rehber” eklemeyi planlıyorum; kısaca, NixOS’ta unit hata ayıklarken systemctl edit --runtime komutuna bakmak iyi olur
      Hata ayıklamayı çok daha kolaylaştırıyor

  • Çok iyi görünüyor
    Benzer bir projeyi sürdürüyorum ve systemd/dbus API ile uğraşmak epey sancılıydı
    Bunu deneyip öğrenebileceğim bir şeyler var mı görmek istiyorum
    https://github.com/rgwood/systemctl-tui

    • Harika
      Bunu çok kullanacak gibiyim
      Eksik olan tek şey bir deb paketi

  • Sonunda systemd-client çıkmış, sevindirici
    Bir sonraki adımın macOS, FreeBSD, Windows gibi Linux dışı TUI’lar olmasını isterim
    macOS’ta LaunchControl.app kullanıyorum ama TUI değil
    Bir not: uv 0.5.21 ile aşağıdaki gibi yapmam gerekti; uvx ise hiç çalışmadı
    $ uv tool install git+https://github.com/isd-project/isd
    Buna karşılık belgelerdeki $ uv tool install https://github.com/isd-project/isd/isd@latest çalışmadı
    Yine de uv, pip(x)’ten çok daha hızlı olduğu için ona geçtim

    • Bu bir hataydı ve artık düzeltildi
      Bildirdiğin için teşekkürler

  • uv sayesinde böyle araçları kurmanın bu kadar kolaylaşması harika
    Kurulum adımlarında eksik olan nokta, uv’nin Python bağımlılığını yok sayıp bu aracı kurması
    Benim makinem 3.10’du, bu yüzden isd çalışmadı; -p 3.13 seçeneğiyle çözdüm
    Belgelerde bahsetmeye değer

    • Bildirdiğin için teşekkürler
      O bayrağı belgelere ekledim

  • “Yazarken sinir olduysanız” demiş ya, tam benlik
    systemd’yi sevmeme rağmen böyle
    Henüz kurmadım ama uzak host’a bağlanabiliyor mu merak ediyorum
    systemctl --host status foo.service komutunu sık kullanıyorum; status, timers, logs vb. bilgileri uzaktan kontrol ediyorum

    • systemctl --host’u ilk kez duyuyorum
      Ne yazık ki desteklenmiyor
      Kabaca yerel systemctl’i saran süslü bir wrapper’a daha yakın
      Yine de AppImage olduğu için uzak sunucuda çalıştırmak hopefully kolay olabilir
      Her hâlükârda bir issue açarsan bakarım

  • Uzak sunuculara ya da Docker imajlarına böyle bir şeyi kuramazsınız
    Komut çalıştırma ve bilgi toplama için birden fazla backend gerekiyor: yerel, SSH, Docker
    Yerelde kurulduktan sonra SSH ile uzak makinede komut çalıştırabilmeli, docker exec ile de çalıştırabilmeli

  • “Nix kuruluysa bu AppImage çalışmaz” ifadesinin gerçekten doğru olup olmadığını merak ediyorum.
    NixOS’ta çalışmamasının nedenini anlıyorum. Ana makinenin systemctl komutunu çalıştıramıyor gibi görünüyordu.
    Ama yalnızca başka bir işletim sisteminde Nix kurulu diye çalışmaması için bir neden yok gibi.
    İlginç şekilde Nix v2.24.11’de verilen Nix komutu da çalışmadı.
    $ nix run https://github.com/isd-project/isd, Failed to open archive (Unrecognized archive format) hatasıyla başarısız oluyor.
    Git URL biçimine çevrilirse çalışabilir, ama Nix’te daha verimli yerleşik bir GitHub fetcher olduğundan doğru komut aslında nix run github:isd-project/isd gibi görünüyor.
    Projenin kendisi harika.
    Aslında systemd’nin DBus API’si ve Qt ile benzer bir şey yapmak istiyordum; biraz kod da yazmıştım.
    DBus API’nin gereken işlevlerin neredeyse tamamını sağlama ihtimali yüksek. Elbette kendi SSH tünellemesini uygulamaktansa systemd -H çağırmak çok daha kolay.
    systemd ve modern Linux’ta sistem yönetimini, özellikle de geleneksel olarak içi pek görünmeyen masaüstü yönetimini kolaylaştıracak veri ve arayüzler fazlasıyla var; buna rağmen bunların iyi görünür olmaması sinir bozucu.
    Eskiden bir xdg otomatik başlatma uygulaması başarısız olduğunda ne olduğunu anlamak zordu; ama artık bazı masaüstlerinde systemd xdg otomatik başlatma uygulamalarını çalıştırdığı için, başarısız otomatik başlatma öğelerini ve bir log görüntüleyiciyi gösteren bir GUI yapmak kolay.
    Yine de bakımı yapılan ve özellikleri nispeten tamamlanmış bir araç yok gibi; bu oldukça can sıkıcı.

    • Doğru, karmaşıklaştığı için önerirken ayrıntıları açıklamak istemedim.
      Özetle AppImage nix ile oluşturuluyor ve AppImage, AppImage içindeki /nix/ dizinini “mount” ediyor. Overlay değil.
      Bu yüzden TUI içinde /nix/’e erişen çağrılar sistemin /nix dizinine gitmiyor ve türlü tuhaf sorunlar ortaya çıkıyor.
      Örneğin Ubuntu’da home-manager ile EDITOR kurabilirsiniz.
      systemctl “erişilebilir” olduğundan isd normal başlıyor; ancak /nix altındaki EDITOR açılmaya çalışıldığında bulunamıyor, bu da kullanıcı açısından çok kafa karıştırıcı.
      Bu yüzden zaten Nix kullanıyorsanız Nix kurulum yöntemini kullanın demek daha kolay.
      Hatalı dokümantasyonu şimdi düzelttim.
      O hayal kırıklığını da paylaşıyorum.
      Şahsen böyle bir araç yapmak gerçekten eğlenceli olurdu, ama kolay bir iş değil; ayrıca bu işi kimin finanse edeceği de ayrı mesele.
      Bu TUI’nin kapsamı yönetilebilir olmasına rağmen epey iş çıkardı.
      Bu yüzden “daha üst seviye arayüzlere” çok fazla yatırım yapacağımı sanmıyorum.
      Bu arada, asıl yorumun neden kötü tepki aldığını bilmiyorum.
    • Bu yorumun neden kötü tepki aldığını hiç anlamıyorum.
      Biri açıklayabilir mi?

  • Harika görünüyor ve iyi yapılmış.
    Yine de böyle bir araca ihtiyaç duyulması başlı başına üzücü.
    systemd ile etkileşimlerin çoğu basit şeyler: servisi yeniden başlatmak, log dosyalarına bakıp neyin yanlış gittiğini anlamak, servisin açılışta başlayıp başlamadığını kontrol etmek.
    Bu kadar yaygın işlerde systemd’nin kullanılabilirliğinin bu kadar yetersiz olmasını anlayamıyorum.
    Yine de bu TUI yardımcı oluyor gibi, teşekkürler.
    Elbette systemd, initd’den farklı olarak daha deterministik ve her türlü özelliği içinde barındırıyor.
    Neyse ki bugünlerde bu etkileşimlerin çoğunu otomatikleştirip ortadan kaldırmak mümkün; eski günlerdeki yakıcı nefret artık yok.
    Şimdiyse daha çok köz gibi.

    • systemd’ye karmaşık ve öznel bir TUI ekleyip onu “şişirmek” istememelerini anlıyorum.
      Yine de üst projeye daha yakın bir arayüz olsaydı gerçekten iyi olurdu.
      Ancak systemd’yi yeni başlayanlar için dostça ve erişilebilir kılmak, finansmanlarında pek önemli değil gibi görünüyor.

  • Güvenlik nasıl ele alınıyor?
    Linux’un iyi yönettiği sistem izinlerinden bahsetmiyorum; dış bir saldırgan tarafından ele geçirilip uzaktan kontrol edilmeyeceğine dair güvenceyi merak ediyorum.

    • Yazarıyım.
      sudo ile bir şeyler yapan bir uygulama ya da script çalıştırırken insanın kendine sorması gereken önemli bir soru olduğunu düşünüyorum.
      Bu yüzden isd dokümantasyon sayfasına oldukça ayrıntılı bir Security bölümü yazdım.
      https://isd-project.github.io/isd/security/
      Eksik bir şey varsa haber verirseniz sevinirim.