Hírek

Ezen az oldalon a rólunk szóló hírek mellett olyan ötleteket, tippeket fogunk közzétenni, amelyekkel az online üzleti eszközöket tényleges profitszerzésre tudod használni.

Iratkozz fel a bejegyzésekre (Atom RSS), vagy ha az egyszerűbb, kövess minket Twitteren, vagy a Facebook oldalunkon.

Miért olyan nehéz hibatűrő webszolgáltatást biztosítani?

Tibor Kruska, 2012. máj. 4. 1:50   [ frissítve: 2012. máj. 4. 3:44, felhasználó: Tamas Grosz ]

A múlt hétvégi hálózati kimaradás kapcsán sokan megszólaltak, felelőtlenül vagdalkozva olyan szakszavakkal mint backup szerver, VPS, dedikált szerver, cluster, redundáns webszerver, felhőszolgáltatás, szimmetrikus hálózati kapcsolat satöbbi; fennen hangoztatva, hogy e varázsszavak halmaza a webhosting szolgáltatók Szent Grálja.

Ezek mind létező dolgok, de szinte mindegyik más feladatra megoldás. Azoknak készítettem ezt az összefoglalót, akik be szeretnének picit pillantani a kulisszák mögé.

Minden valamirevaló szolgáltató védekezik hardverhiba ellen a webszerverein. Az első szinten a hibatűrő lemezköteteket használjuk (RAID), hogy egy szinte mindennapos diszkhiba miatt ne legyen egyetlen másodperc kiesés sem. A következő szint a fürtözött technológia (cluster), amikor a komplett szerver tükrözzük, hogy bármelyik szerver(alkatrész) meghibásodása ne eredményezzen leállást (maximum néhány percet, az átkapcsolás idejére). Itt viszont van egy nagyon komoly korlát: a clusterek szinte kivétel nélkül helyi megoldások, tehát a két gép közel van egymáshoz, egy közös (és hibatűrő) adattárolóra kapcsolódnak, és hálózatilag kívülről ugyanazon az IP címen érhetőek el.

A hétvégi esetben ez a megoldás sajnos nem működhetett, mert a komplett szervertermet kapcsolták le, clusterestül, adattárolóstul, hálózatostul.

Miért nem jó, hogy a mentést visszaállítja a szolgáltató egy másik helyen, egy másik szerveren? Nos, amíg csak információs weboldalakat szolgál ki a szerver, amelyek hetente/havonta változnak, nincs is semmi gond. Azonban ha valódi online rendszerek üzemelnek rajta, úgy mint webáruházak, CRM vagy éppen ERP rendszerek, számlázóprogramok, akkor már akár néhány órányi adatvesztés is óriási probléma. 

Ha a szolgáltató egyszerűen csak fogja az utolsó mentést, és visszaállítva beindítja egy tartalék szerveren, a következőket eredményezi: elveszett ügyfélmegrendelések, hiányos ügyféltörténet, szigorú számadású bizonylatok hiánya (pl. számlasorszámozás). Ez adott esetben elképzelhető hogy nagyobb problémát eredményezne, mint maga a leállás ténye, és az ügyfeleknek mindenképpen óriási pluszmunkát eredményez (adatok rekonstruálása, hiányzó bizonylatok manuális rögzítése). Vegyünk egy példát:

Adott egy tipikus online rendszer, egy webáruház. Vegyünk egy mindennapi tranzakciót, egy ügyfél megrendelést. A következő folyamat játszódik le a "fizetek" gomb lenyomására:
  • megrendelés rögzítése
  • banki kapcsolat, kártyás fizetés
  • készlet csökkentés webáruházban
  • CRM rögzítés és folyamatok beindítása (ügyfél értesítése, visszaigazolás)
  • ERP feladás (gyártási + szállítási rendelési feladás)

Ne is a legrosszabbat vegyük, amikor egy ilyen tranzakció félbemarad, hanem egyszerűen amikor szerverhiba vagy elérés hiánya miatt korábbi mentést kell visszaállítani. Ez azt eredményezi, hogy a webáruházban visszaáll a korábbi állapot (azaz eltűnnek komplett megrendelések), de például a külső CRM/ERP rendszerekbe a hívás már megtörtént, tehát ott léteznek a tranzakció nyomai: az ügyfél megkapta az értesítést, a gyártási/szállítási folyamat megkezdődött, de a hivatkozások nem passzolnak a hiányzó adatok miatt. Ezt hívjuk egyébként inkonzisztenciának. 

