Ubuntu és PHP megoldások

 Bár ez sem linux, és nem is windows :) de érdemes időt pazarolni erre a rituáléra.
 

Az új munkahelyemen van egy pár gép, szám szerint 4 darab, amit aktívan használunk is. Ez a négy gép képviseli az elmúlt 10 év számítógép korszakait, mondhatnám hogy a P4-től a mostani szintig. 

A legrégebbi gép is maximum portalanítva volt. A sorban az enyém a második, hogyha a legöregebbtől jövünk a legfiatalabb gépig. Na az enyém még nem látott porszívót sem :)

A lépések a takarításnál egyszerűek voltak. Oldal burkolat le, porszívó be és adjunk az élvezetnek. A porcicák hangosan hörögtek fel a gépházból, miközben éppen beszippantotta őket a porszívó. Teljes izgalom, ahogyan a körülbelül 4mm-en álló por eltűnik a fém felületekről.

Fontos arra figyelni, hogy a ventilátorokat megpörgetheti a porszívó szívó ereje. Ezeket ilyenkor le kell fogni óvatosan, hogy ne pörgesse meg egyáltalán őket. Mert hogyha netán a porszívó megpörgeti, túlhajthatja azt és veszíthet a teljesítményéből. 

Van nekem egy vékony végű kis fogóm, ami takarításkor azt a jó célt is tudja szolgálni, hogy a processzort hűtő bordák közül, és a ventilátor és a borda közti résekből szépen kiszedje azt az összeragadt porhalmazt, ami az évek során össze tud gyűlni. Ilyenkor is figyelni kell azért, hogy nehogy megsérüljön a lapátja a hűtőventilátornak. 

A régebbi hűtő foglalatokat még viszonylag könnyű leszenvedni az alaplapról. Viszont a régi, rászáradt paszta miatt a processzor is jött vele. Magyarán úgy téptem ki a processzort a foglalatából mint a huzat :)

A figyelmemet még az keltette fel, hogy túl sok pasztát nyomtak a processzor és a borda közé, így a túl sok paszta, ami nem tapasztotta a processzort a bordához, átalakult és mint vastag por szállt fel és ülepedett le a processzor foglalata köré. Ettől is meg kell ám szabadulni, de a módszerről lejjebb.

A processzort óvatosan le kell tépni a hűtőbordáról. Ezután jól jön egy unatkozó, még tiszta kezű kolléga, aki letakarítja a processzor hátlapjáról a még rászáradt pasztát. (Mert ugye én már a lehető legtöbb pasztát ami a hűtőbordán volt össze fogdostam)

A régi pasztát a legegyszerűbben (Figyelem! Termék megjelenés!) Tesco-s popsitörlő kendővel lehet levakarni. Ugyan így kell a processzorral is eljárnia az unatkozó kollégának.
Fontos, hogy a processzor lábak között ne legyen semmilyen szennyeződés, így a pasztát is ki kell varázsolni a lábak közül, a szélein sem lehet.

Én még a processzor foglalat körül is a törlőkendővel körbe törölgettem, hogy ne szálljon bele a foglalatba a régi, már porrá változott paszta. (Érdemes még az alaplapot is körbe törölgetni vele, ugyan így a videó kártyát és a többi eszközt is)

Ezek után ha már mindent kiportalanítottunk, jöhet az összeszerelés. Én még a P4-es gépet megszabadítottam 3-4 fölösleges kábeltől is.

