BSD Kullanıcısının Alpine Linux Deneyimi

 (rubenerd.com)
1 puan yazan GN⁺ 2024-04-28 | 1 yorum | WhatsApp'ta paylaş
  • BSD masaüstü, chroot ve jail'i sık kullanan bir kullanıcı, Alpine Linux'u denerken güvenlik, sadelik ve kaynak verimliliği odaklı tasarımının BSD kullanıcılarına tanıdık geldiğini düşünüyor
  • Küçük boyutu ve sınırlı bağımlılıkları sayesinde Alpine, yalnızca container base image olarak değil; gömülü sistemler, yönlendiriciler, mobil cihazlar, sunucular ve masaüstlerinde de geniş kullanım alanı buluyor
  • Kurulum, canlı ortamda setup-alpine komutunu çalıştırıp keymap, ağ, saat dilimi, SSH ve NTP gibi temel ayarları sırayla yapılandırma şeklinde ilerliyor
  • İlk açılıştan sonra OpenRC, musl ve busybox birleşimi öne çıkıyor; /etc/rc.conf ve crond(8) gibi bileşenler BSD tarzı rc deneyimiyle örtüşüyor
  • apk paket yönetimi, depo yapılandırması ve ZFS kurulum olasılığı incelendikten sonra, test ve sunucu kullanımı için ana Linux dağıtımı adayı olarak ciddi biçimde değerlendirilecek kadar iyi bir izlenim bırakıyor

BSD kullanıcılarına tanıdık gelen Alpine karakteri

  • Alpine Linux; güvenlik, sadelik ve kaynak verimliliğini önemseyen ileri düzey kullanıcılar için bağımsız, ticari olmayan, genel amaçlı bir Linux dağıtımı
  • Kullanıcı alanı ikilileri, PIE (Position Independent Executables) ve stack smashing protection ile derleniyor; böylece belirli zero-day durumları ve güvenlik açığı istismarlarını azaltmaya odaklanıyor
  • Natanael Copa'nın 2005'te projenin kökenlerinden söz etmiş olması, Alpine'ın beklenenden daha eski bir proje olduğunu gösteriyor
  • BSD ailesinde olduğu gibi, gömülü sistemler, yönlendiriciler ve mobil cihazların yanı sıra genel amaçlı sunucu ve masaüstlerinde de kullanılıyor
  • Küçük boyutu ve sınırlı bağımlılıkları nedeniyle Linux container'ları için base image olarak yaygın biçimde kullanılıyor; ayrıca chroot(8) içinde kolayca çalıştırmak için alpine-chroot-install gibi araçlar da bulunuyor
    • NetBSD chroot(8) ve FreeBSD jail'i test ve dağıtım için sık kullanan kullanıcılar açısından özellikle ilgi çekici bir nokta

Kurulum deneyimi

  • Alpine; ARM, PPC64, x86 ve x86_64 dahil çeşitli derlemeler sunuyor
  • Xen ISO imajı bir VM'de önyüklendi, ancak Dom0'ı DomU sanmak hatalı bir seçimdi
    • Dom0, Xen hypervisor ortamını ifade ediyor; misafir sistem değil
    • Yine de standart ISO gibi açılıp kurulumu sürdürebildi
  • Kurulum, canlı ortamda root ve boş parola ile oturum açtıktan sonra setup-alpine komutunu çalıştırma şeklinde yapılıyor
  • Kurulum sırasında keymap, ağ, saat dilimi ve root kimlik doğrulaması gibi temel başlıklar sırayla ayarlanıyor
  • Başlangıç aşamasında SSH anahtarı enjekte edilebiliyor
    • Bu, daha sonra orkestrasyon araçlarıyla VM veya sunucu kümeleri dağıtırken faydalı oluyor
    • OOB konsol sunmayan barındırma ortamlarında da işe yarıyor
  • SSH sunucusu ve NTP istemcisi seçilebiliyor; OpenSSH ve openntpd tercih edilebiliyor
  • Kurulum süreci, Xen üzerinde çalıştığını doğru biçimde algılıyor
  • LVM yapılandırması da mümkün, ancak bu denemede Alpine'ın sys bölümü dediği standart düzen seçilmiş
    • Bu düzen ext4 kullanıyor

