Dinamikus tartalmat szolgáltató webszerver CARP-pal

OpenBSD

Nagy Róbert küldte be a hírt:



Miután már van egy statikus oldalt kezelő web szerverünk CARP-pal, felmerülhet bennünk az igény arra, hogy dinamikus oldalakat is használjunk. A PHPNuke-ra esik a választásunk. A következőkben azt fogom leírni, hogy én hogyan oldottam meg ezt a problémát. A választás a MySQL-re esett, mivel ennek van beépített replikáló funkciója.

Magát a www tartalmat (a php scripteket, képeket stb.) rsync segítségével fogjuk tükrözni. Akkor hát vágjunk a közepébe. Persze előtte mindenképpen olvasd el trey OpenBSD: magas rendelkezésre-állású webszerver készítése CARP-pal című írását, mivel itt a CARP beállításokkal nem fogok foglalkozni. Feltételezem, hogy már be van állítva mindekinek és van egy MASTER és egy SLAVE gépe. A lépéseket mindkét gépen végre kell hajtani, egy két kivétellel, az ilyen eseteknel szólni fogok. Ezért kérek mindekit, hogy először olvassa el a leírást, és utánna álljon neki a dolognak. Ha valami nem működik, akkor e-mail-ben szívesen segítek.Adatok:

---------

MASTER IP: 192.168.1.101

SLAVE IP: 192.168.1.102

OS: OpenBSD 3.5 (GENERIC) #34: Mon Mar 29 12:24:55 MST 2004



MASTER & SLAVE BEÁLLÍTÁSA

------------------------------------