Először is a processzort be kell rakni a foglalatába. Arra ügyeljünk, hogy helyes pozícióban helyezzük bele, és a lábak mind teljesen beleálljanak a hozzájuk tartozó lyukakba. Tehát teljesen süppedjen a foglalatba. (A processzor kitépése után a foglalatot leszorító kis kart felfele kell állítani, akkor van un. nyitott állapotban) majd a kis kart nyomjuk le és akasszuk bele a kis kiálló bigyóba. (Tehát állítsuk zárt állapotba) Ilyenkor egy kicsit elmozdítja a processzort valamilyen irányba. 
Mindezek után, nyomjuk egy kisebb borsószemnyi pasztát a processzor tetejére, és kicsit kenjük is szét rajta. (Ne nyomunk rá túl sokat, mert akkor megint az a helyzet áll fent, hogy a felesleges paszta elszárad, és porrá válik)
Ekkor a hűtőt egy mozdulattal kell ráhelyezni a processzorra, óvatosan, hogy a pasztát ne nyomja túlságosan is szét. Majd fixáljuk le a hűtőt az alaplaphoz.
Innentől ennyi a takarítás, mehet vissza az oldallap a házra. 

Amikor bekapcsoljuk a gépet és a kollégák kiemelik, hogy nem lett halkabb, szimplán közölni kell, hogy én nem is mondtam olyat, hogy halkabb lesz :)

Bár, kicsit tűnhet önreklámnak is a dolog, de nem az a cél (nem csak). 

Rengeteg olyan oldal van, amely bizonyos szolgáltatásait, termékeit csak úgy érhetjük el, hogyha regisztrálunk egy fiókot, vagy megadunk egy e-mail címet. Amelyre a későbbiekben persze folyamatosan küldi a reklám leveleket, és leiratkozni vagy nagyon nehéz, vagy talán nem is lehet (ezt már szerencsére törvény is korlátozza). 

Tehát, erre egy jó megoldás, hogyha ideiglenes e-mail címet használunk. 
A legtöbb ideiglenes címmel csak fogadni tudunk levelet, ritkább esetekben a fogadott levélre választ is tudunk küldeni. 
Ezzel megspórolva magunkak a spam leveleket is. Ezek az ideiglenes címek általában generált e-mail címek, így megjegyezni nehézkes (persze fejben), és idő korláthoz kötöttek. 
Amit én ajánlani tudok, az a saját szolgáltatásom: ideiglenesmail.info. Egy óra az idő korlát, és a kapott levelekre akár válasz is lehet írni. Persze az idő korlát meghosszabbítható egy kattintással,így a visszaszámláló ismét 1 óráról kezd el visszaszámlálni. 

Remélem, van aki hasznosnak találja majd a dolgot. És ha igen, akkor nyom egy Like-ot.

Fejlesztőként sokat szenved az ember az adatbázis kezelő felületek miatt.

Vannak a phpmyadmin-tól alternatívák, persze mindegyiknek van előnye és hátránya, ugyan úgy mint a phpmyadmin használatának.

• SQLBuddy
  Szép, ajaxos, beszéli "tudja" a magyart, viszont a navigációja kicsi szedett vetett (sok táblánál/sok adatbázisnál túl hosszúvá válik a navigációs része). Triggerekkel nem igazán foglalkozik sajnos. (Legalábbis én nem találtam rá utaló jelzést) Ritkábban adnak ki hozzá frissítéseket sajnos.
• Adminer
  Több "verzióban" is letölthetjük (Csak MySql, csak angol nyelv stb...), "egy fájlos" kezelő, pluginezhető is (az oldalon találunk is hozzá pár hasznosat és kevésbé hasznosat). Az alap megjelenése logikus elrendezést használ, és gyors. Ennek a "hátránya" -már hogyha lehet hátránynak nevezni hogy nincs agyon csicsázva. Lebutítható felhasználóknak, így megszabhatjuk, hogy mit tudjanak az adatbázisban csinálni, milyen táblákkal stb. Tehát ráadásnak jól konfigurálható is. (Hogyha toplistát írnék, ez első helyen lenne). A szerencsés dolog még hozzá, hogy nem csak MySql-re alkalmas, és folyamatosan fejlesztik.
