Trải nghiệm thử Alpine Linux của một người dùng BSD

 (rubenerd.com)
1 điểm bởi GN⁺ 2024-04-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một người dùng thường xuyên dùng desktop BSD cùng chroot và jail đã thử Alpine Linux, và nhận thấy thiết kế tập trung vào bảo mật, sự đơn giản và hiệu quả tài nguyên của nó tạo cảm giác quen thuộc với người dùng BSD
  • Nhờ kích thước nhỏ và phụ thuộc hạn chế, Alpine được dùng rộng rãi không chỉ làm base image cho container mà còn trên hệ thống nhúng, router, thiết bị di động, máy chủ và desktop
  • Việc cài đặt diễn ra bằng cách chạy setup-alpine trong môi trường live, lần lượt cấu hình các thiết lập cơ bản như keymap, mạng, múi giờ, SSH và NTP
  • Sau lần khởi động đầu tiên, tổ hợp OpenRC, musl và busybox hiện rõ; các thành phần như /etc/rc.conf và crond(8) có nét tương đồng với trải nghiệm rc kiểu BSD
  • Sau khi kiểm tra trình quản lý gói apk, cấu hình kho lưu trữ và khả năng cài ZFS, Alpine để lại ấn tượng tốt đến mức được cân nhắc nghiêm túc như ứng viên bản phân phối Linux chính cho thử nghiệm và máy chủ

Tính chất Alpine quen thuộc với người dùng BSD

  • Alpine Linux là một bản phân phối Linux độc lập, phi thương mại, đa dụng dành cho power user, chú trọng bảo mật, sự đơn giản và hiệu quả tài nguyên
  • Các binary ở userland được biên dịch với PIE (Position Independent Executables) và stack smashing protection, tập trung vào việc giảm thiểu một số zero-day và khai thác lỗ hổng cụ thể
  • Alpine là một dự án lâu đời hơn nhiều so với tưởng tượng, khi Natanael Copa đã thảo luận về nguồn gốc dự án từ năm 2005
  • Giống các hệ BSD, Alpine được dùng trên hệ thống nhúng, router, thiết bị di động, cũng như máy chủ và desktop thông thường
  • Do kích thước nhỏ và phụ thuộc hạn chế, Alpine được dùng rộng rãi làm base image cho container Linux; cũng có các công cụ như alpine-chroot-install để chạy dễ dàng trong chroot(8)
    • Đây là điểm đặc biệt thú vị với những người dùng thường dùng NetBSD chroot(8) và FreeBSD jail cho thử nghiệm và triển khai

Trải nghiệm cài đặt

  • Alpine cung cấp nhiều bản build cho ARM, PPC64, x86, x86_64, v.v.
  • Tác giả đã boot image ISO Xen trong VM, nhưng đó là lựa chọn do đọc nhầm Dom0 thành DomU
    • Dom0 chỉ Xen hypervisor, không phải guest
    • Dù vậy, quá trình boot và cài đặt vẫn diễn ra như ISO tiêu chuẩn
  • Cài đặt được thực hiện bằng cách đăng nhập vào môi trường live bằng root với mật khẩu trống, rồi chạy setup-alpine
  • Trong quá trình cài đặt, các mục cơ bản như keymap, mạng, múi giờ và xác thực root được cấu hình lần lượt
  • Có thể chèn SSH key ở giai đoạn đầu
    • Điều này hữu ích khi về sau triển khai một nhóm VM hoặc máy chủ bằng công cụ orchestration
    • Cũng hữu ích trong môi trường hosting không cung cấp console OOB
  • Có thể chọn SSH server và NTP client, nên tác giả đã chọn OpenSSH và openntpd
  • Quá trình cài đặt nhận diện chính xác rằng hệ thống đang chạy trên Xen
  • Cũng có thể cấu hình LVM, nhưng lần này tác giả chọn cấu hình tiêu chuẩn mà Alpine gọi là phân vùng sys
    • Cấu hình này dùng ext4