Triviális a megoldás: építsünk olyan clustert, aminek a két lába két különböző helyen üzemel. A technikai kihívás nyilvánvalóan az, hogy valós időben biztosítanunk kell a két szerver közötti tökéletes (bitről bitre) azonosságot. 

Erre az egyik kézenfekvő megoldás, hogy az adatbázist kihelyezzük egy harmadik, önmagában is hibatűrő helyszínre, ahová a webszerverek kapcsolódnak, és minden műveletet ezen a távoli adatbázisban végeznek el. Ez jó megoldásnak tűnik, azonban a kiszolgálási sebesség egyértelmű csökkenése mellett emelik az SPOF szintjét a rendszernek, hiszen keletkezik egy újabb olyan pont, amely kiesése az egész rendszert veszélyezteti. Annyit csináltunk, hogy a webszerverünk sebezhetőségét lecsökkentettük egy kisebb alrendszer, az adatbázisrendszer sebezhetőségére, és amelyre pontosan ugyanúgy érvényesek lesznek a már felsoroltak: ha csak egy helyszínen belül hibatűrő csak az adatbázis, nem vagyunk előrébb.

A másik megoldás, hogy ügyes mérnökeinket megkérjük, hogy biztosítsák adatszinten a két szerver egyezését. Két komponenssel kell igazából foglalkozni: a filerendszerrel és az adatbázissal. A filerendszer szinkronizálására rengeteg megoldás létezik, a teljesség igénye nélkül: hálózati filerendszer, rsync, mirror stb. Az adatbázis folyamatos szinkronizálására pedig a master/slave, standby, replica, logshipping kulszavakat minden gyakorlott IT mérnök kapásból vágja.

Ezek így elméleti síkon akár egyszerűnek is tűnhetnek, azonban a gyakorlatban sajnos már bonyolultabb. A két szerver között ugyanis olyan sávszélesség szükséges, ami távoli helyszínek esetében (ahogy az egésznek értelme van) nem egyszerűen biztosítható. Hiába van a szerverünkön például gigabites hálózati kapcsolat, ha a távoli (esetleg külföldi) szervert csak ennek töredékével tudjuk elérni. Ha nincs megfelelő sávszélesség, a felhasználó jelentős lassulást fog érzékelni (hiszen meg kell várnia, amíg a távoli szerver szinkronba kerül), vagy pedig a konzisztencia fog sérülni hiba esetén, ha engedjük szétcsúszni a szerverszinkront.

Mindezeket csak azért írtam le, hogy a "clustert neki!" vagy éppen a "mire való a backup szerver?" felkiáltások még nem biztos, hogy megoldanak mindent.


Egy lehetséges megoldás...


A hétvégi rendszerleállás margójára

Tibor Kruska, 2012. máj. 2. 2:56   [ 2012. máj. 2. 6:38 frissítve ]

Az április végi hosszú hétvégén, pénteken 15:21 és szombat 11:40 között a magyarországi webszerverünk nem volt elérhető, ez kicsit több mint 20 óra állásidőt jelent. A folyamatos elnézéskérés mellett szeretnénk néhány háttérinformációval szolgálni, és néhány felmerülő kérdésre választ adni:

Mi történt, mit jelent konkrétan az, hogy nem volt elérhető a webszerver?

Az adatparkban, ahol a szerverünket elhelyeztük, lekapcsolták az internetkapcsolatot, így nem lehetett kapcsolódni a szerverünkre. Se a tárhelyet nem lehetett elérni SFTP kapcsolattal, se a webes látogatókat nem tudta kiszolgálni a webszerver.

És a levelezési szolgáltatás?

Mivel az elektronikus levelezést már régóta a céges Gmail megoldás biztosítja, így ez a szolgáltatás zavartalanul üzemelt.

Mi okozta a kiesést?

Az egyik viszonteladó, akitől a mi szolgáltatónk bérli a szerverterem egy részét, teljesítési vitába keveredett a
T-Online-nal, ami odáig fajult, hogy végül a T-Online lekapcsolta a szerverterem internetkapcsolatát.

Mivel a fél internet tele van cégnevekkel, mi is elmondjuk a konkrétumokat: A T-Online-tól bérel egy szervertermet a HostOffice, tőle bérel néhány rackszekrényt többek között a mi szolgáltatónk is, az Axiom-IT, aki közvetlenül szolgál ki minket.

Tehát a teljes lánc ez volt: T-Online » HostOffice » Axiom-IT » ELIT-INFO

