Mengoperasikan blog di Ubuntu 16.04 selama 10 tahun lalu memigrasikannya ke FreeBSD

 (crocidb.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • VPS DigitalOcean berbasis Ubuntu 16.04 LTS memiliki beban karena dukungan sudah berakhir dan risiko keamanan, tetapi tetap mempertahankan uptime 1491 hari hingga saat dipensiunkan
  • Server baru dipindahkan ke Hetzner VPS di Jerman dan FreeBSD 14.3, dengan spesifikasi lebih kuat daripada server lama seharga $13 per bulan, namun biayanya kurang dari 6 euro per bulan
  • Dengan Jails dan Bastille, dibuat lingkungan terisolasi per situs, dan Caddy Jail menangani SSL serta reverse proxy lalu meneruskannya ke masing-masing nginx Jail
  • Dalam uji beban, server FreeBSD baru menunjukkan throughput permintaan 3 hingga 11 kali lebih tinggi setelah kern.ipc.somaxconn disesuaikan untuk 10.000 koneksi serentak
  • Proses perpindahan memerlukan pembelajaran jaringan dan konfigurasi FreeBSD, tetapi berkat konfigurasi yang terpusat dan kualitas dokumentasi, penyiapannya lebih mudah daripada perkiraan

Latar belakang migrasi

  • Blog lama telah dijalankan lebih dari 10 tahun di DigitalOcean VPS, menggunakan Ubuntu 16.04 LTS di pusat data New York
    • Dukungan Ubuntu 16.04 LTS sudah berakhir setidaknya sejak 5 tahun lalu, sehingga tidak lagi menerima pembaruan repositori paket apt
    • Sistem yang tua merugikan dari sisi keamanan, dan blog WordPress terpisah di masa lalu pernah mengalami serangan penyisipan tautan kasino dan judi pada VPS lama
  • Selain blog, server lama juga melayani beberapa situs lain, tetapi sebagian besar adalah situs statis
    • Bahkan blog yang paling populer biasanya hanya berada di kisaran beberapa ribu pageview per bulan, kecuali beberapa tulisan yang sempat viral di Hacker News, sehingga trafiknya tidak besar
    • Server menyajikan berkas statis dengan nginx/1.10.3, dan konfigurasi per situs berada di /etc/nginx/sites-available
    • Blog dibuat dengan Hugo, dan prosedur deploy lama adalah menulis secara lokal → commit dan push ke repositori → SSH ke server → pull repositori → jalankan hugo
  • VPS lama pada awalnya juga dipakai untuk pengujian dan pemrograman, sehingga masih banyak perangkat lunak lama yang tertinggal
    • Meski begitu, sistem tetap berjalan dengan baik, dan uptime saat dihentikan mencapai 1491 hari, berarti beroperasi sekitar 4 tahun tanpa reboot
  • Server baru dipindahkan ke Hetzner VPS di Jerman, dengan spesifikasi lebih tinggi dan biaya bulanan kurang dari setengah server lama
    • Server DigitalOcean lama memiliki RAM 2GB, 1 vCPU, disk 50GB, trafik bulanan 2TB, dan biaya $13 per bulan
    • Server termurah Hetzner pun sudah menawarkan memori dan CPU dua kali lipat dibanding sebelumnya, ruang penyimpanan sedikit lebih kecil, tetapi trafik 10 kali lebih besar
    • Konfigurasi Hetzner yang akhirnya dipilih memiliki spesifikasi lebih kuat dengan harga kurang dari 6 euro per bulan

Alasan memilih FreeBSD

  • FreeBSD dipilih karena ingin mencoba sistem baru langsung di lingkungan produksi nyata
    • Keunggulan yang disebutkan adalah desain yang terintegrasi, stabilitas, keamanan, dan Jails
  • Jails adalah fitur virtualisasi dan kontainerisasi yang sudah ada di FreeBSD selama lebih dari 25 tahun
    • Fitur ini memungkinkan menjalankan “sistem mini” seperti sandbox yang tidak bisa mengakses sistem host
    • Sementara solusi kontainer seperti Docker lebih cocok untuk packaging program dan cenderung bersifat sementara serta immutable, Jails lebih diperlakukan seperti subsistem atau mini VM yang berbagi kernel yang sama
  • ZFS juga menjadi pilihan menarik sebagai filesystem untuk server
    • ZFS memiliki integritas data dan fitur snapshot, dengan kemiripan tertentu dengan Btrfs di Linux
    • ZFS dinilai jauh lebih matang daripada Btrfs, dan jika snapshot diambil sering, ketergantungan pada sistem snapshot atau backup berbayar dari penyedia VPS bisa dikurangi
  • Struktur yang dituju adalah satu Jail untuk tiap situs, dengan tool build yang diperlukan dan nginx di dalam masing-masing Jail
    • Jail untuk web server utama bertugas sebagai reverse proxy yang terhubung ke luar
    • Jika Jail tertentu disusupi, struktur ini dimaksudkan agar Jail tersebut bisa dihapus lalu dibuat ulang

Instalasi FreeBSD dan penggunaan Bastille

  • Di layar pembuatan VM Hetzner, pilihan image OS bawaan terbatas sehingga BSD tidak langsung terlihat
    • Merujuk ke video instalasi Hetzner dari kanal YouTube resmi FreeBSD
    • Hetzner menyediakan image ISO FreeBSD, tetapi harus di-mount lewat tab ISO Images di konsol setelah VM dibuat
    • Instalasi menggunakan ISO FreeBSD 14.3, dan sistem disiapkan mengikuti alur instalasi pada video resmi tersebut
  • Bastille dipilih untuk mempermudah pengelolaan Jails
    • Berbagai langkah yang diperlukan untuk membuat Jail secara manual bisa ditangani dengan perintah bastille
    • Contoh perintahnya adalah bastille list, bastille create, bastille console
    • Instalasi dan aktivasi mengikuti dokumentasi memulai Bastille
pkg install bastille
sysrc bastille_enable="YES"

Struktur jaringan dan reverse proxy

  • Seluruh stack disusun agar satu Caddy Jail menangani semua domain dan sertifikat SSL, lalu me-reverse-proxy trafik ke Jail per situs
    • Setiap Jail situs hanya berisi tool yang diperlukan untuk membangun dan menyajikan situs tersebut
    • Struktur ini bisa dipandang mirip beberapa mesin virtual dalam jaringan yang sama
  • Antarmuka jaringan virtual internal dibuat sebagai 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"
  • Antarmuka loopback dikloning, diberi nama bastille0, lalu dialokasikan jaringan 10.0.0.1/24
  • Semua Jail berjalan pada antarmuka jaringan ini
  • Permintaan HTTP dan HTTPS dari luar diteruskan ke Caddy Jail dengan aturan PF(Packet Filter)
    • Di /etc/pf.conf dikonfigurasi antarmuka eksternal vtnet0, antarmuka internal bastille0, dan tailscale1
    • Trafik ke port 80 dan 443 diarahkan ke 10.0.0.5, yang akan menjadi server Caddy
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 dan gateway diaktifkan dengan perintah berikut
sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Konfigurasi Caddy dan Jail per situs

  • Server lama sudah lama menggunakan nginx, tetapi pada konfigurasi baru dipilih Caddy untuk mengotomatiskan pengelolaan sertifikat SSL
    • Pada lingkungan nginx lama, sertifikat harus diperbarui berkala dengan certbot, dan pembaruan ini beberapa kali pernah terlewat
  • Sebelum membuat Caddy Jail, rilis FreeBSD di-bootstrap ke Bastille terlebih dahulu
bastille bootstrap 14.3-RELEASE
  • Caddy Jail dibuat dengan IP 10.0.0.5
bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy
  • Nama Jail adalah caddy, rilisnya 14.3-RELEASE, dan antarmukanya bastille0
  • Status berjalan bisa dicek dengan bastille list, dan shell di dalam Jail bisa diakses dengan bastille console caddy
  • Instalasi Caddy dan aktivasi layanannya dilakukan di dalam Jail
pkg install caddy
sysrc caddy_enable="YES"
service caddy start
  • Berkas konfigurasi Caddy berada di /usr/local/etc/caddy/Caddyfile di dalam Jail
    • Jika ingin mengelola berkas konfigurasi dari host, direktori host bisa di-mount ke dalam Jail
    • Pada contoh, mount dilakukan dengan nullfs dan opsi read-only ro agar Caddy tidak bisa mengubah konfigurasi
bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

Deploy situs dan blog

  • Target deploy pertama adalah es.cro.to, dan repositori situs dikelola di repositori GitHub
    • Repositori ditempatkan di /usr/local/www/escroto pada host, lalu direktori itu di-mount read-only ke situs Jail
    • Semua situs ditata agar berada di bawah /usr/local/www pada host
  • Jail escroto dibuat dengan template nginx 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-nya ditetapkan sebagai 10.0.0.11
  • Halaman default nginx disajikan dari /usr/local/www/nginx sesuai kebiasaan FreeBSD
  • Direktori situs di host di-mount ke Jail sebagai read-only
bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0
  • Agar direktori .git di repositori tidak ikut tersaji ke web, digunakan skrip deploy
rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git
  • Deploy versi baru dilakukan dengan memperbarui repositori di host lalu menjalankan skrip deploy di dalam Jail
cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh
  • Konfigurasi Caddy mengarahkan cro.to secara permanen ke es.cro.to, lalu mem-proxy es.cro.to ke 10.0.0.11
cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}
  • Blog menggunakan Hugo dan dikelola di repositori GitHub
    • Repositori di-clone ke /usr/local/www/blog pada host
    • Jail blog dibuat mirip dengan escroto, dengan 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 dipasang di dalam Jail blog
