Đã vận hành blog trên Ubuntu 16.04 suốt 10 năm rồi di chuyển sang FreeBSD

(crocidb.com)

1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp

VPS DigitalOcean chạy trên Ubuntu 16.04 LTS có gánh nặng về việc hết hỗ trợ và bảo mật, nhưng vẫn duy trì uptime 1491 ngày cho tới thời điểm ngừng sử dụng
Máy chủ mới được chuyển sang Hetzner VPS tại Đức với FreeBSD 14.3, dùng cấu hình mạnh hơn máy chủ cũ giá $13/tháng nhưng chi phí dưới 6 euro/tháng
Dùng Jails và Bastille để tạo môi trường cô lập theo từng site; jail Caddy đảm nhiệm SSL và reverse proxy rồi chuyển tiếp tới từng jail nginx
Trong bài test tải, máy chủ FreeBSD mới cho thông lượng xử lý request cao hơn 3 đến 11 lần sau khi điều chỉnh kern.ipc.somaxconn để phục vụ 10.000 kết nối đồng thời
Quá trình chuyển đổi đòi hỏi phải học về networking và cấu hình FreeBSD, nhưng nhờ cấu hình được tập trung hóa và tài liệu tốt nên việc thiết lập dễ hơn dự kiến

Bối cảnh di chuyển

Blog cũ đã được vận hành hơn 10 năm trên DigitalOcean VPS, dùng Ubuntu 16.04 LTS tại datacenter New York
- Ubuntu 16.04 LTS đã hết hỗ trợ từ ít nhất 5 năm trước và không còn nhận cập nhật kho gói apt
- Hệ thống cũ bất lợi về mặt bảo mật; trước đây một blog WordPress riêng từng bị chèn link casino và cờ bạc khi chạy trên VPS cũ
Ngoài blog, máy chủ cũ còn phục vụ thêm vài site khác nhưng phần lớn là site tĩnh
- Ngay cả blog phổ biến nhất cũng thường chỉ ở mức vài nghìn pageview mỗi tháng, ngoại trừ một số bài từng lan truyền trên Hacker News thì lưu lượng không nhiều
- Máy chủ dùng nginx/1.10.3 để phục vụ file tĩnh, với cấu hình theo từng site nằm trong /etc/nginx/sites-available
- Blog được tạo bằng Hugo, và quy trình triển khai cũ là viết nội dung trên máy local → commit/push lên repository → SSH vào server → pull repository → chạy hugo
VPS cũ ban đầu cũng được dùng để thử nghiệm và lập trình nên còn sót lại nhiều phần mềm cũ
- Dù vậy nó vẫn hoạt động bình thường, và uptime khi ngừng sử dụng là 1491 ngày, tức gần 4 năm chạy không cần reboot
Máy chủ mới được chuyển sang Hetzner VPS ở Đức, có cấu hình cao hơn mà chi phí hàng tháng chỉ bằng chưa tới một nửa
- Máy chủ DigitalOcean cũ có RAM 2GB, 1 vCPU, đĩa 50GB, lưu lượng 2TB/tháng, giá $13/tháng
- Ngay cả gói rẻ nhất của Hetzner cũng có bộ nhớ và CPU gấp đôi, dung lượng lưu trữ ít hơn một chút nhưng băng thông gấp 10 lần
- Cấu hình Hetzner được chọn cuối cùng mạnh hơn nữa và có giá dưới 6 euro/tháng

Vì sao chọn FreeBSD

FreeBSD được chọn vì muốn thử một hệ thống mới trong môi trường vận hành thực tế
- Các ưu điểm được nhắc tới là thiết kế tích hợp, độ ổn định, bảo mật và Jails
Jails là tính năng ảo hóa/container hóa đã có mặt trong FreeBSD hơn 25 năm
- Có thể chạy các “hệ thống mini” bị sandbox và không truy cập được vào hệ thống host
- Trong khi các giải pháp container như Docker phù hợp hơn cho việc đóng gói chương trình và mang tính tạm thời, bất biến, thì Jails được xem gần giống subsystem hoặc mini VM dùng chung cùng một kernel
ZFS cũng là một lựa chọn hấp dẫn cho filesystem máy chủ
- Nó có tính toàn vẹn dữ liệu và khả năng snapshot, với vài điểm tương đồng với Btrfs phía Linux
- ZFS được đánh giá trưởng thành hơn Btrfs nhiều, và nếu tạo snapshot thường xuyên thì có thể bớt phụ thuộc vào hệ thống snapshot/backup trả phí của nhà cung cấp VPS
Kiến trúc mục tiêu là mỗi site có một Jail riêng, bên trong chứa nginx và các công cụ build cần thiết
- Một jail dành cho web server chính sẽ đảm nhiệm reverse proxy kết nối với bên ngoài
- Nếu một jail cụ thể bị xâm nhập thì có thể xóa jail đó và tạo lại từ đầu

