Ubuntu Natty a házban.

Korábbi Ubuntu frissítési fiaskók révén a fő munkagépen, a netbookon (és ami azt illeti, a desktopon is) az volt a policy, hogy ezeken a gépeken egy jó régi verziót tartok, ami biztosan működik.

Fiaskók: Ubuntut frissíteni, úgy érzem, úgy kell, hogy az ember időt szán rá. Lemegy a kétklikkes frissítés, mindenki boldog, csillog-villog az új felület, aztán jönnek a kis idegesítő dolgok, a release critical bugok, amiket valamiért mégsem zártak le release előtt… Erre idő kell. Én meg lusta vagyok.

Ilyen megfontolásból tehát a netbookon (és ami azt illeti, a desktopon is) Lucid volt, ami ugye a legutóbbi LTS verzió. Tökéletesen működött.

Viszont a Natty release-ekor elkezdett viszketni a tenyerem: talán már nincsenek release critical bugok, és különben is, ezt a Unity-t annyian szidják, hogy még akár jó is lehet. Új, átgondolt felület, ami miatt nincs többé szükség a Netbook Remixre a netbookon (és ami azt illeti, a desktopon is)?
Szó szót követett (persze a fejemben csak) (és ami azt illeti, a desktopon is) és a hétvégén felpakoltam a Natty-t a netbookra. Voltak baljós előjelek: hétfőtől project golive előtti utolsó hardcore teszt, kedden golive, tehát nagyon fontos a jól működő gép — mikor máskor ugorjak az ismeretlenbe, nemigaz? De fasz vagyok, nem bírtam magammal.

Enter Natty.

Egyelőre meg vagyok lepve, de a gép működik. (Természetesen nulláról telepítettem, a /home partíció meghagyása mellett.) Kövezzetek meg, de nekem ez a Unity bejön, eltekintve attól (de más hátrányát tényleg nem tudnék mondani), hogy lenyúlja a <super> billentyűt, vagyis a vindózgonbot a saját színes-szélesvásznú „mindenmenüjére”, márpedig nálam minden shortcut eddig a vindózgonb+valamire volt mappelve. A megoldás egyszerű:
apt-get install aptitude
aptitude install compizconfig-settings-manager
Majd a telepített compiz settings managert elindítva az Ubuntu Unity Plugin alatt szépen átállítottam bármire a „Key to show the launcher” opciót. (<Control>less-re egyébként.)

Ezen felül a következő kisebb-nagyobb bugok vannak:

  • Kétképernyős módban nem működik, teljesen szétcsúszik a kép, a grafikus baszkurálókának pedig nincs olyan opciója, amivel ezt ki lehet küszöbölni. Ha nagyképernyőre dugom, marad az „egy nagy képernyő” mód. (Meg is van a kapcsolódó bug report: itt és itt is.)
  • Sleepből visszahozva a gépet nincs WiFi. Kiküszöbölhető úgy, hogy a /etc/default/acpi-support fileban megkeressük a STOP_SERVICES sort és odabiggyesztjük, hogy „networking”. (Persze ezen a ponton átlagfelhasználónak bukott az Ubuntu upgrade.)
  • Most itt a cikk írása közben egyszer csak elmúlt a WiFi-m, restart kellett hogy visszahozzam. Volt persze biztonsági rendszerfrissítés, lehet, hogy az kavart be valamit.

Ezen felül viszont látszólag működni látszik a látszólagos cucc. Tetszik, hogy a Unity felszabadít egy kis helyet az amúgy nagyon kicsi kijelzőn, és alapvetően tetszik ez a szemcukorka. Meglátjuk, hogy teljesít hétköznapi használatban.

Amazon leállás update.

Pár hozzáadott megjegyzés illetve follow-up hír érkezett az Amazon EC2 leállásos postra:

  • Egyrészt Tyraelhozzáadott némi háttérinfót a dologhoz — köszi, insightful. Kiemeltem a lényeget:
    • konkrétan az EBS illetve az erre épülő RDS és ELB szolgáltatások borultak fel
    • az Amazon availability zónák nem függetlenek egymástól, ezért hiába volt sok felhasználónak multi zone failover clustere, csak a szerencsén múlott, hogy működik-e vagy nem
    • további két érdekes blogpost: 1, 2
  • Másrészt két további infomorzsa az eset utóéletéből:

Észrevételek az Amazon leállásról.

Sok érdekes „aftermath” cikk jelent meg az Amazon Elastic Computing Cloud (EC2) múlt heti, elég hosszúra (majd’ 4 naposra) sikeredett kieséséről. Saját nevet is kapott („amazonpocalypse”), érezhetően-láthatóan befolyásolta az internet működését (tehát kiderült, hogy az Amazon egyfajta Single Point of Failure-ré avanzsált), és végső soron az EC2 a cloud szerverhosting szolgáltatások zászlóshajójának tekinthető, úgyhogy a zemberek kicsit megálltak és esetenként talán el is gondolkoztak ezen a cloud nevű „félig lufi, félig bölcsek köve” jelenségen.

Az utózönge-cikkek természetesen egyöntetűen egyetértettek abban, hogy még egy ilyen illusztris cloud szolgáltatás is megfekszik, következésképpen célszerű a szolgáltatásaidat tükrözni, mégpedig szükség esetén (a szeretnéd, hogy működjön a szolgáltatásod) másik, független szolgáltatásba. Mert hiába egy Amazon redundancia, láthatjuk, hogy az is megfekszik. Igaz a dakota mondás: ne tartsd a tojásaidat egy kosárban.