Cấu hình hệ thống sau lần khởi động đầu tiên

  • Sau lần boot đầu tiên, có thể thấy trong dmesg(1) rằng hệ thống đang dùng OpenRC
  • OpenRC là một hệ thống init có tính di động, kích thước nhỏ, nhanh, hiệu quả, minh bạch và bảo mật
  • Với người dùng quen viết script rc kiểu BSD, OpenRC tạo cảm giác rất quen thuộc
    • Các thành phần như /etc/rc.conf và crond(8) tương đồng với trải nghiệm của người dùng BSD
  • Việc có các bản phân phối Linux dùng OpenRC như Devuan, Gentoo và Alpine khiến Linux trở nên thú vị trở lại
  • Cùng với OpenRC, Alpine bao gồm musl và sử dụng busybox
    • musl và busybox hạn chế hơn GCC và GNU coreutils, nhưng góp phần làm kích thước nhỏ cho hệ thống nền tảng và giảm bề mặt tấn công
  • Cũng có thể dùng llvm
  • MirBSD Korn shell cũng được cung cấp dưới dạng package, và là một trong những shell tương tác ưa thích của tác giả

Quản lý gói và kho lưu trữ

  • Trình quản lý gói mặc định của Alpine là apk
  • Theo cách thường thấy trên Linux, apk không phân biệt hệ thống nền tảng và package mà cập nhật cả hai cùng nhau
  • Tác giả chưa kiểm tra liệu có thể chạy bằng một bản sao không đặc quyền như trên BSD hay không
  • Cũng có thể dùng pkgsrc, nên vẫn còn lựa chọn thay thế
  • Cấu hình kho lưu trữ nằm ở /etc/apk/repositories
    • Bỏ comment URL thứ hai do trình cài đặt cung cấp sẽ kích hoạt kho community
    • Alpine cũng có kho testing, và có thể thêm kho riêng
  • Cách dùng khá đơn giản, nhưng do thói quen cũ nên đôi khi tác giả gõ nhầm apt install thay vì apk add
  • Giao diện web package chính thức nằm tại pkgs.alpinelinux.org
  • Có thể tra cứu kho Alpine trên pkgs.org nữa

ZFS và đánh giá như ứng viên cho máy chủ

  • Sau khi cài một vài package, tác giả đã có thể dựng cấu hình “công cụ thiết yếu” từng dùng trên laptop chỉ có console
  • Một trong những package gây bất ngờ nhất là ZFS
    • Việc cài đặt và nạp kernel module có thể thực hiện bằng hai lệnh
# apk add zfs zfs-lts