• Chive
  Első ránézésre szép. Részemről kicsit néha lassúnak találtam használat közben, de annyira nem gázos. Viszont nagyon hiányzik, hogy nem tudom "agyon konfigurálni", így személyes használatra jó csak. (Osztott hosztingra nem tenném fel.) Ami viszont tetszik benne, az a logikája, és az hogy triggereket tudunk benne elég egyszerűen kezelni. Amit hiányolok benne az idegen kulcsok kezelése (eddig még nem találtam benne utaló jelet, hogy létezne). Az biztos, hogy még most sincsen készen teljesen, mert néha írogatja a hibákat. De az átláthatósága miatt használhatóbb.
  Amikor először néztem, akkor még ennyire nem volt fejlett, mint ahogy most, többször írt hibát, akkoriban le is írtam, hogy sok a csicsa és kevés a tudás.
   

A fenti pár példán kívül biztos akad még pár adatbázis kezelő felület (webre). Ezek voltak azok amiket szívesebben használnék. Sőt, a fent felsoroltakat használtam is mind egy ideig.

Sokan nem gondolnak ilyesmire, pedig elég fontos dolog.

A webszerver, esetünkben Apache2 dinamikus oldalgenerálásokra van optimalizálva, ezért fontos, hogy minél kevesebbszer kelljen neki újra és újra generálnia egy-egy képet.

Sok oldalon (nagyobbakon) megfigyelhető, hogy például a statikus elemeket külön webszerver, akár külön szerver szolgálja ki az oldal alatt.

Ennek oka szintén az, hogy a „Fő webszerver” ami a dinamikus tartalmat szolgálja, erre lett optimalizálva, míg általában a statikus részeket kiszolgáló webszerver le van butítva, így nem is lenne képek akár PHP-t futtatni.

Míg esetünkben adott egy akár általunk átméretezett kép, akár egy általunk generált kép (PHP GD, PHP Imagemagick stb...), amely rosszabb esetben minden meghíváskor újra és újra generálja a képet, ezzel a webkiszolgálót nyúzva.

Minden kép generálás ugyanis erős lemez, memória és processzor használatot igényel, legyen az egy egyszerű átméretezés (nagy képről kicsire stb... ) vagy egy bonyolultabb kép effekt, bármi. Ez nem jó senkinek sem.

Ezért jön a kérdés... Miért nem használjuk ki, hogy az oldalt látogatónk böngészője már egyszer lementette a képet a gyorsítótárába... ?

Az elv:

Kedves látogatónk, először jár az oldalon és mondjuk a galériánkat óhajtja megtekinteni, amely 3MB-os képeinket tartalmazza. De mi nem akarjuk elsőre a 2000x3000 pixeles képeinket betölttetni vele, így azt átméretezzük 200x300px-re. Egy oldalon mondjuk 50 kép, és mindezt átméretezni egyszerre?

Kész örökké valósággá válhat. Ekkor jön a böngésző, ami elsőre menti ezeket a már átméretezett képeket. De látogató barátunk még egyszer meg akarja nézni, frissíti az oldalt. Megint várhat sok ideig.

Szóljunk a böngészőnek, hogy „hé haver, ez a kép nálad egyszer már le van mentve!”.

A böngésző mindig küldi, hogy ő mikor látta utoljára azokat a média elemeket.

$_SERVER['HTTP_IF_MODIFIED_SINCE']

Gyakorlat:

$file = 'kep.jpg';

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) AND (strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) > filemtime($file))) {

header('Last-Modified: '.gmdate('D, d M Y H:i:s', $lm).' GMT',true, 304);

exit;

}

Tehát, ha a böngésző értesít minket, hogy neki ez megvan, akkor értesítsük arról, hogy változott-e azóta.

De honnan jön a kep.jpg, ha generált a kép?

Onnan, hogy érdemes megcsinálni még azt, hogy amikor méretezzük a képet a látogatónknak, mi azt sunyiban le is mentjük átméretezve. És legközelebb megkívánja valaki azt nézni kis méretben, akkor már az jelenik meg, mert létezik, plusz hogy a kis képet se kelljen folyton oldalhívásonként beolvasni, megnézzük és elküldjük a böngészőnek, h mikor változott utoljára.

Íme egy élő példa. Ezzel egy URL-en megadott óriás képet méretez át, ment egy thumb mappába, majd legközelebb már a böngészőnek szól, hogy mikor változott utoljára.

