Blogu Ubuntu 16.04 üzerinde 10 yıl çalıştırdıktan sonra FreeBSD'ye taşıdım

(crocidb.com)

1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş

Ubuntu 16.04 LTS tabanlı DigitalOcean VPS, destek sonu ve güvenlik yükü taşıyordu ama hizmetten kaldırılana kadar 1491 gün uptime korudu
Yeni sunucu Almanya’daki Hetzner VPS ve FreeBSD 14.3’e taşındı; önceki aylık $13’lük sunucudan daha güçlü özellikler aylık 6 euronun altında kullanılmaya başlandı
Jails ve Bastille ile site bazında yalıtılmış ortamlar kuruldu; Caddy Jail, SSL ve reverse proxy işini üstlenip trafiği ilgili nginx Jail’lerine iletiyor
Yük testlerinde yeni FreeBSD sunucusu, 10.000 eşzamanlı bağlantı için kern.ipc.somaxconn ayarlandıktan sonra istek işleme kapasitesinde 3 ila 11 kat daha yüksek sonuç verdi
Geçiş için ağ yönetimi ve FreeBSD yapılandırmasını öğrenmek gerekti ama merkezi yapılandırma ve belgelerin kalitesi sayesinde kurulum beklenenden daha kolay oldu

Geçişin arka planı

Mevcut blog, DigitalOcean VPS üzerinde 10 yıldan uzun süredir çalışıyordu ve New York veri merkezindeki Ubuntu 16.04 LTS kullanılıyordu
- Ubuntu 16.04 LTS’nin desteği en az 5 yıl önce sona ermişti ve apt paket deposu güncellemeleri artık alınamıyordu
- Eski sistemler güvenlik açısından dezavantajlıdır; geçmişte ayrı bir WordPress blogu, eski bir VPS üzerinde casino ve kumar bağlantısı ekleme saldırısına uğramıştı
Mevcut sunucu, blog dışında birkaç siteyi daha barındırıyordu ama bunların çoğu statik siteydi
- En popüler blog bile genelde ayda birkaç bin sayfa görüntüleme düzeyindeydi; yalnızca Hacker News’te bazı yazılar viral olduğunda trafik yükseliyordu
- Sunucu, statik dosyaları nginx/1.10.3 ile sunuyordu ve site bazlı ayarlar /etc/nginx/sites-available altında bulunuyordu
- Blog Hugo ile üretiliyordu; eski dağıtım süreci yerelde yazma → depoya commit ve push → sunucuya SSH ile bağlanma → depoyu pull etme → hugo çalıştırma şeklindeydi
Eski VPS başlangıçta test ve programlama amaçlı da kullanıldığı için üzerinde çok sayıda eski yazılım kalmıştı
- Buna rağmen düzgün çalışıyordu ve kapatıldığı andaki uptime 1491 gündü; yani yaklaşık 4 yıl yeniden başlatılmadan çalışmıştı
Yeni sunucu Almanya’daki Hetzner VPS’e taşındı; öncekiye göre daha güçlü donanım sunarken aylık maliyeti yarıdan da düşüktü
- Eski DigitalOcean sunucusunda 2 GB RAM, 1 vCPU, 50 GB disk, aylık 2 TB trafik vardı ve aylık ücreti $13’tü
- Hetzner’in en ucuz sunucusu bile eskisinin iki katı bellek ve CPU sunuyordu; depolama biraz daha azdı ama trafik limiti 10 kat fazlaydı
- Son seçilen Hetzner yapılandırması, aylık 6 eurodan ucuza daha güçlü özellikler sunuyordu

Neden FreeBSD seçildi

FreeBSD, yeni bir sistemi gerçek üretim ortamında denemek istendiği için seçildi
- Bütünleşik tasarım, kararlılık, güvenlik ve Jails başlıca avantajlar olarak görüldü
Jails, FreeBSD’de 25 yılı aşkın süredir bulunan bir sanallaştırma ve konteynerleştirme özelliği
- Ana sisteme erişemeyen “mini sistemler” sandbox benzeri şekilde çalıştırılabiliyor
- Docker benzeri konteyner çözümleri program paketleme için daha uygundur ve geçici/değişmez bir yapıya sahiptir; Jails ise aynı çekirdeği paylaşan alt sistemler veya mini VM’ler gibi ele alınır
ZFS de sunucu dosya sistemi olarak cazip bir seçimdi
- Veri bütünlüğü ve snapshot özellikleri sunuyor, Linux tarafındaki Btrfs ile benzer yönleri bulunuyor
- ZFS, Btrfs’e göre çok daha olgun kabul edildi; sık snapshot almak, VPS sağlayıcısının ücretli snapshot/yedek sistemlerine daha az bağımlı olmayı sağlayabilir
Hedef mimari, her site için bir Jail kurup her birinin içine gerekli derleme araçlarını ve nginx’i koymaktı
- Ana web sunucusu için bir Jail, dış dünyaya açık reverse proxy görevini üstlenecekti
- Belirli bir Jail ele geçirilirse, o Jail silinip yeniden oluşturulabilecek şekilde tasarım yapıldı

