OpenBSD alapú webszerver
Magyarországon a webszerverek egyik legelterjedtebb operációs rendszere a Linux, amely számos előnnyel kecsegtet, jó a szoftveres ellátottsága, könnyű rendszergazdát találni a karbantartási feladatok elvégzésére és így tovább. Ebben az írásban szeretném bemutatni az OpenBSD-t mint alternatívát, mely filozófiájával inspirációt nyújthat a webes fejlesztéshez, és akár komolyabb projektek stabil alapjául is szolgálhat.
Biztonság
Az OpenBSD fejlesztői számára a legmagasabb prioritást a biztonságos működés jelenti, a fejlesztők állítása szerint 1997 óta csak két távolról kihasználható hibát fedeztek fel a rendszerükben. Rengeteg időt fordítanak a forráskódok auditálására, valamint az API-t is kiegészítették olyan függvényekkel, amelyek eredetijét (például az strcat()
és az strcpy()
) a programozók sokszor rosszul használják, potenciálist rést hagyva a kódban.
A „security by obscurity” mint pszichikai tényező is mellettünk van, azaz mivel kevesen ismerik, kevesen is foglalkoznak a rendszer törésével. A hackerek által használt exploit adatbázisok is üresen konganak, ha OpenBSD-re keresünk, a legfrissebb találatuk is 5-6 éves. Természetesen nem szabad elfelejteni, hogy a teljes biztonságot mindig a leggyengébb lánccszem határozza meg, azaz az operációs rendszerünk hiába stabil, mint egy atombunker, ha például egy rosszul megvalósított fájlfeltöltéssel tetszőleges kódot engedünk futtatni a gépen.
Külön említést érdemel a beépített hálózati csomagszűrő, a PF (Packet Filter), amely a programot ismerő rendszergazdák állítása szerint sokkal jobban és rugalmasabban használható, mint a Linuxok hasonló megoldásai, mint például az iptables.
A készítők hasonlóan ügyelnek a felhasznált szolgáltatásaik licencelésére, csak olyan programokat tesznek elérhetővé például a csomagkezelőjükben, amelyek, amelyek megfelelnek a BSD feltételeinek. Amennyiben egy fontos komponens nem használható ilyen feltételekkel, sokszor inkább a nulláról újraírják az egészet, hogy ne legyenek belőle később problémák, ilyen például az OpenSSH, amit azóta néhány Linux disztribúció is átvett. Az OpenBSD néhány területen úttörőnek számít, az elsők között támogatták például az SSD meghajtókat, valamint a wifi eszközöket.
Webszerver
Magáról a rendszerről látszik, hogy programozók kezében van, mentes mindenféle sallangtól, a marketinget hírből sem ismerik. Szerencsére azért foglalkoznak a használhatósággal, a legutóbbi, 2011 novemberében megjelent 5.0-s változat telepítője továbbra is karakteres, de gyakorlatilag olyan egyszerű, mint a legmodernebb operációs rendszereké, csak kattintás helyett entereket kell nyomogatni. Mivel alapvetően kicsi, legfeljebb öt perc alatt felszalad a lemezre, fejlesztői eszközök (gcc, make és társaik) nélkül 200, velük pedig 250 megabájt a mérete. A mai időkben ugyancsak viccesnek hat, hogy indítás után SSH-val és webszerverrel az aktív memóriafoglalása 10 megabájt alatt van.
Az OpenBSD beépítve tartalmaz egy Apache webszervert, ami licencelési problémák miatt csak 1.3-as verziójú (a 2.0 feltételeit nem tartották elfogadhatónak), de saját patch-eikkel jóval biztonságosabb, mint az eredeti, valamint beépítettek olyan funkciókat, ami a kettesben elérhető, mint például az IPv6 támogatás. Tapasztalataim szerint sebességben hozza a 2.0 szintjét, néha gyorsabb is nála. A tervek szerint a készítők hamarosan az nginx-et teszik alapértelmezetté, amely szerintük modernebb és rugalmasabb, mint a konkurensei.
Az operációs rendszer beépített csomagkezelővel érkezik, így a szoftvertelepítés ugyanolyan kényelmes, mint azt máshol megszokhattuk. Tapasztalataim szerint a csomagok valamennyivel alacsonyabb alverziószámmal érhetőek el, mint a hasonló időben kiadott Linuxokon, de ebből még nem származott probléma. A népszerű programok mind megtalálhatóak a kb. 7000-es csomaglistában, a különféle programozási nyelvektől (Lua 5.1, PHP 5.3.6, NodeJS 0.4.9) az adatbáziskezelőkön át (MySQL 5.1.49, MongoDB 1.8.2) az ablakkezelőkig (KDE 3.5). Ezen felül használhatjuk a BSD-kben megszokott port rendszert is, aminek a segítségével az operációs rendszerhez finomhangolt forráskódokat fordíthatjuk le. Természetesen lehetőségünk van az adott szoftver legfrissebb változatát is fordítani, bár meg kell jegyeznem, hogy nagyon ritkán fordulhatnak elő kompatibilitási hibák, de ezek nem okoznak gondot annak, aki ilyen szinten jár.
Hátrányok
Fontos megemlíteni az OpenBSD hátrányait is. Ismeretlensége miatt nehezebb lehet rendszergazdát találni hozzá, bár fontos megjegyeznem, hogy ugyan vannak dialektusbeli eltérések egy Linuxhoz képest, de ezek nem nagyobbak, mint mondjuk az brit angol és az amerikai angol között, tehát alapvetően minden feladatot meg lehet rajta oldani.
Jogosan kritizálják többen a rendszert, hogy lassabb, mint a Linuxok, és ez sajnos valóban így van, méréseim szerint az eltérés 10-20%. Persze ilyenkor a kérdést feltehetjük: melyik a jobb, egy gyors, feltört szerver, vagy egy lassabb, de töretlen? Az OpenBSD esetében nyugodtak lehetünk, hogy legalább az alapok rendben vannak, onnan kevésbé fenyeget veszély.
Bár alapvetően sok hardverplatformot támogat, azok meglehetősen régiek és kevésbé elterjedtek, a modern és divatos, kis fogyasztású ARM és MIPS rendszereken akadályokba ütközhetünk.
Ajánló
Amennyiben sikerült felkeltenem az érdeklődést, javaslom az OpenBSD-t kipróbálásra, amit a legkönnyebben egy virtuális gép, például az Oracle VirtualBox segítségével tehetünk meg, egy alap játszadozáshoz bőven elég 256 megabájt memória és 2 gigabájt merevlemez, programfordításhoz pedig 768 megabájt RAM és 8-10 gigabájt lemezterület. Telepítésnél érdemes az alapértelmezetten felajánlott automatikus partícionálást választani.
■
Jó cikk
Köszönöm
Gentoo
Az utóbbi időben nekem
Nem annyira
Már megint negatív vagyok... :)
Erre kérhetnék valami konkrét példát?
Amit nekem "sikerült":
felrakok egy debiant/ubuntut, akkor
apt-get update
apt-get install ... - és települ a szükséges csomag
apt-get dist-upgrade - upgrade-eli az összes csomagot a legfrissebb, elérhető verzióra
apt-cache search ... - nem csak a csomag nevében keres, így viszonylag egyszerű megkeresni azt, amit szeretnék.
----
OpenBSD-n addig jutottam, hogy CD-ről telepítés után nekem kell keresnem egy mirrort, annak teljes útvonalát beállítani a PKG_PATH-ban, amit ha sikerül nem elírni, akkor pkg_add segítségével tudok belőle telepíteni, de...
Megpróbáltam felrakni egy mysql-t:
pkg_add mysql-server
Lehúzta a szükséges csomagokat, felrakta, majd közölte, hogy a /etc/rc.d alá berakott egy új scriptet, oszt jónapot.
Merő kíváncsiságból megpróbáltam a szokott módon indítani:
/etc/rc.d/mysqld start
Fél perc várakozás után kaptam egy helyes kis hibaüzenetet.
-----------
Mindezt ezen felbuzdulva:
bírtam elkövetni. :)
Attól tartok, az amerikai és a brit angol közti különbség közel sem akkora, mint a linux és az openBSD közti eltérés. ;)
Hátrányok közé beírnám még, hogy erősen fapados. (mondjuk engem csak a lustaság gátol, hogy mélyebben megismerjem, de azt nagyon nem javasolnám, hogy valaki linuxos ismeretek birtokában OpenBSD szervert kezdjen üzemeltetni... ehhez azért túl nagyok az eltérések)
Ja! Még valami: LVM mostanság egy majdnem szabványos dolog Linuxokon, HPUX-on és talán AIX-en is létező eszköz, ez mintha hiányozna a *BSD-kből. Ami van helyette, az nem tudom, rendelkezik-e hasonló tudással, mint az LVM.
Ha CD-ről telepítesz, akkor
A pkg_add segítségével lehet a frissítéseket is elvégezni - jóbarátunk a man : ) Egyébként szigorúak a fejlesztők a dokumentációval is, csak akkor kerülhet be új driver/parancs a rendszerbe, miután elkészítették hozzá a man leírást, továbbá a régieket is folyamatosan frissítik.
A MySQL csomag init scriptje valóban rossz, remélem, a májusban megjelenő 5.1-re javítják.
A fapadosságon egyébként mit értesz? A karakteres felületet, vagy pedig azt, hogy bizonyos feladatokat nehézkesebb megoldani, mint Linuxon?
Biztos vagy benne?
Nekem a pkg_info kizárólag azt listázza, amit a rendszer telepítése után pakoltam fel a pkg_add segítségével.
Ebből következően a kernelt, a default shellt (ksh), a különböző lib-eket stb. nem valószínű, hogy update-elné.
fapad alatt értem az olyan jellegű dolgokat, hogy linux alatt pl. a mysql eleve úgy kerül fel, hogy már van benne egy root user, megvannak az alaptáblák, a mysql nevű adatbázis stb. Ahogy elnézem, openbsd-n ezt a telepítés után még el kell játszani.
(nem néztem utána alaposabban, lehet, hogy van kulturáltabb megoldás is)
A rendszert nem a pkg_add
A MySQL-es dolognak, amit írtál, utána kell néznem, én már jóideje magamnak fordítom, és nem emlékszem a csomag ilyen problémáira.
A pontosabb megfogalmazás az
Mert pl. egy Gentoon nem kerül fel semmi a binárisokon kívül.
fullextrás LAMP / *BSDAMP?
Szerintem jó lenne egy ilyen. El tudom képzelni, hogy rendszergazdák ezrei csiszolgatják az alapfelhasználású konfigjaikat, apt-get update-elnek, dist-update-elnek és stb stb műveleteket végeznek, mind ugyanazt -- amikor lehetne úgy is, hogy mindez szinte automatikusan megtörténjen.
Valaki, profi szakértő központilag karban tartana egy csomagot, és teljes egészében ez a (szakmailag) igényesen fenntartott rendszer klónozható lenne akárhányfelé. Mondjuk csak néhány opciót kéne kiválasztani meg jelszavakat beirkálni egy felületre a telepítéskor, és máris működne, "önkarbantartana".
Nagy munka van belefektetve a linux, apache, mysql, php projektekbe, ehhez képest már csak egy kicsi kellene, hogy legyen egy szinkronizáló mechanizmus, egy jól átgondolt csomag, ami a legtöbb vason elfut, egy alapszoftver, ami a szokványos igényeket kielégíti, amit frissen tartanak egyszeri munkával és aztán fél-laikusok ezrei is képesek lehetnének ennek segítségével kényelmesen, biztonságosan webszervert üzemeltetni.
Ilyen miért nincs?
Nem lehetséges ilyet csinálni?
(Tudom, megvannak a hátrányai, pl. egy még fel nem tárt sebezhetőséggel az összes ilyen klón megzavarható lenne, de egyrészt egy jól kialakított rendszerben ez ritka, az automatizmus miatt a patch-ek gyorsan javíthatnák a hibákat mindenhol, másrészt még mindig lehetne mást választani, aki szakértő és nem egyenszervert akar.)
Az automatikusan települő
Sohasem tudhatod, hogy mikor jön egy olyan frissítés, ami (legyünk optimisták) inkompatibilis a rajta futó applikációk valamelyikével.
(ezt nagyon megjegyeztem, amikor valami java alverzió váltással sikerült megfektetni az egyik legnagyobb rendszerünket :) )
ok, de
1: Ugye, profi dologról van szó, tehát ilyesmire ügyelnek, tesztelnek az update előtt. Mielőtt jönne update, mindenkit figyelmeztetnek ("5 nap múlva update, ezmegez lesz benne"), ha valamilyen gondot okozhat, akkor arra is figyelmeztetnek, hogy legyen időd átállni. A hibajavító patch-ek ritkán okoznak kompatibilitási gondot.
2: Lehessen késleltetni az update-et, vagy kézire állítani. Ilyenkor gyűjtheti a rendszer, hogy mi maradt ki, aztán egy gombnyomással fel lehet a maradékot rakni.
Tehát nem rögtön akkor küldik el a pakknak az update-et, amikor kijön mondjuk a MySQl vagy a PHP frissítés, hanem akkor, amikor egyébként is feltennék egy éles rendszerbe.
Mondjuk van a Szaki Péter, aki LAMP-os üzemeltető, ő csinálja a "fullextraLAMP" disztrót is, és látja, hogy jött egy PHP frissítés. Nem ész nélkül rakja fel, hanem megnézi hogy mi az. Felteszi egy tesztrendszerben, utánanéz a neten, stb, látja, hogy ilyenmegilyen esetben gond lehet.
De ígymegígy megoldható. Kirakja a "fullextraLAMP" RSS-be, hogy "5 nap múlva PHP frissítés, erre figyeljetek, így javítsatok a PHP kódban".
Aztán, 5 nap múlva, amikor ő is kirakná az éles rendszerébe a frissítést, feltölti a változtatásokat a "fullextraLAMP" elosztószerverére is.
Pont egy ilyen hibajavító
Egyszerűen az van, hogy körültekintő tesztelés nélkül nem szabad kirakni egyetlen update-et sem, ha fontos az alkalmazásod működőképessége.
igazad van
Szerintem azért nincs ilyen,
A témához meg: érdekes volt olvasni, köszi HG :) Szerintem előbb-utóbb mindenki megtalálja a legjobban kezére álló rendszert, és megfelelő ismerettel úgyis abból tudja kihozni a legjobbat, amit mélyen megismert. Legyen az BSD, gentoo, debian, red hat stb. És biztos, hogy mindenkinek vannak rémálom történetei a többivel (is) :)
én kipróbálnám
Ha valakinek LAMP kell, és kicsi, akkor shared hostingot választ.
Viszont mostanában láttam hogy a linode nagyon nyomul és nem is olyan drága már a virtuális szerver egyébként sem. Én is kipróbálnám, de (bár van egy alap rálátásom a dologra) nem bízom magamban annyira, hogy egy webszervert üzemeltessek a wadnyugaton. Arra meg nincs pénzem (nem éri meg) hogy egy (másik) szakértővel üzemeltettessem a webszerveremet.
Szóval ha ilyen olcsó lesz a VPS, akkor több igény is lesz rá, mert több ilyen félláma, mint én, fog elgondolkodni rajta. ;-)
(szerintem az ilyen VPS-eken tömegével futnak az ugyanolyanra konfigolt LAMPok)
Egyszerű dolgokra persze elég
Felhasználói szint?
Addig is, míg valaki nálam
A PHP kiterjesztésekről nem mernék biztosan nyilatkozni, ami PHP-ben íródott, az gyanítom, gond nélkül megy. Ami nem... OpenBSD-t nem tudom, FreeBSD-ben van linux emuláció, amivel linuxos programokat is lehet futtatni, talán működik OpenBSD-n is.
Ami viszont gázos lehet, pl. nekem is: nincs hozzá virtualbox guest additions...
A jogosultságok, parancsok
A PHP-hez ugyancsak elérhető az összes elterjedt könyvtár, tehát összeállítható az elterjedt Linuxokhoz képest 99%-ban megegyező környezet (olyan eltérések lehetnek, hogy a webszerver nem daemon-ként, hanem www-data csoportban fut stb.).
Szerintem az OpenBSD legcélszerűbb felhasználási módja a frontvonalakon van, a fenti leírásomban is említett Packet Filter (PF) nem csak tűzfalként szolgál, hanem például terheléselosztásra is kitűnően használható. A bejövő kapcsolatokat így kezelheti az OpenBSD, fut rajta egy webszerver és egy PHP, míg az adatbázisokat egy nagyteljesítményű Linux backend szolgálja ki. Emellett el tudom úgy is képzelni, mint önálló szolgáltatásszerver, mi például így tervezzük használni.
Jail
Jail
Hm. Akkor ennyivel biztosan.
(anno freebsd-n nézegettem a jailt, ott még nem volt alapértelmezetten belé pakolva semmi)
Mennyivel nehezebb egy
(nem lépésről-lépésre kérdem, csak a munka nagyságrendje érdekelne - telepítésekkel kb. 10 percembe került egy apache2-t chroot-ból indítani)
Vagy valamit félreértenék?
Nehezebb
Kicsit (nagyon) tovább
Lehet, hogy én kezdtem neki
Nagyobbik gond, hogy az openbsd jailről semmi konkrét infót nem találtam a google-n, csak chroot-os hivatkozásokat. FreeBSD-n találkoztam már vele, de az is rég volt.
(ugyanakkor pl. openbsd-n az elindított apache valóban nem látszik a processz táblában)
Lxc-ről még nem is hallottam, de így a leírásod alapján az a jail, amiről te beszélsz, az már (para?)virtualizációnak tűnik, nem valami chrootolt megoldásnak.
(főként a leválasztott hálózat miatt)
chroot, jail (openvz, lxc,
BSD kapcsan erdemes egy