Ahogy a mellékelt ábra mutatja, talán túl kockázatos egy ilyen viszonteladói lánc végén állni, nem?

Az üzleti életben azért nem olyan idegen ez a modell. Amíg a lánc minden tagja tudja a dolgát, és teljesíti a vállalásait, addig általában nincs gond. 

A kényelem mellett van egyéb előny is?

A legelső az ár. Ha direktben a T-Online szolgálna ki minket ugyanilyen paraméterekkel, legalább dupla árat kellene fizetnünk a szerverelhelyezésért. 

A másik érv pedig a szolgáltatás paraméterei. Ha mi direkt ügyfelek vagyunk egy adatparkban, ahol egy rackszekrényben néhány egységet bérlünk, akkor magától értetődik, hogy nem engednek hozzáférni a gépünkhöz, sőt, be sem mehetünk a szerverterembe. Mi sem szeretnénk, ha a mi szerverünk mellett piszkálna valamit egy (számunkra) idegen. Ha gondunk van, lekapcsolják a gépünket, kiskocsin kitolják, elvégezzük a szükséges karbantartást, majd visszatolják, visszaszerelik és beindítják. Ez alsó hangon is 50-60 perc állásidő, holott például egy hibás merevlemezt egy perc alatt ki lehetne cserélni, ha hozzáférnénk a géphez, ráadásul "röptében" (hot swap), tehát a szolgáltatásban egyáltalán nem lenne kiesés.

Viszont így, hiba esetén az Axiom-IT mérnökei pillanatok alatt a helyszínre érnek (nekünk legalább egy óra lenne), a saját szervertermükhöz / szerverszekrényükhöz hozzáférhetnek, és megbízásunkból elvégzik a szükséges karbantartást. Közben telefonon tudjuk tartani a kapcsolatot. 

Egyszóval ez több, mint kényelem. Eddig ezek az érvek tartottak minket ebben a láncban.

És mi történt most hétvégén konkrétan?

Ahogy a felügyeleti rendszerünk jelezte a kiesést, felvettük a kapcsolatot a közvetlen szolgáltatónkkal. Először még ők is azt az információt kapták, hogy ideiglenes technikai probléma lépett fel, és minden szolgáltató dolgozik a helyzet mihamarabbi megoldásán.

Kicsivel később már sajnos kezdett nyilvánvalóvá lenni, hogy a helyzet komolyabb, úgyhogy mindenki elkezdte a vészforgatókönyvet végrehajtani. A közvetlen szolgáltatónk munkatársa eddigre már úton volt az Adatparkba (DataPlex), hogy tárgyalással próbálja elérni a hálózat visszakapcsolását. Mivel ők sem közvetlen szerződött ügyfelei a T-Online-nak, ezért a szolgáltató ettől (végülis érthető módon) elzárkózott. 

Hogyan oldódott meg a helyzet végül?

Az Axiom-IT péntek éjjel elintézte (ezúton is köszönjük nekik), hogy egy másik szolgáltatóhoz átpakolják a gépeinket, így ott rá tudtunk kapcsolódni a hálózatra. 

Miért nem értesítettetek minket előre a leállásról?

Ha tudtunk volna előre a leállásról, valószínűleg meg se történt volna, legalábbis nem ilyen időtartamban. Az egészben az a legfelháborítóbb, hogy egy hosszú hétvége előtti szinte utolsó munkaórában, előre nem bejelentve (legalábbis felénk nem jutott el), hogy ne mondjam, előre megfontolt szándékkal sok száz ügyfelet lehetetlenítettek el. A hétvégén ügyelő mérnök kollégák és operátorok sok mindenre fel vannak készítve, de arra nem, hogy új szerződéseket kössenek. Nem beszélve arról, hogy se kereskedők, se jogászok nem elérhetőek ilyenkor. 

Ki a felelős mindezért?

Még nem tudjuk, de nagyon sok cég nagyon sok ügyvéde dolgozik azon, hogy kiderüljön.

Mi történt volna, ha a szolgáltatótok nem tud szerezni új internetkapcsolatot? Addig nem tudtak volna beindulni a weboldalaink?

A webszerverünkről készülő biztonsági mentést egy teljesen másik helyszínen tároljuk. Tehát ha bármilyen okból kifolyólag a szerver nem elérhető, ebből fel tudjuk építeni egy másik helyszínen a komplett szolgáltatást.

És miért vártatok ilyen sokáig? 20 óra rengeteg idő egy nagy forgalmú webshopnál!