Először is telepítsük a php és mysql csomagokat.

  • Állítsuk be a PKG_PATH környezeti változót:
      setenv PKG_PATH ftp://ftp.openbsd.org/pub/OpenBSD/3.5/packages/i386
  • Telepítsük a csomagokat.
      pkg_add php4-bz2-4.3.5RC3 php4-core-4.3.5RC3 php4-extensions-4.3.5RC3 php4-gd-4.3.5RC3-no_x11

      php4-mysql-4.3.5RC3 php4-shmop-4.3.5RC3 mysql-server-4.0.18p1

    (Az sem árt, hogyha az unzip-5.50p2 csomagot is telepítjük, mert erre szükségünk lehet a PHPNuke kitömörítéséhez.)






    Ezután nézzük meg, milyen csomagokat is raktunk fel, a függőségekkel együtt.

  • Ehhez a pkg_info(1) -t használhatjuk:
      pkg_info




    Itt persze egy frissen telepített rendszerről van szó, tehát ha több csomagot látunk az nem jelent problémát ;-)



    Most pedig telepítsük a php kiegészítőket, a megfelelő helyre.

  • Aktiváljuk a php apache módot:
      /usr/local/sbin/phpxs -s
  • Másoljuk a helyére a php.ini -t:
      cp /usr/local/share/doc/php4/php.ini-recommended /var/www/conf/php.ini
  • Aktiváljuk a php kiegészítéseket:
      /usr/local/sbin/phpxs -a bz2

      /usr/local/sbin/phpxs -a gd

      /usr/local/sbin/phpxs -a mysql

      /usr/local/sbin/phpxs -a shmop



    Ezek után szükség van néhány módosításra a httpd.conf-ba.

  • AddType application/x-httpd-php .php hozzáadása (Én itt most egy szubsztitúciót fogok használni. Mindekinek szíve joga mivel szerkeszti majd a filet:
      perl -pi -e "s,#AddType application/x-httpd-php .php,AddType application/x-httpd-php .php,g" /var/www/conf/httpd.conf
  • Adjuk hozzá az index.php-t a DirectoryIndex -hez:
      perl -pi -e "s,DirectoryIndex index.html,DirectoryIndex index.html index.php,g" /var/www/conf/httpd.conf



    Indítsuk el a MySQL-t és állítsuk be a root user jelszavát.

  • A mysqld indítása:
      /usr/local/bin/mysqld_safe --user=_mysql --datadir=/var/mysql --replicate-ignore-db=mysql >/dev/null &

    A --replicate-ignore-db=mysql-ra azért van szükség, hogy a mysql adatbázist ne replikáljuk.

  • Jelszó megadása és ellenőrzés:

      /usr/local/bin/mysqladmin -u root password 'foobar'

      mysql -u root -p




    A következő lépéseket csak a MASTER gépen hajtsuk végre!


    A MySQL beállítása a replikációhoz.

  • Másoljuk a helyére a my.cnf config filet:
      cp /usr/local/share/mysql/my-medium.cnf /etc/my.conf

    Ebben a fileban már számunkra megfelelő beállítások vannak. A két szükséges dolog a log-bin és a server-id. A binary logra azért van szükség, hogy a SLAVE SQL szerver tudja, milyen feladatokat kell végrehajtania, a server-id pedig magától értetődő. A master server-id-je a config file szerint 1 lesz. Fontos, hogy a SLAVE szerveren a server-id -t írjuk át 2-re a my.conf ban. Miután ez megtörtént állítsuk le a jelenleg futó MySQL-t a következő módon:

      /usr/local/bin/mysqladmin -u root -p shutdown

    Majd indítsuk el a MySQL-t a fentebb említett módon. Erre azért van szükség, hogy a beállítások érvénybe lépjenek.

  • Állítsuk be a MySQL-t MASTER-nek és SLAVE-nek egyaránt, a "vica-versa" replikációhoz:
      mysql -u root -p



    Majd a jelszó megádsa után kapunk egy mysql> shellt. Első lépésként engedélyezzük a replikációt a 'slave' usernek a 192.168.1.102 IP címről:

      GRANT REPLICATION SLAVE ON *.*

      TO 'slave'@'192.168.1.102' IDENTIFIED BY 'slavepass';



    Második lépésként pedig állítsuk be a 192.168.1.102 gépet MASTER-ként is.

      CHANGE MASTER TO

      MASTER_HOST='192.168.1.102',

      MASTER_USER='master',

      MASTER_PASSWORD='masterpass';



    Ezt a két lépést végezzük el a SLAVE gépen is, annyi különbséggel, hogy az IP -t írjuk át 192.168.1.101 -re. Illetve a master és slave usereket és jelszavakat is cseréljük fel. Tehát valahogy így:

      GRANT REPLICATION SLAVE ON *.*

      TO 'master'@'192.168.1.101' IDENTIFIED BY 'masterpass';


      CHANGE MASTER TO

      MASTER_HOST='192.168.1.101',

      MASTER_USER='slave',

      MASTER_PASSWORD='slavepass';


    Így ha a MASTER gépen végrehajtunk egy INSERT-et, azt a slave gép is el fogja végezni. Ugyanez fordítva is igaz. Tehát a két gép egymás master-e és slave-je is egyszerre. Ha mindkét gépet beállítottuk, adjuk ki a következő parancsot mindkét gépen:

      START SLAVE;





    A KÖVETKEZÖKET CSAK A MASTER GÉPEN CSINÁLJUK!



    A PHPNuke telepítése és a httpd elindítása:

  • Töltsük le a PHP-Nuke 7.2-t, és tömörítsük ki azt a /tmp/phpnuke -ba, majd rakjuk be a /var/www/htdocs könyvtárba:
      ftp -a http://phpnuke.org/files/PHP-Nuke-7.2.zip

      mkdir /tmp/phpnuke

      unzip PHP-Nuke-7.2.zip -d /tmp/phpnuke

      cd /var/www/htdocs

      rm -rf *

      cp -R /tmp/phpnuke/html/* .

      chown -R www:www *
  • Állítsuk át az adatbázis jelszavát 'foobar'-ra mivel a következő lépésben ezt fogjuk megadni, majd indítsuk el a httpd-t:
      perl -pi -e 's:$dbpass = "";:$dbpass = "foobar";:g' config.php

      apachectl configtest

      apachectl start

    Mivel nem tcp socketen fogjuk elérni a MySQL-t, és mivel az apache chroot-olni fog a /var/www -be ezért létre kell hoznunk egy hardlinket, hogy a mysql socket elérhető legyen:

      mkdir -p /var/www/var/run/mysql

      ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock





    Állítsuk be a PHPNuke adatbázisát:

  • Hozzunk létre egy adatbázist 'nuke' néven, majd helyezzük bele a szükséges táblákat. Jelen esetben nem fogunk foglalkozni külön user létrehozásával. A root usert használjuk végig. Persze ez nem jó dolog, de a bemutatásra tökéletes. Ezt a lépést a SLAVE gépen is csinájuk meg mivel a mysql db-t nem replikáljuk:
      /usr/local/bin/mysqladmin -u root -p create nuke

      mysql -u root -p





    Az rsync csomag telepítése:

  • Az rsync-et a www tartalom tükrözésére fogjuk használni.
      pkg_add rsync-2.6.2.tgz
  • Az rsync beállítása (config file):
      uid = nobody

      gid = nobody

      use chroot = yes

      max connections = 2

      syslog facility = local5

      pid file = /var/run/rsyncd.pid


      [www]

      path = /var/www/htdocs

      comment = PHPNuke

  • Majd indítsuk el a rsync-et daemon módban:
      /usr/local/bin/rsync --daemon




    Ha ezzel kész vagyunk a SLAVE gépen hozzunk létre egy crontab bejegyzést, hogy 10 percenként
    mirrorozzuk a változásokat. Első futtatásnál a teljes mirrorozás meg fog történni, igy ezután a SLAVE gépen is tökéletesen elérhető lesz minden.

      */10 * * * * /usr/local/bin/rsync -avuzbq rsync://192.168.1.101/www /var/www/htdocs

    Ezek után már csak be kell állítanunk, hogy bootnál is minden szépen működjön:

  • /etc/rc.local:

      if [ -x /usr/local/bin/mysqld_safe ]; then

      echo 'mysql'

      /usr/local/bin/mysqld_safe --user=_mysql --datadir=/var/mysql --replicate-ignore-db=mysql >/dev/null &

      rm -f /var/www/var/run/mysql/mysql.sock

      sleep 5 && ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock

      chown -R _mysql:_mysql /var/www/var/run/mysql

      fi


      if [ -x /usr/local/bin/rsync ]; then

      echo 'rsyncd'

      /usr/local/bin/rsync --daemon

      fi

    Az rsync-es részt csak a MASTER gépen adjuk hozzá az rc.local-hoz, mivel a SLAVE gépen nem futtatunk rsyncd-t.

  • /etc/rc.conf.local:
      httpd_flags=""

    Ezzel kész is lennénk.

    • Egy időben igaz volt, hogy "komolyabb arcok" fejlesztik, amennyiben a komolyabb arcokon a hivatalos időben is ezzel foglalatoskodó emberek számát tekintjük és elfogadjuk az igazságot, hogy a kezdeteti időszakban jobb volt a TCP stack és a VM kezelése a *BSD-nek, főleg a FreeBSD-nek. A helyzet az, hogy ma már viszont a linux térhódítása miatt a nagyobb cégek a fejlesztőiknek - igen, mérnököknek - kiadták, hogy linux alá is meg kell csinálni a dolgokat. Esetleg előtte is csinálták vagy hobbiból buzergálták a linux kernelt, de ez nem egyenlő ugye azzal, ha munkidőben adnak rá lehetőséget és azt csinálhatod amit élvezel is. Ma már a HP, az IBM és Oracle is adott hozzá kódot, kereskedelmi termékeket fejlesztő cégeknek érdek fűződött hozzá, hogy "vállalatilag elfogadott" és erősebb rendszert hozzanak létre. Meglépték ami hiányzott a linux életéből és megvolt pl a FreeBSD Foundationban -> létrejött az OSDL. Meg lehet nézni a különbséget. Egyébként a nagy OpenBSDben, ahol a "legjobb" a VPN megvalósítás a és a crypto mánia az egeik mászik, rengeteg hiba volt a megvalósításban, elég ha visszalapoztok egy kicsit a BSD bugokhoz. Volt már ma(?) is NetBSD-s, FreeBSD-s is nemrég stb. Minden rendszerben van hiba.

    Igazi HA megoldás pedig mindig annak a kérdése lehet: milyen HA is kell nekünk? IMHO.

    Mondjuk azért verik a nyálukat, mert náluk a hibáknál nincs .cvsignore, nem? Egyébként butaság lenne azt hinni, hogy akkor most az OpenBSD a legbiztonságosabb rendszer. Minden viszonylagos. Out-of-the-box security nem létezik, mert akkor még szinte semmi sem működik. Akkor dől el, mikor:

    - fel kell raknod az első nem auditált programot

    - vezetői rendszert

    - adatbázis kezelőt

    - mindezeket karban kell tartanod

    - működtetned - állandó elérhetőség, teljesítménymérés stb.

    - kiegészítő programok garmadáját kell hozzá használnod

    Ez jelenleg üzemeltető és tervező szintű probléma, az operációs rendszer maximum ezen hibák további kihasználását max nehezítheti.

    Miért? Az? :-) Ha majd lesz OpenBSD-ben virtual server support, mint a linuxban :-) akkor lehet. De mondhatnám a HP több megoldását. Még a Compaq felvásárlás előtti részeket is, de azóta bőven volt "fejlődés" HP háza táján. Oprendszer sziten persze megnövelt a rendelkezsére állás, de alkalmazás szinten az ilyet tudomásom szerint máshogy oldják meg. Egyébként poor man's HA-nak teljesen jó. Csak nem a klasszikus HA. De szerintem nem is ez volt a cél.

    Egy raid1 szerű rendszeren a nem ismert hibás diszk hibája által generált hibák kiszűrését? Vagy azt ,ha törlődik valami a raid1-ről a, akkor az ne törlődjön a másik részről? Akkor az nem raid1. Lehet írás előtti checksumokat végezni biztos, de ilyet még nem láttam. Perse ez korlátolt kis életem egyik hibája is lehet :-) Van alap védelem hw defeket ellen persze a raid1-ben oprendszer szinten is, de a fenti probléma gáz lesz akkor is.

    ( anr | 2004. 06. 12., szo – 08:30 )

    Egy apro problema: ha a wincsi-d ugy megy tonkre, hogy eloszor hibazni kezd, akkor a hibas tartalom 10 percen belul megjelenik a SLAVE gepen is. Ez meg RAID-el sem kivedheto, mivel a RAID-nel _fel van tetelezve_, hogy ismerjuk melyik disk hibas. (pl: nem mukodik;-)).

    Ja ez eletbol vett pelda nalam. RAID1 ment igy tonkre.

    Mas: jok ezek a cikkek, jo otlet, hogy nagy, nemtrivialis eletbol vett problemakrol ilyenek szuletnek.

    ( nevergone v | 2004. 06. 12., szo – 09:39 )

    Már vártam a cikket, köszönöm... :)

    ( uid_228 | 2004. 06. 12., szo – 10:33 )

    A cikk nagyon klassz! :)

    Kíváncsi vagyok, hogy _Joel és Kisza megint elkezdik-e osztani az észt, hogy ez nem is igazi HA megoldás. :I

    ( vmiklos | 2004. 06. 12., szo – 11:55 )

    kezd izgatni a dolog: Nagy Róbert=thunglife?

    ( anr | 2004. 06. 12., szo – 17:33 )

    [off]

    Majd elfelejtettem mondani.

    Gratulalok thuglife, hogy felnottel.;)

    [/off]

    hát most hízhatsz egy keveset. kipróbáltam.

    user kóddal fordítottam, le persze nem futott grsecurity(TPE)+noexec file system miatt,

    de mikor root-al áttettem a /usr-be a fordított binárist, és onnan futtattam felhasználóként, tényleg kiverte a biztosítékot.

    úgyhogy most hízhatsz.

    komolyra fordítva:

    *BSD-ben mikor volt ilyen tipusú bug, hogy user kóddal lokálisan le lehetett verni a kernelt?

    csak mert úgyfest kénytelen vagyok gondolkodni az áttérésen, mert ez szerintem linux szempontból egyre rosszabb lesz...

    ( samson | 2004. 06. 12., szo – 20:47 )

    hali.

    Az rsync parameterek(-avuzbq) erdekesek:

    verbose is es quiet is egyszerre :)

    --delete elhagyva

    -u szuksegtelen

    -b szuksegtelen

    grsec ezesetben nemszamit... ;)

    De számít, mert ha a TPE be van kapcsolva, és az összes file rendszer noexec-el vagyon becsatolva (~nekem ez a "szokásom") , ahova a usereknek rw(x) joguk van, akkor a userek nem tudnak idegen binárist futtatni.

    (=ezért kellett nekem is kézzel átteni a /usr-be amikor kipróbáltam az exploitot, lefordítani le lehetett, de futtatni már nem.)

    persze ez talán azt is jelenti, hogy linuxot használni ilyen típusú védelem nélkül lassan életveszélyes.

    egyebkent bsd alatt is vannak nyilvan ilyen problemak

    akkor marad ami most van.

    Ez nyilván attól függ, hogy mit veszünk figyelembe... Bugok szempontjából természetesen kevesebb jön ki BSD-re, de nyilván rálehet fogni arra, hogy azért mert kevesebben használják mint a Linuxot (de azért én bízok abban, hogy azért is, mert komolyabb arcok fejlesztik :). Az, hogy ilyen local DoS hiba előfordul BSD-knél is nem jelenti azt, hogy ugyanennyi fordul elő. És ez a nem mindegy szerintem... ;>

    Koszi de megvagyok elegedve a testsulyommal ;-)


    Erted en csak azt nem szeretem, hogy a linuxosok annyira verik a nyalukat, aztan nincs olyan honap hogy ne lenne valami sulyos hiba a kernelben. Nekem csak ennyi a problemam. Ne gondolkodj az atteresen, hanem tedd meg. Hidd el csak pozitiv tapasztalataid lesznek.

    csak azt nem szeretem, hogy a linuxosok annyira verik a nyalukat

    Na ja, csak sz'tem itt ez nem jellemző...

    Én mondjuk soha nem vontam kétségbe, hogy a linux kernelben is vannak hibák.

    A 2.6-os sz'tem az átlagnál is jobban bugzik, és ha tippelhetek azt mondanám,hogy 2.6.12-ig még sok "víz" folyik le rajta.. Mondjuk a 2.4-es se sikerült valami "fényesre" így "utólag" visszagondolva.

    A 2.2-es szériát szerintem jobban "eltalálták".

    ---

    honap hogy ne lenne valami sulyos hiba a kernelben.

    Ez a mostani azért "különleges", mert kint van az exploit, és gyak. nincs stabil kernel, amit ne érintene.

    csak különféle rc* /pre* "teszt"verziók.

    ---

    Még egy kérdés!

    Van-e a *BSD-ben olyan lehetőség, hogy a filerendszert "noexec" (+nosuid,nodev?)-el csatoljuk fel, és ezt

    meg lehet-e kerülni, lásd linux alatt "/lib/ld-linux.so.x /tmp/binaris" móccer.

    Ha van ilyen megkerülési móccer, akkor azt lehet-e blokkolni. (pl. grsecurity TPE?)

    Sz'tem local root/DoS exploitnál ez lényeges kérdés, bármilyen ritkán forduljon is elő.

    (~ua. elég ha eccer előfordul, hogy exploit kint van , javítás meg sehol (~0day exploit)).

    nem ismerem személyesen thuglife-t így nekem esett le utoljára a nevek közti párhuzam val'szeg ;)

    mindenesetre meglepődtem... az alapján amilyen hozzászólások voltak 1-2 cikkhez, vagy fórumban tőled - mármint thuglife-tól - nem vártam hasonló cikket ;)

    mindenesetre kellemes meglepetés és nem utolsó sorban érdekes a cikk is

    openbsd-ben nem vagyok otthon úgyhogy tartalmához nem tudok hozzászólni, de ha lehetőségem lesz rá kipróbálom...

    ezek után ez a mérce, kéretik hasonló minőségű anyagot leadni, és kevesebbet flame-lni ;) gondolom sokak örömére...

    üdv.

    > Van-e a *BSD-ben olyan lehetőség, hogy a filerendszert "noexec" (+nosuid,nodev?)-el csatoljuk fel, és ezt

    meg lehet-e kerülni, lásd linux alatt "/lib/ld-linux.so.x /tmp/binaris" móccer.

    Ilyen egyszerű módszer nincs, de biztos vagyok benne, hogy profik máshogy megtudják kerülni BSD alatt is (és Linux alatt is van ezen kívül még számtalan más megoldás rá).

    > Ha van ilyen megkerülési móccer, akkor azt lehet-e blokkolni. (pl. grsecurity TPE?)

    TPE van NetBSD-ben alapból és patch formájában az OpenBSD-hez is készült (Stephanie). FreeBSD-ben ott a MAC framework ami (állítólag) jobb, mint a grsec RSBAC.

    > Sz'tem local root/DoS exploitnál ez lényeges kérdés, bármilyen ritkán forduljon is elő.

    Szerintem ha valaki már localisan tud futtatni programokat (legyen az a userland programjai, ls, ps, chmod, stb.) akkor már nem csak helyi DoS-t tud simán végrehajtani, hanem bármilyen tetszőleges más programot is tud futtatni. Ennek legfőbb oka az, hogy míg kernel és suid binárisok esetén próbálnak odafigyelni a hibák visszaszorítására addig a sima programoknál nem ("hisz úgyse lehet priv. emelésre használni") és ezáltal olyan hibák vannak bennük amelyeket kihasználva tetszőleges kód futtatható hiába van noexec vagy TPE vagy akármi...

    ( nevergone v | 2025. 03. 10., h – 12:38 )

    Ez is milyen szép volt! :)

    A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.