FreeBSD kurulumu ve Bastille kullanımı

Hetzner’in VM oluşturma ekranında varsayılan OS imajları sınırlıydı; BSD doğrudan görünmüyordu
- FreeBSD resmi YouTube kanalındaki Hetzner kurulum videosu referans alındı
- Hetzner, FreeBSD ISO imajı sağlıyordu ama bunun VM oluşturulduktan sonra konsoldaki ISO Images sekmesinden bağlanması gerekiyordu
- Kurulumda FreeBSD 14.3 ISO’su kullanıldı ve resmi videodaki kurulum akışı izlenerek sistem yapılandırıldı
Bastille, Jails yönetimini kolaylaştırmak için seçildi
- Elle Jail oluşturmak için gereken birçok adım bastille komutuyla yapılabiliyor
- Örnek komutlar bastille list, bastille create, bastille console
- Kurulum ve etkinleştirme, Bastille başlangıç belgesi temel alınarak yapıldı

pkg install bastille
sysrc bastille_enable="YES"

Ağ ve reverse proxy yapısı

Tüm yığın, tüm alan adlarını ve SSL sertifikalarını yöneten tek bir Caddy Jail ile site bazlı Jail’lere reverse proxy yapan bir yapıdan oluşuyor
- Her site Jail’i, siteyi derlemek ve sunmak için gereken araçları içeriyor
- Bu yapı, aynı ağ içindeki birden fazla sanal makineye benzetilebilir
Dahili sanal ağ arayüzü bastille0 olarak oluşturuldu

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"

Loopback arayüzü kopyalanıp bastille0 adı verildi ve 10.0.0.1/24 ağı atandı
Jail’ler bu ağ arayüzü üzerinde çalışıyor
Dışarıdan gelen HTTP ve HTTPS istekleri PF(Packet Filter) kurallarıyla Caddy Jail’e yönlendiriliyor
- /etc/pf.conf içinde dış arayüz vtnet0, iç arayüz bastille0 ve tailscale1 tanımlandı
- 80 ve 443 port trafiği, Caddy sunucusu olacak 10.0.0.5 adresine yönlendirildi

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 ve ağ geçidi şu komutlarla etkinleştirildi

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

Caddy ve site bazlı Jail kurulumu

Eski sunucuda uzun süredir nginx kullanılıyordu ama yeni yapıda SSL sertifika yönetimini otomatikleştirmek için Caddy seçildi
- Eski nginx ortamında sertifikalar certbot ile periyodik olarak yenilenmek zorundaydı ve bu yenileme birkaç kez kaçırılmıştı
Caddy Jail’i oluşturmadan önce FreeBSD sürümü Bastille’e bootstrap edildi

bastille bootstrap 14.3-RELEASE

Caddy Jail’i 10.0.0.5 IP’siyle oluşturuldu

bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy

Jail adı caddy, sürüm 14.3-RELEASE, arayüz bastille0
Çalışma durumu bastille list ile görülebiliyor, Jail içindeki shell’e bastille console caddy ile girilebiliyor
Caddy kurulumu ve servis etkinleştirmesi Jail içinde yapıldı

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

Caddy yapılandırma dosyası Jail içindeki /usr/local/etc/caddy/Caddyfile konumunda
- Yapılandırma dosyasını host üzerinden yönetmek için host dizini Jail içine mount edilebiliyor
- Örnekte nullfs ve salt okunur ro seçeneği kullanılarak Caddy’nin yapılandırmayı değiştirmesi engellendi

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

Sitelerin ve blogun dağıtımı

İlk dağıtılan site es.cro.to oldu ve site deposu GitHub deposu ile yönetiliyordu
- Depo host üzerindeki /usr/local/www/escroto içine kondu ve site Jail’ine bu dizin salt okunur olarak mount edildi
- Tüm siteler host üzerindeki /usr/local/www altında tutulacak şekilde düzenlendi
escroto Jail’i, nginx Bastille şablonuyla oluşturuldu

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