bastille pkg blog update
bastille pkg blog install gohugo
  • Skrip deploy blog mengosongkan web root nginx lalu menghasilkan output Hugo ke /usr/local/www/nginx
rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx
  • Sebelum DNS dipindahkan, pengujian dilakukan dengan menghubungkan crocidb.cro.to ke server blog baru alih-alih domain lama
crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

Benchmark dan uji beban

  • Sebelum mengubah record DNS, kemampuan menangani beban dibandingkan antara server lama crocidb.com dan server baru crocidb.cro.to
    • Pengunjung blog terutama datang dari Amerika Utara, lalu Eropa dan Amerika Selatan, sehingga latensi ke server baru di Jerman mungkin sedikit lebih tinggi bagi sebagian pengguna
    • Fokus utamanya adalah kecepatan penyajian situs statis dan kemampuan bertahan di bawah beban besar
  • Alat online gratis seperti GTMetrix, Pingdom, dan WebPageTest juga dipakai, tetapi perbedaan kedua server sebagian besar hanya pada latensi
  • Untuk benchmark beban HTTP digunakan wrk dan hey
    • Kedua alat ini membuat permintaan serentak dalam jumlah besar dan mengumpulkan latensi permintaan, respons error, throughput per detik, dan sebagainya
  • Saat wrk dijalankan dari VPS lain di Hetzner yang sama, server baru unggul jauh