Cài đặt FreeBSD và đưa Bastille vào sử dụng

Màn hình tạo VM của Hetzner chỉ có ít image hệ điều hành mặc định nên BSD không hiện ra ngay
- Có tham khảo video cài đặt Hetzner trên kênh YouTube chính thức của FreeBSD
- Hetzner có cung cấp image ISO FreeBSD, nhưng sau khi tạo VM phải mount nó trong tab ISO Images của console
- Quá trình cài đặt dùng ISO FreeBSD 14.3 và cấu hình hệ thống theo luồng cài đặt trong video chính thức
Bastille được chọn để giúp quản lý Jails dễ hơn
- Nhiều bước cần thiết khi tạo Jail thủ công có thể được xử lý bằng lệnh bastille
- Các lệnh ví dụ là bastille list, bastille create, bastille console
- Việc cài đặt và kích hoạt được thực hiện theo tài liệu bắt đầu với Bastille

pkg install bastille
sysrc bastille_enable="YES"

Cấu trúc mạng và reverse proxy

Toàn bộ stack được tổ chức theo mô hình một Caddy Jail xử lý mọi domain và chứng chỉ SSL, rồi reverse proxy traffic sang các jail theo từng site
- Mỗi site jail chỉ chứa những công cụ cần để build và phục vụ site đó
- Có thể xem nó như cấu trúc gồm nhiều máy ảo nằm trong cùng một mạng
Interface mạng ảo nội bộ được tạo với tên bastille0

sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"

Interface loopback được clone, đổi tên thành bastille0 và gán mạng 10.0.0.1/24
Các jail sẽ chạy trên interface mạng này
Các request HTTP/HTTPS từ bên ngoài được chuyển đến Caddy Jail bằng rule PF(Packet Filter)
- Trong /etc/pf.conf có cấu hình interface ngoài vtnet0, interface trong bastille0, và tailscale1
- Traffic cổng 80, 443 được redirect tới 10.0.0.5, nơi sẽ chạy Caddy server

ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state

PF và gateway được bật bằng các lệnh sau

sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Caddy và cấu hình jail theo từng site

Máy chủ cũ đã dùng nginx trong thời gian dài, nhưng ở cấu hình mới thì Caddy được chọn để tự động hóa việc quản lý chứng chỉ SSL
- Trong môi trường nginx cũ, chứng chỉ phải được gia hạn định kỳ bằng certbot, và đã có vài lần bị quên gia hạn
Trước khi tạo Caddy Jail, bản phát hành FreeBSD được bootstrap vào Bastille

bastille bootstrap 14.3-RELEASE

Caddy Jail được tạo với IP 10.0.0.5

bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy

Tên jail là caddy, bản phát hành là 14.3-RELEASE, interface là bastille0
Có thể dùng bastille list để kiểm tra trạng thái chạy và bastille console caddy để vào shell bên trong jail
Việc cài Caddy và bật service được thực hiện từ bên trong jail

pkg install caddy
sysrc caddy_enable="YES"
service caddy start

File cấu hình Caddy nằm tại /usr/local/etc/caddy/Caddyfile bên trong jail
- Nếu muốn quản lý file cấu hình từ host thì có thể mount thư mục trên host vào trong jail
- Ví dụ dùng nullfs với tùy chọn chỉ đọc ro để Caddy không thể chỉnh sửa cấu hình

bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

Triển khai site và blog

Site đầu tiên được triển khai là es.cro.to, với repository nằm tại repository GitHub
- Repository được đặt tại /usr/local/www/escroto trên host, rồi mount thư mục đó vào site jail dưới dạng chỉ đọc
- Tất cả site được sắp xếp theo cách đặt dưới /usr/local/www trên host
Jail escroto được tạo bằng template nginx của Bastille

bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx

IP được gán là 10.0.0.11
Trang mặc định của nginx được phục vụ từ /usr/local/www/nginx theo thông lệ của FreeBSD
Thư mục site trên host được mount vào jail dưới dạng chỉ đọc

bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0

Một script triển khai được dùng để tránh việc thư mục .git trong repository bị phục vụ ra web

rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git

Việc triển khai phiên bản mới được thực hiện bằng cách cập nhật repository trên host rồi chạy script triển khai bên trong jail

cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh

Cấu hình Caddy chuyển hướng vĩnh viễn cro.to sang es.cro.to, rồi proxy es.cro.to tới 10.0.0.11

cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}

Blog dùng Hugo và được quản lý tại repository GitHub
- Repository được clone vào /usr/local/www/blog trên host
- Jail blog được tạo tương tự escroto, với IP 10.0.0.12

bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0

Hugo được cài bên trong jail blog

bastille pkg blog update
bastille pkg blog install gohugo

Script triển khai blog sẽ xóa web root của nginx rồi tạo output Hugo vào /usr/local/www/nginx

rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx

Trước khi chuyển DNS, hệ thống được kiểm thử bằng cách nối crocidb.cro.to tới blog server mới thay vì dùng domain cũ

crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

Benchmark và test tải

Trước khi đổi bản ghi DNS, tác giả so sánh khả năng chịu tải của server cũ crocidb.com với server mới crocidb.cro.to
- Người đọc blog chủ yếu đến từ Bắc Mỹ, sau đó là châu Âu và Nam Mỹ, nên độ trễ tới server mới ở Đức có thể tăng nhẹ với một số người dùng
- Mối quan tâm chính là tốc độ phục vụ site tĩnh và khả năng chịu tải lớn
Cũng có dùng các công cụ online miễn phí như GTMetrix, Pingdom, WebPageTest, nhưng khác biệt giữa hai server chủ yếu chỉ là độ trễ
Hai công cụ benchmark tải HTTP là wrk và hey được sử dụng
- Cả hai đều tạo lượng lớn request đồng thời và thu thập độ trễ request, response lỗi, thông lượng mỗi giây, v.v.
Khi chạy wrk từ một VPS khác cũng thuộc Hetzner, server mới vượt trội rõ rệt

wrk -t4 -c100 -d30s --latency https://crocidb.com/

Tùy chọn là 4 thread, 100 kết nối đồng thời, chạy trong 30 giây
Server cũ có độ trễ trung bình 89.63ms, request mỗi giây 833.41, thông lượng 8.29MB/s
Server mới có độ trễ trung bình 6.75ms, request mỗi giây 12260.10, thông lượng 130.80MB/s
Tuy nhiên phép so sánh này không hoàn toàn công bằng vì máy test nằm cùng datacenter với server mới
Cũng đã thử chạy wrk từ nhiều khu vực qua Proton VPN, nhưng kết quả thấp hơn kỳ vọng
- Trung bình server cũ đạt khoảng 300 request/giây, còn server mới đạt khoảng 800 request/giây
- Cuối cùng cách làm được đổi sang tạo VPS thực ở nhiều khu vực thay vì dùng VPN cho người dùng phổ thông

Test theo khu vực bằng VPS của Vultr

Vultr được chọn để dùng hạ tầng khác với DigitalOcean và Hetzner, nơi các server đang chạy
- Do khối lượng thao tác thủ công, các khu vực được giới hạn ở London, São Paulo, Silicon Valley, Tokyo
- Tại mỗi khu vực, một VM Fedora rẻ nhất được tạo để chạy bài test
Công cụ test cuối cùng được đánh giá là hey phù hợp hơn

./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log

Cấu hình gồm tổng 1,000,000 request, 10,000 request đồng thời, timeout 10 giây, thời gian chạy 5 phút, dùng HTTP/2
Đây là mức tải lớn hơn rất nhiều so với lưu lượng thực tế của blog
Ở lần chạy đầu tiên, server FreeBSD mới không chịu nổi 10.000 kết nối đồng thời và thất bại ngay từ đầu
- Kiểm tra kích thước socket queue bằng netstat -Lan thì tất cả đều hiện 128
- Do giá trị mặc định của kern.ipc.somaxconn là 128, nên đã tăng nó như sau

sysctl kern.ipc.somaxconn=16384

Trong bài test tại São Paulo, cả hai server đều trả về khá nhiều lỗi, nhưng server FreeBSD vẫn xử lý được gần đủ 1,000,000 request như mong đợi, còn server Ubuntu thậm chí không trả được 20,000 request
- Server Ubuntu cũ chỉ hoàn thành khoảng 7% tổng số request
- Server FreeBSD mới hoàn thành khoảng 94%
- Ở Tokyo, tỷ lệ thành công của server mới có thấp hơn đôi chút, nhưng được đánh giá là chưa đáng lo ngại
Tính theo request mỗi giây, server mới đạt kết quả tốt hơn server cũ từ ít nhất 3 lần đến tối đa 11 lần
- Ở các percentile độ trễ, server mới tăng tuyến tính hơn cho tới khoảng mốc 90%, nên có tính dự đoán cao hơn
- Ngay cả dưới tải cao, phần lớn khu vực trên thế giới vẫn có thể nhận nội dung trang chủ blog trong dưới 3,5 giây
Kết quả ở Tokyo không được phân tích sâu
- Phân tích theo giai đoạn request của hey cho thấy traffic tới Nhật có thể chậm hơn
- Các giá trị DNS dial-up và lookup của domain thứ hai có vẻ thấp bất thường, có thể do ảnh hưởng của bản ghi CNAME
- Các giá trị resp wait và resp read cũng cao bất thường, nhưng vì chỉ tính các request thành công nên có khả năng server cũ phản hồi nhanh lúc đầu rồi gần như chặn các request mới về sau