IP olarak 10.0.0.11 atandı
nginx varsayılan sayfası FreeBSD geleneğine uygun olarak /usr/local/www/nginx üzerinden sunuluyor
Host’taki site dizini Jail içine salt okunur olarak mount edildi

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

Deponun .git dizininin web üzerinden sunulmaması için bir dağıtım betiği kullanıldı

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

Yeni sürüm dağıtımı, host üzerinde deponun güncellenmesinden sonra Jail içindeki dağıtım betiğinin çalıştırılmasıyla yapılıyor

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

Caddy yapılandırması, cro.to alanını kalıcı olarak es.cro.to adresine yönlendiriyor ve es.cro.to için 10.0.0.11 adresine proxy yapıyor

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

Blog Hugo kullanıyor ve GitHub deposu ile yönetiliyor
- Depo host üzerindeki /usr/local/www/blog içine klonlandı
- blog Jail’i, escrotoya benzer şekilde oluşturuldu ve IP olarak 10.0.0.12 verildi

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, blog Jail’i içine kuruldu

bastille pkg blog update
bastille pkg blog install gohugo

Blog dağıtım betiği nginx web root’unu boşaltıyor ve Hugo çıktısını /usr/local/www/nginx altında üretiyor

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

DNS taşınmadan önce, yeni blog sunucusunu test etmek için eski alan adı yerine crocidb.cro.to bağlandı

crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

Benchmark ve yük testleri

DNS kayıtları değiştirilmeden önce, eski sunucu crocidb.com ile yeni sunucu crocidb.cro.tonun yük işleme kapasitesi karşılaştırıldı
- Blog ziyaretçileri çoğunlukla Kuzey Amerika’dan, ardından Avrupa ve Güney Amerika’dan geldiği için Almanya’daki yeni sunucunun gecikmesi bazı kullanıcılar için biraz daha yüksek olabilirdi
- Temel ilgi noktası, statik site sunma hızı ve yüksek yük altında dayanıklılıktı
GTMetrix, Pingdom, WebPageTest gibi ücretsiz çevrimiçi araçlar da kullanıldı ama iki sunucu arasındaki fark çoğunlukla gecikme düzeyindeydi
HTTP yük benchmark aracı olarak wrk ve hey kullanıldı
- Bu iki araç, büyük miktarda eşzamanlı istek üretip istek gecikmesi, hata yanıtları ve saniye başına aktarım miktarı gibi verileri topluyor
Aynı Hetzner üzerindeki başka bir VPS’ten wrk çalıştırıldığında yeni sunucu açık ara öndeydi

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

Seçenekler 4 thread, 100 eşzamanlı bağlantı ve 30 saniyelik çalışma süresiydi
Eski sunucuda ortalama gecikme 89.63ms, saniye başına istek 833.41, aktarım 8.29MB/s idi
Yeni sunucuda ortalama gecikme 6.75ms, saniye başına istek 12260.10, aktarım 130.80MB/s idi
Test makinesi yeni sunucuyla aynı veri merkezinde olduğu için tamamen adil bir karşılaştırma değildi
Proton VPN ile farklı bölgelerden wrk çalıştırma denemeleri de yapıldı ama sonuçlar beklenenden düşük çıktı
- Eski sunucu ortalaması saniyede yaklaşık 300 istek, yeni sunucu ortalaması ise yaklaşık 800 istek olarak kaydedildi
- Sonunda genel kullanıcı VPN’i yerine farklı bölgelerde gerçek VPS’ler kurma yaklaşımına geçildi

Vultr VPS ile bölgesel testler

DigitalOcean ve Hetzner’den farklı bir altyapı kullanmak için Vultr seçildi
- Elle çalışma yükü nedeniyle bölgeler London, São Paulo, Silicon Valley ve Tokyo ile sınırlandırıldı
- Her bölgede en ucuz Fedora VM oluşturulup testler çalıştırıldı
Son test aracı olarak heyin daha uygun olduğuna karar verildi

./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

Ayarlar toplam 1,000,000 istek, 10,000 eşzamanlı istek, 10 saniye zaman aşımı, toplam 5 dakika çalışma süresi ve HTTP/2 kullanımından oluşuyordu
Bu yük, gerçekçi bir blog trafiğinin çok üzerindeydi
İlk çalıştırmada yeni FreeBSD sunucusu 10.000 eşzamanlı bağlantıyı taşıyamadı ve başlangıçta başarısız oldu
- netstat -Lan ile socket queue boyutları kontrol edildiğinde hepsinin 128 olduğu görüldü
- Varsayılan kern.ipc.somaxconn değeri 128 olduğu için şu şekilde artırıldı