wrk -t4 -c100 -d30s --latency https://crocidb.com/
  • Opsi yang dipakai adalah 4 thread, 100 koneksi serentak, dan durasi 30 detik
  • Server lama mencatat latensi rata-rata 89.63ms, 833.41 permintaan per detik, throughput 8.29MB/s
  • Server baru mencatat latensi rata-rata 6.75ms, 12260.10 permintaan per detik, throughput 130.80MB/s
  • Perbandingan ini tidak sepenuhnya adil karena mesin pengujian berada di pusat data yang sama dengan server baru
  • Menjalankan wrk dari berbagai wilayah lewat Proton VPN juga sempat dicoba, tetapi hasilnya lebih rendah dari harapan
    • Rata-rata server lama tercatat sekitar 300 permintaan per detik, sedangkan server baru sekitar 800 permintaan per detik
    • Pada akhirnya pendekatan diubah dari VPN pengguna umum menjadi pembuatan VPS nyata di berbagai wilayah

Pengujian per wilayah dengan VPS Vultr

  • Untuk menggunakan infrastruktur yang berbeda dari DigitalOcean dan Hetzner tempat server berada, dipilih Vultr
    • Wilayah dibatasi menjadi empat: London, São Paulo, Silicon Valley, dan Tokyo, karena beban kerja manual
    • Di tiap wilayah dibuat VM Fedora termurah lalu pengujian dijalankan
  • Alat uji akhir yang dinilai lebih cocok adalah hey
./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
  • Konfigurasinya adalah total 1,000,000 permintaan, 10,000 permintaan serentak, timeout 10 detik, durasi total 5 menit, dan menggunakan HTTP/2
  • Beban ini jauh lebih besar daripada trafik blog yang realistis
  • Pada percobaan pertama, server FreeBSD baru gagal menahan 10.000 koneksi serentak di awal pengujian
    • Saat ukuran socket queue dicek dengan netstat -Lan, semuanya terlihat bernilai 128
    • Nilai bawaan kern.ipc.somaxconn adalah 128, sehingga dinaikkan seperti berikut