İlk açılıştan sonra görülen sistem yapısı

  • İlk açılıştan sonra dmesg(1) çıktısında sistemin OpenRC kullandığı doğrulanabiliyor
  • OpenRC, taşınabilir, küçük, hızlı, verimli, şeffaf ve güvenli bir init sistemi
  • BSD tarzı rc betikleri yazmaya alışkın kullanıcılar için OpenRC son derece tanıdık geliyor
    • /etc/rc.conf ve crond(8) gibi unsurlar BSD kullanıcı deneyimiyle kesişiyor
  • Devuan, Gentoo ve Alpine gibi OpenRC kullanan Linux dağıtımlarının bulunması, Linux'u yeniden eğlenceli hissettiriyor
  • Alpine, OpenRC ile birlikte musl içeriyor ve busybox kullanıyor
    • musl ve busybox, GCC ve GNU coreutils'e göre daha sınırlı olsa da taban sistemin küçük kalmasına ve saldırı yüzeyinin azalmasına katkı sağlıyor
  • llvm da kullanılabiliyor
  • MirBSD Korn shell de paket olarak sunuluyor ve tercih edilen etkileşimli kabuklardan biri olarak anılıyor

Paket yönetimi ve depolar

  • Alpine'ın varsayılan paket yöneticisi apk
  • Linux'ta yaygın olduğu gibi apk, taban sistem ile paketleri ayırmadan birlikte güncelliyor
  • BSD'deki gibi yetkisiz bir kopya olarak çalıştırılıp çalıştırılamadığı henüz kontrol edilmemiş
  • pkgsrc da kullanılabildiği için alternatif mevcut
  • Depo yapılandırması /etc/apk/repositories içinde yer alıyor
    • Kurulum aracının verdiği ikinci URL'deki yorum kaldırılırsa community deposu etkinleştirilebiliyor
    • Alpine'da bir testing deposu da bulunuyor ve özel depolar eklemek de mümkün
  • Kullanımı basit olsa da eski alışkanlıklar nedeniyle bazen apk add yerine yanlışlıkla apt install yazılabiliyor
  • Resmî paket web arayüzü pkgs.alpinelinux.org adresinde
  • Alpine depoları pkgs.org üzerinden de incelenebiliyor

ZFS ve sunucu adayı olarak değerlendirme

  • Birkaç paket kurulduktan sonra, yalnızca konsol kullanan bir dizüstünde kullanılan “olmazsa olmaz araçlar” düzenine ulaşılabildi
  • En şaşırtıcı paketlerden biri ZFS oldu
    • Kurulum ve kernel modülünü yükleme iki komutla yapılabildi
# apk add zfs zfs-lts


# modprobe zfs
  • Root filesystem'i ZFS olarak yapılandırmak daha karmaşık olabilir
  • Yükseltme sonrasında ZFS yapılandırmasının nasıl davranacağı henüz doğrulanmış değil
  • Şimdiye kadarki deneyim bile, test ve sunucu kullanımı için ana Linux dağıtımı olarak geçişi ciddi biçimde düşünmeye yetecek kadar olumlu bir izlenim bırakmış durumda
  • htop(1) ve lsof(1) içinde tanınabilen az sayıdaki süreç, OpenRC kullanımı, sade görünen paket yönetimi ve kolay yapılandırma öne çıkan artılar arasında
  • Modern ve işlevsel bir “Occam’s Linux” varsa, Alpine'ın buna oldukça yakın olduğu düşünülüyor
  • busybox'tan daha fazla özelliğe ihtiyaç duyulursa uutils denenebilir, ancak sunucu tarafında buna ihtiyaç az görünüyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-28