Ki ne ismerné a GNOME -ot, akik Linuxot használnak. A 3.0-ás érdekes fajta lett. De ne ugorjunk még ennyire előre.

Még a Natty megjelenése előtt, az első alfa, béta verziók publikálásakor már sokan szidták a fejlesztőket például a unity miatt. Érdekes egy "állat" lett. Akinek eddig gondja volt az előző kiadásokban a videó kártyájával, az most ne számítson jobbra.
A "régi" GNOME felület (felül panel, alul panel Ubuntuban) is eléggé haza tudta vágni a felhasználói élményt. Én személy szerint át is álltam Xubuntura egy ideig.

A unity most rárak egy lapáttal a halálozási szintre. Alapból nem lehet kikapcsolni az effekteket, így számomra teljesen használhatatlanná vált. Próbálkoztam a unity 2d-vel is, nem sok sikerrel. Pláne disztribúció frissítés után.
Viszont, sok helyen is már lehet olvasni, hogy élvezhetjük a régi GNOME (felül panel, alul panel) elrendezést. Ezt a bejelentkezési képernyőnél választhatjuk, és hogy elkényeztessenek minket, választhatunk effektek nélkülit is.

Ez eddig szép és jó. De kérdezem én, Natty-ba miért nem raktak GNOME 3-at?

Tippem szerint, mert a GNOME 3-ban olyan megoldások vannak, amik bealázzák a unity-s elgondolást.

Ez lenne a gnome-shell. Ámúltam bámúltam amikor felraktam, csorgattam a nyálam, ez biztosan szaggatni fog huzamosabb használat után.

És láss csodát. Se flash szaggatás, se Firefox szaggatás, se menü effekt szaggatás. Az elrendezése szimpatikusabb, mint a unity-é. Jobban kézre állnak a dolgok. Míg unity-ban ki sem férnek az általam gyorsan elérhetővé tett ikonok, itt ez nem okoz gondot.

Lényegében 2 fő nézete van a felületnek. A fő nézet, amelyet alapból látunk a szokásosnál kicsit újabb. Felül egy panel szerű dolog található, középen az órával, jobb oldalt a fiók információkkal, hangerő stb. Míg a bal oldalán „Tevékenységek”, és mellette az éppen fókuszban lévő ablak ikonja és neve. Ez eddig szép. A panel le van kerekítve a két végén, átölelve az éppen fókuszban lévő ablak keretet, amely teljes méretre van nyitva. Tehát, az ablak keret is le van kerekítve. Minthogyha egybe tartoznának. (Ugye unity-ben maga az ablak címsor került a panelra, ahol a „Fájl, Szerkesztés” stb... menü kapott helyet).

Amikor egy program értesítést küld, az mind alul jelenik meg, középen egy fekete sávban fehér betűkkel és egy ikonnal. Ha rávisszük az egeret, további információt is közöl.

A jobb alsó sarokba húzott egérre előugrik az alsó panel, amelynek háttere átlátszó színátmenettel feketében végződik, fentről lefele. Itt vannak azok az ikonok, amelyek a régi GNOME elrendezésnél alapból Ubuntuban az óra mellett kaptak helyet.

A második nézetet két -féle képen lehet elővarázsolni.
Az egyik, hogy a jobb felső sarokban vonszoljuk az egeret, ekkor kék hullámzással jelzi a kurzur helyén, hogy most „megnyitom”. Ekkor a régi rendszer szerint a megnyitott ablakok listája jelenik meg rácsos nézetben, és baloldalt (mint unity-ben) a gyorsmenü.

A második módszer az előhíváshoz az, hogyha rákattintunk a felső panelon a „Tevékenységek” feliratra. Bár szerintem hibás fordítás, nem passzol a menünév.

Amikor ezt a nézetet látjuk, jobb oldalt választhatunk még az asztalok közül is.
A nézetben felül még két menüpont található: Ablakok és Alkalmazások