Egy ilyen kiesésnél rengeteg döntést kell meghozni, és sajnos nem látunk előre mindent, utólag könnyen tudunk okosak lenni. Az első néhány órában még úgy tudtuk, hogy pillanatnyi technikai probléma áll fenn, ilyen esetekben nem szoktuk azonnal elkezdeni a költözést, mert az eddigi tapasztalatok alapján sokkal gyorsabban megoldódnak a pillanatnyi kiesések, mint ahogy elkészül az új szerver. 

Amikor kiderült a kiesés igazi oka, azonnal elkezdtük a költözést: egy másik szerverre elkezdtük felmásolni az utolsó mentést. És itt adnék választ a konkrét kérdésre: amikor mentésből állunk vissza egy másik szerverre, mindig történik valamennyi adatvesztés. Ugyanis 4 óránként készül mentés a szerverről (általában más szolgáltatók naponta 1x mentenek). Ez azt jelenti, hogy ha mentésből állunk vissza, akkor az utolsó mentés és a leállás (pl. most 12:00-15:21) közötti módosítások (webshop rendelések, blogbejegyzések, kommentek, változott oldalak) elvesznek. Ezt elkerülendő, eddig ezt csak arra az eshetőségre tartogattuk, amikor ténylegesen megoldhatatlan probléma merül fel a szerverrel. 

És fél napig tart egy ilyen szervert felépíteni mentésből?

Természetesen nem. Azonban fokozva az élvezeteket, épp ahogy elkészültünk a tartalék szerverrel, kaptuk a hírt, hogy mégis lesz hálózatunk, megtörtént a megegyezés. Ennek megörültünk, mert így adatvesztés nélkül tudunk továbbmenni, így a tartalék szervert parkolópályára tettük. Sajnos ez utóbbi döntést így utólag már nem tudom egyértelműen pozitívnak értékelni.

Ugyanis megint egy kellemetlen időszak kezdődött, amikor a hozzáférésekre, új IP címekre és hálózati paraméterekre vártunk. Ez is okozott néhány plusz órát, míg végül szombaton 11:40-kor elérhetővé váltak a weboldalak. Ehhez az összes szolgáltatásnál be kellett állítani az új IP címet, az összes olyan ügyfélnél, akinek mi üzemeltetjük a domainjét, megváltoztattuk az IP címeket a DNS-ben.

Mit kell tenni annak, akinek máshol van a domainje?

Nagyon egyszerű: az összes hivatkozást, ahol a 94.125.251.91 IP cím szerepel, le kell cserélni az újra: 
80.249.161.174

Ezt a domain üzemeltetője tudja megtenni, vagy esetleg ahol van DNS módosítást kínáló webes felület, ott közvetlenül is be lehet állítani.

Milyen más következményekkel járhat az IP cím módosulása?

Normál esetben ez elegendő a weboldalak zavartalan működéséhez. Azonban egyes interfészekeknél szükség lehet a jogosultság beállítására a túloldalon. Például ha egy CRM rendszer korlátozza az API elérést bizonyos webszerverekre, ott elképzelhető, hogy az engedélyezés egy konkrét IP címre szól. Ilyenkor jelezni kell nekik, hogy a webszerver IP címe megváltozott, legyenek kedvesek frissíteni az engedélyeket az új IP címre.

Ha legközelebb ilyen rendszerleállás történne, honnan értesülhetek róla?

Praktikus módon a cégünk Facebook oldalára tesszük fel folyamatosan az információkat. Dolgozunk a rendszerfelügyeleti eszközünk fejlesztésén, melynek segítségével értesülhetnek majd a nem várt eseményekről. Ne legyen rá szükség...

Megelőzésként, technikailag nem lehetne megoldani, hogy azonnal legyen elérhető egy tartalék szerver, ne kelljen várni, amíg a mentés felmásolódik?

Ez az egyik dolog, amit mindenképpen át fogunk gondolni hamarosan. 

Itt nem csak annyiról van szó, hogy legyen máshol egy tartalék szerver, hanem hogy az adatok (beleértve fileok és adatbázisok) folyamatosan szinkronban legyenek a két szerveren. Amíg a két gép egymáshoz közel van, ez nem probléma. Azonban egy ilyen eseménynél ez nem segített volna, hiszen egy egész szerverterem esett ki.

Mindenképpen egy másik szolgáltatónál, sőt én azt is mondom, hogy másik országban kell a tartaléknak lenni, mint ahogy jelenleg is Írországban tartalékolunk. Viszont a valós idejű szinkronizálás egy komolyabb weboldalnál, sőt az általunk üzemeltetett néhány ezer weboldal tömegénél ez már több mint egyszerű technikai kihívás.

