ugrás a tartalomhoz

OpenBSD alapú webszerver

Hidvégi Gábor · 2012. Már. 7. (Sze), 17.55

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.

 
1

Jó cikk

janoszen · 2012. Már. 8. (Cs), 10.10
Nagyon jó cikk. A kollégám BSD-zik, én Gentoo Linuxozom. OpenVZ-vel közel azonos funkcionalitást sikerült elérni, viszont az én gépemre több embernek van bejárása, nem volt opció a nem Linux.
3

Köszönöm

Hidvégi Gábor · 2012. Már. 8. (Cs), 16.23
Szervernek te milyen Linuxot ajánlanál, és milyen szempontok alapján? Debiant szoktam használni, de csak azért, mert egy rendszergazda ismerősöm régen is ezt használta.
10

Gentoo

janoszen · 2012. Már. 9. (P), 10.03
En Gentoot hasznalok, mert azt tudom olyan szinten testre szabni, ahogy nekem kell. Csomagot csinalni hozza a legbonyolultabb esetben is kevesebb ido, mint Debiannal a legegyszerubb csomagot elkesziteni. Ellene szol, hogy igen csak erteni kell a Linux belso vilagat, mert nincs apt-get install, hanem el kell donteni, mint hogy forgatsz le.
15

Az utóbbi időben nekem

Hidvégi Gábor · 2012. Már. 9. (P), 10.25
Az utóbbi időben nekem meggyűlt a bajom az apt-get-tel telepített szoftverekkel, és azon a véleményen vagyok, hogy tisztább és szárazabb érzés magamnak fordítani amit csak lehet. Ami persze nem kevés idő, de közben úgyis tudok mással haladni a munkában.
24

Nem annyira

janoszen · 2012. Már. 9. (P), 16.52
Nekem van egy binhostom, ahol leforgatok mindent binaris csomagba, a tobbi gepre meg mar binarisbol megy fel.
2

Már megint negatív vagyok... :)

H.Z. v2 · 2012. Már. 8. (Cs), 15.57
így a szoftvertelepítés ugyanolyan kényelmes, mint azt máshol megszokhattuk.

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:
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

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

Ha CD-ről telepítesz, akkor

Hidvégi Gábor · 2012. Már. 8. (Cs), 16.26
Ha CD-ről telepítesz, akkor valóban kézzel kell megadni a tükörszerver útvonalát (5.0 előtt még netes telepítés esetén is), én helyből a netről szoktam (akkor megjegyzi), kétszer gyorsabb, mint a CD.

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.

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. ;)
Az amerikai angolon belül is vannak eltérések, lásd Harlem vagy Bronx ; )

A fapadosságon egyébként mit értesz? A karakteres felületet, vagy pedig azt, hogy bizonyos feladatokat nehézkesebb megoldani, mint Linuxon?
5

Biztos vagy benne?

H.Z. v2 · 2012. Már. 8. (Cs), 16.57
A pkg_add tuti, hogy minden frissítést megcsinál?
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)
6

A rendszert nem a pkg_add

Hidvégi Gábor · 2012. Már. 8. (Cs), 17.12
A rendszert nem a pkg_add segítségével kell frissíteni, hanem amikor kijön az új verzió, a telepítő ajánlja fel a lehetőséget.

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

A pontosabb megfogalmazás az

charlie_hu · 2012. Ápr. 8. (V), 11.34
A pontosabb megfogalmazás az lenne, hogy Debian alatt úgy kerül fel és nem Linux alatt.

Mert pl. egy Gentoon nem kerül fel semmi a binárisokon kívül.
16

fullextrás LAMP / *BSDAMP?

zzrek · 2012. Már. 9. (P), 10.26
A "fapados" kifejezésről jutott eszembe, hogy létezik-e (tudom: nem) olyan "fullexrás" linux csomag, amit direkt arra állítanak össze, hogy egy alap webkiszolgálóként működjön, és folyamatosan, akár automatikusan karban tartsa magát?

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.)
17

Az automatikusan települő

H.Z. v2 · 2012. Már. 9. (P), 10.36
Az automatikusan települő update, amit egy éles rendszeren célszerű azonnal kikapcsolni.
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 :) )
18

ok, de

zzrek · 2012. Már. 9. (P), 11.39
OK, de ez ugyanúgy lehet előre ütemezett alapú, körültekintéssel:
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.
20

Pont egy ilyen hibajavító

H.Z. v2 · 2012. Már. 9. (P), 11.59
Pont egy ilyen hibajavító patch hozott magával egy megváltozott algoritmust a java-ban (jdbc driverben? Már nem emlékszem pontosan), amin utána közel egy hónapig tököltek a fejlesztők, hogy valami használható workaroundot találjanak hozzá. És persze meg kellett találni, hogy tképp mi is történt, amitől a patch használhatatlanná lassította a rendszert (nem csupa hülyegyerekből álló fejlesztő gárdáról beszélek)
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.
22

igazad van

zzrek · 2012. Már. 9. (P), 13.47
Egyetértünk, csak én arról beszélek, hogy a körültekintő tesztelést elég lenne egyszer elvégezni egy "egyenkonfigon", aztán ha a konklúziók le vannak vonva, lehetne élesíteni a lámák szerverein.
19

Szerintem azért nincs ilyen,