sysctl kern.ipc.somaxconn=16384

São Paulo testinde her iki sunucu da kayda değer sayıda hata döndürdü ama FreeBSD sunucusu beklenen 1,000,000 isteğe karşılık verebilirken Ubuntu sunucusu 20,000 isteği bile döndüremedi
- Eski Ubuntu sunucusu toplam isteklerin yaklaşık %7’sini tamamladı
- Yeni FreeBSD sunucusu ise yaklaşık %94’ünü tamamladı
- Tokyo’da yeni sunucunun başarı oranı biraz daha düşüktü ama bunun ciddi bir sorun düzeyinde olmadığı düşünüldü
Saniye başına istek sayısında yeni sunucu, eski sunucuya göre en az 3 kat, en fazla 11 kat daha iyiydi
- Gecikme yüzdeliklerinde yeni sunucu yaklaşık %90 seviyesine kadar daha lineer arttığı için daha öngörülebilir görünüyordu
- Yüksek yük altında bile, dünyanın çoğu bölgesinde blogun ana sayfa içeriği 3,5 saniyenin altında alınabiliyordu
Tokyo sonuçları ayrıntılı incelenmedi
- heyin istek aşaması analizinde Japonya yönüne giden trafiğin daha yavaş olabileceği görüldü
- İkinci alan adının DNS dial-up ve lookup değerleri anormal derecede düşük görünüyordu; bunun CNAME kaydıyla ilişkili olabileceği düşünüldü
- resp wait ve resp read değerleri de olağandışı derecede yüksekti; yalnızca başarılı istekler sayıldığı için eski sunucunun başlangıçta hızlı yanıt verip sonrasında yeni istekleri fiilen engellemiş olması mümkün görüldü

Son geçiş ve temel çıkarımlar

Benchmark’lar birçok soruyu tam yanıtlamasa da sonuçlardan memnun kalınarak DNS kayıtları yeni sunucuya geçirildi
- Bu blog artık resmen FreeBSD tabanlı Hetzner sunucusunda çalışıyor
FreeBSD ile site barındırma makinesi kurmak, saatlerce deneme, düzeltme, derleme ve başarısızlık içerse de beklenenden daha az karmaşıktı
- Gereksinimleri karşılayan bir web hosting hizmeti de kullanılabilirdi; örnek olarak OpenBSD Amsterdam verildi
- Proxmox ile konteynerler ve bir yönetim paneli de tercih edilebilirdi
- FreeBSD tarafındaki alternatiflerden biri olarak Sylve da anıldı
- Her şeyi doğrudan kurma yolu çok şey öğrettiği için tatmin edici bulundu
Eski Ubuntu sunucusu da son derece sağlamdı
- 10 yıl boyunca site yükünü iyi taşıdı ve son 4 yıl boyunca yeniden başlatılmadan çalıştı
- Yapılandırmaya çok büyük emek harcamadan da istikrarlı biçimde çalışabildi
FreeBSD yapılandırması beklenenden daha kolaydı; sistem ayarlarını tek yerde merkezileştiren yaklaşım ve çevrimiçi belgelerin kalitesi olumlu bulundu
Kendi blog barındırma makinesini kurmak, oyun geliştiricisinin normalde bildiği alanın ötesinde ağ bilgisi gerektiriyordu
- Farklı bir sistemi öğrenme süreci keyifli bulundu ve bir sonraki denemede OpenBSD ya da NetBSD de denenebilir
- Sonuç olarak, blog trafiğinin büyük bölümünün yapay zeka sistemlerinin crawling faaliyetlerinden gelmesi nedeniyle tüm bu işin pratik faydasının sınırlı olduğu not edildi

1 yorum

GN⁺ 3 시간 전

Hacker News yorumları

Yaptığım en büyük hata yüksek uptime oldu
arjie.com, Hetzner VPS üzerinde 10 yıldan uzun süre çalışınca, Hetzner alttaki makineyi kapatmak istediğinde gençlik yıllarımdaki halimin ne ayarladığını hiç bilmiyordum
Yedekler var ama site 10 yıldır kapalı
Artık taşınabilir olacak şekilde kuruyorum ve gerçekten birkaç kez taşıyıp çalıştığını doğruluyorum
- “En büyük hata yüksek uptime’dı” sözü doğru
  Eskiden makine uptime’ının bir onur nişanı gibi görüldüğü zamanları da hatırlıyorum
  Sadece yaşlandım, pek de daha bilge olmadım ama artık servis uptime’ına bakıyorum
  Eskiden MX gibi DNS kayıtları da buna yakın bir amaca hizmet ediyordu; eski cluster yapıları epey anlaşılmazdı ama split brain gibi dersler kaldı, bu yüzden bugün bile Proxmox 2 düğümlü cluster’ın neden bozulduğunu, neden ek bir witness önerildiğini açıklamaya devam ediyorum
  VMware’in geçmişte 2 düğümlü HA cluster sorununu büyük bir geçici çözümle örtmesi de yanlıştı; o yaklaşım hâlâ yaşıyorsa muhtemelen bugün de yanlıştır
  Yüksek uptime, patch yapılmadığı anlamına gelir; patch yapmak da herkesin en sevdiği iştir