Hacker News yorumları

  • Güvenlik açısından bakarsak, günümüzde Linux ikilileri çoğunlukla PIE olarak derleniyor
    Ubuntu’daki rastgele bir ikili üzerinde checksec çalıştırırsanız bu özellik görünüyor; checkseci pip install pwntools ile kurabilirsiniz
    Öte yandan GLIBC, bildiğim kadarıyla en güçlendirilmiş heap uygulamasına sahip; double free ve diğer heap saldırılarına karşı daha fazla hafifletme önlemi de var
    Bu yüzden bu açıdan Alpine’in musl kullandığı için daha az güvenli olduğu söylenebilir; ancak küçük ve anlaşılması kolay bir sistem olması güvenlikte gerçekten bir avantaj

    • “Küçük ve anlaşılması kolay bir sistem”in neden glibc lehine bir gerekçe olduğunu pek anlamadım. Tam tersi değil mi?
    • Alpine düğümlerimizde her zaman her şey üzerinde checksec çalıştırıyorum; süreçlerin hepsi böyle görünüyor. Tam çıktı uzun olduğu için atlıyorum ama Alpine’in derlediği şeylerde bu bayrakların eksik olduğunu hiç görmedim
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • OpenBSD libcye de bakmaya değer
    • Linux güvenliği açısından, biri sistemde azıcık bile kod çalıştırabiliyorsa işin zaten bittiğini düşünüyorum. Linux delik deşik; Windows kadar kötü amaçlı yazılımla dolu olmamasının nedeni, masaüstünde Linux kullananların az olması ve kötü amaçlı yazılım yazarlarının onu çok hedeflememesi
      Açıkçası modern Windows ve macOS’un ikisinin de daha iyi bir güvenlik mimarisine sahip olduğunu düşünüyorum

  • Ben de BSD tarafındayım ve tesadüfen bu hafta ilk kez bhyve üzerinde bir VM’de Alpine çalıştırdım
    Kilit nokta BusyBox. /bin ve /sbin yardımcı araçlarının her birinin bağımsız ikili olması gerekmiyorsa kullanıcı alanı çok küçük oluyor ve sistem de hızlı açılıyor. Tmux, zsh gibi birkaç şey kurunca çoğu Unix kullanımı için yeterliydi
    Son ortama ulaşmak için epey apk kurulumu yapmam gerekti ama genel olarak uzun zamandır yaşadığım en iyi Linux deneyimiydi. ZFS’in varsayılan olarak gelmesi ve bhyve’in ZFS tabanlı çalışmasına yönelik virtio bağlantısının daha açık olması güzel olurdu

    • 20 yılı aşkın süredir FreeBSD kullanıp dağıtıyorum; GNU/Linux kutularına bağlanmak açıkçası içime sinmiyor. O kadar çok varyasyon ve tutarsızlık var ki sistem dağınık gibi hissettiriyor. Windows sunucusuna bağlanmak bile daha “mantıklı” geliyor
      Yine de aklı başında bir Linux dağıtımı olabileceğini duymak sevindirici; bir Linux kutusuna ihtiyaç duyarsam deneyeceğim. Gerçi bu oldukça nadir oluyor
    • ZFS’in ne ölçüde “varsayılan yerleşik” olmasını istediğinizi merak ediyorum. Alpine, ikili ZFS çekirdek modülü sağlayan az sayıdaki dağıtımdan biri; tek bir apk komutuyla neredeyse kuruluyor
      Alpine wiki’de kök dosya sistemini ZFS olarak kurmak için de oldukça iyi bir belge var: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS, Alpine’de çok iyi çalışıyor. Alpine + ZFS birkaç yıldır varsayılan sunucu kurulumum

  • BSD kullanıcısıysanız Void Linux da hoşunuza gidebilir. NetBSD geliştiricisi xtraeme tarafından oluşturulmuş bir dağıtım; glibc ve musl sürümleri var ve init sistemi olarak runit kullanıyor
    xbps-src ile paketleri kaynaktan da derleyebilirsiniz
    https://voidlinux.org/

    • Arch kullanıyordum; Arch’a benzer hissettiren SystemD olmayan bir alternatif ararken sonunda Void’de karar kıldım. Alpine yerine Void’e geçmemin nedeni, glibc desteği sayesinde NVidia sürücülerini kullanabilmemdi. Elbette “NVidia yuhalama” kısmını biliyorum
    • Void’i çok beğeniyorum. Geniş paket seçenekleri ve systemd’nin kolaylıkları nedeniyle ana sistemim Arch, ama akrabalarıma ve kendi üç cihazıma Void kurdum; harikaydı
      Yalnız şunu belirtmek gerekir: yalnızca çok az değiştirilmiş xfce kurulumları kullandım. Karmaşık çok kullanıcılı yapılandırmalar, runit’in systemd’ye göre varsayılan olarak daha az işlev içermesi nedeniyle biraz daha zahmetli olabilir
    • Birkaç yıl önce voidlinux+musl üzerinde Rust kullanırken sorunlar vardı. Neyse ki Void’i glibc ile yeniden kurmak kolay
    • Chimera da iyi olabilir. Temel araç kullanıcı alanının çoğu FreeBSD kökenli olduğu için BSD kullanıcılarına oldukça tanıdık gelebilir
    • CRUX da var. Archlinux’un atası sayılabilecek bir dağıtım

  • BSD’lerin övündüğü man sayfalarının Alpine’de varsayılan olarak gelmediği konusunun açılacağını sanmıştım. Seyahat dizüstü bilgisayarımda Alpine kullanmamamın nedenlerinden biri buydu; şu anda OpenBSD kullanıyorum
    Alpine’de paket alırken belgelerin her zaman kurulmasını sağlayan bir ayar seçeneğini mi kaçırdım? Yoksa her seferinde -doc paketlerini elle kurmaktan başka yol yok mu?

    • Belgeleri her zaman istiyorsanız docs meta paketini kurmanız yeterli. Daha sonra kurduğunuz şeylere uygun *-doc paketlerini çeker
    • Dizüstü bilgisayarda OpenBSD kullanınca donanım desteği nasıl?

  • İnsanların OpenRC gibi şeyleri neden çekici bulduğunu açıkçası hiç anlamıyorum. İzlemeye dayalı herhangi bir yaklaşımın, PID’leri sağa sola saçıp bunları bir PID dosyasına kaydettikten sonra 3 hafta sonra bile o değerin hâlâ başlatılan daemon’ı işaret etmesini ummaktan daha iyi olduğunu düşünüyorum
    Üstelik bazı durumlarda belirli bir süreç adını pgrep ederek servis yönetimi işlerini hallediyorlar. Her şeyi varsayılan olarak otomatik yeniden başlatmamak gerektiği fikrine bir ölçüde katılıyorum, ama bu kesimin öne sürebileceği avantaj fiilen bundan ibaret
    Ayrıca sonuçta bunlar syslog’a büyük ölçüde bağımlı; bu da 80’ler teknolojisinin ta kendisi. multilog veya svlogd gibi araçlar, birden fazla aracın olay sırasını tek bakışta gösteren merkezi bir görünümü daha kolay sunacak şekilde geliştirilebilir; ama günlükleri belirsiz kategorilerde toplamak ve herkesin herhangi bir adla herhangi bir yere log bırakabilmesini sağlamak tuhaf geliyor

    • Bu arada Alpine birkaç yıldır OpenRC alternatifi arıyor ama uygun bir seçenek bulamadı. Başlatma sisteminden bağımsız bir dağıtım olma girişimleri de var
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • Yine de başlıca alternatif systemd; o da güvenli olmayan bir biçimde tasarlanmış olduğundan yeni ve ilginç CVE’lerin ortaya çıkmasına alan bırakıyor
      PID1’in içinde çok fazla iş var ve bellek güvenli olmayan bir dille yazılmış. Bunun minimal bir PID1 ve birkaç setuid programa bölünememesi için teknik bir neden göremiyorum
      Aklıma yalnızca Docker konteyneri içinde systemd çalıştırabilmek geliyor; ama Red Hat/IBM systemd-nspawn gibi kendi konteynerleştirme araçlarını kullanmanızı tercih ettiğinden bunu çok istemez gibi. Mevcut yapısıyla güvenlik açısından asla makul hâle gelmesinin zor olduğunu düşünüyorum

  • Alpine’ın ilginç bir avantajı var. Nix kullanıcıları bildirimsel paket yönetimiyle övündüğünde /etc/apk/world dosyasını doğrudan düzenleyip apk fix çalıştırarak bunun Nix olmadan nasıl yapılabildiğini gösterebilirsiniz

    • Genelde Gentoo yaklaşımı daha iyi. Elle kurulan paketler /var/lib/portage/world, seçilen kümeler /var/lib/portage/world_sets, küme tanımları da /etc/portage/sets/ altında tutulabilir
      Böylece paketleri kategorilere ayırabilir, yalnızca gereken sistemlere bazılarını kurabilir ve dosyalara istediğiniz gibi yorum ekleyebilirsiniz. apk fix karşılığı emerge -uDU @world && emerge -c; biraz daha hantal gerçi
      Alpine’da da apk add -t setname pkg1 pkg2 pkg3 ile küme benzeri bir şey oluşturabilirsiniz; bu, seçilen paketlere bağımlı sahte bir paket oluşturur. Ben genelde Gentoo hissini taklit etmek için /etc/apk/sets/ altında shell betikleri oluşturuyorum ama her zaman aynı olmuyor
    • Nix’in sistem flake’imi değerlendirmesi için geçen sürede Alpine’ı sıfırdan yeniden kurabilirim
    • Havalı ama Nix/OS, bildirimsel paket kurulumundan çok daha fazlasını yapıyor

  • Eskiden Docker’da Alpine çalıştırırken performansla ilgili yazılar vardı ve Debian/Ubuntu kullanılması önerilirdi diye hatırlıyorum
    Yavaş Alpine ile ilgili yazı:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Alpine’a olumlu bakan yazı:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    Bu konunun hâlâ geçerli olup olmadığını merak ediyorum

    • Somut şikâyetlerin önemli bir kısmı en azından çözülmüş durumda. İlk bağlantının en altında da kabul edildiği gibi artık Alpine uyumlu Python wheel’leri var ve DNS sorunu da epey önce düzeltildi
      Yine de performans açısından benchmark çalıştırıp gerçek sayıları görmek ilginç olurdu

  • musl hâlâ pthread_attr_setaffinity_np desteklemiyor değil mi? O zaman bazı yazılımlar çalıştırılamaz; bunun en büyük örneği PyTorch

    • Performansa duyarlı iş yükleri sırf bu performans nedeniyle glibc’ye bağımlıysa, o uygulamayı konteyner içinde “öylece” çalıştırmak yeterli olabilir
      Birçok durumda sadelik veya güvenlik performanstan daha önemli bir kaygı

  • BSD ile Linux arasında bulduğum uygun orta nokta Slackware. Gururla Unix vari, karmaşık değil ve Slackbuilds üzerinden zengin bir kendi ports ağacı da var

    • Slackware masaüstü dağıtımlarıyla rekabet etmeye çalıştı ama buna gerçekten odaklanmayınca yönünü kaybetti
      Eskiden araya girmeyen minimal bir dağıtım olduğu için severdim ve biraz daha teknik kişileri hedeflediğini düşünürdüm
      Ama bir sorunu kurcalarken tam kurulum yapmadığınız için topluluk bazen düşmanca davranıyordu. Gerekçe, tam kurulumun önerilen yöntem olmasıydı; böyle yapmayınca samba olmadığı için mplayer’ın çalışmaması gibi aptalca bağımlılık sorunları da çıkıyordu
      Alpine’ın her açıdan Slackware’e göre bir iyileştirme olduğunu düşünüyorum
    • Slackware kullananlara saygı duyarım ama bağımlılık yönetiminin olmaması zahmetli görünüyor

  • Alpine Linux aslında GNU/Linux değilmiş. Bilmiyordum
    O zaman BusyBox/Linux mu?

    • Sadece Alpine Linux demek yeterli. Bildiğim kadarıyla BusyBox’ın RMS’den ara sıra sızan kendini gösterme tavırlarıyla ilgisi yok, o yüzden sorun yok