sysctl kern.ipc.somaxconn=16384
  • Pada pengujian São Paulo, kedua server mengembalikan cukup banyak error, tetapi server FreeBSD tetap mampu menangani target 1,000,000 permintaan, sementara server Ubuntu bahkan tidak mampu mengembalikan 20,000 permintaan
    • Server Ubuntu lama hanya menyelesaikan sekitar 7% dari total permintaan
    • Server FreeBSD baru menyelesaikan sekitar 94%
    • Di Tokyo, tingkat keberhasilan server baru sedikit lebih rendah, tetapi tidak dianggap cukup mengkhawatirkan
  • Berdasarkan jumlah permintaan per detik, server baru setidaknya 3 kali hingga 11 kali lebih baik daripada server lama
    • Pada persentil latensi, server baru menunjukkan kenaikan yang lebih linear hingga sekitar titik 90%, sehingga perilakunya lebih mudah diprediksi
    • Bahkan di bawah beban tinggi, sebagian besar wilayah dunia masih bisa menerima konten halaman utama blog dalam waktu kurang dari 3,5 detik
  • Hasil Tokyo tidak dianalisis lebih dalam
    • Analisis tahap demi tahap permintaan dari hey mengindikasikan kemungkinan trafik menuju Jepang memang lebih lambat
    • Nilai DNS dial-up dan lookup untuk domain kedua terlihat tidak normal dan mungkin dipengaruhi record CNAME
    • Nilai resp wait dan resp read juga terlihat aneh, dan karena hanya permintaan yang berhasil yang dihitung, mungkin server lama merespons cepat di awal lalu secara praktis memblokir permintaan baru setelahnya