- Bu bana Japonya’daki Ise Grand Shrine’ı hatırlatıyor
  Her 20 yılda bir tamamen sökülüp yeniden yapılıyor; yakın zamanda okuduğum Dan Wang’in Breakneck kitabında, bu yeniden inşa geleneğinin zamanla yok olacak bilgiyi koruduğu anlatılıyor
  Wang, Ise Grand Shrine ile Notre Dame’ı karşılaştırıyor; Notre Dame çatısını yeniden yapmanın bu kadar zor olmasının nedenlerinden biri de bilgi kaybı olabilir diyor
  İki yapıya da yeterince hâkim olmadığım için bunun adil bir karşılaştırma olup olmadığını bilmiyorum ama ilkenin kendisini seviyorum
  Kitapta küçük bir benzetme sadece; genel olarak ise güçlü şekilde tavsiye ederim
- VM üzerinde yüksek uptime çok da anlamlı değil
  Yeniden başlatma birkaç saniye sürüyor ve upgrade işlemi yeni bir instance’a sadece DNS’i çevirerek kesintisiz yapılabiliyor
  Kolay kopyalanamayan fiziksel makinelerde durum farklı
- Ayarları büyük bir Ansible playbook deposuna koymaya başladım
  Her şeyi Ansible ile tamamen yönetmek gerekmiyor; daha çok ilk kurulum ayarlarını orada tutuyorum ve hâlâ elle yönettiğim çok şey var
- Kişisel projelerde bile bazen Architectural Decision Records bırakıyorum
  Biraz komik hissettiriyor ama beklediğimden daha sık işe yarıyor
Kişisel/hobi kullanımı için çoğunlukla Caddy önde + Docker Compose kombinasyonuyla çalıştırıyorum
Basit web sitesi ise Caddy içeriği doğrudan servis ediyor; “web uygulaması” ise neredeyse hepsini container içine alıp Caddy’ye TLS sonlandırma ve Docker altındaki uygulamaya reverse proxy işini veriyorum
Genelde yapı ~/apps/appname şeklinde; her uygulama dizininde Docker Compose dosyası ve mount edilmiş veri dizinleri bulunuyor
compose down sonrasında veriyi (s)ftp ile çekip uzun süreli saklayabiliyor ya da siteyi/hizmeti taşıyabiliyorum
Bir zamanlar dedicated server üzerinde birden çok VM çalıştırıyordum ama OVH’nin ayrı VPS’lerine geçtim; ayrıca OVH’de mail çalıştıracaksanız mail hosting’e izin vermeyen local zone VM’lerden kaçınmak gerekiyor
Ortama göre değişebilir
- Bir projede Traefik kullanmaya başladım ve nginx proxy manager’a göre iyi bir yükseltme oldu
  NPM de harika ve web GUI’si de iyi ama Traefik’te tek yapmanız gereken Docker Compose dosyasına istediğiniz davranışı yazmak
- Ev kurulumum da benzer
  Sadece container’ları Unraid çalıştırıyor ve onlardan biri diğer servisler için reverse proxy olması amaçlanan nginx türevi bir araç
- Ben de neredeyse aynı şeyi yapıyorum
  Debian’dan, Flatcar gibi container öncelikli ve immutable sistem/OS tarafına geçmeyi düşünüyorum
  FreeBSD’nin ilginç teknik avantajları var ama iyi ya da kötü, pek çok açık kaynak yazılımın varsayılanı Docker ve her şeyi FreeBSD jail’lerine taşımak için ne zamanım ne de isteğim var
Birkaç hafta önce ben de aynısını yaptım
Sunucu yaklaşık 2015’ten beri güncellenmemişti ve o dönemden kalma Ghost blog ile node 0.10 kuruluydu
Ben biraz daha sert bir yol izledim; sadece yedek aldım ve Hermes agent’ı (Gemini 3.1 Pro) saldım
Gerekli tüm upgrade ve patch’leri yaptı, sonra da güncel karşılıklarına migration gerçekleştirdi
Ardından sunucu hardening ve kullanılmayan servislerin kaldırılması da epey ilerledi; AI desteği olmasaydı muhtemelen bunu sürekli ertelerdim
- AI olmadan da update’in kendisi aslında çok kolay
  Asıl sorun bir şeylerin bozulma riski ve bunu da yedekler hafifletiyor
