funny utp cable
  en [english]
japán földrengés - segíts te is!
2011-03-16 23:51 [ZL]
Úgy gondoljuk, hogy mindenki úgy segítsen a katasztrófa súlytotta japán embereken, ahogy tud. Felsorolni nem lehet azokat az érveket, amiért a japánok ezt megérdemlik.
Ha pusztán a technológia felől közelítjük, akkor itojun munkássága az IPv6 területén önmagában elegendő alap ehhez.

Azt találtuk ki, hogy mindenki, aki igazolhatóan adakozik/adakozott a japán földrengés helyreállítására legkésőbb 2011. április 1-ig 1 000 és 30 000 Ft közötti értékben, az 2011 folyamán teljesen felhasználhatja ezt az összeget webhoszting vagy mentés szolgáltatásunk igénybevételére. 30 000 Ft-nál magasabb adományok esetében, az összegtől függetlenül, 30 000 Ft használható fel.

A kedvezmény akár önmagában is használható, tehát nincs semmi megkötés arra, hogy kiegészítő szolgáltatást kellene mellé rendelni.
Természetesen nem feltétel a kedvezményes időszakon túlnyúló "hűségnyilatkozat" sem, egyátalán nem célunk a katasztófából plusz üzletszerzés. Egyszerűen konvertáljuk a munkaidőnket és a rendelkezésre álló szabad gépparkunkat Japánnak küldött adományokká.
Az adományozásról szóló igazolásokat 2011. június 1-ig fogadjuk el.

A rendelkezésre álló helyünk +25 db webhosting és +4 TB mentés kezelését biztosan lehetővé teszi, ami szerény lehetőségeinkhez képest számottevő adományt jelenthet. Ha valaki egyszerűen nem férne be az elkövetkező időszakokra, mert nem bírjuk erőforrással, akkor is kitalálunk valamit számára.
integráció - első szint elkészült
2011-03-16 22:11 [ZL]
Örömmel számolunk be róla, hogy az integráció első hulláma elkészült. Ezzel a mentési rendszer teljesen az új rendszer hatáskörébe került.
Ezzel együtt az U1 (1 napos, napi 1x) mentést a következő 10 nap folyamán U2-re (2 napos, napi 1x) növeljük. Erről ügyfeleinket egyedileg fogjuk értesíteni, amikortól ez rendszerükre életbe lép.

Régi adósság, hogy a összefoglaljuk egy jó mentési rendszer ismérveit.
Addig sok helyen megvalósított a mentés, hogy valamilyen szoftverrel (rsync, amanda, tar + scp) valahol elhelyezik a menteni kívánt adatok másolatát.