Peralihan akhir dan pelajaran utama

  • Meskipun benchmark tidak menjawab semua hal, hasilnya memuaskan sehingga record DNS dipindahkan ke server baru
    • Sejak itu blog ini resmi dijalankan di server Hetzner berbasis FreeBSD
  • Menyiapkan mesin hosting situs dengan FreeBSD memang melalui berjam-jam eksperimen, perbaikan, build, dan kegagalan, tetapi tidak serumit yang dibayangkan
    • Bisa saja menggunakan layanan web hosting yang memenuhi kebutuhan, dan contohnya adalah OpenBSD Amsterdam
    • Bisa juga memakai Proxmox untuk kontainer dan dashboard manajemen
    • Sebagai alternatif di kubu FreeBSD, Sylve juga disebut
    • Namun jalur merakit sendiri ini memberi banyak pembelajaran, sehingga dianggap pilihan yang memuaskan
  • Server Ubuntu lama juga sangat tangguh
    • Selama 10 tahun mampu menangani beban situs dengan baik, dan 4 tahun terakhir berjalan tanpa reboot
    • Sistemnya stabil tanpa perlu upaya konfigurasi besar
  • Konfigurasi FreeBSD ternyata lebih mudah daripada perkiraan, dengan pendekatan sentralisasi pengaturan sistem dan dokumentasi online yang berkualitas baik
  • Untuk merakit sendiri mesin hosting blog, dibutuhkan pengetahuan jaringan yang melampaui apa yang biasanya diketahui pengembang game
    • Proses mempelajari sistem lain terasa menyenangkan, dan lain kali mungkin akan mencoba OpenBSD atau NetBSD
    • Penutupnya mencatat bahwa sebagian besar trafik blog ternyata berasal dari crawler sistem AI, sehingga manfaat praktis dari semua pekerjaan ini agak terbatas

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Kesalahan terbesar yang pernah saya buat adalah uptime yang tinggi
    Karena arjie.com sudah berjalan lebih dari 10 tahun di VPS Hetzner, saat Hetzner hendak mematikan mesin dasarnya, saya sama sekali tidak tahu apa yang sudah saya konfigurasi saat masih remaja
    Ada backup, tetapi situsnya sudah down selama 10 tahun
    Sekarang saya membangunnya agar bisa dipindahkan, lalu benar-benar memindahkannya beberapa kali untuk memastikan semuanya bekerja

    • Ucapan “kesalahan terbesar adalah uptime yang tinggi” memang benar
      Saya juga ingat masa ketika uptime mesin dianggap seperti lencana kehormatan
      Saya memang bertambah tua, bukan berarti jadi lebih bijak, tetapi sekarang saya melihat uptime layanan
      Dulu record DNS seperti MX juga kurang lebih menuju ke tujuan itu, dan cluster lama memang cukup membingungkan, tetapi pelajaran seperti split brain tetap tersisa, jadi sampai sekarang saya masih harus menjelaskan kenapa cluster Proxmox 2-node bisa rusak, dan kenapa witness tambahan direkomendasikan
      VMware dulu juga salah ketika menutupi masalah cluster HA 2-node dengan solusi sementara besar-besaran, dan kalau pendekatan itu masih ada sampai sekarang, besar kemungkinan tetap salah
      Uptime yang tinggi berarti tidak melakukan patch, dan patch adalah hal yang semua orang sukai
    • Ini mengingatkan saya pada Kuil Ise di Jepang
      Kuil itu dibongkar total lalu dibangun ulang setiap 20 tahun, dan di Breakneck karya Dan Wang yang baru saya baca, dijelaskan bahwa praktik pembangunan ulang seperti ini menjaga pengetahuan yang kalau tidak akan hilang seiring waktu
      Wang membandingkan Kuil Ise dengan Notre Dame, dan menganggap salah satu alasan rekonstruksi atap Notre Dame cukup sulit adalah kemungkinan hilangnya pengetahuan
      Saya tidak cukup akrab dengan kedua bangunan itu untuk tahu apakah ini perbandingan yang adil, tetapi saya menyukai prinsipnya
      Di bukunya ini hanya analogi kecil, tetapi secara keseluruhan sangat saya rekomendasikan
    • Di VM, uptime yang tinggi tidak terlalu berarti
      Reboot hanya butuh beberapa detik, dan upgrade bisa dilakukan tanpa downtime cukup dengan mengalihkan DNS ke instance baru
      Ceritanya berbeda untuk mesin fisik yang tidak mudah direplikasi
    • Saya mulai menaruh konfigurasi di repositori playbook Ansible yang besar
      Semuanya tidak harus dikelola sepenuhnya dengan Ansible; kebanyakan saya hanya menaruh konfigurasi awal di sana, dan masih banyak hal yang saya kelola secara manual
    • Kadang saya juga menulis Architectural Decision Records bahkan untuk proyek pribadi
      Rasanya agak konyol, tetapi ternyata lebih sering membantu daripada yang saya kira

  • Untuk penggunaan pribadi/hobi, saya umumnya menjalankan kombinasi Caddy di depan + Docker Compose
    Kalau situsnya sederhana, Caddy langsung menyajikan kontennya, dan kalau itu “web app”, hampir semuanya saya kontainerisasi lalu Caddy menangani terminasi TLS dan reverse proxy ke aplikasi di bawah Docker
    Biasanya strukturnya ~/apps/appname, dan di setiap direktori aplikasi ada file Docker Compose serta direktori data yang di-mount
    Setelah compose down, saya bisa mengambil datanya lewat (s)ftp untuk arsip jangka panjang atau memindahkan situs/layanan
    Dulu saya pernah menjalankan beberapa VM di dedicated server, tetapi kemudian pindah ke VPS terpisah dari OVH, dan kalau ingin menjalankan email di OVH, sebaiknya hindari VM zona lokal yang tidak mengizinkan hosting email
    Tergantung lingkungannya

    • Saya mulai memakai Traefik di satu proyek, dan itu merupakan peningkatan yang lebih baik dibanding nginx proxy manager
      NPM juga bagus dan GUI web-nya lumayan, tetapi dengan Traefik, cukup tulis perilaku yang diinginkan di file Docker Compose lalu selesai
    • Setup rumah saya juga mirip
      Hanya saja Unraid yang menjalankan kontainernya, dan salah satunya adalah alat turunan nginx yang dirancang untuk menjadi reverse proxy bagi layanan lain
    • Saya juga hampir melakukan hal yang sama
      Saya sedang mempertimbangkan untuk beralih dari Debian ke sistem/OS yang container-first dan immutable seperti Flatcar
      FreeBSD punya beberapa keunggulan teknis yang menarik, tetapi suka atau tidak, default bagi banyak software open source adalah Docker, dan saya tidak punya waktu atau motivasi untuk memindahkan semuanya ke FreeBSD jail

  • Beberapa minggu lalu saya juga melakukan hal yang sama
    Servernya belum diperbarui sejak sekitar 2015, dan di sana terpasang blog Ghost dari masa itu serta node 0.10
    Saya menanganinya dengan cara yang lebih kasar: cukup ambil backup, lalu lepas agen Hermes (Gemini 3.1 Pro)
    Agen itu melakukan semua upgrade dan patch yang diperlukan, lalu melanjutkan migrasi ke item yang didukung versi terbaru
    Setelah itu, pengerasan server dan penghapusan layanan yang tidak dipakai juga cukup banyak dilakukan, dan tanpa bantuan AI saya rasa akan terus saya tunda

    • Bahkan tanpa AI pun update-nya sendiri sebenarnya sangat mudah
      Masalah sebenarnya adalah risiko ada sesuatu yang rusak, dan itu bisa diredam oleh backup

  • Saya pernah senang memakai FreeBSD di server pribadi
    Ada kesan keren, rapi, sederhana, dan terasa seperti “punk rock”
    Tetapi saya menyerah karena titik sakit utamanya: PM2 punya bug di FreeBSD dan itu alat yang saya pakai untuk manajemen proses, saya mencoba alternatif menjalankan daemon dengan rc.d tetapi konfigurasi log-nya terlalu sulit, firewall juga punya terlalu banyak hal yang harus diatur manual kalau ingin mengikuti praktik keamanan yang baik seperti bagaimana menangani ICMP, dan saya merindukan template bawaan seperti default UFW

    • FreeBSD juga menyertakan template default seperti itu
      Implementasinya memakai IPFW, bukan PF
      Lihat key firewall_type di rc.conf: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
      Untuk menyiapkan firewall mesin tunggal dengan mudah, Anda bisa memakai firewall_type=client, atau jika ingin meng-host sesuatu, gunakan firewall_type=workstation
      Dalam kasus yang terakhir, firewall_myservices dan firewall_allowservices mengatur port mana yang dibuka dan jaringan/IP mana yang boleh mengakses
      Untuk gateway NAT yang sangat sederhana, gunakan firewall_type=simple serta firewall_simple_(iif|inet|oif|onet)(_ipv6)? untuk menetapkan nama interface sisi ISP/sisi internal dan rentang jaringan IPv4/IPv6
      Implementasi persis tiap opsinya ada di /etc/rc.firewall: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
    • Saya penasaran apakah Anda memakai PM2 untuk tujuan supervision
      Untuk log daemon rc.d, cara Unix yang sederhana adalah memakai logger(1) untuk pesan biasa, atau redirect ke file lalu kelola ukurannya dengan newsyslog(8)
      Untuk firewall, saya merekomendasikan The Book of PF[0]
      PF di FreeBSD memang punya perbedaan sintaks dibanding pf di OpenBSD, tetapi tetap cukup untuk memahami cara kerja firewall dan aturan seperti apa yang perlu ditulis
      [0]: https://nostarch.com/book-of-pf-4e
    • PM2 selalu punya bug tidak peduli dipakai di OS apa
      Awalnya memang terasa sangat praktis, tetapi sekaligus software yang menyebalkan dipakai, dan saat deployment, pembaruan environment variable tidak pernah sekali pun berjalan seperti yang dimaksudkan
    • Masalah utama saya adalah tidak tahan setelah listrik padam
      Jika listrik mati, setelah reboot sistem akan meminta fsck pada filesystem secara manual

  • Ini agak berbeda, tetapi saya penasaran distribusi Linux gratis mana yang saat ini punya siklus dukungan paling panjang
    Selama beberapa waktu saya memakai CentOS 7 untuk VM kecil, karena update keamanannya tersedia sangat lama dan risiko ada sesuatu yang rusak karena update juga minimal
    Setelah sedikit mencari, saat ini Alma/Rocky Linux tampaknya pilihan terbaik dan menawarkan dukungan 10 tahun
    Hanya saja saya penasaran apakah pemeliharaannya benar-benar baik

    • Saya juga menjalankan CentOS di server selama lebih dari 10 tahun dengan harapan stabilitas jangka panjang dan ketenangan pikiran
      Namun setelah periode sepanjang itu, ekosistemnya sangat banyak drift, dan makin sulit menjaga aplikasi di atas OS tersebut tetap terbaru dan berjalan
      Paket infrastruktur seperti glibc, kombinasi Python/Apache, dan GCC perlahan jadi tidak lagi cocok dengan stack aplikasi modern
      Upgrade versinya setelah itu juga menyakitkan, bukan hanya karena saya memojokkan diri dengan campuran paket aneh, tetapi juga karena jalur upgrade-nya sendiri memang selalu sebatas best effort
      Saya rasa saya menyerah saat hendak pindah dari 6 ke 7, dan akhirnya sadar bahwa yang saya butuhkan adalah Fedora
      Dengan update setiap setahun atau setengah tahun, tidak perlu bertarung dengan paket distribusi, konfigurasi tetap modern dan berfungsi, upgrade distribusi besar juga mulus, dan downtime minim
      Saya tidak berniat kembali lagi ke “distribusi server”
    • Alma sekarang tidak lagi kompatibel source dengan RHEL, jadi ada sedikit kelonggaran
      Misalnya, mereka bisa merilis update kernel untuk memperbaiki kerentanan eskalasi privilese lebih cepat
      Rocky menanggapinya dengan repositori keamanan opsional yang menyediakan mitigasi exploit sambil menunggu turunan dari RHEL
      Jika melihat kejadian belakangan ini, keduanya tampak cukup terpelihara dengan baik
    • Saya tidak begitu paham alasan untuk tidak memakai rolling release distro di server pribadi
      Semua layanan dijalankan di kontainer, dan OS dasar dibiarkan auto-update sesering yang diperlukan
      Saya memilih openSUSE MicroOS, dan dengan update serta reboot hampir setiap hari, saya cukup yakin servernya sehat
      Karena update-nya atomik, kalau ada yang rusak dan saya tidak ingin menanganinya saat itu juga, cukup tekan tombol rollback di Cockpit dan lihat lagi nanti saat ada waktu
    • Itu sama saja bertaruh bahwa apa yang Anda host tidak akan hidup lebih lama daripada siklus upgrade
      Pada akhirnya saat upgrade itu datang, kemungkinan besar akan cukup menyakitkan
      Menurut saya lebih baik melakukan lompatan versi kecil lebih sering daripada satu lompatan besar setelah semuanya berubah total
    • Kalau ingin yang benar-benar gratis atau punya banyak mesin, Alma dan Rocky memang cocok
      Kalau Anda tidak keberatan mendaftar ke Red Hat, ada juga RHEL, yang memberi akses update gratis hingga 10 mesin per akun terdaftar
      RHEL jelas yang paling stabil di antara distribusi utama, dan Alma serta Rocky pada dasarnya adalah klon downstream dari RHEL

  • Saya juga berada di perahu yang sama
    Ada dua server tua yang saya biarkan terlalu lama sampai “terlalu” lama, dan sekarang saya takut menyentuhnya untuk update
    Namun melihat keributan distribusi Linux soal verifikasi/pembuktian usia, saya juga terpikir untuk pergi sepenuhnya
    Saya juga mencoba Artix, tetapi minggu lalu rusak setelah restart, dan sepertinya ada yang salah pada update kernel sebelumnya sehingga saya sampai harus mengeluarkan rescue ISO
    Karena itu perangkat tersebut saya ganti ke Devuan, tetapi saya masih menahan penilaian
    Tidak ada keluhan besar, tetapi masih dalam tahap burn-in
    Di laptop saya menjalankan Arch, tetapi komunitasnya terasa agak bermusuhan karena isu sensor, jadi saya menunggu ada waktu akhir pekan untuk menghapusnya dan memasang yang lain
    Saya tidak menginginkan drama politik dalam software
    Menariknya, ini pertama kalinya saya membeli laptop baru lalu langsung memasang Linux tanpa pernah sekali pun boot ke Windows, dan semuanya “langsung berjalan”
    Saat saya justru sedang bersemangat memakai Linux, sedih melihat pemain-pemain besar menerima langkah-langkah pengikisan privasi seperti AI di mana-mana, verifikasi/pembuktian usia, dan telemetri aktif secara default
    Untuk interaksi dengan hal-hal seperti itu, saya cenderung langsung berkata “tidak”

    • Dulu saya pernah membiarkan server Ubuntu selama 10 tahun lalu memperbaruinya dalam 20 menit tanpa rasa sakit
      Server itu bahkan sampai sekarang masih terus berjalan di LTS terbaru
      Saya bahkan tidak tahu apakah awalnya Ubuntu 4 atau 6, tetapi semuanya lancar saja
      Mungkin upgrade yang lambat justru membantu menghindari penderitaan para early adopter
      Sekarang saya jauh lebih sering memakai Debian
      Di tengah banyaknya serangan rantai pasok, Debian Stable benar-benar terasa seperti permata, dan meskipun ada beberapa paket yang harus saya tangani sendiri karena butuh versi lebih baru, saya menyukai semangat engineering lama yang sederhana itu
    • Soal verifikasi/pembuktian usia, saya rasa Anda tersesat oleh arah yang keliru
    • Kalau update kernel sebelumnya rusak lalu sistem gagal setelah restart, itu umumnya masalah khas Arch/Artix
      Keduanya memang yang paling cepat mengikuti arus terbaru, dan stabilitas tidak selalu jadi yang terbaik
      Tetapi rolling distro tidak berarti harus selalu menyediakan versi terbaru dari semua hal
      Selama beberapa bulan terakhir saya memakai Void Linux, dan walau ini rolling distro, ia memakai kernel LTS dan juga menyediakan mainline sebagai opsi, sementara para maintainer lebih fokus pada versi aplikasi yang stabil daripada update secepat mungkin
    • Server/VM saya biasanya menjalankan FreeBSD atau Alpine
      Ada sedikit Debian di tempat yang memerlukannya, misalnya Proxmox, VPS yang tidak mendukung Alpine, atau perangkat terkait pekerjaan
      Saya juga punya beberapa sistem uji yang menjalankan Chimera, tetapi saya tidak akan terlalu bergantung padanya sebelum rilis stabil tersedia
      Saya juga sedikit bereksperimen dengan AerynOS
    • Saya berharap siklus dukungan FreeBSD lebih panjang
      Masa dukungan rilisnya kurang dari 1 tahun, jadi jika melewatkan jendela upgrade, upgrade setelahnya menjadi lebih sulit dibanding distro lain seperti Debian Stable

  • Saya pindah ke Debian dan Ubuntu untuk server, tetapi saat masih muda di pertengahan 2000-an saya benar-benar tergila-gila pada FreeBSD
    Saya menghabiskan lebih banyak waktu untuk mengonfigurasi dan mengutak-atik daripada melakukan hal yang benar-benar berguna
    Saat itu sulit mencari dedicated server atau VPS yang menawarkan keluarga BSD, dan saya rasa akhirnya menetap di tempat seperti Panix.com
    Sebelumnya saya juga ingat ada perusahaan bernama 15MinuteServers, mungkin dulu NAC di New Jersey, yang menyediakan BSD
    Sekarang saya cuma sedang bernostalgia

    • Sekarang pemasangannya cukup mudah di provider saya
      Saya memakai FreeBSD di Hetzner dan OVH, dan dulu juga pernah memakai Vultr
    • OVH punya template FreeBSD
      Dan kebanyakan penyedia VM/VPS KVM mengizinkan akses konsol dan mounting ISO pengguna, jadi Anda bisa memasang apa pun yang diinginkan

  • Laporan fastfetch yang menunjukkan penggunaan memori lebih besar dari kenyataan kemungkinan besar karena ZFS ARC
    Ini mirip page cache di Linux, bisa direbut kembali kapan saja, dan tiap alat menamainya secara berbeda: https://www.linuxatemyram.com/

  • Saya ingat saat seseorang pertama kali menjelaskan Docker kepada saya, saya menjawab, “oh, maksudmu jail?”
    Seperti dijelaskan di artikelnya, itu tidak sepenuhnya sama
    kqueue juga kemenangan besar
    Saya benar-benar berterima kasih kepada para pengembang FreeBSD
    Saya menjalankan perusahaan pertama saya selama 15 tahun di atas FreeBSD, dan uptime serta ketahanannya luar biasa

  • Saya juga punya server Ubuntu 16.04 yang takut saya update
    Uptime saat ini 1281 hari, dan pada titik ini rasanya sayang untuk me-reboot-nya

    • Anda bisa menyalin filesystem ke mesin lain dengan dd, lalu mem-boot-nya di emulator seperti qemu untuk latihan percobaan
      Hati-hati jika ada sesuatu yang otomatis berjalan lalu mencoba terhubung ke luar
    • Saya tidak tahu apa yang ditakutkan
      Bukankah Anda punya backup?
      Sistem Debian/Ubuntu cukup mudah diatur agar melakukan auto-update dan reboot teratur, sehingga pemeliharaan manual hanya tersisa untuk upgrade versi besar
    • Server tertua saya ada di 8.04