Kişisel sunucuda FreeBSD kullanmak keyifliydi
Havalı, temiz, sade ve “punk rock” gibi bir hissi vardı
Ama temel birkaç can sıkıcı nokta yüzünden bıraktım: PM2’nin FreeBSD’de bug’ları vardı ve süreç yönetimi için onu kullanıyordum; alternatif olarak rc.d ile daemon çalıştırmayı denedim ama log ayarlamak çok zordu; firewall tarafında ise ICMP’yi nasıl ele alacağınız gibi güvenlik en iyi uygulamalarına kadar her şeyi elle ayarlamak gerekiyordu ve UFW varsayılanları gibi şablonları özledim
- FreeBSD’de de bu tür varsayılan şablonlar var
  PF ile değil, IPFW ile uygulanıyor
  rc.conf içindeki firewall_type anahtarına bakın: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
  Tek bir makine için firewall’ı kolayca yapılandırmak adına firewall_type=client, bir şey host edecekseniz firewall_type=workstation kullanabilirsiniz
  İkinci durumda firewall_myservices ve firewall_allowservices, hangi portların açılacağını ve hangi ağ/IP’lerin erişebileceğini kontrol eder
  Çok basit bir NAT gateway için firewall_type=simple ve firewall_simple_(iif|inet|oif|onet)(_ipv6)? ile ISS tarafı/iç taraf arayüz adlarını ve IPv4/IPv6 ağ aralıklarını ayarlamak yeterlidir
  Her seçeneğin tam olarak ne yaptığını /etc/rc.firewall içinde görebilirsiniz: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
- PM2’yi supervision amacıyla mı kullandığını merak ettim
  rc.d daemon log’ları için Unix usulü olarak basit mesajlarda logger(1) kullanılabilir; dosyaya yönlendirip boyutu da newsyslog(8) ile yönetebilirsiniz
  Firewall için The Book of PF[0] kitabını öneririm
  FreeBSD’deki PF, OpenBSD’nin pf’sinden sözdizimi olarak farklı ama firewall’ın nasıl çalıştığını kavramak ve hangi kuralları yazmanız gerektiğini anlamak için yeterli
  [0]: https://nostarch.com/book-of-pf-4e
- PM2, hangi OS üzerinde kullanırsanız kullanın hep bug’lıydı
  Başta inanılmaz kullanışlı geliyor ama aynı anda kullanması rahatsız edici bir yazılımdı; deploy sırasında environment variable güncellemesi de bir kez bile istediğim gibi çalışmadı
- Benim asıl sıkıntım elektrik kesintisinden sonra toparlanamamasıydı
  Elektrik gidince yeniden açılışta dosya sistemine elle fsck çalıştırmamı istiyordu
Biraz farklı bir konu ama şu anda destek süresi en uzun olan ücretsiz Linux dağıtımı hangisi merak ediyorum
Uzun süre küçük VM’lerde CentOS 7 kullandım; güvenlik güncellemeleri çok uzun süre geldi ve update yüzünden bir şeylerin bozulma riski de en aza inmişti
Biraz araştırınca şu an Alma/Rocky Linux’un en iyi seçenek gibi göründüğünü ve 10 yıl destek sunduğunu gördüm
Ama iyi korunup korunmadıklarını merak ediyorum
- Ben de 10 yıldan uzun vadeli istikrar ve iç huzuru umuduyla sunucularda CentOS çalıştırdım
  Ama bu kadar uzun süre geçince ekosistem ciddi biçimde drift ediyor ve OS üstünde uygulamaları güncel tutup çalıştırmak giderek zorlaşıyor
  glibc, Python/Apache kombinasyonları, GCC gibi altyapı paketleri modern uygulama stack’leriyle yavaş yavaş uyumsuz hâle geliyor
  Sonraki sürüm yükseltmeleri de acı vericiydi; sadece garip paket karışımlarıyla kendimi köşeye sıkıştırdığım için değil, upgrade yolunun kendisi de hep “best effort” düzeyindeydi
  Sanırım 6’dan 7’ye geçerken pes etmiştim ve sonunda bana gerekenin Fedora olduğunu fark ettim
  Yıllık ya da altı aylık güncellemelerde dağıtım paketleriyle boğuşmak gerekmiyor; yapı güncel kalıyor, çalışıyor, büyük dağıtım sürüm geçişleri de sorunsuz oluyor ve downtime da minimum kalıyor
  Bir daha asla bir “server distro”ya dönmeyi düşünmüyorum