Chuyển đổi cuối cùng và bài học chính

Dù benchmark vẫn để lại nhiều câu hỏi chưa giải đáp, tác giả vẫn hài lòng với kết quả và chuyển bản ghi DNS sang server mới
- Từ đó blog này chính thức chạy trên server Hetzner dùng FreeBSD
Việc dựng một máy host site bằng FreeBSD đã trải qua nhiều giờ thử nghiệm, chỉnh sửa, build và thất bại, nhưng không phức tạp như dự đoán
- Hoàn toàn có thể dùng một dịch vụ web hosting đáp ứng yêu cầu; ví dụ được nhắc đến là OpenBSD Amsterdam
- Cũng có thể dùng Proxmox để có container và dashboard quản trị
- Ở phía FreeBSD, Sylve cũng được nhắc đến như một lựa chọn khác
- Tuy nhiên con đường tự dựng mang lại rất nhiều kiến thức nên được xem là lựa chọn đáng giá
Server Ubuntu cũ cũng rất bền bỉ
- Trong 10 năm nó xử lý tải cho site rất tốt, và 4 năm cuối cùng chạy không cần reboot
- Nó hoạt động ổn định mà không cần bỏ quá nhiều công sức cấu hình
Cấu hình FreeBSD hóa ra dễ hơn mong đợi, nhờ cách tập trung hóa cấu hình hệ thống và chất lượng tài liệu trực tuyến tốt
Để tự dựng một máy host blog thì cần kiến thức về networking vượt ra ngoài phạm vi quen thuộc của một game developer
- Quá trình học một hệ thống khác cũng rất thú vị, và lần tới có thể sẽ thử OpenBSD hoặc NetBSD
- Cuối cùng tác giả kết luận rằng tính thực dụng của toàn bộ công việc này là có giới hạn, vì phần lớn traffic của blog đến từ bot crawl của các hệ thống AI

1 bình luận

GN⁺ 3 giờ trước

Ý kiến trên Hacker News

Sai lầm lớn nhất tôi từng mắc phải là thời gian uptime quá cao
Vì arjie.com đã chạy hơn 10 năm trên VPS của Hetzner, đến lúc Hetzner muốn ngừng máy nền tảng đó thì tôi hoàn toàn không biết bản thân thời thiếu niên đã cấu hình những gì
Có bản sao lưu nhưng trang đã ngừng hoạt động suốt 10 năm nay
Giờ thì tôi xây dựng theo cách có thể di chuyển được, rồi thực sự chuyển vài lần để xác nhận là nó hoạt động
- Câu “sai lầm lớn nhất là uptime quá cao” đúng thật
  Tôi còn nhớ thời mà uptime của máy được xem như huy hiệu danh dự
  Tôi chỉ già đi chứ chưa hẳn khôn hơn bao nhiêu, nhưng giờ tôi nhìn vào uptime của dịch vụ
  Trước đây các bản ghi DNS như MX cũng gần với mục đích đó, và các cụm cũ thì khá khó hiểu, nhưng những bài học như split brain vẫn còn đó, nên đến giờ tôi vẫn phải giải thích vì sao cụm Proxmox 2 node lại hỏng, và vì sao người ta khuyên thêm witness
  VMware trước đây cũng sai khi che đậy vấn đề cụm HA 2 node bằng một biện pháp tình thế rất lớn, và nếu cách đó vẫn còn tồn tại thì khả năng cao là nó vẫn sai
  Uptime cao nghĩa là chưa vá lỗi, mà vá lỗi thì ai cũng thích làm mà