Mindenképpen dolgozunk rajta, igyekszünk minden elképzelhető katasztrófahelyzetre felkészülni, most már legalább kettővel több van a listánkon :(

És mi történt vasárnap este? Rögtön el is romlott valami? 

Bármennyire is közel volt egymáshoz a két esemény, ehhez tényleg semmi közünk. Vasárnap az egyik központi magyarországi névkiszolgáló szerver hibája miatt "lehalt a fél magyar internet". Ez ellen webszolgáltatói oldalról értelmes módon nem igazán lehet védekezni (csak nemzetközi domainekkel), a megelőzés és elhárítás az Internet Szolgáltatók Tanácsa kezében van.

Cikk ebben a témában:

Sovány vigasz látni azt, hogy még a legnagyobbak is hibáznak.


A vírusvédelem művészete

Tibor Kruska, 2010. szept. 17. 3:36   [ 2010. szept. 17. 3:43 frissítve ]

Ez a könyv inkább informatikus szakembereknek íródott, nekik mindenképpen ajánlani szeretnénk. A többieknek inkább az előszó és a beszélgetés tanulmányozását javasoljuk (lásd mellékletek).

Hivatkozások:
A szerző Szőr Péter (F-Secure, Symantec).

55 5perces tipp weboldalad fejlesztésére

Tibor Kruska, 2010. febr. 11. 5:08   [ 2010. febr. 11. 5:10 frissítve ]

A weboldal szerkesztése olyan feladat, ami soha nem ér véget. Ami pár évvel ezelőtt még működött, az ma elavulttá vált. Az egész weboldal lecserélése általában hatalmas feladat lenne, ehelyett érdemes az alábbi apró lépéseket követve fejleszteni a weboldalunkat.


Négy témával foglalkozunk: 


  • szövegírás
  • használhatóság
  • keresőoptimalizálás
  • ergonómia & design

Mikor törik fel a Te jelszavaidat?

Tibor Kruska, 2010. febr. 1. 23:37   [ 2010. febr. 1. 23:59 frissítve ]


Ügyfeleink néha megkérdezik, hogy miért adunk olyan lehetetlen jelszavakat, mint például faRFeoPxqTLd5vx8 ? 

A bonyolult jelszavakat az indokolja, hogy a hackertámadások sokat fejlődtek az utóbbi időben. Ezek a támadások már mind automatikusak, nem szabad tehát azt hinni, hogy a magányos hacker ül egy sötét és füstös szobában és szótárral a kezében egyesével próbálgatja a szavakat, hogy feltörje weboldalunkat. Egy jó kis hackerprogram ugyanis másodpercenként képes egy fiókot feltörni. 

A Rockyou.com fotómegosztó oldalt ért támadás után egy biztonsági cég az oldal 32 millió felhasználójának fiókját nézte át. A vizsgálatból kiderült, hogy a jelszavak között elképesztő mennyiségben vannak a következők:
  • 123456


  • 123456789
  • Password
  • abc123
  • iloveyou
  • 1234567
Hasonló támadást élt át a Hotmail is, ahol 30.000 felhasználó jelszava vált ismertté. A toplista sajnos itt is hasonlít az előzőhöz.

Nincsenek kétségeink afelől, hogy a kutatás Magyarországon is hasonló eredményt hozna. Helyi sajátosság nálunk, de nem kevésbé veszélyes a keresztnév és születési év kombinációja, pl: a kati82. 

A Twitter ezek miatt bevezette a bolondbiztos jelszóellenőrzést, nem engedi ugyanis, hogy a felhasználók túl egyszerű jelszavakat adjanak meg a regisztrációkor. Tiltólistán vannak az autómárkák nevei, a híres 123456 és társai, valamint a focicsapatok nevei is. 

Tanácsaink jelszavakhoz

  • aranyszabály, hogy ne ugyanazt a jelszót használd minden felületen (a felhasználók fele ezt teszi). Ha valaki megszerzi az egyik jelszavadat, nyitva áll az útja az egész online életedhez.
  • a jelszó mindig álljon számok, kis és nagybetűk kombinációjából, és legalább 8 karakterből. Minél hosszabb és bonyolultabb egy jelszó, annál nehezebb feltörni brute-force (nyers erő) módszerrel, jelszó szótár segítségével.
  • ne legyen a jelszavad hozzád köthető, még részletekben sem. A párod / háziállatod neve nagyon könnyen kitalálható, bár ezzel nem az ázsiai hackergyerekek tudnak visszaélni.
  • időről-időre változtasd meg a jelszavaidat. Persze semmi értelme annak, hogy a nagyvállalatoknál szokásos módon havonta minden jelszót megváltoztatsz, de legalább az érzékeny információkat, értékeket védő jelszavakat néha változtasd meg. 
  • ne tárold el a jelszavakat olyan gépen, amit más is használ.
  • próbáld megjegyezni a jelszavaidat, ne írd fel sehová, legalábbis védetlen helyre semmiképpen. Nagy cégeknél teljesen tipikus, hogy a nagyvezér a monitorára ragasztja a jelszavait. Egy takarító (vagy annak álcázott kém) így simán hozzáférhet érzékeny információkhoz, vagy akár közvetlen anyagi kárt is okozhat.
  • jó ötlet egy komolyabb jelszót memorizálni (beírva sokszor egyszerűbb mint kimondani), majd minden rendszerhez kitalálni egy előtagot és utótagot, amit viszont önmagában már le lehet jegyzetelni, esetleg gyakrabban változtatni.
    • Pl. a megjegyzett jelszó: r5ZmspW9, ezt soha, sehol nem írjuk le, nem mondjuk ki, csak a fejünkben van.
    • az egyes jelszavakat pedig így állítjuk össze, és jegyzeteljük le: 41.....rT, vagy 38......vA, ahol a kipontozott részbe beíráskor (!) a megjegyzett "mester" jelszót helyettesítjük be.
    • természetesen itt is fontos, hogy a mester jelszót néha változtassuk meg.
  • Windows alatt óvatosan bánjunk a jelszó beírásokkal. Ez itt most nem hitbeli kérdés, bármennyire is a Unixokat (Linux, Mac OS X) favorizáljuk. Tény az, hogy Windows alatt gyakran előfordulnak trójai, spyware programok, vírusok; amelyek akár a billentyűleütéseket is figyelik, és továbbítják a rosszindulatú gazdájuknak.
  • ha ellopták a telefonodat / laptopodat / noteszedet vagy bármit, amiben jelszavakat tároltál, azonnal változtasd meg mindenhol a jelszavaidat.

Csak vicc: Online jelszavunkat felírhatjuk bankkártyánk hátuljára is, bankkártyánk PIN kódját beírhatjuk a mobilunk telefonkönyvébe, a SIM kártyánk PIN kódját pedig a hűtőnkre. Mese nincs, a kaputelefon kódját meg kell jegyezni. :-)