Az alkalmazásokra kattintva választhatunk feltelepített alkalmazásokból vagy jobb oldalt szűrhetünk a keresővel, a kategóriákkal.

Lényegében a unity és ez a GNOME3 elrendezés nem áll messze egymástól. Viszont a GNOME3 elrendezése nem szaggat, nem öli a videokártyámat, és szép.

Telepítése:

sudo add-apt-repository ppa:gnome3-team/gnome3
sudo apt-get updatesudo apt-get dist-upgrade
sudo apt-get install gnome-shell

Nekem telepítéskor voltak függőségi gondjaim, de ezeket amik függenek érdemes törölni, mert a GNOME3-ban valószínüleg nem is lesz rá szükség.

És íme egy-két screen müködés közben:

Ez a belső nézet, felül a jobboldali ablakban a videó azért fekete, mert épp fekete volt :)

 Egy kép éppen arról, hogy egy videó fut a böngésző ablakában. (és nem szaggat:))

Egy kép az alap asztalról (módosított háttérképpel).

Mint, azt már GNOME-tól megszokhattuk, sajnos még így az elején van a GNOME3 projekt, bizonyos dolgok hiányosak.
Kapott új beállító menüt, de nem sok mindent lehet benne még beállítani, csak nagyon az alapvető dolgokat.

Ez már tényleg a nagyon elvetemült dolgok közé tartozik, hiszen aki ismeri, tudja is, hogy PHP-nak sajnos vannak hátrányai, függetlenül, hogy könnyen használható CLI, azaz "parancs soros" programként is.

Ismert tény, hogy néha szereti felzabálni a memóriát, így nagyon figyelni kell parancssoros alkalmazásakor. De lássuk is mi a téma...

http://nanoweb.si.kz

És igen, létezik!

Mi is ez? Hát egy webszerver PHP-ban, az oldalon is ezt próbálják bizonygatni. Sajnos a fejlesztése már rég óta nem megy.

PHP Pear -ben is található egy csomag, amellyel könnyen hozhatunk létre démon programokat. De ez a Web szerver más.

Telepítése roppant egyszerű:

Töltsd le a PHP4 -et, forgasd be. Ne felejtsük el a következő képen futtatni a ./configure parancsot:

A futáshoz szükséges:

--enable-cli --enable-sockets --enable-pcntl

Míg, opcionális:

--enable-mime-magic --with-zlib --with-mysql --with-ldap

Ezek után jöhet maga a webszerver, persze ha sikerült a PHP4-et beforgatni.

Letölt, kicsomagol után:

./install-sh

Előugrik egy !ablak, amely a telepítési paramétereket mutatja. Majd install. És készen is van, telepítettünk egy apache, lighttpd és barátai tudásának szintjén lévő webszervert.
A legjobb, hogy nem kell php-n kívül más program nyelven programozási tudás, hogy modul-t írjunk hozzá. Esetleg bugot javítsunk.

Böngészőnkben nyissuk meg a localhost címet, majd ott találunk egy linket a Webes admin felülethez. Virtuális hoszttól kezdve gyakorlatilag a php beállításait is tudjuk szerkeszteni. És kezel a .htaccess-hez hasonlóan könyvtár alapú beállításokat is.

Átírható benne, hogy bizonyos állományokat milyen cgi-vel futtasson. Kipróbáltam, hogy a php-t már a php5-ös verziójával futtassa, de sok sikert eddig nem értem el vele. Mert az oldal csak töltött, és töltött. De, ez lehet oka annak is, hogy jelenleg egy agyon hackelt PHP-vel rendelkezem csak saját gépen.

A másik ami még szemet szúrt, hogy a nanoctl start parancs kiadása után, ír egy bizonyos hibát, és onnantól az a terminál használhatatlanná válik, minthogyha valami alkalmazás elkapná a bevitelt a termináltól.

Érdekességnek jó, semmi egyébnek. Nem hiszem, hogy nagyon alkalmas lenne egy olyan szerveren, ahol éles alkalmazások futnak.
 