- Điều này làm tôi nhớ tới đền Ise ở Nhật Bản
  Cứ mỗi 20 năm họ lại tháo dỡ hoàn toàn rồi xây lại, và trong Breakneck của Dan Wang mà tôi mới đọc gần đây có giải thích rằng tập quán tái dựng như vậy giúp bảo tồn tri thức vốn sẽ biến mất theo thời gian
  Wang đặt đền Ise đối lập với Notre Dame, và cho rằng một phần lý do việc khôi phục mái của Notre Dame khó khăn đến vậy có thể là do thất lạc tri thức
  Tôi không đủ quen thuộc với cả hai công trình để biết đây có phải so sánh công bằng không, nhưng tôi thích nguyên tắc đó
  Trong sách đây chỉ là một ẩn dụ nhỏ thôi, nhưng nhìn chung tôi rất khuyến nghị cuốn này
- Uptime cao trên VM thì không có nhiều ý nghĩa
  Khởi động lại chỉ mất vài giây, còn nâng cấp thì có thể đổi DNS sang instance mới để không gián đoạn
  Máy vật lý không thể sao chép dễ dàng thì lại là câu chuyện khác
- Tôi đã bắt đầu đưa cấu hình vào một kho playbook Ansible lớn
  Không cần phải quản lý hoàn toàn mọi thứ bằng Ansible, chủ yếu tôi chỉ để cấu hình ban đầu ở đó, và vẫn còn nhiều thứ được quản lý thủ công
- Thỉnh thoảng tôi còn lưu Architectural Decision Records cho cả dự án cá nhân
  Nghe thì hơi buồn cười, nhưng lại hữu ích thường xuyên hơn tôi tưởng
Với mục đích cá nhân/sở thích, tôi chủ yếu vận hành theo kiểu Caddy phía trước + Docker Compose
Nếu là website đơn giản thì Caddy phục vụ nội dung trực tiếp, còn nếu là “ứng dụng web” thì gần như tôi container hóa toàn bộ rồi để Caddy làm TLS termination và reverse proxy tới ứng dụng bên dưới Docker
Thường là cấu trúc ~/apps/appname, mỗi thư mục ứng dụng có file Docker Compose và thư mục dữ liệu được mount
Sau compose down, tôi có thể lấy dữ liệu ra bằng (s)ftp để lưu trữ dài hạn hoặc di chuyển site/dịch vụ
Có thời tôi chạy nhiều VM trên máy chủ riêng, nhưng đã chuyển sang các VPS riêng lẻ của OVH, và nếu muốn chạy mail trên OVH thì phải tránh local zone VM vì chúng không cho phép hosting mail
Có thể sẽ khác tùy môi trường
- Tôi bắt đầu dùng Traefik trong một dự án, và đó là bản nâng cấp tốt hơn nginx proxy manager
  NPM cũng rất tuyệt và GUI web của nó cũng ổn, nhưng với Traefik thì chỉ cần ghi đúng hành vi mong muốn vào file Docker Compose là xong
- Thiết lập ở nhà tôi cũng tương tự
  Chỉ là Unraid chạy các container, và một trong số đó là công cụ kiểu nginx được thiết kế để reverse proxy cho các dịch vụ khác
- Tôi cũng làm gần như y hệt
  Tôi đang cân nhắc chuyển từ Debian sang hướng ưu tiên container và hệ thống/OS bất biến như Flatcar
  FreeBSD có những ưu điểm kỹ thuật thú vị, nhưng dù thích hay không thì mặc định của rất nhiều phần mềm mã nguồn mở là Docker, và tôi cũng không có thời gian hay động lực để chuyển mọi thứ sang FreeBSD jail
Vài tuần trước tôi cũng làm đúng việc đó
Máy chủ đã không được cập nhật từ đâu đó khoảng năm 2015, và trên đó có cài Ghost blog thời ấy cùng node 0.10
Tôi xử lý kiểu thô bạo hơn: chỉ tạo bản sao lưu rồi thả tác tử Hermes (Gemini 3.1 Pro) vào
Nó thực hiện mọi nâng cấp và bản vá cần thiết, rồi còn migration sang các thành phần hiện đại tương ứng
Sau đó còn làm thêm khá nhiều việc như harden máy chủ và gỡ các dịch vụ không dùng nữa, và nếu không có hỗ trợ AI thì có lẽ tôi đã còn trì hoãn mãi
- Ngay cả không có AI thì bản thân việc cập nhật cũng rất dễ
  Vấn đề thật sự là rủi ro làm hỏng thứ gì đó, và bản sao lưu giúp giảm bớt điều đó