Aztán persze egy ilyen leállás felveti azt a problémát is, hogy hol is van konkrétan az adatod. Amíg az ember a felhők közt jár (a cloudban, ugye), esetleg kevéssé gondol arra, hogy nem tudja, hogy hol van az adat. Egy ilyen leállás első pár órájában azt sem tudja, hogy megvan-e még az adat, és ez gyomorszorító érzés. Amazon alapszolgáltatás esetében egyébként (sejtem hogy még ma is) első körben a fórumokat ajánlják lelki támasznak, biosupport nincs; némi extra pénzmag (azt hiszem talán havi 400 dollár) és kb. 1 nap körömrágás árán viszont kaphatsz gold supportot, ahol akár már telefonálhatsz is. (Hiába, a valódi szekértelem sehol sincs ingyen!)

Az adatvesztés veszélyére a kézenfekvő válasz pedig természetesen a fizikai backup rendszer fenntartása — vagy egy szimpla offsite backup formájában (persze cégmérettől, és az adat fontosságától függően azért óva intenék mindenkit attól, hogy egy Time Machine jellegű tákolt megoldásra backupoljon), vagy valami komolyabb, fizikai valóságban megfogható, eltehető, előszedhető, visszaállítható mentés formájában, amire backup policy van, és hasonlók.

Mellékszál, de felmerül az is, hogy egyáltalán mi van akkor, amikor szerződést bontasz pl. egy Amazonnal, vagy tönkremegy alólad a cloud hosting cég. Kevéssé ismert tény, de a mostani leállás ráirányította a fényt, hogy tavaly és idén az USA-ban 4 nagy cloud szolgáltató húzza le a rolót. Mi történik azzal az adattal? Migrálható? Ha szerződést bontasz, az adatot valóban törlik, vagy csak úgy ottmarad, szanaszéjjel? Ezért is fontos kérdés, hogy fizikailag vajon hol van az adat. Szerződésbontás esetén hogyan garantálja a cloud szolgáltató, hogy valóban megsemmisíti, vagy legalább biztonságosan törli/tárolja az adataidat?

És még egy érdekesség: szintén kevéssé publikált fonákja az Amazon sztorinak, hogy a négynapos leállás ellenére nem sérült az EC2 SLA-ja. Mivel az ügyfél az EC2-re köt szerződést, az SLA is arra szól. A leállás viszont nem a szűken vett EC2-ben, hanem csatolt (igaz, létfontosságú) szolgáltatásokban történt. Az Amazon egyébként 99,95% rendelkezésre állást biztosít éves szinten, ami elég magas követelmény, de hát persze így könnyű.

A cloud szolgáltatásoknál tehát kb. a következő pár dologra érdemes figyelni:

  1. Először is, ha olyan az adatod, inkább építs/vásárolj/bérelj saját megoldást. („Olyan”: fontos, vagy magas biztonsági szintű.) Ha nem tudod vállalni azt, hogy esetleges szolgáltatóváltás esetén nem lehetsz biztos abban, hogy a régi szolgáltató nem lép fel iszonyat magas data privacy risk-ként, ne is vágd cloudba a fejszédet.
  2. Redundancia, redundancia, redundancia! És nem csak szolgáltató szinten belül: ha számít a szolgáltatás folytonossága, hozz létre több szolgáltatóra épülő redundáns rendszert. Nem olcsó, de nem is híg a leve.
  3. Legyen a live szolgáltatástól független backup megoldásod! Már ha egy heti inkrementálison csücsülsz, nyugodtabban alszol.
  4. Mindig legyen biosupport! Az idő 95%-ában nincs rá szükséged (bár egyébként egyszerűsíti az életet), de a maradék 5%-ban hálát adsz, hogy belefeccöltél.
  5. A szolgáltatóiddal (a live szolgáltatás, a backup szolgáltatás, és a support is) legyen jó, működő SLA-d. Cloud esetében talán ezt a legnehezebb elérni, hiszen reménytelen, hogy egy Amazon a te kedvedért extra klauzát épít be a szerződésbe.

Nagyjából összefoglalható úgy a dolog, hogy jó dolog a cloud, de az igazán biztonságos rendszer az, amibe bele tudsz rúgni: néhány nagyvas a datacenterben, és a support személyzet… (Itt kérek elnézést a rendszergazda kollegáktól.)

A fentiekhez disclaimer jelleggel azért hozzáteszem a következőket:

  • A mostani leállás győztesei természetesen mi, felhasználók leszünk: a cloud szolgáltatók nyilván össze fogják magukat kapni, és ezek a szolgáltatások magasabb biztonsági szintre fognak idővel lépni. Persze az ördög nem alszik, a felhaszálói oldali redundancia szüksége nem múlik el.
  • A fentiekkel nem azt akarom sugallni, hogy mostantól az állatorvos weboldala is saját szerveren kell majd fusson — nyilván igénye válogatja, hogy mire érdemes shared hostingot, mire cloudot, és mire skálázott saját megoldást választani. A biosupportot viszont a saját nyugalom megőrzése érdekében mindenkinek ajánlom, akármit is választ.