- Alma artık RHEL kaynak uyumlu değil, bu da biraz hareket alanı sağlıyor
  Örneğin yetki yükseltme açığı için kernel update’lerini daha hızlı yayımlayabiliyor
  Rocky ise RHEL’den düşmesini beklerken exploit azaltımı sunan isteğe bağlı bir güvenlik deposuyla karşılık verdi
  Yakın dönem örneklerine bakınca ikisi de oldukça iyi bakılıyor gibi görünüyor
- Kişisel sunucuda rolling release distro kullanmamak için iyi bir neden göremiyorum
  Tüm servisleri container içinde çalıştırırsınız, taban OS’nin de gerektiği kadar sık otomatik update almasına izin verirsiniz
  Ben openSUSE MicroOS seçtim; neredeyse her gün update ve reboot olduğu için sunucunun sağlıklı olduğundan oldukça emin olabiliyorum
  Atomic update sayesinde bir şey bozulursa ve hemen uğraşmak istemezsem Cockpit’te rollback düğmesine basıp sonra bakıyorum
- Barındırdığınız şeyin upgrade döngüsünden daha uzun yaşamayacağına bahis oynuyorsunuz
  Sonunda upgrade geldiğinde bunun oldukça sancılı olma ihtimali yüksek
  Uzun zaman geçip her şey değiştikten sonra büyük bir sıçrama yapmak yerine, daha küçük sürüm sıçramalarını daha sık yapmanın daha iyi olduğunu düşünüyorum
- Tamamen ücretsiz istiyorsanız ya da çok sayıda makineniz varsa Alma ve Rocky doğru seçim
  Red Hat’e kayıt olmaktan çekinmiyorsanız RHEL de var; kayıtlı hesap başına 10 makineye kadar update erişimini ücretsiz veriyor
  RHEL kesinlikle büyük dağıtımlar arasında en istikrarlısı ve Alma ile Rocky özünde RHEL’in downstream klonları
Ben de aynı durumdayım
“Fazla” uzun süre bırakılmış, artık update etmeye korktuğum iki eski sunucum var
Ama Linux dağıtımlarının yaş doğrulama/kanıtlama tarafında çıkardığı tantanayı görünce tamamen terk etmeyi bile düşünüyorum
Artix’i de denedim ama geçen hafta yeniden başladıktan sonra bozuldu; önceki kernel update’inde bir şeyler ters gitmiş gibi görünüyordu, rescue ISO çıkarmak zorunda kaldım
Bu yüzden o cihazı Devuan’a çevirdim ama henüz karar vermek için erken
Büyük bir şikâyetim yok ama hâlâ burn-in aşamasında
Dizüstünde Arch kullanıyorum ama topluluk sansür meseleleri yüzünden biraz düşmanca geliyor; hafta sonu zaman bulunca silip başka bir şey kurmayı planlıyorum
Yazılımda politik drama istemiyorum
İlginç olan şu ki, bu yeni dizüstü alıp Windows’u bir kez bile açmadan doğrudan Linux kurduğum ilk örnek oldu ve her şey “öylece çalıştı”
Tam Linux’tan keyif almaya başlamışken büyük oyuncuların her yerde AI, yaş kanıtı/doğrulaması ve varsayılan açık telemetry gibi mahremiyet aşındırıcı adımları benimsemesi üzücü
Bu tür şeylerle etkileşimim sadece “nope” olacak
- Bir zamanlar Ubuntu sunucusunu 10 yıl boyunca bırakıp sonra 20 dakikada acısız şekilde update etmiştim
  O sunucu şu anda da en güncel LTS ile çalışmaya devam ediyor
  Ubuntu 4 müydü 6 mıydı hatırlamıyorum ama hep sorunsuzdu
  Belki de yavaş upgrade, erken benimseyenlerin çektiği sıkıntıları atlatmamı sağlamıştır
  Bugünlerde Debian’ı çok daha fazla kullanıyorum
  Bu kadar çok tedarik zinciri saldırısının olduğu bir dönemde Debian Stable gerçekten bir mücevher; daha yeni sürüm gerektiği için ayrıca ilgilenmem gereken birkaç paket olsa bile, onun eski usul sade mühendislik ruhunu seviyorum