Dùng FreeBSD cho máy chủ cá nhân từng là một trải nghiệm vui
Nó có gì đó rất ngầu, sạch sẽ, đơn giản và mang cảm giác “punk rock”
Nhưng tôi đã bỏ vì những điểm đau lớn: PM2 có lỗi trên FreeBSD và đó là công cụ tôi dùng để quản lý tiến trình, tôi từng thử chạy daemon bằng rc.d thay thế nhưng thiết lập log quá khó, còn tường lửa thì có quá nhiều thứ phải tự cấu hình nếu muốn khớp cả các thực hành bảo mật tốt như xử lý ICMP thế nào, tôi rất nhớ các mẫu mặc định kiểu UFW
- FreeBSD cũng có kèm các mẫu mặc định như vậy
  Nó được triển khai bằng IPFW chứ không phải PF
  Chỉ cần xem khóa firewall_type trong rc.conf: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
  Nếu muốn cấu hình tường lửa cho máy đơn một cách dễ dàng thì có thể dùng firewall_type=client, còn nếu định host thứ gì đó thì dùng firewall_type=workstation
  Với trường hợp sau, firewall_myservices và firewall_allowservices kiểm soát việc mở cổng nào và mạng/IP nào được phép truy cập
  NAT gateway rất đơn giản thì có thể dùng firewall_type=simple cùng firewall_simple_(iif|inet|oif|onet)(_ipv6)? để đặt tên interface phía ISP/phía trong và dải mạng IPv4/IPv6
  Việc từng tùy chọn chính xác làm gì được triển khai trong /etc/rc.firewall: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
- Tôi tò mò không biết bạn dùng PM2 cho mục đích giám sát (supervision) à
  Log của daemon rc.d, theo kiểu Unix, nếu là thông điệp đơn giản thì dùng logger(1), còn nếu redirect ra file thì quản lý kích thước bằng newsyslog(8) là được
  Với tường lửa, tôi khuyên dùng The Book of PF[0]
  PF trên FreeBSD có khác biệt cú pháp so với pf của OpenBSD, nhưng vẫn đủ để nắm được tường lửa hoạt động thế nào và hiểu nên viết quy tắc nào
  [0]: https://nostarch.com/book-of-pf-4e
- PM2 dù dùng trên OS nào thì cũng luôn có lỗi
  Ban đầu nó cực kỳ tiện, nhưng đồng thời lại là phần mềm rất khó chịu để dùng, và cập nhật biến môi trường khi triển khai thì chưa bao giờ hoạt động đúng ý tôi lấy một lần
- Nỗi đau chính của tôi là nó không chịu nổi sau khi mất điện
  Mỗi lần mất điện, sau khi khởi động lại nó đều yêu cầu phải fsck hệ thống tệp thủ công
Hơi khác chủ đề một chút, nhưng tôi tò mò hiện nay bản phân phối Linux miễn phí nào có vòng đời hỗ trợ dài nhất
Một thời gian dài tôi dùng CentOS 7 cho các VM nhỏ, vì nó có cập nhật bảo mật rất lâu và nguy cơ cập nhật làm hỏng thứ gì đó cũng tối thiểu
Tìm sơ thì hiện tại có vẻ Alma/Rocky Linux là lựa chọn tốt nhất và có hỗ trợ 10 năm
Chỉ là tôi thắc mắc không biết chúng có đang được bảo trì tốt không
- Tôi cũng từng chạy CentOS trên máy chủ hơn 10 năm với kỳ vọng ổn định lâu dài và an tâm
  Nhưng sau khoảng thời gian dài như thế thì hệ sinh thái bị trôi đi rất nhiều, và việc giữ ứng dụng hiện đại chạy trên OS ngày càng khó hơn
  Các gói hạ tầng như glibc, tổ hợp Python/Apache, GCC dần dần không còn khớp với stack ứng dụng hiện đại
  Việc nâng cấp phiên bản sau đó cũng đau đớn, không chỉ vì tôi tự dồn mình vào góc với mớ gói pha trộn kỳ lạ, mà còn vì bản thân đường nâng cấp vốn luôn chỉ ở mức nỗ lực tối đa
  Hình như tôi đã bỏ cuộc khi đi từ 6 lên 7, và cuối cùng nhận ra thứ mình cần là Fedora
  Nếu cập nhật theo chu kỳ 1 năm hoặc nửa năm thì không cần đánh nhau với gói của distro, cấu hình được giữ mới, hoạt động tốt, nâng cấp bản phân phối lớn cũng mượt mà, thời gian gián đoạn cũng tối thiểu
  Tôi không có ý định quay lại “distro máy chủ” nữa
- Alma giờ không còn tương thích mã nguồn RHEL nữa nên có chút linh hoạt
  Ví dụ nó có thể phát hành cập nhật kernel sửa lỗ hổng leo thang đặc quyền nhanh hơn
  Rocky thì phản ứng bằng kho bảo mật tùy chọn cung cấp biện pháp giảm thiểu khai thác trong lúc chờ RHEL phát hành xuống
  Chỉ xét các sự việc gần đây thì cả hai có vẻ đều được bảo trì khá tốt