BlaZe · 2012. Már. 9. (P), 11.52
Szerintem azért nincs ilyen, mert igazából nincs rá valós igény. Feldobsz egy akármilyen linux distribet és 3 parancs után ott dübörög a lamp. Akinek ez elég, be tudja írni azt a 3 sort. Akinek nem, annak meg úgyse tudná kielégíteni az igényeit egy ilyen lamp distrib, mert egy frontvonalon harcoló szerver ideális esetben nem default configgal fut. Még a legegyszerűbb kiszolgálók sem. A mélyvízben lévő clusteres, particionált táblás, shardinges stb összetett rendszerekről nem is beszélve.

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) :)
21

én kipróbálnám

zzrek · 2012. Már. 9. (P), 13.45
Bizonyára igazad van, ha lenne rá igény, akkor lenne is.
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)
23

Egyszerű dolgokra persze elég

BlaZe · 2012. Már. 9. (P), 15.48
Egyszerű dolgokra persze elég a default config, de arra ott van az apt-get install apache2 php mysql. Vagy ezek alternatívái a különböző distribekben. Aztán már megy is.
7

Felhasználói szint?

T.G · 2012. Már. 8. (Cs), 19.51
Amennyiben én csak hosztolni szeretnék tárhelyet, mondjuk a szokásos PHP, MySql párossal, akkor tapasztalnék bármi különbséget a Linux-os tárhelyekhez képest? (olyanokra gondolok, mint pl. Window, Linux összehasonlításnál a fájlok jogosultsága, a mappa szeperátor karakter) Illetve PHP-hez az összes elterjedt könyvtár, kiterjesztés megtalálható itt is?
8

Addig is, míg valaki nálam

H.Z. v2 · 2012. Már. 8. (Cs), 20.48
Addig is, míg valaki nálam hozzáértőbb előkerül: a "unix-like" rendszerek (BSD-k, linuxok, OS/X stb) mind /-t használnak mappa szeparátornak, az alap jogosultsági rendszerük is megegyezik egy bizonyos szintig (tehát míg egy fájlra rwx jogokat akarsz adni a tulajdonosnak, groupnak, othernek, addig egyformák - könyvtárak, spec. jogok esetében már lehetnek eltérések)
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...
9

A jogosultságok, parancsok

Hidvégi Gábor · 2012. Már. 9. (P), 09.53
A jogosultságok, parancsok meghívásának módja, és a nem op.rendszer specifikus parancsok megegyeznek (paraméterezésben viszont lehet eltérés).

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

Jail

janoszen · 2012. Már. 9. (P), 10.06
Annyi elonyod van, hogy tudsz jaileket csinalni, azaz hermetrikusan el tudod valasztani egymastol a felhasznaloidat. Ezt egyebkent Linux-szal is meg tudod csinalni, csak joval nehezebb.
12

Jail

Hidvégi Gábor · 2012. Már. 9. (P), 10.16
Apropó, elfelejtettem írni, hogy az OpenBSD beépített webszervere (most ugye az Apache, később az nginx) alapértelmezetten jail-ben, chrootolva érkezik, tehát a document root-on kívüli külső fájlrendszert nem lehet elérni mondjuk PHP-ből.
14

Hm. Akkor ennyivel biztosan.

H.Z. v2 · 2012. Már. 9. (P), 10.20
Hm. Akkor ennyivel biztosan. :)
(anno freebsd-n nézegettem a jailt, ott még nem volt alapértelmezetten belé pakolva semmi)
13

Mennyivel nehezebb egy

H.Z. v2 · 2012. Már. 9. (P), 10.18
Mennyivel nehezebb egy chroot-olt környezetet összedobni, mint egy jailt?
(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?
25

Nehezebb

janoszen · 2012. Már. 9. (P), 16.54
Defaultbol a Linuxos szoftvereknek ossze kell vadaszni a dependenyket (.so fileok) es frissiteni is maceras. Plusz a chroot nem valasztja le sem a PID namespacet, sem a halozatot. Az LXC illetve az OpenVZ mar sokkal kozelebb all a BSD jailhez, de nem default funkcionalitas.
26

Kicsit (nagyon) tovább

BlaZe · 2012. Már. 9. (P), 17.42
Kicsit (nagyon) tovább folytatva a gondolatsort, én szívesen olvasnék linux alapú virtualizációról cikket, cikksorozatot tapasztalt szakitól. Ha valaki törte ilyen írásán a fejét, akkor csak hajrá, van rá igény :)
27

Lehet, hogy én kezdtem neki

H.Z. v2 · 2012. Már. 9. (P), 17.45
Lehet, hogy én kezdtem neki rosszul, de szimplán debootstrap-pel csináltam meg a chrootolt környezetet.

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)
30

chroot, jail (openvz, lxc,

charlie_hu · 2012. Ápr. 8. (V), 11.40
chroot, jail (openvz, lxc, solaris zónák, stb.) nem paravirtualizáció (ahhoz egy külön kernelt kéne betöltened a benne futo dolgoknak), hanem konténer megoldás (mivel nincs saját kernele, csak a host kernele szeparálja el önmagától és egymástól ezeket).
28

BSD kapcsan erdemes egy

hron84 · 2012. Már. 10. (Szo), 23.31
BSD kapcsan erdemes egy pillantast vetni a NetBSD-re is. Kicsi, kellemes BSD disztro, bizonyos tekintetben sokkal baratsagosabb, mint az OpenBSD, kicsit talan "Linuxosabb", vagyis egy Linuxrol atjovo ember szamara kenyelmesebb. Dinamikusan fejlodik, rengeteg csomag elerheto hozza, ha jol tudom a pkgin csomagkezelot be akarjak huzni a core-ba, ez egy apt-get bonyolultsagu tortenet. Egy rapillantast meger.