- Yaş doğrulama/kanıtlama konusunda yanlış yönlendirilmiş gibi görünüyorsun
- Önceki kernel update’inin bozulup yeniden başlatma sonrası sistemi kırması büyük ölçüde Arch/Artix tarafının bir sorunu
  İkisi de en yeni akımı en hızlı takip edenlerden ve istikrar için her zaman en iyi seçenek değiller
  Ama rolling dağıtım demek her zaman her şeyin en son sürümünü vermek zorunda demek değil
  Son birkaç aydır Void Linux kullanıyorum; rolling bir dağıtım ama LTS kernel kullanıyor, istenirse mainline da seçilebiliyor ve bakımcılar hızlı update’den çok uygulamaların istikrarlı sürümlerine odaklanıyor
- Sunucularım/VM’lerim genelde FreeBSD ya da Alpine çalıştırıyor
  Gereken yerlerde biraz Debian da var; örneğin Proxmox, Alpine desteklemeyen VPS’ler, işle ilgili ekipmanlar gibi
  Chimera çalıştıran birkaç test sistemi de var ama kararlı sürüm çıkana kadar ona fazla bel bağlamayı düşünmüyorum
  AerynOS ile de biraz deneme yapıyorum
- Keşke FreeBSD’nin destek döngüsü daha uzun olsa
  Sürümlerin destek ömrü 1 yıldan kısa olduğu için upgrade penceresini kaçırırsanız sonradan upgrade etmek Debian Stable gibi diğer dağıtımlardan daha zor olabiliyor
Sunucu tarafında Debian ve Ubuntu’ya geçtim ama gençliğimde, 2000’lerin ortasında FreeBSD hayranıydım
Gerçekten faydalı bir iş yapmaktan çok kurcalamaya ve ayar yapmaya zaman harcıyordum
O zamanlar BSD sunan dedicated server veya VPS bulmak zordu; galiba sonunda Panix.com gibi bir yerde karar kılmıştım
Ondan önce de New Jersey taraflarında NAC olan bir yerde 15MinuteServers adlı şirketin BSD sunduğunu hatırlıyorum
Artık sadece nostalji yapıyorum
- Bugünlerde sağlayıcılarımda kurulum oldukça kolay
  Hetzner ve OVH’de FreeBSD kullanıyorum; geçmişte Vultr de kullandım
- OVH’de FreeBSD template var
  Ayrıca çoğu KVM VM/VPS sağlayıcısı konsol erişimi ve kullanıcı ISO mount etme imkânı verdiği için istediğinizi kurabilirsiniz
fastfetch’in belleği gerçekte olduğundan fazla kullanılıyor göstermesi muhtemelen ZFS ARC yüzündendir
Linux’taki page cache gibi, gerektiğinde geri alınabilir ve araçlar buna farklı isimler verir: https://www.linuxatemyram.com/
Birinin bana Docker’ı ilk anlattığında “aa, jail’den mi bahsediyorsun?” diye cevap verdiğimi hatırlıyorum
Yazının da anlattığı gibi tamamen aynı şey değil
kqueue da büyük bir kazançtı
FreeBSD geliştiricilerine gerçekten minnettarım
İlk şirketimi 15 yıl boyunca FreeBSD üzerinde işlettim; uptime ve dayanıklılığı inanılmazdı
Benim de update etmeye korktuğum bir Ubuntu 16.04 sunucum var
Şu an uptime 1281 gün ve bu noktada reboot atmaya kıyamıyorum
- Dosya sistemini başka bir makineye dd ile kopyalayıp qemu gibi bir emülatörde boot ederek prova yapabilirsiniz
  Otomatik başlayan ve dışarı bağlantı kuran bir şey varsa dikkatli olun
- Neden korktuğunu anlamıyorum
  Yedeğin yok mu?
  Debian/Ubuntu sistemleri düzenli otomatik update ve reboot yapacak şekilde kolayca ayarlanabiliyor; böylece elde sadece büyük sürüm upgrade’leri için manuel bakım kalıyor
- Benim en eski sunucum 8.04 üzerinde

Blogu Ubuntu 16.04 üzerinde 10 yıl çalıştırdıktan sonra FreeBSD'ye taşıdım

Geçişin arka planı

Neden FreeBSD seçildi

FreeBSD kurulumu ve Bastille kullanımı

Ağ ve reverse proxy yapısı

Caddy ve site bazlı Jail kurulumu

Sitelerin ve blogun dağıtımı

Benchmark ve yük testleri

Vultr VPS ile bölgesel testler

Son geçiş ve temel çıkarımlar

İlgili okumalar

1 yorum

Hacker News yorumları