Több fokozatba lehet sorolni az oldalakat biztonsági szempontból. Viszont, a legkisebb biztonsági fokozattal rendelkező oldalaknál is fontos a titkosítás, hogy legalább megköveteljük a felhasználóit az olyan jelszavak használatára, ami legalább nem található meg a szótárakban, nem teljes szavak, és nem ugyan az, mint a bejelentkező név. És ne is tartalmazzon belőle egy részletet sem.
 

Fontos még arra ügyelni, hogy ezeket a bizonyos jelszavakat hogyan mentjük le az adatbázisunkban, legyen az bármilyen adatbázis.

PHP alatt található jó pár titkosítási módszer. Régebben (és még sokan most is) az md5 -re esküsznek. De el kell szomorítanom őket, mert léteznek olyan md5 adatbázisok, amelyek már előre kódolt szavakat tartalmaznak, ezzel bizonyos programok képesek is dolgozni, hogy visszafejtsék a kevésbé ártatlan felhasználóink jelszavait.

Legyen az programozó, vagy egyszerű felhasználó, mindenképpen tudnia kell, hogy jelszava nincsen biztonságban. Olyan jelszót kell megadni, amit nem lehet kitalálni. Ilyenre alkalmas online eszközök is léteznek, például ez is: www.onlinepasswordgenerator.com

Az igaz, hogy ezeket a jelszavakat nehéz megjegyezni, és hogyha elfelejtjük, kérhetünk egy újat. De inkább, minthogy más használja fiókunkat.

PHP-ban a következő megoldásokat érdemes szem előtt tartani.

Például, ha már md5-ben mentettünk jelszavakat, használjunk jelszó sózást.

$jelszo = md5($titkosszo1.$jelszo.$titkosszo2);

tehát, a két titkos szó a só :)

Több fórumon is írták, hogy a többszörös titkosítás:

$jelszo = md5(md5($jelszo));

még könnyebben is törhető, mint az eredeti

$jelszo = md5($jelszo);

megoldás. Ebbe mélyebben nem mennék bele, hogy miért.

Programozóként még érdemes arra figyelni, hogy az ilyen jelszavakat az oldalainkon csak úgy tudják megfejteni, hogyha többször próbálkoznak. Tehát, érdemes beleépíteni az oldal bejelentkező részébe egy számlálót, ami számolja a hibás bejelentkezéseket. Mondjuk, harmadik bejelentkezés után tiltjuk a felhasználói fiókot a próbálkozásoktól. Így meggátolva a brute-force támadást.

Sok oldalon az sütik mentése sem éppen a legjobb biztonsági szempontokból. Érdemes erre is figyelni, hogy a süti lopó kódokat egyszerűen ne engedjük lefutni. Vagy, ne használjunk sütiket.

A süti tartalmát is érdemes esetleg valamilyen sózással tárolni, esetleg minden bejelentkezéskor egy egyedi karaktersorozattal spékeljük meg. Így akár az is meg oldalható, hogy egyszerre csak egy felhasználó tudjon bejelentkezni ugyan azzal a fiókkal. Függetlenül IP címtől.

 Íme egy terheltésgi statisztika (nem élő kép):

Sajnos a grafikonokon a szövegek ékezeti problémáját még nem sikerült kiküszöbölnöm :) 

A téma adott, már egy éve pezsegnek a fórumok tőle.

Hogy mi is az a VPN?
Leegyszerüsítve annyi, hogy egy magán hálózatot hoz létre. Olyan, mintha otthon van egy routered, és a router mögött van több számítógép. És a ráadás, hogy ezt eléred neten keresztül, ami a fenti példára nem igaz.

Úgy értve, hogy eléred, hogy mint kliens, tudsz csatlakozni abba a hálózatba, mintha a routerhez lennél kötve fizikailag. De mégsem.

Tehát, a szerver Ubuntu. A kliens lehet bármelyik operációs rendszer, én eddig WindowsXP-n teszteltem sikerrel. Windows 7 is a palettán volt, de ott router gyanuval kapcsolódás után ledobta az alanyt a hálózatról.