- Tôi không thực sự hiểu lý do không dùng distro rolling release cho máy chủ cá nhân
  Mọi dịch vụ đều chạy trong container, còn OS nền thì cứ để tự động cập nhật thường xuyên đến mức cần thiết
  Tôi chọn openSUSE MicroOS, và việc gần như cập nhật cùng khởi động lại mỗi ngày khiến tôi khá chắc rằng máy chủ luôn khỏe mạnh
  Cập nhật nguyên tử nên nếu có gì hỏng mà lúc đó tôi không muốn xử lý thì chỉ cần bấm nút rollback trong Cockpit rồi xem lại khi có thời gian
- Bạn đang cược rằng thứ mình host sẽ không sống lâu hơn chu kỳ nâng cấp
  Đến lúc buộc phải nâng cấp thì khả năng cao sẽ khá đau
  Tôi nghĩ tốt hơn là nhảy phiên bản nhỏ thường xuyên, thay vì một cú nhảy lớn sau thời gian dài khi mọi thứ đã đổi khác hết
- Nếu muốn hoàn toàn miễn phí hoặc có nhiều máy thì Alma và Rocky là phù hợp
  Còn nếu không ngại đăng ký với Red Hat thì có RHEL, họ cho truy cập cập nhật miễn phí tới 10 máy cho mỗi tài khoản đăng ký
  RHEL chắc chắn là bản phân phối ổn định nhất trong các distro lớn, còn Alma và Rocky về bản chất là các bản sao downstream của RHEL
Tôi cũng đang cùng cảnh ngộ
Tôi có 2 máy chủ cũ đã bị bỏ mặc “quá” lâu, và giờ tôi sợ động vào để cập nhật
Nhưng nhìn mớ ồn ào mà các distro Linux đang làm quanh chuyện xác minh/chứng minh tuổi thì tôi cũng đang nghĩ đến chuyện rời đi hẳn
Tôi cũng thử Artix, nhưng nó hỏng sau lần khởi động lại tuần trước, có vẻ do lần cập nhật kernel trước đó có gì không ổn nên tôi còn phải lôi cả rescue ISO ra
Vì thế tôi đổi máy đó sang Devuan, nhưng vẫn đang tạm thời chưa kết luận
Chưa có phàn nàn lớn nào, nhưng vẫn còn trong giai đoạn burn-in
Trên laptop tôi đang chạy Arch, nhưng cộng đồng có vẻ hơi thù địch vì các vấn đề kiểm duyệt nên tôi đang chờ cuối tuần rảnh để xóa đi cài thứ khác
Tôi không muốn drama chính trị trong phần mềm
Điều thú vị là đây là lần đầu tôi mua laptop mới rồi cài Linux ngay mà không hề boot vào Windows lấy một lần, và mọi thứ đều “chạy luôn”
Đúng lúc tôi chuẩn bị hào hứng dùng Linux thì thật buồn khi các bên lớn lại chấp nhận những bước xói mòn quyền riêng tư như AI ở khắp nơi, xác minh/chứng minh tuổi, telemetry bật sẵn mặc định
Tôi chỉ muốn nói “không đời nào” với những thứ như vậy
- Tôi từng bỏ mặc một máy chủ Ubuntu 10 năm rồi cập nhật nó trong 20 phút mà không đau đớn gì
  Máy đó đến giờ vẫn đang chạy trên LTS mới nhất
  Tôi thậm chí không nhớ nó bắt đầu từ Ubuntu 4 hay 6, nhưng suốt quá trình đều ổn
  Có khi nâng cấp chậm lại giúp tránh được những nỗi đau của người dùng sớm
  Giờ tôi dùng Debian nhiều hơn hẳn
  Trong thời buổi đầy tấn công chuỗi cung ứng, Debian Stable thật sự là viên ngọc quý, và dù có vài gói phải tự xử lý riêng vì cần bản mới hơn thì tôi vẫn thích tinh thần kỹ nghệ giản dị, cổ điển đó
- Về chuyện xác minh/chứng minh tuổi thì có vẻ bạn đã bị dẫn dắt sai rồi
- Việc lần cập nhật kernel trước làm máy hỏng sau khi khởi động lại chủ yếu là vấn đề của Arch/Artix
  Hai distro đó thuộc nhóm chạy theo dòng mới nhất nhanh nhất, và không phải lúc nào cũng tối ưu cho ổn định
  Nhưng điều đó không có nghĩa rolling distro lúc nào cũng phải cung cấp mọi thứ ở bản mới nhất tuyệt đối
  Tôi đã dùng Void Linux vài tháng nay, nó là rolling distro nhưng dùng kernel LTS, vẫn cho chọn mainline, và những người bảo trì tập trung vào phiên bản ứng dụng ổn định hơn là cập nhật thật nhanh