# modprobe zfs
  • Việc cấu hình root filesystem bằng ZFS có thể phức tạp hơn
  • Tác giả chưa kiểm tra sau khi nâng cấp thì cấu hình ZFS sẽ hoạt động ra sao
  • Chỉ với trải nghiệm đến hiện tại, Alpine đã để lại ấn tượng đủ tốt để tác giả cân nhắc nghiêm túc việc chuyển sang dùng làm bản phân phối Linux chính cho thử nghiệm và máy chủ
  • Các ưu điểm được nêu gồm việc chỉ thấy một số ít process nhận ra được trong htop(1) và lsof(1), sử dụng OpenRC, quản lý gói có vẻ đơn giản và cấu hình dễ dàng
  • Tác giả đánh giá rằng nếu có một “Occam’s Linux” hiện đại và có đầy đủ chức năng, Alpine có lẽ là hình ảnh gần nhất
  • Nếu cần nhiều chức năng hơn busybox, có thể thử chạy uutils, nhưng trên máy chủ thì nhu cầu này có vẻ thấp

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-28
Ý kiến trên Hacker News

  • Nhìn từ góc độ bảo mật, phần lớn binary Linux hiện nay được biên dịch dưới dạng PIE
    Nếu chạy checksec trên một binary bất kỳ của Ubuntu thì sẽ thấy thuộc tính đó, và có thể cài checksec bằng pip install pwntools
    Ngược lại, theo tôi biết thì GLIBC có triển khai heap được gia cố mạnh nhất, đồng thời cũng có nhiều biện pháp giảm thiểu hơn đối với double free và các kiểu tấn công heap khác
    Vì vậy xét ở khía cạnh đó, có thể xem Alpine kém an toàn hơn do dùng musl, nhưng việc là một hệ thống nhỏ và dễ hiểu lại là lợi thế thật sự về bảo mật

    • Tôi không rõ vì sao “một hệ thống nhỏ và dễ hiểu” lại là luận cứ có lợi cho glibc. Chẳng phải ngược lại sao?
    • Trên các node Alpine, tôi luôn chạy checksec cho mọi thứ, và các process đều hiện ra như thế này. Toàn bộ output dài nên bỏ qua, nhưng tôi chưa từng thấy thứ gì do Alpine build mà thiếu các flag này
      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 libc cũng đáng để kiểm tra
    • Từ góc độ bảo mật Linux, tôi cho rằng nếu ai đó có thể chạy dù chỉ một chút code trên hệ thống thì coi như đã xong. Linux đầy lỗ hổng, và lý do malware không tràn ngập như trên Windows là vì có ít người dùng Linux trên desktop, nên những người viết malware không nhắm tới nhiều
      Thành thật mà nói, tôi thấy cả Windows và macOS hiện đại đều có kiến trúc bảo mật tốt hơn

  • Tôi cũng là người dùng BSD, và tình cờ tuần này lần đầu chạy Alpine trong VM trên bhyve
    Điểm cốt lõi là BusyBox. Nếu các tiện ích trong /bin và /sbin không cần phải là từng binary độc lập, user space sẽ rất nhỏ và boot cũng nhanh. Cài thêm Tmux, zsh là đã đủ cho phần lớn nhu cầu Unix
    Để tới môi trường cuối cùng thì tôi phải cài khá nhiều thứ bằng apk, nhưng nhìn chung đây là trải nghiệm Linux tốt nhất tôi có sau một thời gian dài. Sẽ tốt hơn nếu ZFS được tích hợp sẵn theo mặc định, và kết nối virtio được làm rõ ràng hơn cho cách chạy dựa trên ZFS của bhyve

    • Tôi đã dùng và triển khai FreeBSD hơn 20 năm, nhưng thật lòng là khá ngại đăng nhập vào một máy GNU/Linux. Quá nhiều biến thể và sự không nhất quán khiến hệ thống có cảm giác như một mớ hỗn độn. Thậm chí đăng nhập vào Windows server còn cho tôi cảm giác “hợp lý” hơn
      Dù vậy, nghe nói có thể có một bản phân phối Linux tỉnh táo thì cũng mừng, và nếu cần một máy Linux tôi sẽ thử. Chỉ là chuyện đó khá hiếm
    • Tôi tò mò bạn muốn ZFS được “tích hợp sẵn” tới mức nào. Alpine là một trong số ít distro cung cấp module kernel ZFS dạng binary, nên gần như chỉ cần một lệnh apk là cài được
      Wiki Alpine cũng có tài liệu khá ổn về việc cài root filesystem trên ZFS: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS chạy rất tốt trên Alpine. Alpine + ZFS đã là cấu hình server mặc định của tôi trong nhiều năm

  • Nếu là người dùng BSD, có thể bạn cũng sẽ thích Void Linux. Đây là distro do xtraeme, một developer NetBSD, tạo ra; có phiên bản glibc và musl, và dùng runit làm hệ thống init
    Cũng có thể build package từ source bằng xbps-src
    https://voidlinux.org/

    • Tôi từng dùng Arch, rồi sau khi tìm một phương án thay thế không dùng SystemD có cảm giác giống Arch, cuối cùng đã chọn Void. Lý do tôi chọn Void thay vì Alpine là nhờ hỗ trợ glibc nên dùng được driver NVidia. Tất nhiên tôi biết chuyện “chê bai NVidia”
    • Tôi rất thích Void. Hệ thống chính của tôi vẫn là Arch vì lựa chọn package lớn và sự tiện lợi của systemd, nhưng tôi đã cài Void trên máy của người thân và ba thiết bị của mình, và nó rất tuyệt
      Tuy nhiên cần lưu ý là tôi chỉ dùng cài đặt xfce với chỉnh sửa tối thiểu. Các cấu hình đa người dùng phức tạp có thể rắc rối hơn một chút vì runit có ít tính năng tích hợp sẵn hơn systemd
    • Vài năm trước, dùng Rust trên voidlinux+musl có vấn đề. May là Void có thể cài lại sang glibc khá dễ
    • Chimera cũng có thể ổn. User space của các công cụ lõi phần lớn thuộc dòng FreeBSD, nên có lẽ khá quen thuộc với người dùng BSD
    • Cũng có CRUX. Đây là distro có thể xem như tiền thân của Archlinux

  • Tôi đã nghĩ thế nào cũng sẽ có người nói rằng các trang man mà BSD tự hào lại không được Alpine cài sẵn mặc định. Đó là một trong những lý do tôi không dùng Alpine trên laptop mang đi xa, và hiện tôi đang dùng OpenBSD
    Có phải tôi đã bỏ lỡ một tùy chọn cấu hình nào đó để tài liệu luôn được cài khi nhận package trên Alpine không? Hay chỉ còn cách lần nào cũng cài thủ công các package -doc?

    • Nếu luôn muốn có tài liệu, hãy cài meta package docs. Sau đó nó sẽ kéo về các package *-doc phù hợp với những thứ bạn cài
    • Dùng OpenBSD trên laptop thì hỗ trợ phần cứng thế nào?

  • Thành thật mà nói, tôi hoàn toàn không hiểu vì sao người ta lại thấy những thứ như OpenRC hấp dẫn. Tôi nghĩ bất kỳ cách nào dựa trên giám sát cũng tốt hơn kiểu làm rò PID, lưu vào file PID, rồi hy vọng rằng 3 tuần sau giá trị đó vẫn trỏ đến daemon đã chạy
    Hơn nữa, trong một số trường hợp người ta còn xử lý tác vụ quản lý service bằng cách pgrep một tên tiến trình cụ thể. Tôi phần nào đồng ý với ý tưởng rằng không nên mặc định tự động khởi động lại mọi thứ, nhưng đó gần như là ưu điểm duy nhất mà loại này có thể đưa ra
    Rốt cuộc những thứ này cũng phụ thuộc rất nhiều vào syslog, mà đây đúng là công nghệ của thập niên 80. Các công cụ như multilog hay svlogd có thể được cải thiện để dễ cung cấp hơn một góc nhìn tập trung giúp xem thứ tự sự kiện của nhiều công cụ cùng lúc, nhưng việc gom log theo các hạng mục mơ hồ và cho phép bất kỳ ai ghi log ở bất kỳ đâu dưới bất kỳ tên nào thì nghe khá kỳ lạ

    • Nhân tiện, Alpine đã cố gắng thay thế OpenRC trong vài năm qua nhưng chưa tìm được phương án phù hợp. Cũng có nỗ lực để trở thành một bản phân phối độc lập với hệ thống init
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • Dù vậy, lựa chọn thay thế chính là systemd, nhưng nó được thiết kế theo cách không an toàn về bảo mật, để ngỏ khả năng tiếp tục xuất hiện những CVE mới và thú vị
      Có quá nhiều thứ nằm trong PID1, và nó được viết bằng một ngôn ngữ không an toàn bộ nhớ. Tôi không thấy lý do kỹ thuật nào khiến nó không thể được tách thành một PID1 tối thiểu và vài chương trình setuid
      Ngoài việc có thể chạy systemd trong container Docker, tôi không nghĩ ra lý do nào khác; mà Red Hat/IBM có lẽ cũng không quá muốn điều đó, vì họ thích mọi người dùng công cụ container hóa của họ như systemd-nspawn hơn. Với cấu trúc hiện tại, tôi nghĩ nó không thể nào hợp lý từ góc độ bảo mật

  • Alpine có một ưu điểm thú vị. Khi người dùng Nix khoe quản lý gói theo kiểu khai báo, bạn có thể chỉnh trực tiếp /etc/apk/world rồi chạy apk fix để cho thấy cách làm tương tự mà không cần Nix

    • Thường thì cách của Gentoo tốt hơn. Các gói cài thủ công có thể nằm ở /var/lib/portage/world, các tập hợp đã chọn ở /var/lib/portage/world_sets, và định nghĩa tập hợp ở /etc/portage/sets/
      Như vậy có thể chia gói theo từng nhóm, chỉ cài một phần trên các hệ thống cần thiết, và thêm chú thích vào file tùy ý. Thứ tương đương với apk fix là emerge -uDU @world && emerge -c, dù hơi rườm rà hơn
      Alpine cũng có thể tạo thứ gần giống tập hợp bằng apk add -t setname pkg1 pkg2 pkg3; khi đó một gói giả phụ thuộc vào các gói đã chọn sẽ được tạo ra. Tôi thường tạo script shell trong /etc/apk/sets/ để bắt chước cảm giác của Gentoo, nhưng không phải lúc nào cũng giống nhau
    • Trong khoảng thời gian Nix đánh giá system flake của tôi, tôi đã có thể cài lại Alpine từ đầu
    • Đúng là hay, nhưng Nix/OS làm nhiều việc hơn rất nhiều so với chỉ cài đặt gói theo kiểu khai báo

  • Tôi nhớ trước đây từng có các bài viết về hiệu năng khi chạy Alpine trong Docker, và họ khuyên dùng Debian/Ubuntu
    Bài viết về Alpine chậm:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Bài viết thân thiện hơn với Alpine:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    Tôi tự hỏi câu chuyện này hiện còn đúng không

    • Khá nhiều phàn nàn cụ thể ít nhất đã được giải quyết. Như chính cuối liên kết đầu tiên cũng thừa nhận, hiện đã có Python wheel tương thích với Alpine, và vấn đề DNS cũng đã được sửa từ khá lâu
      Dù vậy, về mặt hiệu năng, việc chạy benchmark để xem con số thực tế vẫn sẽ khá thú vị

  • Chẳng phải musl đến giờ vẫn chưa hỗ trợ pthread_attr_setaffinity_np sao? Nếu vậy một số phần mềm sẽ không chạy được, ví dụ lớn nhất là PyTorch

    • Nếu workload nhạy cảm về hiệu năng phụ thuộc vào glibc vì chính hiệu năng đó, thì có lẽ chỉ cần “đơn giản” chạy riêng ứng dụng đó trong container
      Trong nhiều tình huống, sự đơn giản hoặc bảo mật là mối quan tâm quan trọng hơn hiệu năng

  • Điểm cân bằng hợp lý mà tôi tìm được giữa BSD và Linux là Slackware. Nó rất Unix một cách tự tin, không phức tạp, và còn có cây ports riêng phong phú thông qua Slackbuilds

    • Slackware từng cố cạnh tranh với các distro desktop nhưng lại không thực sự dốc sức, nên mất phương hướng
      Trước đây tôi thích nó vì đó là một distro tối thiểu không gây cản trở, và tôi xem nó hướng tới những người có kỹ thuật hơn một chút
      Nhưng khi đào sâu vào vấn đề, cộng đồng đôi khi tỏ ra thù địch chỉ vì tôi không cài đặt đầy đủ. Lý do là cài đầy đủ là cách được khuyến nghị, và nếu không làm vậy thì sẽ gặp những vấn đề phụ thuộc ngớ ngẩn kiểu mplayer không chạy vì thiếu samba
      Tôi thấy Alpine là một cải tiến so với Slackware ở mọi mặt
    • Tôi tôn trọng những người dùng Slackware, nhưng việc thiếu quản lý phụ thuộc trông có vẻ phiền phức

  • Hóa ra Alpine Linux thực ra không phải GNU/Linux. Tôi không biết điều đó
    Vậy thì là BusyBox/Linux à?

    • Cứ gọi là Alpine Linux là được. Theo tôi biết, BusyBox không liên quan đến thói tự đề cao bản thân thỉnh thoảng rò rỉ từ RMS, nên không sao