A Twitterezők 6 típusa

Tibor Kruska, 2010. jan. 30. 10:53   [ 2010. jan. 30. 10:57 frissítve ]

Kedvenc írónk, Guy Kawasaki szerint a Twitterezőket 6 csoportba oszthatjuk:

    >>> teljes cikk itt

    Elindult a Web 2.0 tanulmánysorozat

    Tibor Kruska, 2010. jan. 28. 1:33   [ 2010. jan. 28. 1:41 frissítve ]



    Ez egy valódi webkettes tanulmánysorozat, röviden és tömören, technikai szemmel nézve az online közösségépítő eszközöket.

    Wordpress, Drupal, Google Webhelyek, melyik mire (nem) jó

    Tibor Kruska, 2010. jan. 25. 13:12   [ 2010. jan. 25. 14:46 frissítve ]


    Az ingyenes tartalomkezelőkkel kapcsolatban gyakran fellángol a vita azzal kapcsolatban, hogy melyik jobb, melyiknek mik az előnyei és hátrányai. Úgy gondoltuk, ideje - reményeink szerint - objektíven összefoglalni a tudnivalókat és egy kis összehasonlítást készíteni a két vezető CMS (Content Management System = tartalomkezelő) rendszerről (WordPress, Drupal) és a Google Webhelyekről. Mivel mindhármat meglehetősen jól ismerjük, ezért úgy gondoltuk, hogy unalmas statisztikák helyett inkább a saját tapasztalatainkból merítünk.


    A "futottak még" kategóriából való rendszerekkel is dolgoztunk, de velük itt és most nem foglalkozunk:

    WordPress : csak blogolásra, vagy mégsem?

    Bár a legtöbben alapjában csak blogírásra használják, valójában ennél többre is kiválóan használható. Legfontosabb kiemelni, hogy a kezelése rendkívül egyszerű, és a telepítése sem igényel különösebb előképzettséget, bár az oldalukon hirdetett híres "2 perces telepítés" azért nem teljesen fedi a valóságot. Ha az ember kifejezetten csak blogírásra szeretné használni, akkor a Wordpress remek választás, hiszen a telepítést követően máris üzemkész, és azonnal publikálhatjuk is vele a bejegyzéseinket.

    A WordPressben szinte minden alapból megtalálható, nem kell órákat eltöltenünk a neten, különböző pluginok, kiegészítések után kutatva. A blogbejegyzéseinket az olvasók kommentezhetik, működik a trackback (visszalinkelés) is. 

    A WordPress egyszerűsége és jól kezelhetősége mellett nem alkalmas legvadabb webfejlesztői álmunk megvalósításaira. Gyakori kritika vele szemben, hogy nem fejlesztőbarát, és ez igaz is. Az egyedi fejlesztések megvalósítása, a testreszabás nehezen megvalósítható, és sokszor előfordul az is, hogy a WordPress egy-egy frissítése az előző verzió alatt készített fejlesztéseket nem támogatja, rosszabb esetben pedig az egész oldalunk működésképtelenné válhat.

    Előnyei:
    • egyszerű kezelhetőség
    • kiváló blogíráshoz, bejegyzések publikálásához
    • szaktudás nélkül is könnyen megtanulható
    • rengeteg, igényes kinézetű ingyenes sablon áll rendelkezésre
    Hátrányai:
    • nem fejlesztőbarát
    • a WordPress fórumokon gyakoriak a panaszok
    • a biztonságos és megbízható működéshez naprakészen tartani a rendszert a legújabb WordPress frissítésekkel

    Drupal: a fejlesztők álma

    Ez a rendszer sokszor jobban hasonlít egy fejlesztői felületre, mint egy CMS rendszerre. Ez persze nem azt jelenti, hogy csak a fejlesztők képesek vele elboldogulni, de az biztos, hogy jobban otthon fogják benne magukat érezni, mint a másik két rendszer esetén. A fejlesztőbarát érzés sajnos nem teszi automatikusan felhasználóbaráttá is a rendszert, ugyanis a különböző funkciók működtetéséhez sokszor nem elég az egyébként egyszerűen letöltött Drupal alkalmazás. 

    Rengeteg egyébként alapvetőnek hitt funkció (Pl: HTML szövegszerkesztő, képfeltöltés, video feltöltés) működése mind-mind külön letöltendő modult jelent, melyeknek dzsungelében (több ezer van belőlük) nagyon könnyű eltévedni. A modulok kiválasztása, letöltése néha komoly próbát jelenthet a kevésbé tapasztalt felhasználóknak. 

    A szinte végtelen bővítési lehetőségek ellenére a Drupal profizmusa nem mindig látható az oldalak megjelenésén. A WordPress rendkívül tetszetős és változatos sablonjaival szemben a Drupal sminkjei nem sok szépséget tartogatnak.

    Előnyök:
    • rendkívül fejlesztőbarát
    • erős felhasználói közösség és rengeteg elérhető modul
    • egyedi igények megvalósíthatók
    Hátrányok:
    • nem felhasználó és designer  barát, fejlesztői ismeretek nélkül nehéz jót kihozni belőle
    • kevésbé vonzó megjelenés
    • profi kialakítás sok időt vesz igénybe

    Google Webhelyek: az arany középút?

    A legfontosabb különbség az előző kettővel szemben, hogy a Google Webhely valójában nem egy CMS rendszer. Nagyon fontos, hogy nincs szükség hozzá tárhelyre, nem kell tehát tárhelyet bérelnünk, hiszen a tárhelyet maga a Google biztosítja a weboldalunkhoz, természetesen ingyen, mégpedig 10 GB-ot! 

    Ebből adódóan nem kell semmit sem telepítenünk, gyakorlatilag azonnal használható weboldalt kapunk. Bár nem válogathatunk annyi sablon közül, mint a WordPress esetén, bizonyára találunk olyan felületet, ami megjelenésében kedvünkre való. 

    További előnye, hogy tökéletesen felhasználóbarát, bár nem kínál annyi lehetőséget, mint a Drupal, cserébe viszont nagyon egyszerűen kezelhető. Gyakorlatilag aki képes egy szövegszerkesztőn dolgozni, az ezzel is elboldogul. 

    Természetesen az előző két megoldáshoz hasonlóan, saját domainünk alatt fut a weboldalunk, mindössze az oldal alján található kis felirat árulkodik az üzemeltetőről (lásd a mi weboldalunk láblécét is).

    Előnyök:
    • nincs szükség tárhelyre, így jelentős költséget takaríthatunk meg
    • azonnal használható, nincs szükség telepítésre
    • rendkívül egyszerűen kezelhető
    • nincs szükség frissítések letöltésére
    • adatbiztonság és profi technikai háttér a Google szerverein
    • azonnali ötletek, kampányok megvalósítására tökéletes megoldás
    Hátrányok:
    • nem fejlesztőbarát
    • egyedi elképzelések korlátozottan valósíthatók meg


    Összefoglalva elmondhatjuk tehát, hogy mindhárom rendszernek megvannak a maga előnyei és hátrányai, nekünk kell tehát az egyéni elképzeléseinkhez megtalálni a legmegfelelőbbet. 

    Ha azonban a szempontjaink között elsődleges az egyszerűség, a költségek csökkentése, a felhasználóbarát működtetés, akkor a Google Webhelyek jelentik az ideális megoldást.

    Biztonságosabb Gmail HTTPS-en keresztül

    Tibor Kruska, 2010. jan. 25. 5:02   [ 2010. jan. 25. 5:28 frissítve ]

    A Gmailben eddig opcionális volt a biztonságos kapcsolat, mostantól viszont alapértelmezetté vált mindenkinek a HTTPS-en keresztüli (akár saját domaines) Gmail használat. 

    A HTTPS-alapú titkosítás biztonságossá teszi az adatok forgalmát, miközben a böngészőtől a Gmail szerverekig továbbítódnak, így mások nem tudják leveleinket illetéktelenül elolvasni. 

    Például egy nyilvános WiFi hálózaton a titkosítás nélküli HTTP kapcsolat viszonylag egyszerű eszközökkel "lehallgatható", tehát ahogy a szerverről töltődnek le az üzenetek a böngészőbe, a levelek részletei kódolatlan formában haladnak a hálózaton.

    Az igazsághoz hozzátartozik, hogy a jelszó, mint a legérzékenyebb információ, eddig is biztonságos HTTPS módszerrel utazott a hálózaton, tehát a Gmail jelszavunkat eddig sem volt könnyű megszerezni. 

    Mielőtt bárki az első követ vetné rá a Gmail-re, eláruljuk, hogy a legtöbb email szolgáltatótól a mai napig is titkosítatlan formában, POP3 protokollon lehet csak letölteni a beérkező üzeneteket, illetve a szintén kódolatlan SMTP protokollon keresztül pedig elküldeni a kimenő üzeneteket. A titkosítatlan jelszavak kódolatlan továbbításáról nem is beszélve...

    Így kell kinézni a böngésző címsorának levelezés közben:  (Figyeljük a HTTPS előtagot és ikont.)


    A biztonságos kapcsolat átállítható a következő menüpontban: "Beállítások / Általános / Böngészőkapcsolat"


    Marketing Expo: agymosás vagy hasznos kapcsolatépítés?

    Tibor Kruska, 2010. jan. 22. 3:57   [ 2010. jan. 22. 4:43 frissítve ]

    Tegnap mozgalmas napunk volt a Marketing Expo kiállításon: a több, mint ezer látogató 15 %-a volt kíváncsi ránk.
    A nagy érdeklődés köszönhető volt a helyben kitölthető levelezési IQ tesztünknek, meg persze a csinos és ügyes hostess lányainknak is. A tesztet hibátlanul kitöltők névjegyeit kitettük a dicsőségtáblánkra is, ami a bajnokokat nagy büszkeséggel töltötte el.

    Egy üzletkötés után az új megrendelőnk megkérdezte, hogy bár a tesztje nem lett hibátlan, nem tennénk-e ki a névjegyét? Az aláírt megrendelőlapot látva meglágyult a szívünk...

    Üzleti szemmel nézve remek volt ez a kiállítás: olyan vállalkozókkal tudtunk találkozni, akik tökéletesen tisztában vannak a webes minőségi jelenlét fontosságával, ahol a minőségi jelző sokszor nagyon egyszerű, de ötletes megoldásokat takar.

    Remeknek éreztem a kapcsolatot a kiállítók között is: oda-vissza küldözgettünk egymásnak érdeklődőket, hiszen mindannyian tudjuk, hogy mindenki akkor jár a legjobban, ha az adott területen a leginkább hozzáértő csapat szolgálja ki.

     
     
     



    1-10 of 15