- Máy chủ/VM của tôi thường chạy FreeBSD hoặc Alpine
  Ở những nơi cần thiết thì có thêm chút Debian, ví dụ như Proxmox, VPS không hỗ trợ Alpine, hoặc thiết bị liên quan tới công việc
  Tôi cũng có vài hệ thống thử nghiệm chạy Chimera, nhưng chưa định phụ thuộc nhiều vào nó cho đến khi có bản ổn định
  Tôi cũng đang thử AerynOS một chút
- Tôi ước vòng đời hỗ trợ của FreeBSD dài hơn
  Tuổi thọ hỗ trợ của mỗi bản phát hành dưới 1 năm, nên nếu lỡ cửa sổ nâng cấp thì việc nâng cấp về sau còn khó hơn những distro khác như Debian Stable
Tôi đã chuyển sang Debian và Ubuntu cho mục đích máy chủ, nhưng hồi còn trẻ vào giữa những năm 2000 thì tôi từng mê FreeBSD
Tôi đã dành nhiều thời gian để tinh chỉnh và thiết lập nó hơn là làm việc gì thực sự hữu ích
Hồi đó rất khó tìm được máy chủ riêng hay VPS có cung cấp họ BSD, và hình như cuối cùng tôi dùng Panix.com
Trước đó tôi còn nhớ có công ty tên 15MinuteServers, hình như thuộc NAC ở New Jersey, cũng từng cung cấp BSD
Giờ thì tôi chỉ đang lảm nhảm hoài niệm thôi
- Dạo này việc cài đặt ở các nhà cung cấp của tôi khá đơn giản
  Tôi dùng FreeBSD trên Hetzner và OVH, trước đây cũng từng dùng Vultr
- OVH có mẫu FreeBSD
  Và đa số nhà cung cấp VM/VPS KVM đều cho truy cập console và mount ISO của người dùng, nên bạn có thể cài bất cứ gì mình muốn
fastfetch báo dung lượng bộ nhớ dùng cao hơn thực tế có lẽ là do ZFS ARC
Giống page cache trên Linux, nó có thể bị thu hồi bất cứ lúc nào, chỉ là mỗi công cụ gọi tên khác nhau: https://www.linuxatemyram.com/
Tôi nhớ khi ai đó lần đầu giải thích Docker cho mình, tôi đã đáp “à, ý bạn là jail à?”
Đúng như bài viết mô tả, nó không hoàn toàn giống nhau
kqueue cũng là một chiến thắng lớn
Thật sự biết ơn các nhà phát triển FreeBSD
Tôi đã vận hành công ty đầu tiên của mình trên FreeBSD suốt 15 năm, và uptime cùng khả năng phục hồi thật đáng kinh ngạc
Tôi cũng có một máy chủ Ubuntu 16.04 mà tôi sợ cập nhật
Uptime hiện tại là 1281 ngày, đến mức giờ thấy áy náy nếu phải khởi động lại nó
- Bạn có thể sao chép hệ thống tệp sang máy khác bằng dd, rồi boot nó bằng trình giả lập như qemu để diễn tập trước
  Chỉ cần cẩn thận nếu có thứ gì tự khởi động và kết nối ra bên ngoài
- Tôi không hiểu bạn đang sợ điều gì
  Bạn có bản sao lưu mà, đúng không?
  Hệ thống Debian/Ubuntu có thể được cấu hình rất dễ để tự động cập nhật và khởi động lại định kỳ, nhờ đó việc bảo trì thủ công chỉ còn lại các lần nâng cấp phiên bản lớn
- Máy chủ lâu đời nhất của tôi đang ở 8.04

Đã vận hành blog trên Ubuntu 16.04 suốt 10 năm rồi di chuyển sang FreeBSD

Bối cảnh di chuyển

Vì sao chọn FreeBSD

Cài đặt FreeBSD và đưa Bastille vào sử dụng

Cấu trúc mạng và reverse proxy

Caddy và cấu hình jail theo từng site

Triển khai site và blog

Benchmark và test tải

Test theo khu vực bằng VPS của Vultr

Chuyển đổi cuối cùng và bài học chính

Bài viết liên quan

1 bình luận

Ý kiến trên Hacker News