Pontos leírást nem akarok közölni, csak pár extra változtatást, áltam letesztelt beállítási paraméter, de ez változhat a kiszolgáló szervertől függően.

Perpillanat ebben a megoldásban ezt a leírást találtam, ami a legfrissebb:

http://riobard.com/blog/2010-04-30-l2tp-over-ipsec-ubuntu/

Ez müködik is, mint amint feljebb írtam, pár változtatással, finomítással.

Tehát, a linken megadott leírás készen is van. Jön a probléma, hogy pppd szerverünk valamiért előszőr 900kb/s-nál többet nem enged sávszélességnek. Ezt kicsit körbe lövöldözve, sikerült megspékelnem 1,1MB/s sebességre, ugye ami 8,8 Mb/s körül ingadozik.
Hogyha megfigyeljük az interfaceket (lsd. ifconfig), akkor a ppp0 MTU-ja 1400-ra van állítva. Ez szép és jó, ugye az ethernet interface MTU-ja 1500. Namármost, hogyha ezt átírjuk a ppp -hez tartozó beállító fájlban 1280 -ra, akkor elérhető a kliens teljes sávszélessége. (persze, ha a szerveré több, vagy egyenlő).
Referenciaként ez az oldal szolgál: http://rootmanager.com/ubuntu-ipsec-l2tp-windows-domain-auth/setting-up-openswan-xl2tpd-with-native-windows-clients.html

A két leírás hasonlít. Ebben van szó arról, hogy azért 1280, mert Vista Távoli Asztal kapcsolatánál kidobja őt a hálózatról. Érdeks, hogy nálam pont más miatt kell ez.
És érdemes arra figyelni, hogy a ppp démon még lekap az MTU-ból 6bitet, a csomagok fejlécei miatt. Így, akár tesztelhető 1286-al is.

Innentől kezdve, hogyha sikerül a kapcsolat, a szerverre még rakhatunk fel egy SAMBA kiszolgálót, megosztáshoz. PPP képes mysql-ből felhasználót kezelni, mint plugin. Erre legalább 3 megoldást lehet találni neten.

Jön még egy érdekes dolog a sávszélességgel kapcsolatosan.
Nem szeretnénk mondjuk, hogyha házi szerver, és haver a teljes sávszélességet felemésztené a napi pornóvideójával, vagy torrentjével. Ittj ön közbe a u.n. TC, amivel a ppp interfészekre, vagy akár IP-re is állítható sávszélesség korlátozás.

Még hozzá kell hogy tegyem, a legelső linken, ahol található maga a VPN telepítése, ott ír egy bizonyos bugról, amit az openswan okoz. Mindenképen érdemes letölteni, és újraforgatni az openswant, mivel a bug Ubuntu 10.04.1 alatt elérhető verzióban is benne van. És, ami a HowTo-ban van verzió, nem a legfrissebb. Tehát, érdemes megkeresni és leszedni a legújabbat, és azt beforgatni.
 

Ismerős a hiba?

Hogyha nem akkor még találkozhatunk vele.
 

Gyakori probléma. Míg normális esetben egy alkalmazás 1-2 kapcsolatot használ egy időben, előfordulhat, hogy a programunk mégis túl lépi.

Az oka annyi, hogy a MySql adatbázis korlátozza azt, hogy egyszerre hányszor kapcsolódhat hozzá egy felhasználó. És a hibásan írt programok túllépik eme korlátot azzal, hogy nincsenek kellően lezárva a már nem használt kapcsolatok.

A megoldása roppant egyszerü, amit a kis példa kód illusztrál:

$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
if (!$link) {
    die('Not connected : ' . mysql_error());
}
mysql_close($link);
if (isset($link)) {
  unset($link);
}
A lényege csupán annyi, hogy le kell kezelni változóval a kapcsolatot, majd használat után törölni kell.

Így biztosan zárja a kapcsolatot a mysql-el.