Nézzük ennek a buktatóit:
  • A mentés nem fut le, erről nincs értesítés.
  • A mentés nem fut le, erről ugyan e-mail érkezne, de az levelezőszervernek is problémája van vagy éppen a spamszűrő rendetlenkedik és hosszú ideig elvesznek az üzenetek.
  • FTP-n vagy egyéb titkosítatlan megoldással áramlik az adat a mentőszerverre.
  • Ugyanarra a szerverre történik a mentés, mint a mentett adat. Egy komolyabb hardverhibánál vagy feltörlés miatti rombolás során semmi nem marad.
  • A mentés külső gépre történik, de az nincs monitorozva, így annak leállásáról akkor értesülnek, amikor vissza kellene valamit állítani. Ugyanez érvényes akkor is, ha a mentőszerver újraindult és nem indultak be a szükséges szoftverkomponensek/tömbök.
  • Gyakori megoldás, hogy két szervert keresztben mentenek, így egyik ügyfél adata egy másik ügyfél szerverén megjelenik és viszont.
  • Az előző különleges esete, amikor a mentőszerveren nem odavaló szolgáltatások futnak, mert "elbírja" illetve a nap egyes részeiben úgysem csinál mást a szerver. A plusz szolgáltatás növeli a feltörés kockázatát.
  • A mentőszerver ugyan szeparált és monitorozott, de a mentésre használt diszk nem valamilyen megbízható raid megoldás, esetleg nincs monitorozva ennek szétesése. Ilyenkor a toleráltnál több diszk kiesése akkor derül ki, amikor vissza kellene állítani valamit.
  • Feltelik a mentőszerver, ezért nem tud a mentés teljesen lefutni, hiányos lesz.
  • A mentőszerver kulcsos authentikációval éri el a mentett szervert, minden szervert azonos kulccsal és ez a kulcs kiszivárog.
  • Hibázik a mentőszerver valamelyik komponense, így mentés visszaállításnál derül ki, hogy hibásak fájlok.
  • Többnapos a mentés, viszont egy tömbre/diszkre történik az összes nap mentése. Így ennek meghibásodásakor egy napnyi mentés sem áll rendelkezésre.
  • A mentőrendszer "meghibban" a nem ASCII fájlnevektől vagy space karakterektől.
  • A mentőrendszer nem jelzi, ha jogosultsági problémák miatt egyes fájlokat nem tudott menteni.
  • A mentés tartalmaz olyan fájlokat, amiket más scriptek készítenek el (jellemzően SQL dumpok). Amikor ezen scriptek nem futnak le egy meghibásodás miatt, akkor a "semmit" menti a rendszer, vagyis a régi-elavult fájlokat lehet csak visszaállítani.
  • Jó ötlet rossz kivitelezésben: hardlink megoldásos többszöri mentés, ahol a legutolsó fájl megváltozás visszamenőleg az összes példányát felülírja.
  • Helytakarékosság miatt a mentés előtt vagy azzal együtt történik a már megszűnt fájlok törlése. Ekkor egyes esetekben egy megszakadt mentés azt eredményei, hogy új mentés még nincs, régi már nincs.
  • Nem menti a rendszer el a fájlok attribútumait, tulajdonosát vagy ACL beállításait és ez visszatöltésnél derül csak ki.
  • Emberi tényező (figyelmetlenség) okozhatja, hogy "kimarad" fontos útvonal a mentendő halmazból és ez csak visszaállításnál válik világossá.

    Az általunk biztosított mentés mentes a fenti hibáktól:
  • Monitorozott a teljes folyamatra, RAID tömbökre, feltelésre, fájlok darabszámára, összméretére.
  • A felhasznélónév+jelszó pároson felül plusz openvpn kulccsal vagy SMS hitelesítéssel engedi ügyfeleinket hozzáférni az adathoz kizárólag SSH-n keresztül, plusz a hozzáférőket virtualizált mini-környezetekkel szeparálja a normál uid/gid védelmen felül.
  • rsync státuszra ellenőrzött
  • ssh-n biztosított az adat védelme a másolás során
  • Képes jelezni, ha a mentés elavult fájlokkal dolgozik, amik nem változtak meg a kívánt scriptekkel (pl. SQL dump scriptek)
  • A fájlok integritását folyamatosan ellenőrzi a rendszer, nem elégszik meg az időbélyeg és méret egyezőséggel.
  • Akár 1 óránként is futhat mentőscript anélkül, hogy egymásra szaladna két időzítés (zárolás mechanizmus ezt megakadályozza)
  • A többszöri mentéseket "szétszórva" tároljuk, így egy tömb meghibásodása nem jelenti, hogy nem marad visszaállítható mentés.
  • Beszabályozható az rsync az összes opcióra, kérhető utólagos törlés, jogosultságok teljes vagy részleges megtartása.
  • A szerverek egyedi ssh kulccsal engedik be a mentőszervert, a kulcsokat titkosított partíció tartalmazza.
  • Létezik olyan mentési típusunk, ami minden olyat lement a szerverről, ami más mentésekben nem szerepel. Ez kiválóan pótolja azokat az emberi hibákat, amik elfelejtett útvonalak miatt adódnának.

    Jelentős újdonság, hogy tudunk biztosítani "vezérelt" mentést, amikor a mentőhardvert is ügyfelünk adja, mi csupán ennek hibamentes vezérlését adjuk. Ilyen mentésekkel megoldható kivételes adatbiztonság és titkosított mentés/mentés titkosított fájlrendszerre is, ami során senki nem tudja elérni az adatokat, aki nem rendelkezik a szükséges titkosító kulccsal. Ez kiváló megoldás lehet ipari titok megvédésére, mert még a szerver elszállításával, a diszkek szétszerelésével, az operációs rendszer preparálásával sem nyerhető ki a védett adat. (A titkosító kulcsot célszerűen csak ügyfelünk ismeri.)
  • Migrálás 1.
    2011-02-27 22:36 [ZL]
    Napok óta megy a "Nagy Mentés Átszervezés" és jelentem, sokkal jobb az új rendszer, mint a régi volt.

    Legnagyobb nyereség, hogy a különböző rotációk szétszórva mehetnek egymástól független tömbökre.
    Tehát egy 5x24 rotált mentés akár 5 különböző helyre készülhet, jelentősen csökkentve annak lehetőségét, hogy egy tömb meghibásodása érintse az összes napi mentést egyszerre. Gyakorlatilag innen már egy lépés a mentés tömböket egymástól független földrajzi helyekre telepíteni. Itt ugyan még nem tartunk, de a rendszer már képes rá.

    Pont ezen a héten volt egy vita arról az egyik ismerős cégénél, hogy mi a jobb: bérelni egy virtuális gépet a levelezésnek vagy elköltöztetni az egészet a GMail alá.
    A verhetetlen érv az volt szerintük, hogy a Google 1000% megbízható minden szempontból, még mentésről sem kell gondoskodni.
    Erre mit találok ma? I lost all of my mails.
    Nem jártam utána a pontos oknak csak azt látom, hogy sokakat érint.

    Úgy fest, hogy néhány GMail felhasználó a saját kárán tanulja meg, hogy a független (és monitorozott) mentés mennyire fontos.
    rsync 3.0.7 --time-limit folttal @ amd64
    2011-02-25 21:24 [ZL]
    Rsync verzió: 3.0.7
    Oprendszer: Debian 6.0
    Kiegészítő: time-limit.patch
    Letöltés: rsync_3.0.7-2_amd64.deb
    MD5 hash: b0677b8548abd5c5ac5e7c51f4df368f
    SHA1 hash: 6c50aa9d4d31e66686758dbfb970e7c5ab07edc5
    Szívesen!
    2011 - az integráció és hatékonyság éve
    2011-02-17 23:11 [ZL]
    2011. február 1-től az évek alatt elkészült, de nem igazán integrált rendszereinket egy központi megoldásba egyesítjük.

    Az integráció érinti a monitoring, mentési rendszer, weboldal, email/ftp/access switch, DNS rendszereket. A kevéssé együttműködő és emiatt nem kellően hatékony, többféle programnyelven megvalósított rendszerek helyett egy teljesen újraírt logikára állunk át fokozatosan. A rendszert saját fejlesztésű motorra építjük.

    Az sikerekről, sikertelenségről folyamatosan beszámolunk, ezzel könnyítve meg másoknak is az ilyen átszervezéssel kapcsolatos, sokszor fájdalmas döntést.
    PRK - ezt jól megkaptuk
    2006-11-23 16:30 [ZL]
    A jelek szerint megkimélt minket a sajtó munkatársa: az Index cikke. Csupa szépet írt, igazán csak a választékot szidalmazta. Ezt még túléljük valahogy.
    PRK - első nap
    2006-11-22 16:23 [ZL]
    Jól vizsgázott a PIGMENTA REPRODUKCIÓS KIOSZK rendszere az első nap. Nem jártunk úgy, mint Bill Gates, aki a heves demonstráció közben kapott egy szép védelmi hibát. Meg is lepődtünk volna, ha a Fedora Core5 alapú rendszer ilyet produkál. :)
    Tessék ellátogatni a Szépművészeti Múzeumba, egy kis kultúra még senkinek nem ártott meg!
    PIGMENTA REPRODUKCIÓS KIOSZK
    2006-11-22 08:37 [ZL]
    Ma délelőtt 11 órakor a Pigmenta Kiadó megnyitja első önkiszolgáló reprodukciós nyomtatóállomását a budapesti Szépművészeti Múzeumban. A megoldást kiszolgáló szoftver fejlesztésével járultunk hozzá ehhez a művészetet és modern technikát közel hozó rendszerhez.
    A művészi nyomatokról további információ a www.pigmenta.hu weboldalon található.




















     

    HÍRCSOPORTOK
    ÜGYFÉLKAPU
    Mi MAGUNK
      Bit Vader
      Blog